Re: [Nut-upsuser] Support for Online Yunto and Zinto
Hello, schrieb Arnaud Quette, Am 16.02.2012 18:48: Can you please counter check, and report back upsc/upsrw/upscmd upsc: # upsc YQ450 battery.voltage: 13.40 beeper.status: disabled device.type: ups driver.name: blazer_usb driver.parameter.pollinterval: 2 driver.parameter.port: auto driver.parameter.productid: 0002 driver.parameter.protocol: zinto driver.parameter.subdriver: cypress driver.parameter.vendorid: 06da driver.version: 2.6.3 driver.version.internal: 0.04 input.frequency: 50.0 input.voltage: 232.0 input.voltage.fault: 1.0 output.voltage: 232.0 ups.delay.shutdown: 30 ups.delay.start: 180 ups.load: 0 ups.productid: 0002 ups.status: OL BYPASS ups.temperature: 25.0 ups.type: offline / line interactive ups.vendorid: 06da # upsrw -u xxx -p xxx -s ups.delay.start YQ450 Enter new value for ups.delay.start: 90 Unexpected response from upsd: ERR ACCESS-DENIED # upsrw -u xxx -p xxx -s ups.delay.shutdown YQ450 Enter new value for ups.delay.shutdown: 90 Unexpected response from upsd: ERR ACCESS-DENIED # upscmd -u xxx -p xxx YQ450 shutdown.return 1 Unexpected response from upsd: ERR ACCESS-DENIED output, along with the shutdown test: http://www.networkupstools.org/docs/user-manual.chunked/ar01s06.html#Shutdown_design while doing shutdown # upslog -s yq450 -i 2 -l - Network UPS Tools upslog 2.6.3 logging status of yq450 to - (2s intervals) 20120227 091805 NA 0.0 0 [OB] 25.0 0.0 20120227 091807 NA 0.0 0 [OB] 25.0 0.0 20120227 091809 NA 0.0 0 [OB] 25.0 0.0 20120227 091811 NA 0.0 0 [OB] 25.0 0.0 20120227 091957 NA NA NA [FSD WAIT] NA 0.0 20120227 091959 NA 0.0 0 [FSD OB] 25.0 0.0 20120227 092001 NA 0.0 0 [FSD OB LB] 25.0 0.0 20120227 092003 NA 0.0 0 [FSD OB LB] 25.0 0.0 so, no battery voltage is displayed parallel /lib/nut/blazer_usb -a YQ450 -D 23.832061 read: (000.0 001.0 230.0 000 00.0 12.5 25.0 10001000 25.472224 send: Q1 25.816057 read: (000.0 001.0 230.0 000 00.0 12.5 25.0 11001000 25.816249 send_to_all: SETINFO ups.status OB LB 27.473243 send: Q1 27.832053 read: (000.0 001.0 230.0 000 00.0 12.5 25.0 11001000 29.476227 send: Q1 29.848055 read: (000.0 001.0 230.0 000 00.0 12.5 25.0 11001000 31.478227 send: Q1 31.832056 read: (000.0 001.0 230.0 000 00.0 12.5 25.0 11001000 32.070549 send_to_one: PONG Temperature is always 25.0°C When cutting off power to the UPS, power to the outlets isn't switched off despite the low battery warning (at least 15 minutes after cutting power) Do I have a faulty UPS?2 Thomas ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] eaton evolution not shutting down
2012/2/22 Laurent Lesage laur...@lesagepono.be: Bonjour Arnaud, Bonjour Laurent, sorry for the lag in answering... long week end. Arnaud Quette a écrit : 2012/2/21 Laurent Lesage laur...@lesagepono.be: Hi all, Bonjour Laurent, I just changed my old MGE ellipse for a evolution 850 (now eaton). I can connect using mge-shut (newmge-shut doesn't work). But I have a few issues. I looked around on NUT web-site and googled with no luck. Using debian lenny on 2.6.18 kernel (due to some ISDN driver that doesn't work with earlier kernels) 1) the most annoying is that I cannot shutdown the UPS. here is a trace : Network UPS Tools - MGE UPS SYSTEMS/SHUT driver 0.66 (2.2.2) debug level is '2' entering upsdrv_initups() entering shut_ups_start() Communication with UPS established entering shut_get_descriptor(n 21, 9) shut_wait_ack(): ACK received entering shut_get_descriptor(n 01, 18) shut_wait_ack(): ACK received Device Descriptor: bLength: 0x12 bDescriptorType: 0x01 bcdUSB: 0x0110 bDeviceClass: 0x00 bDeviceSubClass: 0x00 bDeviceProtocol: 0x00 bMaxPacketSize0: 0x08 idVendor: 0x0463 idProduct: 0x bcdDevice: 0x0100 iManufacturer: 0x01 iProduct: 0x02 iSerialNumber: 0x03 bNumConfigurations: 0x01 entering shut_get_descriptor(n 22, 1811) shut_wait_ack(): ACK received Unable to get Report Descriptor If I put more D, I see it stucks on need more data! like this : need more data (1691)! Receive: (2 bytes) = 04 88 Receive: (8 bytes) = 10 b1 82 c0 05 84 09 11 shut_checksum: 7a = OK sent: (1 bytes) = 06 need more data (1683)! 2) I tried to set some variables. The drivers accept to do it (upsrw) but the actually do not change. some change but not with the value I set in the command and come back to their initial value after a few seconds. I will need some more details on this point: - which variables - a driver debug output when changing values Any help appreciated. sure, but I need more info. first, issue (1) means that the driver can't start, while (2) implies that the driver is started... is (1) a repeatable issue? Yes. It happens only when trying to shutdown (upsdrvctl shutdown) then, are you sure that, when calling upsdrvctl shutdown, the previous driver instance has been stopped? Ie, before calling upsdrvctl shutdown, you need to call upsdrvctl stop. or is is only that when you're trying to shutdown the UPS (Ie 'upsdrvctl shutdown' or 'mge-shut -k ...'), it fails? can you please send back a full trace, with debug level 5 (Ie -D), in compressed form? here it is (attached). I have to type ''/lib/nut/mge-shut -a evolution -k -D shutdown.trace 21'' to get it (upsdrvctl gives no detail). Finally, note that 2.2.2 is quite oldish now, so you may also consider an update. Sure :-) (It's the lenny version for the moment) I also noticed sthg strange : the variables and values listed with upsrw seem to be defautl values. I changed some with the windows configurator but they stil seem to be the same. If I restart the window MGE software, it gets the modified values, not the default ones. So, it seems (it seems only!) that the values the mge-shut driver gets are wrong. But the variable names are meaningful and totally related to the functionnalities of the UPS - so their names must be correct. for example, upsrw gives (but for example, the outlet.2.delay.start should be 120, as configured by the windows software - and here it is -1) : nothing abnormal. this is due to the difference between NUT and Windows MGE software in storing params and settings values: for example, outlet.2.delay.start set to 120 is stored by the Windows software, but not applied into the device. whenever you see this -1, it is a timer. whenever you set a timer to a value, countdown start, and in the end, the action (Ie start, stop, cycle, ...) is executed. on its side, NUT stores these default value in ups.conf. a modification has been done on the UPS collection, to allow for storing the param value (ups.delay.start) and the actual timer value, when decrementing (ups.timer.start). The same should be done for outlet too. I've logged a task for this one: https://alioth.debian.org/pm/task.php?func=detailtaskproject_task_id=492group_id=30602group_project_id=318 ... Unable to get Report Descriptor Network UPS Tools - MGE UPS SYSTEMS/SHUT driver 0.66 (2.2.2) well, the situation has improved since version 0.66. it would be worth trying more recent version. But I will probably lag in producing a backport for lenny... cheers, Arnaud -- Linux / Unix Expert RD - Eaton - http://powerquality.eaton.com Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/ Debian Developer - http://www.debian.org Free Software Developer - http://arnaud.quette.free.fr/
Re: [Nut-upsuser] Support for Online Yunto and Zinto
I am not able to do the test When I put protocol=zinto I get: Fatal error: 'protocol' is not a valid variable name for this driver. I have also tried subdriver=zinto without luck 2012/2/21 Arnaud Quette aquette@gmail.com: 2012/2/16 Mario Giammarco mgiamma...@gmail.com: Tomorrow I will do the test! Marco, Thomas, before I switched to something else, I'd like to complete this case. have you been able to do some testing on your side? cheers, Arnaud -- Linux / Unix Expert RD - Eaton - http://powerquality.eaton.com 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/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Server Does Not Shut Down - SOLVED!
Thank you for your reply Charles.
First you are correct in both assumptions, my microprocessor does provide the
voltages and my table listing Pin 9 should read Pin 8.
I spent some time reading and thinking about your email and realized that
normal (AC present, battery normal) is at -12V which is a logic low.
I thought this was how I designed it but when I got funny results I convinced
myself that it was +12V.
Moving on, I have never heard of statserial but I found it on the install CD
and tried it out and it is a wonderful tool that I won't forget.
Setting the switches for -12V provided normal operation of logic 0 and flipping
either pin 1 or pin 8 caused that signal to change to a 1.
HOWEVER, flipping both to +12V caused both lines to show 0 again?
The only possible way for this is if the ground pin 5 was broken. I moved the
ground wire of my simple jig from pin 5 and connected it to a metal point on
the server (which I figured was ground) and eureka!
I exited out of statserial, started up nut and this time setting both lines to
+12V caused the servers to shut down as expected.
So, pin 5 (ground) is broken somewhere which I confirmed with my meter so
tonight I will have to disassemble this server and fix the ground issue.
Thank you for your help, I am eager to fix this and get things back to normal.
Sincerely,
Steve
From: Charles Lepple clep...@gmail.com
To: Steve Read sd_r...@yahoo.ca
Cc: nut-upsuser@lists.alioth.debian.org List
nut-upsuser@lists.alioth.debian.org
Sent: Sunday, February 26, 2012 5:55 PMbrocken
Subject: Re: [Nut-upsuser] Server Does Not Shut Down
On Feb 26, 2012, at 3:14 PM, Steve Read wrote:
I made a simple device to apply either +12 or -12volts to both pin 1(DCD) and
pin 8 (CTS) to help me understand the correct handshake but I am very
confused.
Here is a table of what I get:
State Pin 1 Pin 9 Note What I understand it means
1 +12V +12V OL On Line - normal operation.
2 -12V +12V LB OL I don't understand this. It should be
On Battery.
3 +12V -12V OB I thought this should be Low Battery.
4 -12V -12V OL I thought the server should shut down?
Note: results of running:
/usr/local/ups/bin/upsc sdrups@localhost ups.status
For reference, here is the block for type=9 in genericups.h:
/* Type 9 */
{ APC,
Back-UPS,
APC Back-UPS (940-0023A cable),
0, /* cable power: none */
TIOCM_CD, 0, /* online: CD off */
TIOCM_CTS, TIOCM_CTS, /* low battery: CTS on */
TIOCM_RTS /* shutdown: RTS */
},
And the text from the genericups man page:
- - - - - - - - - -
9 = APC Back-UPS/Back-UPS Pro/Smart-UPS with 940-0023A cable
[CP=none] [OL=-DCD] [LB=CTS] [SD=RTS]
- - - - - - - - - -
For your tests where you apply voltage directly, CP is not relevant. (I assume
your microcontroller provides its own power to the serial port control lines.)
Also, SD=RTS is the shutdown signal *to* the UPS (saying that NUT acknowledges
the UPS' low battery condition). But you mentioned pins 1 (DCD) and 8 (CTS), so
we can ignore that for now.
The way I read this, online with a good battery should be negative voltages on
both DCD and CTS. OB+LB should be positive voltages on both. On Battery (but
not yet low) should be DCD high, CTS low. (The fourth condition could occur if
the power has returned, but the battery has not yet charged.)
I am confused as to how you could get OL for both +/+ and -/- states. Your
table says Pin 1 and Pin 9, but earlier you mention Pin 1 and Pin 8. Could pin
8 have been floating during the voltage test?
You can use statserial to double-check that your serial port hardware is still
good.
--
Charles Lepple
clepple@gmail___
Nut-upsuser mailing list
Nut-upsuser@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Server Does Not Shut Down - SOLVED!
On Feb 27, 2012, at 5:25 PM, Steve Read wrote: Moving on, I have never heard of statserial but I found it on the install CD and tried it out and it is a wonderful tool that I won't forget. We should probably mention it in the genericups manual, now that I think about it. Anyone know of a similar tool for BSD? -- Charles Lepple clepple@gmail ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] Server Does Not Shut Down - SOLVED!
On Feb 27, 2012, at 5:25 PM, Steve Read wrote: I spent some time reading and thinking about your email and realized that normal (AC present, battery normal) is at -12V which is a logic low. I thought this was how I designed it but when I got funny results I convinced myself that it was +12V. Of course, the mark/space terminology and weird logic levels on TXD/RXD don't help the debugging process. I suppose this would also depend on fixing the ground pin, but if you're writing the microprocessor code yourself (and assuming you have a RS-232 line driver installed on the microprocessor board), one other thing to consider is emulating a smart UPS. This would allow you to monitor voltages and whatnot. It also provides a more solid handshake between the UPS and the server - if the driver pings the UPS and it doesn't respond, you will get log messages. The Megatec protocol has a simple ASCII query/response structure, and would be fairly easy to implement. http://trac.networkupstools.org/projects/nut/browser/trunk/drivers/blazer.c The vendor and rating strings can be constant, and the status is fixed-width fields - so it should be easy to implement even in assembly. Then again, you might not be as obsessed with graphs and logs as I am :-) -- Charles Lepple clepple@gmail ___ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
