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