Flux_led error - Githubissues

baerni commented 4 years ago

Home Assistant release with the issue:

0.100.2

Operating environment (Hass.io/Docker/Windows/etc.):

Hassbian **Integration:** [flux_led](https://www.home-assistant.io/integrations/flux_led/) **Description of problem:** Hello. I have a problem with flux_led. Turning on the lights doesn't work properly because you need to quickly turn the lights on, off and back on so that they work properly and you can change the colors. It seems to me that the problem is in the component code. [There is a video](https://gofile.io/?c=nrE9n9) in which presents the problem.

cnijpels commented 4 years ago

I have exactly the same problem, but with the magic light bulbs.

baerni commented 4 years ago

Is there anyone who can review the flux_led HA integration code and say whether it's a flux bulb or driver firmware issue or maybe the problem is in the HA add-on code, for example in the light switch-on parameter?

cnijpels commented 4 years ago

I downloaded flux_led from github (https://github.com/beville/flux_led) and ran it from the terminal. After finding the ip adresses everything works fine. Just write the ip adress and rgbw values as program arguments. I think the problem is with HA.

marcusharding commented 4 years ago

@cnijpels Hi, I am having these same issues. I am very new to home assistant, are you able to provide abit more guidance about how you got this to work?

CamielNijpels commented 4 years ago

@marcusharding I have no idea how home assistant works and how it interfaces with the original flux_led code. All I did was run the program from the previously mentioned Github page with python using the instructions given. For example, python2.7 flux_led -sS --on. All my lights turned on and have the possibility to change colours, including warm white. So I know it is possible to use flux_led to control the lights, the only problem is home assistants implementation of the code.

chocobn69 commented 4 years ago

Hi, I just made a PR about this issue. It looks like home assistant was not waiting enough to let device to update it's state. I added a 1 second wait. Not sure it's the good way to implement this, but it's working like a charm on my home system. Please take a look : https://github.com/home-assistant/home-assistant/pull/29079

skylord123 commented 4 years ago

I have similar issues using MagicLight RGBCW bulbs I recently bought off Amazon: https://www.amazon.com/gp/product/B07VQLZBNW/ref=ppx_yo_dt_b_asin_title_o02_s00?ie=UTF8&psc=1

I recently debugged it using the flux_led component here: Danielhiversen/flux_led#61

Here is the issue on this repo I opened: #28940

I don't know if this is the same problem or not. You could try debugging it further as I did on the Danielhiversen/flux_led#61 issue (setting various things through commands and getting the information about the bulb between each run to compare raw data and values).

teejay-87 commented 4 years ago

I think this could also be related to my problem: https://github.com/home-assistant/home-assistant/issues/26779

Mine started to appear after upgrade to 0.97, worked fine on 0.96.5.

I think this commit is the cause: https://github.com/home-assistant/home-assistant/commit/2f7c57b257d0678b00846aeba2abb90851e96a70 In particular the part where it reverts support for MagicHome LED (https://github.com/home-assistant/home-assistant/commit/1444a684e02fab99648f6e5daea9f28b6cf45c10). This one is from March 12, 2019. I bought my controller in March and added it to HA probably in April, and it used to work fine till I updated to 0.97 in September.

stale[bot] commented 4 years ago

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

CorneliousJD commented 4 years ago

Hopping on to say that I'm experiencing same issues here with flux_led component, and I saw the PR that was marked for in review but was changed to cancelled? I'm not sure I'm following why?

https://github.com/home-assistant/core/pull/29079**https://github.com/home-assistant/core/pull/29079**

Can someone assist with how we could temp fix this? I'm running in a docker container on unRAID.

skylord123 commented 4 years ago

Hopping on to say that I'm experiencing same issues here with flux_led component, and I saw the PR that was marked for in review but was changed to cancelled? I'm not sure I'm following why?

29079**

Can someone assist with how we could temp fix this? I'm running in a docker container on unRAID.

I have an entire thread about adding MagicLight RGBCW bulb support. It's quite a mess and I recommend you read some of it to catch up: https://github.com/home-assistant/core/issues/28940

Basically these MagicLight/FLUX bulbs run really crappy firmware that makes all sorts of problems for trying to write a component for them. A great example is how I worked on adding support for RGBCW bulbs and got it working for my bulbs only to find another user with the exact same looking bulb (marked with RGBCW as well) in that thread had issues running the code that was working for me. Come to find out he was running a version of the bulb that they decided to handle differently for some reason. I ended up having to create fixes for various types of bulbs and it got pretty messy because who knows when another type of bulb will come out and we will have to add yet another fix for. This is pretty much exactly why you are having issues. You most likely have some sort of weird version of bulb that isn't supported. You can try and run my custom code and see if it works for you.

Even though I got my bulbs working if you have any sort of issues with your WiFi range or anything you are going to hate these bulbs. For some reason these bulbs get stuck in the ON state and will actually report incorrectly from the firmware that the bulb is OFF. It's been super frustrating because if the bulbs report their correct state I can just have my automation turn them off if they are on when they aren't supposed to be but instead I end up with my outdoor bulbs stuck on 24/7 wasting electricity.

I don't trust the firmware on these devices at all and recommend everyone stay away from these bulbs if possible. I have the internet blocked for them but even then I am still sketched out by them and their garbage firmware (they could attack other devices on my network or be wide open for hacking). The firmware doesn't even do what it is supposed to do well so I can only imagine it has security holes and other problems.

Honestly we need to look into flashing these bulbs with tasmota or something else to replace the bad firmware. The only problem with flashing is a lot of these devices have different internals as well so it's not so straightforward (plus you need soldering skills).

I was really stoked on these bulbs because I could finally have cheap outdoor color lighting controllable from Home Assistant but the problems I encountered made them pretty much useless for what I wanted to do.

The reason that PR got closed was because it didn't actually fix the problem (or it only fixed it for that one user's bulb type). If someone really wants to fix the component for these bulbs they will need to add several bulb types but from what I have seen no one is going that route and instead fixes it for their bulb which ends up breaking it for everyone else (which is why these PRs end up getting rejected).

teejay-87 commented 4 years ago

Ok, yes @skylord123 . But for me, for example, it was PERFECTLY working until 0.97 came out. I'm currently stuck at 0.96.5 because 0.97 broke it up, and, with 0.96.5 I've been using it for month, without a single issue! Please, see my comment up here. If it is not possible to find a way to make them all work together, please split the code in two separate components.

skylord123 commented 4 years ago

Ok, yes @skylord123 . But for me, for example, it was PERFECTLY working until 0.97 came out. I'm currently stuck at 0.96.5 because 0.97 broke it up, and, with 0.96.5 I've been using it for month, without a single issue! Please, see my comment up here. If it is not possible to find a way to make them all work together, please split the code in two separate components.

You can copy the version of flux_led from before it broke and add it as a custom component to override the default one. That way you can get it working on the latest version.

Looks like someone broke it for you when they were trying to fix it for themselves. It will pretty much continue to break for people until the code is updated to handle multiple bulbs well. We don't need to split into separate components we just need the component to allow us to specify our bulb type (which I actually started work on and added support for RGBCW, RGBCWW, & RGBA bulbs without breaking others).

I was going to do a lot of work on this component to get it to a good point but the issues I encountered with the default firmware just starting really bothering me and eventually pushed me away. Even if the component is perfect the firmware is still going to mess up. A great example is how the RGBCW bulbs let you specify RGB or CW but you can't have RGB and CW on at the same time. For some reason though I was able to get my bulbs to turn on CW and RGB LEDs at the same time (have no clue how this happened as it would randomly occur and I couldn't replicate it) and it made the bulb hard crash and get stuck in that mode until I powered it off then on (it wouldn't respond to the phone app or sending custom commands and HA reported the bulb as OFF). Having to manually restart bulbs is just a no-go for my setup. I need something reliable that isn't going to piss the wife off. My wife literally made me replace the bulbs with Hue white bulbs because they kept getting stuck on and were pretty useless and I have not ever had a problem with Hue (sucks cause I will never put a Hue color bulb outside but the cheap white ones are fine).

If you want to get these bulbs working again you have options:

Override the flux_led component with a version before it broke
Try the version I made with the various bulb types I created to see if any of those work
Do the updates in the code yourself to get your bulb supported and do a pull-request to get your changes pushed up

I was really excited about these bulbs for the price but after seeing the problems they really aren't worth the time trying to muck around with the default firmware. I am going to try and flash mine with tasmota instead (everyone that has done it never looks back).

From what I have seen a lot of the other developers working on this run into the same problem and seems to turn them off to the idea as well (that's why that PR that was mentioned was closed and another wasn't even tried).

teejay-87 commented 4 years ago

Try the version I made with the various bulb types I created to see if any of those work

Ok, where can I find your code?

CorneliousJD commented 4 years ago

You can copy the version of flux_led from before it broke and add it as a custom component to override the default one. That way you can get it working on the latest version.

Hey @skylord123 -- Sorry for the rookie question, but how do we add it as a custom component? I am running HA Core in a docker container on unraid, so I went into /config/custom_componets/ and made a flux_led/ folder and added lights.py there but so far it doesnt' seem to override the built in one (or the fix just doesn't work for me mabye?)

