WS2812B RGB not working with Flux_LED

[Obicom]

Home Assistant release with the issue:
0.90.0b3

Last working Home Assistant release (if known):
unkown

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

Component/platform:
https://www.home-assistant.io/components/light.flux_led/

Description of problem:
My new MagicHome RGB controller for WS2812B is discovered from Flux LED but doesn't work. If I add the entity to HA it shows status "off" but controller is on and working.

Additional information:
With MagicHome App I can control the RGB stripe without any problem.

[awarecan]

Can you try on 0.89.2 to confirm whether it is beta related issue?

[Obicom]

I tried with 0.89.1 (snapshot was available) ... I was able to switch on/off (was not able with beta 0.90.0b3) but nothing in the effect list (effect list was not shown) and brightness was not possible to control.

[Obicom]

Tried the same after an update to 0.89.2 .. is the same as 0.89.1 ... if I switch on/of a service error message is shown on the bottom of the window ...and no effect list shown.

[awarecan]

May related with #20733 fix, cc @autinerd @amelchio

(Many light PRs end up breaking bulbs different to the ones the author has)

[Obicom]

Normal RGB stripes and RGB bulb works fine ... I have only the issue with this MagicHome controller 👍
https://www.aliexpress.com/snapshot/0.html?spm=a2g0s.9042647.0.0.56924c4dcwFdxk&orderId=99147285945132&productId=32959345574

[autinerd]

Can you run hass in a shell, reproduce and paste the call stack from the error here?

[amelchio]

To be clear, does it work with 0.89 or is this a new strip that you just got?

[Obicom]

It is a new strip with a new MagicHome controller ... so I would guess it never works correct before ...
@autinerd : could you explain how? I am not so familiar with that ... but I can do with the right advice ...

[autinerd]

@Obicom I forgot, you should see the errors in the log, at <your-url>/dev-info of your instance. Can you post one of the error messages here?

[Obicom]

@autinerd: maybe I did something wrong but found no related error in my home-assistant.log

[autinerd]

@Obicom You can find the log at <your-url>/dev-info of your Homeassistant instance (see screenshot) and there have to be the errors listed.

[Obicom]

No I found an error ... when I try to control the componet: (Done with release version 0.89.2)

[Obicom]

[autinerd]

Now I see the problem. Your device is in your homeassistant config configured as RGBW, but it only can RGB. You have to change it, then it should work.

[Obicom]

Ok, but it is "auto-discovered" and I have no explicit entry for this entity in my configuration.yaml ... how I can change this now? I would say is then a bug in auto discovering ....

[autinerd]

@Obicom I looked at the code again and yeah, you are right! This line of code leads to the bad behaviour:

https://github.com/home-assistant/home-assistant/blob/db07e45df89f23dbfe078364d0e361b39dd138e5/homeassistant/components/flux_led/light.py#L154

That line says that automatically found devices are always RGBW controllers. I will make a pull request which just removes the line, because there is a automatic recognition whether the controller is RGBW or RGB, which is overwritten by this line.

Interesting that nobody faced this problem in the 2 years of existence 😂

[Obicom]

Thank you very much for your effort to investigate ... is there a way for me to fix it by my self in the meantime? (Edit a file or something else) I use hassio on raspbian ...

[autinerd]

@Obicom Remove the line from the file in your local installation or put your controller explicitly into the config.

[lstg]

I have a similar "magic home led spi controller" and see a similar issue. I've already experimented with manually adding the device and changing the mode and protocol settings but unfortunately this doesn't seem to make a difference.

I suspect the problem is that the underlying flux_led library doesn't support these controllers properly yet. My guess is that a different protocol is required to support individually addressable pixels correctly (as in addition to a colour which "pixel" to be changed must somehow be being supplied).

I've not yet had a chance to experiment with this further myself yet though. I'll try to supply you with relevant logs when I next have access to the device.

[Obicom]

@autinerd I guess I am not able to remove the line from the code ... I use hassio in a docker container and would expect that the flux component it part of the docker container ... if not please let me know.

