[Nut-upsuser] Ablerex 625L USB version

[Jon Gough]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20070128/09170b60/attachment.htm