LimitlessLED new remote/LED strip controller

Is it possible to add support for the Milight LED-CCT compatible remote, so the new LED strip controller (LS-2), and the new CCT bulbs, can be used with HA? (5-in-1 LED controller)

It’s available to view in the Milight app, the remote on the far far right, with eight group buttons.

The controller is compatible with the existing ibox/v6 bridge, so I can control it through the app ok


The Remote control model numbers are:

FUT089 (hand held remote, 8 zones)
B8 (Wall plate remote, 8 zones)

They are apparently the same thing in different form factors.

Is there ongoing development of this component, or are people moving to the MQTT/ESP8266 solution for these bulbs?


What bulbs do you refer? If talking about FUT105 (as far as it was discussed, this is the latest commercial non-DMX512 bulb) then it is supported for some time by the project linked below. B8/FUT089 remotes also work (I’m unsure about B0 and FUT088 as judging from the pictures of the products they are be similar to FUT089, however it should be confirmed). Forwarding of either commands or states from the gateway is very well supported by the MQTT implementation.

The emulator on the ESP8266 is far superior to the ibox (and it only requires one unit for the entire house vs. 4 zones only supported by ibox or 8 zones for FUT089/B8 which actually means that at least 3-4 ibox units are needed to associate each room with a zone and then some, in order to create different groups).

All the ingredients for this solution (D1Mini) are already in the mail. Just a case of waiting for eBay :slight_smile:

In the meantime, I was hoping to get some simple HA control through the limitlessled component.

I’m using the newest LED strip controller, and it responds well to the app and ibox. I know there are equivalent rgb-cct bulbs, but I don’t know the model numbers.

On they have listed all the MiLight compatible devices (at least that’s what I’m guessing).

Limitlessled component of HA is slow (it uses UDP for communicating with ibox), buggy (at almost any version update there are several cases of persons complaining the component is broken; EMH uses MQTT integration so no issues when upgrading HA as it won’t change between different version) and it won’t sync lights in HA if official remotes were used instead of phone/HA. Still, you can use Limitlessled component from HA with EMH instead of MQTT if desired, however except for color wheel in MiLight phone app I see no use for it. Moreover, after HA implemented current color wheel, there is virtually no reason to go back to the separate phone app.

I’ve run EMH on D1 Mini and I wasn’t happy about it (too many missed commands) although I’ve tried the solutions mentioned on the github for improving reliability. Then tried it on regular NodeMCU. The same problems, as NRF24L01 is quite power sensible (a capacitor helped a bit but still far from desired results).

I’ve then turned to D1 R2 (same firmware as D1 mini) which is powered on the 12V rail and (nearly) all the problems were gone. D1 R2 it is, by far, the most stable ESP8266 board I’ve run. I’ve got several GU10 bulbs (FUT103) and these are not very responsive. My personal opinion is that the design for FUT103 is completely messed up, at least compared to FUT018 (same GU10 socket) and commands were dropped either by using the official remote or by using EMH. I’ve tried to solve these by sending each command three times with 100 ms delays. Problem partially solved. But sometimes HA got locked by all of these commands in queue and there were occasional delays of 2-3 s between commands instead of 100 ms (which should have been barely visible with naked eye).

Back to drawing board. Again…

Ultimately I’ve solved this placing two EMH (on D1 R2) in opposite corners of the house so they create a mesh network. Then disabled the state updates on one of the units (in order not to flood the state topic); the receiver part of the EMH is literally 100% effective on picking signals from the remotes (either wall mounted or handheld) and sending these as state updates to lights in HA so that the state of bulb is in sync if either remote or HA is used for controlling the bulb.

It is since (about half of year) working reliably in 99.99% of time and I think these rates are comparable to original MiLight controllers; there are occasional command drops (for off commands) which I’ve solved by setting an automation that runs each hour with the off command being sent to bulbs already off.

1 Like

Hi All,

This is my first message in HA community so… Greetings to everybody.

I also have a problem with HA/limtlessled integration as I have built already rich instalation based on FTU089 so to integrate with HA i need to build
NRF24L01+ and NodeCMU as IBOX2 replacement. While I’m reading I’m impressed with sidooh’s module capabilities.


I’d like to build stable controlled so I thought about repeating Petrica’s solution based on D1 R2. I’m not so technical so I’ve got a few questions:

I’ll apprecaite suggestions/feedback on ANY questions above.

