<br><br><div class="gmail_quote">2011/4/25 Michal Soltys <span dir="ltr"><<a href="mailto:soltys@ziu.info">soltys@ziu.info</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
On 11-04-19 18:26, Arnaud Quette wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
<br>
2011/4/15 Michal Soltys <<a href="mailto:soltys@ziu.info" target="_blank">soltys@ziu.info</a> <mailto:<a href="mailto:soltys@ziu.info" target="_blank">soltys@ziu.info</a>>><div class="im"><br>
<br>
  (this would be handled as shutdown.return with extra params,<br>
  following your suggestion)<br>
<br>
  The first one causes:<br>
<br>
  - on very old models: shutdown, return after additional 6*n minutes,<br>
  unconditionally<br>
<br>
  - on reasonably non-ancient models: shutdown, return after<br>
  additional 6*n minutes. If we're on batteries, 6*n is counted since<br>
  power's return. All eeprom programmed delays are also respected<br>
  (such as min. battery level and other ones)<br>
<br>
  The second one is a variation I dig in apcupsd sources. Supposedly<br>
  there were units (buggy ? simpler ?) that required/accepted only 2<br>
  digits, instead of 3.<br>
<br>
<br>
so no need for 2 commands. 1 that supports both versions will do the job.<br>
manpage doc + a useful error msg in the log (ie, when failing "nn",<br>
advise to use "nnn") will help users.<br>
<br>
</div></blockquote>
<br>
I was actually thinking about:<br>
<br>
shutdown.return<br>
shutdown.return cs<br>
shutdown.return <value><br>
<br>
Where value is a number. If it consists of exactly two digits - "hackish" version will be attempted, otherwise standard command with 3 digits will be attempted. Automatic fallback could be added as well, if desirable - though it's prooly better to just inform user to try the standard version.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
so for "b" and "V", everything is ok.<br>
<br>
but I still don't get the "v" version:<br>
- is it the previous firmware version, in which case ups.firmware.old<br>
would be suitable (if .aux is always filled by an auxiliary version,<br>
such as with an expansion card that is used with apcsmart).<br>
- or the old way to get firmware revision, on older units? In which<br>
case, this still maps on ups.firmware, but with a needed code hack to<br>
fallback from "b" to "v".<br>
<br>
</blockquote>
<br></div>
Well, the "old" code is XYZ. X sort-of describes ups model, Y is mounting type (standalone, rack), Z is "international" code<br>
<br>
"new" firmware code is A{1,n}.B.C - with similar meaning as above - A{1,n} denotes sort-of ups model + smart protocol level + maybe something else ?, B is mounting type, C is "international" code<br>
<br>
Note that B != Y, though C seems to be == Z.<br>
<br>
E.g. a newer rackmount unit I have (2200W, ca. 2005) responds:<br>
<br>
V: FWI<br>
b: 665.6.I<br>
<br>
Overall, the meaning is roughly the same, with "new" being a bit more flexible.<br>
<br>
It's not really firmware version either, but it's been like that mapped in apcsmart driver since always (I think), so probably no reason to suddenly change it (and even if, to what kind of variable(s) - some sort of "internal ups model" ?). Meaning of both variables is a pure guess-work either way.<br>
<br>
Some old units respond to both 'V' and 'b', but the latter might not be a valid "firmware" version. I haven't heard about newer units that would support 'b' but not support 'V' at the same time.<br>
<br>
Can't really say anything more, than generic info about smart protocol available online. APC never bothered relasing any official info, afaik, and they now repeat the same silly approach with "microlink" protocol. Though FWIW, they seem to be slowly getting the idea it's perhaps not the best thing to do ... (they released expansion card not so long ago, that can talk real smart protocol on new "smart" models, though for pretty expensive units, one have now to pay extra for the card + waste an expansion slot ...).<br>
<br>
Re: smart protocol and firmware codes:<br>
<br>
<a href="http://homepage1.nifty.com/Que/plamo/apc-ups/manual/upsbible.html" target="_blank">http://homepage1.nifty.com/Que/plamo/apc-ups/manual/upsbible.html</a><br>
<a href="http://apcupsd.org/manual/manual.html#apc-smart-protocol" target="_blank">http://apcupsd.org/manual/manual.html#apc-smart-protocol</a><br>
<br>
(interpretations of firmware codes are a bit off / not up to date)<br>
</blockquote></div><br>BTW, would you be interested in working with me on updating the NUT apcsmart page?<br><a href="http://www.networkupstools.org/ups-protocols.html">http://www.networkupstools.org/ups-protocols.html</a><br>
<br>there is a dual aim:<br>- update the content<br>- integrate the new documentation (and so protocol) library, using AsciiDoc.<br><br>Since a full revamp to AsciiDoc may be too much for a first step, we can simply rip the html page itself (ie, without the menu) and integrate it as an html code snipped...<br>
<br>cheers,<br>Arnaud<br>-- <br>Linux / Unix Expert R&D - Eaton - <a href="http://powerquality.eaton.com" target="_blank">http://powerquality.eaton.com</a><br>Network UPS Tools (NUT) Project Leader - <a href="http://www.networkupstools.org/" target="_blank">http://www.networkupstools.org/</a><br>
Debian Developer - <a href="http://www.debian.org" target="_blank">http://www.debian.org</a><br>Free Software Developer - <a href="http://arnaud.quette.free.fr/" target="_blank">http://arnaud.quette.free.fr/</a><br><br>