I’m setting up my first Home Assistant system and just added the first 2 devices. I’ve been running into a few anomalies and would like to ask for advice on this and a few other issues from more experienced members.
I have taught myself the basics of yaml, read most of the available documentation on HA official site and on several other sites, watched a bunch of YouTube videos and experimented a bit.
The main issue: I’m using the motion sensor to trigger turning on the light bulb when motion is detected and turn it off again once motion is not detected for 15 seconds. The Sonoff motion sensor has around 2 minutes cooldown, so the “light on” period is actually around 2 minutes and 15 seconds. Most of the time it works great but a few times per day, after motion is detected the light turns on for half a second and then turns off again (basically flickers). At this point HA dashboard will still show that the light is turned on. In the logbook and automation graphic trace everything seems correct, motion is detected and there is a record showing that the light gets turned on. If at this point I move the brightness slider of the bulb in GUI a little bit then the light will turn on and everything will keep working for a while again.
In the automation action I send a few different parameters to the bulb: turn it on, set the brightness and set the temperature. I had a few thought why this could be happening:
Is it possible that due to some (network) issues sometimes one of the parameters doesn’t get sent to the bulb ? i.e. Bulb gets turned on, temperature gets changed but the brightness setting doesn’t get changed ? Although in the HA dashboard the brightness slider is at the correct location when this problem occurs.
Could is possibly be network related ? Since these are the first devices and a real mesh doesn’t exist yet ? The bulb is about 5m away from the coordinator, there’s 1 wall between. The Motion sensor probably connects to the bulb since that’s the closes router and it was paired after the bulb.
Does anyone have any idea why this might be happening ?
Sorry that the conditions are not very elegantly written. For testing purposes I keep the whole thing in one automation. I’ll organize it better with helpers and scripts in the future. The time conditions are working great so I guess the problem couldn’t be related to them.
A few side-questions:
Is there any difference between using “device” platform or “state” platform for triggering this type of automation with a motion sensor ? Both seem to work the same and I’ve tested it both ways. Currently it’s “device” trigger to turn on and wait_for_trigger “state” to turn off the bulb. Sidenote: I think the main issue (1) is not caused by the “turn off” part somehow getting triggered right away after “turn on” is triggered, because when the problem occurs then the trace log always shows that the “wait_for_trigger” part is working correctly.
I’m using a transition period of 21 seconds to turn off the bulb (just for a cool effect and smooth transition once the stairs are not used any more). The automation mode is set to “restart”. I noticed that during the 21 seconds transition period, the automation does not start again or restart when motion is detected again. It continues until minimum brightness and then turns off the bulb. Is there any workaround for this other than manually scripting the transition and halting the script when motion is detected ? I’m using this automation for a light at our stairway. It’s not ideal if someone starts going up or down the stairs when the 21 seconds transition is near the end (light is quite dim) but the automation doesn’t restart and light doesn’t brighten up again.
I’m thinking about trying to re-do the automation using a timer instead of wait_for_trigger from motion sensor to turn off the light just to see how it works, but it wouldn’t probably fix my current main issue, because the “turn off” part works fine. The upside would be that in case the motion sensor sometimes somehow gets stuck in “on” position for longer than usual, then the light would still be turned off by timer, so it would be a more controlled “on” period.
Are you using the ZHA integration for ZigBee? If so, there is a routing map that can help you see the signal strength to each device. If signal is weak to that bulb, it could have some strange behavior. I have a Sengled bulb that went rapid fire on/off/on/off repeatedly until I killed power to it. After the mesh improved, the issue went away.
Yes, I’m using ZHA (as mentioned in the beginning of the post )
I’m also leaning towards signal issue, because it occurs way too randomly to be a code problem. I’m getting a USB extension cable and bringing the coordinator a bit closer, so there won’t be a wall between - If that improves the situation then I have some light sockets between the coordinator and the current smart bulb that I could fill with more smart bulbs to strengthen the mesh.
In what range should the LQI number generally be for it to be considered good or decent link ?
I was playing with an automation which had the same problem. I’m not convinced it’s the network.
I have 18 devices from several different manufacturers. I’ve never had any “bounce” on-off or on-off-on when toggling them from the GUI. The one device I had out at the back of my barn, farthest from it’s nearest neighbor, would simply fail to turn off occasionally, until I put another router device in between.
I only experienced this bouncing behavior after I set up a Sengled smart plug right in the dining room, maybe three yards (meters) from the coordinator. It worked great except when I tried to control it from an automation. Then it would occasionally, and seemingly randomly, toggle two or three times when the automation action was to toggle just once.
We could be looking at multiple different failure modes here, but my money is on this not being a coincidence, or a network issue. Fortunately for me the device I was playing with isn’t critical, and I’ve moved on.
For me, I go off the colored lines on the map. Green being good, red being bad. Using that color coding has been pretty accurate for me.
My trouble devices have generally been with red lined connections.
I figured out and solved the main problem which was the transition timer. After I completely removed the transition timer from the “turn_off” action, it has been working for 2 days now without any issues or glitches.
My hypothesis is: The transition timer is not controlled by HA but it’s apparently some kind of special signal that is sent to the bulb and the transition dimming is ran by the bulbs hardware / firmware. The transition timer can not be aborted/halted/stopped once it has started. I used quite long transition timer (21 seconds). When motion was detected during the time when the turn_off transition timer (dimming) was running, my automation sent a “turn_on” command to the bulb again, which for a moment set the brightness to the value specified in the “turn_on” action and then right away continued dimming the bulb (because the turn_off transition timer was still running on the bulb hardware) - this created a bright/dark flicker at that moment and I guess it somehow messed up the brightness parameter in the bulb. After the turn_off transition finished (bulb turned off) and motion was detected again, I got the fast one time on/off flicker that is described in my original post. This flicker would continue every time motion was detected until I manually adjusted the brigthness setting of the bulb from HA GUI.
Lesson learned: Be careful with the transition timer since it’s not controlled by HA and depends on hardware/firmware of the specific device.
If you are referring to a light entity’s transition option, it’s not a “transition timer”. It’s a feature that only works if the lighting device supports. So you were right about “it’s not controlled by HA”; it’s more than a hypothesis, it’s a fact.
Home Assistant simply requests the transition effect and the device’s hardware performs it (if it supports it). This is far more efficient than transitions implemented in software (like the script in the linked post) because a hardware-based transition only requires a single transmitted command to initiate the effect whereas software-based must transmit numerous commands to achieve it.
Normally, if a long transition is underway, any subsequent command (with or without a new transition) will cancel it in favor of the new command.
I mean my hypothesis is that the transition feature caused the flickering problem (in my original post) because after removing it, the automation has been working as intended. I’ll give it a few more days to be 100% sure.
I understand that the transition feature only works with devices that support it and it’s performed by the devices hardware. My bulb supports it but there could be some kind of bug that causes the bulb’s brightness not to update correctly after the transition feature has been used or if a new brightness value is sent to the bulb while the transition is running. I also understand that the transition performed on the bulb’s hardware will always be smoother than transition emulated by HA on software level. I really liked the transition effect and would like to use it but for now I’ll keep it off or try some alternative solutions.
I read through several topics in this forum about the transition feature and most people seemed to think that the transition feature can’t be stopped once it has been started.
Quoting someone on the forum:
“Transition is a hardware feature. Once the bulb has received the command, there is no zigbee command to stop the transition.”
At least for my bulb it seems to be true. But since it is a hardware feature, different devices may run the transition differently and maybe with some other bulbs it can be stopped by a new command. I’ll test it again once I get some new bulbs by another brand.
I’m no Zigbee expect but perhaps the meaning of that statement is that there’s no specific command for the exclusive purpose of ending a transition in progress. Because if one of my Philips Hue bulbs (Zigbee) receives a ‘set to a specific brightness’, ‘set scene’ or ‘turn off’ then its “transition in progress” is definitely terminated.
For now I wrote a small and very basic dimming function using the repeat loop. It will decrease the bulb brightness by 1% every 30 milliseconds until the brightness value is less than 5 and then turn the light off. If motion is detected during the dimming loop then the dimming will be canceled and bulb will set to fixed brightness again because the while automation runs on mode: restart
I know this spams the MQTT network with a lot of commands but I don’t have many devices yet so it should be okay until I can test the built in transition functionality a bit more. Visually the repeat dimming function looks exactly the same as the built in transition, both are smooth.
Perhaps the Hue bulbs are of higher quality than random $10 Chinese Zigbee bulbs I also read in some other topics examples of quality brand bulbs handling the transition well and stopping the transition when receiving new parameters. I guess my bulbs gets stuck in some strange state when a new brightness parameter is sent while the transition is running. I’ll keep testing to see if I can narrow the problem down a bit more. Might depend on the length of the transition or which new parameter is sent to the bulb first during the transition or something else random like this.
I would absolutely recommend against that. I have cheaper Zigbee stuff, mostly RGB strip, and if I send it a command even every 250ms, it will panic after a few minutes and drop off the Zigbee network until I turn power off completely for 30 seconds and turn it back on again.
Interesting I’m sure it stresses the network and device quite a lot but it’s been working for half a day now without any problems. The situation will probably change once I start adding more devices.
The real speed is actually not even close to 30ms. Looking at the trace timeline, it takes this loop approximately 30 seconds to decrease the brightness from 60% to 2% so it’s actually decreasing the brightness by 1% about every 0.5 seconds. I’ll try to set it to 500ms in the script and see if the total time will be the same. There’s probably some kind of hardware limitation how often the device can receive new commands. But even this is still unnecessary stress, so I might eventually go with something like 2% every 1 sec or even 4% every 2 sec - less smooth but serves the purpose and still looks better than a sudden turnoff from maximum brightness.
EDIT: Changed time from 30ms to 500ms and the total run time went up to 2 minutes. Maybe spamming the bulb with commands faster somehow queues up the changes. Anyways, I’ll play around with it to find a sweetspot.
It’ more likely that spamming the bulb with commands faster than the bulb is responding, is probably resulting in a lot of “no reply received” messages in the Zigbee log, so commands are being dropped. If this was ZWave instead of Zigbee, the result of that would be after ~5 or so no response messages, ZWave would mark the device as dead, and refuse to speak to it again until either the bulb sent a message to the network - bringing it back to life, or the ZWave stick was soft reset.
I did some more testing with my bulb and the transition function today.
It turns out that the transition is indeed aborted when a new brightness value is sent to the bulb (for example when motion is detected again and the automation restarts). But the moment when the transition is aborted, the bulb is set to the “destionation state” of the transition in progress. For example when transition is going from 60% brightness → OFF then the moment the transition is aborted: bulb is set to OFF. So the transition doesn’t stop at the current brightness level when it’s aborted. This causes a problem and the event timeline happens like this:
Motion detection turns on the bulb
When motion is not detected any more, bulb starts to transition to OFF (for 30sec) (HA GUI shows bulb turned off from the moment when transition starts - I guess because it’s basically a turn_off command that just takes longer time to complete)
15sec later motion is detected again, automation triggers again (restart) and brightness is set to 60% (HA GUI shows bulb turned on, brightness 60%)
Setting brightness to 60% aborts the transition process that is running on the bulb hardware and bulb turns itself off because that’s the final state of the transition (HA GUI still shows bulb as turned on. I guess because it doesn’t need to report back to HA because it knows that bulb state was already set to OFF when the transition started (step 2)
So this creates the problem. When motion is detected during the transition, bulb blinks on to 60% and turns off right away, leaving HA thinking that it’s still turned on.
I did another test where instead of turning the bulb off when motion is no longer detected, I set brightness to value 1 with light.turn_on command with the same 30sec transition time. Somehow in this scenario bulb doesn’t set it’s brightness to 1 when transition is aborted half way through. I guess that’s where there’s something wrong with the way that the bulb handles these transitions. The timeline would go like this:
Motion detection turns on the bulb
When motion is not detected any more, bulb starts to transition to brightness value 1 (for 30sec) (HA GUI shows bulb on brightness value 1 right away after the transition starts)
15sec later motion is detected again, automation triggers again (restart) and brightness is set to 60% (HA GUI shows bulb turned on, brightness 60%)
Setting the brightness to 60% aborts the transition process that is running on the bulb hardware but this time brightness stays on 60% and the bulb HW doesn’t set it to the final value of the transition (1).
There’s probably a difference in the way the bulb handles this when it’s an on/off situation vs on/on situation. I also tried to do the transition by setting brightness to 0 with the light.turn_on command but the result was the same as with light.turn_off command. I guess they are technically the same.
As a workaround for my automation I set the turn off transition to brightness value 1 (for 30sec), started a 30sec delay followed by a light.turn_off command. Seems to work although the difference between HA delay timing and bulb hardware transition timing may cause the bulb to turn off a bit earlier or later than the moment when brightness reaches 1 (not noticeable). I think this is at least a bit better solution than manually scripting the dimming transiton and spamming the bulb with a lot of brightness values.
I also tried to use wait_for_trigger to wait until bulb brightness reaches value 1 and then execute turn_off command. But it doesn’t work because the brightness value is already set to 1 right away when transition command is sent to the bulb.
)
I also read in some other topics examples of quality brand bulbs handling the transition well and stopping the transition when receiving new parameters. I guess my bulbs gets stuck in some strange state when a new brightness parameter is sent while the transition is running. I’ll keep testing to see if I can narrow the problem down a bit more. Might depend on the length of the transition or which new parameter is sent to the bulb first during the transition or something else random like this.
I’m sure it stresses the network and device quite a lot but it’s been working for half a day now without any problems. The situation will probably change once I start adding more devices.