Re: [Nut-upsuser] Eco Eclipse 1600 connects via USB put does not put out any data:

[Jim Klimov via Nut-upsuser]

Did you check also that `upsc` client does not report anything about the
device?

The message indicates that some other process has a hold on the USB devfs
node, and those can typically be either other copies of a NUT driver,
rarely some other programs that see and grab HID devices, or in case of
virtualization and pass-through - the device being busy in the guest or
host system (other than the one NUT runs in, so harder to debug or notice
specific symptoms).

With NUT v2.8.0 and newer on a Linux (or illumos) system I'd guess the
`nut-driver-enumerator` service integration has spawned a `nut-driver@Eaton`
instance and that is what is holding the device. A systemd unit may have
been started without a PID file, so the copy started from command line does
not see that one to kill off (as NUT drivers usually do since the dawn of
time, assuming a frozen older copy).

More details here:
https://github.com/networkupstools/nut/wiki/nut%E2%80%90driver%E2%80%90enumerator-(NDE)

Newer NUT versions should be more informative in the log about such
situations, as well as capable of communicating with the older copy (if it
is not frozen) over Unix sockets "intelligently" instead of sending
bare-bone signals to reload or exit with no feedback.

Jim




On Fri, Jul 5, 2024 at 1:16 PM Stefan Schumacher via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:

> Hello
>
> Initial Disclaimer: I used this tutorial. I know its in german but the
> entries to be made in the configuration files are marked and should be
> able to identify if there are any errors.
>
> https://techbotch.org/blog/ups-setup/index.html
>
> After several power failures and damaged fuses I decided to give Eaton
> & Nut another try. Eaton because the model I bought seems to be the
> one on the market which has the most power without a permanent fan.
> Unfortunately I don't even get as far as the last time. Lets begin
> with the basic info:
>
> I am using: Debian Bookworm 12.6 with these packages, which were
> installed from the official Debian Repository.
> ii  nut 2.8.0-7
>   all  network UPS tools - metapackage
> ii  nut-client  2.8.0-7
>   amd64network UPS tools - clients
> ii  nut-server  2.8.0-7
>   amd64network UPS tools - core system
>
> My device is a: https://www.eaton.com/de/de-de/skuPage.EL1600USBDIN.html
>
> There is a connection between the USV and the server it protects.
> lsusb = Bus 001 Device 002: ID 0463: MGE UPS Systems UPS
>
> What follows is the output of the driver. As you can see I am running
> it as root. What are the next steps I should take?
>
> Thanks in advance
> Stefan Malte
>
> root@mars:/usr/lib/nut# ./usbhid-ups -DD -a Eaton
> Network UPS Tools - Generic HID driver 0.47 (2.8.0)
> USB communication driver (libusb 1.0) 0.43
>0.00 [D1] debug level is '2'
>0.001566 [D2] Initializing an USB-connected UPS with library
> libusb-1.0.26 (API: 0x1000109) (NUT subdriver name='USB communication
> driver (libusb 1.0)' >
>0.001575 [D1] upsdrv_initups (non-SHUT)...
>0.004892 [D2] Checking device 1 of 7 (1D6B/0003)
>0.004908 [D1] Failed to open device (1D6B/0003), skipping:
> Access denied (insufficient permissions)
>0.004911 [D2] Checking device 2 of 7 (0BDA/5452)
>0.004917 [D1] Failed to open device (0BDA/5452), skipping:
> Access denied (insufficient permissions)
>0.004921 [D2] Checking device 3 of 7 (1D6B/0002)
>0.004926 [D1] Failed to open device (1D6B/0002), skipping:
> Access denied (insufficient permissions)
>0.004929 [D2] Checking device 4 of 7 (1D6B/0003)
>0.004937 [D1] Failed to open device (1D6B/0003), skipping:
> Access denied (insufficient permissions)
>0.004941 [D2] Checking device 5 of 7 (0463/)
>0.463157 [D2] - VendorID: 0463
>0.463198 [D2] - ProductID: 
>0.463215 [D2] - Manufacturer: EATON
>0.463231 [D2] - Product: Ellipse ECO
>0.463249 [D2] - Serial Number: 0
>0.463268 [D2] - Bus: 001
>0.463287 [D2] - Device: unknown
>0.463314 [D2] - Device release number: 0100
>0.463332 [D2] Trying to match device
>0.463350 [D2] match_function_subdriver (non-SHUT mode):
> matching a device...
>0.463603 [D2] Device matches
>0.463624 [D2] Reading first configuration descriptor
>0.463662 [D2] failed to claim USB device: Resource busy
>0.463689 [D2] Kernel driver already detached
>0.463714 [D2] failed to claim USB device: Resource busy
>0.463740 [D2] Kernel driver already detached
>0.463764 [D2] failed to claim USB device: Resource busy
>0.463787 [D2] Kernel driver already detached
>0.463809 [D2] failed to claim USB device: Resource busy
>0.463831 [D2] Kernel driver already detached
>0.463854 Can't claim USB device [0463:]@0/0: Entity not found
>
> 

Re: [Nut-upsuser] Powercom BNT USB fix needs testing

[Jim Klimov via Nut-upsuser]

Gentle bump :)

If there's anyone with a Powercom USB UPS and preferably a non-x86 computer
to build and test a NUT driver on (to confirm the original problem and the
fix), that would be very helpful :)

Jim


On Sun, Jun 16, 2024 at 12:26 PM Jim Klimov  wrote:

> 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
> https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests
> can get you started.
>
> Thanks in advance,
> Jim Klimov
>
>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

[Nut-upsuser] Any ideas what protocol GE VH3000 UPS might talk?

[Jim Klimov via Nut-upsuser]

Got a community question at
https://github.com/networkupstools/nut/issues/2466 with at least two users
(and UPSes) in trouble.

Curiously, they identify as 067b:2303 Prolific Technology like a common
USB-Serial dongle brand. Experiments with blazer and nutdrv-qx got no
reasonable response from the devices.

Jim
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

[Nut-upsuser] Powercom BNT USB fix needs testing

[Jim Klimov via Nut-upsuser]

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
https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests
can get you started.

Thanks in advance,
Jim Klimov
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Permissions error

[Jim Klimov via Nut-upsuser]

Normally you should elevate to run e.g. `sudo upsdrvctl ...` so the NUT
driver program initializes as `root` and drops privileges to `nut`
(tweakable as the `user=...` in ups.conf, like your RUN_AS_USER in
upsmon.conf) soon after that, and default permissions on packaged files
expect that. Alternately you can run a driver's service as that user
account right away, probably, but this is not common.

Jim

On Tue, Jun 11, 2024, 01:35 Jack McGee  wrote:

> https://youtu.be/vyBP7wpN72c?si=SQFhJQ7bhUAUNCIW
>
> I watched a youtube video to get this installed.
>
> I have standalone nut installation on Ubuntu 22.04.  UPS is a
> CP1500PFCLCD.  I have gotten as far as eliminating the no connection
> error that I was being broadcast.  I have the web view viewable at
> http://192.168.1.105/cgi-bin/nut/upsstats.cgi
>
>
> The problem I have I believe is permissions.
>
> mythuser@amethi:~$ upsdrvctl start
> Network UPS Tools - UPS driver controller 2.7.4
> Can't open /etc/nut/ups.conf: Can't open /etc/nut/ups.conf: Permission
> denied
>
> I ran
>
> chown root:nut upsmon.conf
>
> chmod 0640 /etc/nut/upsmon.conf
>
> mythuser@amethi:~$ sudo cat /etc/nut/upsd.users
> [monuser]
>password = 
>admin master
>
> mythuser@amethi:~$ sudo cat /etc/nut/upsmon.conf
> RUN_AS_USER root
> MONITOR cyberpowerAmethi@localhost 1 admin secret master
>   DEADTIME 25
> SHUTDOWNCMD "/sbin/shutdown -h +0"
>
>
> ___
> Nut-upsuser mailing list
> Nut-upsuser@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

[Nut-upsuser] Harden NUT work with strings where dynamic formatting strings are used

[Jim Klimov via Nut-upsuser]

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 to generalize
the use of mapping tables, or carefully construct formatting strings from
pieces during run-time, but warnings from static analysis in compilers also
has a point that a mistake here would cause the code to reference wrong
areas of memory/stack or interpret the owned addresses as wrong data types.
Currently those warnings were hushed by use of pre-processor pragmas, but
this only hides the possible errors under the rug.

  The issue was formally posted as
https://github.com/networkupstools/nut/issues/2450 and a PR to fix it was
proposed at https://github.com/networkupstools/nut/pull/2460

  The general idea for the fix (in several added methods for our different
use-cases) is to provide a fixed constant "reference" formatting string,
which just lists the data types in order of printf-style method's variable
list of arguments - this is a sequence that humans and compilers can well
analyze by looking at code (e.g. static analysis during compilation), like
they do for "normal" string operations. The "dynamic" formatting string
(variable) is another argument to those methods, which we compare at
run-time to the "reference" string and decide if they are equivalent as far
as memory safety is concerned (i.e. that they would treat bytes on stack as
signed or unsigned integers or doubles of specified width, or as strings or
pointers).

  The NUT CI farm formally agrees with this code across many platforms and
toolkits, but before merging this fix, I would rather have different people
using their drivers and hardware build the branch and test the modified
code -- to make sure that existing mappings still work and are not rejected
by run-time checks due to a mismatch of e.g. `long int` variable and a `%d`
conversion character in some applicable mappings and `%ld` in others.

  The changes are not only in drivers, but also in many of the "clients"
and a bit in nut-scanner. Discrepancies would be currently exposed when
debug verbosity level is "1" or more.

  As usual,
https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests
can be a good start to get your custom copy of NUT built (with `git clone
https://github.com/jimklimov/nut -b issue-2450 nut-issue-2450; cd
nut-issue-2450 ; ...` to those instructions).

Thanks in advance,
Jim Klimov
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] UPS not Shutting Down

[Jim Klimov via Nut-upsuser]

Thinking of it, one purpose of upssched is to delay reaction to short-lived
flukes (e.g. if we go on battery for 20 seconds and set a delay for 30, if
we're back on line within that time frame, it is ok to go on living).

I wonder if your UPS went under 70% and you aborted the experiment too
early (compared to the delay you had set, possibly with a margin for the
frequency of UPS polling rate and regular `upsmon` interactions with `upsd`
- typically 5 to 30 sec each)?..

Jim


On Sat, Jun 1, 2024 at 1:32 PM Alan via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:

> Hi,
>
> A while back I set up a NUT server on a debian machine (Proxmox).  I
> followed the guide at https://wiki.debian.org/Exim4Gmail so that I would
> receive email notifications and verified that emails work.
>
> I modified .*/etc/nut/upssched-cmd* and modified the script to send an
> email (happy to share).
>
> I then wanted to test the solution so I unplugged the UPS.
> NUT wrote a message to the console and I received an email to inform me
> that the UPS was on battery.
>
> I had configured the battery.charge.low: 70 and battery.runtime.low: 2500.
> My thought was when one of these conditions are met the server would bring
> down the guests and shut itself down. The UPS battery.charge went under 70
> but nothing happened.  Below is the output from upsc and what happened when
> I plugged the power back into the ups.
>
> upsc pve1@localhost
> Init SSL without certificate database
> battery.charge: 63
> battery.charge.low: 70
> battery.runtime: 3133
> battery.runtime.low: 2500
> battery.type: PbAc
> battery.voltage: 36.80
> battery.voltage.nominal: 36.00
> device.mfr: PHOENIXTEC
> device.model: Innova Unity
> device.serial: CPANM2436540037
> device.type: ups
> driver.name: usbhid-ups
> driver.parameter.pollfreq: 30
> driver.parameter.pollinterval: 2
> driver.parameter.port: auto
> driver.parameter.productid: 
> driver.parameter.serial: CPANM2436540037
> driver.parameter.synchronous: auto
> driver.parameter.vendorid: 06DA
> driver.version: 2.8.0
> driver.version.data: Phoenixtec/Liebert HID 0.41
> driver.version.internal: 0.47
> driver.version.usb: libusb-1.0.26 (API: 0x1000109)
> output.frequency: 50.00
> output.voltage: 229.6
> ups.delay.shutdown: 300
> ups.load: 13
> ups.mfr: PHOENIXTEC
> ups.model: Innova Unity
> ups.productid: 
> ups.serial: CPANM2436540037
> ups.status: OB DISCHRG
> ups.vendorid: 06da
>
> *<< UPS plugged back in >>*
>
> Broadcast message from root@proxmox-01 (somewhere) (Sat Jun  1 12:36:17
> 2024):
>
>
> UPS pve1@localhost on line power
>
> How can I diagnose / resolve this?
>
> Thanks
> Alan
>
>
> ___
> Nut-upsuser mailing list
> Nut-upsuser@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Supporting a DIY UPS with minimal effort but maximum gain

[Jim Klimov via Nut-upsuser]

Hello, and welcome (again) :)

> ...That [driver] executable will talk to the hardware in whatever way it
sees fit, and to nut over the UNIX socket/pipe. It does sound
architecturally feasible, at least, no?

This is more or less what NUT drivers themselves do, so yes - quite
feasible. Architecturally, NUT drivers, data server (upsd) and various
clients are separated for this reason of flexibility and whatnot (they can
die and be recycled independently, developed incompatibly, block on I/O
without impacting others, etc.). There were discussions about maybe making
some umbrella driver core program so the actual drivers would be threads in
it, but it is not likely to happen - especially for drivers of unrelated
hardware. Many threads of, say, `snmp-ups` monitoring different devices?
Maybe it makes sense, maybe not.

Arnaud Quette also proposed a "SmartNUT" project geared towards IoT
use-cases, and based on experience with a HAL back-end that was scrapped
around NUT 2.6.5 as GNOME3 deprecated HAL (note that GNOME2 clones like
MATE are still popular, so there may be value in reviving it too). Such
solutions can use a different communications backend than an Unix socket
talking to `upsd` - e.g. to have NUT drivers present an UPS directly as a
battery device on an OS bus. For some use-cases this can save some bytes in
storage and RAM footprint, and CPU cycles to pass bytes around within a
single device, especially of interest in embedded cases where resource
constraints still matter a lot.

I know some further projects based on NUT also have their own drivers so
sometimes there's a bit of constructive friction to get them ported to new
capabilities of NUT (and to keep the Unix and networked protocols and
library APIs as stable as feasible, or changes well announced and
documented). Probably one major difference, potentially, is that NUT
drivers share a large part of codebase with `common/*` code and a
`drivers/main.c` file, so they have same facilities to parse
configurations, use a data state model and announce it to the data server
(over Unix protocol), same ways of enabling debugging and whatnot.

The "third-party" drivers that I knew of were closer to what you proposed
as a "script or something", in that they did talk the NUT local socket/pipe
protocol to `upsd`, but did not use any NUT codebase. Not sure why; best
guess could be maybe to be licensed independently (perhaps using further
proprietary or differently licensed code that they can not risk linking
with GPL), or maybe to require less maintenance as the NUT codebase changes
and they would have to refactor and recompile regularly to stay on top of
things.

On the performance side, remember that things like opening/closing file
descriptors or spawning processes can be quite costly on some platforms
(many security checks involved), so you'd want to avoid e.g. shell
scripting running in a tight loop to monitor the devices, lest the driver
become a primary load for the (smallish) computer, and prefer some compiled
or pre-interpreted language (perl/python included). For a relaxed loop or
for prototyping even that shell may be okay - at least, often is easier to
tinker in the field, to an extent.

As a NUT maintainer, I guess such external drivers make sense for users who
roll their own devices and are also their consumer base (whether
individuals or corporations). If however this is something worth sharing,
maybe as a new "reference" driver (or small addition to some existing
driver like the arduino-hid subdriver) for a nifty project using your new
and also published micro-controller like here for the DIY-UPS cases, it
makes sense to upstream that driver into NUT and let it evolve and be
maintained independently of yourself. I've had tons of PRs to other
projects with the primary reasons being to share, to take the maintenance
burden off myself (and avoid regular re-merge and rebuild to have both
feature sets in my deployments), and of course to have my contributions
reviewed and stupid (or un-trivially hidden) mistakes weeded out :)

Hope this helps,
Jim Klimov



On Sun, May 19, 2024 at 8:06 PM Kiril Zyapkov 
wrote:

> Hello all,
>
> Now that I am subscribed to the list I can reply at last :)
>
> Kelly, thank you for the comprehensive write-up and pointers to sources
> and the Arduino lib and example. This took me into a rabbit hole and I've
> spent entirely too many hours browsing through the NUT sources and
> USB/HID/PowerDevice specs.
>
> Jim, thanks for the comprehensive write-up and all the work you do on NUT.
> This project has definitely accumulated heaps of wisdom in-between the
> source lines over the years. The picture is much clearer now, and the scope
> of the effort also. Not an easy feat! I wish I had cycles to spare.
>
> For my project I'm probably going for the USB HID approach.
>
> Just one final question -- is it possible to allow running a driver as an
> external executable? That way we can shift the whole problem outside of
> NUT. 

Re: [Nut-upsuser] Supporting a DIY UPS with minimal effort but maximum gain

[Jim Klimov via Nut-upsuser]

Hello all,

  I think there was a very good reply about an Arduino-based controller for
a DIY UPS here. The project you posted to, with an Arduino presenting as a
Megatec protocol server, also seems interesting.

  Here I'd like to reply to one point not covered before - DMF. As a short
and quick reply - unfortunately no, you can not use it with stock upstream
NUT at the moment, and not for USB when customized code is involved. That
said, it is a long-term hope that one day this would be possible. Each
recent NUT release milestone had some work that chipped away the technical
barriers to including DMF into the main project.

  For a longer version: DMF was designed and developed, fairly well tested
and then a bit abandoned in the 42ITy fork of NUT, which went back to using
upstream NUT for their appliances. The developed code base however for a
long time acts as the source of backports for features and vendor device
nuances into upstream NUT to benefit everyone. That codebase is available
in the FTY branch, including DMF along with many other changes (thousands
of commits) so separating them into cleanly visible and revisable
increments, and digesting in the upstream code, aligning with protocol and
other changes that happened over the years, style and tests/quality gates,
is quite an effort. Conversely, merging back the upstream NUT into the FTY
codebase (to achieve green CI survival) was an effort that took a few
years, since the baseline was NUT v2.7.4 and codebases diverged
significantly in some spots - so there were quite a few warnings found that
needed addressing. Currently the FTY branch is relatively recently
synchronised with NUT, at least buildable and passes CI tests, including
the DMF aspect. And since the codebases converged again recently - now as
stuff gets upstreamed here and there, a mere resync and `git diff
FTY..master` helps see how much is left, what commits were missed or typos
added, and what can be picked up next :)

  DMF per se is an effort to separate the binary driver from data mappings,
in cases where logic remains the same and just the data points differ from
device to device (e.g. SNMP OIDs to query for information about different
aspects of UPS or ePDU state). This should well apply to USB HID and maybe
to nutdrv_qx; a recently added concept of `hwmon` driver (talking to sysfs
nodes) is also a good candidate.

  Initial development in the 42ITy project provided a separate library for
DMF general foundations, and build-time changes to the snmp-ups driver (and
nut-scanner snmp mode) to use mappings from XML files rather than built
into the driver binary once and forever until a rebuild. This allows for
smaller binaries on one hand, and for field-maintainable mappings (edit
XML, add another) to support new devices without changing NUT packages and
programs (of course, PRs would be welcome to add such changes to the
upstream library to be included in future releases). In fact, the few
differences for the core driver are hidden by `ifdef` (so there are two
binary builds, with built-in mappings and with DMF support), and the
`nut-scanner` tool is dually-capable in the same build. In fact, to test
the theory, NUT codebase in the branch provides scripts that convert
`*-mib.c` tables into equivalent DMF XML files, so a copy of `snmp-ups-dmf`
driver program with the bunch of text resource files is equivalent out of
the box to a monolithic `snmp-ups` binary built from same codebase, but
more extensible in the field afterwards.

  Part of "abandonment" of this approach was the uncertainty of how correct
the big wad of new code it is (hard to guarantee with that older NUT
baseline which naturally had thousands of warnings so lots of diagnostic
noise) and suspicions that it had memory leaks so maybe had issues with
long-term stability (not proven to be definitely the root cause of some
issues, as far as I am aware). Those were issues entangled with
semi-commercial project priorities (rush to market - pick the lowest
hanging fruits, backlog the rest) so it was left on a backburner, awaiting
a revival in upstream NUT.

  Another part was more technical, a sort of stalemate in design: many
mapping tables in NUT involve data conversions (e.g. date formats,
temperature units, integer milliVolts to floating-point Volts, text labels
for numeric enum values, etc.) for data transfers from a device or writes
back to it. In the current C codebase (*-mib.c, *-hid.c) there are helper
methods to which we can point from the tables. An equivalent for DMF, with
mappings conveyed by text files, involved adding LUA scripts with a LUA-C
bridge to pass the data from binary driver to scripting context and back.
This worked reasonably well; the problem was having two potentially
different implementations of the helpers (C and LUA) for mappings provided
with NUT - and no good way (at least back then) to either compare that they
behave identically or to eliminate one (likely the native C... but then add
LUA as 

Re: [Nut-upsuser] Supporting a DIY UPS with minimal effort butmaximum gain

[Jim Klimov via Nut-upsuser]

two problems getting NUT to recognize the Arduino:
> 1) Will NUT recognize the default Arduino vendor and product id (vid:pid)?
> The answer is YES! There is an Arduino subdriver for usbhid in NUT. It
> looks like the HIDPowerDevice project author added this originally a few
> years ago! See drivers/arduino-hid.c for the list of supported IDs. If you
> end up with an Arduino device that has another vid/pid combo, it would need
> to be added there.
>
> 2) When using the HIDPowerDevice library, the Arduino Micro presents as a
> composite HID device, so it is more than one HID type at once. AFAICT, real
> world examples of composite devices are rare, but it is in the HID spec. In
> this exact case the Arduino presents as both serial/comm interface
> (typically used for debug output when running code from the Arduino IDE)
> and as a HID Power Device (the HID term for UPS status over USB). This all
> works now as of NUT 2.8.2.
>
> Note that the Arduino subdriver is not as full featured as something like
> the APC subdriver. I don't think it allows for NUT to set values on the
> Arduino HID device. I don't know if the Arduino HIDPowerDevice library
> supports this either. I have only tested the send-a-report-periodically
> code path.
>
> NUT config
> What I really wanted was for my NAS to shut down when mains power goes
> away. My QNAP NAS runs NUT, but I needed 2.8.2 and getting a new version on
> there was more than I wanted to tackle, especially since my PRs weren't in
> a release version of NUT at that time. So I run a NUT server on a Raspberry
> PI which is connected via USB to my DIY-NAS Arduino. The RPi does not react
> to changes in the UPS at all. It  makes them available over the network to
> the NUT instance running on the QNAP NAS. The QNAP NAS is then configured
> to poll the RPi NUT instance for UPS status and set to shut down if AC
> power is out for 5 min. I would rather not deal with this extra RPi in the
> setup, but it was the easiest way forward for me. Once NUT 2.8.2 is
> available for my QNAP NAS. I'll get rid of it.
>
>
> Optional Upgrade
> DC voltage sensing to give an idea of remaining runtime or remaining
> capacity. Since this is too long already, I'll try to be brief. One thing I
> did a month or so after the initial install was add DC voltage detection to
> the Arduino side of things:
>
> Gear:
> * 0-25VDC voltage sensor (https://www.amazon.com/gp/product/B01HTC4XKY).
> It's a voltage divider, let's my code sense the DC voltage.
>
> * External ADC: ADS1115 board. I wanted higher resolution DC voltage
> detection.
>
> My code then changed to take readings from the ADS1115 and convert that
> into a rough "50-100% capacity remaining" that I can report to NUT. It took
> a while to get right and it's only "accurate enough", not "trust this to a
> millivolt level of accuracy". For now it's just nice to have and I enjoyed
> having to learn about ADC measuring on Arduino enough to get this accurate
> enough to report with 1% differences in capacity.
>
> Future
> I've been researching designing a PCB and doing an "all-in-one" UPS. I'll
> talk more about that on the wiki page as well.
>
> I guess I should share my Arduino code on GitHub too.
>
> On Thu, May 16, 2024 at 10:59 AM gene heskett via Nut-upsuser <
> nut-upsuser@alioth-lists.debian.net> wrote:
>
>> On 5/16/24 08:59, Jim Klimov via Nut-upsuser wrote:
>> > I agree with earlier posters, such documentation can help future
>> > tinkerers. There is probably more than just one to hold the hand and
>> > walk through the ordeals :)
>> >
>> > Perhaps a new page at https://github.com/networkupstools/nut/wiki
>> > <https://github.com/networkupstools/nut/wiki> can be a good location...
>> >
>> > Jim
>> >
>> Great Idea Jim.
>> >
>> > On Thu, May 16, 2024 at 1:29 PM Bill Gee > > <mailto:b...@campercaver.net>> wrote:
>> >
>> > Hi Kelly -
>> >
>> > As an Arduino nerd, I am interested in this!  I am sure others on
>> the
>> > list would be interested.  If nothing else, it would be nice to have
>> > some documentation in the archives.
>> >
>> > I assume you set it up as an online system rather than a standby
>> > system.
>> >Right?  If true, then the choice of inverter is fairly
>> critical.  It
>> > has to be bomb-proof reliable.
>> >
>> > What did you choose for battery voltage?  What is the power
>> capacity of
>> > the inverter?
>> >
>> > Which Arduino did you use?  All of my Ardui

Re: [Nut-upsuser] Supporting a DIY UPS with minimal effort but maximum gain

[Jim Klimov via Nut-upsuser]

I agree with earlier posters, such documentation can help future tinkerers.
There is probably more than just one to hold the hand and walk through the
ordeals :)

Perhaps a new page at https://github.com/networkupstools/nut/wiki can be a
good location...

Jim


On Thu, May 16, 2024 at 1:29 PM Bill Gee  wrote:

> Hi Kelly -
>
> As an Arduino nerd, I am interested in this!  I am sure others on the
> list would be interested.  If nothing else, it would be nice to have
> some documentation in the archives.
>
> I assume you set it up as an online system rather than a standby system.
>   Right?  If true, then the choice of inverter is fairly critical.  It
> has to be bomb-proof reliable.
>
> What did you choose for battery voltage?  What is the power capacity of
> the inverter?
>
> Which Arduino did you use?  All of my Arduino projects use the Pro Mini,
> though it would be quite easy to get some other model for this.
>
> Thanks -
> ===
> Bill Gee
>
> On 5/15/24 20:11, Kelly Byrd wrote:
> > I put together my own DIY UPS,  it's a RV charger/converter, an
> > inverter, and some batteries. I use an Arduino and the HIDPowerDevice
> > library (https://github.com/abratchik/HIDPowerDevice
> > ) to get it to talk to
> NUT.
> > Been working great for months!
> >
> > The Arduino is connected to two modules:
> > * AC detection circuit to measure mains power on/off
> > * Voltage divider and an external ADC to get a reasonably good DC
> > voltage level for the battery which I turn into the a charge percentage.
> >
> > This uses the USBHID driver in NUT and "just works" as long as you're
> > using NUT 2.8.2 or later. I used the example code in the HIDPowerDevice
> > library as a starting point for running on my Arduino.
> >
> > I can share more specifics about the Arduino side of things off list if
> > you want, the NUT side of things is pretty boring and normal.
> >
> > On Wed, May 15, 2024 at 3:27 PM Kiril Zyapkov via Nut-upsuser
> >  > > wrote:
> >
> > Hello,
> >
> > I found out about NUT just days ago while searching for a solution
> > for my home setup. After some digging through the interwebs, I come
> > to you with questions.
> >
> > I'm putting together a DIY 12V UPS, very similar to what this guy
> did:
> >
> > [1]
> >
> https://baldpenguin.blogspot.com/2015/10/diy-12v-ups-for-home-network-equipment.html
> <
> https://baldpenguin.blogspot.com/2015/10/diy-12v-ups-for-home-network-equipment.html
> >
> >
> > The objective is to keep a bunch of mini PCs and network gear online
> > for as long as the battery lasts and then provide a mechanism for a
> > graceful shutdown of my NAS and other appliances for which cutting
> > power would not be healthy. The project above is missing the
> > "connected" part. I want to get mine to play with NUT nicely. Other
> > prior art is this project:
> >
> > [2] https://github.com/xm381/Raspberry-Pi-UPS
> > 
> >
> > Mentioned in a previous thread here:
> >
> > [3]
> >
> https://alioth-lists.debian.net/pipermail/nut-upsuser/2018-August/011198.html
> <
> https://alioth-lists.debian.net/pipermail/nut-upsuser/2018-August/011198.html
> >
> >
> > A valid approach -- emulates an existing protocol on an arduino.
> >
> > Are there other similar projects that you know of? I found plenty of
> > "DIY UPS" projects, but none were "smart".
> >
> > I am able to put together firmware for some micro which will take
> > care of measuring voltages, currents, possibly also turn on/off
> > loads, serial or USB or IP are options. Not sure yet what hardware
> > features I'll put together, but this depends somewhat on the
> > approach for getting this thing integrated with NUT. PSUs and
> > batteries are already on the way, and my junk drawers have most
> > other parts I may need.
> >
> > So, options found so far:
> >
> > * Use genericups. Least favorite option, very limited features
> >
> > * Use the same approach as [2]. If I were to go that route -- which
> > is the best protocol to pick for emulation? I'm looking for
> > something simple, extensible/flexible and well-documented.
> >
> > But what I really wish was possible was the ability to describe my
> > device in some format, feed it to a generic driver in NUT and
> > profit. I see some efforts have been made in this direction, most
> > notably:
> >
> > [4]
> > https://github.com/networkupstools/nut/wiki/Data-Mapping-File-(DMF)
> >  >
> >
> > What is the state there? Is it usable for USB HID? Or, how hard
> > would it be to make it usable? Even a modbus description will do --
> > implementing the modbus server (yes, server, I'm being
> > politically-correct) over serial or even 

Re: [Nut-upsuser] Possibility to set NUT drivers to "monitor only"?

[Jim Klimov via Nut-upsuser]

FWIW, added this to Wiki:
https://github.com/networkupstools/nut/wiki/Monitoring%E2%80%90only-NUT-clients

On Thu, May 2, 2024 at 11:57 AM Jim Klimov  wrote:

> Hello, and welcome to the NUT community! :)
>
>   On one hand, it would generally help to read up the documentation about
> NUT architecture, seeing as it is a crucial part of your systems' uptime
> and data integrity.
>
>   On another hand, for this particular use-case: it is quite possible to
> set up monitoring-only systems which only inform you if some *other* NUT
> data server has had interesting situations, or mixed-monitoring systems for
> that matter.
>
>   The software part of NUT responsible for actually shutting down a
> computer is typically the `upsmon` client, whose `SHUTDOWNCMD` setting (in
> `upsmon.conf`) defines how to go about the routine. NUT drivers do interact
> with devices (and can send power-off commands to supported UPSes in case of
> `killpower` flag being processed), but they do not make the decision to do
> so - the `upsmon` client running on that box does, based on it being the
> primary (ex-master) system for the UPS meaning it has the physical media to
> talk to the device (serial/USB/networked/...). An `upsmon` client running
> in "primary/master" mode on the system that can actually talk to the UPS
> would have a `MONITOR` line with specification of how many PSUs of this
> server that UPS feeds (1 or more) and a `MINSUPPLIES` line to specify how
> many PSUs (1+) should be fed to consider the server capable of running
> indefinitely as far as having power is the question. On redundant servers
> you can have something like "1 of 2 is okay", or "1..3 out of 4" depending
> on the blade chassis population, etc. When the situation gets critical, a
> "primary" `upsmon` client would set the local `KILLPOWER` flag which would
> cause the OS late-shutdown scripts (where supported) to run a driver
> instance talk to the UPS again and tell it to power off and recycle when
> safe to do so (and thus avoid the "power race condition" where the wall
> power comes back while half of your rack is already down, so it sits for
> days waiting for someone to power all servers back on).
>
>   As far as monitoring-only clients are concerned, you can set the
> argument to the MONITOR line un `upsmon.conf`, that the tracked (and often
> "secondary") UPS feeds zero (0) power sources of this particular monitoring
> box, which makes sense if it sits in a different building for example.
> Orthogonally to that, you can also specify `MINSUPPLIES 0` to a purely
> monitoring system, impacting the trigger for its own shutdown (as long as
> that many PSUs are fed, all is okay). In a mixed system, having its own
> UPS(es) and monitoring some remote NUT data servers, you would have a mix
> of "local" MONITOR lines with a non-zero count of PSUs fed (summing up to
> your MINSUPPLIES for a healthy uptime) and other MONITOR lines with the
> zero amount of fed PSUs.
>
> Hope this helps,
> Jim Klimov
>
>
> On Thu, May 2, 2024 at 9:22 AM Alexander Hofmann via Nut-upsuser <
> nut-upsuser@alioth-lists.debian.net> wrote:
>
>> Dear all,
>>
>> I might have a somewhat strange question (which might arise from my
>> [rather unusual?] use case, see below): Is it possible to put the
>> "blazer_usb" driver (or NUT in general) to something like a "read only"
>> or "monitor only" mode in respect to the communication with the
>> hardware? The idea would be to not allow NUT to switch off the power at
>> the UPS at all.
>>
>> Currently, I disabled the "KILLPOWER" switch, so that "upsdrvctl
>> shutdown" is not called when the monitoring system is shut down (that's
>> what I read in all the guides I could find online, and the only thing
>> related in the manpages AFAIK). But I'm not sure what else to disable or
>> change. So I though, if there's the ability to disable "control" to the
>> UPS entirely at driver level, this would be the most "permanent"
>> solution to make sure no "accident" occurs?
>>
>>
>> If you have another Idea, here's the "real" problem:
>>
>> I'm monitoring a UPS (FSP "Clipper", working with driver blazer_usb)
>> that's controlling power to a inert-gas glovebox-system in a laboratory,
>> with some additional "support" hardware. The goal is to record power
>> usage and lifetime data of the UPS 1st, shutdown on power loss 2nd. The
>> system actually has no means to be "safely shutdown" in an automated
>> way, so most of the usual "protocols" to follow for servers or storage
>> or... do not apply to the system itself. I can of course control other
>> devices or shutdown stuff that's not mandatory to reduce power usage.
>> Thus: I might issue shutdown commands to PCs, power strips etc. powering
>> measurement equipment, or the monitoring system, but will keep the "main
>> thing" running as long as the UPS hardware can handle it (at that time,
>> all other "intelligent" devices are already off, including NUT itself,
>> at least that's the plan). Such an event 

Re: [Nut-upsuser] Possibility to set NUT drivers to "monitor only"?

[Jim Klimov via Nut-upsuser]

Hello, and welcome to the NUT community! :)

  On one hand, it would generally help to read up the documentation about
NUT architecture, seeing as it is a crucial part of your systems' uptime
and data integrity.

  On another hand, for this particular use-case: it is quite possible to
set up monitoring-only systems which only inform you if some *other* NUT
data server has had interesting situations, or mixed-monitoring systems for
that matter.

  The software part of NUT responsible for actually shutting down a
computer is typically the `upsmon` client, whose `SHUTDOWNCMD` setting (in
`upsmon.conf`) defines how to go about the routine. NUT drivers do interact
with devices (and can send power-off commands to supported UPSes in case of
`killpower` flag being processed), but they do not make the decision to do
so - the `upsmon` client running on that box does, based on it being the
primary (ex-master) system for the UPS meaning it has the physical media to
talk to the device (serial/USB/networked/...). An `upsmon` client running
in "primary/master" mode on the system that can actually talk to the UPS
would have a `MONITOR` line with specification of how many PSUs of this
server that UPS feeds (1 or more) and a `MINSUPPLIES` line to specify how
many PSUs (1+) should be fed to consider the server capable of running
indefinitely as far as having power is the question. On redundant servers
you can have something like "1 of 2 is okay", or "1..3 out of 4" depending
on the blade chassis population, etc. When the situation gets critical, a
"primary" `upsmon` client would set the local `KILLPOWER` flag which would
cause the OS late-shutdown scripts (where supported) to run a driver
instance talk to the UPS again and tell it to power off and recycle when
safe to do so (and thus avoid the "power race condition" where the wall
power comes back while half of your rack is already down, so it sits for
days waiting for someone to power all servers back on).

  As far as monitoring-only clients are concerned, you can set the argument
to the MONITOR line un `upsmon.conf`, that the tracked (and often
"secondary") UPS feeds zero (0) power sources of this particular monitoring
box, which makes sense if it sits in a different building for example.
Orthogonally to that, you can also specify `MINSUPPLIES 0` to a purely
monitoring system, impacting the trigger for its own shutdown (as long as
that many PSUs are fed, all is okay). In a mixed system, having its own
UPS(es) and monitoring some remote NUT data servers, you would have a mix
of "local" MONITOR lines with a non-zero count of PSUs fed (summing up to
your MINSUPPLIES for a healthy uptime) and other MONITOR lines with the
zero amount of fed PSUs.

