I have recently updated my home assistant and this issue has cropped up for me. Before the update lights would turn on immediately - now they turn on one at a time. There is a delay of a second at least between each one turning on. Using a scene or script makes no difference. I tried using a group vs not using a group and still no difference. It seems like home assistant is now waiting for each light to turn on before moving on to the next one. This was not how it behaved before the update.
What lighting technology (or technologies) you are using.
To be able to turn on a group of lights simultaneously, the lighting technology they employ must support this ability. In other words, it’s not the standard command to turn an individual light on/off but a special command that applies to controlling a pre-defined collection (group) of lights. When that special command is transmitted, all lights that are programmed to understand it will act on it, simultaneously (because they all receive that one special command at the same time).
This so-called ‘special command’ goes by different names, depending on the lighting technology.
When a lighting technology lacks this ability, the only way to turn on a group of lights is by sending a command to each light individually. This means they are activated sequentially, not simultaneously.
I don’t know which version I was using unfortunately - I don’t think this will be logged anywhere will it? However I’m pretty sure it was in the 0.8 range and not in the 0.9 range. I just updated to 0.93.2.
I am using flux_led lights.
I get what you are saying. However, before the update there was not any noticeable delay at all (there might have been, but it was soo small it was for all intents and purposes instantaneous) and now there is a very noticeable delay. So something has changed here. See the github thread I mentioned - that guy had the same issue and was able too get them to all turn no without delay by using a workaround. He said he was using 0.8 so possibly it was fixed (as I am pretty sure I was somewhere in the middle of 0.8 and 0.9) and then reintroduced.
Agreed. The reason for the pretty big jump was I was reluctant to update when everything was working. The last time I updated it broke loads of things that I had to then go and fix.
I have looked at the logs in the web interface. From the logs in there there are no errors.
As for breaking changes I didn’t know about that it is very handy indeed, but since no errors are coming up I’m inclined to think that it’s not something broken in that respect. However, something with the way home assistant turns lights on and off appears to have changed.
One thing I DID do which (was the reason I updated) was get a bluetooth keyfob tracker. It wasn’t coming up on my known devices so I updated. It didn’t fix it. It turned out to be that I needed to use bluetooth LE tracker…Now…I know this has been said to slow down home assistant and cause the issues I have described. I assumed already this was the cause so I disabled this and removed any traces of these devices from known_devices. It made no difference.
Just in case to make sure that any bluetooth le stuff wasn’t still running I reset the Pi manually rather than via the web interface to restart everything. Still no change.
Therefore I am assuming it is the update that caused this and not to do with trying out bluetooth le tracker.
However, is it possible that enabling bluetooth le tracker just once has changed something in the bluetooth setup that persists even when you no longer use it?
Looking at the forums it seemed that the bluetooth le slowdowns with the Pi have been fixed anyway now. Also, they went away when you stopped using it - so that is not it.
I did a quick examination and discovered this is a proprietary lighting protocol communicating via Wi-Fi. It relies on a python module developed by Daniel Hiverson based on reverse-engineering the protocol.
If you inspect the flux_led component’s manifest.json file, you’ll see it uses the latest version of the flux_led module, namely version 0.22, which was released Oct 21, 2018.
If your previous Home Assistant version was 0.8X, it may have used an older version of the flux_led module (0.21). The behavior you are currently experiencing may be due to the updated module. Maybe.
If you review the available commands in the flux_led module you’ll see it does not support any kind of group-based commands. In other words, it lacks a special command to turn on/off a collection of lights in one operation. The closest it comes to this ability is a command to turn all lights on/off.
Turn on all bulbs on LAN:
python -m flux_led -sS --on
What this means is that any group or scene defined in Home Assistant has no other option but to send a command to each light separately (i.e. commands are transmitted sequentially). The perception of immediacy (i.e. all lights respond seemingly simultaneously) will depend on the speed of transmission. I don’t imagine your Wi-Fi is the bottleneck so the culprit may be some new requirement for each light in the group to reply with an acknowledgement before the command is sent to the next light in the group. Maybe.
There was a bug with the flux_led component previously so I had rewritten part of the flux_led.py script so they worked correctly. Therefore, they flux_led script being used has not changed for me. Incidentally I just tried removing my custom component and using the current updated script instead. The flux_led component works correctly now using the default script. However, since the script I was using hadn’t changed it was definitely not that which caused the change.
I have just tried using their app and it changes all the bulbs in an instant so it is not my wifi causing the problem, and it shows that it can be done. Therefore, I’m thinking it is something with home assistant that is making it slow somehow.
Interesting. So when you use Home Assistant 0.93 with your flux_led custom component or with the stock 0.93 version of the flux_led component, both produce a noticeable ‘one by one’ behavior as opposed to ‘all at once’.
The implication is that something has changed upstream of the flux_led module and the flux_led component. However, that far upstream implies the behavior would affect all lighting platforms and not just flux_led.
I can confirm that if I use the workaround as suggested in the github linked in the OP then it works. I can turn all the lights on/off instantly using that method. Something is clearly wrong here if to get the 4 lights to turn off without delay I have to run a script which runs 4 separate scripts each containing their own light.turn_on. But you can’t just have one script that has 4 light.turn_on statements in it.
As the guy says in github it’s to do with the way home assistant is processing it. Instead of running the light.turn_on in the background and moving on to the next one it is waiting for it to finish. But the way home assistant handles scripts it IS running them in the background - so having a script of scripts works. It is odd that they changed this and I am wondering if it was intentional (possibly because running it in the background was breaking something else?).
In reply to 123 - Given that the workaround works I would suggest it would happen with other light platforms as well - not just flux_led. The exception maybe being those light platforms that have some other way to trigger turning on multiple lights (like maybe Philips hue for example I’m not sure).
This may have been done because running the process in the background was breaking something else? Or it may have been introduced unintentionally and it is a bug. I’m not sure which. Where could this be confirmed with a dev?
Good question. You could try just posting it as an issue in Github, or asking it in the Discord channel, or doing some legwork first and sifting through 0.93’s pull requests to find something remotely related to this new behavior.
Just because your script didn’t update doesn’t mean that your script is using the old resource files. Home assistant resources update based on a flat update file now and it’s no longer referenced in custom components. What @123 is saying still could affect you even though your code hasn’t changed.
I don’t have this issue. But, a while back, when I was still using a raspberry Pi, I can tell you this…
If you are using the built-in bluetooth from the Pi, and the built in Wifi, the two interfere with one another. When I played with it it caused weird delays in wifi transmission that could look like what you’re seeing. As others have said, each light is actually turned on one by one in most cases, it just happens so fast you don’t notice it. But, if Bluetooth is interfering with Wifi transmission, then you will notice it.
I recommend turning off your Bluetooth device tracker and restarting the Pi to see if that improves things. If it does, you can buy a bluetooth dongle for $5 or so (in the US) and it will solve your problems. Alternately, you can use your Pi’s wired connection, or buy a wifi dongle. As long as you aren’t using the builtin Bluetooth and builtin Wifi at the same time.
What’s the reason for the multiple levels of indirection? You have scripts that calls many other scripts where each one of those scripts turns on (or off) a single light?
FWIW, I assume you already know that turning on/off a single group achieves the same thing (with a fraction of the code). So there must be a special reason you’ve chosen the ‘Rube Goldberg’ approach …