[Nut-upsuser] Generic UPS driver

Charles Lepple clepple at gmail.com
Sat Dec 21 00:22:16 UTC 2013


On Dec 20, 2013, at 5:31 PM, Ariel Wainer wrote:

> Hi, I just bought a cheap UPS and apparently I'm hitting the same issue
> that's described here:
> http://comments.gmane.org/gmane.comp.monitoring.nut.user/6146

Maybe I'm getting old, but I wish Gmane hadn't gone with such an unreadable layout for their blog format. (Not your fault, I'm just venting. I suppose I should direct those suggestions to them.) In an effort to help search engines:

http://thread.gmane.org/gmane.comp.monitoring.nut.user/6146

> Mine is a different brand: "Kanji" which appears to be the argentinian
> dealler for some generic chinese manufacturer. My model is also 800VA
> and identified in the same way, so maybe is the same UPS under a
> different brand:
> 
> [ 1244.817586] usb 4-2: new low-speed USB device number 5 using xhci_hcd
> [ 1244.839172] usb 4-2: New USB device found, idVendor=0001, idProduct=0000
> [ 1244.839183] usb 4-2: New USB device strings: Mfr=1, Product=1,
> SerialNumber=1
> [ 1244.839191] usb 4-2: Product: ATCL FOR UPS
> [ 1244.839196] usb 4-2: Manufacturer: ATCL FOR UPS
> [ 1244.839201] usb 4-2: SerialNumber: ATCL FOR UPS
> 
> 
> I understand that because of the bogus product id and vendor id and the
> very scarce info NUT cannot properly support this UPS. However, in hope
> that maybe it's a known protocol or it's helpfull anyway, I made usb
> captures of the windows software that comes with the ups for windows. I
> did two captures: one with the proc interface to usbmon and one with
> with wireshark.
> I have no experience writing drivers, but I can try experimental drivers
> to help.


Maybe Dan, the maintainer of the nutdrv_qx driver, has better insight on this, but my uneducated guess is that I don't think it is Megatec/Qx. The logs don't show any commands going down to the UPS, just Interrupt Read requests to EP1IN.

It definitely won't be covered by stock usbhid-ups either, although it does implement the bare minimum of the USB HID protocol. (The usbhid-ups driver expects USB HID PDC.)

In this thread (which I assume from the name is an equivalent device):

   http://openbsd.7691.n7.nabble.com/general-question-about-usb-stack-and-ups-td234700.html

it looks like there are just two 8-byte reports, one to the UPS (Type: Output), and one back to the PC.

    0.040766     hid_lookup_path: ffa00001 -> not found in lookup table 
    0.040781     hid_lookup_path: ffa00003 -> not found in lookup table 
    0.040796     Path: ffa00001.ffa00003, Type: Input, ReportID: 0x00, Offset: 0, Size: 8 
    0.040810     Entering libusb_get_report 
    0.041661     libusb_get_report: Input/output error 
    0.041697     Can't retrieve Report 00: Input/output error 
    0.041723     hid_lookup_path: ffa00001 -> not found in lookup table 
    0.041741     hid_lookup_path: ffa00004 -> not found in lookup table 
    0.041747     Path: ffa00001.ffa00004, Type: Output, ReportID: 0x00, Offset: 0, Size: 8 

In your upsmon log, these seem to be the usb_interrupt_read() request/response pairs:

ffff88010f25a600 1892124915 S Ii:4:004:1 -115:8 8 <
ffff88010f25a600 1893162682 C Ii:4:004:1 0:8 8 = 03000000 00000000
ffff880138503b40 1893182340 S Ii:4:004:1 -115:8 8 <
ffff880138503b40 1894210833 C Ii:4:004:1 0:8 8 = 03000000 00000000
ffff880138503b40 1894217214 S Ii:4:004:1 -115:8 8 <
ffff880138503b40 1895258986 C Ii:4:004:1 0:8 8 = 03000000 00000000

What might be interesting is whether any of the bits vary when the UPS goes on battery, or when the battery gets low. You may want to plug in a dummy load, and power the computer from another UPS or the wall outlet, in order to fully characterize the protocol.

Also important are the settings in the UPS monitoring software, such as timeouts, or behavior options for when the power returns. Those will probably show up as magic numbers later on.

-- 
Charles Lepple
clepple at gmail






More information about the Nut-upsuser mailing list