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_modeAttached 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>
> 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.My fault, I missed this line: https://github.com/networkupstools/nut/blob/master/drivers/bestups.c#L396 Apparently, the bypass/boost/buck bit is not reliable also when the UPS is performing a battery test (6th bit set to 1) or a shutdown is active (7th bit set to 1). Now it should be fixed: https://github.com/zykh/nut/tree/bestups I noticed that your UPS seems to support the 'M' command as a query of some sort (it replies '0'): now I'm curious as to what it does mean. It could be the 0-9 index of the user-settable voltage limits, page 19 of: http://www.gruberpower.com/pdf-files/Best%20Power%20Patriot%20Pro%20II%20User%20Manual.pdf Could you try and change it and see what happens to the 'M' reply? Or maybe it's a status of some sort: the driver now keeps querying the UPS with 'M', so if you could try and put it in some different conditions we can see whether the reply changes or not. One more question: when the UPS went on battery, did you silenced the beeper through the button on its case? If so, the beeper status bit (8th) stays true to the specs, always at 0, and it's not worth considering its value.
On Nov 7, 2014, at 5:31 PM, hyouko at gmail.com wrote:>> 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. > > My fault, I missed this line: > https://github.com/networkupstools/nut/blob/master/drivers/bestups.c#L396 > Apparently, the bypass/boost/buck bit is not reliable also when the > UPS is performing a battery test (6th bit set to 1) or a shutdown is > active (7th bit set to 1). > > Now it should be fixed: > https://github.com/zykh/nut/tree/bestupsThanks, that works better. I have it charging now; I'll try some more shutdown tests tomorrow.> I noticed that your UPS seems to support the 'M' command as a query of > some sort (it replies '0'): now I'm curious as to what it does mean. > > It could be the 0-9 index of the user-settable voltage limits, page 19 of: > http://www.gruberpower.com/pdf-files/Best%20Power%20Patriot%20Pro%20II%20User%20Manual.pdf > Could you try and change it and see what happens to the 'M' reply?It seems to match. I can do some variac testing some other time, but the current setting (0) corresponds to the LED pattern for the first entry in the table. When I incremented it a few times, it increased.> Or maybe it's a status of some sort: the driver now keeps querying the > UPS with 'M', so if you could try and put it in some different > conditions we can see whether the reply changes or not. > > One more question: when the UPS went on battery, did you silenced the > beeper through the button on its case? > If so, the beeper status bit (8th) stays true to the specs, always at > 0, and it's not worth considering its value.I don't remember which times I silenced it manually, but the logs from today show it as 0. -- Charles Lepple clepple at gmail