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

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>

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>

On Jan 14, 2023, at 6:51 PM, Bruce Pleat via Nut-upsuser <nut-upsuser at
alioth-lists.debian.net> wrote:
> 
> (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...)
Raspbian (assuming that's the OS you're using for the Pi) basically
repackages Debian, so it's up to the Debian maintainers as to when they deem
2.8.x ready. Apparently it is in the works: https://tracker.debian.org/pkg/nut
<https://tracker.debian.org/pkg/nut>

However, we do have documentation on building from Git sources, which will
include the more recent PRs that Jim mentioned:

https://github.com/networkupstools/nut/wiki/Building-NUT-on-Debian,-Raspbian-and-Ubuntu
<https://github.com/networkupstools/nut/wiki/Building-NUT-on-Debian,-Raspbian-and-Ubuntu>

-- 
Charles Lepple
clepple at gmail

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20230114/44d56395/attachment-0001.htm>