Nut upsdev - Apr 2006 - Cyberpower 900AVR/BC900D newhidups problem

I'm trying to get nut to work with a Cyberpower 900AVR. There are many
different products known by this name, but this one has the extra name
'BC900D'.

I am told by a cyberpower tech that this one should talk exactly the
same USB protocol as the 685AVR, which was recently made to work with
newhidups.

Unfortunately, when I run the SVN checkout (trunk) of nut-2.1, I get:

sstreet drivers # ./newhidups -DDDDD -u root /dev/usb/hiddev0
Network UPS Tools: New USB/HID UPS driver 0.28 (2.1.0)

debug level is '5'
Checking device (0000/0000) (005/001)
- VendorID: 0000
[snip]
Checking device (0764/0005) (002/002)
- VendorID: 0764
- ProductID: 0005
- Manufacturer: unknown
- Product: unknown
- Serial Number: unknown
- Bus: 002
Trying to match device
Device matches
failed to claim USB device, trying 2 more time(s)...
detaching kernel driver from USB device...
trying again to claim USB device...
HID descriptor too short (expected 8, got 0)
Checking device (0000/0000) (002/001)
- VendorID: 0000

The dmesg output at this time is:

usb 2-2: newhidups timed out on ep0in len=0/255
usb 2-2: usbfs: USBDEVFS_CONTROL failed cmd newhidups rqt 128 rq 6 len 255 ret
-110
usb 2-2: newhidups timed out on ep0in len=0/255
usb 2-2: usbfs: USBDEVFS_CONTROL failed cmd newhidups rqt 128 rq 6 len 255 ret
-110
usbhid 2-2:1.0: disconnect by usbfs
drivers/usb/core/file.c: removing 96 minor

which seems to indicate a low-level communications error. I do have
the usbhid module loaded, with the standard HID-extensions options
checked in kernel config. I'm running Linux 2.6.15-gentoo-r1 #8 SMP.

The bootup logs for initing this device, from dmesg are:
usb 2-2: Product: CPS RS232 USB BRIDGE for UPS
usb 2-2: Manufacturer: Cyber Power System
usb 2-2: hotplug
usb 2-2: adding 2-2:1.0 (config #1, interface 0)
usb 2-2:1.0: hotplug
drivers/usb/core/inode.c: creating file '002'
hub 3-0:1.0: state 5 ports 2 chg 0000 evt 0000
usbcore: registered new driver hiddev
hub 4-0:1.0: state 5 ports 2 chg 0000 evt 0004
usbhid 2-2:1.0: usb_probe_interface
usbhid 2-2:1.0: usb_probe_interface - got id
uhci_hcd 0000:00:1d.1: suspend_rh (auto-stop)
uhci_hcd 0000:00:1d.3: suspend_rh (auto-stop)
drivers/usb/input/hid-core.c: usb_submit_urb(ctrl) failed
drivers/usb/input/hid-core.c: timeout initializing reports

drivers/usb/core/file.c: looking for a minor, starting at 96
hiddev96: USB HID v1.10 Device [Cyber Power System CPS RS232 USB BRIDGE for UPS
] on usb-0000:00:1d.0-2
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
uhci_hcd 0000:00:1d.2: port 2 portsc 009b,00

Oh, and I had to comment out these lines in libhid.h to get it to
compile:
/* ensure these exists (required for Solaris 10) */
//#ifndef u_int16_t
//      typedef uint16_t u_int16_t;
//#endif
//
//#ifndef u_int8_t
//      typedef uint8_t u_int8_t;
//#endif

... but I assume these were only relevant to solaris? Or is this a
problem?

Cheers,

Lincoln

On 4/13/06, Lincoln Turner <lincolnturner@gmail.com>
wrote:
> HID descriptor too short (expected 8, got 0)
What does 'lsusb -vvv' say after the kernel usbhid driver is detached?
(i.e. if you unplug and replug the device, make sure that you re-run
newhidups once before running lsusb).
> usb 2-2: Product: CPS RS232 USB BRIDGE for UPS
This makes me wonder if it is just a USB-to-serial bridge. If that
were the case, newhidups would not know how to communicate with it -
the cyberpower serial driver would have to be adapted instead.
> Oh, and I had to comment out these lines in libhid.h to get it to
> compile:
> /* ensure these exists (required for Solaris 10) */
> //#ifndef u_int16_t
> //      typedef uint16_t u_int16_t;
> //#endif
> //
> //#ifndef u_int8_t
> //      typedef uint8_t u_int8_t;
> //#endif
>
> ... but I assume these were only relevant to solaris? Or is this a
> problem?
What was the compilation error? It needs the types on the right-hand
side, but they may not have been preprocessor defines. (The proper
solution involves some autoconf magic, and I won't have time to fix
this myself - any volunteers?)

--
- Charles Lepple

Lincoln Turner wrote:
> 
> 
> Hi Peter,
> 
> Thanks for all your help with this. Unfortuantely, I have returned the
> device for a refund, and bought an APC XS 1500, which appears to be
> better supported.
> 
> It would have been fun to debug this cyberpower device, but I needed
> something to work in the short term as it will have to run unattended
> while I'm out of the country. 
No problem!
 
> I was most unimpressed with cyberpower's NDA policy. The tech guy was
> quite helpful, but said that they couldn't release their protocol
> details to anyone without an NDA and that precluded open source. He
> knew about nut and was even prepared to ship free products to 'nut
> people' but not the protocol. Why a hardware maker benefits from
> keeping the protocol secret is beyond me!
Probably because they did not develop it themselves, but bought it
from another company. My guess is that they are probably themselves
bound by an NDA. This could explain their relative happiness to give
away free products to a NUT developer. We should certainly keep it in
mind for the future.

-- Peter

Lincoln Turner wrote:
> 
> > > I was most unimpressed with cyberpower's NDA policy. The tech
guy was
> > > quite helpful, but said that they couldn't release their
protocol
> > > details to anyone without an NDA and that precluded open source.
He
> > > knew about nut and was even prepared to ship free products to
'nut
> > > people' but not the protocol. Why a hardware maker benefits
from
> > > keeping the protocol secret is beyond me!
> > 
> > Probably because they did not develop it themselves, but bought it
> > from another company. My guess is that they are probably themselves
> > bound by an NDA. This could explain their relative happiness to give
> > away free products to a NUT developer. We should certainly keep it in
> > mind for the future.
> 
> I see. The technician said that he had 'tried to contact the nut
> mailing list', but had had no response. I suspect he didn't try
very
> hard - I've found the list very responsive. But you could chase it up
> with them.
> 
> BTW I found your instructions "Linux and the APC Back-UPS ES"
very
> useful in getting going with my new APC ups. The only discrepancy I
> found with my setup was the hotplug stuff - gentoo and many other
> distros now use udev rules files, and it was just a matter of finding
> these in the scripts/hotplug-ng directory and using them instead.
Would you like to send me an addition to the instructions? I don't use
any of those distros, so I have never tried the hotplug-ng stuff. The
instructions should be validated, i.e., one should get another person
to follow the instructions after writing them. Usually it turns out
one has forgotten some steps. For this reason, I can't write them
myself.

-- Peter

P.S. please reply to the list, not to me personally.