[Nut-upsuser] TRIPPLITE OMNIVSINT80 Compatibility

[Dave Williams]

Using this UPS in the UK on 240V mains.

Connected via USB:
Bus 001 Device 002: ID 09ae:0001 Tripp Lite

Requires tripplite_usb driver as it is (Product ID: 0001). There is an
entry in the compatibity list for OMNIVS800 USB (protocol 2012) using
usbhid-ups which is little misleading (although I guess maybe correct
for some instances of the UPS).

OMNIVS1000 USB (older; product ID: 0001) is shown correctly so maybe
the OMNIVSING800 just needs to be added to the list next to it.

UDEV Rules are showing it correctly when decoding the USB ID as above.

Seems to work as far as I have tested so far but upsc reports:

upsc reports
battery.charge: 100
battery.voltage: 14.56
battery.voltage.nominal: 12
device.mfr: Tripp Lite
device.model: OMNIVSINT800
device.type: ups
driver.name: tripplite_usb
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.version: 2.6.4
driver.version.internal: 0.20
input.voltage: 124.00 <============ WRONG
input.voltage.nominal: 230
output.voltage: 120.0 <============ WRONG
ups.debug.load_banks: 0
ups.debug.V: 32 30 32 58 58 58 0d '202XXX.'
ups.delay.shutdown: 64
ups.firmware: F1145.A
ups.firmware.aux: protocol 1001
ups.mfr: Tripp Lite
ups.model: OMNIVSINT800
ups.power.nominal: 800
ups.productid: 0001
ups.status: OL
ups.vendorid: 09ae

Note the two wrong values being reported.

They are, in fact out, by a factor of just over 2 (2.04 measured for output
voltage and 1.95 for input voltage as reported by my main UPS). Whether there
is anything being returned that helps differentiate its a 240v model I dont
know.

This is, at least, consistent with decode_v() in the driver src:

void decode_v(const unsigned char *value)
{
unsigned char ivn, lb;
int bv = hex2d(value+2, 2);

ivn = value[1];
lb = value[4];

switch(ivn) {
case '0': input_voltage_nominal =
input_voltage_scaled = 100;
break;

case '1': input_voltage_nominal =
input_voltage_scaled = 120;
break;

case '2': input_voltage_nominal =
input_voltage_scaled = 230;
break;

case '3': input_voltage_nominal = 208;
input_voltage_scaled = 230;
break;

default:
upslogx(2, "Unknown input voltage range: 0x%02x", (unsigned int)ivn);
break;
}
...
given ups.debugV[1] has the value 0.

Anyway I can sort of live with it as it is and apply the correction factor externally.


Dave

[Charles Lepple]

Post by Dave Williams
Using this UPS in the UK on 240V mains.
Bus 001 Device 002: ID 09ae:0001 Tripp Lite
Requires tripplite_usb driver as it is (Product ID: 0001). There is an
entry in the compatibity list for OMNIVS800 USB (protocol 2012) using
usbhid-ups which is little misleading (although I guess maybe correct
for some instances of the UPS).

I think the OMNIVS800 protocol 2012 entry came from Tripp Lite test results. (There have definitely been naming collisions in the past; hence, the messages in the drivers if you accidentally choose the wrong one.)

Confusingly, if the USB ProductID is 0001, the Tripp Lite specific "Protocol" number (shown in "ups.firmware.aux") is probably not 0001. But if the ProductID is greater than 0001, the ProductID and Protocol should match.

Post by Dave Williams
OMNIVS1000 USB (older; product ID: 0001) is shown correctly so maybe
the OMNIVSING800 just needs to be added to the list next to it.

Will do.

Post by Dave Williams
UDEV Rules are showing it correctly when decoding the USB ID as above.
upsc reports
battery.charge: 100
battery.voltage: 14.56
battery.voltage.nominal: 12
device.mfr: Tripp Lite
device.model: OMNIVSINT800
device.type: ups
driver.name: tripplite_usb
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.version: 2.6.4
driver.version.internal: 0.20
input.voltage: 124.00 <============ WRONG
input.voltage.nominal: 230
output.voltage: 120.0 <============ WRONG
ups.debug.load_banks: 0
ups.debug.V: 32 30 32 58 58 58 0d '202XXX.'
ups.delay.shutdown: 64
ups.firmware: F1145.A
ups.firmware.aux: protocol 1001
ups.mfr: Tripp Lite
ups.model: OMNIVSINT800
ups.power.nominal: 800
ups.productid: 0001
ups.status: OL
ups.vendorid: 09ae
Note the two wrong values being reported.
They are, in fact out, by a factor of just over 2 (2.04 measured for output
voltage and 1.95 for input voltage as reported by my main UPS). Whether there
is anything being returned that helps differentiate its a 240v model I dont
know.

You're right, we have a "magic constant" in the "input.voltage" and "output.voltage" calculations for your protocol.

https://github.com/networkupstools/nut/blob/master/drivers/tripplite_usb.c#L1240

https://github.com/networkupstools/nut/blob/master/drivers/tripplite_usb.c#L1360

[...]

Post by Dave Williams
given ups.debugV[1] has the value 0.

Ugh, that code is a mess. I should find the guy who wrote that driver and... never mind.

For some reason that made sense at the time, the "ups.debug.*" variables in tripplite_usb actually start printing from value+1 (I suppose because v_value[0] is always 'V'). So the input.voltage.nominal value gets set properly because v_value[1] is actually '2'.

I went ahead and changed the 230V nominal to 240V.

https://github.com/networkupstools/nut/commit/f61edb5161de97944074867832edc014323340b1

If you want to rebuild the driver, let me know - even though yours seems to be from NUT 2.6.4, I doubt there will be any issues with building the 2.7.2+ Git version and dropping it in.

[Dave Williams]

Post by Charles Lepple
I think the OMNIVS800 protocol 2012 entry came from Tripp Lite test results. (There have definitely been naming collisions in the past; hence, the messages in the drivers if you accidentally choose the wrong one.)
Confusingly, if the USB ProductID is 0001, the Tripp Lite specific "Protocol" number (shown in "ups.firmware.aux") is probably not 0001. But if the ProductID is greater than 0001, the ProductID and Protocol should match.

Your messages in the driver helped me when I initially chose the wrong
one and got the usual "Driver Not Connected" error!"

Post by Charles Lepple

Post by Dave Williams
OMNIVS1000 USB (older; product ID: 0001) is shown correctly so maybe
the OMNIVSING800 just needs to be added to the list next to it.

Will do.

Thanks

Post by Charles Lepple
You're right, we have a "magic constant" in the "input.voltage" and "output.voltage" calculations for your protocol.
https://github.com/networkupstools/nut/blob/master/drivers/tripplite_usb.c#L1240
https://github.com/networkupstools/nut/blob/master/drivers/tripplite_usb.c#L1360

Yes I found that conversation.

Post by Charles Lepple
For some reason that made sense at the time, the "ups.debug.*" variables in tripplite_usb actually start printing from value+1 (I suppose because v_value[0] is always 'V'). So the input.voltage.nominal value gets set properly because v_value[1] is actually '2'.

Actually if this is reliable across models we could use it to scale actual input/output voltages respectively

Post by Charles Lepple
I went ahead and changed the 230V nominal to 240V.

Thats a moot point. After European Harmonisation (UK was on 240V EU on
220V) they settled for 230V nominal but then defined tolerences of
+/-10% so that everyone suddenly "conformed" to the new regulations
without doing anything. Whilst a lot of the UK is actually on 230V now
my current house is still on 240V. Looked very strange on my main
BestPower and Riello UPS RRD graphs as they show the +10V step change in
measured voltage.

Having said all that the BestPower delivers 240V and the Riello 230V
(adjustable). The Tripp Lite says 240V on the box and is
delivering that as its ONLINE nominal output (but drops to <200V on battery
power given its a budget UPS).
n>

Post by Charles Lepple
https://github.com/networkupstools/nut/commit/f61edb5161de97944074867832edc014323340b1
If you want to rebuild the driver, let me know - even though yours seems to be from NUT 2.6.4, I doubt there will be any issues with building the 2.7.2+ Git version and dropping it in.

No problem. I just installed NUT 2.6.4 as that is the latest from debian (wheezy) and it happens to be running from CF on an SBC - but I have the src and toolchain on the box so no reason why I couldnt rebuild it.
regards
Dave

[Charles Lepple]

Post by Dave Williams

Post by Charles Lepple
I think the OMNIVS800 protocol 2012 entry came from Tripp Lite test results. (There have definitely been naming collisions in the past; hence, the messages in the drivers if you accidentally choose the wrong one.)
Confusingly, if the USB ProductID is 0001, the Tripp Lite specific "Protocol" number (shown in "ups.firmware.aux") is probably not 0001. But if the ProductID is greater than 0001, the ProductID and Protocol should match.

Your messages in the driver helped me when I initially chose the wrong
one and got the usual "Driver Not Connected" error!"

Post by Charles Lepple

Post by Dave Williams
OMNIVS1000 USB (older; product ID: 0001) is shown correctly so maybe
the OMNIVSING800 just needs to be added to the list next to it.

Will do.

Thanks

Post by Charles Lepple
You're right, we have a "magic constant" in the "input.voltage" and "output.voltage" calculations for your protocol.
https://github.com/networkupstools/nut/blob/master/drivers/tripplite_usb.c#L1240
https://github.com/networkupstools/nut/blob/master/drivers/tripplite_usb.c#L1360

Yes I found that conversation.

Well, I ended up linking to the latest version of those files, so this shows the change better:

https://github.com/networkupstools/nut/commit/f61edb5161de97944074867832edc014323340b1

Still a magic constant, but now it has the nominal voltage factored in.

Post by Dave Williams

Post by Charles Lepple
For some reason that made sense at the time, the "ups.debug.*" variables in tripplite_usb actually start printing from value+1 (I suppose because v_value[0] is always 'V'). So the input.voltage.nominal value gets set properly because v_value[1] is actually '2'.

Actually if this is reliable across models we could use it to scale actual input/output voltages respectively

That's the thing, due to the patchwork of methods required to poll the different 0001-type protocols, it *was* scaling some of the voltages - just not for protocol 1001 or 2001.

Post by Dave Williams

Post by Charles Lepple
I went ahead and changed the 230V nominal to 240V.

Thats a moot point. After European Harmonisation (UK was on 240V EU on
220V) they settled for 230V nominal but then defined tolerences of
+/-10% so that everyone suddenly "conformed" to the new regulations
without doing anything. Whilst a lot of the UK is actually on 230V now
my current house is still on 240V. Looked very strange on my main
BestPower and Riello UPS RRD graphs as they show the +10V step change in
measured voltage.

I can change it back to 230V - I was going off of the x2 factor you mentioned. Either way works for me.

Post by Dave Williams
Having said all that the BestPower delivers 240V and the Riello 230V
(adjustable). The Tripp Lite says 240V on the box and is
delivering that as its ONLINE nominal output (but drops to <200V on battery
power given its a budget UPS).
n>

Post by Charles Lepple
https://github.com/networkupstools/nut/commit/f61edb5161de97944074867832edc014323340b1
If you want to rebuild the driver, let me know - even though yours seems to be from NUT 2.6.4, I doubt there will be any issues with building the 2.7.2+ Git version and dropping it in.

No problem. I just installed NUT 2.6.4 as that is the latest from debian (wheezy) and it happens to be running from CF on an SBC - but I have the src and toolchain on the box so no reason why I couldnt rebuild it.
regards
Dave

Feel free to ask on the list if you run into any problems while rebuilding. Debian doesn't have too many odd substitutions in their control files, so it's pretty easy to either reconfigure NUT to match the ./configure paths used by the .debs, or download the debian/ overlay from http://packages.debian.org/wheezy/nut and update the versions to use the latest tar.gz source snapshot from here:

http://buildbot.networkupstools.org/public/nut/waterfall?show=Debian-x64-gcc

[Dave Williams]

Post by Charles Lepple
https://github.com/networkupstools/nut/commit/f61edb5161de97944074867832edc014323340b1
Still a magic constant, but now it has the nominal voltage factored in.

Just building your latest code now. Which commit is this in (just to check
I have it?)

Post by Charles Lepple
I can change it back to 230V - I was going off of the x2 factor you mentioned. Either way works for me.

OK lets just make sure we are answering the right question. The
general/specified UK/European voltage is 230V but the UPS is generating
240v. What is input.nominal.voltage meant to mean in the context of what
the UPS (and upsc) reports?

My guess its what it would expect to see so you can relate input.voltage
to it. In that respect its 230V for the territory the model is sold into
even though Tripp lite are selling it as a 240V model. Either way the
differentiation only has to deal with 2x0V versus 110V and so unlikely
to be the source of any confusion.


Dave

[Charles Lepple]

Post by Dave Williams

Post by Charles Lepple
https://github.com/networkupstools/nut/commit/f61edb5161de97944074867832edc014323340b1
Still a magic constant, but now it has the nominal voltage factored in.

Just building your latest code now. Which commit is this in (just to check
I have it?)

The commit listed above (f61eadb5) includes the scaling, and it is on master (currently 4b753dc7). If upsc shows "driver.version.internal: 0.28" or 0.29, you have it all installed correctly.

Post by Dave Williams

Post by Charles Lepple
I can change it back to 230V - I was going off of the x2 factor you mentioned. Either way works for me.

OK lets just make sure we are answering the right question. The
general/specified UK/European voltage is 230V but the UPS is generating
240v. What is input.nominal.voltage meant to mean in the context of what
the UPS (and upsc) reports?

As a machine-parseable number, it's meant to be a hint to graphing software. (The NUT CGI scripts use it to define the various color bars for normal, high and low voltages.)

Post by Dave Williams
My guess its what it would expect to see so you can relate input.voltage
to it. In that respect its 230V for the territory the model is sold into
even though Tripp lite are selling it as a 240V model. Either way the
differentiation only has to deal with 2x0V versus 110V and so unlikely
to be the source of any confusion.

In that case, I'm inclined to change it back to 230V before the next release, since we don't have any more accurate information as to what the 'V' digits really mean.

[Dave Williams]

Post by Charles Lepple
The commit listed above (f61eadb5) includes the scaling, and it is on master (currently 4b753dc7). If upsc shows "driver.version.internal: 0.28" or 0.29, you have it all installed correctly.

Now looks improved (compiled from commit 4b753dc7 src):

battery.charge: 100
battery.voltage: 14.50
battery.voltage.nominal: 12
device.mfr: Tripp Lite
device.model: OMNIVSINT800
device.type: ups
driver.name: tripplite_usb
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.version: 2.7.2-signed-89-g4b753dc
driver.version.internal: 0.29
input.voltage: 251.93
input.voltage.nominal: 240
output.voltage: 226.0
ups.debug.load_banks: 0
ups.debug.V: 32 30 32 58 58 58 0d '202XXX.'
ups.delay.shutdown: 64
ups.firmware: F1145.A
ups.firmware.aux: protocol 1001
ups.mfr: Tripp Lite
ups.model: OMNIVSINT800
ups.power.nominal: 800
ups.productid: 0001
ups.status: OL
ups.vendorid: 09ae

Measuring the real voltages shows input.voltage is reading high by 2%
and output.voltage low by 6.5% (real voltage is 243.8V and output 244.2V atm).
The measurements reported by the UPS seem to vary quite markedly
between invocations of upsc so I can only assume the A/D used has only a few
bits resolution or the sample window is small. On bypass input.voltage
should = output.voltage of course.

Post by Charles Lepple

Post by Dave Williams
My guess its what it would expect to see so you can relate input.voltage
to it. In that respect its 230V for the territory the model is sold into
even though Tripp lite are selling it as a 240V model. Either way the
differentiation only has to deal with 2x0V versus 110V and so unlikely
to be the source of any confusion.

In that case, I'm inclined to change it back to 230V before the next release, since we don't have any more accurate information as to what the 'V' digits really mean.

I agree!

Dave

[Dave Williams]

Post by Charles Lepple

Post by Dave Williams
OMNIVS1000 USB (older; product ID: 0001) is shown correctly so maybe
the OMNIVSING800 just needs to be added to the list next to it.

Will do.

Don't see the model in the compatibility web page yet at
http://www.networkupstools.org/stable-hcl.html. Am I missing something?

Dave

[Charles Lepple]

Post by Dave Williams

Post by Charles Lepple

Post by Dave Williams
OMNIVS1000 USB (older; product ID: 0001) is shown correctly so maybe
the OMNIVSING800 just needs to be added to the list next to it.

Will do.

Don't see the model in the compatibility web page yet at
http://www.networkupstools.org/stable-hcl.html. Am I missing something?

We're almost finished redoing the way we build the website (to coincide with the next release of NUT).

The latest is here: http://buildbot.networkupstools.org/~buildbot/cayman/docs/latest/stable-hcl.html?manufacturer=Tripp-Lite

Source for that page is: https://github.com/networkupstools/nut/blob/master/data/driver.list.in