similar to: Heads-up: ./configure --with-unmapped-data-points

Hello all, I think I've found the "regression" in Belkin/Liebert USB HID support which worked for NUT v2.7.4 and reports zero voltages in 2.8.0 -- it was actually caused by a bug fix: practically the only functional difference per `git diff v2.7.4..v2.8.0 drivers/belkin-hid.c` is a change from `abs()` to `fabs()` in order-of-magnitude comparisons like `if( abs(value - 1e-7) <

Hello all, I think I've found the "regression" in Belkin/Liebert USB HID support which worked for NUT v2.7.4 and reports zero voltages in 2.8.0 -- it was actually caused by a bug fix: practically the only functional difference per `git diff v2.7.4..v2.8.0 drivers/belkin-hid.c` is a change from `abs()` to `fabs()` in order-of-magnitude comparisons like `if( abs(value - 1e-7) <

oh! Ok, I'll go look at all the HID objects reported by the sample code @abratchik has on top-of-tree of his repo and see what makes sense to add to NUT. PR coming this week. On Sun, Nov 12, 2023 at 2:38?PM Jim Klimov <jimklimov+nut at gmail.com> wrote: > Well, the intention generally is to use it as a driver, so the more > abilities the merrier (PR would be welcome) :) >

Making progress on this PR. I have question about storing and checking state in a subdriver HID Power Devices can a "UPS.PowerSummary.CapacityMode" value. According to the spec, the values are: 0: maH 1: mwH 2: percent (%) 3: Boolean support only (OK or failed) Grep'ing the source, nothing makes use of this now (some subdrivers have it mapped to

Hello Jim, That?s a great help for me. You?re a so kind person ~ Our engineer download the branches f17d9f5 as below and repackage it for test. After testing, The Beta NUT works well with ST VID "0x0483", PID "0xA430. Please tell me how to speed up for merging this to formal version. May I have your predict schedule if possible? Thanks.

For clarity, `upsd` is the networked data server for local or remote clients like `upsmon` or `upsc`. It talks to locally running NUT driver(s) which talk to actual devices with their media and protocols. It is the driver (like `usbhid-ups`) that would be annoyed by hardware reconnections. That said, I think there were some fixes to reconnection behavior, which might have landed even after 2.8.0

Thanks for your support, Jim. I found a workaround: logread showed some access-denied errors, and because I don't know exactly what it may be (except the lack of udev rules perhaps), I ran upsd as root and it connected with the UPS. Therefore I wonder whether a more elegant solution could be used for this part? But there are several things about the readings with the 2.7.4 usbhid-ups driver

Hello, and thanks for the clarifications. As described, the change does not seem to be too complex on the NUT project's side, the PR posted below took about an hour with some research and this write-up, so I'm not sure I can put a price tag on it :) A donation at https://opencollective.com/networkupstools or https://github.com/sponsors/networkupstools would be welcome though, more so a

Thanks again. So one more bit (other than indeed different libusb versions) that could potentially come into play is bitness - armv7l builds are 32-bit, right? One idea from here is to have you run the driver programs directly with high debug verbosity, e.g. `usbhid-ups -DDDDDD -s Liebert` to compare the two walls of text (at some debug level it spews byte data seen from libusb); this might

Well thanks, The solution for my problem was kinda easy (still need some testing though): found out my ups status is a string, so then I changed the way snmp-ups.c gets the status. Had to change *nut_snmp_get_int *to *nut_snmp_get_str *at around line 3470, then grab fourth char out, use *strtol *function to then send it to *su_status_set *function. I created my copy of *apc-mib.c *with my OID at

Hi, > Since NUT is guessing, is there 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

I'm mostly not online for a few more days, so can't check directly. The general answers to the two questions would be: 1) checking if it is there: * revise if it is mentioned in the NEWS file (in sources - release tarball or on github); * check issues on github; * search/grep for 3024 in current/release-tagged codebase... 2) getting it to your system: versioning looks debianish, some

Well, the intention generally is to use it as a driver, so the more abilities the merrier (PR would be welcome) :) Per comments to initial PR that added it, https://github.com/networkupstools/nut/pull/1044 : > The idea of introducing this driver is to enable creation and prototyping of smart UPS based on Arduino, which is inexpensive versatile platform very much suitable for custom fully

<facepalm ;)> the ellispis "something=..." were supposed to be replaced by your device ID numbers, etc. On Sat, Sep 23, 2023, 18:26 FatGear <fatgear1 at free.fr> wrote: > Hello There, > > I tried your advice and i don't think it works either, > > See the logs, > > " > > /tmp/nut# ./drivers/usbhid-ups -DDDDDD -d1 -s test -x port=auto -x

One good intro to this is https://github.com/networkupstools/nut/blob/master/docs/snmp-subdrivers.txt although it focuses on adding new subdrivers - but more or less the same workflow applies to extending existing ones. Sometimes it helps to generate a new one for a currently-partially-supported device, and then compare with existing subdriver (using meld or similar GUI helps a lot) to port the

Thanks for the quick reply! Ya, I'm new to all this so I didn't know this either, I was vaguely aware of USB composite devices from other projects, but never how it was all enumerated. I dug a bit more on this and I'm convinced the relationship is this: Device ??? Configuration 1 ??? Interface 1 ? ??? Endpoint 1 ? ??? Endpoint 2 ? ??? ... ??? Interface 2

@jimklimov: Looking at the code that uses hid_rep_index, hid_desc_index, and hid_ep_in|out in usb_subdriver (all in nut_libusb.h) I don't see any use of the addvars mechanism. If I follow the examples that set and use those struct members, it looks like everything relies on them being initialized to 0 by default, then only set in subdrivers or situations that need something different. If I

That It may be right (I don't know), however, where could we confirm whether 3024 is already supported for 2.8.0 or newer? And let's suppose it is. Because current OpenWrt releases are built arround 2.7.4-27, what could I try to backport that (driver mod) to 2.7.4-27? ________________________________ De: Jim Klimov <jimklimov+nut at gmail.com> Enviado: s?bado, 6 de mayo de 2023 4:21

Hello There, I tried your advice and i don't think it works either, See the logs, " /tmp/nut# ./drivers/usbhid-ups -DDDDDD -d1 -s test -x port=auto -x vendorid=... -x productid=... -x subdriver=... Network UPS Tools - Generic HID driver 0.52 (2.8.0-2557-g81fca30b2) USB communication driver (libusb 1.0) 0.46 ?? 0.000000??? [D3] main_arg: var='port' val='auto' ??

Hi Jim, I?m using on Kali Linux. I?m not using a custom version and finally found the issue which was a hidden character staying in the ups.conf file. I rebuilt the file and everything worked out. Issue closed and many thanks for your help. Laurent From: Jim Klimov <jimklimov+nut at gmail.com> Sent: mercredi 29 mars 2023 13:22 To: laurenttaieb at free.fr Cc: nut-upsuser