[Nut-upsuser] Problem with Multiple USB UPSs, including multiple apparent CyberPower
Bruce Pleat
bpleat at gmail.com
Sun Jan 15 00:02:05 GMT 2023
Yeah, by the time I get to it it'll be out :)
On Sat, Jan 14, 2023 at 4:00 PM Jim Klimov <jimklimov+nut at gmail.com> wrote:
> Just a note: recent PRs are naturally not in 2.8.0 release (April 2022),
> but would be in eventual 2.8.1
>
> Jim
>
> On Sun, Jan 15, 2023, 00:51 Bruce Pleat <bpleat at gmail.com> wrote:
>
>> 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/3c19f372/attachment.htm>
More information about the Nut-upsuser
mailing list