[Nut-upsdev] HCL HP R5000 supported by bcmxcp

[Peter Tuhársky]

Hi, I'd like to inform You that this UPS communicates well via the
serial port. I haven't tested USB, and no shutdown testing so far,
however, I hope it will run well.


HP R5000
upsc output:

ambient.temperature: 27.4
ambient.temperature.high: 45
battery.charge: 99.0
battery.runtime: 536
battery.voltage: 236.3
device.mfr: Eaton
device.model: HP R5000 5000i
device.serial: 3C81520083
device.type: ups
driver.name: bcmxcp
driver.parameter.baud_rate: 9600
driver.parameter.pollinterval: 2
driver.parameter.port: /dev/ttyS0
driver.version: 2.4.3
driver.version.internal: 0.23
input.current: 18.1
input.frequency: 50.0
input.frequency.high: 54
input.frequency.low: 46
input.frequency.nominal: 50
input.transfer.boost.high: 202
input.transfer.high: 288
input.transfer.low: 176
input.transfer.trim.low: 257
input.voltage: 224.1
input.voltage.nominal: 230
outlet.1.delay.shutdown: -1
outlet.1.delay.start: 0
outlet.1.id: 1
outlet.1.status: On
outlet.2.delay.shutdown: 258
outlet.2.delay.start: -1
outlet.2.id: 0
outlet.2.status: Off
output.current: 16.4
output.current.nominal: 21.7
output.frequency: 50.0
output.phases: 1
output.voltage: 222.2
output.voltage.nominal: 230
ups.beeper.status: muted
ups.firmware: Cont:01.02 Inve:01.02
ups.load: 73.1
ups.mfr: Eaton
ups.model: HP R5000 5000i
ups.power: 3655.0
ups.power.nominal: 5000
ups.serial: 3C81520083
ups.status: OL

upscmd output:
Instant commands supported on UPS [hpblade]:

outlet.1.shutdown.return - Description unavailable
outlet.2.shutdown.return - Description unavailable
shutdown.return - Turn off the load and return when power is back
shutdown.stayoff - Turn off the load and remain off
test.battery.start - Start a battery test

shutdown sequence testing results:
No testing so far. Should any take place, I'll let You know.

Quick Specs:
http://h18004.www1.hp.com/products/quickspecs/14109_na/14109_na.pdf


Sincerely
Peter

[Arnaud Quette]

Hi Peter,

Hi, I'd like to inform You that this UPS communicates well via the serial
port. I haven't tested USB, and no shutdown testing so far, however, I hope
it will run well.

thanks for your report.

interestingly, I've been (and am still) working on HP support recently
and have a few patches stagging on this topic.
so expect some more information soon.

FYI, USB support for this unit comes through usbhid-ups (and not bcmxcp_usb).

cheers,
Arnaud

[Peter Tuhársky]

Hi, Arnaud

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.

However with the HP, either R5000 or R5500, there is no such parameter,
and I even didn't find it in web interface settings. There is quite
opposite setting possible (custom): how many seconds AFTER the UPS goes
battery, should it switch off. This is quite illogical, though.

So, I'm afraid a bit doing UPS fullscale test because I don't know,
whether servers will have enough time to shutdown before UPS switches
itself off. I know I will face it in future, however need more info now.

Peter

Post by Arnaud Quette
Hi Peter,

Hi, I'd like to inform You that this UPS communicates well via the serial
port. I haven't tested USB, and no shutdown testing so far, however, I hope
it will run well.

thanks for your report.
interestingly, I've been (and am still) working on HP support recently
and have a few patches stagging on this topic.
so expect some more information soon.
FYI, USB support for this unit comes through usbhid-ups (and not bcmxcp_usb).
cheers,
Arnaud

