Hi, I have a customer who just bought an APC Back-UPS XS 1300 LCD and I thought I'd try the latest NUT with it (on an old-ish FreeBSD 6.x system). It sees the UPS but I can't actually query it for data, in the usbhid-ups debug output I see.. 30.840512 HIDGetEvents: failed to buffer report: Result too large 30.840600 Got -34 HID objects... 30.840681 Quick update... upsc gives.. downie:~>upsc ups1 at localhost ups.status: WAIT downie:~>upsc ups1 at localhost Error: Data stale I have attached the output from the following sudo /usr/local/sbin/upsd -D -D -D sudo /usr/local/libexec/nut/usbhid-ups -D -D -D -a ups1 Any ideas? The libusb support in 6.x is pretty crappy so maybe it's that :( -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: upsd.log.gz Type: application/x-gzip Size: 1289 bytes Desc: not available URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20090530/a2a24d8e/attachment.bin> -------------- next part -------------- A non-text attachment was scrubbed... Name: usb-apc.log.gz Type: application/x-gzip Size: 7058 bytes Desc: not available URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20090530/a2a24d8e/attachment-0001.bin> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: This is a digitally signed message part. URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20090530/a2a24d8e/attachment.pgp>
Citeren Daniel O'Connor <doconnor at gsoft.com.au>:> I have a customer who just bought an APC Back-UPS XS 1300 LCD and I > thought I'd try the latest NUT with it (on an old-ish FreeBSD 6.x > system). > > It sees the UPS but I can't actually query it for data, in the > usbhid-ups debug output I see.. > 30.840512 HIDGetEvents: failed to buffer report: Result too large > 30.840600 Got -34 HID objects... > 30.840681 Quick update...This is probably due to a broken libusb. Looking at the dump of the report descriptor, it looks like this UPS should be supported.> upsc gives.. > downie:~>upsc ups1 at localhost > ups.status: WAIT > downie:~>upsc ups1 at localhost > Error: Data staleInitially, the server can connect to the driver. You can see that, because it sets ups.status to WAIT, indicating that it has successfully sent the DUMPALL command and is now waiting for the reply. That's the last thing we hear, the driver never replies, not even to the PINGs that we send.> Any ideas? The libusb support in 6.x is pretty crappy so maybe it's > that :(If it is very slow in timing out on the USB communication, that could be a problem. The following worries me: 1.272355 upsdrv_updateinfo... 30.839759 file_report_buffer: expected 4 bytes, but got 128! This means the HIDGetEvents() functions takes almost 30 seconds to return, where we expect it to return almost immediately. This means the interrupt pipeline is not being handled correctly. Since the driver stalls so long here, the server will give up on it. My first suggestion would be to check if upgrading libusb helps, possibly by trying it out on a more recent OS. Best regards, Arjen -- Please keep list traffic on the list
Citeren Daniel O'Connor <doconnor op gsoft.com.au>:>> It is tempting to base this on the size of the field that is >> reported, but it would require a major amount of work on the base >> usbhid-ups driver, since we only pass the parameters by value and not >> by the full HID path information. Not that it isn't doable, but it >> takes much more work than I'm prepared to spend on a vendor that >> isn't really supportive with NUT. > Fair enough.On top of this, APC is at the moment the only vendor for which we have 'battery.date' and 'battery.mfr.date' variables. This makes decoding these values even more difficult, since if we don't exactly understand what is meant, we cannot fallback to a device for which we have information from the vendor to give us a clue what is going on. Currently I really doubt that having a static 'battery.date' and static 'battery.mfr.date' field is what was intended by APC. I don't think they are using intelligent batteries (the ones I've seen so far at least weren't), so I suspect that it should be possible to update these fields when the battery is replaced. But how? Because of the above I have my doubts if it is useful to use the HID paths UPS.Battery.APCBattReplaceDate UPS.PowerSummary.APCBattReplaceDate at all (and therefor, if we should display either fields in this case). On the other hand, the (serial) Smart-UPS protocol allows to store this value in the EEPROM of the device, so it probably *is* possible (but not through the usbhid-ups driver right now in NUT). Best regards, Arjen -- Please keep list traffic on the list