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

[Greg Troxel]

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.