Power failure restore - recommended products and thoughts

Hi all,

For my second topic posted in the community, I thought I’d pull together some thoughts around possible solutions for smart IoT (especially for light bulbs) in the event of power failure.

As a background for anybody stumbling on this topic, I’ve been researching for some time around deploying smart home tech. But one concern I have had was that if there were a power cut, having the light bulbs switch on with power restore in the bedrooms would be an annoyance. In my searches, I’ve found a number of off-the-shelf solutions, but all seem to be fairly expensive or seemingly needlessly complicated. And I’ve found it difficult to find a definitive list of off-the-shelf products, and a lot of the time product listings don’t indicate support.

So, I’d like to compile a list of options for people to buy which would enable either ‘return to last state’ or ‘default to off’ capabilities on power restore.
And, I’d also like to start a discussion around possible solutions which don’t include products with native support for ‘return to last state’ or ‘default to off’.

In terms of the list of options, I’d like to break it down by smart hub (smartthings/hue/IKEA hub etc) so those looking for devices can jump straight to the ecosystem(s) you are using. Also, items I add to the list will be proven to work by smartthings community members (I’d like to include the names of those who use the solutions)

List of off-the-shelf products with ‘return to last state’ or 'default to off’

Smartthings hub v3

  • bulb name, model and manufacturer (W/RGB/RGBW/ etc) [additional requirements needed to achieve the function if any] - return to last state and/or default to off - used by XXX and xxx
1 Like

Now, to start the discussion on possible solutions that don’t include off-the-shelf products…

I was thinking of this the other night and thought it am interesting line of thought.

My thoughts

So, I’m thinking it’s possible to put the modem (possibly primary router if necessary) and the smartthings hub on a UPS.

This would mean that in the event of a power cut, the bulbs would lose power, but the smartthings hub would continue to have connection to the STCloud.

Then we would need something on site that would recognise the power failure, for instance a RPi (this could be identified via USB connected to the UPS).

On power resume, the RPi could then communicate with the ST API to send a ‘turn off’ command to all bulbs that should stay off.

This message could be repeated multiple times, to catch bulbs that take a little time to reconnect to the hub.

Of course this would mean that the bulbs would come on, but should turn off pretty quickly after.

It is of course possible that a power cut might also cut off your internet feed, but in my experience this doesn’t usually happen.

What do you think, is this a feasible solution? Or am I being stupid?

As far as the UPS route, Quite a few people have done this in the past, and there are a number of existing threads and project reports on it.

Here’s the FAQ on planning for outages. (The topic title is a clickable link). I would start with that because it’s summarizes a lot of the issues you are likely to run into that you may not be aware of.

After that, you can take a look at some of the existing project reports on the following list:

https://community.smartthings.com/tag/project_power

Just remember that smartthings is primarily a cloud-based system. Providing back ups for power and internet connectivity are helpful for some people, but if the smartthings cloud is out, or if there’s an undocumented platform change that causes some of your stuff to stop working, there just isn’t anything you can do about that. :disappointed_relieved:

In fact, there is very likely to be at least one or two very small outages every single month, just because historically there always has been. Smartthings issues hub updates that individual customers can neither defer or deny, and they will take your hub off-line. Sometimes only for a minute or two, but sometimes for considerably longer.

But again, read the FAQ, it discusses the various points of failure, and then you can start to get a sense of whether it’s worth it to you to invest a lot of money and time and creativity into improving, say, three of five weak points when you know there’s nothing you can do about the other two :thinking:

With regards specifically to lightbulbs, we already discussed this in your other thread, but I just put this here for people who might come in because of this particular topic title. :bulb:

Most Zigbee lightbulbs will turn on to bright full power after a power cut and restore because that way they could be sure the bulbs would work like a regular bulb if someone used the wall switch. So that’s how most smart bulbs were introduced to the market.

Of course, it quickly became clear that this was incredibly annoying if there was a power outage at the house, then the power was restored, and every smart bulb came on to full brightness. :scream:

Eventually Hue offered a very elegant solution for Hue devices connected to a hue bridge. You get three choices for each individual bulb for the “power restore Behaviour”

  1. Default. turn on 100%, warm white. This works for dumb light switches, although over time it can shorten the life of the radio inside the bulb.

  2. Power Loss Recovery. after a power restore, the bulb restores the same settings it had when the power was cut. So if it was off, it stays off. If it was on, it comes back on.

  3. Custom. You can have the bulb come onto any color, brightness, that you choose. For example, if you want to have one bulb come on to red as a signal that there was a power outage and restore, you can do that.