Hope this helps,
Jim Klimov


On Thu, May 2, 2024 at 9:22 AM Alexander Hofmann via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:

> Dear all,
>
> I might have a somewhat strange question (which might arise from my
> [rather unusual?] use case, see below): Is it possible to put the
> "blazer_usb" driver (or NUT in general) to something like a "read only"
> or "monitor only" mode in respect to the communication with the
> hardware? The idea would be to not allow NUT to switch off the power at
> the UPS at all.
>
> Currently, I disabled the "KILLPOWER" switch, so that "upsdrvctl
> shutdown" is not called when the monitoring system is shut down (that's
> what I read in all the guides I could find online, and the only thing
> related in the manpages AFAIK). But I'm not sure what else to disable or
> change. So I though, if there's the ability to disable "control" to the
> UPS entirely at driver level, this would be the most "permanent"
> solution to make sure no "accident" occurs?
>
>
> If you have another Idea, here's the "real" problem:
>
> I'm monitoring a UPS (FSP "Clipper", working with driver blazer_usb)
> that's controlling power to a inert-gas glovebox-system in a laboratory,
> with some additional "support" hardware. The goal is to record power
> usage and lifetime data of the UPS 1st, shutdown on power loss 2nd. The
> system actually has no means to be "safely shutdown" in an automated
> way, so most of the usual "protocols" to follow for servers or storage
> or... do not apply to the system itself. I can of course control other
> devices or shutdown stuff that's not mandatory to reduce power usage.
> Thus: I might issue shutdown commands to PCs, power strips etc. powering
> measurement equipment, or the monitoring system, but will keep the "main
> thing" running as long as the UPS hardware can handle it (at that time,
> all other "intelligent" devices are already off, including NUT itself,
> at least that's the plan). Such an event occurs maybe once a year, if at
> all...
>
> So far, I think disabling UPS shutdown at system shutdown is the only
> thing I really need, but as the system is rather crucial to our
> workflow, I wanted to make sure. The more changes I have to make to the
> "default" configuration, the 

Re: [Nut-upsuser] [Nut-upsdev] RFE to extend "LISTEN" directive to support host-colon-port (as single token)

[Jim Klimov via Nut-upsuser]

Just in case, to the last couple of posts speaking of multiple listeners:
NUT does allow specifying several lines of `LISTEN host port` to handle
multi-homing and whatnot. A reminder to readers who might not realize this
possibility exists already.

Jim

On Tue, Apr 30, 2024, 18:00 Kelly Byrd  wrote:

> IMO, if NUT is going to offer "host and port" in the config, It should be
> host:port. That will surprise the fewest people. Spaces can then be used to
> separate multiple entries (host1:port1 host2:port2)
> I do NOT think you need to go down the "resolve service name string to
> port".
>
> On Mon, Apr 29, 2024 at 6:32 AM Greg Troxel via Nut-upsuser <
> nut-upsuser@alioth-lists.debian.net> wrote:
>
>> Jim Klimov  writes:
>>
>> > Just to clarify: using a different port *is* possible since forever,
>> with
>> > `LISTEN host port` (as two arguments to the directive); the question
>> was if
>> > having a way to spell it as one argument as `LISTEN host:port` would
>> solve
>> > some shortcomings/ease adoption more than introduce some new problems :)
>>
>> Ah.  Well, if there is already a way to do it, IMHO adding a second way
>> is complexity with no benefit.
>>
>> why would anyone want to use "host:port" when "host port" works?  That
>> just seems like "I want to rewrite the config format, because [why?]."
>>
>>
>> > With recent releases addressing this area, a host name resolving to
>> several
>> > IP addresses should be recognized, but at the moment this would only
>> emit a
>> > warning about the situation and the first seen IP address number would
>> get
>> > attempted for bind(). If this proves to be a problem, should not be too
>> > hard to address (need to inject entries into an internal list tracking
>> the
>> > sockets which is originally sized by amount of LISTEN lines; there is
>> > already precedent for injection of IPv4 and IPv6 where a single `LISTEN
>> *`
>> > directive and avoided dual-stack mode are in place).
>>
>> That seems separable, but I'd say listening on the first addr is a bug.
>>
>> > As for practical use of non-default ports, NIT (NUT Integration Testing)
>> > scripts come to mind and do that extensively (especially where the same
>> CI
>> > host/agent can be running different scenarios in parallel, so any one
>> > hard-coded port is prone to conflict).
>>
>> That's fair.
>>
>> > Other practical reasons might include security by obscurity (like
>> runpning
>> > web consoles or ssh on strange ports), running different NUT data
>> servers
>> > (e.g. real drivers on one, and "dummy-ups" or "clone*" relays on the
>> > other), or attempts to avoid conflicts with uncooperative software.
>> Can't
>> > think of much more quickly :)
>>
>> Given that it's already supported, that query of mine is out of scope.
>>
>> ___
>> Nut-upsuser mailing list
>> Nut-upsuser@alioth-lists.debian.net
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>>
> ___
> Nut-upsuser mailing list
> Nut-upsuser@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] [Nut-upsdev] RFE to extend "LISTEN" directive to support host-colon-port (as single token)

[Jim Klimov via Nut-upsuser]

Thanks for sharing your take on this. (Sorry about likely mixing historic
standards, was not in position to cross-check while posting)

Just to clarify: using a different port *is* possible since forever, with
`LISTEN host port` (as two arguments to the directive); the question was if
having a way to spell it as one argument as `LISTEN host:port` would solve
some shortcomings/ease adoption more than introduce some new problems :)

With recent releases addressing this area, a host name resolving to several
IP addresses should be recognized, but at the moment this would only emit a
warning about the situation and the first seen IP address number would get
attempted for bind(). If this proves to be a problem, should not be too
hard to address (need to inject entries into an internal list tracking the
sockets which is originally sized by amount of LISTEN lines; there is
already precedent for injection of IPv4 and IPv6 where a single `LISTEN *`
directive and avoided dual-stack mode are in place).

As for practical use of non-default ports, NIT (NUT Integration Testing)
scripts come to mind and do that extensively (especially where the same CI
host/agent can be running different scenarios in parallel, so any one
hard-coded port is prone to conflict).

Other practical reasons might include security by obscurity (like running
web consoles or ssh on strange ports), running different NUT data servers
(e.g. real drivers on one, and "dummy-ups" or "clone*" relays on the
other), or attempts to avoid conflicts with uncooperative software. Can't
think of much more quickly :)

Hope this helps,
Jim Klimov


On Mon, Apr 29, 2024 at 2:31 PM Greg Troxel via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:

> Jim Klimov via Nut-upsdev  writes:
>
> >   A recent discussion in the issue tracker brought up the idea to allow
> the
> > `LISTEN` keyword to also accept a single "host:port" token (e.g. if there
> > is only one argument, with at least one colon, and the last colon is
> > followed only by numbers, split it into host and port) :
> > https://github.com/networkupstools/nut/issues/2424
>
> Is the point that people want to use different ports, and the current
> situation lets you choose an address but not a port?
>
> Assuming so, why would there be a restriction to a single host if there
> is port, while one could have multiple listen addresses if not?  I would
> think the : scheme should apply to each argument, with lack of : being
> an implict :[normalport].
>
> For me, the reason to use explicit listen is because you don't like *,
> and if you are using IP addresses you might well want to listen to v4
> and v6.
>
> This raises the issue of whether "host" expands to all IP addresses
> associated with a domain name.
>
> >   There are also certain cons, primarily about parsing such stuff
> reliably
> > and consistently in different code bases (now also with augeas and
> nutconf
> > to worry about). The actual "production" parsing in NUT data server code
> > should be trivial.
>
> I find this whole "our config needs to be generally machine readable but
> we aren't just changing it to a machine-readable format" to be odd.   If
> we want to play in some world where that happens we should just flip to
> yaml or something :-)
>
> >   On a somewhat related note, should the port part be constrained to
> > numbers, or should it also pass through the naming database (resolve via
> > typically /etc/services on POSIX systems) if it is a non-numeric string,
> > similar to how we resolve host names into IP address numbers?
>
> sure, non-numeric port could go through getservbyname(3) and then fail
> if not the expected protocol.  Don't talk about /etc/services but the
> posix interface, except it's from 4.2BSD and I'm not sure it's been
> specified by POSIX :-)
>
> On the other hand, if you are using an alternate port, it's because you
> are not doing the normal thing, and the idea that you specify 'ntp'
> because you want nut on 123 doesn't really make sense.   And if you know
> some name it's not hard to look it up by name.   So all in all, I vote
> for no, it's a number.
>
> >   What would the community say, is any of this worth spending time on?
> > Would anyone volunteer to roll up the sleeves for that? :)
>
> No and no, IMHO.   What is the problem being solved?  Are there actual
> people who want to use a different port?  What are their reasons?
> I can believe there might be a scenario, but it seems speculative.
>
> ___
> Nut-upsuser mailing list
> Nut-upsuser@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

[Nut-upsuser] RFE to extend "LISTEN" directive to support host-colon-port (as single token)

[Jim Klimov via Nut-upsuser]

Cheers all,

  A recent discussion in the issue tracker brought up the idea to allow the
`LISTEN` keyword to also accept a single "host:port" token (e.g. if there
is only one argument, with at least one colon, and the last colon is
followed only by numbers, split it into host and port) :
https://github.com/networkupstools/nut/issues/2424

  I see certain pros to the idea (may be more simple to use and consistent
with some other software setup), although I don't think it was an issue
ever brought up in discussions before.

  There are also certain cons, primarily about parsing such stuff reliably
and consistently in different code bases (now also with augeas and nutconf
to worry about). The actual "production" parsing in NUT data server code
should be trivial.

  On a somewhat related note, should the port part be constrained to
numbers, or should it also pass through the naming database (resolve via
typically /etc/services on POSIX systems) if it is a non-numeric string,
similar to how we resolve host names into IP address numbers?

  What would the community say, is any of this worth spending time on?
Would anyone volunteer to roll up the sleeves for that? :)

Jim Klimov
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] NUT v2.8.2, the Easter Egg Edition

[Jim Klimov via Nut-upsuser]

UPDATE: No problem got confirmed about driver code - only some scripting
mishaps with NDE: https://github.com/networkupstools/nut/pull/2413 (testing
welcome)

Jim

On Fri, Apr 19, 2024 at 2:07 PM Jim Klimov  wrote:

> 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 `ups.conf` section. Increasing verbosity and
> decreasing to non-zero (e.g. 1) works.
>
> These are currently being investigated.
>
> Jim Klimov
>
>
>
> On Tue, Apr 2, 2024 at 1:06 AM Jim Klimov  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 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
>> as the field nurse
>>
>>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] NUT v2.8.2, the Easter Egg Edition

[Jim Klimov via Nut-upsuser]

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 `ups.conf` section. Increasing verbosity and
decreasing to non-zero (e.g. 1) works.

These are currently being investigated.

Jim Klimov



On Tue, Apr 2, 2024 at 1:06 AM Jim Klimov  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 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
> as the field nurse
>
>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] NUT v2.8.2, the Easter Egg Edition

[Jim Klimov via Nut-upsuser]

Just the sig file.

On Sun, Apr 7, 2024, 15:45 Greg Troxel via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:

> Jim Klimov via Nut-upsuser  writes:
>
> > A hiccup was reported about validating the tarball signature on some
> > systems, so it was reissued from another workstation. Please don't worry
> :)
>
> Do you mean the signature  was re-issued, which is ok, or that the
> tarball was re-issued, which is very much not ok(!) ?
>
> ___
> Nut-upsuser mailing list
> Nut-upsuser@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] NUT v2.8.2, the Easter Egg Edition

[Jim Klimov via Nut-upsuser]

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  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 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
> as the field nurse
>
>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] CyberPower PR3000LCDRTXL2U — battery date reset?

[Jim Klimov via Nut-upsuser]

Well, for a bit of devil's advocate - if the battery swelled, it might hace
leaked or fumed, contaminating the device and contacts.

The safe approach (for their liability, and for end-users' fire hazard
really) is to not claim the device is safe to use anymore.

Jim

On Tue, Apr 2, 2024, 07:11 Ben  wrote:

> On 4/1/24 7:37 PM, Phil Stracchino via Nut-upsuser wrote:
> > So, I just rebuilt the battery packs in my PR3000LCDRTXL2U and its
> expansion unit.  You don't want to KNOW.  If the internal batteries have
> overheated and bulged, you CANNOT remove the battery pack intact even by
> partially disassembling the UPS, you have to pry the batteries out via the
> top of the chassis one by one.  It's not pretty.  Three and a half hours of
> work including repairing damaged wiring harnesses.
>
> APC UPS aren't much/any better. Kinda funny how big these companies are
> and don't factor in battery swell.
>
> "HEY - just BUY A NEW UPS!" -- LoL. Right?
>
>   -Ben
>
>
> ___
> Nut-upsuser mailing list
> Nut-upsuser@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Language of entities in HomeAssistant

[Jim Klimov via Nut-upsuser]

I suppose you have to ask on HA (or NUT plugin) forums. NUT itself is not
localized.

Jim


On Tue, Apr 2, 2024, 03:19 Roland Scheffer via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:

> Hello,
>
> based on
> https://community.home-assistant.io/t/monitor-a-ups-attached-to-a-windows-machine/444595
>  I
> have installed NUT NUT-Installer-2.6.5-6.msi on my Windows (OS is English,
> keyboard layout is german).
>
> UPS is an Eaton Ellipse 650 DIN-USB. Have also installed “Eaton Companion
> (eng.)”.
>
>
>
> However, if I install the NUT-Tools on my HomeAssistant all entities of
> the UPS are in german. I am looking for a way to have these entities in
> English.
>
> Where are the entities defined ?
>
>
>
>
> ___
> Nut-upsuser mailing list
> Nut-upsuser@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

[Nut-upsuser] NUT v2.8.2, the Easter Egg Edition

[Jim Klimov via Nut-upsuser]

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
as the field nurse
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Je ne parviens pas à faire communiquer mon UPS avec HomeAssistant

[Jim Klimov via Nut-upsuser]

Cursorily, your two LISTEN directives for same IP address can be
conflicting (one grabs the port another one wants)... And/or some service
dependencies (After/Wants/Requires in systemd) in your package are not set
up to start nut-server after surely having passed the network-online
milestone and having the expected IP address.

On Wed, Mar 27, 2024, 14:39 Nicolas via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:

> Bonjour à tous,
>
> Je n'arrive pas a faire marcher NUT avec HomeAssistant.
> Cela fait des mois que je suis la-dessus, mais sans succès !
> Je ne vois plus quoi faire ! Help !
>
>-
>
>Ubuntu 23.10
>-
>
>NUT version = 2.7.4-14ubuntu2
>-
>
>NUT installation method: Package
>-
>
>exact device name and related information : Riello IDG800
>
> Voici les commandes que je tape sur le PC connecté par USB à l'UPS :
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> * $ lsusb Bus 001 Device 002: ID 04b4:5500 Cypress Semiconductor Corp.
> HID->COM RS232 Adapter $ nut-scanner Neon library not found. XML search
> disabled. IPMI library not found. IPMI search disabled. Scanning USB bus.
> No start IP, skipping SNMP No start IP, skipping NUT bus (old connect
> method) [nutdev1] driver = "riello_usb" port = "auto" vendorid
> = "04B4" productid = "5500" bus = "001" *
>
>
>
>
>
>
> *$ sudo upsdrvctl start Network UPS Tools - UPS driver controller 2.7.4
> Network UPS Tools - Riello USB driver 0.03 (2.7.4) Warning: This is an
> experimental driver. Some features may not function correctly.*
>
>
> Fichier : ups.conf
>
> *[**UPS_Bureau*
>
>
> *] driver = riello_usb port = auto #vendorid = "04B4"
> # Lignes commentées car sinon **upsdrvctl start => *
> *Fatal error: 'vendorid' is not a valid variable name for this driver.
> #productid = "5500"**   # **upsdrvctl start
> => **Fatal error: 'productid' is not a valid variable name for this
> driver.*
> *#bus = "001"**  # **upsdrvctl
> start => **Fatal error: '**bus**' is not a valid variable name for this
> driver.*
>
> *desc = "Riello IDG 800 du bureau" *
>
>
> Si Fichier : upsd.conf
>
> *LISTEN localhost 3493*
> *LISTEN 127.0.0.1 3493*
> *LISTEN 192.168.0.49# Adresse IP de mon HomeAssistant*
> *LISTEN 192.168.0.49 3493**   # Adresse IP de mon HomeAssistant*
>
> Alors
> * : *
> *$ upsc UPS_Bureau*
>
> *Error: Connection failure: Connection refused*
>
>
>
> *$ systemctl restart nut-server.service Job for nut-server.service failed
> because the control process exited with error code. See "systemctl status
> nut-server.service" and "journalctl -xeu nut-server.service" for details.*
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *$ systemctl status nut-server.service × nut-server.service - Network UPS
> Tools - power devices information server  Loaded: loaded
> (/lib/systemd/system/nut-server.service; enabled; vendor preset: enabled)
>  Active: failed (Result: exit-code) since Wed 2024-03-27 10:28:00 CET;
> 16s ago Process: 10715 ExecStart=/sbin/upsd (code=exited,
> status=1/FAILURE) CPU: 12ms mars 27 10:28:00 nicolas-MS-7B19
> upsd[10715]: not listening on 192.168.0.49 port 3493 mars 27 10:28:00
> nicolas-MS-7B19 upsd[10715]: listening on 127.0.0.1 port 3493 mars 27
> 10:28:00 nicolas-MS-7B19 upsd[10715]: no listening interface available mars
> 27 10:28:00 nicolas-MS-7B19 upsd[10715]: not listening on 192.168.0.49 port
> 3493 mars 27 10:28:00 nicolas-MS-7B19 upsd[10715]: Network UPS Tools upsd
> 2.7.4 mars 27 10:28:00 nicolas-MS-7B19 upsd[10715]: listening on 127.0.0.1
> port 3493 mars 27 10:28:00 nicolas-MS-7B19 upsd[10715]: no listening
> interface available mars 27 10:28:00 nicolas-MS-7B19 systemd[1]:
> nut-server.service: Control process exited, code=exited, status=1/FAILURE
> mars 27 10:28:00 nicolas-MS-7B19 systemd[1]: nut-server.service: Failed
> with result 'exit-code'. mars 27 10:28:00 nicolas-MS-7B19 systemd[1]:
> Failed to start Network UPS Tools - power devices information server. *
>
>
> Si Fichier : upsd.conf
>
> *LISTEN 127.0.0.1 3493*
>
> Alors
> * : *
>
>
>
>
>
>
>
>
>
>
> *$upsc UPS_Bureau Init SSL without certificate database battery.capacity:
> 7 battery.charge: 255 [...] ups.serial:  ups.status: OL
> ups.temperature: 255 ups.vendorid: 04b4 *
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *$systemctl status nut-server.service ● nut-server.service - Network UPS
> Tools - power devices information server  Loaded: loaded
> (/lib/systemd/system/nut-server.service; enabled; vendor preset: enabled)
>  Active: active (running) since Wed 2024-03-27 12:04:45 CET; 3min 48s
> ago Process: 17682 ExecStart=/sbin/upsd (code=exited, status=0/SUCCESS)
>Main PID: 17683 (upsd)   Tasks: 1 (limit: 19016)  Memory: 620.0K
> CPU: 32ms  CGroup: /system.slice/nut-server.service
>  └─17683 /lib/nut/upsd mars 27 12:04:45 nicolas-MS-7B19
> 

Re: [Nut-upsuser] There is no voltage information

[Jim Klimov via Nut-upsuser]

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) <
1e-9 ) {...}` which feel odd on their own, discussed in
https://github.com/networkupstools/nut/issues/2370

  The old code worked because `abs()` is for `int` numbers, and the
miniscule argument became an always-zero after casting (which is less than
`10^-9`), and for existing devices it just happened to be the correct
codepath to pick an exponent for USB readings. The new code made the
comparisons mathematically correct, to work on `double` precision numbers
using `fabs()` (to not confuse with `fabsf()` for `float` types, go
figure). And boom! Something no longer clicks for `1.39e-06 => 13.9V` and
`2.206e-05 => 220V` (with correction factor `1e7`).

  Obligatory inspiring motivator : https://xkcd.com/1172/

  Thanks to Mr. Fischer for the right logs (and version-dissection
findings) at the right time :)

Jim Klimov


On Mon, Mar 25, 2024 at 7:41 AM Juan Carlos Fischer <
juancarlos.fisc...@gmail.com> wrote:

> Hello Jim!
> First of all, allow me to thank you for your time and invaluable help.
> Exactly arm v7l  are 32 bit. I will conduct several tests and keep you
> informed.
>
> On the other hand this is what I got
> pi@raspberrypi:~ $ sudo /lib/nut/usbhid-ups -DD -a Liebert
>0.00 [D3] do_global_args: var='maxretry' val='3'
>0.001309 [D3] do_global_args: var='user' val='nut'
>0.001604 [D1] Overriding previously specified user 'nut' with 'nut'
> specified in global section
>0.002196 [D3] main_arg: var='driver' val='usbhid-ups'
>0.002280 [D3] main_arg: var='port' val='auto'
>0.002360 [D5] send_to_all: SETINFO driver.parameter.port "auto"
>0.006042 [D3] main_arg: var='vendorid' val='10AF'
>0.006172 [D5] send_to_all: SETINFO driver.parameter.vendorid "10AF"
>0.006402 [D3] main_arg: var='productid' val='0001'
>0.006490 [D5] send_to_all: SETINFO driver.parameter.productid "0001"
>0.006563 [D3] main_arg: var='bus' val='001'
>0.006646 [D5] send_to_all: SETINFO driver.parameter.bus "001"
>0.006720 [D3] main_arg: var='desc' val='PSA UPS'
>0.006792 [D3] main_arg: var='pollinterval' val='15'
>0.006980 [D1] debug level is '6'
>0.009706 [D5] send_to_all: SETINFO device.type "ups"
>0.009873 [D2] Initializing an USB-connected UPS with library
> libusb-1.0.26 (API: 0x1000109) (NUT subdriver name='USB communication
> driver (libusb 1.0)' ver='0.43')
>0.009942 [D1] upsdrv_initups (non-SHUT)...
>0.064656 [D2] Checking device 1 of 12 (2109/0813)
>0.064792 [D1] Failed to open device (2109/0813), skipping: Access
> denied (insufficient permissions)
>0.064851 [D2] Checking device 2 of 12 (1058/2620)
>0.064956 [D1] Failed to open device (1058/2620), skipping: Access
> denied (insufficient permissions)
>0.065018 [D2] Checking device 3 of 12 (2109/0813)
>0.065074 [D1] Failed to open device (2109/0813), skipping: Access
> denied (insufficient permissions)
>0.065122 [D2] Checking device 4 of 12 (1D6B/0003)
>0.065171 [D1] Failed to open device (1D6B/0003), skipping: Access
> denied (insufficient permissions)
>0.065240 [D2] Checking device 5 of 12 (045E/00F5)
>0.065275 [D1] Failed to open device (045E/00F5), skipping: Access
> denied (insufficient permissions)
>0.065308 [D2] Checking device 6 of 12 (10AF/0001)
>0.077166 [D2] - VendorID: 10af
>0.077216 [D2] - ProductID: 0001
>0.077277 [D2] - Manufacturer: Emerson Network Power
>0.077332 [D2] - Product: LiebertPSA
>0.077372 [D2] - Serial Number:
>0.077391 [D2] - Bus: 001
>0.077427 [D2] - Device: unknown
>0.077481 [D2] - Device release number: 0014
>0.077560 [D2] Trying to match device
>0.077600 [D2] match_function_subdriver (non-SHUT mode): matching a
> device...
>0.077664 [D3] match_function_regex: matching a device...
>0.077905 [D2] Device matches
>0.077972 [D2] Reading first configuration descriptor
>0.078055 [D3] libusb_kernel_driver_active() returned 0
>0.078099 [D2] failed to claim USB device: Resource busy
>0.078159 [D2] Kernel driver already detached
>0.078199 [D2] failed to claim USB device: Resource busy
>0.078260 [D2] Kernel driver already detached
>0.078317 [D2] failed to claim USB device: Resource busy
>0.078379 [D2] Kernel driver already detached
>0.078439 [D2] failed to claim USB device: Resource busy
>0.078496 [D2] Kernel driver already detached
>0.078534 Can't claim USB device [10af:0001]@0/0: Entity not found
>
> The same for 2.74. has an endless output.
> I rescue the following
>0.278176 Path: UPS.Input.Voltage, Type: Feature, ReportID: 0x20,
> Offset: 0, Size: 16, Value: 

Re: [Nut-upsuser] There is no voltage information

[Jim Klimov via Nut-upsuser]

Hi,

  FYI: I'll be away from computers (and possibly internet) for a couple of
weeks.

  As for the logs, they are not "the same": the first one (with NUT 2.8.x)
failed to connect to the device it liked -- "failed to claim USB device:
Resource busy" (probably another program holds it, maybe a copy of the
driver wrapped by a systemd unit - see
https://github.com/networkupstools/nut/wiki/nut%E2%80%90driver%E2%80%90enumerator-(NDE)
for probable-cause details).

  The "endless output" makes sense as the driver is running in an infinite
loop (until an exit signal) to collect and publish device information :)

  Logged strings like "assuming correction factor" in the latter (2.7.4)
indicate it goes through drivers/belkin-hid.c which had some attention for
a newly seen strain of Liebert devices just recently with:
* https://github.com/networkupstools/nut/pull/2369
* https://github.com/networkupstools/nut/issues/2271
* https://github.com/networkupstools/nut/issues/2370 - thanks for the log,
it would be helpful here specifically

  You might want to give a shot to a custom master-branch build to see if
it works better with these changes, see
https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests
- or wait for eventual release and some time later packaging of NUT 2.8.2...

Hope this helps,
Jim Klimov



On Mon, Mar 25, 2024 at 7:41 AM Juan Carlos Fischer <
juancarlos.fisc...@gmail.com> wrote:

> Hello Jim!
> First of all, allow me to thank you for your time and invaluable help.
> Exactly arm v7l  are 32 bit. I will conduct several tests and keep you
> informed.
>
> On the other hand this is what I got
> pi@raspberrypi:~ $ sudo /lib/nut/usbhid-ups -DD -a Liebert
>0.00 [D3] do_global_args: var='maxretry' val='3'
>0.001309 [D3] do_global_args: var='user' val='nut'
>0.001604 [D1] Overriding previously specified user 'nut' with 'nut'
> specified in global section
>0.002196 [D3] main_arg: var='driver' val='usbhid-ups'
>0.002280 [D3] main_arg: var='port' val='auto'
>0.002360 [D5] send_to_all: SETINFO driver.parameter.port "auto"
>0.006042 [D3] main_arg: var='vendorid' val='10AF'
>0.006172 [D5] send_to_all: SETINFO driver.parameter.vendorid "10AF"
>0.006402 [D3] main_arg: var='productid' val='0001'
>0.006490 [D5] send_to_all: SETINFO driver.parameter.productid "0001"
>0.006563 [D3] main_arg: var='bus' val='001'
>0.006646 [D5] send_to_all: SETINFO driver.parameter.bus "001"
>0.006720 [D3] main_arg: var='desc' val='PSA UPS'
>0.006792 [D3] main_arg: var='pollinterval' val='15'
>0.006980 [D1] debug level is '6'
>0.009706 [D5] send_to_all: SETINFO device.type "ups"
>0.009873 [D2] Initializing an USB-connected UPS with library
> libusb-1.0.26 (API: 0x1000109) (NUT subdriver name='USB communication
> driver (libusb 1.0)' ver='0.43')
>0.009942 [D1] upsdrv_initups (non-SHUT)...
>0.064656 [D2] Checking device 1 of 12 (2109/0813)
>0.064792 [D1] Failed to open device (2109/0813), skipping: Access
> denied (insufficient permissions)
>0.064851 [D2] Checking device 2 of 12 (1058/2620)
>0.064956 [D1] Failed to open device (1058/2620), skipping: Access
> denied (insufficient permissions)
>0.065018 [D2] Checking device 3 of 12 (2109/0813)
>0.065074 [D1] Failed to open device (2109/0813), skipping: Access
> denied (insufficient permissions)
>0.065122 [D2] Checking device 4 of 12 (1D6B/0003)
>0.065171 [D1] Failed to open device (1D6B/0003), skipping: Access
> denied (insufficient permissions)
>0.065240 [D2] Checking device 5 of 12 (045E/00F5)
>0.065275 [D1] Failed to open device (045E/00F5), skipping: Access
> denied (insufficient permissions)
>0.065308 [D2] Checking device 6 of 12 (10AF/0001)
>0.077166 [D2] - VendorID: 10af
>0.077216 [D2] - ProductID: 0001
>0.077277 [D2] - Manufacturer: Emerson Network Power
>0.077332 [D2] - Product: LiebertPSA
>0.077372 [D2] - Serial Number:
>0.077391 [D2] - Bus: 001
>0.077427 [D2] - Device: unknown
>0.077481 [D2] - Device release number: 0014
>0.077560 [D2] Trying to match device
>0.077600 [D2] match_function_subdriver (non-SHUT mode): matching a
> device...
>0.077664 [D3] match_function_regex: matching a device...
>0.077905 [D2] Device matches
>0.077972 [D2] Reading first configuration descriptor
>0.078055 [D3] libusb_kernel_driver_active() returned 0
>0.078099 [D2] failed to claim USB device: Resource busy
>0.078159 [D2] Kernel driver already detached
>0.078199 [D2] failed to claim USB device: Resource busy
>0.078260 [D2] Kernel driver already detached
>0.078317 [D2] failed to claim USB device: Resource busy
>0.078379 [D2] Kernel driver already detached
>0.078439 [D2] failed to claim USB device: Resource busy
>0.078496 [D2] Kernel driver already detached
>0.078534 Can't claim USB device [10af:0001]@0/0: Entity not found
>
> The 

Re: [Nut-upsuser] There is no voltage information

[Jim Klimov via Nut-upsuser]

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 -DD -s Liebert` to compare the
two walls of text (at some debug level it spews byte data seen from
libusb); this might be more convenient to proceed with as a github issue.

  Another idea, if you would be comfortable building NUT from source, would
be to check if NUT v2.8.0 (and/or current git master) mis-behaves similarly
if built in the Debian 11 32-bit environment against libusb-0.1. So to
dissect if the issue is between NUT 2.7.4 and 2.8.0 or in the OS
environment/dependencies somehow. This can get you started:
https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests
(take care to `configure --with-usb=libusb-0.1 ...`) - notably, you won't
have to *install* this build over what have you in the OS to just test the
newly built driver.

Jim



On Thu, Mar 21, 2024 at 7:18 AM Juan Carlos Fischer <
juancarlos.fisc...@gmail.com> wrote:

> Hello!
>
> NUT 2.7.4
> Raspberry Pi 4 Model B Rev 1.5 8 GB"Raspbian GNU/Linux 11
> (bullseye)"   Linux raspberrypi 5.15.32-v7l+ #1538 SMP Thu Mar 31
> 19:39:41 BST 2022 armv7l GNU/Linux
>
> pi@raspberrypi:~ $ sudo ldd /lib/nut/usbhid-ups
>
> linux-vdso.so.1 (0xbec53000)
> /usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so =>
> /usr/lib/arm-linux-gnueabihf/libarmmem-v7l.so (0xb6f83000)
> libusb-0.1.so.4 => /lib/arm-linux-gnueabihf/libusb-0.1.so.4 (0xb6f4e000)
> libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb6f22000)
> libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6dce000)
> /lib/ld-linux-armhf.so.3 (0xb6f98000)
>
> NUT 2.8.0
> Raspberry Pi 4 Model B Rev 1.5 8 GB "Debian GNU/Linux 12 (bookworm)"  Linux
> raspberrypi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr  3 17:24:16 BST 2023
> aarch64 GNU/Linux
>
> pi@raspberrypi:~ $ sudo ldd /lib/nut/usbhid-ups
>
>  linux-vdso.so.1 (0x007f9051c000)
> libusb-1.0.so.0 => /lib/aarch64-linux-gnu/libusb-1.0.so.0
> (0x007f9041)
> libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x007f9026)
> /lib/ld-linux-aarch64.so.1 (0x007f904df000)
> libudev.so.1 => /lib/aarch64-linux-gnu/libudev.so.1 (0x007f9021)
> libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0
> (0x007f901e)
>
> Best regards,
> -jcf
>
>
> On Wed, Mar 20, 2024 at 5:10 PM Jim Klimov 
> wrote:
>
>> Thanks.
>>
>>   Can you please also check (e.g. with ldd `which usbhid-ups`) which
>> `libusb` variant (1.0 or 0.1) was the 2.7.4 version of the driver running
>> with?
>>   I wonder if the two generations of that library got something
>> differently?..
>>
>>   The commit I mentioned -
>> https://github.com/networkupstools/nut/commit/207fed2282 - which added
>> the exponent checks, was from 2012 and should be in 2.7.4 as well :-\
>>
>>   Checked: it is -
>> https://github.com/networkupstools/nut/blob/v2.7.4/drivers/belkin-hid.c#L157-L194
>>
>>   Are the two tests running on otherwise the same HW/OS setup?
>>
>> Jim
>>
>>
>> On Wed, Mar 20, 2024 at 9:01 PM Juan Carlos Fischer <
>> juancarlos.fisc...@gmail.com> wrote:
>>
>>> Hello!
>>> Thanks for answering.
>>> This is the result using version 2.7.4:
>>>
>>> Network UPS Tools - UPS driver controller 2.7.4
>>> Network UPS Tools - Generic HID driver 0.41 (2.7.4)
>>> USB communication driver 0.33
>>> Using subdriver: Belkin/Liebert HID 0.17
>>>
>>> battery.charge: 100
>>> battery.charge.low: 38
>>> battery.charge.warning: 38
>>> battery.type: PbAc
>>> battery.voltage: 13.9
>>> battery.voltage.nominal: 12.0
>>> device.mfr: Emerson Network Power
>>> device.model: LiebertPSA
>>> device.serial:
>>> device.type: ups
>>> driver.name: usbhid-ups
>>> driver.parameter.bus: 001
>>> driver.parameter.pollfreq: 30
>>> driver.parameter.pollinterval: 2
>>> driver.parameter.port: auto
>>> driver.parameter.productid: 0001
>>> driver.parameter.synchronous: no
>>> driver.parameter.vendorid: 10AF
>>> driver.version: 2.7.4
>>> driver.version.data: Belkin/Liebert HID 0.17
>>> driver.version.internal: 0.41
>>> input.frequency: 50.0
>>> input.voltage: 221.8
>>> output.voltage: 222.6
>>> ups.load: 8
>>> ups.mfr: Emerson Network Power
>>> ups.model: LiebertPSA
>>> ups.productid: 0001
>>> ups.serial:
>>> ups.status: OL CHRG
>>> ups.vendorid: 10af
>>>
>>> Regards,
>>>
>>> Juan Carlos
>>>
>>> On Wed, Mar 20, 2024 at 4:22 PM Jim Klimov 
>>> wrote:
>>>
 Hello,

   For clarity: what changed with the move from NUT v2.7.4 to 2.8.0 -
 the warnings "became reported", or the highlighted values became zeroes
 (and were valid non-zero numbers with older NUT - so a regression)?

   It seems the message is specific to the subdriver and comes from
 commit 207fed2282 and a change to the method involved was just recently
 experimentally proposed in

Re: [Nut-upsuser] There is no voltage information

[Jim Klimov via Nut-upsuser]

Thanks.

  Can you please also check (e.g. with ldd `which usbhid-ups`) which
`libusb` variant (1.0 or 0.1) was the 2.7.4 version of the driver running
with?
  I wonder if the two generations of that library got something
differently?..

  The commit I mentioned -
https://github.com/networkupstools/nut/commit/207fed2282 - which added the
exponent checks, was from 2012 and should be in 2.7.4 as well :-\

  Checked: it is -
https://github.com/networkupstools/nut/blob/v2.7.4/drivers/belkin-hid.c#L157-L194

  Are the two tests running on otherwise the same HW/OS setup?

Jim


On Wed, Mar 20, 2024 at 9:01 PM Juan Carlos Fischer <
juancarlos.fisc...@gmail.com> wrote:

> Hello!
> Thanks for answering.
> This is the result using version 2.7.4:
>
> Network UPS Tools - UPS driver controller 2.7.4
> Network UPS Tools - Generic HID driver 0.41 (2.7.4)
> USB communication driver 0.33
> Using subdriver: Belkin/Liebert HID 0.17
>
> battery.charge: 100
> battery.charge.low: 38
> battery.charge.warning: 38
> battery.type: PbAc
> battery.voltage: 13.9
> battery.voltage.nominal: 12.0
> device.mfr: Emerson Network Power
> device.model: LiebertPSA
> device.serial:
> device.type: ups
> driver.name: usbhid-ups
> driver.parameter.bus: 001
> driver.parameter.pollfreq: 30
> driver.parameter.pollinterval: 2
> driver.parameter.port: auto
> driver.parameter.productid: 0001
> driver.parameter.synchronous: no
> driver.parameter.vendorid: 10AF
> driver.version: 2.7.4
> driver.version.data: Belkin/Liebert HID 0.17
> driver.version.internal: 0.41
> input.frequency: 50.0
> input.voltage: 221.8
> output.voltage: 222.6
> ups.load: 8
> ups.mfr: Emerson Network Power
> ups.model: LiebertPSA
> ups.productid: 0001
> ups.serial:
> ups.status: OL CHRG
> ups.vendorid: 10af
>
> Regards,
>
> Juan Carlos
>
> On Wed, Mar 20, 2024 at 4:22 PM Jim Klimov 
> wrote:
>
>> Hello,
>>
>>   For clarity: what changed with the move from NUT v2.7.4 to 2.8.0 - the
>> warnings "became reported", or the highlighted values became zeroes (and
>> were valid non-zero numbers with older NUT - so a regression)?
>>
>>   It seems the message is specific to the subdriver and comes from commit
>> 207fed2282 and a change to the method involved was just recently
>> experimentally proposed in
>> https://github.com/networkupstools/nut/issues/2271 discussion comments
>> (refinement to consider merging as a pull request pending).
>>
>> Thanks,
>> Jim
>>
>> On Wed, Mar 20, 2024 at 3:33 PM Juan Carlos Fischer via Nut-upsuser <
>> nut-upsuser@alioth-lists.debian.net> wrote:
>>
>>> Hello everyone
>>>
>>> I'm using: Raspberry Pi 4 Model B Rev 1.5  8 GB "Debian GNU/Linux 12
>>> (bookworm)"
>>>
>>> It all started when I updated from version 2.7.4 to version 2.8.0 and
>>> the consequences were the following:
>>>
>>> pi@raspberrypi:~ $ sudo upsdrvctl start
>>>
>>> Network UPS Tools - UPS driver controller 2.8.0
>>> Network UPS Tools - Generic HID driver 0.47 (2.8.0)
>>> USB communication driver (libusb 1.0) 0.43
>>> Using subdriver: Belkin/Liebert HID 0.18
>>> LineVoltage exponent looks wrong, but not correcting.
>>> LineVoltage exponent looks wrong, but not correcting.
>>> LineVoltage exponent looks wrong, but not correcting.
>>> ConfigVoltage exponent looks wrong, but not correcting.
>>>
>>> pi@raspberrypi:~ $ upsc Liebert
>>>
>>> Init SSL without certificate database
>>> battery.charge: 100
>>> battery.charge.low: 38
>>> battery.charge.warning: 38
>>> battery.type: PbAc
>>>
>>> *battery.voltage: 0.0  >>  <--*
>>> device.mfr: Emerson Network Power
>>> device.model: LiebertPSA
>>> device.serial:
>>> device.type: ups
>>> driver.name: usbhid-ups
>>> driver.parameter.bus: 001
>>> driver.parameter.pollfreq: 30
>>> driver.parameter.pollinterval: 15
>>> driver.parameter.port: auto
>>> driver.parameter.productid: 0001
>>> driver.parameter.synchronous: auto
>>> driver.parameter.vendorid: 10AF
>>> driver.version: 2.8.0
>>> driver.version.data: Belkin/Liebert HID 0.18
>>> driver.version.internal: 0.47
>>> driver.version.usb: libusb-1.0.26 (API: 0x1000109)
>>> input.frequency: 49.9
>>>
>>> *input.voltage: 0.0  <---output.voltage: 0.0
>>>  <--*
>>> ups.load: 9
>>> ups.mfr: Emerson Network Power
>>> ups.model: LiebertPSA
>>> ups.productid: 0001
>>> ups.serial:
>>> ups.status: OL CHRG
>>> ups.vendorid: 10af
>>>
>>> Except for those marked, all values are correct.
>>>
>>> Any help would be appreciated.
>>>
>>> Regards,
>>>
>>> Juan Carlos
>>>
>>> ___
>>> Nut-upsuser mailing list
>>> Nut-upsuser@alioth-lists.debian.net
>>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>>>
>>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] There is no voltage information

[Jim Klimov via Nut-upsuser]

Hello,

  For clarity: what changed with the move from NUT v2.7.4 to 2.8.0 - the
warnings "became reported", or the highlighted values became zeroes (and
were valid non-zero numbers with older NUT - so a regression)?

  It seems the message is specific to the subdriver and comes from commit
207fed2282 and a change to the method involved was just recently
experimentally proposed in
https://github.com/networkupstools/nut/issues/2271 discussion comments
(refinement to consider merging as a pull request pending).

Thanks,
Jim

On Wed, Mar 20, 2024 at 3:33 PM Juan Carlos Fischer via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:

> Hello everyone
>
> I'm using: Raspberry Pi 4 Model B Rev 1.5  8 GB "Debian GNU/Linux 12
> (bookworm)"
>
> It all started when I updated from version 2.7.4 to version 2.8.0 and the
> consequences were the following:
>
> pi@raspberrypi:~ $ sudo upsdrvctl start
>
> Network UPS Tools - UPS driver controller 2.8.0
> Network UPS Tools - Generic HID driver 0.47 (2.8.0)
> USB communication driver (libusb 1.0) 0.43
> Using subdriver: Belkin/Liebert HID 0.18
> LineVoltage exponent looks wrong, but not correcting.
> LineVoltage exponent looks wrong, but not correcting.
> LineVoltage exponent looks wrong, but not correcting.
> ConfigVoltage exponent looks wrong, but not correcting.
>
> pi@raspberrypi:~ $ upsc Liebert
>
> Init SSL without certificate database
> battery.charge: 100
> battery.charge.low: 38
> battery.charge.warning: 38
> battery.type: PbAc
>
> *battery.voltage: 0.0    <--*
> device.mfr: Emerson Network Power
> device.model: LiebertPSA
> device.serial:
> device.type: ups
> driver.name: usbhid-ups
> driver.parameter.bus: 001
> driver.parameter.pollfreq: 30
> driver.parameter.pollinterval: 15
> driver.parameter.port: auto
> driver.parameter.productid: 0001
> driver.parameter.synchronous: auto
> driver.parameter.vendorid: 10AF
> driver.version: 2.8.0
> driver.version.data: Belkin/Liebert HID 0.18
> driver.version.internal: 0.47
> driver.version.usb: libusb-1.0.26 (API: 0x1000109)
> input.frequency: 49.9
>
> *input.voltage: 0.0  <---output.voltage: 0.0  <--*
> ups.load: 9
> ups.mfr: Emerson Network Power
> ups.model: LiebertPSA
> ups.productid: 0001
> ups.serial:
> ups.status: OL CHRG
> ups.vendorid: 10af
>
> Except for those marked, all values are correct.
>
> Any help would be appreciated.
>
> Regards,
>
> Juan Carlos
>
> ___
> Nut-upsuser mailing list
> Nut-upsuser@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

[Nut-upsuser] Considering a release

[Jim Klimov via Nut-upsuser]

Hello all,

  By some criteria (like known squashed bugs and regressions, or added
features) it is always high time to cut a NUT release, even if backlog and
pending nice-to-haves are looming well over horison. Missed 29.2. "the
neverday issue", but upcoming 3.14. "pi day" also looks like a fun date to
push current code out for a newer public baseline and collect feedback.

  WDYT? Is there any known severe breakage on master?

Jim Klimov
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] NUT 2.8.1 build from source - upssched missing

[Jim Klimov via Nut-upsuser]

That is odd.

I suppose you ran not quite "autogen.sh, make, make install" but
"autogen.sh, *configure*, make, make install", with the "configure" part
taking a ton of options to tune for your system. There are no particular
options for `upssched`, or put another way, at least it would get built
along with `upsmon`.

Hope this helps,
Jim Klimov


On Sun, Mar 3, 2024 at 5:32 PM Dan Grostick via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:

> PI OS - Debian12 - Raspberry PI 5 NUT 2.8.1
>
> I'm building from source just downloaded from GITHUB.
>
> The error when starting NUT:
>
> * nut-monitor:  /usr/sbin/upssched not found*
>
> I did a 'find / ' and upssched is not in the filesystem.
> I've done a make clean, make uninstall.
> then autogen.sh, make, make install
>
>
>1.  is there an option to make that completely removes everything? In
>case there is some leftovers...
>2.  what am I missing?
>
>
> Dan
> ___
> Nut-upsuser mailing list
> Nut-upsuser@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] NUT help request

[Jim Klimov via Nut-upsuser]

To me, this line is suspect:

libusb1: Could not open any HID devices: insufficient permissions on everything


it seems like USB permissions on the host do not allow the NUT run-time
user (nutty?) to own the device filesystem node.
Check the upower/udev/... settings relevant there.

According to Git, this ID should be known in NUT v2.8.0 or newer (so the
rest is about OS integration for this bit):

$ git blame v2.8.0 scripts/upower/95-upower-hid.hwdb | grep usb:v0764p0601
8b72ac9fc2 (Benjamin Berg2022-03-28 17:19:41 +0200 103) usb:v0764p0601*

Hope this helps,
Jim Klimov



On Wed, Feb 28, 2024 at 1:23 PM Giacomo Tognetti via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:

> Hi guys
> I just struggling to configure my EPYC Neon UPS (it appears like Cyber
> Power System, Inc. PR1500LCDRT2U UPS) using NUT on my Home Assistant server.
> I installed official NUT from HACS add-ons and I placed a very easy config:
>
> users:
>   - username: nutty
> password: 
> instcmds:
>   - all
> actions: []
> devices:
>   - name: neon
> driver: usbhid-ups
> port: auto
> config: []
> mode: netserver
> shutdown_host: false
> list_usb_devices: true
>
> But it doesn’t work, even if UPS is actually listed, as you can see from
> the complete log.
>
> s6-rc: info: service s6rc-oneshot-runner: starting
> s6-rc: info: service s6rc-oneshot-runner successfully started
> s6-rc: info: service base-addon-banner: starting
> --- Add-on: Network 
> UPS Tools Manage battery backup (UPS) 
> devices--- Add-on 
> version: 0.13.0 You are running the latest version of this add-on. System: 
> Home Assistant OS 11.5  (amd64 / qemux86-64) Home Assistant Core: 2024.2.3 
> Home Assistant Supervisor: 
> 2024.02.0--- Please, 
> share the above information when looking for help or support in, e.g., 
> GitHub, forums or the Discord 
> chat.---
> s6-rc: info: service base-addon-banner successfully started
> s6-rc: info: service fix-attrs: starting
> s6-rc: info: service base-addon-timezone: starting
> s6-rc: info: service base-addon-log-level: starting
> s6-rc: info: service fix-attrs successfully started
> [15:30:13] INFO: Configuring timezone (Europe/Rome)...
> s6-rc: info: service base-addon-log-level successfully started
> s6-rc: info: service base-addon-timezone successfully started
> s6-rc: info: service legacy-cont-init: starting
> cont-init: info: running /etc/cont-init.d/nut.sh
> [15:30:16] INFO: Setting mode to netserver...
> [15:30:16] INFO: Connected USB devices:
> Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> Bus 002 Device 003: ID 10c4:ea60 Silicon Labs CP210x UART Bridge
> Bus 002 Device 002: ID 0764:0601 Cyber Power System, Inc. PR1500LCDRT2U UPS
> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd QEMU Tablet
> Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> [15:30:17] INFO: Generating /etc/nut/upsd.users...
> [15:30:17] INFO: Configuring user: nutty
> [15:30:17] INFO: Password is NOT in the Have I Been Pwned database! Nice!
> [15:30:18] INFO: Configuring Device named neon...
> [15:30:18] INFO: Starting the UPS drivers...
> Network UPS Tools - Generic HID driver 0.47 (2.8.0)
> USB communication driver (libusb 1.0) 0.43
> libusb1: Could not open any HID devices: insufficient permissions on 
> everything
> No matching HID UPS found
> Driver failed to start (exit status=1)
> Network UPS Tools - UPS driver controller 2.8.0
> cont-init: info: /etc/cont-init.d/nut.sh exited 1
> cont-init: info: running /etc/cont-init.d/nutclient.sh
> cont-init: info: /etc/cont-init.d/nutclient.sh exited 0
> cont-init: warning: some scripts exited nonzero
> s6-rc: warning: unable to start service legacy-cont-init: command exited 1
> /run/s6/basedir/scripts/rc.init: warning: s6-rc failed to properly bring all 
> the services up! Check your logs (in /run/uncaught-logs/current if you have 
> in-container logging) for more information.
> /run/s6/basedir/scripts/rc.init: fatal: stopping the container.
> s6-rc: info: service fix-attrs: stopping
> s6-rc: info: service base-addon-timezone: stopping
> s6-rc: info: service base-addon-log-level: stopping
> s6-rc: info: service fix-attrs successfully stopped
> s6-rc: info: service base-addon-timezone successfully stopped
> s6-rc: info: service base-addon-log-level successfully stopped
> s6-rc: info: service base-addon-banner: stopping
> s6-rc: info: service base-addon-banner successfully stopped
> s6-rc: info: service s6rc-oneshot-runner: stopping
> s6-rc: info: service s6rc-oneshot-runner successfully stopped
>
>
>
> I tried to add vendorid (764) and producid (601, in my case) but results
> are the same.
>
> I really need your help, also 

Re: [Nut-upsuser] System keeps going into FSD mode after power on

[Jim Klimov via Nut-upsuser]

Hello,

  Hard to say for sure, devices are all different. But from general
experience, some thoughts may be relevant:

1) I've seen some UPSes return different battery charge levels or remaining
runtimes when they are running off wall power or just after switching to
battery. It may be that some other circuit kicks in for measurements, or
the voltage reported by the battery drops when it is actually under load,
etc. So double-check if your 90% threshold is not passed by just getting
into the ONBATT state.

2) Regarding FSD after boot, I've mostly seen such behavior with
enterprise-level UPSes which have their own alert mechanisms and NUT is a
subscribed client to those (e.g. netxml drivers), but the general idea
probably applies with the high thresholds you've set here: the goal of an
UPS is to protect your servers' data, in the end, by not letting them lose
power abruptly. If your setup says you need 1000 seconds or 90% of the
battery to diligently shut down, anything below that is unsafe to run with.
If you had a real outage, started up the rack, and had another outage while
the battery is still drained - servers could lose the power suddenly and
corrupt their databases or whatever. For that matter, UPSes with such
threshold configurations backed by hardware controllers do not even start
the load until sufficiently charged (so you have service downtime for, say,
an hour after wall power gets repaired - but that delay may be cheaper than
repairing the data in the worse case).

One known hack around that is to use a SHUTDOWNCMD which is a script, not
directly a call to the shutdown program. This script would check for some
touch-file in a location of your choosing (probably in a tmpfs), or for
larger racks, maybe `curl` it from some shared web-service, LDAP, etc. --
and abort if the flag's presence says "Admins know what they are doing, do
not actually shut down!" or proceed with the shut down if the flag is
absent. This allows them to turn on the servers quickly after an outage
while they are monitored by personnel, or follow a safe shutdown/restart
routine if nobody is around.

Hope this helps,
Jim Klimov



On Thu, Feb 22, 2024 at 12:10 AM Andrei Zmievski via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:

> Hello,
>
> I am a new user of NUT and trying to wrap my ahead around a couple of
> things. I installed NUT 2.7.4-13 from package on RasPi 4, running Raspbian
> Linux 11 (bullseye). I have Cyberpower SL700U connected to it. For
> testing I set battery.charge.low to 90, so I wouldn't have to wait a long
> time. See all relevant config below.
>
> First of all, what seems to happen is that UPS gets to the low battery
> state and the system immediately goes into the shutdown, not letting the
> 30s timer specified in upssched.conf fire. Here's the syslog:
>
> Feb 21 20:54:11 berry upsmon[1462]: UPS cyberpower@localhost battery is
> low
> Feb 21 20:54:11 berry upsd[1459]: Client monserver@127.0.0.1 set FSD on
> UPS [cyberpower]
> Feb 21 20:54:11 berry upssched[1712]: New timer: shutdowncritical (30
> seconds)
> Feb 21 20:54:19 berry upsmon[1462]: Executing automatic power-fail shutdown
> Feb 21 20:54:19 berry upsmon[1462]: Auto logout and shutdown proceeding
>
> Then, I connected the UPS to wall power and reset power on RasPi. After
> boot-up it seemed to see low battery state (even though on wall power) and
> fired off the 'shutdowncritical' timer, which after 30 seconds, issued the
> FSD command and the system shut down again.
>
> Feb 21 20:54:55 berry upsmon[758]: Startup successful
> Feb 21 20:54:55 berry upsmon[759]: Init SSL without certificate database
> Feb 21 20:54:55 berry upsd[756]: User monserver@127.0.0.1 logged into UPS
> [cyberpower]
> Feb 21 20:54:55 berry upsmon[759]: UPS cyberpower@localhost battery is low
> Feb 21 20:54:55 berry upssched[766]: Timer daemon started
> Feb 21 20:54:55 berry upssched[766]: New timer: shutdowncritical (30
> seconds)
> Feb 21 20:54:56 berry upsd[756]: User monclient@192.168.11.180 logged
> into UPS [cyberpower]
> Feb 21 20:55:25 berry upssched[766]: Event: shutdowncritical
> Feb 21 20:55:25 berry upssched-cmd[793]: Calling upssched-cmd
> shutdowncritical
> Feb 21 20:55:25 berry upsmon[759]: Signal 10: User requested FSD
> Feb 21 20:55:25 berry upsd[756]: Client monserver@127.0.0.1 set FSD on
> UPS [cyberpower]
> Feb 21 20:55:27 berry upssched-cmd[800]: UPS battery critically low,
> forced shutdown. [OL CHRG LB]:82%
> Feb 21 20:55:31 berry upsmon[759]: Executing automatic power-fail shutdown
> Feb 21 20:55:31 berry upsmon[759]: Auto logout and shutdown proceeding
> Feb 21 20:55:36 berry upsd[756]: mainloop: Interrupted system call
> Feb 21 20:55:36 berry upsd[756]: Signal 15: exiting
>
> How come it reacts to the LB state when the UPS is on wall power? I know I
> manually reset the power on the RasPi, but wouldn't the same happen if UPS
> was shut off and then regained power? Do I need to modify my upssched-cmd
> script to not react to LOWBATT 

Re: [Nut-upsuser] Compile/Package / Config/Run 2.8.1 / Raspberry / UPS

[Jim Klimov via Nut-upsuser]

Hello, and thanks for the detailed report.

  Regarding /var/run/nut - I think `systemd-tmpfiles --create` should have
taken care of this. Can you check if your tarball "package" actually
shipped a /usr/lib/tmpfiles.d/nut-common-tmpfiles.conf file, and does it
list (/var)/run/nut among the items it tracks? On the build system, would
`grep PATH= config.log` reveal anything? (I suspect the PIDPATH could be
defaulted as `(/var)/run` without the `.../nut` suffix)

  Regarding run-time configurations, you did not specify a
`--sysconfdir=/etc/nut` so it defaults to using an `etc` dir under the
`--prefix` which is also defaulted in your case:

nut-scanner -qUN > /etc/nut/ups.conf
...
Mon 19 Feb 2024 03:06:21 AM UTC : OK: No more changes to reconcile between
systemd service instances and device configurations
  in '/usr/local/ups/etc/ups.conf'

   I wonder how it finds *something* to claim a "nutdev" configuration,
though. Is there something actually written into
/usr/local/ups/etc/ups.conf or is NUT hallucinating (sounds trendy this
year, maybe it grew an AI too?) :)

> [Do I also need: "--enable-inplace-runtime"?]

  If you had a previous installation of NUT, perhaps a package, this option
helps the `configure` script auto-detect other options like paths and user
names for your new build to be a functional replacement of the old one. In
particular, this helps with testing of new program iterations right from
the build workspace using the same system-wide configs.

Jim



On Mon, Feb 19, 2024 at 4:51 AM Bruce Pleat via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:

