similar to: New wiki article to help testing of bug-fixes and improvements

Cheers all, Per https://github.com/networkupstools/nut/pull/2480 there seems to have been a byte-order bug in usbhid-ups subdriver for Powercom that precluded it from shutdowns. I am not fully certain if the problem (or the fix) are endianness-dependent, so would welcome testing of that PR from various platforms (x86, arm, ...) As usual, I hope

Cheers all, Per https://github.com/networkupstools/nut/pull/2480 there seems to have been a byte-order bug in usbhid-ups subdriver for Powercom that precluded it from shutdowns. I am not fully certain if the problem (or the fix) are endianness-dependent, so would welcome testing of that PR from various platforms (x86, arm, ...) As usual, I hope

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

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.

Hello all, During discussion for development of a new driver, an old thought came to my attention that we have a potentially insecure approach with some parts of the codebase working with string and "var arg list" manipulation, which use dynamic `char *` variables instead of fixed strings (or macros that expand to those). There are typically good reasons in code to do so, such as

Hello all, During discussion for development of a new driver, an old thought came to my attention that we have a potentially insecure approach with some parts of the codebase working with string and "var arg list" manipulation, which use dynamic `char *` variables instead of fixed strings (or macros that expand to those). There are typically good reasons in code to do so, such as

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

Hello and welcome! Just recently there was a trip down the memory lane with another device with Richcomm-based hardware, and ultimately nutdrv_qx driver happened to support that one: https://github.com/networkupstools/nut/issues/2395 Some key take-aways were: * try starting the driver with bumped debug verbosity (e.g. from command line, or using a `debug_min` setting with NUT v2.8.0 and

Hello all, as users of certain (primarily CyberPower and APC) devices know, some firmwares report both "online" and "discharging" in some situations. These depend on the device, vendor and firmware, but cases seen in practice include: * calibration (APC), * being on-battery (CPS), * having got charged to 100% (APC) Recent attention to this area culminated in PR

Cheers all, With PR https://github.com/networkupstools/nut/pull/2686 I hope to allow one to configure (a generally comma-separated list of) sdcommands option with arbitrary INSTCMD values supported by the device-specific part of driver code (if any). In testing e.g. beeper commands can be used instead of powering off the load. It also aliases the call to upsdrv_shutdown() as a shutdown.default

Cheers all, With PR https://github.com/networkupstools/nut/pull/2686 I hope to allow one to configure (a generally comma-separated list of) sdcommands option with arbitrary INSTCMD values supported by the device-specific part of driver code (if any). In testing e.g. beeper commands can be used instead of powering off the load. It also aliases the call to upsdrv_shutdown() as a shutdown.default

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) <

Hello, Just wanted to clarify: what sort of issues did you have with the APC? Since last year there have been several posts such as https://github.com/networkupstools/nut/issues/2347 about BX****MI (3-4 digits for wattage) series built (or flashed with firmware?) roughly in 2023-2024 as frequently reporting low-battery/replace-battery/all-good events in a short timeframe, both with NUT and

It seems the `libmodbus` library or headers were not found, or something similar - so the driver against it was not built. Did you install `libmodbus-dev` before the build? What does `config.log` in the build root say (and.or the summary shown after you run the `configure` script)? On Sat, Sep 16, 2023 at 7:46?PM FatGear <fatgear1 at free.fr> wrote: > Hi, > > I don't know what

Thanks for the info! First, regarding the later detail about starting `usbhid-ups`: the "Resource busy" indicates that likely an earlier instance of the NUT driver (in its own service unit) is still running and holding the device. In a worse case, some other programs might consider this a HID device (same class family as keyboards and mice) and grab it somehow, or it gets passed through

Hello there, I don't think that's working,? I have done all your repo but i don't know how it's supposed to work. I have a idea, change vendor id and product id? to make the driver try to connect to the ups, what do you think of that ? With this driver maybe : usbhid-ups FatGear Le 16/09/2023 ? 20:40, Jim Klimov a ?crit?: > It seems the `libmodbus` library or headers were

Hi, ?Thank you for your prompt response! The problem I had with my BX950MI unit was that it was frequently reporting off-line, on batt and often not responding to requests from apcupsd (apcaccess) and then going back online again. However, the warranty replacement was prompted by a failed battery, apparently leaking acid, after around ten months use.? As a matter of interest, I had a

<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

Well, now that the `subdriver` option got added to `usbhid-ups` too, you can at least try that (by building again the current master). See command-line help for the subdrivers it would currently recognize, and copy e.g. the first word as the matching option, e.g.: ./drivers/usbhid-ups -DDDDDD -d1 -s test -x port=auto -x vendorid=... -x productid=... -x subdriver=... and try to lockpick your