Obviously, this is very cool, but at least the last time I checked it only worked with Hue brand devices, not the other brands like IKEA and INNR that can also work with hue bridge.

Osram Sylvania offered two of these options (not custom) for their bulbs connected to their lightify gateway, but again the last time I checked there was no way to create those settings and then have them carry over to Bulbs that you were using with smartthings. And Osram is shutting down their Lightify service this summer, so their gateway isn’t going to work anymore anyway.

So those are the two I know.

By the way, feel free to create a page in table format for this information in the community – created wiki. That way everybody can contribute to it, it can be updated as needed, and you can link back to this thread for discussion. :sunglasses:

You can put it in the following category, just don’t use the template for that category because that’s intended for one device per page.

https://thingsthataresmart.wiki/index.php?title=Category:Officially_supported_devices

If you go that route, make sure you disable the alarm on it. The UPS beeping every 30 seconds is far more annoying then a bulb coming on if there is an outage. Most alarms on UPS’s are enabled by default.

I generally use smart switches over smart bulbs. The inovelli red series swiitches can be configured for on/off/last state after a power outage.

1 Like

Here an old discussion and solution?

1 Like

Hi @JDRoberts

Thanks for linking to this

My thoughts were specifically around power outage

For clarity, for points of failure as identified on the linked page are:

  1. Mains Power
  2. The Hub Itself (device failure)
  3. Local WiFi/LAN (The Internet might be up, but your own Wi-Fi router is not working)
  4. Internet Connection
  5. The SmartThings Cloud

Let’s assume, for the time being that: internet connection will not go down; the smartthings hub will not fail; the hub is connected to the network via cable meaning any wi-fi failure would not impact; the internet connection would not fail.

It’s worth mentioning that failure in items 2-5 would not cause the lights to come on in the middle of the night. In fact each of those items would simply cause the automations to stop working.

So, I will continue to read some of those topics in the community to see if anything else comes to light.

I think that, without hardware/firmware that has the specific options/capabilities built in (such as the hue bulb and hue bridge), we can only hope for something that reduces disruption as much as possible.
If I (and others) are to implement our own code utilising the smartthings API, it doesn’t seem a leap to me to have a script that is activated on power restore. A script that would send a ‘turn off’ command to the necessary bulbs
To implement this we would need:

  • to keep a persistent internet connection between the smartthings hub and smartthings cloud
  • to have a device on site, to host code/hardware that would detect a power restore, and to keep a persistent internet connection between it and smartthings API

I do have a question:
When an instruction is sent to turn on a bulb (for instance through the API),
Does the STHub know for sure the bulb has switched on, or does it send the message and assume that the message was received, understood and obeyed?

The hub doesn’t necessarily know, and never knows for many of the most popular smart bulbs, because they are Wi-Fi or other “not hub connected“ protocols and don’t communicate with the hub.

As far as to whether your account knows, that comes back to the first rule of home automation: “the model number matters.“ Some bulbs send an acknowledgment, some don’t.

1 Like

The issue with this is that after a power outage, household behavior may be very different than normal. And a power outage might be only a few seconds or hours long. :thinking: If someone is in the middle of walking down the staircase, and they turned the switch on manually for the bulb prior to your whole script operation running, do you really want to turn the light off before they get to the bottom of the staircase?

And If the power outage was caused by a fire or a pipe breaking, you don’t necessarily want all the lights off once your home automation backup kicks in.

So I do have concerns about trying to automate these unusual events.

I’m most comfortable with the idea of restoring to exactly the setting when the power went out if the operation is local and very quick, which is true for the hue bridge. It’s unlikely that a person could even get to the light switch before the Hue Bridge power restore event would have occurred.

But anything based on custom code in smartthings is likely to have a 2 to 3 second lag, maybe more. More than enough time for a person to hit a wall switch which would then be turned off by the automated system.

But again, it depends on your specific household and needs. Just something to keep in mind.

1 Like

Hi @JDRoberts

I agree that what people want to happen when the power comes back on will have to be thought about very carefully, and will vary between different people and perhaps even between houses.
In my case I would want lights in bedrooms to go off. Lights in hallways and living room/kitchen/etc can all come on as would be expected and would mean all areas (like stairs) would be lighted avoiding any dangerous situations.

