Nut upsdev - Jan 2015 - nutdrv_qx and Best Power equipment

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/bestups
Thanks, 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

Yet again, sorry for the delay - I hope the UPS is still alive.
>> 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.
>
Implemented:
https://github.com/zykh/nut/tree/bestups

Before I merge it (well.. provided that it works..), I'd like to know
a couple of things more:
1. does the load.off command ('S00R0000') work?
2. does the 'C' command (mapped as shutdown.stop and load.on) turn the
load on if executed while the ups.delay.start time elapses after
having fired a shutdown.return?
3. (OK, I lied - 3 things more) does the shutdown.stayoff command
('SnR0000') work?

Thanks for your patience, Charles.

On Jan 2, 2015, at 7:31 PM, hyouko at gmail.com wrote:
> Yet again, sorry for the delay - I hope the UPS is still alive.
> 
No worries, although I'm going to need to rewire things to do shutdown
testing. (At the moment, I have a wireless access point and a Mac plugged in to
it, but all of my USB-to-serial cables turned out to be unsupported under the
latest version of OS X.)
> Implemented:
> https://github.com/zykh/nut/tree/bestups
> 
> Before I merge it (well.. provided that it works..), I'd like to know
> a couple of things more:
> 1. does the load.off command ('S00R0000') work?
> 2. does the 'C' command (mapped as shutdown.stop and load.on) turn
the
> load on if executed while the ups.delay.start time elapses after
> having fired a shutdown.return?
> 3. (OK, I lied - 3 things more) does the shutdown.stayoff command
> ('SnR0000') work?
> 
> Thanks for your patience, Charles.
I'll see what I can do this weekend.

-- 
Charles Lepple
clepple at gmail

On Fri, Jan 2, 2015 at 7:31 PM, hyouko at gmail.com <hyouko at gmail.com>
wrote:
> Before I merge it (well.. provided that it works..), I'd like to know
> a couple of things more:
> 1. does the load.off command ('S00R0000') work?
load.off works.
> 2. does the 'C' command (mapped as shutdown.stop and load.on) turn
the
> load on if executed while the ups.delay.start time elapses after
> having fired a shutdown.return?
I only tested the following case, but yes:

1) removed power
2) ran shutdown.return
3) waited for 30-second shutdown timer; UPS turns off
4) reconnected power
5) before 180 second power-on timer elapses, run load.on
6) UPS turns on
> 3. (OK, I lied - 3 things more) does the shutdown.stayoff command
> ('SnR0000') work?
shutdown.stayoff does not work - the UPS turns on immediately after
its usual (~5 second) self-test.

I tried it with both the default 30-second ups.delay.shutdown
(S.5R0000), as well as 60 seconds (S01R0000).

I don't think this is a regression for my model, although the docs
suggest sending the command without the "R####":
http://buildbot.networkupstools.org/~buildbot/cayman/docs/latest/protocols/sola.html#_shutdown_command

-- 
- Charles Lepple