[autinerd]

@Obicom ah, okay, then the only thing you can do is manually put the controller into the config.

[autinerd]

@lstg I didn't even know that these controllers exist! How do they look like in the Magic Home App? As one light?

If possible, a packet capture from the phone to the controller and back would be fine.

[Obicom]

@autinerd is it posible to combine the local definition for the new WS2812B led stripe and automatic_add for the rest together in one light entry or how should I do?

[Obicom]

@autinerd I tried a combination of automatic and single entry, also only single entry only for the one new RGB light, without success. Mostly when I switch the light on the switch goes back to off after 5 seconds. I was a short time able to switch on/off and change brightness but not to use one of the effects. I do not know why it works partly for a view minutes ... but 90% of testing nothing works. I guess here is a bigger bug for this controller inside. Here some screens:

Mostly if I tried to switch on the it switched back to off after a view seconds:

for some minutes (but effects doesn't works):

[autinerd]

@Obicom I just see you have the python file version before my and @amelchio changes, so these can't be the problem at all.

I'm wondering why raw_state is None. Are effects supported by the "Magic Home" app for this controller?

Are you using an Android phone with the "Magic Home" App? If yes, can you install Packet Capture (https://play.google.com/store/apps/details?id=app.greyshirts.sslcapture), let it capture while you turn on, change the color, select an effect and turn off the controller with the "Magic Home" app.

Then you should have "Magic Home" in the list of captured packages

Then open it, press the download button in the upper right and select "Save pcap"

Then post the .pcap here, so I can look if this is a protocol not fully supported by the module.

[lstg]

@autinerd I've collected some initial packet captures from the magic home app.

Firstly, here's the packet capture when going device information screen on the magic home app.

Appears to make a device status request (0x81)

00000000  81 8a 8b 96                                        ....
    00000000  81 a1 23 00 b2 51 00 ff  00 02 03 00 3c 88         ..#..Q.. ....<.

Followed by a time sync (0x10)

00000004  10 14 13 03 15 07 3b 09  04 00 0f ad               ......;. ....
    0000000E  81 a1 23 00 b2 51 00 ff  00 02 03 00 3c 88         ..#..Q.. ....<.

In fact the above 2 packets seem to happen whenever focus goes back to the magichome app.

Additionally the following information is sent as a post request to the magichome server

{"DeviceType":161,"FirmwareVer":"A1_18_20181031","FirmwareVerNum":18,"LEDVersionNum":3,"MacAddress":"DC4F22E18580","ModuleID":"AK001-ZJ210","ModuleType":"AK"}

The following screen is available to configure the LED strip

The following packet is sent when going to the above screen (this appears to be a currently undocumented command)

00000000  63 12 21 36                                        c.!6
    00000000  63 00 3c 04 00 00 00 00  00 00 02 a5               c.<..... ....

Here's turning off then turning on (this looks like the standard format).

00000010  71 24 0f a4                                        q$..
    00000038  0f 71 24 a4                                        .q$.
00000014  71 23 0f a3                                        q#..
    0000003C  0f 71 23 a3                                        .q#.

The functions screen has a list of about 300 different patterns

This is the packet sent when selecting one

00000010  61 00 b2 51 0f 73                                  a..Q.s
    0000000E  81 a1 23 00 b2 51 ff 00  00 02 03 00 3c 88         ..#..Q.. ....<.

Note that it looks like there's an extra byte sent after the usual pattern byte (see https://github.com/Danielhiversen/flux_led/blob/13e87e06ff7589356c83e084a6be768ad1290557/flux_led/__main__.py#L1086)

00 pattern
b2 appears to be the pattern (the pattern number from the list + 100) (eg 78 + 100 = 178 (0xb2))
51 is the speed (eg 81)

Some other examples of the device info message with different patterns selected :

Previous pattern :

00000000  81 8a 8b 96                                        ....
    00000000  81 a1 23 00 b1 51 00 00  00 02 03 00 3c 88         ..#..Q.. ....<.

All red:

00000000  81 8a 8b 96                                        ....
    00000000  81 a1 24 00 61 55 80 00  00 02 03 00 3c bd         ..$.aU.. ....<.

It looks like what is usually the pattern code in position 3 is 0x00 and the pattern code is offset into position 4 (eg 0x61 is the pattern code for "color" mode)

I'll try and capture some more relevant packets this evening (though I've got a young child which can make finding an opportune moment awkward!)

[RIKWEBB]

I seem to be able to switch my Magic Home devices on and off, but not adjust brightness on the two that are just white dimmers. I get this in the log:
Error rendering data template: UndefinedError: 'mappingproxy object' has no attribute 'brightness'
They used to work fine before moving to Hassio 0.90
The colour lightstrip one I have still works fine, brightness, colour all operating as normal.

[lubbertkramer]

@paularmstrong no real dev here so not sure how to test it because you're not talking about adding it to HA as custom component to overrule the component

[amelchio]

Just a note, Home Assistant 0.97 has reverted flux_led to the HA 0.89 state. This should fix the regressions that @alexvandervegt mentioned above.

This issue remains open since AFAIU it is actually about an unsupported model and the regressions were a bit of a tangent.

[henrikklarup]

Been having the same issue, with the same controller.
The strip entity turns off after a few seconds, and I get the following error code inside HA.

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 273, in async_update_ha_state
    self._async_write_ha_state()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 314, in _async_write_ha_state
    attr.update(self.state_attributes or {})
  File "/usr/src/homeassistant/homeassistant/components/light/__init__.py", line 487, in state_attributes
    data[ATTR_EFFECT] = self.effect
  File "/usr/src/homeassistant/homeassistant/components/flux_led/light.py", line 263, in effect
    current_mode = self._bulb.raw_state[3]
TypeError: 'NoneType' object is not subscriptable

I also do not have any color options, but do have a brightness option.
It seems like turning on and turning off the entity does turn on and off the strip, except for the error.
The brightness also adjusts the brightness of the strip.

I have the following config:

light:
  - platform: flux_led
    devices:
      <LEDIP>:
        name: stue_lys
        mode: "rgb"

Any pointers on where I best start to solve this issues. I am thinking about solving it in two steps.
FIrst figuring out how to get the state of the strip. Then figuring out how I can get the color working.

@autinerd maybe you have some pointers on where to start?

[KeNt606]

Have you forgotten about this problem without solving it?

[RIKWEBB]

Have you forgotten about this problem without solving it?

I gave up on waiting for the fix and flashed mine with Tasmota - now they work well

[KeNt606]

Have you forgotten about this problem without solving it?

I gave up on waiting for the fix and flashed mine with Tasmota - now they work well

And what settings on tasmata do you use, what configuration?

[RIKWEBB]

Have you forgotten about this problem without solving it?

I gave up on waiting for the fix and flashed mine with Tasmota - now they work well

And what settings on tasmata do you use, what configuration?

Just flashed - used one of the templates for MagicHome or Arilux and set for autodiscovery in HA
That was it - pretty much, they now appear as a light with the ability to control brightness and colour etc.

[KeNt606]

Have you forgotten about this problem without solving it?

I gave up on waiting for the fix and flashed mine with Tasmota - now they work well

And what settings on tasmata do you use, what configuration?

Just flashed - used one of the templates for MagicHome or Arilux and set for autodiscovery in HA
That was it - pretty much, they now appear as a light with the ability to control brightness and colour etc.

Do you have a controller for tape ws2812b?

[lubbertkramer]

Flashing worked for me for the RGB versions of magic home but not for the WS2812 where you can control 3 or 1 leds independent

[RIKWEBB]

Have you forgotten about this problem without solving it?

I gave up on waiting for the fix and flashed mine with Tasmota - now they work well

And what settings on tasmata do you use, what configuration?

Just flashed - used one of the templates for MagicHome or Arilux and set for autodiscovery in HA
That was it - pretty much, they now appear as a light with the ability to control brightness and colour etc.

Do you have a controller for tape ws2812b?

I just have the RGBW MagicHome controllers

[KeNt606]

Have you forgotten about this problem without solving it?

I gave up on waiting for the fix and flashed mine with Tasmota - now they work well

And what settings on tasmata do you use, what configuration?

Just flashed - used one of the templates for MagicHome or Arilux and set for autodiscovery in HA
That was it - pretty much, they now appear as a light with the ability to control brightness and colour etc.

Do you have a controller for tape ws2812b?

I just have the RGBW MagicHome controllers

I think the solution to the problem in this topic is relevant only for ws2812b controllers (maybe ws2811) because, having flashed my controller on esphome and tasmota, I could not configure it to make it work.

[RIKWEBB]

Have you forgotten about this problem without solving it?

I gave up on waiting for the fix and flashed mine with Tasmota - now they work well

And what settings on tasmata do you use, what configuration?

Just flashed - used one of the templates for MagicHome or Arilux and set for autodiscovery in HA
That was it - pretty much, they now appear as a light with the ability to control brightness and colour etc.

Do you have a controller for tape ws2812b?

I just have the RGBW MagicHome controllers

I think the solution to the problem in this topic is relevant only for ws2812b controllers (maybe ws2811) because, having flashed my controller on esphome and tasmota, I could not configure it to make it work.

Possibly, I think my issue got merged into this one. My problem was specifically around the MagicHome RBGW. Apologies, I didn't spot that.
I don't think this will be fixed given updates were rolled back and there doesn't seem to be any dev on it.
I seem to remember DrZZs trying out something new for the WS2812 type - might be worth looking at? I think its based around esp8266 control -- WLED https://github.com/Aircoookie/WLED

[lstg]

This issue unfortunately has ended up being quite confusing as it seems to have ended up covering 2 separate problems :

1. Support for the new "magic home led spi controller" hardware, which supports individually addressable 'digital' LED strips such as the WS2812. This is a new device which the underlying flux_led library doesn't support. @autinerd made some progress in adding support for these devices, but as it required a fairly large change to the underlying library this ultimately appears to have been abandoned. See also Flux Led/MagicLight - ZJ-MW-HC01 not reporting state #22807 which appears to be a dupe of the original problem mentioned here.
2. A different problem for users of the existing flux_led support using analog RGB/RGBW LED strips that appears to ultimately have been resolved by reverting to a previous version of the flux_led library (see WS2812B RGB not working with Flux_LED #22161 (comment))

As far as I'm aware, there is no support for Tasmota on the "magic home led spi controller" which this issue originally covered. See xoseperez/espurna#1437 for some details of the underlying hardware which you may be able to use to flash it with Tasmota / WLED / esphome, however it's likely this would not directly support the separate IC which it uses to actually control the strip.

[KeNt606]

This issue unfortunately has ended up being quite confusing as it seems to have ended up covering 2 separate problems :

1. Support for the new "magic home led spi controller" hardware, which supports individually addressable 'digital' LED strips such as the WS2812. This is a new device which the underlying flux_led library doesn't support. @autinerd made some progress in adding support for these devices, but as it required a fairly large change to the underlying library this ultimately appears to have been abandoned. See also Flux Led/MagicLight - ZJ-MW-HC01 not reporting state #22807 which appears to be a dupe of the original problem mentioned here.
2. A different problem for users of the existing flux_led support using analog RGB/RGBW LED strips that appears to ultimately have been resolved by reverting to a previous version of the flux_led library (see #22161 (comment))

As far as I'm aware, there is no support for Tasmota on the "magic home led spi controller" which this issue originally covered. See xoseperez/espurna#1437 for some details of the underlying hardware which you may be able to use to flash it with Tasmota / WLED / esphome, however it's likely this would not directly support the separate IC which it uses to actually control the strip.

All this is very sad for the owners of such controllers, including for me. Is there any chance of adding support for spi controllers in flux_led? Can open this request again?

[epikurus]

1. This is a new device which the underlying flux_led library doesn't support.

I believe it's a combination of flux_led library version and a refactor involving HA light component that happenend at some point in the past. This devices were working on previous HA versions (0.8X), at least I had three of the with full control over color and brightness.

@autinerd:
As there's interest in this devices, maybe you could rename the fork to flux_led_spi and make it platform specific (in case of no agreement to merge your PR into main library).
Maybe it's worth looking HA's flux_led component to support this devices (maybe anoter "protocol" config entry?)
I've tried to overwrite HA's flux_led with y fork, but HA's gives the same "Object not scriptable error", although library works flawlessly from cli and test script. Am I missing something?

[lstg]

@epikurus ah right I see, yes I guess before the 'status' check on them was broken you would have been able to control the on / off and set the overall colour as the protocol for these is the same. I only got mine after the point it was already broken so have never seen it even partly working and thus assumed it never was as it also didn't look like the library had any direct support for them.

However the flux_led library won't support setting the pattern correctly for these devices currently, which is kind of the point of using an individually addressable LED strip in the first place. Any attempt to set a pattern on them will likely cause unexpected behaviour (as this controller uses two bytes for the pattern instead of one).

[jannicklorenzen]

Dying to have these controllers work with strips in Home Assistant, even without the built in effects.
For those of you working on it - thank you!

[epikurus]

Playing around with the UI I discovered I can change brightness with the slider (light is on, but HA reports its as off)

[brandond]

I'm going to see if I can get one of the SPI devices to work with ESPHome.

[lstg]

Have a look at Aircoookie/WLED#398 for someone that's similarly trying to flash it.

I suspect whilst you may be able to flash the esp chip, the LEDs go via a separate IC which you'll either need to bypass or interface with.

I'd recommend wled. I've now switched to that with a nodemcu board in favour of this controller

[brandond]

I haven't messed with flashing it yet. I have managed to dump the serial communication between the ESP and the ARM chip, and confirmed that it is just passing raw flux_led message payloads back and forth at 9600 baud, which confirms the theory that it's basically just acting as a modem.

I haven't dumped out all the various special patterns yet, but if they appear to be the same as those already documented by the Python module, it'll probably be easy enough to convert it all over to C++ for ESPHome.

I've already got two of these, 15 meters of LED strip, and a project in mind, so I'm willing to make it work.

[brandond]

I got it turning on and off from ESPHome with a simple uart component and template switch. Unfortunately I neglected to grab the commands that configure the LED type or count, so I'll have to run another capture from the device that I haven't reflashed yet.

I also realized that there does not appear to be a way to control individual LEDs in the strip via the protocol, so I might just end up bodging around the ARM MCU to run the strip off a GPIO anyway.

[stale]

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.

[GrumpyMeow]

I just encountered the same issue with my "Home Magic SPI Controller v3" with a "WS2812B"-strip. The issue is that i had "automatic_add: true" in my configuration, but also explicitly defined the device. The name is then used from the device-definition, but apparently not the mode and/or protocol settings. The default mode is RGBW which causes the exception.

This worked for me:

- platform: flux_led
    automatic_add: false    <-- set this disabled
    devices:
      192.168.11.220:
        name: Harrie's disco schuur verlichting
        mode: rgb     <--- chose the correct mode for my led-strip
        protocol: ledenet 

To patch the exception in code, i did this in components/flux_led/light.py:

    @property
    def effect(self):
        """Return the current effect."""
        if self._bulb.raw_state is None:
           _LOGGER.warning("raw_state is None. Maybe you have to disable automatic_add and choose the correct mode (rgb)")
           return None

I still see the following issues:

• When controlling the device through the App. The status in HASS is not updated.
• When i choose an effect, this doesn't work. Nothing changes.

[bdraco]

Implemented in 2021.12