<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>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>