Nut upsuser - Mar 2017 - [HCL] Cyber Power Systems EC750G supported by usbhid-ups [UPS.Output.DelayBeforeShutdown]

On 12/8/2016 10:37 PM, Charles Lepple wrote:
> On Dec 8, 2016, at 1:34 PM, Mike wrote:
>>
>> I didn't want to sign up for the nut-devs list or create a git
account
>> just to provide this information, so I hope posting this info here is
OK...
> 
> Not a problem. (Both lists go into the same mailbox on my end.) The
important part is the "HCL" subject so I can find it later.
> 
> For anyone else who runs across this: you don't necessarily need to be
subscribed to the list to send an HCL entry. It will take some time for me to
get to the moderator web page to let it through, so please be patient.
> 
>> The result of the command
>>
>> upscmd -u user -p password myups load.off.delay 300
>>
>> is an immediate power-off, no delay.
> 
> Hmm. Certainly possible that we are sending the delay to the wrong spot.
Hopefully the 300 is overriding the 20-second delay specified by
ups.delay.shutdown.
> 
> You can try restarting just the driver with debug flags - something like
the following, depending on your distribution's paths:
> 
> /lib/nut/usbhid-ups -a <name> -DDD 2>&1 | tee CPS-EC750G.log
> 
> Let it run for 45-60 seconds and then stop it with Ctrl-C. Please compress
the log with gzip before posting.
> 
Hi Charles,

Command, run on FreeBSD 11.0 (amd64)

/usr/local/libexec/nut/usbhid-ups -a myups -DDD 2>&1 | tee CPS-EC750G.log

70 seconds of output attached.


Let me know if you need anything else.  This is an 'on the shelf' spare
UPS for me, so there is some flexibility in playing with it...

thx.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CPS-EC750G.log.tar.gz
Type: application/gzip
Size: 10001 bytes
Desc: not available
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20161209/3995aac8/attachment.bin>

On 12/9/2016 11:14 AM, Mike wrote:
> On 12/8/2016 10:37 PM, Charles Lepple wrote:
>> On Dec 8, 2016, at 1:34 PM, Mike wrote:
>>>
>>> I didn't want to sign up for the nut-devs list or create a git
account
>>> just to provide this information, so I hope posting this info here
is OK...
>>
>> Not a problem. (Both lists go into the same mailbox on my end.) The
important part is the "HCL" subject so I can find it later.
>>
>> For anyone else who runs across this: you don't necessarily need to
be subscribed to the list to send an HCL entry. It will take some time for me to
get to the moderator web page to let it through, so please be patient.
>>
>>> The result of the command
>>>
>>> upscmd -u user -p password myups load.off.delay 300
>>>
>>> is an immediate power-off, no delay.
>>
>> Hmm. Certainly possible that we are sending the delay to the wrong
spot. Hopefully the 300 is overriding the 20-second delay specified by
ups.delay.shutdown.
>>
>> You can try restarting just the driver with debug flags - something
like the following, depending on your distribution's paths:
>>
>> /lib/nut/usbhid-ups -a <name> -DDD 2>&1 | tee
CPS-EC750G.log
>>
>> Let it run for 45-60 seconds and then stop it with Ctrl-C. Please
compress the log with gzip before posting.
>>
> 
> Hi Charles,
> 
> Command, run on FreeBSD 11.0 (amd64)
> 
> /usr/local/libexec/nut/usbhid-ups -a myups -DDD 2>&1 | tee
CPS-EC750G.log
> 
> 70 seconds of output attached.
> 
> 
> Let me know if you need anything else.  This is an 'on the shelf'
spare
> UPS for me, so there is some flexibility in playing with it...
> 
> thx.
> 

I have to break down my test setup as I need to use the equipment
elsewhere for a while.  So, for now, I cannot perform any further testing...

On Dec 9, 2016, at 11:14 AM, Mike <the.lists at mgm51.com>
wrote:
> 
> On 12/8/2016 10:37 PM, Charles Lepple wrote:
>> On Dec 8, 2016, at 1:34 PM, Mike wrote:
>>> The result of the command
>>> 
>>> upscmd -u user -p password myups load.off.delay 300
>>> 
>>> is an immediate power-off, no delay.
>> 
>> Hmm. Certainly possible that we are sending the delay to the wrong
spot. Hopefully the 300 is overriding the 20-second delay specified by
ups.delay.shutdown.
>> 
>> You can try restarting just the driver with debug flags - something
like the following, depending on your distribution's paths:
>> 
>> /lib/nut/usbhid-ups -a <name> -DDD 2>&1 | tee
CPS-EC750G.log
>> 
>> Let it run for 45-60 seconds and then stop it with Ctrl-C. Please
compress the log with gzip before posting.
>> 
> 
> Hi Charles,
> 
> Command, run on FreeBSD 11.0 (amd64)
> 
> /usr/local/libexec/nut/usbhid-ups -a myups -DDD 2>&1 | tee
CPS-EC750G.log
> 
> 70 seconds of output attached.
> 
> 
> Let me know if you need anything else.  This is an 'on the shelf'
spare
> UPS for me, so there is some flexibility in playing with it...
> 
> thx.
   0.207421	Path: UPS.Output.DelayBeforeShutdown, Type: Feature, ReportID: 0x15,
Offset: 0, Size: 16, Value: -60

I haven't been able to find any information on what a "-60" would
signify. The value "-1" is used to cancel a timer, so maybe the
internal timer is set in minutes, and read back with a times-60 scale factor?

In that case, I would start by setting the "ups.delay.shutdown" and
"ups.delay.start" variables to multiples of 60 seconds, and try the
shutdown command without an argument. Using e.g. 120 and 180 will tell you
whether the start timer is measured from the beginning or end of the shutdown
timer. (Should be the latter, but no need to confuse the microcontroller any
more than necessary.) If that works, we can figure out why the load.off.delay
argument is being ignored.

You should be able to read the timer for UPS.Output.DelayBeforeShutdown via the
"ups.timer.shutdown" NUT variable.

Also, when testing, you may want to make sure that you have some sort of dummy
load on the UPS, such that "ups.load" is not zero. I am only vaguely
familiar with the MGE power saving features - so I am extrapolating to CPS here
- but I would not be surprised if the UPS ignored the shutdown delay if it
doesn't think there is a load attached.

On 3/2/2017 9:57 AM, Charles Lepple wrote:
> On Dec 9, 2016, at 11:14 AM, Mike <the.lists at mgm51.com> wrote:
>>
>> On 12/8/2016 10:37 PM, Charles Lepple wrote:
>>> On Dec 8, 2016, at 1:34 PM, Mike wrote:
>>>> The result of the command
>>>>
>>>> upscmd -u user -p password myups load.off.delay 300
>>>>
>>>> is an immediate power-off, no delay.
>>>
>>> Hmm. Certainly possible that we are sending the delay to the wrong
spot. Hopefully the 300 is overriding the 20-second delay specified by
ups.delay.shutdown.
>>>
>>> You can try restarting just the driver with debug flags - something
like the following, depending on your distribution's paths:
>>>
>>> /lib/nut/usbhid-ups -a <name> -DDD 2>&1 | tee
CPS-EC750G.log
>>>
>>> Let it run for 45-60 seconds and then stop it with Ctrl-C. Please
compress the log with gzip before posting.
>>>
>>
>> Hi Charles,
>>
>> Command, run on FreeBSD 11.0 (amd64)
>>
>> /usr/local/libexec/nut/usbhid-ups -a myups -DDD 2>&1 | tee
CPS-EC750G.log
>>
>> 70 seconds of output attached.
>>
>>
>> Let me know if you need anything else.  This is an 'on the
shelf' spare
>> UPS for me, so there is some flexibility in playing with it...
>>
>> thx.
> 
>    0.207421	Path: UPS.Output.DelayBeforeShutdown, Type: Feature, ReportID:
0x15, Offset: 0, Size: 16, Value: -60
> 
> I haven't been able to find any information on what a "-60"
would signify. The value "-1" is used to cancel a timer, so maybe the
internal timer is set in minutes, and read back with a times-60 scale factor?
> 
> In that case, I would start by setting the "ups.delay.shutdown"
and "ups.delay.start" variables to multiples of 60 seconds, and try
the shutdown command without an argument. Using e.g. 120 and 180 will tell you
whether the start timer is measured from the beginning or end of the shutdown
timer. (Should be the latter, but no need to confuse the microcontroller any
more than necessary.) If that works, we can figure out why the load.off.delay
argument is being ignored.
> 
> You should be able to read the timer for UPS.Output.DelayBeforeShutdown via
the "ups.timer.shutdown" NUT variable.
> 
> Also, when testing, you may want to make sure that you have some sort of
dummy load on the UPS, such that "ups.load" is not zero. I am only
vaguely familiar with the MGE power saving features - so I am extrapolating to
CPS here - but I would not be surprised if the UPS ignored the shutdown delay if
it doesn't think there is a load attached.
> 

