search for: subdrivers

...that this is simply a case of doing: > > subdriver_t some_subdriver = { > /* ... */ > some_format_serial, > NULL, > } > > Rather than: > > subdriver_t belkin_subdriver = { > /* ... */ > belkin_format_serial, > belkin_init, > } > in the subdrivers that don't need init()ing? Yes. > >- change the call to: > > > > if (subdriver->init != NULL) { > > subdriver->init(); > > } > > As I've found out since I came up with the original idea (see one of my > previous messages) I can...

On Feb 10, 2014, at 1:16 AM, ??? ????? wrote: > Thanks for you reply. Concerning the subscribtion list, I have earlier filled in the fields and sent request to subscribe to this list, but still haven't got an answer. I added you manually, but check your spam folder just in case it ended up there. > Yes, I do have a MIB file that was on CD that came with the UPS, attached it to this

Hi I'd like to know what you guys think to the following idea. Please be aware, C/C++ are not exactly my strongpoint (couldn't be much further from it actually..!), so I'm not sure whether this is all legal code. -- SYNOPSIS: Allow a newhidups subdriver to register that it can handle settings in ups.conf (and via -x on the command line), as per the normal serial drivers.

Hi, Nut-upsusers, I am having problem configuring NUT to work with Tripplite UPS through SNMP. There is a Tripplite SmartOnline SU10KRT3/1X and attempts to monitor it using NUT though SNMP are failing... OS: Enterprise Linux 6, Nut version: 2.6.5. ups.conf is configured: [trippliteups] driver = snmp-ups port = 10.200.254.39 desc = "ProductionServer"

2014-02-25 12:58 GMT+01:00 Charles Lepple <clepple at gmail.com>: > On Feb 24, 2014, at 11:48 PM, Jason R Begley wrote: > > > 0.073855 load_mib2nut: trying classic method with 'delta_ups' mib > > 0.073878 Entering nut_snmp_get_str() > > 0.073899 nut_snmp_get((null)) > > 0.073918 nut_snmp_walk((null)) > > Arnaud, > >

