[Nut-upsuser] Copeland Engineering Dockmaster

Fri Mar 3 04:19:16 UTC 2017

On Mar 2, 2017, at 6:07 PM, Drew from Zhrodague <drewzhrodague at 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/