Nut upsuser - Jan 2023 - Problem with Multiple USB UPSs, including multiple apparent CyberPower

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/08f99723/attachment-0001.htm>

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>