Re: [Nut-upsuser] Device not supported?

[Manuel Wolfshant]

On 07/06/2017 02:50 AM, Charles Lepple wrote:

On Jul 5, 2017, at 7:45 PM, Manuel Wolfshant  wrote:

udevadm control --reload ||:

from the man page:

--reload
Signal systemd-udevd to reload the rules files and other databases 
like the kernel module index. Reloading rules and databases does not apply any 
changes to already existing devices; the new configuration will only be applied 
to new events.

So that might not be sufficient for devices that are plugged in at the time the 
package is installed.


Thanks for the heads up. Docs say:

   I've installed udev rules and want udev to do something about it.

udevadm trigger --action=change

*and* Depend on udev (you can't udevadm when udev is
unconfigured)

The action argument is of utmost importance.  Without it, the
kernel will tell udev to treat all devices as *NEW*.  This will
have lots of side-effects you are probably not expecting.

"change" is completely safe.  It tells udev just to refresh
devices, and make sure everything's as it should be.


So I have changed my spec file to issue the trigger command you 
mentioned earlier.



___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Device not supported?

[Charles Lepple]

> On Jul 5, 2017, at 7:45 PM, Manuel Wolfshant  wrote:
> 
> udevadm control --reload ||:

from the man page:

--reload
   Signal systemd-udevd to reload the rules files and other databases 
like the kernel module index. Reloading rules and databases does not apply any 
changes to already existing devices; the new configuration will only be applied 
to new events.

So that might not be sufficient for devices that are plugged in at the time the 
package is installed.
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Device not supported?

[Manuel Wolfshant]

On 07/06/2017 02:38 AM, Charles Lepple wrote:

On Jul 5, 2017, at 7:23 PM, Manuel Wolfshant wrote:

Manuel: did you happen to regenerate the udev files, or use one of the Buildbot tarballs? 
We typically don't bother to do that until "make dist" before a release (since 
the rules files are generated from *.in files based on configure parameters), so your 
package might still have the rules file from 2.7.4 (which does not include protocol 1330).

yes, the package installed by Mr. Coletti includes the new rules:

Thanks for checking. (I really should set up a Fedora VM and/or learn how to 
use alien to check on things like this.)
I was tempted to say that alien sucks donkey balls but that would not be 
polite, would it ?
Beware that despite the heavy backporting done by RH, fedora is far 
ahead of RHEL 7 and very far ahead of RHEL 6 ( especially in terms of 
libraries )





Does udev automatically reload when the rules files change? The Debian/Ubuntu packages 
are supposed to run "udevadm trigger --subsystem-match=usb --action=change" as 
part of the postinst.
I've stolen from the fedora package the following gem which , AFAIK ( I 
am no udev wizard.. ) does the same thing:


postinstall scriptlet (using /bin/sh):
/sbin/ldconfig
udevadm control --reload ||:


(I think udev rescans the rules when a device is plugged in, so unplugging and 
re-plugging the USB cable should work, too.)


you are 100% right here, AFAIK


___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Device not supported?

[Charles Lepple]

On Jul 5, 2017, at 7:23 PM, Manuel Wolfshant wrote:
> 
>> Manuel: did you happen to regenerate the udev files, or use one of the 
>> Buildbot tarballs? We typically don't bother to do that until "make dist" 
>> before a release (since the rules files are generated from *.in files based 
>> on configure parameters), so your package might still have the rules file 
>> from 2.7.4 (which does not include protocol 1330).
> yes, the package installed by Mr. Coletti includes the new rules:

Thanks for checking. (I really should set up a Fedora VM and/or learn how to 
use alien to check on things like this.)

Does udev automatically reload when the rules files change? The Debian/Ubuntu 
packages are supposed to run "udevadm trigger --subsystem-match=usb 
--action=change" as part of the postinst.

(I think udev rescans the rules when a device is plugged in, so unplugging and 
re-plugging the USB cable should work, too.)
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Device not supported?

[Manuel Wolfshant]

On 07/06/2017 02:23 AM, Manuel Wolfshant wrote:

On 07/06/2017 02:18 AM, Charles Lepple wrote:
On Jul 5, 2017, at 5:34 PM, Ambrogio Coletti > wrote:


