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

Carsten Aulbert <carsten.aulbert at aei.mpg.de> writes:
> Hi all,
>
> On 5/19/23 15:11, Greg Troxel wrote:
>>    LB is baked in to nut behavior.   So if a UPS doesn't report LB,
then
>>    it makes sense to synthesize it.  Synthetic LB is the cleanest fix
at
>>    the earlier processing point.
>
> I fully agree and thus this ought to be done in/near uspd IMHO. I
> glanced over the server/ directory and was not sure where even to
> begin hooking this in. Should this be directly in upsd (upsd.c) or
> rather in/near the driver level (driver/main.c)?
I think it belongs in upsd someplace, as what I want is a way to make LB
appear based on a rule instead of (or in addition) to the LB reported by
the device.   The 50% vs 10% example captures the need for %-LB  on
devices that actually do report LB perfectly, and I think it's a desire
many will have.
>>    Yes, this could be in upsmon, but that's not synthetic LB,
it's
>>    choosing to shutdown if battery is below X.
>
> Yeah, this should be independent and fully on the client side (and
> thus upsmon) where each client can choose how to react to a UPS on
> battery.
It could also make sense to make upsmon smarter, but if we are really
talking about defining "this UPS's battery is now low", that's
what LB
is supposed to mean and we should make it work that way.
>>    We should be clear on "critical" vs "LB" and
clean up the language to
>>    be consistent.
>
> For upsmon, I would stay with critical as this is already mentioned in
> upsmon(8) and I guess "LB" could stay for the server part as each
user
> could decide whether she wants to rely on LB from the UPS itself or on
> the self-defined override.
I think the difference is:

  LB is a state reported by a UPS (perhaps synthetic in upsd) that says
  that the battery is nearing empty and remaining runtime is limited

  critical is an opinion by upsmon that the UPS has reached a state
  where it is prudent to do an immediate shutdown.  Typically LB implies
  critical but it could be more complicated.
>>    Beware that I'm a bit fuzzy on details beyond my comments and
even
>>    some on things I commented on, so take them as such.
>
> Same here, quite at a loss what is handled where on the server and
> always low on time due to other projects/tasks.
>
> Cheers and any pointers appreciated!
I would look where input from drivers is processed, and basically add

  if (battery% <= 50 && ! set?(LB)) {
     log that we are doing synthetic LB
     set!(LB)
  }

to mix C and scheme :)   Then of course make it configurable.  But it
probably is that easy to just make it hard-coded 50.

Hmm. Is there maybe something there already that will do this? Maybe kind of
back-handed.

In drivers/dstate.c, I see:

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.

So, I surmise that of the UPS config in ups.conf included:
	driver.flag.ignorelb = 1
	override.battery.charge.low = 50

would not that cause status to be returned as ?OB LB? when charge dropped below
50%?

(I?d tried doing the override a while ago, but didn?t know about the ?ignorelb?
thing.)

Am I missing something?

(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.)


(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.)
> On May 22, 2023, at 6:12 AM, Greg Troxel <gdt at lexort.com> wrote:
> 
> Carsten Aulbert <carsten.aulbert at aei.mpg.de> writes:
> 
>> Hi all,
>> 
>> On 5/19/23 15:11, Greg Troxel wrote:
>>>   LB is baked in to nut behavior.   So if a UPS doesn't report
LB, then
>>>   it makes sense to synthesize it.  Synthetic LB is the cleanest
fix at
>>>   the earlier processing point.
>> 
>> I fully agree and thus this ought to be done in/near uspd IMHO. I
>> glanced over the server/ directory and was not sure where even to
>> begin hooking this in. Should this be directly in upsd (upsd.c) or
>> rather in/near the driver level (driver/main.c)?
> 
> I think it belongs in upsd someplace, as what I want is a way to make LB
> appear based on a rule instead of (or in addition) to the LB reported by
> the device.   The 50% vs 10% example captures the need for %-LB  on
> devices that actually do report LB perfectly, and I think it's a desire
> many will have.
> 
>>>   Yes, this could be in upsmon, but that's not synthetic LB,
it's
>>>   choosing to shutdown if battery is below X.
>> 
>> Yeah, this should be independent and fully on the client side (and
>> thus upsmon) where each client can choose how to react to a UPS on
>> battery.
> 
> It could also make sense to make upsmon smarter, but if we are really
> talking about defining "this UPS's battery is now low",
that's what LB
> is supposed to mean and we should make it work that way.
> 
>>>   We should be clear on "critical" vs "LB" and
clean up the language to
>>>   be consistent.
>> 
>> For upsmon, I would stay with critical as this is already mentioned in
>> upsmon(8) and I guess "LB" could stay for the server part as
each user
>> could decide whether she wants to rely on LB from the UPS itself or on
>> the self-defined override.
> 
> I think the difference is:
> 
>  LB is a state reported by a UPS (perhaps synthetic in upsd) that says
>  that the battery is nearing empty and remaining runtime is limited
> 
>  critical is an opinion by upsmon that the UPS has reached a state
>  where it is prudent to do an immediate shutdown.  Typically LB implies
>  critical but it could be more complicated.
> 
>>>   Beware that I'm a bit fuzzy on details beyond my comments and
even
>>>   some on things I commented on, so take them as such.
>> 
>> Same here, quite at a loss what is handled where on the server and
>> always low on time due to other projects/tasks.
>> 
>> Cheers and any pointers appreciated!
> 
> I would look where input from drivers is processed, and basically add
> 
>  if (battery% <= 50 && ! set?(LB)) {
>     log that we are doing synthetic LB
>     set!(LB)
>  }
> 
> to mix C and scheme :)   Then of course make it configurable.  But it
> probably is that easy to just make it hard-coded 50.
> 
> _______________________________________________
> Nut-upsuser mailing list
> Nut-upsuser at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20230522/58b8580a/attachment-0001.htm>