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

[Jim Klimov via Nut-upsuser]

FWIW, https://github.com/networkupstools/nut/pull/1709 (when merged) should
over time make custom rebuilds to replace standard packages (or older
custom builds) easier by tracking CONFIG_FLAGS involved in the existing
binary build.

Jim


On Sun, Jan 15, 2023 at 11:49 AM Jim Klimov  wrote:

> What Charles said ;)
>
> Generally (for any random OS) it is about a couple of things:
> * Getting build environment/prerequisites set up as needed:
>   - reading NUT docs/config-prereqs.txt can go a long way for many OSes
> that CI regularly tests (or does not to regularly, but were touched upon
> once since that document started): section K in the rendered docs at
> https://networkupstools.org/docs/user-manual.chunked/index.html
>   - reading OS packaging recipes, if they define build prerequisites and
> procedure (RPM, DEB do)
> * Getting "configure" script parameters (mostly paths) right, especially
> if you want to replace the package rather than do a one-off test with a new
> driver or tool without installing at all (may still want the right
> sysconfdir, statepath, user/group) - also from packaging recipes
>
> Jim
>
>
> On Sun, Jan 15, 2023 at 4:27 AM Charles Lepple via Nut-upsuser <
> nut-upsuser@alioth-lists.debian.net> wrote:
>
>> On Jan 14, 2023, at 6:51 PM, Bruce Pleat via Nut-upsuser <
>> nut-upsuser@alioth-lists.debian.net> 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
>>
>
___
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]

What Charles said ;)

Generally (for any random OS) it is about a couple of things:
* Getting build environment/prerequisites set up as needed:
  - reading NUT docs/config-prereqs.txt can go a long way for many OSes
that CI regularly tests (or does not to regularly, but were touched upon
once since that document started): section K in the rendered docs at
https://networkupstools.org/docs/user-manual.chunked/index.html
  - reading OS packaging recipes, if they define build prerequisites and
procedure (RPM, DEB do)
* Getting "configure" script parameters (mostly paths) right, especially if
you want to replace the package rather than do a one-off test with a new
driver or tool without installing at all (may still want the right
sysconfdir, statepath, user/group) - also from packaging recipes

Jim


On Sun, Jan 15, 2023 at 4:27 AM Charles Lepple via Nut-upsuser <
nut-upsuser@alioth-lists.debian.net> wrote:

> On Jan 14, 2023, at 6:51 PM, Bruce Pleat via Nut-upsuser <
> nut-upsuser@alioth-lists.debian.net> 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
>
___
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

[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

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

[Greg Troxel]

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] Problem with Multiple USB UPSs, including multiple apparent CyberPower

[Bruce Pleat via Nut-upsuser]

Trying to configure multiple UPS on one Raspberry Pi 4 (Bullseye).

Issue: Whenever more than one is plugged in, one shows as all - as in "upsc
x" for all of them shows identical information for one UPS rather distinct
for each plugged in.

OS:
/proc/version = "Linux version 5.10.103-v7l+ (dom@buildbot)
(arm-linux-gnueabihf-gcc-8 (Ubuntu/Linaro 8.4.0-3ubuntu1) 8.4.0, GNU ld
(GNU Binutils for Ubuntu) 2.34) #1529 SMP Tue Mar 8 12:24:00 GMT 2022"

I'm using the latest updates to OS and running the latest apt nut packages
in the dist (2.7.x?).

UPS in use:
One UPS is APC, two are branded Cyber Power, one is branded Amazon Basics
but lsusb matches to (and others report is built by) Cyber Power. All are
"driver = usbhid-ups".

Relevant lsusb lines:
ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS
ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS
ID 051d:0002 American Power Conversion Uninterruptible Power Supply
ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS
(Bus/Device varies greatly, of course, so omitted)

Here's my ups.conf file:


[sl]
driver = usbhid-ups
port = auto
desc = "CyberPower UPS SL"
-x product = "SL Series"
-x model = "SL Series"
-x productid = 0501
-x vendorid  = 0764

[ab]
driver = usbhid-ups
port = auto
desc = "CyberPower UPS AB"
-x product = ABST600
-x model = ABST600
-x productid = 0501
-x vendorid  = 0764

[cp]
driver = usbhid-ups
port = auto
desc = "CyberPower UPS CP"
-x model = "CP685AVR-G"
-x vendorid = "0764*"
-x product  = "CP*"

[apc]
driver = usbhid-ups
port = auto
desc = "APC BE600M1 UPS"
-x product = "Back-UPS ES 600M1*"
-x model = "Back-UPS ES 600M1"
-x vendorid  = 051d



Major issue:
For whatever reason, only one UPS gets recognized regardless of how precise
or loose I am in the matching - I've commented out or restored each of the
"-x" parameters.

When I only have one plugged in at a time, here's the ups.model (same as
device.model) info for the four:
apc: APC: Back-UPS ES 600M1
ab: CPS (Amazon): ABST600
sl: CPS:  SL Series
cp: CPS:  CP685AVR-G

The three units recognized by lsusb as Cyber Power do not report a
device.serial, so I can't match based on that.

When multiple are plugged in, no matter which I "upsc x", it comes back for
the same one (i.e., "upsc sl" and "upsc apc" return the same UPS's data).

I've tried commenting out various combinations of the "-x" (thinking maybe
it was "or" instead of "and"), no difference.

Thanks in advance for any leads/help.

(Refs:
https://networkupstools.org/docs/user-manual.chunked/apfs02.html
https://networkupstools.org/docs/man/ups.conf.html
https://networkupstools.org/ddl/Cyber_Power_Systems/CP1500AVRLCD.html
https://perfecto25.medium.com/monitor-cyberpower-ups-devices-with-raspberry-pi-99559725dbb8
https://www.howtoraspberry.com/2020/11/how-to-monitor-ups-with-raspberry-pi/
https://www.networkshinobi.com/raspberry-pi-as-ups-server-via-the-nut/
https://docs.technotim.live/posts/NUT-server-guide/
https://melgrubb.com/2016/12/11/rphs-v2-ups/
https://community.openhab.org/t/beginners-guide-to-network-ups-tools-nut-on-a-raspberry-pi/78443/1
)
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser