Nut upsdev - Aug 2023 - Proposal: Add an "initialize.*" prefix to `ups.conf` device settings

Hello all,

  Recently there were a few issue discussions the crux of which was that
when
some UPS values are overridden e.g. by `override.battery.charge.low=40` then
the driver knows this value (and in case of "override.*" vs
"default.*" has
it "bolted"
even if the device reports something else), but there is no value-setting
actually
propagated to a device (so a capable UPS HW/FW would raise the LB alarm
at that charge level). Setting the value explicitly with `upsrw` as part of
driver
service unit startup (for devices which support setting that, but do not
remember
it across power-cycles) helped in the discussed cases.

  My proposal is to introduce another prefix for such values where the
driver
would actively push them to the device during daemon start-up. So far I came
up with a couple of ideas, e.g.:
* `initialize.battery.charge.low` - push the setting to device (if
possible) and then
  act as `default.battery.charge.low` so if the device HW/FW does not
actually
  support that toggle, the driver knows the value from config; and if it
does - the
  driver knows it from an actual reading.
* `initialize.(default|override).battery.charge.low` - like above, but
explicitly say
  how the value is treated next (e.g. `override` like before makes sense
for broken
  firmware). One downside is that such spelling is longer and more
cumbersome,
  but on the upside - explicit and less open to surprises.

So far this was just an idea in the back of my head, no code written - so a
good
moment to discuss: whether there is merit to this? Is `initialize` a proper
keyword
for the idea? Which of the two ideas above, or some alternate one, is
better?
What is the best bike-shed color? Would anyone step up to code this? (Should
be a dozen lines I think, plus docs).

Jim Klimov
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20230816/c0651ea2/attachment.htm>

Hi Jim,
I would have used either??set? or ?push? instead of initialize.

Best Regards,Strahil Nikolov?


On Wednesday, August 16, 2023, 8:37 PM, Jim Klimov via Nut-upsdev <nut-upsdev
at alioth-lists.debian.net> wrote:

Hello all,
? Recently there were a few issue discussions the crux of which was that
whensome UPS values are overridden e.g. by `override.battery.charge.low=40`
thenthe driver knows this value (and in case of "override.*" vs
"default.*" has it "bolted"even if the device reports
something else), but there is no value-setting actuallypropagated to a device
(so a capable UPS HW/FW would raise the LB alarmat that charge level). Setting
the value explicitly with `upsrw` as part of driverservice unit startup (for
devices which support setting that, but do not rememberit across power-cycles)
helped in the discussed cases.

? My proposal is to introduce another prefix for such values where the
driverwould actively push them to the device during daemon start-up. So far I
cameup with a couple of ideas, e.g.:* `initialize.battery.charge.low` - push the
setting to device (if possible) and then
? act as `default.battery.charge.low` so if the device HW/FW does not actually?
support that toggle, the driver knows the value from config; and if it does -
the? driver knows it from an actualreading.*
`initialize.(default|override).battery.charge.low` - like above, but explicitly
say? how the value is treated next (e.g. `override` like before makes sense for
broken? firmware). One downside is that such spelling is longer and more
cumbersome,? but on the upside - explicit and less open to surprises.

So far this was just an idea in the back of my head, no code written - so a
goodmoment to discuss: whether there is merit to this? Is `initialize` a proper
keywordfor the idea? Which of the two ideas above, or some alternate one, is
better?What is the best bike-shed color? Would anyone step up to code this?
(Shouldbe a dozen lines I think, plus docs).
Jim Klimov
?_______________________________________________
Nut-upsdev mailing list
Nut-upsdev at alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20230816/f55efda3/attachment.htm>

I guess the big question is whether variables are under the control of
driver or config or both, and how do we know.  It seems best to step
back and assess the semantics and assumptions about what is written
when.  Maybe drivers should just write to hw when  variable is written.
Or maybe we already have a "read only by system and driver is in
charge"
norm.

I realize this is in some way a clueless answer, but I think we need to
have a clear architecture first and then the answer will fall out
easily.