Hmm, looking at status_commit(), if the UPS actually reported just “OB", but the “ignorelb” logic kicked in, wouldn’t status_commit() change it to “OB LB”? And would clients interpret that correctly?
And, assuming status_commit() is called, is the status so saved what’s returned on a future client query? I’m really unsure how all of this works. I don’t suppose there’s some kind of “general flow of information” documentation somewhere? > On May 24, 2023, at 4:26 AM, Carsten Aulbert <[email protected]> > wrote: > > Hi again, > > On 5/22/23 18:31, Willcox David via Nut-upsuser wrote: >> Hmm. Is there maybe something there already that will do this? Maybe kind of >> back-handed. >> In drivers/dstate.c, I see: >> 1. In status_init(), if “driver.flag.ignorelb” is set in the driver >> state, the “ignorelb” flag is set. >> 2. 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. >> 3. 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. > > this looks exactly like the right place and functionality I would like to > have, BUT >> Am I missing something? > > yes, probably the same trap I fell into, status_commit does not seem to be > not called (at least from the dummy driver I use for testing) upon changing > charge/runtime. I can only force a call by flipping OL/OB. > > I sprinkled a bit of debug information [1] into status_commit and journald > looks like > > initial upsrw call to set dummy OL: > > May 24 08:23:24 gateway dummy-ups[284580]: [D2] entering setvar(ups.status, > OL) > May 24 08:23:24 gateway dummy-ups[284580]: [D2] status_commit: Entering (1) > May 24 08:23:24 gateway dummy-ups[284580]: [D2] status_commit: charge val/low > 33/30'] > May 24 08:23:24 gateway dummy-ups[284580]: [D2] status_commit: runtime > val/low 200/180'] > May 24 08:23:27 gateway dummy-ups[284580]: [D1] upsdrv_updateinfo... > > setting it OB > > May 24 08:23:38 gateway dummy-ups[284580]: [D2] entering setvar(ups.status, > OB) > May 24 08:23:38 gateway dummy-ups[284580]: [D2] status_commit: Entering (1) > May 24 08:23:38 gateway dummy-ups[284580]: [D2] status_commit: charge val/low > 33/30'] > May 24 08:23:38 gateway dummy-ups[284580]: [D2] status_commit: runtime > val/low 200/180'] > May 24 08:23:42 gateway dummy-ups[284580]: [D1] upsdrv_updateinfo... > > changing run-time > > May 24 08:23:48 gateway dummy-ups[284580]: [D2] upsdrv_updateinfo: NO-OP: > input file was already read once to the end > May 24 08:23:49 gateway dummy-ups[284580]: [D2] entering > setvar(battery.runtime, 100) > May 24 08:23:52 gateway dummy-ups[284580]: [D1] upsdrv_updateinfo... > > later changing charge > > May 24 08:37:28 gateway dummy-ups[284580]: [D2] send_to_one: sending PONG > May 24 08:37:32 gateway dummy-ups[284580]: [D1] upsdrv_updateinfo... > May 24 08:37:33 gateway dummy-ups[284580]: [D2] upsdrv_updateinfo: NO-OP: > input file was already read once to the end > May 24 08:37:33 gateway dummy-ups[284580]: [D2] entering > setvar(battery.charge, 5) > May 24 08:37:37 gateway dummy-ups[284580]: [D1] upsdrv_updateinfo... > May 24 08:37:38 gateway dummy-ups[284580]: [D2] upsdrv_updateinfo: NO-OP: > input file was already read once to the end > > and still no LB. > > But going back "OL", suddenly LB is added: > > May 24 09:21:48 gateway dummy-ups[284580]: [D2] entering setvar(ups.status, > OL) > May 24 09:21:48 gateway dummy-ups[284580]: [D2] status_commit: Entering (1) > May 24 09:21:48 gateway dummy-ups[284580]: [D2] status_commit: charge val/low > 5/30'] > May 24 09:21:48 gateway dummy-ups[284580]: [D2] status_commit: appending LB > flag [charge '5' below '30'] > > Thus it seems somewhere in the state logic there ought to be a possibility to > trigger this automatically (on changing charge/runtime while OB) but there is > not. > > Hopefully, someone with more knowledge than I have can chime in here :) > > Cheers > > Carsten > > [1] Please don't judge me by this, I still use printf and friends a lot for > debugging (sorry for breaking lines, it's just for illustration): > > @@ -1113,12 +1116,13 @@ > /* write the status_buf into the externally visible dstate storage */ > void status_commit(void) > { > + upsdebugx(2, "%s: Entering (%d)", __func__, ignorelb); > while (ignorelb) { > const char *val, *low; > > val = dstate_getinfo("battery.charge"); > low = dstate_getinfo("battery.charge.low"); > - > + upsdebugx(2, "%s: charge val/low %s/%s']", __func__, val, > low); > if (val && low && (strtol(val, NULL, 10) < strtol(low, NULL, > 10))) { > snprintfcat(status_buf, sizeof(status_buf), " LB"); > upsdebugx(2, "%s: appending LB flag [charge '%s' below > '%s']", __func__, val, low); > @@ -1127,6 +1131,7 @@ > > val = dstate_getinfo("battery.runtime"); > low = dstate_getinfo("battery.runtime.low"); > + upsdebugx(2, "%s: runtime val/low %s/%s']", __func__, val, > low); > > if (val && low && (strtol(val, NULL, 10) < strtol(low, NULL, > 10))) { > snprintfcat(status_buf, sizeof(status_buf), " LB"); > > > > -- > Dr. Carsten Aulbert, Max Planck Institute for Gravitational Physics, > Callinstraße 38, 30167 Hannover, Germany, Phone +49 511 762 17185 > _______________________________________________ > 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
