I agree. I assume they’re the same as well. I didn’t have much time to test last night and I’m currently at work (shhhh) so I’ll likely be testing it tomorrow or late tonight. I’ll be using a RGBW strip with it which works in the app but I’ll give RGB mode a try to see what it does. Nevertheless, I’m encouraged by the progress and attention this is getting. I also won’t have access to a windows machine this weekend but I’ll try to find a Debian alternative to packet capturing if I’m still having trouble after trying your suggestion.
[[edit]] I did try both mods on both controllers. One shows V1 and the other is V3 in the app. Only the V3 mods worked with the V3 controller. Haven’t tried the RGB mode yet. Also noticed the RGB mode got pushed to production today so I’ll update HA first before testing.
@Danielhiversen
Not sure how easily it could be implemented but similar to setting mode RGB, I was thinking a version option could be manually set to differentiate the different byte signals each need. I’m not sure if that would break it for other bulbs and controllers that it currently supports but it was just a thought.
@Danielhiversen - I can confirm v1 changes are effective here.
(edited to add) > I am using the same XCSOURCE controller simpat1zq mentioned in the first post. Magic Home app reports my lights are v1. I have six controllers, (all the same sku), they all work with this patch.
I do seem to have an issue where they get “stuck” and stop responding to packets occasionally. A power cycle fixes it. This causes exceptions in the HASS log. I didn’t notice this behavior before trying this fix, but I can’t say for sure that they are related. These controllers can be unreliable.
@Zen
That’s encouraging Zen. Thank you for the second confirmation. Curious which controller you have. Not sure if there is a difference between the LEDENET and XCSource. I’ll be testing my LEDENET in about 3 hours.
I assumed my V1 is the same as others and unless I’m missing something, the changes that have worked for others haven’t work for me. I am using RGBW strips with these controllers as well, I did try the mode RGB on both and on my V3, the brightness control works but it does have the same bug that @simpat1zq mentioned with resetting the slider to 100% while leaving the LEDs at the correct setting. I noticed after the update and not using RGB mode, I’m not able to control the white with the slider. Sorry I’m not a coder so I know I’m not the most helpful. Does anyone know if might be possible to include the white in the color selector and have the brightness slider effect RGBW? I’ll be looking into trying to packet capture sometime early this week.
I had a chance to do a bit more testing and found my error. I misread the changes for the V1 and didn’t realize it needed a third 0x00. Sorry if I caused any confusion. I can confirm the V1 revisions work on the V1 and the V3 revisions work on the V3. I do get the same effect with the brightness slider bug on both.
It seems that we need to support different protocols for different versions of the bulb.
I hope we can find a way to detect the version of the bulb. Since the is able to detect the version, we should also be able to do so.
It would be great if some people with different versions of the bulb could dowloand the latest version of the lib https://github.com/Danielhiversen/flux_led/blob/master/flux_led/init.py and run python __init__.py --scan --scanresults --info
Then post the output and the version of the bulb here.
Results from V1
pi@raspberrypi:/home/hass/.homeassistant/deps/flux_led $ python latest__init__.py --scan --scanresults --info
ACCF23DEDA14 [192.168.0.18] False [Color: (255, 255, 255) raw state: 129,37,36,97,33,1,255,255,255,0,1,240,240,43,]
Results from V3 Getting an error. Tried with the V1 on the network and by itself. Same result.
pi@raspberrypi:/home/hass/.homeassistant/deps/flux_led $ python latest__init__.py --scan --scanresults --info
Traceback (most recent call last):
File “latest__init__.py”, line 1416, in
main()
File “latest__init__.py”, line 1392, in main
print("{} [{}] {}".format(info[‘id’], info[‘ipaddr’],bulb))
File “latest__init__.py”, line 516, in str
pattern = rx[3]
TypeError: ‘NoneType’ object has no attribute ‘getitem’
Wanted to update the V1 byte information for warm white. The RGB function works with the config you posted but the warm white/brightness slider doesn’t. I found for my controller the config should be the following, line 616 = (0x00), line 617 = (0x00), line 618 = (0x0f). If anyone else is using a V1 with a RGBW strip it would be great if this config could be tested on other devices.
My controller is a “XSOURCE” branded one from Amazon. The Magic Home app identifies it as a V1. I have a RGBW strip hooked up to it.
The only function that works from Home Assistant is on/off. Neither color change or brightness does anything. Strangely however, if I change the color with the Magic Home app, the new color shows on the bulb icon in Home Assistant.
I did some packet captures from the Magic Home app doing various functions.
master on - 71:23:0f:a3
blue - 31:00:00:ff:00:00:f0:0f:2f
green - 31:00:ff:00:00:00:f0:0f:2f
red - 31:ff:00:00:00:00:f0:0f:2f
blue - 31:00:00:ff:00:00:f0:0f:2f
blue brightness change - 31:00:00:82:00:00:f0:0f:b2
rgb brightness to 0 - 31:00:00:00:00:00:f0:0f:30
white on - 31:00:00:00:ff:00:0f:0f:4e
white off - 31:00:00:00:00:00:0f:0f:4f
white on - 31:00:00:00:ff:00:0f:0f:4e
white brightness change 25% - 31:00:00:00:3f:00:0f:0f:8e
master off - 71:24:0f:a4
Looking at the code again, I just realized the packet captures have a extra byte in them compared to the flux_led code! I added the extra byte to both the “SetWarmWhite255” and “SetRGB” functions and now they work from Home Assistant!
Only issue now is the brightness slider… it only changes the brightness of the white LEDs (which is fine), however setting it to 0 turns both the white and color LEDs off. So I can’t totally turn the white LEDs off.
I believe the reason for the extra byte is because this controller supports RGBWW. A RGB strip with both independently controllable cool white and warm white LEDs. You have to manually set your wiring configuration inside the app. Changing the wiring configuration shows/hides various functions inside the app. See the below screen shot.
The software does seem to know the controller requires the extra bytes. As it sends the extra bytes regardless of what wiring configuration you select.
