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

[Greg Troxel]

Willcox David via Nut-upsuser <nut-upsuser at alioth-lists.debian.net>
writes:

> In status_init(), if “driver.flag.ignorelb” is set in the driver state, the “ignorelb” flag is set.
> In status_set(), if ignorelb is set, and the status being set
> (presumably from the UPS) is LB, it’s ignored. In other words, LB
> reported by the UPS is ignored.
> In status_commit(), if ignorelb is set, there’s code to compare
> battery.charge against battery.charge.low and battery.runtime against
> battery.runtime.low. If either is below the “low” setting, “ LB” is
> added to the status. (So “OL” would become “OL LB” and “OB" would
> become “OB LB”. And note that the two “.low” settings can be
> overridden in the config.

Interesting.  Perhaps the runtime check to set LB should be in
status_set also.  However I think it's more subtle than that.

Read

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

and also look at some other drivers.


I think there's an assumption baked in that changing values like
battery% and line voltage is a different thing from changing flags, but
"set LB if battery <= X" crosses those.   So it may be necessary to
understand how this init/set interacts with everything else.

Perhaps we need a "update cycle done" call that is made every time
regardless of if the drive thinks it changed flags.  Or perhaps a driver
is supposed to call status_commit when it is done no matter what.  Some
code reading is in order!

> (I tried setting this but it didn’t seem to work. But then, I’m not
> sure how the NUT I installed from a package on my RPI compares with
> the source I downloaded.)

If you are trying to debug or to develop new things, you really have to
build from source and run that, rather than running old code from a
packaging system.  Nobody should run 2.7.4, pretty much for any reason.

> (I surmise from the way that code works that there must be a seperate
> process for each driver. Otherwise all of those static variables are
> scary.)

Yes, each driver runs as a process, as ps will show you, and this is
essentially the driver library from which a device-specific driver is
constructed.