<div dir="ltr"><div>Hello all,</div><div><br></div><div>  I've raised an issue <a href="https://github.com/networkupstools/nut/issues/2708">https://github.com/networkupstools/nut/issues/2708</a> to discuss a subject that I'll just summarise below:</div><div><br></div><div>
<p dir="auto">The "Status data" section in <code class="gmail-notranslate">docs/new-drivers.txt</code>
 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."</p>
<p dir="auto">In fact we do have a number of other values in code (example in GitHub issue).</p><p dir="auto">
</p><p dir="auto">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.?

</p>
<p dir="auto">Perhaps more importantly: would such legalisation of keywords acceptable in <code class="gmail-notranslate">ups.status</code> 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)?</p><p dir="auto">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.<br></p><p>Thanks in advance for feedback,<br>Jim Klimov<br></p>



</div></div>