From section 4.23 of the Developer Guide:

"There are a few USB UPS devices that are not HID devices. These 
devices typically implement some version of the manufacturer’s 
serial protocol over USB (which is a really dumb idea, by the way). 
An example is the Tripplite USB. Such devices are not supported by 
the usbhid-ups driver, and are not covered in this document."


I guess that applies to me?


No, but my original comment does:

"The Protocol 1330 support was added after 2.7.4 was released. You 
might be able to use a 2.7.4 tarball with "productid = 1330" in 
ups.conf, but voltages might be off by a factor of 10. *You will also 
need to adjust the udev files manually to fix /dev/bus/usb 
permissions.*"


Manuel: did you happen to regenerate the udev files, or use one of 
the Buildbot tarballs? We typically don't bother to do that until 
"make dist" before a release (since the rules files are generated 
from *.in files based on configure parameters), so your package might 
still have the rules file from 2.7.4 (which does not include protocol 
1330).

yes, the package installed by Mr. Coletti includes the new rules:

# TrippLite
[...]
#  e.g. TrippLite ECO550UPS  - usbhid-ups
ATTR{idVendor}=="09ae", ATTR{idProduct}=="1010", MODE="664", 
GROUP="dialout"

#  e.g. TrippLite SU3000LCD2UHV  - usbhid-ups
ATTR{idVendor}=="09ae", ATTR{idProduct}=="1330", MODE="664", 
GROUP="dialout"

#  e.g. TrippLite OMNI1000LCD  - usbhid-ups
ATTR{idVendor}=="09ae", ATTR{idProduct}=="2005", MODE="664", 
GROUP="dialout"

[...]
I forgot to mention that the above is a quote from 
/lib/udev/rules.d/62-nut-usbups.rules


___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Device not supported?

[Manuel Wolfshant]

On 07/06/2017 02:18 AM, Charles Lepple wrote:
On Jul 5, 2017, at 5:34 PM, Ambrogio Coletti > wrote:


From section 4.23 of the Developer Guide:

"There are a few USB UPS devices that are not HID devices. These 
devices typically implement some version of the manufacturer’s 
serial protocol over USB (which is a really dumb idea, by the way). 
An example is the Tripplite USB. Such devices are not supported by 
the usbhid-ups driver, and are not covered in this document."


I guess that applies to me?


No, but my original comment does:

"The Protocol 1330 support was added after 2.7.4 was released. You 
might be able to use a 2.7.4 tarball with "productid = 1330" in 
ups.conf, but voltages might be off by a factor of 10. *You will also 
need to adjust the udev files manually to fix /dev/bus/usb permissions.*"


Manuel: did you happen to regenerate the udev files, or use one of the 
Buildbot tarballs? We typically don't bother to do that until "make 
dist" before a release (since the rules files are generated from *.in 
files based on configure parameters), so your package might still have 
the rules file from 2.7.4 (which does not include protocol 1330).

yes, the package installed by Mr. Coletti includes the new rules:

# TrippLite
[...]
#  e.g. TrippLite ECO550UPS  - usbhid-ups
ATTR{idVendor}=="09ae", ATTR{idProduct}=="1010", MODE="664", GROUP="dialout"
#  e.g. TrippLite SU3000LCD2UHV  - usbhid-ups
ATTR{idVendor}=="09ae", ATTR{idProduct}=="1330", MODE="664", GROUP="dialout"
#  e.g. TrippLite OMNI1000LCD  - usbhid-ups
ATTR{idVendor}=="09ae", ATTR{idProduct}=="2005", MODE="664", GROUP="dialout"
[...]


___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Device not supported?

[Charles Lepple]

On Jul 5, 2017, at 5:34 PM, Ambrogio Coletti  wrote:
> 
> From section 4.23 of the Developer Guide:
> 
> "There are a few USB UPS devices that are not HID devices. These devices 
> typically implement some version of the manufacturer’s serial protocol over 
> USB (which is a really dumb idea, by the way). An example is the Tripplite 
> USB. Such devices are not supported by the usbhid-ups driver, and are not 
> covered in this document."
> 
> I guess that applies to me?

No, but my original comment does:

"The Protocol 1330 support was added after 2.7.4 was released. You might be 
able to use a 2.7.4 tarball with "productid = 1330" in ups.conf, but voltages 
might be off by a factor of 10. You will also need to adjust the udev files 
manually to fix /dev/bus/usb permissions."

Manuel: did you happen to regenerate the udev files, or use one of the Buildbot 
tarballs? We typically don't bother to do that until "make dist" before a 
release (since the rules files are generated from *.in files based on configure 
parameters), so your package might still have the rules file from 2.7.4 (which 
does not include protocol 1330).

The comment in the developer guide was mostly accurate when we first saw 
Tripp-Lite USB devices with VID:PID 09ae:0001. Technically, they implement the 
USB HID protocol, but not the intended USB HID PDC (Power Device Class) spec. 
It looks like every PID other than 0001 (including 1330) implements PDC.___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Device not supported?

[Ambrogio Coletti]

>From section 4.23 of the Developer Guide:

"There are a few USB UPS devices that are not HID devices. These devices
typically implement some version of the manufacturer’s serial protocol over
USB (which is a really dumb idea, by the way). An example is the Tripplite
USB. Such devices are *not* supported by the usbhid-ups driver, and are not
covered in this document."

I guess that applies to me?

On Wed, Jul 5, 2017 at 3:19 PM Ambrogio Coletti  wrote:

> I've eventually installed Manuel's packages (nut and nut-client).
>
> When I run the driver as root (for my tripplite ups) I get:
>
> /usr/sbin/upsdrvctl start
> Network UPS Tools - Generic HID driver 0.42 (v2.7.4-418-gb1314c62.7.4.1)
> USB communication driver (libusb 0.1) 0.33
> writepid: fopen /var/run/nut/usbhid-ups-trippliteups.pid: Permission denied
> Can't claim USB device [09ae:1330]: could not detach kernel driver from
> interface 0: Operation not permitted
> Driver failed to start (exit status=1)
>
> And I had to create manually /var/run/nut.
>
> What is the problem there?
>
> On Fri, Jun 23, 2017 at 8:27 PM Manuel Wolfshant 
> wrote:
>
>> On 06/24/2017 04:52 AM, Charles Lepple wrote:
>> > On Jun 23, 2017, at 5:50 PM, Ambrogio Coletti 
>> wrote:
>> >> "This TrippLite device (09ae:1330) is not (or perhaps not yet)
>> supported by usbhid-ups. [...]"
>> >> but my device (SU2200RTXLCD2U) is supported, as clearly state here.
>> > No, the HCL also mentions "protocol 4001". For Tripp-Lite, a USB PID
>> other than 0001 is generally the protocol number. So your SU2200* model is
>> different.
>> >
>> > https://github.com/networkupstools/nut/issues/64
>> >
>> >> Then I thought I needed the last src code (2.7.4), hence I built it
>> for my machine, but when I run it by:
>> >> /usr/local/ups/sbin/upsdrvctl start
>> > The Protocol 1330 support was added after 2.7.4 was released. You might
>> be able to use a 2.7.4 tarball with "productid = 1330" in ups.conf, but
>> voltages might be off by a factor of 10. You will also need to adjust the
>> udev files manually to fix /dev/bus/usb permissions.
>> >
>> > If you do choose to build using the latest source code from Git, be
>> aware that you will need more tools, as specified in the Developer Guide:
>> http://networkupstools.org/docs/developer-guide.chunked/ar01s03.html#building
>> >
>> > It may be easier to use the 2.7.4 tarball, and add the patch which
>> introduces Protocol 1330 support to the RPM spec file:
>> https://github.com/networkupstools/nut/commit/4eff5b7068e9873ce11b5a296f403e8cdf0e3580
>> I've uploaded to http://wolfy.fedorapeople.org/nut a new set of packages
>> based on the latest source code from git. Unfortunately they do not
>> include any man pages, I did not have time to find a workaround for the
>> hard requirement of newer versions for the tools used by the build
>> process to create the man pages. I will fix that in a later set of
>> packages.
>>
>> ___
>> Nut-upsuser mailing list
>> Nut-upsuser@lists.alioth.debian.org
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
>>
>
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Device not supported?

