Nut upsdev - Dec 2024 - Discussion about legalizing some `ups.status` tokens

Hello all,

  I've raised an issue https://github.com/networkupstools/nut/issues/2708
to discuss a subject that I'll just summarise below:

The "Status data" section in docs/new-drivers.txt defines certain
keywords
that are "Possible values for status_set", stressing that
"Anything else
will not be recognized by the usual clients. Coordinate with the nut-upsdev
list before creating something new, since there will be duplication and
ugliness otherwise."

In fact we do have a number of other values in code (example in GitHub
issue).

Gotta decide what to do with the currently unknown names - can rename some
cases, but what about others? Legalise them into the docs chapter, and add
handling in C++ bindings, augeas, clients, etc.?

Perhaps more importantly: would such legalisation of keywords acceptable in
ups.status constitute a bump of NUT protocol/API for formal versioning
(e.g. that clients conforming to protocol N are expected to handle tokens
X,Y,Z)?

Note this concerns not only "rogue" names used by some one driver, but
also
"ALARM" and "ECO" that were elaborately added across most of
the practical
codebase in recent (post NUT v2.8.2) development.

Thanks in advance for feedback,
Jim Klimov
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20241203/5e79f59b/attachment.htm>

As a client developer, I do wish a lot of the important values & variable
names were standardized and made available in the developer docs. I was unaware
of the docs/new-drivers.txt file so I'll give that a look.

I've been dealing with quite a few edge cases of OEMs taking creative
liberties with their server and driver distributions. Synology is a common
offender with undocumented behavior in their NUT server, the ECO status popped
up too as mentioned, and there's also handling several different load
calculations from the UPS drivers, to name a few of my experiences so far.

I understand that not all OEMs can be expected to implement every possible point
of measurement and functionality in their hardware/software, but if we can start
to move towards some basic standards (and have this thoroughly documented),
I'd be a happy camper.

Thanks for gathering our feedback Jim, I hope this was helpful in some way. Let
me know if you want this crossposted to the issue on GH.

Glen
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20241203/ff0f3b3a/attachment.htm>