[Nut-upsdev] Re: CyberPower 685AVR and newhidups

[Peter Selinger]

Scott Alfter wrote:
> 
> (It took me a little while to get back to this...headed out of town over the 
> weekend, and I've been tied up with other stuff since then.)
> 
> Peter Selinger wrote:
> > Please test this. Run the driver as:
> > 
> > drivers/newhidups -DD -u root -x vendorid=0764 auto
> > 
> > (without the -x generic option from last time, as your model is now
> > supported).
> 
> Here's what it produced as output before I killed it:
> 
> Network UPS Tools: New USB/HID UPS driver 0.28 (2.1.0)
> 
> debug level is '2'
> Checking device (0000/0000) (002/001)
> - VendorID: 0000
>
> [snip]
> 
> The variables you wanted to check appear to not be listed.

Hi Scott,

sorry, I should have been more specific. The purpose at this point is
no longer to look at the debugging output from the driver. The purpose
is now to check if the driver is working properly, by interacting with
upsd (i.e., via the commands upsc, upsrw, upscmd).

>  > It would be great if you could post the output of
> > "upsc upsname at localhost" back to the list. 
> 
> driver.name: newhidups
> driver.parameter.generic: 1
> driver.parameter.port: /dev/usb/hiddev0
> driver.parameter.vendorid: 0764
> driver.version: 2.1.0
> driver.version.data: GENERIC HID 0.1
> driver.version.internal: 0.28
> ups.mfr: CPS
> ups.model: UPS BF700

This list is incomplete, because you ran the driver with the "-x
generic" option when you produced it (the line
"driver.parameter.generic: 1" gives it away!). Please run without this
option, and a lot more variables should be listed, included
(hopefully) all the ones that I was asking about.
 
> > Please also test the following instant commands (again, disconnect
> > your equipment from the UPS before testing):
> > 
> > load.off
> > load.on
> > shutdown.return
> > shutdown.stop
> > beeper.on
> > beeper.off
> > 
> > (the latter two will only work properly during a "beeper" event, i.e.,
> > when there is a power failure).
> > 
> > Finally, it would be great if you could test the -k flag, to see if it
> > shuts down the power. 
> > 
> > drivers/newhidups -DD -u root -x vendorid=0764 auto -k
> 
> Those tests will have to wait until later, as I'm at work and the
> UPS is at home.

No problem, there is no rush. It would be nice if you could do the
tests at some point though.

> One other bit of weirdness I've noticed is that in order to switch
> back to the hidups driver, I have to unload and reload usbhid.ko.
> When newhidups loads up, /dev/usb/hiddev0 goes away.

Yes, this is normal. Newhidups uses the /proc/bus/usb/... interface,
and the kernel does not allow this and /dev/usb/hiddev0 to be used at
the same time. The kernel actually removes /dev/usb/hiddev0 in this
situation.  Unplugging and re-plugging the USB device should have the
same effect as reloading the kernel driver.