<div dir="ltr">Part of what made my life harder is nut-scanner isn't in the package.<div><br></div><div>Once I get a chance, I'll update to 2.8, but that'll be a little while off.</div><div>(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...)<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jan 14, 2023 at 3:12 PM Jim Klimov <<a href="mailto:jimklimov%2Bnut@gmail.com">jimklimov+nut@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Thanks! <div dir="auto"><br></div><div dir="auto">FWIW if you do get to test new code, <a href="https://github.com/networkupstools/nut/pull/1811" target="_blank">https://github.com/networkupstools/nut/pull/1811</a> adds warnings for situations like yours. Would be great to check if it works actually, with many "same-serial" devices :)</div><div dir="auto"><br></div><div dir="auto">Jim</div><div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jan 14, 2023, 23:39 Bruce Pleat <<a href="mailto:bpleat@gmail.com" target="_blank">bpleat@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Thank you, looks like the regex idiosyncracy might have been the issue.</div><div><br></div><div>My current file:</div><div>[sl]<br>        driver = usbhid-ups<br>        port = auto<br>        desc = "CyberPower UPS SL"<br>        product   = "SL.*"<br>        productid = 0501<br>        vendorid  = 0764<br>        #model     = "SL Series"<br><br>[ab]<br>        driver = usbhid-ups<br>        port = auto<br>        desc = "CyberPower UPS AB"<br>        product   = "AB.*"<br>        productid = 0501<br>        vendorid  = 0764<br>        #model     = "ABST600"<br><br>[cp]<br>        driver = usbhid-ups<br>        port = auto<br>        desc = "CyberPower UPS CP"<br>        product  = "CP.*"<br>        productid = 0501<br>        vendorid = 0764<br>        #model    = "CP685AVR-G"<br><br>[apc]<br>        driver = usbhid-ups<br>        port = auto<br>        desc = "APC BE600M1 UPS"<br>        #product   = "*Back-UPS ES 600M1*"<br>        vendorid  = 051d<br>        productid = 0002<br>        #model     = "Back-UPS ES 600M1"<br></div><div><br></div><div>I did not test the USB settings since this works. (For search results: This means I did not test multiple identical devices either.)</div><div><br></div><div>Thank you again.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jan 14, 2023 at 12:01 PM Jim Klimov <<a href="mailto:jimklimov%2Bnut@gmail.com" rel="noreferrer" target="_blank">jimklimov+nut@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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:</div><div><br></div><div>
[cp]<br>        driver = usbhid-ups<br>        port = auto<br>        desc = "CyberPower UPS CP"<br>        model = "CP685AVR-G"<br>        vendorid = "0764"<br>        product  = "CP.*" <br></div><div><br></div><div>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+).</div><div>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.</div><div><br></div><div>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).<br></div><div><br></div><div>So also note the lack of "-x" in device section lines, to be clear(er) :)</div><div><br></div><div>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.</div><div><br></div><div>
<div>
[cp]<br>        driver = usbhid-ups<br>        port = auto<br>        desc = "CyberPower UPS CP"<br>        model = "CP685AVR-G"<br>        vendorid = "0764"<br>        product  = "CP.*"</div><div>        bus = 003</div><div>        device = 001<br></div><div><br></div>

</div><div>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).<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jan 14, 2023 at 8:16 PM Bruce Pleat <<a href="mailto:bpleat@gmail.com" rel="noreferrer" target="_blank">bpleat@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto">Thank you both for answering.</div><div dir="auto"><br></div><div>I tried with and without the "-x" as the manual wasn't clear enough to me.</div><div dir="auto">I tried with and without wildcards (e.g., "*SL*", "*SL Series*", "SL Series" for that one).</div><div dir="auto">I tried other permutations before asking for help here.</div><div dir="auto">("model" throws an error, "-x model" doesn't, which was confusing)</div><div dir="auto"><br></div><div dir="auto">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?)</div><div dir="auto"><br></div><div dir="auto">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.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jan 14, 2023, 04:03 Jim Klimov via Nut-upsuser <<a href="mailto:nut-upsuser@alioth-lists.debian.net" rel="noreferrer" target="_blank">nut-upsuser@alioth-lists.debian.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Actually in merged PRs of recent weeks there can be several suitable fixes:<div dir="auto"><br></div><div dir="auto">1) support for common USB matching parameters in more drivers (though usbhid-ups has long had it);</div><div dir="auto"><br></div><div dir="auto">2) nut-scanner should provide more of these parameters in generated config sections, in particular "device" port numbers;</div><div dir="auto"><br></div><div dir="auto">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!</div><div dir="auto"><br></div><div dir="auto">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 :)</div><div dir="auto"><br></div><div dir="auto">Jim</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jan 14, 2023, 01:11 Greg Troxel <<a href="mailto:gdt@lexort.com" rel="noreferrer noreferrer" target="_blank">gdt@lexort.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Bruce Pleat via Nut-upsuser <<a href="mailto:nut-upsuser@alioth-lists.debian.net" rel="noreferrer noreferrer noreferrer" target="_blank">nut-upsuser@alioth-lists.debian.net</a>><br>
writes:<br>
<br>
> I'm using the latest updates to OS and running the latest apt nut packages<br>
> in the dist (2.7.x?).<br>
<br>
Debian 11 has 2.7.4.<br>
<br>
That's old; 2.8.0 was released in spring of 2022.  And git master has a<br>
lot of improvements since 2.8.0, and I would therefore recommend trying<br>
that.  I think but am not 100% sure that there is a fix for the problem<br>
you are seeing.<br>
<br>
_______________________________________________<br>
Nut-upsuser mailing list<br>
<a href="mailto:Nut-upsuser@alioth-lists.debian.net" rel="noreferrer noreferrer noreferrer" target="_blank">Nut-upsuser@alioth-lists.debian.net</a><br>
<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser</a><br>
</blockquote></div>
_______________________________________________<br>
Nut-upsuser mailing list<br>
<a href="mailto:Nut-upsuser@alioth-lists.debian.net" rel="noreferrer noreferrer" target="_blank">Nut-upsuser@alioth-lists.debian.net</a><br>
<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser" rel="noreferrer noreferrer noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser</a><br>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>