[Nut-upsuser] Tripp Lite Smart1000LCD driver problem

[Phil DeBoest]

Peter Selinger wrote:
> Charles Lepple wrote:
>> On 7/24/06, Phil DeBoest <phil at deboest.com> 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 <phil at deboest.com> 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 otherwise in this communication (including any attachments), any tax advice contained in this communication is not intended or written to be used, and cannot be used, for the purpose of (i) avoiding penalties under the Internal Revenue Code or (ii) promoting, marketing, or recommending to another party any transaction or other matter addressed herein.

This electronic transmission and any documents accompanying this electronic transmission contain confidential information belonging to the sender.  This information may be legally privileged.  The information is intended only for the use of the individual or entity named above.  If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or the taking of any action in reliance on or regarding the contents of this electronically transmitted  information is strictly prohibited.