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
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
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
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
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
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
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
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]
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"
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"
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;
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 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+
13 matches
Mail list logo
