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

[Strahil Nikolov]

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>