Yeah, by the time I get to it it'll be out :)
On Sat, Jan 14, 2023 at 4:00 PM Jim Klimov <[email protected]> wrote: > 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
