<div dir="auto"><div>Hello,<div dir="auto"><br></div><div dir="auto"> I can at least address part of your question -- NUT per se is not limited to monitoring one device per system. Each driver runs as a separate process, using a separate device node to talk to USB hardware.</div><div dir="auto"><br></div><div dir="auto"> Can't vouch however for other variables in the equation, such as system drivers, libusb (0.1 as supported in NUT releases so far), or behavior of the USB hub in the chipset (can it be just overloaded by two devices - electrically or logically? or entering some power-saving mode and resetting all ports instead of one? are there other devices connected to it?)</div><div dir="auto"><br></div><div dir="auto"> I wonder now, if using "auto" port instead of particular path like /dev/ttyUSB<N> can cause re-discoveries of the device over time, and if the two drivers collide then or steal devices from each other.</div><div dir="auto"><br></div><div dir="auto"> I believe that with at least master-branch codebase of NUT, it should be possible and valid to specify device details like vendor and product IDs, to auto-match a specific device per driver config instance.</div><div dir="auto"><br></div><div dir="auto">Jim</div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 10, 2021, 07:44 Jeff Rickman <<a href="mailto:jrickman@myamigos.us">jrickman@myamigos.us</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">** The actual problem is listed at the very bottom of this email **<br>
** All of the lead-in data is requested per the NUT webpages **<br>
<br>
OS:<br>
4.19.0-17-amd64 #1 SMP Debian 4.19.194-3 (2021-07-18) x86_64 GNU/Linux<br>
<br>
NUT version info:<br>
nut-client 2.7.4-8 amd64 network UPS tools - clients<br>
nut-server 2.7.4-8 amd64 network UPS tools - core system<br>
<br>
All aspects of NUT on this Debian system were installed from <br>
Debian-provided packages using their "apt" package tool. Even the Linux <br>
kernel on this system is from a Debian-provided package.<br>
<br>
2 UPS devices are in question here, but from different manufacturers<br>
<br>
UPS Model: Cyberpower CPS CP 1500C<br>
- CPS CP 1500C per 'upsc'<br>
- has the LCD display and NO front panel USB-A ports<br>
- older unit, perhaps 5 years old, batteries have been replaced once<br>
- more data requires UP de-installation<br>
- NUT "vendorid" of 0764<br>
- uses the NUT "usbhid-ups" driver as show here:<br>
<br>
Network UPS Tools - Generic HID driver 0.41 (2.7.4)<br>
USB communication driver 0.33<br>
Using subdriver: CyberPower HID 0.4<br>
cps_adjust_battery_scale: battery readings will be scaled by 2/3<br>
<br>
<br>
UPS Model: Eaton 5S 1500 LCD (from vendor's tag)<br>
- brand new unit<br>
- Batteries were manufactuered in April 2021 per shipping box<br>
- NUT "vendorid" of 0463<br>
- uses the NUT "usbhid-ups" driver as shown here:<br>
<br>
Network UPS Tools - Generic HID driver 0.41 (2.7.4)<br>
USB communication driver 0.33<br>
Using subdriver: MGE HID 1.39<br>
<br>
<br>
** THE PROBLEM **<br>
<br>
Either UPS connected to any USB2 port on this PC will work fine without <br>
any troule what-so-ever.<br>
<br>
When BOTH UPS are connected to discrete USB2 ports on this PC, or any <br>
other Linux PC where I run NUT, _EITHER_UPS_ will eventually drop out <br>
with a "Communication Lost" message. There are no mysterious external <br>
factors taking place like AC power outages, AC power spikes, or heavy <br>
loads on the UPS. A 'upsc' printout of "ups.load" reads 10 or less at <br>
all times on the Cyberpower unit; the Eaton unit has nothing plugged <br>
into it.<br>
<br>
A query of the "missing" UPS using "upsc" might show something like this:<br>
<br>
nano1 ~ # upsc es1500<br>
Init SSL without certificate database<br>
Error: Unknown UPS<br>
<br>
Yes, both UPS devices have been entered into "ups.conf" as follows:<br>
[cpups]<br>
# ups.vendorid: 0764<br>
driver = usbhid-ups<br>
port = auto<br>
desc = "CP UPS on NANO1"<br>
<br>
[es1500]<br>
# ups.vendorid: 0463<br>
driver = usbhid-ups<br>
port = auto<br>
desc = "Eaton Ellipse Pro 1500 on NANO-1"<br>
<br>
I have experimented with "direct calling" the "usbhid-ups" driver with <br>
the "-x vendorid=" parameter... even though the manpages suggest not <br>
doing that; they suggest we use "upsdrvctl" instead, but that can't seen <br>
to handle 2 different vendor's UPS devices with different vendorid <br>
values both using the same driver. Even that direct calling approach <br>
does not help as either UPS will eventually disappear with a <br>
"Communication Lost" message on the console.<br>
<br>
Some might be tempted to say, "Oh that UPS must be going bad." or "That <br>
USB cable or port must be going bad.". I thought that a few YEARS AGO <br>
when I first saw this problem occur. I can easily swap around USB2 <br>
ports, USB cables (I have a few spares), and monitoring PCs - none of <br>
that makes any difference at all.<br>
<br>
My only workaround hads been to separate the 2 UPS devices that both <br>
used the NUT "usbhid-ups" driver to separate monitoring devices (low <br>
power Atom PCs or Raspberry Pi boxes). That workaround is getting old <br>
and I am hoping for a better solution.<br>
<br>
I prefer to monitor my UPS devices even when the devices they protect <br>
are powered down. In that manner I have caught signs of UPS needing <br>
batteries replaced and odd AC power problems.<br>
<br>
<br>
Does the NetworkUPSTools project officially support 2 physically <br>
different UPS from 2 completely different vendors (based on NUT reported <br>
"vendorid") both accessing the same NUT driver on the same monitoring <br>
device? The manpage for the "usbhid-ups" driver does not say if it does <br>
or does not support multiple UPS devices requiring it.<br>
<br>
<br>
-- <br>
"No one gets sick on Wednesdays." (unknown)<br>
<br>
_______________________________________________<br>
Nut-upsuser mailing list<br>
<a href="mailto:Nut-upsuser@alioth-lists.debian.net" target="_blank" rel="noreferrer">Nut-upsuser@alioth-lists.debian.net</a><br>
<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser" rel="noreferrer noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser</a><br>
</blockquote></div></div></div>