similar to: Happy New Year

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

FYI: PR https://github.com/networkupstools/nut/pull/1328 adds handling of `PRIMARY` alias to `MASTER` on protocol side, hopefully completing the puzzle for issue #840. Reviews and testing would be welcome :) On Sun, Mar 14, 2021, 00:34 Jim Klimov <jimklimov+nut at gmail.com> wrote: > Thanks again for all the suggestions. > > For now I've prepared draft PRs, mostly to map out

FYI: PR https://github.com/networkupstools/nut/pull/1328 adds handling of `PRIMARY` alias to `MASTER` on protocol side, hopefully completing the puzzle for issue #840. Reviews and testing would be welcome :) On Sun, Mar 14, 2021, 00:34 Jim Klimov <jimklimov+nut at gmail.com> wrote: > Thanks again for all the suggestions. > > For now I've prepared draft PRs, mostly to map out

Hello, fellow NUTs! This October proved to be a rather productive month, with several developments wrapped up, as well as some issues with master codebase behavior created, reported, fixed and tested :) While we were not part of some official Hacktoberfest this year, it pretty much felt like one - great thanks to everyone involved! The month is also ending soon, so if we're to follow

Hello, fellow NUTs! This October proved to be a rather productive month, with several developments wrapped up, as well as some issues with master codebase behavior created, reported, fixed and tested :) While we were not part of some official Hacktoberfest this year, it pretty much felt like one - great thanks to everyone involved! The month is also ending soon, so if we're to follow

Hello all, Given that some UPSes and other devices manageable by NUT may have several means of connectivity simultaneously, such as USB/Serial and SNMP, it may be useful to utilize several connection methods to the same UPS. Moreover, a couple of master servers with connection to the engineering VLAN (where an SNMP UPS is present) might provide equivalent "access" to the UPS data

Hi, Great work Jim! I?m glad you could reproduce the problem and found a potential culprit. Just for my own interest I restored upsshed from my backups (version 2.7.4-13) and it seems to running ok, so no big runtime changes regarding that with Debian 12. It is not hogging CPU. From the daemon log the heartbeat seems to be working ok. Only difference between the old logs (pre Debian 12 update)

Hi, Great work Jim! I?m glad you could reproduce the problem and found a potential culprit. Just for my own interest I restored upsshed from my backups (version 2.7.4-13) and it seems to running ok, so no big runtime changes regarding that with Debian 12. It is not hogging CPU. From the daemon log the heartbeat seems to be working ok. Only difference between the old logs (pre Debian 12 update)

Errata coming up for NUT v2.8.2: * it was discovered that the nut-driver-enumerator (NDE) script had a regression which caused it to not reload nut-driver instances (systemd, SMF) when `ups.conf` edits happened. * on a related note, it may be possible that "live" driver reloading (at least on master branch) does not reduce debug verbosity to zero when `debug_min 0` is active in its

Errata coming up for NUT v2.8.2: * it was discovered that the nut-driver-enumerator (NDE) script had a regression which caused it to not reload nut-driver instances (systemd, SMF) when `ups.conf` edits happened. * on a related note, it may be possible that "live" driver reloading (at least on master branch) does not reduce debug verbosity to zero when `debug_min 0` is active in its

After launching the command several times, with debug (posted by new code in a new branch for the investigation) confirming that the same daemon handles operations from the new client instances, its strace now has numerous FDs to report after select() - so I guess it is a problem of detecting an exit of the counterpart. 0.000000 [D2] parse_at: is 'heartbeat at localhost' in AT

After launching the command several times, with debug (posted by new code in a new branch for the investigation) confirming that the same daemon handles operations from the new client instances, its strace now has numerous FDs to report after select() - so I guess it is a problem of detecting an exit of the counterpart. 0.000000 [D2] parse_at: is 'heartbeat at localhost' in AT

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

Cheers all, I would like to take a moment to wish everyone a happier New Year than the few we've seen before, and hope for peace, quiet and joy for everyone. We have had some good collaborations here, with new people and old guard being engaged, more platforms confirmed and upkept by NUT CI farm, sponsorship becoming a thing, and a new release getting cut - we're back on track of

Cheers all, I would like to take a moment to wish everyone a happier New Year than the few we've seen before, and hope for peace, quiet and joy for everyone. We have had some good collaborations here, with new people and old guard being engaged, more platforms confirmed and upkept by NUT CI farm, sponsorship becoming a thing, and a new release getting cut - we're back on track of

Hello all, After a prolonged labour with a few re-issues of the tag and many pushes during the day, NUT v2.8.2 was found in a strange egg by a bunny hopping away from the April fools. All that - blessed under the shine of Polar lights in the middle of the icy North Ocean. A python module was released but slipped away with an earlier commit. Other artifacts should follow shortly. Jim Klimov

Hello all, After a prolonged labour with a few re-issues of the tag and many pushes during the day, NUT v2.8.2 was found in a strange egg by a bunny hopping away from the April fools. All that - blessed under the shine of Polar lights in the middle of the icy North Ocean. A python module was released but slipped away with an earlier commit. Other artifacts should follow shortly. Jim Klimov

Jim Klimov <jimklimov+nut at gmail.com> writes: > By the way, on the NUT CI farm the libwrap is present on some (though not > all) systems - covering linux, freebsd, openindiana... and neither > complained about `sockdebug` :\ > > What version do you have? Maybe it is some alternate implementation? Looks like 7.4, as amended in NetBSD over the years. Looks like the

Yes I do have Linux. I have assigned the ups.conf file as seen below.. [testups] Driver = usbhid-ups Port = /dev/ttyUSB0 When I try to start the ups driver I get the following error... $ sudo upsdrvctl start Network Ups Tools - UPS driver controller 2.7.1 Network Ups Tools - Generic HID driver 0.38 (2.7.1) USB communication driver 0.32 No matching HID UPS found Driver failed to start (exit