Peter,
Looking at the data further down it has min and max values. These
would seem to make sense for voltage (0 & 250), frequency (0 & 60),
so is this data coming from the UPS, or is it just something in the
system that expects these values?
Regards
Jon
At 17:20 28/01/2007, Peter Selinger wrote:
Hi Jon,
I can't figure out which version of NUT you are running, because you
have pruned that information from your output. Also, which patches, if
any, have you applied?
What you are seeing from lsusb is not "data" from the UPS; it is
simply a detailed parsing of the report descriptor. For example, when
it says "Usage, data= [ 0x40 ] 64 Config Voltage", this simply means
that HID usage code 0040 corresponds to the "ConfigVoltage" item (see
e.g. libhid.c, line 1100).
The error message "(75): Value too large for defined data type" may
indicate that the UPS is unhappy with the size of the buffer provided
by NUT (apparently 13). You can play with this by hacking a larger
buffer size. It should be easy to do this in the function
libhid.c:refresh_report_buffer(), by setting len to something bigger
(or smaller).
If the buffer is too small, the device is supposed to fill it with
valid data up to the given size, instead of bailing out with an error
message. So it seems that the device is at least a little buggy.
Similar behavior has been observed in other cheap devices. (In fact,
one Belkin UPS that I own seems to have a dual bug: if you give a
buffer that is too large, then it will attempt to write random
contents from the firmware memory into the buffer, often crashing the
device).
Alternatively, what would happen if you just ignored the error in
libhid.c after the call to get_report? Perhaps the buffer has been
filled with partial data in spite of the error message?
Just some thoughts. -- Peter
Jon Gough wrote:
>
> Peter,
> I have been trying with no luck to get the drivers working. I
> have done a "lsusb -v -d ffff:" to get the info from the USB
> regarding my UPS and it seems to be giving valid data. However, I am
> now confused with the "explore" option of the usbhid-ups program as
> the Report Descriptor is 632 byte long (which is confirmed by the
> lsusb program). But the lsusb program seems to be reading every other
> byte not each byte. What are the in between bytes for?
>
> I have included the output of the lsusb command below (sorry for
> the length) and it seems to read the output fine, but the NUT
> software seems to call libusb and get invalid responses. I notice in
> the latest output that the length of the data and the length being
> requested seem different (I put a couple of extra debugging statements in).
>
><snip>
> Item(Local ): Usage, data= [ 0x40 ] 64
> Config Voltage
> Item(Global): Report Size, data= [ 0x10 ] 16
> Item(Global): Report Count, data= [ 0x01 ] 1
> Item(Global): Unit, data= [ 0x21 0xd1 0xf0 0x00 ] 15782177
> Item(Global): Unit Exponent, data= [ 0x07 ] 7
> Item(Global): Logical Minimum, data= [ 0x00 ] 0
> Item(Global): Logical Maximum, data= [ 0xfa 0x00 ] 250
> Item(Main ): Feature, data= [ 0x02 ] 2
> Data Variable Absolute No_Wrap Linear
> Preferred_State No_Null_Position
> Non_Volatile Bitfield
> Item(Local ): Usage, data= [ 0x42 ] 66
> Config Frequency
> Item(Global): Report Size, data= [ 0x10 ] 16
> Item(Global): Report Count, data= [ 0x01 ] 1
> Item(Global): Unit, data= [ 0x01 0xf0 ] 61441
> Item(Global): Unit Exponent, data= [ 0x00 ] 0
> Item(Global): Logical Minimum, data= [ 0x00 ] 0
> Item(Global): Logical Maximum, data= [ 0x3c ] 60
> Item(Main ): Feature, data= [ 0x02 ] 2
> Data Variable Absolute No_Wrap Linear
> Preferred_State No_Null_Position
> Non_Volatile Bitfield
<snip>
---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 000707-0, 27/01/2007
Tested on: 28/01/2007 5:49:24 PM
avast! is copyright (c) 2000-2007 ALWIL Software.
http://www.avast.com
_______________________________________________
Nut-upsuser mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
