[Nut-upsdev] apcsmart question

[Arnaud Quette]

2011/4/25 Michal Soltys <soltys at ziu.info>

> On 11-04-19 18:26, Arnaud Quette wrote:
>
>>
>>
>> 2011/4/15 Michal Soltys <soltys at ziu.info <mailto:soltys at ziu.info>>
>>
>>
>>    (this would be handled as shutdown.return with extra params,
>>    following your suggestion)
>>
>>    The first one causes:
>>
>>    - on very old models: shutdown, return after additional 6*n minutes,
>>    unconditionally
>>
>>    - on reasonably non-ancient models: shutdown, return after
>>    additional 6*n minutes. If we're on batteries, 6*n is counted since
>>    power's return. All eeprom programmed delays are also respected
>>    (such as min. battery level and other ones)
>>
>>    The second one is a variation I dig in apcupsd sources. Supposedly
>>    there were units (buggy ? simpler ?) that required/accepted only 2
>>    digits, instead of 3.
>>
>>
>> so no need for 2 commands. 1 that supports both versions will do the job.
>> manpage doc + a useful error msg in the log (ie, when failing "nn",
>> advise to use "nnn") will help users.
>>
>>
> I was actually thinking about:
>
> shutdown.return
> shutdown.return cs
> shutdown.return <value>
>
> 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.
>
>
>
>> so for "b" and "V", everything is ok.
>>
>> but I still don't get the "v" version:
>> - is it the previous firmware version, in which case ups.firmware.old
>> would be suitable (if .aux is always filled by an auxiliary version,
>> such as with an expansion card that is used with apcsmart).
>> - or the old way to get firmware revision, on older units? In which
>> case, this still maps on ups.firmware, but with a needed code hack to
>> fallback from "b" to "v".
>>
>>
> Well, the "old" code is XYZ. X sort-of describes ups model, Y is mounting
> type (standalone, rack), Z is "international" code
>
> "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
>
> Note that B != Y, though C seems to be == Z.
>
> E.g. a newer rackmount unit I have (2200W, ca. 2005) responds:
>
> V: FWI
> b: 665.6.I
>
> Overall, the meaning is roughly the same, with "new" being a bit more
> flexible.
>
> 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.
>
> 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.
>
> 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
> ...).
>
> Re: smart protocol and firmware codes:
>
> http://homepage1.nifty.com/Que/plamo/apc-ups/manual/upsbible.html
> http://apcupsd.org/manual/manual.html#apc-smart-protocol
>
> (interpretations of firmware codes are a bit off / not up to date)
>

BTW, would you be interested in working with me on updating the NUT apcsmart
page?
http://www.networkupstools.org/ups-protocols.html

there is a dual aim:
- update the content
- integrate the new documentation (and so protocol) library, using AsciiDoc.

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...

cheers,
Arnaud
-- 
Linux / Unix Expert R&D - Eaton - http://powerquality.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20110426/e226cbbb/attachment.htm>