search for: usbup

I have an FC5 system with a powerware 5110 usb ups. The system seems to find the UPS ------------------------------ [root@b1 src]# lsusb Bus 004 Device 001: ID 0000:0000 Bus 003 Device 002: ID 0592:0002 Powerware Corp. Bus 003 Device 001: ID 0000:0000 Bus 002 Device 001: ID 0000:0000 Bus 005 Device 001: ID 0000:0000 Bus 001 Device 001: ID 0000:0000 ------------------------------- [root@b1

...Powerware 5115A using the following steps: 1. sudo apt-get source nut 2. sudo apt-get build-dep nut 3. wget 'http://svn.debian.org/wsvn/nut/trunk/drivers/nut_usb.c?op=file&rev=1220&sc=1' -O nut_usb.c.new 4. wget 'http://boxster.ghz.cc/projects/nut/browser/trunk/scripts/udev/nut-usbups.rules.in?format=raw' -O nut-usbups.rules.in.new 5. wget 'http://svn.debian.org/wsvn/nut/trunk/drivers/nut_usb.h?op=file&rev=1220&sc=1' -O nut_usb.h.new 6. mkdir nut-2.2.1/debian/patches 7. diff -ruN nut-2.2.1/drivers/nut_usb.c nut_usb.c.new | dpatch patch-template -p > nut-2...

...ux 4.4.0-72-generic x86_64) nut V2.7.1 installed from repository /etc/nut/ups.conf [HPR1500] driver=usbhid-ups port=auto After dealing hours with this, hope this will help some : rename udev rule to higher priority and move it to its right location, reload udev rules mv /lib/udev/rules.d/52-nut-usbups.rules /lib/udev/rules.d/62-nut-usbups.rules cp /lib/udev/rules.d/62-nut-usbups.rules /etc/udev/rules.d/ udevadm control --reload-rules udevadm trigger reboot server to be sure everything is OK Nicolas upsc HPR1500 Init SSL without certificate database battery.charge: 100 battery.charge.low: 20...

.../* e.g. TrippLite Smart1000LCD */ + { USB_DEVICE(TRIPPLITE_VENDORID, 0x2009), battery_scale_0dot1 }, /* e.g. TrippLite smart2200RMXL2U */ { USB_DEVICE(TRIPPLITE_VENDORID, 0x3012), battery_scale_1dot0 }, /* e.g. ? */ diff --git a/src/nut/nut-2.4.3/scripts/udev/52-nut-usbups.rules b/etc/udev/rules.d/52-nut-usbups.rules index c8f0437..fbb03df 100644 --- a/src/nut/nut-2.4.3/scripts/udev/52-nut-usbups.rules +++ b/etc/udev/rules.d/52-nut-usbups.rules @@ -92,6 +92,8 @@ ATTR{idVendor}=="09ae", ATTR{idProduct}=="1008", MODE="664", GROUP="nu...

Ok, I installed the ups, and installed nut, and /proc/bus/usb/devices says this T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=1.5 MxCh= 0 D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=06da ProdID=0002 Rev= 0.01 S: Manufacturer=POWERWARE S: Product=Powerware UPS C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr= 20mA I: If#= 0 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=00 Prot=00

On Jan 30, 2015, at 4:22 PM, Melvin Call <melvincall979 at gmail.com> wrote: > At this point I unplugged the UPS and plugged it into a different USP port, but > that did not change the above. Figuring this was likely a udev problem, I > created the following /etc/udev/rules.d/52-nut-usbups.rules (based on an example > on our database server, and changing the vendor and product id values): You may want to rename this from 52- to 62-nut-usbups.rules, which will prevent it from being masked by an earlier rules file. Alternatively, you probably already have a similar file in /lib/u...

Hi Pawel, 2011/7/26 Pawel Sikora <pluto at agmk.net> > On Tuesday 26 of July 2011 14:33:15 you wrote: > > Hi Pawel, > > > > 2011/7/26 Pawel Sikora <pluto at agmk.net> > > > > > Hi, > > > > > > i have an orvaldi ups > > > http://en.orvaldi.com/index.php/en/product_catalog/product_view/11/162 > > > and it works

Hi Pawel, 2011/7/26 Pawel Sikora <pluto at agmk.net> > Hi, > > i have an orvaldi ups > http://en.orvaldi.com/index.php/en/product_catalog/product_view/11/162 > and it works fine with blazer_usb driver. could you please add a new udev > rule? > > # ORVALDI 750/900SP - blazer_usb > ATTR{idVendor}=="0665", ATTR{idProduct}=="5161",

Hi, I have a UPS device that seems to work fine with the blazer_usb driver. (I have guessed the driver by googling up the "Product" usb string 010937). However, it does not appear in the supported list, and I had to manually add a udev rule for granting access to the 'nut' user. Would be nice if the info I provide below could be used to help the project/future users to

...it through USB to my Gentoo linux machine running kernel 2.6.22. While the device was detected properly and added to /dev, it was added with the wrong permissions (gid was set to 'usb' instead of 'nut', as it was expected to be according to the rules under /etc/udev/rules.d/70-nut-usbups.rules). Worse, it was improperly setup only during udev coldplug, whereas hotplugging worked fine. Finally, when I recompiled the kernel without CONFIG_USB_DEVICE_CLASS (which is marked DEPRECATED as of 2.6.22), it constantly added the device with the wrong gid. After spending many hours, I man...

