Lance Thomas
2007-May-11 17:06 UTC
[Nut-upsdev] tripp lite smart2200RMXL2U error reading protocol
I'm working on a gentoo server with Nut 2.0.5-r1 and libusb-0.1.12.
I originally tried the hidups driver which seemed to work, but produced
a large amount of unhandled events. Then I tried the newhidups which
told me my ups wasn't supported. When I try using
tripplite_usb -u root -DDDD /proc/bus/usb/002/002
I get that there isn't a match. But when I try using
tripplite_usb -DDDD -a tripplite1
with the following ups.conf:
[tripplite1]
driver = tripplite_usb
port = /proc/bus/usb/002/002
productid = 3012
bus = 002
desc = "top ups"
I get it to run and find the HID, but it returns the following errors
before quitting:
Detected a UPS: Tripp Lite /TRIPP LITE SMART2200RMXL2U
send_cmd(msg_len=3, type='W')
libusb_get_interrupt() returned 4 instead of 8
libusb_get_interrupt() returned 4 instead of 8
libusb_get_interrupt() returned 4 instead of 8
libusb_get_interrupt() returned 4 instead of 8
libusb_get_interrupt() returned 4 instead of 8
libusb_get_interrupt() returned 4 instead of 8
libusb_get_interrupt() returned 4 instead of 8
libusb_get_interrupt() returned 4 instead of 8
libusb_get_interrupt() returned 4 instead of 8
send_cmd: send_try = 3, recv_try = 3
Could not reset watchdog. Please send model information to nut-upsdev
mailing list
send_cmd(msg_len=2, type='
libusb_get_interrupt() returned 4 instead of 8
libusb_get_interrupt() returned 4 instead of 8
libusb_get_interrupt() returned 4 instead of 8
libusb_get_interrupt() returned 4 instead of 8
libusb_get_interrupt() returned 4 instead of 8
libusb_get_interrupt() returned 4 instead of 8
libusb_get_interrupt() returned 4 instead of 8
libusb_get_interrupt() returned 4 instead of 8
libusb_get_interrupt() returned 4 instead of 8
send_cmd: send_try = 3, recv_try = 3
Error reading protocol
Any suggestions?
____________________________________________________________________
This email and any attachments may contain confidential information and is
solely for the intended recipient(s). Email communications are not considered
secure. If you are not the intended recipient(s) of this email you are expected
to disregard the content, delete the message and notify the original sender.
--University of Wisconsin, Department of Family Medicine--
____________________________________________________________________
**UW DFM**
Kjell Claesson
2007-May-11 17:43 UTC
[Nut-upsdev] tripp lite smart2200RMXL2U error reading protocol
Hi Lance, Can you do a lsusb So we get the product and vendor id. The driver seems only to support product-id 0001, so if your ups have 3012 as product id, it is a new version. Regards Kjell fre 2007-05-11 klockan 11:08 -0500 skrev Lance Thomas:> I'm working on a gentoo server with Nut 2.0.5-r1 and libusb-0.1.12. > I originally tried the hidups driver which seemed to work, but produced > a large amount of unhandled events. Then I tried the newhidups which > told me my ups wasn't supported. When I try using > > tripplite_usb -u root -DDDD /proc/bus/usb/002/002 > > I get that there isn't a match. But when I try using > > tripplite_usb -DDDD -a tripplite1 > > with the following ups.conf: > [tripplite1] > driver = tripplite_usb > port = /proc/bus/usb/002/002 > productid = 3012 > bus = 002 > desc = "top ups" > > I get it to run and find the HID, but it returns the following errors > before quitting: > Detected a UPS: Tripp Lite /TRIPP LITE SMART2200RMXL2U > send_cmd(msg_len=3, type='W') > libusb_get_interrupt() returned 4 instead of 8 > libusb_get_interrupt() returned 4 instead of 8 > libusb_get_interrupt() returned 4 instead of 8 > libusb_get_interrupt() returned 4 instead of 8 > libusb_get_interrupt() returned 4 instead of 8 > libusb_get_interrupt() returned 4 instead of 8 > libusb_get_interrupt() returned 4 instead of 8 > libusb_get_interrupt() returned 4 instead of 8 > libusb_get_interrupt() returned 4 instead of 8 > send_cmd: send_try = 3, recv_try = 3 > > Could not reset watchdog. Please send model information to nut-upsdev > mailing list > send_cmd(msg_len=2, type=' > libusb_get_interrupt() returned 4 instead of 8 > libusb_get_interrupt() returned 4 instead of 8 > libusb_get_interrupt() returned 4 instead of 8 > libusb_get_interrupt() returned 4 instead of 8 > libusb_get_interrupt() returned 4 instead of 8 > libusb_get_interrupt() returned 4 instead of 8 > libusb_get_interrupt() returned 4 instead of 8 > libusb_get_interrupt() returned 4 instead of 8 > libusb_get_interrupt() returned 4 instead of 8 > send_cmd: send_try = 3, recv_try = 3 > > Error reading protocol > > > Any suggestions? > ____________________________________________________________________ > > This email and any attachments may contain confidential information and is > solely for the intended recipient(s). Email communications are not considered > secure. If you are not the intended recipient(s) of this email you are expected > to disregard the content, delete the message and notify the original sender. > > --University of Wisconsin, Department of Family Medicine-- > ____________________________________________________________________ > > **UW DFM** > > > _______________________________________________ > Nut-upsdev mailing list > Nut-upsdev@lists.alioth.debian.org > http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Lance Thomas
2007-May-11 18:10 UTC
[Nut-upsdev] tripp lite smart2200RMXL2U error reading protocol
Here's a shot of the lsusb Bus 003 Device 002: ID 04b4:6560 Cypress Semiconductor Corp. CY7C65640 USB-2.0 "TetraHub" Bus 003 Device 001: ID 0000:0000 Bus 001 Device 001: ID 0000:0000 Bus 002 Device 003: ID 413c:2003 Dell Computer Corp. Bus 002 Device 002: ID 09ae:3012 Tripp Lite Bus 002 Device 001: ID 0000:0000>>> Kjell Claesson <kjell.claesson@epost.tidanet.se> 05/11/07 12:42 PM >>>Hi Lance, Can you do a lsusb So we get the product and vendor id. The driver seems only to support product-id 0001, so if your ups have 3012 as product id, it is a new version. Regards Kjell fre 2007-05-11 klockan 11:08 -0500 skrev Lance Thomas:> I'm working on a gentoo server with Nut 2.0.5-r1 and libusb-0.1.12. > I originally tried the hidups driver which seemed to work, butproduced> a large amount of unhandled events. Then I tried the newhidups which > told me my ups wasn't supported. When I try using > > tripplite_usb -u root -DDDD /proc/bus/usb/002/002 > > I get that there isn't a match. But when I try using > > tripplite_usb -DDDD -a tripplite1 > > with the following ups.conf: > [tripplite1] > driver = tripplite_usb > port = /proc/bus/usb/002/002 > productid = 3012 > bus = 002 > desc = "top ups" > > I get it to run and find the HID, but it returns the following errors > before quitting: > Detected a UPS: Tripp Lite /TRIPP LITE SMART2200RMXL2U > send_cmd(msg_len=3, type='W') > libusb_get_interrupt() returned 4 instead of 8 > libusb_get_interrupt() returned 4 instead of 8 > libusb_get_interrupt() returned 4 instead of 8 > libusb_get_interrupt() returned 4 instead of 8 > libusb_get_interrupt() returned 4 instead of 8 > libusb_get_interrupt() returned 4 instead of 8 > libusb_get_interrupt() returned 4 instead of 8 > libusb_get_interrupt() returned 4 instead of 8 > libusb_get_interrupt() returned 4 instead of 8 > send_cmd: send_try = 3, recv_try = 3 > > Could not reset watchdog. Please send model information to nut-upsdev > mailing list > send_cmd(msg_len=2, type=' > libusb_get_interrupt() returned 4 instead of 8 > libusb_get_interrupt() returned 4 instead of 8 > libusb_get_interrupt() returned 4 instead of 8 > libusb_get_interrupt() returned 4 instead of 8 > libusb_get_interrupt() returned 4 instead of 8 > libusb_get_interrupt() returned 4 instead of 8 > libusb_get_interrupt() returned 4 instead of 8 > libusb_get_interrupt() returned 4 instead of 8 > libusb_get_interrupt() returned 4 instead of 8 > send_cmd: send_try = 3, recv_try = 3 > > Error reading protocol > > > Any suggestions? > ____________________________________________________________________ > > This email and any attachments may contain confidential informationand is> solely for the intended recipient(s). Email communications are notconsidered> secure. If you are not the intended recipient(s) of this email youare expected> to disregard the content, delete the message and notify the originalsender.> > --University of Wisconsin, Department of Family Medicine-- > ____________________________________________________________________ > > **UW DFM** > > > _______________________________________________ > Nut-upsdev mailing list > Nut-upsdev@lists.alioth.debian.org > http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev_______________________________________________ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Kjell Claesson
2007-May-11 18:40 UTC
[Nut-upsdev] tripp lite smart2200RMXL2U error reading protocol
OK Lance, This may indicate that we hit another type of protocol. It's not the same usb (even if the name is the same) that is named as compatible to this driver. see:http://lists.alioth.debian.org/pipermail/nut-upsuser/2006-September/001671.html Charles Lepple and Peter Selinger have much more experience of this drivers. So I think they going to give you more info about this. Regards Kjell fre 2007-05-11 klockan 13:13 -0500 skrev Lance Thomas:> Here's a shot of the lsusb > Bus 003 Device 002: ID 04b4:6560 Cypress Semiconductor Corp. CY7C65640 > USB-2.0 "TetraHub" > Bus 003 Device 001: ID 0000:0000 > Bus 001 Device 001: ID 0000:0000 > Bus 002 Device 003: ID 413c:2003 Dell Computer Corp. > Bus 002 Device 002: ID 09ae:3012 Tripp Lite > Bus 002 Device 001: ID 0000:0000 > > >>> Kjell Claesson <kjell.claesson@epost.tidanet.se> 05/11/07 12:42 PM > >>> > Hi Lance, > > Can you do a > > lsusb > > So we get the product and vendor id. The driver > seems only to support product-id 0001, so if your > ups have 3012 as product id, it is a new version. > > Regards > Kjell > > fre 2007-05-11 klockan 11:08 -0500 skrev Lance Thomas: > > I'm working on a gentoo server with Nut 2.0.5-r1 and libusb-0.1.12. > > I originally tried the hidups driver which seemed to work, but > produced > > a large amount of unhandled events. Then I tried the newhidups which > > told me my ups wasn't supported. When I try using > > > > tripplite_usb -u root -DDDD /proc/bus/usb/002/002 > > > > I get that there isn't a match. But when I try using > > > > tripplite_usb -DDDD -a tripplite1 > > > > with the following ups.conf: > > [tripplite1] > > driver = tripplite_usb > > port = /proc/bus/usb/002/002 > > productid = 3012 > > bus = 002 > > desc = "top ups" > > > > I get it to run and find the HID, but it returns the following errors > > before quitting: > > Detected a UPS: Tripp Lite /TRIPP LITE SMART2200RMXL2U > > send_cmd(msg_len=3, type='W') > > libusb_get_interrupt() returned 4 instead of 8 > > libusb_get_interrupt() returned 4 instead of 8 > > libusb_get_interrupt() returned 4 instead of 8 > > libusb_get_interrupt() returned 4 instead of 8 > > libusb_get_interrupt() returned 4 instead of 8 > > libusb_get_interrupt() returned 4 instead of 8 > > libusb_get_interrupt() returned 4 instead of 8 > > libusb_get_interrupt() returned 4 instead of 8 > > libusb_get_interrupt() returned 4 instead of 8 > > send_cmd: send_try = 3, recv_try = 3 > > > > Could not reset watchdog. Please send model information to nut-upsdev > > mailing list > > send_cmd(msg_len=2, type=' > > libusb_get_interrupt() returned 4 instead of 8 > > libusb_get_interrupt() returned 4 instead of 8 > > libusb_get_interrupt() returned 4 instead of 8 > > libusb_get_interrupt() returned 4 instead of 8 > > libusb_get_interrupt() returned 4 instead of 8 > > libusb_get_interrupt() returned 4 instead of 8 > > libusb_get_interrupt() returned 4 instead of 8 > > libusb_get_interrupt() returned 4 instead of 8 > > libusb_get_interrupt() returned 4 instead of 8 > > send_cmd: send_try = 3, recv_try = 3 > > > > Error reading protocol > > > > > > Any suggestions? > > ____________________________________________________________________ > > > > This email and any attachments may contain confidential information > and is > > solely for the intended recipient(s). Email communications are not > considered > > secure. If you are not the intended recipient(s) of this email you > are expected > > to disregard the content, delete the message and notify the original > sender. > > > > --University of Wisconsin, Department of Family Medicine-- > > ____________________________________________________________________ > > > > **UW DFM** > > > > > > _______________________________________________ > > Nut-upsdev mailing list > > Nut-upsdev@lists.alioth.debian.org > > http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev > > > _______________________________________________ > Nut-upsdev mailing list > Nut-upsdev@lists.alioth.debian.org > http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev > > >
Charles Lepple
2007-May-14 14:00 UTC
[Nut-upsdev] tripp lite smart2200RMXL2U error reading protocol
Lance sent me the output of "lsusb -vvv" for this device off-list, and
here is the key portion of that:
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.10
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 1121
Report Descriptor: (length is 1121)
Item(Global): Usage Page, data= [ 0x84 ] 132
Power Device Page
Item(Local ): Usage, data= [ 0x04 ] 4
UPS
Item(Main ): Collection, data= [ 0x01 ] 1
Application
Item(Local ): Usage, data= [ 0x24 ] 36
Power Summary
Item(Main ): Collection, data= [ 0x00 ] 0
Physical
Item(Global): Usage Page, data= [ 0x84 ] 132
Power Device Page
As Kjell mentioned, this looks like another one of those cases where
the innards of the UPS got an overhaul, but they kept the model name.
Lance: I forget, did you try the newhidups driver as well? That's the
one that should eventually support this UPS (tripplite_usb only
handles the older serial-protocol-over-USB models).
You may have to pass the manufacturer and model options to newhidups
as well, since we were not aware of this alternate vendor/product ID
for this model of UPS.
On 5/11/07, Lance Thomas <Lance.Thomas at fammed.wisc.edu>
wrote:> I'm working on a gentoo server with Nut 2.0.5-r1 and libusb-0.1.12.
> I originally tried the hidups driver which seemed to work, but produced
> a large amount of unhandled events. Then I tried the newhidups which
> told me my ups wasn't supported. When I try using
>
> tripplite_usb -u root -DDDD /proc/bus/usb/002/002
>
> I get that there isn't a match. But when I try using
>
> tripplite_usb -DDDD -a tripplite1
>
> with the following ups.conf:
> [tripplite1]
> driver = tripplite_usb
> port = /proc/bus/usb/002/002
> productid = 3012
> bus = 002
> desc = "top ups"
>
> I get it to run and find the HID, but it returns the following errors
> before quitting:
> Detected a UPS: Tripp Lite /TRIPP LITE SMART2200RMXL2U
> send_cmd(msg_len=3, type='W')
> libusb_get_interrupt() returned 4 instead of 8
> libusb_get_interrupt() returned 4 instead of 8
> libusb_get_interrupt() returned 4 instead of 8
> libusb_get_interrupt() returned 4 instead of 8
> libusb_get_interrupt() returned 4 instead of 8
> libusb_get_interrupt() returned 4 instead of 8
> libusb_get_interrupt() returned 4 instead of 8
> libusb_get_interrupt() returned 4 instead of 8
> libusb_get_interrupt() returned 4 instead of 8
> send_cmd: send_try = 3, recv_try = 3
>
> Could not reset watchdog. Please send model information to nut-upsdev
> mailing list
> send_cmd(msg_len=2, type='
> libusb_get_interrupt() returned 4 instead of 8
> libusb_get_interrupt() returned 4 instead of 8
> libusb_get_interrupt() returned 4 instead of 8
> libusb_get_interrupt() returned 4 instead of 8
> libusb_get_interrupt() returned 4 instead of 8
> libusb_get_interrupt() returned 4 instead of 8
> libusb_get_interrupt() returned 4 instead of 8
> libusb_get_interrupt() returned 4 instead of 8
> libusb_get_interrupt() returned 4 instead of 8
> send_cmd: send_try = 3, recv_try = 3
>
> Error reading protocol
>
>
> Any suggestions?
> ____________________________________________________________________
>
> This email and any attachments may contain confidential information and is
> solely for the intended recipient(s). Email communications are not
considered
> secure. If you are not the intended recipient(s) of this email you are
expected
> to disregard the content, delete the message and notify the original
sender.
>
> --University of Wisconsin, Department of Family Medicine--
> ____________________________________________________________________
>
> **UW DFM**
>
>
> _______________________________________________
> Nut-upsdev mailing list
> Nut-upsdev at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
>
--
- Charles Lepple
Lance Thomas
2007-May-14 14:28 UTC
[Nut-upsdev] tripp lite smart2200RMXL2U error reading protocol
I tried the newhidups with the command:
newhidups -u root -DDDD -x vendorid=09ae -x productid=3012 auto
and it goes through finds the ups and tells me that this particular
Tripp Lite device (09ae/3012) is not supported. And then to try the
tripplite_usb.
I forgot to mention that when we got this tripplite we took the standard
NEMA 5-20P input plug off and are using the NEMA 5-15P plug instead. I
don't think that would make a difference, but I thought I'd mention it
just in case.
----
Lance sent me the output of "lsusb -vvv" for this device off-list, and
here is the key portion of that:
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.10
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 1121
Report Descriptor: (length is 1121)
Item(Global): Usage Page, data= [ 0x84 ] 132
Power Device Page
Item(Local ): Usage, data= [ 0x04 ] 4
UPS
Item(Main ): Collection, data= [ 0x01 ] 1
Application
Item(Local ): Usage, data= [ 0x24 ] 36
Power Summary
Item(Main ): Collection, data= [ 0x00 ] 0
Physical
Item(Global): Usage Page, data= [ 0x84 ] 132
Power Device Page
As Kjell mentioned, this looks like another one of those cases where
the innards of the UPS got an overhaul, but they kept the model name.
Lance: I forget, did you try the newhidups driver as well? That's the
one that should eventually support this UPS (tripplite_usb only
handles the older serial-protocol-over-USB models).
You may have to pass the manufacturer and model options to newhidups
as well, since we were not aware of this alternate vendor/product ID
for this model of UPS.
On 5/11/07, Lance Thomas <Lance.Thomas at fammed.wisc.edu>
wrote:> I'm working on a gentoo server with Nut 2.0.5-r1 and libusb-0.1.12.
> I originally tried the hidups driver which seemed to work, but
produced> a large amount of unhandled events. Then I tried the newhidups which
> told me my ups wasn't supported. When I try using
>
> tripplite_usb -u root -DDDD /proc/bus/usb/002/002
>
> I get that there isn't a match. But when I try using
>
> tripplite_usb -DDDD -a tripplite1
>
> with the following ups.conf:
> [tripplite1]
> driver = tripplite_usb
> port = /proc/bus/usb/002/002
> productid = 3012
> bus = 002
> desc = "top ups"
>
> I get it to run and find the HID, but it returns the following errors
> before quitting:
> Detected a UPS: Tripp Lite /TRIPP LITE SMART2200RMXL2U
> send_cmd(msg_len=3, type='W')
> libusb_get_interrupt() returned 4 instead of 8
> libusb_get_interrupt() returned 4 instead of 8
> libusb_get_interrupt() returned 4 instead of 8
> libusb_get_interrupt() returned 4 instead of 8
> libusb_get_interrupt() returned 4 instead of 8
> libusb_get_interrupt() returned 4 instead of 8
> libusb_get_interrupt() returned 4 instead of 8
> libusb_get_interrupt() returned 4 instead of 8
> libusb_get_interrupt() returned 4 instead of 8
> send_cmd: send_try = 3, recv_try = 3
>
> Could not reset watchdog. Please send model information to nut-upsdev
> mailing list
> send_cmd(msg_len=2, type='
> libusb_get_interrupt() returned 4 instead of 8
> libusb_get_interrupt() returned 4 instead of 8
> libusb_get_interrupt() returned 4 instead of 8
> libusb_get_interrupt() returned 4 instead of 8
> libusb_get_interrupt() returned 4 instead of 8
> libusb_get_interrupt() returned 4 instead of 8
> libusb_get_interrupt() returned 4 instead of 8
> libusb_get_interrupt() returned 4 instead of 8
> libusb_get_interrupt() returned 4 instead of 8
> send_cmd: send_try = 3, recv_try = 3
>
> Error reading protocol
>
>
> Any suggestions?
> ____________________________________________________________________
>
> This email and any attachments may contain confidential information
and is> solely for the intended recipient(s). Email communications are not
considered> secure. If you are not the intended recipient(s) of this email you
are expected> to disregard the content, delete the message and notify the original
sender.>
> --University of Wisconsin, Department of Family Medicine--
> ____________________________________________________________________
>
> **UW DFM**
>
>
> _______________________________________________
> Nut-upsdev mailing list
> Nut-upsdev at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
>
--
- Charles Lepple
_______________________________________________
Nut-upsdev mailing list
Nut-upsdev at lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Charles Lepple
2007-May-14 14:47 UTC
[Nut-upsdev] tripp lite smart2200RMXL2U error reading protocol
On 5/14/07, Lance Thomas <Lance.Thomas at fammed.wisc.edu> wrote:> I tried the newhidups with the command: > newhidups -u root -DDDD -x vendorid=09ae -x productid=3012 auto > > and it goes through finds the ups and tells me that this particular > Tripp Lite device (09ae/3012) is not supported. And then to try the > tripplite_usb.If you're comfortable poking around the source code, you could add another case to drivers/tripplite-hid.c (~ line 205) to check for your product ID (0x3012). Not sure how hard that is to work into the Gentoo package, but I imagine someone here could help if you get stuck. There still may be some other adjustments needed to the driver, but this will let us see the debug output from the tripplite-hid.c/h files.> I forgot to mention that when we got this tripplite we took the standard > NEMA 5-20P input plug off and are using the NEMA 5-15P plug instead. I > don't think that would make a difference, but I thought I'd mention it > just in case.I am not sure if the UPS can identify the plug type in its status messages. -- - Charles Lepple
Lance Thomas
2007-May-14 15:41 UTC
[Nut-upsdev] tripp lite smart2200RMXL2U error reading protocol
I'll look into the newest svn of nut. Here is the output from: newhidups -u root -x vendorid=09ae -x explore auto Detected a UPS: Tripp Lite /TRIPP LITE SMART2200RMXL2U Using subdriver: EXPLORE HID 0.1 Path: UPS.PowerSummary.iProduct, Type: Feature, Value: 2.000000 Path: UPS.PowerSummary.iSerialNumber, Type: Feature, Value: 3.000000 Path: UPS.PowerSummary.iManufacturer, Type: Feature, Value: 1.000000 Path: UPS.PowerSummary.Input.ConfigVoltage, Type: Feature, Value: 120.000000 Path: UPS.PowerSummary.Input.Voltage, Type: Feature, Value: 125.599998 Path: UPS.PowerSummary.AudibleAlarmControl, Type: Feature, Value: 2.000000 Path: UPS.PowerSummary.iDeviceChemistry, Type: Feature, Value: 4.000000 Path: UPS.PowerSummary.iOEMInformation, Type: Feature, Value: 1.000000 Path: UPS.PowerSummary.CapacityMode, Type: Feature, Value: 2.000000 Path: UPS.PowerSummary.RemainingCapacity, Type: Input, Value: 100.000000 Path: UPS.PowerSummary.RemainingCapacity, Type: Feature, Value: 100.000000 Path: UPS.PowerSummary.RemainingCapacityLimit, Type: Feature, Value: 10.000000 Path: UPS.PowerSummary.FullChargeCapacity, Type: Feature, Value: 100.000000 Path: UPS.PowerSummary.DesignCapacity, Type: Feature, Value: 100.000000 Path: UPS.PowerSummary.WarningCapacityLimit, Type: Feature, Value: 30.000000 Path: UPS.PowerSummary.CapacityGranularity1, Type: Feature, Value: 1.000000 Path: UPS.PowerSummary.CapacityGranularity2, Type: Feature, Value: 1.000000 Path: UPS.PowerSummary.Rechargeable, Type: Feature, Value: 1.000000 Path: UPS.PowerSummary.PresentStatus., Type: Input Path: UPS.PowerSummary.PresentStatus., Type: Input Path: UPS.PowerSummary.PresentStatus., Type: Input Path: UPS.PowerSummary.PresentStatus., Type: Input Path: UPS.PowerSummary.PresentStatus., Type: Input Path: UPS.PowerSummary.PresentStatus., Type: Input Path: UPS.PowerSummary.PresentStatus., Type: Input Path: UPS.PowerSummary.PresentStatus.InternalFailure, Type: Input, Value: 0.000000 Path: UPS.PowerSummary.PresentStatus., Type: Input Path: UPS.PowerSummary.PresentStatus.ShutdownImminent, Type: Input, Value: 0.000000 Path: UPS.PowerSummary.PresentStatus., Type: Input Path: UPS.PowerSummary.PresentStatus., Type: Input Path: UPS.PowerSummary.PresentStatus., Type: Input Path: UPS.PowerSummary.PresentStatus., Type: Input Path: UPS.PowerSummary.PresentStatus., Type: Input Path: UPS.PowerSummary.PresentStatus., Type: Input Path: UPS.PowerSummary.PresentStatus.ACPresent, Type: Input, Value: 1.000000 Path: UPS.PowerSummary.PresentStatus., Type: Input Path: UPS.PowerSummary.PresentStatus.BelowRemainingCapacityLimit, Type: Input, Value: 0.000000 Path: UPS.PowerSummary.PresentStatus.FullyCharged, Type: Input, Value: 1.000000 Path: UPS.PowerSummary.PresentStatus.Charging, Type: Input, Value: 0.000000 Path: UPS.PowerSummary.PresentStatus.Discharging, Type: Input, Value: 0.000000 Path: UPS.PowerSummary.PresentStatus.FullyDischarged, Type: Input, Value: 0.000000 Path: UPS.PowerSummary.PresentStatus.NeedReplacement, Type: Input, Value: 0.000000 Path: UPS.PowerSummary.PresentStatus., Type: Feature Path: UPS.PowerSummary.PresentStatus., Type: Feature Path: UPS.PowerSummary.PresentStatus., Type: Feature Path: UPS.PowerSummary.PresentStatus., Type: Feature Path: UPS.PowerSummary.PresentStatus., Type: Feature Path: UPS.PowerSummary.PresentStatus., Type: Feature Path: UPS.PowerSummary.PresentStatus., Type: Feature Path: UPS.PowerSummary.PresentStatus.InternalFailure, Type: Feature, Value: 0.000000 Path: UPS.PowerSummary.PresentStatus., Type: Feature Path: UPS.PowerSummary.PresentStatus.ShutdownImminent, Type: Feature, Value: 0.000000 Path: UPS.PowerSummary.PresentStatus., Type: Feature Path: UPS.PowerSummary.PresentStatus., Type: Feature Path: UPS.PowerSummary.PresentStatus., Type: Feature Path: UPS.PowerSummary.PresentStatus., Type: Feature Path: UPS.PowerSummary.PresentStatus., Type: Feature Path: UPS.PowerSummary.PresentStatus., Type: Feature Path: UPS.PowerSummary.PresentStatus.ACPresent, Type: Feature, Value: 1.000000 Path: UPS.PowerSummary.PresentStatus., Type: Feature Path: UPS.PowerSummary.PresentStatus.BelowRemainingCapacityLimit, Type: Feature, Value: 0.000000 Path: UPS.PowerSummary.PresentStatus.FullyCharged, Type: Feature, Value: 1.000000 Path: UPS.PowerSummary.PresentStatus.Charging, Type: Feature, Value: 0.000000 Path: UPS.PowerSummary.PresentStatus.Discharging, Type: Feature, Value: 0.000000 Path: UPS.PowerSummary.PresentStatus.FullyDischarged, Type: Feature, Value: 0.000000 Path: UPS.PowerSummary.PresentStatus.NeedReplacement, Type: Feature, Value: 0.000000 Path: UPS.BatterySystem.Battery.ConfigVoltage, Type: Feature, Value: 48.000000 Path: UPS.BatterySystem.Battery.Voltage, Type: Feature, Value: 54.299999 Path: UPS.BatterySystem.Battery.PresentStatus., Type: Feature Path: UPS.BatterySystem.Battery.PresentStatus., Type: Feature Path: UPS.BatterySystem.Battery.PresentStatus.BelowRemainingCapacityLimit, Type: Feature Path: UPS.BatterySystem.Battery.PresentStatus.FullyCharged, Type: Feature, Value: 0.000000 Path: UPS.BatterySystem.Battery.PresentStatus.Charging, Type: Feature, Value: 1.000000 Path: UPS.BatterySystem.Battery.PresentStatus.Discharging, Type: Feature, Value: 0.000000 Path: UPS.BatterySystem.Battery.PresentStatus.FullyDischarged, Type: Feature, Value: 0.000000 Path: UPS.BatterySystem.Battery.PresentStatus.NeedReplacement, Type: Feature, Value: 0.000000 Path: UPS.BatterySystem.Battery.RemainingCapacity, Type: Feature, Value: 100.000000 Path: UPS.BatterySystem.Test, Type: Feature, Value: 0.000000 Path: UPS.BatterySystem.Temperature, Type: Feature, Value: 307.000000 Path: UPS.Flow.ConfigVoltage, Type: Feature, Value: 120.000000 Path: UPS.Flow.ConfigFrequency, Type: Feature, Value: 60.000000 Path: UPS.Flow.ffff0097, Type: Feature, Value: 0.000000 Path: UPS.Flow.ConfigApparentPower, Type: Feature, Value: 2200.000000 Path: UPS.PowerConverter.Input.Voltage, Type: Feature, Value: 125.099998 Path: UPS.PowerConverter.Input.Frequency, Type: Feature, Value: 59.900002 Path: UPS.PowerConverter.Output.Voltage, Type: Feature, Value: 125.599998 Path: UPS.PowerConverter.Output.Frequency, Type: Feature, Value: 59.900002 Path: UPS.PowerConverter.Output.LowVoltageTransfer, Type: Feature, Value: 83.000000 Path: UPS.PowerConverter.Output.HighVoltageTransfer, Type: Feature, Value: 145.000000 Path: UPS.PowerConverter.PresentStatus.VoltageOutOfRange, Type: Feature, Value: 0.000000 Path: UPS.PowerConverter.PresentStatus.Buck, Type: Feature, Value: 0.000000 Path: UPS.PowerConverter.PresentStatus.Boost, Type: Feature, Value: 0.000000 Path: UPS.PowerConverter.PresentStatus., Type: Feature Path: UPS.PowerConverter.PresentStatus.Overload, Type: Feature, Value: 0.000000 Path: UPS.PowerConverter.PresentStatus.Used, Type: Feature, Value: 1.000000 Path: UPS.PowerConverter.PresentStatus.OverTemperature, Type: Feature, Value: 0.000000 Path: UPS.PowerConverter.PresentStatus.InternalFailure, Type: Feature, Value: 0.000000 Path: UPS.PowerConverter.PresentStatus., Type: Feature Path: UPS.PowerConverter.PresentStatus., Type: Feature Path: UPS.PowerConverter.PresentStatus., Type: Feature Path: UPS.PowerConverter.PresentStatus., Type: Feature Path: UPS.PowerConverter.PresentStatus., Type: Feature Path: UPS.PowerConverter.PresentStatus., Type: Feature Path: UPS.PowerConverter.PresentStatus.AwaitingPower, Type: Feature, Value: 0.000000 Path: UPS.PowerConverter.PresentStatus., Type: Feature Path: UPS.OutletSystem.Outlet.DelayBeforeShutdown, Type: Feature, Value: -1.000000 Path: UPS.OutletSystem.Outlet.DelayBeforeStartup, Type: Feature, Value: -1.000000 Path: UPS.OutletSystem.Outlet.DelayBeforeReboot, Type: Feature, Value: -1.000000 Path: UPS.OutletSystem.Outlet.PercentLoad, Type: Feature, Value: 43.000000 Path: UPS.OutletSystem.Outlet.ffff0056, Type: Feature, Value: -1.000000 Path: UPS.OutletSystem.Outlet.ffff0081, Type: Feature, Value: 0.000000 Path: UPS.OutletSystem.Outlet.ffff0091, Type: Feature, Value: 0.000000 Path: UPS.OutletSystem.Outlet.ffff0092, Type: Feature, Value: 0.000000 Path: UPS.OutletSystem.Outlet.ffff0093, Type: Feature, Value: 0.000000 Path: UPS.OutletSystem.Outlet.ffff0095, Type: Feature, Value: 7.000000 Path: UPS.OutletSystem.Outlet.ffff0096, Type: Feature, Value: 7.000000 Path: UPS.OutletSystem.Outlet.ffff0098, Type: Feature, Value: 0.000000 Can't retrieve Report 106 (25): Inappropriate ioctl for device Path: UPS.OutletSystem.Outlet.ffff0099, Type: Feature Can't retrieve Report 107 (25): Inappropriate ioctl for device Path: UPS.OutletSystem.Outlet.ffff009a, Type: Feature Path: UPS.OutletSystem.Outlet.ffff00a7, Type: Feature, Value: 0.000000 Path: UPS.OutletSystem.Outlet.ffff00a9, Type: Feature, Value: 0.000000 Path: UPS.OutletSystem.Outlet.ffff00a2, Type: Feature, Value: 0.000000 Can't retrieve Report 124 (25): Inappropriate ioctl for device Path: UPS.OutletSystem.Outlet.ffff00a8, Type: Feature Can't retrieve Report 114 (25): Inappropriate ioctl for device Path: UPS.OutletSystem.Outlet.ffff00a0, Type: Feature Path: UPS.OutletSystem.Outlet.ffff00aa, Type: Feature, Value: 0.000000 Path: UPS.OutletSystem.Outlet.ffff00a4, Type: Feature, Value: 0.000000 Path: UPS.OutletSystem.Outlet.ffff00ab, Type: Feature, Value: 0.000000 Path: UPS.OutletSystem.Outlet.ffff00ac, Type: Feature, Value: 0.000000 Path: UPS.ffff0010[1].ffff0075, Type: Feature Path: UPS.ffff0010[1].ffff0076, Type: Feature Path: UPS.ffff0010[1].ffff007c, Type: Feature Path: UPS.ffff0010[1].ffff00e1, Type: Feature Path: UPS.ffff0010[1].ffff007d, Type: Feature Path: UPS.ffff0010[1].ffff00e0, Type: Feature Path: UPS.ffff0010[1].ffff00e2, Type: Feature Path: UPS.ffff0010[1].ffff00e3, Type: Feature Path: UPS.ffff0010[1].ffff00e4, Type: Feature Path: UPS.ffff0010[1].ffff00e5, Type: Feature Path: UPS.ffff0010[1].ffff00e6, Type: Feature Path: UPS.ffff0010[1].ffff00e7, Type: Feature Path: UPS.ffff0010[1].ffff00e8, Type: Feature Path: UPS.ffff0015[1].ffff00c0, Type: Feature Path: UPS.ffff0015[1].ffff00c2, Type: Feature Path: UPS.ffff0015[1].ffff00d2, Type: Feature Path: UPS.ffff0015[1].ffff00d3, Type: Feature Path: UPS.ffff0015[1].ffff00c1, Type: Feature Path: UPS.ffff0015[1].ffff00c3, Type: Feature Path: UPS.ffff0015[1].ffff00c5, Type: Feature Path: UPS.ffff0015[1].ffff00d6, Type: Feature Path: UPS.ffff0015[1].ffff00c4, Type: Feature upsdrv_updateinfo... dstate_init: sock /var/lib/nut/newhidups-auto open on fd 6 upsdrv_updateinfo... Waiting for notifications... =>Got 1 HID Objects... find_hid_info: unknown variable: UPS.PowerSummary.RemainingCapacity upsdrv_updateinfo... Waiting for notifications... =>Got 24 HID Objects... find_hid_info: unknown variable: UPS.PowerSummary.PresentStatus. find_hid_info: unknown variable: UPS.PowerSummary.PresentStatus.>>> Peter Selinger <selinger at mathstat.dal.ca> 05/14/07 9:43 AM >>>Lance Thomas wrote:> > I tried the newhidups with the command: > newhidups -u root -DDDD -x vendorid=09ae -x productid=3012 auto > > and it goes through finds the ups and tells me that this particular > Tripp Lite device (09ae/3012) is not supported. And then to try the > tripplite_usb.And then it asks you to report the results to the mailing list, which you have hereby done :) There are two things to do: (1) try the --explore option that Charles was talking about. This will not make the driver work, but it will generate sufficient debugging info for us to make the driver work. Please use -DD and not -DDDD, as the latter generates too much useless information. Please post the output. (2) If you can upgrade from 2.0.5 to a current SVN version of NUT (compiled from sources), then the driver might work directly. -- Peter> I forgot to mention that when we got this tripplite we took thestandard> NEMA 5-20P input plug off and are using the NEMA 5-15P plug instead.I> don't think that would make a difference, but I thought I'd mention it > just in case. > > ---- > Lance sent me the output of "lsusb -vvv" for this device off-list, and > here is the key portion of that: > > HID Device Descriptor: > bLength 9 > bDescriptorType 33 > bcdHID 1.10 > bCountryCode 0 Not supported > bNumDescriptors 1 > bDescriptorType 34 Report > wDescriptorLength 1121 > Report Descriptor: (length is 1121) > Item(Global): Usage Page, data= [ 0x84 ] 132 > Power Device Page > Item(Local ): Usage, data= [ 0x04 ] 4 > UPS > Item(Main ): Collection, data= [ 0x01 ] 1 > Application > Item(Local ): Usage, data= [ 0x24 ] 36 > Power Summary > Item(Main ): Collection, data= [ 0x00 ] 0 > Physical > Item(Global): Usage Page, data= [ 0x84 ] 132 > Power Device Page > > As Kjell mentioned, this looks like another one of those cases where > the innards of the UPS got an overhaul, but they kept the model name. > > Lance: I forget, did you try the newhidups driver as well? That's the > one that should eventually support this UPS (tripplite_usb only > handles the older serial-protocol-over-USB models). > > You may have to pass the manufacturer and model options to newhidups > as well, since we were not aware of this alternate vendor/product ID > for this model of UPS. > > On 5/11/07, Lance Thomas <Lance.Thomas at fammed.wisc.edu> wrote: > > I'm working on a gentoo server with Nut 2.0.5-r1 and libusb-0.1.12. > > I originally tried the hidups driver which seemed to work, but > produced > > a large amount of unhandled events. Then I tried the newhidupswhich> > told me my ups wasn't supported. When I try using > > > > tripplite_usb -u root -DDDD /proc/bus/usb/002/002 > > > > I get that there isn't a match. But when I try using > > > > tripplite_usb -DDDD -a tripplite1 > > > > with the following ups.conf: > > [tripplite1] > > driver = tripplite_usb > > port = /proc/bus/usb/002/002 > > productid = 3012 > > bus = 002 > > desc = "top ups" > > > > I get it to run and find the HID, but it returns the followingerrors> > before quitting: > > Detected a UPS: Tripp Lite /TRIPP LITE SMART2200RMXL2U > > send_cmd(msg_len=3, type='W') > > libusb_get_interrupt() returned 4 instead of 8 > > libusb_get_interrupt() returned 4 instead of 8 > > libusb_get_interrupt() returned 4 instead of 8 > > libusb_get_interrupt() returned 4 instead of 8 > > libusb_get_interrupt() returned 4 instead of 8 > > libusb_get_interrupt() returned 4 instead of 8 > > libusb_get_interrupt() returned 4 instead of 8 > > libusb_get_interrupt() returned 4 instead of 8 > > libusb_get_interrupt() returned 4 instead of 8 > > send_cmd: send_try = 3, recv_try = 3 > > > > Could not reset watchdog. Please send model information tonut-upsdev> > mailing list > > send_cmd(msg_len=2, type=' > > libusb_get_interrupt() returned 4 instead of 8 > > libusb_get_interrupt() returned 4 instead of 8 > > libusb_get_interrupt() returned 4 instead of 8 > > libusb_get_interrupt() returned 4 instead of 8 > > libusb_get_interrupt() returned 4 instead of 8 > > libusb_get_interrupt() returned 4 instead of 8 > > libusb_get_interrupt() returned 4 instead of 8 > > libusb_get_interrupt() returned 4 instead of 8 > > libusb_get_interrupt() returned 4 instead of 8 > > send_cmd: send_try = 3, recv_try = 3 > > > > Error reading protocol > > > > > > Any suggestions? > > ____________________________________________________________________ > > > > This email and any attachments may contain confidential information > and is > > solely for the intended recipient(s). Email communications are not > considered > > secure. If you are not the intended recipient(s) of this email you > are expected > > to disregard the content, delete the message and notify the original > sender. > > > > --University of Wisconsin, Department of Family Medicine-- > > ____________________________________________________________________ > > > > **UW DFM** > > > > > > _______________________________________________ > > Nut-upsdev mailing list > > Nut-upsdev at lists.alioth.debian.org > > http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev > > > > > -- > - Charles Lepple > > _______________________________________________ > Nut-upsdev mailing list > Nut-upsdev at lists.alioth.debian.org > http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev > > > > > _______________________________________________ > Nut-upsdev mailing list > Nut-upsdev at lists.alioth.debian.org > http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev >_______________________________________________ Nut-upsdev mailing list Nut-upsdev at lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
Peter Selinger
2007-May-14 16:16 UTC
[Nut-upsdev] tripp lite smart2200RMXL2U error reading protocol
OK, that is very similar to the other Tripplite-HID devices; the functionality of this device seems to be almost a superset of the OMNI1000LCD and of the SmartOnlineSU1500RTXL2ua. It should work without problems with the newhidups driver, if you just add the 0x3012 to the source code where Charles suggested. I have just done this in the latest SVN version (revision 901). Note that in SVN, the driver has been renamed to usbhid-ups from newhidups. -- Peter Lance Thomas wrote:> > I'll look into the newest svn of nut. > Here is the output from: > newhidups -u root -x vendorid=09ae -x explore auto > > Detected a UPS: Tripp Lite /TRIPP LITE SMART2200RMXL2U > Using subdriver: EXPLORE HID 0.1 > Path: UPS.PowerSummary.iProduct, Type: Feature, Value: 2.000000 > Path: UPS.PowerSummary.iSerialNumber, Type: Feature, Value: 3.000000 > Path: UPS.PowerSummary.iManufacturer, Type: Feature, Value: 1.000000 > Path: UPS.PowerSummary.Input.ConfigVoltage, Type: Feature, Value: > 120.000000 > Path: UPS.PowerSummary.Input.Voltage, Type: Feature, Value: 125.599998 > Path: UPS.PowerSummary.AudibleAlarmControl, Type: Feature, Value: > 2.000000 > Path: UPS.PowerSummary.iDeviceChemistry, Type: Feature, Value: 4.000000 > Path: UPS.PowerSummary.iOEMInformation, Type: Feature, Value: 1.000000 > Path: UPS.PowerSummary.CapacityMode, Type: Feature, Value: 2.000000 > Path: UPS.PowerSummary.RemainingCapacity, Type: Input, Value: 100.000000 > Path: UPS.PowerSummary.RemainingCapacity, Type: Feature, Value: > 100.000000 > Path: UPS.PowerSummary.RemainingCapacityLimit, Type: Feature, Value: > 10.000000 > Path: UPS.PowerSummary.FullChargeCapacity, Type: Feature, Value: > 100.000000 > Path: UPS.PowerSummary.DesignCapacity, Type: Feature, Value: 100.000000 > Path: UPS.PowerSummary.WarningCapacityLimit, Type: Feature, Value: > 30.000000 > Path: UPS.PowerSummary.CapacityGranularity1, Type: Feature, Value: > 1.000000 > Path: UPS.PowerSummary.CapacityGranularity2, Type: Feature, Value: > 1.000000 > Path: UPS.PowerSummary.Rechargeable, Type: Feature, Value: 1.000000 > Path: UPS.PowerSummary.PresentStatus., Type: Input > Path: UPS.PowerSummary.PresentStatus., Type: Input > Path: UPS.PowerSummary.PresentStatus., Type: Input > Path: UPS.PowerSummary.PresentStatus., Type: Input > Path: UPS.PowerSummary.PresentStatus., Type: Input > Path: UPS.PowerSummary.PresentStatus., Type: Input > Path: UPS.PowerSummary.PresentStatus., Type: Input > Path: UPS.PowerSummary.PresentStatus.InternalFailure, Type: Input, > Value: 0.000000 > Path: UPS.PowerSummary.PresentStatus., Type: Input > Path: UPS.PowerSummary.PresentStatus.ShutdownImminent, Type: Input, > Value: 0.000000 > Path: UPS.PowerSummary.PresentStatus., Type: Input > Path: UPS.PowerSummary.PresentStatus., Type: Input > Path: UPS.PowerSummary.PresentStatus., Type: Input > Path: UPS.PowerSummary.PresentStatus., Type: Input > Path: UPS.PowerSummary.PresentStatus., Type: Input > Path: UPS.PowerSummary.PresentStatus., Type: Input > Path: UPS.PowerSummary.PresentStatus.ACPresent, Type: Input, Value: > 1.000000 > Path: UPS.PowerSummary.PresentStatus., Type: Input > Path: UPS.PowerSummary.PresentStatus.BelowRemainingCapacityLimit, Type: > Input, Value: 0.000000 > Path: UPS.PowerSummary.PresentStatus.FullyCharged, Type: Input, Value: > 1.000000 > Path: UPS.PowerSummary.PresentStatus.Charging, Type: Input, Value: > 0.000000 > Path: UPS.PowerSummary.PresentStatus.Discharging, Type: Input, Value: > 0.000000 > Path: UPS.PowerSummary.PresentStatus.FullyDischarged, Type: Input, > Value: 0.000000 > Path: UPS.PowerSummary.PresentStatus.NeedReplacement, Type: Input, > Value: 0.000000 > Path: UPS.PowerSummary.PresentStatus., Type: Feature > Path: UPS.PowerSummary.PresentStatus., Type: Feature > Path: UPS.PowerSummary.PresentStatus., Type: Feature > Path: UPS.PowerSummary.PresentStatus., Type: Feature > Path: UPS.PowerSummary.PresentStatus., Type: Feature > Path: UPS.PowerSummary.PresentStatus., Type: Feature > Path: UPS.PowerSummary.PresentStatus., Type: Feature > Path: UPS.PowerSummary.PresentStatus.InternalFailure, Type: Feature, > Value: 0.000000 > Path: UPS.PowerSummary.PresentStatus., Type: Feature > Path: UPS.PowerSummary.PresentStatus.ShutdownImminent, Type: Feature, > Value: 0.000000 > Path: UPS.PowerSummary.PresentStatus., Type: Feature > Path: UPS.PowerSummary.PresentStatus., Type: Feature > Path: UPS.PowerSummary.PresentStatus., Type: Feature > Path: UPS.PowerSummary.PresentStatus., Type: Feature > Path: UPS.PowerSummary.PresentStatus., Type: Feature > Path: UPS.PowerSummary.PresentStatus., Type: Feature > Path: UPS.PowerSummary.PresentStatus.ACPresent, Type: Feature, Value: > 1.000000 > Path: UPS.PowerSummary.PresentStatus., Type: Feature > Path: UPS.PowerSummary.PresentStatus.BelowRemainingCapacityLimit, Type: > Feature, Value: 0.000000 > Path: UPS.PowerSummary.PresentStatus.FullyCharged, Type: Feature, Value: > 1.000000 > Path: UPS.PowerSummary.PresentStatus.Charging, Type: Feature, Value: > 0.000000 > Path: UPS.PowerSummary.PresentStatus.Discharging, Type: Feature, Value: > 0.000000 > Path: UPS.PowerSummary.PresentStatus.FullyDischarged, Type: Feature, > Value: 0.000000 > Path: UPS.PowerSummary.PresentStatus.NeedReplacement, Type: Feature, > Value: 0.000000 > Path: UPS.BatterySystem.Battery.ConfigVoltage, Type: Feature, Value: > 48.000000 > Path: UPS.BatterySystem.Battery.Voltage, Type: Feature, Value: 54.299999 > Path: UPS.BatterySystem.Battery.PresentStatus., Type: Feature > Path: UPS.BatterySystem.Battery.PresentStatus., Type: Feature > Path: > UPS.BatterySystem.Battery.PresentStatus.BelowRemainingCapacityLimit, > Type: Feature > Path: UPS.BatterySystem.Battery.PresentStatus.FullyCharged, Type: > Feature, Value: 0.000000 > Path: UPS.BatterySystem.Battery.PresentStatus.Charging, Type: Feature, > Value: 1.000000 > Path: UPS.BatterySystem.Battery.PresentStatus.Discharging, Type: > Feature, Value: 0.000000 > Path: UPS.BatterySystem.Battery.PresentStatus.FullyDischarged, Type: > Feature, Value: 0.000000 > Path: UPS.BatterySystem.Battery.PresentStatus.NeedReplacement, Type: > Feature, Value: 0.000000 > Path: UPS.BatterySystem.Battery.RemainingCapacity, Type: Feature, Value: > 100.000000 > Path: UPS.BatterySystem.Test, Type: Feature, Value: 0.000000 > Path: UPS.BatterySystem.Temperature, Type: Feature, Value: 307.000000 > Path: UPS.Flow.ConfigVoltage, Type: Feature, Value: 120.000000 > Path: UPS.Flow.ConfigFrequency, Type: Feature, Value: 60.000000 > Path: UPS.Flow.ffff0097, Type: Feature, Value: 0.000000 > Path: UPS.Flow.ConfigApparentPower, Type: Feature, Value: 2200.000000 > Path: UPS.PowerConverter.Input.Voltage, Type: Feature, Value: 125.099998 > Path: UPS.PowerConverter.Input.Frequency, Type: Feature, Value: > 59.900002 > Path: UPS.PowerConverter.Output.Voltage, Type: Feature, Value: > 125.599998 > Path: UPS.PowerConverter.Output.Frequency, Type: Feature, Value: > 59.900002 > Path: UPS.PowerConverter.Output.LowVoltageTransfer, Type: Feature, > Value: 83.000000 > Path: UPS.PowerConverter.Output.HighVoltageTransfer, Type: Feature, > Value: 145.000000 > Path: UPS.PowerConverter.PresentStatus.VoltageOutOfRange, Type: Feature, > Value: 0.000000 > Path: UPS.PowerConverter.PresentStatus.Buck, Type: Feature, Value: > 0.000000 > Path: UPS.PowerConverter.PresentStatus.Boost, Type: Feature, Value: > 0.000000 > Path: UPS.PowerConverter.PresentStatus., Type: Feature > Path: UPS.PowerConverter.PresentStatus.Overload, Type: Feature, Value: > 0.000000 > Path: UPS.PowerConverter.PresentStatus.Used, Type: Feature, Value: > 1.000000 > Path: UPS.PowerConverter.PresentStatus.OverTemperature, Type: Feature, > Value: 0.000000 > Path: UPS.PowerConverter.PresentStatus.InternalFailure, Type: Feature, > Value: 0.000000 > Path: UPS.PowerConverter.PresentStatus., Type: Feature > Path: UPS.PowerConverter.PresentStatus., Type: Feature > Path: UPS.PowerConverter.PresentStatus., Type: Feature > Path: UPS.PowerConverter.PresentStatus., Type: Feature > Path: UPS.PowerConverter.PresentStatus., Type: Feature > Path: UPS.PowerConverter.PresentStatus., Type: Feature > Path: UPS.PowerConverter.PresentStatus.AwaitingPower, Type: Feature, > Value: 0.000000 > Path: UPS.PowerConverter.PresentStatus., Type: Feature > Path: UPS.OutletSystem.Outlet.DelayBeforeShutdown, Type: Feature, Value: > -1.000000 > Path: UPS.OutletSystem.Outlet.DelayBeforeStartup, Type: Feature, Value: > -1.000000 > Path: UPS.OutletSystem.Outlet.DelayBeforeReboot, Type: Feature, Value: > -1.000000 > Path: UPS.OutletSystem.Outlet.PercentLoad, Type: Feature, Value: > 43.000000 > Path: UPS.OutletSystem.Outlet.ffff0056, Type: Feature, Value: -1.000000 > Path: UPS.OutletSystem.Outlet.ffff0081, Type: Feature, Value: 0.000000 > Path: UPS.OutletSystem.Outlet.ffff0091, Type: Feature, Value: 0.000000 > Path: UPS.OutletSystem.Outlet.ffff0092, Type: Feature, Value: 0.000000 > Path: UPS.OutletSystem.Outlet.ffff0093, Type: Feature, Value: 0.000000 > Path: UPS.OutletSystem.Outlet.ffff0095, Type: Feature, Value: 7.000000 > Path: UPS.OutletSystem.Outlet.ffff0096, Type: Feature, Value: 7.000000 > Path: UPS.OutletSystem.Outlet.ffff0098, Type: Feature, Value: 0.000000 > Can't retrieve Report 106 (25): Inappropriate ioctl for device > Path: UPS.OutletSystem.Outlet.ffff0099, Type: Feature > Can't retrieve Report 107 (25): Inappropriate ioctl for device > Path: UPS.OutletSystem.Outlet.ffff009a, Type: Feature > Path: UPS.OutletSystem.Outlet.ffff00a7, Type: Feature, Value: 0.000000 > Path: UPS.OutletSystem.Outlet.ffff00a9, Type: Feature, Value: 0.000000 > Path: UPS.OutletSystem.Outlet.ffff00a2, Type: Feature, Value: 0.000000 > Can't retrieve Report 124 (25): Inappropriate ioctl for device > Path: UPS.OutletSystem.Outlet.ffff00a8, Type: Feature > Can't retrieve Report 114 (25): Inappropriate ioctl for device > Path: UPS.OutletSystem.Outlet.ffff00a0, Type: Feature > Path: UPS.OutletSystem.Outlet.ffff00aa, Type: Feature, Value: 0.000000 > Path: UPS.OutletSystem.Outlet.ffff00a4, Type: Feature, Value: 0.000000 > Path: UPS.OutletSystem.Outlet.ffff00ab, Type: Feature, Value: 0.000000 > Path: UPS.OutletSystem.Outlet.ffff00ac, Type: Feature, Value: 0.000000 > Path: UPS.ffff0010[1].ffff0075, Type: Feature > Path: UPS.ffff0010[1].ffff0076, Type: Feature > Path: UPS.ffff0010[1].ffff007c, Type: Feature > Path: UPS.ffff0010[1].ffff00e1, Type: Feature > Path: UPS.ffff0010[1].ffff007d, Type: Feature > Path: UPS.ffff0010[1].ffff00e0, Type: Feature > Path: UPS.ffff0010[1].ffff00e2, Type: Feature > Path: UPS.ffff0010[1].ffff00e3, Type: Feature > Path: UPS.ffff0010[1].ffff00e4, Type: Feature > Path: UPS.ffff0010[1].ffff00e5, Type: Feature > Path: UPS.ffff0010[1].ffff00e6, Type: Feature > Path: UPS.ffff0010[1].ffff00e7, Type: Feature > Path: UPS.ffff0010[1].ffff00e8, Type: Feature > Path: UPS.ffff0015[1].ffff00c0, Type: Feature > Path: UPS.ffff0015[1].ffff00c2, Type: Feature > Path: UPS.ffff0015[1].ffff00d2, Type: Feature > Path: UPS.ffff0015[1].ffff00d3, Type: Feature > Path: UPS.ffff0015[1].ffff00c1, Type: Feature > Path: UPS.ffff0015[1].ffff00c3, Type: Feature > Path: UPS.ffff0015[1].ffff00c5, Type: Feature > Path: UPS.ffff0015[1].ffff00d6, Type: Feature > Path: UPS.ffff0015[1].ffff00c4, Type: Feature > upsdrv_updateinfo... > dstate_init: sock /var/lib/nut/newhidups-auto open on fd 6 > upsdrv_updateinfo... > Waiting for notifications... > > =>Got 1 HID Objects... > find_hid_info: unknown variable: UPS.PowerSummary.RemainingCapacity > > upsdrv_updateinfo... > Waiting for notifications... > > =>Got 24 HID Objects... > find_hid_info: unknown variable: UPS.PowerSummary.PresentStatus. > > find_hid_info: unknown variable: UPS.PowerSummary.PresentStatus. > > > >>> Peter Selinger <selinger at mathstat.dal.ca> 05/14/07 9:43 AM >>> > Lance Thomas wrote: > > > > I tried the newhidups with the command: > > newhidups -u root -DDDD -x vendorid=09ae -x productid=3012 auto > > > > and it goes through finds the ups and tells me that this particular > > Tripp Lite device (09ae/3012) is not supported. And then to try the > > tripplite_usb. > > And then it asks you to report the results to the mailing list, which > you have hereby done :) > > There are two things to do: > > (1) try the --explore option that Charles was talking about. This will > not make the driver work, but it will generate sufficient debugging > info for us to make the driver work. Please use -DD and not -DDDD, > as the latter generates too much useless information. Please post > the output. > > (2) If you can upgrade from 2.0.5 to a current SVN version of NUT > (compiled from sources), then the driver might work directly. > > -- Peter > > > I forgot to mention that when we got this tripplite we took the > standard > > NEMA 5-20P input plug off and are using the NEMA 5-15P plug instead. > I > > don't think that would make a difference, but I thought I'd mention it > > just in case. > > > > ---- > > Lance sent me the output of "lsusb -vvv" for this device off-list, and > > here is the key portion of that: > > > > HID Device Descriptor: > > bLength 9 > > bDescriptorType 33 > > bcdHID 1.10 > > bCountryCode 0 Not supported > > bNumDescriptors 1 > > bDescriptorType 34 Report > > wDescriptorLength 1121 > > Report Descriptor: (length is 1121) > > Item(Global): Usage Page, data= [ 0x84 ] 132 > > Power Device Page > > Item(Local ): Usage, data= [ 0x04 ] 4 > > UPS > > Item(Main ): Collection, data= [ 0x01 ] 1 > > Application > > Item(Local ): Usage, data= [ 0x24 ] 36 > > Power Summary > > Item(Main ): Collection, data= [ 0x00 ] 0 > > Physical > > Item(Global): Usage Page, data= [ 0x84 ] 132 > > Power Device Page > > > > As Kjell mentioned, this looks like another one of those cases where > > the innards of the UPS got an overhaul, but they kept the model name. > > > > Lance: I forget, did you try the newhidups driver as well? That's the > > one that should eventually support this UPS (tripplite_usb only > > handles the older serial-protocol-over-USB models). > > > > You may have to pass the manufacturer and model options to newhidups > > as well, since we were not aware of this alternate vendor/product ID > > for this model of UPS. > > > > On 5/11/07, Lance Thomas <Lance.Thomas at fammed.wisc.edu> wrote: > > > I'm working on a gentoo server with Nut 2.0.5-r1 and libusb-0.1.12. > > > I originally tried the hidups driver which seemed to work, but > > produced > > > a large amount of unhandled events. Then I tried the newhidups > which > > > told me my ups wasn't supported. When I try using > > > > > > tripplite_usb -u root -DDDD /proc/bus/usb/002/002 > > > > > > I get that there isn't a match. But when I try using > > > > > > tripplite_usb -DDDD -a tripplite1 > > > > > > with the following ups.conf: > > > [tripplite1] > > > driver = tripplite_usb > > > port = /proc/bus/usb/002/002 > > > productid = 3012 > > > bus = 002 > > > desc = "top ups" > > > > > > I get it to run and find the HID, but it returns the following > errors > > > before quitting: > > > Detected a UPS: Tripp Lite /TRIPP LITE SMART2200RMXL2U > > > send_cmd(msg_len=3, type='W') > > > libusb_get_interrupt() returned 4 instead of 8 > > > libusb_get_interrupt() returned 4 instead of 8 > > > libusb_get_interrupt() returned 4 instead of 8 > > > libusb_get_interrupt() returned 4 instead of 8 > > > libusb_get_interrupt() returned 4 instead of 8 > > > libusb_get_interrupt() returned 4 instead of 8 > > > libusb_get_interrupt() returned 4 instead of 8 > > > libusb_get_interrupt() returned 4 instead of 8 > > > libusb_get_interrupt() returned 4 instead of 8 > > > send_cmd: send_try = 3, recv_try = 3 > > > > > > Could not reset watchdog. Please send model information to > nut-upsdev > > > mailing list > > > send_cmd(msg_len=2, type=' > > > libusb_get_interrupt() returned 4 instead of 8 > > > libusb_get_interrupt() returned 4 instead of 8 > > > libusb_get_interrupt() returned 4 instead of 8 > > > libusb_get_interrupt() returned 4 instead of 8 > > > libusb_get_interrupt() returned 4 instead of 8 > > > libusb_get_interrupt() returned 4 instead of 8 > > > libusb_get_interrupt() returned 4 instead of 8 > > > libusb_get_interrupt() returned 4 instead of 8 > > > libusb_get_interrupt() returned 4 instead of 8 > > > send_cmd: send_try = 3, recv_try = 3 > > > > > > Error reading protocol > > > > > > > > > Any suggestions? > > > ____________________________________________________________________ > > > > > > This email and any attachments may contain confidential information > > and is > > > solely for the intended recipient(s). Email communications are not > > considered > > > secure. If you are not the intended recipient(s) of this email you > > are expected > > > to disregard the content, delete the message and notify the original > > sender. > > > > > > --University of Wisconsin, Department of Family Medicine-- > > > ____________________________________________________________________ > > > > > > **UW DFM** > > > > > > > > > _______________________________________________ > > > Nut-upsdev mailing list > > > Nut-upsdev at lists.alioth.debian.org > > > http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev > > > > > > > > > -- > > - Charles Lepple > > > > _______________________________________________ > > Nut-upsdev mailing list > > Nut-upsdev at lists.alioth.debian.org > > http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev > > > > > > > > > > _______________________________________________ > > Nut-upsdev mailing list > > Nut-upsdev at lists.alioth.debian.org > > http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev > > > > > _______________________________________________ > Nut-upsdev mailing list > Nut-upsdev at lists.alioth.debian.org > http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev > > >
Lance Thomas
2007-May-14 17:18 UTC
[Nut-upsdev] tripp lite smart2200RMXL2U error reading protocol
I tried the new usbhid-ups from the rev 900 of the svn and after creating a few links to make it work in the gentoo framework I am connected and receiving data from the tripp lite ups. I will be checking to make sure the data is correct, but here is what I received from upsc tripplite at localhost battery.charge: 100 battery.charge.low: 10 battery.charge.warning: 30 battery.temperature: 33 battery.type: PbAC battery.voltage: 5.4 battery.voltage.nominal: 48.0 driver.name: usbhid-ups driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.parameter.productid: 3012 driver.version: 2.1.0 driver.version.data: TrippLite HID 0.1 (experimental) driver.version.internal: 0.30 input.frequency: 59.9 input.transfer.high: 145.0 input.transfer.low: 83.0 input.voltage: 125.1 input.voltage.nominal: 120 output.frequency: 59.9 output.frequency.nominal: 60 output.voltage: 124.5 output.voltage.nominal: 120 ups.beeper.status: enabled ups.delay.reboot: -1 ups.delay.restart: -1 ups.delay.shutdown: -1 ups.load: 43 ups.mfr: Tripp Lite ups.model: TRIPP LITE SMART2200RMXL2U ups.power.nominal: 2200 ups.productid: 3012 ups.serial: 9550ALCSM538900110 ups.status: OL ups.test.result: 0 ups.vendorid: 09ae Thanks for all the help.>>> Peter Selinger 05/14/07 11:16 AM >>>OK, that is very similar to the other Tripplite-HID devices; the functionality of this device seems to be almost a superset of the OMNI1000LCD and of the SmartOnlineSU1500RTXL2ua. It should work without problems with the newhidups driver, if you just add the 0x3012 to the source code where Charles suggested. I have just done this in the latest SVN version (revision 901). Note that in SVN, the driver has been renamed to usbhid-ups from newhidups. -- Peter ____________________________________________________________________ This email and any attachments may contain confidential information and is solely for the intended recipient(s). Email communications are not considered secure. If you are not the intended recipient(s) of this email you are expected to disregard the content, delete the message and notify the original sender. --University of Wisconsin, Department of Family Medicine-- ____________________________________________________________________ **UW DFM**
Peter Selinger
2007-May-14 17:29 UTC
[Nut-upsdev] tripp lite smart2200RMXL2U error reading protocol
This looks good.
If you get revision 901 ("svn update"), then you no longer need the -x
productid option.
-- Peter
Lance Thomas wrote:>
> I tried the new usbhid-ups from the rev 900 of the svn and after
> creating a few links to make it work in the gentoo framework I am
> connected and receiving data from the tripp lite ups. I will be
> checking to make sure the data is correct, but here is what I received
> from upsc tripplite at localhost
>
> battery.charge: 100
> battery.charge.low: 10
> battery.charge.warning: 30
> battery.temperature: 33
> battery.type: PbAC
> battery.voltage: 5.4
> battery.voltage.nominal: 48.0
> driver.name: usbhid-ups
> driver.parameter.pollinterval: 2
> driver.parameter.port: auto
> driver.parameter.productid: 3012
> driver.version: 2.1.0
> driver.version.data: TrippLite HID 0.1 (experimental)
> driver.version.internal: 0.30
> input.frequency: 59.9
> input.transfer.high: 145.0
> input.transfer.low: 83.0
> input.voltage: 125.1
> input.voltage.nominal: 120
> output.frequency: 59.9
> output.frequency.nominal: 60
> output.voltage: 124.5
> output.voltage.nominal: 120
> ups.beeper.status: enabled
> ups.delay.reboot: -1
> ups.delay.restart: -1
> ups.delay.shutdown: -1
> ups.load: 43
> ups.mfr: Tripp Lite
> ups.model: TRIPP LITE SMART2200RMXL2U
> ups.power.nominal: 2200
> ups.productid: 3012
> ups.serial: 9550ALCSM538900110
> ups.status: OL
> ups.test.result: 0
> ups.vendorid: 09ae
>
> Thanks for all the help.
>
> >>> Peter Selinger 05/14/07 11:16 AM >>>
> OK, that is very similar to the other Tripplite-HID devices; the
> functionality of this device seems to be almost a superset of the
> OMNI1000LCD and of the SmartOnlineSU1500RTXL2ua.
>
> It should work without problems with the newhidups driver, if you just
> add the 0x3012 to the source code where Charles suggested.
>
> I have just done this in the latest SVN version (revision 901).
> Note that in SVN, the driver has been renamed to usbhid-ups from
> newhidups.
>
> -- Peter
>
>
> ____________________________________________________________________
>
> This email and any attachments may contain confidential information and is
> solely for the intended recipient(s). Email communications are not
considered
> secure. If you are not the intended recipient(s) of this email you are
expected
> to disregard the content, delete the message and notify the original
sender.
>
> --University of Wisconsin, Department of Family Medicine--
> ____________________________________________________________________
>
> **UW DFM**
>
Arjen de Korte
2007-May-14 18:44 UTC
[Nut-upsdev] tripp lite smart2200RMXL2U error reading protocol
Lance Thomas wrote:> I tried the new usbhid-ups from the rev 900 of the svn and after > creating a few links to make it work in the gentoo framework I am > connected and receiving data from the tripp lite ups. I will be > checking to make sure the data is correct, but here is what I received > from upsc tripplite at localhost > > battery.charge: 100 > battery.charge.low: 10 > battery.charge.warning: 30 > battery.temperature: 33 > battery.type: PbAC > battery.voltage: 5.4The above is a known issue. The battery voltage is off by a factor of 10, so it should read 54.0 (which is a typical voltage for a 48V battery string. All other values look fine. Best regards, Arjen