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

So... April 1st came and went, busy with last-minute warnings from a newly set-up NetBSD build agent for the NUT CI farm, as Greg-inspired warnings exposed by the stricter platform kept popping up and biting. Led to some discoveries in toolkits and standards I thought I knew for decades, too. So it was a tad bit annoying, but good overall :) But now we are a day over the hopeful "not more

So... April 1st came and went, busy with last-minute warnings from a newly set-up NetBSD build agent for the NUT CI farm, as Greg-inspired warnings exposed by the stricter platform kept popping up and biting. Led to some discoveries in toolkits and standards I thought I knew for decades, too. So it was a tad bit annoying, but good overall :) But now we are a day over the hopeful "not more

Hello all, It has been too long that I was feeling a release is just around the corner, just gotta tie up a few loose ends. The significant ones we had are finally tied, some others delayed to v2.8.4 trail, and a documentation refresh remains. Thanks to some package maintainers taking a look at the master branch, some issues with "dist" archive creation and parallel builds were also

Hello all, It has been too long that I was feeling a release is just around the corner, just gotta tie up a few loose ends. The significant ones we had are finally tied, some others delayed to v2.8.4 trail, and a documentation refresh remains. Thanks to some package maintainers taking a look at the master branch, some issues with "dist" archive creation and parallel builds were also

So, NUT v2.8.3-rc1 is out. I first thought it was the release, but some CI runs convinced me otherwise, so there would be a bit of back and forth on the master branch as some recipes get fixed. Apparently, some parallel runs stepped onto each other's toes sometimes, but coinciding the wrong way just once in a few hundred builds. Hopefully I found why and will re-publish in a few hours. Jim

So, NUT v2.8.3-rc1 is out. I first thought it was the release, but some CI runs convinced me otherwise, so there would be a bit of back and forth on the master branch as some recipes get fixed. Apparently, some parallel runs stepped onto each other's toes sometimes, but coinciding the wrong way just once in a few hundred builds. Hopefully I found why and will re-publish in a few hours. Jim

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