Re: [Nut-upsuser] CyberPower CST150UC: Question re: battery.runtime.low configuration settings

[Charles Lepple via Nut-upsuser]

On Apr 24, 2024, at 3:45 PM, tim.o via Nut-upsuser 
 wrote:
>> Have you tried any other values? 3600 is hex 0xe10, and 16 is 0x10, so it is 
>> quite possible the UPS is using an 8-bit field to store battery.runtime.low. 
>> I'm guessing the maximum is going to be 255.
>> 
> I am not sure I follow. Would you mind unpacking this for me?
> When I initially issued 'upsrw' this is what was returned. What does the 
> value '300' indicate, if not seconds;

Confirmed, it's seconds. (The maximum length for that field is just the number 
of digits that the driver is prepared to accept as a string, but it just 
converts them to a number to send to the UPS.)

> and attempting to change it to '3600' sets it two '16'. Is this what you mean 
> when you're referring to a '8-bit field'?

Yes, sorry, I missed the default of 300, and I was mixing bits and hexadecimal. 
At least 9 bits are needed to represent 300 decimal.

Let's say the UPS stores the runtime in 9 bits, and consider what would happen 
if you send 3600:

3600 decimal = 1110 0001  binary

Low 9 bits = ___0 0001  binary = 16 decimal

(note that 0 and -1 may have special meaning to the UPS, but this will probably 
hold true for other values)

My guess is that if you sent 520, upsc would return 8 (for a revised maximum of 
511 seconds). If not, the UPS is even weirder than most :-)

As you found, the ignorelb option is available to work around limitations in 
the UPS shutdown logic.

-- 
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] CyberPower CST150UC: Question re: battery.runtime.low configuration settings

[Charles Lepple via Nut-upsuser]

> On Apr 23, 2024, at 3:51 PM, tim.o via Nut-upsuser 
>  wrote:
> 
> The value changed to battery.runtime.low: 16, instead of 3600. I don't 
> understand why, because executing the command resulted in SUCCESS.

Unfortunately, the SUCCESS response is just saying that upsrw was able to send 
that request to upsd (i.e. the username/password were correct). As you saw, the 
real proof is in what you read back from upsc.

Have you tried any other values? 3600 is hex 0xe10, and 16 is 0x10, so it is 
quite possible the UPS is using an 8-bit field to store battery.runtime.low. 
I'm guessing the maximum is going to be 255.

This is not entirely surprising - we have a GitHub issue label specific to CPS 
for issues with their USB HID protocol implementation.

-- 
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] Are all measurements are in seconds?

[Charles Lepple via Nut-upsuser]

On Mar 14, 2024, at 11:09 AM, Alan via Nut-upsuser 
 wrote:
> 
> Hi,
> 
> I am studying (in a few months I might go on a TV quiz show :-)
> Rodger's excelent guide and wanted to confirm that all measurements in
> NUT are in seconds.

all timing measurements are in seconds, yes.

> For example, the Cyber Power System CP1500 AVR UPS returns that the
> **driver.parameter.pollfreq = 30**. This means that I can (maybe
> should) adjust the settings within NUT.CONF to match this value.
> Setting this value to 2 seconds gains will return the same value 14
> times.
> 
> Is my reasoning correct?

I'm not sure I follow - which settings do you want to adjust, and why? Do you 
mean driver polling intervals in ups.conf, or upsmon.conf (POLLFREQ*)?

The pollfreq value (the time between full updates of all HID reports, in 
usbhid-ups) defaults to 30 seconds to not bog down the UPS. Less-critical 
values (ups.load, input.frequency, etc.) may not update as often this way. 
However, the OB/LB flags are part of the set that is polled and/or checked via 
USB "interrupt" transfers every pollinterval seconds (default: 2).

You can see the full/quick difference by stopping NUT, then manually starting 
the driver with at least one "-D" flag. Or reference the driver source for your 
UPS to see the possible set of values that the driver will check for. For Cyber 
Power, that table starts at 
https://github.com/networkupstools/nut/blob/master/drivers/cps-hid.c#L187 and 
the ones with HU_FLAG_QUICK_POLL will be updated per pollinterval.

While this throttling may seem unnecessary, note that many UPS microcontrollers 
use USB 1.x low-speed transfers (1.5 Mbit/sec bit raw rate, but throughput can 
be 10x less) and there is a fair amount of back-and-forth to poll USB HID 
values that aren't sent automatically whenever the USB interrupt pipe is polled.

That said, if you are observing the same value 14x in a row, then changing and 
holding for another 14x-15x, it is certainly possible that the UPS is not 
updating its values as frequently as the driver polls.

-- 
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] driver.parameter.offdelay vs ups.delay.shutdown / driver.parameter.ondelay vs ups.delay.start

[Charles Lepple via Nut-upsuser]

On Mar 14, 2024, at 11:41 AM, Alan via Nut-upsuser 
 wrote:

> Hi,
> 
> My Cyber Power reports these two values. Each pair has the same value.
> 
> Would they normally be the same thing?

Without any intervening `upsrw` changes, yes. `driver.parameter.*` corresponds 
to the initial value from ups.conf or `-x` command-line flags.

For usbhid-ups (and a few other drivers), the offdelay parameter sets 
ups.delay.shutdown when the driver starts:

https://github.com/networkupstools/nut/blob/v2.8.1/drivers/usbhid-ups.c#L1300-L1306

and likewise for ondelay and ups.delay.start.

-- 
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] Cyber Power System CP1500 AVR UPS: changing battery.charge.low value [ups.delay.start sidebar]

[Charles Lepple via Nut-upsuser]

On Mar 9, 2024, at 6:14 PM, Charles Lepple  wrote:
> 
> On Mar 9, 2024, at 5:16 PM, chrib...@duck.com wrote:
>> I used the override.ups.delay.start = -1 in nut.conf and this is now being 
>> reported.

The ups.conf man page describes the direction that the data flows with 
override.*:

> Use with caution! This will only change the appearance of the variable to the 
> outside world [read: clients connected to upsd], internally in the UPS the 
> original value is used.

https://networkupstools.org/docs/man/ups.conf.html#_ups_fields

-- 
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] Cyber Power System CP1500 AVR UPS: changing battery.charge.low value [ups.delay.start sidebar]

[Charles Lepple via Nut-upsuser]

On Mar 9, 2024, at 5:16 PM, chrib...@duck.com wrote:
> 
> The posting at 
> https://github.com/networkupstools/nut/issues/432#issuecomment-405371395 
> references ups.delay.start and suggests setting it to -1.
> 
> upsrw -l pve1@localhost listed this as modifiable but any attempt at 
> modifying the value failed.  I used the override.ups.delay.start = -1 in 
> nut.conf and this is now being reported.

My original suggestion (which implies the use of override.*) is mainly for 
setting values that the UPS driver uses to decide when to shut down (if it is 
told to ignore the UPS LB flag, and must calculate the LB condition in the 
driver).

ups.delay.start is a value that is only interpreted by the UPS hardware (the 
driver just passes it through to upsd/upsc when override.* is not in play). So 
IMHO it doesn't make sense to override it, unless you have something else that 
needs to read it. In most cases, the startup delay happens when NUT is not 
running yet (assuming the machine with upsd/driver is powered by that UPS).

If the UPS won't let you change a delay variable, then I don't think override 
is going to help here.

> Two observations are that once a variable setting is overridden, upsrw -w 
> will not show these values.  Is it by design? 
> 
Others will have to speak to the design rationale of override.* and default.*, 
but I guess I tend to think of override.* as hard-coding a value in the driver 
(and therefore something that I wouldn't attempt to change with upsrw, but with 
the conf file instead). I guess that probably means the variable should be 
removed from the list of read/write variables.
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] NUT 2.8.1 (source build) Pi OS bookworm 32 bit - nut-monitor trying to connect to UPS - Connection Refused

[Charles Lepple via Nut-upsuser]

On Mar 8, 2024, at 8:22 AM, Dan Grostick via Nut-upsuser 
 wrote:
> 
> I've installed 2.8.1 on a Raspberry PI 5 using Pi OS bookworm 64 bit (Debian 
> 12) with success.
> 
> When I take that same configuration to a PI 3B running bookworm 32 bit, 
> compile from source, use the same files from /etc/nut, I get a 'nut-monitor  
> ups@localhost  Connection refused.
> usbhid-ups and dummy-ups are running at the time.
> 
> What should I be looking for?
> 
> Dan

If you only see:

nut-server[6536]: listening on 192.168.x.y

and no equivalent line for 127.0.0.1, then monitoring ups-name@localhost will 
likely not work. You may want to listen on the wildcard 0.0.0.0 address instead 
of a specific address (helps if the IP is dynamic), or just add "LISTEN 
127.0.0.1".

-- 
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] Cyber Power System CP1500 AVR UPS: changing battery.charge.low value

[Charles Lepple via Nut-upsuser]

On Mar 8, 2024, at 7:07 AM, Roger Price  wrote:
> 
> Perhaps setting lowbatt = 50 in ups.conf would help.

Roger, good point.

That option is missing in the usbhid-ups man page, so I logged an issue to 
remind us to fix that: https://github.com/networkupstools/nut/issues/2356

Since I am used to fighting the Cyber Power Systems shutdown timers, I 
automatically assumed it was a similar issue where the UPS accepts the value 
then ignores it.

Alan, your shutdown timers might need to be multiples of 60 seconds (I see 20 
and 30 for ups.delay.shutdown and ups.delay.start, respectively), and that 
might not even be enough. Discussion: 
https://github.com/networkupstools/nut/issues/432#issuecomment-405371395 and 
https://github.com/networkupstools/nut/issues/625

-- 
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] Cyber Power System CP1500 AVR UPS: changing battery.charge.low value

[Charles Lepple via Nut-upsuser]

On Mar 4, 2024, at 3:23 PM, Alan C. Bonnici via Nut-upsuser 
 wrote:
> 
> I would like to push up the shutdown process to initiate when the ups is at 
> 50% rather than 10% mainly because there is a need to down other servers.
> 

Some UPSes have a limited range for adjusting the LB threshold, or do not save 
the threshold in non-volatile storage. To work around this, you can use the 
"ignorelb" setting to ignore the UPS low battery indication, and have the 
driver generate the LB flag based on the UPS reported runtime or charge level:

https://networkupstools.org/docs/man/ups.conf.html#_ups_fields

-- 
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] Keeping the traffis on or off the list ?

[Charles Lepple via Nut-upsuser]

On Feb 17, 2024, at 11:17 AM, Greg Troxel wrote:
> 
> I would guess that reply-to is getting added because of header munging.
> Turn off munging and this all goes away.

Please re-read my email that explains the current setup of the list: 
https://alioth-lists.debian.net/pipermail/nut-upsuser/2024-February/013560.html

TL;DR we are not root on the mailing list server.

This has worked out well enough for a few decades, during which time I 
acknowledge that email standards have moved a bit (an as users of the Alioth 
mailing list service, we have not had to think about this much). The only time 
this is a problem is when a major email provider decides to switch to hard 
enforcement of standards like DKIM, and a raft of people get unsubscribed due 
to the bounce messages.

The list currently has "reply_goes_to_list" set to "poster". According to the 
documentation:

> reply_goes_to_list: This variable controls whether Mailman will add its own 
> Reply-To: header, and if so, what the value of that header will be (not 
> counting original header stripping - see above).
> 
> When you set this variable to Poster, no additional Reply-To: header will be 
> added by Mailman. This setting is strongly recommended.

The other settings will explicitly add a Reply-To header.

Maybe this is a bug in either Mailman or its documentation. Either way, with 
the knobs we have available to us, I am inclined to do the next best thing, 
which is to set the reply-to back to the list (and maybe add a disclaimer to 
the footer of the list to pay attention to the destination addresses). If that 
is not acceptable, I think the idea of moving to an alternate mailing list 
server is still on the table. (I have my hands full managing my home email 
server, so I am not volunteering for this job.)

[please use Reply-All as we get this all sorted out, thanks. No intentional 
asides to me; I will instinctively add back the list address as I have been 
doing manually for years when people email me directly about NUT issues.]

-- 
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] Keeping the traffis on or off the list ?

[Charles Lepple via Nut-upsuser]

On Feb 17, 2024, at 7:57 AM, Jim Klimov wrote:
> 
> Other than that, I think the mailing list service we get from alioth comes 
> "as is", not sure we can configure much about it. Can check, but not really 
> inclined to - let humans decide how to best post and what is correct for each 
> case :)
> 
Jim,

I think this made more sense before, when the mailing list didn't *add* a 
Reply-To that goes to the individual sender.

Since the defaults have changed, and there seems to be no option for "don't add 
Reply-To" (see my previous email with links to applicable documentation), I 
personally think the default should be changed to reply to the list (which 
individual senders can still override).

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

Re: [Nut-upsuser] Keeping the traffis on or off the list ?

[Charles Lepple via Nut-upsuser]

On Feb 17, 2024, at 3:29 AM, Roger Price wrote:
> 
> Note that the Reply-To goes back to the original poster, not the list.
> Many mailing lists encourage the subscribers to "keep the list traffic on the 
> list", rather than wandering off into private discussions.  The nut-upsuser 
> setup has exactly the opposite effect.

Thanks for bringing this upstream change to our attention.

For context, NUT has been using Mailman through the Alioth mailing list 
services ever since the project used CVS and Subversion code hosting services 
from Alioth as well. While it is handy to not have to maintain all of the 
infrastructure of a mailing list server (especially in this age of complex 
requirements for successful mail delivery), it also means that we do not have a 
ton of visibility into the changes made upstream.

As Matus pointed out, the header-signing requirements are apparently forcing 
mailing lists to put in default values for some headers. While I am not sure I 
agree with the Mailman decision, this has made me aware of two settings that 
seem to have crept in when we weren't looking:

- first_strip_reply_to (currently: no)

- reply_to_goes_to_list (currently: poster)

Documentation: https://www.gnu.org/software/mailman/mailman-admin/node11.html

I have not yet adjusted reply_to_goes_to_list on the Mailman end, but I set the 
Reply-To header in my mail client in addition to putting the list in the To 
field. In theory, the first_strip_reply_to setting should allow my Reply-To 
header to pass through.

If that works, I am okay with changing reply_to_goes_to_list to actually point 
to the list. IMHO, if subscribers really want replies to their messages to 
include their address, they can go to the trouble of setting a Reply-To header 
that includes both the list and their personal address.

On Feb 17, 2024, at 5:09 AM, Roger Price wrote:
> 
> Debian doesn't do it.  Why should we?


Debian (and NetBSD, to Greg's point) are larger projects that can afford to 
make much more intentional choices about their infrastructure, such as mailing 
lists. They can also directly monitor the fallout from decisions such as not 
signing headers. If anyone is interested in taking on the project of 
maintaining a separate mailing list server for NUT, please get in touch with 
the -owner alias for this list. (If that sounds like an overreaction, but you 
would still like to help manage the current mailing lists, we could also use a 
few more moderators.)

[please use Reply-All as we get this all sorted out, thanks. No intentional 
asides to me; I will instinctively add back the list address as I have been 
doing manually for years when people email me directly about NUT issues.]

-- 
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-upsdev] Cyber Power LE1000DG UPS

[Charles Lepple via Nut-upsdev]

On Jan 13, 2024, at 6:28 PM, Justin Choponis  wrote:
> 
> I have a Cyber Power LE1000DG UPS I got from Best Buy this weekend. I plan to 
> use it with a TrueNAS scale system, and it is connected via USB. Vendor link: 
> https://www.cyberpowersystems.com/product/ups/battery-backup/le1000dg/.
>  
> TrueNAS has you pick a UPS driver. I could not find any “LE” related models 
> on https://networkupstools.org/stable-hcl.html (which is the list TrueNAS 
> uses). Per your guidance on that page, I tried one that I hoped was 
> compatible: “Cyber Power Systems ups 2 Value 800E USB (usbhid-ups)”. Every 
> Cyber Power system with USB on the list there seems to use usbhid-ups anyway 
> – so perhaps picking any of them is reasonable?

Picking anything that maps to usbhid-ups does seem reasonable, though it's 
possible that they pass additional options for certain models (I think FreeNAS 
does this). I don't know of any that are needed for CPS, though.

>  I can have the TrueNAS system power down when power is lost and the UPS runs 
> on battery, but I see occasional messages about communications being lost 
> with the UPS (saying “Statistics could not be recovered”). I also see 
> statistics being gathered in other alert messages (like it is working fine).

No mention of stability issues for LE825G: 
https://alioth-lists.debian.net/pipermail/nut-upsdev/2013-November/006563.html 
(but I don't know different the DG and G models differ)

It is probably worth skimming some of the issues here to see whether there is 
any wisdom applicable to your case: 
https://github.com/networkupstools/nut/issues?q=+label%3A%22CyberPower+%28CPS%29%22+label%3A%22Connection+stability+issues%22

Different versions of the underlying OS and NUT might handle things 
differently, but I don't think I have run across this particular issue (my CPS 
UPS is currently on a Mac, so I don't see connect/disconnect logs). The usual 
hardware suggestions are to swap out the USB cable, and try a powered USB hub.

-- 
Charles Lepple
clepple@gmail

> _
> Nut-upsdev mailing list
> Nut-upsdev@alioth-lists.debian.net <mailto:Nut-upsdev@alioth-lists.debian.net>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev

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

Re: [Nut-upsuser] NUT server with multiple raspberry pi

[Charles Lepple via Nut-upsuser]

On Jan 9, 2024, at 8:19 PM, Claudio Zanetta Penna via Nut-upsuser 
 wrote:
> 
> My problem is that I want to connect a second Raspberry to the first one with 
> NUT server on it, so the information obtained by the second can be sent to 
> the server 
> and be presented in only one web GUI.
> 
If you are referring to this tutorial: 
https://technotim.live/posts/NUT-server-guide/

then on the first Raspberry Pi with the web interface, you should be able to 
replace "localhost" in "MONITOR upsname@localhost" with the hostname of the 
second Pi.

-- 
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-upsdev] RunTimeToEmpty is in minutes or seconds?

[Charles Lepple via Nut-upsdev]

On Jan 2, 2024, at 1:49 PM, Kelly Byrd  wrote:
> 
> My question for you all is what units ups.powersummary.runtimetoempty is 
> supposed to be in? This doc from USB.org: 
> https://www.usb.org/sites/default/files/hut1_4.pdf (Section 31.2) says 
> minutes,

Do you mean the Power Device Class documentation?

I agree that the description on p.37 of 
https://usb.org/sites/default/files/pdcv11.pdf says minutes, but the last 
reference to RunTimeToEmpty on p.57 is embedded in a descriptor that specifies 
the units to be seconds. I think most manufacturers end up reporting seconds, 
since the descriptors tend to look fairly similar to the spec.

