Hi Kjell,<br><br>please to see you're still around :-)<br><br><div class="gmail_quote">2012/3/29 Kjell Claesson <span dir="ltr"><<a href="mailto:kjell.claesson@epost.tidanet.se">kjell.claesson@epost.tidanet.se</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">torsdagen den 29 mars <a href="tel:2012%2018.38.17" value="+12012183817">2012 18.38.17</a> skrev  Arnaud Quette:<br>
<div class="im">> Hi Peter,<br>
><br>
> sorry for the lag in answering... crowded week.<br>
><br>
> One thing bothers me. I don't see parameters like "battery.runtime.low"<br>
><br>
> > here. How will the UPS notice the NUT that it is running critically low?<br>
> > Or<br>
> > better said, when will it do that?<br>
> ><br>
> > With APC, there is such parameter, default set to 120 seconds. As I<br>
> > understand, when battery goes critically low (2 minutes before getting<br>
> > fully discharged), it sends "battery critical" to the NUT server, and the<br>
> > NUT sends "shutdown" command to clients.<br>
><br>
> that's it.<br>
><br>
> However with the HP, either R5000 or R5500, there is no such parameter, and<br>
><br>
<br>
</div>8<--------------snip-------------------<br>
<br>
Hi Peter,<br>
<br>
You can see this by adding this instead in the bcmxcp.c at row 1052.<br>
-----------------------------------------------------<br>
/* Low battery warning */<br>
value = answer[BCMXCP_EXT_LIMITS_BLOCK_LOW_BATT_WARNING];<br>
<br>
          if (value != 0) {<br>
                dstate_setinfo("battery.runtime.low", "%d", value);<br>
          }<br>
<br>
bcmxcp_status.lowbatt = value * 60;<br></blockquote><div><br>well, since battery.runtime.low is in seconds and value in minutes, bcmxcp_status.lowbatt should be used instead of value.<br>I've started to investigate, and we need to PW_SET_CONF_COMMAND 0xFF to check capabilities.<br>
For example, this feature is not available on Eaton 9130. I'll try to check on R5000 on Monday.<br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

/* Check if we should warn the user that her shutdown delay is to long? */<br>
----------------------------------------------------------<br>
But this is something that is set in the "config parameters" so it would not<br>
change. The driver is made so if you try to set the "shutdown delay"<br>
(This is the delay between the low battery signal to the ups would be shut<br>
down) longer than remaining time set in the config it would warn you.<br>
<br>
So as long this is not configurable, it is no meaning to show it.<br></blockquote><div><br>there is still a point in exposing this, as other info.<br>it's simply that not being able to modify it heavily lowers its interest. <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">
And if Arnaud like it, it could be entered into the driver. I have<br>
hade no time to work on the driver and don't have the latest trunk checked<br>
out as developer at the moment.<br></blockquote><div><br>I've been thinking about bcmxcp recently, and now think that a partial rewrite is needed.<br><br>my idea is to simplify code, make it more generic and remove redundancies.<br>
we should use definition structures for XCP blocks, and create generic iterators.<br>this is a variation of the mechanisms found in usbhid-ups, snmp-ups and blazer for example.<br>that would also make completion an easy task.<br>
<br>would you get back on board to work with me on a eaton-xcp driver?<br></div></div><br>cheers,<br>Arnaud<br><br>