Oooppss. Lets try with less data!
Peter,
Here is the line that I pruned out.
Network UPS Tools: 0.28 USB communication driver 0.28 - core 0.30 (2.1.0)
When I start the driver with
/usr/local/ups/bin/upsdrvctl -u nut start
I get the following messages
Network UPS Tools - UPS driver controller 2.1.0
Network UPS Tools: 0.28 USB communication driver 0.28 - core 0.30 (2.1.0)
Detected a UPS: UIS Ablerex/Ablerex USB Interface 049e
Using subdriver: Upsilon HID 0.1
Then I issue
/usr/local/ups/sbin/upsd -u nut
and get
Network UPS Tools upsd 2.1.0
upsd: listening on 0.0.0.0:3493
Connected to UPS [eclipse]: eclipse
Then I try to see what is available from the driver with
/usr/local/ups/bin/upsc eclipse
and get
Activepower: 0
Apparentpower: 0
driver.name: usbhid-ups
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.version: 2.1.0
Shutdown.Delay: 0
Startup.Delay: 0
ups.mfr: UIS Ablerex
ups.model: Ablerex USB Interface 049e
ups.status: WAIT
If I try
/usr/local/ups/bin/upsc eclipse battery.voltage
I get
Error: Variable not supported by UPS
Yet battery.voltage is defined in the hid_info_t variable.
It looks like only part of the output is being read. But at this
point I do not know what to do to get further information from the
system. I have modified the stub to have the correct (I hope) labels
for at least some of the values that should be returned, but they do
not show up when I call the command processor.
I seem to be missing something in this process. Not sure what,
but I am getting confused about what I should have to do.
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).
>
> Using subdriver: EXPLORE HID 0.1
> parsing 00860004
> parsing Flow
> hid_lookup_usage: found 84001e
> parsing FlowID
> hid_lookup_usage: found 84001f
> Path depth = 3
> 0: Usage(00860004)
> 1: Usage(0084001e)
> 2: Usage(0084001f)
> Entering libusb_get_report. ReportSize: 13
> typesafe_control_msg: size: 13
> Can't retrieve Report 1 (75): Value too large for defined data type
> Path: 00860004.Flow.FlowID, Type: Feature, ReportID: 0x01,
Offset: 0, Size: 4
> parsing 00860004
> parsing Flow
> hid_lookup_usage: found 84001e
> parsing ConfigVoltage
> hid_lookup_usage: found 840040
> Path depth = 3
> 0: Usage(00860004)
> 1: Usage(0084001e)
> 2: Usage(00840040)
> Entering libusb_get_report. ReportSize: 13
> typesafe_control_msg: size: 13
> Can't retrieve Report 1 (75): Value too large for defined data type
> Path: 00860004.Flow.ConfigVoltage, Type: Feature, ReportID: 0x01,
> Offset: 8, Size: 16
>
> Is this correct, or is there something else that needs looking at?
>
> Regards
> Jon
>
> Data from lsusb
><snip>
---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 000707-0, 27/01/2007
Tested on: 28/01/2007 5:33:41 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
