[Nut-upsuser] TRIPPLITE OMNIVSINT80 Compatibility

[Charles Lepple]

On Sep 26, 2014, at 3:48 AM, Dave Williams <dave at opensourcesolutions.co.uk> wrote:

> On 22:17, Thu 25 Sep 14, Charles Lepple wrote:
>> 
>> 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!"
> 
>>> 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
>> 
>> 
>> 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.

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

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

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

-- 
Charles Lepple
clepple at gmail