> Is this just a case where real world UPS' are using seconds so we're stuck 
> with it now?

That, and the fact that that the HID protocol uses a lot of base SI units.

> I guess it's being pedantic, but IMO trying to measure a UPS remaining 
> runtime with accuracy is sort of silly. I noticed this because I'm cobbling 
> together a personal project that has absurd capacity for the load, somewhere 
> around 2-3 days from a fully charged battery and I'm using NUT's Arduino 
> driver to report things.

To be honest, this is exactly the sort of thing that the Physical and Logical 
units are meant to address. You can keep the internal time-remaining counter in 
whatever format makes sense in the firmware, and specify some Logical units to 
map that back to seconds so you aren't sending 32-bit numbers for something 
with a really small range.

I'm pretty sure there is one UPS where the shutdown timer settings are kept in 
minutes, and the NUT drivers expose seconds because the vendor specified a 
Physical-to-Logical factor of 60.

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

Re: [Nut-upsuser] Help with CGI upsstats.cgi giving "file not found"

[Charles Lepple via Nut-upsuser]

On Dec 21, 2023, at 1:13 PM, Tim Reimers KA4LFP wrote:

> Yet, a "file" command shows it to be an 32-bit ELF executable.
> 

Although you mentioned that they are both running Debian bullseye, Pi2 is 
64-bit capable, and it looks like the Raspbian image is 64-bit (aarch64 in the 
/lib pathnames). So that won't run 32-bit ELFs without additional packages. 
(The Model B can only run 32-bit code.)

Did the packages for Pi2 install upsstats.cgi to /var/www/cgi-bin? Does the 
problem go away if you use the copy installed to /usr/lib/cgi-bin/nut ? (If 
not, it seems like a bug in the 64-bit Raspbian build - I wonder if they keep 
the build logs online somewhere. But a 32-bit binary creeping in to a 64-bit 
build seems quite unlikely.)

I don't have a 64-bit Pi to test this, but I'm fairly certain the original 
"file not found" error is related to not being able to find/load the 32-bit 
libc on a 64-bit system.

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

Re: [Nut-upsuser] Help with CGI upsstats.cgi giving "file not found"

[Charles Lepple via Nut-upsuser]

On Dec 20, 2023, at 5:17 PM, Tim Reimers KA4LFP via Nut-upsuser wrote:
> 
> First, a summary:
> - I have a RasPI  (hereafter referred to as Pi1)  running Bullseye in which 
> this all WORKS FINE -- the upsd/upsc/ monitor services, etc
> - I have a SECOND RasPI (hereafter referred to as Pi2) running Bullseye in 
> which ONLY the CGI scripts do not work. 
> All other (upsc/upsd/systemctl) show normal status and work to retrieve data 
> from the single UPS attached to each Pi.
> 
I'm not quite sure what is missing[*], but when you get no output from a 
program, and a "file not found" error from bash, it is usually a missing shared 
library that prevents the executable from fully loading.

[*] the confusing part is that the other NUT command line tools aren't affected.

Was the CGI program installed from the Debian nut-cgi package? Or was it built 
from source, or copied from the other Pi?

You should get output similar to this from ldd (this is from an amd64 Ubuntu 
system, so details may differ, but consider overall structure):

$ ldd /usr/lib/cgi-bin/nut/upsstats.cgi 
linux-vdso.so.1 (0x7fff1a99b000)
libupsclient.so.4 => /lib/x86_64-linux-gnu/libupsclient.so.4 
(0x7eff6ebec000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7eff6ebc9000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7eff6e9d7000)
libnss3.so => /usr/lib/x86_64-linux-gnu/libnss3.so (0x7eff6e888000)
libssl3.so => /usr/lib/x86_64-linux-gnu/libssl3.so (0x7eff6e829000)
libplds4.so => /usr/lib/x86_64-linux-gnu/libplds4.so (0x7eff6e824000)
libplc4.so => /usr/lib/x86_64-linux-gnu/libplc4.so (0x7eff6e81b000)
libnspr4.so => /usr/lib/x86_64-linux-gnu/libnspr4.so (0x7eff6e7db000)
/lib64/ld-linux-x86-64.so.2 (0x7eff6ec29000)
libnssutil3.so => /usr/lib/x86_64-linux-gnu/libnssutil3.so (0x7eff6e7a8000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7eff6e7a2000)

If any of the libraries don't have a path after "=>", that's something to 
investigate on the working Pi (e.g. "dpkg --search libnss3.so 
" to see which package provides that library)

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

Re: [Nut-upsdev] Minutemen UPS Driver

[Charles Lepple via Nut-upsdev]

I think the problem is that there were some communication errors, as noted 
here: https://github.com/networkupstools/nut/issues/555

I would want to test thoroughly before relying on it for automated shutdowns.

-- 
Charles Lepple
clepple@gmail

> On Dec 14, 2023, at 8:35 AM, Jim Klimov via Nut-upsdev 
>  wrote:
> 
> That's MinutemAn and such a key word exists in usbhid-ups subdriver 
> tripplite-hid :)
> 
> 
> Specifically, the "PRO RT 2U" series is among the few mentioned by name:
> 
> $ git grep -i minuteman
> NEWS.adoc:   * add Delta Minuteman UPS VID/PID [PR #1230, issues #555 and 
> #1227]
> drivers/tripplite-hid.c:/* Delta/Minuteman */
> drivers/tripplite-hid.c:/* Delta/Minuteman Enterprise Plus E1500RM2U 
> */
> drivers/tripplite-hid.c:/* Delta/Minuteman PRO1500RT2U */
> 
> 
>   Oddly, it seems nobody posted it to neither HCL nor DDL so far...
> 
> Hope this helps,
> Jim Klimov
> 
> 
> On Thu, Dec 14, 2023 at 1:08 PM James Parascand via Nut-upsdev 
>  <mailto:nut-upsdev@alioth-lists.debian.net>> wrote:
>> I am wondering if there is a way to have Nut Server monitor a Minutemen UPS.
>> 
>> https://minutemanups.com/uninterruptible-power-supply/pro-rt2u-line-interactive-uninterruptible-power-supply/
>> 
>> Thanks
>> James
>> ___
>> Nut-upsdev mailing list
>> Nut-upsdev@alioth-lists.debian.net 
>> <mailto:Nut-upsdev@alioth-lists.debian.net>
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
> ___
> Nut-upsdev mailing list
> Nut-upsdev@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev

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

Re: [Nut-upsuser] usbhid-ups not loading with Arduino Leonardo on Ubuntu 23.10

[Charles Lepple via Nut-upsuser]

> On Oct 29, 2023, at 9:25 PM, Kelly Byrd  wrote:
> 
> I have seen reports of folks claiming this just worked for them out of the 
> box,

Here you're referring to just making things work on Windows or macOS, right? I 
don't think it will be quite as simple with NUT, mostly because the NUT drivers 
are trying to expose all of the variables and commands, rather than just the 
simple shutdown bits.

I'm not sure where a generic HID PDC driver sits in the priority list at the 
moment, but IIRC the current driver is still fairly tightly coupled to the USB 
VID and resulting model-specific mappings. So once you get the permissions 
worked out, you would still need a new source file that maps the HID Usage 
"paths" to NUT variable names. It's one of those things that in hindsight, it 
would have been great to fall back to a generic mapping that just looks at the 
OB and LB bits, but real-world UPSes are messy, and we would have needed those 
model-specific mappings to be able to distinguish things like input and output 
voltage.

That said, if you change the VID/PID to something supported already, things 
just might work. The "Couldn't retrieve descriptors" is likely a result of the 
driver dropping root privileges, then not having enough permissions to write to 
the /dev/bus/usb node to request the HID descriptor. I don't know how your 
VID/PID got into the udev rules file - VID 2341 doesn't show up in the NUT Git 
source tree.

-- 
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] had to reinstall on new drive, lost all nut related .conf's

[Charles Lepple via Nut-upsuser]

> On Jun 19, 2023, at 8:33 PM, gene heskett wrote:
> 
>>> However, any attempt to add it to the [myups] stanza in ups.conf is a 
>>> showstopper error. No mention of this "flag" in the rest of the file's 
>>> comments. 
>> 
>> So how does that syntax actually look like?
> 

In ups.conf, you should be able to do something like this:

[myups]
driver = usbhid-ups
port = auto
pollonly

If that isn't working, check for spurious UPS-specific lines in the "global" 
section (above the first UPS stanza like "[myups]"), or vice-versa (global 
options covered in ups.conf documentation that got added to the end of the 
ups.conf template).

("pollonly" doesn't appear in the standard ups.conf template because it is 
specific to usbhid-ups.)

ref: https://networkupstools.org/docs/man/usbhid-ups.html#_extra_arguments

- Charles


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

Re: [Nut-upsuser] Monitoring a remote UPS

[Charles Lepple via Nut-upsuser]

On Jun 9, 2023, at 5:25 AM, Nichole Kaligian via Nut-upsuser 
 wrote:
> 
> Hi,
> 
> Every guide I'm finding is connecting their NUT server to the UPS directly. 
> Is there no option to monitor a network-attached UPS? On its IP or hostname? 
> This was my first assumption when looking at a product called 'Network UPS 
> Tools', but it seems I'm misunderstanding? Thanks for any advice you can give 
> me.

TBH those guides exist because the most common small UPS models don't have 
network connections, and therefore you need additional software like NUT to 
serve power status over the network. Without knowing your UPS model or system 
version, I'm still going to hazard a guess that the vendor of your 
network-connected UPS provides a network-based shutdown solution for you 
already, and many people are going to opt for that direct approach (rather than 
inserting NUT in the middle).

There are a few drivers for network-connected UPS models, and the correct 
driver depends on the protocol that the UPS uses. Probably the most common 
network UPS protocol is SNMP: 
https://networkupstools.org/docs/man/snmp-ups.html but there is also a driver 
for Eaton's XML/HTTP protocol: 
https://networkupstools.org/docs/man/netxml-ups.html (see NUT FAQ #43 
https://networkupstools.org/docs/FAQ.html )

You can find out whether your UPS is well-supported by filtering on 
"Connection=Network" on the Hardware Compatibility List: 
https://networkupstools.org/stable-hcl.html?connection=Network (note that while 
some UPSes may use SNMP, information can still be in vendor-proprietary 
extensions, and therefore not immediately accessible to the generic SNMP driver)

- Charles



> ___
> 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] Using 'dummy.ups' for a real application, not just testing...

[Charles Lepple via Nut-upsuser]

> On Feb 19, 2023, at 8:18 AM, Tom via Nut-upsuser 
>  wrote:
> 
> Good Morning,
> 
> I am working on setting up a 12V DC UPS that will power a NAS and a router 
> for a few hours.  It contains some lithium-ion batteries, and a BMS to 
> control charging.  Since it is just a dumb box with batteries, it has no 
> intelligence to inform the NAS of its status.  This is where NUT comes in...
> 
> I would like to incorporate a Raspberry Pi NUT server into this scheme.  The 
> Rpi can measure input voltage, and output voltage & current to determine the 
> status of this simple UPS.
> 
> With some of the excellent documentation online, I have gotten a NUT server 
> running on the Rpi, and my NAS (a Qnap) has been able to read the status.  I 
> used the 'dummy-ups' driver for testing this and it worked great.
> 
> Now, for the real business - Since this is entirely homebrew, there is not an 
> appropriate driver available.  I read about creating my own driver using 
> 'skel.c' as a template.  But, nobody else would have any interest in my very 
> specialized driver.

You'd be surprised, especially if you are using a more common battery 
management chip.

>   Plus - it seems overwhelming to me when I attempt to understand how to 
> build NUT and I fear getting totally bogged down in all the minutiae of that.

While it looks somewhat intimidating at first glance, we do have instructions 
for building a version of NUT from source that matches a lot of the paths that 
are in the Raspbian (Debian) package: 
https://github.com/networkupstools/nut/wiki/Building-NUT-on-Debian,-Raspbian-and-Ubuntu

> But, it occurred to me - Why can't I just use 'dummy-ups' for this as-is?  I 
> can have a simple 'c' or Python program to read my values (to determine 
> status) and then just write a few relevant lines into a '.dev' file to be 
> served out to the LAN with the factory NUT server tools?  My file would 
> contain something like this:

For what it's worth, I think using dummy-ups for prototyping is a good idea, 
especially if you put the .dev file on a RAM-based filesystem  (as Greg 
suggested), like /run or /dev/shm. (I forget whether Raspbian usually puts /tmp 
on the SD card.)

There are also a few i2c-based drivers in the NUT tree, such as 
https://github.com/networkupstools/nut/blob/master/drivers/pijuice.c and 
https://github.com/networkupstools/nut/blob/master/drivers/asem.c

I have some notes on interfacing to an i2c-based battery pack from a few years 
ago: https://www.ghz.cc/charles/NUT/OpenElectrons_SmartUPS.html The code is 
pretty old, and the rest of NUT has been updated since then, but it's probably 
helpful for estimating the scope of converting a standalone C-based i2c program 
into a NUT driver. (I ended up not merging that driver into NUT.)

> 
> ups.mfr: Tom
> ups.model: My Contraption
> battery.charge: 100
> ups.status: OL
> input.voltage: 1.02
> battery.voltage: 11.5
> output.voltage: 11.2
> output.current: 3.4
> battery.runtime: 1000
> 
> I write this file periodically (maybe every 15-60 seconds) and the Rpi NUT 
> server would be none the wiser and just keep supplying the constantly updated 
> contents of this file to the NAS.

I think the NAS is probably only looking at ups.status (OL/OB/LB) to trigger 
shutdown (barring any custom "shut down when variable X gets below a 
threshold), but it certainly can't hurt to publish the other values if you have 
something to log them.

-- 
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] Init SSL without certificate database

[Charles Lepple via Nut-upsuser]

> On Jan 28, 2023, at 6:14 PM, Jim Klimov via Nut-upsuser 
>  wrote:
> 
> and I have a hard time guessing what distro might ship a "driver.version: 
> DSM7-1-1-42930-workplus-version2-repack-42930-220712". Ask them what NUT 
> version (release or snapshot) they use, and if they would consider shipping a 
> newer one?

Jim, veering OT from the original post, but probably a Synology NAS? e.g. 
https://www.synoforum.com/threads/another-dsm7-regression-ups.6586/page-4

I could see this happening if someone unpacks a NUT release tarball in a larger 
Git/SVN working copy, and the NUT version expansion code picks up one of the 
parent repository's tags.

Ubuntu 22.04 includes NUT 2.7.4 + some Debian/Ubuntu patches, and is built 
against NSS instead of OpenSSL, hence that error. Ref: 
https://packages.ubuntu.com/jammy/nut -> 
https://packages.ubuntu.com/jammy/nut-client -> 
https://packages.ubuntu.com/jammy/libupsclient4

Roger, I don't think self-signed certificates will help in this case - if 
present, the code also logs a message to stderr showing the location of the 
certificate database: 
https://github.com/networkupstools/nut/blob/v2.7.4/clients/upsclient.c#L363
___
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 
<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
 
<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] battery.voltage Powercom Macan MRT-3000

[Charles Lepple via Nut-upsuser]

Please email nut-upsuser@alioth-lists rather than nut-upsuser-owner, thanks!

> On Jan 10, 2023, at 12:58 PM, Alex Rydzewski  wrote:
> 
> Yes, You right) battery.voltage
> 
> I found these data among other
> 
>0.522942 [D5] hid_lookup_path: 00840004 -> UPS
>0.522950 [D5] hid_lookup_path: 00840024 -> PowerSummary
>0.522958 [D5] hid_lookup_path: 00840030 -> Voltage
>0.522967 [D1] Path: UPS.PowerSummary.Voltage, Type: Feature, ReportID: 
> 0x12, Offset: 0, Size: 16, Value: 220
> 
>0.558943 [D5] hid_lookup_path: 00840004 -> UPS
>0.558950 [D5] hid_lookup_path: 00840012 -> Battery
>0.558958 [D5] hid_lookup_path: 00850066 -> RemainingCapacity
>0.558966 [D1] Path: UPS.Battery.RemainingCapacity, Type: Feature, 
> ReportID: 0x18, Offset: 0, Size: 8, Value: 100
>0.558973 [D4] Entering libusb_get_report
>0.563880 [D3] Report[get]: (3 bytes) => 19 dc 00
>0.563899 [D5] PhyMax = 0, PhyMin = 0, LogMax = 12288, LogMin = 3072
>0.563911 [D5] Unit = , UnitExp = 0
>0.563920 [D5] Exponent = 0
>0.563927 [D5] hid_lookup_path: 00840004 -> UPS
>0.563934 [D5] hid_lookup_path: 00840012 -> Battery
>0.563942 [D5] hid_lookup_path: 00840040 -> ConfigVoltage
>0.563951 [D1] Path: UPS.Battery.ConfigVoltage, Type: Feature, 
> ReportID: 0x19, Offset: 0, Size: 16, Value: 3072
>0.563958 [D4] Entering libusb_get_report
>0.568883 [D3] Report[get]: (3 bytes) => 1a 02 15
>0.568902 [D5] PhyMax = 0, PhyMin = 0, LogMax = 9216, LogMin = 2304
>0.568914 [D5] Unit = , UnitExp = 0
>0.568924 [D5] Exponent = 0
>0.568931 [D5] hid_lookup_path: 00840004 -> UPS
>0.568939 [D5] hid_lookup_path: 00840012 -> Battery
>0.568946 [D5] hid_lookup_path: 00840030 -> Voltage
>0.568955 [D1] Path: UPS.Battery.Voltage, Type: Feature, ReportID: 
> 0x1a, Offset: 0, Size: 16, Value: 5378
> 
> But the real level of battery.voltage is 79.7 Perhaps the data interpret 
> somehow?
> 
> Do You mean the "Report Descriptor" when speak about reports from USB?
> 
> On 10.01.23 19:14, Jim Klimov wrote:
>> I suppose that should have read "correct battery.voltage" ;)
>> 
>> Not sure really - this is the standard endpoint for that info, so firmware 
>> is broken for USB HID power device support.
>> 
>> If you start the driver with higher debug verbosity, it prints the reports 
>> from USB. If you can decipher those (online tools exist but I don't have a 
>> link handy), maybe some other field (possibly with an untranslated hex name) 
>> conveys data that looks like what you need.
>> 
>> Jim
>> 
>> On Tue, Jan 10, 2023, 18:09 Alex Rydzewski > > wrote:
>> Thank You for your attention, Jim!
>> I compiled and ran the 2.8.0 version with this part uncomment
>>  *{ "battery.voltage", 0, 0, "UPS.PowerSummary.Voltage", NULL, "%.2f", 
>> 0, NULL },
>>  *{ "battery.voltage", 0, 0, "UPS.Battery.Voltage", NULL, "%.2f", 0, 
>> NULL },
>>  *{ "battery.voltage.nominal", 0, 0, "UPS.PowerSummary.ConfigVoltage", 
>> NULL, "%.0f", HU_FLAG_STATIC, NULL },
>>  *{ "battery.voltage.nominal", 0, 0, "UPS.Battery.ConfigVoltage", NULL, 
>> "%.0f", HU_FLAG_STATIC, NULL },
>> from powercom-hid.c, and it is so, it is duplicates for output.voltage.
>> 
>> Is there anything I can do to find the correct output.voltage?
>> 
>> On 10.01.23 14:12, Jim Klimov wrote:
>>> Hello,
>>> 
>>>   One thing that pops out in your report is that NUT 2.7.2 is used, which 
>>> is pretty old now. If you have a chance to install 2.8.0 or newer (custom 
>>> build of current git master) to confirm if the problem is still there, it 
>>> could be helpful.
>>> 
>>>   Other than that, current source says at 
>>> https://github.com/networkupstools/nut/blob/1deab1638322e9e64a0cf3200dadc93dbe3a3f41/drivers/powercom-hid.c#L362-L368
>>>  
>>> 
>>>  that "battery.voltage" is served in USB reports, but is not useful (same 
>>> as output voltage). Nearby, "battery.runtime" and "battery.mfr.date" do 
>>> come from USB reports, but per 
>>> https://github.com/networkupstools/nut/issues/1644 
>>>  the latter was 
>>> previously wrongly reported as "battery.date" (for replacement). Note that 
>>> generally fixes are based on user reports about devices which misbehaved; 
>>> if a vendor has multiple devices with different behaviors (including bug 
>>> fixes in newer firmwares) it can get messy and need some more elaborate 
>>> fixes :-\
>>> 
>>>   Something in your question does ring a bell - please revise 
>>> https://github.com/networkupstools/nut/issues?q=label%3APowercom 
>>>  and/or 
>>> https://github.com/networkupstools/nut/issues?q=powercom 
>>> 

