Re: [Nut-upsuser] Best practice to shutdown hosts which has not NUT via upssched
Dmitri Stepanov wrote on 7/14/2016 5:18 AM: All the hosts are installed together in one rack and have fed from one UPS (only I am remote from the system :) and I haven't ability to connect to it. Some of hosts haven't NUT for a number of reasons. I don't need to inform not-NUT hosts about any UPS events, heartbeat, etc... but only shutdown all the hosts after upssched timer expired. Because script shutdown-all-hosts.sh works fine (there is no ssh problem) if it's been run by hand but don't work from CMDSCRIPT - I thought that I miss something "at the NUT side". I do something similar, I don't want inbound connections (DMZ --> LAN), so I use SSH. SSH environment difference (e.g. SSH agent forwarding)? That could explain why it works manually, but not when unattended (upssched). I specifically set SSH_AUTH_SOCK="" in my shutdown script so it won't affect my testing when running the script by hand. I use ssh -i for each host to shut down. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] CyberPower CP1500PFCLCD and NUT upsset.cgi
Bill S wrote, On 4/15/2014 11:18 AM: The problem is that when I run upsset.cgi I first get a prompt for user name and password. I then enter the same username and password as I established in upsd.users and it seems to accept it. upsset.cgi doesn't check that user/password is valid, it just tries it when doing a command. I just tested it, it is working for me on a remote and a local UPS using the below upsd.users configuration. [admin] password = xx instcmds = ALL actions = SET actions = FSD ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
[Nut-upsuser] Setting UPS values can be confusing
Windows 7 Pro x64, NUT 2.6.5-4 (interim release) Product: Back-UPS RS 1200 FW:8.g3 .D USB FW:g3 Setting UPS values can be confusing. For example, battery.charge.low and battery.runtime.low. Using upsrw, the values will be retained after restarting the OS, but not if the UPS is turned off/restarted. In the driver log (below), it looks like the values are obtained from the UPS, but if I set default.variable in ups.conf, those get used instead, indicating that the UPS isn't providing those values (per the man page). I did some tests to see how the UPS responds after using upsrw... battery.charge.low -- LB reported by NUT, UPS beeper doesn't indicate LB. battery.runtime.low -- LB reported by NUT, UPS beeper indicates LB. The lowbatt option changes the value in upsc, but otherwise doesn't do anything, I saw it get reset back to 10 after running upscmd. So I guess it would be best to use ignorelb and override.variable? --- 0.624002hid_lookup_usage: UPS - 00840004 0.624002hid_lookup_usage: PowerSummary - 00840024 0.624002hid_lookup_usage: RemainingCapacityLimit - 00850029 0.624002string_to_path: depth = 3 0.624002Report[buf]: (2 bytes) = 11 0a 0.624002PhyMax = 0, PhyMin = 0, LogMax = 100, LogMin = 1 0.624002Unit = , UnitExp = 0 0.624002Exponent = 0 0.624002Path: UPS.PowerSummary.RemainingCapacityLimit, Type: Feature, ReportID: 0x11, Offset: 0, Size: 8, Value: 10 0.624002send_to_all: SETINFO battery.charge.low 10 0.624002send_to_all: SETFLAGS battery.charge.low RW STRING 0.624002send_to_all: SETAUX battery.charge.low 10 0.624002hid_lookup_usage: UPS - 00840004 0.624002hid_lookup_usage: Battery - 00840012 0.624002hid_lookup_usage: RemainingTimeLimit - 0085002a 0.624002string_to_path: depth = 3 0.624002Report[buf]: (3 bytes) = 24 78 00 0.624002PhyMax = 0, PhyMin = 0, LogMax = 65535, LogMin = 0 0.624002Unit = 1001, UnitExp = 0 0.624002Exponent = 0 0.624002Path: UPS.Battery.RemainingTimeLimit, Type: Feature, ReportID: 0x24, Offset: 0, Size: 16, Value: 120 0.624002send_to_all: SETINFO battery.runtime.low 120 0.624002send_to_all: SETFLAGS battery.runtime.low RW STRING 0.624002send_to_all: SETAUX battery.runtime.low 10 21.993257setvar(battery.charge.low, 20) 21.993257Unit = , UnitExp = 0 21.993257Exponent = 0 21.993257PhyMax = 0, PhyMin = 0, LogMax = 100, LogMin = 1 21.998258Report[set]: (2 bytes) = 11 14 21.998258Set report succeeded 21.998258setvar: SUCCEED 30.217728setvar(battery.runtime.low, 240) 30.217728Unit = 1001, UnitExp = 0 30.217728Exponent = 0 30.217728PhyMax = 0, PhyMin = 0, LogMax = 65535, LogMin = 0 30.222728Report[set]: (3 bytes) = 24 f0 00 30.222728Set report succeeded 30.222728setvar: SUCCEED ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Update to the NUT Team members
Arnaud Quette wrote, On 2/15/2014 2:35 AM: Dear NUT users and developers, Frédéric Bohe, NUT Senior developer, who has worked with us as an Eaton contractor from 2009 to 2013, is now retired. Thanks for all the hard work on the Windows port, nut-scanner, Unix packaging, support, ... Fred. We will miss you! Is there anyone left maintaining the Windows port? At the same time, Daniele Pezzini has devoted a lot of time and energy over the past months (and years even). Daniele deserve the NUT Senior developer title, which he kindly accepted. Please join me in welcoming and thanking him. Welcome, and thank you for all the hard work, it's greatly appreciated! ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
[Nut-upsuser] Eaton 5PX broken interrupt on usbhid-ups, also pollfreq vs pollinterval?
Linux NUT 2.7.1 Eaton 5PX usbhid-ups It would appear that interrupts are not actually working on my 5PX using the usbhid-ups driver. I will be trying the serial mge-shut driver next. It just seemed like it was working before because of the default pollinterval of 2 seconds. The status update comes in during the pollinterval no matter what I have pollfreq set to. And I can set pollonly and get the same behavior. With the driver usbhid-ups, what is the relationship between pollfreq and pollinterval? It looks like pollinterval overrides pollfreq. usbhid-ups -a ups -D -x pollfreq=30 -i 30 21 | egrep '(update|ups.status)' 8.580411 upsdrv_updateinfo... 8.831572 Quick update... 8.832351 send_to_all: SETINFO ups.status OL CHRG 8.832807 upsdrv_updateinfo... 9.084535 Quick update... 38.833152 upsdrv_updateinfo... 39.085481 Quick update... (AC removed at this point) 68.833928 upsdrv_updateinfo... 68.844373 Full update... 69.511072 send_to_all: SETINFO ups.status OB DISCHRG (AC restored) 98.833548 upsdrv_updateinfo... 98.839093 Quick update... 98.955823 send_to_all: SETINFO ups.status OL CHRG 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] Delayed UPS start up after shutdown?
Angel Tsankov wrote, On 12/26/2013 12:04 AM: On 12/25/2013 11:42 PM, Kris Jordan wrote: Angel Tsankov wrote, On 12/25/2013 12:16 AM: What did you mean by load.on.delay? upscmd -l ups load.on.delay - Turn on the load with a delay (seconds) Alright, but... how does this command work? Once it has been executed, will the UPS wait the specified period before turning the load on whenever main power is back? The load.on/off commands let you control the load by sending commands to the UPS. One use might be in large installations where you want to fully control (stage) the start-up/shut-down sequence. On a Eaton 3S, the commands worked independently of the state of the manual power switch, but on others I've seen undesired operation. I was just playing, so far I've not needed the functionality. No, to my knowledge, it won't change the power return behavior. ups.timer.shutdown: 0 ups.timer.start: 0 are my upsc values. I'll have to pay more attention to those next time I test. Can you change these values in your UPS's? They aren't in upsrw. I'll be watching them after sending UPS commands that have a delay. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Delayed UPS start up after shutdown?
Angel Tsankov wrote, On 12/25/2013 12:16 AM: What did you mean by load.on.delay? upscmd -l ups load.on.delay - Turn on the load with a delay (seconds) ups.timer.shutdown: 0 ups.timer.start: 0 are my upsc values. I'll have to pay more attention to those next time I test. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Delayed UPS start up after shutdown?
Angel Tsankov wrote, On 12/24/2013 1:22 AM: On 12/06/2013 10:57 PM, Kris Jordan wrote: [...] (*) Some UPS's do provide extra options to determine when they will restore power to load. That would be a nice feature. Anyway, it is a strange thing that I can set the waiting time for power to be restored if main power comes back before offdelay has elapsed, but the UPS ignores this setting if main power comes back after offdelay has elapsed. To me it seems intuitive to restore power only after ondelay has elapsed no matter if main power has come back before or after offdelay. Depends a lot on the UPS's firmware. Cheap units tend to just turn on instantly no matter what, and the better ones tend to follow your directions. I still need to test the reboot functionality on my 5PX, but if it's anything like the Evo850 (also MGE), it should behave. I'll let you know. I can see that my UPS (MGE Protection Center 675) has a parameter ups.timer.start (currently holding the strange value of -10). Any idea if this could help and how this parameter can be changed? in upsrw? ups.timer.start -- Time before the load will be started (seconds). Maybe it counts down after using load.on.delay? Mine don't have the value in upsrw so it can't be set. The Eaton 5PX (which is part MGE) I have here does have one return condition, to return power only if the battery is charged to a certain percentage, battery.charge.restart in upsrw. The only UPS I've had so far that could also (always) wait a bit after power return were APC Smart-UPS's. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Plea for a more loquacious nut
Charles Lepple wrote, On 12/4/2013 4:11 PM: On Dec 4, 2013, at 3:52 PM, Kris Jordan wrote: Roger Price wrote, On 12/4/2013 12:35 PM: I would like nut to become more loquacious, and to log a much more complete report of its activity. At present nut reports that its components have started operation but does not automatically log their activity when UPS's switch between OB and OL. I believe that this under-reporting of important facts is too minimalist - it would be better for system administrators and for the nut support team if a much more complete report were available of all OB/OL activity by each component. I've noticed that NUT doesn't notice short power outages or glitches like previous setups (APC Smart-UPS+Apcupsd) I've had. I do miss that. I thought NUT supported UPS notifications/interrupts so that it can know of power events that happen in-between the regular poll interval. But I don't how much the lack of reporting is due to NUT or the Eaton UPS's I am using now. The default setting in upsmon.conf for ONLINE/ONBATT is SYSLOG+WALL. If those events aren't being logged, we would need to trace further upstream and see if the driver is generating the events. Kris: I don't know the various debug levels off the top of my head, but if you want to manually start the driver with a few -D flags and log the resulting output, we can see whether or not your UPS is sending the notifications the way that the driver is expecting them. apcsmart quick power cuts @ 20 30 usbhid-ups @ 30 40 The APC unit logs alert_handler: OB. usbhid-ups isn't so obvious, so I'm not sure. At least the apcsmart driver is reacting immediately, but upsmon reports nothing unless I cut power long enough. upsmond has noticed quick power cut, but I think that's because It happened at the same time as the normal check interval. I'm using defaults here, as far as poll intervals. Maybe upsd is getting the message, does it push upsmon? I thought to try upsd at full debugging to see if it says anything, but it appears that nothing special is shown for UPS/driver events. 2.7.1 is working fine so far. Thanks for changing the USB timeout. UPS interrupt test.7z Description: Binary data ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Delayed UPS start up after shutdown?
Angel Tsankov wrote, On 12/6/2013 12:31 PM: Hello, René. You can change the parameter ups.delay.start into your UPS to set the Interval to wait before (re)starting the load (seconds) use upsset to change the value. So far, the ups.delay.start parameter in my MGE Protection Center 675 has always been equal to the driver.parameter.ondelay parameter (which equals the ondelay argument in ups.conf). Furthermore, whenever I have changed the ondelay argument in ups.conf (and restarted NUT) the above parameters have always been set equal to ondelay. Therefore, I would assume that ups.delay.start cannot help. Do you have any reason to consider this assumption might be wrong? ondelay maps to ups.delay.start, and offdelay maps to ups.delay.shutdown. offdelay needs to be greater than ondelay. I'm using 600 615 on a Win2k3 server I have connected to an Evolution 850. If the power comes back on during the offdelay period, the ups will do a reboot cycle with a 15s wait. If the power is off for more than offdelay, yeah, it will turn on instantly (*), but by then the PC has had no power for at least 15s. The above will depend on having a good UPS. (*) Some UPS's do provide extra options to determine when they will restore power to load. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
[Nut-upsuser] RedHat init script
I fixed a couple issues in the RedHat init script provided in the scripts directory. There are some other things about it that could use updating, but first I checked out the one included with the RPM (https://admin.fedoraproject.org/pkgdb/acls/name/nut). That one looks pretty good, maybe it should replace the included scripts if permission is given by mhlavink? --- /root/sources/nut-2.6.5/scripts/RedHat/upsd 2012-07-31 10:38:56.0 -0700 +++ /etc/init.d/upsd2013-09-24 16:36:42.0 -0700 @@ -58,16 +58,16 @@ start) # new style drivers uses 'upsdrvctl' echo -n NUT Starting UPS model drivers: - # starting ase nut user + # starting as nut user daemon --user $NUTUSER `which upsdrvctl` start - echo if [ $? -eq 0 ]; then + echo echo -n NUT Starting UPS daemon: - # starting ase nut user + # starting as nut user daemon upsd -u $NUTUSER - echo touch /var/lock/subsys/upsd fi + echo ;; stop) @@ -98,9 +98,6 @@ ;; status) - # new style drivers - action NUT: checking UPS model drivers upsdrvctl status - status upsd ;; *) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Smart-UPS staying in OB after power return
John Morris wrote, On 9/21/2013 11:28 AM: Hi list, UPS is a Smart-UPS 3000 RM (SU3000RM3U, ups.firmware 92.11.D, ups.mfr.date 12/14/99) with brand-new batteries. NUT is 2.6.5 running on SL6 (RHEL6 clone) from EPEL packages. 'upsc' output pasted at bottom. I'm not very familiar with UPSs in general or this model in particular, and it's doing things I don't expect. I have done my homework, and read UPS user manual, googled much, read most NUT manuals, read up to 'queequeg', asked on APC forums, etc. The most distressing problem is the UPS stays OB after removing and reapplying utility power. When power is removed, the UPS goes OB and upsmon detects the power failure no problem, reporting 's0-ups0@localhost is on battery'. But when power is restored, there is no clicking of contactors, no switch back to OL, and no detection by upsmon that power is restored. The UPS can be manually put back OL with 'upscmd load.on'. I would expect the UPS go back OL automatically, though; am I wrong about this? (APC forums folk are thus-far silent on this question.) Pull the batteries and unplug the UPS and press the buttons to fully discharge the UPS. Disconnect the serial/computer interface connection. Re-connect the batteries, plug into utility. Do not re-connect the computer interface. Now that we have rebooted the UPS, see that it works like it should. There are other things I also think odd: - The on-line LED flashes continually; other LEDs look normal; I think I read the on-line LED flashes during a self-test initiated through the 'on/test' button. - The 'on/test' button does not initiate a self-test, or otherwise change the pattern of front-panel LEDs. Normally you would press and hold until it beeps, then it will do a manual self-test. That's if it was already turned on. Otherwise a quick press should turn it on and do a self-test. The on-line LED does flash during the self-test. - While on utility power, the 'off' button acts as a momentary switch, and the loads are powered down only as long as the button is being pressed; also, 'upscmd -u admin -p $passwd s0-ups0 load.off' (twice, 5 secs apart) does not shut down the loads. While on battery power, 'upscmd [...] load.off' works as expected. I think a quick press is all that's needed for it to turn off. In your upsc output, I see 0 load. When the issues where happening, was there a load present? ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Smart-UPS staying in OB after power return
John Morris wrote, On 9/21/2013 6:19 PM: Hi Kris, On 09/21/2013 05:11 PM, Kris Jordan wrote: John Morris wrote, On 9/21/2013 11:28 AM: The most distressing problem is the UPS stays OB after removing and reapplying utility power. When power is removed, the UPS goes OB and upsmon detects the power failure no problem, reporting 's0-ups0@localhost is on battery'. But when power is restored, there is no clicking of contactors, no switch back to OL, and no detection by upsmon that power is restored. The UPS can be manually put back OL with 'upscmd load.on'. I would expect the UPS go back OL automatically, though; am I wrong about this? (APC forums folk are thus-far silent on this question.) Pull the batteries and unplug the UPS and press the buttons to fully discharge the UPS. Disconnect the serial/computer interface connection. Re-connect the batteries, plug into utility. Do not re-connect the computer interface. Now that we have rebooted the UPS, see that it works like it should. I've done this a few times already after reading a 'braindeading' procedure. With cable installed or not, removing utility power switches to battery; restoring power remains on battery. Is that how it should work, or not? Definitely not. Since we got the UPS, it has only been under testing without any load (I just plugged a 200W lamp in for fun). These issues have been persistent since the first time the new batteries were installed and the unit was powered up two days ago. My question remains: The on-line LED should not flash incessantly, and removing and restoring mains power should cause the UPS to switch to OB and then back to OL without intervention, correct? Yes. I've not seen this behavior myself even with bad batteries and a wrong battery constant. Might want to check the batteries with multimeter to be sure. Disconnect and allow them to sit for a day, then check the voltage of each one. They should all be fairly balanced, and I would expect something just above 13V. The UPS itself is going to be pretty aged by now if it has been in use most of that time. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] UPS compatibility list
Chris Boot wrote, On 9/19/2013 12:16 AM: On 19/09/13 01:30, Kris Jordan wrote: Luke-Jr wrote, On 9/18/2013 1:02 PM: I wanted to suggest some rating for functionality. I got the UPS available that seemed to have the best possible rating from NUT's list (Eaton Powerware UPS 1500), and found out it doesn't support telling me battery level or runtime! :/ I'm avoiding Eaton/Powerware because the lack of usbhid support, the bcmxcp driver doesn't report much bootc@tarquin ~ $ upsc pw9120 snip It doesn't? Turns out my choice of UPS is partially to blame. Still, there are items still missing from the driver, like battery.runtime.low and beeper control. I was also told it needed a complete rewrite and it was no where near as complete as the other drivers, mge/hid. Alf has been working on it lately. Thanks. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] UPS compatibility list
Charles Lepple wrote, On 9/19/2013 7:49 PM: On Sep 19, 2013, at 12:11 PM, Paul O'Rorke wrote: So where does this leave things regards Eaton and shut down? Has anyone managed graceful shut down from an Eaton unit with either of the ushhid or bcmxcp drivers? Generally speaking, the UPS will signal when it reaches a low battery state, regardless of whether the UPS publishes runtime statistics, battery percentages, or any other such values. The real difference between a smart and dumb UPS is not just the protocol, but how advanced the battery monitoring and charging circuitry is. I have an old MGE UPS that uses the usbhid-ups driver, and I have no problems shutting down the system via the LB signal in NUT. The non-Powerware-based Eaton units can be considered descendants of this hardware, from what I understand, and provide similar variables. I was able to change battery.charge.low to 50 (*) on an Evolution 850. I tested that the setting took, even if the UPS was rebooted. Because it's powering Win2k3, I changed the offdelay to 600 and the ondelay to 615. I then disabled the beeper. It all works, so I'm pretty happy with the driver capability with this UPS. Driver: usbhid-ups. (*) You don't have to neccessarily use a timeout script to keep from draining the battery. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
[Nut-upsuser] Tripp-lite SMART1050SLT
Windows 7 Pro x64 Tripp-lite SMART1050SLT (USBHID) NUT 2.6.4-5 Driver is malfunctioning if the UPS goes on-battery (quick test or otherwise). usbhid-ups - libusb_get_report: libusb0-dll:err [control_msg] sending control message failed, win error: A device attached to the system is not functioning. (from event log) libusb_get_interrupt: libusb0-dll:err [_usb_reap_async] reaping request failed, win error: A device attached to the system is not functioning. 5D log attached. Disabling and re-enabling the LibUSB entry in device manager will get it back to normal without restarting NUT. Re-plugging the USB cord also works. Windows built-in driver works reliably, but is very limited. Unlike my APC UPS's on Windows 7, this UPS + NUT works just fine through a sleep cycle. usbhid-ups.7z Description: Binary data ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] UPS don't reset
Try rebooting the UPS micro-controller, 1. Unplug the UPS. 2. Disconnect the batteries. 3. Push the buttons to make sure the unit fully discharges internally. 4. Reconnect the batteries and AC. Does that help? Bzzz wrote, On 3/28/2013 1:35 PM: Debian sid package v. 2.6.4-2.3 UPS nitram elite 2002 700VA (serial port) MOBO A7V8X-X Hi list, Everything work fine, except after an AC supply shortage: the UPS don't come back to a normal behavior, it stays on battery (of course, it works right w/o any cable). Is there something I can do recover a normal behavior? JY ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Eaton Powerware 5110
Petr Macek wrote, On 3/7/2013 6:04 AM: Hi, OS: FreeBSD 9.0-RELEASE NUT version: nut-2.6.5_1 (installed from ports) UPS: Eaton powerware 5110 Can you help me with this device, please? [root@mail /usr/local/etc/nut]# /usr/local/libexec/nut/usbhid-ups - -a eaton http://www.networkupstools.org/stable-hcl.html -- bcmxcp_usb I have a 5110 and it does work with that driver, on Windows XP at least. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
[Nut-upsuser] Windows: offdelay/ondelay
Are there plans to change the default offdelay/ondelay for the Windows versions of NUT since it can't be invoked at the end of shutdown? E.g. I have a Win2k3 server that takes just over 4min to shut down, so I set my offdelay to 600 (ondelay is +15 that) to be extra safe. Maybe a 2 min by default would be good? Most (all?) APC non-smart UPS's are hard-coded at an annoying 1min delay, so it wouldn't affect those. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] usbhid-ups driver crash
NUT or this particular UPS+NUT doesn't like the USB 3.0 port it was plugged into. It's all good now after I moved it to a USB 2.0 port. Kris Jordan wrote, On 2/26/2013 8:44 PM: NUT 2.6.5-4 Eaton 3S550 Windows 7 Pro x64 usbhid-ups is crashing if it is started without debugging. This UPS worked fine on my test system with the same OS, but since moving it to the system where it will be used, it's refusing to function with NUT. Looks like it is working with the Windows built-in drivers though. Thanks. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] UPS Liebert GXT-3
Marcelo Roccasalva wrote, On 3/1/2013 12:10 PM: On Thu, Feb 28, 2013 at 6:17 PM, Marcelo Roccasalva roc...@gmail.com wrote: On Tue, Feb 26, 2013 at 10:56 PM, Charles Lepple clep...@gmail.com wrote: On Feb 21, 2013, at 6:21 PM, Marcelo Roccasalva wrote: I'll try the windows monitoring program tomorrow... Any luck? Haven't tried... An Emerson support person sent me an updated version of their software, which offers me an USB port to connect but it fails to communicate with the UPS... Tomorrow will be windows tested... windows xp software tells me I need an UPS connected for the software to work... The usb port has to be damaged... Thanks for your support. Does Windows even notice the USB connection being made? Try resetting the UPS by unplugging, disconnecting batteries, and pressing/holding all the buttons to make sure the UPS is completely discharged. Does that help? ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] false low battery alarm
Vieri wrote, On 2/28/2013 9:41 AM: --- On Thu, 2/28/13, Manuel Wolfshant wo...@nobugconsulting.ro wrote: Good batteries ( for instance Yaesu, as seen in APC UPSes ) last 4 years. Normal ( usual ) ones last 2. Do the math yourself Thanks for that information. Just a side question: Will the ups.mfr.date value be updated automatically by the APC ups firmware when I change the battery or will I need to set it manually? I'm asking because I'm not sure if the current battery was really installed at the time indicated by this field. Where APC has provided a value for battery mfg date, it has always been the same as the UPS mfg date. The value isn't automatically updated and NUT doesn't (from what I've seen) provide a way to update it manually. Before getting new batteries, you might want to check the float voltage with a good multimeter. 55.65 is rather high (~2.32/cell), but I wouldn't trust what the UPS says. Smart-UPS's can be bad about overcharging their batteries. It can be adjusted by software in some cases. I also have another (maybe related) problem. I have another 2 APC devices I'd like to monitor (apparently same model and serial numbers). However, whenever I connect a serial cable to the port on the UPS, the whole device shuts down immediately. This happens only if I connect the other end of the serial cable to either a ttyS0 port on a running motherboard or a port on a rs232-to-usb adapter (even if the usb end ISN'T connected to a NUT monitoring server). What could be happening here? This is obviously slightly off-topic because it doesn't seem to be related to the nut ups drivers. I'm just wondering what could be happening and if old batteries on relatively high load (approx. 75%) could be a reason the UPS shuts down abruptly on connecting a serial cable on both ends. IT sounds really strange though. Also, the UPS won't switch on while the serial cable is connected even if I press the UPS power-on button several times. I have to disconnect it (or at least the far end of it) in order to boot the ups. Are you using APC's supplied serial cable? They have special wiring and it varies depending on UPS model. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] false low battery alarm
Ben Kamen wrote, On 2/28/2013 10:08 AM: On 2013-02-28 11:55 AM, Kris Jordan wrote: Vieri wrote, On 2/28/2013 9:41 AM: --- On Thu, 2/28/13, Manuel Wolfshant wo...@nobugconsulting.ro wrote: Will the ups.mfr.date value be updated automatically by the APC ups firmware when I change the battery or will I need to set it manually? I'm asking because I'm not sure if the current battery was really installed at the time indicated by this field. Where APC has provided a value for battery mfg date, it has always been the same as the UPS mfg date. The value isn't automatically updated and NUT doesn't (from what I've seen) provide a way to update it manually. The Nut Gnome client does allow updating the battery changeout value. the field in question is: battery.date I've only seen it as a read-only value (not in upsrw). Have you tried changing it in that client? ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] false low battery alarm
Ben Kamen wrote, On 2/28/2013 11:52 AM: On 2013-02-28 1:48 PM, Kris Jordan wrote: Ben Kamen wrote, On 2/28/2013 10:08 AM: On 2013-02-28 11:55 AM, Kris Jordan wrote: Vieri wrote, On 2/28/2013 9:41 AM: --- On Thu, 2/28/13, Manuel Wolfshant wo...@nobugconsulting.ro wrote: Will the ups.mfr.date value be updated automatically by the APC ups firmware when I change the battery or will I need to set it manually? I'm asking because I'm not sure if the current battery was really installed at the time indicated by this field. Where APC has provided a value for battery mfg date, it has always been the same as the UPS mfg date. The value isn't automatically updated and NUT doesn't (from what I've seen) provide a way to update it manually. The Nut Gnome client does allow updating the battery changeout value. the field in question is: battery.date I've only seen it as a read-only value (not in upsrw). Have you tried changing it in that client? Yep. Just did it again now as a sanity check. Seems to work (barring a complete shutdown of my web/dns/mail server and all systems to make sure it sticks in the UPS too) Restarting NUT should be enough to check. So NUT probably does support it on certain models. I have a bunch of APC RS's that can have their battery date updated using apctest, but not with NUT. Not a big deal though. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] false low battery alarm
Vieri wrote, On 2/28/2013 10:17 AM: --- On Thu, 2/28/13, Kris Jordan nut...@sagebrushnetworks.com wrote: Are you using APC's supplied serial cable? They have special wiring and it varies depending on UPS model. Nevertheless I'll take some extra time to search for the ups cables just in case I do find them and they really are different. Look for a code on the cable, like 940-0024C. http://www.networkupstools.org/cables.html http://www.apcupsd.com/manual/manual.html#cables ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
[Nut-upsuser] usbhid-ups driver crash
NUT 2.6.5-4 Eaton 3S550 Windows 7 Pro x64 usbhid-ups is crashing if it is started without debugging. This UPS worked fine on my test system with the same OS, but since moving it to the system where it will be used, it's refusing to function with NUT. Looks like it is working with the Windows built-in drivers though. Thanks. usbhid-ups.7z Description: Binary data ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] APC SMX3000RMLV2UNC with AP9631 NUT compatibility via network
Jeff Kowalczyk wrote, On 2/25/2013 4:09 PM: I have an APC SMX3000RMLV2UNC UPS, with installed network card model AP9631. http://www.apc.com/resource/include/techspec_index.cfm?base_sku=SMX3000RMLV2UNC http://www.apc.com/resource/include/techspec_index.cfm?base_sku=AP9631 http://www.networkupstools.org/docs/man/snmp-ups.html I don't see the 9631, so it might not work. I planned to use network connectivity with this unit and apcupsd, but have not this far. The UPS is shared by multiple servers, so a USB or Serial connection via the AP9620 is not feasible: http://www.apc.com/resource/include/techspec_index.cfm?base_sku=AP9620 You don't have to use a SNMP card to shutdown multiple systems. NUT can handle this quite well. I'd expect NUT to work with the AP9620 legacy communications card using either the apcsmart (serial) or usbhid-ups (USB) drivers. I don't recall anyway saying for sure though. I see a prior thread discussing the unfortunate proprietary microlink protocol: Subject: Re: APC Smart-UPS 1200 Date: 2012-10-04 14:55:55 GMT My question is whether microlink is what is actually used for a TCP/IP connection to the AP9631 network card, or whether another protocol such as SNMP is available for NUT to use. Even a lower count of UPS metrics via SNMP would be usable, I just need to reliably signal on power loss events. I'm pretty sure Microlink is just for serial and USB on any current Smart-UPS model. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Detect ups.status on battery seems a little delay
Oleg Semyonov wrote, On 2/20/2013 12:39 AM: UPS model: APC Smart-UPS 750 (051D/0002) But when UPS is offline, status will not change to OB immediately. After test many times. this delay time didn't have any rules. Maybe immediately or few seconds or few minutes. It will cause doing ONBATT action also delayed. I asked exactly the same question on the 29th of January, and got nothing in reply. It doesn't seem to be a bike shedding problem, so nobody bothered, including developers (about using non-documented and probably non-supported option value). http://en.wikipedia.org/wiki/Parkinson's_law_of_triviality Short solution: set pollinterval=0 in driver configuration. It will report OB/OL immediately (but with a bit more CPU load). Full description: see my question here: http://lists.alioth.debian.org/pipermail/nut-upsuser/2013-January/008195.html Does the problem persist outside of a VM? * pollfreq*=/num/ Set polling frequency, in seconds, to reduce the USB data flow. Between two polling requests, the driver will wait for interrupts (aka UPS notifications), which are data changes returned by the UPS by itself. This mechanism allow to avoid or reduce staleness message, due to the UPS being temporarily overloaded with too much polling requests. The default value is 30 (in seconds). Sounds like NUT supports interrupts with this driver. Pollfreq vs. pollinterval, I also wonder what is up with those two options. Is that a Microlink Smart-UPS? Perhaps one of its compatibility mode limitations are no interrupts. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Detect ups.status on battery seems a little delay
黃俊瑋 wrote, On 2/20/2013 5:45 PM: My default setting in upsmon.conf already have POLLFREQ 5. (defalut value in upsmon.conf) And my original pollinterval is pollinterval=5. I didn't run nut on VM when I report this issue. I tried Oleg's solution to set pollinterval=0, it works. But I am afraid any other side effect. I was talking about pollfreq in usbhid-ups, http://www.networkupstools.org/docs/man/usbhid-ups.html. When I get time, I plan to test UPS notifications. I'm interested to see how NUT reacts. I did notice one thing though after switching to NUT. The many APC RS UPS's I have spam battery disconnect/reconnect (no battery) messages as one of the indications that a replacement battery is needed. NUT didn't care this was happening, as there were no messages or upsc output to indicate an issue. So UPS notifications are not working or NUT is ignoring short-lived events. The replace/bad battery light was going on and off randomly, so I knew it was happening at the time. If I unplug the battery for real, NUT will eventually tell me. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] UPS Liebert GXT-3
Charles Lepple wrote, On 2/19/2013 6:35 PM: On Feb 19, 2013, at 3:07 PM, Marcelo Roccasalva wrote: Bus 004 Device 002: ID 10af:0008 Liebert Corp. PowerSure Interactive UPS Not sure if you tried this yet, but what if you set productid=0008 in ups.conf? You will also need to temporarily start the driver with -u root or add this vendor/product ID pair to the udev file (sorry, not sure where that lives on CentOS) since that isn't one of the known USB Product IDs. /etc/udev/rules.d Centos5 will require syntax alternations, if using 52-nut-usbups.rules from NUT 2.6.5. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Windows XP ups.conf question
Charles Lepple wrote, On 2/16/2013 8:08 AM: On Feb 14, 2013, at 4:23 PM, Kris Jordan wrote: port = com3 It's obvious but I initially didn't know either. Dev suggestion: Might be good if this was noted in the sample config. Does it matter whether or not the COM port name has a colon after it? It worked without a colon for mge-shut on Win7 x64 + usb serial adapter. Want me to try it with a colon? ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Windows XP ups.conf question
Charles Lepple wrote, On 2/16/2013 10:19 AM: On Feb 16, 2013, at 12:07 PM, Kris Jordan wrote: Charles Lepple wrote, On 2/16/2013 8:08 AM: On Feb 14, 2013, at 4:23 PM, Kris Jordan wrote: port = com3 It's obvious but I initially didn't know either. Dev suggestion: Might be good if this was noted in the sample config. Does it matter whether or not the COM port name has a colon after it? It worked without a colon for mge-shut on Win7 x64 + usb serial adapter. Want me to try it with a colon? Sure, when you have a chance. It works with a colon too, port = com3: ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Windows XP ups.conf question
port = com3 It's obvious but I initially didn't know either. Dev suggestion: Might be good if this was noted in the sample config. Nick P. Petropoulos wrote, On 2/14/2013 12:43 PM: Dear friends, I am trying NUT standalone on XP. My UPS is on serial port COM3 How can I include the serial port info in the ups.conf file. If it was like in Linux, I would put port=/dev/ttyS2 However, something tells me that this is not correct. Your input will be much appreciated. Regards Nick ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] IBM 6000 VA LCD 4U Rack UPS
Kilian Röhner wrote, On 2/12/2013 5:56 AM: Hello, i have a new IBM 6000 VA LCD 4U Rack UPS attached to my debian machine via USB. Can you help me choosing a matching driver? Is this UPS type even supported by NUT? I could not find the UPS in this list: http://www.networkupstools.org/stable-hcl.html Made by Eaton? http://powerquality.eaton.com/ibm/EMEA/Products/UPS-systemx.asp Try the usbhid-ups driver. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] IBM 6000 VA LCD 4U Rack UPS
Kilian Röhner wrote, On 2/13/2013 2:03 PM: Made by Eaton? http://powerquality.eaton.com/ibm/EMEA/Products/UPS-systemx.asp that is the one (at least the picture looks the same, not sure if its really made by eaton though - manufacturer is IBM). UPS re-branding is pretty common from what I've heard. Try the usbhid-ups driver. i did and set port = auto. Unfortunately, upsdrvctl said: # upsdrvctl start Network UPS Tools - UPS driver controller 2.6.4 Network UPS Tools - Generic HID driver 0.37 (2.6.4) USB communication driver 0.31 No matching HID UPS found Driver failed to start (exit status=1) lsusb, so we can see the UPS ID. Run the driver by itself with -D's (up to 5 of them) usbhid-ups -a ups_name -DD ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] IBM 6000 VA LCD 4U Rack UPS
Kilian Röhner wrote, On 2/13/2013 2:51 PM: Run the driver by itself with -D's (up to 5 of them) usbhid-ups -a ups_name -DD i'm not sure how to do that - there is no usbhid-ups exec in the PATH. Should i specify the arguments in the ups.conf somewhere? upsdrvctl -DD start will tell you where it is. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] IBM 6000 VA LCD 4U Rack UPS
Kilian Röhner wrote, On 2/13/2013 3:03 PM: ok, i found it. the relevant output is: 0.264144 Checking device (04B3/0001) (006/003) 0.264193 - VendorID: 04b3 0.264225 - ProductID: 0001 0.264256 - Manufacturer: unknown 0.264280 - Product: unknown 0.264309 - Serial Number: unknown 0.264334 - Bus: 006 0.264364 Trying to match device 0.264390 Device does not match - skipping For a second there I thought the vendorid was 0463 which is MGE UPS, owned by Eaton. You can specify the vendorid option in ups.conf, vendorid = 04b3 http://www.networkupstools.org/docs/man/usbhid-ups.html And try the explore option, but I'm not sure that is entirely safe. I'll let someone else answer what's best to do next. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] IBM 6000 VA LCD 4U Rack UPS
Kilian Röhner wrote, On 2/13/2013 4:13 PM: Even if you run the driver as root, it drops privileges unless otherwise specified. /path/to/usbhid-ups -u root -a ups_name -DD ok, now something is happening (see below). The last lines just keep repeating (with -DD). But honestly, i have no clue what all this means... :-) Looks about normal to me (not sure if those unknown info types are a concern), once the driver finishes all its pre-initialization, it goes into a polling loop. I let it run for 1 minute or so... is it supposed to terminate at some point? ^C when you're done. 0.390554 Found HID device 0.390581 Detected a UPS: IBM/IBM 6000VA/5600W Rack HV UPS snip Now try without explore, but with vendor still set and see if the driver will start normally. ___ 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 with NUT and an Eaton 5PX UPS, usbhid-ups won't start
Stefan wrote, On 2/8/2013 12:16 PM: Hey, thanks for answering. I haven't used a mailing list before and I'm not sure where to send my reply. Anyway I found the problem. I normally reply only to the list. lsusb -v -s 006:002 returned the ups descriptor just fine, so I figured there is something wrong in usbhid-ups. Thing is, lsusb takes about 5 seconds to run, while usbhid-ups clearly has a 4 seconds timeout for getting the FULL descriptor. I did some snooping with usbmon and I found out that 4 seconds are not enough to receive the whole descriptor (it got to 2312 of 2580 bytes). I downloaded the nut source and did some digging. In file /root/nut-2.6.5/drivers/libusb.c somebody lowered the default timeout: /* USB standard state 5000, but we've decreased it to * improve reactivity */ #define USB_TIMEOUT 4000 So here are those 4 seconds ruining my day. I increased the timeout to 8000, compiled and everything runs fine now: 0.263313 Checking device (0463/) (006/002) 0.566989 - VendorID: 0463 0.567026 - ProductID: 0.567043 - Manufacturer: EATON 0.567060 - Product: Eaton 5PX 0.567076 - Serial Number: G097C22040 0.567092 - Bus: 006 0.567107 Trying to match device 0.567129 Device matches 0.619001 HID descriptor, method 1: (9 bytes) = 09 21 10 01 21 01 22 14 0a 0.619026 i=0, extra[i]=09, extra[i+1]=21 0.619051 HID descriptor, method 2: (9 bytes) = 09 21 10 01 21 01 22 14 0a 0.619069 HID descriptor length 2580 5.073991 Report Descriptor size = 2580 5.074039 Report Descriptor: (2580 bytes) = 05 84 09 04 a1 01 09 10 a1 00 09 12 a1 (snipped) Turns out it was a matter of 0.4s, so the USB standard 5 seconds would have worked as expected. lsusb for mine takes, real0m4.891s 5s would be cutting it close. Perhaps that's also why it's not working on Windows. Now where do I bug report this? They're on this list, but they've been quiet for a while. ___ 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 with NUT and an Eaton 5PX UPS, usbhid-ups won't start
I set mine to 6000. I only get the below now. libusb_get_interrupt: Connection timed out Otherwise, it appears to be working fine. I don't even get the kernel message anymore. Thanks Stefan. ___ 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 with NUT and an Eaton 5PX UPS, usbhid-ups won't start
I couldn't get a 5PX1500RT to work with NUT 2.6.5-4 on Windows using usbhid. In your Log, 4.805060 No appropriate HID device found 4.805087 No matching HID UPS found I got those on my Windows test machine. I recently compiled NUT 2.6.5-4 on Centos 5. It seems to be working with usbhid-ups. Not sure why it doesn't on Windows. Though, I still do get some errors, Warning: report descriptor too short (expected 2580, got 2312) libusb_get_report: Connection timed out Can't retrieve Report 28: Connection timed out libusb_get_interrupt: Connection timed out and USBDEVFS_CONTROL failed cmd usbhid-ups rqt 161 rq 1 len 2 ret -110 kernel messages. A higher pollinterval doesn't eliminate that. Seems to only happen when the driver starts. Try updating NUT to 2.6.5, you could also try mge-shut (I'm using the newer mge-shut driver) over serial, that seems to work fine (on my Windows machine anyway). Stefan wrote, On 2/7/2013 3:33 PM: Hello, I have trouble connecting to an Eaton 5PX UPS via the usbhid-ups driver. It is supposed to be fully working according to the compatibility list (support level 5). OS: A fresh Debian stable install. Then changed the apt source to unstable and did aptitute update and aptitude install nut. Nothing else. I did that, because the unstable package is a more recent version and I've already tried with stable a few days before. The hard drive was changed, so there are no old version leftovers to worry about. NUT version: the Debian package says 2.6.4-2.3 NUT installation method: Debian unstable package (http://packages.debian.org/sid/nut) UPS info: Eaton 5PX3000iRT3U, which is the European (220V) version of 5PX3000RT3U. http://powerquality.eaton.com/5PX3000iRT3U.aspx?CX=101 I tried to power cycle the machine, as well as the UPS. Permissions seem fine: root@backup:/usr/share/doc/nut# ls -al /dev/bus/usb/006/002 crw-rw-r-- 1 root nut 189, 641 Feb 8 01:26 /dev/bus/usb/006/002 /lib/nut/usbhid-ups - -a myups whole log: http://pastebin.com/Xc57QUft relevant part: 0.265426 Checking device (0463/) (006/002) 0.570524 - VendorID: 0463 0.570560 - ProductID: 0.570578 - Manufacturer: EATON 0.570595 - Product: Eaton 5PX 0.570612 - Serial Number: G097C22040 0.570629 - Bus: 006 0.570646 Trying to match device 0.570678 Device matches 0.621532 HID descriptor, method 1: (9 bytes) = 09 21 10 01 21 01 22 14 0a 0.621569 i=0, extra[i]=09, extra[i+1]=21 0.621595 HID descriptor, method 2: (9 bytes) = 09 21 10 01 21 01 22 14 0a 0.621614 HID descriptor length 2580 4.622305 Unable to get Report descriptor: Connection timed out I don't know how to provide more info about that connection timeout. Steven ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] upsd crashing when stopped
Kris Jordan wrote, On 1/16/2013 2:30 PM: Windows 7 Pro x64 SP1 NUT 2.6.5-4 upsd is crashing when stopped and I think it has only started with the latest version. Nothing shows up in 5'D upsd output, the normal output just quits. Windows 7 event log output below. upsd no longer crashes when downgraded to 2.6.5-3. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] usbbid-ups crashes, wake from sleep
Kris Jordan wrote, On 1/20/2013 3:47 PM: Windows 7 Pro x64 NUT 2.6.5-4 APC RS 1200 (BR1200) and also RS 500 (BR500) Two PC's which are routinely put to sleep is giving usbhid-ups headaches. From the Event log... I've done further tests... It would appear that only APC UPS's cause the driver to crash on system wake. I also tested a APC ES 725 and got the same crash. An Eaton 3S 550, despite still getting the libusb_get_interrupt error, does not crash usbhid-ups and reestablishes communications fine. I downgrade to 2.6.5-3, but the usbhid-ups driver crash persisted. I made sure to clean all drivers off (pnputil -e, etc) before I downgraded. I will attempt to get driver debug output between the ES and the 3S. My current workaround is an event based task that restarts the nut service when the system wakes. Feature idea, have the nut master service restart crashed sub-processes (driver, upsmon, upsd). You would also want to limit how often this can happen in case a process will simply not start for some reason. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
[Nut-upsuser] Windows driver installer not always successful
The Windows driver installer isn't always successful, actually most of the time it fails. I thought it was due to differences between Windows XP and 7 or different UPS models. But I'm noticing that it might be a bit more random than that. What does seem to always work is running wdi-simple.exe from the others folder manually. When having it run from the NUT installer, it will extract usb_driver to windows\system32 (or syswow64). And when run afterwards, the others folder instead. Not sure if that is really a problem or not except a bit messy. As always, thanks! ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] usbbid-ups crashes, wake from sleep
Kris Jordan wrote, On 1/29/2013 2:00 PM: Kris Jordan wrote, On 1/20/2013 3:47 PM: Windows 7 Pro x64 NUT 2.6.5-4 APC RS 1200 (BR1200) and also RS 500 (BR500) Two PC's which are routinely put to sleep is giving usbhid-ups headaches. From the Event log... I've done further tests... It would appear that only APC UPS's cause the driver to crash on system wake. I also tested a APC ES 725 and got the same crash. An Eaton 3S 550, despite still getting the libusb_get_interrupt error, does not crash usbhid-ups and reestablishes communications fine. I will attempt to get driver debug output between the ES and the 3S. By itself, the driver reconnects to either UPS after wake, when started at the command line. It's not until I also run upsd upsmon that it will crash. The ES log simply ends when the system sleeps. So I'm not sure how much use it will be. driver logs.7z Description: Binary data ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
[Nut-upsuser] usbbid-ups crashes, wake from sleep
Windows 7 Pro x64 NUT 2.6.5-4 APC RS 1200 (BR1200) and also RS 500 (BR500) Two PC's which are routinely put to sleep is giving usbhid-ups headaches. From the Event log... usbhid-ups - libusb_get_interrupt: libusb0-dll:err [submit_async] submitting request failed, win error: The system cannot find the file specified. Above is at the time of system sleep. The rest below happens when the system is woke back up. I collected the files in the programdata WER folder. It takes restarting the NUT service twice; upsd is 'unable to stop' on the first try. upsd - Data for UPS [ups] is stale - check driver. --- upsmon - Poll UPS [ups@localhost] failed - Write error: Unknown error. --- Faulting application name: usbhid-ups.exe, version: 0.0.0.0, time stamp: 0x50ae4032 Faulting module name: msvcrt.dll, version: 7.0.7601.17744, time stamp: 0x4eeaf722 Exception code: 0xc005 Fault offset: 0x000101d5 Faulting process id: 0x32c Faulting application start time: 0x01cdf4473bcae202 Faulting application path: C:\Program Files (x86)\NUT\bin\usbhid-ups.exe Faulting module path: C:\Windows\syswow64\msvcrt.dll Report Id: 81638a30-60cb-11e2-90d9-001fd0a249ba --- Fault bucket , type 0 Event Name: APPCRASH Response: Not available Cab Id: 0 Problem signature: P1: usbhid-ups.exe P2: 0.0.0.0 P3: 50ae4032 P4: msvcrt.dll P5: 7.0.7601.17744 P6: 4eeaf722 P7: c005 P8: 000101d5 P9: P10: Attached files: C:\Windows\Temp\WERC718.tmp.appcompat.txt C:\Windows\Temp\WERCC47.tmp.WERInternalMetadata.xml C:\Windows\Temp\WERCCC5.tmp.hdmp C:\Windows\Temp\WERCE4C.tmp.mdmp These files may be available here: C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_usbhid-ups.exe_a7c32d8e6d503378bf6dadb5b28e547f78d77d1c_cab_10a8ce78 Analysis symbol: Rechecking for solution: 0 Report Id: 81638a30-60cb-11e2-90d9-001fd0a249ba Report Status: 6 --- upsd - User upsmon@127.0.0.1 logged into UPS [ups]. --- upsmon - Poll UPS [ups@localhost] failed - Data stale. --- upsd - Send ping to UPS [ups] failed: No error [The pipe is being closed. ]. --- upsmon - Poll UPS [ups@localhost] failed - Data stale. (EVERY 5 seconds from then on!) ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
[Nut-upsuser] upsmon event log spam
Windows 7 Pro x64 NUT 2.6.5-4 upsmon, when there is a problem, spams the event log every 5 seconds. Poll interval is 5 seconds also. I have witnessed the below messages filling up the event log. upsmon - UPS [ups@localhost]: connect failed: Connection failure: Unknown error. upsmon - Poll UPS [ups@localhost] failed - Data stale. I've already reported earlier how I've been spammed with invisible (at least over RDP) message.exe processes. Ate all the system memory and caused massive hard disk swapping, system would have been lost to me if pskill didn't work. I've disabled 'WALL' in upsmon.conf to hopefully prevent that occurring again. There doesn't appear to be a way to stop the 'data stale' messages from upsmon using NOTIFYFLAG. I also never see commbad/nocomm messages, just 'data stale' (UPS unplugged) then COMMOK when I plug the UPS back in. There needs to be some kind of limiter in place for any kind of logging or message.exe spawning. Also, not seeing any popups from upsmon, nor message.exe's. Is that because of my OS type? Regards. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
[Nut-upsuser] upsd crashing when stopped
Windows 7 Pro x64 SP1 NUT 2.6.5-4 upsd is crashing when stopped and I think it has only started with the latest version. Nothing shows up in 5'D upsd output, the normal output just quits. Windows 7 event log output below. It's also crashing on XP, though I do have one XP system where it doesn't crash. One difference on WinXP is the upsd process gets stuck running and doesn't close, like it does on Win7, so I have to end the task manually before I can start NUT back up. It happens on my clean test machine with a different driver too, so it will probably be easily reproducible. Regards. Log Name: Application Source:Application Error Date: 1/16/2013 1:44:33 PM Event ID: 1000 Task Category: (100) Level: Error Keywords: Classic User: N/A Computer: x Description: Faulting application name: upsd.exe, version: 0.0.0.0, time stamp: 0x50ae404a Faulting module name: ntdll.dll, version: 6.1.7601.17725, time stamp: 0x4ec49b8f Exception code: 0xc005 Fault offset: 0x000222b2 Faulting process id: 0xb54 Faulting application start time: 0x01cdf4329fa997b4 Faulting application path: C:\Program Files (x86)\NUT\sbin\upsd.exe Faulting module path: C:\Windows\SysWOW64\ntdll.dll Report Id: e9e86704-6025-11e2-ae84-00241d8c7529 Event Xml: Event xmlns=http://schemas.microsoft.com/win/2004/08/events/event; System Provider Name=Application Error / EventID Qualifiers=01000/EventID Level2/Level Task100/Task Keywords0x80/Keywords TimeCreated SystemTime=2013-01-16T21:44:33.0Z / EventRecordID50514/EventRecordID ChannelApplication/Channel Computerx/Computer Security / /System EventData Dataupsd.exe/Data Data0.0.0.0/Data Data50ae404a/Data Datantdll.dll/Data Data6.1.7601.17725/Data Data4ec49b8f/Data Datac005/Data Data000222b2/Data Datab54/Data Data01cdf4329fa997b4/Data DataC:\Program Files (x86)\NUT\sbin\upsd.exe/Data DataC:\Windows\SysWOW64\ntdll.dll/Data Datae9e86704-6025-11e2-ae84-00241d8c7529/Data /EventData /Event ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
[Nut-upsuser] Eaton 5PX1500RT
Windows 7 x64 NUT 2.6.5-4 Eaton 5PX1500RT Using explore did not yield any additional output. This UPS is on the compatibility list, so hopefully not a big deal. I double-checked that the 3S still works with the same USB cable. I'll check mge-shut over serial next. Regards. Network UPS Tools - Generic HID driver 0.37 (2.6.5-3780M) USB communication driver 0.31 0.00 debug level is '5' 0.00 upsdrv_initups... 0.00 Checking device (0463/) (bus-0/\\.\libusb0-0001--0x0463-0x) 0.281250 - VendorID: 0463 0.281250 - ProductID: 0.281250 - Manufacturer: EATON 0.281250 - Product: Eaton 5PX 0.281250 - Serial Number: G090C25071 0.281250 - Bus: bus-0 0.281250 Trying to match device 0.281250 Device matches 0.343750 HID descriptor, method 1: (9 bytes) = 09 21 10 01 21 01 22 14 0a 0.343750 i=0, extra[i]=09, extra[i+1]=21 0.343750 HID descriptor, method 2: (9 bytes) = 09 21 10 01 21 01 22 14 0a 0.343750 HID descriptor length 2580 4.343750 Unable to get Report descriptor: No error [The I/O operation has been aborted because of either a thread exit or an application request. ] 4.343750 No appropriate HID device found 4.343750 No matching HID UPS found ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Eaton 5PX1500RT
Kris Jordan wrote, On 1/10/2013 2:50 PM: Windows 7 x64 NUT 2.6.5-4 Eaton 5PX1500RT Using explore did not yield any additional output. This UPS is on the compatibility list, so hopefully not a big deal. I double-checked that the 3S still works with the same USB cable. I'll check mge-shut over serial next. Looks like mge-shut is working, even over a USB-serial adapter. I have a lot to test, but I'd rather do that with usbhid, unless you think mge-shut is preferable for some reason? I'm not using SSL, but now when I run upsc I get... upscli not initialized, force initialisation without SSL configuration Init SSL without certificate database Can not connect to localhost in SSL, continue uncrypted Something apparently changed in 2.6.5 with SSL. Regards. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
[Nut-upsuser] Eaton 5P (5P1500RT)
So based on the compatibility page, I might be okay with the 5P. The page specifically mentions the 5PX. Anyone using this UPS? When looking at Eaton UPS's I excluded any of the older ones that use the BCM driver since that driver provides little functionality as I've learned with the 5110. There's also the Evo, but I would prefer to have one with ABM. I'm open to other models (or even brands) if they work great with NUT and are decent hardware-wise overall. I'd like better battery management than I'm used to (darn Smart-UPS's), so an always on fan and temperature compensation would be best. Can't be too expensive though, the 5P I'm looking at is ~$600 which might be a stretch as it is. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] 181 message.exe processes
Kris Jordan wrote, On 11/8/2012 11:19 PM: Windows Server 2000 R2 Standard edition x64 I found a bunch of message.exe processes running on this system (181 of them in total). The UPS was going on-battery a lot! There is no attached screen and I don't see any message boxes when I RDP. Do I just set NOTIFYCMD to something nonsensical to stop it from running message.exe? I removed WALL from NOTIFYFLAG's. NOTIFYFLAG ONLINESYSLOG NOTIFYFLAG ONBATTSYSLOG NOTIFYFLAG LOWBATTSYSLOG NOTIFYFLAG FSDSYSLOG NOTIFYFLAG COMMOKSYSLOG NOTIFYFLAG COMMBADSYSLOG NOTIFYFLAG SHUTDOWNSYSLOG NOTIFYFLAG REPLBATTSYSLOG NOTIFYFLAG NOCOMMSYSLOG NOTIFYFLAG NOPARENTSYSLOG ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Tripp-Lite INTERNET525U
Kris Jordan wrote, On 10/25/2012 11:30 AM: Charles Lepple wrote, On 10/25/2012 4:18 AM: On Thu, Oct 25, 2012 at 2:47 AM, Kris Jordan nut...@sagebrushnetworks.com wrote: I assume some kind of USB debugging will need to be done? And can that be easily done (software-wise) on Windows 7 Pro x64? I don't have a convenient Linux test system at hand for the moment, though I do have a few VM's (assuming the extra layers don't get in the way). Unfortunately, it sounds like our usual suggestions for Windows tools won't work: http://libusb.6.n5.nabble.com/Working-preferably-free-USB-sniffer-for-Windows-7-x64-td8754.html It is easiest to have Windows in a VM, and do the USB capture from a Linux host running the virtual machine manager (VirtualBox, VMWare, Qemu, etc.) I also have a Windows XP VM. So I could use the old Windows tools. I wouldn't mind learning a bit about the USB capture stuff. I have SniffUSB installed on a Windows XP VM. I think SniffUSB is the latest *free* Windows USB sniff program available, built on other people's work. Seems to work fine when I tested it with the 3S 550. So I can do some captures of the Tripp-Lite 550 if that setup will do. Otherwise, the WinXP virtualbox, linux usbmon + ?wireshark? setup will be some time later when I get a test machine setup with Centos6 or the current Fedora release. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
[Nut-upsuser] 181 message.exe processes
Windows Server 2000 R2 Standard edition x64 I found a bunch of message.exe processes running on this system (181 of them in total). The UPS was going on-battery a lot! There is no attached screen and I don't see any message boxes when I RDP. Do I just set NOTIFYCMD to something nonsensical to stop it from running message.exe? It would be nice if the Windows defaults were shown in the config files. Thanks! ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Eaton 3S550
Arnaud Quette wrote, On 10/29/2012 1:11 PM: the point is that there is a bug in NUT, and I dislike when I don't understand. I've tracked it, for later processing: https://alioth.debian.org/tracker/index.php?func=detailaid=313884group_id=30602atid=411542 I installed Sniff USB 2.0 on an XP VM running on a Windows 7 Pro x64 host. I attached the 3S 550 to that VM and installed the Eaton personal solution pac. I activated logging just long enough for me to disable then enable the beeper using Eaton's software. Is this output helpful? If so, I'll do similar for low/high transfer setting. Maybe sometime I can get a Linux usbmon type setup and run the VM on that. USB Sniff.7z Description: Binary data ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Tripp-Lite INTERNET525U
Kris Jordan wrote, On 10/1/2012 9:27 PM: Charles Lepple wrote, On 10/1/2012 5:01 AM: Kris: Let us know if you want to experiment with the INTERNET525U after your other UPS comes in. Yeah, maybe later. I assume some kind of USB debugging will need to be done? And can that be easily done (software-wise) on Windows 7 Pro x64? I don't have a convenient Linux test system at hand for the moment, though I do have a few VM's (assuming the extra layers don't get in the way). ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Eaton 3S550
Arnaud Quette wrote, On 10/24/2012 3:33 PM: I always test. Beeper still beeps while on-battery. Using Eaton's software, it can disable the alarm just fine. I re-enabled the alarm before I ran the above command. My previously attached logs included me running every command including upsc. quite frankly, I'm puzzled. I would need to test on an actual device... and currently, I can't! that would be worth, with the below (depending on your answer) to contact the official Eaton support. For being a problem just for NUT, it sounds like Eaton would not care much. I have no need to re-enable it once I got it disabled, so I'm fine. The two values are linked, as long as you use a valid value for low or high, the other value will also change. But, there is one that doesn't work, a low value of 75. low-high: 84-142 (red light) 96-138 (both lights) 75-144 (green light) upsrw -u admin -p password -s input.transfer.high=138 ups Result: 84-142 -- 96-138 upsrw -u admin -p password -s input.transfer.low=75 ups Result: 96-138 -- 84-142 upsrw -u admin -p password -s input.transfer.low=96 ups Result: 84-142 -- 96-138 I've tested it a bunch of times, low=75 is the only one giving me troubles. The other way to get 75-144 is to use high=144, which works fine. strange! the trace shows no error, but the value is indeed not changed. and this works with the windows SW? Yes, and I just doubled-checked to be sure. Perhaps it only sends the high value. So there might be a firmware bug for setting the low value. I have my work-around and it's documented in my notes for this UPS. Unless Eaton changes their stance about NUT, it sounds like there is nothing worth contacting them about. However, I have told them about the sleep issue I was having since that happens no matter what. Don't worry about the lag, and thank you for the hard work (and more)! ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Tripp-Lite INTERNET525U
Charles Lepple wrote, On 10/25/2012 4:18 AM: On Thu, Oct 25, 2012 at 2:47 AM, Kris Jordan nut...@sagebrushnetworks.com wrote: I assume some kind of USB debugging will need to be done? And can that be easily done (software-wise) on Windows 7 Pro x64? I don't have a convenient Linux test system at hand for the moment, though I do have a few VM's (assuming the extra layers don't get in the way). Unfortunately, it sounds like our usual suggestions for Windows tools won't work: http://libusb.6.n5.nabble.com/Working-preferably-free-USB-sniffer-for-Windows-7-x64-td8754.html It is easiest to have Windows in a VM, and do the USB capture from a Linux host running the virtual machine manager (VirtualBox, VMWare, Qemu, etc.) I also have a Windows XP VM. So I could use the old Windows tools. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Eaton 3S550
Arnaud Quette wrote, On 10/18/2012 11:39 AM: Hi Kris, as told in a separate mail on the list, I will there be acting as an individual, since Eaton current stance is to not allow me to support NUT users nor to do my NUT leader tasks on my working hours for a few weeks now! I must have missed that message. I saw something about the hosting change, but I saw no reason why. Part of my reason to go Eaton was because of their support for Open Source and NUT (or at least I thought because they were hosting). the current Eaton support is limited to Frederic's work on the Windows port, and Vaclav integration works (clock_gettime and monotonic). 2012/10/13 Kris Jordan nut...@sagebrushnetworks.com mailto:nut...@sagebrushnetworks.com Kris Jordan wrote, On 10/10/2012 11:00 PM: Windows 7 Pro x64 Eaton 3S550 (brand new, battery mfg 8/15/2012) NUT 2.6.5-3 Pretty much done testing this UPS on Windows. I couldn't disable the beeper using NUT, and even after doing so successfully with the Solution-Pac, it still says enabled (in NUT). Though I thank Eaton for not using an obnoxious (loud) beeper. is it actually enabled? i.e, when unplugging the power cord, does it beep or not? I would like to see a driver debug trace (level 5) when calling 'upscmd ... beeper.off'. upscmd -u admin -p password ups beeper.off I always test. Beeper still beeps while on-battery. Using Eaton's software, it can disable the alarm just fine. I re-enabled the alarm before I ran the above command. My previously attached logs included me running every command including upsc. I also get ERR VAR-NOT-SUPPORTED for input.transfer.low/high. This is perhaps normal because of the way this UPS sets the value in a combined fashion. I did not log this happening. If wanted, I can test it more. strange, the trace clearly state the variable publication. so, yes, I'm interested in both the exact command used (copy/paste) + the driver trace excerpt around the upsrw call (grep for 'setvar') For whatever reason, I no longer get the ERR message, maybe I kept mistyping something. The two values are linked, as long as you use a valid value for low or high, the other value will also change. But, there is one that doesn't work, a low value of 75. low-high: 84-142 (red light) 96-138 (both lights) 75-144 (green light) upsrw -u admin -p password -s input.transfer.high=138 ups Result: 84-142 -- 96-138 upsrw -u admin -p password -s input.transfer.low=75 ups Result: 96-138 -- 84-142 upsrw -u admin -p password -s input.transfer.low=96 ups Result: 84-142 -- 96-138 I've tested it a bunch of times, low=75 is the only one giving me troubles. The other way to get 75-144 is to use high=144, which works fine. Thanks! Logs.7z Description: Binary data ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Eaton 3S550
Kris Jordan wrote, On 10/10/2012 11:00 PM: Windows 7 Pro x64 Eaton 3S550 (brand new, battery mfg 8/15/2012) NUT 2.6.5-3 Pretty much done testing this UPS on Windows. I couldn't disable the beeper using NUT, and even after doing so successfully with the Solution-Pac, it still says enabled (in NUT). Though I thank Eaton for not using an obnoxious (loud) beeper. I also get ERR VAR-NOT-SUPPORTED for input.transfer.low/high. This is perhaps normal because of the way this UPS sets the value in a combined fashion. I did not log this happening. If wanted, I can test it more. Thanks! usbhid-ups.7z Description: Binary data ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Eaton 3S550
fredericb...@eaton.com wrote, On 10/11/2012 6:08 AM: From: nut-upsuser-bounces+fredericbohe=eaton@lists.alioth.debian.org [nut-upsuser-bounces+fredericbohe=eaton@lists.alioth.debian.org] on behalf of Kris Jordan [nut...@sagebrushnetworks.com] Sent: Thursday, October 11, 2012 8:00 AM To: nut-upsuser@lists.alioth.debian.org Subject: [Nut-upsuser] Eaton 3S550 I had to reinstall to get a proper usb_device.inf. Is there an easier way to regenerate that file when dealing with multiple UPS types on a test system? Not sure if this is what you are looking for, but maybe running wdi-simple.exe (in the others directory of your NUT installation) after plugging your new device might help. Thanks, that's what I needed. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Eaton 3S550
Kris Jordan wrote, On 10/10/2012 11:00 PM: Windows 7 Pro x64 Eaton 3S550 (brand new, battery mfg 8/15/2012) NUT 2.6.5-3 I have more to report... This UPS is waking my test system from sleep mode. The USB connection is also broken in the process (the device manager entry is still present though), if I restart the driver I just get a no matching HID device error. I have to re-plug the USB connection to fix. The log includes me sleeping the system and forcing the UPS on-battery, causing the system to wake. The system will eventually wake w/o the UPS going on battery too. I've not had this happen with the APC's. I've re-tested a APC ES350 and found that it doesn't wake the system nor breaks the driver, however the driver does sometimes crash! I've attached a log of that happening, it's very easy to reproduce after a couple sleep cycles. The Eaton is going to power an always-on system, so not a big deal for me. 3S550_ES350 sleep.7z Description: Binary data ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Eaton 3S550
Kris Jordan wrote, On 10/10/2012 11:00 PM: Windows 7 Pro x64 Eaton 3S550 (brand new, battery mfg 8/15/2012) NUT 2.6.5-3 I've come across an undocumented feature on this UPS. Holding down the power button when the UPS is off seems to put it into some kind of config mode. If it's a sensitivity adjustment, NUT is not reporting it. I found what it does, it picks from three threshold values: 84-142, 96-138, and 75-144. I believe 84-142 was the default. Installed Personal Solution-Pac, it says 'charging' too. And besides an annoying communication failure warning dialog after waking the system from sleep, it has no problem reestablishing communication after a bit. The UPS will still cause the system to wake though. There is no power management tab in device manager where I could prevent the device from waking the system. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Tripp-Lite INTERNET525U
Charles Lepple wrote, On 10/1/2012 5:01 AM: Kris: Let us know if you want to experiment with the INTERNET525U after your other UPS comes in. Yeah, maybe later. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] For APC Back UPS ES users
Seems to be working as far as reporting data w/o staleness. driver.version: 2.6.5-3691:3709M device.model: Back-UPS ES 725 ups.firmware: 802.n2.D ups.firmware.aux: n2 ups.productid: 0002 ups.vendorid: 051d Kris Jordan wrote, On 9/10/2012 1:30 PM: I didn't have any issues with my old ES 725 and 2.6.4 for Windows (7x64). I better make sure this new driver doesn't cause any issue for its particular firmware. I can't look at it at the moment, but I'll try and check it out today. fredericb...@eaton.com wrote, On 9/10/2012 7:58 AM: With Arnaud Quette's help, I have tried to fix the regression concerning the APC Back UPS ES unit. This regression is related to an issue in this UPS firmware. It cannot be reverted to previous version because the current code fixes communication issue with others UPS (which behave correctly, but are not very permissive). So we (Arnaud and I) have decided to add a tweak (call it a hack if you wish) for this APC UPS. I need your help to test it on real hardware. For UNIX users, you will need to compile NUT from revision 3723. For Windows users, it is here : http://fbohe.free.fr/usbhid-ups.exe For Denis: It is NOT the same binary you have already tested. You should use this one now. Please let us know if this new driver fix your issue. Thanks to all reporter. Regards, Fred ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] For APC Back UPS ES users
Arnaud Quette wrote, On 9/11/2012 1:39 AM: 2012/9/11 Kris Jordan nut...@sagebrushnetworks.com mailto:nut...@sagebrushnetworks.com Seems to be working as far as reporting data w/o staleness. driver.version: 2.6.5-3691:3709M device.model: Back-UPS ES 725 ups.firmware: 802.n2.D ups.firmware.aux: n2 ups.productid: 0002 ups.vendorid: 051d is battery.charge reported on both units now? I'd also be interested in seeing a driver debug trace (-D, during a minute or so) and a complete upsc output, in compressed form please, to counter validate on my side. Both units? battery.charge was always reported on this ES725 (NUT 2.6.4-2.6.5 and the new driver). Do you normally want upsd, upsmon, and upsc ran during the 1min debug trace? Otherwise, here's the logs from the driver ran by itself for 1min. The only difference in the upsc output is the driver version. --- I'd like to thank you guys for the Windows pid and fsd fixes, 2.6.5 has been working great. Thank you! Logs.7z Description: Binary data ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] For APC Back UPS ES users
Arnaud Quette wrote, On 9/11/2012 2:22 PM: 2012/9/11 Kris Jordan nut...@sagebrushnetworks.com mailto:nut...@sagebrushnetworks.com Do you normally want upsd, upsmon, and upsc ran during the 1min debug trace? Otherwise, here's the logs from the driver ran by itself for 1min. only the driver and upsd are required to get the data, so it's fine. you should also do a quick discharge (a couple of minutes) to see battery.charge decreasing well. I'll redo it since I didn't even run upsd. I'd like to thank you guys for the Windows pid and fsd fixes, 2.6.5 has been working great. Thank you! Fred will appreciate a lot, as usual. I'm forcing him to work on the Windows port for ~ 2 years (is a pure Linux fan!) So thanks again Fred for all your excellent work on the Windows port, and making NUT more widely available. I'm eager to see it finally entering the mainstream (we have still a lot of work before). I've pretty much decided to standardize/switch to NUT, many of the systems are running Windows (client/desktop systems). I really like how you can tell the UPS to do stuff (instant commands) without having to shut the program down. Logs-redo.7z Description: Binary data ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] For APC Back UPS ES users
Kris Jordan wrote, On 9/11/2012 7:28 PM: Arnaud Quette wrote, On 9/11/2012 2:22 PM: 2012/9/11 Kris Jordan nut...@sagebrushnetworks.com mailto:nut...@sagebrushnetworks.com Do you normally want upsd, upsmon, and upsc ran during the 1min debug trace? Otherwise, here's the logs from the driver ran by itself for 1min. only the driver and upsd are required to get the data, so it's fine. you should also do a quick discharge (a couple of minutes) to see battery.charge decreasing well. I'll redo it since I didn't even run upsd. Forgot to mention that battery.charge does decrease. I checked both 2.6.5 and the new driver. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] For APC Back UPS ES users
I didn't have any issues with my old ES 725 and 2.6.4 for Windows (7x64). I better make sure this new driver doesn't cause any issue for its particular firmware. I can't look at it at the moment, but I'll try and check it out today. fredericb...@eaton.com wrote, On 9/10/2012 7:58 AM: With Arnaud Quette's help, I have tried to fix the regression concerning the APC Back UPS ES unit. This regression is related to an issue in this UPS firmware. It cannot be reverted to previous version because the current code fixes communication issue with others UPS (which behave correctly, but are not very permissive). So we (Arnaud and I) have decided to add a tweak (call it a hack if you wish) for this APC UPS. I need your help to test it on real hardware. For UNIX users, you will need to compile NUT from revision 3723. For Windows users, it is here : http://fbohe.free.fr/usbhid-ups.exe For Denis: It is NOT the same binary you have already tested. You should use this one now. Please let us know if this new driver fix your issue. Thanks to all reporter. Regards, Fred -- Eaton Opensource Team - http://opensource.eaton.com - - ___ 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] Windows NUT shutdown UPS?
fredericb...@eaton.com wrote, On 7/27/2012 12:15 AM: On Windows 7 x64 (I haven't tested XP), upsdrvctl shutdown doesn't appear to get called during automatic OS shutdown by NUT. I used upsmon -c fsd to test. upsdrvctrl shutdown works if I run it manually. Last time I tested this, upsdrvctl was correclty called at OS shutdown time. Maybe a regression or an issue with Win7. I will a have to investigate. Okay, that's good. That is what I was hoping it would at least do. I'll do some more tests to make sure I don't have something else going on. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Windows NUT shutdown UPS?
Kris Jordan wrote, On 7/27/2012 9:39 AM: fredericb...@eaton.com wrote, On 7/27/2012 12:15 AM: On Windows 7 x64 (I haven't tested XP), upsdrvctl shutdown doesn't appear to get called during automatic OS shutdown by NUT. I used upsmon -c fsd to test. upsdrvctrl shutdown works if I run it manually. Last time I tested this, upsdrvctl was correclty called at OS shutdown time. Maybe a regression or an issue with Win7. I will a have to investigate. Okay, that's good. That is what I was hoping it would at least do. I'll do some more tests to make sure I don't have something else going on. Not working in XP (as a VM) either. I might be doing something wrong. upsdrvctl stop Network UPS Tools - UPS driver controller 2.6.4-3534:3579M Stopping UPS: ups Sending signal to C:\Program Files\NUT\bin\..\var\run/usbhid-ups-ups.pid Stopping C:\Program Files\NUT\bin\..\var\run/usbhid-ups-ups.pid failed: No error [The parameter is incorrect. ] I get the same message on Win7. If I run upsdrvctrl start myself, I can upsdrvctl stop then shutdown without issues. upsmon.pid doesn't get removed after stopping the nut service. upsd.exe.pid does get removed and it has 'exe' in its filename. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Windows NUT shutdown UPS?
fredericb...@eaton.com wrote, On 7/24/2012 12:43 AM: Hello Kris, I was wondering what you guys do about UPS shutdown on Windows systems? Apcupsd has the same issue, so I'm assuming it is the same with NUT. Windows just makes it hard/impossible to do. Can you elaborate on which issue you are talking about please ? Reading that now, I see I didn't make a whole lot of sense, sorry about that. On Windows 7 x64 (I haven't tested XP), upsdrvctl shutdown doesn't appear to get called during automatic OS shutdown by NUT. I used upsmon -c fsd to test. upsdrvctrl shutdown works if I run it manually. I could probably configure an instant command to send shutdown.reboot just before shutting down the OS. My test UPS only provides 1min (non-adjustable) which isn't always enough time for Windows (XP especially), so this hack is not ideal. Do you find draining the batteries down so much cause issues for longevity? Sorry I am not an expert of batteries. This is directed to anyone on the list who might know. I'm deciding if I want to switch to low battery shutdown as NUT seems to prefer that method. I've typically just used a 2min timer for desktops. Also, with the way NUT works on Windows right now, the UPS will drain itself even more because it doesn't shut off. Thanks! ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
[Nut-upsuser] Windows NUT shutdown UPS?
I was wondering what you guys do about UPS shutdown on Windows systems? Apcupsd has the same issue, so I'm assuming it is the same with NUT. Windows just makes it hard/impossible to do. Do you find draining the batteries down so much cause issues for longevity? Regarding my Eaton 5110, I found that automatic driver setup works just fine on Windows XP but not at all on Windows 7 x64 (I don't have any x86, so I can't test that). I have a APC ES 725 plugged into my win7x64 test machine and I had to manually install the driver for it too. So I'm thinking it might be a win7x64 issue. Not a big deal for me though. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] NUT for Windows + Eaton/PW 5110
Frédéric Bohé wrote, On 5/29/2012 12:39 AM: On Mon, 2012-05-28 at 10:21 -0700, Kris Jordan wrote: Frédéric Bohé wrote, On 5/28/2012 2:43 AM: On Sat, 2012-05-26 at 12:27 -0700, Kris Jordan wrote: Kris Jordan wrote, On 5/14/2012 11:14 AM: If I start 'upsc eaton' a couple seconds *before* upsd, it will get the values before it crashes upsd. You mean before upsmon, not upsd ? Or is there another instance of upsd running ? 0. In separate command prompts. 1. I start the driver. 2. I run upsc 3. Wait 2 seconds (some delay is important) 4. I run upsd 5. upsc spits out values 6. upsd crashes If I start upsd before upsc/upsmon like your suppose to, it will crash immediately once they try to connect to it. In upsc's case no values are spitted out before upsd crashes. Try to un-comment the LISTEN 127.0.0.1 3493 line in upsd.conf. That works! On the system (also Win7x64) with the Tripp-lite, it functions fine with the LISTEN line commented-out. I had to install the USB driver manually on that Tripp-lite system too. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Question regarding Tripp-Lite omnismart 1050 and Nut
twhit...@clearbearing.com wrote, On 5/15/2012 8:34 AM: Hey all, I have a omnismart 1050 which i've got working under nut 2.2.2. It starts fine, and seems to poll fine. The only thing that is throwing me for a loop is my UPS is reporting that battery.runtime isn't supported. Will this affect upsmon's ability to shutdown my system in a power outage? I can whip up a simple bash script to take care of it but ideally I'd like to work within the nut framework. I have a Tripp-lite OMNISM1000USB, their own software didn't report a runtime, it simply shut down the PC after a set amount of time (2-5min). It also didn't show load, so a watt meter was needed to determine that. Using the runtime graphs on Tripp-Lite's site, you can verify you have enough time, but you need to be conservative to account for aging batteries. I think NUT can take care of the scheduling (running shutdown after X minutes) based on a powerfail event. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] NUT for Windows + Eaton/PW 5110
Arnaud Quette wrote, On 5/14/2012 5:08 AM:
2012/5/13 Kris Jordannut...@sagebrushnetworks.com:
Looks like the bcmxcp_usb isn't going to get me what I need, but I'm not
sure until I can see the output of upsc.
things that helps to understand Eaton position:
- Eaton is composed of many acquired brands: Powerware, Best, Sola,
Deltec, Phoenixtec, MGE, Fiskars, ...
- the XCP protocol is from Powerware (previously called BCM, for Best
Communication M???, AFAICT)
- the SHUT and USB/HID protocols are from MGE, the division I came with,
- before joining Eaton, I was working for MGE, concentrating my driver
development efforts on MGE protocols (SHUT, USB/HID and SNMP),
- XCP protocol is legacy, even if some units still sold on the market
are using this protocol,
- XCP is being replaced by SHUT (serial) and USB/HID,
- NUT efforts in XCP support are (and will remain) higher than in IPP,
- I've started to work on bcmxcp, but this needs almost a complete rewrite,
- so bcmxcp is far from being as complete as mge-shut or usbhid-ups
for Eaton devices...
Note that it's not a justification, but more an explanation of the
support / features differences between drivers supporting Eaton
hardware.
also note that I have an incomplete patch for bcmxcp that:
- simplify the driver (remove redundancies),
- add beeper.{disable,enable}, bypass.{start,stop}, load.on commands,
- add battery.runtime.low setting,
- checks for available commands and settings (incomplete).
but I won't be able to complete this for 2.6.4, considering the actual
late and the remaining TODO lists (and not only on NUT release) .
Thanks, so I can expect it might start working better in the future. I'm
planning on just holding onto the unit and getting something else for now.
Since I had an easy time getting a USB HID Tripp-Lite working with NUT,
I'll probably be going over to them for now. They have an overwhelming
array of desktop/workstation grade units with USB HID, line-interactive,
even pure sine-wave.
Hopefully I don't end up with a model that beeps loudly during automatic
self-test! I had to physically remove its beeper.
On APC units I can disable the alarm in NVRAM, and it stays off in every
situation I've tested; on battery, no battery, low battery, bad battery.
What is typical for current Eaton units? I just mentioned that I was
able to use lansafe to disable the alarm (permanently checked-off), but
it forgot as soon as I switched the UPS off.
Lansafe, am I right to assume this is legacy software that IPP is replacing?
Thanks!
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
