Multiple lights now turn on one by one instead of immediately since update

Looks like they were messing with the flux_led.py which I have my own custom component for. So that shouldn’t be the cause unless my custom component isn’t being loaded. However…I do remember I used to get a warning message about loading a custom component for flux_led and I don’t get that now. I wonder if my custom component isn’t being loaded and the one that was changed is bugged. I noticed it added a line with a sleep statement so that could easily be the cause if home assistant is using this and not my custom component.

I will try tomorrow to put an intentional error in my code to see if home assistant throws an error. If not then it’s obviously not using my custom flux_led.py.

That would be irritating as the guy was warned about changing it and breaking stuff for other users lol.

I’m almost certain that will be the problem: the sleep statement. At a quick glance it looks to be set for 2 seconds, pretty much the delay I’m getting.

I have a feeling the location I need to put my custom flux_led.py has changed and it’s no longer loading it. I have it in custom_components/light/flux_led.py and I think that may have changed to just be in custom_components/flux_led.py.

Looks like I was right about my custom component not being loaded…things have changed considerably:

Would have been good for a warning to have appeared about that, but I know now. I’ll have a tinker tomorrow and get it loading again. I’m sure this will fix it. I’ll keep you posted.

I will also look into why it was deemed a good idea /necessary to introduce a sleep statement into the flux_led.py - I’m pretty sure whatever it was done for it was a bad workaround and needs to be changed for future releases.

Are you sure it’s not in the log (the detailed version )? The custom components I use always get reported in the log. Unless you mean it didn’t report that it found but did not load your custom component. In my case where I use a customized version of the MQTT climate component, I assigned it a completely different platform name (my_mqtt instead of mqtt). This ensures that Home Assistant cannot substitute the original mqtt version. If it can’t find the my_mqtt component, it will fail with a boatload of error messages.

I believe the sleep statement was added to fix a specific type of light, for setting rgb (I think). However, the test suite may have overlooked to check if the modification affected the control of a group of lights.

I can confirm that it is the flux_led component script that is causing the popcorn issue. A sleep statement was introduced and is the culprit. Previously I had a custom component using the old flux_led.py file that did not have a sleep statement in and was altered significantly by myself to work correctly (the old flux_led.py was really buggy). However, there was a breaking change for custom components that I wasn’t aware of - the way you set this up is now completely different.

To fix I made a directory:

config/custom_components/flux_led (config should be the same directory your configuration.yaml file will be)

I added the following files (tagged as code or the underscores don’t show up):

__init__.py (this was just a blank file - it is still required to be there though)
light.py (this was my previous flux_led.py just renamed)
manifest.json (taken from the "home assistant/components/flux_led" folder)

If anyone needs it the manifest.json looks like this:

{
  "domain": "flux_led",
  "name": "Flux led",
  "documentation": "https://www.home-assistant.io/components/flux_led",
  "requirements": [
    "flux_led==0.22"
  ],
  "dependencies": [],
  "codeowners": []
}

Since the latest flux_led code seems to not be buggy now and has other updates I then transferred the light.py file from “home assistant/components/flux_led /light.py” to my config/custom_components/flux_led folder and commented out the sleep line. The popcorn effect is gone.

The reason they added this was just so the frontend would update quickly - without the sleep line you have to wait for the frontend to update but at the expense of causing a popcorn effect. I wonder if there is a better way to update the frontend without a sleep statement??? But for me having a group of lights turn on immediately for scenes etc trumps having the frontend update smoothly.

I guess one solution is to add an argument to let the user choose if they want to prevent the sleep statement for the purpose of turning on groups.

Just to satisfy my own curiosity, originally you reported 0.90 worked but 0.91 had the bug. However, after reviewing their Release Notes, I found the flux_led component changed in 0.90 so the bug would’ve been evident in 0.90, 0.91, etc. How was it that you found it worked in 0.90? Was it because your custom component was loaded successfully in that version but failed to load in 0.91?

Yes because “the great migration” (which I just noticed you made a post about before so you’ve had to deal with this too lol) happened in 0.91

So yes before 0.91 my custom component would have loaded.

I’m pretty sure there is a better way to deal with this. Maybe this?

https://developers.home-assistant.io/docs/en/entity_index.html

Yeah, that’s why I suggested creating your own platform name (like my_flux_led). This way Home Assistant can’t ‘fall back’ to using flux_led because your config entries are explicitly requesting to use the my_flux_led platform. In addition, when perusing the config file, it serves as a reminder that your lights are using your custom component as opposed to the stock component.

For example, my climate entity uses a custom component derived from Home Assistant’s climate component for the MQTT platform. The config entry begins like this:

climate:
 - platform: my_mqtt
   name: "Thermostat"

The component is located in custom_components/my_mqtt/climate.py. For Home Assistant, this is now a different platform from mqtt. Should it ever fail to locate my custom component, it will not substitute the mqtt platform but report an error.