Also where would I be able to find a copy of the file from 0.96.5 as @teejay-87 mentioned was working for him, I'ld like to try that older version of the file if I can find out how to override the existing one as a custom component and use the old version of the file.

Ideally my goal is to get them working for now, until I can get around to messing with Tasmota.

Thanks in advance!

skylord123 commented 4 years ago

Try the version I made with the various bulb types I created to see if any of those work

Ok, where can I find your code?

I left a comment with where my code is and how to install it on that other thread I mentioned: https://github.com/home-assistant/core/issues/28940#issuecomment-559690970

You will want to read my comments on that thread to see what changes I applied and how to configure it. I left examples and all of that so it should be pretty easy. One thing you will want to watch out for is that I changed custom_effect config option so that it can now be defined per bulb instead of globally for all flux_led bulbs (and it allows you to specify multiple effects instead of just a single one so you can do various holidays). Just check my comments on that thread and it should all make sense.

Hey @skylord123 -- Sorry for the rookie question, but how do we add it as a custom component? I am running HA Core in a docker container on unraid, so I went into /config/custom_componets/ and made a flux_led/ folder and added lights.py there but so far it doesnt' seem to override the built in one (or the fix just doesn't work for me mabye?)

I actually had the same question back when I started working on this so don't worry, it's not such a noob question ;) Check your logs for HA. In my logs when the flux_led component errors it tells me the path to the python file that the error occurred. It looks like this: So that is one way to see if it is loading from the custom_components folder. The logs will honestly be your best bet for figuring out what is going on.

You can edit your HA configuration.yaml file's logger settings so that flux_led gives debug messages. Just do something like this:

logger:
  default: info
  logs:
    homeassistant.components.flux_led: debug

And now you will only get debug for flux_led component (if you enable global debug the logs can get pretty busy).

When you create folders on Unraid it will create them as whatever user you are using and the container may not have permissions to view that new folder/files (I run HA on Unraid as well). I left a comment with how to check & fix that here: https://github.com/home-assistant/core/issues/28940#issuecomment-570086521

Also where would I be able to find a copy of the file from 0.96.5 as @teejay-87 mentioned was working for him, I'ld like to try that older version of the file if I can find out how to override the existing one as a custom component and use the old version of the file.

The ~~current release~~ dev version of the flux_led component can be found here: https://github.com/home-assistant/core/tree/dev/homeassistant/components/flux_led

Press the button that says Branch: dev and click the Tags tab to select what version of HA you want. It will then load up the component version for that tag and you will need to download all the files under that flux_led component and put them in your custom component folder. Double check the permissions to make sure HA can read the files (just as I mentioned above how to do).

CorneliousJD commented 4 years ago

I was able to implement a different fix (coudln't get yours to actually work to control my RGB-only lights)

Posted it here for those that want to try their hand at it. Big thanks @skylord123 for the permission tip, it was throwing me for a loop for a while, forgot to check that ;)

https://github.com/CorneliousJD/flux_led

skylord123 commented 4 years ago

@CorneliousJD glad you got it working :)

This inspired me to write a post about overriding components in HA. I hope others find it useful in the future: https://skylar.tech/overriding-default-home-assistant-components/

christensonautohome commented 4 years ago

Sounds like this was fixed by adding a custom component; not the ideal fix IMO. see fix here #28940 and https://github.com/CorneliousJD/flux_led why isn't this being addressed in the core HA?

CorneliousJD commented 4 years ago

Sounds like this was fixed by adding a custom component; not the ideal fix IMO. see fix here #28940 and https://github.com/CorneliousJD/flux_led why isn't this being addressed in the core HA?

My (admittedly lacking) understanding of it is that the firmware has been changed on these actual devices that it makes creating one cohesive component extremely challenging, because I'm not sure there is any way to detect what version of the chips/firmware you have, etc, so the fix I have works for MY specific lights, (latest firmware, RGB only) but probably wouldn't work for some of the other ones.

I personally thing the better approach may be to split this into different components or one big component that you have to maybe just manually specify what type of lights you have (people should know this when they buy it) and then what version of the firmware you have (i think the magichome app tells you this).

wkelton commented 4 years ago

I just want to add that this is still and issues and affects me.

@skylord123, I haven't dug deep into this, but from what I've looked at and tried, this seems to be a simple problem with needing a delay after turning on. I think the OP's (and my) issue are the same as #36060. I have tested this hypothesis by placing a time.sleep(1) after self._bulb.turnOn() and this issue goes away. That sleep was there in 0,96 and removed in 0.97. And the PR #29079 was attempting to add it back (maybe not in the same way).

skylord123 commented 4 years ago

I just want to add that this is still and issues and affects me.

@skylord123, I haven't dug deep into this, but from what I've looked at and tried, this seems to be a simple problem with needing a delay after turning on. I think the OP's (and my) issue are the same as #36060. I have tested this hypothesis by placing a time.sleep(1) after self._bulb.turnOn() and this issue goes away. That sleep was there in 0,96 and removed in 0.97. And the PR #29079 was attempting to add it back (maybe not in the same way).

I actually tested a delay in there and it didn't fix anything for me. That is why I ended up creating my fork in the first place was because my bulbs had so many problems that were specific to my bulb and firmware and no one had any answers.

wkelton commented 4 years ago

I just want to add that this is still and issues and affects me. @skylord123, I haven't dug deep into this, but from what I've looked at and tried, this seems to be a simple problem with needing a delay after turning on. I think the OP's (and my) issue are the same as #36060. I have tested this hypothesis by placing a time.sleep(1) after self._bulb.turnOn() and this issue goes away. That sleep was there in 0,96 and removed in 0.97. And the PR #29079 was attempting to add it back (maybe not in the same way).

I actually tested a delay in there and it didn't fix anything for me. That is why I ended up creating my fork in the first place was because my bulbs had so many problems that were specific to my bulb and firmware and no one had any answers.

Just to be clear, when you say it didn't fix anything for you were you experiencing the same problem as the OP, specifically

"Turning on the lights doesn't work properly because you need to quickly turn the lights on, off and back on so that they work properly and you can change the colors."

chocobn69 commented 4 years ago

PR #29079 is not ok yet as flux_leb module needs to be async too. I did not find the time to do it yet but it's on my todo list.

skylord123 commented 4 years ago

I just want to add that this is still and issues and affects me. @skylord123, I haven't dug deep into this, but from what I've looked at and tried, this seems to be a simple problem with needing a delay after turning on. I think the OP's (and my) issue are the same as #36060. I have tested this hypothesis by placing a time.sleep(1) after self._bulb.turnOn() and this issue goes away. That sleep was there in 0,96 and removed in 0.97. And the PR #29079 was attempting to add it back (maybe not in the same way).

I actually tested a delay in there and it didn't fix anything for me. That is why I ended up creating my fork in the first place was because my bulbs had so many problems that were specific to my bulb and firmware and no one had any answers.

Just to be clear, when you say it didn't fix anything for you were you experiencing the same problem as the OP, specifically

"Turning on the lights doesn't work properly because you need to quickly turn the lights on, off and back on so that they work properly and you can change the colors."

Yes and no. My bulbs turned on if they were set to the correct mode from the Flux app the problem was the CW & RGB channels weren't being handled correctly by HA so my bulbs would get stuck in RGB mode instead of the brighter CW mode. Brightness also didn't work because it must be done as a fraction of RGB instead of using RGBW where the W is the brightness. When I tried to set brightness it was trying to set the white channel and RGB at the same time which my bulb specifically will not allow (only RGB or CW can be active at a single time, not both). So if my brightness was set it would actually prevent my bulbs from turning on.