Re: [Nut-upsdev] Can we just import apcupsd code?

[Charles Lepple via Nut-upsdev]

On Jan 4, 2023, at 5:02 PM, Ted Mittelstaedt via Nut-upsdev 
 wrote:
> 
> But instead of that NUT elected to write a shim that spawns apcuspd.  
> 
Technically, it doesn't launch apcupsd, the driver connects to an existing 
apcupsd instance. And the shim (apcupsd-ups) was contributed by a user.

Let's stick to the facts, rather than attempting to guess at motives.
___
Nut-upsdev mailing list
Nut-upsdev@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsuser] confusion about shutdown

[Charles Lepple via Nut-upsuser]

On Dec 30, 2022, at 7:42 PM, Greg Troxel  wrote:
> 
> maybe me, maybe docs.
> 
> I have never had auto shutdown set up on netbsd.  Mostly I monitor to
> mqtt.  But now I'm trying and have multiple confusions.
> 
> 1) 'upsdrvctl shutdown' vs 'upscmd shutdown.return'
> 
> upsdrvctl is about stopping the driver, but lowbatt shutdown wants to
> send a command.  I don't get the upsmon example file:

"upsdrvctl stop" is for stopping the driver, but "upsdrvctl shutdown" runs 
"$DRIVER -k" to kill power to the load on the UPS (which is actually a second, 
non-long-running instance of the driver that doesn't talk to upsd, after the 
rest of the system is ready to stop).

That being said, upscmd needs to talk to upsd, which needs a running driver - 
IMHO this is only workable if you trust your delay-before-shutdown in the UPS. 
The "upsdrvctl shutdown" case can often be run after everything has been 
remounted read-only, at which point it is okay if there is no delay before the 
power gets pulled.

> 
>  # POWERDOWNFLAG - Flag file for forcing UPS shutdown on the primary system
>  #
>  # upsmon will create a file with this name in primary mode when it's time
>  # to shut down the load.  You should check for this file's existence in
>  # your shutdown scripts and run 'upsdrvctl shutdown' if it exists, to tell
>  # the UPS(es) to power off.
> 
Hopefully explained by the above. Also, you don't have to check for the file 
directly - you can use "upsmon -K" as in the following excerpt from the 
rc.d/nut script in FreeBSD's NUT port:

nut_poststop() {
if ${nut_prefix}/sbin/upsdrvctl stop && checkyesno nut_upsshut; then
if ${nut_prefix}/sbin/upsmon -K; then
${nut_prefix}/sbin/upsdrvctl shutdown
fi
fi

}

> 
> 2) LB config.   On a Best Fortress, I can set lowbatt runtime, but only
> 3 digits, even though I want 1800s.   Is this likely a Fortress
> limitation, or a bug?  I will read the source...

Looks like it might be a NUT bug. There should be room for four digits in the 
protocol, but the protocol appears to be minutes. NUT shouldn't limit the 
seconds field to three characters.

> 2A) seems like nut should be able to have time-based config to start
> shutdown, all of batt%, seconds remaining, and seconds on battery, built
> in.

Others have covered solutions in greater depth (I think Roger's config guide 
handles most of these), but IMHO things like "seconds on battery" aren't as 
easy as they look (unless you don't care about the intersection with seconds 
remaining).

> 3) seems like shutdown should remove /etc/killpower but maybe upsmon
> removes it at boot.  should be explained more, probably, guessing it is
> at boot since fs is ro

probably should be removed at boot (or better yet, placed on a RAM-based 
filesystem), but this is not my area of expertise.
> 
> 4) not clear where I should edit in the instant command, as it doesn't
> belong when shutting down upsd, but yet it has to be before.  This is
> complicated.

probably covered by the nut_poststop() example above, but shout if you still 
have questions about that.

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

Re: [Nut-upsuser] Shutdown variables

[Charles Lepple via Nut-upsuser]

On Nov 27, 2022, at 8:21 PM, Simon Wilson via Nut-upsuser wrote:
> 
> "[replbatt] The UPS needs to have its battery replaced. Not all UPS's can 
> indicate this."
> 
> Can anyone advise whether the Eaton USB UPSs support that? Specifically mine 
> is a 5SX 1750.

I don't know for the 5SX line in particular, but if you have a maintenance 
window where you can stop NUT, then start the usbhid-ups driver manually with a 
few -D flags (was 2+ for older versions of NUT), there is a HID descriptor 
element you can look for:

UPS.PowerSummary.PresentStatus.NeedReplacement

and that gets mapped to the RB flag in ups.status, and "Replace battery!" in 
ups.alarm.

If the 5SX is a superset of the 5S, then it should have this. A 5S 1000 log is 
here: https://alioth-lists.debian.net/pipermail/nut-upsuser/2016-May/010122.html

Reference:

https://github.com/networkupstools/nut/blob/v2.8.0/drivers/mge-hid.c#L1264 
(assuming your UPS has a vendorid of 0x0463) maps the variable to 
replacebatt_info -> mapped to "replacebatt" string in drivers/usbhid-ups.c, 
then to RB: 
https://github.com/networkupstools/nut/blob/v2.8.0/drivers/usbhid-ups.c#L1681-L1683

-- 
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] Building a Custom UPS with NUT Compatibility

[Charles Lepple via Nut-upsuser]

Hi Josh,

I'm not finding this Microchip firmware example online at the moment, but there 
was once a PIC sample project that implemented USB HID PDC, which is the 
protocol the NUT usbhid-ups driver speaks. I think the OpenUPS product 
(somewhat misleadingly named IMHO; the firmware is not open source, as far as I 
know) has similar HID descriptors to that example project, and it is one of the 
models with custom variables.

https://networkupstools.org/docs/man/usbhid-ups.html

https://github.com/networkupstools/nut/blob/v2.8.0/drivers/openups-hid.c

As long as you have a good USB HID vendor example project to work from, you 
should be good to go. HID PDC is fairly straightforward, just with a lot of 
different names and variables. For basic system shutdown, there are just a few 
bits in UPS.PowerSummary.PresentStatus that need to be implemented.

Related: I haven't followed ESR's "upside" project in a while, so not sure if 
it will provide a good starting point. If nothing else, there might be some 
good UPS engineering information in the wiki: https://gitlab.com/esr/upside

-- 
Charles Lepple
clepple@gmail

> On Sep 16, 2022, at 3:34 PM, Joshua Quesenberry via Nut-upsuser 
>  wrote:
> 
> Good Afternoon,
>  
> I’m part of team that’s been tasked with building an embedded system that 
> does, among other things, battery management, including behaving like a UPS. 
> We’d like to take full advantage of integrating with NUT and hopefully also 
> it offers some support for running custom queries of the device? Can some 
> point me in a good direction for writing firmware that works seamlessly with 
> NUT? Are there any existing firmware frameworks that are open source that I 
> can look at? We haven’t selected a microcontroller/microprocessor yet, but 
> we’re familiar with Microchip and NXP, so if one of those would provide a 
> shorter path to results or you have a 3rd recommendation to consider, please 
> let me know.
>  
> Thanks!
>  
> Josh Q
>  
> 

P.S. please subscribe to the list using the URL below. Gmail allows you to 
easily create filters for list traffic, and once you are subscribed, you can 
turn off delivery (or change to daily digest mode), but in any event, emails 
from subscribers won't need to be manually approved.

> ___
> 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] dual cyberpower 2200 on windows

[Charles Lepple via Nut-upsuser]

On Aug 11, 2022, at 10:46 PM, Richard Ward  wrote:
> 
> Thanks Charles,
> 
> The devices are the same make and model, bought at the same time. both return 
> the following when running upsc, and I cant see any way to distiguish the 2 
> apart. Any suggestions, other than to connect them to different servers? :
> 
Maybe you can use the "bus=" parameter? I don't know; 2.6.5 is pretty old, and 
I haven't done much with the Windows branch on actual hardware.

> battery.charge: 100
> battery.charge.low: 10
> battery.charge.warning: 20
> battery.mfr.date: CPS
> battery.runtime: 1031
> battery.runtime.low: 300
> battery.type: PbAcid
> battery.voltage: 17.3

Also, beware of the CyberPower HID bugs, e.g. 
https://github.com/networkupstools/nut/issues/439 (I vaguely remember a similar 
bug for battery.voltage)

> 
> ___
> 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] dual cyberpower 2200 on windows

[Charles Lepple via Nut-upsuser]

On Aug 11, 2022, at 10:06 AM, Richard Ward wrote:
> 
>  I need to specify the usb port in the ups.conf file, but I cannot work out 
> how to find the path for each ups to fill in the port = section. If I leave 
> it as port = auto, then only 1 unit can be monitored at a time.
> 
as the documentation describes, just leave port=auto and use the other 
USB-specific options to distinguish USB UPSes from one another: 
https://networkupstools.org/docs/man/usbhid-ups.html#_implementation (port is a 
relic from the days of serial UPSes)

If the UPSes are truly identical (no unique serial number), then that's 
something you should take up with your UPS vendor.
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Where is nut-scanner on raspberry pi?

[Charles Lepple via Nut-upsuser]

> On Aug 11, 2022, at 8:03 AM, z.kevino--- via Nut-upsuser wrote:
> 
> So even with Buster I get the same results - no nut-scanner. I was under the 
> impression that it was needed to get the serial # of an APC device. I have 
> two of the same type of devices (APC UPS) and the vendor code and product 
> code are the same for them, so I didn’t know how to distinguish one from the 
> other in the config files.
> 
The serial number is shown in dmesg:

[7.337934] usb 6-2: New USB device found, idVendor=051d, idProduct=0003
[7.337935] usb 6-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[7.337936] usb 6-2: Product: Smart-UPS C 1000 FW:UPS 10.0 / ID=1005
[7.337937] usb 6-2: Manufacturer: American Power Conversion 
[7.337938] usb 6-2: SerialNumber: 3S1746X05384  

or you can retrieve it with lsusb:

$ sudo lsusb -d 51d: -v | grep -2 iSerial
  iManufacturer   1 American Power Conversion 
  iProduct2 Smart-UPS C 1000 FW:UPS 10.0 / ID=1005
  iSerial 3 3S1746X05384  
  bNumConfigurations  1
  Configuration Descriptor:

(examples from Ubuntu; formatting may vary slightly. the "lsusb -d 51d:" flag 
filters for APC's vendor ID.)

# ups.conf
[apc]
driver = usbhid-ups
port = auto
serial = "3S1746X05384"
    desc = "Basement"

-- 
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] NUT can't connect to USB UPS on OpenBSD

[Charles Lepple via Nut-upsuser]

On Aug 10, 2022, at 9:15 PM, Marc-André Harbec via Nut-upsuser wrote:
> # These are all the USB devices on my machine
> ❯ doas ls -l /dev/usb*
> crw-r-  1 root  usb   61,   0 Jun 24 16:21 /dev/usb0
> crw-r-  1 root  usb   61,   1 Jun 24 16:21 /dev/usb1
> crw-r-  1 root  usb   61,   2 Jun 24 16:21 /dev/usb2
> 
I haven't done much initial configuration of USB devices on *BSD in a while, 
but I think you'll need a different device node for libusb.

http://dant.net.ru/calomel/nut_ups.html implies that it is /dev/ugen*

Does OpenBSD have an equivalent for FreeBSD's devd, to set permissions on a 
specific USB device node based on the USB IDs? We have some devd information 
here: https://github.com/networkupstools/nut/tree/master/scripts/devd

https://github.com/networkupstools/nut/blob/master/tools/nut-usbinfo.pl#L181-L196
 also implies that on FreeBSD, `chmod g+rw` is needed on the appropriate device 
node.

If that fails, I'd recommend using ktrace to find out what is failing, such 
that you get the "no USB buses found" error.

> ___
> 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] Where is nut-scanner on raspberry pi?

[Charles Lepple via Nut-upsuser]

On Aug 10, 2022, at 9:05 PM, z.kevino--- via Nut-upsuser 
 wrote:
> 
> VERSION="9 (stretch)"
> VERSION_CODENAME=stretch
> 
stretch is getting pretty old now - 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921379 appears to have been 
fixed in 2019. The output of nut-scanner should mostly be portable (besides any 
bus-specific numbering), so if you really need nut-scanner, it should be 
possible to find another distro (e.g. Linux live CD/USB; probably most recent 
version of Ubuntu would suffice) and run it on a PC.

On the other hand, while I guess nut-scanner is useful for some, I have seen 
nothing but headaches from the developer perspective (it is very sensitive to 
the exact library paths, which vary based on distro and architecture). Unless 
you are dealing with more than one or two UPS units, it will probably be 
quicker to describe the UPS and its connection method (USB/serial/network) to 
this list, and have someone generate a configuration file by hand.

For the common USB case, the ups.conf syntax is straightforward and 
well-documented: 
https://networkupstools.org/docs/man/usbhid-ups.html#_implementation
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsdev] Compatibility question

[Charles Lepple via Nut-upsdev]

On Jul 17, 2022, at 4:09 PM, Al M via Nut-upsdev 
 wrote:
> 
> Should this APC UPS be compatible with NUT? Could not find it on the 
> compatible list.
> 
> This description from Amazon:
> APC UPS Battery Backup and Surge Protector, 600VA Backup Battery Power 
> Supply, BE600M1 Back-UPS

It would probably work well enough to get some debug output from the usbhid-ups 
driver, if it doesn't work out of the box.

I'm basing this off of the user manual linked from what seems to be the 
appropriate product page:

https://www.apc.com/shop/tt/en/products/APC-Back-UPS-600VA-120V-1-USB-charging-port-7-NEMA-outlets-2-surge-/P-BE600M1

"Note: PowerChute is only compatible with a Windows operating system. If you 
are using Mac OSX, use the native shutdown feature to protect your system. See 
the documentation provided with your computer."

What the OS X comment implies is that the UPS is compatible with USB HID PDC 
(Power Device Class), which both macOS and NUT usbhid-ups implement. However, 
this doesn't guarantee full NUT compatibility, and it doesn't indicate which 
readings you would be able to get with NUT (versus PowerChute, which apparently 
uses another protocol on top of USB HID).

TL;DR make sure the UPS comes with a good return policy.

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


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

Re: [Nut-upsuser] Info on Cyber Power CP1500AVRLCDa

[Charles Lepple via Nut-upsuser]

On Jun 5, 2022, at 5:54 AM, Greg Troxel wrote:
> 
> So having documentation per model that enables buying something that
> works seems key, and I don't find that.
[...]
> Sorry, I did find the compat list
> 
> https://networkupstools.org/stable-hcl.html
> 
> but I'm not really clear where the sort of extended discussion you are
> providing belongs.  (I am sure it's useful.)

Individual fields can be flagged with messages and links in the DDL:

   https://networkupstools.org/ddl/Cyber_Power_Systems/CP1000PFCLCD.html

   https://networkupstools.org/ddl/Cyber_Power_Systems/CP1500AVRLCDa.html

and if I understand Phil's post correctly, he is referring to this firmware 
issue regarding ups.delay.start:

   https://github.com/networkupstools/nut/issues/625

Updates to the DDL can be requested here:

   https://github.com/networkupstools/nut-ddl/issues

-- 
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] Debian Bullseye Package

[Charles Lepple via Nut-upsuser]

> On May 31, 2022, at 10:57 AM, Brandon Wright via Nut-upsuser 
>  wrote:
> 
> Hello,
> 
> I have my 2.7.4 server running, but wanting to update to the 2.8 version to 
> make use of the many updates and hard work that has been done. Curious if 
> there has been any updates or a timeframe for the Debian package to be 
> distributed? I initially installed via the package, and if I try to manually 
> update, it installs the files into a different directory which causes many 
> issues and conflicts.

We have instructions for building and installing on top of a Debian package 
here: 
https://github.com/networkupstools/nut/wiki/Building-NUT-on-Debian,-Raspbian-and-Ubuntu
 


I don't see any bugs here that might indicate the status of the packaging 
process for 2.8.0: https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=nut 


> If a package will be available soon I can just hold off until then. 
> Otherwise, some suggestions or guidance on updating the packaged NUT with the 
> source code pulled from Github would be very appreciated.
> 
> Again thank you to this team for such an amazing job with this!
> 
> -- 
> Brandon Wright
> ___
> 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-upsdev] a few build nits

[Charles Lepple via Nut-upsdev]

On Mar 31, 2022, at 9:18 AM, Greg Troxel wrote:
> 
> I see your point about distcheck.  I tend to build tarballs from source
> to then use in pkgsrc (not that I publish those tarballs and packages),
> to be able to debug the combination of upstream and pkgsrc to be ready
> for a release.   I can certainly just flip my script to the light version.
> 
mostly for the archives (sounds like Greg has a solution), this page talks 
about the difference between "make distcheck" and "make distcheck-light" in NUT:

https://networkupstools.org/docs/developer-guide.chunked/ar01s03.html#building

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

Re: [Nut-upsuser] finding a common abstraction for reporting

[Charles Lepple via Nut-upsuser]

