[Nut-upsuser] Ablerex 625L USB version

[Peter Selinger]

Jon Gough wrote:
> 
> Oooppss. Lets try with less data!

Yes, I also had trouble posting to the list because of the size
limit. It might help if you could teach your mailer not to repeat the
entire message in HTML at the end of each message.
 
> 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

OK, so you are using some patch that I have not seen. There is no
"Upsilon" subdriver in the official NUT sources.
 
> 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

OK, sure, you are getting ahead of the game. There is no point in this
unless the driver can first communicate with the UPS. 
 
> 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>