[Nut-upsuser] Problem with Multiple USB UPSs, including multiple apparent CyberPower
Bruce Pleat
bpleat at gmail.com
Sat Jan 14 22:38:34 GMT 2023
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/0b903a4a/attachment.htm>
More information about the Nut-upsuser
mailing list