[Nut-upsuser] Problem with Multiple USB UPSs, including multiple apparent CyberPower
Jim Klimov
jimklimov+nut at gmail.com
Sun Jan 15 00:00:06 GMT 2023
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/20230115/b3caaec7/attachment-0001.htm>
More information about the Nut-upsuser
mailing list