I am not sure which stability problems you talk about but I got great improvements by adding a power adapter and have not had any issues since.


Don’t quote me on that but I think there is no D1 R3 (probably some Chinese site confusion with a newer D1 R2 revision).

EMH different versions are based on the flash memory size (4 MB for the regular, 16 MB for the pro version). Any of the D1 mini or D1 R2 (note that D1 R32 is a completely different animal as it is based on ESP32 and EMH is not available for this platform) will work with the D1 mini version.

Not needed, microusb power from the computer during flash is sufficient. Afterwards can power from either microusb or barrel connector (12 V including).

Unfortunately it ain’t exactly 100% sure that a D1 R2 (or newer D1 R2/R3) would work better than a regular NodeMCU. It depends on a lot of factors in addition to the NodeMCU/Wemos and NRF24L01 boards (like type of router you have, noise from other 2.4 Ghz devices such as microwave ovens, other RF devices that can cause interference, etc). You could try a two EMH gateways solution as it will cover a larger area and provide also some redundancy. EMH already includes watchdog functionality but there might be cases when it doesn’t automatically reconnect to wifi so you’ll need to do some debugging.

Probably yes, but not 100% sure. There are a lot of NRF24L01 knockoffs (aka cheap clones) so this should be, in theory, a better option. Chris added a lot of advises for improving stability (including adding capacitors, using longer cables, etc):

I have managed to order several LT8900 boards and will report later if they’re better than NRF24L01 (in theory they should, as this is the chip used by MiLight).

Do you also use wall/handheld MiLight remotes?

Thanks guys for prompt response. This community is awsome…

Hmmm… This is “D1 Uno R3”. I still can buy “D1 R2”, but suprisingly “D1 Uno R3” is cheaper.

OK. So, if I understand you right, I can flash “D1 R2” (or “D1 Uno R3”) with D1-mini image. Thanks for this info.

So, will 5V from USB be enough for regular work (after flashing)?

Yes, I,ve got B8 wall switch and FUT089 remote already paired with… ugh… many… LS2
I’d like to keep remotes, so having state updates in HA is awsome feature for me…

AFAIU some users are responding missing that WIFI is missing some signals to/from bulbs/remotes. I guess the side effect of these “stability problems” is “light state” synchronization problems in HA. Am I right?
Your suggestion about power adapter is also helping, but I would need precise guide how to wire this thing. I’m computer-science professional but coming from “algorythmic” side (math background) not “electronics”… I can do wiring/flashing tricks if they are well described :slight_smile:
EDIT: OK I’ve read a bit and I know how to connect this stabilizer. Maybe I’ll try this with NodeMCU.

BTW. For a while I was tempted to reverse-engineer sidoh’s code and improve component by adding “8-channel remote” compatibility, but I found that light state synchronization with remotes provided by sidoh’s solution is something, which cannot be beated…

Yes, just use a good phone charger (not necessarily a 2.4 A with Quick/Fast Charge/etc but not a very cheap one either; a regular 500 mA should fine).

Hmmm, I think that is still R2 as there is no v3 for the Arduino Uno compatible format board ( If you able to wait for 2-3 weeks you can order directly from Aliexpress (that Amazon product followed the same circuit anyway :slight_smile: )
although I would recommend the black PCB version:

I don’t think there is need for this as FUT089/B8 (8 channel remotes) already has EMH support (FUT045/LSx/FUT103/FUT105 led controllers and bulbs too).

FUT088/B0 (1 channel only, with same protocol as FUT089 but only uses Groups 1 and 0) are quite nice for controlling lights in a single room.

Another advantage of physical remotes is that there is no need to use HA/EMH or other controller such as Google Assistant/Alexa (thus case of power failures/ethernet/wifi issues/etc, the lights can still be controlled without any issues which is not the case for most smart devices).

Thanks Petrica,

And what you think about this one:

This is D1 R2 by Robodyn, slightly different that the one you suggested. I can’t see this big Wifi chip which is on Node MCUIs there any difference?
Can I buy this one and flash it with D1-mini image?

It should work fine with the D1 mini firmware.

Actually this has the same ESP8266 chip as the others. The other boards only have a metal casing around the chip; however, I’m unsure how efficient that is in dissipating heat generated by the chip vs. a bare chip.

Anyway, it doesn’t affect wifi performance as the antenna is located outside the area that is usually covered by the metal casing (the area with the WIFI Alliance logo). The board you pointed is also exposing a connector for external antenna (from what I can see not included with the board).

Both the D1 Mini and the NRF24L01 have versions with external antennae.

I was given to understand they are called the “D1 Mini Pro” and “NRF24L01 + PA + LNA”, respectively. At least that’s how they’re termed by sellers on eBay. Please correct if I’m mistaken.

I’m planning on rebuilding my MiLight Hub with these, someday.

Yes, these hardware revisions both have external antennas. However, they are not the single options for external antennas: the previous board mentioned, with ESP8266, on the Arduino UNO format, has external antenna connector too; also, has an external antenna connector.

For a medium sized house (up to 100 sqm) there is no need for external antenna if the board is located centrally (case the walls are not very thick and no significant metal insertions to create a Faraday cage; anyway, a two gateway option provides both coverage and redundancy). External antennas NRF24L01 boards are usually used for control of drones and other long distance (1 km+) communication. The ESP8266 uses a very low bandwidth of the 2.4 Ghz wifi spectrum thus it doesn’t need a very powerful router to connect to; NRF24L01 should not have direct competition but there’s always the possibility of an obscure device interfering…

You might need to get larger batches (10+) of NRF24L01 to find several good items if the boards seem inexpensive (probably they’re low quality too).

I usually shop directly from Aliexpress and for shops with several thousands of 98%+ positive ratings the products are ok if in the 2 - 5 USD interval, but the Amazon prices are in a quite different range although they’re of the same Chinese origin.

That was the kind of problems I had. Automations in Home Assistant would not always turn bulbs on/off. So I would be down the basement stairs with no light coming on. You asked if it is annoying and it is, very much. But the power adapter fixed it for me.

I am not using remotes, so cannot comment on that. Sometimes I toggle a wall switch to power on a bulb and this will not be synchronized to Home Assistant.

Hi Guys,

I did it. I flushed yesterday brand new NodeMCU+stablizer+WIFI with antenna and… it works like charm! Old IBOX2 will become now addtionall AP :slight_smile:

Now I’d like to ask you for recommendation of setup the HA integration.

I’ve got a challenge, which if not answered maybe growing into new… Feature Request(!)

As I wrote above I have currently many remotes (and B8 wall switches) and many LS2 controllers installed. Some of the LS2s are paired with more than one remote and even worse… some of them are paired under different channel number on each remote (this was to emulate 2-way-switch when you need to turn on/off the same light in hallway with one remotes/wall switches placed/mounted in bedrooms/kitchen.

Now, I had an idea that such light could be controlled in ESP using the same DeviceID as one of the already paired remotes (emulating one of the existing remotes). I guess the “command” MQTT topic will work with no problem.

But… I have a problem with “state” topic. AFAIK the lights are not brodcasting the state but just ESP is publishing intecepted packets from remotes to “state” MQTT topic.
…and in my case, my “MQTT light” in HA wants to listen of a few distinct topics (listening for state updates from more than one remote DeviceId). Note:

  • I cannot use a MQTT topic wildcards (+) for DeviceID as not all remotes are controlling “shared lights”
  • I cannot use wildcards either for “group_number” as I have the same light under different groups on different remotes.

Ideally wit would be if I could point state_topic of “MQTT Light” into two distinct topics e.g.

state_topic: ["milight/states/0x5423/fut089/1", "milight/states/0x6743/fut089/8"]

but I can’t see such option.

I’ll appreciate any ideas, hints, aswers…

Got you covered :slight_smile:

Unfortunately, except for some weird case scenario (when in Dance revolution mode :smiley:) bulbs don’t give you any feedback (state responses come from the EMH gateway if captured from other remotes and for commands sent they’re caught in software (i.e. the EMH gateway doesn’t send the package and then to be listening for reply from the bulbs).

You can pair each bulb/led controller with up to 4 different remote IDs (that is you can’t pair one bulb with two different IDs on the same remote; however, you can use group 0 of that remote to control all lights).

Also, you cannot add two state topics for the light. You could try to set automations that forward states back and forth between the two but it’s going to take a lot of effort to set it (and it won’t be right, either as I’ve tried some combinations until I got it).

Context: EMH has three different topics to work with:

  • topic (which you need to set in HA to the command topic for the light);
  • state (in HA set as the state/status topic for the light); this includes full state and HA can even be set without it (although it is recommended to keep);
  • update (this doesn’t have a direct correspondent in HA but comes into play later); this is, in fact, what the bulb receives, individual changes (like change RGB, change saturation, turn on or turn off), not full state;

Set only one remote as the light in HA (for instance 5423). You don’t need the second remote to be set in HA if it will control the same bulb.

Then set an automation to forward MQTT messages on the update topic from the secondary remote (6743) to the command topic of the main remote (5423) (you need to also set the update topic in EMH - similarly to the ones for command and state)

- alias: MiLight Sync
  initial_state: True
    platform: mqtt
    topic: 'milight/update/0x6743/fut089/8'
    - service: mqtt.publish
        topic: 'milight/0x5423/fut089/1'
        payload_template: >
          {{ trigger.payload }}

Not very logical at first sight but after giving some thought it will be :slight_smile: Lights won’t flicker, as the bulbs already have changed to the command provided by the secondary remote, but it will keep an updated state for the lights.

I have a wall remote that I have paired to all bulbs in the house in order to be able to control them at once. The automation above would include, in the action part, the command topic for all the lights. Remember: this is only to keep them in sync in HA as the physical state of the bulbs has already changed. Don’t think you’ll need that ibox (maybe another EMH as backup/increase coverage).

If you’re willing to follow I think I’ll be able to finish soon polishing (need to get some commenting job done :smiley: ) a full package for seamless control of lights (keep sync with multiple remotes; turn lights on from PIR sensors with reset-able timers each time a new motion triggers it or from smart switches with different turn off time depending on what device turned on the lights; different color settings/brightness and timers based on time of day, set brightness to 1 before turning the bulbs off to prevent turning on at full brightness, etc.)

You won’t believe it but I found this solution already, just turned to a topic to describe it. This was a code I’ve prepared nearly 1:1 as yours

- id: '3333'
  alias: B8 Remote Sync
  initial_state: True
    platform: mqtt
    topic: milight/sta/0x5FFF/fut089/1
    - service: mqtt.publish
        topic: milight/sta/0x5BAC/fut089/4
        payload_template: >
          {{ trigger.payload }}

This is great and… works! Maybe I’m bit too enthusiastic, but first impression is great.

I’m just starting with HA but want to thank all the community for their hard work on custom firmware devices and… knowledge
Thanks Petrica…

BTW. IBOX2 will be AP for extending WIFI coverage as I have places at home where the signal is hmmmm just weak.

This won’t work reliably. There are several reasons behind it:

  • bulbs don’t publish their state;
  • remotes don’t keep track of their state; it’s the EMH gateway that keeps track and publishes the full state topic.

When using a remote, the commands sent are not the ones published on the full state topic (like {“state”:ON,“color”:{“r”:150,“g”:200,“b”:30},“brightness”:200}) but individual commands only ({“state”:ON}, {“color”:{“r”…}},{“brightness”:}, etc). As a result, although state published by one remote includes {“state”:on}, this is only kept by the EMH, not the actual state of the bulb. You can easily get into situations where one remote is in off state and the other in on state and copying full state between the two will only mess things up. Just try to do on/off or change colors independently from the two remotes paired with the same bulb and the light in HA will not be always updated (or even the bulb color matching the HA color).

I spent some time digging (Discrete command for turning the light bulbs off · Issue #451 · sidoh/esp8266_milight_hub · GitHub) Simplest and most elegant solution is to use the automation posted by me before.

Unfortunately, AFAIK, ibox doesn’t work similar to an WIFI repeater. In order to work like that it would need multiple chipsets for receiving, then sending payloads, which the hardware simply doesn’t include. You can see on the official Limitless page integration (which is completely different than EMH) that HA cannot track it if using another way of controlling the light besides HA (such as a wall/handheld remote or the mobile app; by the way, don’t see the point of using the mobile app as HA controls are superior). If using both Limitless and MQTT to control same bulb you’ll end up in a lot of problems synchronizing these two…

You can use EMH to setup a Limitless hub (and use the Limitless HA integration; might wander why do this if EMH HA integration using MQTT is superior to Limitless, which uses UDP; the reason is that Limitless integration supports transition; you could do it with MQTT but it is a little more tedious) and not the other way around.

Solution to increase coverage is to use another EMH gateway or, if using a single gateway, to place it centrally (anyway, it doesn’t work on ethernet so no problem finding a good spot).