[Nut-upsuser] Using 'dummy.ups' for a real application, not just testing...

[Jim Klimov]

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

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

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.

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.

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.

Hope this helps,
Jim Klimov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20230220/986e3be3/attachment.htm>