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.

I believe the integration is presented as a container on the HA server, so there should be a way to log into it and edit `/etc/nut/ups.conf` or similar during the experiments (generated from YAML settings made in HA GUI somewhere). I have not used it directly, so I can't really help more here. Jim On Wed, Sep 25, 2024 at 5:47?PM Daniele Lamaddalena <dlamaddalena at gmail.com> wrote:

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

The trip to FOSDEM 2025 was great fun, with many interactions, useful lectures and fruitful conversations. It was insightful to randomly meet at least one person using the project, a few eager to use and asking question, and sadly quite a few who did not recognize not only "NUT" but also "UPS" key words. Face-to-face talks to maintainers of Debian, OpenIndiana, Tribblix and

The trip to FOSDEM 2025 was great fun, with many interactions, useful lectures and fruitful conversations. It was insightful to randomly meet at least one person using the project, a few eager to use and asking question, and sadly quite a few who did not recognize not only "NUT" but also "UPS" key words. Face-to-face talks to maintainers of Debian, OpenIndiana, Tribblix and

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

Hi Jim: After doing comprehensive tests, we have confirmed that there are no problems with the source code update related to temperature this time. We kindly request you to update the source code concerning temperature in cps-hid.c (driver: USBHID-UPS(8)) and include it in the next official release of NUT. Additionally, please inform us of the planned timeline and version for the upcoming

Hello, Not really sure. Have not heard about such a brand/model on one hand, and the Home Assistant NUT plugin may be (or not be) limiting the selection of data points it shows from NUT on the other. Can you query the readings with NUT `upsc` client? Also, `nutdrv_qx` is an umbrella driver for many different dialects of "Megatec Q<x>" protocol family. Check the

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, Is anyone planning to be at FOSDEM this year? I'll be in Brussels from Thursday evening to Sunday evening. My Friday is pretty tightly scheduled, but I would love to meet any of you in person during the weekend (or on a Thursday supper) :) Jim Klimov -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hello all, Is anyone planning to be at FOSDEM this year? I'll be in Brussels from Thursday evening to Sunday evening. My Friday is pretty tightly scheduled, but I would love to meet any of you in person during the weekend (or on a Thursday supper) :) Jim Klimov -------------- next part -------------- An HTML attachment was scrubbed... URL:

Regarding the follow-up, IIRC `open` walks a device list returned by libusb, checks each entry against the matcher, and tells libusb if it wants to claim the device described by a particular entry. I don't think it walks further entries after a successful match and claim? We can't use the matcher directly, because its fields can be a regex geberally (e.g. `vendor=A*` instead of `APC` or

Looks good. Posted the PR as https://github.com/networkupstools/nut/pull/2711, code base to test would be available at https://github.com/jimklimov/nut/tree/cps-hid-temp currently or as part of https://github.com/networkupstools/nut/tree/master after the pull request passes our CI and gets merged. Thanks, Jim Klimov On Wed, Dec 4, 2024 at 9:11?AM Yvonne.Chen <Yvonne.Chen at

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