[Nut-upsuser] TRIPPLITE OMNIVSINT80 Compatibility

[Charles Lepple]

On Sep 25, 2014, at 5:51 PM, Dave Williams <dave at opensourcesolutions.co.uk> wrote:

> 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).

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.

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

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

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

[...]
> 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.

-- 
Charles Lepple
clepple at gmail