WS2812B RGB not working with Flux_LED

Obicom commented 5 years ago

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 commented 5 years ago

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

Obicom commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

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

Obicom commented 5 years ago

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 commented 5 years ago

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

amelchio commented 5 years ago

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

Obicom commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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

autinerd commented 5 years ago

@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. Screenshot (34)

Obicom commented 5 years ago

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

Obicom commented 5 years ago

autinerd commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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

lstg commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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

autinerd commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

@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 signal-attachment

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

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

lstg commented 5 years ago

@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

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

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 commented 5 years ago

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 commented 5 years ago

Enclosed my pcap file:

WS2812B.zip

Obicom commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

Obicom commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

That sounds great ...

autinerd commented 5 years ago

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

lstg commented 5 years ago

@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 commented 5 years ago

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

lstg commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

autinerd commented 5 years ago

@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 commented 5 years ago

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

autinerd commented 5 years ago

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.

home-assistant / core

WS2812B RGB not working with Flux_LED #22161