** The actual problem is listed at the very bottom of this email **
** All of the lead-in data is requested per the NUT webpages **
OS:
4.19.0-17-amd64 #1 SMP Debian 4.19.194-3 (2021-07-18) x86_64 GNU/Linux
NUT version info:
nut-client 2.7.4-8 amd64 network UPS tools - clients
nut-server 2.7.4-8 amd64 network UPS tools - core system
All aspects of NUT on this Debian system were installed from
Debian-provided packages using their "apt" package tool. Even the Linux
kernel on this system is from a Debian-provided package.
2 UPS devices are in question here, but from different manufacturers
UPS Model: Cyberpower CPS CP 1500C
- CPS CP 1500C per 'upsc'
- has the LCD display and NO front panel USB-A ports
- older unit, perhaps 5 years old, batteries have been replaced once
- more data requires UP de-installation
- NUT "vendorid" of 0764
- uses the NUT "usbhid-ups" driver as show here:
Network UPS Tools - Generic HID driver 0.41 (2.7.4)
USB communication driver 0.33
Using subdriver: CyberPower HID 0.4
cps_adjust_battery_scale: battery readings will be scaled by 2/3
UPS Model: Eaton 5S 1500 LCD (from vendor's tag)
- brand new unit
- Batteries were manufactuered in April 2021 per shipping box
- NUT "vendorid" of 0463
- uses the NUT "usbhid-ups" driver as shown here:
Network UPS Tools - Generic HID driver 0.41 (2.7.4)
USB communication driver 0.33
Using subdriver: MGE HID 1.39
** THE PROBLEM **
Either UPS connected to any USB2 port on this PC will work fine without
any troule what-so-ever.
When BOTH UPS are connected to discrete USB2 ports on this PC, or any
other Linux PC where I run NUT, _EITHER_UPS_ will eventually drop out
with a "Communication Lost" message. There are no mysterious external
factors taking place like AC power outages, AC power spikes, or heavy
loads on the UPS. A 'upsc' printout of "ups.load" reads 10 or less at
all times on the Cyberpower unit; the Eaton unit has nothing plugged
into it.
A query of the "missing" UPS using "upsc" might show something like this:
nano1 ~ # upsc es1500
Init SSL without certificate database
Error: Unknown UPS
Yes, both UPS devices have been entered into "ups.conf" as follows:
[cpups]
# ups.vendorid: 0764
driver = usbhid-ups
port = auto
desc = "CP UPS on NANO1"
[es1500]
# ups.vendorid: 0463
driver = usbhid-ups
port = auto
desc = "Eaton Ellipse Pro 1500 on NANO-1"
I have experimented with "direct calling" the "usbhid-ups" driver with
the "-x vendorid=" parameter... even though the manpages suggest not
doing that; they suggest we use "upsdrvctl" instead, but that can't seen
to handle 2 different vendor's UPS devices with different vendorid
values both using the same driver. Even that direct calling approach
does not help as either UPS will eventually disappear with a
"Communication Lost" message on the console.
Some might be tempted to say, "Oh that UPS must be going bad." or "That
USB cable or port must be going bad.". I thought that a few YEARS AGO
when I first saw this problem occur. I can easily swap around USB2
ports, USB cables (I have a few spares), and monitoring PCs - none of
that makes any difference at all.
My only workaround hads been to separate the 2 UPS devices that both
used the NUT "usbhid-ups" driver to separate monitoring devices (low
power Atom PCs or Raspberry Pi boxes). That workaround is getting old
and I am hoping for a better solution.
I prefer to monitor my UPS devices even when the devices they protect
are powered down. In that manner I have caught signs of UPS needing
batteries replaced and odd AC power problems.
Does the NetworkUPSTools project officially support 2 physically
different UPS from 2 completely different vendors (based on NUT reported
"vendorid") both accessing the same NUT driver on the same monitoring
device? The manpage for the "usbhid-ups" driver does not say if it does
or does not support multiple UPS devices requiring it.
--
"No one gets sick on Wednesdays." (unknown)
_______________________________________________
Nut-upsuser mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
