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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> >>> 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 <[email protected]> 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 < >>>>> [email protected]> 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 <[email protected]> wrote: >>>>>> >>>>>>> Bruce Pleat via Nut-upsuser <[email protected]> >>>>>>> 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 >>>>>>> [email protected] >>>>>>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser >>>>>>> >>>>>> _______________________________________________ >>>>>> Nut-upsuser mailing list >>>>>> [email protected] >>>>>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser >>>>>> >>>>>
_______________________________________________ Nut-upsuser mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
