Automation based on offline/unavailable bulb

Hi. I have a IKEA trådfri bulb I am using with a “dumb” lamp connected to a normal wall switch. I wish to use the bulb status to control a different IKEA trådfri bulb so that I can turn on and off the mentioned bulb.

If the first bulb goes offline / becomes unavailable then the other bulb should be turned off. If the bulb goes online / becomes available the other bulb should be turned on.

I have not found a way to do this using the normal automation routines as they seem to assume that the bulb is always available and there is no “unavailable” status that can be used to turn off a different bulb.

This is not possible. It is not recommended to pull power from smartbulbs for several different reasons, the primary being that it will interfere with your mesh. The Tradfri bulb is a zigbee repeater. Which means other devices might be routing their messages through it. When you power it down, you are cutting that repeater our of your network.

On top of that, that means that you will not be able to control that bulb from ST anymore. Why bother having a smartbulb at all if you don’t want to have a smartbulb?

1 Like

I’m not completely sure what your end goal is, but

Could you make some virtual switches? When Bulb A is on, then Virtual Switch A is on. If Virtual Switch A is on, then Bulb B is on. If Bulb A is off, then Virtual Switch A is off. If Virtual Switch A is off, then Bulb B is off.


1 Like

@smacmac, there are some SmartApps which are checking device health…

But, I understand your point, you want to turn off your bulb physically with the switch and you want to use that to control your other bulb.

I would replace your switch to a smart switch. Then you can achieve this without any issue. It doesn’t have to be a physically wired switch.

Or get one of these and use it as a switch to control your bulb. You can set a rule to turn on and off both bulbs from the same remote. (The 5 button remote gives more options, like dimming, changing colours etc. And it can be grouped directly to Tradfri bulbs.)

What would have more switches in the mix accomplish? I’m not sure why you would do that.

I’ll try to describe my motivation:
By installing a smart bulb into the first lamp I gained the posibility to change white balance and dim the light without involving an electrician or adding any new switches. This was cheap and gave me all the functionallity I wanted without any clutter. I did not know that this was a bad solution and I have not experienced any issues with this since I installed it.

So when my girlfriend wanted a new lamp in the same room I was hoping I would get away with only buying another smart bulb and turn it on and off based on the status of the first bulb. Since the first lamp is a part of a 4-way switch setup with several other lamps and three different switches it will be a significant cost and job to install an fully smart solution.

I’ll look into the code for the device monitor SmartApp. I think I will be able to use it.

FYI, the device monitor will not be immediate as it does polling.

Just to use them as a trigger/workaround, really. They’re virtual switches, so it’d be all backend that no one would ever have to see.

I understand that…but I still don’t understand why you think you need them. You don’t. He is trying to detect when the bulb is unavailable as in not plugged in so no power. It won’t read as off. It will read as unavailable.

But in general, when trying to sync two switches together, you do not need to create two additional switches. Instead of turning off virtual switch A to turn off Switch B, switch A could just turn off switch B!! Why have a virtual switch in the middle? There’s absolutely no reason for it. You could have 100 virtual switches in the middle if you really wanted to Rube Goldberg it. But you need zero.

I understand that most battery powered zigbee devices do not act as repeaters. Can I prevent the bulbs in question to act as repeaters to avoid this?
I already have another bulb which is behind a light sensor meaning that it goes offline during the day. I have not had any probelms with it. Is this causing problems which does actual damage or is it merly a point to look into during a future problem seeking in case of a problem with the mesh?

If you have Tradfri bulbs, then all functions as repeaters. By design they were intended to be powered all the time. You can turn them off by the Hub and the App.
They will behave as a repeater. If you don’t use dodgy devices your battery powered devices will recognize the missing mesh point and will rejoin on a different route. (Or not.)
It depends how big and stable is your mesh generally. As you haven’t stated how many bulbs and battery powered devices you have, I cannot assume anything. But I guess you have less then 10 signed devices probably in close proximity to the Hub. So might not an issue for you at the moment.

I have found a solution that is far from instant, but which actually does the job for me using webCoRE. As I still hope there are ways to improve the code to maybe reduce the delay, I have posted it on the webCoRE forums:
Trigger when bulb goes online - webCoRE forums

No, you cannot.

Everytime the bulb gets power back the same things happens:

  • Configure command is sent to the bulb.
  • The check interval is changed.

I believe there should be a way that I can use the configure command that is being sent as a trigger.

Does anyone know how I can do that? Alternatively why it will not work?

No…you cannot do that.

I found a way to use the configure action as a trigger.

By making a modified device handler I was able to add “setLevel(99)” at the end of the “def configure()” block. This I could then use as a trigger for webCoRE. I am still puzzled why there is no way to use the configure event as a trigger by itself, but I guess I got to accept that.

I also modified the checkInterval to 60 for a quicker response when turning the light off.
I could then use a timer to check the health status every minute as well.
I understand that lowering the checkInterval is bad for battery life, but as I currently do not have any battery devices on the given hub I don’t think it should be a problem. I assume someone will tell me why this is a bad idea and I don’t have a problem with using a larger value, it just does not seem as nice.

Because the configure method does not publish any events to the system. It is used to configure the device for reporting to ST, not for recognizing when the device has done something. You have to realize that what you are trying to do is exactly is what they designers of the system don’t want you to do. They’re not going to make it easier for you to do it.