[Nut-upsuser] Problem with Multiple USB UPSs, including multiple apparent CyberPower
Bruce Pleat
bpleat at gmail.com
Sat Jan 14 23:51:13 GMT 2023
Part of what made my life harder is nut-scanner isn't in the package.
Once I get a chance, I'll update to 2.8, but that'll be a little while off.
(Any clue how to get 2.8 included in the package provider for my Raspberry
Pi is presumably beyond the scope of this list, but if someone knows and
wants to let me know, I wouldn't complain...)
On Sat, Jan 14, 2023 at 3:12 PM Jim Klimov <jimklimov+nut at gmail.com> wrote:
> Thanks!
>
> FWIW if you do get to test new code,
> https://github.com/networkupstools/nut/pull/1811 adds warnings for
> situations like yours. Would be great to check if it works actually, with
> many "same-serial" devices :)
>
> Jim
>
>
> On Sat, Jan 14, 2023, 23:39 Bruce Pleat <bpleat at gmail.com> wrote:
>
>> Thank you, looks like the regex idiosyncracy might have been the issue.
>>
>> My current file:
>> [sl]
>> driver = usbhid-ups
>> port = auto
>> desc = "CyberPower UPS SL"
>> product = "SL.*"
>> productid = 0501
>> vendorid = 0764
>> #model = "SL Series"
>>
>> [ab]
>> driver = usbhid-ups
>> port = auto
>> desc = "CyberPower UPS AB"
>> product = "AB.*"
>> productid = 0501
>> vendorid = 0764
>> #model = "ABST600"
>>
>> [cp]
>> driver = usbhid-ups
>> port = auto
>> desc = "CyberPower UPS CP"
>> product = "CP.*"
>> productid = 0501
>> vendorid = 0764
>> #model = "CP685AVR-G"
>>
>> [apc]
>> driver = usbhid-ups
>> port = auto
>> desc = "APC BE600M1 UPS"
>> #product = "*Back-UPS ES 600M1*"
>> vendorid = 051d
>> productid = 0002
>> #model = "Back-UPS ES 600M1"
>>
>> I did not test the USB settings since this works. (For search results:
>> This means I did not test multiple identical devices either.)
>>
>> Thank you again.
>>
>>
>> On Sat, Jan 14, 2023 at 12:01 PM Jim Klimov <jimklimov+nut at gmail.com>
>> wrote:
>>
>>> So, regarding wildcards (globs) vs. regular expressions, the latter
>>> being used for such matches, I believe (did not check now) the config
>>> sections should look like this:
>>>
>>> [cp]
>>> driver = usbhid-ups
>>> port = auto
>>> desc = "CyberPower UPS CP"
>>> model = "CP685AVR-G"
>>> vendorid = "0764"
>>> product = "CP.*"
>>>
>>> Note the ".*" (dot meaning "any char", asterisk "any amount") so either
>>> "CP" or CP followed by any chars would match. The "CP*" regex means "C"
>>> followed by any amount of "P" (0+).
>>> I *think* this is also sensitive to start/end markers of a string, so as
>>> spelled here a "CP" in the middle of a string would also match. If you want
>>> it at a start, a "^CP" or "^CP.*" or pedantically "^CP.*$" may suffice.
>>>
>>> With examples you posted e.g. "*SL*" the error could be run-time regex
>>> compilation (any amount of what? - for the first asterisk), while the "-x
>>> model" key is unrecognized and so not handled as a regex (or anything else
>>> for that matter).
>>>
>>> So also note the lack of "-x" in device section lines, to be clear(er) :)
>>>
>>> Finally, try to add the "bus" and "device" numbers as reported by
>>> `lsusb` (NUT drivers started in higher-verbosity debug mode can also report
>>> the values they saw on device but could not match or rule-out), to match
>>> essentially by their non-unique combos, e.g.
>>>
>>> [cp]
>>> driver = usbhid-ups
>>> port = auto
>>> desc = "CyberPower UPS CP"
>>> model = "CP685AVR-G"
>>> vendorid = "0764"
>>> product = "CP.*"
>>> bus = 003
>>> device = 001
>>>
>>> Note that for older NUT built with libusb-0.1 API support (likely in NUT
>>> 2.7.4 and older packages), the device number may be misleading - not the
>>> port number which `lsusb` reports, but just the iteration counter of NUT
>>> lookup, so prone to change with re-plugging of other devices. For
>>> libusb-1.0 API this should be the non-zero hardware-related port number (if
>>> supported by HW/OS/drivers) by default (or iteration counter if OS does not
>>> tell).
>>>
>>> On Sat, Jan 14, 2023 at 8:16 PM Bruce Pleat <bpleat at gmail.com> wrote:
>>>
>>>> Thank you both for answering.
>>>>
>>>> I tried with and without the "-x" as the manual wasn't clear enough to
>>>> me.
>>>> I tried with and without wildcards (e.g., "*SL*", "*SL Series*", "SL
>>>> Series" for that one).
>>>> I tried other permutations before asking for help here.
>>>> ("model" throws an error, "-x model" doesn't, which was confusing)
>>>>
>>>> I am not in position to change versions now - I am using whatever is
>>>> installed by Bullseye/Raspbian. (I wouldn't know how to ask the package
>>>> version be updated?)
>>>>
>>>> If I unplug them and switch the order I plug them in (regardless of USB
>>>> slot?), it impacts which Cyber Power shows up by default - only the last
>>>> will be detected.
>>>>
>>>> On Sat, Jan 14, 2023, 04:03 Jim Klimov via Nut-upsuser <
>>>> nut-upsuser at alioth-lists.debian.net> wrote:
>>>>
>>>>> Actually in merged PRs of recent weeks there can be several suitable
>>>>> fixes:
>>>>>
>>>>> 1) support for common USB matching parameters in more drivers (though
>>>>> usbhid-ups has long had it);
>>>>>
>>>>> 2) nut-scanner should provide more of these parameters in generated
>>>>> config sections, in particular "device" port numbers;
>>>>>
>>>>> 3) for obscenely poor cases when devices can not be identified as
>>>>> unique, new "allow_duplicates" flag was added, to not stop iterating if a
>>>>> first "good match" is busy. Caveat emptor here!
>>>>>
>>>>> In your case, I hope adding the device numbers (3 digits) to configs
>>>>> should help. Also `-x` is for command-libe specification of such
>>>>> parameters. In config file it is just key=value. For these matchers they
>>>>> are generally regexes (not shell globs). Please do RTFM :)
>>>>>
>>>>> Jim
>>>>>
>>>>> On Sat, Jan 14, 2023, 01:11 Greg Troxel <gdt at lexort.com> wrote:
>>>>>
>>>>>> Bruce Pleat via Nut-upsuser <nut-upsuser at alioth-lists.debian.net>
>>>>>> writes:
>>>>>>
>>>>>> > I'm using the latest updates to OS and running the latest apt nut
>>>>>> packages
>>>>>> > in the dist (2.7.x?).
>>>>>>
>>>>>> Debian 11 has 2.7.4.
>>>>>>
>>>>>> That's old; 2.8.0 was released in spring of 2022. And git master has
>>>>>> a
>>>>>> lot of improvements since 2.8.0, and I would therefore recommend
>>>>>> trying
>>>>>> that. I think but am not 100% sure that there is a fix for the
>>>>>> problem
>>>>>> you are seeing.
>>>>>>
>>>>>> _______________________________________________
>>>>>> Nut-upsuser mailing list
>>>>>> Nut-upsuser at alioth-lists.debian.net
>>>>>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>>>>>>
>>>>> _______________________________________________
>>>>> Nut-upsuser mailing list
>>>>> Nut-upsuser at alioth-lists.debian.net
>>>>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20230114/cf476c63/attachment.htm>
More information about the Nut-upsuser
mailing list