For a while now I’ve been struggling to figure out some inconsistencies I’ve been experiencing with my ikea zigbee buttons. I have a 5-button remote paired to the hub, and two zigbee bulbs that are configured to be toggled on/off when the middle button is pressed.
After a lot of trial and error, and chasing some red herrings (thinking low LQI/RSSI was the issue), I’ve isolated Smart Lighting as the weak link.
Long story short, I can see the button press event register in the web IDE, but nothing will happen sometimes. With the example setup it was a…consistent inconsistency. That is, every time the bulbs were changed using the app, the FIRST remote button press would do nothing. After that, it works fine. This becomes an issue when I used voice control.
And of course, this was only the consistent misbehavior. Sometimes it would randomly ignore inputs. And on a separate setup with another zigbee remote, similarly the Smart Lighting configuration would randomly do nothing when the button press event came in and was registered.
If I set up my button press actions through the plain Automations, everything works properly without issues. Of course there are downsides to this. The Automations don’t run locally, so they are slower than Smart Lighting. Also, they don’t operate on my bulbs as a pair, so if one bulb is on while the other off, the toggle action will keep them de-synced.
If you are using a single button to toggle on and off, smart lighting stores the toggle state in the smartapp, rather than checking the state of the devices, as we might expect.
The advantage of this approach is that you don’t have an issue of some lights turning off and others turning on with one button press. The disadvantage is that sometimes it will turn devices on that are already on, and appear to have no effect.
Wow so this terrible behavior is built-in? I don’t understand how this isn’t a big issue for everyone. This means any time the bulb is changed using an app, voice assistant, or another directly paired remote, your Smart Lighting automation isn’t going to work (the first time). And that’s…intended…
Is there a way around this? I don’t see how this isn’t an issue for more people.
A common work round for toggling in Smart Lighting is to use two automations. One that turns the light on, but only if it is off, and one to turn the light off, but only if it is on. It might sound like there would be a race condition, but there isn’t.
@GSzabados yeah I know the ikea remotes and motion sensor don’t have a local DTH sadly. But, that part of the automation’s response time is fixed. The question is whether or not having the ‘Automations’ version be cloud-based will slow down its response much. So far it’s not a huge difference over Smart Lighting, but I think it’s noticeable. Still, the fact that it always works is a big benefit.
I lost you again. Due to the cloud based DH Smart Lighting is cloud based as well. Smart Lighting still uses the old Groovy code and IDE implementation, meanwhile the Automation Rules are using the new API, what should make it more responsive.
Interesting. I was under the impression that because the DH is cloud-based, the whole “automation” is considered cloud-based, since one link in the chain of execution is cloud-based, meaning that without internet the whole thing won’t work. But still, I thought that the Smart Lighting portion of the execution chain will run locally. You’re saying that as soon as there is a cloud-based link in the chain, the entire thing just gets sent to the cloud?
Maybe I’ll try and time the execution of these automations and compare. It’s just so far I’ve noticed the new ‘Automation’ version hang a few times, where the Smart Lighting one was quite responsive, when it actually worked.