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