Need tips for detecting AC power failure

123

Senior Member
I need the ability to detect when household AC power is lost and restored.

I have an M1 and I believe the simplest technique would be to look for events "1138 = AC FAILURE TROUBLE" and "1158 = AC FAIL RESTORE". The M1 automatically reports events via its serial/ethernet port using command "LD - System Log Data Update" so there'd be no need for my HA application to poll for status. A recent firmware upgrade introduced the new "System Trouble Status (SS)" command, it includes AC status, but you have to poll the M1 to acquire this information.

I also have a Tripplite UPS powering my HA server. There may be some sort of software hook into Tripplite's UPS driver, or maybe via Windows WMI, that'd let me monitor the AC status. I couldn't find anything of the sort documented on Tripplite's site. Plus, I never bothered to install the monitoring software because of its onerous size (20Mb download ... to shutdown a PC?).

It seems like monitoring the M1's events is the simplest technique. It could also serve as the means for sending a shutdown signal to my PC (thereby eliminating the need for a 20MB UPS driver).

How are other Cocooners handling this?
 
Hi 123,

The 20MB UPS drive should be monitoring the battery status and only shut down the PC when the battery is nlow. If you have the ELK send a shutdown signal to the PC upon power loss it woudl be immediatly and defeat the purpose of being able to ride out short interuptions.

I suppose you can put a delay on the signal, but the UPS driver is intended for that purpose. 20MB seems like a lot for what function it provides (early games on my 268 computer took 1MB of ram, what happened to the programing skills)!!!

Can you a a management card to the UPS and connumicate with it though SNTP or something?
 
The 20MB UPS drive should be monitoring the battery status ...If you have the ELK send a shutdown signal to the PC upon ...defeat the purpose of being able to ride out short interuptions.
...
Can you add a management card to the UPS and connumicate with it though SNTP or something?

I agree that UPS monitoring software would provide the best protection for the PC. However, the Java based application from Tripplite (the Java Runtime Environment probably makes up most the download size) doesn't claim to provide any hooks for other programs (maybe that info is buried deep in its manual; I don't know). I'd like my HA app to perform other duties when AC failure is detected ... not possible if the UPS software won't talk to anything.

Upon detection of AC failure (via the M1), it would trigger a 15 minute timer. Upon timer expiration, the PC would be shutdown. If the AC is restored prior to the timer's expiration, the timer would be purged. It is not as accurate as using UPS software because it doesn't take into account other factors like your example about a weak battery. However, it eliminates the need for connecting the UPS to the PC via another precious RS-232 port.

The UPS is basic; there's no ability to add SNMP support.

If anyone knows the serial protocol used by Tripplite's UPS, I could whip up a driver and have Premise monitor the UPS directly. Alternately, if anyone knows how to hook into Tripplite's UPS driver, or via WMI, that's be good too.
 
Well I know that the M1 will trigger a rule immediately (a second or two) when AC power fails, I believe this is "Whenever AC Power Fail" but am not sure right now. I know because I have a cell ping set up for this and it works. Whether the M1 blurts an ASCII string promptly on AC failure, I don't know, but it is certainly easy to test (you probably have already done so?).

The actual M1 alarm condition associated with AC power failure has a delay of (I recall) 15 minutes.

I would use a wall wart to a zone with a diode bridge and a small cap if the M1 did not already have this fast response ability.
 
Well I know that the M1 will trigger a rule immediately (a second or two) when AC power fails, ... The actual M1 alarm condition associated with AC power failure has a delay of (I recall) 15 minutes....
In ELK RP the trigger conditions are:
Whenever > Miscellaneous System > Troubles > Power Supv Zn - AC Trouble
Whenever > Miscellaneous System > Restorals > Power Supv Zn - AC Trouble Restore


I could have these rules transmit an ASCII string that is received by Premise via my ELK M1 driver (shameless plug). Alternately, my driver already exposes the last logged event; I can have a script fire whenever EventID is 1138 or 1158 (i.e. AC Fail/ AC Restore).

I haven't experimented with how the M1 responds to an AC failure. I was not aware of the 15 minute delay you described. I assume this is a grace period before the M1 reports an AC failure to the central? If it applies all of the time, that would mess up my plans.
 
123,

The Elk driver I developed for Girder is capable of notifying Girder within a few seconds that the Elk has lost AC power via the SS command. When the Elk loses power the SS message is sent with that flag shown as Trouble, when AC is restored the command is sent shown as Normal.
 
When the Elk loses power the SS message is sent with that flag shown as Trouble, when AC is restored the command is sent shown as Normal.

Seems like you have your answer.

FWIW, according to the logs, the 1138 code occurs after a 15 minute delay, meaning that AC failures briefer than that are not recognized or reported via 1138.

Also FWIW, the rule "WHENEVER AC FAILURE TROUBLE IS DETECTED" is triggered after a short delay, 10-15 seconds (correcting my earlier post where I said one or two seconds).

Note this rule is not created from the Miscellaneous / Troubles / Power Supv Zn selections, instead it is Miscellaneous / Troubles / AC Power Failure.

Dave
 
Thank you everyone for your quick and helpful replies.

Lagerhead, you are right, sir! I cut power to the M1 and it didn't announce anything nor transmit a log event. I didn't bother to wait 15 minutes; there is clearly a delay in effect.

According to the manual, the delay is adjustable and designed (I guess) to prevent reporting brief outages to a central. I hesitate to reduce this delay; I'll have to scrap the idea of triggering on a log event.

Thanks for the clarification regarding the correct location of AC Failure. A 10-15 second delay is acceptable. I don't have ELK RP handy at the moment, but unless there's a complementary AC Failure Restore this technique may be a blind alley as well.

Harleydude, my M1 isn't flashed with latest firmware so I don't have access to the SS command. Is it broadcasted upon AC failure or is your driver polling for status? Your post suggests SS is broadcasted whereas the documentation (V1.70) implies polling is required.
 
123,

I am at the latest firmware for the Elk. I just went to the closet and yanked the power supply for the Elk from the outlet. Takes about 10 seconds for the Elk to broadcast the SS command, but yes it does send it without being polled. Plugged it back in and took a couple of seconds to indicate AC was restored.
 
i use a wall wart that is connected to a digital input of my HA controller.

x2, also remember you can control when the machine boots in the same manner. Often for me anyway the power flickers back a couple times before service is fully restored. By having a second timer of say 15 minutes after power restored you can avoid all that.
 
I haven't purchase my Elk (yet), but couldn't you energize a NO relay with a wall wart, connect to a NC zone input? You should be able to know instantly when power fails or is restored. Or am I missing something?
 
I haven't purchase my Elk (yet), but couldn't you energize a NO relay with a wall wart, connect to a NC zone input? You should be able to know instantly when power fails or is restored. Or am I missing something?

Sure. Given the nature of the M1 zone inputs (powered, with 2.2k pull-up resistors), this might be a better solution than a direct connection. Not sure how this would react to very very brief interruptions, however.
 
As was mentioned you run a timer so the controller would see the open and wait until the timer expires, if it closes before it expires the timer stops and a variable set and the power header on the mainboard is shorted momentarily. When it closes a second timer starts and any opens restarts it (power flickers coming back on) when it expires the power switches on the mainboards are shorted again to boot the machines.
 
Back
Top