[Nut-upsuser] NUT Configuration Question
Manuel Wolfshant
wolfy at nobugconsulting.ro
Fri Nov 12 01:34:07 GMT 2021
On 11/12/21 01:49, Jeff Rickman wrote:
>
> 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.
>
A configuration which specifies the vendorid or the busid in the config
file i.e. similar to the one from the man page ( included below for
reference ) is definitely supported
[mge]
driver = usbhid-ups
port = auto
vendorid = 0463
[tripplite]
driver = usbhid-ups
port = auto
vendorid = 09ae
>
> 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 <jrickman at myamigos.us
>> <mailto:jrickman at 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.
>>
More information about the Nut-upsuser
mailing list