[Nut-upsuser] Problem with Multiple USB UPSs, including multiple apparent CyberPower

[Jim Klimov]

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