On Mar 2, 2017, at 6:07 PM, Drew from Zhrodague <drewzhroda...@zhrodague.net> wrote: > > On 3/2/17 10:02 AM, Charles Lepple wrote: >> Can you provide a pointer to details on the usbhid-dump tool? Not >> familiar with that one. > > I'm using Ubuntu 14.04 Server on an i686 Dell/Wyse CX0 thin-client - > usbhid-dump was available as part of usbhid-utils, if I am not mistaken. > > https://github.com/DIGImend/usbhid-dump
Cool, thanks. > >> Depending on how much of the Power Device Class (PDC) HID spec they >> have implemented (rather than doing non-PDC HID as a cheap >> USB-to-serial replacement), this might require a separate driver, or >> it might be easy to extend usbhid-ups. The "explore mode" mentioned >> in the link below will provide the output to guide that decision. > > I do have the correct permissions for udev. The explore mode complains: > > 0.185149 HID descriptor, method 1: (9 bytes) => 09 21 10 01 00 01 22 22 > 00 > 0.186126 i=0, extra[i]=09, extra[i+1]=21 > 0.186323 HID descriptor, method 2: (9 bytes) => 09 21 10 01 00 01 22 22 > 00 > 0.186537 HID descriptor length 34 > 0.195165 Report Descriptor size = 34 > 0.195484 Report Descriptor: (34 bytes) => 06 a0 ff 09 a5 a1 01 09 a6 09 > a7 15 00 25 > 0.196073 ff 75 08 95 08 81 02 09 a9 15 00 25 ff 75 08 95 08 91 02 c0 > 0.196506 Using subdriver: EXPLORE HID 0.1 > 0.197232 Entering libusb_get_report > 0.200187 Can't retrieve Report 00: Broken pipe > 0.200434 Path: ffa000a5.ffa000a6, Type: Input, ReportID: 0x00, Offset: > 0, Size: 8 > 0.201022 Entering libusb_get_report > 0.204196 Can't retrieve Report 00: Broken pipe > 0.204443 Path: ffa000a5.ffa000a7, Type: Input, ReportID: 0x00, Offset: > 0, Size: 8 > 0.204589 Entering libusb_get_report > 0.207190 Can't retrieve Report 00: Broken pipe > 0.207493 Path: ffa000a5.ffa000a9, Type: Output, ReportID: 0x00, Offset: > 0, Size: 8 Usually, path values starting with "ff" are vendor-defined, so it looks like you may need to continue experimenting to determine the meaning behind each byte. Also, the "can't retrieve report" message is probably a sign that it will be easier to write a new driver, but see below. > 0.207768 Report descriptor retrieved (Reportlen = 34) > 0.208330 Found HID device > 0.208487 Detected a UPS: Copeland Engineering, LLC/Dock Master > 0.209065 find_nut_info: unknown info type: load.off.delay > 0.209226 find_nut_info: unknown info type: load.on.delay > 0.209365 find_nut_info: unknown info type: load.off.delay > 0.209891 upsdrv_initinfo... > 0.210091 upsdrv_updateinfo... > 0.462138 libusb_get_interrupt: Connection timed out > 0.463669 Got 0 HID objects... > 0.464839 Quick update... > 0.466362 dstate_init: sock /var/run/nut/usbhid-ups-dockmaster open on fd > 5 > 0.467580 upsdrv_updateinfo... > 0.720135 libusb_get_interrupt: Connection timed out > 0.721710 Got 0 HID objects... > 0.723106 Quick update... > 2.469447 upsdrv_updateinfo... > 2.722132 libusb_get_interrupt: Connection timed out Do you get any messages other than "timed out", especially after changing power states? If not, there may be some tricks needed to get the messages flowing, but apparently usbhid-dump knows how to do it - and it is also written for libusb. > Bus 003 Device 002: ID 04d8:0500 Microchip Technology, Inc. ... > Report Descriptors: > ** UNAVAILABLE ** meh. However, the report descriptor is short enough that we can probably ignore it (or just match a few bytes at the beginning). Also, I thought that 04d8 vendor ID sounded familiar... I don't know if 04d8:0500 is unique, but we can try it and see what other software breaks in the process. > > I've ordered a second model (EBay, $25) - one to install into the car, > and one to debug/test. It is possible to change some of the parameters of the > device, using a Windows program. I have another CXO host with Windows on it > that runs the Copeland Engineering software, with which I can compare if > necessary. > > I expect it won't be hard to get this working with nut, and I'm happy > to do a bunch of legwork (commit credits!) in order to get this thing working > for my purposes - and I appreciate your help, Charles. > Sounds good. Having a second unit is always handy for testing. If you are interested in taking a look at related code, these two drivers are probably good starting points: * https://github.com/networkupstools/nut/blob/libusb-1.0/drivers/nutdrv_atcl_usb.c * https://github.com/networkupstools/nut/blob/libusb-1.0/drivers/richcomm_usb.c The libusb-1.0 branch actually has code for both v0.1 and v1.0, and this is a good reminder that we should merge that soon. Either way, you will need to build from the Git repository, so that branch is probably the better place to start. Let me know if you have questions about source control, or any of the other developer documentation (I know it's a lot to wade through, but much of it doesn't apply to this device). -- - Charles Lepple https://ghz.cc/charles/ _______________________________________________ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