I accept that the hue setup will give the best results, but I have to accept that cost is a huge consideration. For instance, my bedroom has 4 ceiling bulbs and 2 bed side lamps. Your looking at approximately £40 for the hue hub, plus £40-£50 per colour bulb - close to £300. If we can find a (not perfect) solution that uses products that don’t natively support the ‘return to last state’ or ‘default off’, this could be done at £10 a bulb (maybe less with multi packs), plus ups (seen for about £40), plus a rpi - closer to £120 with the Extra bonus that doing the same in other bedrooms will cost just £10 per bulb instead of £40+. I could do all of my bedrooms for approx a quarter of the cost of Hue.

Now I have to say, I like the canary bulb solution. It is almost the same as what I’m proposing.
With a canary bulb, people are polling the bulb every X seconds/minutes to see if it is on, and if it is on that means the power must have gone out and restored, which triggers the process to turn off the bulbs (whatever that looks like). If this script runs every 2 minutes (for example), you could be waiting upto 2 minutes between the lights coming on, and the script turning them back off
What I’m thinking is that using a ups and a rpi (or other computer), a script can be triggered immediately when the power resumes, meaning the time between the light coming on and going back off again will be much quicker, potentially only a fraction of a second.

Of course it’s possible this could be done without a rpi. I’ve heard that some bulbs may announce to ST that they have been switched on/powered up. This could be used as the trigger for our script, and would need only 1 bulb like this in the house to work.

One last thought.

But anything based on custom code in smartthings is likely to have a 2 to 3 second lag, maybe more. More than enough time for a person to hit a wall switch which would then be turned off by the automated system.

I agree that it could be quicker to get out of bed and press the wall switch - in my case, if either of us step out of bed we’re not likely to be able to get back to sleep (especially having to them go round turning the lights off in the kids bedrooms), where as even if a light comes on and wake us up, as long as it goes back off within a few seconds it shouldn’t disrupt our sleep that much.
Also, using a ups on the ST hub will mean that the connection to battery operated smart switches will never be lost. Without the ups you are relying on the ST hub powering up, booting up and reconnecting to SM Cloud, and both the button and bulb reconnecting to the ST hub, all quicker than the bulb being powered up which is where the inherent delay would exist. With the ST hub always powered and connected, the delay would only be between the bulb powering up and becoming able to receive instructions from the ST hub which should be pretty instant.
It’s worth noting as well that during the delay waiting for the ST hub to boot and reconnect to cloud, any smart buttons wouldn’t work, even though the bulbs would already be on.

They will if the mains powered repeaters they depend on to get their messages to the hub are still off power.

That’s why this kind of planning depends so much on the tiny details of the specific setup. :thinking:

Sorry if I wasn’t clear. My concern isn’t for someone using a switch to turn a power-restored bulb off.

It’s that there are so many unpredictable scenarios for a power outage. Some examples.

  1. it’s 8 pm. Everyone is moving around downstairs. There’s a loud bang outside. (Probably a transformer blew.) The lights go out. the lights come back on a minute later. Someone starts going up to make sure no windows are broken. 10 seconds later the automatic script turns the stairway light off again. :face_with_hand_over_mouth:

  2. it’s late at night. Everyone is in bed. The power goes off and comes back on after a few minutes. The lights come on. You wake up and feel a draft from the hallway. (This time, a window has broken.) You start walking down the hall and the automatic script turns the lights off.

  3. similar to 2, but this time you smell something odd. The smoke alarm is not going off, though. And the power only went out in one part of the house—not the part you’re in, but the part that triggers your power restore logic. In fact, the power in that area is going on and off rapidly a couple of times. You get up, turn on the lights where you are, and the automatic script activates and turns them off. You hit the wall switch, but because the automatic script repeats, it turns it off again. (BTW, what you smell is ozone: a space heater is overheating, causing a local circuit overload.)

———

There are multiple additional possible scenarios, including some where whatever caused the power outage also caused an injury. Or a fire.

The point is that a power outage is an unpredictable event usually caused by other unpredictable events, some of which need to be immediately investigated. Some of which cause damage to the house or injuries to pets or people.

