[Nut-upsdev] Tripplite OMNI1000LCD Watchdog

Wed Dec 12 02:20:01 UTC 2007

Arjen,

I tried to trace this one on my own, but something seems to have broken for
me since 2.2.0. I can compile the SVN fine, but when I try: usbhid-ups
-DDDDD -a omni1000lcd
I get this:

-- snip lots of similar output --

Path: UPS.PowerSummary.Input.ConfigVoltage, Type: Feature, ReportID: 0x30,
Offset: 0, Size: 8, Value: 120.000000
hid_lookup_usage: UPS -> 00840004
hid_lookup_usage: PowerConverter -> 00840016
hid_lookup_usage: Input -> 0084001a
hid_lookup_usage: Frequency -> 00840032
string_to_path: depth = 4
Report[buf]: (3 bytes) => 19 57 02
PhyMax = 0, PhyMin = 0, LogMax = 65535, LogMin = 0
get_unit_expo: 00000000 found 0
Path: UPS.PowerConverter.Input.Frequency, Type: Feature, ReportID: 0x19,
Offset: 0, Size: 16, Value: 59.900000
hid_lookup_usage: UPS -> 00840004
hid_lookup_usage: PowerConverter -> 00840016
hid_lookup_usage: Output -> 0084001c
hid_lookup_usage: HighVoltageTransfer -> 00840054
string_to_path: depth = 4
hid_lookup_usage: UPS -> 00840004
hid_lookup_usage: PowerConverter -> 00840016
hid_lookup_usage: Output -> 0084001c
hid_lookup_usage: LowVoltageTransfer -> 00840053
string_to_path: depth = 4
hid_lookup_usage: UPS -> 00840004
hid_lookup_usage: PowerSummary -> 00840024
hid_lookup_usage: Voltage -> 00840030
string_to_path: depth = 3
Entering libusb_get_report
Can't retrieve Report 49: Value too large for defined data type
HIDGetDataValue: Value too large for defined data type
Can't initialize data from HID UPS 

My ups.conf only has one entry:
[omni1000lcd]
	driver = usbhid-ups
	port = auto
	description = "TrippLite Omni1000LCD UPS"

When I do this same thing with 2.2.0 it works perfectly with no errors.

I saw this same error referenced on the list archives, but it didn't seem to
match my situation, and it wasn't for a Tripp Lite UPS. I tried to look
through the libhid stuff to figure out if a buffer had changed size since
2.2.0, but gave up. What's your thoughts?

Thanks,

Thomas Golding
Information Technology Engineer
World Radio Link
208-733-3551 ext. 14
thomasg at worldradiolink.com

> -----Original Message-----
> From: 
> nut-upsdev-bounces+thomasg=worldradiolink.com at lists.alioth.deb
> ian.org 
> [mailto:nut-upsdev-bounces+thomasg=worldradiolink.com at lists.al
> ioth.debian.org] On Behalf Of Thomas Golding
> Sent: Tuesday, December 11, 2007 2:36 PM
> To: nut-upsdev at lists.alioth.debian.org
> Subject: Re: [Nut-upsdev] Tripplite OMNI1000LCD Watchdog
> 
>  > -----Original Message-----
> > From: Arjen de Korte [mailto:nut+devel at de-korte.org]
> > Sent: Tuesday, December 11, 2007 1:44 PM
> > To: Thomas Golding
> > Cc: nut-upsdev at lists.alioth.debian.org
> > Subject: Re: [Nut-upsdev] Tripplite OMNI1000LCD Watchdog
> > 
> > Thomas Golding wrote:
> > 
> > > I'm working with usbhid-ups and a Tripplite OMNI1000LCD. I
> > used a USB
> > > packet sniffer to discover something cool about the
> > watchdog feature in this unit.
> > > (not sure if the other OMNI-X-LCD models work the same or not.) 
> > > Basically there's a single HID variable at Report ID 0x52
> > > (UPS.OutletSystem.Outlet.ffff0092) that's one byte (0-255
> > int) and it
> > > contains the Watchdog timeout value. If it's set to zero,
> > the watchdog
> > > is effectively disabled. If it's set to >0, it represents
> > the amount
> > > of time (in seconds) the UPS will count down to reboot if 
> it looses 
> > > comms with the PC. Tripplite's PowerAlert software just writes a 
> > > user-assigned number to this location to enable watchdog.
> > 
> > That is a highly dangerous feature. If someone accidentally removes 
> > the USB plug, it would trip the watchdog.
> 
> 
> Yes the potential for problems is high in most environments. 
> However, when used in a radio transmitter shack in Alaska 
> where the closest human is 300 miles away... invaluable. :)
> 
> 
> > > I've looked at the code for 2.2.0, 2.2.1-pre, and SVN rev. 1170
> > > (12-08-2007) and none of them seems to implement watchdog
> > in usbhid-ups at all.
> > 
> > No, although it can be done pretty easily in the subdriver. 
> > There is no need to do this in usbhid-ups (and we won't do that 
> > either, see below).
> > 
> > > Could anyone point me in the right direction on how to code 
> > > ups.watchdog.status and reset.watchdog in usbhid-ups?
> > 
> > See if what I came up with in the trunk (r1175) suits your 
> needs. The 
> > following commands control the watchdog:
> > 
> > 	upsc <upsname> ups.watchdog.status (shows time left)
> > 	upscmd -u <user> -p <pass>] <ups> reset.watchdog[=seconds]
> > 
> > By default, the latter command will write '60' to this variable if 
> > called without the optional seconds, but you can override 
> this. You'll 
> > need to hack up a script that periodically calls this 
> command to keep 
> > your watchdog happy.
> > 
> > This feature is far too dangerous to include in the 
> mainstream NUT, so 
> > adding these variables to the tripplite-hid subdriver is as 
> far as I 
> > want to go.
> 
> 
> Understood. Now that you mention it, this feature is probably 
> implemented TOTALLY differently on other brands of UPS, so 
> having it in the Tripplite subdriver makes the most sense. 
> I'll check out the latest SVN later today and let you know 
> how it works. I really appreciate your quick response.
> Other people on the list archives have said the NUT 
> Developers are awesome, but now I've seen it for myself. :)
> 
> 
> > Best regards, Arjen
> 
> 
> Thanks Arjen,
> 
> Thomas Golding
> Information Technology Engineer
> World Radio Link
> 208-733-3551 ext. 14
> thomasg at worldradiolink.com
> 
> 
> _______________________________________________
> Nut-upsdev mailing list
> Nut-upsdev at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
> 
> __________ NOD32 2716 (20071211) Information __________
> 
> This message was checked by NOD32 antivirus system.
> http://www.eset.com
> 
> 