On Mar 17, 2022, at 7:26 PM, Greg Troxel  wrote:
> 
> My script is in the process of being extended to also deal with apcupsd
> and that seems to have different variables, like timeleft in minutes
> instead of runtime in seconds.  It seems obvious to me that I should
> bring things into a common schema, because the monitoring system doesn't
> care about UPS brand; it wants to know is utility power good enough, how
> many seconds left, etc.

I am not necessarily recommending that you should use apcupsd-ups (it's 
monitor-only and won't send the shutdown command[*], for one thing); however, 
it's worth pointing out that a few of the conversion factors are documented in 
that driver's source:

https://github.com/networkupstools/nut/blob/v2.7.4/drivers/apcupsd-ups.h#L66

[*] https://networkupstools.org/docs/man/apcupsd-ups.html#_limitations

> I wonder how much NUT does that by itself, or if it's more doing format
> translation of the individual units.  And I would appreciate comments on
> the wisdom/necessity of this approach.

What Jim said about this is technically correct, but I would look at it another 
way:

NUT defines standard units for variables (as long as the variables are not 
marked as "opaque"), and the drivers map device-specific readings to those 
standard units. (USB HID PDC tends to use seconds, as do most SNMP MIBs, if I 
am not mistaken.)

Units are in parentheses in the Description column: 
https://networkupstools.org/docs/user-manual.chunked/apcs02.html

-- 
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-upsdev] On retiring some terminology

[Charles Lepple via Nut-upsdev]

On Mar 12, 2022, at 11:51 AM, Ted Mittelstaedt via Nut-upsdev 
 wrote:
> 
> 11 post over the last year on this topic.  Lots of effort expended on a WOKE 
> problem far more than effort expended on real issues that actually affect 
> code functionality.  My condolences.
> 
Ted, this project doesn't need yet another a Monday morning quarterback. Not 
sure how you're counting those 11 posts (remember, this request originally came 
in through GitHub, and the initial poster made a very level-headed request for 
synonyms in the configuration), but no matter, Jim has admirably worked this 
change in among hundreds of other more substantial commits.

Constructive criticism is welcome, including offering ideas on where to expend 
developer energy in the future for better impact. Uninformed comparisons to 
other projects after work has been undertaken are not useful. You have provided 
contrarian advice before on these lists, and I wouldn't be surprised if you 
saved some people the trouble of doing things the hard way. But that's very 
different than offering an eyeroll literally a year after the discussion 
started.

- Charles


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

Re: [Nut-upsuser] Incorrect output.voltage readings : CyberPower AVRG900LCD UPS

[Charles Lepple via Nut-upsuser]

The patch has been merged into the main Git branch, as mentioned here: 
https://github.com/networkupstools/nut/issues/439 
<https://github.com/networkupstools/nut/issues/439> (also suggests why the 
CP1500... doesn't exhibit the problem)

but a new release is still in the works: 
https://github.com/networkupstools/nut/issues/1263 
<https://github.com/networkupstools/nut/issues/1263>

For reference, CPS UPSes have their own issue tag/label in GitHub, which can 
help when looking for problems and patches: 
https://github.com/networkupstools/nut/issues?q=is%3Aissue+is%3Aopen+label%3A%22CyberPower+%28CPS%29%22
 
<https://github.com/networkupstools/nut/issues?q=is:issue+is:open+label:%22CyberPower+(CPS)%22>

-- 
Charles Lepple
clepple@gmail

> On Mar 8, 2022, at 7:04 PM, James N. Grace via Nut-upsuser 
>  wrote:
> 
> nut 2.7.4
> Ubuntu Linux 21.10
> CyberPower CP1500AVRLCD
> CyberPower AVRG900LCD
> 
> The CyberPower CP1500AVRLCD UPS indicates the expected output.voltage value 
> of 120.0 VAC.
> The CyberPower AVRG900LCD UPS indicates unexpected output voltage values of 
> 130.0 to 139.0 VAC.
> Note that input.voltage values fluctuate between 119.0 to 121.0 VAC on both 
> models (as expected).
> 
> Searching the mailing-list archives, it looks like various other CyberPower 
> UPS models are reporting similar (incorrect) output.voltage values (e.g. 
> https://alioth-lists.debian.net/pipermail/nut-upsuser/2015-December/010020.html
>  
> <https://alioth-lists.debian.net/pipermail/nut-upsuser/2015-December/010020.html>)
>  but I just want to verify that there isn't a patch and/or configuration 
> adjustment required for the AVRG900LCD model.
> 
> Thanks in advance for your time + effort...
> ___
> 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] NUT Client Not Working, Server OK

[Charles Lepple via Nut-upsuser]

[please keep the list CC'd - probably easiest via Reply-All]

On Jan 28, 2022, at 10:20 AM, William Cole wrote:
> However, when executing sudo service nut-client on the Client PC, still 
> getting a Connection refused message:
> 
> upsmon[491] UPS [APCES750Client@192.168.1.101]:connect failed: Connection 
> failure: Connection refused
> (repeated 9 times)

"Connection refused" is a standard network error message that says that either 
a firewall is blocking the port, or no daemon is currently listening on that 
port. Since both ends of this connection are on the same host, a firewall is 
not particularly likely to be blocking this, but you could always change it to 
use 127.0.0.1 (localhost) if there is a firewall that can't easily be changed.

In the case of the client Pi, you mentioned that ups.conf was originally empty. 
You may need to restart upsd (sudo "service nut-server restart", I think) now 
that it has an entry for the locally connected UPS. upsd listens on the port 
that NUT clients like upsmon and upsc connect to.

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

Re: [Nut-upsuser] NUT Client Not Working, Server OK

[Charles Lepple via Nut-upsuser]

On Jan 26, 2022, at 3:01 PM, William Cole via Nut-upsuser 
 wrote:
> 
> Thank you for your reply and help.
> 
> I admit to still learning how to use NUT.
> 
> My general NUT-use plan is as follows: the NUT server Pi controls a number of 
> network devices; router, VoIP, mesh pod, fiber connection, etc., but no 
> computers other than the Pi server.  It would shut down last.  The client Pi 
> controls two PCs and would shut down first after shutting down its attached 
> devices.  If this is not workable, please let me know.

That is pretty much the textbook NUT master/slave arrangement.

Additional information is in section 5 of Roger's configuration guide: 
http://rogerprice.org/NUT/ConfigExamples.A5.pdf

> I have made the change to the client's ups.conf adding the entry for APCES750 
> [and keeping it on the server's ups.conf].

You can keep it in the server's ups.conf, but you may want to make a note that 
it is really for the other system (in case you get log messages from one of the 
startup scripts that starts drivers). The ups.conf file only needs to list 
directly-attached (USB, serial, etc) UPSes, not the remote ones.

>   However, I am now getting this message set when I run sudo service 
> nut-client status on the client:
> 
> UPS [APCES750@192.168.101] connect failed: Connection failure: Network is 
> unreachable
> Master privileges unavailable on UPS [APCES850@192.168.1.100]
> Response: [ERR ACCESS-DENIED]

Two separate issues: the first does look like an authentication issue.

> UPS [ [APCES750@192.168.101] connect failed: Connection failure:Connection 
> refused
> 
> UPS [ [APCES750@192.168.101] connect failed: Connection failure:Connection 
> refused 
> UPS [ [APCES750@192.168.101] connect failed: Connection failure:Connection 
> refused 
> UPS [ [APCES750@192.168.101] connect failed: Connection failure:Connection 
> refused 
> 
> UPS [ [APCES750@192.168.101] connect failed: Connection failure:Connection 
> refused 

For this, make sure that upsd.conf has a "LISTEN" directive that isn't just 
listening to 127.0.0.1

I'd recommend "LISTEN 0.0.0.0" (and use firewall rules if you want to limit 
access to one network, or even just the client Pi)

> ___
> 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] NUT Client Not Working, Server OK

[Charles Lepple via Nut-upsuser]

On Jan 25, 2022, at 2:51 PM, William Cole via Nut-upsuser 
 wrote:
> 
> I hope that this is an appropriate post for this group.  Please let me know 
> if it should go elsewhere.

Yes, this is a good place to ask general questions. However, you may want to 
subscribe to the list, at least temporarily, so that we do not need to manually 
approve your messages:

https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

As such, you may have missed Roger's reply which looks like it went only to the 
list: 
https://alioth-lists.debian.net/pipermail/nut-upsuser/2022-January/012666.html

> I am running NUT on RaspberryPi 3B+ [RPi] units using Buster.  The NUT 
> version is 2.7.4.

Thanks for the info.
> 
> I have two UPS's in two different physical locations.  Each is attached to 
> its own RPi.
> Both UPS's are APCs but of different models.
> 
> I have one APC attached to an RPi w/NUT configured as a server with the 
> following script entries:
> -
> nut.conf
> MODE=netserver
> 
> ups.conf
> [APCES850Server]
>  driver=usbhid-ups
>  port=auto
>  desc=”APC ES850”
>  serial=4B2037P49872
>  pollinterval=15
>  vendorid=051d
> [APCES750Client]
>  driver=usbhid-ups
>  port=auto
>  desc=”APC ES750”
>  serial=3B0907X16989
>  pollinterval=15
>  vendorid=051d

It looks like you have the syntax correct for ups.conf, but the USB details 
like the serial number and vendorid should go in the ups.conf on the Pi that is 
directly connected to that UPS.

You can think of the client/server setup as follows: the server is providing 
the UPS status over the network to the clients, much as a simple file server 
has a local disk, and the files on that disk are available to other clients of 
that server.

> 
> upsmon.conf
> MONITOR APCES850Server@192.168.1.100 1 upsmon LASTPASS master
> MONITOR APCES750Client@192.168.1.101 1 upsremote LASTPASS slave
> 
> Usual entries for upsd.conf and upsd.users.
> ---
> The other APC is attached to a different RPi w/NUT configured as a client 
> with the following script entries:
> ---
> nut.conf
> MODE=netclient
> 
> ups.conf
> [no entries]
> 
> upsmon.conf
> MONITOR APCES850Server@192.168.1.100 1 upsmon LASTPASS master
> MONITOR APCES750Client@192.168.1.101 1 upsremote LASTPASS slave
> --
> The server works fine.  The client will not connect, throwing a "UPS 
> APCES750Client@192.168.1.101 is unavailable"error.

If you look at the service status on 192.168.1.100, you will probably see that 
upsd was not able to connect to the ES750 over USB on that Pi. Since there is 
no entry for the ES750 in ups.conf on 192.168.1.101, that is why you get the 
"UPS ... is unavailable" error.

$ systemctl status nut-server
● nut-server.service - Network UPS Tools - power devices information server
   Loaded: loaded (/lib/systemd/system/nut-server.service; enabled; vendor 
preset: enabled)
   Active: active (running) since Fri 2022-01-14 21:07:31 EST; 1 weeks 4 days 
ago
 Main PID: 2187 (upsd)
...
Jan 14 21:07:31  upsd[2023]: Connected to UPS [apc]: usbhid-ups-apc

The part that Roger and I aren't sure of is how you intend the rest of the 
monitoring to work.

Should the second Pi shut down when the UPS on the first Pi is exhausted? Or do 
you just want to log the status remotely?

As far as terminology, we covered the server/client side of things. There is 
also a similar concept of master/slave (exact terms to be changed later) which 
is more about which upsmon server (the master) waits for other clients (the 
slaves) to shut down before it does. It's more like a captain on a ship waiting 
for everyone else to get on the life rafts safely (or the captain goes down 
with the ship). If you do not want to create extra dependencies between the two 
Pis, each can have a "master" entry in its upsmon.conf that points to the 
directly-connected UPS.

-- 
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] Can NUT handle a laptop battery?

[Charles Lepple via Nut-upsuser]

On Jan 8, 2022, at 12:38 PM, Goran Vukoman  wrote:
> 
> The Pine64 ARM boards have a battery connector, not quite a laptop, but AFAIK 
> the board will charge and use the battery as fallback if lights go out.

It looks like the Pinebook Pro has a /sys/class/power_supply driver:

https://github.com/Syonyk/pinebookpro/blob/master/pbp-status.sh#L10 


so theoretically, you could poll that interface and export some data for 
dummy-ups, as suggested in this thread:

https://alioth-lists.debian.net/pipermail/nut-upsuser/2016-September/010300.html
 


Admittedly, a compiled NUT driver for Linux power_supply devices would be 
better:

https://github.com/networkupstools/nut/issues/319 



> ___
> 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] issue SHUTDOWNCMD from a slave

[Charles Lepple via Nut-upsuser]

On Nov 29, 2021, at 11:58 AM, Ken Brubacher wrote:
> 
> Is it possible to issue a SHUTDOWNCMD command from a slave or only from a 
> master?
>  
> The scenario is a Dell R740 hypervisor, and I’d like NUT server to run as a 
> virtual machine on it, and shut down the host from the virtual machine NUT 
> server. So the NUT server VM would issue a shut down command to the slave 
> installed on the Dell hypervisor DOM0. I want SHUTDOWNCMD on the Dell slave 
> hypervisor to issue the shutdown command to the UPS, as the NUT server master 
> will have been shut down by the host slave by then.  The other option would 
> be to install NUT server in DOM0 on the hypervisor which I’m not excited 
> about.

Slight clarification, SHUTDOWNCMD can shut down either a master or a slave 
system, but in all of the cases I can think of, only the master system has the 
connection to the UPS (that is, the connection to tell the UPS to cut power to 
the outlets), and you're right that it is typically triggered by the 
SHUTDOWNCMD.

Think of the NUT master system (the one running the driver) as being a 
multiplexor for single-user UPS hardware. This makes more sense when the UPS 
has a single USB or serial port for control, but it also helps if you have a 
network card (running SNMP, for instance). In the case of a network connection, 
you might be able to have a non-master system shut down the UPS after the 
master system is down, but if you are doing this from NUT, you would need to be 
sure that the non-master driver configuration is only used at shutdown time 
($DRIVER -k). Most of the NUT example configurations are written assuming the 
master stays up longer than the slaves, in order to keep that hardware 
connection to the UPS to request the power to be removed.

I have heard of people doing something similar with ESXi, and having NUT 
master/slave running on one of the guests. The key is probably having the 
master guest VM request a delayed shutdown of both the hypervisor and the UPS. 
You will want to make sure your UPS supports the delay values needed to make 
this work (for instance, CyberPower UPSes round down to the nearest minute: 
https://github.com/networkupstools/nut/issues/432 ), and that the UPS doesn't 
have a race condition if the power comes back in the middle of a delayed 
shutdown (see NUT FAQ).
 
> I’m very aware this is a non standard setup. Is there other better ways to 
> accomplish this without running something like a Raspberry PI as the NUT 
> server master?
>  
>  
> ___
> 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] UPS Monitor Won't Start: invalid directive monitor

[Charles Lepple via Nut-upsuser]

On Nov 21, 2021, at 9:28 PM, Jarrod Coombes via Nut-upsuser 
 wrote:
> 
> When I try to start the UPS monitor service I get:
> 
> Starting Network UPS Tools - power device monitor and shutdown controller...
> fopen /run/nut/upsmon.pid: No such file or directory
> /etc/nut/upsmon.conf line 86: invalid directive monitor APC-t@localhost 1 
> admin <8 random letters> master
> /etc/nut/upsmon.conf line 87: invalid directive monitor APC-b@localhost 1 
> admin <8 random letters> master

 ^^^ most of NUT is 
case-sensitive, so this should be "MONITOR".

> The two UPSes are identical, so I created some custom udev rules to create 
> /dev/apc-t and /dev/apc-b and this appears to work. I can run ls /dev/a* and 
> get:
> 
> /dev/apc-b  /dev/apc-t  /dev/autofs

If these dev nodes work, it is just coincidence - the usbhid-ups driver cannot 
open a specific UPS by a /dev node, and the port option is ignored:

https://networkupstools.org/docs/man/usbhid-ups.html#_implementation

In your case, it sounds like you can specify "serial =" for each UPS in 
ups.conf.

> ___
> 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-upsdev] Cross-compiling for OpenWRT on Debian - neon libraries error

[Charles Lepple via Nut-upsdev]

On Sep 16, 2021, at 6:30 AM, Seb Belcher via Nut-upsdev 
 wrote:
> 
> Bit of a noob question I'm sure but would appreciate the help.  The nut 
> package maintained for OpenWRT does not include the netxml drivers that I 
> need for my UPS, so I'm embarking on something a little outside my comfort 
> zone and trying to cross-compile from source.  The build system is Debian. 
> 
> I've got quite far, and was able to cross-compile nut with default options 
> but adding the --with-neon is breaking it.  I've installed the neon dev 
> libraries on the build system and they seem to be detected during the 
> configure stage
> ...
> checking for libneon version via pkg-config (0.25.0 minimum required)... 
> 0.30.2 found
> checking for libneon cflags... -I/usr/include/neon
> checking for libneon ldflags... -lneon
> ...
> but then it quits with an error. 
> configure: error: "neon libraries not found, required for neon based XML/HTTP 
> driver"
> 
> I've verified the neon header files are in /usr/include/neon beyond that, I'm 
> at a loss.  Any help would be appreciated.  Thanks. 
> 
It's been a little while since I last used a cross-compiler, so maybe I am 
rusty on terminology. It sounds like you are building on a Debian system, but 
targeting OpenWRT - are they both the same architecture? (e.g. Debian on MIPS, 
and a WRT54G MIPS-based router)

If not, I would expect that your path for libneon would be a little longer, 
with the target architecture/OS included in there somewhere. (The include files 
might work across similar architectures, but the libraries are definitely going 
to have to match the target architecture/OS.)

For instance, you might need to install libneon into the Buildroot staging_dir 
if you are following these instructions:

https://openwrt.org/docs/guide-developer/crosscompile

then follow their recommendations on setting LDFLAGS (which should probably 
show up in NUT's ./configure output).
___
Nut-upsdev mailing list
Nut-upsdev@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev

Re: [Nut-upsuser] Empty readings from sensors (MEC0003)

[Charles Lepple via Nut-upsuser]

On Aug 13, 2021, at 7:32 AM, Manuel Wolfshant wrote:
> 
>> [...]   2.135215 read: (000.0 000.0 000.0 000 00.0 0.00 00.0 
> As far as I can see, the UPS is sending exclusively zeroes so there isn't 
> much that the drivers could do.
> 
I agree that the logs seem to be showing that the UPS is sending all zeroes, 
but I do remember some discussion about sending additional setup commands to 
make the UPS start sending actual data. A quick search of the email archives 
(matching MEC0003) turned up some branches that @zykh was working on, but I 
can't tell how those discussions were resolved.

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

Re: [Nut-upsuser] permanently setting "battery.charge.low" on APC Back-UPS RS 550G

[Charles Lepple via Nut-upsuser]

On Jun 29, 2021, at 12:27 PM, Roger Price wrote:
> 
> On Tue, 29 Jun 2021, Ralf Fassel via Nut-upsuser wrote:
> 
>> OS Ubuntu 20.04.2 LTS
>> Network UPS Tools 2.7.4 (Debian Package nut-client 2.7.4-11ubuntu4)
>> 
>> device.mfr: American Power Conversion
>> device.model: Back-UPS RS 550G
>> 
>> driver.name: usbhid-ups
> 
>> Is there a way to permanently set the battery.charge.low in the
>> device?  Or in some config file (which)?
> 
> Have a look at man ups.conf which has the example
> 
>   override.battery.charge.low = 30

Again, override.* is only part of the story for changing the threshold that NUT 
and/or the UPS uses for LB detection:

https://alioth-lists.debian.net/pipermail/nut-upsuser/2021-February/012294.html

TL;DR: override does not change anything on the UPS - it only changes what upsd 
reports. You would need to use something like "ignorelb" in addition.

> I don't know if this works for a Back-UPS RS 550G

ignorelb should work for any UPS, though you can only effectively set it higher 
than the UPS default.
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Random output of a LIST ENUM command ?

[Charles Lepple via Nut-upsuser]

On Jun 19, 2021, at 10:25 AM, Roger Price wrote:
> 
> The ENUM entries are not in ascending order.  Does this mean that the output 
> is in random order?, or is there some other logic?

Similar to the LIST RANGE email, I don't have a good citation for this, but my 
understanding is that this was intended to mirror the order that an UPS uses 
for its settings (i.e. 0 in the UPS-specific protocol is 103, 1 is 100, etc). 
In this case, the items are ordered from most sensitive to low-voltage 
transients, to least sensitive.

The current implementation adds ENUM items to the end of a list, and that list 
is traversed in the same order each time.

drivers/apcsmart-old.c seems to indicate that the APC protocol has a command to 
advance the setting to the next in order (similar to what a front panel button 
would do), but the driver probably doesn't care about the order of the items in 
the state/dstate data structures.

> ___
> 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] Discontinuous output of a LIST RANGE command ?

[Charles Lepple via Nut-upsuser]

On Jun 19, 2021, at 10:55 AM, Roger Price wrote:
> 
> During the ISE review of the proposed RFC, the IETF editor has asked for 
> clarification of the output of command LIST RANGE  .
> 
> The Developer Guide Chapter 9 
> https://networkupstools.org/docs/developer-guide.chunked/ar01s09.html 
> "Network Protocol Information" provides the following example of the output 
> of a LIST RANGE command:
> 
> BEGIN LIST RANGE su700 input.transfer.low
> RANGE su700 input.transfer.low "90" "100"
> RANGE su700 input.transfer.low "102" "105"
> ...
> END LIST RANGE su700 input.transfer.low
> 
> The RANGE entries are not contiguous. There is a gap between "100" and "102". 
> Is this correct?
> 
Unfortunately, I don't think we have an example of the full set of data for the 
su700 UPS mentioned there. The only use of this in recent history seems to be 
in nutdrv_qx (search for dstate_addrange()).

The way I read the protocol document, though, the gap seems intentional. 
Otherwise, a single range from 90 to 105 could have been used. I suspect this 
was intended for cases where the low voltage is relative to a 110/220V setting 
(e.g. you can't set the low voltage to be something in the middle like 150V). I 
admit this sounds contrived; however, the NUT code seems to support multiple 
discontinuous ranges as shown in that example.

Here is a real-world example of a single range per variable:

https://github.com/networkupstools/nut-ddl/blob/master/INELT/INELT__Monolith_E1000LT-12V__nutdrv-qx__2.7.4__01.dev#L72

This would probably yield:

BEGIN LIST RANGE inelt input.transfer.low
RANGE inelt input.transfer.low "40" "47"
END LIST RANGE inelt input.transfer.low

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



-- 
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] Tripp Lite model number AVR900U didn't change, but USB product ID did

[Charles Lepple via Nut-upsuser]

On May 8, 2021, at 11:46 PM, Paul Nickerson via Nut-upsuser wrote:
> 
> I'm running Raspbian GNU/Linux 10 (buster) on a Raspberry Pi 4.
> I have nut-client and nut-server version 2.7.4-8 armhf installed from the 
> Raspbian Buster main apt repository.
> I have a Tripp Lite AVR900U series AG-0309 connected via USB to the Pi. The 
> USB vendor ID is 09ae as expected, but the product ID is 3024. The 
> compatibility page at https://networkupstools.org/ddl/Tripp_Lite/AVR900U.html 
>  says the product ID 
> is expected to be 2010.

I think we need some better background text on the DDL pages to explain this, 
but the way to look at it is that the 2010 product ID is the last "known good" 
version of the AVR900U model. I don't remember offhand when we started to see 
the under-the-hood change to 30xx product IDs, but this was discussed about a 
year ago:

https://alioth-lists.debian.net/pipermail/nut-upsuser/2020-May/thread.html#11840
 


Towards the end was discussion of the "data stale" error, which is a 
higher-level symptom of the driver (usbhid-ups, in your case) not being able to 
stay connected to the UPS. (I have an UPS with product ID 3016 which does the 
same thing on Linux with newer motherboards. It seems to be a combination of 
hardware issues with a lack of error handling for this particular fault in the 
Linux USB driver.)

> There's no manufacturing date printed on the UPS or box, but I bought it from 
> Amazon.com this week.

I thought we had more info on how to interpret serial numbers, but all I can 
find is this:

https://www.tripplite.com/support/identify-products 


so the first four digits are the "date code", which do seem to be pretty close 
to the one mentioned in the May 2020 thread.

> I have these settings:
> 
> /etc/nut/ups.conf
> [tripplite]
> driver = usbhid-ups
> port = auto
> desc = "Tripp Lite AVR900U"
> vendorid = 09ae
> productid = 3024

^ The last line tells upsdrvctl to add "-x productid = 3024" to the command 
line, so you should be set with this config.

> To get usbhid-ups to try communicating with the UPS anyways, I added this 
> udev rule and then unplugged and plugged back in the USB cord:
> 
> /lib/udev/rules.d/62-nut-usbups.rules
> ATTR{idVendor}=="09ae", ATTR{idProduct}=="3024", MODE="664", GROUP="nut"

This udev rule is necessary until 3024 is added to NUT, yes.

> It looks like forcing usbhid-ups to communicate works, maybe? I'm not sure 
> what's expected here:

At this point, if you restart with "productid = 3024" in ups.conf, things 
should work.

>0.023703   Path: UPS.PowerSummary.Input.Voltage, Type: Feature, ReportID: 
> 0x31, Offset: 0, Size: 16, Value: 0.001254

We have a couple of hacks in the driver to handle cases like this 
(Input.Voltage is being reported with 100,000x too low):

https://github.com/networkupstools/nut/blob/v2.7.4/drivers/tripplite-hid.c#L59 


It looks like one of these was merged for 3024 recently:

https://github.com/networkupstools/nut/issues/962 


You might also want to check other issues labeled Tripp Lite in GitHub: 
https://github.com/networkupstools/nut/labels/Tripp%20Lite 


> 0.043213  Path: UPS.PowerConverter.Input.Frequency, Type: Feature, 
> ReportID: 0x19, Offset: 0, Size: 16, Value: 6020

Similar issue with frequency (x100)

> Should I run this without -x explore? Is there a way to get upsdrvctl to send 
> the option -x productid=3024 to usbhid-ups? Would that be a good idea?

Correct, "-x explore" is only useful when adding support for a new UPS. It 
doesn't send anything to upsd.

It sounds like you will need a newer build of NUT than 2.7.4 to get the fix for 
Issue 962 mentioned above (which still doesn't address the "data stale" issue). 
I don't have a lot of time to work on the NUT codebase these days, though. 
Hopefully some other folks on the list can help out. We also have some tips on 
rebuilding NUT on the GitHub wiki: https://github.com/networkupstools/nut/wiki 


> 
>  ~ Paul Nickerson
> ___
> 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] How to reset "Shutting Down" Status in Tray-App without re-Starting the monitoring (WIN 7) Computer?

[Charles Lepple via Nut-upsuser]

On May 4, 2021, at 12:50 PM, Jürgen Wege via Nut-upsuser 
 wrote:
> 
> It also keeps the old date for "STARTTIME".

You mentioned apcupsd earlier. STARTTIME is not a NUT variable, and I don't 
think NUT ever had a system tray application (though maybe one of the 
third-party Windows ports did), so you might want to ask on one of the 
apcupsd-specific lists:

http://www.apcupsd.org/wordpress/email-lists/
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] ONLINE + LOWBATT shutdown

[Charles Lepple via Nut-upsuser]

On Mar 8, 2021, at 5:38 PM, Lee Damon via Nut-upsuser 
 wrote:
> 
> On 3/8/21 2:05 PM, Manuel Wolfshant wrote:
>> calibrating should not trigger nut
> 
> I agree, it shouldn't.
> 
The behavior is going to depend slightly on which version of NUT you are 
running.

v2.7.4: https://github.com/networkupstools/nut/blob/v2.7.4/clients/upsmon.c#L701

There's a later commit to specifically ignore calibration-induced "OB LB":

https://github.com/networkupstools/nut/commit/13b26974b4b22e629ecb13c2ce501aba8fdd6aad

> The only thing I can think of that may explain what happened was
>  UPS1 - ONBATT (calibrating)
>  UPS2 - ONLINE + LOWBATT (because of a bad battery)
>  UPS3 - ONLINE
> 
> it saw the ONBATT for 1 and the LOWBATT from 2 and triggered.

For the state described above, you should have a "power value" of 2 (OB but not 
LB still contributes 1 to the power value):

* https://github.com/networkupstools/nut/blob/v2.7.4/clients/upsmon.c#L679 
(loop over all UPSes, check each independently as to whether they are critical)
* https://networkupstools.org/docs/man/upsmon.html#_power_values

What is your MINSUPPLIES in upsmon.conf?

> If that's the case, how do I prevent it from happening again?

I think the key is going to be figuring out the exact state that triggered it. 
You can increase log levels to see state changes in the drivers. If these are 
CyberPower UPSes doing OB+LB+CAL, that commit mentioned above is probably the 
simplest fix.

Another option is to do some sort of "debouncing" with upssched, but that 
assumes that your batteries will last longer in an actual power failure than 
the duration of the test. Debouncing is also harder to configure correctly.

In any case, it might be good to use VMs with dummy-ups drivers to test some of 
these potential solutions.

-- 
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] Liebert GXT4

[Charles Lepple via Nut-upsuser]

On Mar 3, 2021, at 7:43 AM, Matthew Rivett via Nut-upsuser 
 wrote:
> 
> Charles,
> 
> Being me I'd love to have all the data but that shouldn't be necessary.  :)

