Nut upsdev - May 2019 - Update to user-manual.html#Configuration_notes

Charles, All, Arjen (if he is still kicking),

  I have run CyberPower ups's with NUT for a number of years, and aside from
newer model voltage scaling, etc.., the usbhid driver installs have always
just worked.

  I ended up with another CP UPS and installed 2.7.4-5 from the AUR package
for Arch. As soon as I plugged the UPS in, it was found instantly, so I
expected no problems with the configuration or starting the upsd service.

  I set ups.conf as:

/etc/ups/ups.conf
[stp_ups]
        driver = usbhid-ups
        port = auto
        desc = "stp CP825 UPS"

  However, no matter what I tried, I ended up with a failed start:

May 12 22:16:41 2pi systemd[1]: Starting Network UPS Tools - power device
driver controller...
May 12 22:16:41 2pi upsdrvctl[541]: Network UPS Tools - Generic HID driver
0.41 (2.7.4)
May 12 22:16:41 2pi upsdrvctl[541]: USB communication driver 0.33
May 12 22:16:41 2pi upsdrvctl[541]: No matching HID UPS found
May 12 22:16:41 2pi upsdrvctl[541]: Driver failed to start (exit status=1)
May 12 22:16:41 2pi upsdrvctl[541]: Network UPS Tools - UPS driver controller
2.7.4
May 12 22:16:41 2pi systemd[1]: nut-driver.service: Control process exited,
code=exited, status=1/FAILURE
May 12 22:16:41 2pi systemd[1]: nut-driver.service: Failed with result
'exit-code'.
May 12 22:16:41 2pi systemd[1]: Failed to start Network UPS Tools - power
device driver controller.

  I tried the old port = /dev/hiddev0, same result. I searched though
user-manual.html#Configuration_notes and couldn't find a solution.
Thankfully,
the Arch wiki page had the answer,
https://wiki.archlinux.org/index.php/Network_UPS_Tools

  The problem is permission and the solution is a Udev rule is needed. The
Arch page provided the following:

<quote>

If you receive an error message like this one:

  Can't claim USB device [XXXX:YYYY]: could not detach kernel driver from
  interface 0: Operation not permitted
  Driver failed to start (exit status=1)

Or a less specific one:

  USB communication driver 0.33
  No matching HID UPS found
  Driver failed to start (exit status=1)

It's most likely a problem with permissions for accessing the device. You
can
fix that by specifying an udev rule that sets the correct group:

  /etc/udev/rules.d/50-ups.rules

  SUBSYSTEM=="usb", ATTR{idVendor}=="XXXX",
ATTR{idProduct}=="YYYY",
SYMLINK+="ups0", GROUP="nut"

Where idVendor and idProduct are the device manufacturer and product ID. You
can see these either in the error output [XXXX:YYYY] or by using lsusb.

After this is done, reload and retrigger udev rules by issuing this command:

  # udevadm control --reload-rules && udevadm trigger

</quote>

  After adding the rule and calling udevadm, Bingo! Up and running.

Consider adding the information about the permission errors and Udev rule to
tuser-manual.html. That is the first place I thought to look, but either it
missed the information of it wasn't there.

  Thanks for your work on NUT. Wonderful tool.

-- 
David C. Rankin, J.D.,P.E.

On May 13, 2019, at 12:51 AM, David C. Rankin wrote:
> 
> Consider adding the information about the permission errors and Udev rule
to
> tuser-manual.html. That is the first place I thought to look, but either it
> missed the information of it wasn't there.
> 
We do have this in the FAQ, though I realize we don't have many links from
the main user manual:

https://networkupstools.org/docs/FAQ.html#_my_usb_ups_is_supported_but_doesn_8217_t_work

I made a note to update this: https://github.com/networkupstools/nut/issues/696

Was the AUR package missing a udev entry for that UPS? If so, is it in the
upstream NUT repository? The UDEV files are generated from the C source of the
drivers, so in your case, that would be this table:

https://github.com/networkupstools/nut/blob/master/drivers/cps-hid.c#L56

Another possibility is that the AUR package puts the udev file in the wrong
place relative to other system-provided udev files, as was the case in Debian:

https://github.com/networkupstools/nut/issues/140

If the AUR package doesn't run the udevadm command that you mentioned as
part of its postinstall script (or equivalent script), I would recommend that
you file a bug with the packagers.