Hi Daniele, I finally got a Best Power Patriot Pro II fixed up with a new battery and cable, and tried it with nutdrv_qx (since it uses a variant of the Q1 protocol). It auto-detected the use of Q1. It looks like things mostly work: bestups: battery.charge: 100.0 battery.voltage: 13.9 battery.voltage.nominal: 12 device.mfr: Best Power device.model: Patriot Pro II 400 device.type: ups driver.name: bestups driver.parameter.pollinterval: 2 driver.parameter.port: /dev/ttyUSB0 driver.version: 2.6.4 driver.version.internal: 1.06 input.frequency: 60.0 input.voltage: 119.9 input.voltage.nominal: 120 output.voltage: 119.9 output.voltage.nominal: 120 ups.load: 000 ups.mfr: Best Power ups.model: Patriot Pro II 400 ups.status: OL nutdrv_qx: battery.voltage: 13.90 device.type: ups driver.name: nutdrv_qx driver.parameter.pollfreq: 30 driver.parameter.pollinterval: 2 driver.parameter.port: /dev/ttyUSB0 driver.version: 2.7.2-signed-65-gefa7bc9 driver.version.data: Q1 0.03 driver.version.internal: 0.12 input.frequency: 60.0 input.voltage: 119.9 input.voltage.fault: 119.9 output.voltage: 119.9 ups.beeper.status: disabled ups.delay.shutdown: 30 ups.delay.start: 180 ups.load: 0 ups.status: OL BYPASS ups.type: offline / line interactive A few observations: 1) The bestups driver uses an "ID" command to retrieve the model and rating. I didn't see that exact string in the nutdrv_qx source - would the best place for that be in nutdrv_qx_q1.c, or a new source file? (I don't think there are too many differences with the other Q1 models, but I defer to your opinion on this.) 2) The Patriot Pro models have an inverted BYPASS bit: https://github.com/networkupstools/nut/blob/master/drivers/bestups.c#L63 (nutdrv_qx does log a message that the fault voltage is not as expected, but with the ID string, this bit could be inverted in the driver for those models) 3) I don't think the UPS has a serial command for setting the beeper status. (There is a button on the front panel.) At least, bestups.c does not mention it, and neither does the protocol document: http://www.networkupstools.org/protocols/sola.html Still haven't tried the instant commands or LB, but I should have some time for that later. Also, if you would like, I can generate and send some logs of Q1 responses to integrate into the "#ifdef TESTING" block. Thanks, -- Charles Lepple clepple at gmail
> I finally got a Best Power Patriot Pro II fixed up with a new battery and cable, and tried it with nutdrv_qx (since it uses a variant of the Q1 protocol). It auto-detected the use of Q1. > > It looks like things mostly work:Nice, merging bestups.c into nutdrv_qx has been on my todo list for a while, let's see how far we can get.> 1) The bestups driver uses an "ID" command to retrieve the model and rating. I didn't see that exact string in the nutdrv_qx source - would the best place for that be in nutdrv_qx_q1.c, or a new source file? (I don't think there are too many differences with the other Q1 models, but I defer to your opinion on this.)I'd prefer keeping Q1 as a light fallback subdriver. Here's a first version: https://github.com/zykh/nut/tree/bestups> 3) I don't think the UPS has a serial command for setting the beeper status. (There is a button on the front panel.) At least, bestups.c does not mention it, and neither does the protocol document: http://www.networkupstools.org/protocols/sola.htmlMe too, the 'Q' command otherwise used as beeper.toggle, here is used as an alternative version of 'Q1': removed it from the subdriver.> Also, if you would like, I can generate and send some logs of Q1 responses to integrate into the "#ifdef TESTING" block.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 Also, I'd like to know whether the 'C' command (shutdown.stop) works also as a load.on like in other megatec implementations or not and if the 'SnR0000' command (shutdown.stayoff) has any effect on the UPS, as they are not in the specs ('C' is only described as a shutdown.stop).
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 startupExcellent, that worked well (commit 375c9ea). The startup log with -DDD is attached. I'll try the commands tomorrow when I can get a dummy load attached. Also: $ upsc ppro2 battery.charge: 100 battery.runtime: 6180 battery.voltage: 13.90 battery.voltage.high: 13.6 battery.voltage.low: 10.8 device.mfr: Best Power device.model: Patriot Pro II device.type: ups driver.name: nutdrv_qx driver.parameter.pollfreq: 30 driver.parameter.pollinterval: 2 driver.parameter.port: /dev/ttyUSB0 driver.version: 2.7.2-signed-128-g375c9ea driver.version.data: BestUPS 0.01 driver.version.internal: 0.13 input.frequency: 60.0 input.voltage: 119.9 input.voltage.fault: 119.9 input.voltage.nominal: 120 output.voltage: 119.9 output.voltage.nominal: 120 ups.beeper.status: disabled ups.delay.shutdown: 30 ups.delay.start: 180 ups.load: 0 ups.power.nominal: 400 ups.status: OL ups.type: offline / line interactive This is with a Keyspan USA19 USB-to-serial adapter. I think the modem control lines work, but at the moment, the cable only has Tx/Rx/GND wired up. -- Charles Lepple clepple at gmail -------------- next part -------------- A non-text attachment was scrubbed... Name: qx_bestups-g375c9ea.log.gz Type: application/x-gzip Size: 1477 bytes Desc: not available URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20141101/d070f4b4/attachment.bin>
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>