<br><br><div class="gmail_quote">2011/4/15 Michal Soltys <span dir="ltr">&lt;<a href="mailto:soltys@ziu.info" target="_blank">soltys@ziu.info</a>&gt;</span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

W dniu 14.04.2011 23:49, Arnaud Quette pisze:<div><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
I would more be in favor of finally using the extra param of<br>
instcmd(const char *cmdname, const char *extra)<br>
and mapping these commands onto existing ones. Specific parameters would<br>
then be described in manpages.<br>
<br>
</blockquote>
<br></div>
I&#39;m all for this approach. Should just work, from what I&#39;ve seen, without any need for custom command trickery.</blockquote><div><br>indeed.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<div>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
    apcsmart.shutdown.grace (@nnn)<br>
    apcsmart.shutdown.grace.h (@nn)<br>
<br>
</blockquote>
<br></div>
(this would be handled as shutdown.return with extra params, following your suggestion)<br>
<br>
The first one causes:<br>
<br>
- on very old models: shutdown, return after additional 6*n minutes, unconditionally<br>
<br>
- on reasonably non-ancient models: shutdown, return after additional 6*n minutes. If we&#39;re on batteries, 6*n is counted since power&#39;s return. All eeprom programmed delays are also respected (such as min. battery level and other ones)<br>


<br>
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.</blockquote><div><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 &quot;nn&quot;, advise to use &quot;nnn&quot;) will help users.<br><br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<div>

<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

    apcsmart.firmware.old (V)<br>
<br>
<br>
I&#39;m not sure to see how useful it is. Are they really storing the<br>
previous FW version?<br>
and what is the use case?<br>
is your unit filling ups.firmware + .aux + .old?<br>
if it&#39;s the case, ups.firmware.old has to be added.<br>
otherwise, I&#39;m not sure ups.firmware.aux would be a good option!<br>
<br>
</blockquote>
<br></div>
I&#39;d just switch to ups.firmware with extra parameters, similary to the above. From command perspective, it&#39;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. &#39;V&#39; is called before &#39;b&#39;, as I have an unit that returns both, but garbage in &#39;b&#39; (and also garbage in &#39;a&#39; ...)<br>


<br>
Current state:<br>
<br>
b (mapped to ups.firmware) is &quot;new&quot; firmware revision<br>
v (mapped to ups.firmware.aux) is &quot;Measure-UPS firmware&quot;. From quick google it seems to be one of the expansion card&#39;s firmware. Though not 100% sure. Likely the reason why it was mapped to .aux<br>
V is &quot;old&quot; firmware revision, which has always been in use internally, but not exposed as instcmd.<br>
<br>
Proposed state:<br>
<br>
b: ups.firmware<br>
V: ups.firmware old<br>
v: either ups.firmware measure, or current ups.firmware.aux, or even better - ups.firmware.aux measure (with fallback to &#39;v&#39;, if extra string is not specified)<br>
</blockquote></div><br>you misunderstood me: ups.firmware.* are not commands, but variables!<br>which means there is no extra param, only sub collections.<br><br>so for &quot;b&quot; and &quot;V&quot;, everything is ok.<br>
<br>but I still don&#39;t get the &quot;v&quot; version:<br>- 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).<br>
- 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 &quot;b&quot; to &quot;v&quot;.<br><br>as per your above explanation, it should be the former (previous firmware version).<br>
so, if you see any possibility to have both .aux and .old, it makes sense to propose .old addition<br>otherwise, putting that data in .aux makes sense too. possibly adding an &quot;old&quot; or &quot;previous&quot; tag somewhere around this data (ie: &quot;ups.firmware.aux: X.Y.Z (previous FW)&quot;)<br>
<br>cheers,<br>Arno<br><br>