Nut upsuser - Feb 2015 - Install problems (group permissions) with nut 2.7.2

I think I had a misconception about something..

My goal was that someone could use our UPS with the "default" UPS
driver in NUT right out of the box, so they wouldn't have to alter any NUT
code to get it working.  NUT config files, yes, but not NUT code.

I thought that if I put in the ups.conf file that I wanted to use the usbhid-ups
driver, and then put our vendor and product ID, it would find whatever USB
device matched those vid and pid, and then use the usbhid-ups driver with it.

Instead, it seems that the usbhid-ups driver will search through its own list of
known devices with vid/pid, and won't "match" my device unless
that device exists as an entry in its device table.  Is that correct?

In other words, instead of the ups.conf file saying "Use usbhid-ups with
USB device of vid/pid", it is saying "Use usbhid-ups with USB device
of vid/pid *if* they are in the list of devices for usbhid-ups"?


Sincerely,
Rob Groner
> -----Original Message-----
> From: Charles Lepple [mailto:clepple at gmail.com]
> Sent: Thursday, February 19, 2015 10:09 PM
> To: Rob Groner
> Cc: nut-upsuser List
> Subject: Re: [Nut-upsuser] Install problems (group permissions) with nut
> 2.7.2
> 
> On Feb 19, 2015, at 8:43 AM, Rob Groner <rgroner at RTD.com> wrote:
> 
> > I looked at the file and saw how it was laid out...basically an ATTR
for every
> known USB UPS.  Well, since mine is not a known UPS, I had to add my own
> entry.
> 
> If you want, once things are working, we can add an entry to that table
(via
> drivers/usbhid-ups.c, which gets parsed into the udev script)
> 
> >  So I added a similar entry to all the others, but putting in my USB
vendor
> and product IDs and setting GROUP="nut" (like all the other
entries do).
> >
> > ATTR{idVendor}=="04d8", ATTR{idProduct}=="005c",
MODE="664",
> GROUP="nut"
> >
> You might need to tell udev to reload, although newer versions seem to re-
> read the rules files automatically.
> 
> Also, I think there is a debug mode for udev that will show what is being
> parsed when.
> 
> > But so far as I can tell, when I plug in the USB cable from the
UPS...it is still
> not setting it to nut group permissions.  I am looking at the file in
> /dev/usb/hid/hiddev0 (which goes away when I unplug the UPS).  Either
> way, upsdrvctrl still won't start unless I add "-u root".
> 
> /dev/bus/usb/*/* is the place to look (the hiddev* nodes are not used by
> libusb). Once the permissions there look correct, can you post the output
of
> running the driver directly with -D?

On Feb 20, 2015, at 3:15 PM, Rob Groner <rgroner at RTD.com> wrote:
> Instead, it seems that the usbhid-ups driver will search through its own
list of known devices with vid/pid, and won't "match" my device
unless that device exists as an entry in its device table.  Is that correct?
More or less, yes.

It turns out that UPS vendors all have somewhat different interpretations of the
PDC spec.

There was an idea to create a generic fallback driver that could talk to any USB
HID PDC device:

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

But at the moment, when we suggest passing the 'productid = ' parameter
to usbhid-ups, it is because there is already a set of tables for that vendor,
and their model is not all that different from earlier models.

The nutdrv_qx driver might be more flexible in this regard, since we tend to see
different VID:PID combinations for devices that all speak one of several easily
identifiable dialects of the Megatec Q* protocols.

- Charles Lepple
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150220/716dd294/attachment.html>

Ok, so please correct me if I?m wrong?.

The quickest way to get my UPS running with nut (as the current release exists)
is to either:


1)      Add my vendor and device ID to the openups_usb_device_table  OR

2)      Create my own driver file, and then add that driver to the usbhid-ups
subdriver_list

And then recompile/install.

Obviously #1 will be easier at this point, but I understand that it will only
get me the functionality that currently exists in the openups driver (which is
ok, I structured my USB reports around what that driver makes available).  If I
want full functionality I?ll need to eventually make my own driver file.

Sincerely,
Rob Groner

From: Charles Lepple [mailto:clepple at gmail.com]
Sent: Friday, February 20, 2015 7:50 PM
To: Rob Groner
Cc: nut-upsuser List
Subject: Re: [Nut-upsuser] Install problems (group permissions) with nut 2.7.2

On Feb 20, 2015, at 3:15 PM, Rob Groner <rgroner at RTD.com<mailto:rgroner
at RTD.com>> wrote:

Instead, it seems that the usbhid-ups driver will search through its own list of
known devices with vid/pid, and won't "match" my device unless
that device exists as an entry in its device table.  Is that correct?

More or less, yes.

It turns out that UPS vendors all have somewhat different interpretations of the
PDC spec.

There was an idea to create a generic fallback driver that could talk to any USB
HID PDC device:

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

But at the moment, when we suggest passing the 'productid = ' parameter
to usbhid-ups, it is because there is already a set of tables for that vendor,
and their model is not all that different from earlier models.

The nutdrv_qx driver might be more flexible in this regard, since we tend to see
different VID:PID combinations for devices that all speak one of several easily
identifiable dialects of the Megatec Q* protocols.

- Charles Lepple
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20150225/21598cbc/attachment.html>