> I'm trying to Compile/Package and then (on a different box) Config/Run
> 2.8.1. Both boxes are Raspberry Pi 4b on Bullseye with a generic USB UPS.
>
> --
>
> I'm trying to get nut running on my Raspberry (bullseye/11).  (I'd also
> love to share a working 2.8.1 for Raspberry with the world, but...)
>
> I compiled the latest code from git: version 2.8.1-774-g963abbd87
> I compiled it on one system that does NOT have a UPS, to "package" for my
> three other UPS-monitoring systems.
>
> Here's the general history/steps.
>
> (Note: In some places, I did repeat prior steps in different orders, but
> did not take detailed notes of every last diagnostic effort...)
>
> (Note: Anywhere I put a semicolon, I did each command separately, but am
> simplifying here)
> (Note: For each step, I can cite where I found it if desired)
>
> [The next four are just general info, not specific to this build]
> [Installed VS Code on my RPi 4 - 8GB if relevant]
> [Changed "disable-hardware-acceleration": true]
> [Git clone: https://github.com/networkupstools/nut/]
> [Installed a bunch of VS Code plugins/addins/whatevers]
>
> [Installed desired-feature prerequisites:] [Note: I did the "configure"
> step repeatedly, looked at errors, and then "apt-get install" for needed
> items, so I did run it several times...]
> apt-get install ccache time git python perl curl make autoconf automake
> libltdl-dev libtool valgrind cppcheck pkg-config gcc g++ clan libtool-bin
> libxml2-utils xsltproc asciidoc libusb-1.0-0-dev libusb-dev libsystemd-dev
> python3-systemd
> ./autogen.sh
> ./configure
> ./configure --enable-dependency-tracking --enable-strip --with-nutconf
> --with-usb --with-nut-monitor --with-nut-scanner --with-libsystemd
> --with-doc --enable-strip --with-ssl=NO --with-openssl=NO --with-user=ups
> --with-group=nut
> [Do I also need: "--enable-inplace-runtime"?]
> make DESTDIR=/tmp/package install
> make DESTDIR=/tmp/package install-conf
> [Not sure if needed for Package system, but I did:] mkdir -p
> /var/state/ups; chmod 0770 /var/state/ups; chown root:nut /var/state/ups
> make all; make; make check; make spellcheck
> [Then, since I realized that might not be sufficient for packaging, redid
> as follows:]
> make all; make DESTDIR=/tmp/package install; make DESTDIR=/tmp/package
> install-conf; cd conf; make DESTDIR=/tmp/package install; make
> DESTDIR=/tmp/package install-conf ; make install; cd ..; make; make check
> && make spellcheck
> [Then tar -compress- it up to move to my desired "run" system]
>
> [Then, of course tar -expand- on run system]
> [On the run system]:
> useradd ups; groupadd nut
> [Also added user "ups" to group "nut":] usermod -a -G nut ups]
>
>
> mkdir -p /var/state/ups
> chmod 0770 /var/state/ups
> chown root:nut /var/state/ups
>
> [Copied man pages and reindexed, though not relevant here]
>
> [Then copied / linked from my tar folder as follows]
> cp bin/* /bin
> ln -s /usr/local/ups/etc /etc/nut
> md /lib/ups; cp lib/* /lib/ups/
> cp libexec/* /usr/libexec
> cp sbin /sbin/
> ln -s /usr/local/ups/lib /lib/ups
>
> [Configuration details...]
>
> [Why reinvent the wheel and risk a problem?]
> nut-scanner -qUN > /etc/nut/ups.conf
>
> [Configuration of /etc/nut/ups.conf becomes:]
> [nutdev-usb1]
> driver = "usbhid-ups"
> port = "auto"
> vendorid = "0764"
> productid = "0501"
> product = "SL Series"
> vendor = "CPS"
> # bus = "001"
> # device = "049"

Re: [Nut-upsuser] Keeping the traffis on or off the list ?

[Jim Klimov via Nut-upsuser]

I sometimes get replies that are directed only to me.

Oftentimes it is a sender "error" to not have used Reply to All, so I
direct my response back to the list. Rarely it is about something the
senders deem confidential, where a pointed reply seems to make sense
(overriding would be bad).

Other than that, I think the mailing list service we get from alioth comes
"as is", not sure we can configure much about it. Can check, but not really
inclined to - let humans decide how to best post and what is correct for
each case :)

Jim


On Sat, Feb 17, 2024 at 9:32 AM Roger Price via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:

> I recently wrote to the list.  The distributed message had the following
> headers:
>
> > Date: Fri, 16 Feb 2024 19:22:59 +0100 (CET)
> > From: Roger Price via Nut-upsuser 
> > Reply-To: Roger Price 
> > To: nut-upsuser Mailing List 
> > Subject: ...
>
> Note that the Reply-To goes back to the original poster, not the list.
> Many mailing lists encourage the subscribers to "keep the list traffic on
> the
> list", rather than wandering off into private discussions.  The
> nut-upsuser
> setup has exactly the opposite effect.
>
> Is it the intention to send the subscibers into private conversation?  If
> not,
> and I suspect not, then the current Reply-To looks like a bug.
>
> Any replies to the list please.  Roger
>
> ___
> Nut-upsuser mailing list
> Nut-upsuser@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Can't claim USB device: Invalid parameter

[Jim Klimov via Nut-upsuser]

Hello, thanks for the details although I too am not sure about the "invalid
parameter" - got neither reasons nor solutions at the moment.

Regarding the "device: unknown", there was an issue in the USB matcher code
that did not let the driver "remember" the value it saw from libusb (and so
it could not match if the desired value was requested in ups.conf). That
was fixed in NUT v2.8.1; however, given the inherent unreliability of these
numbers (dependent on hotplug events, USB ports used and presence of other
devices, etc.), nut-scanner would not suggest them to be part of the driver
configuration section by default starting with NUT v2.8.2 (and current
master already).

Your config did not mention these link-specific numbers, so I think it
should not be the problem in your case.

Jim



On Wed, Feb 7, 2024 at 10:09 PM Jason Doolittle 
wrote:

> I think I have another lead:
>
> For the Powervar, lsusb gives:
>
> Bus 003 Device 002: ID 4234:0002 AMETEK-POWERVAR Corporation UPM UPS
> (v01.51, Nov  3 2018)
> When running usbhid-ups from the command line, I get:
>
> 0.035977 [D2] - Bus: 003
> 0.035989 [D2] - Device: unknown
>
> So is it passing "unknown" as the device number to libusb instead of 002?
>
> On Wed, Feb 7, 2024, at 3:54 PM, Jason Doolittle wrote:
>
> Hello,
>
> Thanks for your reply.
>
> Both of the services you mentioned (nut-driver@PowervarUPS01.service and
> nut-driver@APCUPS01.service) were running. They were spamming syslog with
> messages like the following:
>
> 2024-02-07T14:29:27.704506-05:00 hostname nut-driver@PowervarUPS01[72162]:
> Network UPS Tools - Generic HID driver 0.47 (2.8.0)
>
> 2024-02-07T14:29:27.704537-05:00 hostname nut-driver@PowervarUPS01[72162]:
> USB communication driver (libusb 1.0) 0.43
>
> 2024-02-07T14:29:27.704873-05:00 hostname nut-driver@PowervarUPS01[72161]:
> Driver failed to start (exit status=1)
>
> 2024-02-07T14:29:32.718262-05:00 hostname nut-driver@PowervarUPS01[72167]:
> Can't claim USB device [4234:0002]@1/0: Invalid parameter
>
> 2024-02-07T14:29:32.718386-05:00 hostname nut-driver@PowervarUPS01[72167]:
> Network UPS Tools - Generic HID driver 0.47 (2.8.0)
>
> 2024-02-07T14:29:32.718422-05:00 hostname nut-driver@PowervarUPS01[72167]:
> USB communication driver (libusb 1.0) 0.43
>
> 2024-02-07T14:29:32.718684-05:00 hostname nut-driver@PowervarUPS01[72161]:
> Driver failed to start (exit status=1)
>
> 2024-02-07T14:29:32.718829-05:00 hostname nut-driver@APCUPS01[72166]:
> Can't claim USB device [051d:0002]@1/0: Invalid parameter
>
> After stopping those services I ran the driver again from the CLI with the
> same result. That "Invalid parameter" is conspicuous. I haven't seen it in
> anyone else's questions or answers. The only place i've seen it in relation
> to this problem is in libusb1.c (on github), but not in a way that makes it
> obvious how to track down the cause. I suspect some sort of version or
> parameter mismatch somewhere in libusb, but I have no idea how to test for
> that.
>
>
> On Wed, Feb 7, 2024, at 12:57 PM, Jim Klimov wrote:
>
> Hello and welcome!
>
>   My guess would be that a nut-driver service unit (or instances thereof
> since NUT v2.8.0, monolithic before) have started and captured the devices,
> so your attempts with another copy of the driver started from CLI fail at
> that. Normally drivers detect an older sibling running (by poking a PID
> file), but service units may forgo creation of one. (Since 2.8.1 they can
> also try to use driver-server protocol locally.)
>
>   Since NUT v2.8.0 there is a nut-driver-enumerator (script and service)
> which manages creation, deletion and reloading/restarting of unit instances
> based on ups.conf contents (start-up) or changes (run-time). Check if you
> have `nut-driver@PowervarUPS01.service` (and `...@APCUPS01`) there to fit
> this bill? If yes, then to experiment with CLI copies of drivers,
> `systemctl stop` such unit(s).
>
> Hope this helps,
> Jim Klimov
>
>
> On Wed, Feb 7, 2024, 14:48 Jason Doolittle 
> wrote:
>
> I am working in Ubuntu Linux on a Raspberry Pi 5. Nut is unable to connect
> to USB UPSs.
>
> uname -srvmpio
> Linux 6.5.0-1009-raspi #12-Ubuntu SMP PREEMPT_DYNAMIC Wed Jan 17 11:45:08
> UTC 2024 aarch64 aarch64 aarch64 GNU/Linux
>
> Current Installed version of nut is 2.8.0-7 installed with apt
>
> apt-cache policy nut
> nut:
>   Installed: 2.8.0-7
>   Candidate: 2.8.0-7
>   Version table:
> *** 2.8.0-7 500
> 500 http://ports.ubuntu.com/ubuntu-ports mantic/main arm64
> Packages
> 100 /var/lib/dpkg/status
>
> I currently have 2 UPSs connected to the system
> A Powervar UPM UPS
> Bus 003 Device 002: ID 4234:0002 AMETEK-POWERVAR Corporation UPM UPS
> (v01.51, Nov  3 2018)
>
> An APC Back-UPS Pro 1500
> Bus 001 Device 002: ID 051d:0002 American Power Conversion Uninterruptible
> Power Supply
>
> It appears that the all of the permissions were set up correctly during
> installation. The nut user and group were created and the usb devices have
> the correct 

Re: [Nut-upsuser] Can't claim USB device: Invalid parameter

[Jim Klimov via Nut-upsuser]

Hello and welcome!

  My guess would be that a nut-driver service unit (or instances thereof
since NUT v2.8.0, monolithic before) have started and captured the devices,
so your attempts with another copy of the driver started from CLI fail at
that. Normally drivers detect an older sibling running (by poking a PID
file), but service units may forgo creation of one. (Since 2.8.1 they can
also try to use driver-server protocol locally.)

  Since NUT v2.8.0 there is a nut-driver-enumerator (script and service)
which manages creation, deletion and reloading/restarting of unit instances
based on ups.conf contents (start-up) or changes (run-time). Check if you
have `nut-driver@PowervarUPS01.service` (and `...@APCUPS01`) there to fit
this bill? If yes, then to experiment with CLI copies of drivers,
`systemctl stop` such unit(s).

Hope this helps,
Jim Klimov


On Wed, Feb 7, 2024, 14:48 Jason Doolittle 
wrote:

> I am working in Ubuntu Linux on a Raspberry Pi 5. Nut is unable to connect
> to USB UPSs.
>
> uname -srvmpio
> Linux 6.5.0-1009-raspi #12-Ubuntu SMP PREEMPT_DYNAMIC Wed Jan 17 11:45:08
> UTC 2024 aarch64 aarch64 aarch64 GNU/Linux
>
> Current Installed version of nut is 2.8.0-7 installed with apt
>
> apt-cache policy nut
> nut:
>   Installed: 2.8.0-7
>   Candidate: 2.8.0-7
>   Version table:
> *** 2.8.0-7 500
> 500 http://ports.ubuntu.com/ubuntu-ports mantic/main arm64
> Packages
> 100 /var/lib/dpkg/status
>
> I currently have 2 UPSs connected to the system
> A Powervar UPM UPS
> Bus 003 Device 002: ID 4234:0002 AMETEK-POWERVAR Corporation UPM UPS
> (v01.51, Nov  3 2018)
>
> An APC Back-UPS Pro 1500
> Bus 001 Device 002: ID 051d:0002 American Power Conversion Uninterruptible
> Power Supply
>
> It appears that the all of the permissions were set up correctly during
> installation. The nut user and group were created and the usb devices have
> the correct ownership and permissions set per the udev rules
>
> For the Powervar:
> crw-rw-r-- 1 root nut 189, 257 Feb  7 06:42 /dev/bus/usb/003/002
>
> For the APC:
> crw-rw-r-- 1 root nut 189, 1 Feb  7 06:42 /dev/bus/usb/001/002
>
> In ups.conf, I have this:
>
> [PowervarUPS01]
> driver = "usbhid-ups"
> port = "auto"
> vendorid = "4234"
> productid = "0002"
>
> [APCUPS01]
> driver = "usbhid-ups"
> port = "auto"
> vendorid = "051D"
> productid = "0002"
>
> The UPSs are matched, but drivers continuously fail to start. Here is the
> output from running the usbhid-ups driver manually for the Powervar:
>
> sudo /usr/lib/nut/usbhid-ups -u root -a PowervarUPS01 -DD
>
> Network UPS Tools - Generic HID driver 0.47 (2.8.0)
> USB communication driver (libusb 1.0) 0.43
>0.00 [D1] debug level is '2'
>0.001191 [D2] Initializing an USB-connected UPS with library
> libusb-1.0.26 (API: 0x1000109) (NUT subdriver name='USB communication
> driver (libusb 1.0)' ver='0.43')
>0.001209 [D1] upsdrv_initups (non-SHUT)...
>0.006358 [D2] Checking device 1 of 6 (1D6B/0003)
>0.006385 [D1] Failed to open device (1D6B/0003), skipping: Access
> denied (insufficient permissions)
>0.006393 [D2] Checking device 2 of 6 (4234/0002)
>0.007354 [D2] - VendorID: 4234
>0.007364 [D2] - ProductID: 0002
>0.007371 [D2] - Manufacturer: AMETEK-POWERVAR Corporation
>0.007378 [D2] - Product: UPM UPS (v01.51, Nov  3 2018)
>0.007385 [D2] - Serial Number: 5008094R-1940438
>0.007395 [D2] - Bus: 003
>0.007402 [D2] - Device: unknown
>0.007409 [D2] - Device release number: 0002
>0.007418 [D2] Trying to match device
>0.007425 [D2] match_function_subdriver (non-SHUT mode): matching a
> device...
>0.007485 [D2] Device matches
>0.007497 [D2] Reading first configuration descriptor
>0.007505 [D2] result: -5 (Entity not found)
>0.007517 [D2] failed to claim USB device: Entity not found
>0.007529 [D1] failed to detach kernel driver from USB device: Invalid
> parameter
>0.007539 [D2] failed to claim USB device: Entity not found
>0.007549 [D1] failed to detach kernel driver from USB device: Invalid
> parameter
>0.007560 [D2] failed to claim USB device: Entity not found
>0.007574 [D1] failed to detach kernel driver from USB device: Invalid
> parameter
>0.007582 [D2] failed to claim USB device: Entity not found
>0.007594 [D1] failed to detach kernel driver from USB device: Invalid
> parameter
>0.007604 Can't claim USB device [4234:0002]@1/0: Invalid parameter
>
> I get basically the same from the APC.
>
> I think the "failed to detach kernel driver from USB device: Invalid
> parameter" is the key here, especially the "Invalid parameter" part, but
> after a few hours of poking at things, I haven't made any progress.
>
> I would be eternally grateful if someone could point me in the right
> direction.
>
> ___
> Nut-upsuser mailing list
> Nut-upsuser@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
>

Re: [Nut-upsuser] NUT and Eaton UPS produce a lot of error messages

[Jim Klimov via Nut-upsuser]

tefan Schumacher <
> stefanschumacheratw...@gmail.com> wrote:
>
>> Hello Jim,
>>
>> I am away from home visiting a friend until tomorrow but if you give
>> me a checklist of the information you need, I will gladly gather all
>> that I can find. My computer is not a Raspberry Pi although I own
>> several models of the little guys. My file server is simply my former
>> workstation (Skylake 6700K, 32 GB RAM, Broadcom 3008 HBA, Intel 10GBE
>> NIC). It runs all the time and never goes into suspend or
>> energy-saving mode.It has a btrfs-filesystem with 6 hard drives and
>> about 100TB Brutto capacity.
>>
>> This is the output I get when I plug the USB connection to the UPS on and
>> off:
>>
>> [120112.880346] usb 1-14: USB disconnect, device number 3
>> [120116.883552] usb 1-14: new full-speed USB device number 4 using
>> xhci_hcd
>> [120118.836528] usb 1-14: New USB device found, idVendor=0463,
>> idProduct=, bcdDevice= 1.00
>> [120118.836608] usb 1-14: New USB device strings: Mfr=1, Product=2,
>> SerialNumber=4
>> [120118.836657] usb 1-14: Product: Ellipse ECO
>> [120118.836687] usb 1-14: Manufacturer: EATON
>> [120118.836717] usb 1-14: SerialNumber: 0
>> [120122.114630] hid-generic 0003:0463:.0002: hiddev0,hidraw0: USB
>> HID v10.10 Device [EATON Ellipse ECO] on usb-:00:14.0-14/input0
>>
>> This is the output from the driver with nut-monitor and nut-server not
>> running:
>> root@mars:/usr/lib/nut# ./usbhid-ups -DD -a Eaton
>> Network UPS Tools - Generic HID driver 0.47 (2.8.0)
>> USB communication driver (libusb 1.0) 0.43
>>0.00 [D1] debug level is '2'
>>0.001288 [D2] Initializing an USB-connected UPS with library
>> libusb-1.0.26 (API: 0x1000109) (NUT subdriver name='USB communication
>> driver (libusb 1.0)' ver='0.43')
>>0.001295 [D1] upsdrv_initups (non-SHUT)...
>>0.004834 [D2] Checking device 1 of 7 (1D6B/0003)
>>0.004849 [D1] Failed to open device (1D6B/0003), skipping: Access
>> denied (insufficient permissions)
>>0.004854 [D2] Checking device 2 of 7 (0BDA/5452)
>>0.004860 [D1] Failed to open device (0BDA/5452), skipping: Access
>> denied (insufficient permissions)
>>0.004865 [D2] Checking device 3 of 7 (1D6B/0002)
>>0.004878 [D1] Failed to open device (1D6B/0002), skipping: Access
>> denied (insufficient permissions)
>>0.004882 [D2] Checking device 4 of 7 (1D6B/0003)
>>0.004888 [D1] Failed to open device (1D6B/0003), skipping: Access
>> denied (insufficient permissions)
>>0.004892 [D2] Checking device 5 of 7 (0463/)
>>0.417990 [D2] - VendorID: 0463
>>0.418048 [D2] - ProductID: 
>>0.418065 [D2] - Manufacturer: EATON
>>0.418082 [D2] - Product: Ellipse ECO
>>0.418103 [D2] - Serial Number: 0
>>0.418123 [D2] - Bus: 001
>>0.418141 [D2] - Device: unknown
>>0.418161 [D2] - Device release number: 0100
>>0.418183 [D2] Trying to match device
>>0.418204 [D2] match_function_subdriver (non-SHUT mode): matching a
>> device...
>>0.418394 [D2] Device matches
>>0.418416 [D2] Reading first configuration descriptor
>>0.418456 [D2] failed to claim USB device: Resource busy
>>0.418487 [D2] Kernel driver already detached
>>0.418512 [D2] failed to claim USB device: Resource busy
>>0.418546 [D2] Kernel driver already detached
>>0.418571 [D2] failed to claim USB device: Resource busy
>>0.418594 [D2] Kernel driver already detached
>>0.418619 [D2] failed to claim USB device: Resource busy
>>0.418643 [D2] Kernel driver already detached
>>0.418664 Can't claim USB device [0463:]@0/0: Entity not found
>>
>>
>> Yours sincerely
>> Stefan Schumacher
>>
>>
>> Am Sa., 20. Jan. 2024 um 12:03 Uhr schrieb Jim Klimov via Nut-upsuser
>> :
>> >
>> > Well, at least per issue tracker, they can be finicky especially
>> regarding reconnects (in many models, the USB controller tends to fall into
>> power-saving at the wrong times, so polling rates should be increased).
>> More on the Wiki and in github search/labels :)
>> >
>> > As for Eatons, I've had experience with many enterprise and some
>> home-oriented models (worked there for a while), and can't point to any
>> particular "systemic" flaws of the brand. Individual devices of course
>> could be randomly damaged in shop/transport/storage/..., but that's about
>> it.
>> >
>> > In this thread I haven't yet seen one clue or report tha

Re: [Nut-upsuser] NUT and Eaton UPS produce a lot of error messages

[Jim Klimov via Nut-upsuser]

Well, at least per issue tracker, they can be finicky especially regarding
reconnects (in many models, the USB controller tends to fall into
power-saving at the wrong times, so polling rates should be increased).
More on the Wiki and in github search/labels :)

As for Eatons, I've had experience with many enterprise and some
home-oriented models (worked there for a while), and can't point to any
particular "systemic" flaws of the brand. Individual devices of course
could be randomly damaged in shop/transport/storage/..., but that's about
it.

In this thread I haven't yet seen one clue or report that would be about
the actual UPS or its driver, or a dmesg dump about re-connections, if any
- so just have no founded opinion if the power device is or is not at any
fault. Likewise, I don't think I've seen any details about the fileserver's
hardware (e.g. Raspberry Pi's are often mentioned in issues nowadays, no
idea if that points to inherent issues of their hardware or just to their
popularity and higher chance-to-encounter in tinkering, though). All
bread-crumbs so far were about the data server (nut-server/upsd) and the
client (upsmon).

Jim


On Sat, Jan 20, 2024 at 2:03 AM Sam Varshavchik 
wrote:

> Stefan Schumacher via Nut-upsuser writes:
>
> > I am considering returning the device to the online shop I bought. As
> > it is, it's nothing but trouble. Can you recommend a small UPS (1
> > Server) that is guaranteed to work flawlessly with NUT?
>
> I've had good experience with Cyberpower units, as long as they're
> included
> NUT's hardware list.
>
> ___
> Nut-upsuser mailing list
> Nut-upsuser@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] NUT and Eaton UPS produce a lot of error messages

[Jim Klimov via Nut-upsuser]

One more idea, inspired by messages systemd sometimes gives:

* Select to "Copy" the timestamps of when e.g. your `nut-server.service`
stopped/restarted;
* As root(!) run `journalctl -xl` for a detailed log with service state
changes and reasons, and other details, piped into `less` by default
* Press `G` to scroll to the end (maybe wait a minute for it to react, if
you like me have months of active journal to sift through)
* Search up via `?` for the timestamp you've copied earlier
* Scroll a few screenfulls of text around (mostly before) to get a better
educated guess about why the restart happened (some failure of the NUT
daemon? some dependency change? system restart? sleep/hibernate/throttle?
OOM killer - this one would also be seen in `dmesg`? etc.)

Also check in `dmesg` if there are any USB events around that time (e.g.
UPS getting lost and reconnected)? If it does happen, check polling
frequency settings on one hand and maybe set up monitoring like MRTG to
correlate if the system could have been e.g. too busy at the moment, so
could not dedicate enough time to regular polls and assumed a timeout
(happened to me with a weak embedded device destined to monitor a dozen
UPSes, or so we hoped).

Good luck,
Jim


On Fri, Jan 19, 2024 at 8:35 PM Jim Klimov  wrote:

> > 1) How do I make the nut-server and nut-monitor find the right pid
> files? They are there but it seems they can't be opened. Permissions are
> nut/nut.
>
> Actually, if the preceding lifetime of the service was a graceful stop,
> the exiting daemon should have removed its PID files. Then the newly
> starting one would check and not find them - as I wrote before - to make
> sure there is no hung old competitor to kill off as part of the start-up.
> So works as is normal, just with scary messages (newer versions should be
> less cryptic about this).
>
> > Jan 19 16:14:52 mars nut-monitor[3781]: Init SSL without certificate
> database
>
> This means your NUT build is SSL-capable, but you did not configure it
> with certificates so it is using plaintext mode.
>
> > Jan 19 16:14:52 mars nut-monitor[3781]: Login on UPS [Eaton@localhost]
> failed - got [ERR ACCESS-DENIED]
>
> Given that in some messages posted earlier it works, and in some it is
> denied (soon after upsd startup), it is the most puzzling issue here (other
> than the service restarts which you did not post explanations about). I'd
> guess that it retried the connection too early somehow, if upsd is already
> listening but did not yet read all configuration. Not sure this should
> happen. Also might be if you have several MONITOR lines for the same
> device/server and some of them are wrong?
>
> Jim
>
>
> On Fri, Jan 19, 2024 at 6:33 PM Stefan Schumacher via Nut-upsuser <
> nut-upsuser@alioth-lists.debian.net> wrote:
>
>> I still have two questions:
>> 1) How do I make the nut-server and nut-monitor find the right pid
>> files? They are there but it seems they can't be opened. Permissions
>> are nut/nut.
>> 2) What do these error messages mean?
>> Jan 19 16:14:52 mars nut-monitor[3781]: Init SSL without certificate
>> database
>> Jan 19 16:14:52 mars nut-monitor[3781]: Login on UPS [Eaton@localhost]
>> failed - got [ERR ACCESS-DENIED]
>>
>> Yours sincerely
>> Stefan
>>
>> Am Fr., 19. Jan. 2024 um 17:59 Uhr schrieb Matus UHLAR - fantomas
>> :
>> >
>> > On 19.01.24 17:02, Stefan Schumacher via Nut-upsuser wrote:
>> > >Jan 19 05:50:13 mars nut-monitor[849]: Signal 15: exiting
>> >
>> > >Jan 19 05:50:17 mars nut-server[1303]: Signal 15: exiting
>> >
>> > this looks like someone repeatedly killed nut server. This not a
>> problem of
>> > UPS.
>> > --
>> > Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
>> > Warning: I wish NOT to receive e-mail advertising to this address.
>> > Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
>> > Atheism is a non-prophet organization.
>> >
>> > ___
>> > Nut-upsuser mailing list
>> > Nut-upsuser@alioth-lists.debian.net
>> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>>
>> ___
>> Nut-upsuser mailing list
>> Nut-upsuser@alioth-lists.debian.net
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>>
>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] NUT and Eaton UPS produce a lot of error messages

[Jim Klimov via Nut-upsuser]

> 1) How do I make the nut-server and nut-monitor find the right pid files?
They are there but it seems they can't be opened. Permissions are nut/nut.

Actually, if the preceding lifetime of the service was a graceful stop, the
exiting daemon should have removed its PID files. Then the newly starting
one would check and not find them - as I wrote before - to make sure there
is no hung old competitor to kill off as part of the start-up. So works as
is normal, just with scary messages (newer versions should be less cryptic
about this).

> Jan 19 16:14:52 mars nut-monitor[3781]: Init SSL without certificate
database

This means your NUT build is SSL-capable, but you did not configure it with
certificates so it is using plaintext mode.

> Jan 19 16:14:52 mars nut-monitor[3781]: Login on UPS [Eaton@localhost]
failed - got [ERR ACCESS-DENIED]

Given that in some messages posted earlier it works, and in some it is
denied (soon after upsd startup), it is the most puzzling issue here (other
than the service restarts which you did not post explanations about). I'd
guess that it retried the connection too early somehow, if upsd is already
listening but did not yet read all configuration. Not sure this should
happen. Also might be if you have several MONITOR lines for the same
device/server and some of them are wrong?

Jim


On Fri, Jan 19, 2024 at 6:33 PM Stefan Schumacher via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:

> I still have two questions:
> 1) How do I make the nut-server and nut-monitor find the right pid
> files? They are there but it seems they can't be opened. Permissions
> are nut/nut.
> 2) What do these error messages mean?
> Jan 19 16:14:52 mars nut-monitor[3781]: Init SSL without certificate
> database
> Jan 19 16:14:52 mars nut-monitor[3781]: Login on UPS [Eaton@localhost]
> failed - got [ERR ACCESS-DENIED]
>
> Yours sincerely
> Stefan
>
> Am Fr., 19. Jan. 2024 um 17:59 Uhr schrieb Matus UHLAR - fantomas
> :
> >
> > On 19.01.24 17:02, Stefan Schumacher via Nut-upsuser wrote:
> > >Jan 19 05:50:13 mars nut-monitor[849]: Signal 15: exiting
> >
> > >Jan 19 05:50:17 mars nut-server[1303]: Signal 15: exiting
> >
> > this looks like someone repeatedly killed nut server. This not a problem
> of
> > UPS.
> > --
> > Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
> > Warning: I wish NOT to receive e-mail advertising to this address.
> > Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
> > Atheism is a non-prophet organization.
> >
> > ___
> > Nut-upsuser mailing list
> > Nut-upsuser@alioth-lists.debian.net
> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
> ___
> Nut-upsuser mailing list
> Nut-upsuser@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] NUT and Eaton UPS produce a lot of error messages

[Jim Klimov via Nut-upsuser]

Can you please check what was previous to the signal 15 (graceful
termination)? With `journalctl -lu nut-server` or with longer `systemctl
status -n 50 nut-server` if that works for yours?

Also, check NUT Wiki or other docs about using `debug_min` setting woth
2.8.0+ to bump it and have more context about why differebt daemons decide
to do whatever they do (e.g. restart).

For all I know from the few lines here, the restart of services could be
auto-updates rebooting the server, unrelated to NUT or UPS. Or not. Just
got too little to say anything definite.

Good luck,
Jim


On Fri, Jan 19, 2024, 17:02 Stefan Schumacher via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:

> Jan 19 05:50:13 mars nut-monitor[849]: Signal 15: exiting
> Jan 19 05:50:13 mars nut-monitor[849]: Network UPS Tools upsmon 2.8.0
> Jan 19 05:50:13 mars systemd[1]: Stopping nut-monitor.service -
> Network UPS Tools - power device monitor and shutdown controller...
> Jan 19 05:50:13 mars systemd[1]: nut-monitor.service: Deactivated
> successfully.
> Jan 19 05:50:13 mars systemd[1]: Stopped nut-monitor.service - Network
> UPS Tools - power device monitor and shutdown controller.
> Jan 19 05:50:17 mars nut-server[1303]: mainloop: Interrupted system call
> Jan 19 05:50:17 mars nut-server[1303]: Signal 15: exiting
> Jan 19 05:50:17 mars nut-server[1303]: Network UPS Tools upsd 2.8.0
> Jan 19 05:50:17 mars systemd[1]: Stopping nut-server.service - Network
> UPS Tools - power devices information server...
> Jan 19 05:50:17 mars upsd[1303]: mainloop: Interrupted system call
> Jan 19 05:50:17 mars upsd[1303]: Signal 15: exiting
> Jan 19 05:50:17 mars systemd[1]: nut-server.service: Deactivated
> successfully.
> Jan 19 05:50:17 mars systemd[1]: Stopped nut-server.service - Network
> UPS Tools - power devices information server.
> Jan 19 05:50:44 mars usbhid-ups[845]: WARNING: send_to_all: write 31
> bytes to socket 11 failed (ret=-1), disconnecting: Broken pipe
>
> Am Fr., 19. Jan. 2024 um 16:33 Uhr schrieb Matus UHLAR - fantomas
> :
> >
> > On 19.01.24 16:20, Stefan Schumacher via Nut-upsuser wrote:
> > >This morning at 9:50 the server stopped working unexpectedly - I was
> > >still sleeping until 10:00, so no user intervention took place.
> > >
> > >Jan 19 05:50:17 mars nut-server[1303]: mainloop: Interrupted system call
> > >Jan 19 05:50:17 mars nut-server[1303]: Signal 15: exiting
> > >Jan 19 05:50:17 mars nut-server[1303]: Network UPS Tools upsd 2.8.0
> > >Jan 19 05:50:17 mars systemd[1]: Stopping nut-server.service - Network
> > >UPS Tools - power devices information server...
> > >Jan 19 05:50:17 mars upsd[1303]: mainloop: Interrupted system call
> > >Jan 19 05:50:17 mars upsd[1303]: Signal 15: exiting
> > >Jan 19 05:50:17 mars systemd[1]: nut-server.service: Deactivated
> successfully.
> > >Jan 19 05:50:17 mars systemd[1]: Stopped nut-server.service - Network
> > >UPS Tools - power devices information server.
> > >
> > >I am considering returning the device to the online shop I bought. As
> > >it is, it's nothing but trouble. Can you recommend a small UPS (1
> > >Server) that is guaranteed to work flawlessly with NUT?
> >
> > perhaps Eaton Ellipse would be fine.
> >
> > The message above does not look like a problem of the UPS.
> > Was there anything other in the logs, before the message above?
> >
> > >Am Fr., 19. Jan. 2024 um 10:54 Uhr schrieb Jim Klimov via Nut-upsuser
> > >:
> > >>
> > >> With recent NUT releases, driver disconnections should be contained
> in its own `nut-driver@eaton` instance (the `@upsname` part is derived
> from the `ups.conf` section name). One of the drivers failing and
> restarting is not a proper cause for the data server to recycle.
> > >>
> > >> Also, nowadays some (maybe not all) USB-capable drivers should try to
> reconnect without restarting. Note however, that in some NUT iterations it
> is possible that this feature misfires if the devices get re-enumerated and
> the driver tries to reuse results of original libusb discovery (e.g. some
> kernels add +1 to "device" number upon each reconnection, such as due to
> USB chip/hub reset, EMI causing protocol reset, or a device going to sleep
> and yanked back to work).
> > >>
> > >> In fact, recent work on master branch got `nut-scanner` to not
> suggest the `device` option by default to avoid such situations.
> > >>
> > >> Jim
> > >>
> > >>
> > >> On Fri, Jan 19, 2024 at 9:36 AM Matus UHLAR - fantomas <
> uh...@fantomas.sk> wrote:
> > >>>
> > >>&g

Re: [Nut-upsuser] NUT and Eaton UPS produce a lot of error messages

[Jim Klimov via Nut-upsuser]

With recent NUT releases, driver disconnections should be contained in its
own `nut-driver@eaton` instance (the `@upsname` part is derived from the
`ups.conf` section name). One of the drivers failing and restarting is not
a proper cause for the data server to recycle.

Also, nowadays some (maybe not all) USB-capable drivers should try to
reconnect without restarting. Note however, that in some NUT iterations it
is possible that this feature misfires if the devices get re-enumerated and
the driver tries to reuse results of original libusb discovery (e.g. some
kernels add +1 to "device" number upon each reconnection, such as due to
USB chip/hub reset, EMI causing protocol reset, or a device going to sleep
and yanked back to work).

In fact, recent work on master branch got `nut-scanner` to not suggest the
`device` option by default to avoid such situations.

Jim


On Fri, Jan 19, 2024 at 9:36 AM Matus UHLAR - fantomas 
wrote:

> On 19.01.24 09:00, Jim Klimov via Nut-upsuser wrote:
> >Well, from your logs it seems that at 05:17:03 your nut-server (upsd)
> >restarted, so an upsmon reconnection attempt at 05:17:09 had an issue with
> >that (config not all applied? strange a bit) but since 05:17:14 it is
> okay.
> >
> >Maybe a few too many banners shown from upsmon, while its same uptime
> seems
> >to continue. Maybe someone should check on that, seems like a good and
> easy
> >newcomer issue to learn the code, so PRs are welcome :D
> >
> >Messages about lack of "*.pid" files are okay, they should look less scary
> >in newer releases of NUT. They confirm that there is no previous daemon
> >with the same basic configuration currently running, so that your new
> >instance might conflict with it or send it some signals intentionally - so
> >it is just a new start in a clean environment with no competitors.
> >
> >It is a bit unfortunate that both syslog (upsd) and stderr (nut-server)
> >messages land into the same systemd journal. It may be possible to add
> >auto-detection of systemd and not-emit one of those streams then, or add
> an
> >option for that to be quieter and better readable (some people can have a
> >separate syslog setup anyway, maybe on a remote "sink" system, so just
> >cutting one off always is not right).
> >
> >So one question that remains is the missing lines from previous lifetime
> in
> >the short excerpt of upsd: why did it restart at that time? :)
>
> I also have Eaton UPS, just different model. It sometimes disconnects and
> nut has to connect again. I guess this is what happened.
>
> I assume the disonnect message is not visible in "Systemctl status"
> message
> because it does not belong to the current process but previous one.
> Looking for syslog (/var/log/messages) or journal messages (journalctl)
> could
> show that. I guess nothing bad happened there.
>
> >On Fri, Jan 19, 2024 at 6:13 AM Stefan Schumacher via Nut-upsuser <
> >nut-upsuser@alioth-lists.debian.net> wrote:
> >> I recently bought a small UPS by Eaton (Ellipse ECO 800) in order to
> >> prevent my
> >> btrfs-fileserver (running Debian 12 Bookworm 12.4 from shutting down
> >> abruptly while writing
> >> something important during a power loss. I am using the version
> >> 2.8.0.7 provided by Debian.
> >> I have found very gooddocumentation on how to set up the UPS and the
> >> services on the server
> >> connected to it. Unfortunately it's in German
> >> (https://techbotch.org/blog/ups-setup/index.html) which is not a
> >> problem for me but possibly for others trying to understand my set-up.
> >>
> >> I will now describe the steps I took and the configuration options I
> >> set and then post the errors of nut-monitor and nut server. I hope
> >> someone can help fix the underlying problem behind these error
> >> messages.
> >>
> >> lsusb shows the UPS:
> >> Bus 001 Device 003: ID 0463: MGE UPS Systems UPS
> >>
> >> So I made this changes to ups.conf
> >> [Eaton]
> >> driver = usbhid-ups
> >> port = auto
> >> vendorid = 0463
> >> pollfreq = 30
> >>
> >> In nut.conf I set mode=standalone.
> >>
> >> And finally I added these lines to upsd.users:
> >> [upsmon]
> >> password = 
> >> actions = SET
> >> instcmds = ALL
> >>
> >> I did a live test, plugged the cord and waited until the server shut
> >> down at 20%. Worked fine.
> >> Upsc also works - I can query my UPS for specific parameters or show
> them
> >> all.
> >>

Re: [Nut-upsuser] NUT and Eaton UPS produce a lot of error messages

[Jim Klimov via Nut-upsuser]

Well, from your logs it seems that at 05:17:03 your nut-server (upsd)
restarted, so an upsmon reconnection attempt at 05:17:09 had an issue with
that (config not all applied? strange a bit) but since 05:17:14 it is okay.

Maybe a few too many banners shown from upsmon, while its same uptime seems
to continue. Maybe someone should check on that, seems like a good and easy
newcomer issue to learn the code, so PRs are welcome :D

Messages about lack of "*.pid" files are okay, they should look less scary
in newer releases of NUT. They confirm that there is no previous daemon
with the same basic configuration currently running, so that your new
instance might conflict with it or send it some signals intentionally - so
it is just a new start in a clean environment with no competitors.

It is a bit unfortunate that both syslog (upsd) and stderr (nut-server)
messages land into the same systemd journal. It may be possible to add
auto-detection of systemd and not-emit one of those streams then, or add an
option for that to be quieter and better readable (some people can have a
separate syslog setup anyway, maybe on a remote "sink" system, so just
cutting one off always is not right).

So one question that remains is the missing lines from previous lifetime in
the short excerpt of upsd: why did it restart at that time? :)

Jim


On Fri, Jan 19, 2024 at 6:13 AM Stefan Schumacher via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:

> Hello
>
> I recently bought a small UPS by Eaton (Ellipse ECO 800) in order to
> prevent my
> btrfs-fileserver (running Debian 12 Bookworm 12.4 from shutting down
> abruptly while writing
> something important during a power loss. I am using the version
> 2.8.0.7 provided by Debian.
> I have found very gooddocumentation on how to set up the UPS and the
> services on the server
> connected to it. Unfortunately it's in German
> (https://techbotch.org/blog/ups-setup/index.html) which is not a
> problem for me but possibly for others trying to understand my set-up.
>
> I will now describe the steps I took and the configuration options I
> set and then post the errors of nut-monitor and nut server. I hope
> someone can help fix the underlying problem behind these error
> messages.
>
> lsusb shows the UPS:
> Bus 001 Device 003: ID 0463: MGE UPS Systems UPS
>
> So I made this changes to ups.conf
> [Eaton]
> driver = usbhid-ups
> port = auto
> vendorid = 0463
> pollfreq = 30
>
> In nut.conf I set mode=standalone.
>
> And finally I added these lines to upsd.users:
> [upsmon]
> password = 
> actions = SET
> instcmds = ALL
>
> I did a live test, plugged the cord and waited until the server shut
> down at 20%. Worked fine.
> Upsc also works - I can query my UPS for specific parameters or show them
> all.
>
> The problem is the dozens of errors the systemctl status messages
> show. I bought the UPS to increase reliability and now I don't know if
> the service is working in case of an emergency. How can I fix this ?
>
> ● nut-server.service - Network UPS Tools - power devices information server
> Loaded: loaded (/lib/systemd/system/nut-server.service; enabled;
> preset: enabled)
> Active: active (running) since Fri 2024-01-19 05:17:03 CET; 5s ago
> Main PID: 1303 (upsd)
> Tasks: 1 (limit: 38253)
> Memory: 640.0K
> CPU: 3ms
> CGroup: /system.slice/nut-server.service
> └─1303 /lib/nut/upsd -F
> Jan 19 05:17:03 servername nut-server[1303]: fopen /run/nut/upsd.pid:
> No such file or directory
> Jan 19 05:17:03 servername nut-server[1303]: Could not find PID file
> '/run/nut/upsd.pid' to see if previous upsd instance is already
> running!
> Jan 19 05:17:03 servername nut-server[1303]: listening on 127.0.0.1 port
> 3493
> Jan 19 05:17:03 servername nut-server[1303]: listening on ::1 port 3493
> Jan 19 05:17:03 servername upsd[1303]: listening on 127.0.0.1 port 3493
> Jan 19 05:17:03 servername upsd[1303]: listening on ::1 port 3493
> Jan 19 05:17:03 servername nut-server[1303]: Connected to UPS [Eaton]:
> usbhid-ups-Eaton
> Jan 19 05:17:03 servername upsd[1303]: Connected to UPS [Eaton]:
> usbhid-ups-Eaton
> Jan 19 05:17:03 servername upsd[1303]: Running as foreground process,
> not saving a PID file
> Jan 19 05:17:03 servername nut-server[1303]: Running as foreground
> process, not saving a PID file
>
> ● nut-monitor.service - Network UPS Tools - power device monitor and
> shutdown controller
> Loaded: loaded (/lib/systemd/system/nut-monitor.service; enabled;
> preset: enabled)
> Active: active (running) since Fri 2024-01-19 03:37:28 CET; 1h 41min ago
> Main PID: 847 (upsmon)
> Tasks: 2 (limit: 38253)
> Memory: 3.4M
> CPU: 338ms
> CGroup: /system.slice/nut-monitor.service
> ├─847 /lib/nut/upsmon -F
> └─849 /lib/nut/upsmon -F
> Jan 19 03:43:08 servername nut-monitor[849]: UPS Eaton@localhost on
> battery
> Jan 19 03:43:09 servername nut-monitor[916]: Network UPS Tools upsmon 2.8.0
> Jan 19 03:43:33 servername nut-monitor[849]: UPS Eaton@localhost on line
> power
> Jan 19 03:43:34 servername 

Re: [Nut-upsuser] Windows NUT Client - Settings description somewhere ?

[Jim Klimov via Nut-upsuser]

I haven't used that package with Windows (haven't used that for a while) so
can't say directly. However I can't find, neither in sources nor in the
files stored in the MSI, the GUI program you've sent the screenshot from
and particularly the localization strings it uses. Are you sure it was not
a separate download?

Note that the existing MSI's are based on a branch spun off a NUT 2.6.5
release (newest variants are from 10 years ago). The NUT for Windows effort
was restarted in the recent couple of years to become part of the main
codebase, with current status outlined in
https://github.com/networkupstools/nut/wiki/NUT-for-Windows (some things
can be built and run, some known not-yet-ported, installer not re-addressed
yet, not sure if anyone ran the full stack with monitoring and shutdowns -
at least nobody reported back whether it works end-to-end, I think). It
seems there was little interest from developers on this platform (some more
from end-users), so I can't remember any PRs and very few investigative
tickets posted not by myself. Help is always welcome, as anywhere :)

Jim


On Fri, Jan 12, 2024 at 10:12 AM edward.ebay 
wrote:

> I did download that for Windows from the NUT-pages – Download-section
> https://networkupstools.org/download.html
>
>
>
> See chapter „Binary packages“ – „Windows MSI installer“.
>
>
>
> Downloaded end of 2023 when i did start with UPS-topic.
>
>
>
> Let me know if you need additional information.
>
>
>
> Thanks in advance
>
>
>
> Eddie
>
>
>
> *Von:* Jim Klimov 
> *Gesendet:* Donnerstag, 11. Januar 2024 19:14
> *An:* edward.ebay 
> *Cc:* Arnaud Quette via Nut-upsuser 
> *Betreff:* Re: [Nut-upsuser] Windows NUT Client - Settings description
> somewhere ?
>
>
>
> I do not seem to recognize that client. Is it part of the old NUT MSI
> package or a third-party project?
>
>
>
> Jim
>
>
>
> On Fri, Jan 5, 2024, 13:38 edward.ebay  wrote:
>
> Hi there,
>
>
>
> Question: Is there anywhere a description of how to use the settings for
> shutdown options in Windows NUT client ?
>
>
>
> i have successfully set up NUT on a Raspberry which gathers data from a
> CyberPower CP1500EPFCLCD.
>
> Have also connected 2 Windows 11 machines and one Synology device tot hat
> master, in order read data and to react on powersupply issues. All working
> fine.
>
>
>
> What i am struggeling with are the settings available in Windows NUT
> Client about the Shutdown options. My first trial to get the system to
> hibernate after a power failure was not successful. Seems to be different
> possible settings which may confuse each other.
>
> Is there anywhere a description of how to use the settings for shutdown
> options in Windows NUT client ?
>
>
>
> Current setting see screenshot
>
>
>
>
>
> As nothing happened, i did set the first value for battery-threshold to
> 90%, (while the batt was below) and that then did immediately react with
> hiberate.
>
>
>
> My preferred setting would be to wait after powerfailure for 1 minute,
> then hibernate. Without taking other values into account like batterylevel
> or batteryruntime…
>
>
>
> Any help or information on that would be appreciated.
>
>
>
> Thanks
>
> Eddie
>
> ___
> Nut-upsuser mailing list
> Nut-upsuser@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

[Nut-upsuser] Happy New Year 2024

[Jim Klimov via Nut-upsuser]

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 getting one at least every year (sure hope for more)!

Thanks to everyone involved,
on behalf of the Network UPS Tools project,
Jim Klimov
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Help with CGI upsstats.cgi giving "file not found"

[Jim Klimov via Nut-upsuser]

Well, it seems both apache and bash literally say they did not find an
executable there; it is not about NUT configs. Is the file present? (is
"spivey" same as "pi2" in "screenshots" posted?) Does it have the exec bit
set? Are all directories at least "executable" by apache user?

Jim


On Thu, Dec 21, 2023, 13:11 Tim Reimers KA4LFP via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:

>
> Hi everyone --
>
> I'm having a problem with the CGI scripts for NUT.
>
> First, a summary:
> - I have a RasPI  (hereafter referred to as Pi1)  running Bullseye in
> which this all WORKS FINE -- the upsd/upsc/ monitor services, etc
> - I have a SECOND RasPI (hereafter referred to as Pi2) running Bullseye in
> which ONLY the CGI scripts do not work.
> All other (upsc/upsd/systemctl) show normal status and work to retrieve
> data from the single UPS attached to each Pi.
>
> Discussion below is in regard to "PI2", in which CGI scripts don't work.
> On "Pi1" everything works fine.
>
> I have compared many files/permissions/config files, and cannot find a
> difference between the two Pi.
>
> On both of them, running "upsc @localhost" works fine, and produces
> output from the UPS.
> So at a basic level, the UPS is connected to the USB port, the driver is
> working, and the upsd monitoring service is OK.
>
>
> The essential problem
> The CGI script returns "file not found"
> If I execute it from a browser via Apache,
> I simply get a 500 Internal Server Error.
>
> On another site, I discovered that it's possible to simply execute a CGI
> script directly, if it's a compiled executable.
>
> Here's what happens at the CLI by executing the file.
> root@Pi2 :~# /var/www/cgi-bin/nut/upsstats.cgi
> -bash: /var/www/cgi-bin/nut/upsstats.cgi: No such file or directory
>
> That's different from the suggested scenarios for running upsstats.cgi
> from the CLI, which were issues
> with host authentication or "spits a bunch of HTML at you", which would be
> fine.
>
> On "Pi1", the fully working one - that's exactly what happens  - calling
> "upsstats.cgi" from the CLI
> results in it simply spitting out HTML with the configured UPS detailed
> out.
> Running the CGI from a browser > Apache2 on the Pi works exactly as
> expected
>
> What I lack an understanding of is which files in /etc/nut
> these CGI scripts access, and what permissions are needed.
> Or if there are other files in other directories that the CGI scripts need.
> That error, cryptically gives me the impression that the CGI script cannot
> access some file it needs
> I've looked at
> /etc/nut/hosts.conf
> /etc/nut/upsstats.html
> /etc/nut/upssstats-single.html
> /etc/nut/upsset.conf
>
> All those files -- which I believe to be the required ones for CGI, appear
> to be identical on Pi2 as compared to Pi1
>
> Does anyone have any idea which files/permissions that the CGI may require
> other than the above?
> I'm not sure if something in /usr/lib /var/wherever, etc are also
> required?
>
> Thanks Tim
>
> Some details for those who will want to compare versions, etc.
>
> The apache logfile
> [Tue Dec 19 15:20:42.088991 2023] [cgi:error] [pid 3293] [client
> 72.250.240.54:31043] AH01215: (2)No such file or directory: exec of
> '/var/www/cgi-bin/nut/upsstats.cgi' failed:
> /var/www/cgi-bin/nut/upsstats.cgi
> [Tue Dec 19 15:20:42.092452 2023] [cgi:error] [pid 3293] [client
> 72.250.240.54:31043] End of script output before headers: upsstats.cgi
> [Tue Dec 19 15:20:42.498512 2023] [cgi:error] [pid 3294] [client
> 72.250.240.54:40731] AH01215: (2)No such file or directory: exec of
> '/var/www/cgi-bin/nut/upsstats.cgi' failed:
> /var/www/cgi-bin/nut/upsstats.cgi
> [Tue Dec 19 15:20:42.502123 2023] [cgi:error] [pid 3294] [client
> 72.250.240.54:40731] End of script output before headers: upsstats.cgi
>
> Permissions on /etc/nut
> root@spivey:~#  ls -la /etc/nut
> total 64
> drwxr-xr-x 1 root nut   292 Dec 18 20:02 .
> drwxr-xr-x 1 root root 3882 Dec 19 06:14 ..
> -rwxr-x--- 1 nut  nut   675 Dec  6 20:40 etcnutfileperms.txt
> -rwxr-x--- 1 root root 1148 Dec 18 20:02 hosts.conf
> -rwxr-x--- 1 nut  nut  1543 Dec  6 20:40 nut.conf
> -rwxr-x--- 1 nut  root 1137 Dec 15 21:12 old-hosts.conf
> -rwxr-x--- 1 nut  nut  6170 Dec 18 20:01 ups.conf
> -rwxr-x--- 1 nut  nut  4631 Dec  6 20:40 upsd.conf
> -rwxr-x--- 1 nut  nut  2185 Dec 18 19:54 upsd.users
> -rwxr-x--- 1 root root 1263 Dec 18 20:01 upsmon.conf
> -rwxr-x--- 1 nut  nut  5634 Dec  6 20:40 upssched.conf
> -rwxr-x--- 1 nut  nut  1415 Dec 15 21:36 upsset.conf
> -rwxr-x--- 1 nut  root 3603 Dec  6 20:40 upsstats.html
> -rwxr-x--- 1 nut  root 6446 Dec  6 20:40 upsstats-single.html
> root@spivey:~#  ls -la /etc/ | grep nut
> drwxr-xr-x 1 root nut  292 Dec 18 20:02 nut
>
>
> root@Pi2:~# upsc tripplite@localhost
> Init SSL without certificate database
> battery.charge: 100
> .
> .
>
>
> root@Pi2:~# /usr/sbin/upsd -DD -a tripplite@localhost
> Network UPS Tools upsd 2.7.4
>
>
> root@Pi2:~#
> root@spivey:~# file 

Re: [Nut-upsuser] Looking for a UPS Driver

[Jim Klimov via Nut-upsuser]

Hello,

  Did you acquaint yourself with the NUT project? There are quite a few
architecture and installation documents and README's (maybe a few too many
for people just getting started, pull requests for simple entry points are
welcome) :)

  In short, you would either have it installed via packaging prepared by
your OS distribution maintainers (for `apc_modbus` in particular, you would
need at least NUT v2.8.1), or built by yourself - in case of this driver
and USB links, also building the custom libmodbus with USB capability, as
per Wiki page linked earlier. Specifically in case of this driver and
use-case, your best shot is "built by yourself" anyway, since distributions
are not likely to ship the libmodbus with USB patches added (they are not
merged into upstream code yet).

Hope this helps,
Jim Klimov


On Sun, Dec 10, 2023 at 3:48 PM James Parascand 
wrote:

> where can I download apc_modbus?
> Also where do I install the driver?
>
> Thanks
>
> On Sun, Dec 10, 2023 at 6:23 AM Jim Klimov 
> wrote:
>
>> Cheers,
>>
>>   The current situation is a bit of a moving target - for USB devices
>> you'd need to custom build a `libmodbus` and then NUT against it. For more
>> details, see
>> https://github.com/networkupstools/nut/wiki/APC-UPS-with-Modbus-protocol
>>
>> Hope this helps,
>> Jim Klimov
>>
>> On Sun, Dec 10, 2023 at 3:01 AM James Parascand via Nut-upsuser <
>> nut-upsuser@alioth-lists.debian.net> wrote:
>>
>>> I have an Smart-UPS X 1500 (SMX1500I, USB)
>>> USB.  I am looking for the APC_MODBUS driver.
>>>
>>> Thanks
>>>
>>> James
>>> ___
>>> Nut-upsuser mailing list
>>> Nut-upsuser@alioth-lists.debian.net
>>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>>>
>>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Can not Access the Web GUI

[Jim Klimov via Nut-upsuser]

Hello,

  Hard to say from your "screenshot" but it seems like you're typing the
URL into command-line. Does your OS handle starting a browser for that?
Otherwise, you should run one manually and enter the URL there.

  For that matter, did you follow the documentation on setting up the NUT
CGI programs, their permissions and credentials, enabling the web-server to
publish them, etc.?

Hope this helps,
Jim Klimov

On Sat, Dec 9, 2023, 20:11 James Parascand via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:

> I have installed NUT Server and everything went fine.  Now when I try to
> run
> dradmin@raspberrypi:/etc/nut $ http://localhost/cgi-bin/nut/upsstats.cgi
> I get the following error
> dradmin@raspberrypi:/etc/nut $ http://localhost/cgi-bin/nut/upsstats.cgi
>
> I am trying to run this on a local host.
>
> ___
> Nut-upsuser mailing list
> Nut-upsuser@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Looking for a UPS Driver

[Jim Klimov via Nut-upsuser]

Cheers,

  The current situation is a bit of a moving target - for USB devices you'd
need to custom build a `libmodbus` and then NUT against it. For more
details, see
https://github.com/networkupstools/nut/wiki/APC-UPS-with-Modbus-protocol

Hope this helps,
Jim Klimov

On Sun, Dec 10, 2023 at 3:01 AM James Parascand via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:

> I have an Smart-UPS X 1500 (SMX1500I, USB)
> USB.  I am looking for the APC_MODBUS driver.
>
> Thanks
>
> James
> ___
> Nut-upsuser mailing list
> Nut-upsuser@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

[Nut-upsuser] PR to change logging of OL+DISCHRG UPS state combo

[Jim Klimov via Nut-upsuser]

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
https://github.com/networkupstools/nut/pull/2216 and it would be great if
someone with the "troublesome" devices could build that code branch and
confirm its log messages behave just as theoretically expected :)

  An in-place build routine (and references to build prerequisites, if
someone here lacks them), can be found at
https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests

  PR source is at https://github.com/jimklimov/nut/tree/issue-1970-throttle
- or for code building purposes:

:; git clone https://github.com/jimklimov/nut.git -b
issue-1970-throttle nut-issue-1970
:; cd nut-issue-1970
# ... follow the Wiki about prerequisites and build procedure
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] OMV + NUT + TrippLite OMNIVSX850

[Jim Klimov via Nut-upsuser]

>could not detach kernel driver from interface 0: Operation not permitted

Does that system have something like udev, upower, devd or some such in
charge of assigning filesystem permissions to USB device nodes - should get
owned by NUT run-time user?

Alternatively, try adding `user=root` line to the driver config section.

Also, NUT v2.7.4 was popular for a few years too many, but now is a few
releases behind modernity. Is it an option for you to build a replacement
from github master branch there (if not packaged yet by vendor)? Note there
was an errata published after 2.8.1, with a one-line fix, so better take
the git master.

Jim


On Mon, Dec 4, 2023, 23:27 Olaf Lendt via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:

> Hello,
> I am try to get my "new" UPS running with NUT on my OpenMediaVault device
> but only receive error meassages on several configurations I try.
> Your support is really appreciated for getting it solved.
>
> Best Regards, Olaf
>
>
> *lsusb*
> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 003 Device 003: ID 09ae:3024 Tripp Lite OMNIVSX850
> Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 005 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>
> config#1 in OMV:
> driver = usbhid-ups
> #driver = tripplite_usb
> port = auto
> #vendorid = 09ae
> #productid=3024
>
> result:
>
> *upsdrvctl start*Network UPS Tools - UPS driver controller 2.7.4
> Network UPS Tools - Generic HID driver 0.41 (2.7.4)
> USB communication driver 0.33
> This TrippLite device (09ae:3024) is not (or perhaps not yet) supported
> by usbhid-ups. Please make sure you have an up-to-date version of NUT. If
> this does not fix the problem, try running the driver with the
> '-x productid=3024' option. Please report your results to the NUT user's
> mailing list .
>
> No matching HID UPS found
> Driver failed to start (exit status=1)
>
> config#2 in OMV:
> driver = usbhid-ups
> #driver = tripplite_usb
> port = auto
> #vendorid = 09ae
> productid=3024
>
> result:
>
> *upsdrvctl start*Network UPS Tools - UPS driver controller 2.7.4
> Network UPS Tools - Generic HID driver 0.41 (2.7.4)
> USB communication driver 0.33
> Can't claim USB device [09ae:3024]: could not detach kernel driver from
> interface 0: Operation not permitted
> Driver failed to start (exit status=1)
> ___
> Nut-upsuser mailing list
> Nut-upsuser@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Liebert UPS driver

[Jim Klimov via Nut-upsuser]

Cheers,

  Looking at the `vendorid=0x10af` -- the usbhid-ups subdriver `belkin-hid`
has the best chance here (being the only one to mention it).

  The `productid=0x0002` is indeed not mentioned in `drivers/belkin-hid.c`
so probably nobody encountered it before and/or tested a hotfix to PR it
into NUT upstream.

  Since the NUT release v2.8.1, the `usbhid-ups` should support a
`subdriver` config option, so you can try it with devices whose IDs are not
compiled into the binary program.

  If you don't have it packaged but are comfortable building from source,
the github NUT wiki has some pointers about "in-place" builds to test from
the build area and later optionally install to override what the distro
package delivers.

Jim




On Mon, Dec 4, 2023, 13:15 tim Goins via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:

> Replaced ups with a new Liebert UPS and it seems the device may not be
> known to nut. Below is output of lsusb:
> ID 10af:0002 Liebert Corp. PowerSure PST UPS
>
> Sent from Outlook 
> ___
> Nut-upsuser mailing list
> Nut-upsuser@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] NUT 'upsstats' Battery Meter Question

[Jim Klimov via Nut-upsuser]

Hello Jeff,

  `upsstats` by itself only relays and renders the information provided by
a NUT data server (upsd) and the NUT driver for the device. So you can
revise the specific reported values with e.g. `upsc` command-line client to
be sure.

  What I think happens here is that the driver uses a
`battery.voltage.low/nominal/high` group of readings which does not match
the hardware circumstances well for some reason. These readings can be
provided by a device (and then a 3x12=36V nominal would be reasonable), it
can be imposed in your driver configuration with
`override.battery.voltage = ...` lines, and in some but not all drivers
the ranges can be guessed from other information served by the device, as a
fallback.

  Use of overrides is fairly popular, so check if that would help you (and
that you don't have it misleadingly misconfigured already by copy-paste of
an `ups.conf` device section from the internet).

  While at it, check the manual pages for the driver you use - if it
supports a `runtimecal` option. It often comes up in this context, to give
the driver a better grasp at battery discharge dynamics so it can issue the
critical-situation alarms at power loss if the device/protocol lacks the
ability on its own.

Hope this helps,
Jim Klimov


Jim


On Thu, Nov 30, 2023 at 12:57 AM Jeff Rickman  wrote:

> Hello,
>
> I am using Nut 2.8.0 (2.8.0-7 packages) Debian 'Bookworm' in it's Devuan
> form 'Daedalus'.
>
> When I look at my Eaton (ex-MGE Powerware) E5115 UPS boxes in NUT
> 'upsstats" I am confused by the battery readings.
>
> Under the 'System' column I can click on the link and obtain a GUI with a
> few meters.
>
> The NUT 'upsstats' battery voltage meter for these E5115 UPS boxes is
> almost in the lower level RED zone which is just under 40 volts. The GREEN
> zone seems to be 48 to 55 volts with a RED zone above that.
>
> Here's the confusing part: These Eaton E5115 UPS boxes only have 3x 12v
> 9Ah sealed lead-acid AGM battery blocks inside them. I verified that after
> I recently changed out some aged batteries from those boxes. There is no
> room for any more battery blocks in the case.
>
> NUT 'upsstats' reports the battery voltage as 40.25 volts for 1 of the UPS
> boxes and 39.02 volts for the other UPS box. Those voltages seem reasonable
> (and similar to past results for other battery blocks) for NEW 12v sealed
> lead-acid AGM battery blocks.
>
> When I look at the 'Data tree' link from the NUT 'upsstats' tool I can see
> the organized list of data from the UPS. There does not appear to be any
> upper or lower battery charge limits in that data.
>
> So, how does NUT 'upsstats' figure out it's upper and lower limits and
> where it places it's RED zones? Can these meters be adjusted in some way?
>
> /Jeff/
>
> --
>
>
> ___
> Nut-upsuser mailing list
> Nut-upsuser@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

[Nut-upsuser] Sponsorship from DigitalOcean

[Jim Klimov via Nut-upsuser]

Cheers all,

  you may have seen related preparatory news on the NUT website or in the
README changes, but now the next step is official:

  The fine folks at DigitalOcean approved FOSS sponsoring credits to
re-host the custom-built multi-platform non-regression NUT CI farm, which
builds several hundred scenarios per iteration (to cover a matrix with many
OSes, toolkit versions and implementations, and dependency versions), with
a tranche of credits that by my estimation should last for the intended
year with VM config/setup comparable to what runs now elsewhere and has an
eviction notice looming.

  As part of that discussion I've discovered that the social-networking
element of GitHub et al with "stars"/"likes"/... of projects being a
practical physically meaningful metric for FOSS sponsors to gauge the
impact their help can make (and visibility it brings back).

  So it was surprising that NUT is around for a quarter of a century,
installed and helping probably on millions of machines, and yet there are
just a handful of visibly active people and 1.2k collected stars... Vim,
bash, git or curl are similar as commonly pre-installed background
radiation, but are way more "liked"! ;)

  Long story short: when you visit official repos of projects you use and
like, don't hesitate to "star" them - sooner or later it can help them
tangibly!

Jim Klimov
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] APC Modbus support is finally here!

[Jim Klimov via Nut-upsuser]

Thanks again,

  Great to see confirmations of more and more things working!

> I wonder what's the fastest method to test the function (previously I
setup the ups and unplug the utility from the ups for testing).
> is "upsrw driver.flag.allow_killpower=1" then "upscmd driver.killpower"
the correct testing procedure?

At least by intent of this new feature -- yes. Normally the drivers are not
allowed to pass these dangerous commands unless started specifically for
killpower handling late in the system shutdown. Since NUT v2.8.1 however
there's this safety switch to toggle and then an instant command should be
usable. But as this is a relatively recent addition to the codebase and it
is not integrated with practical shutdowns in any packages yet (AFAIK) to
avoid killing a driver daemon to restart it as the driver tool just for the
killpower command, it has not seen much real-life testing -- so it is
possible that some bugs lurk here too.

Regarding shutdowns triggered due to calibration - the `CAL` state should
be specially handled with regard to `OB`/`LB` in `upsmon` since recently.
However this driver seems to use `TEST` here? Raised a question in
https://github.com/networkupstools/nut/pull/2184 discussion (also
referenced your replies there). Actually, now I wonder (did not test) how
`upsmon` interacts with `upssched` in case of calibrations, if this is
suppressed or not...

Jim




On Mon, Nov 27, 2023 at 1:50 PM d tbsky  wrote:

> Jim Klimov 
> >
> > I believe some fixes were applied to the branch since your report (most
> visibly, about battery time settings), are you in position to test how it
> behaves now? :)
>
> Hi:
>I got another ups for testing. so I test the new commit for both
> APC SRT3000XL and SMT2200RM2U. the results below:
>
> 1. I get the new attribute "ups.test.result" for both ups and it is fine.
>
> 2. upsrw battery.date works fine for both UPS. and the modified result
> shows immediately. no need to restart the driver. (I still need to
> restart the driver to get correct battery.date.maintenance. but I
> think that's not very important. there's not even that attribute at
> apcupsd.)
>
> 3. test.battery.stop works fine at SRT3000XL. but it is not working at
> SMT2200RM2U (same experience as the driver author). I think it is not
> important. BTW, at program "apctest" from apcupsd, the function
> "test.battery.start" is called "self test", and the physical ups panel
> also shows "self test". the function "test.panel.start" is called
> "alarm test" at apctest. what bothers me is when testing, the ups
> status will become "OB TEST". "OB" will cause the system shutdown when
> I configured upssched for early shutdown. I had only saw one very old
> APC ups which will show "OB" when testing/calibration. most will show
> like "OL DISCHRG". but I think the information is from ups and can not
> change?
>
> 4. almost all the power-related upscmd command(load.* outlet.*
> shutdown.*) are not working. there is only one exception: ouetlet1.*
> works at SMT2200RM2U (I test outlet.1.load.off). nothing works at
> SRT3000XL. the new driver detect there are two outlet groups for both
> UPS(outlet.group.count: 2). but SMT2200RM2U has only one outlet group.
> since the new driver can not shutdown the ups, I wonder what's the
> fastest method to test the function (previously I setup the ups and
> unplug the utility from the ups for testing). is "upsrw
> driver.flag.allow_killpower=1" then "upscmd driver.killpower" the
> correct testing procedure?
>
> 5. the default/actual shutdown delay for both ups is 90 seconds(when
> real testing under apcupsd). the "upsrw -l myups" has value "90" for
> the attribute "outlet.group.1.delay.shutdown". but other attributes
> related to the shutdown delay are all "0". BTW, apcupsd also shows "0"
> shutdown delay although it can correctly shutdown ups.
>
> below are the raw data for SMT2200RM2U:
>
> >upsc myups
> battery.charge: 100.00
> battery.date: 2023-11-25
> battery.date.maintenance: 2028-05-25
> battery.runtime: 22320
> battery.temperature: 24.69
> battery.voltage: 54.53
> device.mfr: American Power Conversion
> device.model: Smart-UPS 2200
> device.serial: AS1848260180
> device.type: ups
> driver.debug: 0
> driver.flag.allow_killpower: 0
> driver.name: apc_modbus
> driver.parameter.pollinterval: 10
> driver.parameter.port: /dev/ttyS0
> driver.parameter.synchronous: yes
> driver.state: quiet
> driver.version: 2.8.1.1
> driver.version.internal: 0.10
> experimental.output.energy: 0
> input.transfer.high: 127
> input.transfer.low: 106
> input.transfer.reason: AcceptableInput
> input.voltage: 109.39
> outlet.group.0.delay.reboot: 8
> outlet.group.0.delay.shutdown: 0
> outlet.group.0.delay.start: 0
> outlet.group.0.name: UPS Outlets
> outlet.group.1.delay.reboot: 8
> outlet.group.1.delay.shutdown: 90
> outlet.group.1.delay.start: 0
> outlet.group.1.name: Outlet Group 1
> outlet.group.2.delay.reboot: -1
> outlet.group.2.delay.shutdown: -1
> outlet.group.2.delay.start: 

Re: [Nut-upsuser] APC Modbus support is finally here!

[Jim Klimov via Nut-upsuser]

I believe some fixes were applied to the branch since your report (most
visibly, about battery time settings), are you in position to test how it
behaves now? :)

Thanks in advance,
Jim Klimov


On Wed, Nov 22, 2023 at 3:20 PM Jim Klimov  wrote:

> Great! Thanks for the info, and hope the driver author can address the
> nits (forwarding now...)
>
> Jim
>
> On Wed, Nov 22, 2023, 15:05 d tbsky  wrote:
>
>> Jim Klimov via Nut-upsuser 
>> >
>> > Got an update for APC Modbus users: a new PR is waiting for real-life
>> testing for settable variables and instant commands support.
>> >
>> > https://github.com/networkupstools/nut/pull/2184
>> >
>> > As before, a custom build of libmodbus may be needed for USB support
>> (detailed in the earlier PR), but Serial and TCP may already be well served
>> by a distro near you!
>>
>> Hi:
>>I got a new APC SRT3000XL and tested the new driver "apc_modbus".
>> the ups works fine with nut+apcupsd.  the new driver "apc_modbus" has
>> result below:
>>
>> 1.  upsrw can write the variable "battery.date". but the new value
>> will only show after restarting apc_modbus. and in my case the written
>> data will shift one day. eg the command "upsrw -s
>> battery.date=2023-09-13" will return "2023-09-12" later.
>> 2. the upscmd power-off related commands (like load.*, outlet.*,
>> shutdown.*) can not work. so it can not shutdown the ups. (I think
>> this is the most important feature which needs to be fixed)
>> 3. upscmd command works: beeper.mute, bypass.start, bypass.stop,
>> test.battery.start, test.battery.stop, test.panel.start
>> 4. I can't  attach any load so I can not test calibrate.start. but I
>> found the new driver seems missing an import item which apcupsd have:
>> "ups.test.result"
>>
>> below are some raw data:
>> > data read from  nut+apcupsd (for reference):
>> battery.charge: 99.0
>> battery.charge.low: 5
>> battery.date: 2023-11-21
>> battery.runtime: 57000.0
>> battery.runtime.low: 180
>> battery.voltage: 109.0
>> device.mfr: APC
>> device.model: Smart-UPS SRT3000
>> device.serial: AS2032296523
>> device.type: ups
>> driver.debug: 0
>> driver.flag.allow_killpower: 0
>> driver.name: apcupsd-ups
>> driver.parameter.pollinterval: 10
>> driver.parameter.port: localhost
>> driver.parameter.synchronous: auto
>> driver.state: quiet
>> driver.version: 2.8.1
>> driver.version.internal: 0.71
>> input.frequency: 60.0
>> input.voltage: 224.7
>> output.current: 0.00
>> output.frequency: 60.0
>> output.voltage: 207.6
>> output.voltage.nominal: 208
>> power.percent: 0.0
>> ups.date: 2023-11-22
>> ups.delay.shutdown: 0
>> ups.delay.start: 0
>> ups.firmware: UPS 15.5
>> ups.firmware.aux: 00.5
>> ups.id: APC UPS
>> ups.load: 0.0
>> ups.mfr: APC
>> ups.mfr.date: 2020-08-10
>> ups.model: Smart-UPS SRT3000
>> ups.power.nominal: 3000
>> ups.realpower.nominal: 2700.0
>> ups.serial: AS2032296523
>> ups.status: OL
>> ups.temperature: 27.0
>> ups.test.result: OK
>> ups.time: 17:24:25
>>
>> > data read from new driver "apc_modbus"
>> battery.charge: 99.00
>> battery.date: 2023-11-21
>> battery.date.maintenance: 2028-05-21
>> battery.runtime: 57425
>> battery.temperature: 29.00
>> battery.voltage: 108.69
>> device.mfr: American Power Conversion
>> device.model: Smart-UPS SRT3000
>> device.serial: AS2032296523
>> device.type: ups
>> driver.debug: 0
>> driver.flag.allow_killpower: 0
>> driver.name: apc_modbus
>> driver.parameter.pollinterval: 10
>> driver.parameter.port: /dev/ttyS0
>> driver.parameter.synchronous: yes
>> driver.state: quiet
>> driver.version: 2.8.1
>> driver.version.internal: 0.10
>> experimental.output.energy: 7
>> input.transfer.high: 220
>> input.transfer.low: 184
>> input.transfer.reason: TestEnded
>> input.voltage: 224.77
>> outlet.group.0.delay.reboot: 8
>> outlet.group.0.delay.shutdown: 0
>> outlet.group.0.delay.start: 0
>> outlet.group.0.name: Unswitched Group
>> outlet.group.1.delay.reboot: 8
>> outlet.group.1.delay.shutdown: 90
>> outlet.group.1.delay.start: 0
>> outlet.group.1.name: Outlet Group 1
>> outlet.group.2.delay.reboot: 8
>> outlet.group.2.delay.shutdown: 90
>> outlet.group.2.delay.start: 0
>> outlet.group.2.name: Outlet Group 2
>> outlet.group.3.delay.reboot: 8
&

Re: [Nut-upsuser] APC Modbus support is finally here!

[Jim Klimov via Nut-upsuser]

Great! Thanks for the info, and hope the driver author can address the nits
(forwarding now...)

Jim

On Wed, Nov 22, 2023, 15:05 d tbsky  wrote:

> Jim Klimov via Nut-upsuser 
> >
> > Got an update for APC Modbus users: a new PR is waiting for real-life
> testing for settable variables and instant commands support.
> >
> > https://github.com/networkupstools/nut/pull/2184
> >
> > As before, a custom build of libmodbus may be needed for USB support
> (detailed in the earlier PR), but Serial and TCP may already be well served
> by a distro near you!
>
> Hi:
>I got a new APC SRT3000XL and tested the new driver "apc_modbus".
> the ups works fine with nut+apcupsd.  the new driver "apc_modbus" has
> result below:
>
> 1.  upsrw can write the variable "battery.date". but the new value
> will only show after restarting apc_modbus. and in my case the written
> data will shift one day. eg the command "upsrw -s
> battery.date=2023-09-13" will return "2023-09-12" later.
> 2. the upscmd power-off related commands (like load.*, outlet.*,
> shutdown.*) can not work. so it can not shutdown the ups. (I think
> this is the most important feature which needs to be fixed)
> 3. upscmd command works: beeper.mute, bypass.start, bypass.stop,
> test.battery.start, test.battery.stop, test.panel.start
> 4. I can't  attach any load so I can not test calibrate.start. but I
> found the new driver seems missing an import item which apcupsd have:
> "ups.test.result"
>
> below are some raw data:
> > data read from  nut+apcupsd (for reference):
> battery.charge: 99.0
> battery.charge.low: 5
> battery.date: 2023-11-21
> battery.runtime: 57000.0
> battery.runtime.low: 180
> battery.voltage: 109.0
> device.mfr: APC
> device.model: Smart-UPS SRT3000
> device.serial: AS2032296523
> device.type: ups
> driver.debug: 0
> driver.flag.allow_killpower: 0
> driver.name: apcupsd-ups
> driver.parameter.pollinterval: 10
> driver.parameter.port: localhost
> driver.parameter.synchronous: auto
> driver.state: quiet
> driver.version: 2.8.1
> driver.version.internal: 0.71
> input.frequency: 60.0
> input.voltage: 224.7
> output.current: 0.00
> output.frequency: 60.0
> output.voltage: 207.6
> output.voltage.nominal: 208
> power.percent: 0.0
> ups.date: 2023-11-22
> ups.delay.shutdown: 0
> ups.delay.start: 0
> ups.firmware: UPS 15.5
> ups.firmware.aux: 00.5
> ups.id: APC UPS
> ups.load: 0.0
> ups.mfr: APC
> ups.mfr.date: 2020-08-10
> ups.model: Smart-UPS SRT3000
> ups.power.nominal: 3000
> ups.realpower.nominal: 2700.0
> ups.serial: AS2032296523
> ups.status: OL
> ups.temperature: 27.0
> ups.test.result: OK
> ups.time: 17:24:25
>
> > data read from new driver "apc_modbus"
> battery.charge: 99.00
> battery.date: 2023-11-21
> battery.date.maintenance: 2028-05-21
> battery.runtime: 57425
> battery.temperature: 29.00
> battery.voltage: 108.69
> device.mfr: American Power Conversion
> device.model: Smart-UPS SRT3000
> device.serial: AS2032296523
> device.type: ups
> driver.debug: 0
> driver.flag.allow_killpower: 0
> driver.name: apc_modbus
> driver.parameter.pollinterval: 10
> driver.parameter.port: /dev/ttyS0
> driver.parameter.synchronous: yes
> driver.state: quiet
> driver.version: 2.8.1
> driver.version.internal: 0.10
> experimental.output.energy: 7
> input.transfer.high: 220
> input.transfer.low: 184
> input.transfer.reason: TestEnded
> input.voltage: 224.77
> outlet.group.0.delay.reboot: 8
> outlet.group.0.delay.shutdown: 0
> outlet.group.0.delay.start: 0
> outlet.group.0.name: Unswitched Group
> outlet.group.1.delay.reboot: 8
> outlet.group.1.delay.shutdown: 90
> outlet.group.1.delay.start: 0
> outlet.group.1.name: Outlet Group 1
> outlet.group.2.delay.reboot: 8
> outlet.group.2.delay.shutdown: 90
> outlet.group.2.delay.start: 0
> outlet.group.2.name: Outlet Group 2
> outlet.group.3.delay.reboot: 8
> outlet.group.3.delay.shutdown: 90
> outlet.group.3.delay.start: 0
> outlet.group.3.name: Outlet Group 3
> outlet.group.count: 2
> output.current: 0.00
> output.frequency: 60.00
> output.voltage: 207.62
> ups.delay.reboot: 8
> ups.delay.shutdown: 0
> ups.delay.start: 0
> ups.efficiency: LoadTooLow
> ups.firmware: UPS 15.5
> ups.id: APC UPS
> ups.load: 0.00
> ups.mfr: American Power Conversion
> ups.mfr.date: 2020-08-10
> ups.model: Smart-UPS SRT3000
> ups.power: 0.00
> ups.power.nominal: 3000
> ups.realpower: 0.00
> ups.realpower.nominal: 2700
> ups.serial: AS2032296523
> ups.status: OL
> ups.timer.reboot: -1
> ups.timer.shutdown: -1
> u

Re: [Nut-upsuser] APC Modbus support is finally here!

[Jim Klimov via Nut-upsuser]

Got an update for APC Modbus users: a new PR is waiting for real-life
testing for settable variables and instant commands support.

https://github.com/networkupstools/nut/pull/2184

As before, a custom build of libmodbus may be needed for USB support
(detailed in the earlier PR), but Serial and TCP may already be well served
by a distro near you!

Jim

On Sun, Oct 22, 2023, 01:08 Jim Klimov  wrote:

> Hello fellow NUTs :)
>
>   It is my great pleasure to get a bit of sunshine from other people's
> work, and announce that the initial pull request for `apc_modbus` NUT
> driver has recently been merged to the main NUT codebase, so it would be
> part of an eventual 2.8.1 release. Great thanks go to Axel Gembe for the
> implementation, and to numerous community members for testing as well as
> their bug-fix and feature suggestions. It is my understanding that some
> thanks also goes to the apcupsd project that served as inspiration for data
> points that we can collect from the devices, as well as for its unfortunate
> development inactivity that convinced someone to step up and implement a
> native NUT driver for the "new" APC devices (~2010+) which all but
> deprecated USB HID support. Really, this feature was very long awaited!
>
>   At the moment the driver is "read-only", with commands and variables to
> be implemented later (hopefully some coming before 2.8.1 cut-off point). It
> can be used with the already published and packaged libmodbus versions for
> Serial-port and TCP support (with add-in network management cards). However
> please note that USB support is not currently part of the upstream library,
> but rather is provided by a fork (PR pending). It is not certain
> whether/when exactly such a feature will appear in the upstream library
> project - it does not seem very actively maintained at the moment :\
>
>   For more details please see
> https://github.com/networkupstools/nut/pull/2063 and
> https://github.com/networkupstools/nut/issue/139.
>
> Jim Klimov
>
>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] NUT v2.8.1 is released

[Jim Klimov via Nut-upsuser]

NOTE for packagers (and other builders of NUT release tarball):

Got an ERRATA to NUT v2.8.1:
*
https://github.com/networkupstools/nut/pull/2155/commits/2842201db26468a1eb1bf579e8b2fbf7538c5076

Probably should have a short cycle before a NUT v2.8.2 with smaller scope
than originally anticipated :\

In the meanwhile, packages of NUT v2.8.1 are encouraged to apply a small
patch per referenced commit.

Jim


On Tue, Oct 31, 2023 at 11:51 PM Jim Klimov  wrote:

> ...it was almost midnight, Cinderella became a pumpkin, and NUT was
> released!..
>
> Trick or treat?!
>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

[Nut-upsuser] Should upsd abort if one if LISTEN addresses is not available?

[Jim Klimov via Nut-upsuser]

Cheers all,

  Issue https://github.com/networkupstools/nut/issues/723 was brought up
recently, and I've re-verified it with the current codebase that it still
happens.

  The crux of it is that if upsd can LISTEN to some but not all addresses,
it aborts because "no listening interface available" and worse - does so
inconsistently (seems to depend on whether the *first* listed address
works).

  A fix (to count if at least one address either is or isn't accessible) is
not complicated technically; a bigger question is which behavior would be
"right" with regard to security(?) vs. usability? What do other networked
servers do - so we might follow deterministic suit and claim least-surprise?

Jim
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

[Nut-upsuser] NUT v2.8.1 is released

[Jim Klimov via Nut-upsuser]

...it was almost midnight, Cinderella became a pumpkin, and NUT was
released!..

Trick or treat?!
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] FSD sequence: Waiting for bigger and slower clients before cutting power

[Jim Klimov via Nut-upsuser]

Hello again :)

> Aren't the drivers daemonized and isn't it the drivers that kill power
already?

Historically, a mixed bag: they are daemonized while monitoring, then they
exit (or are killed) as part of shutdown, and then a late-shutdown script
(historically a patch to rc.halt or similar init-script - this integration
depends a lot on the OS and its service management framework, whether we
can inject late-shutdown logic at all) would check that we are in FSD mode
and then would call the driver binary again which connects to the device
again and tells it to power off.

With recent work on master branch, a possibility was introduced to use the
running driver daemon to send such a command to the UPS; however it would
need some rework of OS integration to not kill the daemon, retain the
communication sockets available, etc. - so probably not something instantly
usable for the out-of-the-box shutdown routine today.

> The manual makes a significant point of the idea that when an FSD event
occurs, everything should be shut down and the power cut so that the UPS
later will power everything back up again, whereas if some consumers are
shut down early, they won't automatically come back up.

To my knowledge, that stance remains. It is generally complicated to
orchestrate revival of a rack full of servers from partially-off state,
with some databases depending on storage and apps depending on databases,
etc. - and especially with legacy systems lacking some cross-server service
health and dependency tracking. So the safe approach is to power everything
off and then start up consistently and predictably. After all, this chain
of events is something tested by every power-on of the data room, unlike
any other random situations :) Of course, if a particular deployment can
take advantage of their local tools (say, everything is a single Kubernetes
farm and all nodes know each other's health), solutions specific to such
use-cases can differ from NUT's generally suggested safe default behavior.
If blueprints to such optimized solutions can be shared as part of NUT FAQ
or Wiki - so much the better :)

Regarding power coming back after our shutdown began, and if we can not
power-cycle the UPS when this routine ends (e.g. poor hardware support),
then other than WoL packets, the late-shutdown integration noted above can
also be used (if it can) on the NUT-client systems. If an upsmon client has
caused an FSD shutdown, the client system can just sleep for a long time
and reboot programmatically. If the battery dies during this time - no
loss. If the UPS stays up, servers come back after some time.

> I figure it'd be better if the primary could shut down as soon as it's
safe to do so rather than waiting for a fixed amount of time.

Here we balance opposing goals :) If you want the heavy-weight secondary
servers to take time for a shut down (assuming battery can handle it),
before the NUT primary is green-lit to proceed with its shut-down and
complete it by cutting the UPS power, then you wait for all secondary
upsmons to log off. As soon as they do, it is considered safe for the
primary to proceed (it does not wait "for a fixed time" beyond that).

Currently the primary does wait for a (configurable) fixed time and proceed
with its shutdown even if secondaries did not log off.

Makes sense for such a primary to not have long-stopping services of its
own, which would rely on some large-file consistency etc. - the battery
would be running on fumes during its shutdown and power might disappear any
time. Something lightweight (service-wise) like a firewall machine or a
dedicated Raspberry might be a good choice. Perhaps some integration via
upssched (or further development work in upsmon; or maybe using a separate
secondary upsmon client with a special SHUTDOWNCMD on the same machine)
could ensure that the NUT primary host would stop its heavy services (if
any) as soon as it tells other clients to stop themselves. This way there
would be nothing important running except NUT on this primary system by the
time that the primary upsmon proceeds to shut down its host server.

As part of this discussion, https://github.com/networkupstools/nut/pull/2133
was merged and added a way for the secondary upsmons to NOT exit as soon as
they called their SHUTDOWNCMD - now alternatives exist for upsmon to wait
for a specified time and then exit, or to never exit on its own accord (but
to honour e.g. a SIGTERM when its OS service is finally told to go down, up
to the sysadmins to make sure this happens after all the heavy services are
safely parked). This is available on master branch now, and should be part
of NUT v2.8.1 release soon.

Hope this helps,
Jim Klimov


On Tue, Oct 31, 2023 at 11:27 AM Magnus Holmgren <
magnus.holmg...@milientsoftware.com> wrote:

> fredag 27 oktober 2023 20:07:58 CET skrev  Jim Klimov:
> > Hi, this does sound like a useful idea - although for the principle of
> > least surprise and for variation in deployments, I'd 

Re: [Nut-upsuser] [Nut-upsdev] release?

[Jim Klimov via Nut-upsuser]

Hello all,

  Thanks to everyone who chimed in with tests, ideas and even freshly
confirmed regressions introduced by NUT v2.8.0 release compared to v2.7.4
(yes, there were after all a few eggs broken to make that omelette, with
all the code clean-up that went into it), so now I feel more confident
about the upcoming release being usable out-of-the-box (e.g. packaged) for
more people than v2.8.0 "vanilla" happened to be in hindsight.

  Given the seasonal timing, we're still aiming for a Halloween Edition (oh
well, maybe just a release at a neat date...) so y'all have another day to
check the recent master branch buildability and behavior... perhaps with a
focus specifically on the changes that landed with the most recent fixes in
the past few days.

Thanks again,
Jim Klimov



On Fri, Oct 27, 2023 at 8:29 PM Jim Klimov  wrote:

> 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 up with the hope to
> release NUT v2.8.1 "during October" - there's only so few days to make it
> happen.
>
>   People are hereby welcome to give the current code a spin to try and
> discover any blocker issues, "or forever hold their silence" (well, till
> next release). I'm a bit concerned especially regarding real-life important
> behaviors like shutdown handling - there were several layers changes to
> `upsmon` regarding support of administrative-OFF, BYPASS and CALibration
> states vs. OL/OB and/or loss of connection to data server. Hopefully we
> tuned the state machine better with each iteration, but any glaring issues
> would better be found and fixed before the release. Some changes also
> arrived to the `nutshutdown` script that is typically part of
> systemd-shutdown endgame, but could be used in other platforms as well.
> Earlier changes since 2.8.0 also touched `upssched` and ability of driver
> daemons to initiate shutdown (as an alternative to killing the daemon and
> starting another copy for `drivername -K` action which would take time
> again to detect and initialize the device), for example, although the
> latter is primarily just an option for future integrations and is not
> immediately beneficial out of the box today.
>
>   Another important recent improvement is the addition of an `apc_modbus`
> driver to support the APC ModBus protocol (currently for read-only
> monitoring - I am not sure if development for commands and writable
> variables would land before the end of month).
>
>   Generally you can preview the live list of notable changes since 2.8.0
> release at
> https://networkupstools.org/docs/release-notes.chunked/NUT_Release_Notes.html#_planned_release_notes_for_nut_2_8_1_what_8217_s_new_since_2_8_0
> and for things that are expected to impact packaging and upgrades (whether
> by possibly breaking disruption, or by adding new ways to automate things
> more efficiently that the audience could benefit from) - at
> https://networkupstools.org/docs/release-notes.chunked/NUT_Upgrading_Notes.html#_changes_from_2_8_0_to_2_8_1
> - with such release notes publication also being a recent addition.
>
> Jim Klimov
>
>
> On Mon, Oct 2, 2023 at 5:50 PM Jim Klimov  wrote:
>
>> Seconding ...  or firsting, considering the recent call to testing hidden
>> somewhere in a recent mail post ;) Currently I'm aiming at cutting a NUT
>> 2.8.1 release during October.
>>
>> As a bit of self-imposed retrospective:
>>
>> I did hope for a faster (quarterly or so) cadence when I made the 2.8.0
>> release, but then a few issues came up as regressions of 2.8.0 and it
>> became a sort of crusade to fix them all before 2.8.1. Perhaps it was a
>> flawed decision (I can now see the benefits of issuing releases so
>> packaging can include the fixes as soon as serious flaws are discovered and
>> addressed).
>>
>> Another big wad of work (which is not necessarily a release blocker, but
>> happened to act as such) is an update of HCL (in NUT main sources) and DDL
>> (another repo). In particular, it felt important (maybe indeed wrong in
>> practice, especially in hind-sight) to have each release include the
>> reports of devices supported by it (or at least by the earlier codebase).
>> Many confirmations come from the current master branch state of that day,
>> so it is part of NUT support for the snapshot release.
>>
>> For now, myself and various GitHub issue-posters happen to be practically
>> going over different build scenarios to find recipe flaws and avoidable
>> warnings (especially with new compiler releases) that could compromise the
>> actual or perceived quality of the next NUT release. One puzzling case at
>> the moment is a failed `make distcheck` that I can't reproduce 

Re: [Nut-upsuser] usbhid-ups not loading with Arduino Leonardo on Ubuntu 23.10

[Jim Klimov via Nut-upsuser]

OTOH: I wonder whether, when it says "Claimed interface 2 successfully" it
got the right number of the correct (HID) one of many interfaces you likely
have there?.. :\

Jim


On Mon, Oct 30, 2023, 00:04 Kelly Byrd  wrote:

>
>
> Apologies for the long post. I'm trying to include what I hope are the
> relevant bits (output of lsusb -v and usbhid-ups)
>
> Long term goal: I've got a DIY UPS that I would like to get working with
> my QNAP NAS (which uses Linux and NUT underneath the hood)
> ...
>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Spammy notification-tech diagnostic message

[Jim Klimov via Nut-upsuser]

Would this help?

https://github.com/networkupstools/nut/pull/2136

Jim

On Sun, Oct 29, 2023 at 5:04 PM Vojtěch Hurčík  wrote:

> Thanks for the reply, it's only reported once per spawned process and what
> you say makes perfect sense in this light. A configuration toggle or
> environment variable also seems like a good idea, but I'm sure I or we can
> also live with the message being reported once per process as it currently
> is... looking forward to the stable release & thanks for everything!
>
> VH
>
> --- Original Message ---
> On Sunday, October 29th, 2023 at 16:22, Jim Klimov <
> jimklimov+...@gmail.com> wrote:
>
> Thanks for your concern.
>
> Technically, it is not about just systemd - other systems where launched
> processes that have ways to interact with some OS framework (like SMF,
> upstart, Windows services, docker/kubernetes, whatever) *and* such
> framework offers ways for services to inform they have started and e.g.
> dependencies can begin starting, with better precision than "we have forked
> off an init script and assume that this instant its service is fully ready".
>
> One bit that worries me in your report is "I am repeatedly getting these
> messages in my *syslog*" - does it mean you get them more often than once
> per uptime of each daemon (upsd, upsmon, driver)? Or that you reboot so
> often that the "noise" gets your eyes sore? :)
>
> I did initially have the opposite feedback in the beginning, about not
> having those notifications working and services set up for
> notification-based integration getting restarted by their OS framework
> because their startup allegedly timed out.
>
> I think this sort of behaviors with OS-dependent variations was supposed
> to become managed by envvars (e.g. offering a toggle to not make noise easy
> to set in packaged init-scripts etc.) but it seems that for this particular
> case one was not merged. Something similar was discussed about NUT daemon
> banner and a few other lines emitted at startup, which some people see as
> important post-mortem tool when inspecting logs or console dumps, and
> others treat as noise ("unless there's an error, I want to see nothing") -
> and frankly both stances have their merits for different audiences.
>
> Jim Klimov
>
>
> On Sun, Oct 29, 2023 at 2:45 PM Vojtěch Hurčík via Nut-upsuser <
> nut-upsuser@alioth-lists.debian.net> wrote:
>
>> Hello friends!
>>
>> With the upcoming NUT release there is one thing I would like to ask:
>>
>>-
>>
>>no notification tech defined, will not spam more about
>>
>>
>> I am repeatedly getting these messages in my *syslog* more recently
>> because I do not have *systemd* available to me on my distribution and
>> also do not want to use it.
>>
>> Maybe the debug level for such messages could be raised to 1 instead, as
>> they still seem a bit too spammy for something us, who don't use the
>> *systemd*, already know. At least then we would have a way to suppress
>> them...
>>
>> Vojtěch
>> ___
>> Nut-upsuser mailing list
>> Nut-upsuser@alioth-lists.debian.net
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>>
>
>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Spammy notification-tech diagnostic message

[Jim Klimov via Nut-upsuser]

Thanks for your concern.

Technically, it is not about just systemd - other systems where launched
processes that have ways to interact with some OS framework (like SMF,
upstart, Windows services, docker/kubernetes, whatever) *and* such
framework offers ways for services to inform they have started and e.g.
dependencies can begin starting, with better precision than "we have forked
off an init script and assume that this instant its service is fully ready".

One bit that worries me in your report is "I am repeatedly getting these
messages in my *syslog*" - does it mean you get them more often than once
per uptime of each daemon (upsd, upsmon, driver)? Or that you reboot so
often that the "noise" gets your eyes sore? :)

I did initially have the opposite feedback in the beginning, about not
having those notifications working and services set up for
notification-based integration getting restarted by their OS framework
because their startup allegedly timed out.

I think this sort of behaviors with OS-dependent variations was supposed to
become managed by envvars (e.g. offering a toggle to not make noise easy to
set in packaged init-scripts etc.) but it seems that for this particular
case one was not merged. Something similar was discussed about NUT daemon
banner and a few other lines emitted at startup, which some people see as
important post-mortem tool when inspecting logs or console dumps, and
others treat as noise ("unless there's an error, I want to see nothing") -
and frankly both stances have their merits for different audiences.

Jim Klimov


On Sun, Oct 29, 2023 at 2:45 PM Vojtěch Hurčík via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:

> Hello friends!
>
> With the upcoming NUT release there is one thing I would like to ask:
>
>-
>
>no notification tech defined, will not spam more about
>
>
> I am repeatedly getting these messages in my *syslog* more recently
> because I do not have *systemd* available to me on my distribution and
> also do not want to use it.
>
> Maybe the debug level for such messages could be raised to 1 instead, as
> they still seem a bit too spammy for something us, who don't use the
> *systemd*, already know. At least then we would have a way to suppress
> them...
>
> Vojtěch
> ___
> Nut-upsuser mailing list
> Nut-upsuser@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] My Back-UPS RS 1000 went haywire, any ideas?

[Jim Klimov via Nut-upsuser]

Is the battery old? PbAc ones usually last for 2-3 years and then degrade.
Should be a field-replaceable part.

Some 20 years ago I had an APC BackUPS become a glorified power strip every
few years, so when the wall power disappeared - load went down immediately.
It was also beeping about battery replacement (but in the closet, was not
often noticed quickly). This is also a way for you to check if the
situation is something like that - pull the cable and see if it holds up
for any non-trivial time ;)

Otherwise, maybe electronics went bad over time (dried capacitors etc.) so
the controller and its sensors are in fact going haywire. This might also
be replaceable, if you're good with soldering (or can find/hire someone who
is) or if warranty repair is still an option.

Finally, the UPS might partake in self-calibration, where it deliberately
discharges itself to check how long the battery holds up your load (maybe
the charge-level cycle also lets it keep the internal chemistry healthier).
Usually it powers itself back up from mains in the nick of time before it
would otherwise shutdown, if it guessed the timing correctly (e.g. battery
did not age too poorly since last test, and the load did not change too
much).

Hope this helps,
Jim Klimov


On Sat, Oct 28, 2023 at 5:28 PM Gennadiy Poryev via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:

> Hi,
>
> I am sorry for possible offtopic as this question is not quite
> NUT-related but I cannot imagine any other place with people of such
> deep and intimate knowledge of UPS behavior.
>
> One day all of a sudden my APC Back-UPS RS 1000 refused to go online
> (green led) even though mains was connected. I used upsc to see what is
> going on, and ups.status was "OB DISCHRG", battery.charge was slowly
> decreasing and input looked like this
>
> input.sensitivity: medium
> input.transfer.high: 264
> input.transfer.low: 194
> input.voltage: 182.0
> input.voltage.nominal: 230
>
> I took an external voltmeter and made sure that actual input voltage is
> around 223 V and is not changing. However, each successive run of upsc
> indicated drastically different "input.voltage", arbitrarily jumping
> from 160 V to 280 V. Besides this, no other values seemed abnormal.
>
> Is this something that can be fixed in-house? Or something widely known
> about this particular model and/or vendor? I'm puzzled. Please, advice.
> Sorry for the offtopic once again.
> ___
> Nut-upsuser mailing list
> Nut-upsuser@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] FSD sequence: Waiting for bigger and slower clients before cutting power

[Jim Klimov via Nut-upsuser]

Check it out now,
my NUT project braza!..

https://github.com/networkupstools/nut/pull/2133
https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests

Jim


On Fri, Oct 27, 2023 at 8:07 PM Jim Klimov  wrote:

> Hi, this does sound like a useful idea - although for the principle of
> least surprise and for variation in deployments, I'd rather have it as a
> (non-default state of a) configuration toggle that can be set via
> `upsmon.conf`: whether this particular client exits after processing FSD or
> not. The onus for the rest would be on general systems integration - e.g.
> ensure that init scripts `K*`ill the long-running services before they go
> after upsmon and upsd, or add a drop-in systemd config snippet for
> nut-monitor to not-conflict with "shutdown.target" (and half a dozen of its
> equivalents for halt/reboot/poweroff/...), and possibly to break the
> shutdown-dependency between nut-monitor/nut-server/nut-driver units.
>
> On a related note - there was lately work to allow daemonized drivers to
> kill power of the UPS (may be useful especially for devices with long
> protocol init times), with a safety switch to flip about this and actually
> allow the driver to issue killpower commands. So stopping driver daemons
> might eventually be not needed - but I'm not sure any OS integrations took
> note of this possibility yet. It was not officially released so far, just
> is in master branch.
>
> Note however that typically FSD happens when the power is critical.
> Definitions of that vary, as well as ability or not to set certain
> thresholds for when the device would emit (and a driver would relay) the
> low-battery condition. You might not physically have those 2 minutes worth
> of remaining battery charge to shut down the VMs or other long-stopping
> services (e.g. app servers to flush in-flight operations, and only later
> their databases) - more so with the probable storage I/O and power-draw
> burst to flush out databases or hibernate those VMs.
>
> In this case fiddling with upssched or setting up dummy-ups relays with an
> override for defining earlier trigger of critical state (usually by battery
> charge or time remaining) may fare better: your NUT primary server would
> seem to serve several UPSes (the "real" device and a few dummies with
> different "criticality" levels), and various secondary hosts would MONITOR
> the suitable dummy to begin their shutdown earlier into the outage. This
> approach may also be useful for Dan's post :)
>
> Jim
>
> On Fri, Oct 27, 2023 at 4:55 PM Magnus Holmgren <
> magnus.holmg...@milientsoftware.com> wrote:
>
>> Hi, and thanks for this great piece of free software! I've been meaning
>> to
>> sort this out for some time, but we don't get power outages that often,
>> fortunately...
>>
>> So, correct me if I'm wrong, but from the documentation at https://
>> networkupstools.org/docs/user-manual.chunked/
>> Configuration_notes.html#UPS_shutdown, and also reading upsmon.c, when a
>> UPS
>> goes OB LB (assuming we have a single UPS connected to a primary and
>> supplying
>> power to the primary and some number of secondaries), the primary
>> notifies the
>> secondaries, the secondaries wait for FINALDELAY and then execute
>> SHUTDOWNCMD
>> immediately followed by exiting, thereby disconnecting from the primary,
>> and
>> the primary, after seeing all secondaries disconnect, proceed with its
>> shutdown (only waiting for FINALDELAY), which ends with telling the UPS
>> to cut
>> the power (without delay too, right?).
>>
>> Again, correct me if I'm wrong, Is it only I who find this a bit flawed?
>> I
>> would like for the secondaries to stay connected until they shut down. We
>> have
>> a server with a bunch of virtual machines on, and they can take a couple
>> of
>> minutes to shut down. Otherwise the primary can easily cut the power
>> prematurely. Avoiding this, it seems, could pretty easily be accomplished
>> by
>> having upsmon wait, perhaps in a separate loop, for the INT/TERM/QUIT
>> signal
>> (it would still be necessary to configure the service manager such that
>> upsmon
>> is terminated as late as possible). The primary could start shutting down
>> its
>> services in the meantime, but upsmon would hold the poweroff until the
>> secondaries have disconnected (or HOSTSYNC expires).
>>
>> Surely this would be better than cranking up FINALDELAY on the primary
>> and
>> always waiting for a fixed period of time, as suggested in
>> https://alioth-lists.debian.net/pipermail/nut-upsuser/2012-April/007550.html?
>> I guess I could
>> try writing a SHUTDOWNCMD script that doesn't exit until most other
>> services
>> have also done so, taking care not to create a deadlock situation.
>>
>> Another option would be to use upssched to shut down the "big rig"
>> earlier. It
>> just seems unsatisfying to me that upssched is entirely time-based. It
>> would
>> be nice if it were easier to trigger off 

Re: [Nut-upsuser] [Nut-upsdev] release?

[Jim Klimov via Nut-upsuser]

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 up with the hope to
release NUT v2.8.1 "during October" - there's only so few days to make it
happen.

  People are hereby welcome to give the current code a spin to try and
discover any blocker issues, "or forever hold their silence" (well, till
next release). I'm a bit concerned especially regarding real-life important
behaviors like shutdown handling - there were several layers changes to
`upsmon` regarding support of administrative-OFF, BYPASS and CALibration
states vs. OL/OB and/or loss of connection to data server. Hopefully we
tuned the state machine better with each iteration, but any glaring issues
would better be found and fixed before the release. Some changes also
arrived to the `nutshutdown` script that is typically part of
systemd-shutdown endgame, but could be used in other platforms as well.
Earlier changes since 2.8.0 also touched `upssched` and ability of driver
daemons to initiate shutdown (as an alternative to killing the daemon and
starting another copy for `drivername -K` action which would take time
again to detect and initialize the device), for example, although the
latter is primarily just an option for future integrations and is not
immediately beneficial out of the box today.

  Another important recent improvement is the addition of an `apc_modbus`
driver to support the APC ModBus protocol (currently for read-only
monitoring - I am not sure if development for commands and writable
variables would land before the end of month).

  Generally you can preview the live list of notable changes since 2.8.0
release at
https://networkupstools.org/docs/release-notes.chunked/NUT_Release_Notes.html#_planned_release_notes_for_nut_2_8_1_what_8217_s_new_since_2_8_0
and for things that are expected to impact packaging and upgrades (whether
by possibly breaking disruption, or by adding new ways to automate things
more efficiently that the audience could benefit from) - at
https://networkupstools.org/docs/release-notes.chunked/NUT_Upgrading_Notes.html#_changes_from_2_8_0_to_2_8_1
- with such release notes publication also being a recent addition.

Jim Klimov


On Mon, Oct 2, 2023 at 5:50 PM Jim Klimov  wrote:

> Seconding ...  or firsting, considering the recent call to testing hidden
> somewhere in a recent mail post ;) Currently I'm aiming at cutting a NUT
> 2.8.1 release during October.
>
> As a bit of self-imposed retrospective:
>
> I did hope for a faster (quarterly or so) cadence when I made the 2.8.0
> release, but then a few issues came up as regressions of 2.8.0 and it
> became a sort of crusade to fix them all before 2.8.1. Perhaps it was a
> flawed decision (I can now see the benefits of issuing releases so
> packaging can include the fixes as soon as serious flaws are discovered and
> addressed).
>
> Another big wad of work (which is not necessarily a release blocker, but
> happened to act as such) is an update of HCL (in NUT main sources) and DDL
> (another repo). In particular, it felt important (maybe indeed wrong in
> practice, especially in hind-sight) to have each release include the
> reports of devices supported by it (or at least by the earlier codebase).
> Many confirmations come from the current master branch state of that day,
> so it is part of NUT support for the snapshot release.
>
> For now, myself and various GitHub issue-posters happen to be practically
> going over different build scenarios to find recipe flaws and avoidable
> warnings (especially with new compiler releases) that could compromise the
> actual or perceived quality of the next NUT release. One puzzling case at
> the moment is a failed `make distcheck` that I can't reproduce anywhere,
> which involves apparent lack of man page source files in the build area -
> which I can't make happen even on a minimally installed container. FWIW =>
> https://github.com/networkupstools/nut/issues/2081
>
> Some other issues remain marked in the 2.8.1 milestone, some recently
> addressed, others pushed to later releases, most of the remainder being
> about HCL/DDL updates.
>
> A couple of driver contributions are actively brewing (including
> long-awaited APC-ModBus support), so I'm looking out for the opportunity to
> merge them too, so the upcoming release lets the greater public see them
> and report back...
>
> Jim
>
>
> On Mon, Oct 2, 2023 at 5:06 PM Greg Troxel  wrote:
>
>> I stuck in a comment in an issue, but I think we're overdue, picking 6
>> months as arbitrary.
>>
>> I just created a snapshot privately.  It passes make check on netbsd 9
>> amd64.  I am updating pkgsrc-wip, which involves adjusting a lot of
>> packages 

Re: [Nut-upsuser] FSD sequence: Waiting for bigger and slower clients before cutting power

[Jim Klimov via Nut-upsuser]

Hi, this does sound like a useful idea - although for the principle of
least surprise and for variation in deployments, I'd rather have it as a
(non-default state of a) configuration toggle that can be set via
`upsmon.conf`: whether this particular client exits after processing FSD or
not. The onus for the rest would be on general systems integration - e.g.
ensure that init scripts `K*`ill the long-running services before they go
after upsmon and upsd, or add a drop-in systemd config snippet for
nut-monitor to not-conflict with "shutdown.target" (and half a dozen of its
equivalents for halt/reboot/poweroff/...), and possibly to break the
shutdown-dependency between nut-monitor/nut-server/nut-driver units.

On a related note - there was lately work to allow daemonized drivers to
kill power of the UPS (may be useful especially for devices with long
protocol init times), with a safety switch to flip about this and actually
allow the driver to issue killpower commands. So stopping driver daemons
might eventually be not needed - but I'm not sure any OS integrations took
note of this possibility yet. It was not officially released so far, just
is in master branch.

Note however that typically FSD happens when the power is critical.
Definitions of that vary, as well as ability or not to set certain
thresholds for when the device would emit (and a driver would relay) the
low-battery condition. You might not physically have those 2 minutes worth
of remaining battery charge to shut down the VMs or other long-stopping
services (e.g. app servers to flush in-flight operations, and only later
their databases) - more so with the probable storage I/O and power-draw
burst to flush out databases or hibernate those VMs.

In this case fiddling with upssched or setting up dummy-ups relays with an
override for defining earlier trigger of critical state (usually by battery
charge or time remaining) may fare better: your NUT primary server would
seem to serve several UPSes (the "real" device and a few dummies with
different "criticality" levels), and various secondary hosts would MONITOR
the suitable dummy to begin their shutdown earlier into the outage. This
approach may also be useful for Dan's post :)

Jim

On Fri, Oct 27, 2023 at 4:55 PM Magnus Holmgren <
magnus.holmg...@milientsoftware.com> wrote:

> Hi, and thanks for this great piece of free software! I've been meaning to
> sort this out for some time, but we don't get power outages that often,
> fortunately...
>
> So, correct me if I'm wrong, but from the documentation at https://
> networkupstools.org/docs/user-manual.chunked/
> Configuration_notes.html#UPS_shutdown, and also reading upsmon.c, when a
> UPS
> goes OB LB (assuming we have a single UPS connected to a primary and
> supplying
> power to the primary and some number of secondaries), the primary notifies
> the
> secondaries, the secondaries wait for FINALDELAY and then execute
> SHUTDOWNCMD
> immediately followed by exiting, thereby disconnecting from the primary,
> and
> the primary, after seeing all secondaries disconnect, proceed with its
> shutdown (only waiting for FINALDELAY), which ends with telling the UPS to
> cut
> the power (without delay too, right?).
>
> Again, correct me if I'm wrong, Is it only I who find this a bit flawed? I
> would like for the secondaries to stay connected until they shut down. We
> have
> a server with a bunch of virtual machines on, and they can take a couple
> of
> minutes to shut down. Otherwise the primary can easily cut the power
> prematurely. Avoiding this, it seems, could pretty easily be accomplished
> by
> having upsmon wait, perhaps in a separate loop, for the INT/TERM/QUIT
> signal
> (it would still be necessary to configure the service manager such that
> upsmon
> is terminated as late as possible). The primary could start shutting down
> its
> services in the meantime, but upsmon would hold the poweroff until the
> secondaries have disconnected (or HOSTSYNC expires).
>
> Surely this would be better than cranking up FINALDELAY on the primary and
> always waiting for a fixed period of time, as suggested in
> https://alioth-lists.debian.net/pipermail/nut-upsuser/2012-April/007550.html?
> I guess I could
> try writing a SHUTDOWNCMD script that doesn't exit until most other
> services
> have also done so, taking care not to create a deadlock situation.
>
> Another option would be to use upssched to shut down the "big rig"
> earlier. It
> just seems unsatisfying to me that upssched is entirely time-based. It
> would
> be nice if it were easier to trigger off battery.charge or battery.runtime
> going below arbitrary values instead of just the on battery and low
> battery
> statuses.
>
> How do others solve this?
>
> --
> Magnus Holmgren
> ./¯\_/¯\. Milient
> (also holmg...@debian.org)
>
>
>
> ___
> Nut-upsuser mailing list
> Nut-upsuser@alioth-lists.debian.net
> 

[Nut-upsuser] APC Modbus support is finally here!

[Jim Klimov via Nut-upsuser]

Hello fellow NUTs :)

  It is my great pleasure to get a bit of sunshine from other people's
work, and announce that the initial pull request for `apc_modbus` NUT
driver has recently been merged to the main NUT codebase, so it would be
part of an eventual 2.8.1 release. Great thanks go to Axel Gembe for the
implementation, and to numerous community members for testing as well as
their bug-fix and feature suggestions. It is my understanding that some
thanks also goes to the apcupsd project that served as inspiration for data
points that we can collect from the devices, as well as for its unfortunate
development inactivity that convinced someone to step up and implement a
native NUT driver for the "new" APC devices (~2010+) which all but
deprecated USB HID support. Really, this feature was very long awaited!

  At the moment the driver is "read-only", with commands and variables to
be implemented later (hopefully some coming before 2.8.1 cut-off point). It
can be used with the already published and packaged libmodbus versions for
Serial-port and TCP support (with add-in network management cards). However
please note that USB support is not currently part of the upstream library,
but rather is provided by a fork (PR pending). It is not certain
whether/when exactly such a feature will appear in the upstream library
project - it does not seem very actively maintained at the moment :\

  For more details please see
https://github.com/networkupstools/nut/pull/2063 and
https://github.com/networkupstools/nut/issue/139.

Jim Klimov
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] URL upsstats.cgi DOES not show UPS

[Jim Klimov via Nut-upsuser]

Glad it worked out!

> I have not made ANY changes to hosts.conf in my server.

So was this in the end a wrong assumption on your side, or was some error
in the file shipped by packaging (or even NUT upstream sources)?

Jim

On Wed, Oct 11, 2023 at 5:25 AM S K  wrote:

> Can close the thread! Had a typo in hosts.conf
>
> On Tuesday, October 10, 2023 at 10:07:12 PM EDT, S K via Nut-upsuser <
> nut-upsuser@alioth-lists.debian.net> wrote:
>
>
>
> sudo tcpdump --interface=eth0 -n host 192.168.0.20 and port 3493
> tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
> listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144
> bytes
> 21:55:26.538305 IP 192.168.0.29.36942 > 192.168.0.20.3493: Flags [P.], seq
> 110794:110822, ack 3026019235, win 1004, options [nop,nop,TS val
> 2185119584 ecr 4073717875], length 28
> 21:55:26.539061 IP 192.168.0.20.3493 > 192.168.0.29.36942: Flags [P.], seq
> 1:30, ack 28, win 509, options [nop,nop,TS val 4073722923 ecr 2185119584],
> length 29
> 21:55:26.539249 IP 192.168.0.29.36942 > 192.168.0.20.3493: Flags [.], ack
> 30, win 1004, options [nop,nop,TS val 2185119585 ecr 4073722923], length 0
> 21:55:31.551433 IP 192.168.0.29.36942 > 192.168.0.20.3493: Flags [P.], seq
> 28:56, ack 30, win 1004, options [nop,nop,TS val 2185124597 ecr
> 4073722923], length 28
> 21:55:31.552211 IP 192.168.0.20.3493 > 192.168.0.29.36942: Flags [P.], seq
> 30:59, ack 56, win 509, options [nop,nop,TS val 4073727937 ecr 2185124597],
> length 29
> 21:55:31.552406 IP 192.168.0.29.36942 > 192.168.0.20.3493: Flags [.], ack
> 59, win 1004, options [nop,nop,TS val 2185124598 ecr 4073727937], length 0
> 21:55:36.567843 IP 192.168.0.29.36942 > 192.168.0.20.3493: Flags [P.], seq
> 56:84, ack 59, win 1004, options [nop,nop,TS val 2185129614 ecr
> 4073727937], length 28
> 21:55:36.568645 IP 192.168.0.20.3493 > 192.168.0.29.36942: Flags [P.], seq
> 59:88, ack 84, win 509, options [nop,nop,TS val 4073732954 ecr 2185129614],
> length 29
> 21:55:36.568827 IP 192.168.0.29.36942 > 192.168.0.20.3493: Flags [.], ack
> 88, win 1004, options [nop,nop,TS val 2185129615 ecr 4073732954], length 0
> 21:55:41.600681 IP 192.168.0.29.36942 > 192.168.0.20.3493: Flags [P.], seq
> 84:112, ack 88, win 1004, options [nop,nop,TS val 2185134647 ecr
> 4073732954], length 28
> 21:55:41.601481 IP 192.168.0.20.3493 > 192.168.0.29.36942: Flags [P.], seq
> 88:117, ack 112, win 509, options [nop,nop,TS val 4073737988 ecr
> 2185134647], length 29
> 21:55:41.601764 IP 192.168.0.29.36942 > 192.168.0.20.3493: Flags [.], ack
> 117, win 1004, options [nop,nop,TS val 2185134647 ecr 4073737988], length 0
> 21:55:46.621153 IP 192.168.0.29.36942 > 192.168.0.20.3493: Flags [P.], seq
> 112:140, ack 117, win 1004, options [nop,nop,TS val 2185139667 ecr
> 4073737988], length 28
> 21:55:46.621968 IP 192.168.0.20.3493 > 192.168.0.29.36942: Flags [P.], seq
> 117:146, ack 140, win 509, options [nop,nop,TS val 4073743009 ecr
> 2185139667], length 29
>
>
> On Tuesday, October 10, 2023 at 05:22:28 PM EDT, Jim Klimov <
> jimklimov+...@gmail.com> wrote:
>
>
> Well... one troubleshooting idea is to use a sniffer (ngrep, tcpdump,
> etc.) to see the dialogue between the web server and upsd data server (
> 192.168.0.20:3493), to check if anything looks fishy there. Maybe some
> firewalls, SELinux after an update, etc. tempered up and there is no
> network chatter from http context to outside unless allowed (`setenforce 0`
> can help quickly confirm or rule out involvement of SELinux).
>
> Another idea is to hack around `drivers/upsstatus.c` to add debug messages
> around connections (at least `fprintf(stderr...)` but if this matures to
> become a PR - then ideally `upsdebugx` and some way to pass debug verbosity
> into the program - e.g. config file).
>
> On Tue, Oct 10, 2023 at 9:03 PM S K via Nut-upsuser <
> nut-upsuser@alioth-lists.debian.net> wrote:
>
> Hey the NUT sever (http://192.168.0.29/) was working fine and the URL
> http://192.168.0.29/cgi-bin/nut/upsstats.cgi did show me all the UPS
> slaves - but all of a sudden one particular slave is not showing up.The
> one that is not showing up IP is 192.168.0.20 and the following command
> in NUT server
>
> upsc upshpomv@192.168.0.20
>
> Does respond with
>
> Init SSL without certificate database
> battery.charge: 100
> battery.charge.low: 10
> battery.charge.warning: 20
> battery.mfr.date: CPS
> battery.runtime: 3270
> battery.runtime.low: 300
> battery.type: PbAcid
> battery.voltage: 24.0
> battery.voltage.nominal: 24
> device.mfr: CPS
> device.model: CP1350PFCLCD
> device.serial: 
> device.type: ups
> driver.name: usbhid-ups
> driver.parameter.pollfreq: 30
> driver.parameter.pollinterval: 15
> driver.parameter.port: auto
> driver.parameter.synchronous: no
> driver.version: 2.7.4
> driver.version.data: CyberPower HID 0.4
> driver.version.internal: 0.41
> input.transfer.high: 139
> input.transfer.low: 88
> input.voltage: 117.0
> input.voltage.nominal: 120
> 

Re: [Nut-upsuser] URL upsstats.cgi DOES not show UPS

[Jim Klimov via Nut-upsuser]

Well... one troubleshooting idea is to use a sniffer (ngrep, tcpdump, etc.)
to see the dialogue between the web server and upsd data server (
192.168.0.20:3493), to check if anything looks fishy there. Maybe some
firewalls, SELinux after an update, etc. tempered up and there is no
network chatter from http context to outside unless allowed (`setenforce 0`
can help quickly confirm or rule out involvement of SELinux).

Another idea is to hack around `drivers/upsstatus.c` to add debug messages
around connections (at least `fprintf(stderr...)` but if this matures to
become a PR - then ideally `upsdebugx` and some way to pass debug verbosity
into the program - e.g. config file).

On Tue, Oct 10, 2023 at 9:03 PM S K via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:

> Hey the NUT sever (http://192.168.0.29/) was working fine and the URL
> http://192.168.0.29/cgi-bin/nut/upsstats.cgi did show me all the UPS
> slaves - but all of a sudden one particular slave is not showing up.The
> one that is not showing up IP is 192.168.0.20 and the following command
> in NUT server
>
> upsc upshpomv@192.168.0.20
>
> Does respond with
>
> Init SSL without certificate database
> battery.charge: 100
> battery.charge.low: 10
> battery.charge.warning: 20
> battery.mfr.date: CPS
> battery.runtime: 3270
> battery.runtime.low: 300
> battery.type: PbAcid
> battery.voltage: 24.0
> battery.voltage.nominal: 24
> device.mfr: CPS
> device.model: CP1350PFCLCD
> device.serial: 
> device.type: ups
> driver.name: usbhid-ups
> driver.parameter.pollfreq: 30
> driver.parameter.pollinterval: 15
> driver.parameter.port: auto
> driver.parameter.synchronous: no
> driver.version: 2.7.4
> driver.version.data: CyberPower HID 0.4
> driver.version.internal: 0.41
> input.transfer.high: 139
> input.transfer.low: 88
> input.voltage: 117.0
> input.voltage.nominal: 120
> output.voltage: 141.0
> ups.beeper.status: enabled
> ups.delay.shutdown: 20
> ups.delay.start: 30
> ups.load: 12
> ups.mfr: CPS
> ups.model: CP1350PFCLCD
> ups.productid: 0501
> ups.realpower.nominal: 810
> ups.serial: 
> ups.status: OL
> ups.test.result: No test initiated
> ups.timer.shutdown: -60
> ups.timer.start: -60
> ups.vendorid: 0764
>
>
> Hence I know the slave does respond to server but why is it now showing in
> the http://192.168.0.29/cgi-bin/nut/upsstats.cgi  - BTW I have not made
> ANY changes to hosts.conf in my server. Any idea how to troubleshoot?
>
> ___
> Nut-upsuser mailing list
> Nut-upsuser@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] New Tool: nut2mqtt

[Jim Klimov via Nut-upsuser]

Thanks, updated. Should get published soon.

Jim

On Tue, Oct 3, 2023 at 3:05 AM Raymond Burkholder 
wrote:

> Hello,
>
> On the page https://networkupstools.org/projects.html, I didn't see a
> general purpose Nut to MQTT client.
>
> I've written one in C++.  Source can be found at:
> https://github.com/rburkholder/nut2mqtt
>
> It iterates all devices found with the client and publishes select
> variables to a provided MQTT queue for each device found.
>
> --
> Raymond
> https://blog.raymond.burkholder.net/
>
> ___
> Nut-upsuser mailing list
> Nut-upsuser@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] EATON device.model 5E 1500i

[Jim Klimov via Nut-upsuser]

Kinda forgot about this aspect, thanks for reminding.

 More technical and historical detail here:
https://github.com/networkupstools/nut/issues/630 ... referring to one's
own earlier post - how typical of internet these days! ;)

Jim

On Thu, Sep 21, 2023, 16:17 Eyal Lebedinsky  wrote:

>
> On 21/09/2023 19.17, Jeff Goldrich via Nut-upsuser wrote:
> > Looking for support on my Eaton UPS. Model 5E 1500i  USB.
> >
> > The 5E 650i and 5E 1100i is supported but not the 5E 1500i.
> >
> > Trying to use with Truenas. Any help would be appreciated.
> >
> > Thank You
>
> I had this UPS in 2019 for a few months. I see that I added a boot option
> 'usbhid.quirks=0x0463:0x:0x08'
> to get it working.
>
> I do not remember where I got this info and I do not remember what was the
> problem it fixed.
>
> HTH
>
> --
> Eyal Lebedinsky (e...@eyal.emu.id.au)
>
> ___
> Nut-upsuser mailing list
> Nut-upsuser@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

[Nut-upsuser] Heads-up: now it will be possible to manually select `subdriver` in `usbhid-ups`, and... looking at a release!

[Jim Klimov via Nut-upsuser]

Hello all,

  Over the past years there have been several cases where I wished we could
specify an USB HID subdriver as easily as a subdriver/protocol combo in
nutdrv_qx or blazer drivers, or a MIB in snmp-ups driver. But never got
around to implementing that (nor convinced somebody else to do it).

  Finally, with https://github.com/networkupstools/nut/pull/2058 (currently
in CI testing), this ability should appear. In particular, it can help with
a sore point of "phoenixtec/liebert" and "mge" mappings which respond to
the same VID:PID identification and try to guess if some other clues about
the device fit the particular subdriver. Some reported regressions of NUT
v2.8.0 vs. v2.7.4 were about changes to this guesswork.

  On a grander scale, I think this is among the last large NUT-development
blockers I had burdening my conscience before unleashing a new release
(lack of which, in turn, makes many people sad about not receiving
long-completed bug fixes). Quite a few others were merged during recent
weeks, and hopefully packages based on current code would be easier for
end-users to deploy and for us as a community to remotely debug, than with
earlier releases.

  I think I'll wait a while for currently active PRs to complete, if they
would do so soon, but it seems prudent to ask the greater NUT user and
developer community to test custom builds of master branch with their
devices and use-cases, to help ensure no new bugs get delivered this time ;)

  Take a look at NEWS.adoc for the whole feature change set since the
previous release, and UPGRADING.adoc for highlights of the changes that are
expected to impact existing deployments and/or packaging recipes.

  On my side, I still have plans for some documentation changes, including
the tracking of HCL/DDL reports which are not yet formally logged, but this
is a chore that may spill over into the next release and should not be a
blocker. Help is welcome, though - example chores summarized at
https://github.com/networkupstools/nut-ddl/pull/38 and
https://github.com/networkupstools/nut/pull/2059 going from
https://github.com/orgs/networkupstools/projects/3/views/1 ;)

Jim
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Info for decoding report from UPS

[Jim Klimov via Nut-upsuser]

One tool for one job :)

You can have another protocol client with GUI. NUT includes a python (qt5
or gtk) set of UI clients.

On Thu, Sep 14, 2023, 17:06 Alessandro Mandelli 
wrote:

> It works, but I got an allergy for CLI
>
>
>
> PS C:\Program Files (x86)\NUT\bin> .\upsc.exe UPS
>
> device.mfr: Richcomm dry-contact to USB solution
>
> device.model: UPS USB MON V1.4
>
> device.serial: unknown
>
> device.type: ups
>
> driver.debug: 0
>
> driver.flag.allow_killpower: 0
>
> driver.name: richcomm_usb
>
> driver.parameter.pollinterval: 2
>
> driver.parameter.port: auto
>
> driver.parameter.synchronous: auto
>
> driver.state: quiet
>
> driver.version: 2.8.0-2350-g9c6b22e61
>
> driver.version.internal: 0.12
>
> ups.mfr: Richcomm dry-contact to USB solution
>
> ups.model: UPS USB MON V1.4
>
> ups.productid: 1234
>
> ups.serial: unknown
>
> ups.status: OL
>
> ups.vendorid: 0925
>
>
>
>
>
>
>
>
>
> *Da:* Jim Klimov 
> *Inviato:* giovedì 14 settembre 2023 15:21
> *A:* Alessandro Mandelli 
> *Cc:* Arnaud Quette via Nut-upsuser 
> *Oggetto:* Re: [Nut-upsuser] Info for decoding report from UPS
>
>
>
> Ah, I see. My take is that using or adapting something that exists is
> easier than starting from scratch - but to each their own. Surely you'll
> learn a lot :)
>
> Still, just to clarify: after the NUT v2.8.0 release I began a slow
> revival of old NUT for Windows effort (abandoned a decade ago at 2.6.5-8
> based branch), so now there are regular native win64 (CLI) builds regularly
> produced by CI, as a tarball of a result of `make install` area (plus the
> dependency DLLs). They can run in-place and do work for testing NUT
> behaviors on the platform, but are not "properly packaged" yet, have no
> installer, and indeed may need fiddling with USB libraries in particular
> (so that Windows "HID Battery" driver won't get in the way and would let
> libusb handle that node for NUT), but still sounds easier to give this a
> shot before constructing something new. This OS integration bit may have
> worked in that older 2.6.5 codebase, just I had no time to look hard at
> this recently, and nobody else stepped up either. PRs to complete this part
> are welcome, so fiddling would not be needed ;)
>
>
>
> Quoting from a recent post:
>
> For kicks, you can try starting different drivers from a NUT for Windows
> build - I'd be interested to know if it actually picks up a serial port
> device (with nutdrv_qx as a  first stop, to test for Megatec Qx protocol
> family). Getting USB handled directly may be quite a hassle currently
> (without a proper elevated installer), but may be doable too:
> https://github.com/networkupstools/nut/issues/1690#issuecomment-1455206002
>
>
>
> Can try a pre-built tarball from CI https://ci.appveyor
> .com/project/nut-travis/nut/history
>
> e.g. for currently-latest master-branch build: https://ci.appveyor
> .com/project/nut-travis/nut/builds/48009107/artifacts => https://ci.
> appveyor
> .com/api/buildjobs/kn42sp8aek4md9va/artifacts/NUT-for-Windows-x86_64-SNAPSHOT-2.8.0.725-master.7z
>
>
>
> Good luck,
>
> Jim
>
>
>
>
>
>
>
> On Thu, Sep 14, 2023 at 2:31 PM Alessandro Mandelli <
> mandelli.alessan...@ngi.it> wrote:
>
> Yeah, existing packages and libraries don’t work for me, introduce
> overhead and require fiddling well beyond the capabilities of a standard
> user.
>
> I’d like a native win64 app.
>
> Anyway, thanks for your help
>
>
>
>
>
> *Da:* Jim Klimov 
> *Inviato:* giovedì 14 settembre 2023 13:17
> *A:* Alessandro Mandelli 
> *Cc:* Arnaud Quette via Nut-upsuser 
> *Oggetto:* Re: [Nut-upsuser] Info for decoding report from UPS
>
>
>
> So, do you plan to write some new program for that UPS instead of trying
> to use NUT? (Note there are also regular Windows builds on CI - with some
> caveats so far).
>
>
>
> I'm commuting now so can't find links easily, but can suggest you to
> peruse the issue/PR tracker, there's a discussion about an SMS Brazil
> device with links to PoC Python "driver" that's relatively straightforward.
> Or read up NUT drivers, nutdrv_qx, blazer, and some others for megatec
> protocol dialects. NUT website should have a protocol library with formal
> definitions for some of those.
>
>
>
> But really, not reinventing the wheel (at least, checking if ours does
> roll) might be the faster option ;)
>
>
>
> Jim
>
>
>
>
>
> On Thu, Sep 14, 2023, 13:07 Alessandro Mandelli <
> mandelli.alessan...@ngi.it> wrote:
>
> Thanks. I forgot to mention I am developing in c# for Windows.
>
> Porting or using existing ports seems like an effort with swinging results.
>
> My prototype is working, at least as proof of concept. I’d just like some
> directions to decode the raw reports.
>
>
>
> Thanks for your help.
>
>
>
>
>
> *Da:* Jim Klimov 
> *Inviato:* giovedì 14 settembre 2023 11:48
> *A:* Alessandro Mandelli 
> *Cc:* nut-upsuser@alioth-lists.debian.net
> *Oggetto:* Re: [Nut-upsuser] Info for decoding report from UPS
>
>
>
> Seems like recent work on nutdrv_qx subdriver armac (merged to 

Re: [Nut-upsuser] Info for decoding report from UPS

[Jim Klimov via Nut-upsuser]

Ah, I see. My take is that using or adapting something that exists is
easier than starting from scratch - but to each their own. Surely you'll
learn a lot :)

Still, just to clarify: after the NUT v2.8.0 release I began a slow revival
of old NUT for Windows effort (abandoned a decade ago at 2.6.5-8 based
branch), so now there are regular native win64 (CLI) builds regularly
produced by CI, as a tarball of a result of `make install` area (plus the
dependency DLLs). They can run in-place and do work for testing NUT
behaviors on the platform, but are not "properly packaged" yet, have no
installer, and indeed may need fiddling with USB libraries in particular
(so that Windows "HID Battery" driver won't get in the way and would let
libusb handle that node for NUT), but still sounds easier to give this a
shot before constructing something new. This OS integration bit may have
worked in that older 2.6.5 codebase, just I had no time to look hard at
this recently, and nobody else stepped up either. PRs to complete this part
are welcome, so fiddling would not be needed ;)

Quoting from a recent post:

For kicks, you can try starting different drivers from a NUT for Windows
build - I'd be interested to know if it actually picks up a serial port
device (with nutdrv_qx as a  first stop, to test for Megatec Qx protocol
family). Getting USB handled directly may be quite a hassle currently
(without a proper elevated installer), but may be doable too:
https://github.com/networkupstools/nut/issues/1690#issuecomment-1455206002

Can try a pre-built tarball from CI https://ci.appveyor
.com/project/nut-travis/nut/history
e.g. for currently-latest master-branch build: https://ci.appveyor
.com/project/nut-travis/nut/builds/48009107/artifacts => https://ci.appveyor
.com/api/buildjobs/kn42sp8aek4md9va/artifacts/NUT-for-Windows-x86_64-SNAPSHOT-2.8.0.725-master.7z

Good luck,
Jim



On Thu, Sep 14, 2023 at 2:31 PM Alessandro Mandelli <
mandelli.alessan...@ngi.it> wrote:

> Yeah, existing packages and libraries don’t work for me, introduce
> overhead and require fiddling well beyond the capabilities of a standard
> user.
>
> I’d like a native win64 app.
>
> Anyway, thanks for your help
>
>
>
>
>
> *Da:* Jim Klimov 
> *Inviato:* giovedì 14 settembre 2023 13:17
> *A:* Alessandro Mandelli 
> *Cc:* Arnaud Quette via Nut-upsuser 
> *Oggetto:* Re: [Nut-upsuser] Info for decoding report from UPS
>
>
>
> So, do you plan to write some new program for that UPS instead of trying
> to use NUT? (Note there are also regular Windows builds on CI - with some
> caveats so far).
>
>
>
> I'm commuting now so can't find links easily, but can suggest you to
> peruse the issue/PR tracker, there's a discussion about an SMS Brazil
> device with links to PoC Python "driver" that's relatively straightforward.
> Or read up NUT drivers, nutdrv_qx, blazer, and some others for megatec
> protocol dialects. NUT website should have a protocol library with formal
> definitions for some of those.
>
>
>
> But really, not reinventing the wheel (at least, checking if ours does
> roll) might be the faster option ;)
>
>
>
> Jim
>
>
>
>
>
> On Thu, Sep 14, 2023, 13:07 Alessandro Mandelli <
> mandelli.alessan...@ngi.it> wrote:
>
> Thanks. I forgot to mention I am developing in c# for Windows.
>
> Porting or using existing ports seems like an effort with swinging results.
>
> My prototype is working, at least as proof of concept. I’d just like some
> directions to decode the raw reports.
>
>
>
> Thanks for your help.
>
>
>
>
>
> *Da:* Jim Klimov 
> *Inviato:* giovedì 14 settembre 2023 11:48
> *A:* Alessandro Mandelli 
> *Cc:* nut-upsuser@alioth-lists.debian.net
> *Oggetto:* Re: [Nut-upsuser] Info for decoding report from UPS
>
>
>
> Seems like recent work on nutdrv_qx subdriver armac (merged to master last
> month) could handle it, or some older QX drivers like richcomm if it is a
> different brew of a loosely similar product.
>
>
>
> Try following
> https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests
> for example, to check if it would "just work" now?
>
>
>
> Jim
>
>
>
>
>
> On Thu, Sep 14, 2023 at 9:40 AM Alessandro Mandelli via Nut-upsuser <
> nut-upsuser@alioth-lists.debian.net> wrote:
>
> Hi, everybody, I just subscribed, though I’ve been lurking around for some
> time.
>
> I searched for my question in the archive, but I wasn’t able to find an
> answer.
>
> Sorry if this question has been asked before.
>
> I am in the process of writing an interfacing software.
>
> After some trial and error, I was able to query the UPS and receive an
> answer, though I am not sure how to decode the report.
>
> The UPS is generic, non branded with VID/PID 0925/1234.
>
> The report is 6 bytes long and raw data look like “0x01 0x04 0x02 0xDE
> 0xFE 0xFF”. (The fifth byte changes now and then).
>
> Any help pointing me to the right decoding table would be much appreciated.
>
>
>
> Cheers
>
> 

Re: [Nut-upsuser] Info for decoding report from UPS

[Jim Klimov via Nut-upsuser]

So, do you plan to write some new program for that UPS instead of trying to
use NUT? (Note there are also regular Windows builds on CI - with some
caveats so far).

I'm commuting now so can't find links easily, but can suggest you to peruse
the issue/PR tracker, there's a discussion about an SMS Brazil device with
links to PoC Python "driver" that's relatively straightforward. Or read up
NUT drivers, nutdrv_qx, blazer, and some others for megatec protocol
dialects. NUT website should have a protocol library with formal
definitions for some of those.

But really, not reinventing the wheel (at least, checking if ours does
roll) might be the faster option ;)

Jim


On Thu, Sep 14, 2023, 13:07 Alessandro Mandelli 
wrote:

> Thanks. I forgot to mention I am developing in c# for Windows.
>
> Porting or using existing ports seems like an effort with swinging results.
>
> My prototype is working, at least as proof of concept. I’d just like some
> directions to decode the raw reports.
>
>
>
> Thanks for your help.
>
>
>
>
>
> *Da:* Jim Klimov 
> *Inviato:* giovedì 14 settembre 2023 11:48
> *A:* Alessandro Mandelli 
> *Cc:* nut-upsuser@alioth-lists.debian.net
> *Oggetto:* Re: [Nut-upsuser] Info for decoding report from UPS
>
>
>
> Seems like recent work on nutdrv_qx subdriver armac (merged to master last
> month) could handle it, or some older QX drivers like richcomm if it is a
> different brew of a loosely similar product.
>
>
>
> Try following
> https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests
> for example, to check if it would "just work" now?
>
>
>
> Jim
>
>
>
>
>
> On Thu, Sep 14, 2023 at 9:40 AM Alessandro Mandelli via Nut-upsuser <
> nut-upsuser@alioth-lists.debian.net> wrote:
>
> Hi, everybody, I just subscribed, though I’ve been lurking around for some
> time.
>
> I searched for my question in the archive, but I wasn’t able to find an
> answer.
>
> Sorry if this question has been asked before.
>
> I am in the process of writing an interfacing software.
>
> After some trial and error, I was able to query the UPS and receive an
> answer, though I am not sure how to decode the report.
>
> The UPS is generic, non branded with VID/PID 0925/1234.
>
> The report is 6 bytes long and raw data look like “0x01 0x04 0x02 0xDE
> 0xFE 0xFF”. (The fifth byte changes now and then).
>
> Any help pointing me to the right decoding table would be much appreciated.
>
>
>
> Cheers
>
> ___
> Nut-upsuser mailing list
> Nut-upsuser@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Info for decoding report from UPS

[Jim Klimov via Nut-upsuser]

Seems like recent work on nutdrv_qx subdriver armac (merged to master last
month) could handle it, or some older QX drivers like richcomm if it is a
different brew of a loosely similar product.

Try following
https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests
for example, to check if it would "just work" now?

Jim


On Thu, Sep 14, 2023 at 9:40 AM Alessandro Mandelli via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:

> Hi, everybody, I just subscribed, though I’ve been lurking around for some
> time.
>
> I searched for my question in the archive, but I wasn’t able to find an
> answer.
>
> Sorry if this question has been asked before.
>
> I am in the process of writing an interfacing software.
>
> After some trial and error, I was able to query the UPS and receive an
> answer, though I am not sure how to decode the report.
>
> The UPS is generic, non branded with VID/PID 0925/1234.
>
> The report is 6 bytes long and raw data look like “0x01 0x04 0x02 0xDE
> 0xFE 0xFF”. (The fifth byte changes now and then).
>
> Any help pointing me to the right decoding table would be much appreciated.
>
>
>
> Cheers
> ___
> Nut-upsuser mailing list
> Nut-upsuser@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] PR to test for users of Qx devices (blazer and nutdrv_qx)

[Jim Klimov via Nut-upsuser]

Thanks!

  So, comparing this with the January report -- there are no substantial
changes in device discovery process and the collected info.
  However, the 10K seems to actually report most of the data which we have
to "guesstimate" in other cases.

  Hoping somebody else with QX devices would chime in then :)

Jim


On Wed, Sep 13, 2023 at 3:26 PM d tbsky  wrote:

> jim Klimov 
> >
> > Hello all,
> >
> >   Had another hard look at the PR for QX device voltage/charge/runtime
> fixes for some broken use-cases (AND hoping to not introduce problems for
> cases that were not broken), and hopefully found and rolled back the change
> which in fact introduced the strangeness found in our winter round of
> tests. Then the year was busy...
> >
> >   As before, the context for this is:
> > * issue https://github.com/networkupstools/nut/issues/1279
> > * PR https://github.com/networkupstools/nut/pull/1652
> > * PR source git branch (code to build for tests)
> https://github.com/jimklimov/nut/tree/issue-1279
> > *
> https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests
> suggests how to quickly build and
>
> Hi:
>one of our voltronic ups caught fire last year. so we abandoned
> them and bought APC.  now I have only one 10KV ups to test. It's sad
> because I like nutdrv_qx driver. APC microlink is too bad since nut
> doesn't support it. there is only modbus with apcupsd driver.
>
>BTW I saw an APC ups discussion at nut-upsdev about "SRVS1KI"(can
> not reply, not subscribed to that list) . I have that easy-ups series.
> nut can support them well with apcsmart driver. normally we should
> attach it via serial cable. if you attach the ups with usb cable, you
> will see "XR21V1410" which is a usb-serial converter. linux kernel
> 5.15 seems include the driver. or you will need to compile the
> driver(xr_usb_serial_common) yourself and get "/dev/ttyXRUSB0" to use
> as an serial port. I do that because we lost serial cable at a remote
> site and forced to use the usb cable.
>
> > ./nutdrv_qx -a ftups -u root -DD -d1
> Network UPS Tools - Generic Q* USB/Serial driver 0.35
> (2.8.0-2359-g6c0032e52)
> USB communication driver (libusb 1.0) 0.45
>0.00 [D1] Network UPS Tools version 2.8.0-2359-g6c0032e52
> (release/snapshot of 2.8.0.1) built with gcc (GCC) 11.3.1 20221121
> (Red Hat 11.3.1-4) and configured with flags: --enable-Wcolor
> --enable-keep_nut_report_featu
> re --with-all=auto --with-cgi=auto
> --with-serial=auto --with-dev=auto --with-doc=skip
> --with-nut_monitor=auto --with-pynut=auto
> --disable-force-nut-version-header --enable-check-NIT
> --enable-maintainer-mode
>0.11 [D1] debug level is '6'
>0.14 [D5] send_to_all: SETINFO driver.debug "6"
>0.18 [D5] send_to_all: SETFLAGS driver.debug RW NUMBER
>0.000815 [D1] Succeeded to become_user(root): now UID=0 GID=0
>0.000822 [D5] send_to_all: SETINFO device.type "ups"
>0.000825 [D5] send_to_all: SETINFO driver.state "init.device"
>0.000827 [D1] upsdrv_initups...
>0.003147 [D2] Checking device 1 of 11 (8087/8000)
>0.057855 [D2] - VendorID: 8087
>0.057861 [D2] - ProductID: 8000
>0.057862 [D2] - Manufacturer: unknown
>0.057864 [D2] - Product: unknown
>0.057865 [D2] - Serial Number: unknown
>0.057867 [D2] - Bus: 002
>0.057868 [D2] - Device: 002
>0.057870 [D2] - Device release number: 0005
>0.057873 [D2] Trying to match device
>0.057875 [D3] match_function_regex: matching a device...
>0.057888 [D2] Device does not match - skipping
>0.071830 [D2] Checking device 2 of 11 (1D6B/0002)
>0.078881 [D2] - VendorID: 1d6b
>0.078885 [D2] - ProductID: 0002
>0.078887 [D2] - Manufacturer: Linux 5.14.0-162.23.1.el9_1.x86_64
> ehci_hcd
>0.07 [D2] - Product: EHCI Host Controller
>0.078890 [D2] - Serial Number: :00:1d.0
>0.078891 [D2] - Bus: 002
>0.078893 [D2] - Device: 001
>0.078894 [D2] - Device release number: 0514
>0.078897 [D2] Trying to match device
>0.078898 [D3] match_function_regex: matching a device...
>0.078912 [D2] Device does not match - skipping
>0.091359 [D2] Checking device 3 of 11 (8087/8008)
>0.145626 [D2] - VendorID: 8087
>0.145635 [D2] - ProductID: 8008
>0.145637 [D2] - Manufacturer: unknown
>0.145638 [D2] - Product: unknown
>0.145640 [D2] - Serial Number: unknown
>0.145641 [D2] - Bus: 001
>0.145643 [D2] - Device: 002
>0.145645 [D2] - Device release number: 0005
>0.145648 [D2] Trying to match device
>0.145661 [D3] match_function_regex: matching a device...
>0.145664 [D2] Device does not match - skipping
>0.159837 [D2] Checking device 4 of 11 (1D6B/0002)
>0.166862 [D2] - VendorID: 1d6b
>0.166867 [D2] - 

Re: [Nut-upsuser] Multiple battery levels to trigger actions?

[Jim Klimov via Nut-upsuser]

Hello,

  I think this should be possible, probably with dummy-ups or clone*
drivers and respective override.* definitions in the "secondary drivers"

  So if something does not work here, I'm ready to consider it a bug. Can
you post samples of config and logs (are there any errors?)

  One thing that comes to mind quickly: with NUT 2.8.0+ we deliver a new
`nut-driver-enumerator` (script and service) which when enabled, looks at
ups.conf contents and its real-time changes, and can generate unit
instances for nut-driver@SectionName (a bit more complicated than that in
the most general case, not all name patterns are valid for systemd or SMF
that this approach supports - can be MD5 hashes of the section name then).
As part of such definitions, it describes "After" and "Wants" dependencies
based on driver type (e.g. not all of them are tied to networking). A
possible caveat here is that one driver depending on another, and depending
on an upsd data server, while any driver generally also being a dependency
for upsd to start - this may require manual addition of systemd "drop-in"
files to untangle the dependencies.

  Note that this entanglement concerns primarily the service definitions.
Daemons themselves are relatively independent, with `upsd` capable of
polling the FS if socket files appear so they would pick up a driver
(re-)started after the data server began running. Nowadays there is also an
option for `upsd` to allow starting if currently there are no devices
listed in `ups.conf`, so it can be reloaded with a signal later - after the
file becomes populated (e.g. to behave predictably on a newly deployed
monitoring appliance). Generally a driver also can start and live
independently of `upsd` appearing or going away. A `dummy-ups` or `clone*`
driver might however refuse to start if it can not read its data source
which it relays further - e.g. if the `upsd` is not yet running or serving
the "original" driver data (snmp-ups in your case).

 Something to try here is to check if such units do exist, and if yes - to
start them (or even for experiments - directly start the daemons via
command-line, without a service unit). If I guess the default situation
correctly, after boot you would have snmp-ups running, and possibly upsd
(if a failed cloning driver did not preclude its start as the nut-server
systemd unit). Hopefully after some time any failed clone driver units
would retry starting after a quiet timeout, and would find the upsd and
snmp-ups's data on it. If however systemd decides there is a dependency
loop, it might decide to never (re-)start something, in order to avoid the
loop - either clone driver units or nut-server.

  If such simple attempts prove that the daemons and configurations CAN
still work like this (no regression in NUT itself), then a drop-in file for
each clone driver unit like
/etc/systemd/system/nut-driver@dummy1.service/customdeps.conf
could be used (see man pages for your systemd version to be sure about the
syntax) to e.g. remove the backwards "Install" dependency like
`WantedBy=nut-server.service` (probably by specifying a blank `WantedBy=`)
so that the loop would be no more, and ensuring there is a  "Service"
section dependency set of `Wants=nut-server.service` and
`After=nut-server.service` - so this clone driver would only try to start
when it can actually succeed. Use `systemd daemon-reload` to apply edits.

Hope this helps,
Jim Klimov


On Wed, Sep 13, 2023 at 9:30 AM Steffen Grunewald <
steffen.grunew...@aei.mpg.de> wrote:

> Good morning NUTcrackers,
>
> several years ago, I had a setup that used the SNMP driver to collect data
> from a networked UPS and act as a source for multiple "secondary" drivers
> that each had a different battery level to trigger various actions, e.g.
> at 70% shut down some services, at 50% freeze the batch system and at 30%
> switch off everything but the spinning disks (leave JBODs running, change
> runlevel to 1).
>
> My attempts to clone the old setting for a recent version of NUT (2.8.0,
> backported from sid a few months ago) failed to start the set of drivers,
> so something must have changed while I wasn't looking.
>
> Is this approach still possible with NUT 2.8.x, and may I learn from
> someone who is running such a setup?
>
> Thanks in advance,
>  Steffen
>
> --
> Steffen Grunewald, Cluster Administrator
> Max Planck Institute for Gravitational Physics (Albert Einstein Institute)
> Am Mühlenberg 1 * D-14476 Potsdam-Golm * Germany
> ~~~
> Fon: +49-331-567 7274
> Mail: steffen.grunewald(at)aei.mpg.de
> ~~~
>
> ___
> Nut-upsuser mailing list
> Nut-upsuser@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Eaton 3s 550 and testing

[Jim Klimov via Nut-upsuser]

I don't think they have variables attached (maybe some for known verdicts
after a test). The tests and other available ops should be among `upscmd
-l`.

Jim

On Mon, Sep 4, 2023, 11:12 Łukasz Michalski via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:

> Hi,
>
> I have Eaton 3S 700 connected and configure using nut-2.8.0 under
> ArchLinux. OL, OB reporting works OK, but I am not able to enable battery
> testing. Variables ups.test.* are not reported by upsc:
>
> [root@black ~]# upsc eaton@192.168.20.2 |grep ups.*
> device.type: ups
> driver.name: usbhid-ups
> ups.beeper.status: enabled
> ups.delay.shutdown: 360
> ups.delay.start: 120
> ups.firmware: 02
> ups.load: 5
> ups.mfr: EATON
> ups.model: Eaton 3S 700
> ups.power.nominal: 700
> ups.productid: 
> ups.realpower: 28
> ups.serial: 0
> ups.status: OL
> ups.timer.shutdown: -1
> ups.timer.start: -1
> ups.vendorid: 0463
>
>
> Recently I had to replace battery and when using official Eaton UPS
> Companion 2.1 under windows7, I see "battery testing" option and I can
> choose battery test period (every day, every week, etc).
>
> Is there any way I can enable battery testing with nut for this model?
>
> Thanks,
> Łukasz
>
>
>
> ___
> Nut-upsuser mailing list
> Nut-upsuser@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] [Nut-upsdev] Setting up charge/voltage based shutdowns

[Jim Klimov via Nut-upsuser]

>From my understanding, alone with other NUT behaviors it would not.

Even if NUT drivers already do (or are changed to) react to the actual
charge/runtime going below this setting to fabricate an LB status, this as
a driver setting/override would have immediate effect on all clients like
`upsmon` watching the device status on their shared data server. This
simultaneously requested shutdown *might* then be handled differently by
shutdown procedures on different clients (e.g. a NAS somehow waiting until
its clients disconnect), but such solutions are not part of NUT directly at
the moment.

If such a feature is indeed missing currently, engineering it would be a
useful addition as it is something people sort-of-expect NUT to be capable
of.

But for different clients to get the shutdown signal at different times
might need something different in e.g. `upsmon`.

One idea that comes to mind though would be to use dummy-ups (or clone*)
drivers as relays, specifically to inject custom overrides (if/when that
mechanism works to generate LB) over "real device" data. So your server
could have a "realups" section as well as some dummies proxying its other
info and overridden to have LBs at say 90%, 50% and 30% marks. And
different clients would monitor different such constructs.

Jim



On Sun, Aug 6, 2023 at 7:59 PM Strahil Nikolov 
wrote:

> Hi Jim,
>
> I was thinking about setting different values for each device , so the
> first system has higher values and shutdowns earlier:
>
> override.battery.charge.low
>
> override.battery.runtime.low
>
>
> Won’t it work ?
>
> Best Regards,
> Strahil Nikolov
>
> On Sunday, August 6, 2023, 7:41 PM, Jim Klimov via Nut-upsdev <
> nut-ups...@alioth-lists.debian.net> wrote:
>
> Yeah, I have no lack of imagination about scenarios where that can be
> useful - just was surprised to see no apparent "here's how you do it" sort
> of man page or something,
>
> Although technically the shutdown scenario like yours, where a NAS server
> only is told to go down - or actually does so (which is substantially
> different and can be implemented elsewhere) - after its consumers go down,
> can be implemented outside of NUT.
>
> For your example, one can have the NAS's `SHUTDOWNCMD` script wait until
> `upsc` reports some critical remaining time/charge or until all known
> protocol clients (NFS, CIFS, iSCSI, ...) have disconnected - e.g. check
> whether `netstat -an | grep ESTABLISHED | grep PORTNUMS` port count went to
> zero (assuming TCP connections). In this case, some same event trigger on
> the NUT `primary` server (like "on battery for over 1 minute per upssched")
> would tell all clients to shut down, and the NAS client would by such
> script wait until the VM server goes down. Although in this 1:1 case it
> would be beneficial for NAS to be the primary server (otherwise the other
> primary can eventually time out and take action to go down itself and
> command the UPS to power-off). Whatever the programmatic case, in the end
> this is limited by how long the UPS holds up :)
>
> Jim
>
>
> On Sun, Aug 6, 2023 at 6:05 PM Arnaldo Viegas de Lima <
> arna...@viegasdelima.com> wrote:
>
> I think it can be useful in a scenario like:
>
> - Large UPS, that powers 2 hosts: one is VMServer with just a small boot
> driver and the second is a NAS with all the disks for the first server.
> - UPS is connected by USB to another host (such as a small Raspberry PI),
> acting as the NUT primary.
> - Both machines served by UPS are NUT secondaries.
> - The NAS box can only shutdown one the VMware is fully stopped to avoid
> corruption at several levels.
>
> If the secondaries can define their one parameters for initiating the
> shutdown, one can decide something like:
>
> - VMware will shutdown at 20% battery left OR 15min of runtime left
> - NAS will shutdown at 10% ou 8min left
>
> Another approach is to attempt to define a way to sync secondaries… but
> that’s much more complex.
>
> Arnaldo.
>
> On Aug 6, 2023, at 12:39 PM, Jim Klimov via Nut-upsuser <
> nut-upsuser@alioth-lists.debian.net> wrote:
>
> Hello all again,
>
>   While looking at https://github.com/networkupstools/nut/issues/2014 I
> understood that I am
> not sure if currently NUT has a standard way of triggering a shutdown
> based on remaining charge
> or runtime, if a device/driver lacks a `battery.charge.low` setting but
> has readings for the values
> themselves.
>
>   Such an ability rings a bell to me, but maybe it is specific to some
> drivers and is not
> something ubiquitous - as being in the driver (and/or upsmon/upssched?)
> core codebase?
>
>   So there are a few questions stemming from this:
> * Can a user curren

Re: [Nut-upsuser] Setting up charge/voltage based shutdowns

[Jim Klimov via Nut-upsuser]

Yeah, I have no lack of imagination about scenarios where that can be
useful - just was surprised to see no apparent "here's how you do it" sort
of man page or something,

Although technically the shutdown scenario like yours, where a NAS server
only is told to go down - or actually does so (which is substantially
different and can be implemented elsewhere) - after its consumers go down,
can be implemented outside of NUT.

For your example, one can have the NAS's `SHUTDOWNCMD` script wait until
`upsc` reports some critical remaining time/charge or until all known
protocol clients (NFS, CIFS, iSCSI, ...) have disconnected - e.g. check
whether `netstat -an | grep ESTABLISHED | grep PORTNUMS` port count went to
zero (assuming TCP connections). In this case, some same event trigger on
the NUT `primary` server (like "on battery for over 1 minute per upssched")
would tell all clients to shut down, and the NAS client would by such
script wait until the VM server goes down. Although in this 1:1 case it
would be beneficial for NAS to be the primary server (otherwise the other
primary can eventually time out and take action to go down itself and
command the UPS to power-off). Whatever the programmatic case, in the end
this is limited by how long the UPS holds up :)

Jim


On Sun, Aug 6, 2023 at 6:05 PM Arnaldo Viegas de Lima <
arna...@viegasdelima.com> wrote:

> I think it can be useful in a scenario like:
>
> - Large UPS, that powers 2 hosts: one is VMServer with just a small boot
> driver and the second is a NAS with all the disks for the first server.
> - UPS is connected by USB to another host (such as a small Raspberry PI),
> acting as the NUT primary.
> - Both machines served by UPS are NUT secondaries.
> - The NAS box can only shutdown one the VMware is fully stopped to avoid
> corruption at several levels.
>
> If the secondaries can define their one parameters for initiating the
> shutdown, one can decide something like:
>
> - VMware will shutdown at 20% battery left OR 15min of runtime left
> - NAS will shutdown at 10% ou 8min left
>
> Another approach is to attempt to define a way to sync secondaries… but
> that’s much more complex.
>
> Arnaldo.
>
> On Aug 6, 2023, at 12:39 PM, Jim Klimov via Nut-upsuser <
> nut-upsuser@alioth-lists.debian.net> wrote:
>
> Hello all again,
>
>   While looking at https://github.com/networkupstools/nut/issues/2014 I
> understood that I am
> not sure if currently NUT has a standard way of triggering a shutdown
> based on remaining charge
> or runtime, if a device/driver lacks a `battery.charge.low` setting but
> has readings for the values
> themselves.
>
>   Such an ability rings a bell to me, but maybe it is specific to some
> drivers and is not
> something ubiquitous - as being in the driver (and/or upsmon/upssched?)
> core codebase?
>
>   So there are a few questions stemming from this:
> * Can a user currently (on NUT 2.8.0) set up battery percentage based
> shutdowns
>   when the "low" variable is missing in the driver/device? (Suggestions in
> the ticket
>   linked above are welcome)
> * Does it make sense to add something like this (if missing) to be
> consistent on
>   un-capable devices? Or is it already there but too buried in code or
> docs?
> * Would anyone step up to make this setup easy for newcomers (even if it
> means "just"
>   finding a chapter in the docs/FAQ and making it better exposed, perhaps
> in the Wiki),
>   or more so if design and coding are due? ;)
>
> Jim
>
> ___
> Nut-upsuser mailing list
> Nut-upsuser@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
>
>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

[Nut-upsuser] Setting up charge/voltage based shutdowns

[Jim Klimov via Nut-upsuser]

Hello all again,

  While looking at https://github.com/networkupstools/nut/issues/2014 I
understood that I am
not sure if currently NUT has a standard way of triggering a shutdown based
on remaining charge
or runtime, if a device/driver lacks a `battery.charge.low` setting but has
readings for the values
themselves.

  Such an ability rings a bell to me, but maybe it is specific to some
drivers and is not
something ubiquitous - as being in the driver (and/or upsmon/upssched?)
core codebase?

  So there are a few questions stemming from this:
* Can a user currently (on NUT 2.8.0) set up battery percentage based
shutdowns
  when the "low" variable is missing in the driver/device? (Suggestions in
the ticket
  linked above are welcome)
* Does it make sense to add something like this (if missing) to be
consistent on
  un-capable devices? Or is it already there but too buried in code or docs?
* Would anyone step up to make this setup easy for newcomers (even if it
means "just"
  finding a chapter in the docs/FAQ and making it better exposed, perhaps
in the Wiki),
  or more so if design and coding are due? ;)

Jim
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Question on simultaneous IPv4 and IPv6 "any address" listening

[Jim Klimov via Nut-upsuser]

Thanks to everyone for a fruitful discussion, links and ideas.

The result is nearing a merge at
https://github.com/networkupstools/nut/pull/2013 and seems to not upset CI
on any platform, including Windows (which behaves funny WRT binding to the
same host:port as many times as you ask).

Ultimately the chosen logic is that if there was a `LISTEN * ` in
`upsd.conf`, the depending on CLI settings (-4/-6) or lack thereof we try
PIv4, IPv6 or both, with the bigger logic for "both" being:
* try to get IPv4 "ANY", to know we can do so
* release IPv4, try to get IPv6 and then IPv4 again

If in the end neither socket works, declare a fatal error (could not
fulfill the config requirement).
If we could get IPv4 initially, and could not after getting IPv6, do not
bother - assume a dual-stack system (and log it so).

Also as part of this change, NUT would ask (although not insist) for the
IPV6_V6ONLY socket option when preparing IPv6 connections, except when
handling `LISTEN *`.
Finally, I noticed that if some configuration hostname resolves to more
than one address, the first one bound wins and others are ignored. This
behavior was here before, the PR change just logs that this happens.

Jim Klimov


On Sat, Aug 5, 2023 at 2:24 PM Greg Troxel  wrote:

> Jim Klimov via Nut-upsuser  writes:
>
> >   I've recently found that at least on my test box the `LISTEN *` line
> had
> > only set up an IPv4 `0.0.0.0` listener but not an IPv6 `::0` listener for
> > `upsd`.
>
> Interesting.  On one system I checked, I have 4 explicit directives for
> 127.0.0.1, ::1, and the LAN on v4/v6.  On another, I have an empty
> upsd.conf and it is listening:
>
> nut  upsd10474* internet stream tcp 127.0.0.1:3493
> nut  upsd10475* internet6 stream tcp [::1]:3493
>
> > In fact, at least on a "dual-stack" system, it seems impossible to
> > bind to both - so depending on binding order I either lose IPv6 or lose
> > IPv4 directly (but have it practically as IPv4-over-IPv6).
>
> That is not intrinsic to a system that does v4 and v6.  It is about a
> misfeature which if turned on, when one binds to v6 also sets up a
> listener on v4 which connects as a mapped address.  These days, I view
> it as a bug for a system to be configuret hat way.  On NetBSD, from
> ip6(4):
>
>  IPV6_V6ONLY int *
>  Get or set whether only IPv6 connections can be made to this
>  socket.  For wildcard sockets, this can restrict connections
> to
>  IPv6 only.
>
> which is 1 on my system.
>
> >   Given that `LISTEN *` support is in fact not documented explicitly (I
> > think), I am inclined to define it as listening to "any" on whatever
> > address families are available and supported by the NUT build, and
> somehow
> > ensuring that to the best of our capability (technical puzzles exist -
> see
> > GitHub issue).
>
> It seems really obvious that * means anything, so agreed.
>
> I think it's important that the default, if there are no LISTEN
> directives, be "listen on all localhost addresses of all address
> familes".  And probably there should be a way to say that explicitly,
> like "LISTEN localhost".
>
> Practically, LISTEN localhost should:
>
> #ifdef v6 at compile time
>   open a socket and bind to [::1]:3493
> error log that v6 bind failed
> #endif
>
>   open a socket and bind to 127.0.0.1:3493
> if error:
>   if there is a v6 socket:
> debug log that v4 bind failed, maybe, or maybe it's a real
> error?  need to figure out if v6only=0 systems some try to map
> this.  The point  being not to fight os/sysadmin choice even if
> misguided :-)
>   else:
> error log that v4 bind failed
>
> and LISTEN * should
>
> #ifdef v6 at compile time
>   open a socket and bind to INADDR6_ANY:3493
> error log that v6 bind failed
> #endif
>
>   open a socket and bind to INADDR_ANY:3493
> if error:
>   if there is a v6 socket:
> debug log that v4 bind failed
>   else:
> error log that v4 bind failed
>
>
>
>
> >   Detailed musing and logs are posted in
> > https://github.com/networkupstools/nut/issues/2012
> >
> >   Pro/Con ideas are welcome :)
> >
> > Jim
> > ___
> > Nut-upsuser mailing list
> > Nut-upsuser@alioth-lists.debian.net
> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
> ___
> Nut-upsuser mailing list
> Nut-upsuser@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

[Nut-upsuser] Question on simultaneous IPv4 and IPv6 "any address" listening

[Jim Klimov via Nut-upsuser]

Cheers all,

TL;DR version:

  I've recently found that at least on my test box the `LISTEN *` line had
only set up an IPv4 `0.0.0.0` listener but not an IPv6 `::0` listener for
`upsd`. In fact, at least on a "dual-stack" system, it seems impossible to
bind to both - so depending on binding order I either lose IPv6 or lose
IPv4 directly (but have it practically as IPv4-over-IPv6).

  Given that `LISTEN *` support is in fact not documented explicitly (I
think), I am inclined to define it as listening to "any" on whatever
address families are available and supported by the NUT build, and somehow
ensuring that to the best of our capability (technical puzzles exist - see
GitHub issue).

  Detailed musing and logs are posted in
https://github.com/networkupstools/nut/issues/2012

  Pro/Con ideas are welcome :)

Jim
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

[Nut-upsuser] Android client capable of NUT monitoring, exists and can be made better

[Jim Klimov via Nut-upsuser]

Hello all,

  A recent issue discussion pointed me to an Android app called
"apcupsd-monitor", which is in fact *also* capable of NUT and Eaton IPM
(via XML/HTTP?) protocols, and looks quite neat for a mobile dashboard:
* https://github.com/networkupstools/nut/wiki/Android-clients
* https://play.google.com/store/apps/details?id=com.nitramite.apcupsdmonitor

  As programs go, it is always open to perfection though :) So I posted a
few points of improvement at
https://github.com/norkator/apcupsd-monitor/issues/170 and the author's
reply was reasonable: that basic NUT support came via user request, and any
improvements are quite welcome as PR's but there is no personal urge for
the author (as an `apcupsd` user).

  So, "challenge accepted"? If anyone in the NUT community longs for a
mobile client, there is a sandbox to play in with a head start!

Hope this helps someone get better versed in yet another programming
ecosystem,
Jim Klimov
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Powering off the big stuff first

[Jim Klimov via Nut-upsuser]

I think the client should be able to do that with `upssched` as long as the
`upsmon` calls it to trigger the events. Thinking of it, the common
use-case is indeed time (e.g. 5 minutes after on-battery, certain systems
begin their shutdown), or the primary upsmon telling others to FSD ASAP.

Maybe the other use-cases you mention would benefit from a PR - primarily
for `upsmon` configuration syntax and actual logic to do certain actions
based on certain data states (e.g. "we ticked to battery 9% and previous
reading was >= 10% - gotta call the SHUTDOWNCMD handler!", which could be
upssched to filter out floating glitches, or directly the shutdown
script...)

And as always, PRs are welcome ;)

Jim


On Sun, Jul 16, 2023 at 9:39 PM Arnaldo H Viegas de Lima <
arna...@viegasdelima.com> wrote:

> One thing that I think NUT misses is the client side being able to decide
> to shutdown by itself based on time (this can be done), battery charge (ex
> if bellow 10%), and estimated runtime left (if available and considered
> reliable/calibrated).
> Without having to sort on the LB state from the server.
>
> Sent from my iPhone with  iTypos
>
> On Jul 16, 2023, at 4:34 PM, Willcox David via Nut-upsuser <
> nut-upsuser@alioth-lists.debian.net> wrote:
>
> 
> Interesting. Something similar came up in late May. Look for "[Nut-upsuser]
> Synthesize low batt (LB) fron SNMP UPS which does not support this?” Is
> there an archive of this list? I an’t find it. I’d been trying to figure
> out how to do that itself, but then found some code in drivers/dstate.c
> that looked like it would work, but someone else replied that they’d
> tried it and it didn’t work.
>
> But that was about getting the NUT server to synthesize LB to its clients
> before the actual UPS did.
>
> If you’re running NUT as a client on your server, then yes, as others
> have noted, upssched on your server is probably the way to go.
>
>
> On Jul 16, 2023, at 9:00 AM, Dan Langille via Nut-upsuser <
> nut-upsuser@alioth-lists.debian.net> wrote:
>
> Hello,
>
> I had an idea last week: why shut everything off (in my basement) when the
> power goes off (and run time goes below X minutes)?
>
> My idea: shutdown the big stuff first (two servers) leaving the little
> stuff (switches, wireless, gateway) running for a while longer. I might get
> another 30 minutes of internet that way. Let me watch a bit more streaming….
>
> I’m convinced that idea is achievable with a little programming.
>
> Mind you, most of my power outages exceed 1 hour.
>
> Do you already do something similar? Do you have something you’d like to
> share please?
>
> Thank you
>
> --
>  Dan Langille
>  d...@langille.org
>
> ___
> Nut-upsuser mailing list
> Nut-upsuser@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
>
> ___
> Nut-upsuser mailing list
> Nut-upsuser@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
> ___
> Nut-upsuser mailing list
> Nut-upsuser@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] NUT start service problem

[Jim Klimov via Nut-upsuser]

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 2.8.0 release), with regular CI-made archives of binary build
"installation" directories which so far lack an installer (nobody looked at
it yet) and have some other caveats and bits of known-missing code. In
particular, lack of the installer may be behind the lack of
(privileged-mode) USB integration, although it is possible to use the Zadig
tool to specify which low-level USB drivers should handle certain
VendorID:ProductID hits. From codebase re-integration differences over the
commit history I saw several ways iterated and changed about Windows
Service registration in particular, so it is possible that the approach
used at the time of MSI releases is different from the one implemented in
the codebase now. Sadly so far nobody else stepped up to brush up the
remaining parts and complete the Windows codebase integration, someone who
would actually use Windows, UPS and NUT together to find and iron out the
wrinkles. Help is welcome :)

See some more details and further links about this at
https://github.com/networkupstools/nut/wiki/NUT-for-Windows

Hope this helps,
Jim Klimov


On Sun, Jul 16, 2023 at 2:49 PM Michael Golub via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:

> Hi
> After install on Windows 11 I can't start NUT service.
>
> Michael Golub, with best regards.
> ___
> Nut-upsuser mailing list
> Nut-upsuser@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] failed after upgrade - upscode2: Missing UPCL after UPCL

[Jim Klimov via Nut-upsuser]

Yes, the bug was about conversion of `upsdebugx()` and friends to macros,
so actual methods (and their parameter evaluations) only waste CPU cycles
when the verbosity level is high enough. Otherwise lots of logic was
executed to prepare method arguments only for it to bail out in the first
line.

In a couple of cases (addressed by that PR referenced in the thread) this
change left "production" logic overboard unless it was debug-printed, hence
this failure.

Can't phone-type an article on building NUT now, but there should be a few
pages on that in Wiki, including one referenced earlier. Otherwise, I
guess, you can find a packaging recipe from distro ("debian" dir is their
turf) and add a patch equivalent to that PR...

Jim

On Wed, Jul 5, 2023, 22:49 Karl Schmidt  wrote:

>
>
> On 7/5/23 03:17AM, Jim Klimov wrote:
> > Ah, I thought you missed in my earlier reply the part about a bug with
> debug printouts in 2.8.0 (fixed on master since),
> > did not comment on that when you replied with quoting... So, for now
> options are to bump debugging to 3+ or to build
> > your own in one of many ways possible :\
>
> I think I'm not following you - with debug 3 -->> it WORKS -- without
> debug it fails. (even debug 2 fails).
>
> Could be you want me to build a version off of github?
>
> I see there isn't anything is sid or experimental ..
>
> I'm rusty at building packages (keeps changing) - do you have a build
> script?
>
> git clone https://github.com/networkupstools/nut
>
> -- no debian directory ?
>
>
>
>
> --
> With debug =2
>
> :02.557753-05:00 malaysia systemd[1]: Starting nut-driver@malaysia.service
> - Network UPS Tools - device driver for
> malaysia...
> 2023-07-05T15:06:02.571832-05:00 malaysia nut-driver@malaysia[6]:
> 0.00#011[D1] debug level is '2'
> 2023-07-05T15:06:02.572748-05:00 malaysia nut-driver@malaysia[6]:
> 0.001186#011[D1] Saving PID 6 into
> /run/nut/upscode2-malaysia.pid
> 2023-07-05T15:06:02.572795-05:00 malaysia nut-driver@malaysia[6]:
> 0.001215#011tcgetattr(/dev/ttyUSB-nut):
> Inappropriate ioctl for device
> 2023-07-05T15:06:02.572818-05:00 malaysia nut-driver@malaysia[6]:
> Network UPS Tools - UPScode II UPS driver 0.90 (2.8.0)
> 2023-07-05T15:06:02.572839-05:00 malaysia nut-driver@malaysia[6]:
> Warning: This is an experimental driver.
> 2023-07-05T15:06:02.572857-05:00 malaysia nut-driver@malaysia[6]:
> Some features may not function correctly.
> 2023-07-05T15:06:02.573030-05:00 malaysia nut-driver@malaysia[61110]:
> Driver failed to start (exit status=1)
> 2023-07-05T15:06:02.573066-05:00 malaysia nut-driver@malaysia[61110]:
> Network UPS Tools - UPS driver controller 2.8.0
> 2023-07-05T15:06:02.573252-05:00 malaysia systemd[1]:
> nut-driver@malaysia.service: Control process exited, code=exited,
> status=1/FAILURE
> 2023-07-05T15:06:02.573390-05:00 malaysia systemd[1]:
> nut-driver@malaysia.service: Failed with result 'exit-code'.
>
> Not enough time to fail from not finding UPCL
>
>
> This seems like this might be a timing issue - something is running before
> something else is ready?  Debug would slow
> something down?
>
>
> I hooked it up to cutecom connected and I seem to get a list of supported
> commands back if I ask for UPCL
>
>
> UPSS
> UPDS
> UPDV
> UPTP
> UPSN
> UPPN
> UPSD
> UPCD
> UPPC
> UPPU
> UPIS
> UP??
> UPEA
> UPDA
> UPCL
>
> Looks like a list of supported commands? UPCL(Ups Command List?)
>
>
>
> Takes a couple of seconds.
>
>
> Looking at the debug output of  /usr/lib/nut/upscode2 -a malaysia -
>
> I see a problem at :
>
>   0.954763 [D3] upscsend: 'UPCD'
>   0.956318 [D3] upscsend: ''
>   2.958427 [D3] upscrecv: Timeout
>   4.960535 [D3] upscrecv: Timeout
>   4.960566 [D2] Got value:
>   4.960580 Bad response to UPCD :
>   4.960596 dstate_setflags: base variable (ups.delay.reboot)
> does not exist
>   4.960609 dstate_setaux: base variable (ups.delay.reboot)
> does not exist
>
>  From cutecom - UPCD  returns
>
> ACCD
> 060
>
>
>
>
>
> >
> > On Wed, Jul 5, 2023, 06:23 Karl Schmidt  k...@lrak.net>> wrote:
> >
> > On 7/4/23 10:01PM, Jim Klimov wrote:
> >  > Normally yes - enable and start the target and the particular
> services relevant to your setup.
> >  >
> >  > For the binary you have from packaging (if not rebuilt as
> suggested earlier), set debug_min=3 in ups.conf section
> > for
> >  > upscode2, to currently trade driver viability for some storage
> traffic with more logs :\
> >  >
> >  > Sorry about that,
> >  > Jim
> >
> > OK - this is strange . If I run it WITH the debug - it works -
> WITHOUT - it fails.  Put debug back in and it works
> > again..
> >
> > With debug I can run upsc malaysia - and it works.. without it fails.
> >
> > I'm thinking the old 1200 baud is too slow for something?
> >
> > - The logs are sort of big - should I 

Re: [Nut-upsuser] failed after upgrade - upscode2: Missing UPCL after UPCL

[Jim Klimov via Nut-upsuser]

Ah, I thought you missed in my earlier reply the part about a bug with
debug printouts in 2.8.0 (fixed on master since), did not comment on that
when you replied with quoting... So, for now options are to bump debugging
to 3+ or to build your own in one of many ways possible :\

On Wed, Jul 5, 2023, 06:23 Karl Schmidt  wrote:

> On 7/4/23 10:01PM, Jim Klimov wrote:
> > Normally yes - enable and start the target and the particular services
> relevant to your setup.
> >
> > For the binary you have from packaging (if not rebuilt as suggested
> earlier), set debug_min=3 in ups.conf section for
> > upscode2, to currently trade driver viability for some storage traffic
> with more logs :\
> >
> > Sorry about that,
> > Jim
>
> OK - this is strange . If I run it WITH the debug - it works - WITHOUT -
> it fails.  Put debug back in and it works again..
>
> With debug I can run upsc malaysia - and it works.. without it fails.
>
> I'm thinking the old 1200 baud is too slow for something?
>
> - The logs are sort of big - should I send to list as attachments or
> direct?
>
>
> >
> > On Wed, Jul 5, 2023, 02:29 Karl Schmidt  k...@lrak.net>> wrote:
> >
> > Ok - I'm wondering is this is a systemd config bit?
> >
> > systemctl restart nut-driver@malaysia.service
> > Job for nut-driver@malaysia.service failed because the control
> process exited with error code.
> > See "systemctl status nut-driver@malaysia.service" and "journalctl
> -xeu nut-driver@malaysia.service" for details.
> > root@malaysia:~# systemctl status nut-driver@malaysia.service
> > ● nut-driver@malaysia.service - Network UPS Tools - device driver
> for malaysia
> >Loaded: loaded (/lib/systemd/system/nut-driver@.service;
> enabled; preset: enabled)
> >   Drop-In: /etc/systemd/system/nut-driver@malaysia.service.d
> >└─nut-driver-enumerator-generated-checksum.conf
> >Active: activating (auto-restart) (Result: exit-code) since
> Tue 2023-07-04 19:03:20 CDT; 9s ago
> >   Process: 14926 ExecStart=/bin/sh -c
> NUTDEV="`/usr/libexec/nut-driver-enumerator.sh --get-device-for-service
> > malaysia`" && [ -n "$NUTDEV" ] || { echo "FATAL: Could not find a
> NUT device section for service unit malaysia" >&2 ;
> > exit 1 ; } ; /sbin/upsdrvctl start "$NUTDEV" (code=exited,
> status=0/SUCCESS)
> >   Process: 14955 ExecStop=/bin/sh -c
> NUTDEV="`/usr/libexec/nut-driver-enumerator.sh --get-device-for-service
> > malaysia`" && [ -n "$NUTDEV" ] || { echo "FATAL: Could not find a
> NUT device section for service unit malaysia" >&2 ;
> > exit 1 ; } ; /sbin/upsdrvctl stop "$NUTDEV" (code=exited,
> status=1/FAILURE)
> >
> >
> > >%-
> > So I tried
> > # /usr/libexec/nut-driver-enumerator.sh --get-device-for-service
> malaysia
> > malaysia
> >
> >
> >
> >
> > I'm not clear about all the unit files -
> >
> > ~# systemctl list-unit-files |grep nut
> > nut-driver-enumerator.path enabled enabled
> > nut-client.service alias   -
> > nut-driver-enumerator.service  enabled enabled
> > nut-driver@.serviceindirectenabled
> > nut-monitor.serviceenabled enabled
> > nut-server.service enabled enabled
> > nut-driver.target  enabled enabled
> > nut.target
> >
> > My understanding was to start via nut.target?
> >
> > Checking config directory permissions:
> > # ll |grep nut
> > drwxr-xr-x  2 root nut   4096 2023-07-04 18:46 nut/
> >
> >
> > # ll
> > total 72
> > -rw-r--r-- 1 root root  1076 2023-06-22 00:37 hosts.conf-off
> > -rw-r- 1 root nut   1921 2023-06-22 00:33 nut.conf
> > -rw-r- 1 root nut  10065 2023-07-04 18:35 ups.conf
> > -rw-r- 1 root nut  10068 2023-07-04 18:21 ups.conf~
> > -rw-r- 1 root nut   7390 2023-06-22 00:35 upsd.conf
> > -rw-r- 1 root nut   2425 2023-06-22 00:36 upsd.users
> > -rw-r- 1 root nut  20355 2023-07-04 18:46 upsmon.conf
> > -rw-r- 1 root nut   4201 2023-01-25 03:27 upssched.conf
> >
> > --
> >
>  
> 
> > Karl Schmidt  EMail k...@lrak.net
> 
> > 3209 West 9th Street  Ph (785) 841-3089
> > Lawrence, KS 66049
> >
> > The secret of getting ahead is getting started. The secret of
> > getting started is breaking your complex overwhelming tasks into
> > small manageable tasks, and then starting on the first one.
> > --Mark Twain
> >
>  
> 
> >
> > ___
> > Nut-upsuser mailing list

Re: [Nut-upsuser] failed after upgrade - upscode2: Missing UPCL after UPCL

[Jim Klimov via Nut-upsuser]

Normally yes - enable and start the target and the particular services
relevant to your setup.

For the binary you have from packaging (if not rebuilt as suggested
earlier), set debug_min=3 in ups.conf section for upscode2, to currently
trade driver viability for some storage traffic with more logs :\

Sorry about that,
Jim

On Wed, Jul 5, 2023, 02:29 Karl Schmidt  wrote:

> Ok - I'm wondering is this is a systemd config bit?
>
> systemctl restart nut-driver@malaysia.service
> Job for nut-driver@malaysia.service failed because the control process
> exited with error code.
> See "systemctl status nut-driver@malaysia.service" and "journalctl -xeu
> nut-driver@malaysia.service" for details.
> root@malaysia:~# systemctl status nut-driver@malaysia.service
> ● nut-driver@malaysia.service - Network UPS Tools - device driver for
> malaysia
>   Loaded: loaded (/lib/systemd/system/nut-driver@.service; enabled;
> preset: enabled)
>  Drop-In: /etc/systemd/system/nut-driver@malaysia.service.d
>   └─nut-driver-enumerator-generated-checksum.conf
>   Active: activating (auto-restart) (Result: exit-code) since Tue
> 2023-07-04 19:03:20 CDT; 9s ago
>  Process: 14926 ExecStart=/bin/sh -c
> NUTDEV="`/usr/libexec/nut-driver-enumerator.sh --get-device-for-service
> malaysia`" && [ -n "$NUTDEV" ] || { echo "FATAL: Could not find a NUT
> device section for service unit malaysia" >&2 ;
> exit 1 ; } ; /sbin/upsdrvctl start "$NUTDEV" (code=exited,
> status=0/SUCCESS)
>  Process: 14955 ExecStop=/bin/sh -c
> NUTDEV="`/usr/libexec/nut-driver-enumerator.sh --get-device-for-service
> malaysia`" && [ -n "$NUTDEV" ] || { echo "FATAL: Could not find a NUT
> device section for service unit malaysia" >&2 ;
> exit 1 ; } ; /sbin/upsdrvctl stop "$NUTDEV" (code=exited, status=1/FAILURE)
>
>
> >%-
> So I tried
> # /usr/libexec/nut-driver-enumerator.sh --get-device-for-service malaysia
> malaysia
>
>
>
>
> I'm not clear about all the unit files -
>
> ~# systemctl list-unit-files |grep nut
> nut-driver-enumerator.path enabled enabled
> nut-client.service alias   -
> nut-driver-enumerator.service  enabled enabled
> nut-driver@.serviceindirectenabled
> nut-monitor.serviceenabled enabled
> nut-server.service enabled enabled
> nut-driver.target  enabled enabled
> nut.target
>
> My understanding was to start via nut.target?
>
> Checking config directory permissions:
> # ll |grep nut
> drwxr-xr-x  2 root nut   4096 2023-07-04 18:46 nut/
>
>
> # ll
> total 72
> -rw-r--r-- 1 root root  1076 2023-06-22 00:37 hosts.conf-off
> -rw-r- 1 root nut   1921 2023-06-22 00:33 nut.conf
> -rw-r- 1 root nut  10065 2023-07-04 18:35 ups.conf
> -rw-r- 1 root nut  10068 2023-07-04 18:21 ups.conf~
> -rw-r- 1 root nut   7390 2023-06-22 00:35 upsd.conf
> -rw-r- 1 root nut   2425 2023-06-22 00:36 upsd.users
> -rw-r- 1 root nut  20355 2023-07-04 18:46 upsmon.conf
> -rw-r- 1 root nut   4201 2023-01-25 03:27 upssched.conf
>
> --
>
> 
> Karl Schmidt  EMail k...@lrak.net
> 3209 West 9th Street  Ph (785) 841-3089
> Lawrence, KS 66049
>
> The secret of getting ahead is getting started. The secret of
> getting started is breaking your complex overwhelming tasks into
> small manageable tasks, and then starting on the first one.
> --Mark Twain
>
> 
>
> ___
> Nut-upsuser mailing list
> Nut-upsuser@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] failed after upgrade - upscode2: Missing UPCL after UPCL

[Jim Klimov via Nut-upsuser]

Hello, thanks for the report and trying to wrap my head around it.

On a side note, it seems you've reported the same(?) UPS a couple of
decades ago? ;)
https://networkupstools.org/networkupstools-master.github.io/ddl/Exide/NetUPS_SE_PRC2400a.html
=>
https://github.com/networkupstools/nut-ddl/blob/master/Exide/Exide__NetUPS_SE_PRC2400a__upscode2__2.0.2__01.dev
=>
https://alioth-lists.debian.net/pipermail/nut-upsuser/2005-July/30.html

So to me there are a few issues that pop up from this recent message:

1) Do I understand correctly that in the topmost "screenshot" with debug
verbosity "2" the driver only proceeds to report the  `tcgetattr()` error
and exits, while the runs at greater verbosity they lived longer at least
(seems they also actually worked)?
* Did you check if this is linked to verbosity level (something broken
about debugging methods - these were refactored between 2.7.4 and 2.8.0),
* ...or to just running it several times - e.g. a competing driver instance
or some other program held the device node, but was killed off
during/before retries?
* Namely, there was a bug related to that debug-method refactor, and the
fix mentions `upscode2` specifically among the places it could pop up:
https://github.com/networkupstools/nut/pull/1495
** if this is it - running the packaged build at debug verbosity 3 or more
may be an option; otherwise a custom build either from debian sources of
your package + patch equivalent for the PR, or just of the current NUT
master: e.g.
https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests
may help

2) I suppose the udev rule above was hand-crafted? NUT sources do not
mention a "6001" (productId), and the "0403" (vendorId) is mentioned in a
`nutdrv_siemens_sitop` driver which was added in NUT 2.8.0 release.
* Asking because one of the changes introduced by 2.8.0 was a change from
"rules" to "hwdb" format in
https://github.com/networkupstools/nut/pull/1342/files - however as I'm
revisiting it now, I am having second thoughts: the changed file was about
UPower not UDev - both subsystems are from FreeDesktop project, but not
sure if the similarities don't end there.
* Originally was going to suggest that the NUT "udev rules" are replaced by
"udev hwdb" (format change leading to a more optimized use of binary
database under the systemd hood), but not fully sure this is actually the
case at the moment.
* Anyway, wondering if your rule is honored or ignored by systemd after the
OS upgrade - this may depend on config file location and naming. At least,
would for HWDB override mechanism:
https://www.freedesktop.org/software/systemd/man/hwdb.html
* ...and/or if it conflicts with something due to also-use of some same
SUBSYSTEM (not listed in your snapshot)...

Hope this helps,
Jim Klimov

On Tue, Jul 4, 2023 at 5:08 AM Karl Schmidt  wrote:

> Upgraded to Debian bookworm - working nut system stopped working.
>
> nut-server:   Installed: 2.8.0-7
>
>
> Trying :
>
> /usr/lib/nut/upscode2 -a malaysia -DD
> Network UPS Tools - UPScode II UPS driver 0.90 (2.8.0)
> Warning: This is an experimental driver.
> Some features may not function correctly.
>
> 0.00 [D1] debug level is '2'
> 0.002302 tcgetattr(/dev/ttyUSB-nut): Inappropriate ioctl for device
>
> Looks like two problems  - the udev rule isn't working any more?
> ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001",
> ATTRS{serial}=="AJV9MKOY", SYMLINK+="ttyUSB-nut",GROUP = "nut",
> MODE="0666"
>
>
> So I tried going straight to the device:
> /usr/lib/nut/upscode2 -a malaysia -
>
> This returns the following after a bit (Looks like it likes UPTP)..
>
>
> ] upscsend: 'UPTP'
> 1.857813 [D3] upscrecv: Empty line
> 1.921764 [D3] upscrecv: 5 bytes: 'NNAME'
> 2.097563 [D3] upscrecv: 20 bytes:'UPS 2400 VA FW -0026'
> 2.097593 [D2] Got value: NNAME UPS 2400 VA FW -0026
>
> So it IS talking to the UPS - but something above my knowledge is going
> wrong?
>
>
>
>
> Here is a longer output tail..
>
> /usr/lib/nut/upscode2 -a malaysia -
> Network UPS Tools - UPScode II UPS driver 0.90 (2.8.0)
> Warning: This is an experimental driver.
> Some features may not function correctly.
>
> 0.00 [D1] debug level is '4'
> 0.002995 [D1] input_timeout = 2 Sec
> 0.003002 [D1] output_pace = 200 uSec
> 0.003007 [D1] full_update_timer = 60 Sec
> 0.003011 [D1] use_crlf = 0
> 0.003016 [D1] use_pre_lf = 0
> 0.004308 [D3] upscsend: 'UPCL'
> 0.217722 [D3] upscrecv: Empty line
> 0.265688 [D3] upscrecv: 4 bytes: 'UPSS'
> 0.265717 [D2] Supports command: UPSS
> 0.313620 [D3] upscrecv: 4 bytes: 'UPDS'
> 0.313649 [D2] Supports command: UPDS
> 0.361570 [D3] upscrecv: 4 bytes: 'UPDV'
> 0.361599 [D2] Supports command: UPDV
> 0.409520 [D3] upscrecv: 4 bytes: 'UPTP'
> 0.409549 [D2] Supports command: UPTP
> 

[Nut-upsuser] NUT, Linux and libusb

[Jim Klimov via Nut-upsuser]

Cheers,

  Trying to wrap my head around an issue discussed in
https://github.com/networkupstools/nut/issues/1925

  The gist of it is that despite the usbhid-ups driver running as `root`
and seeing most of the regular run-time info, in the initial device search
it fails to find basic matching info points - the device vendor, product
and sernum strings:


   0.289953 [D2] Device does not match - skipping
   0.289960 [D2] Checking device 8 of 9 (0463/)
   0.311147 [D1] nut_libusb_open get iManufacturer failed, retrying...
   0.332348 [D1] nut_libusb_open get iManufacturer failed, retrying...
   0.353600 [D1] nut_libusb_open get iManufacturer failed, retrying...
   0.374780 [D1] nut_libusb_open get iProduct failed, retrying...
   0.395962 [D1] nut_libusb_open get iProduct failed, retrying...
   0.417222 [D1] nut_libusb_open get iProduct failed, retrying...
   0.438631 [D1] nut_libusb_open get iSerialNumber failed, retrying...
   0.46 [D1] nut_libusb_open get iSerialNumber failed, retrying...
   0.481267 [D1] nut_libusb_open get iSerialNumber failed, retrying...
   0.481286 [D2] - VendorID: 0463
   0.481291 [D2] - ProductID: 
   0.481296 [D2] - Manufacturer: unknown
   0.481301 [D2] - Product: unknown
   0.481306 [D2] - Serial Number: unknown
   0.481311 [D2] - Bus: 003
   0.481316 [D2] - Device: unknown
   0.481321 [D2] - Device release number: 0202
   0.481344 [D2] Trying to match device
   0.481350 [D2] match_function_subdriver (non-SHUT mode): matching a
device...
   0.481358 [D3] match_function_regex: matching a device...
   0.481364 [D2] Device matches


...which does not preclude it from being queried and accepted thanks to
numeric IDs and dialog with the device. Later on the lack of iProduct name
however creeps into "unknown 2000" (per mge-hid.c logic).

  Has anyone please got clues, hints, gut feelings and trench anecdotes to
share? Why could these basics be "invisible" to NUT (as root) while lsusb
and udevadm have no problem reporting them. Apparently a different
APC-oriented daemon also reported the name well.

Thanks in advance,
Jim Klimov
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Controlling outlets

[Jim Klimov via Nut-upsuser]

Unfortunately it is vague, at least on the NUT side, since it really
depends on capabilities of particular hardware (and then on who coded what
in NUT drivers and mapping tables). Often this level of precision is not
available or manageable externally at all, NUT or not (e.g. WebUI of an UPS
might have the abilities, but they are not exposed elsewhere for us to
tickle). I've more often seen such manage-abilities on smarter ePDUs (many
are monitorable, but not all are manageable per socket/group); rarely on
rack-mountable UPSes that have a dozen sockets so group them, and can't
remember if even saw that on smaller devices (even those that expose having
groups like small Eaton Ellipse ECO).

Generally (see docs/nut-names.txt for key words) - and assuming your
device/firmware and our drivers support that level of setup and granularity
- that could be a set up of `outlet.N.delay.start` or
`outlet.n.timer.start` to change a setting that UPS firmware then handles
during (re)start. An alternative might be to somehow set most of the
outlets to not power on by default, and when the server running NUT boots,
it would tell the outlets (or "load groups") to start explicitly via
`outlet.n.switch` command.

Note that if it is documented by vendor, then that might be as "staggered
start-up" which primarily aims to avoid the stress of starting everything
at once (POST usually runs at full power, before computer power-saving
modes based on load/temperature kick in; historically disk spin-up was a
large but short-lived Amps burst, etc.).

Jim

On Thu, Jun 15, 2023 at 8:12 PM Prometheus via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:

> I have a TrippLite UPS and am trying to control the sequence of which
> loads/outlets turn on after a simulated shutdown what would i need to
> configure to achieve this? The documentation is pretty vague about this
> matter ___
> Nut-upsuser mailing list
> Nut-upsuser@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Accessing: upsstats.cgi Error: no hosts to monitor (check hosts.conf)

[Jim Klimov via Nut-upsuser]

Not fully true about example configs in docs: man pages for CGI bits have
some :)

https://github.com/networkupstools/nut/blob/master/docs/man/upsset.conf.txt
https://github.com/networkupstools/nut/blob/master/docs/man/upsstats.cgi.txt
https://github.com/networkupstools/nut/blob/master/docs/man/hosts.conf.txt
etc.

Other than that, check permissions - e.g. OTOH if Apache user may read your
/etc/nut/hosts.conf (and the /etc/nut directory - may be inaccessible to
non-nut accounts completely, at least in packaging)

Hope this helps,
Jim

On Thu, Jun 15, 2023 at 12:38 AM Greg Troxel  wrote:

> Dan Grostick via Nut-upsuser 
> writes:
>
> > When Apache starts is complains about not finding the fully qualified
> domain name.
>
> That seems normal
>
> > In the past, upsstats.cgi would just load. I didn’t have to do any
> Apache2 configuration. I don’t know what has changed.
>
> in general this does need configuration.   read the apache config file.
> read the apache logs.
>
> > I’ve build NUT 2.8.0 from source, autogened, configured, make, make
> > install, and it is running. Is there something I’m missing that isn’t
> > getting updated when I do the make install?
>
> I would not expect that to adjust apache configs.
>
> > Upsstats.cgi and the others are located in the cgi-bin/nut/ folder.
>
> generally one needs a config stanza that says for this web path execute
> this binary.  Both ScriptAlias and Directory.
>
> > I can get to http://192.168.123.49/ and the Apache page loads.
> >
> > Any suggestions?
>
> Read the apache manual about to configure cgi.  (I'm actually serious.)
>
> I don't see any example config files in the sources.
>
>
> ___
> Nut-upsuser mailing list
> Nut-upsuser@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Upssched 100% CPU after updating Debian 12

[Jim Klimov via Nut-upsuser]

Thanks for the feedback.

Just the bit about "when provided by Debian" concerns me - we have a
slow-ish cadence of releases, and then distros take another year to ship
them :\

You might be reasonably served by a custom build (in-place or even
package). YMMV...

Jim

On Tue, Jun 13, 2023, 18:38 Kari Lempiäinen 
wrote:

> 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) is the there is this line (Network UPS Tools upsmon
> 2.8.0) every five minutes.
>
>
>
> Jun 13 19:17:08 fricka upssched[1896873]: Timer daemon started
>
> Jun 13 19:17:08 fricka upssched[1896873]: New timer:
> heartbeat-failure-timer (660 seconds)
>
> Jun 13 19:17:08 fricka nut-monitor[1896870]: Network UPS Tools upsmon 2.8.0
>
> Jun 13 19:22:08 fricka nut-monitor[1899911]: Network UPS Tools upsmon 2.8.0
>
> Jun 13 19:27:08 fricka upssched[1896873]: Cancelling timer:
> heartbeat-failure-timer
>
> Jun 13 19:27:08 fricka upssched[1896873]: New timer:
> heartbeat-failure-timer (660 seconds)
>
> Jun 13 19:27:08 fricka nut-monitor[1903379]: Network UPS Tools upsmon 2.8.0
>
> Jun 13 19:32:13 fricka nut-monitor[1906677]: Network UPS Tools upsmon 2.8.0
>
>
>
> That line wasn’t there previously. I will leave the old version in place
> until nut gets fixed and it’s been provided by Debian.
>
>
>
> This actually reminded me of a similar problem I had myself a lng time
> ago. I was writing a large software distribution program for a Windows
> platform. The connection between server and client were done by TCP
> sockets. In my server code there was place where I read reply from the
> client and the read (from socket) function didn’t return error code, but
> the data length was 0. In the documentation, at least at the time, it
> wasn’t specified directly that it was an error situation. My server code
> looped in a thread hogging CPU. When I modified the code to treat 0 bytes
> read as an error, everything worked fine.
>
>
>
> Best regards,
>
> Kari
>
>
>
> *From: *Jim Klimov 
> *Date: *Tuesday, 13. June 2023 at 18.36
> *To: *Kari Lempiäinen 
> *Cc: *Arnaud Quette via Nut-upsuser ,
> nut-upsdev , Dimitris Economou <
> dimitris.s.econo...@gmail.com>
> *Subject: *Re: [Nut-upsuser] Upssched 100% CPU after updating Debian 12
>
> So... determining that FD is to be reaped proved hard. Internet lore
> suggests fcntl() and poll() on the FD, but it just seems valid to them. The
> errno is also usually not raised (once I saw a "111: Connection refused"
> though).
>
> So the best dumb idea so far is to bail out if we spent the whole loop
> (128 attempts) and only got zero-sized read replies and no errors.
>
>
>
> https://github.com/networkupstools/nut/pull/1965
>
>
>
> Jim
>
>
>
> On Tue, Jun 13, 2023 at 4:06 PM Jim Klimov 
> wrote:
>
> 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.00 [D2] parse_at: is 'heartbeat@localhost' in AT command the
> 'heartbeat@localhost' we were launched to process?
>0.34 [D1] parse_at: 'heartbeat@localhost' in AT command
> matched the 'heartbeat@localhost' UPSNAME we were launched to process
>0.41 [D1] parse_at: processing CANCEL-TIMER
>0.54 [D2] parse_at: is 'heartbeat@localhost' in AT command the
> 'heartbeat@localhost' we were launched to process?
>0.57 [D1] parse_at: 'heartbeat@localhost' in AT command
> matched the 'heartbeat@localhost' UPSNAME we were launched to process
>0.60 [D1] parse_at: processing START-TIMER
>0.000151 [D1] Keeping stderr open due to debug verbosity 8
>0.000195 Timer daemon started
>0.000204 [D2] Timer daemon waiting for connections on pipefd 10
>0.250325 [D3] new connection on fd 7
>0.250377 New timer: heartbeat-failure-timer (660 seconds)
>0.250423 [D1] Exiting upssched (CLI process)
>
>
>
>0.00 [D2] parse_at: is 'heartbeat@localhost' in AT command the
> 'heartbeat@localhost' we were launched to process?
>0.39 [D1] parse_at: 'heartbeat@localhost' in AT command
> matched the 'heartbeat@localhost' UPSNAME we were launched to process
>0.47 [D1] parse_at: processing CANCEL-TIMER
>   14.745773 [D3] new connection on fd 8
>   14.745829 Cancelling timer: heartbeat-failure-timer
>0.000153 [D2] parse_at: is 'heartbeat@localhost' in AT command the
> 'heartbeat@localhost' we were launched to