search for: l1240

...ng 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.*" vari...

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

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

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