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. _______________________________________________ Nut-upsdev mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
