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 <[email protected]> wrote:
>
> Carsten Aulbert <[email protected]> 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
> [email protected]
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
_______________________________________________
Nut-upsuser mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
