As a followup I just did a few tests. I am going to implement a small card that allows you to select the modes and sends the command (likely via REST for me). Last night I used the built in to HA “colorloop” and immediately saw an issue. The little blue light on the ESP board went binkers which leads me to believe they implemented some generic change color/send/increment color/send and it just bogs the network down to crap.
But If I sent a command to select a mode, it is one command and that is all. The controller then handles all the work.
Just testing a new GUI, working great! Uses Mushroom but custom button would be easier and more reusable. But looks like this:
The buttons 1 - 8 are the modes for the remote for colorloop and other things. +/- are speed up and slow down the effects. Those use a simple rest_command template to send the mode/speed switch to the appropriate UDP address.
To do’s –
Get all the addresses from one call and put them in a sensor (done)
Change from mushroom to custom:button so that it can all be templated and reused to reduce code by 80%
Implement a status update for UDP folks since REST can get the status to update the GUI (like if mode 3 is active, color the button)
So far it is now this:
In this image … the Pergola is on to a solid color, the triangle is mode “4”, the table is mode “6” and the kitchen is off.
If a “mode” is active, it shows an animated color icon. Speed up/down and mode selection are all tied to the zone being powered on. Still needs an enhancement to emphasize the mode button when you select a solid color after selecting a mode. Issue is this does not trigger any change in state so that is a challenge.
This was a veeeery long shipment. After almost two months, I finally received FUT036W device. But, they changed a chip, and this one, inside my device, is not supported with OpenBeken yet. I was in doubt either to hardware modify device, and replace native chip with ESP12 since they have same pinout and layout or to make a Milight hub as @BebeMischa proposed. Hub was easier solution for me, cause I already have several ESP8266 laying around, and had a store with NRF24L01 in stock, in neighborhood. Plus, it wouldn’t be easy desolder that chip. I integrated it to HA via MQTT. Actually, firstly I tried to do so via LimitlessLED integration, but it wonted to work. Yup, I created a block in configuration.yaml similar as @kbrown01 provided above, and simlar as on documentation page, only for one device/group. I’m not sure is it UDP needed to be set inside Milight hub firmware in order that this work, but somhow I firstly set MQTT and noticed it is working regardless of LimitlessLED, so I decided to remove LimitlessLED and stick with MQTT, since I am already familiar with it.
Yeah, I know, already said that I was in doubt to replace it with ESP or to make a hub. I am not beginner with soldering, doing it very often. Maybe because of that, I know it is not simple to remove original chip (it is not impossible at all, but it is pain in the…). On top, didn’t want to wait for one more Aliexpress/eBay, since I have no any ESP12, wanted to buy missing locally, so:
ESP12: ~$1 on Aliexpress <> almost $4 in my country
On the other hand, to build a hub, I missed only NRF24L01 which is ~70c on Ali and ~$2 in my country
I was thinking: Even $4 isn’t some big money (but yes, it is insane give $4 for ESP12 ), but hub opens space for me to get more of these MiBoxer devices in future and avoid flashing at all.
Yes, for someone who own hot air gun, I am not in that group . Know for that, already watched some other, but same, video on YT, and was surprised how these things is easy to remove with hot air gun.
), but hub opens space for me to get more of these MiBoxer devices in future and avoid flashing at all.