[Manuel Wolfshant]

On 07/06/2017 12:19 AM, Ambrogio Coletti wrote:

I've eventually installed Manuel's packages (nut and nut-client).

When I run the driver as root (for my tripplite ups) I get:

/usr/sbin/upsdrvctl start
Network UPS Tools - Generic HID driver 0.42 (v2.7.4-418-gb1314c62.7.4.1)
USB communication driver (libusb 0.1) 0.33
writepid: fopen /var/run/nut/usbhid-ups-trippliteups.pid: Permission 
denied
that is odd because nut-client should have created /var/run/nut/. If you 
run rpm -ql nut-client you will notice that /var/run/nut is listed in 
the very last line:


[root@belgrade ~]# rpm -ql --qf "%{name}-%{version}-%{release}\n\n" 
nut-client
nut-client-2.7.5-0.20170613gitb1314c6.el6.wolfy.usb01 (ignore the 
"usb01" tag, I added it for my personal reference since I built against 
various libusb versions)


/etc/rc.d/init.d/ups
/etc/ups
/etc/ups/upsmon.conf
/etc/ups/upssched.conf
[...]
/usr/share/pixmaps/nut-monitor.png
/var/lib/ups
/var/run/nut  <=



Can't claim USB device [09ae:1330]: could not detach kernel driver 
from interface 0: Operation not permitted
That's the error I get with one of my UPSes ( an Eaton ) as well. No 
solution so far for me.





Driver failed to start (exit status=1)

And I had to create manually /var/run/nut.

What is the problem there?
I am really puzzled. Do you get any selinux related errors ( running 
aureport -ts today -a should list the AVCs if any )?





On Fri, Jun 23, 2017 at 8:27 PM Manuel Wolfshant 
> wrote:


On 06/24/2017 04:52 AM, Charles Lepple wrote:
> On Jun 23, 2017, at 5:50 PM, Ambrogio Coletti
> wrote:
>> "This TrippLite device (09ae:1330) is not (or perhaps not yet)
supported by usbhid-ups. [...]"
>> but my device (SU2200RTXLCD2U) is supported, as clearly state here.
> No, the HCL also mentions "protocol 4001". For Tripp-Lite, a USB
PID other than 0001 is generally the protocol number. So your
SU2200* model is different.
>
> https://github.com/networkupstools/nut/issues/64
>
>> Then I thought I needed the last src code (2.7.4), hence I
built it for my machine, but when I run it by:
>> /usr/local/ups/sbin/upsdrvctl start
> The Protocol 1330 support was added after 2.7.4 was released.
You might be able to use a 2.7.4 tarball with "productid = 1330"
in ups.conf, but voltages might be off by a factor of 10. You will
also need to adjust the udev files manually to fix /dev/bus/usb
permissions.
>
> If you do choose to build using the latest source code from Git,
be aware that you will need more tools, as specified in the
Developer Guide:

http://networkupstools.org/docs/developer-guide.chunked/ar01s03.html#building
>
> It may be easier to use the 2.7.4 tarball, and add the patch
which introduces Protocol 1330 support to the RPM spec file:

https://github.com/networkupstools/nut/commit/4eff5b7068e9873ce11b5a296f403e8cdf0e3580
I've uploaded to http://wolfy.fedorapeople.org/nut a new set of
packages
based on the latest source code from git. Unfortunately they do not
include any man pages, I did not have time to find a workaround
for the
hard requirement of newer versions for the tools used by the build
process to create the man pages. I will fix that in a later set of
packages.

___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org

http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser



___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Device not supported?

[Ambrogio Coletti]

I've eventually installed Manuel's packages (nut and nut-client).

When I run the driver as root (for my tripplite ups) I get:

/usr/sbin/upsdrvctl start
Network UPS Tools - Generic HID driver 0.42 (v2.7.4-418-gb1314c62.7.4.1)
USB communication driver (libusb 0.1) 0.33
writepid: fopen /var/run/nut/usbhid-ups-trippliteups.pid: Permission denied
Can't claim USB device [09ae:1330]: could not detach kernel driver from
interface 0: Operation not permitted
Driver failed to start (exit status=1)

And I had to create manually /var/run/nut.

What is the problem there?

On Fri, Jun 23, 2017 at 8:27 PM Manuel Wolfshant 
wrote:

> On 06/24/2017 04:52 AM, Charles Lepple wrote:
> > On Jun 23, 2017, at 5:50 PM, Ambrogio Coletti 
> wrote:
> >> "This TrippLite device (09ae:1330) is not (or perhaps not yet)
> supported by usbhid-ups. [...]"
> >> but my device (SU2200RTXLCD2U) is supported, as clearly state here.
> > No, the HCL also mentions "protocol 4001". For Tripp-Lite, a USB PID
> other than 0001 is generally the protocol number. So your SU2200* model is
> different.
> >
> > https://github.com/networkupstools/nut/issues/64
> >
> >> Then I thought I needed the last src code (2.7.4), hence I built it for
> my machine, but when I run it by:
> >> /usr/local/ups/sbin/upsdrvctl start
> > The Protocol 1330 support was added after 2.7.4 was released. You might
> be able to use a 2.7.4 tarball with "productid = 1330" in ups.conf, but
> voltages might be off by a factor of 10. You will also need to adjust the
> udev files manually to fix /dev/bus/usb permissions.
> >
> > If you do choose to build using the latest source code from Git, be
> aware that you will need more tools, as specified in the Developer Guide:
> http://networkupstools.org/docs/developer-guide.chunked/ar01s03.html#building
> >
> > It may be easier to use the 2.7.4 tarball, and add the patch which
> introduces Protocol 1330 support to the RPM spec file:
> https://github.com/networkupstools/nut/commit/4eff5b7068e9873ce11b5a296f403e8cdf0e3580
> I've uploaded to http://wolfy.fedorapeople.org/nut a new set of packages
> based on the latest source code from git. Unfortunately they do not
> include any man pages, I did not have time to find a workaround for the
> hard requirement of newer versions for the tools used by the build
> process to create the man pages. I will fix that in a later set of
> packages.
>
> ___
> Nut-upsuser mailing list
> Nut-upsuser@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
>
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

[Nut-upsuser] (no subject)

[Andrea de Lutti]

2017-07-05 13:32 GMT+02:00 Charles Lepple :

> On Jul 5, 2017, at 7:05 AM, Andrea de Lutti  wrote:
> >
> > Which are the ups.status I can use with ups in dummy mode?
> > I have seen only OB, LB, OL...
> >
> Those are the ones that upsmon will respond to. The dummy-ups driver
> accepts any string, AFAIK.
>
> Others: http://networkupstools.org/docs/developer-guide.chunked/
> ar01s04.html#_manipulating_the_data
> ___
>

​What if I would like to implement a notification for [OL CAL] status
during battery calibration?​
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Help with Elite 800VA usb UPS

[Charles Lepple]

On Jul 5, 2017, at 7:05 AM, Andrea de Lutti  wrote:
> 
> Which are the ups.status I can use with ups in dummy mode?
> I have seen only OB, LB, OL...
> 
Those are the ones that upsmon will respond to. The dummy-ups driver accepts 
any string, AFAIK.

Others: 
http://networkupstools.org/docs/developer-guide.chunked/ar01s04.html#_manipulating_the_data
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser

Re: [Nut-upsuser] Help with Elite 800VA usb UPS

[Andrea de Lutti]

Thank you lots! Finally I have everything working!
Which are the ups.status I can use with ups in dummy mode?
I have seen only OB, LB, OL...

thank you
Andrea

2017-07-04 19:55 GMT+02:00 Charles Lepple :

> On Jul 3, 2017, at 11:06 AM, Andrea de Lutti  wrote:
> >
> > ​I would like that NOTIFYCMD points to upssched​.
> >
> If I understand correctly, Roger is pointing out that your configuration
> is confusing upssched and upssched-script.
>
> Since you are using Ubuntu, upsmon.conf should contain "NOTIFYCMD
> /sbin/upssched". Similarly, upssched.conf should contain "CMDSCRIPT
> /usr/local/bin/upssched-script".
>
> Not sure if those passwords in the script are real, but if they are, you
> will want to change them now.
> ___
> Nut-upsuser mailing list
> Nut-upsuser@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
>
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser