Re: [Nut-upsuser] List of connected slaves
On 13/04/2018 07.56, zefanjas wrote: Hi, is there a command to get a list of connected slaves you can run on the nutserver? I want to monitor the slaves and if their are actually connected to server. if there is no such command in NUT, then on my Debian Stretch using the lsof -p command on the upsd proccess on my NUT server reveals TCP connections to the clients. I see 2 connections pr. client, probably because each client monitors 2 UPS's, one for each powersupply. JonB ___ 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 Back-UPS XS 1500G says "No battery"
On 11/05/17 19.51, Jesse Molina wrote: I have a new-ish APC Back-UPS XS 1500G connected via USB. It's giving me a "ups.alarm: No battery installed!" error. I also installed and configured apcupsd to give that a try and it's giving me the same error. I recently also had an strange error with a similar APC ups, but my battery was not 16 years old :-O battery.date: 2001/09/25 battery.mfr.date: 2016/08/13 strange difference in battery dates. battery.runtime: 3345 I wonder if that is days? ups.alarm: No battery installed! I got the same error message. Since my UPS was a decade old I ended up just buying a new. I choose Eaton because NUT+Eaton seems to be so well supported. When my UPS lost power, it would shut off instantly. JonB ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] HP R1500 G2 USB on Ubuntu
On 12/04/17 09.23, m...@electronico.nc wrote: Hello, Control HP R1500 G2 with nut via USB. Ubuntu 14.04.5 LTS (GNU/Linux 4.4.0-72-generic x86_64) nut V2.7.1 installed from repository /etc/nut/ups.conf [HPR1500] driver=usbhid-ups port=auto After dealing hours with this, hope this will help some : rename udev rule to higher priority and move it to its right location, reload udev rules mv /lib/udev/rules.d/52-nut-usbups.rules /lib/udev/rules.d/62-nut-usbups.rules cp /lib/udev/rules.d/62-nut-usbups.rules /etc/udev/rules.d/ udevadm control --reload-rules udevadm trigger reboot server to be sure everything is OK what was the issue before that? [cuuut] ups.serial: 3C80341001 if you put that in the ups.conf definition, would it have made it detect it without the issues above? [HPR1500] driver=usbhid-ups port=auto serial = 3C80341001 JonB ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] battery not installed, but battery still 100% and NUT 2.7.2-4 does not catch this and report a error
On 11/04/17 03.36, Charles Lepple wrote: [cuut] good points. Not sure if this got answered already, but is the "No battery installed" alarm accurate, or is it just an old battery? If old, does the battery.runtime value > get adjusted downwards after a battery test? Either way, we would need to > establish which reading should take priority, and I don't think this is straightforward. I think the battery is installed, but it is a really really old battery. I will try to do a battery test now that it doesn't power anything at all, hopefully a monitor is enough to do the load test. I could also try to open it and see if the battery is connected. JonB ps: in my new UPS Eaton 5SC I could not see a battery manufacture date in the extended tree data from nut-cgi :-/ so I wrote the install date on a sticker and put it on it. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] battery not installed, but battery still 100% and NUT 2.7.2-4 does not catch this and report a error
On 10/04/17 16.39, Jon Bendtsen wrote: On 10/04/17 15.25, Jon Bendtsen wrote: On 04/04/17 15.19, Arnaud Quette wrote: 2017-04-04 14:18 GMT+02:00 Jon Bendtsen <jon.bendt...@jonix.dk <mailto:jon.bendt...@jonix.dk>>: [cut] I'd say your change is a success :-) well, almost, but maybe that is outside NUT's control. /usr/lib/nagios/plugins/check_ups -H dkvideobackup -u apc1500 UPS OK - Status=Online, Unknown Utility=227.5V Batt=100.0% Load=0.0% |voltage=227500mV;;;0 battery=100%;;;0;100 load=0%;;;0;100 Actually maybe it is within NUT's control. Maybe NUT should only claim that a UPS is ONLINE if ONLINE is the only thing it is? JonB ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] battery not installed, but battery still 100% and NUT 2.7.2-4 does not catch this and report a error
On 10/04/17 15.25, Jon Bendtsen wrote: On 04/04/17 15.19, Arnaud Quette wrote: 2017-04-04 14:18 GMT+02:00 Jon Bendtsen <jon.bendt...@jonix.dk <mailto:jon.bendt...@jonix.dk>>: [cut] I'd say your change is a success :-) well, almost, but maybe that is outside NUT's control. /usr/lib/nagios/plugins/check_ups -H dkvideobackup -u apc1500 UPS OK - Status=Online, Unknown Utility=227.5V Batt=100.0% Load=0.0% |voltage=227500mV;;;0 battery=100%;;;0;100 load=0%;;;0;100 JonB ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] battery not installed, but battery still 100% and NUT 2.7.2-4 does not catch this and report a error
On 04/04/17 15.19, Arnaud Quette wrote: 2017-04-04 14:18 GMT+02:00 Jon Bendtsen <jon.bendt...@jonix.dk <mailto:jon.bendt...@jonix.dk>>: [cut] there is a Github issue: https://github.com/networkupstools/nut/issues/415 + a branch with the implementation: https://github.com/networkupstools/nut/tree/upsmon_alarm For now: - upsmon can react on the ALARM notify type, as with other events, and WALL+SYSLOG+EXEC... - I've also fixed the CGI to expose the ALARM flag, which was not done. A possible improvement would be to send the content of ups.alarm, but that requires more thinking and time. And the current implementation already points at this data. @Jon: would you be able to test this branch and ack? (including the "covers (or not) my needs...) I have some trouble installing it, but I succeeded running it from the build directory, see below. [cut] libtool: install: /usr/bin/install -c .libs/libnutclient.so.0.0.0 /usr/local/ups/lib/libnutclient.so.0.0.0 /usr/bin/install: cannot stat '.libs/libnutclient.so.0.0.0': No such file or directory Makefile:580: recipe for target 'install-libLTLIBRARIES' failed make[2]: *** [install-libLTLIBRARIES] Error 1 make[2]: Leaving directory '/usr/local/src/nut/clients' Makefile:1029: recipe for target 'install-am' failed root@dkvideobackup:/usr/local/src/nut# ls -la clients/.libs/ total 2112 drwxr-sr-x 2 root staff 4096 Apr 10 14:32 . drwxr-sr-x 4 root staff 4096 Apr 10 14:55 .. -rw-r--r-- 1 root staff 468820 Apr 10 14:32 libnutclient.a lrwxrwxrwx 1 root staff 18 Apr 10 14:32 libnutclient.la -> ../libnutclient.la -rw-r--r-- 1 root staff984 Apr 10 14:32 libnutclient.lai lrwxrwxrwx 1 root staff 21 Apr 10 14:32 libnutclient.so -> libnutclient.so.0.0.0 lrwxrwxrwx 1 root staff 21 Apr 10 14:32 libnutclient.so.0 -> libnutclient.so.0.0.0 -rw-r--r-- 1 root staff 237182 Apr 10 14:28 libupsclient.a lrwxrwxrwx 1 root staff 18 Apr 10 14:28 libupsclient.la -> ../libupsclient.la -rw-r--r-- 1 root staff984 Apr 10 14:28 libupsclient.lai lrwxrwxrwx 1 root staff 21 Apr 10 14:28 libupsclient.so -> libupsclient.so.4.0.0 lrwxrwxrwx 1 root staff 21 Apr 10 14:28 libupsclient.so.4 -> libupsclient.so.4.0.0 -rwxr-xr-x 1 root staff 158768 Apr 10 14:28 libupsclient.so.4.0.0 -rw-r--r-- 1 root staff 419208 Apr 10 14:32 nutclient.o -rwxr-xr-x 1 root staff 61376 Apr 10 14:32 upsc -rw-r--r-- 1 root staff 62432 Apr 10 14:28 upsclient.o -rwxr-xr-x 1 root staff 63968 Apr 10 14:32 upscmd -rwxr-xr-x 1 root staff 106680 Apr 10 14:32 upsimage.cgi -rwxr-xr-x 1 root staff 75760 Apr 10 14:32 upslog -rwxr-xr-x 1 root staff 137408 Apr 10 14:32 upsmon -rwxr-xr-x 1 root staff 91392 Apr 10 14:32 upsrw -rwxr-xr-x 1 root staff 113208 Apr 10 14:32 upsset.cgi -rwxr-xr-x 1 root staff 124888 Apr 10 14:32 upsstats.cgi So I ran it from the build directory, and here is the WALL I get Broadcast message from jonbendtsen@dkvideobackup (somewhere) (Mon Apr 10 15:07: Communications with UPS apc1500@localhost established Broadcast message from jonbendtsen@dkvideobackup (somewhere) (Mon Apr 10 15:07: UPS apc1500@localhost has one or more alarms (check ups.alarm) got CGI scripts up and running, and the status field is indeed now red and says: ALARM ONLINE Network UPS Tools upsstats 2.7.4-367-gf7de20a Mon Apr 10 15:19:22 CEST 2017 System Model Status Battery Input (VAC) Output (VAC)Load (%)UPS TempBattery Runtime Data Tree old broken ups Smart-UPS 1500 ALARM ONLINE 100 % 230.4 230.4 0.0 % 32.4 °C 02:05:00All data the tree data looks the same old ups.alarm : No battery installed! ups.status : ALARM OL battery.charge : 100 I'd say your change is a success :-) JonB ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] battery not installed, but battery still 100% and NUT 2.7.2-4 does not catch this and report a error
On 04/04/17 15.19, Arnaud Quette wrote: [cuuut] there is a Github issue: https://github.com/networkupstools/nut/issues/415 + a branch with the implementation: https://github.com/networkupstools/nut/tree/upsmon_alarm For now: - upsmon can react on the ALARM notify type, as with other events, and WALL+SYSLOG+EXEC... - I've also fixed the CGI to expose the ALARM flag, which was not done. A possible improvement would be to send the content of ups.alarm, but that requires more thinking and time. And the current implementation already points at this data. @Jon: would you be able to test this branch and ack? (including the "covers (or not) my needs...) yeah, I can do that, but I'd prefer to wait a few days and test with a machine that does nothing else and with NUT software that my main servers does not rely on. I've just ordered a new Eaton 5SC 1500i as a replacement because it is listed as very well supported. Once it gets here I'll get the broken UPS free and I'll install the NUT software on a test machine. JonB ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] battery not installed, but battery still 100% and NUT 2.7.2-4 does not catch this and report a error
On 04/04/17 14.10, Roger Price wrote: On Tue, 4 Apr 2017, Arnaud Quette wrote: [cut] Hi Arnaud, It seems to me that, looking out into the future, there are three things upsmon needs: 1. A fall-through of "UNKNOWN" so that all status changes, no matter how wierd, can be caught. Such a catch-all would also have caught the "ALARM" from the old battery. 2. A UPS specific option in the NOTIFYFLAG and NOTIFYMSG declarations as already provided by the AT declaration in upssched.conf. This would make it possible to have messages and action specific to a UPS, in a multi-UPS configuration. I would like to be able to specify NOTIFYMSG myups@localhost ONBATT "%s: local UPS on battery" NOTIFYMSG bigups@serverONBATT "%s: Server room alert: UPS on battery" NOTIFYFLAG myups@localhost ONBATT SYSLOG+EXEC+WALL NOTIFYFLAG heartbeat@localhost ONBATT SYSLOG+EXEC 3. A "ALARM" as you propose. good ideas JonB ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] battery not installed, but battery still 100% and NUT 2.7.2-4 does not catch this and report a error
On 03/04/17 22.11, Gene Heskett wrote: On Monday 03 April 2017 14:13:08 Stuart D. Gathman wrote: Back on the mailing list, where such belongs. [cuuut] We want the ALARM that the nut driver is generating, and upsd is passing on - to be acted on in some way by upsmon. Which NOTIFYCMD is run when there is an ALARM? [cuuut] I dont think any NOTIFYCMD is run when there is an ALARM Stuart. I've not read the docs in ages, but if there isn't something mentioned in a man upsmon, I would be unpleasantly surprised. According to my copy, it does a -wall (warn all) by default, and it looks like REPLBATT is one such message, and the default time for a repeat is 12 hours. The -wall type message shows on every open terminal on the system's network, so someone should see it. From the upsmon.conf file: [ct] Possible values for type: ONLINE UPS is back online ONBATT UPS is on battery LOWBATT UPS is on battery and has a low battery (is critical) FSD UPS is being shutdown by the master (FSD = "Forced Shutdown") COMMOK Communications established with the UPS COMMBAD Communications lost to the UPS SHUTDOWN The system is being shutdown REPLBATT The UPS battery is bad and needs to be replaced NOCOMM A UPS is unavailable (can’t be contacted for monitoring) ALARM is not mentioned, so I suppose NUT only reacts to the Online message it gets? JonB ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] battery not installed, but battery still 100% and NUT 2.7.2-4 does not catch this and report a error
On 03/04/17 18.05, Tim Dawson wrote: NUT can only report what the UPS tells it. IE, if no battery/load test is runs on the UPS, it has no way to know the battery croaked . . . it just sees normal voltage, and says "100% charge" . . . . yeah, but the UPS does also tell NUT: root@dkfitlet:/etc/nut# upslog -s apc1500 -l - Network UPS Tools upslog 2.7.2 logging status of apc1500 to - (30s intervals) Init SSL without certificate database 20170403 154055 100 230.4 21.4 [ALARM OL] NA NA 20170403 154125 100 230.4 20.8 [ALARM OL] NA NA 20170403 154155 100 230.4 21.4 [ALARM OL] NA NA root@dkfitlet:/etc/nut# upsmon -DDD Network UPS Tools upsmon 2.7.2 kill: No such process 0.00UPS: apc1500@localhost (monitoring only) 0.000214UPS: Smart-UPS_3000@localhost (monitoring only) 0.000328UPS: R3000XR@localhost (monitoring only) 0.001278Using power down flag file /etc/killpower 0.002126debug level is '3' 0.005831Init SSL without certificate database 0.011754Trying to connect to UPS [apc1500@localhost] 0.013150Can not connect to localhost in SSL, continue uncrypted 0.013909Logged into UPS apc1500@localhost 0.014384pollups: apc1500@localhost 0.014501get_var: apc1500@localhost / status 0.014889parse_status: [ALARM OL] 0.015012parsing: [ALARM] 0.015100parsing: [OL] 0.015181ups_on_line: apc1500@localhost (first time) however, I have to go into debug level 2 to see that. root@dkfitlet:/home/jonbendtsen# upsmon -DD Network UPS Tools upsmon 2.7.2 kill: No such process 0.00 UPS: apc1500@localhost (monitoring only) 0.000166 UPS: Smart-UPS_3000@localhost (monitoring only) 0.000257 UPS: R3000XR@localhost (monitoring only) 0.000884 Using power down flag file /etc/killpower 0.001629 debug level is '2' 0.005681 Init SSL without certificate database 0.011154 Trying to connect to UPS [apc1500@localhost] 0.013431 Logged into UPS apc1500@localhost 0.013955 pollups: apc1500@localhost 0.014318 parse_status: [ALARM OL] level 1 is not enough to see the ALARM in the output ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] battery not installed, but battery still 100% and NUT 2.7.2-4 does not catch this and report a error
On 03/04/17 17.24, Roger Price wrote: On Mon, 3 Apr 2017, Jon Bendtsen wrote: On 03/04/17 17.10, Roger Price wrote: On Mon, 3 Apr 2017, Jon Bendtsen wrote: Power seem to be lost immediately. But my APC Smart-UPS 1500 always reported everything OK. battery.charge : 100 ... battery.mfr.date : 2005/08/26 Hi, Could you confirm that the battery is nearly 12 years old? Roger yeah, it most likely is that old That's probably the cause of the immediate power loss. A new battery should fix the problem. Roger yeah a new battery will most likely make it go away. However, that is not why I wrote the email. I wrote the email because I want NUT to tell me much more clearly that something is wrong, and NUT currently does not do that. JonB ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
[Nut-upsuser] battery not installed, but battery still 100% and NUT 2.7.2-4 does not catch this and report a error
Hi debian jessie, nut 2.7.2-4 APC Smart-UPS 1500 connected through USB, running nut driver usbhid-ups This UPS powers my switches, internet connection and my monitor server that monitors this and my other UPSes + runs smokeping and nagios. But recently a powerloss seemed to have shutdown my monitor PC immediately, so it did not shut down the other servers cleanly. Power seem to be lost immediately. But my APC Smart-UPS 1500 always reported everything OK. output from CGI scripts APC Smart-UPS 1500 - powers switches and routers in little rack +++ also this server dkfitlet Smart-UPS 1500 ONLINE 100 % 227.5 227.5 20.8 % 39.6 °C 00:17:00All data UPS Model: Smart-UPS 1500 Status: ONLINE Runtime:00:17:00 Battery:27.1 V Input: 226.0 V Output: 226.0 V 0.94 A 50.0 Hz when I go into treemode though, I see something interesting APC Smart-UPS 1500 - powers switches and routers in little rack +++ also this server dkfitlet battery.charge : 100 battery.charge.low : 10 battery.charge.warning : 50 battery.mfr.date: 2005/08/26 battery.runtime : 1020 battery.runtime.low : 120 battery.temperature : 39.6 battery.type: PbAc battery.voltage : 27.1 battery.voltage.nominal : 24.0 device.mfr : American Power Conversion device.model: Smart-UPS 1500 device.serial : AS0535132782 device.type : ups driver.name : usbhid-ups driver.parameter.pollfreq : 30 driver.parameter.pollinterval : 2 driver.parameter.port : auto driver.parameter.serial : AS0535132782 driver.version : 2.7.2 driver.version.data : APC HID 0.95 driver.version.internal : 0.38 input.sensitivity : high input.transfer.high : 253 input.transfer.low : 208 input.voltage : 226.0 output.current : 0.94 output.frequency: 50.0 output.voltage : 226.0 output.voltage.nominal : 230.0 ups.alarm : No battery installed! ups.beeper.status : enabled ups.delay.shutdown : 20 ups.delay.start : 30 ups.firmware: 653.12.I ups.firmware.aux: 4.2 ups.load: 20.8 ups.mfr : American Power Conversion ups.mfr.date: 2005/08/26 ups.model : Smart-UPS 1500 ups.productid : 0002 ups.serial : AS0535132782 ups.status : ALARM OL ups.test.result : No test initiated ups.timer.reboot: -1 ups.timer.shutdown : -1 ups.timer.start : -1 ups.vendorid: 051d what? no battery installed, and the status is ALARM? how come NUT doesnt report this? root@dkfitlet:/etc/nut# upslog -s apc1500 -l - Network UPS Tools upslog 2.7.2 logging status of apc1500 to - (30s intervals) Init SSL without certificate database 20170403 154055 100 230.4 21.4 [ALARM OL] NA NA 20170403 154125 100 230.4 20.8 [ALARM OL] NA NA 20170403 154155 100 230.4 21.4 [ALARM OL] NA NA root@dkfitlet:/etc/nut# upsmon -DDD Network UPS Tools upsmon 2.7.2 kill: No such process 0.00 UPS: apc1500@localhost (monitoring only) 0.000214 UPS: Smart-UPS_3000@localhost (monitoring only) 0.000328 UPS: R3000XR@localhost (monitoring only) 0.001278 Using power down flag file /etc/killpower 0.002126 debug level is '3' 0.005831 Init SSL without certificate database 0.011754 Trying to connect to UPS [apc1500@localhost] 0.013150 Can not connect to localhost in SSL, continue uncrypted 0.013909 Logged into UPS apc1500@localhost 0.014384 pollups: apc1500@localhost 0.014501 get_var: apc1500@localhost / status 0.014889 parse_status: [ALARM OL] 0.015012 parsing: [ALARM] 0.015100 parsing: [OL] 0.015181 ups_on_line: apc1500@localhost (first time) notice the value of parsing, first it is ALARM, and then OL. But if only the last value is returned, then everything seems okay and NUT never reports the issue? for my other UPS'es it looks like this, only ever having OL as value. 0.015265 Trying to connect to UPS [Smart-UPS_3000@localhost] 0.016294 Can not connect to localhost in SSL, continue uncrypted 0.017190 Logged into UPS Smart-UPS_3000@localhost 0.017673 pollups: Smart-UPS_3000@localhost 0.017779 get_var: Smart-UPS_3000@localhost / status 0.018083 parse_status: [OL] 0.018178 parsing: [OL] 0.018261 ups_on_line: Smart-UPS_3000@localhost (first time) 0.018344 Trying to connect to UPS [R3000XR@localhost] 0.019224 Can not connect to localhost in SSL, continue uncrypted 0.020028 Logged into UPS R3000XR@localhost 0.020600 pollups: R3000XR@localhost 0.020704
Re: [Nut-upsuser] NUT 2.6.1+ Windows 2008 R2 - NOTIFYCMD not being called
On 02/09/2011, at 12.09, Ian Wells wrote: Hi All, I’m using a recent post 2.6.1 build provided by Fred (executables have modified date of 9th August) [ct] When a notify event occurs, such as when I pull the plug on the UPS, the appropriate message _is_ logged in the event logs, but the batch file is _not_ being called. Do I need to dosomething more to enable this? Does it have execute permissions ? JonB ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] OT: gadget to display time remaining
On 28/11/2010, at 03.36, James wrote: On 11/22/10 05:42, Jon Bendtsen wrote: On 22/11/2010, at 02.26, James wrote: I have two UPSs, one is not connected to a computer. I am looking for a gadget that I can plug in to the other one so I can see the time remaining without a computer. That would be network UPS tools, get it from http://www.networkupstools.org/ ;-) Oh, and be sure to get the right UPS, because not all UPSes show the information. I have a guru plug server plus connected to the Microdowell BP500 UPS in the attachment, the UPS showing no Battery runtime. The other UPS is a APC Smart-UPS 1500 and in my old debian sta(b)le installation running Network UPS Tools upsstats 2.0.4 there was no information about battery runtime, but see the attachment. JonB Without a computer. :-) The guru plug is almost not a computer, but rather an appliance. Some UPSes has a network port to tell this information, but basically it is just a build in computer. Personally I dream of this standard: Primary goals: UPS(s) and Server(s) automatically talk together with no need for configuration using just 1 cable, the power cable, without the need for new special power cables UPS(s) can start Server(s) in some (on server) configurable order such that the upstart do not pull too much power Server(s) with X power supplies connected to Y different UPS(s) will automatically know the state of all UPS(s) using just the power cable without spilling information over from one failed UPS connected to 1 or more power supplies to all the other UPS(s) connected to another power supply in the same server. Secondary goals: Server(s) can tell the UPS how much load they would likely draw as a maximum UPS(s) can stop powering on servers if the load is too high Server(s) can refuse to start if the UPS(s) load is too high Technical implementation idea: ethernet over power cables - http://en.wikipedia.org/wiki/Homeplug 8 bit 0-255 levels you can assign on each server in the bios or similar 0 means start as soon as there is power, regardless of what the UPS(s) say 1 means start once the UPS(s) send out level 1 start now ... once the UPS sends out level 255 start now any level servers on a level below 255 may start now (yet unknown what happens when server connected to 2 UPSs receives different level information) (yet unknown if each power supply should have its own level, or it is for the entire server) Servers when plugged in may send out their level and ask level Y, permission to start? UPS(s) should answer (yet unknown what happens when 2 or more UPSs answer differently) Servers should always honor when an human presses the power On button. UPS(s) should regularly broadcast their state and existence over the network such that servers can get information from that. Server(s) should listen for broadcasts and note when the UPS(s) stop giving out information on a regularly interval All information in the network should optionally be cryptographically signed to be able to trust the source. JonB ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] OT: gadget to display time remaining
On 30/11/2010, at 14.27, Douglas Parsons wrote: Primary goals: UPS(s) and Server(s) automatically talk together with no need for configuration using just 1 cable, the power cable, without the need for new special power cables Don't forget not all UPS have computers connected to them but still need to be monitored for state and condition. Point taken, I'll think about a solution. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] OT: gadget to display time remaining
On 30/11/2010, at 14.57, Charles Lepple wrote: On Nov 30, 2010, at 8:27 AM, Douglas Parsons wrote: Primary goals: UPS(s) and Server(s) automatically talk together with no need for configuration using just 1 cable, the power cable, without the need for new special power cables Don't forget not all UPS have computers connected to them but still need to be monitored for state and condition. Doug: it sounds like you and Jon B are trying to solve different problems. I am not sure so sure. I think that Doug reminded me that I might have a switch/router UPS with no servers on it, and how am I supposed to monitor that then using my idea? Quick fixes I can think of is retain old usb/serial monitor system put a homeplug on it with the network cable plugged into a server and run some software on that server to monitor it. Arjen mentioned something similar before: if you want to see the status of a single UPS without involving a computer, there are UPSes with displays on the front. For instance: http://www.newegg.com/Product/Product.aspx?Item=N82E16842102070 (disclaimer: haven't tried this product.) Jon: if you want plug-and-play without a separate data cable, that is a different set of design criteria from James' original post. Powerline networking hasn't really caught on in mainstream computing, but HomePlug might be a good starting point. I know it is a different set. I know powerline networking has not caught on, but I think that is only because there was no need. I do take it exactly as a starting point, and I used that to avoid redesigning a new protocol and hardware. JonB ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
[Nut-upsuser] howto handle USB serial port keeps changing
Hi I have a serial UPS connected using a serial2USB device. Usually it is port=/dev/ttyUSB0, but occasionally i need port=/dev/ttyUSB1. How do you guys handle something like this? JonB ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] howto handle USB serial port keeps changing
On 24/11/2010, at 13.57, Charles Lepple wrote: On Nov 24, 2010, at 7:27 AM, James Harper wrote: Hi I have a serial UPS connected using a serial2USB device. Usually it is port=/dev/ttyUSB0, but occasionally i need port=/dev/ttyUSB1. How do you guys handle something like this? Could some udev persistent device naming rules help with this? I've done that with usb harddisks before but not serial ports. The udev rules need something unique to latch on to, so hopefully the serial-to-USB device has a USB serial number, or is a different model or brand than the other converters that you use. I have 2, one has a serial number, the other does not. And the other is a dual serial port thing. Thanks for the advice. JonB ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] OT: gadget to display time remaining
On 22/11/2010, at 02.26, James wrote: I have two UPSs, one is not connected to a computer. I am looking for a gadget that I can plug in to the other one so I can see the time remaining without a computer. That would be network UPS tools, get it from http://www.networkupstools.org/ ;-) Oh, and be sure to get the right UPS, because not all UPSes show the information. I have a guru plug server plus connected to the Microdowell BP500 UPS in the attachment, the UPS showing no Battery runtime. The other UPS is a APC Smart-UPS 1500 and in my old debian sta(b)le installation running Network UPS Tools upsstats 2.0.4 there was no information about battery runtime, but see the attachment. JonB Title: Network UPS Tools upsstats 2.4.3 : UPS Status Network UPS Tools upsstats 2.4.3 Mon Nov 22 11:37:55 CET 2010 System Model Status Battery Input (VAC) Output (VAC) Load (%) UPSTemp BatteryRuntime DataTree Microdowell BP 500VA - powers only dkplugbab9 500VA ONLINE 100 % 234.0 234.0 0 % 34 °C All data APC Smart-UPS 1500 - powers switches and routers in little rack Smart-UPS 1500 ONLINE 100 % 231.8 231.8 26.0 % 33.3 °C 00:43:00 All data ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] NUT 2.4.3 on new server can not see serial number, but old nut on different hardware can?
On 13/11/2010, at 01.19, Charles Lepple wrote:
On Nov 12, 2010, at 11:16 AM, Jon Bendtsen wrote:
dkplugbab9:/usr/local/ups/etc# /usr/local/ups/bin/usbhid-ups -a apc1500 -u
nut -DD
Network UPS Tools - Generic HID driver 0.34 (2.4.3)
USB communication driver 0.31
0.00debug level is '2'
0.002738upsdrv_initups...
0.005059Checking device (051D/0002) (001/011)
0.005304- VendorID: 051d
0.005351- ProductID: 0002
0.005383- Manufacturer: unknown
0.005420- Product: unknown
0.005451- Serial Number: unknown
0.005486- Bus: 001
0.005516Trying to match device
0.005630Device does not match - skipping
Arjen has a point about a lot of things changing at once, but one thing that
can cause these items to show up as unknown is that the nut user doesn't
have write access to the device.
SPOT on. It is not group nut.
I know it is a lot of things changed, but I can not change anything less,
expect maybe installing the debian nut package.
In order to fetch a string from a USB device (such as the serial number), you
need to be able to write a control message to it.
On the old system, the Debian packaging would have interacted with udev to
set this up. Chances are that you just need to find the right place to drop
the scripts/udev/nut-usbups.rules file, and tell udev to rescan the bus.
On both the old and the new machine there is this file:
/etc/udev/rules.d/52-nut-usbups.rules
Both files start with
ACTION!=add, GOTO=nut-usbups_rules_end
SUBSYSTEM==usb_device, GOTO=nut-usbups_rules_real
SUBSYSTEM==usb, GOTO=nut-usbups_rules_real
BUS!=usb, GOTO=nut-usbups_rules_end
And both have
# APC
# various models - usbhid-ups
ATTR{idVendor}==051d, ATTR{idProduct}==0002, MODE=664,
GROUP=nut
And ends with
LABEL=nut-usbups_rules_end
I just tried restarting udev
/etc/init.d/udev stop
/etc/init.d/udev start
But the file
dkplugbab9:/etc/udev# ls -la /dev/bus/usb/001/
total 0
drwxr-xr-x 2 root root 160 2010-11-12 17:14 .
drwxr-xr-x 3 root root 60 2010-11-12 17:14 ..
crw-rw-r-- 1 root root 189, 0 2010-11-12 17:14 001
crw-rw-r-- 1 root root 189, 1 2010-11-12 17:14 002
crw-rw-r-- 1 root root 189, 2 2010-11-12 17:14 003
crw-rw-r-- 1 root root 189, 3 2010-11-12 17:14 004
crw-rw-r-- 1 root root 189, 4 2010-11-12 17:14 005
crw-rw-r-- 1 root root 189, 5 2010-11-12 17:14 006
still do not change the group, but
udevadm info --name=/dev/bus/usb/001/006 --attribute-walk | less
shows me the serial number. But it shows it differently, it says:
ATTRS{idVendor}==051d
ATTRS{idProduct}==0002
ATTRS{bcdDevice}==0006
ATTRS{bDeviceClass}==00
ATTRS{bDeviceSubClass}==00
ATTRS{bDeviceProtocol}==00
ATTRS{bNumConfigurations}==1
ATTRS{bMaxPacketSize0}==8
ATTRS{speed}==1.5
ATTRS{busnum}==1
ATTRS{devnum}==6
ATTRS{version}== 1.10
ATTRS{maxchild}==0
ATTRS{quirks}==0x0
ATTRS{authorized}==1
ATTRS{manufacturer}==American Power Conversion
ATTRS{product}==Smart-UPS 1500 FW:653.12.I USB FW:4.2
ATTRS{serial}==AS0535132782
Notice how the /etc/udev/rules.d/52-nut-usbups.rules uses ATTR where udev uses
ATTRS. If add a ATTRS line to /etc/udev/rules.d/52-nut-usbups.rules then
everything works fine
crw-rw-r-- 1 root nut 189, 5 2010-11-12 17:14 006
So now I am only left pondering what is up with the ATTR and ATTRS difference?
JonB
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] NUT 2.4.3 on new server can not see serial number, but old nut on different hardware can?
On 12/11/2010, at 18.45, Arjen de Korte wrote: Citeren Jon Bendtsen jbendt...@laerdal.dk: NUT 2.4.3 on new server can not see serial number, but old nut on different hardware can? For the same UPS? It is not clear to me what the problem is. Are you attempting to monitor two devices from the same system, or are these connected to different systems? the same UPS. I only run the monitor software on a new computer and no i do not connect the UPS to 2 monitors. Note that in your setup there are too many variables. Not only NUT versions are different, but also the kernel versions (and libusb versions). Diagnosing problems with that many changes is challenging. Try to limit the variables... i know, i can not do much different. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] NUT 2.4.3 on new server can not see serial number, but old nut on different hardware can?
On 15/11/2010, at 13.11, Charles Lepple wrote:
On Nov 15, 2010, at 6:59 AM, Jon Bendtsen wrote:
So now I am only left pondering what is up with the ATTR and ATTRS
difference?
Ah, Gene Heskett just ran across this last night.
What does udevadm --version return?
We will need to figure out when they introduced that change.
On both the new and the old machine i get 125 as the version.
Looking closer in the old debian 52_nut-usbups.rules
SYSFS{idVendor}==051d, SYSFS{idProduct}==0002, MODE=664,
GROUP=nut
And then in the new 52_nut-usbups.rules file
ATTR{idVendor}==051d, ATTR{idProduct}==0002, MODE=664, GROUP=nut
And my change
ATTRS{idVendor}==051d, ATTRS{idProduct}==0002, MODE=664,
GROUP=nut
When i try with the SYSFS line on the new server that too works perfectly.
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
[Nut-upsuser] For Arjens regression testing archive of report descriptors. ( was Re: Setting offdelay and ondelay in Smart-UPS 1500 RM units )
On 12/11/2010, at 13.52, Arjen de Korte wrote:
Citeren Jon Bendtsen jbendt...@laerdal.dk:
Please run the following command
/path/to/usbhid-ups -DDD -a upsname Smart-UPS1500RM.log 21
Are you interested in the same output from APC Smart-UPS RM 3000VA ?
dkserver:/etc/nut# udevadm info --name=/dev/bus/usb/001/004
--attribute-walk | grep -i product
ATTRS{product}==Smart-UPS 3000 RM FW:666.6.I USB FW:7.4
dkserver:/etc/nut# udevadm info --name=/dev/bus/usb/001/003
--attribute-walk | grep -i product
ATTR{product}==Smart-UPS 1500 FW:653.12.I USB FW:4.2
And maybe also from my 1500 which is not RM?
Yes and yes. For regression testing I keep an archive of report descriptors.
This allows me to parse them again at any time. It is also helpful to see
which of the listed reports is actually used, so we always ask for about half
a minute worth of output (which should give us a rough idea about the use of
the interrupt pipe). Thanks in advance.
Allright, here is the output from all my UPS'ses.
Both APC_Smart-UPS1500.log Microdowell_BP500.log are created using nut 2.4.3
GE Digital Energy Match UPS 1500 is made using Debian Squeeze NUT package
2.4.3-1.1
I also have a Microdowell 3000VA UPS but I dare not put it online since it
sometimes trips our residual current device to turn off :-(
Both APC Smart-UPS 3000 RM and HP R3000 XR UPS are created using Debian Lenny
nut package 2.2.2-6.5. Are those still useful?
JonB
GE Digital Energy Match Ups 1500.log.gz
Description: GNU Zip compressed data
HP_R3000XR.log.gz
Description: GNU Zip compressed data
APC_Smart-UPS_3000RM.log.gz
Description: GNU Zip compressed data
Microdowell_BP500.log.gz
Description: GNU Zip compressed data
APC_Smart-UPS1500.log.gz
Description: GNU Zip compressed data
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] how normal is this temporary power loss for a single UPS?
On 15/11/2010, at 18.17, Gene Heskett wrote: On Monday, November 15, 2010 12:14:18 pm Jon Bendtsen did opine: Hi Occasionally I get emails from my NUT system saying that one of my UPSes lost power for about a minute. Losing power: Date: 15. nov 2010 17.40.25 CET regaining power: Date: 15. nov 2010 17.41.34 CET 69 seconds later. But why? None of the 3 other UPSes reports any power loss. What is the problem? So I made some scripts that logs the input, output and frequency at the time of power loss, but they show nothing strange. Today results was: input228.9 V output 228.9 V Today the UPS was a APC Smart-UPS 3000 RM, but I have seen it with other UPSes as well. How normal is my experiences? Pretty normal if there are any Prolific usb parts in the path. Although 69 seconds is a much longer time frame than I have encountered. If you are using a ser-usb adaptor, I have found the FTDI parts considerably more dependable in that regard. YMMV or course. This one is connected using USB directly. One other UPS is on that server using a usb2serial device. JonB ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Setting offdelay and ondelay in Smart-UPS 1500 RM units
On 11/11/2010, at 19.57, Arjen de Korte wrote:
Citeren Javier Miqueleiz jav...@miqueleiz.com:
This unit uses a different HID path than the stardard one for sending a
load.on.delay command. As the driver (usbhid-ups) can't find this command,
it has to revert to rebooting the UPS. The HID paths involved are:
- UPS.PowerSummary.DelayBeforeStartup: the standard command for triggering
a load.on.delay in USB units.
- UPS.Output.DelayBeforeStartup: used in this unit for triggering a
load.on.delay. The former doesn't exist.
Please run the following command
/path/to/usbhid-ups -DDD -a upsname Smart-UPS1500RM.log 21
Are you interested in the same output from APC Smart-UPS RM 3000VA ?
dkserver:/etc/nut# udevadm info --name=/dev/bus/usb/001/004 --attribute-walk |
grep -i product
ATTRS{product}==Smart-UPS 3000 RM FW:666.6.I USB FW:7.4
dkserver:/etc/nut# udevadm info --name=/dev/bus/usb/001/003 --attribute-walk |
grep -i product
ATTR{product}==Smart-UPS 1500 FW:653.12.I USB FW:4.2
And maybe also from my 1500 which is not RM?
JonB
___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] HP R3000XR charge level
On 10/09/2010, at 19.37, Brother Railgun of Reason wrote: On Fri, Sep 10, 2010 at 11:16:30AM +0200, Jon Bendtsen wrote: My HP R3000XR is also acting funny. When the power fails i get BATTERY LOW after only a few seconds. My current load is 60% and my battery rarely reaches 100%, it has been at 98,7 for a long time. How old is your battery pack? It has always done this. I dont know how old it is, since head office supplied it to me. JonB ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] HP R1500 G2 UPS
On 18/02/2010, at 11.34, Schupfer Stephan wrote: Hi, I have a HP R1500 G2 UPS and want to get it working under Debian Lenny – as this OS is not supported by HP I’m trying to use nut for it – but I can’t get it working. Do I have any chance to get the UPS running with nut. I also tried different drivers but had no luck either. Or does anyone has experience with HP UPS under debian ? I have a R3000XR, and i use bcmxcp using a seriel port out, since i can not find a USB port on the UPS. I do have a USB2serial on the host. I still experience that NUT upsstats.cgi says the UPS battery is at 97%, and some days later at 100%. It happens regularly. JonB ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Accurate battery reports? (HP R3000 XR)
Hi NUT cgi started to report the battery at 100% without i remember doing anything. JonB On 13/07/2009, at 12.43, Jon Bendtsen wrote: Hi I have a HP R3000 XR UPS which NUT never says is at 100% battery. It seems stuck in 98 or 99 . something percentage. How accurate should i expect the reports to be? All my other UPSes has been and is at 100%, even those i have retired. My monitor system runs debian. The host that is physically connected to this ups runs: nut 2.2.2-6.4 The web script runs nut-cgi 2.0.4-4 JonB ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
[Nut-upsuser] Accurate battery reports? (HP R3000 XR)
Hi I have a HP R3000 XR UPS which NUT never says is at 100% battery. It seems stuck in 98 or 99 . something percentage. How accurate should i expect the reports to be? All my other UPSes has been and is at 100%, even those i have retired. My monitor system runs debian. The host that is physically connected to this ups runs: nut 2.2.2-6.4 The web script runs nut-cgi 2.0.4-4 JonB ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Accurate battery reports? (HP R3000 XR)
On 13/07/2009, at 14.06, Kjell Claesson wrote: Hi Hi Jon, I have a HP R3000 XR UPS which NUT never says is at 100% battery. It seems stuck in 98 or 99 . something percentage. How accurate should i expect the reports to be? All my other UPSes has been and is at 100%, even those i have retired. This is something I have noticed during testing of the driver. My PW5115 is only going up to 90% and the PW5125 is at 98%. This is reported from the ups and i am not sure how this is measured. But in the config of the ups you have possibility to set the 'Max Battery Equalize Voltage' this is the highest voltage the battery get charged to. Protocol and info is now public at http://www.networkupstools.org/protocols/eaton/ The problem is at the moment the driver does not support setting this parameter. I hold back on this as it may damage the ups if it is not done in the right way. But you may hook up the settings program from powerware (Eaton) to make adjustments. is bcmxcp a eaton driver? My monitor system runs debian. The host that is physically connected to this ups runs: nut 2.2.2-6.4 The web script runs nut-cgi 2.0.4-4 If you can try the new 2.4.1, you have some more info from the ups, and better support for load-segments. And it would be fine for me if you can test it so it don't break the function of the HP XR series. sorry, the UPS is already in production usage. As for 2.4.1, i will get it eventually once it is in debian stable. I did try to upgrade to 2.4.1-3 from debian testing, but i had to change a lot to get it working, so i gave up and reverted to debian stable. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] upsmon shutdown based on Time since power fail.
On 20/05/2009, at 12.11, Richard Chapman wrote: For various reasons - I have been trying to get my Desktops and/or servers to shut-down a fixed time after a power fail - or better still a fixed time - or a low battery whichever comes first. [cut] Is there another parameter somewhere - probably in upsmon - which would allow me to specify a shut-down after (say) 3 minutes running on battery regardless of battery status? In the upsmon.conf file you use NOTIFYCMD and ONBATT to execute a shutdown $time Then you use a ONLINE to execute a -c to cancel a shutdown if the power returns. JonB ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] early shutdown of VMware VMs
On 13/02/2009, at 16.48, David Newman wrote: On 2/12/09 11:19 PM, Arjen de Korte wrote: Citeren David Newman dnew...@networktest.com: How to shut down VMWare guest virtual machines earlier than the host machine they run on? (For example, if everything normally shuts down at 5% UPS battery, then the VMs should shut down at 10%.) First question is, why do you want to do that? Because a clean shutdown of the VMs is more important than high uptime for the VMs. If both guest and host machines shut down at the same time, the host might finish its shutdown before the guests have, leading to possible filesystem corruption. I will gladly trade off some downtime of the VMs to ensure clean shutdowns. I also read upssched.txt but I can't tell from the early shutdown section which settings to use on the master and which on the slaves. This seems like a fairly standard problem -- are there sample configs posted someplace? I'm not an expert on VMware, but I would expect that you can configure on the host that it shuts down the guests before going down. Thanks -- that's what I'm asking for -- what is it that I configure, and are there sample configs someplace that do this? I think you have to ask on a VMware list how you configure the VMware server to tell the VMware clients to shut down. Maybe just sending ctrl+alt+delete is enough. Or you could just use the notify command? Once ONBATT is reached, then sleep for a 1 minute or more, and start the shutdown? If you get a ONLINE then have the script check if all virtual machines are running. There might be a problem if the UPS has very little power left. So when you get a LOWBATT execute a script that doesnt sleep but start the shutdown now. NOTIFYFLAG LOWBATT SYSLOG+WALL+EXEC NOTIFYFLAG ONBATT SYSLOG+WALL+EXEC NOTIFYFLAG ONLINE SYSLOG+EXEC NOTIFYCMD /sbin/upsmail.sh Then just include something that tells the virtual machines to shut down. And install it on every vmware client unless you can instruct vmware to shut the clients nicely down. Maybe tell vmware to sleep the machines at ONBATT? JonB ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
[Nut-upsuser] tool that records and plots graphs of UPS load over time?
Hi I'm looking for a tool that records and plots graphs of UPS load over time? Any suggestions? JonB ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] tool that records and plots graphs of UPS load over time?
On 17/01/2008, at 11.42, Carlos Rodrigues wrote: On Jan 17, 2008 9:43 AM, Jon Bendtsen [EMAIL PROTECTED] wrote: On 17/01/2008, at 10.24, Dan Mahoney, System Admin wrote: On Thu, 17 Jan 2008, Jon Bendtsen wrote: MRTG should be able to do it just fine, if you know what you're doing. I was hoping for some plug'n'pray system ;-) You can try this: http://code.google.com/p/quicklook/ If you pull the upsmon branch from svn it also does graphs for NUT. It's still experimental though. Thanks, it seems nice. Jonb ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] trouble with Cyber Power System CPS RS232 USB BRIDGE for UPS
On 22/11/2007, at 15.15, Jon Bendtsen wrote: On 22/11/2007, at 14.55, Arjen de Korte wrote: Recently i bought a MicroDoWell BP50, and with it followed a USB 2 serial converter. When i plug it into my 2.6.19 kernel, dmesg shows I gave up on using the USB converter and used a regular serial cable, it works fine using both the powerpanel and the cpsups driver. I prefer the powerpanel because the name is slightly nicer in the cgi. JonB ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] trouble with Cyber Power System CPS RS232 USB BRIDGE for UPS
On 26/11/2007, at 12.06, Arjen de Korte wrote: Jon Bendtsen wrote: I gave up on using the USB converter and used a regular serial cable, it works fine using both the powerpanel and the cpsups driver. I prefer the powerpanel because the name is slightly nicer in the cgi. Could you post the output of 'upsc upsname' here? We're working on extending the support for the powerpanel driver, but in order to do that, we need some information on what is reported by devices that are supported already. Thanks in advance. powerpanel driver: - [EMAIL PROTECTED]:~# upsc bp500 battery.capacity: 7 battery.charge: 100.0 battery.charge.low: 20 battery.packs: 1 battery.voltage.nominal: 12 driver.name: powerpanel driver.parameter.pollinterval: 2 driver.parameter.port: /dev/ttyS0 driver.version: 2.2.0- driver.version.internal: 0.22 input.frequency: 49.9 input.frequency.high: 63 input.frequency.low: 47 input.transfer.high: 272 input.transfer.low: 180 input.voltage: 234 input.voltage.nominal: 230 output.voltage: 234 ups.firmware: 1.704 ups.load: 80 ups.mfr: CYBER POWER ups.model: 500VA ups.power.nominal: 500 ups.realpower.nominal: 330 ups.serial: ups.status: OL ups.temperature: 32 cpsups driver: [EMAIL PROTECTED]:/etc/nut# upsc bp500 battery.charge: 100.0 battery.runtime: 3:58 driver.name: cpsups driver.parameter.pollinterval: 2 driver.parameter.port: /dev/ttyS0 driver.version: 2.2.0- driver.version.internal: .05 input.frequency: 50 input.voltage: 234 output.voltage: 234 ups.load: 82 ups.mfr: CyberPower ups.model: OP500TE 1.704 ups.power.nominal: 500 ups.runtime: 16.5 ups.status: OL ups.temperature: 32 ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
[Nut-upsuser] trouble with Cyber Power System CPS RS232 USB BRIDGE for UPS
Hi Recently i bought a MicroDoWell BP50, and with it followed a USB 2 serial converter. When i plug it into my 2.6.19 kernel, dmesg shows hiddev96: USB HID v1.10 Device [Cyber Power System CPS RS232 USB BRIDGE for UPS] on usb-:00:04.2-2 usbcore: registered new interface driver usbhid drivers/usb/input/hid-core.c: v2.6:USB HID core driver So, i figured i should use usbhid-ups, /etc/nut/ups.conf [switch] driver = usbhid-ups port = auto and then i ran the command /lib/nut/usbhid-ups - -a switch [EMAIL PROTECTED]:/etc/nut# /lib/nut/usbhid-ups - -a switch Network UPS Tools: 0.28 USB communication driver 0.28 - core 0.30 (2.2.0-) debug level is '16' Checking device (0764/0005) (001/002) - VendorID: 0764 - ProductID: 0005 - Manufacturer: unknown - Product: unknown - Serial Number: unknown - Bus: 001 Trying to match device Device matches Unable to get HID descriptor (error sending control message: Connection timed out) i=0, extra[i]=09, extra[i+1]=21 HID descriptor, method 2: (9 bytes) = 09 21 10 01 21 01 22 5a 00 HID descriptor retrieved (Reportlen = 90) Unable to get Report descriptor (-110): Connection timed out Checking device (/) (001/001) - VendorID: - ProductID: - Manufacturer: unknown - Product: unknown - Serial Number: unknown - Bus: 001 Trying to match device Device does not match - skipping No appropriate HID device found No matching HID UPS found [EMAIL PROTECTED]:/etc/nut# The MicroDoWell BP50 only has a serial out, but i am using the serial cable that came with the UPS. Unfortunately it is not very long, so having a USB extender cable i connected the serial cable to the UPS and the USB2serial converter and then the extender cable and into my server. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] trouble with Cyber Power System CPS RS232 USB BRIDGE for UPS
On 22/11/2007, at 14.55, Arjen de Korte wrote: Recently i bought a MicroDoWell BP50, and with it followed a USB 2 serial converter. When i plug it into my 2.6.19 kernel, dmesg shows hiddev96: USB HID v1.10 Device [Cyber Power System CPS RS232 USB BRIDGE for UPS] on usb-:00:04.2-2 usbcore: registered new interface driver usbhid drivers/usb/input/hid-core.c: v2.6:USB HID core driver That's a little confusing. Apparently, Cyber Power System designed this device to be used particularly for UPS use. However, all it should do is provide a serial port, so that you can connect the 'powerpanel' or 'cpsups' driver to it. i was thinking it new how to convert a serial port to a USB hid UPS protocol? So, i figured i should use usbhid-ups, /etc/nut/ups.conf [switch] driver = usbhid-ups port = auto I understand what made you think this is the correct driver, but unfortunately it isn't. Worse still, CPS also uses this same VID:PID for their USB HID UPS'es, so we have really no means to exclude this in the 'apc-hid' subdriver. The MicroDoWell BP50 only has a serial out, but i am using the serial cable that came with the UPS. Unfortunately it is not very long, so having a USB extender cable i connected the serial cable to the UPS and the USB2serial converter and then the extender cable and into my server. Your serial-to-USB converter should provide a virtual COM port, something like /dev/ttyUSB0 ot something like that. This port should be configured in 'ups.conf' with either the 'powerpanel' or 'cpsups' driver. If no virtual COM port is created upon plugging in the serial-to-USB converter, it is most likely not recognized by your kernel. In that case, the only thing we can do for the moment is to suggest to try a different one that is supported by your kernel. I tried that part, but i can not get it to work. I tried ttyUSB0, 1, 2 and 3. neither worked. i will try to find another usb2serial converter JonB ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
[Nut-upsuser] has anyone used Microdowell Enterprise N- series with NUT?
Hi I got an offer for some microdowell enterprise N- series UPS'ses. The NUT homepage only lists the B.Box BP series. Does anyone know if the Enterprise N- series works with NUT? JonB ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
[Nut-upsuser] abusing nut ups to do temperature shutdown WHILE monitoring UPS'es
Hi I am thinking about using the existing NUT software to tell the slave servers to shutdown if the temperature in the server room becomes too high. I was thinking of monitoring the temperature on the master NUT server and then just letting the slave clients shut down. But the slaves (and master server) needs to do a complete power off even though the UPS's does get 220v power all the time. Does nut do a complete power off by default for slave clients? The reason i want to do this is because what if the master UPS server gets too hot, and shuts down. But that means all the nut slave clients looses connection to the ups master server, and then later the power to the UPS's are lost. Then noone will tell the NUT slave clients to shut down gracefully. I am open to other suggestions if anyone has (better) ideas. JonB ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] abusing nut ups to do temperature shutdownWHILEmonitoring UPS'es
Den torsdag 26.jul kl. 14:18 skrev Doug Parsons: I have a plan to do the same thing. The approach I was going to take is to use several fake ups units that use contact closure style drivers. The use a contact closure from the temp sensor to send the fake UPS units into LB status. If the are fake units and all servers monitor for these in addition to the real ones. Then you can set your needed count to shut down when the temp goes high. You will need some of these relays to be feed from the same source as the UPS units so that in a real power failure the fake units go off line. Do you really need a fake thing? cant you fake it in software and once the temperature goes too high you just run a script which hooks into NUT and sets the TemperaturUPS to NO battery or something and shut it down using that? I was planning to use lmsensors to monitor the temperature and then shutdown. JonB ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] abusing nut ups to do temperature shutdown WHILE monitoring UPS'es
Den torsdag 26.jul kl. 12:19 skrev Arjen de Korte: The problem here is that once you've switched off all your equipment, it will stayoff until someone intervenes. true, but thats okay Then noone will tell the NUT slave clients to shut down gracefully. I am open to other suggestions if anyone has (better) ideas. I think a better idea would be to monitor the temperature in the server room through other means and raise an alarm / send notifications to an operator who can then decide what to do. there are no night time operators, and i certainly do not want to become one. Besides if the temperature really is too high because of a broken airconditioner then i can not fix that anyway. JonB ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
