Powerchute Business Edition not recording Power failure events

[MysteryGuy_apc]

Hi;

I have an old SU1400 connected to a Windows 7 64-bit system. For some reason, events like power failed and power restored don't seem to get entered in the events as seen in the 'Agent Web Interface'.

Under Events/logs I can see entries for 'Communications established', 'Monitoring started', 'Self-test Passed', etc.

But, if I drop the power to the SU1400 (and it goes on battery for a second or two), I don't see any entries added for this.

I can see the UPS load information, Initiate a self test, etc. and that seems to work.

I initially tried version 9.2, and then later tried 9.2.1 (9.0.4.601) with the same result.

I am using 'smart' signaling and an old serial interface connection.

Is this an issue with the software, or a problem with my SU1400?

Thanks;

0Y1ORWMM86pwGcW%2F5Ar%2Fyw%3D%3D&Rest-Api-Key=d3Bhc3F1aWw6NjM3MzU2MWEtNzYzMC00OTc5LTkyMTAtOTJjYTU0NGEwZWFl.jpeg

[BillP]

Hi,

I tested PCBE 9.0.4 with SU700 and the system recorded the UPS going onto battery and did power down so I suspect the issue is with the UPS you have.

You can test the unit by stopping the PowerChute Agent service and with a utility like putty hyperterminal to the unit. Baud rate = 2400, Bits Per Character = 8, Stop Bits 1, Parity = None

Once connected enter the ASCii character upper case Y and the UPS should respond with SM to tell you it is in Smart Signalling mode. Switch the UPS to battery then enter the number 9. The UPS should reply with the code 00 or FF. You can also enter upper case Q and the unit should reply with the code of 0 - 7. Which codes are returned? 

[MysteryGuy_apc]

Hi;

I used the terminal, entered Y and the UPS did respond with SM. I dropped the power to the UPS, and it returned a few '!' symbols.

The response to '9' was '00'. The response to 'Q' was '07'.  I restored the power and the ups returned '!$' by the time I got back from turning on the breaker.

I will attach the screen shot.

mBhaTDtX%2BttW3%2FBtend8tw%3D%3D.jpeg

With the power back on, '9' returned 'FF' while 'Q' still returned '07'.

In the past I only dropped the power for a second or two. If I do that, no event is recorded. But just now I restarted the Service and I left the power off for a longer time. That time I did see an entry for 'Power failed' and 'Power restored'.

Shouldn't I see an event for any length of dropout?

Thanks;

[BillP]

Hi,

9 reporting 00 when on battery and FF when on utility power is expected. Q reporting 7 indicates there is a bad battery but I would have expected Q to return 4 when on battery. Seem there may be a comm issue with the unit. You can do a reset of the unit to see if that corrects the issue.

1) Turn off and unplug UPS from wall
2) Press and hold the OFF button again
3) You may see a quick flash of the LED's and you should hear an audible "click" from the UPS.
4) Plug UPS back into the wall and turn UPS back on

[MysteryGuy_apc]

> Q reporting 7 indicates there is a bad battery but I would have expected Q to return 4 when on battery...

I think I accidentally typed 'q' the last time instead of 'Q'. So I probably got the 'Low battery minutes' instead of 'status flags'.

I reset the UPS as requested anyway, and tried again. I seem to get the same results as far as what ends up in the Powerchute logs. If I cut power for a second or two, I don't see any Power outage event recorded.

If I leave the power off for a longer time, I do seem to get an event.

I retested with puttyterm, this time making sure to enable 'local echo' so I can see what I'm actually typing. I also found a document that claims to describe smart-signaling commands.

The following seems consistent with what I would expect as described in that document.

3RCJc11ZCdgOVwdRWlFJvg%3D%3D.jpeg

I did a 'Q' and '9' while on line power and got back '08' and 'FF'. I dropped the power for a second or so and got the 'Smart Alert' for '!' = 'Line fail' followed by '$'= 'UPS back on line power'.

I redid 'Q' and '9', again receiving '08' and 'FF'.

I then dropped the line power, which resulted in two '!' line fails by the time I got back to the console.

'9' and 'Q' now returned '00' and '10'.

Restoring the power showed '$' for back on line power.

So, as best as I can tell, the Powerchute software either isn't looking at (or seeing) the power loss/restore smart alerts (maybe polling instead), or perhaps ignores them unless they persist.

[BillP]

Hi,

When you say 

On 8/29/2017 1:41 PM, Gregory said:

If I leave the power off for a longer time, I do seem to get an event.

how long of a time.

[MysteryGuy_apc]

It depends on how you count it, but it looks like 9-14 seconds.

I had someone repeatedly hitting 'refresh' on the 'Agent Web interface' 'Events/Logs' page in Firefox.

I dropped the power twice. The first time, it took about 14 seconds of refreshing to see a new event added. But, the time stamp on the event was about 12 seconds after I dropped the power.

The second time, it took about 11 seconds to see the event appear, with a time stamp of about 9 seconds after dropping the power. (Give or take a second).

The line restored event showed up in the log within a second or two of restoring power.

If I drop and restore the power for a total of only a second or so, nothing shows up in the log for that event regardless of how long I wait.

rvWzSp%2BPutGFApFK2L0eZA%3D%3D.jpeg

[BillP]

Hi,

I tested with SU700 and SUA750 models connected serially. The greatest recorded data rate change I see in PowerChute is 10 seconds after power loss. The delay you are seeing is a little longer than what I have seen.   

[MysteryGuy_apc]

I guess my questions are 

A) Is what I'm seeing specific to my setup

and

B) What is the designed behavior supposed to be?

My desire is to have any power failure (however short) reported. Or, at least have an option to have it reported if desired.

It seems that on my system the behavior is that the failure must exceed a certain length of time, somewhere around 9-12 seconds.

It sounds like what you are seeing is similar, in that power failures must exceed a minimum duration to get recorded.

Is that correct? If so, is this the expected/desired behavior?

[BillP]

Hi,

What you are seeing is expected behavior for your Model UPS. When power fails the UPS will report the issue, PowerChute must receive the data, process it, and act on it. When received PowerChute will verify that the UPS is in fact on battery. Then verify that the event has not been caused by an attached accessory and finally will post to the event log.

With newer Smart-UPS connected via serial let say a SMT1500 there is little to no delay. Switch the UPS to battery and within a second or 2 the event is posted to the PowerChute event log. The few second delay is cause by the UPS reporting, PowerChute processing the data, verifying the data, and then posting to the event log.  

[MysteryGuy_apc]

> The few second delay is cause by the UPS reporting, PowerChute processing the data, verifying the data, and then posting to the event log. 

To be clear, my concern is not that there is a few second delay between the power failing and when it gets recorded.

It's that the event is not recorded at all (regardless of delay) if the power failure doesn't persist for about 10 seconds or longer.

From my perspective a 1 second power failure is still a power failure. As it is, it appears that I can not look at an 'empty' log and be certain that short power events haven't happened earlier in the day.

For all I know there may have been hundreds of short power outages or none that day.

Looking at the 'alert' output in an RS-232 terminal appears to show that the power-loss event is reported quickly after the event (as "!"). So it would seem to the casual observer that the software would be able to know that something happened even in the short event case.

Are you saying that even newer UPSs (like SMT1500) behave the same way (as far as not ever reporting a power failure unless it lasts more than 10 seconds)?

[BillP]

Hi,

On 9/6/2017 12:55 PM, Gregory said:

Are you saying that even newer UPSs (like SMT1500) behave the same way (as far as not ever reporting a power failure unless it lasts more than 10 seconds)?

No that is not what I wrote. What I wrote was 

With newer Smart-UPS connected via serial let say a SMT1500 there is little to no delay. Switch the UPS to battery and within a second or 2 the event is posted to the PowerChute event log.

[MysteryGuy_apc · Accepted solution]

I guess I was confused by the semantics of your statement.  It seems there are two aspects to this:

A) Any delay or latency between the time an action occurs and when that action has a result,

and

B) Whether an action must be sustained to be noticed at all.

So when you said:

On 9/6/2017 1:16 PM, Bill said:

With newer Smart-UPS connected via serial let say a SMT1500 there is little to no delay

it now sounds to me like you meant that there was a 2 second latency (between when the event happened and when the event was reported), but that there was no requirement that the failure be sustained.

Is that Correct?

In that case, what did you mean for the behavior for the SU750 class you tried?

You previously said "The delay you are seeing is a little longer than what I have seen".

In my case, I see both a short latency (which I have not really measured) and a minimum required event duration without which nothing will ever be recorded at all for that event.

Since you said 'delay' I thought you meant latency (I was not complaining about any delay as much as a minimum time for the power failure to be sustained before it would be recorded in the event log at all.).