That's fair :-)

> What got me interested is that the frequency is shown on the UPS and I was 
> curious what was going on when the power issues around President's Day.  I 
> wondered if I could capture that output from the UPS.

The short answer is that there isn't anything that looks like low-hanging fruit 
for frequency. If an UPS includes a frequency Usage ID in its HID Report 
Descriptor, NUT can usually pick that up (even if it gets the value wrong), and 
I'm not seeing something that maps to input.frequency.

If you wanted to log values over time, there are a bunch of 
"UPS.PowerSummary.Undefined" lines, and the bytes before them are candidates 
for frequency.

Here's a simple example for a value that seems to be working:

   0.113694 [D3] Report[get]: (2 bytes) => 13 14
   0.113860 [D1] Path: UPS.PowerSummary.RemainingCapacityLimit, Type: 
Feature, ReportID: 0x13, Offset: 0, Size: 8, Value: 20

The first line with the hex bytes is the raw data coming back from the UPS. 
First byte (0x13) is the report ID, which you can see listed on the next line. 
The Path is the list of HID Usage IDs that are accumulated while NUT parses the 
Report Descriptor. They generally map 1:1 with NUT variables, so 
...RemainingCapacityLimit is "battery.charge.low".

The Offset and Size fields tell NUT how to carve up the bits after the 
ReportID. Offset and Size are in bits, so the 8 bits after 0x13 are 0x14, which 
is 20.

Frequency is a little more complicated. You probably want more precision than 
just 59 or 60 Hz, so it is typically multiplied by some scaling factor so that 
integers can represent e.g. 59.9 Hz with a scale factor of 10. Unless it's a 
small scale factor (under 5), the scaled value won't fit into a single byte 
(0-255). HID reports are little-endian, so for a 16-bit value, you would need 
to add two contiguous bytes, and multiply the second byte by 256.

There are a lot of potential factors, but I don't see any likely candidates at 
the moment. You'd probably want to collect a lot of data, and grab a few 
readings from the front panel to correlate.

I'm not sure what to make of the other values.

   0.208056 [D3] Report[buf]: (5 bytes) => 05 36 00 30 00
   0.208187 [D2] Path: UPS.PowerSummary.Voltage, Type: Feature, ReportID: 
0x05, Offset: 0, Size: 16, Value: 0
   0.208311 LineVoltage exponent looks wrong, but not correcting.
   0.208463 [D3] Report[buf]: (5 bytes) => 05 36 00 30 00
   0.208593 [D2] Path: UPS.PowerSummary.ConfigVoltage, Type: Feature, 
ReportID: 0x05, Offset: 16, Size: 16, Value: 0
   0.208718 ConfigVoltage exponent looks wrong, but not correcting.

Those lines talk about LineVoltage and ConfigVoltage, which usually refer to AC 
voltages when taken together, but the values in the descriptor (54 and 48 
decimal, from 0x0036 and 0x0030) seem like they could be DC battery voltage, 
and nominal battery voltage. (The correction refers to backing out an errant 
exponent which forces the values to be very close to zero.)

> I guess whatever the minimum data to have nut work properly.  I wouldn't mind 
> using this to shutdown multiple computers in the event of a power outage.  

This one's a little easier - you just need working OL/OB and LB bits in 
ups.status, plus a working shutdown command. There are potential timing gotchas 
(I don't see shutdown delay values in upsc output, so hopefully there are fixed 
delays that are long enough), but you'll want to make sure you can do the 
simple stuff first, and the best way to be sure about that is to test. There 
are suggestions in the NUT documentation about using dummy loads, etc.



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

Re: [Nut-upsuser] Liebert GXT4

[Charles Lepple via Nut-upsuser]

On Feb 28, 2021, at 7:02 PM, Matthew Rivett via Nut-upsuser 
 wrote:
> 
> I'm new to this project.  What would the next steps be to get the values 
> working correctly?  I will help where I have the necessary skills.  

I can't promise if/when I will have time to look at the results, but to debug 
the 0.0 values, it would be useful to increase the driver debug output level 
from -D2 to -D3. That includes the raw bytes from the UPS.

Also, what other variables are you looking for? (Previous Liebert GXT units 
have not provided as many measurements as other UPSes.)

-- 
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] Overriding battery.runtime.low

[Charles Lepple via Nut-upsuser]

On Feb 24, 2021, at 4:02 AM, Peter Bishop via Nut-upsuser 
 wrote:
> 
> I have an APC BR1500GI and want to run my devices for the longest possible 
> period. Consequently I want to use the battery.runtime.low setting, 
> sufficient to allow my devices to shutdown. The APC has a setting of 5 
> minutes for this purpose but I want to change this to 10 minutes, so have 
> added the “override.battery.runtime.low = 600” setting to the ups.conf file. 
> However, this override doesn’t appear to be causing the NUT setup to initiate 
> a shutdown.
>  
> Does the “override.battery.runtime.low” work for this purpose or does it just 
> change the value being displayed by upsc? If it’s the latter, is there a way 
> to achieve the override for the low battery setting? For testing purposes I 
> changed this value to “2500”, switched off the mains, and monitored the 
> “battery.runtime” value. It dropped below “2500” (and remained there) but the 
> “battery is low” message was never generated.

The override.* settings can cover both cases. If you just provide 
override.battery.runtime.low, you are just replacing what is sent from the 
driver to upsd, and then on to clients like upsc. (In particular, this doesn't 
send any settings adjustments back to the UPS.) Since upsmon is watching 
ups.status for the UPS-provided LB bit (by default), this isn't sufficient to 
modify shutdown behavior.

The subtle difference in examples like this:

   https://alioth-lists.debian.net/pipermail/nut-upsuser/2020-August/011977.html

is the use of "ignorelb" in concert with "override.battery.runtime.low".

I also ran across this thread while looking up info on the BR1500GI:

   
https://alioth-lists.debian.net/pipermail/nut-upsuser/2020-November/012172.html

I don't think we resolved the shutdown issue (or got debug logs to dig deeper).

>  
> Required information:
>  
> OS: Linux  5.4.83+ #1379 Mon Dec 14 13:06:05 GMT 2020 
> armv6l GNU/Linux
> NUT version: 2.7.4-8
> NUT installation: package
> UPS: APC BR1500GI

Thanks, appreciate the info!

>  
> Thanks.
> ___
> 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] warning in hasss.io

[Charles Lepple via Nut-upsuser]

On Feb 20, 2021, at 2:02 PM, Charles Lepple  wrote:
> 
> On Feb 20, 2021, at 8:54 AM, enzo fn via Nut-upsuser 
>  wrote:
[...]
>> on rasberry pi4 
>> this is in my supervisor log:
>> 21-02-20 11:38:31 WARNING (MainThread) [supervisor.addons.validate] Add-on 
>> config 'startup' with 'before' is deprecated. Please report this to the 
>> maintainer of Network UPS Tools
>> 21-02-20 11:38:31 WARNING (MainThread) [supervisor.addons.validate] Add-on 
>> config 'devices' use a deprecated format, the new format uses a list of 
>> paths only. Please report this to the maintainer of Network UPS Tools
> 
> You probably want to file an issue here:
> 
> https://github.com/home-assistant/core/labels/integration%3A%20nut

Sorry for the duplicate text in the original email.

On second thought, the NUT integration code for hass.io seems to be here:

https://github.com/hassio-addons/addon-nut

Not sure where the apcupsd add-on lives.


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

Re: [Nut-upsuser] warning in hasss.io

[Charles Lepple via Nut-upsuser]

On Feb 20, 2021, at 8:54 AM, enzo fn via Nut-upsuser 
 wrote:
> 
> hassio vers.core-2021.2.3
> Nut vers. 0.6.2

That is an unfortunate choice of names, but you are probably referring to this 
hassio add-on that uses Network UPS Tools:

https://www.home-assistant.io/integrations/nut

You probably want to file an issue here:

https://github.com/home-assistant/core/labels/integration%3A%20nut