[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

I even didn't find it in web interface settings. There is quite opposite
setting possible (custom): how many seconds AFTER the UPS goes battery,
should it switch off. This is quite illogical, though.

a fallback option is to use upssched:
http://www.networkupstools.org/docs/user-manual.chunked/ar01s07.html#_the_advanced_approach_using_upssched

If you, for example, have 10 mn of runtime, and need 2 mn to shutdown the
system, then you would declare a (max) 8 mn timer when switching on battery.

So, I'm afraid a bit doing UPS fullscale test because I don't know, whether

servers will have enough time to shutdown before UPS switches itself off. I
know I will face it in future, however need more info now.

your remarks are valid!
I entered the round lately on this driver, following Eaton acquisition of
MGE OPS.
The thing is that, since that time, the various redundant Eaton protocols
coming from Eaton or MGE (Ie serial XCP Vs SHUT, USB XCP Vs USB/HID, ...)
have seen some decision: XCP has been superseded by SHUT and HID.
My main focus has so gone to these, though I've also been putting some
efforts to improve the XCP driver.

So, mge-shut and usbhid-ups (Eaton and derivative products) provide support
for lot more data and features.
battery.runtime.low is for example supported.
And R5000 is supported by usbhid-ups through the USB port.

Otherwise, there are still planned improvement for XCP (and a lot around
configuration).
The best would be a driver rewrite, but I've currently not enough resources
to staff one on this.
But I think I've identified what should be mapped battery.runtime.low.
So I you really want to go the XCP way, let me know and I'll check what I
can do.
One thing that may help is to tell HP that you want a better NUT support...

I hope this will shed some light on this, and provide you at least a
suitable solution.

cheers,
Arnaud

[Kjell Claesson]

Post by 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;

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

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.

Regards
Kjell

[Arnaud Quette]

Hi Kjell,

please to see you're still around :-)

Post by Kjell Claesson

Post by 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"

Post by Peter Tuhársky
here. How will the UPS notice the NUT that it is running critically

low?

Post by Arnaud Quette

Post by Peter Tuhársky
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

Post by Arnaud Quette

Post by Peter Tuhársky
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.

Post by Kjell Claesson
/* 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

Post by Kjell Claesson
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

[t***@misbb.sk]

Hello,

I've got Tripplite Smart Int 1000 UPS with lan4.1 serial interface.
Quite sympathetic UPS, I must say from first glance. I have made a
proper serial cable (btw i hate all those constructor's decisions to
make distinct serial wiring for each and every UPS type from each and
every manufacturer!)

I use [tripplite] driver for NUT and I can use upsc to get report from
UPS, but some of these numbers are nonsense. For example

battery.voltage    13.4
(the UPS has 3x6V batteries in serial = 18V and it would never drop so
low IMO when the UPS claims battery.charge is 99% that I also consider
suspicious, after few minutes of charging from seriously depleted state,
but the batteries are not new either)

input frequency seems OK at 50,2Hz, but
input.voltage (both with maximum and minimum) give 128-129V, where I
have european grid with 230V.

Is there a problem with interpretation of these values in driver
(version 2.7.4, internal 0.9.1), or have I UPS with faulty sensors? I
don't deny this possibility either since I bought it second hand.

Could I diagnose it somehow and/or help improve the driver if necessary?
E.q., send You some raw output if You tell me how?

I also miss values such as output.voltage, battery.runtime etc, but
maybe this model simply dosen't have the numbers reported.

Sincerely
Peter

[Charles Lepple]

[please use reply-all to keep the list CC'd, thanks!]

Post by t***@misbb.sk
Hello,
I've got Tripplite Smart Int 1000 UPS with lan4.1 serial interface. Quite sympathetic UPS, I must say from first glance. I have made a proper serial cable (btw i hate all those constructor's decisions to make distinct serial wiring for each and every UPS type from each and every manufacturer!)

Is the "lan4.1" cable different from this one? http://networkupstools.org/cables.html#_tripp_lite

Post by t***@misbb.sk
I use [tripplite] driver for NUT and I can use upsc to get report from UPS, but some of these numbers are nonsense. For example
battery.voltage 13.4
(the UPS has 3x6V batteries in serial = 18V and it would never drop so low IMO when the UPS claims battery.charge is 99% that I also consider suspicious, after few minutes of charging from seriously depleted state, but the batteries are not new either)

This sounds very similar to the tripplite_usb driver: https://github.com/networkupstools/nut/blob/master/drivers/tripplite_usb.c#L436

Post by t***@misbb.sk
input frequency seems OK at 50,2Hz, but
input.voltage (both with maximum and minimum) give 128-129V, where I have european grid with 230V.

Same thing, the voltages in tripplite_usb are scaled by the nominal voltage (more or less).

Post by t***@misbb.sk
Is there a problem with interpretation of these values in driver (version 2.7.4, internal 0.9.1), or have I UPS with faulty sensors? I don't deny this possibility either since I bought it second hand.

The driver hasn't been updated since 2009-2010, so it is probably that we did not know as much about the protocol then.

Post by t***@misbb.sk
Could I diagnose it somehow and/or help improve the driver if necessary? E.q., send You some raw output if You tell me how?

Are you comfortable with rebuilding the drivers?

I think the best thing might be to see if your UPS responds to the same protocol query command that is used in tripplite_usb:

https://github.com/networkupstools/nut/blob/master/drivers/tripplite_usb.c#L880-L896

If so, it is possible that we could reuse some of the code from that driver for the serial interface.

The protocol command has an embedded ASCII 0 character, so it might be tough to send this from the command line or a serial console program.

Post by t***@misbb.sk
I also miss values such as output.voltage, battery.runtime etc, but maybe this model simply dosen't have the numbers reported.

We have to calculate an estimate of battery.runtime in tripplite_usb, but we could try something similar.

Post by t***@misbb.sk
_______________________________________________
Nut-upsdev mailing list
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

[Charles Lepple]

Post by Charles Lepple

Post by t***@misbb.sk
I also miss values such as output.voltage, battery.runtime etc, but maybe this model simply dosen't have the numbers reported.

We have to calculate an estimate of battery.runtime in tripplite_usb, but we could try something similar.

Here is an example of the data we get from an older device using tripplite_usb:

http://new.networkupstools.org/ddl/Tripp_Lite/OMNIVS1000.html#_report_1

[t***@misbb.sk]

Thank You for You reply, Charles

Post by Charles Lepple
Is the "lan4.1" cable different from this one?
http://networkupstools.org/cables.html#_tripp_lite

Yes, it is different. The correct cable for this interface version looks
like this:
http://pinouts.ru/UPS/tripplite_smartpro_cable_pinout.shtml

Post by Charles Lepple
Are you comfortable with rebuilding the drivers?

Seems that it could help tripplite tree as such... Charles, well, I'm
not a programmer, but if You send me instructions and/or howto, I'll try
my best.

I have Debian 9 so please decide, whether it would suffice to use the
distributional source packages or whether build from "raw" upstream
source, and instruct me accordingly.

Peter

[Charles Lepple]

Post by t***@misbb.sk
Thank You for You reply, Charles

Post by Charles Lepple
Is the "lan4.1" cable different from this one? http://networkupstools.org/cables.html#_tripp_lite

http://pinouts.ru/UPS/tripplite_smartpro_cable_pinout.shtml

Thanks, I just created an issue to remind me about that later: https://github.com/networkupstools/nut/issues/487

Post by t***@misbb.sk

Post by Charles Lepple
Are you comfortable with rebuilding the drivers?

Seems that it could help tripplite tree as such... Charles, well, I'm not a programmer, but if You send me instructions and/or howto, I'll try my best.
I have Debian 9 so please decide, whether it would suffice to use the distributional source packages or whether build from "raw" upstream source, and instruct me accordingly.

You might want to rebuild the .deb packages later, but for now, the quickest way is probably from source.

1) make sure you have "deb-src" lines to match the "deb" lines in /etc/apt/sources
2) run "sudo apt-get update" if you had to change anything
3) run "sudo apt-get build-dep nut"
3.5) optional: remove "asciidoc" (or install the build-deps manually, and omit asciidoc) to save a bit of build time
4) run "sudo apt-get -y install git" if you do not already have Git installed
5) clone the source to your working directory: "git clone https://github.com/networkupstools/nut.git"
6) "cd nut" and run this mega-command:

./configure --includedir=/usr/include --mandir=/usr/share/man \
--infodir=/usr/share/info --sysconfdir=/etc/nut --localstatedir=/var \
--libexecdir=/usr/lib/nut --srcdir=. --enable-maintainer-mode \
--disable-silent-rules --libdir=/usr/lib/x86_64-linux-gnu \
--with-ssl --with-nss --with-cgi --with-dev --enable-static \
--with-statepath=/var/run/nut --with-altpidpath=/var/run/nut \
--with-drvpath=/lib/nut --with-cgipath=/usr/lib/cgi-bin/nut \
--with-htmlpath=/usr/share/nut/www --with-pidpath=/var/run/nut \
--datadir=/usr/share/nut --with-pkgconfig-dir=/usr/lib/x86_64-linux-gnu/pkgconfig \
--with-user=nut --with-group=nut --with-udev-dir=/lib/udev \
--with-systemdsystemunitdir=/lib/systemd/system

7) run "make"

Hopefully that works, and in the mean time, I will work on a quick patch that will attempt to grab the protocol number.

[t***@misbb.sk]

Hi, Charles

I'm trying compilation but there is no configure command in the cloned
git directory of nut.

Post by Charles Lepple

Post by t***@misbb.sk
Thank You for You reply, Charles

Post by Charles Lepple
Is the "lan4.1" cable different from this one? http://networkupstools.org/cables.html#_tripp_lite

http://pinouts.ru/UPS/tripplite_smartpro_cable_pinout.shtml

Thanks, I just created an issue to remind me about that later: https://github.com/networkupstools/nut/issues/487

Post by t***@misbb.sk

Post by Charles Lepple
Are you comfortable with rebuilding the drivers?

Seems that it could help tripplite tree as such... Charles, well, I'm not a programmer, but if You send me instructions and/or howto, I'll try my best.
I have Debian 9 so please decide, whether it would suffice to use the distributional source packages or whether build from "raw" upstream source, and instruct me accordingly.

You might want to rebuild the .deb packages later, but for now, the quickest way is probably from source.
1) make sure you have "deb-src" lines to match the "deb" lines in /etc/apt/sources
2) run "sudo apt-get update" if you had to change anything
3) run "sudo apt-get build-dep nut"
3.5) optional: remove "asciidoc" (or install the build-deps manually, and omit asciidoc) to save a bit of build time
4) run "sudo apt-get -y install git" if you do not already have Git installed
5) clone the source to your working directory: "git clone https://github.com/networkupstools/nut.git"
./configure --includedir=/usr/include --mandir=/usr/share/man \
--infodir=/usr/share/info --sysconfdir=/etc/nut --localstatedir=/var \
--libexecdir=/usr/lib/nut --srcdir=. --enable-maintainer-mode \
--disable-silent-rules --libdir=/usr/lib/x86_64-linux-gnu \
--with-ssl --with-nss --with-cgi --with-dev --enable-static \
--with-statepath=/var/run/nut --with-altpidpath=/var/run/nut \
--with-drvpath=/lib/nut --with-cgipath=/usr/lib/cgi-bin/nut \
--with-htmlpath=/usr/share/nut/www --with-pidpath=/var/run/nut \
--datadir=/usr/share/nut --with-pkgconfig-dir=/usr/lib/x86_64-linux-gnu/pkgconfig \
--with-user=nut --with-group=nut --with-udev-dir=/lib/udev \
--with-systemdsystemunitdir=/lib/systemd/system
7) run "make"
Hopefully that works, and in the mean time, I will work on a quick patch that will attempt to grab the protocol number.

[Charles Lepple]

My apologies, I forgot a step. See below.

Post by t***@misbb.sk
Hi, Charles
I'm trying compilation but there is no configure command in the cloned git directory of nut.

Post by Charles Lepple

Post by t***@misbb.sk
Thank You for You reply, Charles

Post by Charles Lepple
Is the "lan4.1" cable different from this one? http://networkupstools.org/cables.html#_tripp_lite

http://pinouts.ru/UPS/tripplite_smartpro_cable_pinout.shtml

Thanks, I just created an issue to remind me about that later: https://github.com/networkupstools/nut/issues/487

Post by t***@misbb.sk

Post by Charles Lepple
Are you comfortable with rebuilding the drivers?

Seems that it could help tripplite tree as such... Charles, well, I'm not a programmer, but if You send me instructions and/or howto, I'll try my best.
I have Debian 9 so please decide, whether it would suffice to use the distributional source packages or whether build from "raw" upstream source, and instruct me accordingly.

You might want to rebuild the .deb packages later, but for now, the quickest way is probably from source.
1) make sure you have "deb-src" lines to match the "deb" lines in /etc/apt/sources
2) run "sudo apt-get update" if you had to change anything
3) run "sudo apt-get build-dep nut"
3.5) optional: remove "asciidoc" (or install the build-deps manually, and omit asciidoc) to save a bit of build time
4) run "sudo apt-get -y install git" if you do not already have Git installed
5) clone the source to your working directory: "git clone https://github.com/networkupstools/nut.git"

6.5) "git fetch && git checkout tripplite_serial_protocol"
6.6) "./autogen.sh"

Post by t***@misbb.sk

Post by Charles Lepple
./configure --includedir=/usr/include --mandir=/usr/share/man \
--infodir=/usr/share/info --sysconfdir=/etc/nut --localstatedir=/var \
--libexecdir=/usr/lib/nut --srcdir=. --enable-maintainer-mode \
--disable-silent-rules --libdir=/usr/lib/x86_64-linux-gnu \
--with-ssl --with-nss --with-cgi --with-dev --enable-static \
--with-statepath=/var/run/nut --with-altpidpath=/var/run/nut \
--with-drvpath=/lib/nut --with-cgipath=/usr/lib/cgi-bin/nut \
--with-htmlpath=/usr/share/nut/www --with-pidpath=/var/run/nut \
--datadir=/usr/share/nut --with-pkgconfig-dir=/usr/lib/x86_64-linux-gnu/pkgconfig \
--with-user=nut --with-group=nut --with-udev-dir=/lib/udev \
--with-systemdsystemunitdir=/lib/systemd/system
7) run "make"
Hopefully that works, and in the mean time, I will work on a quick patch that will attempt to grab the protocol number.

The tripplite_serial_protocol branch has some debug statements that will show up if you run "sudo drivers/tripplite -D -a name-of-ups" from the nut directory.

[t***@misbb.sk]

Heh,

"Regenerating Augeas ups.conf lens" - a bit of Greek mythology based
humor? :-)

Post by Charles Lepple
git fetch && git checkout tripplite_serial_protocol

[t***@misbb.sk]

Charles, maybe we are getting closer :-)

Post by Charles Lepple
The tripplite_serial_protocol branch has some debug statements that will show up if you run "sudo drivers/tripplite -D -a name-of-ups" from the nut directory.

Network UPS Tools - Tripp-Lite SmartUPS driver 0.91 (2.7.4-432-gafd90f5a)
   0.000000    [D1] debug level is '1'
   0.177766    [D1] W value = 0x86
   0.177782    [D1] L value = 0x45
   0.177786    [D1] V value = 0x01
   0.177790    [D1] X value = 0x0000
Detected Tripp Lite Smart 1000 on /dev/ttyS0

[Thomas Charron]

I do have some of the more modern protocol documentation for Tripplite
from the tripplite engineers, if someone is working on updating the
Tripplite drivers.

Their protocols are horrible.

Thomas

Post by t***@misbb.sk
Charles, maybe we are getting closer :-)

Post by Charles Lepple
The tripplite_serial_protocol branch has some debug statements that will
show up if you run "sudo drivers/tripplite -D -a name-of-ups" from the nut
directory.

Network UPS Tools - Tripp-Lite SmartUPS driver 0.91 (2.7.4-432-gafd90f5a)
0.000000 [D1] debug level is '1'
0.177766 [D1] W value = 0x86
0.177782 [D1] L value = 0x45
0.177786 [D1] V value = 0x01
0.177790 [D1] X value = 0x0000
Detected Tripp Lite Smart 1000 on /dev/ttyS0
_______________________________________________
Nut-upsdev mailing list
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev

[Charles Lepple]

I do have some of the more modern protocol documentation for Tripplite from the tripplite engineers, if someone is working on updating the Tripplite drivers.

Is this something we can publish on the protocol section of the NUT website? If not... any recommendations on things we should change in the code?

I'm happy to help with updating drivers, as long as someone is willing to test the changes.

[Charles Lepple]

Post by t***@misbb.sk
Charles, maybe we are getting closer :-)

Post by Charles Lepple
The tripplite_serial_protocol branch has some debug statements that will show up if you run "sudo drivers/tripplite -D -a name-of-ups" from the nut directory.

Network UPS Tools - Tripp-Lite SmartUPS driver 0.91 (2.7.4-432-gafd90f5a)
0.000000 [D1] debug level is '1'
0.177766 [D1] W value = 0x86
0.177782 [D1] L value = 0x45
0.177786 [D1] V value = 0x01
0.177790 [D1] X value = 0x0000

Hmm, I was hoping to see some numbers in V that matched the format of the V command results in tripplite_usb.

If you run "git pull" and rebuild, what does it print for the "D" value?

We might need to get some results from others who have similar hardware, but 120V wiring, and compare to see if one of the digits refers to the voltage range.

[t***@misbb.sk]

Post by Charles Lepple
We might need to get some results from others who have similar hardware, but 120V wiring, and compare to see if one of the digits refers to the voltage range.

Well, I don't know any... And I don't see voltage selector on UPS either.

[t***@misbb.sk]

Charles, You asked for numbers, and got numbers in return :-)

After recompilation,

   0.314016    [D1] D value: 1181128E50001681811F5

Post by Charles Lepple

Post by t***@misbb.sk
Charles, maybe we are getting closer :-)

Post by Charles Lepple
The tripplite_serial_protocol branch has some debug statements that will show up if you run "sudo drivers/tripplite -D -a name-of-ups" from the nut directory.

Network UPS Tools - Tripp-Lite SmartUPS driver 0.91 (2.7.4-432-gafd90f5a)
0.000000 [D1] debug level is '1'
0.177766 [D1] W value = 0x86
0.177782 [D1] L value = 0x45
0.177786 [D1] V value = 0x01
0.177790 [D1] X value = 0x0000

Hmm, I was hoping to see some numbers in V that matched the format of the V command results in tripplite_usb.
If you run "git pull" and rebuild, what does it print for the "D" value?
We might need to get some results from others who have similar hardware, but 120V wiring, and compare to see if one of the digits refers to the voltage range.

[Peter Tuhársky]

Hi, Arnaud

Thank You for Your kind answer.

I attempted to use USB, as You suggested. After connecting the cable, kernel detects HP R 5000 as HID like this:

[ 1701.100025] usb 2-1: new full speed USB device using ohci_hcd and address 2
[ 1701.324982] usb 2-1: New USB device found, idVendor=03f0, idProduct=1fe7
[ 1701.324985] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=4
[ 1701.324989] usb 2-1: Product: HP R5000
[ 1701.324991] usb 2-1: Manufacturer: HP
[ 1701.324992] usb 2-1: SerialNumber: 3C81520083
[ 1701.325147] usb 2-1: configuration #1 chosen from 1 choice
[ 1701.391326] usbcore: registered new interface driver hiddev
[ 1701.433359] generic-usb: probe of 0003:03F0:1FE7.0001 failed with error -22
[ 1701.433395] usbcore: registered new interface driver usbhid
[ 1701.433460] usbhid: v2.6:USB HID core driver

Although generic-usb fails with error -22, I hope this should not be a problem, since next lines, usbcore and usbhid show no no sign of trouble.

I set ups.conf like this:

protocol = usbhid-ups
port = auto

However, starting upsdrvctl shows this error:

Network UPS Tools - UPS driver controller 2.4.3
Network UPS Tools - Generic HID driver 0.34 (2.4.3)
USB communication driver 0.31
No matching HID UPS found
Driver failed to start (exit status=1)


Should I use some exact vendor specification in ups.conf and if, what should it be? Or is there other source of trouble?

cheers,
Peter

----------------Pôvodná správa-----------------
Od: "Arnaud Quette" ***@gmail.com
Komu: "Peter Tuhársky" ***@misbb.sk
Kópia: nut-***@lists.alioth.debian.org
Dátum: Thu, 29 Mar 2012 18:38:17 +0200
-------------------------------------------------

Post by 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

I even didn't find it in web interface settings. There is quite opposite
setting possible (custom): how many seconds AFTER the UPS goes battery,
should it switch off. This is quite illogical, though.

http://www.networkupstools.org/docs/user-manual.chunked/ar01s07.html
#_the_advanced_approach_using_upssched
If you, for example, have 10 mn of runtime, and need 2 mn to shutdown the
system, then you would declare a (max) 8 mn timer when switching on battery.
So, I'm afraid a bit doing UPS fullscale test because I don't know, whether

servers will have enough time to shutdown before UPS switches itself off. I
know I will face it in future, however need more info now.

your remarks are valid!
I entered the round lately on this driver, following Eaton acquisition of
MGE OPS.
The thing is that, since that time, the various redundant Eaton protocols
coming from Eaton or MGE (Ie serial XCP Vs SHUT, USB XCP Vs USB/HID, ...)
have seen some decision: XCP has been superseded by SHUT and HID.
My main focus has so gone to these, though I've also been putting some
efforts to improve the XCP driver.
So, mge-shut and usbhid-ups (Eaton and derivative products) provide support
for lot more data and features.
battery.runtime.low is for example supported.
And R5000 is supported by usbhid-ups through the USB port.
Otherwise, there are still planned improvement for XCP (and a lot around
configuration).
The best would be a driver rewrite, but I've currently not enough resources
to staff one on this.
But I think I've identified what should be mapped battery.runtime.low.
So I you really want to go the XCP way, let me know and I'll check what I
can do.
One thing that may help is to tell HP that you want a better NUT support...
I hope this will shed some light on this, and provide you at least a
suitable solution.
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/

[Arnaud Quette]

Post by Peter Tuhársky
Hi, Arnaud

Hi Peter

Thank You for Your kind answer.

Post by Peter Tuhársky
I attempted to use USB, as You suggested. After connecting the cable,
[ 1701.100025] usb 2-1: new full speed USB device using ohci_hcd and address 2
[ 1701.324982] usb 2-1: New USB device found, idVendor=03f0, idProduct=1fe7
[ 1701.324985] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=4
[ 1701.324989] usb 2-1: Product: HP R5000
[ 1701.324991] usb 2-1: Manufacturer: HP
[ 1701.324992] usb 2-1: SerialNumber: 3C81520083
[ 1701.325147] usb 2-1: configuration #1 chosen from 1 choice
[ 1701.391326] usbcore: registered new interface driver hiddev
[ 1701.433359] generic-usb: probe of 0003:03F0:1FE7.0001 failed with error -22
[ 1701.433395] usbcore: registered new interface driver usbhid
[ 1701.433460] usbhid: v2.6:USB HID core driver
Although generic-usb fails with error -22, I hope this should not be a
problem, since next lines, usbcore and usbhid show no no sign of trouble.

not sure why you get this. I'll have to go back to the kernel soon...

Post by Peter Tuhársky
protocol = usbhid-ups
port = auto
Network UPS Tools - UPS driver controller 2.4.3
Network UPS Tools - Generic HID driver 0.34 (2.4.3)
USB communication driver 0.31
No matching HID UPS found
Driver failed to start (exit status=1)
Should I use some exact vendor specification in ups.conf and if, what
should it be? Or is there other source of trouble?

R5000 (USB productID 0x1fe7) is part of my (still underway) patch :-/
adding "productid=0x1fe7" to your usp.conf will indeed fix it.

note that I've still a few fixes staging and tests needed on my side, even
for HID.
so expect to see a few buggy values, like for battery.temperature.

cheers,
Arnaud

[Peter Tuhársky]

Hi,

I tested productid=0x1fe7 for usbhid-ups and it did not help. Do I need
to compile a development version of NUT first?

Or what should I do?

Peter

Post by Arnaud Quette

Post by Peter Tuhársky
Hi, Arnaud

Hi Peter
Thank You for Your kind answer.

Post by Peter Tuhársky
I attempted to use USB, as You suggested. After connecting the cable,
[ 1701.100025] usb 2-1: new full speed USB device using ohci_hcd and address 2
[ 1701.324982] usb 2-1: New USB device found, idVendor=03f0, idProduct=1fe7
[ 1701.324985] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=4
[ 1701.324989] usb 2-1: Product: HP R5000
[ 1701.324991] usb 2-1: Manufacturer: HP
[ 1701.324992] usb 2-1: SerialNumber: 3C81520083
[ 1701.325147] usb 2-1: configuration #1 chosen from 1 choice
[ 1701.391326] usbcore: registered new interface driver hiddev
[ 1701.433359] generic-usb: probe of 0003:03F0:1FE7.0001 failed with error -22
[ 1701.433395] usbcore: registered new interface driver usbhid
[ 1701.433460] usbhid: v2.6:USB HID core driver
Although generic-usb fails with error -22, I hope this should not be a
problem, since next lines, usbcore and usbhid show no no sign of trouble.

not sure why you get this. I'll have to go back to the kernel soon...

Post by Peter Tuhársky
protocol = usbhid-ups
port = auto
Network UPS Tools - UPS driver controller 2.4.3
Network UPS Tools - Generic HID driver 0.34 (2.4.3)
USB communication driver 0.31
No matching HID UPS found
Driver failed to start (exit status=1)
Should I use some exact vendor specification in ups.conf and if, what
should it be? Or is there other source of trouble?

R5000 (USB productID 0x1fe7) is part of my (still underway) patch :-/
adding "productid=0x1fe7" to your usp.conf will indeed fix it.
note that I've still a few fixes staging and tests needed on my side, even
for HID.
so expect to see a few buggy values, like for battery.temperature.
cheers,
Arnaud

[Arnaud Quette]

Post by Peter Tuhársky
Hi,

Hi Peter

I tested productid=0x1fe7 for usbhid-ups and it did not help. Do I need to

Post by Peter Tuhársky
compile a development version of NUT first?
Or what should I do?

mea culpa: the productID was obviously missing, but the VendorID too.
I've just committed the patch in trunk (r3525) which adds USB/HID (Eaton
mode) support for HP:
http://trac.networkupstools.org/projects/nut/changeset/3525

(the changeset should be available in ~1h)

there are still a few TODO and tests needed, but I've been retaining this
commit for too long now.