I've been using nut to manage a variety of smart and dumb UPS's for about a year now, so I've got no excuse for just subscribing to the list now. Except maybe that the debian-user lists provide plenty of reading material. Anyway, I recently updated a couple of boxes to 2.6.15 kernels from 2.4.x and got to learn fun things about udev. I'm happy to do a write up on a simple udev

...ch kernel driver from interface 0: Operation not permitted Driver failed to start (exit status=1) At this point I unplugged the UPS and plugged it into a different USP port, but that did not change the above. Figuring this was likely a udev problem, I created the following /etc/udev/rules.d/52-nut-usbups.rules (based on an example on our database server, and changing the vendor and product id values): [root at mypc:/etc/nut]# cat /etc/udev/rules.d/52-nut-usbups.rules ACTION!="add|change", GOTO="nut-usbups_rules_end" SUBSYSTEM=="usb_device", GOTO="nut-usbups_rules...

G'day, all! It's my second trouble with NUT. Latest nut-2.6.1.tar.gz installed from source on Xenserver 5.6 SP2, UPS is Powercom WOW--500U FW3.A4 (USB). Problem with setting permissions for udev (described in /etc/udev/rules.d/52-nut-usbups.rules file): ACTION!="add|change", GOTO="nut-usbups_rules_end" don't work for me. Only when I changed ACTION to: ACTION!="add", GOTO="nut-usbups_rules_end" (without |change) - it's began to set correct permissions 0664 for my USB UPS device as sp...

On 6/19/19 5:59 AM, Charles Lepple wrote: >> >> “The 62-nut-usbups.rules file looks pretty standard. Do you know if the changes to 42-usb-hd-pm.rules are needed? It seems like none of the USB devices would have the right permissions if 62-nut-usbups.rules isn't sufficient (though this happened in Debian once).” >> >> My means of testing wasn’t...

...anges necessary: http://www.networkupstools.org/docs/man/nutdrv_qx.html#_notes_for_the_previous_user_of_blazer_drivers It also looks like the Ubuntu 14.04 package still is affected by a udev-related bug: https://bugs.launchpad.net/ubuntu/+source/nut/+bug/1099947/comments/4 If you rename the 52-nut-usbups.rules file to 62-nut-usbups.rules as indicated in that URL, and unplug and re-plug in the USB cable (or run "udevadm trigger -- subsystem-match=usb"), subsequent driver runs should find the USB device. -- Charles Lepple clepple at gmail -------------- next part -------------- An HTM...

...oso 825AVRLCD - usbhid-ups ATTR{idVendor}=="0764", ATTR{idProduct}=="0501", MODE="664", GROUP="nut", RUN+="/sbin/upsdrvctl start" In Ubuntu, the recommended way to do this is described in /etc/udev/rules.d/README. I copied /lib/udev/rules.d/*-nut-usbups.rules to /etc/udev/rules.d/nut-usbups.rules and modified my device's line as shown above. Works like a charm, very stable, and, as a fringe benefit, I can hotplug my UPS, if I need to rearrange my USB cables. HTH, ---SirG

...om repository > > /etc/nut/ups.conf > [HPR1500] > driver=usbhid-ups > port=auto > > After dealing hours with this, hope this will help some : > > rename udev rule to higher priority and move it to its right location, reload > udev rules > mv /lib/udev/rules.d/52-nut-usbups.rules /lib/udev/rules.d/62-nut-usbups.rules > cp /lib/udev/rules.d/62-nut-usbups.rules /etc/udev/rules.d/ > udevadm control --reload-rules > udevadm trigger > reboot server to be sure everything is OK what was the issue before that? [cuuut] > ups.serial: 3C80341001 if you put th...

...from repository > > /etc/nut/ups.conf > [HPR1500] > driver=usbhid-ups > port=auto > > After dealing hours with this, hope this will help some : > > rename udev rule to higher priority and move it to its right location, reload udev rules > mv /lib/udev/rules.d/52-nut-usbups.rules /lib/udev/rules.d/62-nut-usbups.rules > cp /lib/udev/rules.d/62-nut-usbups.rules /etc/udev/rules.d/ > udevadm control --reload-rules > udevadm trigger > reboot server to be sure everything is OK Yes, this has been a known issue for a while: * https://bugs.launchpad.net/ubuntu/...

...rule that will allow upsdrvctl to start gid 'nut'. Theoretically, that is the sort of information that we are already gathering from the NUT drivers: https://github.com/networkupstools/nut/blob/master/tools/nut-usbinfo.pl That script generates (among other things) the scripts/udev/nut-usbups.rules.in file, which gets its @RUN_AS_GROUP@ token replaced by the group name at configure time. On the Debian 7 (wheezy) box where I just verified that udev works, it is installed to /lib/udev/rules.d/52-nut-usbups.rules The necessary-and-sufficient set for the udev rules file (once the device i...

I have been testing out my new MGE Nova 1100 on a system (dual Athlon) running Fedora Core 5 and the newhidups driver seems to be regularly dying. The UPS is the USB model, I have nut-2.0.3-0.1.fc5 and nut-cgi-2.0.3-0.1.fc5 installed. I am running a 2.6.16 kernel. (I haven't upgraded to FC5's 2.6.17 kernel yet as there seem to be some complaints about it.) The driver initially works.