OK, I'll run your suggested changes and report back in a few days.

thanks.

On 3/2/2017 9:57 AM, Charles Lepple wrote:
> On Dec 9, 2016, at 11:14 AM, Mike <the.lists at mgm51.com> wrote:
>>
>> [snip]
>>
>    0.207421	Path: UPS.Output.DelayBeforeShutdown, Type: Feature, ReportID:
0x15, Offset: 0, Size: 16, Value: -60
> 
> I haven't been able to find any information on what a "-60"
would signify. The value "-1" is used to cancel a timer, so maybe the
internal timer is set in minutes, and read back with a times-60 scale factor?
> 
> In that case, I would start by setting the "ups.delay.shutdown"
and "ups.delay.start" variables to multiples of 60 seconds, and try
the shutdown command without an argument. Using e.g. 120 and 180 will tell you
whether the start timer is measured from the beginning or end of the shutdown
timer. (Should be the latter, but no need to confuse the microcontroller any
more than necessary.) If that works, we can figure out why the load.off.delay
argument is being ignored.
> 
> You should be able to read the timer for UPS.Output.DelayBeforeShutdown via
the "ups.timer.shutdown" NUT variable.
> 
> Also, when testing, you may want to make sure that you have some sort of
dummy load on the UPS, such that "ups.load" is not zero. I am only
vaguely familiar with the MGE power saving features - so I am extrapolating to
CPS here - but I would not be surprised if the UPS ignored the shutdown delay if
it doesn't think there is a load attached.
> 


You were on to the correct solution with your hypothesis of the internal
timer being in minutes.

Going back to my original notes, I noticed a typo in my very first
message about this.  I had written the command I executed as:

 upscmd -u user -p password myups load.off.delay 300

when the actual command I executed was:

 upscmd -u user -p password myups load.off.delay 30



With that in mind, I tried the following command with no load:

 upscmd -u user -p password myups load.off.delay 30

and the UPS shut off immediately.  Using my new test setup, I wanted to
duplicate the results I had gotten previously.  They were duplicated.

Then I ran the command with no load:

 upscmd -u user -p password myups load.off.delay 60

and there was a 1 minute delay, then the UPS shut off.



For the rest of this message, I have a load on the UPS.

When I specify a 59 second delay on the command line, the UPS shuts off
immediately.

  59 second delay specified - immediate shutoff
  60 second delay specified - exactly one minute delay, then shutoff
  80 second delay specified - exactly one minute delay, then shutoff
 115 second delay specified - exactly one minute delay, then shutoff
 128 second delay specified - exactly two minute delay, then shutoff

So if I had to guess, I would offer that the UPS is doing an integer
divide by 60 on the number of seconds given by the command.  That is why
my request for a 30 (and 59) second delay resulted in no delay at all.


And here is the upsc command output for the UPS in question:

# upsc myups
battery.charge: 100
battery.charge.low: 10
battery.charge.warning: 20
battery.mfr.date: CPS
battery.runtime: 1950
battery.runtime.low: 300
battery.type: PbAcid
battery.voltage: 14.2
battery.voltage.nominal: 12
device.mfr: CPS
device.model: EC750G
device.type: ups
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.synchronous: no
driver.version: 2.7.4
driver.version.data: CyberPower HID 0.4
driver.version.internal: 0.41
input.transfer.high: 140
input.transfer.low: 96
input.voltage: 118.0
input.voltage.nominal: 120
output.voltage: 118.0
ups.beeper.status: enabled
ups.delay.shutdown: 20
ups.delay.start: 30
ups.load: 21
ups.mfr: CPS
ups.model: EC750G
ups.productid: 0501
ups.realpower.nominal: 450
ups.status: OL
ups.test.result: No test initiated
ups.timer.shutdown: -60
ups.timer.start: 0
ups.vendorid: 0764


As always, let me know if there's anything else you'd like me to try...

Thanks for the assist!