The automatic script assumes that the residents want to stay in bed and keep sleeping during both the outage and the restoration. Which is unquestionably the time when lights coming back on is annoying. But there are many other possible scenarios associated with a power outage, and in some of them the lights repeatedly turning themselves off will not be the desired Behaviour. It’s one of the tricky parts of this kind of planning. :thinking:

1 Like

This is true.
It’s worth being a bit more detailed in my circumstances, but of course others may be different.

I have all of my data services enter the house into a cupboard in my office which is located upstairs. I’ve tested a button in all the bedrooms with no other devices powered and the signal seems to be stable.

I’ve told this story before, but I think it’s the best example, so I’ll tell it again. :wink:

Mesh is tricky. Messages can and do bounce around the network and In all kinds of different paths depending on what’s going on at that exact moment.

Zigbee messages, for example, are tiny, and as a low power protocol, can easily get drowned out by strong wifi.

But they can also get blocked by a lot of different physical objects in the environment. If a refrigerator door is open or a car is in the garage when the space was previously empty or just people are walking around, or water is running through the pipes in the walls, a direct path may get blocked.

I had one engineering course where the exam was the description of a scenario where everything in an automated house had worked great during installation and while the house was being shown.

Once it was sold and the family moved in, though, lots of things stopped working reliably. We had to go through and mark everything on every room that might be causing a problem.

The one that nobody got was in the kitchen. The family had a set of cast-iron pans and depending on who was doing the dishes there was a big frying pan that might be put on the left side of the shelf or the right side of the shelf. On the left side of the shelf, no problem, all the automated systems kept working. On the right side of the shelf, though, it happened to block one of the only pathways for signal in and out of the kitchen to a switch by the sink (kitchens are notoriously tricky because of the big metal objects in them).

If the house is small enough, not many people live there, routines are fairly consistent, and the battery powered button lives in just one place and doesn’t move around, then, sure, you may have a reliable path to the hub even from across the house. But it’s not how most field techs would design an installation. And even more so if you’re assuming one of those unpredictable power outage events.

But everybody has to design for their own preferences and priorities, so as long as you’re aware of what the issues might be you can go ahead with any plan that meets safety code and seems good to you. :sunglasses:

BTW, I am aware of two devices (one zigbee, one zwave) that are normally mains Powered but will switch to their own built-in battery if there’s a power outage and will continue to repeat for a few hours. these are intended to provide continuous support for battery-powered security sensors during power outages. I think they can be useful in planning for outages.

The first one is Zwave, latest technology, currently supported by the manufacturer, and is a solid and simple device. Literally the only thing it does is act as a repeater, which normally I wouldn’t recommend, but the switch to battery power makes it useful for some specific situations.

The next one is zigbee, and sounds wonderful, but the problem is it was literally the last device released by centralite before their bankruptcy and the product description doesn’t match what it actually does. It says it’s an RGBW nightlight and that you can control the colors from your home automation system. As far as I know, you can’t. It’s just an on/off light. there’s a tap pattern on the device itself that will let you change the colors, but not via the network. Also some product description say it has a temperature sensor inside, it doesn’t. Finally, some product description said you would get a notification if it switches to battery power, and that doesn’t seem to have been implemented, either.

Next, the company went through re-organization and sale and basically there’s nobody who’s going to support this device if it doesn’t work. So only buy it from a retailer that will take a return if it’s defective.

But you can still sometimes find some for sale, and again, it might be worth considering for some situations.

The company was a good company (they made some of the early smartthings branded products), their issues had to do with their business model.

As it’s (almost) direct line of sight between the hub and where the buttons are located, and they won’t be moving around, and (especially with no power) there won’t be any interference from electronics or WiFi - in confident in my case that there won’t be any issues here.

But, yes this is something people should consider.

On a side note, I started a thread on RPi forums regarding a RPi that would ping the smartthings API on power failure and power resume whilst connected to the USB on a UPS. It seems that this is a straight forward thing to set up using NUT (networkupstools.org).
This will mean that we should be able to create a scene which is ‘all bedroom lights off’, and activate that scene when the power resumes without needing any additional code.
The only thing to consider is how quickly the bulbs become ready to receive instructions after the power resumes - if the scene is changed before the bulbs are ready, they won’t ‘hear’ the command. In this case we could write a script (that is triggered by the RPi) to send additional ‘scene change’ messages after the restore to the smartthings API

1 Like