[Nut-upsuser] Synthesize low batt (LB) fron SNMP UPS which does not support this?

[Carsten Aulbert]

Hi Roger,

On 5/16/23 17:00, Roger Price wrote:
> Hello Carsten, That's what I did but for a much simpler setup. I live in 
> an area with a lot of lightning, and my shutdown criteria is to be able 
> to shut down repeatedly during an electrical storm.  The NOTIFY and 
> CMDSCRIPT and the upssched-cmd logic are written up in detail in chapter 
> 7 of https://rogerprice.org/NUT/ConfigExamples.A5.pdf .
> 
> Chapter 8 contains a detailed description of a hypothetical installation 
> fed by multiple UPSs.

wow, that looks like a LOT of content to digest but I'm not so sure if 
our problems align that well (but then I only briefly skimmed over it).

Luckily for us, our power grid is really stable, I think we only had 4 
or 5 outages lasting more than a fraction of a second over the past ~ 15 
years. Thus, we use our UPSes mainly for providing clean and stable 
power to our computing center with the bonus of have power when the 
mains go down.

We shut down the compute nodes via upssched and a 30s timer. If the 
power cut is shorter than that, they will simply continue running as the 
timer is cancelled by nut. Otherwise they will simply power down and 
stretch our 6-8 minutes battery buffer to much longer.

What I'm more worried about then are the storage servers, networking, 
head nodes and a couple of special nodes which are powered by both UPSes.

We could use upssched also for those nodes, but the pipelining of 
messages makes it a bit hard to have a final "stateful" service working 
around the missing LB flag. This would need to actively query the UPS 
and act after battery.runtime or battery.charge is too low overall. My 
simple approach there did not work (effectively looping in the script) 
as the next message from upssched would simply wait in the pipeline 
while my script was still looping.

We could also use upsmon to call our script instead of upssched which 
then would need to handle being called multiple times and coordinate 
what to do based on the messages being passed.

Both cases would probably need our own running service which would need 
to be fed messages and then act based on their own UPS queries. Probably 
doable, but not that nice.

Idly browsing the client sources, I guess I could try to add our logic 
here[1] and use [2] to gather the battery stats from our UPS and then 
decide if this UPS is considered critical or not. But for this, I would 
need to dust off/excavate my ancient poor C knowledge ;-).

I guess I will give this a try unless someone has a brilliant idea and 
could save my sanity.

Cheers

Carsten

[1] 
https://github.com/networkupstools/nut/blob/e3bdc28476700c7396bdde912e5789ccb7ecb1d7/clients/upsmon.c#L925

[2] 
https://github.com/networkupstools/nut/blob/e3bdc28476700c7396bdde912e5789ccb7ecb1d7/clients/upsclient.h#LL105C1-L107C33

-- 
Dr. Carsten Aulbert, Max Planck Institute for Gravitational Physics,
Callinstraße 38, 30167 Hannover, Germany, Phone +49 511 762 17185
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4827 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20230516/7f693f9a/attachment.bin>