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.
_______________________________________________
Nut-upsdev mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