> 
> on rasberry pi4 
> this is in my supervisor log:
> 21-02-20 11:38:31 WARNING (MainThread) [supervisor.addons.validate] Add-on 
> config 'startup' with 'before' is deprecated. Please report this to the 
> maintainer of Network UPS Tools
> 21-02-20 11:38:31 WARNING (MainThread) [supervisor.addons.validate] Add-on 
> config 'devices' use a deprecated format, the new format uses a list of paths 
> only. Please report this to the maintainer of Network UPS Tools

You probably want to file an issue here:

https://github.com/home-assistant/core/labels/integration%3A%20nut

> 21-02-20 11:38:31 WARNING (MainThread) [supervisor.addons.validate] Add-on 
> config 'devices' use a deprecated format, the new format uses a list of paths 
> only. Please report this to the maintainer of APC UPS Daemon

Likely similar for this warning.

> 21-02-20 11:38:31 WARNING (MainThread) [supervisor.addons.validate] Add-on 
> config 'startup' with 'before' is deprecated. Please report this to the 
> maintainer of Network UPS Tools
> 21-02-20 11:38:31 WARNING (MainThread) [supervisor.addons.validate] Add-on 
> config 'devices' use a deprecated format, the new format uses a list of paths 
> only. Please report this to the maintainer of Network UPS Tools
> 21-02-20 11:38:31 WARNING (MainThread) [supervisor.addons.validate] Add-on 
> config 'devices' use a deprecated format, the new format uses a list of paths 
> only. Please report this to the maintainer of APC UPS Daemon
> ___
> 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] Why do ondelay and offdelay parameters break the NUT driver?

[Charles Lepple via Nut-upsuser]

On Feb 12, 2021, at 1:25 PM, Shilov via Nut-upsuser 
 wrote:
> 
> Ok, what needs to be done to make this parameter fit for this driver? 

Someone would need to add the necessary command to send the ondelay value, if 
it is implemented by the UPS.

Protocols are posted here: 
https://networkupstools.org/ups-protocols.html#_powercom

(Not sure which one corresponds to KIN-* models)
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Why do ondelay and offdelay parameters break the NUT driver?

[Charles Lepple via Nut-upsuser]

On Feb 11, 2021, at 10:45 AM, Shilov via Nut-upsuser 
 wrote:
> 
>   └─557 /lib/nut/powercom -a myserver
> 
...
> фев 11 17:23:48 myserver upsdrvctl[531]: Network UPS Tools - PowerCom 
> protocol UPS driver 0.17 (2.7.4)
> фев 11 17:23:48 myserver upsdrvctl[531]: Fatal error: 'ondelay' is not a 
> valid variable name for this driver.
> фев 11 17:23:48 myserver upsdrvctl[531]: Look in the man page or call this 
> driver with -h for a list of
> фев 11 17:23:48 myserver upsdrvctl[531]: valid variable names and flags.

As the message says, "ondelay" is not a valid option for that particular driver:

https://networkupstools.org/docs/man/powercom.html

There seems to be a strange syntax for the equivalent of "offdelay" - search 
for "shutdownArguments".
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] New User Questions (again) - With Belkin USB

[Charles Lepple via Nut-upsuser]

On Jan 23, 2021, at 1:07 PM, David White via Nut-upsuser 
 wrote:
> 
> I did the chmod myself thinking that there might be some odd 
> access/permission problem and will change it back since that hasn't changed 
> diddly.
> 
> ls -l /dev/bus/usb/001/003 shows:
> crw-rw. 1 root aid_usb 189, 2 Jan 23 00:06 /dev/bus/usb/001/003
> 
Is the NUT system user in the aid_usb group? That is the recommended way to fix 
this, though you could try to alter whatever is setting that group on the /dev 
node, or do something else with permissions.

If your version of NUT has nutdrv_qx, that's about the only other driver I 
would expect to work with that hardware.
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] An RFC for the NUT project

[Charles Lepple via Nut-upsuser]

On Jan 23, 2021, at 8:18 AM, Roger Price  wrote:
> 
> IETF and IANA require that protocols on ports assigned by IANA be documented 
> with RFC's.  We do not currently have an RFC for port nut/3493.  To solve 
> this IANA port administration issue, I propose the text 
> http://rogerprice.org/NUT/draft-rprice-ups-management-protocol-00.html as a 
> candidate.  Such texts are known as "Internet Drafts".  They have a limited 
> lifetime, but if accepted by the IETF become permanent "Informational RFC's".
> 
> Clauses "5. IANA Considerations" and "6. Security Considerations" are key 
> clauses.
> 
> There are places in the text which need clarification.  I would much 
> appreciate assistance in completing those clauses.
> 
> In the long term, if all goes well, it would be good for the NUT Project to 
> have the RFC promoted to "Best Current Practice" (BCP), which is a step 
> towards the Nivana of "Standards Track" and highly desirable.  Getting to BCP 
> requires a full consensus.
> 
> Comments and corrections are welcome in this list.  When we have a consensus, 
> I will submit the draft to the IETF.

Nice work! I would like to take a little more time to read through this, but a 
few early notes:

* I try not to be too picky about moving threads between lists (since our 
archives are fragmented as-is), but for new protocol-related threads, I'd 
recommend listing the discussion address in the RFC as the nut-upsdev list 
instead of nut-upsuser.

* For a new document that will be undergoing review by a diverse audience, I 
would recommend we seriously discuss changing the master/slave terminology 
before submitting to IETF. I have not had a chance to see what other recent 
RFCs use, but some preliminary NUT discussion is here: 
https://github.com/networkupstools/nut/issues/840 (maybe captain/crew, 
leader/follower, etc?)

* CHRG generally implies OL, but not if UPS output is OFF (battery still may be 
recharging). OL does not imply CHRG if battery is floating. DISCHRG is similar, 
in that the UPS output may not be "on battery" if there is an internal dummy 
load for calibration. I would recommend against reading into what some of the 
drivers do - not all of them are correct, especially the ones based on 
observations or generic protocols rather than vendor documentation.

* NETVER is IMHO problematic. Numeric version tests can generally can be 
avoided by distinguishing between various error codes when trying commands. If 
we are proposing a new way to describe the protocol revision (PROTVER?) I would 
instead recommend something based on named features (which would be more 
amenable to branching and merging). Some past discussion on the topic:

https://alioth-lists.debian.net/pipermail/nut-upsdev/2012-March/006000.html

https://alioth-lists.debian.net/pipermail/nut-upsdev/2012-May/006123.html

For an example, see 
https://en.wikipedia.org/wiki/Sieve_(mail_filtering_language)#Extensions and 
the "require" line in the sample script in the next section.
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] New User Questions (again) - With Belkin USB

[Charles Lepple via Nut-upsuser]

On Jan 22, 2021, at 5:38 PM, David White via Nut-upsuser 
 wrote:
> 
> 4. lsusb shows the UPS on Bus 001, Device 003 (cypress USB to Serial)
> Bus 002 Device 002: ID 05e3:0612 Genesys Logic, Inc.
> Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> Bus 001 Device 005: ID 046d:c52b Logitech, Inc. Unifying Receiver
> Bus 001 Device 004: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter
> Bus 001 Device 003: ID 0665:5161 Cypress Semiconductor USB to Serial

David,

is this the same system as mentioned in this thread? 
https://alioth-lists.debian.net/pipermail/nut-upsuser/2020-January/011619.html

While wolfy's suggestions are applicable for a serial UPS with an external 
USB-to-serial adapter, it sounds like your Belkin UPS has the Cypress chip 
built-in, and the blazer_usb driver expects to talk directly to that chip 
(bypassing any kernel drivers that create /dev/ttyUSB* nodes).

Changing the config file modes from 777 to 640 is likely orthogonal to the 
problem, but something I'd want to fix sooner than later.

What does `ls -l /dev/bus/usb/001/003` show?

You can also try starting the driver manually. There are easier ways to do this 
in newer versions of NUT, but with 2.7.1 and an Ubuntu-like filesystem layout, 
it would be something like this (assuming the UPS name is still belkinusb in 
/etc/nut/ups.conf):

/lib/nut/blazer_usb -a belkinusb -DD

-- 
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] New stable release of NUT after 2.7.4?

[Charles Lepple via Nut-upsuser]

On Jan 10, 2021, at 8:29 AM, Dan Langille via Nut-upsuser 
 wrote:
> 
> On Sun, Jan 10, 2021, at 8:12 AM, Jim Klimov wrote:
>> On January 10, 2021 11:12:48 AM UTC, Victor Hooi via Nut-upsuser 
>>  wrote:
>>> Hi,
>>> 
>>> The last release of NUT seems to be 2.7.4, from 2016.
>>> 
>>> However, from the Github, there does seem to be a lot of activity, and
>>> I
>>> know Jim recently took on maintainership.
>>> 
>>> Just wondering - are there plans to cut a new stable release of NUT
>>> anytime
>>> soon?
>>> 
>>> Thanks,
>>> Victor
>> 
>> Yes there are; my personal priorities were to first reduce or remove 
>> warnings from modern linters (clang-9 started out with about 2000 
>> cases, now down to ~1000) and integrate some or all of the libusb-1.0 
>> support proposed quite a while ago now (with linter making sure this 
>> does not add much mess) and a few other PRs.
> 
> Is there a list of those 1000 warnings? A way for folks to find them?
> 
> This might be an easy way for people to contribute by providing patches.

I would say that stress-testing the libusb-1.0 branch(es) on various UPSes 
would be a more effective way for someone who is unfamiliar with the codebase 
to help. At this point, a lot of the remaining warnings are either 
platform-specific, or the fixes require driver/protocol-specific knowledge in 
order to ensure that the warning fix is not worse than the current state.

https://github.com/networkupstools/nut/issues/300

I personally don't see libusb-1.0 or the warnings as being blockers for a new 
release (we have plenty more fixes in the master branch that seem more likely 
to benefit users), but also I don't have the time to do a proper release myself 
(and the procedure for creating, validating and testing a release for an 
autoconf-based project like NUT is far more complicated than "git tag"), so I 
am deferring to Jim on the release.

The list of other open issues that we had targeted for a 2.7.5 release are 
here: https://github.com/networkupstools/nut/milestone/7

> 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] What does ENUM mean?

[Charles Lepple via Nut-upsuser]

On Jan 10, 2021, at 4:37 AM, Roger Price  wrote:
> 
> I am trying to understand the specification of subcommand ENUM in
> https://networkupstools.org/docs/developer-guide.chunked/ar01s09.html
...
> What exactly does command LIST ENUM call for?  Is it a list of those 
> variables for which there is a fixed set of possible values?

"Is it a list of those variables" -> I would say that for a given variable 
called  (on ), it returns the set of possible values that can 
be read or written. I don't think there is a way to query upsd for just the 
list of ENUM variables, the way it is possible to query for RW variables.

Several UPSes have settings which can be cycled via a front panel button (e.g. 
sensitivity or voltage thresholds), and if those are exposed in the protocols, 
then the drivers should use ENUMs to pass that along. This is not currently the 
case for usbhid-ups: https://github.com/networkupstools/nut/issues/134


-- 
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] How to handle flags as status?

[Charles Lepple via Nut-upsuser]

On Dec 29, 2020, at 9:54 AM, Shakil Shaikh via Nut-upsuser wrote:
> 
> Are clients therefore supposed to list all possibilities, or split on space 
> to get the flags back?
> 
Clients should split on space. I remember we had a better description of this 
from the protocol perspective, but that description does not seem to be in the 
current documentation (which has a description aimed at driver developers).

This is the code that builds ups.status for the drivers:

https://github.com/networkupstools/nut/blob/v2.7.4/drivers/dstate.c#L850

as suggested in the developer guide:

https://networkupstools.org/docs/developer-guide.chunked/ar01s04.html#_manipulating_the_data

As Roger indicated, upsmon is the canonical example for parsing ups.status.

https://github.com/networkupstools/nut/blob/v2.7.4/clients/upsmon.c#L1474
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsdev] Does Cyberpower BR1000ELCD work?

[Charles Lepple via Nut-upsdev]

On Dec 28, 2020, at 10:01 AM, Mike Ricketts wrote:
> 
> Hi
> 
> I am considering buying a Cyberpower BR1000ELCD UPS.
> 
> https://www.cyberpower.com/uk/en/product/series/brics_lcd
> 
> It does not appear on the HCL, but other Cyberpower USB models do.
> 
> The specs claim it has a HID-compliant USB interface (although who knows how 
> "compliant" that is...)
> 
> I've found that https://github.com/networkupstools/nut/issues/552 was opened 
> to add it to the HCL, but it hasn't been added.  Does anyone know if it was 
> not added because it doesn't work, or just that nobody got around to it?

I think that issue is the only information we have on that UPS, so I'd say it 
just fell through the cracks.

Be sure to check out some of the other issues tagged "CyberPower (CPS)" for 
background on which stats and settings are expected to work. In particular, 
some of the transfer voltages might not work as well as in the vendor software, 
and I don't recall whether these models store those settings in EEPROM (or if 
the software is responsible for re-applying them). I keep thinking "we should 
fix these HID-descriptor related bugs" but that's a big job that only fixes 
things for a few UPSes, and we've had broader tasks like keeping up with libusb 
changes (0.1 vs 1.0) and getting a release out the door.

https://github.com/networkupstools/nut/labels/CyberPower%20%28CPS%29

The good news is that the OL/OB status is generally not affected by voltage 
scaling issues.

> If it is thought to work, I'm happy to do whatever testing is needed to get 
> it added to the HCL - just don't want to buy it and then find it is known to 
> not work for some reason.

Nothing too magical about the HCL - since it is best-effort, and vendors can 
change the innards of an UPS while keeping the name, it can really only be a 
rough guide. For a single UPS, your best hedge against unexpected 
incompatibility might be a good return policy. If you are thinking about a 
larger purchase, I would want to contact a vendor sales rep and mention that 
you want to use the UPSes with third-party software like NUT, since they often 
have their own UPS monitoring software, and very few companies do compatibility 
testing with NUT.

That said, if it works, or if it doesn't, we can still collect that 
information. We're trying to keep this all on open mailing lists and GitHub 
issues to make it easy for others to find. Guidance for testing is at the 
bottom of the HCL page: https://networkupstools.org/stable-hcl.html#footnotes

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


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

Re: [Nut-upsuser] APC Back-UPS 1500 RS - looking for help with strange behaviour

[Charles Lepple]

On Oct 31, 2020, at 5:40 PM, David Butler  wrote:
> 
> Hi All,
> 
> hoping someone might have some insights to what is going wrong with my NUT 
> setup and my APC Back - UPS RS 1500 (specifically a BR1500GI) using the 
> usbhid driver.
> 
> https://download.schneider-electric.com/files?p_File_Name=AHUG-9JU4RH_R0_EN.pdf_Doc_Ref=SPD_AHUG-9JU4RH_EN_enDocType=User%20guide
>   
> 
> Main issue:
> 
> NUT successfully shuts down my server when it goes on battery but when I 
> restore power, as soon as my master computer comes up the UPS goes back on 
> battery. It stays like this until it fully discharges whereby everything 
> loses power, everything restarts and again, as soon as the master computer 
> comes online then the UPS goes back on battery... this whole cycle keeps 
> repeating until I switch off the UPS from the front power button.

It seems like this has come up before for this model, but with no resolution:

https://alioth-lists.debian.net/pipermail/nut-upsuser/2018-September/011228.html
> 
> To keep things short I've tried this on pfSense, FreeNAS and Ubuntu, each 
> independently configured as a solo master and for pfSense and FreeNAS the 
> only settings I change is to select the driver as usbhid, port auto and name 
> ups. 
> 
> Curiously I tried the apcupsd package of pfSense and it seemed to work as 
> expected.

Alternatively, if you want to run apcupsd for direct UPS control, there is an 
apcupsd-ups driver in NUT that translates apcupsd network status to NUT 
protocol - useful for a NAS.
> 
> Happy to send any logs or info that might be relevant (probably best to set 
> up ubuntu again since it's easier to control the config files). I first asked 
> about this in the Netgate (pfSense) forum so the last entries under uk_dave 
> is me with some info on upsc and upsrw. 
> https://forum.netgate.com/topic/102959/nut-package/728
> 
If I read everything correctly, my best guess here is that NUT is sending a 
different shutdown command than apcupsd. (Other than this model, I haven't 
heard of an UPS staying on battery once the power has returned.)

I'd agree that testing in Ubuntu is probably the easiest to control.

If you can capture the USB traffic when apcupsd tells the UPS to shutdown, we 
can compare that to what usbhid-ups does.

https://wiki.wireshark.org/CaptureSetup/USB

I'm not sure of the debugging support in apcupsd, but if it is doing things 
correctly, maybe we can just compare PCAPs, and reference the NUT logs?

For the NUT shutdown test, I think we might need at least a debug level of 3. 
You might also want to power the machine running NUT from another outlet 
temporarily, since we need to run the driver in debug mode without the help of 
upsd/upsmon to shut down the system properly.

Stop the services (nut-server and nut-client), then run 'sudo 
/lib/nut/usbhid-ups -DDD -k -a name-of-ups | tee -a 
/tmp/usbhid-ups.BR1500GI.log'. The '-k' flag tells the UPS to shut down, so you 
might need the UPS to be on battery power at that time.


> ___
> 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] upsd "events"

[Charles Lepple]

On Nov 7, 2020, at 11:18 AM, Jason Antman  wrote:
> 
> Hello,
> 
> I'm quite new to NUT, currently setting it up on a few machines in my home 
> lab because I switched from an APC UPS to a CyberPower unit. This is running 
> in a home lab, and I'm trying to implement some apparently unusual logic 
> around load-shedding.

The interesting thing to me is the shift from a single server being able to be 
supplied from one or more UPSes for redundancy, to a single UPS powering a 
number of smaller systems.

> I'm strongly considering writing my own custom script to replace upsmon in 
> order to achieve the desired result.
> 
> I see a lot of mention in the documentation on upsmon and upssched about 
> "events", as in an ONBATT, LOWBATT, ONLINE, etc., however I see nothing about 
> these in the Network protocol documentation.

> 
> Can someone please confirm whether there are actual "events" being sent out 
> to clients by upsd, or whether these events are completely derived/generated 
> within upsmon, just based on polling upsd and detecting a change in something 
> (such as ups.status)?
> 
The latter description is correct: upsmon polls the "ups.status" variable. When 
the state changes, upsmon generates the events internally. The majority of the 
mapping is in the comments here: 
https://github.com/networkupstools/nut/blob/v2.7.4/clients/upsmon.h 
 and the 
code here: 
https://github.com/networkupstools/nut/blob/v2.7.4/clients/upsmon.c#L1466-L1489 


There is a lot of business logic in upsmon devoted to logging, reconnecting, 
and detecting the status changes (potentially across disconnects). If you 
didn't want to rewrite and test that code in your own script, you could use the 
EXEC flag in upsmon to start your script from NOTIFYCMD when the UPS goes on 
battery, and then poll battery level from there. You could then set up another 
section of your script for ONLINE (which only gets called on a transition from 
OB to OL, not at startup) that does wake-on-LAN and kills the script started 
for ONBATT.

The key to on-battery/online is the NOTIFYTYPE environment variable: 
https://networkupstools.org/docs/man/upsmon.conf.html 


> Thanks so much,
> Jason Antman
> 
> PS - Since someone may ask about it, given my introduction, here's the setup 
> I have:
> 
> * One CyberPower UPS powering everything
> * Three Linux machines, "A", "B", and "C"
> * A bunch of network devices, as well as two Raspberry Pis
> 
> I'm trying to achieve the following shutdown behavior:
> * Kill host A when battery drops to 80%
> * Kill host B at 50%
> * Kill host C at 10%
> * Leave the outputs turned on always, so the network and Pis keep running
> * If the power comes back before the battery is exhausted, a script will turn 
> on hosts A, B, and C via wake-on-lan.
> 
> ___
> 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] ups.test.result meaning

[Charles Lepple]

On Oct 31, 2020, at 10:53 PM, Charles Lepple  wrote:
> 
> On Oct 31, 2020, at 8:30 PM, Gene Heskett  wrote:
>> 
>>> battery.voltage: 16.0
>> At that voltage, 5 of the 12 cells are shorted
>>> battery.voltage.nominal: 24
> 
> The 16.0 is a scaled version of the fixed (bogus) 24.0 V reading, similar to 
> this unit:
> 
> https://networkupstools.org/ddl/Cyber_Power_Systems/CP1500PFCLCD.html

Gene,

you might have missed this email, and I admit I wasn't very precise with my 
wording.

This particular UPS model is returning a fixed (in the sense of "constant") 
integer "24" (not 24.0) for both battery voltage and nominal battery voltage, 
likely because according to the vendor, some models do not have a battery 
voltage sensor (or, I suspect, it isn't accessible to the microprocessor that 
sends stats back over USB). Given the broken HID report descriptor that the UPS 
provides, NUT 2.7.2 scales "24" to "16.0". NUT 2.7.4 uses a heuristic to "fix" 
that value back to 24.0, but "garbage in, garbage out".

Another way to look at it: if you had two 12V lead-acid batteries in series, 
and someone gave you many readings of 27.0V, 26.0V, 25.0V, and 24.0V over time, 
would you be suspicious that you weren't seeing, say, 26.5V at some point?

Rick's batteries may be low, but I would be surprised if he actually saw 16.0V 
on a multimeter.

I wish we had a better way to flag these bogus values in NUT, but we're still 
collecting the data in order to programmatically figure out which models really 
do have a voltage sensor hooked up to USB, and which ones don't. For now, the 
next best thing is annotating the DDL entries from user-submitted data, like 
the link above.

See also the output.voltage discussion below. The scaling issue isn't as bad, 
but it's rooted in the same USB HID descriptor (the decoder ring for the values 
the UPS sends back).

> 
> I think we even "fixed" that after NUT 2.7.2, before I realized that many 
> units are providing a bogus value:
> 
> https://github.com/networkupstools/nut/commit/c8950dee9c91ce45d05d8f220ea26891fb92329e
> 
>>> output.voltage: 138.0
>> too high by about 15 volts
>> 
> 
> From the other CPS UPS thread on Monday:
> 
>> This is another known CyberPower issue, and fixing it properly requires 
>> making some changes deep in the core USB HID code (that would require a lot 
>> of testing on other vendors' equipment) for what is basically a cosmetic 
>> issue:
>> 
>> https://github.com/networkupstools/nut/issues/439
> 
> https://alioth-lists.debian.net/pipermail/nut-upsuser/2020-October/012126.html
> 


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

Re: [Nut-upsuser] ups.test.result meaning

[Charles Lepple]

On Oct 31, 2020, at 8:13 PM, Rick Dicaire  wrote:
> 
> On Sat, Oct 31, 2020 at 2:42 PM Tim Dawson  > wrote:
> I'm going to guess that since your test runtime of 305 is very close to the 
> low limit of 300, that's the warning. Not yet a fail, but very, very close. 
> 
Rick,

unfortunately, we don't get a ton of information back from the UPS about 
battery test results, so Tim's assessment is likely the explanation.

(Your UPS is literally sending back "2" for the test result, which maps to that 
message: 
https://github.com/networkupstools/nut/blob/master/drivers/usbhid-ups.c#L352 
 
. That's part of the USB HID PDC standard - if there are other vendor-specific 
results returned by CyberPower UPSes, we aren't yet aware of them.)

> I tried setting 
> override.battery.runtime.low = 60

The override.* settings are basically used in upsd to replace the values that 
the driver sends through upsd to clients like upsc and upsmon. The values don't 
go back down through the driver to the UPS hardware (the intent is to mask bad 
values sent in the other direction).

In order to change a value stored in the UPS, you can use upsrw on the value. 
(Related: many CyberPower UPS models require the shutdown/startup timer  values 
to be rounded up to the next multiple of 60 seconds.)

The one case where you can set override.battery.runtime.low and change the 
shutdown behavior is when you also set the "ignorelb" option. (I don't see that 
listed in the driver.parameter.* section of the upsc output.) If you were not 
having any luck changing that variable with upsrw to affect the shutdown 
threshold, you could use "ignorelb" to let upsd determine when to send the 
shutdown command to the UPS (instead of just sending it when the UPS reports 
LB). https://networkupstools.org/docs/man/ups.conf.html#_ups_fields 


> in ups.conf, and waited for the UPS to reach 100% charge, and ups.status to 
> report only OL.
> 
> I initiated another test.battery.start.quick.
> Same kind of result:
> 
> battery.charge: 31
> battery.charge.low: 10
> battery.charge.warning: 20
> battery.mfr.date: CPS

It is still possible that the battery is old, and needs to be replaced. The 
usual guideline is 3-5 years for a lead-acid battery in an UPS.

Note that this is a case where you can stash the date you changed out the 
battery by overriding the "battery.mfr.date: CPS" variable's value with an 
actual date.

> ___
> 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] ups.test.result meaning

[Charles Lepple]

On Oct 31, 2020, at 8:30 PM, Gene Heskett  wrote:
> 
>> battery.voltage: 16.0
> At that voltage, 5 of the 12 cells are shorted
>> battery.voltage.nominal: 24

The 16.0 is a scaled version of the fixed (bogus) 24.0 V reading, similar to 
this unit:

https://networkupstools.org/ddl/Cyber_Power_Systems/CP1500PFCLCD.html

I think we even "fixed" that after NUT 2.7.2, before I realized that many units 
are providing a bogus value:

https://github.com/networkupstools/nut/commit/c8950dee9c91ce45d05d8f220ea26891fb92329e

>> output.voltage: 138.0
> too high by about 15 volts
> 

From the other CPS UPS thread on Monday:

> This is another known CyberPower issue, and fixing it properly requires 
> making some changes deep in the core USB HID code (that would require a lot 
> of testing on other vendors' equipment) for what is basically a cosmetic 
> issue:
> 
> https://github.com/networkupstools/nut/issues/439

https://alioth-lists.debian.net/pipermail/nut-upsuser/2020-October/012126.html


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

Re: [Nut-upsuser] NUT Installation Issue

[Charles Lepple]

On Oct 31, 2020, at 5:36 PM, bobby  wrote:
> 
> Fatal error: 'maxretry' is not a valid variable name for this driver. 

https://networkupstools.org/docs/man/ups.conf.html

'maxretry' is in the global section, which needs to come before the 
UPS/driver-specific sections
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Can't get CyberPower UPS to work with Raspberry Pi 4

[Charles Lepple]

On Oct 30, 2020, at 12:22 AM, Gene Heskett  wrote:
> 
> On Thursday 29 October 2020 22:12:00 Charles Lepple wrote:
> 
>> On Oct 28, 2020, at 9:56 PM, Gene Heskett  wrote:
>>> Which looks very incomplete to me.  OTOH, its not a very big UPS but
>>> neither is the pi.  I have tested that, and it shuts off long before
>>> it outouts a LB signal.
>> 
>> Which part looks incomplete, the variables or the commands?
> 
> Commands Charles.  Since the pi is a very low drain bit of kit, I 
> expected to be able to lengthen the shutdown delay, to at least use 50% 
> of the battery, which should be several hours but its stuck at 2 
> minutes. Unreal, but it is what it is.

This is going to sound a bit picky, but to map what you're describing to what 
is implemented in NUT, "lengthen the shutdown delay" (with a driver that works 
100% as expected with that UPS) you'd want to change a R/W variable, which is 
separate from the list of instant commands.

(There is another "shutdown delay" - the time between when NUT signals the UPS 
to turn off, and when the relay actually goes "clunk". That would be 
"ups.delay.shutdown", but from the context, it sounds like you are concerned 
about lengthening the time between when the power fails and when the UPS says 
"the battery is low". A USB HID UPS typically measures it the other way: the 
battery is low (LB flag is set) when either:

* the charge is below a certain percentage (battery.charge.low)

* or the runtime is below a certain number of seconds (battery.runtime.low) - 
though for a CyberPower UPS, you generally have to round up any time-related 
values to the next larger multiple of 60 seconds.

(Of course, those are both estimates, but ideally, after a battery test, those 
estimates are close to reality.)

So if the UPS is setting the "LB" flag too early for your needs, you have a few 
options. As long as the UPS isn't turning off on its own (that is, NUT is 
telling it to turn off), and the reported charge or runtime values are 
reliable, you can tell NUT to use its own thresholds for shutdown:

"ignorelb" under UPS Fields: 
https://networkupstools.org/docs/man/ups.conf.html#_ups_fields

> 
>> Even the larger UPSes tend to return a lot of read-only values, and
>> only provide a few knobs for shutdown-related settings.
> 
> So I note running those cmds on this 1500wa APC under this desk. 
> Disappointing...

The APC protocol situation is a different rant entirely...

> Take care now.

You, too!

> Cheers, Gene Heskett
> -- 
> "There are four boxes to be used in defense of liberty:
> soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> If we desire respect for the law, we must first make the law respectable.
> - Louis D. Brandeis
> Genes Web page <http://geneslinuxbox.net:6309/gene>
> 
> ___
> 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] NUT Installation Issue

[Charles Lepple]

On Oct 30, 2020, at 3:00 PM, bobby  wrote:
> 
> I installed NUT on my raspberry pi.  I've been following this tutorial: 
> https://melgrubb.com/2016/12/11/rphs-v2-ups/.  I am trying to use NUT to 
> monitor my cyberpower UPS. I seem to have this problem though: upsc 
> cyberpower@localhost Init SSL without certificate database Error: Driver not 
> connected
> Doing a status check on nut-server, I see the following: Can't connect to UPS 
> [cyberpower] (usbhid-ups-cyberpower): No such file or directory

Just before starting nut-server (which needs to connect to a running driver), 
the article says to run "sudo upsdrvctl start". What did that return?

Also, for the benefit of others who come across this thread, please include a 
bit more detail on your setup. Since there's a good chance you're running 
Raspbian, you can probably get the NUT version with `dpkg -l nut-server`. 

> ___
> 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] Can't get CyberPower UPS to work with Raspberry Pi 4

[Charles Lepple]

On Oct 31, 2020, at 8:42 AM, Robert Stocker  wrote:
> 
> I successfully changed my UPS name and after a reboot, things seems to be 
> well on their way. Do I need to worry about this line in the upsc results:
> 
> Init SSL without certificate database

https://askubuntu.com/questions/468632/nut-ups-and-ssl-certificates
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Can't get CyberPower UPS to work with Raspberry Pi 4

[Charles Lepple]

On Oct 29, 2020, at 2:44 PM, Robert Stocker  wrote:
> 
> Sorry for the delay. Here are my outputs, but first a quick question: am I 
> right in thinking I can change the name of my ups simply by editing ups.conf? 
> That script I ran from the Pi forum used that name, and I don't care for it. 
> Thanks again for your help.
> 
Yes, ups.conf, plus the other locations that refer to it (upsmon.conf, and any 
scripts). You'll want to restart the systemd services, too.

Thanks for posting the variables and commands.
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Can't get CyberPower UPS to work with Raspberry Pi 4

[Charles Lepple]

On Oct 28, 2020, at 9:56 PM, Gene Heskett  wrote:
> 
> Which looks very incomplete to me.  OTOH, its not a very big UPS but 
> neither is the pi.  I have tested that, and it shuts off long before it 
> outouts a LB signal.

Which part looks incomplete, the variables or the commands?

Even the larger UPSes tend to return a lot of read-only values, and only 
provide a few knobs for shutdown-related settings.
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] NUT uses port 3493 for everything

[Charles Lepple]

On Oct 24, 2020, at 3:20 PM, Roger Price  wrote:
> 
> The NUT project uses port 3493 to receive traffic to the upsd server. Unlike 
> the protocols http (80) and https (443), NUT has no specific port for 
> encrypted traffic.  For the upsdTLS.py daemon. I squatted port 563, but it 
> would be much better to have an officially assigned port.
> 
> Port 3494 was at one time assigned to
>  ibm34943494/tcp # IBM 3494  [Jeffrey_Pilch]
>  ibm34943494/udp # IBM 3494  [Jeffrey_Pilch]
> 
> The IBM 3494 is a huge tape cartridge device.  Over 6000 cartridges at a 
> time! It was announced 1995, withdrawn from marketing 2006 and service was 
> discontinued 2018.
> 
> I see that the port 3494 has disappeared from /etc/services in Debian 9.  Is 
> it possible to aquire the port for NUT?

I think Russell Kroll registered port 3493 before I started using NUT. (If 
others have more information, please jump in.) My understanding is that TCP 
port assignments are handled by IANA:

https://www.iana.org/form/ports-services



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

Re: [Nut-upsuser] Can't get CyberPower UPS to work with Raspberry Pi 4

[Charles Lepple]

On Oct 27, 2020, at 2:45 PM, Robert Stocker  wrote:
> 
> Thanks so much for all the help! It looks like at present I've at least got a 
> working configuration that I need to test and fine-tune, am I interpreting 
> this correctly?

Yes. If you're good with the default NUT behavior of shutting down when the UPS 
signals LB (low battery; per upsc, seems to be at 10% charge or 300 seconds 
left, whichever comes first), it's just a matter of testing the shutdown 
command, and any power sequencing (including any auto power-on settings on the 
motherboard) issues on the way back up.

If not, there are ways to either adjust the UPS low power thresholds, or ignore 
them completely. Roger Price has a good enumeration of alternate shutdown 
strategies in his Configuration Examples document linked here: 
http://rogerprice.org/NUT/

As I just mentioned in my reply to Gene, it would be handy to have the output 
of "upsrw" and "upscmd -l" for your UPS. Those commands show the read/write 
variables and instant commands that the NUT driver detects, respectively.
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Can't get CyberPower UPS to work with Raspberry Pi 4

[Charles Lepple]

On Oct 26, 2020, at 9:38 AM, Gene Heskett  wrote:
> 
>>> battery.voltage: 24.0
>>> battery.voltage.nominal: 24
>> 
>> I don't have the citation handy, but I think another user reported
>> that the battery.voltage returned by the UPS is a constant 24.0 V,
>> regardless of the actual battery voltage.
[...]
> I think it may be dependent on thhe ups. I have a 625 WA cyberpower on an 
> rpi4, and I believe its more truthfull. Is this helpfull?
> 
You're right, the lack of a battery voltage sensor isn't true for all CPS 
hardware.

I was trying to make the point that the 24.0 V reading is suspect, while 
covering the cases where broken scaling means that NUT displays it as 16.0 V.

However, back in January, we discussed the input.transfer.high/.low issue: 
https://alioth-lists.debian.net/pipermail/nut-upsuser/2020-January/011668.html

The root cause of that is closer to some of the other CPS issues, like the 
"output.voltage: 137.0" that Robert posted.

That upsc dump is useful. For completeness, could you (and Robert) please post 
the output of "upsrw myups" and "upscmd -l myups"?

I manually grep through upsc output to find these sorts of things, but some 
day, I'd like the DDL[*] to be able to show a table of UPS models and their 
supported NUT variables. (Something like a hardware comparison on a vendor 
website, but from the perspective of what NUT can read.)

[*] e.g. https://networkupstools.org/ddl/Cyber_Power_Systems/
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Can't get CyberPower UPS to work with Raspberry Pi 4

[Charles Lepple]

On Oct 26, 2020, at 9:01 AM, I wrote:
> 
>> battery.voltage.nominal: 24
> 
> I don't have the citation handy, but I think another user reported that the 
> battery.voltage returned by the UPS is a constant 24.0 V, regardless of the 
> actual battery voltage.

Here's what I was thinking of:

https://github.com/networkupstools/nut-ddl/blob/8995562a0253e980d36f6bdddfe09c9f2c866657/Cyber_Power_Systems/Cyber_Power_Systems__CP1500PFCLCD__usbhid-ups__2.7.1__01.dev#L11-L13

"CyberPower states that battery voltage is not supported in this model of UPS. 
[CP1500PFCLCD; circa 2014]
It's not even shown in their 'PowerPanel' software."
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Can't get CyberPower UPS to work with Raspberry Pi 4

[Charles Lepple]

On Oct 26, 2020, at 9:01 AM, I wrote:
> 
>> battery.voltage: 24.0
>> battery.voltage.nominal: 24
> 
> I don't have the citation handy, but I think another user reported that the 
> battery.voltage returned by the UPS is a constant 24.0 V

*another user reported that CyberPower support said the voltage returned is a 
constant 24.0 V.
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Can't get CyberPower UPS to work with Raspberry Pi 4

[Charles Lepple]

On Oct 25, 2020, at 11:52 AM, Robert Stocker  wrote:
> 
> Init SSL without certificate database
> battery.charge: 100
> battery.charge.low: 10
> battery.charge.warning: 20
> battery.mfr.date: CPS
> battery.runtime: 15690
> battery.runtime.low: 300
> battery.type: PbAcid
> battery.voltage: 24.0
> battery.voltage.nominal: 24

I don't have the citation handy, but I think another user reported that the 
battery.voltage returned by the UPS is a constant 24.0 V, regardless of the 
actual battery voltage.

> device.mfr: CPS
> device.model: CST135XLU
> device.serial: CR7EO2003120
> device.type: ups
> driver.name: usbhid-ups
> driver.parameter.pollfreq: 30
> driver.parameter.pollinterval: 5
> driver.parameter.port: auto
> driver.parameter.synchronous: no
> driver.version: 2.7.4
> driver.version.data: CyberPower HID 0.4
> driver.version.internal: 0.41
> input.voltage: 121.0
> input.voltage.nominal: 120
> output.voltage: 137.0

Given the description on the product page you sent earlier, the UPS is likely 
not providing 137.0 V, but is bypassing the transformer since the power is good.

