[Nut-upsuser] APC Smart-UPS 1000
Citeren Kevin bakd...@gmail.com:
[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
[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 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
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
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] Building nut 2.6.0 on OpenBSD 4.8 - compile issue
Citeren Mike. the.li...@mgm51.com: 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'.
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
On 1/21/2011 at 8:15 PM Arjen de Korte wrote: |Citeren Mike. the.li...@mgm51.com: | | 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] APC Smart-UPS 1000
Arjen de Korte nut+users at 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-upsuser
