Nut upsdev - Feb 2025 - Should NUT have a way to optionally report last-update timestamps (or equivalent deemed safe)?

Hello all,

 During an issue discussion I began wondering why we don't report any sort
of last-update timestamp that consumers could read and decide whether to
process the rest of info, for example (similar to HTTP-304). Then I thought
it might be unsafe to expose a server timestamp, or service uptime,
generally nowadays (especially with NUT read-only access being anonymous) -
so it should be hidden by default and only users who want/need the data can
enable their drivers to report it (troubleshooting, development, secure
LAN...) - and then there's more specific info we could show, like the age
of each reading individually.

  One of the hardest IT problems then rears its head - namely Naming :)

  I posted some ideas I've had about this at
https://github.com/networkupstools/nut/issues/2810 and invite you to share
your thoughts here or there.

WDYT?
Jim Klimov
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20250223/42d86536/attachment.htm>

My quick reaction is that this is a lot of complexity and we should
first be clear on the problem.

BLUF: I propose that "is this data valid, ie is the UPS reporting data,
vs has it stopped" would solve 99.9% of uses, and that we should demand
written designs for reasonable uses beyond that in order to justify
anything more.

I see "are the nut daemons running" as sysadmin monitoring to be dealt
with the same way every other daemon is, and thus not to be worried
about.  (If they crash, we should fix that, but that's separate.)

The point of monitoring a UPS is to have fresh data.  If you let someone
see the data, I don't see the harm in letting them see that it's not
fresh, since that's something that should not happen.  System uptime is
perhaps another matter, but that's not relevant to "is this data
ok".

I don't see any real value in a 304 not modified so callers can decide
to skip processing.  This just isn't that complicated.  And not modified
is since when, and how do we know?  I do processing like this in a
client, but it's "send a report if something interesting changed, or if
it's been a minute since the last report".  For that, I just want
"give
me a dictionary of values".


I think it is important to know if the data is stale.  But so far, I
only need this coarsely.  Consider a UPS that updates once every 2s.  I
am ok with just getting the most recent reading, but if it's been 60s
(or whatever nut's threshold is for comms failure), I'm fine with the
data being withdrawn.    Or perhaps a data_valid: key normally true that
goes to false.

I really can't see it being reasonable to want timestamps per reading
for readings that come at 5s vs 1s.  I guess if somebody wants that we
can talk about it, but I'd like to see a written design for how it will
be used and why that is reasonable.  I increasingly find software too
complicated as we have years of adding things, so I tend to not want
mechanisms unless there's a good reason and then I want the mechanism to
be simple/minimal to increase the changes.

All that said, I could see a "data_updated: [unix-epoch]" which is
basically the last time we heard data from the device.  But I would want
to see if adding a validity binary sensor is good enough.