Re: [Nut-upsuser] Tripp Lite Smart1000LCD driver problem
Yes, that is helpful. It seems that your Tripp Lite has different bugs than James's. That means it will be more tricky to fix. In any case, I am glad to see that the driver is now working. The bugs are minor and only affect how the voltages are displayed. -- Peter Phil DeBoest wrote: OK, this is good, now we are getting into fixing small details. I have just committed some changes to the trunk that improve debugging messages and make it easier to get the information I need. Please update to the new version, and then run (as root): drivers/newhidups -DDD -u root [EMAIL PROTECTED] /tmp/logfile After 2 seconds, you can hit CTRL-C. Please send the resulting log file. Note: this is one of the rare times when I actually want to see the output of -DDD. Normally, one should only use -DD on this list, unless specifically requested otherwise. Thanks! -- Peter Sorry this took me so long. I don't know if you still need it, but here are the results I got (trunk revision 501). Thanks again! Phil debug level is '3' Checking device (/) (001/001) - VendorID: - ProductID: - Manufacturer: unknown - Product: USB UHCI-alt Root Hub - Serial Number: 10c0 - Bus: 001 Trying to match device Device does not match - skipping Checking device (09AE/2005) (001/004) - VendorID: 09ae - ProductID: 2005 - Manufacturer: Tripp Lite - Product: TRIPP LITE UPS - Serial Number: 692195 A - Bus: 001 Trying to match device Device matches HID descriptor, method 1: (9 bytes) = 09 21 10 01 00 01 22 cb 01 HID descriptor, method 2: (9 bytes) = 09 21 10 01 00 01 22 6a 02 Warning: two different HID descriptors retrieved (Reportlen = 459 vs. 618) HID descriptor retrieved (Reportlen = 618) Report descriptor retrieved (Reportlen = 618) Found HID device Network UPS Tools: 0.28 USB communication driver 0.28 - core 0.30 (2.1.0) Report Descriptor size = 618 Report Descriptor: (618 bytes) = 05 84 09 04 a1 01 09 24 a1 02 05 84 85 28 09 fe 75 08 95 01 26 ff 00 15 00 b1 03 85 29 09 ff b1 03 85 2b 09 fd b1 03 09 1a a1 02 09 40 85 30 b1 83 c0 75 08 95 01 26 ff 00 85 11 09 5a b1 82 05 85 95 01 75 08 26 ff 00 15 00 85 2a 09 89 b1 03 85 33 09 2c b1 03 25 64 85 34 09 66 81 a2 85 34 09 66 b1 a2 85 37 09 67 b1 03 05 84 09 02 a1 02 25 01 75 01 85 32 05 84 95 01 09 69 81 a2 09 d0 81 a2 95 03 09 44 09 45 09 4b 81 a2 95 03 81 01 85 32 05 84 75 01 95 01 09 69 b1 a2 05 85 09 d0 b1 a2 95 03 09 44 09 45 09 4b b1 a2 95 03 b1 01 c0 c0 05 84 09 10 a1 02 09 12 a1 02 85 04 09 40 75 10 95 01 27 ff ff 00 00 b1 02 75 08 05 84 09 02 a1 02 85 23 05 85 75 01 25 01 95 03 09 44 09 45 09 4b b1 82 95 05 b1 01 c0 c0 05 84 95 01 75 08 26 ff 00 09 58 85 10 b1 82 c0 05 84 09 1e a1 02 95 01 75 08 26 ff 00 85 01 09 40 b1 03 85 02 09 42 b1 03 05 84 85 03 09 43 75 10 95 01 27 ff ff 00 00 b1 03 c0 05 84 95 01 75 08 15 00 26 ff 00 09 18 a1 02 09 20 a1 02 75 08 15 00 25 01 95 01 75 10 27 ff ff 00 00 15 00 85 15 09 57 b1 82 75 08 15 00 26 ff 00 06 ff ff 85 51 09 91 b1 82 85 52 09 92 b1 82 85 b6 09 c7 b1 82 c0 c0 06 ff ff 09 10 a1 81 75 10 95 01 27 ff ff 00 00 85 6c 09 7d b1 03 c0 06 ff ff 09 15 a1 81 75 08 95 01 26 ff 00 15 00 85 96 09 c0 b1 02 75 20 85 b4 09 d2 b1 02 75 10 85 97 09 c1 b1 02 75 08 85 98 09 c2 b1 02 75 10 85 99 09 c3 b1 02 85 9b 09 c5 b1 02 75 20 85 9a 09 c4 b1 02 c0 05 84 09 24 a1 02 85 31 09 30 75 08 95 01 26 ff 00 15 00 b1 03 c0 09 10 a1 02 09 12 a1 02 85 20 09 30 75 10 27 ff ff 00 00 b1 02 c0 c0 09 16 a1 02 09 1a a1 02 85 18 55 0f 09 30 b1 82 85 19 09 32 b1 82 c0 55 00 85 22 09 02 a1 02 75 01 95 03 25 01 05 84 09 63 09 6f 09 6e b1 82 95 01 b1 03 09 65 b1 82 09 6d 95 01 b1 03 09 67 09 62 95 02 b1 82 95 06 b1 03 95 01 09 72 b1 82 95 01 b1 03 c0 c0 05 84 09 18 a1 02 09 20 a1 02 75 10 95 01 15 00 27 ff ff 00 00 85 17 09 55 b1 82 c0 c0 c0 Detected a UPS: Tripp Lite /TRIPP LITE UPS Using subdriver: TrippLite HID 0.1 (experimental) Report: (2 bytes) = 28 01 Path: UPS.PowerSummary.iProduct, Type: Feature, Value: 1.00 Report: (2 bytes) = 29 02 Path: UPS.PowerSummary.iSerialNumber, Type: Feature, Value: 2.00 Report: (2 bytes) = 2b 03 Path: UPS.PowerSummary.iManufacturer, Type: Feature, Value: 3.00 Report: (2 bytes) = 30 78 Path: UPS.PowerSummary.Input.ConfigVoltage, Type: Feature, Value: 120.00 Report: (2 bytes) = 11 02 Path: UPS.PowerSummary.AudibleAlarmControl, Type: Feature, Value: 2.00 Report: (2 bytes) = 2a 18 Path: UPS.PowerSummary.iDeviceChemistry, Type: Feature, Value: 24.00 Report: (2 bytes) = 33 02 Path: UPS.PowerSummary.CapacityMode, Type: Feature, Value: 2.00 Report: (2 bytes) = 34 64 Path: UPS.PowerSummary.RemainingCapacity, Type: Input, Value: 100.00 Report: (2 bytes) = 34 64 Path: UPS.PowerSummary.RemainingCapacity, Type: Feature, Value: 100.00 Report: (2 bytes) = 37 64 Path: UPS.PowerSummary.FullChargeCapacity, Type: Feature, Value: 100.00 Report: (2 bytes) = 32 06 Path:
Re: [Nut-upsuser] Tripp Lite Smart1000LCD driver problem
Peter Selinger wrote: Charles Lepple wrote: On 7/24/06, Phil DeBoest [EMAIL PROTECTED] wrote: HID descriptor retrieved (Reportlen = 459) Unable to get Report descriptor (-75) Phil, This looks a lot like the problem mentioned here: http://lists.alioth.debian.org/pipermail/nut-upsdev/2005-November/000318.html Peter, Do you know where the problem turned out to be in the aforementioned message? If it is a wrong value for desc-wDescriptorLength, we could start a quirks table, and override the descriptor length for that particular UPS (and for some of the APCs, if we are still seeing that problem). -- - Charles Lepple Indeed, the cause of this bug was isolated here: http://lists.alioth.debian.org/pipermail/nut-upsdev/2006-February/000705.html As it turns out, there are two ways of retrieving report 0x21 (the HID descriptor) from the UPS: either by requesting report 0x21 directly, or by requesting report 0x02, which will have a copy of report 0x21 tucked onto its end. Normally, the two ways are supposed to give the same result. However, on some buggy UPS's (notably Tripp Lite, and some APC), only the second method works. lsusb always uses the second method, whereas NUT has always used the first. I have just committed some changes to the development branch that hopefully solve this problem. Now I retrieve the HID descriptor in two different ways, and when in doubt, use the second value (the same as lsusb). I have also made libusb_open() more tolerant in case the actual report descriptor is shorter than expected; so this should no longer fail. Phil, James, Justin, could you test this? Thanks, -- Peter Peter Selinger wrote: Charles Lepple wrote: On 7/24/06, Phil DeBoest [EMAIL PROTECTED] wrote: HID descriptor retrieved (Reportlen = 459) Unable to get Report descriptor (-75) Phil, This looks a lot like the problem mentioned here: http://lists.alioth.debian.org/pipermail/nut-upsdev/2005-November/000318.html Peter, Do you know where the problem turned out to be in the aforementioned message? If it is a wrong value for desc-wDescriptorLength, we could start a quirks table, and override the descriptor length for that particular UPS (and for some of the APCs, if we are still seeing that problem). -- - Charles Lepple Indeed, the cause of this bug was isolated here: http://lists.alioth.debian.org/pipermail/nut-upsdev/2006-February/000705.html As it turns out, there are two ways of retrieving report 0x21 (the HID descriptor) from the UPS: either by requesting report 0x21 directly, or by requesting report 0x02, which will have a copy of report 0x21 tucked onto its end. Normally, the two ways are supposed to give the same result. However, on some buggy UPS's (notably Tripp Lite, and some APC), only the second method works. lsusb always uses the second method, whereas NUT has always used the first. I have just committed some changes to the development branch that hopefully solve this problem. Now I retrieve the HID descriptor in two different ways, and when in doubt, use the second value (the same as lsusb). I have also made libusb_open() more tolerant in case the actual report descriptor is shorter than expected; so this should no longer fail. Phil, James, Justin, could you test this? Thanks, -- Peter Thanks Peter (and Charles)! That seemed to do the trick. The driver now loads and upsd is able to retrieve information from it. Some of the information seems a bit suspect, though. For example, it says the battery voltage is 0, and, even less likely, the output voltage is 177.0. (I'm in the US, so nominal is 120). Surely it wouldn't be indicating peak voltage instead of RMS? Since the computers connected to the UPS continue to function without smoking, I doubt the output voltage is actually that high. The display on the UPS itself indicates everything is normal. Is this likely a parsing issue, or should I investigate further with the UPS itself? I could hook it up to a Windows box, install the software that came with it, and see what it reads. Any other suggestions? Here's the output of upsc: battery.charge: 100 battery.type: PbAc battery.voltage: 0.0 battery.voltage.nominal: 12.0 driver.name: newhidups driver.parameter.port: auto driver.version: 2.1.0 driver.version.data: TrippLite HID 0.1 (experimental) driver.version.internal: 0.30 input.frequency: 59.8 input.voltage: 120.1 input.voltage.nominal: 120 output.frequency.nominal: 60 output.voltage: 177.0 output.voltage.nominal: 120 ups.beeper.status: enabled ups.delay.reboot: 65535 ups.delay.shutdown: 65535 ups.mfr: Tripp Lite ups.model: TRIPP LITE UPS ups.power.nominal: 1000 ups.serial: 692195 A ups.status: OL CHRG Phil Davis Brown is committed to providing Exceptional Client Service. For a review of the supporting principles, go to www.lawiowa.com/about/exceptional To ensure compliance with requirements imposed by the IRS in Circular 230, we inform you that, unless we expressly state
Re: [Nut-upsuser] Tripp Lite Smart1000LCD driver problem
Phil DeBoest wrote: Peter Selinger wrote: I have just committed some changes to the development branch that hopefully solve this problem. Now I retrieve the HID descriptor in two different ways, and when in doubt, use the second value (the same as lsusb). I have also made libusb_open() more tolerant in case the actual report descriptor is shorter than expected; so this should no longer fail. Phil, James, Justin, could you test this? Thanks, -- Peter Thanks Peter (and Charles)! That seemed to do the trick. The driver now loads and upsd is able to retrieve information from it. Some of the information seems a bit suspect, though. For example, it says the battery voltage is 0, and, even less likely, the output voltage is 177.0. (I'm in the US, so nominal is 120). Surely it wouldn't be indicating peak voltage instead of RMS? Since the computers connected to the UPS continue to function without smoking, I doubt the output voltage is actually that high. The display on the UPS itself indicates everything is normal. Is this likely a parsing issue, or should I investigate further with the UPS itself? I could hook it up to a Windows box, install the software that came with it, and see what it reads. Any other suggestions? Here's the output of upsc: battery.charge: 100 battery.type: PbAc battery.voltage: 0.0 battery.voltage.nominal: 12.0 driver.name: newhidups driver.parameter.port: auto driver.version: 2.1.0 driver.version.data: TrippLite HID 0.1 (experimental) driver.version.internal: 0.30 input.frequency: 59.8 input.voltage: 120.1 input.voltage.nominal: 120 output.frequency.nominal: 60 output.voltage: 177.0 output.voltage.nominal: 120 ups.beeper.status: enabled ups.delay.reboot: 65535 ups.delay.shutdown: 65535 ups.mfr: Tripp Lite ups.model: TRIPP LITE UPS ups.power.nominal: 1000 ups.serial: 692195 A ups.status: OL CHRG Phil OK, this is good, now we are getting into fixing small details. I have just committed some changes to the trunk that improve debugging messages and make it easier to get the information I need. Please update to the new version, and then run (as root): drivers/newhidups -DDD -u root [EMAIL PROTECTED] /tmp/logfile After 2 seconds, you can hit CTRL-C. Please send the resulting log file. Note: this is one of the rare times when I actually want to see the output of -DDD. Normally, one should only use -DD on this list, unless specifically requested otherwise. Thanks! -- Peter ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Tripp Lite Smart1000LCD driver problem
What does /proc/bus/usb/devices say about the UPS? -- - Charles Lepple ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Tripp Lite Smart1000LCD driver problem
Here's the relevant /proc/bus/usb/devices output: T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 3 Spd=1.5 MxCh= 0 D: Ver= 1.10 Cls=00(ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=09ae ProdID=2005 Rev= 0.10 S: Manufacturer=Tripp Lite S: Product=TRIPP LITE UPS S: SerialNumber=692195 A C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=00 Driver=(none) E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=40ms Thanks! Phil ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
