[Nut-upsdev] apcsmart question

[Arnaud Quette]

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

> W dniu 14.04.2011 23:49, Arnaud Quette pisze:
>
>
>> I would more be in favor of finally using the extra param of
>> instcmd(const char *cmdname, const char *extra)
>> and mapping these commands onto existing ones. Specific parameters would
>> then be described in manpages.
>>
>>
> I'm all for this approach. Should just work, from what I've seen, without
> any need for custom command trickery.


indeed.


>
>     apcsmart.shutdown.grace (@nnn)
>>    apcsmart.shutdown.grace.h (@nn)
>>
>>
> (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.


    apcsmart.firmware.old (V)
>>
>>
>> I'm not sure to see how useful it is. Are they really storing the
>> previous FW version?
>> and what is the use case?
>> is your unit filling ups.firmware + .aux + .old?
>> if it's the case, ups.firmware.old has to be added.
>> otherwise, I'm not sure ups.firmware.aux would be a good option!
>>
>>
> I'd just switch to ups.firmware with extra parameters, similary to the
> above. From command perspective, it's just for user convenience to call it
> and get the info. Internally they are used for detection of UPSes, that
> cannot return command set. 'V' is called before 'b', as I have an unit that
> returns both, but garbage in 'b' (and also garbage in 'a' ...)
>
> Current state:
>
> b (mapped to ups.firmware) is "new" firmware revision
> v (mapped to ups.firmware.aux) is "Measure-UPS firmware". From quick google
> it seems to be one of the expansion card's firmware. Though not 100% sure.
> Likely the reason why it was mapped to .aux
> V is "old" firmware revision, which has always been in use internally, but
> not exposed as instcmd.
>
> Proposed state:
>
> b: ups.firmware
> V: ups.firmware old
> v: either ups.firmware measure, or current ups.firmware.aux, or even better
> - ups.firmware.aux measure (with fallback to 'v', if extra string is not
> specified)
>

you misunderstood me: ups.firmware.* are not commands, but variables!
which means there is no extra param, only sub collections.

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

as per your above explanation, it should be the former (previous firmware
version).
so, if you see any possibility to have both .aux and .old, it makes sense to
propose .old addition
otherwise, putting that data in .aux makes sense too. possibly adding an
"old" or "previous" tag somewhere around this data (ie: "ups.firmware.aux:
X.Y.Z (previous FW)")

cheers,
Arno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20110419/6595b0a3/attachment.htm>