similar to: New edition of NUT Config Examples is out

Now back to computers - so re-checked some bits. The existing https://networkupstools.org/documentation.html page offers currently the https://github.com/networkupstools/ConfigExamples/releases/latest/ URL as "NUT Configuration Examples <https://github.com/networkupstools/ConfigExamples/releases/latest> book maintained by Roger Price" This in turn redirects to a particular newest

The pieces should all be there, I think. NUT source iterations cooperate with the sister nut-website repo on github, as well as nut-ddl and some more, to produce an horde of static HTML pages, and PDF versions of some docs, tarballs, etc. which are pushed to a repo for "github pages" and with their magic (I guess GH spins up a container with a web server and many data files for each new

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

Thanks for your support, Jim. I found a workaround: logread showed some access-denied errors, and because I don't know exactly what it may be (except the lack of udev rules perhaps), I ran upsd as root and it connected with the UPS. Therefore I wonder whether a more elegant solution could be used for this part? But there are several things about the readings with the 2.7.4 usbhid-ups driver

For clarity, `upsd` is the networked data server for local or remote clients like `upsmon` or `upsc`. It talks to locally running NUT driver(s) which talk to actual devices with their media and protocols. It is the driver (like `usbhid-ups`) that would be annoyed by hardware reconnections. That said, I think there were some fixes to reconnection behavior, which might have landed even after 2.8.0

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

I'm mostly not online for a few more days, so can't check directly. The general answers to the two questions would be: 1) checking if it is there: * revise if it is mentioned in the NEWS file (in sources - release tarball or on github); * check issues on github; * search/grep for 3024 in current/release-tagged codebase... 2) getting it to your system: versioning looks debianish, some

> Previously, the manufacturer tested this UPS on version 2.6.5-6 NUT for Windows. Thanks for this important detail. For immediate re-testing, I would recommend to use either NUT v2.8.0 already packaged by some distributions in their testing/bleeding-edge repositories (unfortunately, during the almost year since release many distros - especially for LTS versions - did not change recipes to

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

A hiccup was reported about validating the tarball signature on some systems, so it was reissued from another workstation. Please don't worry :) Jim Klimov On Tue, Apr 2, 2024, 01:06 Jim Klimov <jimklimov+nut at gmail.com> wrote: > 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

A hiccup was reported about validating the tarball signature on some systems, so it was reissued from another workstation. Please don't worry :) Jim Klimov On Tue, Apr 2, 2024, 01:06 Jim Klimov <jimklimov+nut at gmail.com> wrote: > 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

That It may be right (I don't know), however, where could we confirm whether 3024 is already supported for 2.8.0 or newer? And let's suppose it is. Because current OpenWrt releases are built arround 2.7.4-27, what could I try to backport that (driver mod) to 2.7.4-27? ________________________________ De: Jim Klimov <jimklimov+nut at gmail.com> Enviado: s?bado, 6 de mayo de 2023 4:21

Hello, interesting to hear. What version of NUT, what way of installation on Windows, what sort of UPS (USB or some other)? Asking because this info is lacking and currently there are a few variants to consider: * an MSI package based on NUT v2.6.5 (last released about 9 years ago as "2.6.5-6"), * results of re-integration of that codebase into current NUT master (some months after

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.

Thanks for the response, Roger. On 7/31/2024 12:19 AM, Roger Price wrote: > On Tue, 30 Jul 2024, Harlan Stenn via Nut-upsuser wrote: > >> I've got a client who lives in an area where there are now frequent >> power outages that last for several hours at a time. > > I live in an area with frequent power outages, so I use a nut > configuration [1] which shuts down

On Tue, 13 Jun 2017, Charles Lepple wrote: > On Jun 9, 2017, at 10:16 AM, Roger Price wrote: >> To address this, I propose a "NUT configuration for Noobs" which is >> called "Configuration Examples". > I am also curious whether you tried to edit any of the existing NUT > documentation before creating a new document. We chose AsciiDoc in part >

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