Nut upsdev - Sep 2011 - Introductions, questions

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.

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

  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

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

-- 
-- Thomas

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.