Re: [Nut-upsuser] Eaton 5PX after battery replacement still says "replace battery" in NUT [HCL]
> On 17 Jan 2018, at 2:27 pm, Charles Lepple wrote: > > On Jan 16, 2018, at 6:07 PM, James Whitwell wrote: >> >> This might be a simple thing to fix, but I can’t figure it out. We replaced >> the battery for the first time in our Eaton 5PX a couple of weeks ago, but >> we haven’t been able to clear the “ups.alarm: replace battery!” status. >> >> Details of our installation are: >> OS: Debian 6 >> NUT version: 2.7.4 >> Installation method: from source tarball >> UPS device: Eaton 5PX2000IRT, 240V, 1800W, 2000VA, bought in October 2013 >> > We don't have a complete dump for the 5PX, but I would assume that it has at > least one or two battery test commands, and I would recommend trying the > quick one first. (If you can also send the output of "upscmd -l" and "upsrw", > we can add it to our database.) > > http://networkupstools.org/docs/man/upscmd.html > <http://networkupstools.org/docs/man/upscmd.html> Thanks Charles. I forgot to put in my original email that I had done “test.battery.start.quick” as well. How long does the deep test usually take? We’ll be moving the UPS to another location in a couple of days, so just want to be sure it won’t take that long. “upscmd -l” gives me this: Instant commands supported on UPS [eaton-5px-1]: beeper.disable - Disable the UPS beeper beeper.enable - Enable the UPS beeper beeper.mute - Temporarily mute the UPS beeper beeper.off - Obsolete (use beeper.disable or beeper.mute) beeper.on - Obsolete (use beeper.enable) load.off - Turn off the load immediately load.off.delay - Turn off the load with a delay (seconds) load.on - Turn on the load immediately load.on.delay - Turn on the load with a delay (seconds) outlet.1.load.off - Turn off the load on outlet 1 immediately outlet.1.load.on - Turn on the load on outlet 1 immediately outlet.2.load.off - Turn off the load on outlet 2 immediately outlet.2.load.on - Turn on the load on outlet 2 immediately shutdown.return - Turn off the load and return when power is back shutdown.stayoff - Turn off the load and remain off shutdown.stop - Stop a shutdown in progress test.battery.start.deep - Start a deep battery test test.battery.start.quick - Start a quick battery test test.battery.stop - Stop the battery test And “upsrw” gives me this: [battery.charge.low] Remaining battery level when UPS switches to LB (percent) Type: STRING Maximum length: 5 Value: 20 [battery.charge.restart] Minimum battery level for restart after power off (percent) Type: STRING Maximum length: 3 Value: 0 [battery.energysave] Switch off when running on battery and no/low load Type: STRING Maximum length: 5 Value: no [battery.protection] Prevent deep discharge of battery Type: STRING Maximum length: 5 Value: yes [input.frequency.extended] Extended input frequency range Type: STRING Maximum length: 5 Value: no [input.sensitivity] Input power sensitivity Type: STRING Maximum length: 10 Value: normal [input.transfer.boost.low] Low voltage boosting transfer point (V) Type: STRING Maximum length: 5 Value: 184 [input.transfer.high] High voltage transfer point (V) Type: STRING Maximum length: 5 Value: 294 [input.transfer.low] Low voltage transfer point (V) Type: STRING Maximum length: 5 Value: 160 [input.transfer.trim.high] High voltage trimming transfer point (V) Type: STRING Maximum length: 5 Value: 265 [input.voltage.extended] Extended input voltage range Type: STRING Maximum length: 5 Value: no [outlet.1.autoswitch.charge.low] Remaining battery level to power off this outlet (percent) Type: STRING Maximum length: 3 Value: 0 [outlet.1.delay.shutdown] Interval to wait before shutting down this outlet (seconds) Type: STRING Maximum length: 5 Value: 65535 [outlet.1.delay.start] Interval to wait before restarting this outlet (seconds) Type: STRING Maximum length: 5 Value: 3 [outlet.1.desc] Outlet description Type: STRING Maximum length: 20 Value: PowerShare Outlet 1 [outlet.2.autoswitch.charge.low] Remaining battery level to power off this outlet (percent) Type: STRING Maximum length: 3 Value: 0 [outlet.2.delay.shutdown] Interval to wait before shutting down this outlet (seconds) Type: STRING Maximum length: 5 Value: 65535 [outlet.2.delay.start] Interval to wait before restarting this outlet (seconds) Type: STRING Maximum length: 5 Value: 6 [outlet.2.desc] Outlet description Type: STRING Maximum length: 20 Value: PowerShare Outlet 2 [outlet.desc] Outlet description Type: STRING Maximum length: 20 Value: Main Outlet [output.voltage.nominal] Nominal output voltage (V) Type: ENUM Option: "200" Option: "208" Option: "220" Option: "230" SELECTED Option: "240" [ups.delay.shutdown] Interval to wait after shutdown with delay command (seconds) Type: STRING Maximum length: 10 Value: 20 [ups.delay.start] Interval to wait before (re)starting the load (se
[Nut-upsuser] Eaton 5PX after battery replacement still says "replace battery" in NUT
Hi, This might be a simple thing to fix, but I can’t figure it out. We replaced the battery for the first time in our Eaton 5PX a couple of weeks ago, but we haven’t been able to clear the “ups.alarm: replace battery!” status. Details of our installation are: OS: Debian 6 NUT version: 2.7.4 Installation method: from source tarball UPS device: Eaton 5PX2000IRT, 240V, 1800W, 2000VA, bought in October 2013 Here’s the status as reported by upsc: battery.capacity: 9.00 battery.charge: 100 battery.charge.low: 20 battery.charge.restart: 0 battery.charger.status: floating battery.energysave: no battery.protection: yes battery.runtime: 1032 battery.type: PbAc device.mfr: EATON device.model: Eaton 5PX 2000 device.serial: G098D27047 device.type: ups driver.name: usbhid-ups driver.parameter.pollfreq: 30 driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.parameter.synchronous: no driver.parameter.vendorid: 0463 driver.version: 2.7.4 driver.version.data: MGE HID 1.39 driver.version.internal: 0.41 input.current: 0.00 input.frequency: 49.9 input.frequency.extended: no input.frequency.nominal: 50 input.sensitivity: normal input.transfer.boost.low: 184 input.transfer.high: 294 input.transfer.low: 160 input.transfer.trim.high: 265 input.voltage: 235.0 input.voltage.extended: no input.voltage.nominal: 230 outlet.1.autoswitch.charge.low: 0 outlet.1.current: 1.20 outlet.1.delay.shutdown: 65535 outlet.1.delay.start: 3 outlet.1.desc: PowerShare Outlet 1 outlet.1.id: 1 outlet.1.power: 282 outlet.1.powerfactor: 57.00 outlet.1.realpower: 162 outlet.1.status: on outlet.1.switchable: yes outlet.2.autoswitch.charge.low: 0 outlet.2.current: 0.40 outlet.2.delay.shutdown: 65535 outlet.2.delay.start: 6 outlet.2.desc: PowerShare Outlet 2 outlet.2.id: 2 outlet.2.power: 94 outlet.2.powerfactor: 72.00 outlet.2.realpower: 68 outlet.2.status: on outlet.2.switchable: yes outlet.current: 1.00 outlet.desc: Main Outlet outlet.id: 0 outlet.power: 276 outlet.powerfactor: 99.00 outlet.realpower: 274 outlet.switchable: no output.current: 2.60 output.frequency: 49.9 output.frequency.nominal: 50 output.powerfactor: 0.82 output.voltage: 235.0 output.voltage.nominal: 230 ups.alarm: Replace battery! ups.beeper.status: enabled ups.delay.shutdown: 20 ups.delay.start: 30 ups.efficiency: 95 ups.firmware: 06 ups.load: 30 ups.load.high: 105 ups.mfr: EATON ups.model: Eaton 5PX 2000 ups.power: 611 ups.power.nominal: 2000 ups.productid: ups.realpower: 504 ups.realpower.nominal: 1800 ups.serial: G098D27047 ups.shutdown: enabled ups.start.auto: yes ups.start.battery: yes ups.start.reboot: yes ups.status: ALARM OL CHRG RB ups.test.interval: 604800 ups.test.result: Done and passed ups.timer.shutdown: 0 ups.timer.start: 0 ups.type: offline / line interactive ups.vendorid: 0463 And here’s the output from /usr/local/nut/bin/usbhid-ups -DD -a I had to ^C it after a bit as it was just retrying. Looks like a communications problem with the UPS over the USB cable? We’ve unplugged it and replugged it half a dozen times before this. Network UPS Tools - Generic HID driver 0.41 (2.7.4) USB communication driver 0.33 0.00 debug level is '2' 0.000279 upsdrv_initups... 0.000424 Checking device (0463/) (002/008) 0.275036 - VendorID: 0463 0.275054 - ProductID: 0.275056 - Manufacturer: EATON 0.275059 - Product: Eaton 5PX 0.275061 - Serial Number: G098D27047 0.275063 - Bus: 002 0.275065 - Device release number: 0100 0.275068 Trying to match device 0.275102 Device matches 0.309531 HID descriptor length 2580 4.749244 Report Descriptor size = 2580 4.749684 Using subdriver: MGE HID 1.39 4.749691 234 HID objects found 4.778444 Path: UPS.BatterySystem.Battery.AudibleAlarmControl, Type: Feature, ReportID: 0x28, Offset: 0, Size: 8, Value: 2 4.816700 Path: UPS.BatterySystem.Battery.BatteryID, Type: Feature, ReportID: 0x20, Offset: 0, Size: 8, Value: 1 4.850696 Path: UPS.BatterySystem.Battery.Count, Type: Feature, ReportID: 0x21, Offset: 0, Size: 8, Value: 0 4.886600 Path: UPS.BatterySystem.Battery.DeepDischargeProtection, Type: Feature, ReportID: 0x22, Offset: 0, Size: 8, Value: 1 4.925954 Path: UPS.BatterySystem.Battery.DesignCapacity, Type: Feature, ReportID: 0x23, Offset: 0, Size: 32, Value: 32400 4.964082 Path: UPS.BatterySystem.Battery.PresentStatus.Present, Type: Feature, ReportID: 0x27, Offset: 0, Size: 8, Value: 1 4.964102 Path: UPS.BatterySystem.Battery.PresentStatus.Present, Type: Input, ReportID: 0x27, Offset: 0, Size: 8, Value: 1 4.994604 Path: UPS.BatterySystem.Battery.Test, Type: Feature, ReportID: 0x24, Offset: 0, Size: 8, Value: 1 5.033884 Path: UPS.BatterySystem.Battery.TestPeriod, Type: Feature, ReportID: 0x25, Offset: 0, Size: 32, Value: 604800 5.033899 Path: UPS.BatterySystem.BatterySystemID, Type: Feature, ReportID: 0x20, Offset: 8, Size: 8
[Nut-upsuser] windows beta installer
Hi I have installed nut 2.6.5-6 using the msi installer, but during the install popped up a box asking me to manually install libusb0.dll The msi package doesn't seem to contain the libusb0.dll, the question is, where do I get it from? Thx ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] upssched setup
Roger, Yes thanks I have been using your site as a guide (excellent writeup), trying to work out the difference between OpenSUSE and Ubuntu. I will re-visit this tomorrow and try to tighten up security. Cheers, James > Date: Mon, 27 Apr 2015 23:06:37 +0200 > From: ro...@rogerprice.org > To: nut-upsuser@lists.alioth.debian.org > Subject: Re: [Nut-upsuser] upssched setup > > On Mon, 27 Apr 2015, James Hammond wrote: > > > ... Not too sure where to start with assigning the correct permissions. > > If it is of any help, you will see a full list of the permissions and > owners I use in Table 1 at http://rogerprice.org/NUT.html#SOFT > > Cheers, Roger > > ___ > 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] upssched setup
Gents, Thanks, yes definitely a permissions problem. Roger pointed me in the correct direction with the command to add logging for the script. I have the shutdown working now but need to tighten up the permissions. Not too sure where to start with assigning the correct permissions. Cheers, James > Date: Mon, 27 Apr 2015 21:25:45 +0100 > From: n...@dana.org.uk > To: nut-upsuser@lists.alioth.debian.org > Subject: Re: [Nut-upsuser] upssched setup > > Hi, > > The exec is returning 126 - "Command invoked cannot execute. A > permission or command not executable problem.". > > Are you sure that the script is executable by the user running NUT? Do > you have SELinux enabled? > > Regards, > > > Neil. > > On 27/04/15 20:55, James Hammond wrote: > > Hi Roger, > > > > I get: > > > > Apr 27 20:50:05 unifi upsmon[1022]: UPS ups on battery > > Apr 27 20:50:05 unifi upssched[2688]: Timer daemon started > > Apr 27 20:50:06 unifi upssched[2688]: New timer: onbatt (20 seconds) > > Apr 27 20:50:26 unifi upssched[2688]: Event: onbatt > > Apr 27 20:50:26 unifi upssched[2688]: exec_cmd(/sbin/upssched-cmd.sh > > onbatt) returned 126 > > Apr 27 20:50:41 unifi upssched[2688]: Timer queue empty, exiting > > > > > > /etc/nut/upssched.conf > > > > CMDSCRIPT /sbin/upssched-cmd.sh > > PIPEFN /etc/nut/upssched/upssched.pipe > > LOCKFN /etc/nut/upssched/upssched.lock > > AT ONBATT * START-TIMER onbatt 20 > > AT ONLINE * CANCEL-TIMER onbatt > > > > /sbin/upssched-cmd.sh > > > > #!/bin/sh > > # Debugging: Log all calls to this script > > logger -t upssched-cmd.sh Calling upssched-cmd.sh $1 > > case $1 in > > onbatt) > > /sbin/upsmon -c fsd;; > > *) > > echo "shutdown implemented";; > > esac > > > > Any help gratefully received as this has got me beat. Most files > > have been chmod to 777 with no difference. > > > > Cheers, > > > > James > > > > > Date: Mon, 27 Apr 2015 16:04:34 +0200 > > > From: ro...@rogerprice.org > > > To: nut-upsuser@lists.alioth.debian.org > > > Subject: Re: [Nut-upsuser] upssched setup > > > > > > On Mon, 27 Apr 2015, James Hammond wrote: > > > > > > > Roger, I did and it didnt work. > > > > > > Aha!, what does your upssched.conf look like? If you add the lines: > > > > > > # Debugging: Log all calls to this script > > > logger -t upssched-cmd.sh Calling upssched-cmd.sh $1 > > > > > > to your /sbin/upssched-cmd.sh , what is reported if anything when it > > > doesn't work? Cheers, Roger > > > > > > ___ > > > 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 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] upssched setup
Hi Roger, I get: Apr 27 20:50:05 unifi upsmon[1022]: UPS ups on batteryApr 27 20:50:05 unifi upssched[2688]: Timer daemon startedApr 27 20:50:06 unifi upssched[2688]: New timer: onbatt (20 seconds)Apr 27 20:50:26 unifi upssched[2688]: Event: onbattApr 27 20:50:26 unifi upssched[2688]: exec_cmd(/sbin/upssched-cmd.sh onbatt) returned 126Apr 27 20:50:41 unifi upssched[2688]: Timer queue empty, exiting /etc/nut/upssched.conf CMDSCRIPT /sbin/upssched-cmd.shPIPEFN /etc/nut/upssched/upssched.pipeLOCKFN /etc/nut/upssched/upssched.lockAT ONBATT * START-TIMER onbatt 20AT ONLINE * CANCEL-TIMER onbatt /sbin/upssched-cmd.sh #!/bin/sh# Debugging: Log all calls to this scriptlogger -t upssched-cmd.sh Calling upssched-cmd.sh $1 case $1 in onbatt) /sbin/upsmon -c fsd;; *) echo "shutdown implemented";; esac Any help gratefully received as this has got me beat. Most files have been chmod to 777 with no difference. Cheers, James > Date: Mon, 27 Apr 2015 16:04:34 +0200 > From: ro...@rogerprice.org > To: nut-upsuser@lists.alioth.debian.org > Subject: Re: [Nut-upsuser] upssched setup > > On Mon, 27 Apr 2015, James Hammond wrote: > > > Roger, I did and it didnt work. > > Aha!, what does your upssched.conf look like? If you add the lines: > > # Debugging: Log all calls to this script > logger -t upssched-cmd.sh Calling upssched-cmd.sh $1 > > to your /sbin/upssched-cmd.sh , what is reported if anything when it > doesn't work? Cheers, Roger > > ___ > 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] upssched setup
Roger, I did and it didnt work. Hence why I was trying to run just the shell script manually. I am not sure if this works though with the timer defined in it? Cheers, James Date: Mon, 27 Apr 2015 15:03:44 +0200 From: ro...@rogerprice.org To: nut-upsuser@lists.alioth.debian.org Subject: Re: [Nut-upsuser] upssched setup On Mon, 27 Apr 2015, James Hammond wrote: > I am unable to get upssched working correctly as my UPS calls low > battery too late and there is no way to change it. I am running Nut > 2.7.3 on Ubuntu 14.04 I have made this script, called > /sbin/upssched-cmd.sh > > #!/bin/sh > case $1 in >onbatt) > /sbin/upsmon -c fsd;; >*) > echo "shutdown implemented";; > esac Hi, Just wondering, do you have a line in upssched.conf which specifies CMDSCRIPT /sbin/upssched-cmd.sh ? Roger ___ 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] upssched setup
Hi, I am unable to get upssched working correctly as my UPS calls low battery too late and there is no way to change it. I am running Nut 2.7.3 on Ubuntu 14.04 I have made this script, called /sbin/upssched-cmd.sh #!/bin/sh case $1 in onbatt) /sbin/upsmon -c fsd;; *) echo "shutdown implemented";; esac I am trying to run the script manually to break down my issues. All that happens when I run the script is I get the echo script but no shutdown, effectively the script doesn't seem to run the command /sbin/upsmon -c fsd . I have run this command from the command line and the system shuts down as expected.: root@unifi:/sbin# ./upssched-cmd.shshutdown implemented Command run manually works just fine: root@unifi:/# upsmon -c fsdNetwork UPS Tools upsmon 2.7.3 Broadcast Message from nut@unifi(somewhere) at 13:40 ... Executing automatic power-fail shutdown Broadcast Message from nut@unifi(somewhere) at 13:40 ... Auto logout and shutdown proceeding Broadcast message from root@unifi(unknown) at 13:40 ... The system is going down for reboot NOW! Permissions are: root@unifi:/sbin# ls -la upssched-cmd.sh-rwxrwx--- 1 root root 107 Apr 27 13:33 upssched-cmd.sh I have the command pointing at the correct place: unifi@unifi:~$ command -v upsmon/sbin/upsmon Any help appreciated. All I am looking to do is shutdown this master upsd and send shutdown requests to 2 other slaves after 10 mins of the UPS going onto battery. Cheers, James ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Fry's Electronics UPS...
Upgrading to 2.7.3 and using the nutdrv_qx driver and everything is talking now between 3 devices. I will need to test shutdown when I get home, but thanks for the excellent support. Cheers,James > Subject: Re: [Nut-upsuser] Fry's Electronics UPS... > From: clep...@gmail.com > Date: Thu, 23 Apr 2015 22:54:17 -0400 > CC: nut-upsuser@lists.alioth.debian.org > To: james_r_hamm...@hotmail.com > > On Apr 23, 2015, at 1:16 PM, James Hammond > wrote: > > > I am running Ubuntu 14.04 and using NUT version 2.73 installed from apt-get > > package. > > Hmm, the version below says 2.7.1, not 2.7.3. > > > Driver debug output: > > > > root@unifi:/lib/nut# ./blazer_usb -DD -a nutdev1 > > Network UPS Tools - Megatec/Q1 protocol USB driver 0.10 (2.7.1) > > > > To get the drivers hyouko mentioned on Ubuntu, the easiest way might be to > use a PPA: > > https://launchpad.net/~clepple/+archive/ubuntu/nut > > (the strange version number in the PPA is because the packages were built > from Git just before the official 2.7.3 tarball was released.) > > -- > Charles Lepple > clepple@gmail > > > ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
[Nut-upsuser] Fry's Electronics UPS...
ce 0.245499 Device does not match - skipping 0.245520 No appropriate HID device found 0.245547 No supported devices found. Please check your device availability with 'lsusb'and make sure you have an up-to-date version of NUT. If this does not help,try running the driver with at least 'subdriver', 'vendorid' and 'productid'options specified. Please refer to the man page for details about these options(man 8 blazer). Is there anything else I can try or just forget it? Cheers, James ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] infosec e4
Great, it's working fine. I'm using upssched to shutdown computer after 15mn when on battery. Should I trigger "upsmon -c fsd" with my script? I mean, is it the normal way to shutdown both computer and ups. Best regards, -Message d'origine- From: Charles Lepple Sent: Monday, August 26, 2013 3:07 AM To: James HORLEY Cc: nut-upsuser list Subject: Re: [Nut-upsuser] infosec e4 On Aug 26, 2013, at 6:22 AM, James HORLEY wrote: I've download again nut source today from "https://github.com/networkupstools/nut/tree/voltronic-driver"; and try compiliing the voltronic-driver. This branch has been merged in, and will be part of 2.7.1 when it is released. The drivers is working fine (ie computer is shutting down) except for the shutdown of the ups. I can shutdown the ups by sending the command "shutdown.return" but standard shutdown doesn't work. upsmon -K return: "upsmon -K" is for use inside a shutdown script. (See the man page for details.) I think you want "upsmon -c fsd", which triggers the entire shutdown sequence. -- Charles Lepple clepple@gmail ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] infosec e4
I've download again nut source today from "https://github.com/networkupstools/nut/tree/voltronic-driver"; and try compiliing the voltronic-driver. The drivers is working fine (ie computer is shutting down) except for the shutdown of the ups. I can shutdown the ups by sending the command "shutdown.return" but standard shutdown doesn't work. upsmon -K return: kill: No such process UPS: myups@localhost (master) (power value 1) Using power down flag file /etc/killpower Power down flag is not set Is there a way I can help nut developpers by send debug output or anything else? Best regards, -Message d'origine- From: James HORLEY Sent: Thursday, August 01, 2013 4:40 PM To: nut-upsuser list Subject: Re: [Nut-upsuser] infosec e4 I'm pretty sure, I've install pkg-config, but I will check it monday after my holliday. This is my test steps: - Shutting down nut-client (upsmon) - Only nut-server (driver + upsd) is running - upsmon.conf have been revert to normal shutdown, no upssched - upsc myups return ups stats then: upsmon -K -D, here is the output: kill: No such process UPS: myups@localhost (master) (power value 1) Using power down flag file /etc/killpower Power down flag is not set Best regards, -Message d'origine- From: Charles Lepple Sent: Thursday, August 01, 2013 2:25 AM To: James HORLEY Cc: nut-upsuser list Subject: Re: [Nut-upsuser] infosec e4 On Jul 31, 2013, at 9:07 AM, James HORLEY wrote: I’m wondering if what I have done is good : # get the source from github on my computer # autogen.sh # name=nut # ./configure --prefix=/ --sysconfdir=/etc/$name --mandir=/usr/share/man --libdir=/usr/lib --includedir=/usr/include --datadir=/usr/share/$name --with-statepath=/var/run/nut --with-altpidpath=/var/run/nut --with-drvpath=/lib/nut --with-pidpath=/var/run/$name --with-user=$name –with-group=$name --without-ssl If these are the same parameters as are used to build the .deb, then that should owrk. There was an error : ./configure: line 7079: syntax error near unexpected token `CPPUNIT,' ./configure: line 7079: `PKG_CHECK_MODULES(CPPUNIT, cppunit, have_cppunit=yes, have_cppunit=no)' Do you have pkg-config installed? I put in commentary the line PKG_CHECK_MODULES(CPPUNIT, cppunit, have_cppunit=yes, have_cppunit=no) then # make # make install I took the driver voltronic_ser then from my workstation put it in the server, change the ups.conf and try it. The command “upscmd –u admin myups shutdown.return” now work (shutting down server then ups). Unfortunately, when I do “shutdown –h +0”, the ups is never shut down. After a little research, it appears that the line “upsmon –K >/dev/null 2>&1” in ups-monitor always return 1 so the line “exec /etc/init.d/nut-server poweroff” is never execute. For initial shutdown testing, I would recommend using a dummy load (such as a lamp) and plug the server into another UPS or directly to line power. Then, you can remove power from the UPS and run "upsmon -K" from the command line (without redirection) to see why it is failing. I’m ussing upssched in upsmon.conf, do I need to create the flag with my script before calling the shutdown –h +0? How (it’s supposed to be set automaticaly)? or maybe I’m missing something. I don't recommend configuring upssched until basic shutdowns work. Did I do the right thing by getting only the driver from my computer and put it on the server? Or should I do a package of the whole nut (binary, conf etc...) This is not guaranteed to work, but when the version numbers are close enough (2.6.4, 2.6.5, 2.7.1/master), it usually does work. The network protocol is more stable than the upsd/driver interface. -- Charles Lepple clepple@gmail ___ 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] infosec e4
I'm pretty sure, I've install pkg-config, but I will check it monday after my holliday. This is my test steps: - Shutting down nut-client (upsmon) - Only nut-server (driver + upsd) is running - upsmon.conf have been revert to normal shutdown, no upssched - upsc myups return ups stats then: upsmon -K -D, here is the output: kill: No such process UPS: myups@localhost (master) (power value 1) Using power down flag file /etc/killpower Power down flag is not set Best regards, -Message d'origine- From: Charles Lepple Sent: Thursday, August 01, 2013 2:25 AM To: James HORLEY Cc: nut-upsuser list Subject: Re: [Nut-upsuser] infosec e4 On Jul 31, 2013, at 9:07 AM, James HORLEY wrote: I’m wondering if what I have done is good : # get the source from github on my computer # autogen.sh # name=nut # ./configure --prefix=/ --sysconfdir=/etc/$name --mandir=/usr/share/man --libdir=/usr/lib --includedir=/usr/include --datadir=/usr/share/$name --with-statepath=/var/run/nut --with-altpidpath=/var/run/nut --with-drvpath=/lib/nut --with-pidpath=/var/run/$name --with-user=$name –with-group=$name --without-ssl If these are the same parameters as are used to build the .deb, then that should owrk. There was an error : ./configure: line 7079: syntax error near unexpected token `CPPUNIT,' ./configure: line 7079: `PKG_CHECK_MODULES(CPPUNIT, cppunit, have_cppunit=yes, have_cppunit=no)' Do you have pkg-config installed? I put in commentary the line PKG_CHECK_MODULES(CPPUNIT, cppunit, have_cppunit=yes, have_cppunit=no) then # make # make install I took the driver voltronic_ser then from my workstation put it in the server, change the ups.conf and try it. The command “upscmd –u admin myups shutdown.return” now work (shutting down server then ups). Unfortunately, when I do “shutdown –h +0”, the ups is never shut down. After a little research, it appears that the line “upsmon –K >/dev/null 2>&1” in ups-monitor always return 1 so the line “exec /etc/init.d/nut-server poweroff” is never execute. For initial shutdown testing, I would recommend using a dummy load (such as a lamp) and plug the server into another UPS or directly to line power. Then, you can remove power from the UPS and run "upsmon -K" from the command line (without redirection) to see why it is failing. I’m ussing upssched in upsmon.conf, do I need to create the flag with my script before calling the shutdown –h +0? How (it’s supposed to be set automaticaly)? or maybe I’m missing something. I don't recommend configuring upssched until basic shutdowns work. Did I do the right thing by getting only the driver from my computer and put it on the server? Or should I do a package of the whole nut (binary, conf etc...) This is not guaranteed to work, but when the version numbers are close enough (2.6.4, 2.6.5, 2.7.1/master), it usually does work. The network protocol is more stable than the upsd/driver interface. -- Charles Lepple clepple@gmail ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] infosec e4
I compile nut with the voltronic-driver on my computer then I've copy the driver "/lib/nut/voltronic_ser" on the server. I can now shutdown the ups using "upscmd -u admin myups shutdown.return". My first question is, is it really ok to only take the driver whithout taking the whole package? I'm using upssched to shutdown server after 15mn on battery, the "shutdown -h +0" isn't enough to shutdown ups. Do I need to use upscmd in order to shutdown ups, or is there another way? Best regards, -Message d'origine- From: Charles Lepple Sent: Thursday, August 01, 2013 2:19 AM To: James HORLEY Cc: nut-upsuser@lists.alioth.debian.org Subject: Re: [Nut-upsuser] infosec e4 On Aug 1, 2013, at 8:15 AM, Charles Lepple wrote: On Jul 29, 2013, at 7:12 AM, James HORLEY wrote: There’s a software advised by the constructor that work on linux (http://www.power-software-download.com/viewpower.html), unfortunately it’s heavy (tomcat and java) and I don’t find it as flexible as NUT. We have a development branch called "voltronic-driver" which might work better than the blazer* for UPS models which are meant to work with ViewPower. Have you rebuilt a .deb package before? Oops, just noticed the new thread where /dan replied: http://thread.gmane.org/gmane.comp.monitoring.nut.user/8023 -- Charles Lepple clepple@gmail ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
[Nut-upsuser] Fw: infosec e4
I’m wondering if what I have done is good : # get the source from github on my computer # autogen.sh # name=nut # ./configure --prefix=/ --sysconfdir=/etc/$name --mandir=/usr/share/man --libdir=/usr/lib --includedir=/usr/include --datadir=/usr/share/$name --with-statepath=/var/run/nut --with-altpidpath=/var/run/nut --with-drvpath=/lib/nut --with-pidpath=/var/run/$name --with-user=$name –with-group=$name --without-ssl There was an error : ./configure: line 7079: syntax error near unexpected token `CPPUNIT,' ./configure: line 7079: `PKG_CHECK_MODULES(CPPUNIT, cppunit, have_cppunit=yes, have_cppunit=no)' I put in commentary the line PKG_CHECK_MODULES(CPPUNIT, cppunit, have_cppunit=yes, have_cppunit=no) then # make # make installI took the driver voltronic_ser then from my workstation put it in the server, change the ups.conf and try it.The command “upscmd –u admin myups shutdown.return” now work (shutting down server then ups).Unfortunately, when I do “shutdown –h +0”, the ups is never shut down. After a little research, it appears that the line “upsmon –K >/dev/null 2>&1” in ups-monitor always return 1 so the line “exec /etc/init.d/nut-server poweroff” is never execute.I’m ussing upssched in upsmon.conf, do I need to create the flag with my script before calling the shutdown –h +0? How (it’s supposed to be set automaticaly)? or maybe I’m missing something. Did I do the right thing by getting only the driver from my computer and put it on the server? Or should I do a package of the whole nut (binary, conf etc...) Best regards, From: hyo...@gmail.com Sent: Monday, July 29, 2013 1:34 AM To: James HORLEY Subject: Re: [Nut-upsuser] infosec e4 You could try voltronic driver https://github.com/networkupstools/nut/tree/voltronic-driver /dan 2013/7/29 James HORLEY Hi, Sorry for my poor english but it isn’t my native language. I’m testing an infosec E4 with nut-2.6.4-2.3 on Proxmox ve 3.0 (based on debian wheezy). The drivers that match this ups, is blazer_usb. Btw, I have try nut-2.6.5 with unstable repository from wheezy, but it still doesn’t fully work. I can shutdown my computer when battery is low, but unfortunately I can’t shutdown ups. Like said on the man blazer : “Some UPS commands aren’t supported by all models. In most cases, the driver will send a message to the system log when the user tries to execute an unsupported command” I’m wondering if there’s a way I can post some data to help make this ups more compatible with NUT. There’s a software advised by the constructor that work on linux (http://www.power-software-download.com/viewpower.html), unfortunately it’s heavy (tomcat and java) and I don’t find it as flexible as NUT. Best regards, ___ 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] infosec e4
Hi, Sorry for my poor english but it isn’t my native language. I’m testing an infosec E4 with nut-2.6.4-2.3 on Proxmox ve 3.0 (based on debian wheezy). The drivers that match this ups, is blazer_usb. Btw, I have try nut-2.6.5 with unstable repository from wheezy, but it still doesn’t fully work. I can shutdown my computer when battery is low, but unfortunately I can’t shutdown ups. Like said on the man blazer : “Some UPS commands aren’t supported by all models. In most cases, the driver will send a message to the system log when the user tries to execute an unsupported command” I’m wondering if there’s a way I can post some data to help make this ups more compatible with NUT. There’s a software advised by the constructor that work on linux (http://www.power-software-download.com/viewpower.html), unfortunately it’s heavy (tomcat and java) and I don’t find it as flexible as NUT. Best regards, ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] getting nut 2.6.4 working in Nas4Free
On Tue, Jul 24, 2012 at 3:18 AM, wrote: > Hello Jim, > > Can you send your configuration files please (hide your password). > > Regards, > Fred > > -- > Eaton Opensource Team - http://opensource.eaton.com > > > I hope I'm sending the right stuff. It's out of the box setup. I didn't edit anything except the port and driver, and email stuff. /var/etc/ups.conf is [ups] driver = usbhid-ups port = auto /var/etc/nut.conf is MODE = standalone /var/etc/upsd.conf is MAXAGE 15 MAXCONN 1024 LISTEN 127.0.0.1 3493 LISTEN ::1 3493 /var/etc/upds.users is [root] password = xxx actions = set instcmds = all upsmon master /var/etc/upsmon.conf is MONITOR ups@localhost 1 root password master MINSUPPLIES 1 SHUTDOWNCMD "/sbin/shutdown -p now" NOTIFYCMD /usr/local/sbin/upssched POLLFREQ 5 POLLFREQALERT 5 HOSTSYNC 15 DEADTIME 15 POWERDOWNFLAG /var/etc/killpower NOTIFYFLAG ONLINE SYSLOG+WALL+EXEC NOTIFYFLAG ONBATT SYSLOG+WALL+EXEC NOTIFYFLAG LOWBATT SYSLOG+WALL+EXEC NOTIFYFLAG FSD SYSLOG+WALL+EXEC NOTIFYFLAG COMMOK SYSLOG+WALL+EXEC NOTIFYFLAG COMMBAD SYSLOG+WALL+EXEC NOTIFYFLAG SHUTDOWN SYSLOG+WALL+EXEC NOTIFYFLAG REPLBATT SYSLOG+WALL+EXEC NOTIFYFLAG NOCOMM SYSLOG+WALL+EXEC NOTIFYFLAG NOPARENT SYSLOG+WALL+EXEC RBWARNTIME 43200 NOCOMMWARNTIME 300 FINALDELAY 5 /var/etc/upssched.conf is CMDSCRIPT /usr/local/bin/upssched-cmd PIPEFN /var/run/upssched.pipe LOCKFN /var/run/upssched.lock AT COMMOK * EXECUTE notify AT COMMBAD * EXECUTE notify AT REPLBATT * EXECUTE notify AT NOCOMM * EXECUTE notify AT FSD * EXECUTE forced-shutdown AT NOPARENT * EXECUTE notify AT SHUTDOWN * EXECUTE notify AT ONLINE * CANCEL-TIMER shutdown AT ONLINE * EXECUTE resume AT ONBATT * START-TIMER shutdown 30 AT ONBATT * EXECUTE shutdown-warning AT LOWBATT * START-TIMER shutdown AT LOWBATT * EXECUTE shutdown-warning Jim A > -- > > -- > > > > -- > *From:* > nut-upsuser-bounces+fredericbohe=eaton@lists.alioth.debian.org[nut-upsuser-bounces+fredericbohe= > eaton@lists.alioth.debian.org] on behalf of Jim Abernathy [ > jfaberna...@gmail.com] > *Sent:* Monday, July 23, 2012 9:51 PM > *To:* nut-upsuser@lists.alioth.debian.org > *Subject:* [Nut-upsuser] getting nut 2.6.4 working in Nas4Free > > I'm trying to use a Nas4Free storage system. This same hardware worked > fine on Freenas 0.7.2. > > O/S: Nas4Free 9.0.0.1.148 which comes with nut 2.6.4. > > UPS is an APC Back UPS RS 800. USB interface. > > Driver : usbhid-ups > Port: auto > > my NAS is communicating with the UPS, but in testing power failures, I'm > not getting the shutdown to be handled properly. > > When I pull the AC plug on the UPS, the NAS recognizes that event, but > doesn't send out the email and doesn't start the shutdown sequence even > though the 30 sec time limit has passed. The log shows errors. I've posted > them below. The restoring of power is also recognized by the NAS. > > Jul 14 06:14:41 nas4free upsmon[1813]: UPS Back-UPS-RS-800@localhost on > battery > > Jul 14 06:14:42 nas4free upssched[2334]: read confirmation got [ERR > UNKNOWN own" "30"] > Jul 14 06:14:43 nas4free last message repeated 24 times > Jul 14 06:14:43 nas4free upssched[2334]: Unable to connect to daemon and > unable to start daemon > > Jul 14 06:17:01 nas4free upsmon[1813]: UPS Back-UPS-RS-800@localhost on > line power > Jul 14 06:17:01 nas4free upssched-cmd: UPS Back-UPS-RS-800@localhost - > Running on line power. Shutdown cancelled. > > Jul 14 06:17:03 nas4free msmtp: host=smtp.gmail.com tls=on auth=on > user=x...@gmail.com from=x...@gmail.com recipients=xyz@gmail.commailsize=244 > smtpstatus=250 smtpmsg='250 2.0.0 OK 1342261023 > y66sm18956640yhi.10' exitcode=EX_OK > > more information in the daemon log file: > > Jul 14 08:35:17 nas4free upsmon[6990]: UPS ups@localhost on battery > Jul 14 08:35:17 nas4free upssched[7010]: Timer daemon started > Jul 14 08:35:17 nas4free upssched[7010]: Unknown command on socket: > Jul 14 08:35:17 nas4free upssched[7010]: arg 0: 30START > Jul 14 08:35:17 nas4free upssched[7010]: arg 1: shutdown > Jul 14 08:35:17 nas4free upssched[7010]: arg 2: 30 > Jul 14 08:35:17 nas4free upssched[7009]: read confirmation got [ERR > UNKNOWN own" "30"] > > Jim A > > ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Upsonic IRT1000 on Nut 2.2.1-2.1ubuntu7.2 (Ubuntu Hardy)
On Wed, Mar 07, 2012 at 05:25:06PM +1100, Matthew Cengia wrote: > On 2012-03-07 16:46, James Cameron wrote: > [...] > > > 3. Can anybody recommend a UPS that meets the following specs: > > > > > > * Works with the aforementioned version of NUT, either via USB or > > > RS232 > > > * Is ideally rack-mountable (and no taller than 2U) - as a > > > fall-back, free-standing is satisfactory > > > * Supplies at least 650 watts of power > > > * Costs under AU$1000 > > > > Can't talk about a rack mountable unit, but I've been happy with a > > PowerShield series. I got a PowerShield Commander 2000 for $990 last > > year. I think I had NUT running on Ubuntu 11.04, but didn't find I > > needed it, and repurposed the cable. > > Thanks for your response James. Your reference to 11.04 has thrown me a > bit, so just confirm, you have this working on 8.04? No, I had this working on 11.04 ... saying more about the compatibility of the device with NUT more than 8.04, which is so old I've forgotten most of my experience with it. And as a general principle, if it can be made to work on 11.04, then backporting of packages may make it work on 8.04. -- James Cameron http://quozl.linux.org.au/ ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Upsonic IRT1000 on Nut 2.2.1-2.1ubuntu7.2 (Ubuntu Hardy)
On Wed, Mar 07, 2012 at 04:19:44PM +1100, Matthew Cengia wrote: > Hi all, > > I have a client who is currently using an UPSonic IRT1000 UPS > (http://www.upsonic.com.au/industrial-rt.php), and is running NUT > 2.2.1-2.1ubuntu7.2 on Ubuntu Hardy, which I've not been able to get to > work using either USB or RS232. I *believe* the UPS is supposed to use > the Megatec driver, but am not 100% sure. > > I can see three possible resolutions to my problem, which leads me to > seeking an answer to one of the following questions (in order of highest > to lowest preference): > > 1. Has anybody had this UPS work with such an old NUT release? If so, > how? Not me. > 2. Has anybody successfully compiled and installed a newer release of > NUT on Ubuntu Hardy? If so, where was it from and what procedure was > followed? Not me. But it is theoretically possible, although it may require some backporting of things that might render the Ubuntu Hardy system a dogs breakfast of packages. ;-) i.e. it might require several cycles to get it right. > 3. Can anybody recommend a UPS that meets the following specs: > > * Works with the aforementioned version of NUT, either via USB or > RS232 > * Is ideally rack-mountable (and no taller than 2U) - as a > fall-back, free-standing is satisfactory > * Supplies at least 650 watts of power > * Costs under AU$1000 Can't talk about a rack mountable unit, but I've been happy with a PowerShield series. I got a PowerShield Commander 2000 for $990 last year. I think I had NUT running on Ubuntu 11.04, but didn't find I needed it, and repurposed the cable. > P.S. I've looked for but not found a NUT IRC channel. Does one exist, > and if so, where can I find it? No idea. Quozl on freenode #olpc. -- James Cameron http://quozl.linux.org.au/ ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Newbie question: real-time power usage monitoring?
On Wed, Oct 19, 2011 at 08:40:40AM -0400, Christian Convey wrote: > You're right - I *am* looking for total energy expenditure (Joules, > Watt-hours, etc.) I have no specific desire to do that integration in > my own code. What I used was a kit design from Silicon Chip in 2004, one retailer provides this as http://www.altronics.com.au/index.asp?area=item&id=K4600 but there are others. It is significantly more expensive than the consumer watt hour meters available today. It contains a chip that accumulates the counts independently, and a microcontroller driving the display and panel buttons. If I was doing what you are doing, I would replace the microcontroller with one that relays the readings over USB, serial, or ethernet. Then I'd worry about high voltage isolation and chuck in an optoisolator. I imagine there are better designs for the job. I'm only sharing my limited knowledge of the subject. ;-} Your later point about having the device do the counting and then seeing timed results reminds me of my very early work on the same subject ... a rotation sensor that emitted a millisecond counter alongside a rotation counter, so that it didn't matter when the host computer processed the data. http://quozl.linux.org.au/speedo/ -- James Cameron http://quozl.linux.org.au/ ___ 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 CyberPower 425HG
On 11-10-16 01:51 PM, n...@johnea.net wrote: On 2011-10-16 12:06, Ron wrote: Rebooting worked for me too. Wish I had read this post earlier Hi Ron, I've been struggling with nut and CyberPower USB devices for over a year now. You may find connection to the UPS on boot to be unreliable, sometimes it will connect, other times it won't. > From the thread: "Re: [Nut-upsuser] USB CyberPower" --- Hi James, I've worked extensively on getting a similar CyberPower UPS (same IDs) to play well with nut. The conclusion I ultimately came to is that if this UPS is not connected to by it's driver within about 20sec, it drops off the USB bus and re-enumerates. This causes an endless cycle of the UPS attaching and detaching. In archlinux, I was able to make it work by placing the nut daemon at the beginning of the rc scripts, before everything else. This caused it to be attached to before it dropped from the bus. Once it was attached, everything worked. IMHO, If you can, return it and get a different unit. --- As the text above indicates, the time between the system powering up, and the driver trying to connect to the UPS is critical. If this time is too long (greater than about 20sec) the UPS will have already disconnected from the USB and the connection will fail. Thereafter the UPS will continuously re-enumerate, wait about 20sec then disconnect again, and continue an endless cycle of re-enumerate/wait 20sec/disconnect. To add some more information, this cycle (re-enumerate/wait) will also occur if the driver is unloaded for any reason. This means that the stock scripts for shutting down in case of power failure won't work on CyberPower UPSs, at least they didn't for me. I had to adjust my shutdown scripts so that nut is never shut off, and the nut driver process is never sent the TERM/KILL signals during shutdown. Then, the UPS shutdown command works correctly. Otherwise, as soon as the driver is unloaded the UPS goes into that cycle, and you cannot send a UPS command, so the machine shuts down normally, which is not what you want. One major factor in the length of the delay on power up, was my computer's DHCP delay. I found if I could get the nut driver to load prior to my computer going out for DHCP, then it would reliably connect on boot. This matches my experience too, I actually moved NUT to the very first item in the startup sequence. If you have a static Network IP address, then this DHCP delay is not a factor for you. Anyway, try to connect to the UPS first, before any other boot time activity. Thanks for your post! Please pass along your ongoing experiences... johnea ___ 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] USB CyberPower
I have a ups that doesn't always (sometimes it does) load NUT right. I use Gentoo: * sys-power/nut Latest version available: 2.6.0-r1 Latest version installed: 2.6.0-r1 Size of files: 1,663 kB Homepage: http://www.networkupstools.org/ Description: Network-UPS Tools License: GPL-2 The kernel is 3.0.4. Here is the dmesg output: generic-usb 0003:0764:0501.0005: claimed by neither input, hiddev nor hidraw usb 2-3: USB disconnect, device number 5 usb 2-3: new low speed USB device number 6 using ohci_hcd usb 2-3: New USB device found, idVendor=0764, idProduct=0501 usb 2-3: New USB device strings: Mfr=3, Product=1, SerialNumber=0 usb 2-3: Product: CP550HG usb 2-3: Manufacturer: CPS usb 2-3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 128 rq 6 len 255 ret -110 usb 2-3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 128 rq 6 len 255 ret -62 usb 2-3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 129 rq 6 len 9 ret -6 2 usb 2-3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 129 rq 6 len 376 ret -62 usb 2-3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 128 rq 6 len 255 ret -62 usb 2-3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 128 rq 6 len 255 ret -62 usb 2-3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 129 rq 6 len 9 ret -6 2 usb 2-3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 129 rq 6 len 376 ret -62 usb 2-3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 128 rq 6 len 255 ret -62 usb 2-3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 128 rq 6 len 255 ret -62 usb 2-3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 129 rq 6 len 9 ret -6 2 usb 2-3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 129 rq 6 len 376 ret -62 usb 2-3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 128 rq 6 len 255 ret -62 usb 2-3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 128 rq 6 len 255 ret -62 usb 2-3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 129 rq 6 len 9 ret -6 2 usb 2-3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 129 rq 6 len 376 ret -62 usb 2-3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 128 rq 6 len 255 ret -62 usb 2-3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 128 rq 6 len 255 ret -62 usb 2-3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 129 rq 6 len 9 ret -6 2 usb 2-3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 129 rq 6 len 376 ret -62 usb 2-3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 128 rq 6 len 255 ret -62 usb 2-3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 128 rq 6 len 255 ret -62 usb 2-3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 129 rq 6 len 9 ret -6 2 usb 2-3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 129 rq 6 len 376 ret -62 usb 2-3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 128 rq 6 len 255 ret -62 usb 2-3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 128 rq 6 len 255 ret -62 usb 2-3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 129 rq 6 len 9 ret -6 2 usb 2-3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 129 rq 6 len 376 ret -62 usb 2-3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 128 rq 6 len 255 ret -62 usb 2-3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 128 rq 6 len 255 ret -62 usb 2-3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 129 rq 6 len 9 ret -6 2 usb 2-3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 129 rq 6 len 376 ret -62 usb 2-3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 128 rq 6 len 255 ret -62 usb 2-3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 128 rq 6 len 255 ret -62 usb 2-3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 129 rq 6 len 9 ret -6 2 usb 2-3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 129 rq 6 len 376 ret -62 usb 2-3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 128 rq 6 len 255 ret -62 usb 2-3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 128 rq 6 len 255 ret -62 usb 2-3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 129 rq 6 len 9 ret -6 2 usb 2-3: usbfs: USBDEVFS_CONTROL failed cmd usbhid-ups rqt 129 rq 6 len 376 ret -62 ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Looking for a low cost USB UPS that supports shutdown.return
I will be running more tests today since I want to get this working, I'll post again if I find out anything else. Halting looks like this, when I run "upsmon -c fsd" to simulate a power failure: === * Stopping Network UPS Tools * Stopping virtual private network daemon(s)... * Asking all remaining processes to terminate... * Killing all remaining processes... * Deconfiguring network interfaces... * Deactivating swap... * Unmounting weak filesystems... mount: / is busy * Shutting down the UPS ... Network UPS Tools - UPS driver controller 2.4.3 Network UPS Tools - Generic HID driver 0.34 (2.4.3) USB communication driver 0.31 No matching HID UPS found Driver failed to start (exit status=1) * Will now halt OK, so the problem is that at shutdown-time, "upsdrvctl shutdown" cannot find the device on the USB bus. After some playing around, I've found that this happens when the udev service is not running. To duplicate this, you can do (on Ubuntu): service udev stop /sbin/upsdrvctl shutdown WARNING: if your system isn't like mine, and this actually does work, it will cut power to all loads on the UPS, so be careful here. I attempted to start the udev service before calling upsdrvctl in /etc/init.d/ups-monitor, but the driver still failed to load. I will try some more tomorrow. In the mean time, if anybody has run into this before, I would love some pointers. James ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Looking for a low cost USB UPS that supports shutdown.return
On 11-09-29 12:22 PM, Mark Butsch wrote: Hello, I am new to NUT (running Ubuntu Lucid (10.04) and NUT 2.4.3 (from the Ubuntu package). I have been trying to use an APC Back-UPS ES 750, but when running the Shutdown Design test it doesn't cause my computer to power back on. It appears that it makes it all the way to powering off the computer during shutdown instead of having the UPS turn off power to the computer and then restoring it later after main power is back. I have the same problem with a CyberPower 425VA. I don't believe the problem is the UPS - I believe it's the shutdown sequence. > From my research, it appears the I need a UPS that supports the shutdown.return functionality (in addition to configuring my computer to return to its last known state after power restored). As far as I know, your UPS should work fine. The problem here, as you noted, is that instead of the UPS being instructed to cut power to the computer, which would then make it turn itself back on when power was restored, the computer completes a full shutdown. Since power is never cut, the computer never turns itself back on. My tests on Ubuntu have shown that there is something in the shutdown sequence that stops the "/sbin/upsdrvctl shutdown" command from running - I haven't yet been able to isolate it further. If you run this command just from a normal shell, power will be cut to your computer immediately. But, when it is run as part of /etc/init.d/ups-monitor during the halt procedure, it fails and shutdown completes normally, which we do not want. I will be running more tests today since I want to get this working, I'll post again if I find out anything else. Can anyone tell me how to get this functionality with the Back-UPS ES 750 or recommend a UPS that does provide it? Thanks, Mark ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
[Nut-upsuser] CyberPower USB UPS fails to cut power during shutdown
Hi, I have a CyberPower UPS connected to a Ubuntu karmic machine. All functions are working well. I can use upsc to see all the UPS parameters, power loss and battery low events are correctly detected, and shutdown is correctly initiated. If I run upsdrvctl shutdown, the UPS cuts power immediately. However, if I simulate a shutdown with upsmon -c fsd, the UPS fails to cut power. The normal halt procedure completes, and my machine turns itself off and stays off. The relevant part of the shutdown script is: flag=`sed -ne 's#^ *POWERDOWNFLAG *\(.*\)$#\1#p' /etc/nut/upsmon.conf` wait_delay=`sed -ne 's#^ *POWEROFF_WAIT= *\(.*\)$#\1#p' /etc/default/nut` if [ -f "$flag" ] ; then if $upsmon -K >/dev/null 2>&1 ; then log_action_msg "Shutting down the UPS ..." # log_action_msg "Restarting udev to give USB access" # /etc/init.d/udev start # sleep 10 log_action_msg "Running $upsdrvctl shutdown" if $upsdrvctl shutdown ; then sleep 5 log_action_msg "Waiting for UPS to cut the power" log_end_msg 0 else log_action_msg "Shutdown failed." log_action_msg "Waiting for UPS batteries to run down" log_end_msg 0 fi log_action_msg "UPS should now be off!" sleep 10 if [ "$wait_delay" ] ; then log_action_msg " (will reboot after $wait_delay) ..." sleep "$wait_delay" /etc/init.d/reboot stop fi else log_action_msg "Power down flag is not set (UPS shutdown not needed)" fi else if [ -z "$flag" ] ; then log_daemon_msg "##" log_progress_msg "## POWERDOWNFLAG is not defined in /etc/nut/upsmon.conf ##" log_progress_msg "## ##" log_progress_msg "## Please read the Manual page upsmon.conf(5) ##" log_progress_msg "##" log_end_msg 0 fi fi This is part of /etc/init.d/nut, which gets called by /etc/init.d/halt at the correct time. This script is bundled with the ubuntu package (version 2.4.1-3ubuntu2) If I run /etc/init.d/nut poweroff myself, the UPS receives the command and cuts power. When I run the script directly, I see on the console: Shutting down the UPS ... Running /sbin/upsdrvctl shutdown When the script is called from the halt routines, I see: Shutting down the UPS ... Will now halt The "Will now halt" message is from /etc/init.d/halt, and indicates that we returned to that script instead of having the power cut as expected. I thought that the problem might be that the USB device is no longer available, so I tried the commented lines above to restart udev to restore access to USB devices. This didn't work. I also tried specifying that the upsdrvctl command run as root, with $upsdrvctl -u root shutdown - this also didn't work. Does anyone have any ideas on why the shutdown command is failing when run as part of the halt process? Or do you have any pointers on debugging the halt process? Thanks, James ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Using NUT to detect a normally closed circuit opening
So how do I make sure it never sees the LB event (or ignores it)? The sensor is in an oily boiler room that is prone to water spillages etc., our only semi reliable option was a mechanical thermostat style sensor strapped directly to a pipe, so usb is pretty much out of the question. All I am using this for is to email our maintenance crew if the temp in the cooling tower pipe goes over-range as it indicates a situation that can usually easily be remedied before it becomes an issue, it has no relation whatsoever to the power situation where the NUT software is, I'm just using a framework that's already there for something completely unrelated. The point about the short is a valid one, but I don't think it will be an issue (if it ever does become an issue, I can change the sensor out for a normally open one and change the driver file accordingly) -Original Message- From: nut-upsuser-bounces+james.smith=jofco@lists.alioth.debian.org [mailto:nut-upsuser-bounces+james.smith=jofco@lists.alioth.debian.org] On Behalf Of Arjen de Korte Sent: Wednesday, June 22, 2011 11:10 AM To: nut-upsuser@lists.alioth.debian.org Subject: Re: [Nut-upsuser] Using NUT to detect a normally closed circuit opening Citeren James Smith : > I now have everything in place and I get an email when the temp sensor > opens > > Question - what do I set so the system doesn't shut down when the > sensor stays open? The system will only shutdown if you have an OB+LB event at the same time. As long as you make sure the system sees either OB or LB, but not both, you'll be fine. > Can I just set SHUTDOWNCMD "" ? This isn't needed. Note that there is a fatal flaw in a setup where opening a contact triggers an event. You'll have no way to verify that there is not a short in your cable, short of raising the temperature periodically to see if you see something changing. I wouldn't recommend using a temperature switch for anything else than a redundant over temperature kill switch, especially since USB connected temperature sensors are very cheap nowadays. This would allow you to monitor the health of your alarm system much easier. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) ___ 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] Using NUT to detect a normally closed circuit opening
Ok. I now have everything in place and I get an email when the temp sensor opens Question - what do I set so the system doesn't shut down when the sensor stays open? Can I just set SHUTDOWNCMD "" ? Or is there a cleaner way thx -Original Message- From: Charles Lepple [mailto:clep...@gmail.com] Sent: Tuesday, June 21, 2011 7:18 AM To: James Smith Cc: 'nut-upsuser@lists.alioth.debian.org' Subject: Re: [Nut-upsuser] Using NUT to detect a normally closed circuit opening On Jun 20, 2011, at 2:09 PM, James Smith wrote: > I have a temperature sensor (normally closed) that opens when it > reaches a pre-defined temp. what I am trying to do is use NUT to look > for the circuit opening and trigger an action (email or whatever). Is > there a NUT ups driver I can use to do this? If so, does anybody know > which pins on the serial I should connect the sensor to? > Someone else might have some suggestions about which pins to use, but the genericups driver is the one which allows you to choose which pins map to various states: http://www.networkupstools.org/docs/man/genericups.html#_custom_configurations You probably want to map the sensor to the on line/on battery states, since the low battery state is meant to be a one-way trip to shutting down the system. The OL and OB states mentioned in the genericups man page will trigger the first two notifications listed here: http://www.networkupstools.org/docs/man/upsmon.html#_notify_events ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Using NUT to detect a normally closed circuit opening
I looked at the docs for the generic ups and I get how to configure the driver, my problem is I cant seem to get the sensor to change any of the pin states when it opens - not being an electronics genius, I was hoping somebody who was could tell me what to wire to where to get the pins to change state when the contact opens Thx -Original Message- From: Charles Lepple [mailto:clep...@gmail.com] Sent: Tuesday, June 21, 2011 7:18 AM To: James Smith Cc: 'nut-upsuser@lists.alioth.debian.org' Subject: Re: [Nut-upsuser] Using NUT to detect a normally closed circuit opening On Jun 20, 2011, at 2:09 PM, James Smith wrote: > I have a temperature sensor (normally closed) that opens when it > reaches a pre-defined temp. what I am trying to do is use NUT to look > for the circuit opening and trigger an action (email or whatever). Is > there a NUT ups driver I can use to do this? If so, does anybody know > which pins on the serial I should connect the sensor to? > Someone else might have some suggestions about which pins to use, but the genericups driver is the one which allows you to choose which pins map to various states: http://www.networkupstools.org/docs/man/genericups.html#_custom_configurations You probably want to map the sensor to the on line/on battery states, since the low battery state is meant to be a one-way trip to shutting down the system. The OL and OB states mentioned in the genericups man page will trigger the first two notifications listed here: http://www.networkupstools.org/docs/man/upsmon.html#_notify_events ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
[Nut-upsuser] Using NUT to detect a normally closed circuit opening
Hi I have a temperature sensor (normally closed) that opens when it reaches a pre-defined temp. what I am trying to do is use NUT to look for the circuit opening and trigger an action (email or whatever). Is there a NUT ups driver I can use to do this? If so, does anybody know which pins on the serial I should connect the sensor to? Thx ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] problem starting upsd
On 03/13/11 06:30, Arjen de Korte wrote: > Citeren James : > >> $ sudo /usr/sbin/upsd - >> Network UPS Tools upsd 2.4.3 >>0.00 listen_add: added ::1:3493 >>0.84 listen_add: added 127.0.0.1:3493 >>0.000102 setuptcp: try to bind to 127.0.0.1 port 3493 >>0.000185 listening on 127.0.0.1 port 3493 >>0.000204 setuptcp: try to bind to ::1 port 3493 >>0.001328 setuptcp: socket: Address family not supported by >> protocol >>0.001381 not listening on ::1 port 3493 > > Apparently the version of NUT you're using was built on a system that > had IPv6 enabled and yours doesn't. Adding > > LISTEN 127.0.0.1 > > to 'upsd.conf' should fix this. See also 'man 5 upsd.conf'. > > Best regards, Arjen Awesome, thanks so much. That fixed it. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
[Nut-upsuser] problem starting upsd
$ sudo /usr/sbin/upsd - Network UPS Tools upsd 2.4.3 0.00 listen_add: added ::1:3493 0.84 listen_add: added 127.0.0.1:3493 0.000102 setuptcp: try to bind to 127.0.0.1 port 3493 0.000185 listening on 127.0.0.1 port 3493 0.000204 setuptcp: try to bind to ::1 port 3493 0.001328 setuptcp: socket: Address family not supported by protocol 0.001381 not listening on ::1 port 3493 $ sudo upsc -L Error: Connection failure: Connection refused ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] PowerShield Centurion 2000
On Tue, Mar 08, 2011 at 09:23:03AM +0100, Arjen de Korte wrote: > Try the blazer_usb driver instead. Thanks. That fixed it, I think. # upsc myups battery.voltage: 81.72 battery.voltage.nominal: 72.0 beeper.status: enabled device.mfr: device.model: HV 2K device.type: ups driver.name: blazer_usb driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.parameter.vendorid: 0665 driver.version: 2.4.3 driver.version.internal: 0.03 input.current.nominal: 8.0 input.frequency: 50.0 input.frequency.nominal: 50 input.voltage: 246.1 input.voltage.fault: 246.1 input.voltage.nominal: 240 output.voltage: 0.0 ups.delay.shutdown: 30 ups.delay.start: 180 ups.firmware: 1907 ups.load: 0 ups.mfr: ups.model: HV 2K ups.productid: 5161 ups.status: OL ups.temperature: 22.9 ups.type: online ups.vendorid: 0665 # upscmd myups load.on Username (root): Password: # It didn't turn on. What's this username and password? -- James Cameron http://quozl.linux.org.au/ 0.00 debug level is '3' 0.041776 Checking device (1D6B/0001) (002/001) 0.041991 - VendorID: 1d6b 0.042031 - ProductID: 0001 0.042054 - Manufacturer: Linux 2.6.35-27-generic uhci_hcd 0.042074 - Product: UHCI Host Controller 0.042095 - Serial Number: :00:1f.4 0.042115 - Bus: 002 0.042135 Trying to match device 0.042194 Device does not match - skipping 0.042246 Checking device (0665/5161) (001/005) 0.062004 - VendorID: 0665 0.062124 - ProductID: 5161 0.062146 - Manufacturer: unknown 0.062167 - Product: unknown 0.062187 - Serial Number: unknown 0.062208 - Bus: 001 0.062228 Trying to match device 0.062353 Device matches 0.062454 failed to claim USB device: could not claim interface 0: Device or resource busy 0.073348 detached kernel driver from USB device... 0.076465 Trying megatec protocol... 0.080401 send: Q1 0.121394 read: (NAK 0.121522 blazer_status: short reply 0.121556 Status read 1 failed 0.125352 send: Q1 0.353329 read: (244.6 244.8 000.0 000 50.1 2.27 22.9 0001 0.360213 Status read in 2 tries 0.360411 Supported UPS detected with megatec protocol 0.364325 send: F 0.473292 read: #240.0 008 072.0 50.0 0.473529 Ratings read in 1 tries 0.477254 send: I 0.665233 read: #HV 2K 1907 0.665401 Vendor information read in 1 tries 0.665430 Battery runtime will not be calculated (runtimecal not set) 0.669193 send: Q1 0.907001 read: (244.9 245.0 000.0 000 50.1 2.27 22.9 0001 0.907419 dstate_init: sock /var/run/nut/blazer_usb-myups open on fd 5 0.911124 send: Q1 1.137095 read: (244.6 244.7 000.0 000 50.1 2.27 23.1 0001 2.912571 send: Q1 3.144496 read: (244.9 244.9 000.0 000 50.1 2.27 22.9 0001 4.913049 send: Q1 5.143904 read: (244.5 244.5 000.0 000 50.1 2.27 22.9 0001 6.914350 send: Q1 7.143320 read: (244.4 244.4 000.0 000 50.0 2.27 23.1 0001 8.915790 send: Q1 9.150716 read: (243.9 244.1 000.0 000 50.0 2.27 22.9 0001 10.916183 send: Q1 11.150764 read: (244.4 244.4 000.0 000 50.0 2.27 22.9 0001 12.917569 send: Q1 13.149529 read: (244.6 244.7 000.0 000 50.1 2.27 22.9 0001 14.918002 send: Q1 15.148930 read: (244.7 244.7 000.0 000 50.1 2.27 22.9 0001 16.919376 send: Q1 17.148335 read: (243.9 243.9 000.0 000 50.1 2.27 23.1 0001 18.920816 send: Q1 19.155742 read: (244.0 244.0 000.0 000 50.1 2.27 22.9 0001 20.922219 send: Q1 21.155152 read: (243.5 243.6 000.0 000 50.1 2.27 22.9 0001 22.923990 send: Q1 23.154551 read: (243.4 243.5 000.0 000 50.1 2.27 22.9 0001 24.924000 send: Q1 25.153961 read: (243.5 243.4 000.0 000 50.1 2.27 22.9 0001 26.925439 send: Q1 27.153370 read: (243.4 243.4 000.0 000 50.0 2.27 22.9 0001 28.925810 send: Q1 29.153021 read: (243.6 243.2 000.0 000 50.0 2.27 22.9 0001 30.927216 send: Q1 31.168175 read: (243.8 243.8 000.0 000 50.1 2.27 22.9 0001 32.928658 send: Q1 33.159580 read: (244.1 244.2 000.0 000 50.1 2.27 22.9 0001 34.929031 send: Q1 35.158990 read: (244.3 244.1 000.0 000 50.1 2.27 22.9 0001 36.930435 send: Q1 37.166391 read: (243.9 243.9 000.0 000 50.1 2.27 23.1 0001 38.931163 send: Q1 39.165799 read: (243.8 243.9 000.0 000 50.0 2.27 22.9 0001 40.932245 send: Q1 41.157205 read: (242.9 243.6 000.0 000 50.0 2.27 23.1 0001 42.933684 send: Q1 43.172646 read: (243.8 243.7 000.0 000 50.0 2.27 23.1 0001 44.934347 send: Q1 45.164014 read: (243.9 244.0 000.0 000 50.0 2.27 23.1 0001 46.935463 send: Q1 47.165539 read: (243.9 244.0 0
[Nut-upsuser] PowerShield Centurion 2000
G'day, New toy, came with bundled software which is non-free, so I'm looking at whether NUT can be convinced to play with the toy. I've never used NUT before. OS name and version: Ubuntu 10.10 exact NUT version: 2.4.3-1ubuntu5 NUT installation method: Ubuntu package nut exact device name and related information: PowerShield Centurion 2000 http://powershield.com.au/products/centurion/ just purchased # lsusb Bus 001 Device 004: ID 0665:5161 Cypress Semiconductor USB to Serial # lsusb -v [attached] # dmesg | tail [ 3599.632065] usb 1-1: new low speed USB device using uhci_hcd and address 4 [ 3599.947982] usbcore: registered new interface driver hiddev [ 3599.998434] generic-usb 0003:1941:8021.0001: hiddev96,hidraw0: USB HID v1.00 Device [HID 1941:8021] on usb-:00:1f.2-2/input0 [ 3600.015506] generic-usb 0003:0665:5161.0002: hiddev97,hidraw1: USB HID v1.11 Device [HID 0665:5161] on usb-:00:1f.2-1/input0 [ 3600.018920] usbcore: registered new interface driver usbhid [ 3600.018931] usbhid: USB HID core driver # /sbin/upsdrvctl start myups Network UPS Tools - UPS driver controller 2.4.3 Network UPS Tools - Generic HID driver 0.34 (2.4.3) USB communication driver 0.31 No matching HID UPS found Driver failed to start (exit status=1) ups.conf: [myups] driver = usbhid-ups port = auto vendorid = 0665 On the other hand, if I try megatec_usb, and chgrp nut the /dev/bus/usb/001/004 entry, I get this: # /sbin/upsdrvctl start myups Network UPS Tools - UPS driver controller 2.4.3 Network UPS Tools - Megatec protocol driver 1.6 (2.4.3) Serial-over-USB transport layer 0.10 Startup timer elapsed, continuing... # echo $? 1 # And then shortly afterward: ser_get_line: Device detached? (error -1: could not claim interface 0: Device or resource busy) Successfully reconnected ... and this repeats periodically. -- James Cameron http://quozl.linux.org.au/ Bus 001 Device 004: ID 0665:5161 Cypress Semiconductor USB to Serial Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x0665 Cypress Semiconductor idProduct 0x5161 USB to Serial bcdDevice0.01 iManufacturer 3 iProduct1 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 34 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 0 No Subclass bInterfaceProtocol 0 None iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType33 bcdHID 1.11 bCountryCode0 Not supported bNumDescriptors 1 bDescriptorType34 Report wDescriptorLength 27 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 12 Device Status: 0x (Bus Powered) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] help with CyberPower 425HG
On 12/29/10 04:19, Kjell Claesson wrote: > Hi James, >> $ sudo upsdrvctl start >> Network UPS Tools - UPS driver controller 2.4.3 >> Network UPS Tools - Generic HID driver 0.34 (2.4.3) >> USB communication driver 0.31 >> Using subdriver: CyberPower HID 0.3 >> > OK, the driver seems to start. > > But have you started the daemon (upsd)? > >> $ sudo upsc my...@localhost >> Error: Driver not connected > Then you have to start the upsmon to monitor the ups. > - > Check with: > ps xau |grep nut > nut 5324 0.0 0.0 12428 508 ?Ss 09:41 0:00 > /lib/nut/bcmxcp -a pw5115 > nut 5348 0.0 0.0 40528 864 ?Ss 09:41 0:00 > /usr/sbin/upsd > nut 5367 0.0 0.0 40496 1148 ?S09:41 0:00 > /usr/sbin/upsmon > - > You may also do: > ps xau |grep ups > > Then you see that upsmon have two instants. One as nut and one as root. > > Regards > Kjell Crazy, it worked after I rebooted. Is 'battery.runtime' the time the UPS will last in seconds? ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
[Nut-upsuser] help with CyberPower 425HG
$ sudo upsdrvctl start Network UPS Tools - UPS driver controller 2.4.3 Network UPS Tools - Generic HID driver 0.34 (2.4.3) USB communication driver 0.31 Using subdriver: CyberPower HID 0.3 $ sudo upsc my...@localhost Error: Driver not connected ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] OT: gadget to display time remaining
On 11/22/10 03:34, Arjen de Korte wrote: > Citeren James : > >> I have two UPSs, one is not connected to a computer. >> I am looking for a gadget that I can plug in to the other one so I can >> see the time remaining without a computer. > > Since you don't mention the make and model of the UPS in question, it > will probably be impossible to help you any further. > > Best regards, Arjen Ah, standard USBHID (CyberPower CP550SLG). ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] OT: gadget to display time remaining
On 11/22/10 03:34, Arjen de Korte wrote: > Citeren James : > >> I have two UPSs, one is not connected to a computer. >> I am looking for a gadget that I can plug in to the other one so I can >> see the time remaining without a computer. > > Since you don't mention the make and model of the UPS in question, it > will probably be impossible to help you any further. > > Best regards, Arjen Ah, standard USBHID (CyberPower CP550SLG). ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] OT: gadget to display time remaining
On 11/22/10 05:42, Jon Bendtsen wrote: > On 22/11/2010, at 02.26, James wrote: > >> I have two UPSs, one is not connected to a computer. >> I am looking for a gadget that I can plug in to the other one so I can >> see the time remaining without a computer. > That would be network UPS tools, get it from http://www.networkupstools.org/ > ;-) > > Oh, and be sure to get the right UPS, because not all UPSes show the > information. > > I have a guru plug server plus connected to the Microdowell BP500 UPS in the > attachment, the UPS showing no Battery runtime. The other UPS is a APC > Smart-UPS 1500 and in my old debian sta(b)le installation running Network UPS > Tools upsstats 2.0.4 there was no information about battery runtime, but see > the attachment. > > > JonB Without a computer. :-) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] howto handle USB serial port keeps changing
> > Hi > > I have a serial UPS connected using a serial2USB device. Usually it is > port=/dev/ttyUSB0, but occasionally i need port=/dev/ttyUSB1. How do you guys > handle something like this? > > Could some udev persistent device naming rules help with this? I've done that with usb harddisks before but not serial ports. James ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
[Nut-upsuser] OT: gadget to display time remaining
I have two UPSs, one is not connected to a computer. I am looking for a gadget that I can plug in to the other one so I can see the time remaining without a computer. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Dynamix 650 VA USB UPS
Glen, I went through the same troubles you are experiencing. While I was using the 650's bigger brother the 1000VA it has the same issue. Upshot was I could get it to work. The USB implimentation is what is generally regarded as a "hack" where the manufacturer has mangled the implimentation so as to mimic a megatec serial protocol across a USB connection with the result being a special drivers/software is needed to cope. I ended up returning my Dynamix for a refund and am waiting for NZ to get stocks of Belkin USB based UPS. I have friends with said brand which DOES work under USB on Linux. If you really do want to continue with Dynamix then check out the manufacturers site. There is a model which has a real serial port that will probably be ok. Regards, James. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
[Nut-upsuser] power on settings after a power failure
On 07/14/10 11:27, Arjen de Korte wrote: the UPS should power off(and restart when the power comes back Can I set any UPS to only provide power after the battery is charged to a certain level? Or better yet, a certain length on consecutive time when the power has been on. I'd be worried about flapping, where the power goes on and off. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
[Nut-upsuser] output of upsc
Why is battery.mfr.date not a date? Why is there no device.serial? Are they both errors on CyberPower's part? $ /usr/local/ups/bin/upsc cp550...@localhostbattery.charge: 100 battery.charge.low: 10 battery.charge.warning: 20 battery.mfr.date: CPS battery.runtime: 960 battery.runtime.low: 300 battery.type: PbAcid battery.voltage: 4.9 battery.voltage.nominal: 12 device.mfr: CPS device.model: CP550HG device.type: ups driver.name: usbhid-ups driver.parameter.pollfreq: 30 driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.version: 2.4.3 driver.version.data: CyberPower HID 0.3 driver.version.internal: 0.34 input.transfer.high: 0 input.transfer.low: 0 input.voltage: 121.0 input.voltage.nominal: 120 output.voltage: 120.0 ups.beeper.status: enabled ups.delay.shutdown: 20 ups.delay.start: 30 ups.load: 46 ups.mfr: CPS ups.model: CP550HG ups.productid: 0501 ups.realpower.nominal: 330 ups.status: OL ups.test.result: No test initiated ups.timer.shutdown: -60 ups.timer.start: 0 ups.vendorid: 0764 ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] USB problems
On 05/11/10 20:56, James wrote: I used VirtualBox to run the Windows software and now nut works. It might be a coincidence. :-( I rebooted once and didn't run VirtualBox and nut works. We'll see if it breaks. I was playing around with different options. I did use these: ./configure --without-serial --without-neon --without-powerman --without-wrap --with out-ipv6 --with-usb --with-drivers=usbhid-ups --with-hal --with-user=ups --with-group=nut I may NOT have tried it before using VirtualBox though. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] USB problems
I used VirtualBox to run the Windows software and now nut works. It might be a coincidence. :-( I rebooted once and didn't run VirtualBox and nut works. We'll see if it breaks. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] USB problems
On 05/10/10 23:25, Charles Lepple wrote:
On Mon, May 10, 2010 at 11:02 PM, James wrote:
On 05/10/10 22:09, Charles Lepple wrote:
On Mon, May 10, 2010 at 8:35 PM, Jameswrote:
[...]
0.000663 failed to claim USB device: could not claim interface 0:
Operation not permitted
0.000671 failed to detach kernel driver from USB device: could not
detach kernel driver from interface 0: Operation not permitted
This error is different ("operation not permitted" versus "Device or
resource busy"). Is your source build using a different user than the
Gentoo build? (Some distributions have a specific NUT userid instead
of using "nobody" - not sure how they do it in Gentoo).
I'm compiling it with root but I followed the instructions (I think):
./configure --with-user=ups --with-group=nut
What user should perform the #8 step, /usr/local/ups/bin/upsdrvctl start
You can run upsdrvctl as root, and the driver will change to the user
you listed above. If you change the parameters to ./configure, you
will need to run "make clean" before "make all" and/or "make install"
The key is to make sure that the installed udev files match that
username as well. (At the beginning of this thread, you quoted a udev
rule which set the USB device node to user "nobody", which probably
isn't in group "nut".)
I changed that.
Is there any way to see what these two devices are?
May the UPS one should be root:nut
$ ls -l /dev/usb
total 0
crw-rw 1 root root 180, 96 May 11 00:40 hiddev0
crw-rw 1 root root 180, 97 May 11 00:40 hiddev1
PS!
I changed code in drivers/libusb.c
It doesn't fix my problems but I think is nicer code.
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] USB problems
On 05/10/10 22:09, Charles Lepple wrote:
On Mon, May 10, 2010 at 8:35 PM, James wrote:
On 05/10/10 14:37, Jason Englander wrote:
On Mon, 10 May 2010, James wrote:
Network UPS Tools - UPS driver controller 2.4.3
Network UPS Tools - Generic HID driver 0.34 (2.4.3)
USB communication driver 0.31
Using subdriver: CyberPower HID 0.3
libusb_get_report: could not claim interface 0: Device or resource busy
Got disconnected by another driver: Device or resource busy
Can't initialize data from HID UPS
Driver failed to start (exit status=1)
FYI, I got that error yesterday with NUT 2.4.3, kernel 2.6.33.3, and a
CyberPower CP1500AVRLCD using usbhid-ups and it seems fine after applying
this patch:
http://boxster.ghz.cc/projects/nut/changeset/2407?format=diff&new=2407
I applied the patch and it loaded the driver once. :-(
I had problems with starting upsd so I tried to fix it but I think the
driver crashed.
Now I can't restart it even after rebooting.
nut-2.4.3/drivers $ sudo ./usbhid-ups -a CP550SLG -D -D
Network UPS Tools - Generic HID driver 0.34 (2.4.3)
USB communication driver 0.31
0.00 debug level is '2'
0.000408 upsdrv_initups...
0.000583 Checking device (0764/0501) (002/007)
0.000611 - VendorID: 0764
0.000617 - ProductID: 0501
0.000622 - Manufacturer: unknown
0.000626 - Product: unknown
0.000631 - Serial Number: unknown
0.000636 - Bus: 002
0.000640 Trying to match device
0.000655 Device matches
0.000663 failed to claim USB device: could not claim interface 0:
Operation not permitted
0.000671 failed to detach kernel driver from USB device: could not
detach kernel driver from interface 0: Operation not permitted
This error is different ("operation not permitted" versus "Device or
resource busy"). Is your source build using a different user than the
Gentoo build? (Some distributions have a specific NUT userid instead
of using "nobody" - not sure how they do it in Gentoo).
I'm compiling it with root but I followed the instructions (I think):
./configure --with-user=ups --with-group=nut
What user should perform the #8 step, /usr/local/ups/bin/upsdrvctl start
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
[Nut-upsuser] more USB logs
# export USB_DEBUG=5 # /usr/local/ups/bin/usbhid-ups -a CP550SLG -D Network UPS Tools - Generic HID driver 0.34 (2.4.3) USB communication driver 0.31 0.00 debug level is '5' 0.000426 upsdrv_initups... usb_set_debug: Setting debugging level to 5 (on) usb_os_init: Found USB VFS at /dev/bus/usb usb_os_find_busses: Found 001 usb_os_find_busses: Found 002 usb_os_find_devices: couldn't get connect info usb_os_find_devices: Found 001 on 001 error obtaining child information: Operation not permitted usb_os_find_devices: couldn't get connect info usb_os_find_devices: Found 082 on 002 skipped 1 class/vendor specific interface descriptors usb_os_find_devices: couldn't get connect info usb_os_find_devices: Found 003 on 002 skipped 1 class/vendor specific interface descriptors skipped 1 class/vendor specific interface descriptors usb_os_find_devices: couldn't get connect info usb_os_find_devices: Found 001 on 002 error obtaining child information: Operation not permitted error obtaining child information: Operation not permitted error obtaining child information: Operation not permitted 0.000667 Checking device (1D6B/0002) (001/001) USB error: error sending control message: Operation not permitted USB error: error sending control message: Operation not permitted USB error: error sending control message: Operation not permitted 0.000694 - VendorID: 1d6b 0.000700 - ProductID: 0002 0.000705 - Manufacturer: unknown 0.000710 - Product: unknown 0.000714 - Serial Number: unknown 0.000720 - Bus: 001 0.000724 Trying to match device 0.000738 Device does not match - skipping 0.000745 Checking device (0764/0501) (002/082) USB error: error sending control message: Operation not permitted USB error: error sending control message: Operation not permitted 0.000765 - VendorID: 0764 0.000770 - ProductID: 0501 0.000775 - Manufacturer: unknown 0.000780 - Product: unknown 0.000784 - Serial Number: unknown 0.000789 - Bus: 002 0.000794 Trying to match device 0.000805 Device matches USB error: could not claim interface 0: Operation not permitted 0.000816 failed to claim USB device: could not claim interface 0: Operation not permitted USB error: could not detach kernel driver from interface 0: Operation not permitted 0.000827 failed to detach kernel driver from USB device: could not detach kernel driver from interface 0: Operation not permitted USB error: could not claim interface 0: Operation not permitted 0.000837 failed to claim USB device: could not claim interface 0: Operation not permitted USB error: could not detach kernel driver from interface 0: Operation not permitted 0.000881 failed to detach kernel driver from USB device: could not detach kernel driver from interface 0: Operation not permitted USB error: could not claim interface 0: Operation not permitted 0.000892 failed to claim USB device: could not claim interface 0: Operation not permitted USB error: could not detach kernel driver from interface 0: Operation not permitted 0.000901 failed to detach kernel driver from USB device: could not detach kernel driver from interface 0: Operation not permitted USB error: could not claim interface 0: Operation not permitted 0.000909 failed to claim USB device: could not claim interface 0: Operation not permitted USB error: could not detach kernel driver from interface 0: Operation not permitted 0.000918 failed to detach kernel driver from USB device: could not detach kernel driver from interface 0: Operation not permitted 0.000925 Can't claim USB device [0764:0501]: could not detach kernel driver from interface 0: Operation not permitted # dmesg hub 2-0:1.0: state 7 ports 10 chg evt 0004 ohci_hcd :00:02.0: GetStatus roothub.portstatus [1] = 0x00030300 PESC CSC LSDA PPS hub 2-0:1.0: port 2, status 0300, change 0003, 1.5 Mb/s usb 2-2: USB disconnect, address 87 usb 2-2: unregistering device usb 2-2: usb_disable_device nuking all URBs usb 2-2: unregistering interface 2-2:1.0 hub 2-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x300 hub 1-0:1.0: state 7 ports 10 chg evt 0004 ehci_hcd :00:02.1: GetStatus port 2 status 001403 POWER sig=k CSC CONNECT hub 1-0:1.0: port 2, status 0501, change 0001, 480 Mb/s hub 1-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x501 ehci_hcd :00:02.1: port 2 low speed --> companion ehci_hcd :00:02.1: GetStatus port 2 status 003402 POWER OWNER sig=k CSC hub 1-0:1.0: state 7 ports 10 chg evt 0004 hub 2-0:1.0: state 7 ports 10 chg evt 0004 ohci_hcd :00:02.0: GetStatus roothub.portstatus [1] = 0x00010301 CSC LSDA PPS CCS hub 2-0:1.0: port 2, status 0301, change 0001, 1.5 Mb/s hub 2-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x301 ohci_hcd :00:02.0: GetStatus roothub.portstatus [1] = 0x00100303 PRSC LSDA PPS
Re: [Nut-upsuser] USB problems
On 05/10/10 14:37, Jason Englander wrote: On Mon, 10 May 2010, James wrote: Network UPS Tools - UPS driver controller 2.4.3 Network UPS Tools - Generic HID driver 0.34 (2.4.3) USB communication driver 0.31 Using subdriver: CyberPower HID 0.3 libusb_get_report: could not claim interface 0: Device or resource busy Got disconnected by another driver: Device or resource busy Can't initialize data from HID UPS Driver failed to start (exit status=1) FYI, I got that error yesterday with NUT 2.4.3, kernel 2.6.33.3, and a CyberPower CP1500AVRLCD using usbhid-ups and it seems fine after applying this patch: http://boxster.ghz.cc/projects/nut/changeset/2407?format=diff&new=2407 I applied the patch and it loaded the driver once. :-( I had problems with starting upsd so I tried to fix it but I think the driver crashed. Now I can't restart it even after rebooting. nut-2.4.3/drivers $ sudo ./usbhid-ups -a CP550SLG -D -D Network UPS Tools - Generic HID driver 0.34 (2.4.3) USB communication driver 0.31 0.00 debug level is '2' 0.000408 upsdrv_initups... 0.000583 Checking device (0764/0501) (002/007) 0.000611 - VendorID: 0764 0.000617 - ProductID: 0501 0.000622 - Manufacturer: unknown 0.000626 - Product: unknown 0.000631 - Serial Number: unknown 0.000636 - Bus: 002 0.000640 Trying to match device 0.000655 Device matches 0.000663 failed to claim USB device: could not claim interface 0: Operation not permitted 0.000671 failed to detach kernel driver from USB device: could not detach kernel driver from interface 0: Operation not permitted 0.000678 failed to claim USB device: could not claim interface 0: Operation not permitted 0.000684 failed to detach kernel driver from USB device: could not detach kernel driver from interface 0: Operation not permitted 0.000691 failed to claim USB device: could not claim interface 0: Operation not permitted 0.000697 failed to detach kernel driver from USB device: could not detach kernel driver from interface 0: Operation not permitted 0.000703 failed to claim USB device: could not claim interface 0: Operation not permitted 0.000710 failed to detach kernel driver from USB device: could not detach kernel driver from interface 0: Operation not permitted 0.000716 Can't claim USB device [0764:0501]: could not detach kernel driver from interface 0: Operation not permitted ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] USB problems
On 05/10/10 08:31, Charles Lepple wrote:
On Mon, May 10, 2010 at 1:49 AM, James wrote:
I was getting:
"Can't claim USB device [0764:0501]: could not detach kernel driver from
interface 0: Operation not permitted"
so I manually installed the udev rules the source (I installed the Gentoo
ebuild).
I am now getting:
# upsdrvctl start
Network UPS Tools - UPS driver controller 2.4.3
Network UPS Tools - Generic HID driver 0.34 (2.4.3)
USB communication driver 0.31
Using subdriver: CyberPower HID 0.3
libusb_get_report: could not claim interface 0: Device or resource busy
Got disconnected by another driver: Device or resource busy
Can't initialize data from HID UPS
Driver failed to start (exit status=1)
which seems a bit better.
This seems to be a recent regression. What kernel version are you using?
$ lsusb
Bus 002 Device 005: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS
The udev rule is:
# Dynex DX-800U? - usbhid-ups
ATTR{idVendor}=="0764", ATTR{idProduct}=="0501", MODE="664", GROUP="nobody"
Can you also post the output from 'lsusb -vvv -d0764:', preferably run as root?
The vendor name from lsusb (without -v) is usually a good guess, but
often it is the name of the OEM (lsusb looks that up in a static
number-to-name mapping file). The product and vendor strings returned
by 'lsusb' with one or more '-v' flags are usually customized to match
the name printed on the unit.
$ sudo lsusb -vvv -d0764:
Bus 002 Device 004: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x0764 Cyber Power System, Inc.
idProduct 0x0501 CP1500 AVR UPS
bcdDevice0.01
iManufacturer 3 CPS
iProduct1 CP550HG
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 34
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 50mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0 No Subclass
bInterfaceProtocol 0 None
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType33
bcdHID 1.10
bCountryCode 33 US
bNumDescriptors 1
bDescriptorType34 Report
wDescriptorLength 376
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes3
Transfer TypeInterrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 10
Device Status: 0x
(Bus Powered)
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
[Nut-upsuser] USB problems
I was getting:
"Can't claim USB device [0764:0501]: could not detach kernel driver from
interface 0: Operation not permitted"
so I manually installed the udev rules the source (I installed the
Gentoo ebuild).
I am now getting:
# upsdrvctl start
Network UPS Tools - UPS driver controller 2.4.3
Network UPS Tools - Generic HID driver 0.34 (2.4.3)
USB communication driver 0.31
Using subdriver: CyberPower HID 0.3
libusb_get_report: could not claim interface 0: Device or resource busy
Got disconnected by another driver: Device or resource busy
Can't initialize data from HID UPS
Driver failed to start (exit status=1)
which seems a bit better.
$ lsusb
Bus 002 Device 005: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS
The udev rule is:
# Dynex DX-800U? - usbhid-ups
ATTR{idVendor}=="0764", ATTR{idProduct}=="0501", MODE="664", GROUP="nobody"
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] One little thing not quite correct in my configuration
Charles Lepple wrote: On Sep 9, 2009, at 8:36 AM, James Moody wrote: All of this work is being done on the system that has the UPS - I'm not trying to do any network monitoring yet. The symptom is that when I try to use 'upsc' I get the failure message "Error: server disconnected" on the console, and this line in /var/log/daemon.log: upsd[4899]: Rejecting TCP connection from 127.0.0.1 My current suspicion is I don't have the upsd.users file set up quite correctly. Questions: (1) are the users listed in upsd.conf real system users (ie, as listed in /etc/passwd file), or are they just defined within nut. Completely separate from /etc/passwd. Good. One form of samba authentication requires that the samba users must be legitimate linux users as well. I was wondering if maybe something like that was going on here with nut. Grasping at straws, you know. Here's my entire 'upsd.users' contents: [nutmon] password = mypassword allowfrom = local upsmon master Here's my entire 'upsmon.conf' file (though I'm not sure how this comes in to play with upsc): MONITOR cy...@localhost 1 nutmon mypassword master Are there other entries I need to add? All I want to do at this point is verify that 'upsc cyber' will work. I'm running an Ubuntu 8.10 server, and the latest release of nut available through the package manager. Is that 2.2.2-6ubuntu1? Correct. Any thoughts on what I might try, or errors to look for? --Jim ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
[Nut-upsuser] One little thing not quite correct in my configuration
All of this work is being done on the system that has the UPS - I'm not trying to do any network monitoring yet. The symptom is that when I try to use 'upsc' I get the failure message "Error: server disconnected" on the console, and this line in /var/log/daemon.log: upsd[4899]: Rejecting TCP connection from 127.0.0.1 My current suspicion is I don't have the upsd.users file set up quite correctly. Questions: (1) are the users listed in upsd.conf real system users (ie, as listed in /etc/passwd file), or are they just defined within nut. (2) what is this 'upsc.conf' file mentioned in the man page for upsc? The man page systems knows nothing about it, and I can't find a description through web browsing. Or is this an obsolete file? Thanks, --Jim For anyone interested, here are the details on my configuration: I'm running an Ubuntu 8.10 server, and the latest release of nut available through the package manager. My UPS is a Cyberpower 1500AVR, connected via USB. I'm working on the server with the UPS, I'm not doing any remote monitoring at this point. All of the files in /etc/nut have owner:group as "root:nut", and permissions set to 0640 upsdrvctl and upsd seem to be properly configure to a point: after I rebooted my server this appeared in the /var/log/daemon.log: usbhid-ups[4879]:: Startup successful upsd[4898]: Connected to UPS [cyber]: usbhid-ups-cyber When I try something like this from the console: % upsc cyber I get this response: Error: server disconnected And this appears in /var/log/daemon.log: upsd[4899]: Rejecting TCP connection from 127.0.0.1 My upsd.conf consist of: LISTEN 127.0.0.1 3493 I don't think the port is necessary since I'm using the default, but I'll leave it for now. The file '/etc/default/upsd' contained this line: PORT=/dev/ttyS0 What is the purpose of this for a system tied to the USB port? It is referenced in the /etc/init.d/bin script. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
[Nut-upsuser] CyberPower OR2200
>Does the battery voltage match the front panel? The specs on the website say >4x 12V batteries, but that could be in a 2x2 arrangement to give 24V. there is no voltage information on the front panel so i am not sure whats going on there. >Was upsc actually showing two copies of these values, or was that just >cut-n-paste? No worries if it was the latter, but I'm curious to see if we >are parsing the HID descriptor incorrectly. cut and paste error.sorry about that. _ Windows Live™: Keep your life in sync. http://windowslive.com/explore?ocid=PID23384::T:WLMTAGL:ON:WL:en-US:NF_BR_sync:082009___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] CyberPower OR2200
On Mon, Aug 10, 2009 at 10:26:41PM -0400, Charles Lepple wrote: > [please keep this thread on-list - that way other people can reference > it later.] > > On Aug 10, 2009, at 10:24 PM, James Erickson wrote: > > >> Please run "/lib/nut/usbhid-ups -a cyberpower -u root -x > >> productid=0601", and if we need additional detail, we'll add a few > >> more "-D"s to the line. (The debug output can get unmanageable > >> quickly.) > > > > odysseus ~ # /lib/nut/usbhid-ups -a cyberpower -u root -x > > productid=0601 > > Network UPS Tools - Generic HID driver 0.34 (2.4.1) > > USB communication driver 0.31 > > Using subdriver: CyberPower HID 0.2 > > > > just let me know if you need more data. > > Looks like you can start upsd, and see what it says when you connect > with 'upsc'. i made no changes to the configuration files. it was simply a matter of running "/etc/init.d/upsdrv start" followed by upsd and upsc. thanks again for all your help in this matter. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] CyberPower OR2200
On Mon, Aug 10, 2009 at 10:26:41PM -0400, Charles Lepple wrote: > [please keep this thread on-list - that way other people can reference > it later.] > > On Aug 10, 2009, at 10:24 PM, James Erickson wrote: > > >> Please run "/lib/nut/usbhid-ups -a cyberpower -u root -x > >> productid=0601", and if we need additional detail, we'll add a few > >> more "-D"s to the line. (The debug output can get unmanageable > >> quickly.) > > > > odysseus ~ # /lib/nut/usbhid-ups -a cyberpower -u root -x > > productid=0601 > > Network UPS Tools - Generic HID driver 0.34 (2.4.1) > > USB communication driver 0.31 > > Using subdriver: CyberPower HID 0.2 > > > > just let me know if you need more data. > > Looks like you can start upsd, and see what it says when you connect > with 'upsc'. i think i got it! odysseus ~ # /etc/init.d/upsdrv start upsdrv|* Caching service dependencies... [ ok ] upsdrv|* Starting UPS drivers... upsdrv|Network UPS Tools - UPS driver controller 2.4.1 upsdrv|Network UPS Tools - Generic HID driver 0.34 (2.4.1) upsdrv|USB communication driver 0.31 upsdrv|Using subdriver: CyberPower HID 0.2 [ ok ] odysseus ~ # upsd Network UPS Tools upsd 2.4.1 not listening on 127.0.0.1 port 3493 odysseus ~ # upsc cyberpo...@odysseus:3493 battery.charge: 100 battery.charge.low: 10 battery.charge.warning: 20 battery.mfr.date: CPS battery.runtime: 1440 battery.runtime.low: 300 battery.type: PbAcid battery.voltage: 27.4 battery.voltage.nominal: 24 driver.name: usbhid-ups driver.parameter.pollfreq: 30 driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.parameter.productid: 0601 driver.version: 2.4.1 driver.version.data: CyberPower HID 0.2 driver.version.internal: 0.34 input.transfer.high: 140 input.transfer.low: 90 input.voltage: 119.0 input.voltage.nominal: 120 output.voltage: 119.0 ups.beeper.status: enabled ups.delay.shutdown: 20 ups.delay.start: 30 ups.delay.shutdown: 20 ups.delay.start: 30 ups.load: 37 ups.mfr: CPS ups.model: OR2200LCDRM2U ups.productid: 0601 ups.realpower.nominal: 1320 ups.status: OL ups.test.result: Done and warning ups.timer.shutdown: -60 ups.timer.start: -60 ups.vendorid: 0764 odysseus ~ # does this look right? or am i doing it wrong? ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] CyberPower OR2200
On Mon, Aug 10, 2009 at 10:26:41PM -0400, Charles Lepple wrote: > [please keep this thread on-list - that way other people can reference > it later.] > > On Aug 10, 2009, at 10:24 PM, James Erickson wrote: > > >> Please run "/lib/nut/usbhid-ups -a cyberpower -u root -x > >> productid=0601", and if we need additional detail, we'll add a few > >> more "-D"s to the line. (The debug output can get unmanageable > >> quickly.) > > > > odysseus ~ # /lib/nut/usbhid-ups -a cyberpower -u root -x > > productid=0601 > > Network UPS Tools - Generic HID driver 0.34 (2.4.1) > > USB communication driver 0.31 > > Using subdriver: CyberPower HID 0.2 > > > > just let me know if you need more data. > > Looks like you can start upsd, and see what it says when you connect > with 'upsc'. odysseus ~ # /lib/nut/usbhid-ups -a cyberpower -u root -x productid=0601 Network UPS Tools - Generic HID driver 0.34 (2.4.1) USB communication driver 0.31 Using subdriver: CyberPower HID 0.2 odysseus ~ # upsd Network UPS Tools upsd 2.4.1 listening on localhost port 3493 getaddrinfo: Servname not supported for ai_socktype odysseus ~ # upsc cyberpo...@odysseus:3493 Error: Connection failure: Connection refused odysseus ~ # what am i doing wrong? ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] CyberPower OR2200
On Sun, Aug 09, 2009 at 06:38:32PM -0400, Charles Lepple wrote: > > > From: James Erickson > > Date: August 9, 2009 6:17:51 PM EDT > > To: Charles Lepple > > Subject: Re: [Nut-upsuser] CyberPower OR2200 > > > > On Sun, Aug 09, 2009 at 03:46:26PM -0400, Charles Lepple wrote: > >> On Aug 9, 2009, at 12:01 PM, James Erickson wrote: > >> > >>> i own a CyberPower OR2200LCDRM2U and was wondering if any nut > >>> drivers support this ups. none i have tried have worked although > >>> usbhid-ups did tell me that the productid=0601 was not supported > >>> yet. i see in the compatability list on the nut website that the > >>> PR2200 is supported with the powerpanel driver but the OR2200 is not > >>> listed. i am interested in what i am doing wrong or if this is a > >>> support issue. i will gladly post any requested data. thank you for > >>> your consideration in this matter. > >> > >> Some useful bits of information: > >> > >> * Your Linux (?) distribution and kernel version > >> * The version of NUT which you tried > >> > >> Also, please send the output of 'lsusb -vvv -d :0601' to a file, and > >> attach that to your reply. > >> > >> Thanks! > > > > > > Linux Distribution: Gentoo > > Kernel Version: Linux-2.6.30-gentoo-r4 > > NUT Version: NUT 2.4.1-r1 > > > > Please find output of "lsusb -vvv -d :0601" attached. > > > > Thank you very much. > odysseus ~ # lsusb -vvv -d :0601 > > Bus 001 Device 020: ID 0764:0601 Cyber Power System, Inc. > Device Descriptor: > bLength18 > bDescriptorType 1 > bcdUSB 1.10 > bDeviceClass0 (Defined at Interface level) > bDeviceSubClass 0 > bDeviceProtocol 0 > bMaxPacketSize0 8 > idVendor 0x0764 Cyber Power System, Inc. > idProduct 0x0601 > bcdDevice2.00 > iManufacturer 3 > iProduct1 > iSerial 0 > bNumConfigurations 1 > Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 41 > bNumInterfaces 1 > bConfigurationValue 1 > iConfiguration 0 > bmAttributes 0xc0 > Self Powered > MaxPower 50mA > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber0 > bAlternateSetting 0 > bNumEndpoints 2 > bInterfaceClass 3 Human Interface Device > bInterfaceSubClass 0 No Subclass > bInterfaceProtocol 0 None > iInterface 0 > ** UNRECOGNIZED: 09 21 10 01 21 01 22 7b 02 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x81 EP 1 IN > bmAttributes3 > Transfer TypeInterrupt > Synch Type None > Usage Type Data > wMaxPacketSize 0x0008 1x 8 bytes > bInterval 10 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x02 EP 2 OUT > bmAttributes3 > Transfer TypeInterrupt > Synch Type None > Usage Type Data > wMaxPacketSize 0x0008 1x 8 bytes > bInterval 20 > cannot read device status, Connection timed out (110) > > > The HID descriptor is only 31 bytes long, which is probably too short > to contain the information needed by the usbhid-ups driver. > > There is a possibility that this UPS is using some sort of USB-to- > serial adapter internally. > > Do you have any details about what software is intended to be used to > monitor this UPS? yes they have "powerpanel for linux" available here: http://www.cyberpowersystems.com/products/ups-systems/browse-by-category/smart-app-ups/rackmount-lcd/OR2200LCDRM2U.html?selectedTabId=downloads&imageI=#tab-box but i wanted to use NUT as it is in portage and is open source. Thanks! ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
[Nut-upsuser] CyberPower OR2200
i own a CyberPower OR2200LCDRM2U and was wondering if any nut drivers support this ups. none i have tried have worked although usbhid-ups did tell me that the productid=0601 was not supported yet. i see in the compatability list on the nut website that the PR2200 is supported with the powerpanel driver but the OR2200 is not listed. i am interested in what i am doing wrong or if this is a support issue. i will gladly post any requested data. thank you for your consideration in this matter. _ Express your personality in color! Preview and select themes for Hotmail®. http://www.windowslive-hotmail.com/LearnMore/personalize.aspx?ocid=PID23391::T:WLMTAGL:ON:WL:en-US:WM_HYGN_express:082009___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Access to internal UPS logs?
> -Original Message- > From: Arjen de Korte [mailto:[EMAIL PROTECTED] > Sent: Wednesday, 17 September 2008 17:35 > To: James Harper > Cc: nut-upsuser > Subject: Re: [Nut-upsuser] Access to internal UPS logs? > > Citeren "James Harper" <[EMAIL PROTECTED]>: > > > It's a brand new UPS (3 weeks old) and has failed this way twice, both > > after hours. No other equipment at the same site was affected indicating > > that there were no power problems. > > In that case, create one at a time convenient for you. Make sure there > is sufficient load connected and throw the circuit breaker on the > input. If it keeps on running, the batteries are not the problem. > > > upsc says this about the battery state: > > > > battery.charge: 100 > > battery.charge.low: 10 > > battery.charge.warning: 30 > > battery.temperature: 34.9 > > battery.type: PbAC > > battery.voltage: 54.6 > > battery.voltage.nominal: 48.0 > > Unfortunately, neither of the above will tell anything about how well > the unit will behave under load. Bad (high ohmic) connections of the > battery terminals or a failure in the inverter circuit will only > surface if the UPS must supply power. That's why one should never skip > periodic battery tests. Ideally, these should be initiated by an > operator, so that if the test fails there is someone at hand to fix > the problem (or at least reboot the system). > What you say is correct, but the failure mode is that the UPS stays on but turns off its outputs. During the failure, all monitoring continues to report that everything is fine - battery at 100% capacity, input voltage at ~248, output voltage at ~248, temperature at ~32C. The only thing that changes is that the output load changes from ~10% to 0%, which is expected if the outputs are turned off. I would have expected that a battery failure combined with an input failure would have resulted in the UPS shutting down, and then starting up again once the input failure condition sorted itself out. As it happens though there was no input failure condition long enough to cause any problems with any other equipment, although I understand that a UPS will respond to even short conditions like that. Or maybe it is possible that the UPS could detect a very brief (ms) input failure, try to switch over to battery, find the batteries broken, and reboot in a "I'm not working because my batteries are broken" mode? According to the onsite person, none of the LED's indicated a failure condition though... HP are sending a new unit anyway and it should be here tomorrow. I hope we don't find anything stupid like someone forgot to connect the batteries... Thanks James ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Access to internal UPS logs?
> > The UPS is randomly turning off its output power, at intervals of once > > every week or two, even though during this failure it reports that input > > and output voltages are still around 248V (240V is nominal). The only > > recourse is to reboot the UPS. > > First course of action, is to check the age of the batteries. Chances > are that the UPS starts a quick battery test every two weeks > (automatically), which is failing so quickly (immediately) that the > UPS shuts down. This shouldn't happen, but we've seen this before on > very old batteries that fail under load instantly. In that case, there > may not be enough time to switch back on the AC mains and report a > battery fault and instead the UPS shuts down. > It's a brand new UPS (3 weeks old) and has failed this way twice, both after hours. No other equipment at the same site was affected indicating that there were no power problems. upsc says this about the battery state: battery.charge: 100 battery.charge.low: 10 battery.charge.warning: 30 battery.temperature: 34.9 battery.type: PbAC battery.voltage: 54.6 battery.voltage.nominal: 48.0 thanks James ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Access to internal UPS logs?
> > Do any known UPS's keep internal logs of events? I am currently using a > slightly modified version if usbhid-ups to talk to a HP T/R2200 G2, > which is internally a TrippLite UPS. > > The UPS is randomly turning off its output power, at intervals of once > every week or two, even though during this failure it reports that input > and output voltages are still around 248V (240V is nominal). The only > recourse is to reboot the UPS. > > HP are sending a replacement unit as AFAICT it reports that everything > is otherwise okay and so is obviously broken, but if there were some > internal logs somewhere it would be useful to get access to them. I just noticed that upsmon wasn't running, which would explain the absence of anything useful in syslog. My question about internal logs still stands though. Thanks James ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
[Nut-upsuser] Access to internal UPS logs?
Do any known UPS's keep internal logs of events? I am currently using a slightly modified version if usbhid-ups to talk to a HP T/R2200 G2, which is internally a TrippLite UPS. The UPS is randomly turning off its output power, at intervals of once every week or two, even though during this failure it reports that input and output voltages are still around 248V (240V is nominal). The only recourse is to reboot the UPS. HP are sending a replacement unit as AFAICT it reports that everything is otherwise okay and so is obviously broken, but if there were some internal logs somewhere it would be useful to get access to them. This failure mode occurred the first time before any USB or serial cables were connected so I don't believe the failure is related to the (very alpha) nut ups driver I am using. After the first time I plugged one of the server PSU's into the mains, bypassing the UPS, so that it wouldn't down the server in the event of failure, and no messages were logged and the UPS continues reporting status (being graphed via mrtg). Thanks James ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] HP T/R2200 G2
> > Has anyone had any success with the HP T/R2200 G2? I have used the > T/R2200 with nut a few times before and it works great, but the G2 > doesn't want to talk to me. > > I have tried bcmxcp from 2.0.4, 2.2.2, and svn, as well as the usb > drivers. Maybe the G2 isn't a rebadged powerware unit? > One more thing... if it helps, the usb info is: Bus 003 Device 003: ID 03f0:1f0a Hewlett-Packard James ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
[Nut-upsuser] HP T/R2200 G2
Has anyone had any success with the HP T/R2200 G2? I have used the T/R2200 with nut a few times before and it works great, but the G2 doesn't want to talk to me. I have tried bcmxcp from 2.0.4, 2.2.2, and svn, as well as the usb drivers. Maybe the G2 isn't a rebadged powerware unit? Thanks James ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Upsonic PrOffice 650 usb/serial
On Thu, 2007-11-08 at 14:19 +, Carlos Rodrigues wrote:
> Try "megatec_usb". If it doesn't work, it may be possible to add support.
Wow, that worked right away (after recompiling 2.2 for etch):
# cat /etc/nut/ups.conf
[Pro]
driver=megatec_usb
port=/dev/usb/hiddev0
# ./megatec_usb -a Pro -DDD -u root
Network UPS Tools 2.2.0 - Megatec protocol driver 1.5.4 [megatec_usb]
Carlos Rodrigues (c) 2003-2007
Serial-over-USB transport layer for Megatec protocol driver [megatec_usb]
debug level is '3'
[snip other usb]
Checking device (0665/5161) (003/002)
- VendorID: 0665
- ProductID: 5161
- Manufacturer: Cypress Semiconductor
- Product: USB to Serial
- Serial Number: unknown
- Bus: 003
Trying to match device
Device matches
failed to claim USB device, trying 2 more time(s)...
detaching kernel driver from USB device...
trying again to claim USB device...
Starting UPS detection process...
Attempting to detect the UPS...
Sending "Q1" command...
"Q1" command successful.
Attempting to detect the UPS...
Sending "Q1" command...
"Q1" command successful.
Attempting to detect the UPS...
Sending "Q1" command...
"Q1" command successful.
Attempting to detect the UPS...
Sending "Q1" command...
"Q1" command successful.
Attempting to detect the UPS...
Sending "Q1" command...
"Q1" command successful.
0 out of 5 detection attempts failed (minimum failures: 2).
Asking for UPS information ("I" command)...
UPS doesn't return any information about itself.
Megatec protocol UPS detected.
Asking for UPS power ratings ("F" command)...
UPS power ratings: #240.0 003 12.00 50.0
Asking for UPS status ("Q1" command)...
UPS status: (245.2 245.1 245.1 035 50.0 13.3 25.0 1000
12.0V battery, interval [9.7V, 13.7V].
Done setting up the UPS.
Asking for UPS status ("Q1" command)...
UPS doesn't return any information about its status.
dstate_init: sock /var/run/nut/megatec_usb-Pro open on fd 5
Asking for UPS status ("Q1" command)...
UPS status: (245.1 245.1 245.1 034 50.0 13.3 25.0 1000
Charge: 90.0%
Asking for UPS status ("Q1" command)...
UPS status: (245.1 245.1 245.1 035 50.1 13.3 25.0 1000
Charge: 90.0%
Asking for UPS status ("Q1" command)...
UPS status: (245.1 245.0 245.1 035 50.1 13.3 25.0 1000
Charge: 90.0%
The charge is wrong, it's fully charged, but I guess that's what the
battvolts override is for.
Thanks, that was much less painful than I thought it was going to be.
James Andrewartha
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
[Nut-upsuser] Upsonic PrOffice 650 usb/serial
Hi, I recently installed a Upsonic PrOffice 650 UPS, which is a cheap model[1] available in Australia. It has a serial and USB port, and comes with a note saying WinPower software can be downloaded from [2]. Investigation of the software shows it to be Java with native libraries for serial and USB. Disassembling various classes reveals it talks at 2400 baud, and has a protocol similar to Megatec [3]. I tested this by connecting with minicom to the UPS, and got a status from Q1\r and heard it click on T and TL. So far, so good. I'd like to use the USB interface, but I can't get it to work. It appears in dmesg as hiddev96: USB HID v1.00 Device [Cypress Semiconductor USB to Serial] on usb-:00:1d.0-1 howevery cypress_m8 doesn't bind to it and create /dev/ttyUSB0. newhidups doesn't recognise it, but I don't think it should because it's a serial interface, not a proper USB HID Power device. What's my next step towards getting this device running with nut? [1] http://www.shopbot.com.au/p-34502.html [2] http://ups-software-download.com/ [3] http://www.networkupstools.org/protocols/megatec.html -- # TRS-80 trs80(a)ucc.gu.uwa.edu.au #/ "Otherwise Bub here will do \ # UCC Wheel Member http://trs80.ucc.asn.au/ #| what squirrels do best | [ "There's nobody getting rich writing ]| -- Collect and hide your | [ software that I know of" -- Bill Gates, 1980 ]\ nuts." -- Acid Reflux #231 / ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
[Nut-upsuser] Tripp Lite OMNIVS1500XL Unknown protocol
Good afternoon, I'm trying without much success to monitor a Tripp Lite OMNIVS1500XL using NUT. I checked the compatibility list and saw that this UPS is supported by tripplite_usb. The system is running Debian Stable, but I've downloaded NUT 2.0.3 and compiled from source since the packaged 2.0.1 doesn't include tripplite_usb. I compiled --with-user=nut. My first attempt at starting the driver with /usr/local/ups/bin/tripplite_usb auto gave "No matching USB/HID UPS found". I searched the list archives and found that -u root might help, and also that the kernel hid driver must not be allowed to claim the device. After doing "rmmod hid", "/usr/local/ups/bin/tripplite_usb -u root auto" gives one of the following, seemingly at random: Network UPS Tools - Tripp Lite OMNIVS and SMARTPRO driver 0.6 (2.0.3) Warning: This is an experimental driver. Some features may not function correctly. Detected a UPS: TRIPP LITE/TRIPP LITE OMNIVS1500XL Unknown protocol (2001)Attached to Tripp Lite OMNIVS1500XL Unknown value for s[2]: 0x34 Error reading 'D' value: Unknown error 0 Error reading 'M' value: Unknown error 0 Network UPS Tools - Tripp Lite OMNIVS and SMARTPRO driver 0.6 (2.0.3) Warning: This is an experimental driver. Some features may not function correctly. Detected a UPS: TRIPP LITE/TRIPP LITE OMNIVS1500XL Unknown protocol (2001)Attached to Tripp Lite OMNIVS1500XL Unknown value for s[2]: 0x34 libusb_set_report() returned -6 instead of 8 Error reading L value: Unknown error -6 Network UPS Tools - Tripp Lite OMNIVS and SMARTPRO driver 0.6 (2.0.3) Warning: This is an experimental driver. Some features may not function correctly. Detected a UPS: TRIPP LITE/TRIPP LITE OMNIVS1500XL Unknown protocol (2001)Attached to Tripp Lite OMNIVS1500XL Unknown value for s[2]: 0x34 libusb_get_interrupt() returned -19 instead of 8 libusb_get_interrupt() returned -19 instead of 8 libusb_get_interrupt() returned -19 instead of 8 Error reading 'D' value: Unknown error 0 libusb_set_report() returned -19 instead of 8 Error reading 'M' value: Device detached? Reconnect attempt #1 Successfully reconnected libusb_set_report() returned -6 instead of 8 Unknown input voltage: 0x00 Unknown battery voltage: 0x Unknown number of switchable load banks: 0x00 Unknown protocol (2001)Attached to Tripp Lite OMNIVS1500XL libusb_set_report() returned -6 instead of 8 Error reading 'T' value: Unknown error -6 I've checked the list archives, and it seems that the unknown protocol part means that my UPS is using a protocol that hasn't yet been seen by the developers. The rest of the errors seem to indicate a connection problem? I have two questions. First, am I right? Is this UPS not supported by tripplite_usb? If so, is there anything I can do to help update the compatibility list and/or add support for my UPS? If not, what else can I try to get it working? Second, what permissions should I set so that I don't need -u root? I've tried chgrp nut /dev/usb/hiddev*, but without -u root I still just get "No UPS found". Thanks, James ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