So yeah you can do a PR but like I said unless you add many types of bulbs as a config option and build the code to work differently depending on the bulb you aren't actually fixing it for everyone and are just fixing it for yourself (and the lucky few that have the same bulb AND firmware version). I started a version that would handle many flux bulb types (and it wouldn't be hard to add more moving forward) but it seems every approach people are taking only fixes it for themselves.

If someone wants to continue the work that I have abandoned feel free to check it out (adding bulb types in the way to go): https://github.com/home-assistant/core/issues/28940#issuecomment-559690970

One fun issue is that one user had the same RGBCW bulb as me but I had to make another bulb type to get his working because of some weird firmware variation. So whoever picks this up will have to keep that in mind as well.

wkelton commented 4 years ago

I just want to add that this is still and issues and affects me. @skylord123, I haven't dug deep into this, but from what I've looked at and tried, this seems to be a simple problem with needing a delay after turning on. I think the OP's (and my) issue are the same as #36060. I have tested this hypothesis by placing a time.sleep(1) after self._bulb.turnOn() and this issue goes away. That sleep was there in 0,96 and removed in 0.97. And the PR #29079 was attempting to add it back (maybe not in the same way).

I actually tested a delay in there and it didn't fix anything for me. That is why I ended up creating my fork in the first place was because my bulbs had so many problems that were specific to my bulb and firmware and no one had any answers.

Just to be clear, when you say it didn't fix anything for you were you experiencing the same problem as the OP, specifically

"Turning on the lights doesn't work properly because you need to quickly turn the lights on, off and back on so that they work properly and you can change the colors."

Yes and no. My bulbs turned on if they were set to the correct mode from the Flux app the problem was the CW & RGB channels weren't being handled correctly by HA so my bulbs would get stuck in RGB mode instead of the brighter CW mode. Brightness also didn't work because it must be done as a fraction of RGB instead of using RGBW where the W is the brightness. When I tried to set brightness it was trying to set the white channel and RGB at the same time which my bulb specifically will not allow (only RGB or CW can be active at a single time, not both). So if my brightness was set it would actually prevent my bulbs from turning on.

So yeah you can do a PR but like I said unless you add many types of bulbs as a config option and build the code to work differently depending on the bulb you aren't actually fixing it for everyone and are just fixing it for yourself (and the lucky few that have the same bulb AND firmware version). I started a version that would handle many flux bulb types (and it wouldn't be hard to add more moving forward) but it seems every approach people are taking only fixes it for themselves.

If someone wants to continue the work that I have abandoned feel free to check it out (adding bulb types in the way to go): #28940 (comment)

One fun issue is that one user had the same RGBCW bulb as me but I had to make another bulb type to get his working because of some weird firmware variation. So whoever picks this up will have to keep that in mind as well.

I understand that there is a general problem with the handling of all these different devices all under flux_led. However, this particular ticket is describing a very specific problem: "turning on the lights doesn't work properly because you need to quickly turn the lights on, off and back on so that they work properly". This appears to be because there is a slight delay between sending the turn-on signal and the state be reflected as such. There use to be a short sleep in the component code that addressed this behavior. I believe adding that sleep back will (I have tested this) resolve this issue. I agree that there needs to be an overhaul of the flux_led component code. However, I think that this particular behavior is present in enough different different devices (I only have 1 flux device that works without this delay) that it warrants addressing before figuring out how to better handle individual firmware versions.

mondomx commented 4 years ago

I was able to implement a different fix (coudln't get yours to actually work to control my RGB-only lights)

Posted it here for those that want to try their hand at it. Big thanks @skylord123 for the permission tip, it was throwing me for a loop for a while, forgot to check that ;)

https://github.com/CorneliousJD/flux_led

@CorneliousJD awesome job on the custom component, I'll pretty much try anything I can to get my darn RGBCW strips to work (resonably well). By any chance do you have an updated version of your custom component? I get a warning that reads:

WARNING (MainThread) [homeassistant.components.light] Light is deprecated, modify FluxLight to extend LightEntity

Not sure if its a breaking change.

CorneliousJD commented 4 years ago

@CorneliousJD awesome job on the custom component, I'll pretty much try anything I can to get my darn RGBCW strips to work (resonably well). By any chance do you have an updated version of your custom component?

@mondomx Just uploaded the fix at https://github.com/CorneliousJD/flux_led

skylord123 commented 4 years ago

