Re: [Nut-upsuser] APC Smart-UPS 1000
Arjen de Korte de-korte.org> writes: > This looks actually pretty promising. It looks like the UPS sets a > lower limit to the shutdown timer. I would not be surprised if this is > caused by the value that is set in the > "UPS.Output.APCShutdownAfterDelay" HID path, which is currently set at > "90". > > Could you try the attached patch on the nut-2.6.0 sources, compile it > again and run the driver again? If all is well, I expect the > 'ups.delay.shutdown' to be a modifiable value after that. You could > try if setting it to "20" works. If the above is the case, I expect > there might be a mapping for the 'ups.delay.start' and > 'ups.delay.reboot' as well. > > If the variable seems to be modifiable, try to run 'shutdown.return' > again while logging as the above. Here is the output: # ./clients/upscmd -u apcmon -p pass123 apc1500 shutdown.return OK delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:-1 START:-1 delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:-1 START:-1 delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:-1 START:-1 delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:89 START:249 delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:89 START:249 delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:87 START:247 delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:87 START:247 delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:85 START:245 Some seconds later... # ./clients/upsc apc1500 battery.charge: 100 battery.charge.low: 10 battery.charge.warning: 50 battery.mfr.date: 2007/07/07 battery.runtime: 5880 battery.runtime.low: 120 battery.temperature: 32.4 battery.type: PbAc battery.voltage: 27.4 battery.voltage.nominal: 24.0 device.mfr: American Power Conversion device.model: Smart-UPS 1000 device.serial: AS0727233122 device.type: ups driver.name: usbhid-ups driver.parameter.offdelay: 1 driver.parameter.ondelay: 250 driver.parameter.pollfreq: 30 driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.version: 2.6.0 driver.version.data: APC HID 0.95 driver.version.internal: 0.35 input.sensitivity: high input.voltage: 230.4 output.voltage: 230.4 output.voltage.nominal: 230.0 ups.beeper.status: disabled ups.delay.shutdown: 1 ups.delay.start: 250 ups.firmware: 652.13.I ups.firmware.aux: 7.3 ups.load: 5.8 ups.mfr: American Power Conversion ups.mfr.date: 2007/07/07 ups.model: Smart-UPS 1000 ups.productid: 0002 ups.serial: AS0727233122 ups.status: OL ups.test.result: No test initiated ups.timer.reboot: -1 ups.timer.shutdown: 17 ups.timer.start: 177 ups.vendorid: 051d Contents of apc-hid.c: [...] { "ups.timer.reboot", 0, 0, "UPS.Output.DelayBeforeReboot", NULL, "%.0f", HU_FLAG_QUICK_POLL, NULL}, /* used by APC BackUPS ES */ { "ups.delay.start", ST_FLAG_RW | ST_FLAG_STRING, 10, "UPS.APCGeneralCollection.APCDelayBeforeStartup", NULL, DEFAULT_ONDELAY, HU_FLAG_ABSENT, NULL}, { "ups.delay.shutdown", ST_FLAG_RW | ST_FLAG_STRING, 10, "UPS.APCGeneralCollection.APCDelayBeforeShutdown", NULL, DEFAULT_OFFDELAY, HU_FLAG_ABSENT, NULL}, { "ups.timer.start", 0, 0, "UPS.APCGeneralCollection.APCDelayBeforeStartup", NULL, "%.0f", HU_FLAG_QUICK_POLL, NULL}, { "ups.timer.shutdown", 0, 0, "UPS.APCGeneralCollection.APCDelayBeforeShutdown", NULL, "%.0f", HU_FLAG_QUICK_POLL, NULL}, { "ups.timer.reboot", 0, 0, "UPS.APCGeneralCollection.APCDelayBeforeReboot", NULL, "%.0f", HU_FLAG_QUICK_POLL, NULL}, [...] I am not seeing any difference. > > Isn't putting the UPS to sleep the desired behaviour here, so that > > it wakes up again when power returns? > > It should wakeup if the power returns after a power outage. But if the > power happens to return between the moment NUT sees the battery is low > (and initiates the shutdown sequence on the server) and the moment it > sends the shutdown signal to the UPS, it should rather cycle the > outlet to prevent what is known as a power race (see the documentation > for more information). You don't want to see the happening when you're > not around to restart your servers by hand. That's understood, I'd have to do some more testing to try to reproduce this. > > On the CS 500, the shutdown timer is the only one that changes at all. The > > reboot and start timers stay at zero (not -1) all the time. > > I guess this means that the existing mapping might be wrong. I suspect > that it only has 'shutdown.reboot' and that the other mappings allow > setting the delay values. Note that in the CS 500 these are all vendor > specific HID paths. I'll deal with that, after we fully understand the > operation on the Smart-UPS 1000. Ok, and thanks for your efforts. Actually, as I have a working solution on the Smart-UPS 1000, and not on the CS 500, it is the latter that is more critical (as I'm currently on standby all the time for when the power goes down!) Regards, Kevin. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-u
Re: [Nut-upsuser] Building nut 2.6.0 on OpenBSD 4.8 - compile issue
On 1/21/2011 at 8:15 PM Arjen de Korte wrote: |Citeren "Mike." : | |> Trying to build nut 2.6.0 on OpenBSD 4.8, I get a compiler error. | |[...] | |> Making all in drivers |> gmake[1]: Entering directory `/home/downloads/nut/nut-2.6.0/drivers' |> gcc -DHAVE_CONFIG_H -I. -I../include-I../include -DSHUT_MODE |> -g -O2 -Wall -Wsign-compare -MT newmge_shut-usbhid-ups.o -MD -MP -MF |> .deps/newmge_shut-usbhid-ups.Tpo -c -o newmge_shut-usbhid-ups.o `test |> -f 'usbhid-ups.c' || echo './'`usbhid-ups.c |> usbhid-ups.c: In function 'hid_ups_walk': |> usbhid-ups.c:1231: error: 'EPROTO' undeclared (first use in this |> function) |> usbhid-ups.c:1231: error: (Each undeclared identifier is reported only |> once |> usbhid-ups.c:1231: error: for each function it appears in.) |> gmake[1]: *** [newmge_shut-usbhid-ups.o] Error 1 |> gmake[1]: Leaving directory `/home/downloads/nut/nut-2.6.0/drivers' |> gmake: *** [all-recursive] Error 1 | |In the usbhid-ups driver this line is a no-op, so I suggest to comment |it out. Question remains why this happens. Either OpenBSD 4.8 is not |POSIX compliant or we're not including the right headers. Could you |run a grep on your /usr/include directory (or whatever it may be |called in OpenBSD) for EPROTO? = Thanks for the quick reply. On OpenBSD 4.8, the errno.h file resides in /usr/include/sys and contains the various error number defines up to code 91, but no EPROTO. None of the other include files contained EPROTO (according to the grep results). I looked at the same file on my FreeBSD 8.1 box, and errno.h contains the various error number defines up to code 92, which happens to be the code for EPROTO. According to the wikipedia entry, OpenBSD, FreeBSD and the various Linux distributions are "mostly complaint" with POSIX. I guess "mostly complaint" means that certain, and differing, bits are not present, depending upon the particular OS. ( http://en.wikipedia.org/wiki/POSIX#Mostly_POSIX-compliant ) In any case, I commented out the line, as you sugggested and the compile completed cleanly. Thanks. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Cyber Power USB UPS'.
Hi All: Someone may have already answered this, I get the digest. I found this posting in the archives, OF COURSE, after I posted my problem. http://lists.freebsd.org/pipermail/freebsd-questions/2010-August/220187.html I can't say it explains everything to me. I still am interested in ya'lls thoughts. I can't totally say I understand why this is happening. If my limited understanding is correct the USB is dropping out, coming back, and when it comes back init 0 or S90Halt is run. But now the USB is given a new 'address' and the orig binding via the driver is gone. So it seems to me the less kludgy fix would be to assign the port setting in usb.conf to something more akin to reality so this does not occur. I'd rather not muck with the shutdown script as I'll be applying this to about 50 systems as I upgrade their UPS'. Andrew ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Building nut 2.6.0 on OpenBSD 4.8 - compile issue
Citeren "Mike." : Trying to build nut 2.6.0 on OpenBSD 4.8, I get a compiler error. [...] Making all in drivers gmake[1]: Entering directory `/home/downloads/nut/nut-2.6.0/drivers' gcc -DHAVE_CONFIG_H -I. -I../include-I../include -DSHUT_MODE -g -O2 -Wall -Wsign-compare -MT newmge_shut-usbhid-ups.o -MD -MP -MF .deps/newmge_shut-usbhid-ups.Tpo -c -o newmge_shut-usbhid-ups.o `test -f 'usbhid-ups.c' || echo './'`usbhid-ups.c usbhid-ups.c: In function 'hid_ups_walk': usbhid-ups.c:1231: error: 'EPROTO' undeclared (first use in this function) usbhid-ups.c:1231: error: (Each undeclared identifier is reported only once usbhid-ups.c:1231: error: for each function it appears in.) gmake[1]: *** [newmge_shut-usbhid-ups.o] Error 1 gmake[1]: Leaving directory `/home/downloads/nut/nut-2.6.0/drivers' gmake: *** [all-recursive] Error 1 In the usbhid-ups driver this line is a no-op, so I suggest to comment it out. Question remains why this happens. Either OpenBSD 4.8 is not POSIX compliant or we're not including the right headers. Could you run a grep on your /usr/include directory (or whatever it may be called in OpenBSD) for EPROTO? 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/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Cyber Power USB UPS'.
Citeren tubbi...@math.arizona.edu: Debian Server (Lenny) running a Linux 2.6.26-2-686 SMP kernel. NUT version 2.2.2-6.5 (Latest Lenny Stable) [...] Any insights? Upgrade. We no longer support this version of NUT. Since nut-2.2.2 was released, a lot of changes were made to the usbhid-ups driver. Chances are that the problems you're seeing now have been solved already (or not). 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/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Cyber Power USB UPS'.
Greetings: I'm evaluating two replacements for UPS upgrades to my dept. Because the CyberPower OP650 has been retired, we are evaluating the CyberPower600VA and the CyperPower 1000AVRLCD. We will be evaluating others. Initial configuration and communications are established via the usbhid-ups driver, the gambit of tests are all passed with the exception of one. I seem to be failing the power race test. As I understand it the power race test happens when mains is lost, a system and ups shutdown are commanded (I simulate this via the upsmon -c fsd command), but the mains come back online before the UPS cycles power. The result is the server is left in a hang state waiting for the UPS to cycle power. What should happen is the UPS cycles power to restart the server via an open loop timer. This is not happening, the UPS does not re-cycle the power. So my setup... Debian Server (Lenny) running a Linux 2.6.26-2-686 SMP kernel. NUT version 2.2.2-6.5 (Latest Lenny Stable) UPS's under test Cyber Power 1000AVRLCD, Cyber Power 600VA. Our /etc/nut/ups.conf entry looks like this (for the 600VA) [MyUPS] driver = usbhid-ups pollfreq = 5 offdelay=45 ondelay=70 #vendorid=0764 #product=0501 #desc = "UPS CP600" The Test: First I check to make sure I have communications with the UPS, this is useless but hey, with a upsc MyUPS@localhost. I get the full telemetry dump, in this dump I note that my offdelay and ondelay are not being sent to the UPS. The default values are still there. Pull the plug. Within the poll time, I get the system on battery message. Execute a usbmon -c fsd, to force the shutdown command. After the system has announced it is entering shutdown, I replug in the mains. Now the strangeness begins. I get a USB disconnect message for the USB subsystem, immediately followed by a reconnect message with the same USB port vendor id you name it. The system seems to rerun a portion of the shutdown script after the USB restarts the USB connection to the UPS. The final messages. Shutting down the UPS ...:Network UPS Tools - UPS driver controller 2.2.2 Network UPS Tools: 0.29 USB communication driver - core 0.33 (2.2.2) No matching HID UPS found Driver failed to start (exit status=1) Shutdown failed. Waiting for UPS batteries to run down. Will now halt. True to the system messages, the system does indeed wait for a UPS power cycle that never comes. As a sanity check I reconfigure and plug in a Cyber Power OP-1250 and run the same test with no issues. Any insights? Andrew ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
[Nut-upsuser] APC Smart UPS 3000 LCD & Eaton Evolution S 3000
We're looking at supplementing our Belkin Regulator Pro 1400 with a 2nd UPS, and were contemplating the APC's 3kVA Smart UPS LCD. We'd still be using either our existing FreeBSD box or a CentOS box to control the UPS. I was just wondering if anyone's got much experience with using these with NUT. From the NUT compatibility guide, it says it uses the usb-hid driver. It also just dawned upon me to look at Eaton after seeing the compatability list, makes sense if they're sponsoring NUT. Evolution S 3000 appeared apt too. Any users? Many thanks, John ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
[Nut-upsuser] Building nut 2.6.0 on OpenBSD 4.8 - compile issue
Trying to build nut 2.6.0 on OpenBSD 4.8, I get a compiler error. Here's my configure: ./configure --with-user=_ups --with-group=_ups \ --sysconfdir=/etc/ups --with-usb=no ... and the result: -e Configuration summary: == build serial drivers: yes build USB drivers: no build SNMP drivers: no build neon based XML driver: no build Powerman PDU client driver: no enable SSL development code: yes enable libwrap (tcp-wrappers) support: no build CGI programs: no enable HAL support: no build and install documentation: no build and install the development files: no The compile goes well until: Making all in drivers gmake[1]: Entering directory `/home/downloads/nut/nut-2.6.0/drivers' gcc -DHAVE_CONFIG_H -I. -I../include-I../include -DSHUT_MODE -g -O2 -Wall -Wsign-compare -MT newmge_shut-usbhid-ups.o -MD -MP -MF .deps/newmge_shut-usbhid-ups.Tpo -c -o newmge_shut-usbhid-ups.o `test -f 'usbhid-ups.c' || echo './'`usbhid-ups.c usbhid-ups.c: In function 'hid_ups_walk': usbhid-ups.c:1231: error: 'EPROTO' undeclared (first use in this function) usbhid-ups.c:1231: error: (Each undeclared identifier is reported only once usbhid-ups.c:1231: error: for each function it appears in.) gmake[1]: *** [newmge_shut-usbhid-ups.o] Error 1 gmake[1]: Leaving directory `/home/downloads/nut/nut-2.6.0/drivers' gmake: *** [all-recursive] Error 1 Where do I go from here? Thanks. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
[Nut-upsuser] APC Smart-UPS 1000
Citeren Kevin : [apc1500] driver=usbhid-ups port=auto ondelay=200 offdelay=1 Yes. After restarting the driver, and running shutdown.return, the timers are set to 90 and 200. (the values of ups.delay.shutdown and ups.delay.start) REBOOT:-1 SHUT:-1 START:-1 REBOOT:-1 SHUT:-1 START:-1 REBOOT:-1 SHUT:89 START:199 REBOOT:-1 SHUT:89 START:199 REBOOT:-1 SHUT:89 START:199 REBOOT:-1 SHUT:85 START:195 REBOOT:-1 SHUT:85 START:195 REBOOT:-1 SHUT:83 START:193 REBOOT:-1 SHUT:83 START:193 Using values of 250 and 1 gives: delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:-1 START:-1 delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:-1 START:-1 delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:89 START:249 delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:89 START:249 delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:89 START:249 delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:86 START:246 delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:86 START:246 delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:84 START:244 delay.start:250 delay.shutdown:1 REBOOT:-1 SHUT:84 START:244 This looks actually pretty promising. It looks like the UPS sets a lower limit to the shutdown timer. I would not be surprised if this is caused by the value that is set in the "UPS.Output.APCShutdownAfterDelay" HID path, which is currently set at "90". Could you try the attached patch on the nut-2.6.0 sources, compile it again and run the driver again? If all is well, I expect the 'ups.delay.shutdown' to be a modifiable value after that. You could try if setting it to "20" works. If the above is the case, I expect there might be a mapping for the 'ups.delay.start' and 'ups.delay.reboot' as well. If the variable seems to be modifiable, try to run 'shutdown.return' again while logging as the above. [...] Ok, this makes sense now. The Smart-UPS 1000 apparently has some variations on the 'standard'. Well, it is not the only UPS (nor vendor) that has. These so called vendor specific HID paths are allowed by the PDC standard. The problem is that every vendor can choose what to put in them. So you can't refer to a standard to find the meaning of them. This is not a problem if we have full access to the specifications (like Eaton for instance). But if the vendor is not willing to share them with us (like APC for instance), we need to reverse engineer them. The latter is a long, tedious process, which requires lots of help from owners of these devices. [...] Isn't putting the UPS to sleep the desired behaviour here, so that it wakes up again when power returns? It should wakeup if the power returns after a power outage. But if the power happens to return between the moment NUT sees the battery is low (and initiates the shutdown sequence on the server) and the moment it sends the shutdown signal to the UPS, it should rather cycle the outlet to prevent what is known as a power race (see the documentation for more information). You don't want to see the happening when you're not around to restart your servers by hand. [...] On the CS 500, the shutdown timer is the only one that changes at all. The reboot and start timers stay at zero (not -1) all the time. I guess this means that the existing mapping might be wrong. I suspect that it only has 'shutdown.reboot' and that the other mappings allow setting the delay values. Note that in the CS 500 these are all vendor specific HID paths. I'll deal with that, after we fully understand the operation on the Smart-UPS 1000. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) Index: drivers/apc-hid.c === --- drivers/apc-hid.c (revision 2844) +++ drivers/apc-hid.c (working copy) @@ -259,6 +259,7 @@ { "ups.timer.reboot", 0, 0, "UPS.PowerSummary.DelayBeforeReboot", NULL, "%.0f", HU_FLAG_QUICK_POLL, NULL}, /* used by APC SmartUPS RM */ { "ups.delay.start", ST_FLAG_RW | ST_FLAG_STRING, 10, "UPS.Output.DelayBeforeStartup", NULL, DEFAULT_ONDELAY, HU_FLAG_ABSENT, NULL}, + { "ups.delay.shutdown", ST_FLAG_RW | ST_FLAG_STRING, 10, "UPS.Output.APCShutdownAfterDelay", NULL, "%.0f", HU_FLAG_SEMI_STATIC, NULL }, { "ups.delay.shutdown", ST_FLAG_RW | ST_FLAG_STRING, 10, "UPS.Output.DelayBeforeShutdown", NULL, DEFAULT_OFFDELAY, HU_FLAG_ABSENT, NULL}, { "ups.timer.start", 0, 0, "UPS.Output.DelayBeforeStartup", NULL, "%.0f", HU_FLAG_QUICK_POLL, NULL}, { "ups.timer.shutdown", 0, 0, "UPS.Output.DelayBeforeShutdown", NULL, "%.0f", HU_FLAG_QUICK_POLL, NULL}, ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser