On Nov 1, 2014, at 9:28 PM, hyo...@gmail.com wrote: > Provided that the subdriver works, I'd like to see, if possible, the logs of: > - driver startup > - a command that succeeds > - a command that fails > - q1 when online and all's ok > - q1 on battery > - setting pins_shutdown_mode
Attached is a log of most of these conditions. Looks like reading the status for pins_shutdown_mode does not work on my UPS. (The manual describes fixed timeouts in the pinout section, so that makes sense.) 9.562389 Using protocol: BestUPS 0.01 9.562405 upsdrv_initinfo... 9.562480 send: 'Q1' 9.772351 read: '(119.0 118.1 118.1 020 60.0 13.9 XX.X 00101000' 9.772424 ups_infoval_set: non numerical value [ups.temperature: XX.X] 9.772530 send: 'ID' 9.896340 read: 'PR2,400,120,120,10.8,13.6' 9.896482 send: 'RT' 9.927323 read: '053' 9.927433 send: 'SS?' 10.928470 read: timeout (0) 10.928491 qx_process_answer: short reply (pins_shutdown_mode) The set of instcmds looks good: $ upscmd -l ppro2 Instant commands supported on UPS [ppro2]: shutdown.return - Turn off the load and return when power is back shutdown.stayoff - Turn off the load and remain off shutdown.stop - Stop a shutdown in progress test.battery.start - Start a battery test test.battery.start.deep - Start a deep battery test test.battery.start.quick - Start a quick battery test test.battery.stop - Stop the battery test I ran test.battery.start here: 83.411009 instcmd(test.battery.start, [NULL]) 83.411094 send: 'T10' 84.412120 read: timeout (0) 84.412151 instcmd: SUCCEED and the test started. Status looked like this during the test: 87.412958 read: '(119.9 119.9 120.0 029 60.0 12.9 XX.X 00001100' Test stopped successfully: 114.998222 instcmd(test.battery.stop, [NULL]) 114.998469 send: 'CT' 115.999538 read: timeout (0) 115.999573 instcmd: SUCCEED I ran the shutdown.return command while the UPS was still on AC: 197.276833 instcmd(shutdown.return, [NULL]) 197.277314 send: 'S.5R0003' 198.278346 read: timeout (0) 198.278366 instcmd: SUCCEED Sure enough, it turned off after about 30 seconds (t=228). I unplugged it for about five seconds, and it came back on three minutes after I plugged it back in. However, the bypass bit inversion might be responsible for this: 228.304623 send: 'Q1' 228.515426 read: '(119.0 119.0 000.0 000 60.0 13.5 XX.X 00001010' 228.515494 ups_infoval_set: non numerical value [ups.temperature: XX.X] 228.515506 blazer_process_status_bits: output voltage too low 228.515510 Communications with the UPS lost: status read failed! Similarly, when I unplugged the unit around t=638, I also got "data stale" messages from upsd (probably at t=662.124768). I let it run the battery down, and plugged it back in just before t=2617.617643. Let me know if you would like me to add any more debugging code for the bypass/boost/buck bits. -- Charles Lepple clepple@gmail
qx_bestups.2014-11-02.g375c9ea.log.gz
Description: GNU Zip compressed data
_______________________________________________ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev