[Nut-upsuser] Powerware 5110 UPS with nut in Ubuntu

[Arnaud Quette]

2009/7/17 Greg Vickers <daehenoc at optusnet.com.au>

> Hi Arnaud,
>

Hey Greg,


>
> > Arnaud Quette <aquette.dev at gmail.com> wrote:
> >
> > Hi Greg
> >
> > first, a thank to Kjell too...
> >
> > 2009/7/12 Greg Vickers <daehenoc at optusnet.com.au>
> >
> > > Hi Kjell,
> > >
> > >
> > > Kjell Claesson wrote:
> > >
> > >> Hi all,
> > >>>
> > >> Hi Greg,
> > >>
> > >>  I've got a Powerware 5110 UPS that I'm trying to set up with nut in
> > >>> Ubuntu.  I've installed nut and configured the first two files:
> > >>>
> > >>> $ cat /etc/nut/nut.conf
> > >>> MODE=standalone
> > >>> $ cat /etc/nut/ups.conf
> > >>> [pw5110]
> > >>>        driver = bcmxcp_usb
> > >>>        port = auto
> > >>> #       port = /dev/bus/usb/002/002
> > >>>
> > >> Yes the port should be auto.
> > >> And if you use the latest libusb you should have a device
> > >> at /dev/bus/usb/002/002 that you have found.
> > >>
> > >>
> > >>> When I try to test this configuration with the following command:
> > >>> $ sudo upsdrvctl start pw5110
> > >>> Network UPS Tools - UPS driver controller 2.4.1
> > >>> Network UPS Tools - BCMXCP UPS driver 0.21 (2.4.1)
> > >>> USB communication subdriver 0.17
> > >>> Can't set POWERWARE USB configuration
> > >>> Unable to find POWERWARE UPS device on USB bus
> > >>>
> > >>>
> > >> To make a real test that it read the usb you can do the following.
> > >> Set libusb debug to 3.
> > >> sudo export LIBUSB_DEBUG=3
> > >>
> > >> Then run the driver in debug (not by upsdrvctl).
> > >> sudo /path/to/bcmxcp_usb -DD -u -a pw5110
> > >>
> > >> Now it should spit out some info. You end it by ctrl-c.
> > >>
> > >> Report back and we can have a look.
> > >>
> > >> We may have a bug here, but it is not confirmed as our tests
> > >> does not reveal it.
> > >>
> > >
> > > After leaving my Ubuntu host overnight, I've turned it on and the nut
> > > daemon was running when I tried the above check.  I stopped that
> > daemon and
> > > the above test worked just fine!  I didn't change anything and now
> > it's
> > > working just fine.
> > >
> > > Thank you for the information about the debug test!  All OK now! :)
> >
> > well, ok now, but there is still something under the hood!
> > my guess is that the udev update change introduced by Scott James
> > doesn't fully refresh the udev rights.
> > I've not taken the time to validate it though, so mea culpa.
> > the result is basically that if you don't unplug/replug your device or
> > reboot your system after nut installation, the udev rule is not applied.
>
> I did try unplugging and replugging the USB cable the UPS was attached by,
> and still couldn't contact the UPS correctly.  I have also had trouble on
> this system with the IR receiver on my TV tuner card not reappearing on a
> reboot, I have to do a shutdown and turn the host back on to get the IR
> receiver device to reappear.  I didn't diagnose this IR receiver problem
> until after that night, so I suspect that this may have impacted the UPS
> communication as well.
>

you're running Jaunty, right?
what perms do you have on your device (when it was not nut)?
a simple test (I've just replayed here) is to remove nut (don't purge,
you'll keep your config), unplug your UPS USB cord, plug it back and check
the device, ie /dev/bus/usb/XXX/YYY
where XXX is the Bus number and YYY the Device number, as given by lsusb.

here it was vboxusers (due to VirtualBox installed here).


> However, now when I do a reboot, the UPS is detected just fine - go figure.
>
> At one point I was suspicious that the udev rule wasn't being run, and
> tried copying it into /etc/udev/rules.d, and un/re-plugging the UPS, but to
> no avail.
>

/etc/udev/rules.d is now for local rules (ie the ones created by the
user/sysadmin).
the distro rules now sits in /lib/udev/rules.d...


> > I'll try to check that tomorrow, and make some more progress on 2.4.1-4,
> > which will be a major Debian update.
>

ok, I've validated that the faulty bits is the new call to udevadm (thanks
Scott James for this change!)
udevadm trigger --action=change
that is not sufficient to refresh (coldplug) the device perms without the
before mentioned system reboot or device unplug/replug...
the problem is that the previous call (udevadm trigger
--subsystem-match=usb_device) will refresh all USB devices, resulting in a
kind of reset.
I've gotta check for a more suitable solution.

cheers,
Arnaud
-- 
Linux / Unix Expert R&D - Eaton - http://www.eaton.com/mgeops
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20090717/f00373bf/attachment-0001.htm>