<html xmlns="http://www.w3.org/1999/xhtml" xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office"><head><!--[if gte mso 9]><xml><o:OfficeDocumentSettings><o:AllowPNG/><o:PixelsPerInch>96</o:PixelsPerInch></o:OfficeDocumentSettings></xml><![endif]--></head><body>
Hi Jim,<div><br></div><div>I would have used either ‘set’ or ‘push’ instead of initialize.</div><div><br></div><div><br></div><div>Best Regards,</div><div>Strahil Nikolov <br><br><p class="yahoo-quoted-begin" style="font-size: 15px; color: #715FFA; padding-top: 15px; margin-top: 0">On Wednesday, August 16, 2023, 8:37 PM, Jim Klimov via Nut-upsdev <nut-upsdev@alioth-lists.debian.net> wrote:</p><blockquote class="iosymail"><div id="yiv2551703118"><div dir="ltr"><div>Hello all,</div><div><br></div><div> Recently there were a few issue discussions the crux of which was that when</div><div>some UPS values are overridden e.g. by `override.battery.charge.low=40` then</div><div>the driver knows this value (and in case of "override.*" vs "default.*" has it "bolted"</div><div>even if the device reports something else), but there is no value-setting actually</div><div>propagated to a device (so a capable UPS HW/FW would raise the LB alarm</div><div>at that charge level). Setting the value explicitly with `upsrw` as part of driver</div><div>service unit startup (for devices which support setting that, but do not remember</div><div>it across power-cycles) helped in the discussed cases.<br></div><div><br></div><div> My proposal is to introduce another prefix for such values where the driver</div><div>would actively push them to the device during daemon start-up. So far I came</div><div>up with a couple of ideas, e.g.:</div><div>* `initialize.battery.charge.low` - push the setting to device (if possible) and then<br></div><div> act as `default.battery.charge.low` so if the device HW/FW does not actually</div><div>
support that toggle, the driver knows the value from config; and if it does - the</div><div> driver knows it from an actual
reading.</div><div>
* `initialize.(default|override).battery.charge.low` - like above, but explicitly say</div><div> how the value is treated next (e.g. `override` like before makes sense for broken</div><div> firmware). One downside is that such spelling is longer and more cumbersome,</div><div> but on the upside - explicit and less open to surprises.<br></div><div><br></div><div>So far this was just an idea in the back of my head, no code written - so a good</div><div>moment to discuss: whether there is merit to this? Is `initialize` a proper keyword</div><div>for the idea? Which of the two ideas above, or some alternate one, is better?</div><div>What is the best bike-shed color? Would anyone step up to code this? (Should</div><div>be a dozen lines I think, plus docs).</div><div><br></div><div>Jim Klimov</div><div><br></div><div> </div></div>
</div>_______________________________________________<br>Nut-upsdev mailing list<br><a ymailto="mailto:Nut-upsdev@alioth-lists.debian.net" href="mailto:Nut-upsdev@alioth-lists.debian.net">Nut-upsdev@alioth-lists.debian.net</a><br><a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev</a><br><blockquote></blockquote></blockquote></div>
</body></html>