I understand that there is a general problem with the handling of all these different devices all under flux_led. However, this particular ticket is describing a very specific problem: "turning on the lights doesn't work properly because you need to quickly turn the lights on, off and back on so that they work properly". This appears to be because there is a slight delay between sending the turn-on signal and the state be reflected as such. There use to be a short sleep in the component code that addressed this behavior. I believe adding that sleep back will (I have tested this) resolve this issue. I agree that there needs to be an overhaul of the flux_led component code. However, I think that this particular behavior is present in enough different different devices (I only have 1 flux device that works without this delay) that it warrants addressing before figuring out how to better handle individual firmware versions.

The problem with the current component is it uses the same code for all fluxled bulbs so adding back in the delay will more than likely break other peoples bulbs (the guy who removed it may have done so for the exact reason that it fixed it for him and was working fine so he thought it was safe to create a PR).

So in order to avoid breaking fluxled for others we need to re-write the code to handle multiple bulb types. I did a lot of the work on this already on my fork.

Even after adding bulb types it will take a while to figure out all the different variations as well (like how someone had an RGBCW just like me but the code needed slight changes to get his to work). So the sooner someone gets started on this the better ;)

teejay-87 commented 4 years ago

I understand that there is a general problem with the handling of all these different devices all under flux_led. However, this particular ticket is describing a very specific problem: "turning on the lights doesn't work properly because you need to quickly turn the lights on, off and back on so that they work properly". This appears to be because there is a slight delay between sending the turn-on signal and the state be reflected as such. There use to be a short sleep in the component code that addressed this behavior. I believe adding that sleep back will (I have tested this) resolve this issue. I agree that there needs to be an overhaul of the flux_led component code. However, I think that this particular behavior is present in enough different different devices (I only have 1 flux device that works without this delay) that it warrants addressing before figuring out how to better handle individual firmware versions.

The problem with the current component is it uses the same code for all fluxled bulbs so adding back in the delay will more than likely break other peoples bulbs (the guy who removed it may have done so for the exact reason that it fixed it for him and was working fine so he thought it was safe to create a PR).

So in order to avoid breaking fluxled for others we need to re-write the code to handle multiple bulb types. I did a lot of the work on this already on my fork.

Even after adding bulb types it will take a while to figure out all the different variations as well (like how someone had an RGBCW just like me but the code needed slight changes to get his to work). So the sooner someone gets started on this the better ;)

Or, if it is too work for now, I think we could just duplicate the code for each bulb and then consider a merge.

ovcrash commented 3 years ago

I downloaded flux_led from github (https://github.com/beville/flux_led) and ran it from the terminal. After finding the ip adresses everything works fine. Just write the ip adress and rgbw values as program arguments. I think the problem is with HA.

Changing color is still a issue. But the original code works, the one from the beville GitHub. So since HA seem to use the same code, it should work, but it doesn't. Probably a HA problem with using the code.

exentio commented 3 years ago

I'm having the same issue with one of the new BL602-based LED controllers, perfectly working from CLI but unusable from HA. I'll try to dive into the code and see if there's anything I can do

Sangoku commented 3 years ago

Can confirm it on magic home zj-bwce-ir-rgbw v1.2 RGBW Changing colors does not work at all. White Chanel si kaput. Turn on and of does work some times..

Worst part is this is a new board version so it is not possible to flash it with esphome or testamota.

Curros commented 3 years ago

Sounds like this was fixed by adding a custom component; not the ideal fix IMO. see fix here #28940 and https://github.com/CorneliousJD/flux_led why isn't this being addressed in the core HA?

My (admittedly lacking) understanding of it is that the firmware has been changed on these actual devices that it makes creating one cohesive component extremely challenging, because I'm not sure there is any way to detect what version of the chips/firmware you have, etc, so the fix I have works for MY specific lights, (latest firmware, RGB only) but probably wouldn't work for some of the other ones.

I personally thing the better approach may be to split this into different components or one big component that you have to maybe just manually specify what type of lights you have (people should know this when they buy it) and then what version of the firmware you have (i think the magichome app tells you this).

Really thanks! this works for me!

github-actions[bot] commented 3 years ago

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

ianschorr commented 3 years ago

Stale bump

github-actions[bot] commented 3 years ago

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

home-assistant / core

Flux_led error #27755

29079**