<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><span class="gmail_default">Jim:</span></div><div class="gmail_default" style="font-size:small"><span class="gmail_default"><br></span></div><div class="gmail_default" style="font-size:small"><span class="gmail_default">>  </span>Regarding dummy-ups looping, note that NUT v2.8.0 introduced a separation of mode to</div><div class="gmail_default" style="font-size:small">>`dummy-once` (default for `*.dev` files to be slurped once) and `dummy-loop` (default for </div><div class="gmail_default" style="font-size:small">> others to be re-read, e.g. `*.seq` files or your use-case). Previously it behaved like a </div><div class="gmail_default" style="font-size:small">>`dummy->loop` for all.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Interesting...  I was using the latest doc's, but what I installed was from the released raspberry pi distro's (v2.7.4).  I did use a .dev file but it was looping.  I guess this explains it.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">One reason I hesitate to do my own build is not that I can't do it, but I prefer to use the released distro's because that way, the normal update process keeps me 'current' (well, maybe a step or-two behind).  If I have my own build, I know I will likely never touch it again and will eventually fall way behind the current versions.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">>I'd say one problem would be relative inefficiency and overheads: you have one process</div><div class="gmail_default" style="font-size:small">> talking to the device to extract data, save it into a file, another process to regularly</div><div class="gmail_default" style="font-size:small">> fopen() and read it and tell `upsd` to update its model data points. Depending on OS, file</div><div class="gmail_default" style="font-size:small">> access may be expensive (flush to write, audit, RBAC and all that) so avoiding it makes</div><div class="gmail_default" style="font-size:small">> sense, especially in a loop. Since you have dealt with the hard part - talking to a device, it</div><div class="gmail_default" style="font-size:small">> should not be easy to plug that into the skeleton driver (or another if that is a closer</div><div class="gmail_default" style="font-size:small">> match to start from) to `dstate_setinfo()` instead of preparing lines to write into a file :)<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Although I completely understand this argument, part of me feels like this 'inefficiency and overhead' is utterly trivial in this case.  We are talking about 10's of bytes, not even kilobytes, and updates are seconds, not milliseconds.  Yes, OS 'overheads' apply too, and if this were a performance limited application then I could better accept the argument.  If I felt that what I was doing would apply to a wider audience, I would be more inclined to incorporate it in a way that could perhaps contribute to the community.  My thought is that this is more of a one-of.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">-Tom</div><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 20, 2023 at 8:14 AM Jim Klimov <<a href="mailto:jimklimov%2Bnut@gmail.com">jimklimov+nut@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>>
  Do you think there could be some merit in either embellishing 
dummy-ups or deriving a new driver from it that is sanctioned as a 
'file-based' interface for NUT?

</div><div><br></div><div>I'd say one problem would be relative inefficiency and overheads: you have one process talking to the device to extract data, save it into a file, another process to regularly fopen() and read it and tell `upsd` to update its model data points. Depending on OS, file access may be expensive (flush to write, audit, RBAC and all that) so avoiding it makes sense, especially in a loop. Since you have dealt with the hard part - talking to a device, it should not be easy to plug that into the skeleton driver (or another if that is a closer match to start from) to `dstate_setinfo()` instead of preparing lines to write into a file :)</div><div><br></div><div>Regarding RAM-based FS, on one hand there is no benefit to storing these files persistently, and any persistent storage I/O just takes longer. Flash wearing is also a problem, although it may be relaxed due to caching and later flushing large writes (e.g. might happen with logs, if not every line is forcefully synced to storage). Older flash techs also had more write-cycles (by orders of magnitude) than the faster but more fragile current devices which throw smarter caching and more redundant transistors at the problem. So if your Pi's were writing logs "for years" they might just use earlier-generation SD/MMC devices that lacked finesse but were sturdier.<br></div><div><br></div><div><span class="gmail_default" style="font-size:small"></span>Regarding dummy-ups looping, note that NUT v2.8.0 introduced a separation of mode to `dummy-once` (default for `*.dev` files to be slurped once) and `dummy-loop` (default for all others to be re-read, e.g. `*.seq` files or your use-case). Previously it behaved like a `dummy-loop` for all.<br><br>The driver sleeps a hard-coded 1 second between looped file reads. Also the file contents may include a `TIMER <NUM>` line to add a delay, whether before further lines (e.g. when preparing tests - report on-battery, wait 10 sec, report on-line again) or as the last line to slow down the loop.<br><br></div><div>Hope this helps,</div><div>Jim Klimov<br></div></div>
</blockquote></div></div>