Core: 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 :joy:

[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 

![Screenshot_20190321-075858](https://user-images.githubusercontent.com/302556/54744949-36ff0f00-4bc0-11e9-9761-570e4d2903ee.png)

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

![Screenshot_20190321-075816](https://user-images.githubusercontent.com/302556/54745311-1aafa200-4bc1-11e9-9f19-44c772ff8f9b.png)

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.

[Obicom]

Enclosed my pcap file:

WS2812B.zip

[Obicom]

Do someone have a idea why I was a short while able to control from HA on/off, brightness an color ... and now (also with new release 0.90.0) I can switch on but after 5 seconds later the HA switch switch back to off from alone? I can try what I want ... I am not able to reproduce the control mode ... I guess the problem with the "Function" (effects) is that the WS2812B controler has complete other effects (300) then the normal RGB controlers.

[lstg]

@Obicom as the on off is the same I suspect that will work until it tries to process the device status that is returned (at which point the mode becomes "unknown" probably leading to further errors)

[autinerd]

@Obicom do you know which color was set at the beginning of the capture?

@lstg Can you send me the request and response when:

• You put the color on complete red
• You change the GRB to RGB and then back
• You change the IC type to UCS1903 and then back
• You change the LED quantity
  Then maybe I can extract the needed numbers from the magic home app. I found some stuff there, but I don't know which of these magic numbers are used for transmitting.

[lstg]

I think there are 2 commands involved :

0x62 - sets the values

request : 
#pos  0  1  2  3  4  5  6  7  8  9 10 11 12
#    62 00 3c 04 0e 0c 06 12 03 e8 02 f0 b1
#     |  |  |  |  |  |  |  |  |  |  |  |  |  
#     |  |  |  |  |  |  |  |  |  |  |  |  checksum
#     |  |  |  |  |  |  |  |  |  |  |  ??
#     |  |  |  |  |  |  |  |  |  |  wiring
#     |  |  |  |  |  |  |  |  |  ??
#     |  |  |  |  |  |  |  |  ??
#     |  |  |  |  |  |  |  ??
#     |  |  |  |  |  |  ??
#     |  |  |  |  |  ???
#     |  |  |  |  ????
#     |  |  |  ic
#     |  |  num pixels (16 bit, low byte)
#     |  num pixels (16 bit, high byte)
#     msg head
#

0x63 - retrieves the current settings

request : 
#pos  0  1  2  3 
#    63 12 21 36   
#     |  |  |  | 
#     |  |  |  checksum
#     |  |  ???
#     |  ???
#     msg head
#

response:

#pos  0  1  2  3  4  5  6  7  8  9 10 11 
#    63 00 3c 04 00 00 00 00  00 00 02 a5  
#     |  |  |  |  |  |  |  |  |  |  |  |  
#     |  |  |  |  |  |  |  |  |  |  |  checksum
#     |  |  |  |  |  |  |  |  |  |  wiring
#     |  |  |  |  |  |  |  |  |  ??
#     |  |  |  |  |  |  |  |  ??
#     |  |  |  |  |  |  |  ??
#     |  |  |  |  |  |  ??
#     |  |  |  |  |  ???
#     |  |  |  |  ????
#     |  |  |  ic
#     |  |  num pixels (16 bit, low byte)
#     |  num pixels (16 bit, high byte)
#     msg head
#

Details

Num Pixels
60 Pixels :

00000010  62 00 3c 04 0e 0c 06 12  03 e8 02 f0 b1            b.<..... .....
00000000  63 12 21 36                                        c.!6
    00000000  63 00 3c 04 00 00 00 00  00 00 02 a5              

45 Pixels :

0000001D  62 00 2d 04 0e 0c 06 12  03 e8 02 f0 a2            b.-..... .....
00000000  63 12 21 36                                        c.!6
    00000000  63 00 2d 04 00 00 00 00  00 00 02 96               c.-..... ....

So looks like 3rd byte is the number of pixels (0x3c = 60, 0x2d = 45)

Wiring
RGB

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

GRB

00000010  62 00 3c 04 0e 0c 06 12  03 e8 02 f0 b1            b.<..... .....
00000000  63 12 21 36                                        c.!6
    00000000  63 00 3c 04 00 00 00 00  00 00 02 a5               c.<..... ....

BGR

0000001D  62 00 3c 04 0e 0c 06 12  03 e8 05 f0 b4            b.<..... .....
00000000  63 12 21 36                                        c.!6
    00000000  63 00 3c 04 00 00 00 00  00 00 05 a8               c.<..... ....

Looks like the last byte (before the checksum) is the order. I would guess they match the order of the screenshot above.

IC
UCS1903

00000010  62 00 3c 01 28 0a 0a 28  01 e0 02 f0 d6            b.<.(..( .....
00000000  63 12 21 36                                        c.!6
    00000000  63 00 3c 01 00 00 00 00  00 00 02 a2               c.<..... ....

WS2812B

0000002A  62 00 3c 04 0e 0c 06 12  03 e8 02 f0 b1            b.<..... .....
00000000  63 12 21 36                                        c.!6
    00000000  63 00 3c 04 00 00 00 00  00 00 02 a5               c.<..... ....

LB1914

0000001D  62 00 3c 08 0c 0c 06 84  06 40 02 f0 80            b.<..... .@...
00000000  63 12 21 36                                        c.!6
    00000000  63 00 3c 08 00 00 00 00  00 00 02 a9               c.<..... ....

So the 4th Byte looks to be the IC. Again I would guess that the order matches the list from the screenshot above.

[lstg]

This is red full 255

0000004C  31 ff 00 00 00 00 0f 3f                            1......? 

Here's various other reds (adjusting the brightness slider in the app)

0000064  31 cb 00 00 00 00 0f 0b                            1....... 
0000006C  31 c5 00 00 00 00 0f 05                            1....... 
00000074  31 c2 00 00 00 00 0f 02                            1....... 
0000007C  31 c1 00 00 00 00 0f 01                            1....... 
00000084  31 be 00 00 00 00 0f fe                            1....... 
0000008C  31 ba 00 00 00 00 0f fa                            1....... 
00000094  31 bd 00 00 00 00 0f fd                            1....... 
0000009C  31 bf 00 00 00 00 0f ff                            1....... 
000000A4  31 bf 00 00 00 00 0f ff                            1....... 

This is full blue

00000026  31 00 00 ff 00 00 0f 3f                            1......? 

This looks to match the standard packet format

[lstg]

This is changing between different functions/patterns :

00000010  61 00 65 33 0f 08                                  a.e3..
00000016  61 00 66 33 0f 09                                  a.f3..
0000001C  61 00 67 33 0f 0a                                  a.g3..
00000022  61 00 77 33 0f 1a                                  a.w3..
00000028  61 00 7c 33 0f 1f                                  a.|3..

And changing the speed :

00000010  61 00 7c 5b 0f 47                                  a.|[.G
00000016  61 00 7c 64 0f 50                                  a.|d.P
0000001C  61 00 7c 32 0f 1e                                  a.|2..

As I mentioned previously it looks like there is an extra byte before the normal pattern values. As there are now > 255 patterns it needs an extra byte

Here's a higher number pattern selection

61 01 8e 33 0f 32  

Thus the pattern command is as follows :

#pos  0  1  2  3  4  5 
#    61 01 8e 33 0f 32  
#     |  |  |  |  |  |  
#     |  |  |  |  |  checksum
#     |  |  |  |  local/remote
#     |  |  |  speed
#     |  |  pattern (16 bit, low byte)
#     |  pattern (16 bit, high byte)
#     msg head
#

[autinerd]

Thank you very much! I hope I can implement the stuff in the next days to the flux_led module and afterwards here as well.

[Obicom]

@autinerd I am not sure but if needed I could do a new test but please tell me what I should do exactly ...

[Obicom]

@autinerd I see we both come from Germany ... it would be also possible that I send you my controller if it would help to implement this one quick & seriously ....

[lstg]

Great, sounds good :)

The 16 bit word for the pattern selection got me thinking and the same applies to the number of pixels :

Here's 1000 pixels :

0000001D  62 03 e8 04 0e 0c 06 12  03 e8 02 f0 60            b....... ....`
00000000  63 12 21 36                                        c.!6
    00000000  63 03 e8 04 00 00 00 00  00 00 02 54               c....... ...T

So the first 2 bytes are the number of pixels (0x03 0xe8 = 1000)

I've updated my comment above with the command details to reflect this.

[autinerd]

In the next days I will implement it and write a test script, which you can run and which will check if it works correctly.

[Obicom]

That sounds great ...

[autinerd]

@lstg @Obicom how much patterns are available at the Magic Home App?

[lstg]

@autinerd 300! I'll see if I can get a list of them for you. They appear to be in the apk.

Note I've also stumbled across this with some further details about the hardware in the controller https://github.com/xoseperez/espurna/issues/1437

And this HA community post : https://community.home-assistant.io/t/new-controller/79111

[lstg]

@autinerd Here's the list of all the different patterns : patterns-sorted.txt

[lstg]

Also, looking back over the traces I think that the IC configuration is bytes 3 - 9 in the 0x62 request (not just the third byte as I suspected originally) as this varies between each of them:

IC Selected|Full 0x62|IC config?
----|----|----
WS28182B|62 00 3c 04 0e 0c 06 12 03 e8 02 f0 b1|04 0e 0c 06 12 03 e8
UCS1903|62 00 3c 01 28 0a 0a 28 01 e0 02 f0 d6|01 28 0a 0a 28 01 e0
LB1914|62 00 3c 08 0c 0c 06 84 06 40 02 f0 80|08 0c 0c 06 84 06 40

I'll try to gather some more traces later to confirm.

[lstg]

Have managed to get full traces of all the ICs now :

IC Selected|Full 0x62|IC config?
----|----|----
UCS1903 |62 00 3c 01 28 0a 0a 28 01 e0 02 f0 d6|01 28 0a 0a 28 01 e0
SM16703 |62 00 3c 02 12 06 00 12 06 40 02 f0 02|02 12 06 00 12 06 40
WS2811 |62 00 3c 03 28 0a 0a 28 03 e8 02 f0 e2|03 28 0a 0a 28 03 e8
WS28182B|62 00 3c 04 0e 0c 06 12 03 e8 02 f0 b1|04 0e 0c 06 12 03 e8
SK6812 |62 00 3c 05 0c 0c 06 84 06 40 02 f0 7d|05 0c 0c 06 84 06 40
INK1003 |62 00 3c 06 0c 0c 06 84 06 40 02 f0 7e|06 0c 0c 06 84 06 40
WS2801 |62 00 3c 07 0c 0c 06 84 06 40 02 f0 7f|07 0c 0c 06 84 06 40
LB1914 |62 00 3c 08 0c 0c 06 84 06 40 02 f0 80|08 0c 0c 06 84 06 40

[lubbertkramer]

This issue looks like mine issue with the ZJ-MW-HC01 and a WS2811 ledstrip -> https://github.com/home-assistant/home-assistant/issues/22807

[autinerd]

@lstg Wow, you are great! I will put this into the flux_led module and afterwards into the config options here.

[autinerd]

@lubbertkramer You are right, it's because the flux_led module doesn't support strip controllers yet. I'm working on it, I hope that this week I am able to finish it.

[lubbertkramer]

Great to hear @autinerd , let me know when we can test for you. Thanks!

[autinerd]

Good news @lubbertkramer @lstg @Obicom, the test file is now finished! https://github.com/autinerd/flux_led Just clone the repo or download the zip file to your computer, go to the directory and run python3 striptest.py. After testing, please say if it's working or if there are any problems.

[lstg]

@autinerd awesome, thanks, will try and give it a test tonight :)

[lubbertkramer]

Will dive in it tonight, but do in need to install it locally instead of downloading the file and adding it as a custom component in HA?

[autinerd]

@lubbertkramer It is independent. You just need an installed python 3.x.

[Obicom]

Here my result:

Thank you for doing the testing of Magic Home RGB strip controllers.
Before starting, please open the Magic Home App and look how your strip setup is for checking.
When the test stops before finishes, please post the text into the thread on GitHub.

Please enter the ip address of the strip controller: 192.168.1.105
Checking whether connection to controller works... yes
Checking whether controller is a strip controller... yes
Checking if the strip controller status can be received... yes
Checking whether the strip setup data can be understood... yes
Checking whether the strip IC value can be understood... no

[autinerd]

@Obicom Thank you. I forgot to implement that it prints out the data for debugging. Can you update the striptest.py and run it again?

[lstg]

Here's mine (note that I needed to split the print(stripdata) into it's own statement on line 40 as was getting a concatenation error :

Checking whether connection to controller works... yes
Checking whether controller is a strip controller... yes
Checking if the strip controller status can be received... yes
Checking whether the strip setup data can be understood... yes
Received strip data:
bytearray(b'c\x00<\x04\x00\x00\x00\x00\x00\x00\x02\xa5')
Checking whether the strip IC value can be understood... no

Packet trace :

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

It think for some reason the 0x63 only includes the IC "index" (eg0x04) and not the other values which are sent to configure it in the 0x62 message

[lstg]

Couple of other bits (if I skip the assertion :p )

Traceback (most recent call last):
  File "striptest.py", line 55, in <module>
    askyesno("Is the LED count = "+led_count+"?", 0)
TypeError: can only concatenate str (not "int") to str

Replacing the relevant line with askyesno("Is the LED count = "+str(led_count)+"?", 0) seems to fix it (though I then get "Is the LED count = 0?").

led_count = struct.unpack('>h', stripdata[1:3])

I think might work instead of trying to bitshift?

[Obicom]

Please enter the ip address of the strip controller: 192.168.1.105
Checking whether connection to controller works... yes
Checking whether controller is a strip controller... yes
Checking if the strip controller status can be received... yes
Checking whether the strip setup data can be understood... yes
Traceback (most recent call last):
File "C:UsersobicoDesktopflux_led-masterstriptest.py", line 40, in
print("Received strip data: "+stripdata)
TypeError: can only concatenate str (not "bytearray") to str

[autinerd]

Thank you very much @lstg and @Obicom, have the bugs now fixed and it's now possible to get the IC with just the first byte. Can you try it again?

[lstg]

Thanks @autinerd :) There still seems to be a couple of issues :

Traceback (most recent call last):
  File "striptest.py", line 41, in <module>
    print("Received strip data: "+hexlify(stripdata))
TypeError: can only concatenate str (not "bytes") to str

Moving the hexlify bit into it's own print statement sorts it, and I then get :

Received strip data:
b'63003c0400000000000002a5'
Checking whether the strip IC value can be understood... no

If I comment out the following line then it does find it (perhaps it's throwing an exception?)

    ic = flux.StripIC(stripdata[3:10])

And I get the following :

Received strip data:
b'63003c0400000000000002a5'
Checking whether the strip IC value can be understood... yes
Checking whether the strip wiring value can be understood... yes
Is the LED count = 60? (Y/n) Y
Is the strip IC = WS2812B? (Y/n) Y
Is the strip wiring = GRB? (Y/n) Y
Checking whether values are recognized correctly... yes
Now it will be tested whether the communication with the strip controller works...
Is the controller currently off? (Y/n)

Note I'm currently testing the above with a mountebank mock server based on the packet sniffs (as I don't currently have access to the device as I'm at work). Will update you with the further results when I test against the actual controller later. I can send you the configuration I'm using for the mock server if you'd like to use it in your testing too?

[autinerd]

@lstg Thank you very much, I have now fixed these little bugs.

[Obicom]

Thank you for doing the testing of Magic Home RGB strip controllers.
Before starting, please open the Magic Home App and look how your strip setup is for checking.
When the test stops before finishes, please post the text into the thread on GitHub.
Please enter the ip address of the strip controller: 192.168.1.105
Checking whether connection to controller works... yes
Checking whether controller is a strip controller... yes
Checking if the strip controller status can be received... yes
Checking whether the strip setup data can be understood... yes
Received strip data: b'6300640400000000000002cd'
Checking whether the strip IC value can be understood... yes
Checking whether the strip wiring value can be understood... yes
Is the LED count = 100? (Y/n) y
Is the strip IC = WS2812B? (Y/n) y
Is the strip wiring = GRB? (Y/n) y
Checking whether values are recognized correctly... yes
Now it will be tested whether the communication with the strip controller works...
Is the controller currently off? (Y/n) n
Is the light now red? (Y/n) y
Traceback (most recent call last):
File "C:UsersobicoDesktopflux_led-master (1)flux_led-masterstriptest.py", line 74, in
if answers[5][1] == 0:
IndexError: list index out of range

>

[autinerd]

Is now fixed. I hope that the test can now run without more problems.

[Obicom]

Please enter the ip address of the strip controller: 192.168.1.105
Checking whether connection to controller works... yes
Checking whether controller is a strip controller... yes
Checking if the strip controller status can be received... yes
Checking whether the strip setup data can be understood... yes
Received strip data: b'6300640400000000000002cd'
Checking whether the strip IC value can be understood... yes
Checking whether the strip wiring value can be understood... yes
Is the LED count = 100? (Y/n) y
Is the strip IC = WS2812B? (Y/n) y
Is the strip wiring = GRB? (Y/n) y
Checking whether values are recognized correctly... yes
Now it will be tested whether the communication with the strip controller works...
Is the controller currently off? (Y/n) n
Is the light now red? (Y/n) y
Is the light now green? (Y/n) y
Is the light now blue? (Y/n) y
Testing whether effects can be addressed...
Traceback (most recent call last):
File "C:UsersobicoDesktopflux_led-masterstriptest.py", line 101, in
controller.setPresetPattern(102, 50)
File "C:UsersobicoDesktopflux_led-masterflux_led__main__.py", line 1159, in setPresetPattern
PresetPattern.valtostr(pattern)
File "C:UsersobicoDesktopflux_led-masterflux_led__main__.py", line 206, in valtostr
return pattern.name
AttributeError: 'int' object has no attribute 'name'

[enbrander]

I've had an issue with my MagicHome LED strip controllers since .90, and have had to refrain from upgrading past .89 in order to keep functionality. I'm not sure if this issue is related to the one I'm having, which I believe is discussed in Issue 20733 but that has been merged and closed.

"This seems to have broken my ability to control my MagicHome RGBW strip, making either my RGB brightness work or the whitevalue work, but setting one turns off the other. If I revert back to .89 it works perfectly."
@alexvandervegt appears to have had the same problem.
If my symptoms are related to this issue then I'll just wait for it to be fixed and/or reverted. However, if this is unrelated then I will open a new issue and flag @autinerd as requested in that other thread.
Also, I'm more than willing to help troubleshoot though my skills in this area are mediocre so be gentle on me.
THANKS!
-Eric

[autinerd]

@Obicom I have fixed the issue, can you try again? Thank you very much.

[autinerd]

@enbrander Thank you for posting the issue, that is a new one. I didn't know that there are some types which can do both at the same time. Can you open a new issue?

[enbrander]

Will do!

[Obicom]

@autinerd -> Unfortunately is not 100% fixed:

Please enter the ip address of the strip controller: 192.168.1.105
Checking whether connection to controller works... yes
Checking whether controller is a strip controller... yes
Checking if the strip controller status can be received... yes
Checking whether the strip setup data can be understood... yes
Received strip data: b'6300640400000000000002cd'
Checking whether the strip IC value can be understood... yes
Checking whether the strip wiring value can be understood... yes
Is the LED count = 100? (Y/n) y
Is the strip IC = WS2812B? (Y/n) y
Is the strip wiring = GRB? (Y/n) y
Checking whether values are recognized correctly... yes
Now it will be tested whether the communication with the strip controller works...
Is the controller currently off? (Y/n) n
Is the light now red? (Y/n) y
Is the light now green? (Y/n) y
Is the light now blue? (Y/n) y
Testing whether effects can be addressed...
Traceback (most recent call last):
  File "C:\Users\obico\Desktop\flux_led-master\striptest.py", line 101, in <module>
    controller.setPresetPattern(102, 50)
  File "C:\Users\obico\Desktop\flux_led-master\flux_led\__main__.py", line 1160, in setPresetPattern
    raise Exception
Exception

[lubbertkramer]

@lubbertkramer It is independent. You just need an installed python 3.x.

Not fully understanding how this can be tested, i'm running HA on a NUC with Ubuntu where HA is running in a docker. Contacting me directly instead of posting here can also be done so i can help testing.

Otherwise i would like to know how to put this into HA?

[autinerd]

@Obicom can you try again?

[Obicom]

I tried but the last question "Is the effect now "7 colors change gradually"? (Y/n)" I have to answer with "No" (light starts from red low light and goes step by step brighter) I got an error. (Same if I say "Yes"):

Please enter the ip address of the strip controller: 192.168.1.105
Checking whether connection to controller works... yes
Checking whether controller is a strip controller... yes
Checking if the strip controller status can be received... yes
Checking whether the strip setup data can be understood... yes
Received strip data: b'6300640400000000000002cd'
Checking whether the strip IC value can be understood... yes
Checking whether the strip wiring value can be understood... yes
Is the LED count = 100? (Y/n) y
Is the strip IC = WS2812B? (Y/n) y
Is the strip wiring = GRB? (Y/n) y
Checking whether values are recognized correctly... yes
Now it will be tested whether the communication with the strip controller works...
Is the controller currently off? (Y/n) n
Is the light now red? (Y/n) y
Is the light now green? (Y/n) y
Is the light now blue? (Y/n) y
Testing whether effects can be addressed...
Is the effect now "7 colors change gradually"? (Y/n) n
Traceback (most recent call last):
File "C:UsersobicoDesktopflux_led-masterstriptest.py", line 103, in
if answers[10][1] == 0:
IndexError: list index out of range

[autinerd]

@Obicom Ich have now fixed all of the bugs, and it will now print the current state after connecting. Can you set up an effect before doing the test and post the effect number from the App with the answer of the controller status? Maybe the offset is not right in my test.

[KeNt606]

@autinerd , so I tried how the script checks the effects:
Effect 80, speed 87 - b'81a12300a95700ff000203003c85'
Effect 208, speed 68 - b'81a123013344000a0a0203003c12'
Effect 296, speed 100 - b'81a123018b64ffae510203003c74'

[Obicom]

I am currently on vacation and not able to do any testing, sorry..

[lstg]

I've tested now and all works aside from the effect :) I think it's off by one as it looks like the effect being show is "7 colours run in olivary". However it's hard to tell if it's one higher or one lower as both appear the same.

A better test pattern may be "7 colours change quickly" as it will be easier to identify which of the neighbouring patterns is shown.

[autinerd]

@lstg I have changed it, can you try again?

[lstg]

Great, thanks, that seems to all work for me now :)

[autinerd]

Very good, when there are no problems then I would do the pull request to the module.

[lubbertkramer]

Sounds good, then i can also test it once it's merged :)

[alexvandervegt]

When will this all be available in home assistant? Because my led strip is now broken for to long :P

[autinerd]

I have opened the pull request at Danielhiversen/flux_led#59, when all there is done, I will edit the flux_led module inside of home assistant and hopefully as soon as possible it will be working.

[alexvandervegt]

When can we expect an update?

[RIKWEBB]

Is there any estimated timescale for this fix to become live?
Apologies for chasing, but I have 3 lights that I cannot control correctly and my wife is complaining LOL 🤣

[alexvandervegt]

Yes i have the same, I have 8 lights which are not working. This sucks big time...

Maybe @Danielhiversen can roll-back this all for now?

[alexvandervegt]

@autinerd @danielhiversen can someone start taking care? We had a good solution. Now nothing works at all i have 8 lights which are totally uncontrollable.

This is becoming frustrating because nobody is telling us anything.

Of they dont want to fix it then please roll it back so we can all enjoy our lights again.

[Danielhiversen]

@alexvandervegt You are welcome to open a pull request to revert the code back to a working state.

[alexvandervegt]

Version 85 was working fine.

[balloob]

@alexvandervegt your comment is rude and you are making it sound like they owe any time to help you and your problem. They don't.

This is open source. People volunteer.

[alexvandervegt]

Everything was working perfectly. And in my opinion they don't need to do anything. All i ask for is a rollback but nobody is doing anything.

Whats the point of making something if someone else breaks it completely and nobody wants to do a rollback?

Just roll it back untill everything is tested carefully then proceed.

We are all using this software in our homes. Half of my lights are not working for 3 months now and i still cant be pissed off about it. Because it's open source?

[balloob]

You can be pissed about things. You can however not demand anything from anyone. Nobody owes you a reply. We work hard on keeping this place a friendly place for contributors and users, and so yes, we will call people out that are having a negative impact on our welcoming environment.

Five days ago Daniel commented that you could open a pull request to revert the changes. That should help you get to a solution for your problem.

[paularmstrong]

Sorry I'm coming in pretty late here and just trying to catch up. I don't have the full extent of the history of what's going on here, but I'll try to ask questions for understanding and hopefully steer the discussion back to a more respectful state.

I'm a bit lost and perhaps we could get a recap:

I have opened the pull request at Danielhiversen/flux_led#59, when all there is done, I will edit the flux_led module inside of home assistant and hopefully as soon as possible it will be working.

• Is this pull request the main blocker for home-assistant?
• Is there something we're waiting for on the issue outside of review/merge/publish? Or is there more work to be done to help get the PR into a state that will allow it to get into that state? (if so, would love to see what needs to be done and if some of us could help out)

@alexvandervegt You are welcome to open a pull request to revert the code back to a working state.

I'm not seeing discussion of what change(s) broke the behavior. I think I read through everything here, but I could have missed something.

Also, this comment seems contradictory to the PR for flux_led ¯_(ツ)_/¯

Good news @lubbertkramer @lstg @Obicom, the test file is now finished! https://github.com/autinerd/flux_led Just clone the repo or download the zip file to your computer, go to the directory and run python3 striptest.py. After testing, please say if it's working or if there are any problems.

This is working great for me! (though "changing quickly" is objective 😄 )

[[0, 1], [1, 1], [2, 1], [3, 0], [5, 1], [7, 1], [9, 1], [10, 1], [11, 1]]

[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 https://github.com/home-assistant/home-assistant/issues/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 https://github.com/home-assistant/home-assistant/issues/22161#issuecomment-519916930)

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 https://github.com/xoseperez/espurna/issues/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 #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).

[Noizexx]

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 https://github.com/Aircoookie/WLED/issues/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[bot]]

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.