similar to: Harden NUT work with strings where dynamic formatting strings are used

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

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

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

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

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.

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

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 all, I've long felt that I am reciting tips about building from git source a bit too often in the issue discussions over the past couple of years, and automated some of that area during the time to make it simple to type, so finally posted a Wiki article that I hope to refer to in such situations from now on. Perhaps it would be useful not only to "newcomers":

Hello all, I've long felt that I am reciting tips about building from git source a bit too often in the issue discussions over the past couple of years, and automated some of that area during the time to make it simple to type, so finally posted a Wiki article that I hope to refer to in such situations from now on. Perhaps it would be useful not only to "newcomers":

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