Hello ups-dev Arnaud asked me to add a function upsdrv_print_ups_list the drivers upsdrv_print_ups_list : why This function would print the vendorId and the productId of the UPS supported by the driver (for USB driver at least). It could then be parsed by a tool (that I'll have to make too), whose the goal would be to automagically generate 4 sort of file : - fdi file for HAL - udev rules

Hello, I'm working on getting nut using a Powermust Office 650 USB USV. Using today's trunk megatec_usb detects its vendorid 0665 productid 5161 but uses the agiler driver for it which apparently does not work (timeout...). I think this device is using that USB-to-serial chip but a different protocol behind. I got the phoenix subdriver working with the device but I had to extend

Thanks, now I started getting messages from the list. As you advised, I renamed the mib file NETCARD.mib to Tripplite and ran command ./gen-snmp-subdriver.sh -H 10.200.254.39 -c public -n Tripplite Here is what it says: snmp_build: unknown failuresnmpget: Error building ASN.1 representation (Can't build OID for variable) COUNT = 0 / 0 Creating tripplite-mib.h Creating tripplite-mib.c Done.

On Feb 25, 2014, at 4:23 PM, Arnaud Quette wrote: > gen-snmp-subdriver.sh simply hasn't done its job, for some reasons. > well, 1 clear is that's it not a completed effort... at all > but, still IIRC, it should have produced at least a bit more Hi Arnaud, I may not have been specific enough in my description. The crash that Jason saw is with the version of snmp-ups that is

On Wed, Sep 24, 2008 at 2:27 PM, Arjen de Korte <adkorte-guest at alioth.debian.org> wrote: > - /* Server side variables */ > - { "driver.version.internal", ST_FLAG_STRING, sizeof(DRIVER_VERSION), NULL, NULL, DRIVER_VERSION, HU_FLAG_ABSENT, NULL }, > - { "driver.version.data", ST_FLAG_STRING, sizeof(APC_HID_VERSION), NULL, NULL, APC_HID_VERSION,

Thanks to the great help here, I now have a UPS spitting out something resembling a report descriptor. So since I seem destined to have to create a new USB HID subdriver, I figured I'd get started on the path. I followed all of the directions on the web....I used the script to generate the usbhid subdriver, feeding it the output of the usbhid-ups driver from reading my UPS. All that worked

On 2015/03/28 20:02, Charles Lepple wrote: > On Mar 25, 2015, at 9:21 PM, Stuart Henderson <stu at spacehopper.org> wrote: > > > Hi, the diff inline below adds a new subdriver for snmp-ups to support > > Huawei UPS, based on an observed walk from a UPS5000-E with a few bits > > filled in from the MIBs (copy at http://junkpile.org/HUAWEI_UPS_MIB/). > > Sample

...t usb->get_interrupt() instead or alternatively, get_data_agiler(). Hopping back-and-forth between various layers in the code is bad coding style as it makes the code difficult to understand. 2) So what is the benefit of this patch? It seem to try to optimize something away that complicates the subdrivers and really provides no runtime advantages (the ser_open() function is only run once). 3) Something you're probably not responsible for, but if flushing the input buffers is needed, this is something that should be done in main driver body (megatec.c). The driver doesn't flush I/O buffers,...

...e a way to make it list likely drivers back to the user when they are a close match and check validity for each one until it gets a good connection? Part of auto select? What NUT currently does in `usbhid-ups` (some other drivers may handle similar stuff differently), is it goes through a list of subdrivers built into the binary and calls those subdrivers' `claim()` methods to see if they report the device is deemed known to that subdriver. Primarily this goes by USB VendorID:ProductID matching, in some cases also clues like manufacturer string (e.g. "mge" and "phoenixtec/liebert&qu...

> Everything looks fine apart from ups.beeper.status always shows enabled > even if the status bit fom the ups has changed state. Probably because the driver updates the beeper status only every 'pollfreq' (default 30) seconds, so it may have missed the change. > After more testing the indexes work as follows > > 0x0a = load.on / cancel.shutdown.stayoff /

...d after_PSE_9, roughly). * all the vendor-specific code that was in various "switch" statements has now been moved to the individual subdriver (apc-hid, mge-hid, belkin-hid) files. This also includes the vendor-specific Usage tables. In future, it should be quite easy to add new subdrivers: essentially this involves adding two files and one table entry in newhidups.c. I added a document docs/hid-subdrivers.txt that is intended to explain how to make subdrivers. This information is still incomplete, but might be a good start. * I have eliminated all global variables from libu...

...er way to link and use the commands with the matching delays. But it's generally a default behavior of SNMP agent (i.e. first set the delay, then execute the command) Thanks for your contribution, cheers, Arno -- [1] http://www.networkupstools.org/docs/developer-guide.chunked/ar01s04.html#snmp-subdrivers https://github.com/networkupstools/nut/blob/master/scripts/subdriver/gen-snmp-subdriver.sh [2] http://www.networkupstools.org/ups-protocols.html [3] https://github.com/networkupstools/nut/issues/20 [4] https://github.com/networkupstools/nut/blob/master/drivers/powerware-mib.c#L314 -- Eaton Data Ce...

Hi! I've (finally) decided to try and make my PowerWalker work with megatec_usb. So far it seems the agiler subdriver is the way to go, but it doesn't work. The initial detection process sometimes succeeds in 1 out of 5 "Q1" commands, but that's about it (which is better than what the krauler subdriver can do... absolutely nothing). So, what needs to be done to obtain more

On Feb 28, 2014, at 1:05 PM, Tim Dawson wrote: > Git: > > Network UPS Tools - BCMXCP UPS driver 0.28 (2.7.1) > RS-232 communication subdriver 0.20 > > > 2.7.1: > > Network UPS Tools - BCMXCP UPS driver 0.26 (2.6.5-3857M) > RS-232 communication subdriver 0.20 > > > I'm not so much noting the "2.6.5" in the dev, but the 0.28 vs 0.26 bcmxcp

...[Nut-upsdev] Adding drivers to NUT? aehm.. the innards of nutdrv_qx are not exactly well documented (and vars have somewhat confusing names) -- my fault, sorry. This is another thing that has been on my todo list for a while... Briefly, at the moment, in nutdrv_qx, there are actually two kinds of subdrivers: - 'protocols', which are communication-type-agnostic (i.e. they do not fiddle with serial or USB operations, and are not restrained by them), only map the protocol used by the device to the protocol used by NUT, and are implemented in their own files using (and exposing only) the `subdrive...