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

[Charles Lepple via Nut-upsuser]

On Jan 14, 2023, at 6:51 PM, Bruce Pleat via Nut-upsuser 
 wrote:

> 
> (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...)

Raspbian (assuming that's the OS you're using for the Pi) basically repackages 
Debian, so it's up to the Debian maintainers as to when they deem 2.8.x ready. 
Apparently it is in the works: https://tracker.debian.org/pkg/nut 


However, we do have documentation on building from Git sources, which will 
include the more recent PRs that Jim mentioned:

https://github.com/networkupstools/nut/wiki/Building-NUT-on-Debian,-Raspbian-and-Ubuntu
 


-- 
Charles Lepple
clepple@gmail

___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

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

[Bruce Pleat via Nut-upsuser]

Yeah, by the time I get to it it'll be out :)


On Sat, Jan 14, 2023 at 4:00 PM Jim Klimov  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  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 
>> 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  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 
 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  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 

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

[Jim Klimov via Nut-upsuser]

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  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 
> 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  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 
>>> 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  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 

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

[Bruce Pleat via Nut-upsuser]

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  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  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 
>> 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  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@alioth-lists.debian.net> wrote:

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

[Jim Klimov via Nut-upsuser]

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  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 
> 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  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@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 

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

[Bruce Pleat via Nut-upsuser]

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  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  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@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  wrote:
>>>
 Bruce Pleat via Nut-upsuser 
 writes:

 > I'm using the 

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

[Jim Klimov via Nut-upsuser]

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

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

[Bruce Pleat via Nut-upsuser]

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

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

[Jim Klimov via Nut-upsuser]

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  wrote:

> Bruce Pleat via Nut-upsuser 
> 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@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser