I’m looking for a plug that reports a power failure (e.g. because a fuse has blown).
It needs a battery or capacity so that it can still send a signal in the event of a power failure. ZigBee, 433 MHz radio or a Wi-Fi connection should be used for radio transmission. Can someone give me a hint on such hardware. So far I have only found solutions for HomeMatic or standalone solutions (some with their own gateway), but none that can be connected directly to openhab.
I guess the use case should be quite common, e.g. to receive an alarm if the freezer has no power. Any help is greatly appreciated.
Use a UPS that supports NUT ( Network UPS Tool )
Then your OH installation can take care for sending an alarm being triggered by the NUT binding
But how to send an alarm in case of a local power failure ? Sending may not work while acoustic alarm may work for a while.
Checking the freezers power supply by using a shelly plug and observing the power consumption may be one way. OH again would then send an alarm in case the power consumption is below a specific value for a longer time.
I use a SONOFF Basic flashed with Tasmota, connected to openHAB via MQTT. Using the LWT topics you can determine when the MQTT broker has lost contact with the SONOFF, which you can use as a proxy for the SONOFF losing power (assuming your WiFi itself is reliable).
I’m not sure this would be common. If a fuse is blowing repeatedly, I think most people would try and prevent it by reducing the load or rewiring for a higher amperage. You’d only think to monitor it if you’re into home automation like we are (and we are not common 
).
What’s the specific concern that you’re trying to address? Perhaps we can help you deal with it more at the root cause. The fact that you have fuses suggests an older building, so I’m guessing your options are limited.
Are there other appliances on the same circuit as your freezer? If that’s the case and you can’t separate them, you could use smart plugs to ensure that they don’t both run at the same time.
You could theoretically monitor power and shut one appliance down when another one ramps up, but I’m not sure that openHAB would be fast enough to react to the change in current.
Thanks for all your answers and hints.
Monitoring the last-seen-message of a smart-plug was also my first thought. However, I thought that an active message would be better, especially since there are acoustic battery-buffered devices for 5 €. The use case is a circuit breaker that tripped once within 3 years for no apparent reason. My electric system is generally fine. Maybe it was an overload from outside, I don’t know and will probably never find out if it doesn’t happen more often.
Of course, a direct acoustic alarm makes sense, but I thought a message to openhab (which of course has an ups) would be nice. And my ambition was to avoid an additional gateway and use either my rfxtrx (433mHz), zigbee or mqtt.
1 Like
I just happen to have a RPi plugged into the same outlet as the fridge I have in the garage which is on the GFI circuit (i.e. it flips off far too frequently). This RPi has a job (controls and reports the garage door opener states and has a camera) so it’s not special purpose just for this (if I needed something special purpose I’d set up a NodeMCU or the like). When the circuit trips the RPi goes offline and I which tells me, by proxy, that the whole circuit is offline. I detect it goes offline using the Network binding, though I could also use the LWT MQTT message for this purpose also like @hafniumzinc mentions.
That fridge is where we keep my wife’s insulin. It’s a pretty big deal if it goes offline. Sometimes there’s good reasons, sometimes it’s just fun.
2 Likes
Absolutely.
This seems like a good use for a Pi Zero W.
@Larsen, this gives me an idea. Put an old Android phone on that circuit and trigger messages based on its charging state. You could use Tasker or HabPanelViewer to send commands to openHAB.
@rlkoshak @rlkoshak :
many thanks for the valuable hints. I had already started your raspi-with-UPS-way, but then I restartet reading hundreds of specs in search of a leaner solution. I finally found something promising. It’s a zigbee siren that is powered by ac but has an additional backup battery and reports an ac_connected message: Zigbee-Alarm Siren with Backup Battery
I am now impatiently waiting for delivery from CN and will be happy to report if my expectations are fulfilled.
@rlkoshak: It usually starts out for good reasons but quite often drifts into a mix of fun and over-perfection
If you use any smart plug on that circuit and it keeps sending messages at regular intervals (e.g. on current consumption), why not trigger on absence of messages ?
Or reuse the comms layer and trigger upon the state of device things. Put all device thing states on that circuit into one group and use aggregation to have a monitoring item for your circuit.
That was (kind of) my suggestion too, with MQTT’s LWT topic. But it’s clear @Larsen wants an active, audible signal at source which will alarm using the battery when the power is out.
Well, you can initiate all sorts of audible alarming from OH when detected, including a siren, Alexa announcement or some such.
The advantage of processing this in OH rather than in some device is you can make the alarm more intelligent such as not to trigger during the night, wait for n minutes or m outstanding messages, run some active diagnosis before alarming etc.
I’m sure the OP will be doing all of that in openHAB anyway. The chosen device will only alarm when commanded by an external source (such as openHAB, via zigbee(2mqtt)). The ac_connected parameter is just another MQTT topic - it doesn’t internally command the device to alarm by itself.
yes, monitoring like a dead-man-switch is an option too, but I would prefer the direct way, to avoid alarms when zigbee-net or wifi is temporary down (happens often as I constantly “optimize” things).
Of course one could argue that an alarm should be raised if the transmitting network is down and I don’t have too many arguments against that.
@mstormi : No worries: Of course I stay faithfull to openhab. Everything will be handeled by openhab (like acoustic messages in the house and and sending messages via whatsapp and telegram)
@hafniumzinc: Completely correct: The siren is only for transmitting the ac_connect=false to openhab via mqtt if power is lost.
I received the siren today and made a short test:
It seems to be absolutely perfect for the job:
- Theres a small pouch lithium-ion-cell included that you can see on the photo
- A disconnection from ac is reported within a second
- If you like you can additionally use it to send an accoustic and optical signal
- Here a picture of the opened device
At the moment it’s not directly discovered by zigbee2mqtt but I raised a PR so the current manufacturer code is accepted. I can keep you informed when the PR is accepted if anybody is interested.
1 Like
You mean, the device itself will make a sound if it is disconnected from AC, without any external input?
Unfortunately not. There is no option in the config to trigger an alarm from ac-disconnect or battery-low. The alarm has to be triggered by sending a command to the item.
One additional remark: The device acts as a zigbee-router which can be quite useful to stabilize a zigbee-network.
Though note that it will stop acting as a router when on battery power, which may make any devices relying on this router unresponsive when power has been cut to this device.
Though I presume a power cut would be the bigger issue anyway…!
Well, some news about the power-outage-solution, after some weeks of experience:
-
My PR to support the actual version was merged, so the siren now gets detected by zigbee2mqtt. I cannot tell you if it would work with the OH-zigbee-binding too. But I like the additional level of control and transparency of z2m anyway.
-
The rechargable battery lasts about 2 days. @hafniumzinc: The siren always stays in router mode, even if running on battery. For me a cool feature cause this way the zigbee-net might survive longer in a power outage. In combination with a UPS for the OH-server a gain in robustness.
-
Regarding responsiveness: A power outage is immediately detected, so that it can be handeled by openhab in 1 sec. For me a plus against polling (which I wouldn’t want to do every second)
My thing definition looks as follows:
Thing mqtt:topic:Alarm1 "Alarm1" (mqtt:broker:MosquittoMqttBroker) { Channels:
Type switch : state "State" [ commandTopic = "zigbee2mqtt/Alarm1/set/warning", on="{\"mode\": \"emergency\"}", off="{\"mode\": \"stop\"}" ]
Type switch : ac_connected "ac_connected" [ stateTopic = "zigbee2mqtt/Alarm1/ac_connected", on=true, off=false ]
Type datetime : last_seen "last_seen" [ stateTopic = "zigbee2mqtt/Alarm1/last_seen" ]
}
I use a rule that reacts when ac_connected switches from ON to OFF by starting the siren, switching some plugs and sending a telegram message. Another rule stops the alarm etc. if power comes back.
@rlkoshak , @hafniumzinc: To sum it up I recommend that solution. It’s low SW- and HW-complexity, reacts within a second, is cheap (woox siren for around 20 €) and reliable (no false alarm due to wifi-problems, reboots etc).
I additionally check the LWT to make sure the device is not broken and a dead-mans-bot monitors the OH-server (but that’s another story).
2 Likes