[Nut-upsuser] TrippLite Eco Series UPS

[Arjen de Korte]

Citeren Charles Lepple <clepple op gmail.com>:

> You are more familiar with the usbhid-ups code than I am, so if you  
> have time, can you check to see what might be preventing the driver  
> from listing an actual battery voltage?

Most likely, it uses a non-mapped (vendor specific) HID path (or the  
value is not reported at all). These series of TrippLite units (with  
productid 0x100n and 0x200n) seem to be the first stab (?) of  
TrippLite on implementing the HID PDC. Unfortunately, they use many  
vendor specific HID paths and also managed to not follow the  
specifications for others. The battery voltage being one example,  
which requires the use of a model specific scaling function to get  
this right.

> If not, I can muddle through the debug options related to that.

I will take care of this, but I'll need the first 30 seconds worth of  
output for the below command to do so:

     /path/to/usbhid-ups -DDDDD -a usbhid-ups -u root -x productid=1008

Hopefully this will provide enough information to reverse engineer the  
mapping.

> I noticed this while adding the following to my local tree:
>
> diff --git a/drivers/tripplite-hid.c b/drivers/tripplite-hid.c
> index 58def3b..173d7c3 100644
> --- a/drivers/tripplite-hid.c
> +++ b/drivers/tripplite-hid.c
> @@ -67,6 +67,8 @@ static usb_device_id_t tripplite_usb_device_table[] = {
>         { USB_DEVICE(TRIPPLITE_VENDORID, 0x1003), battery_scale_0dot1 },
>         /* e.g. TrippLite AVR750U */
>         { USB_DEVICE(TRIPPLITE_VENDORID, 0x1007), battery_scale_0dot1 },
> +	/* e.g. TrippLite ECO550UPS (battery scale unverified) */
> +	{ USB_DEVICE(TRIPPLITE_VENDORID, 0x1008), battery_scale_1dot0 },
>         /* e.g. TrippLite OMNI1000LCD */
>         { USB_DEVICE(TRIPPLITE_VENDORID, 0x2005), battery_scale_0dot1 },

I agree with the above addition. It is probably safe to add this model  
to the matching function (since at least we get *some* meaningful  
values) but we should probably mention the support status to be  
experimental (at best).

> Lindsey - note that this should only affect the readings, not the internal
> low-battery shutdown decision inside the UPS.

Currently, the driver is definitly missing some HID to NUT mappings  
related to the shutdown function, so in its present state the driver  
won't be able to shutdown the UPS and/or cycle the power to the load.  
This means that it is probably OK for a desktop system, but can't be  
used for a server that is running unattended.

Best regards, Arjen
-- 
Please keep list traffic on the list