[Nut-upsdev] HCL HP R5000 supported by bcmxcp

[Arnaud Quette]

Hi Kjell,

please to see you're still around :-)

2012/3/29 Kjell Claesson <kjell.claesson at epost.tidanet.se>

> torsdagen den 29 mars 2012 18.38.17 skrev  Arnaud Quette:
> > Hi Peter,
> >
> > sorry for the lag in answering... crowded week.
> >
> > One thing bothers me. I don't see parameters like "battery.runtime.low"
> >
> > > here. How will the UPS notice the NUT that it is running critically
> low?
> > > Or
> > > better said, when will it do that?
> > >
> > > With APC, there is such parameter, default set to 120 seconds. As I
> > > understand, when battery goes critically low (2 minutes before getting
> > > fully discharged), it sends "battery critical" to the NUT server, and
> the
> > > NUT sends "shutdown" command to clients.
> >
> > that's it.
> >
> > However with the HP, either R5000 or R5500, there is no such parameter,
> and
> >
>
> 8<--------------snip-------------------
>
> Hi Peter,
>
> You can see this by adding this instead in the bcmxcp.c at row 1052.
> -----------------------------------------------------
> /* Low battery warning */
> value = answer[BCMXCP_EXT_LIMITS_BLOCK_LOW_BATT_WARNING];
>
>          if (value != 0) {
>                dstate_setinfo("battery.runtime.low", "%d", value);
>          }
>
> bcmxcp_status.lowbatt = value * 60;
>

well, since battery.runtime.low is in seconds and value in minutes,
bcmxcp_status.lowbatt should be used instead of value.
I've started to investigate, and we need to PW_SET_CONF_COMMAND 0xFF to
check capabilities.
For example, this feature is not available on Eaton 9130. I'll try to check
on R5000 on Monday.


> /* Check if we should warn the user that her shutdown delay is to long? */
> ----------------------------------------------------------
> But this is something that is set in the "config parameters" so it would
> not
> change. The driver is made so if you try to set the "shutdown delay"
> (This is the delay between the low battery signal to the ups would be shut
> down) longer than remaining time set in the config it would warn you.
>
> So as long this is not configurable, it is no meaning to show it.
>

there is still a point in exposing this, as other info.
it's simply that not being able to modify it heavily lowers its interest.

And if Arnaud like it, it could be entered into the driver. I have
> hade no time to work on the driver and don't have the latest trunk checked
> out as developer at the moment.
>

I've been thinking about bcmxcp recently, and now think that a partial
rewrite is needed.

my idea is to simplify code, make it more generic and remove redundancies.
we should use definition structures for XCP blocks, and create generic
iterators.
this is a variation of the mechanisms found in usbhid-ups, snmp-ups and
blazer for example.
that would also make completion an easy task.

would you get back on board to work with me on a eaton-xcp driver?

cheers,
Arnaud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20120331/db31b618/attachment.html>