[Nut-upsdev] Introductions, questions

[Charles Lepple]

On Sep 21, 2011, at 4:06 PM, Thomas Charron wrote:

>  Hello,
>
>  I have found that I need to be able to control a TrippLite
> SMART2200RMXL2U ups, with an external battery.  I found recently after
> trying to communicate that many of the bits I would care about (the
> output ports/loads) wheren't exposed in the current driver.
>
>  I also happen to have the Web/SNMP card, which allows me to change
> many of the settings via ssh/http interfaces.  I'm using this to try
> to identify exactly which of the bits means what, by doing an explore,
> making a change, then exploring again.

This is with usbhid-ups, right? (Older SMART2200RMXL2U models used  
tripplite_usb, which is completely different code.)

>  I was wondering what the best way to get this back into the driver  
> was.

The sub-driver (drivers/tripplite-hid.c) was probably initially  
generated from feeding the "explore" output to scripts/subdriver/path- 
to-subdriver.sh, so you could try that route and compare to the  
current tripplite-hid.c.

Or, if the HID usage paths indicated by "explore" look similar to the  
ones listed after "#ifdef USBHID_UPS_TRIPPLITE_DEBUG", you could  
define that preprocessor directive and see the output in upsc.

There are a number of items under UPS.OutletSystem.Outlet, so the  
latter method might be sufficient.

>  I am also finding that I get usb errors up the wazzoo, such as:
>
>
>   0.077393	libusb_get_report: error sending control message: Broken  
> pipe
>   0.077398	Can't retrieve Report 6b: Broken pipe

Hmm, I don't see the code path to get that error. libusb_get_report()  
has an explicit test for EPIPE, and returns zero.

>  I'm currently using 2.6.0, as I need to be able to add these changes
> to a known debian package (get source, make patch, rebuild deb
> package).

I think the changes should be applicable to both 2.6.0 and later  
versions in that series.