[Nut-upsdev] nutdrv_qx and Best Power equipment

[Charles Lepple]

On Nov 1, 2014, at 9:28 PM, hyouko at 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 at gmail


-------------- next part --------------
A non-text attachment was scrubbed...
Name: qx_bestups.2014-11-02.g375c9ea.log.gz
Type: application/x-gzip
Size: 75724 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20141102/110f5e98/attachment-0001.bin>