In regards to the "auto" setting for "port" in "ups.conf", after a few
hours of online reading a number of days ago, I eventually found a post
to the effect that the "usbhid-ups" driver works in a way that "auto" is
the appropriate setting. The programmers can explain better than I as to
why that is.
I have experimented with separating these USB-attached devices, and they
are the only _external_ USB devices, to different "bus" values per
'lsusb' and that does not seem to make any difference.
In my case, 1 USB bus has 1 UPS connected and another USB bus has the
other UPS connected. No other USB devices are on those USB buses per
'lsusb'.
If USB power saving is a potential issue, then I am interested in what
Linux commands (this is a Debian Linux box) might be used to check for
that. Nothing in a 'lsusb -v' output suggesys anything.
As noted in my original post, these 2 UPS have different 'vendorid' and
I have tried calling the drivers with that value attached in the format
of "-x vendorid=XXXX", but that does not make any difference. Perhaps
the driver simply ignores that specific variable? I have not tried other
unique variables.
My own thinking on this matter is leaning in the direction of some sort
of software collision or competition since I can 'power cycle by power
switch', 'hard reset by reset switch', or 'shutdown -r 0' via CLI the
Linux box and that reboot clears the problem for a random amount of time.
Yes, the occurence of this issue is random, but it appears guaranteed to
happen within 60 minutes or so of starting up NUT after a power-up or
reboot.
For the record, I have a monitoring PC that watches 2 different UPS
devices that use 2 different drivers in NUT. That PC does not encounter
the issue that I am reporting here.
On 11/11/2021 5:26 PM, Jim Klimov wrote:
Hello,
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.
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?)
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.
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.
Jim
On Wed, Nov 10, 2021, 07:44 Jeff Rickman <jrick...@myamigos.us
<mailto:jrick...@myamigos.us>> wrote:
** 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
Nut-upsuser@alioth-lists.debian.net
<mailto: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