https://www.cyberpowersystems.com/product/ups/battery-backup/cst135xlu/

This is another known CyberPower issue, and fixing it properly requires making 
some changes deep in the core USB HID code (that would require a lot of testing 
on other vendors' equipment) for what is basically a cosmetic issue:

https://github.com/networkupstools/nut/issues/439

> ups.beeper.status: disabled
> ups.delay.shutdown: 20
> ups.delay.start: 30

For these delays, note there seems to be an issue with ondelay/ups.delay.start:

https://github.com/networkupstools/nut/issues/625

and rounding of the timers down to the next lower minute:

https://github.com/networkupstools/nut/blob/f3a40e4595c1f18368f89b9af338bfe52dd06846/docs/man/usbhid-ups.txt#L53-L78

so basically I'd recommend testing shutdown extensively.

> ups.load: 4
> ups.mfr: CPS
> ups.model: CST135XLU
> ups.productid: 0501
> ups.realpower.nominal: 810
> ups.serial: CR7EO2003120
> ups.status: OL
> ups.test.result: No test initiated
> ups.timer.shutdown: -60
> ups.timer.start: -60
> ups.vendorid: 0764
>  
> If you run systemctl, you should see something like this:
> 
> And here's what I got from that:
> 
>  nut-driver.service   loaded active running   Network UPS Tools - power 
> device driver controller   
>  nut-monitor.service   loaded active running   Network UPS Tools - power 
> device monitor and shutdown controller 
>  nut-server.service   loaded active running   Network UPS Tools - power 
> devices information server 
> 


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

Re: [Nut-upsuser] Can't get CyberPower UPS to work with Raspberry Pi 4

[Charles Lepple]

On Oct 23, 2020, at 11:06 AM, Robert Stocker  wrote:
> 
> Thanks again for your patience. I'm still learning how to deal with systemctl 
> myself (and starting from, I'm sure, a much lower level of understanding), so 
> if I've neglected to restart or start something, please let me know.
> 
> I made the change to /etc/nut/upsd.conf.
> I restarted upsdrvctl, which reported back:
> Network UPS Tools - UPS driver controller 2.7.4
> Network UPS Tools - Generic HID driver 0.41 (2.7.4)
> USB communication driver 0.33
> Using subdriver: CyberPower HID 0.4
> 
> /root/ups-info still returns
> Unable to retrieve UPS information

I can't speak to the ups-info script (I might have missed where that came from 
- wasn't in the zip file from the RPi forum thread), but there are three basic 
components needed for NUT monitoring and shutdown:

* the driver (which it looks like upsdrvctl is starting)
* the network server (upsd; probably not running?)
* the monitoring and shutdown client (upsmon)

The easiest way to tell if upsd is working is to run "upsc -l" on the same 
system, which will list the NUT UPS names, and then run e.g. "upsc mge" 
(replacing "mge" with the name returned by "upsc -l").

If you run systemctl, you should see something like this:

$ systemctl |grep nut-
nut-driver.service  loaded active running   Network UPS Tools - power 
device driver controller
nut-monitor.service loaded active running   Network UPS Tools - power 
device monitor and shutdown controller
nut-server.service  loaded active running   Network UPS Tools - power 
devices information server

For each service that isn't running, try e.g. "systemctl start nut-server" and 
if that is not successful, you should be able to get more information from 
"systemctl status nut-server".
> 
> Here's the updated (and again truncated) output of sudo /lib/nut/usbhid-ups 
> -DD -a 

^ This debug output is from the driver talking to the hardware. We won't need 
to look at that again unless there is an issue at that layer. If there is, and 
we need to revisit that layer, please gzip and attach the output.


> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Nut-upsuser digest..."

^ Please note. Also, the mailing list has a limit of 40kB/message, otherwise 
messages need to be manually approved. If you don't need HTML formatting, that 
will help cut down on message size.
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Can't get CyberPower UPS to work with Raspberry Pi 4

[Charles Lepple]

On Oct 21, 2020, at 3:27 PM, Robert Stocker  wrote:
> 
> Operating System:  Raspbian GNU/Linux 10 (buster)
> Kernel name & release: Linux 5.4.51-v7l+
> Kernel version:#1333 SMP Mon Aug 10 16:51:40 BST 2020
> 
> exact NUT version:
> Network UPS Tools 2.7.3, according to the last line of man ups

Hmm, either that's a typo, or something didn't get rebuilt correctly. The debug 
output shows that the package is based on NUT 2.7.4.

For Raspbian (Debian) packages, the canonical version number (that also 
specifies how many patch releases have been built by the packagers) is shown by 
e.g. "dpkg -l nut-server"

That said, I don't think this is version-specific (but we do appreciate the 
info). See below.
> 
> NUT installation method: from source tarball, package or Subversion,
> installed from package with apt-get install, using a scripted install from 
> the Raspberry Pi forums (found here: 
> https://www.raspberrypi.org/forums/viewtopic.php?t=240651=1508882#p1508882 
> )
> 
> exact device name and related information (manufacturing date, web pointers, 
> …)
> lsusb reports: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS
> Actual model number is CST135LXU according to the device's labeling. Here's 
> the web page: 
> https://www.cyberpowersystems.com/product/ups/battery-backup/cst135xlu/ 
> 
> 
> complete problem description, with any relevant traces, like system log 
> excerpts, and driver debug output. You can obtain the latter using the 
> following command, as root and after having stopped NUT:
> /path/to/driver -DD -a 
> 
> After installing and rebooting, running ups-info returns:
> Unable to retrieve UPS information
> 
> All attempts to use commands like upsc, upscmd, upsrw result in:
> Error: Connection failure: Connection refused
> 
Parallel init systems like systemd have broken a lot of the assumptions about 
what is running at any given time, and we're always playing catch-up. 
Distributions should be starting NUT after the network interfaces are fully up. 
However, that doesn't always seem to be the case, and that script includes the 
following:

  cat <> /etc/nut/upsd.conf

LISTEN 127.0.0.1 3493
LISTEN ${IPADDR} 3493
EOF


Unless you have multiple network interfaces, both the LISTEN addresses should 
be replaced with a single "LISTEN 0.0.0.0 3493". Even if you have multiple 
network interfaces, firewall rules are probably a better place to exclude one 
or more of the interfaces.

Note also that the CyberPower UPSes have a number of mostly cosmetic errors in 
the output: 
https://github.com/networkupstools/nut/issues?q=is%3Aissue+is%3Aopen+label%3A%22CyberPower+%28CPS%29%22
 


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

Re: [Nut-upsuser] [EXTERNAL] Is there a new way to search the listserv archives?

[Charles Lepple]

On Oct 20, 2020, at 3:44 PM, David Zomaya  wrote:
> 
 I see the link  here, but clicking it results in a 404. Before I waste 
 everyone's time posting my question, I really wanted to search to see if 
 it's been solved already.
> 
> I don't know of a baked-in official method, but the 
> "site:alioth-lists.debian.net/pipermail/nut-upsuser/" search modifier should 
> work with both DuckDuckGo and Google.
> 
> Example:
> https://duckduckgo.com/?q=Tripp+Lite++SMART1500+site%3Aalioth-lists.debian.net%2Fpipermail%2Fnut-upsuser%2F=ffab=web
>  
> 

Agreed, we have a similar Google search box here: 
http://networkupstools.org/support.html 


Something is broken which does not allow us to edit the link on the Mailman 
list info page. https://github.com/networkupstools/nut-website/issues/10 


> ___
> 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] Multi UPS Monitoring

[Charles Lepple]

On Oct 9, 2020, at 8:07 PM, Rusty Bower wrote:
> 
> Hey all,
> 
> I've read through as many relevant mailing list posts and public blog posts 
> as I could, but I can't seem to find an answer to my issue.
> 
> I currently have 2x Tripp Lite SMART1500LCDXLs, and I am attempting to 
> monitor both of them with the same Raspberry Pi using NUT. The problem I have 
> is there doesn't seem to be any way in the nut.conf to differentiate between 
> the two UPS via USB other than Vendor/Product/Serial. Unfortunately, I cannot 
> leverage Vendor/Product filtering, because they are the exact same model, and 
> the serial number is returning "unknown"

The unknown serial number does seem to be the case for other 2012 protocol 
models, yes.

(I'm 99% certain this isn't going to yield different results in your case, but 
if you ever want to rule out NUT as part of the problem in retrieving the 
serial number, you can run "lsusb -vvv" as root, or check dmesg/journalctl to 
see if other parts of the system were able to retrieve a serial number.)

> 
> Does anyone know how to get these Tripp Lite models to return an actual 
> serial number? Or is there a way to differentiate between the two devices on 
> the same USB bus?

I forget if adding a USB hub ends up creating a second logical bus as far as 
the kernel is concerned, but if you have a spare hub on hand, it's an easy 
thing to try.

It is possible that a future version of NUT could use the kernel's USB topology 
information: 
http://libusb.sourceforge.net/api-1.0/group__libusb__dev.html#ga14879a0ea7daccdcddb68852d86c00c4
 


but we are still working out issues in the libusb-0.1/1.0 transition: 
https://github.com/networkupstools/nut/issues/300 


If it were me, I'd probably just find a spare Raspberry Pi and have a 1:1 
UPS-to-Pi mapping, just to hedge against the Pi and its power supply being a 
single point of failure in the monitoring system.

> 
> Raspbian GNU/Linux 10
> Nut Version 2.7.4-8

Thanks for the NUT and OS version info!
> 
>0.056938 Checking device (09AE/2012) (001/113)
>0.062961 - VendorID: 09ae
>0.063011 - ProductID: 2012
>0.063055 - Manufacturer: Tripp Lite
>0.063094 - Product: Tripp Lite UPS
>0.063136 - Serial Number: unknown
>0.063189 - Bus: 001
>0.063259 - Device release number: 0009
> 
> Rusty
> ___
> 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] ups not being started sat reboot

[Charles Lepple]

On Sep 5, 2020, at 5:23 AM, Roger Price wrote:
> 
> On Sat, 5 Sep 2020, Gene Heskett wrote:
> 
>> But runs normally if started.  On a rpi4 running an uptodate raspbian 
>> buster, how do I set it to auto start at boot time?
> 
> Hello Gene, By "auto start" I assume you mean the automatic power on of a box 
> when wall power returns after a power failure. For this to work, two things 
> are needed:
> 
Roger, I don't have any experience with the Raspberry Pi 4, but previous RPi 
models would just boot as soon as power is applied, so I'm guessing this is 
more of a problem starting NUT at boot.

Gene, assuming this is a "standalone" setup (upsd, driver, and upsmon on the 
same system). If so, I'd recommend using "LISTEN 127.0.0.1" if you don't need 
network access (e.g. upsc or other monitoring software on another box), or 
"LISTEN 0.0.0.0" to listen on all local network interfaces.

If the LISTEN line is't the culprit, I'd recommend posting the output of 
"systemctl status nut-server.service" after boot to see why it didn't start (or 
more likely, stay running after starting).

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

Re: [Nut-upsuser] Device recommendation Salicru

[Charles Lepple]

On Aug 19, 2020, at 8:20 AM, Charles Lepple wrote:
> 
> Getting back to Marc's original question, this is all we have collected for 
> Salicru: https://github.com/networkupstools/nut-ddl/tree/master/Salicru
> 
> That is not to say that other models don't work, but that information was 
> harvested from a post about USB errors, so I wouldn't consider that a ringing 
> endorsement. At the very least, I would not want use that particular hardware 
> for a critical system that needs monitoring. (It may be fine as a standalone 
> unit for providing power; unfortunately, we don't get much hard information 
> on that, since most NUT users are interested in monitoring.)

my mistake, we do have this open issue:

https://github.com/networkupstools/nut/issues/803

Basically, there are some collisions in USB IDs and NUT tables, such that 
certain Salicru units may not be able to be shut down properly by NUT.
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Device recommendation Salicru

[Charles Lepple]

On Aug 19, 2020, at 6:22 AM, Manuel Wolfshant wrote:
> 
> On 8/19/20 12:55 PM, Marc Franquesa wrote:
>> Thanks all for the quick responses on the question (always a good sign of 
>> this mailing list).
>> 
>> (Tim Dawson, Manuel Wolfshant):
>> Regarding root cause of my current problem pointing to a faulty battery, 
>> this is not the first time that someone points to it. However I made a 
>> simple test with the vendor tools (Windows) and didn't found any issue, as 
>> well as they discharged normally (although only tested without load).
>> 
> That test is not very relevant, unfortunately. You can easily get false 
> results ( as in battery OK when it is not really OK ). The only relevant test 
> is under real load, which is why I suggested using a small motor or a light 
> bulb.

An UPS battery test (especially on a higher-end UPS like many of the MGE 
models) can do two things: provide a small load, and recalibrate the runtime 
estimate based on how the UPS responds to that load.

The UPS may not result in a NUT "RB" (replace battery) flag, but it should 
still have a better estimate of runtime. Marc indicated he saw adequate runtime 
figures, but if those are based on the original battery, then they are bogus.

>> 
>> (David Zomaya).
>> Regarding Tripplite, I found many active threads on the mailing list so I 
>> consider it everytime as an alternative, however those devices are a bit 
>> pro/expensive too and they are harder to get/find support on my country 
>> compared with other vendors. However feel free to suggest a model like the 
>> Ellipse ECO 1200VA (in power and price).
>> 
>> Also I found many reports of NUT working devices on the mailing list which 
>> are not reported on the HCL (https://networkupstools.org/stable-hcl.html) 
>> which makes me ask if this list is maintained/updated as well as the 
>> acknowledges section (https://networkupstools.org/acknowledgements.html)
> 
> Unfortunately that list is rather unmaintained.

The HCL on the website is built as part of the NUT release process, and due to 
a combination of blocking bugs (which I'm not going to rehash here; see 
GitHub), we haven't made a new release recently.

Also note that if an UPS implements the PhoenixTec Qx protocol "well enough" 
for blazer_usb or nutdrv_qx, we don't often get reports of success.

However, the HCL doesn't adequately capture a lot of the nuances of how *well* 
certain aspects of UPSes are supported by NUT. The Device Dump Library (DDL) 
has annotations on what is known to be incorrect (typically incorrect scaling 
on voltages), as well as lists of supported commands (including battery tests), 
and links to sources for that information. The DDL is also part of the NUT 
website, but as with the HCL, it is also stored on GitHub.

Getting back to Marc's original question, this is all we have collected for 
Salicru: https://github.com/networkupstools/nut-ddl/tree/master/Salicru

That is not to say that other models don't work, but that information was 
harvested from a post about USB errors, so I wouldn't consider that a ringing 
endorsement. At the very least, I would not want use that particular hardware 
for a critical system that needs monitoring. (It may be fine as a standalone 
unit for providing power; unfortunately, we don't get much hard information on 
that, since most NUT users are interested in monitoring.)

> __
> 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] Eaton 5E 1100i USB UPS - failed to claim USB device error

[Charles Lepple]

On Aug 19, 2020, at 6:00 AM, Louis van Dyk  wrote:
> 
> @DEVS:  Could you please re-add the code for using this UPS?  It's
> still being sold fast and furious in our region, and I'm sure more
> people are having the same problem.

Kernel quirks need to be added back by the kernel developers. 

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

Re: [Nut-upsuser] Synology NAS is shutting down Ubuntu servers after very brief power outage (fwd)

[Charles Lepple]

On Aug 12, 2020, at 5:32 PM, Todd Benivegna  wrote:
> 
>> Those LISTEN lines were appropriate pre-systemd when NUT's startup script 
>> was launched after networking was fully enabled. I would recommend "LISTEN 
>> 0.0.0.0 3493" instead, and use firewall rules if you are trying to exclude 
>> an interface (which is likely not the case on a Pi).

> Ok, so replace both with that or just one of the lines?  I suspected one of 
> the lines may be the problem because when I took out the second line, 
> nut-server service wouldn’t fail, but then clients couldn’t connect.

Recommend replacing both. Binding to 0.0.0.0 will allow connections to/from 
127.0.0.1. The error handling is not ideal, but upsd logs messages as it 
parses. You can stop the service (if systemd is still trying to restart it), 
and then try "sudo upsd -D" to see what it is doing. It should respond to 
Ctrl-C.
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Synology NAS is shutting down Ubuntu servers after very brief power outage (fwd)

[Charles Lepple]

On Aug 12, 2020, at 12:11 AM, Todd Benivegna  wrote:
> 
> Here is my upsd.conf:
> 
> LISTEN 127.0.0.1 3493
> LISTEN 192.168.1.31 3493
> 
Those LISTEN lines were appropriate pre-systemd when NUT's startup script was 
launched after networking was fully enabled. I would recommend "LISTEN 0.0.0.0 
3493" instead, and use firewall rules if you are trying to exclude an interface 
(which is likely not the case on a Pi).
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Synology NAS is shutting down Ubuntu servers after very brief power outage (fwd)

[Charles Lepple]

On Aug 9, 2020, at 3:18 PM, Todd Benivegna wrote:
> 
> Now they will spin-up on their own, but it takes 5-10 seconds.  My thought 
> was if they can’t communicate initially, they assume the server is dead and 
> shut down.  Would that make sense at all?  

Sorry to jump in the middle here, but this can occur in certain cases, when 
upsmon sees a server go dead *after seeing it go on battery*. See "DEADTIME" 
description: https://networkupstools.org/docs/man/upsmon.conf.html (defaults to 
15 seconds)
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Low Battery Problems

[Charles Lepple]

On Jun 22, 2020, at 3:42 PM, Gene Heskett wrote:
> 
> pi@rpi4:~ $ sudo nano /etc/nut/upsd.users
> pi@rpi4:~ $ upscmd myups test.battery.start.deep

You'll need a "sudo upsd -c reload" in between editing the users file and 
trying a new command.

https://networkupstools.org/docs/man/upsd.html 


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

Re: [Nut-upsuser] Low Battery Problems

[Charles Lepple]

On Jun 22, 2020, at 3:36 PM, Charles Lepple wrote:
> 
> On Jun 22, 2020, at 1:26 PM, Gene Heskett wrote:
>> 
>> So I just edited /etc/nut/upsd.users to add both the commands it claims 
>> to have but get this response to either:
> 
> In your original example, you had multiple “instcmd =“ lines for one user- I 
> think the allowed commands all need to be listed on one instcmd line.

Ignore this, I misremembered (and didn't read far enough down the URL I sent). 
Multiple allowed commands are specified with one command per instcmd.





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

Re: [Nut-upsuser] Low Battery Problems

[Charles Lepple]

On Jun 22, 2020, at 1:26 PM, Gene Heskett wrote:
> 
> So I just edited /etc/nut/upsd.users to add both the commands it claims 
> to have but get this response to either:

In your original example, you had multiple “instcmd =“ lines for one user- I 
think the allowed commands all need to be listed on one instcmd line. 
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser