[Nut-upsuser] NUT upsstats.cgi problem
I seem to have NUT all working with my R3000XR, except for the CGIs. The webserver's all properly configured and upsstats.cgi *runs*, but doesn't yield any useful output - no values are displayed, every value is replaced by [error: Invalid argument]. Apache is not logging any resulting errors, and there doesn't seem to be a lot of useful documentation on the CGIs to troubleshoot with. Is anyone familiar with this problem? -- Phil Stracchino, CDK#2 DoD#299792458 ICBM: 43.5607, -71.355 ala...@caerllewys.net ala...@metrocast.net p...@co.ordinate.org Renaissance Man, Unix ronin, Perl hacker, Free Stater It's not the years, it's the mileage. ___ 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 900i
> Citeren Rene Bartsch : > >> Command: "/lib/nut/apcsmart -a su900i -D" >> >> - snip >> - >> >> Network UPS Tools - APC Smart protocol driver 2.00 (2.4.1) >> APC command table version 2.0 >> debug level is '5' >> send_to_all: SETINFO ups.mfr "APC" >> Attempting firmware lookup >> Attempting to contact older Smart-UPS version >> Firmware: [7QI] > > That's all we need for now. > > I've just added support for this version, assuming that it is similar > to the Smart UPS 900 firmware [7TD] we already support. We have > confirmed that this is the case for the 600 and 1250 models, so this > probably goes for the 900 as well. > > I've added support for all variations of the [678][QT][DI] models now, > so if you grab the latest version from the SVN trunk, you should be > fine. Please let us know if this works for you. > > Best regards, Arjen > -- > Please keep list traffic on the list > > Command: "upsc su900i" -- snip --- battery.alarm.threshold: 0 battery.charge: 100.0 battery.charge.restart: 10 battery.date: 11/02/01 battery.runtime: 4440 battery.runtime.low: 120 battery.voltage: 27.67 battery.voltage.nominal: 024 driver.name: apcsmart driver.parameter.cable: 940-0024C driver.parameter.pollinterval: 2 driver.parameter.port: /dev/ttyUSB0 driver.version: 2.4.1 driver.version.internal: 2.03 input.frequency: 50.00 input.quality: FF input.sensitivity: H input.transfer.high: 253 input.transfer.low: 196 input.transfer.reason: O input.voltage: 229.4 input.voltage.maximum: 231.8 input.voltage.minimum: 229.4 output.voltage: 229.4 output.voltage.nominal: 225 ups.delay.shutdown: 180 ups.delay.start: 300 ups.id: UPS_IDEN ups.load: 006.2 ups.mfr: APC ups.mfr.date: 02/18/93 ups.serial: 00016325 ups.status: OL ups.temperature: 045.9 ups.test.interval: 0 ups.test.result: NO -- snap --- Many thanks for the fast help! :) Best regards, Renne ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] New NUT user with HP R3000XR problem
On Wed, May 27, 2009 at 11:51:44PM +0200, Arjen de Korte wrote: > Citeren Brother Railgun of Reason : > babylon4:root:/opt/nut:25 # sbin/upsd Network UPS Tools upsd 2.4.1 listening on 127.0.0.1 port 3493 listening on ::1 port 3493 /opt/nut/var is world readable Connected to UPS [tokamak]: bcmxcp-tokamak Maximum number of connections limited to 256 [requested 1024] >>> Weird, apparently your system has a limited number of file descriptors >>> available. I have a feeling that this is not a standard operating system. >> I was a little puzzled by that myself. It's Solaris 10 x86 running on a >> pretty substantial box, it shouldn't be an OS limitation. > > Oops, looking at the code I saw this isn't a warning, but a (fatal) error > instead (this was not one of the most descriptive error messages I ever > wrote). I now recall that this value is OS dependent, so you probably > want/need to limit this in upsd.conf through the MAXCONN parameter (which > in your case seems to be mandatory). Ah, ... yeah, that would have been better than patching the code, wouldn't it? *sheepish* I missed that parameter. I'll undo my patch and try using the maxconn param instead. As just mentioned, my studies appear to indicate that this is a tunable kernel parameter which, on Solaris, defaults out-of-the-box to 256. > I'm not quite sure what would be the better thing to do in case the > (default) MAXCONN value is too high: > > 1) Bail out with a more descriptive error message > 2) Adjust the number of connections to the maximum allowed (with message to > syslog) > > I think it would be much more user friendly to do the latter, but opinions > on this are welcomed. Given that this varies by OS *but* may be tunable, my inclination would be to adjust the connections to the max available if less than MAXCONN, emit a warning in syslog and on the console, and document in the sample upsd.conf that depending on OS this MAY be a tunable parameter. >> BTW, upsd.conf is default with everything commented out, which should >> result in listening on everything: >> >> # This defaults to the global IPv4 listening address and port 3493. You >> # may specify each interface you want upsd to listen on for connections, >> # optionally with a port number. > > We need to change this. This used to be the case in older versions, but we > now default to a (safer) localhost only. Ah, so the behavior is as *intended*, but the documentation has gotten out of step with the intent. I see. If this change was made for security reasons, perhaps this goal might be aided by adding a netblock ALLOW or ACCEPT directive? For example, with two subnets, I might specify: LISTEN 127.0.0.1 3493 ACCEPT 127.0.0.0/8 LISTEN 10.24.32.14 3493 ACCEPT 10.24.32.0/24 ACCEPT 10.24.33.0/24 upsd could simply refuse connections from outside the netblocks it had been told to ACCEPT, without doing any further authentication. -- Phil Stracchino, CDK#2 DoD#299792458 ICBM: 43.5607, -71.355 ala...@caerllewys.net ala...@metrocast.net p...@co.ordinate.org Renaissance Man, Unix ronin, Perl hacker, Free Stater It's not the years, it's the mileage. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] New NUT user with HP R3000XR problem
On Wed, May 27, 2009 at 05:10:07PM -0400, Brother Railgun of Reason wrote: > and then telnetting to port 3493, still from localhost, and I still > couldn't connect to port 3493. So, being a nasty suspicious sort, I > checked lsof ... nothing's got port 3493 open. checked the process > table ... upsd isn't running. It appears to start up, then immediately > die. > > Could this be because something is limiting it to 256 connections? > (Not that I'm ever going to need even a tenth of that 16 > connections would be more than I'm ever going to need to use.) > > I'm wondering whether I should go tweak the source to request only 256 > connections (or even 128) and see if upsd still dies on startup. Indeed, I checked the code, and inability to get the requested number of connections is a fatal error. Investigating this, I've discovered that when upsd checks how many connections it may have, it's actually checking _SC_OPEN_MAX, which is the number of files it's allowed to have open, and which appears to be governed by rlim_fd_cur. On Solaris 10, out of the box, rlim_fd_cur defaults to 256. I'll reset this to 2048 in /etc/system on my next reboot, but in the meantime I've patched upsd.c to set maxconn to 128, since I'm never going to need even 256 connections to upsd. Now: babylon4:root:/opt/nut:10 # upsd Network UPS Tools upsd 2.4.1 listening on 10.24.32.14 port 3493 listening on 127.0.0.1 port 3493 Connected to UPS [tokamak]: bcmxcp-tokamak babylon4:root:/opt/nut:11 # upsc toka...@localhost ups.status OL babylon4:root:/opt/nut:12 # upsc toka...@localhost ambient.temperature: 23.8 ambient.temperature.high: 55 battery.charge: 33.1 battery.runtime: 442 battery.voltage: 129.2 driver.name: bcmxcp driver.parameter.baud_rate: 19200 driver.parameter.pollinterval: 2 driver.parameter.port: /dev/tty00 driver.version: 2.4.1 driver.version.internal: 0.21 input.current: 11.2 input.frequency: 60.0 input.frequency.high: 65 input.frequency.low: 55 input.frequency.nominal: 60 input.transfer.boost.high: 12 input.voltage: 119.8 input.voltage.nominal: 120 outlet.1.delay.shutdown: -1 outlet.1.delay.start: 1 outlet.1.id: 1 outlet.1.status: On outlet.2.delay.shutdown: -1 outlet.2.delay.start: 2 outlet.2.id: 2 outlet.2.status: On outlet.3.delay.shutdown: -1 outlet.3.delay.start: 3 outlet.3.id: 3 outlet.3.status: On output.current:9.4 output.current.nominal: 24.0 output.frequency: 60.0 output.phases: 1 output.voltage: 115.3 output.voltage.nominal: 120 ups.beeper.status: enabled ups.firmware: Cont:01.01 ups.load: 37.5 ups.model: COMPAQ UPS 2900VA ups.power: 1080.5 ups.power.nominal: 2900 ups.serialMPAQ ups.status: OL So this is starting to look much better. I wish I'd realized sooner that upsd wasn't just complaining, but complaining *and dying*. -- Phil Stracchino, CDK#2 DoD#299792458 ICBM: 43.5607, -71.355 ala...@caerllewys.net ala...@metrocast.net p...@co.ordinate.org Renaissance Man, Unix ronin, Perl hacker, Free Stater It's not the years, it's the mileage. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] New NUT user with HP R3000XR problem
Citeren Brother Railgun of Reason : babylon4:root:/opt/nut:25 # sbin/upsd Network UPS Tools upsd 2.4.1 listening on 127.0.0.1 port 3493 listening on ::1 port 3493 /opt/nut/var is world readable Connected to UPS [tokamak]: bcmxcp-tokamak Maximum number of connections limited to 256 [requested 1024] Weird, apparently your system has a limited number of file descriptors available. I have a feeling that this is not a standard operating system. I was a little puzzled by that myself. It's Solaris 10 x86 running on a pretty substantial box, it shouldn't be an OS limitation. Oops, looking at the code I saw this isn't a warning, but a (fatal) error instead (this was not one of the most descriptive error messages I ever wrote). I now recall that this value is OS dependent, so you probably want/need to limit this in upsd.conf through the MAXCONN parameter (which in your case seems to be mandatory). I'm not quite sure what would be the better thing to do in case the (default) MAXCONN value is too high: 1) Bail out with a more descriptive error message 2) Adjust the number of connections to the maximum allowed (with message to syslog) I think it would be much more user friendly to do the latter, but opinions on this are welcomed. For whatever reason, you can't connect to localhost. I've never seen this before. The only thing I can imagine now is that some kind of policy exists that doesn't allow you connect through localhost because this is OS is running as a guest on top of another system. Nope, this is not a client OS or vhost. This is the global zone of a Solaris 10 machine, and as you can see, the above was running as root. This all makes sense now. The server is not running. BTW, upsd.conf is default with everything commented out, which should result in listening on everything: # This defaults to the global IPv4 listening address and port 3493. You # may specify each interface you want upsd to listen on for connections, # optionally with a port number. We need to change this. This used to be the case in older versions, but we now default to a (safer) localhost only. [...] Could this be because something is limiting it to 256 connections? (Not that I'm ever going to need even a tenth of that 16 connections would be more than I'm ever going to need to use.) I'm wondering whether I should go tweak the source to request only 256 connections (or even 128) and see if upsd still dies on startup. Yes, see a couple of lines down in upsd.conf (no need to tweak the sources for that). Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] New NUT user with HP R3000XR problem
On Wed, May 27, 2009 at 08:42:40PM +0200, Kjell Claesson wrote: > > On Wed, May 27, 2009 at 06:04:40PM +0200, Kjell Claesson wrote: > OK, > 8<-snip--- > > With the config indicating 19200, it locks immediately at 19200. I just > > don't get any UPS "signature" displayed on connection: > > > > babylon4:root:/opt/nut:24 # bin/upsdrvctl start > > Network UPS Tools - UPS driver controller 2.4.1 > > Network UPS Tools - BCMXCP UPS driver 0.21 (2.4.1) > > RS-232 communication subdriver 0.17 > > Connected to UPS on /dev/tty00 with baudrate 19200 > This is right. You dont get anything more from the driver. Oh, OK ... I thought the examples and other list threads with R3000XRs showed a version string being echoed at this point. > > > babylon4:root:/opt/nut:25 # sbin/upsd > > Network UPS Tools upsd 2.4.1 > > listening on 127.0.0.1 port 3493 > > listening on ::1 port 3493 > > /opt/nut/var is world readable > > Connected to UPS [tokamak]: bcmxcp-tokamak > > Maximum number of connections limited to 256 [requested 1024] > > babylon4:root:/opt/nut:26 # bin/upsc toka...@localhost > > Error: Connection failure: Connection refused > This is not so good. But it is the daemon that is complaining > that it can not connect to the socket right. > > Check your configuration once more. I've been over it several times ... it appears upsd is dying immediately after startup, but I don't yet know why. > You have a config block. (not used at the moment. [...] > Yes it looks like it is giving the right sequence for load-segments. So far, so good then... > So check that all permissions on the files and socket directory is right. > The driver is working OK. The way I configured it, that should be /opt/nut/var: [from config.status:] exec /bin/bash "./configure" '--prefix=/opt/nut' '--htmldir=/var/httpd/local/manuals/nut' '--with-serial' '--with-gd-includes=-I/usr/local/include' '--with-gnu-ld' '--with-statepath=/opt/nut/var' '--with-pidpath=/opt/nut/var' '--with-user=nut' '--with-group=nut' '--with-cgi' '--with-lib' '--without-usb' '--without-snmp' '--without-ssl' $ac_configure_extra_args --no-create --no-recursion babylon4:root:/opt/nut:53 # ls -l . var .: total 15 drwxr-xr-x 2 root nut 44 May 26 21:02 bin/ drwxr-xr-x 2 root nut 5 May 26 21:02 cgi-bin/ drwxr-x--- 2 root nut 15 May 26 21:15 etc/ drwxr-xr-x 2 root nut 6 May 26 21:02 html/ drwxr-xr-x 2 root nut 2 May 26 21:02 include/ drwxr-xr-x 3 root nut 7 May 26 21:02 lib/ drwxr-xr-x 2 root nut 5 May 26 21:02 sbin/ drwxr-xr-x 3 root nut 5 May 26 21:02 share/ drwxrwx--- 2 root nut 4 May 27 16:51 var/ var: total 2 srw-rw 1 nut nut 0 May 27 16:51 bcmxcp-tokamak= -rw-r--r-- 1 nut nut 4 May 27 16:51 bcmxcp-tokamak.pid babylon4:root:/opt/nut:54 # ls -l /dev/tty00 lrwxrwxrwx 1 root root 26 Apr 18 18:48 /dev/tty00 -> ../devices/isa/a...@1,3f8:a babylon4:root:/opt/nut:55 # ls -l /devices/isa/a...@1,3f8:a crw-rw 1 root nut 106, 0 May 27 17:17 /devices/isa/a...@1,3f8:a -- Phil Stracchino, CDK#2 DoD#299792458 ICBM: 43.5607, -71.355 ala...@caerllewys.net ala...@metrocast.net p...@co.ordinate.org Renaissance Man, Unix ronin, Perl hacker, Free Stater It's not the years, it's the mileage. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] New NUT user with HP R3000XR problem
On Wed, May 27, 2009 at 08:56:13PM +0200, Arjen de Korte wrote: > Citeren Brother Railgun of Reason : > >> babylon4:root:/opt/nut:24 start >> Network UPS Tools - UPS driver controller 2.4.1 >> Network UPS Tools - BCMXCP UPS driver 0.21 (2.4.1) >> RS-232 communication subdriver 0.17 >> Connected to UPS on /dev/tty00 with baudrate 19200 > > OK, the driver is running, so this is not the problem. > >> babylon4:root:/opt/nut:25 # sbin/upsd >> Network UPS Tools upsd 2.4.1 >> listening on 127.0.0.1 port 3493 >> listening on ::1 port 3493 >> /opt/nut/var is world readable >> Connected to UPS [tokamak]: bcmxcp-tokamak >> Maximum number of connections limited to 256 [requested 1024] > > Weird, apparently your system has a limited number of file descriptors > available. I have a feeling that this is not a standard operating system. I was a little puzzled by that myself. It's Solaris 10 x86 running on a pretty substantial box, it shouldn't be an OS limitation. >> babylon4:root:/opt/nut:26 # bin/upsc toka...@localhost >> Error: Connection failure: Connection refused > > For whatever reason, you can't connect to localhost. I've never seen this > before. The only thing I can imagine now is that some kind of policy exists > that doesn't allow you connect through localhost because this is OS is > running as a guest on top of another system. Nope, this is not a client OS or vhost. This is the global zone of a Solaris 10 machine, and as you can see, the above was running as root. BTW, upsd.conf is default with everything commented out, which should result in listening on everything: # This defaults to the global IPv4 listening address and port 3493. You # may specify each interface you want upsd to listen on for connections, # optionally with a port number. Despite the above statement, this *actually* results in upsd defaulting to listening only on loopback. I just tried explicitly adding the machine's external IP as well: LISTEN 127.0.0.1 3493 LISTEN 10.24.32.14 3493 babylon4:root:/opt/nut:42 # sbin/upsd -DDD Network UPS Tools upsd 2.4.1 listen_add: added 127.0.0.1:3493 listen_add: added 10.24.32.14:3493 setuptcp: try to bind to 10.24.32.14 port 3493 listening on 10.24.32.14 port 3493 setuptcp: try to bind to 127.0.0.1 port 3493 listening on 127.0.0.1 port 3493 Connected to UPS [tokamak]: bcmxcp-tokamak Maximum number of connections limited to 256 [requested 1024] and then telnetting to port 3493, still from localhost, and I still couldn't connect to port 3493. So, being a nasty suspicious sort, I checked lsof ... nothing's got port 3493 open. checked the process table ... upsd isn't running. It appears to start up, then immediately die. Could this be because something is limiting it to 256 connections? (Not that I'm ever going to need even a tenth of that 16 connections would be more than I'm ever going to need to use.) I'm wondering whether I should go tweak the source to request only 256 connections (or even 128) and see if upsd still dies on startup. -- Phil Stracchino, CDK#2 DoD#299792458 ICBM: 43.5607, -71.355 ala...@caerllewys.net ala...@metrocast.net p...@co.ordinate.org Renaissance Man, Unix ronin, Perl hacker, Free Stater It's not the years, it's the mileage. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] New NUT user with HP R3000XR problem
Citeren Brother Railgun of Reason : babylon4:root:/opt/nut:24 start Network UPS Tools - UPS driver controller 2.4.1 Network UPS Tools - BCMXCP UPS driver 0.21 (2.4.1) RS-232 communication subdriver 0.17 Connected to UPS on /dev/tty00 with baudrate 19200 OK, the driver is running, so this is not the problem. babylon4:root:/opt/nut:25 # sbin/upsd Network UPS Tools upsd 2.4.1 listening on 127.0.0.1 port 3493 listening on ::1 port 3493 /opt/nut/var is world readable Connected to UPS [tokamak]: bcmxcp-tokamak Maximum number of connections limited to 256 [requested 1024] Weird, apparently your system has a limited number of file descriptors available. I have a feeling that this is not a standard operating system. babylon4:root:/opt/nut:26 # bin/upsc toka...@localhost Error: Connection failure: Connection refused For whatever reason, you can't connect to localhost. I've never seen this before. The only thing I can imagine now is that some kind of policy exists that doesn't allow you connect through localhost because this is OS is running as a guest on top of another system. Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] New NUT user with HP R3000XR problem
[oops, forgot to copy list] On Wed, May 27, 2009 at 06:04:40PM +0200, Kjell Claesson wrote: > > On Tue, May 26, 2009 at 09:51:31PM -0400, Brother Railgun of Reason wrote: > Hi, > > > ups.conf looks like this: > > > > > > [tokamak] > > > driver = bcmxcp > > > port= /dev/tty00 > > > baud_rate = 19200 > > > desc= HP R3000XR (main rack) > > > > (Oops. That's *after* changing to the 19200 rate the driver claims to > > autodetect.) > That sound strange. It should hit 19200 direct if it is in the config. > And the HP R3000XR is communicating at 19200 default. That type > is the reason the baud changing got into the driver. Sorry, I confused the issue a little there. I originally had 9600 specified. It failed to connect at 9600, autodetected, and claimed sync at 19200. When I went back and pasted in the config section, I didn't realize until too late that I'd pasted the config from *after* editing to 19200 in before the stage of the process where I'd actually done so. With the config indicating 19200, it locks immediately at 19200. I just don't get any UPS "signature" displayed on connection: babylon4:root:/opt/nut:24 # bin/upsdrvctl start Network UPS Tools - UPS driver controller 2.4.1 Network UPS Tools - BCMXCP UPS driver 0.21 (2.4.1) RS-232 communication subdriver 0.17 Connected to UPS on /dev/tty00 with baudrate 19200 babylon4:root:/opt/nut:25 # sbin/upsd Network UPS Tools upsd 2.4.1 listening on 127.0.0.1 port 3493 listening on ::1 port 3493 /opt/nut/var is world readable Connected to UPS [tokamak]: bcmxcp-tokamak Maximum number of connections limited to 256 [requested 1024] babylon4:root:/opt/nut:26 # bin/upsc toka...@localhost Error: Connection failure: Connection refused > If it say it connect it is talking to the ups. But to be sure about that, you > may run it in debug mode, like this. > > /path/to/bcmxcp -DD -a tokamak > (stop it by hitting ctrl-c) > > Now it would spit out some info. I'm interested in the output. There may > be some problems how the HP is counting the load-segments. > It depends on the version of the firmware in the ups. That generates a lot of output with many repeats. I've edited out most of the repeats from the end of the following: debug level is '2' Connected to UPS on /dev/tty00 with baudrate 19200 Length of meter map: 82 Index Offset Format NUT 001561 None 0018000461 input.current 0021000861 None 0023001261 ups.power 0027001651 output.frequency 0028002051 input.frequency 0031002461 None 0033002851 battery.voltage 0034003251 battery.charge 00350036e2 battery.runtime 0056004061 input.voltage 0062004461 ambient.temperature 0065004861 output.current 0068005261 output.current.nominal 0071005661 None 0078006061 output.voltage Length of alarm map: 27 Index Alarm Supported INVERTER_AC_OVER_VOLTAGEYes 0001INVERTER_AC_UNDER_VOLTAGE Yes -001INVERTER_OVER_OR_UNDER_FREQ No -001BYPASS_AC_OVER_VOLTAGE No -001BYPASS_AC_UNDER_VOLTAGE No -001BYPASS_OVER_OR_UNDER_FREQ No 0002INPUT_AC_OVER_VOLTAGE Yes 0003INPUT_AC_UNDER_VOLTAGE Yes 0004INPUT_UNDER_OR_OVER_FREQYes -001OUTPUT_OVER_VOLTAGE No -001OUTPUT_UNDER_VOLTAGENo -001OUTPUT_UNDER_OR_OVER_FREQ No 0005REMOTE_EMERGENCY_PWR_OFFYes -001REMOTE_GO_TO_BYPASS No -001BUILDING_ALARM_6No -001BUILDING_ALARM_5No -001BUILDING_ALARM_4No -001BUILDING_ALARM_3No -001BUILDING_ALARM_2No -001BUILDING_ALARM_1No -001STATIC_SWITCH_OVER_TEMP No -001CHARGER_OVER_TEMP No -001CHARGER_LOGIC_PWR_FAIL No -001CHARGER_OVER_VOLTAGE_OR_CURRENT No -001INVERTER_OVER_TEMP No 0006OUTPUT_OVERLOAD Yes 0007RECTIFIER_INPUT_OVER_CURRENTYes 0008INVERTER_OUTPUT_OVER_CURRENTYes 0009DC_LINK_OVER_VOLTAGEYes -001DC_LINK_UNDER_VOLTAGE No -001RECTIFIER_FAILEDNo 0010INVERTER_FAULT Yes -001BATTERY_CONNECTOR_FAIL No -001BYPASS_BREAKER_FAIL No 0011CHARGER_FAILYes -001RAMP_UP_FAILED No -001STATIC_SWITCH_FAILEDNo -001ANALOG_AD_REF_FAIL No -001BYPASS_UNCALIBRATED No -001RECTIFIER_UNCALIBRATED No -001OUTPUT_UNCALIBRATED No -001INVERTER_UNCALIBRATED No -001DC_VOLT_UNCALIBRATEDNo -001OUTPUT_CURRENT_UNCALIBRATED No -001RECTIFIER_CURRENT_UNCALIBRATED No -001BATTERY_CURRENT_UNCALIBRATEDNo -001INVERTER_ON_OFF_STAT_FAIL No -001BATTERY_CURRENT_LIMIT No -001INVERTER_STARTUP_FAIL No -001ANALOG_BOARD_AD_STAT_FAIL No -001OUTPUT_CURRENT_OVER_100 No -001BATTERY_GROUND_FAULTNo -001WAITING_FOR_CHARGER_SYNCNo -001NV
Re: [Nut-upsuser] New NUT user with HP R3000XR problem
> On Tue, May 26, 2009 at 09:51:31PM -0400, Brother Railgun of Reason wrote: Hi, > > ups.conf looks like this: > > > > [tokamak] > > driver = bcmxcp > > port= /dev/tty00 > > baud_rate = 19200 > > desc= HP R3000XR (main rack) > > (Oops. That's *after* changing to the 19200 rate the driver claims to > autodetect.) That sound strange. It should hit 19200 direct if it is in the config. And the HP R3000XR is communicating at 19200 default. That type is the reason the baud changing got into the driver. > > > Am I using the correct cable here? If not, what's the correct cable to > > use? If it say it connect it is talking to the ups. But to be sure about that, you may run it in debug mode, like this. /path/to/bcmxcp -DD -a tokamak (stop it by hitting ctrl-c) Now it would spit out some info. I'm interested in the output. There may be some problems how the HP is counting the load-segments. It depends on the version of the firmware in the ups. > > The other detail I forgot to add was that, just out of sheer > constructive paranoia, I tried using an APC 940-0024C cable instead of > the HP cable, which as far as I can tell with a DVM is just a dumb > serial cable wired all nine pins straight through. With the HP cable, > the driver thinks it has comm sync at 19200, but upsdrvctl can't talk to > it; with the APC cable, the driver can't even establish communication at > all. /Kjell ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
[Nut-upsuser] This guy must be an idiot
OK, can someone tell me what utterly moronic thing I am doing wrong? I have two roughly identical Linux system running NUT, and one works properly. The other almost does. The second system works well once everything is up, but after booting, the system does not have connectivity to the UPS. I have to manually run `upsdrvctl start backup`, `/etc/init.d/nut start`, and `upsd` to get NUT working. Thereafter it works fine, whether anyone is logged in or not. After a boot, however, I have to log in and kick-start it again. What am I missing? The S50nut symlink is in /etc/rc2.d, and both systems are at runlevel 2. I set up the systems the very same way (as far as I can remember or tell), except that one employs driver = tripplite_usb in usb.conf and the other uses driver = usbhid-ups, plus the two have different backup names. Otherwise, I think everything is the same. ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Nut and PowerWare 5115
Kjell, 2009/5/26 Kjell Claesson > Greg and Arnaud > > > > I missed to add that I'm also interested in this one: "unset USB_DEBUG && > > lsusb -d06da:0002 -v" on your 9.04. I can't find it back in the thread. > > > > @Kjell: do you see anything that could lead to that kind of "regression"? > > I'm not sure that it's on our side though. > > > I can not set the finger on what it is. My PW3105 is running fine on > nut-2.4.1. > so does the 5115 I have underhand. tested with both 2.4.1 (ubuntu vanilla) and the trunk! > I know that there have been changes to the nut_usb.c file, and I > made a comment to Arjen about it. Because it was breaking the > switch between Powerware and Phoenixtec. But that is fixed. > yup, I've checked the code 2 times, since many things have moved around. but I don't see any possible break here. > And the problem on my side is that I don't have any ups with the > Phoenixtec Power Co usb interface. I've cc'ed Tatu. Maybe he can arrange a remote access to such a device. > If I get some time I can put > ubuntu on a computer and test if the nut package is working on > the pw3105. > > Arnaud, do you have any problems running PW5115 with nut-2.4.1 ? > yes, as stated above. that's why I'm interested in the verbose lsusb (check if bConfigurationValue == 1) and the kernel version (some 2.6.28 have broken USB, irrc -3 and another one). as told previously, I'm more inclined in thinking that this issue comes from outside of NUT. something between libusb and the kernel, since the device is working otherwise, and particularly with an older NUT release. testing 2.2.2 on Greg's jaunty would confirm that (if it doesn't work!). cheers, Arnaud -- Linux / Unix Expert R&D - Eaton - http://www.eaton.com/mgeops Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/ Debian Developer - http://www.debian.org Free Software Developer - http://arnaud.quette.free.fr/ ___ 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 900i
Citeren Rene Bartsch : Command: "/lib/nut/apcsmart -a su900i -D" - snip - Network UPS Tools - APC Smart protocol driver 2.00 (2.4.1) APC command table version 2.0 debug level is '5' send_to_all: SETINFO ups.mfr "APC" Attempting firmware lookup Attempting to contact older Smart-UPS version Firmware: [7QI] That's all we need for now. I've just added support for this version, assuming that it is similar to the Smart UPS 900 firmware [7TD] we already support. We have confirmed that this is the case for the 600 and 1250 models, so this probably goes for the 900 as well. I've added support for all variations of the [678][QT][DI] models now, so if you grab the latest version from the SVN trunk, you should be fine. Please let us know if this works for you. Best regards, Arjen -- Please keep list traffic on the list ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
