HI!
You might have heard about this project:
Here’s what I’m thinking. It might be possible to use NodeMCU to listen to what the remotes are sending over 2.4GHz and send it via UDP to Home Assistant, right? Has anyone thought about that? I think that would be amazing!
The only thing I’m curious about is how would I receive the UDP packets in Home Assistant and set the lights status?
Would indeed be very, very cool!!!
I do know the RF-link component (also adruino + NRF24L01+ ) should be able to do this, and already picks up on the remote!!! Same costs, same effort, more functionality… it seems to me…
Unfortunately i lack the knowledge to implement it… Still hoping someone will get to it. Looks so close…
I’m the author of esp8266_milight_hub.
What you’re suggesting is certainly possible in theory, but not a feature of the current firmware.
re: rflink, it’s possible they’ve gotten around to implementing it, but I think I was the first to reverse the RF protocol for newer devices (there was some pretty heavy scrambling involved that took quite a bit of effort to crack), and I’m not sure others have gotten around to implementing it yet.
Amazing! Really nice to have you here.
Do you think it would be possible to implement it in a future release? Just reversing the signal, picking up the signal from the remotes and sending it to HA via UDP or RestAPI.
It’d take a fair amount of work, but certainly possible. The signal can already be received and viewed, it’s just sort of a side-feature right now used to sniff remote IDs.
any news on this, still planning a update?
I have been happily using your project to emulate bridges and connect all my bulbs, having the status paired between Hass and my milight remotes would be great
Ah, sorry if I made it sound like I had active plans for an update. I think it’d be a nice new feature, and it’s definitely on the todo list, but I’m pretty distracted with other projects at the moment.
I did create a Github issue: https://github.com/sidoh/esp8266_milight_hub/issues/83
Happy to take suggestions or look at a PR.
I have uploaded the firmware to my NodeMCU yesterday and I have to say, it works amazing! Good job! We’ll be waiting patiently 
Very nice! Just decided to give it a try today since I had been using the RFLink with some automations linked to my actual lights.
I simply added the “mqtt_topic_pattern” and “mqtt_update_topic_pattern” to the ones suggested on Github
milight/commands/:device_id/:device_type/:group_id
milight/updates/:device_id/:device_type/:group_id
and added on my Hass config under lights:
- platform: mqtt_json name: 'MiLight Test' state_topic: "milight/updates/0x354A/rgbw/1" command_topic: "milight/commands/0x354A/rgbw/1" brightness: true flash: true rgb: true optimistic: false qos: 0
And it worked out of the box I can toggle the light on the remote and have the state updated on Hass!
But if I reboot Hass with the Lights on Hass with boot up with state off, is there a way to fix it?
Also noticed the lights wont go out if being used only by MQTT and Hass reboot!
Glad it’s working!
There’s a bit of work to do before HASS can boot with the correct state:
Also noticed the lights wont go out if being used only by MQTT and Hass reboot!
I’m not sure I’m following what you mean by this. Do you mean you can’t turn off lights from HASS after rebooting it?
Nothing like that, with the normal limitlessled component if the lights are on after Hass reboots they will turn out automatically as stated in the component page
INITIALIZATION & SYNCHRONIZATION
When starting Home Assistant, your LimitlessLED bulbs will be set to known default values. This ensures a consistent user interface and uninterrupted turning on/off. If you control your LimitlessLED lights via the MiLight mobile application or other means while Home Assistant is running, Home Assistant can not track those changes and you may observe unexpected behavior. This is due to a LimitlessLED limitation.
And using only MQTT it doesn’t happen anymore! life saver for when I’m playing around at night with wife around 
Looking better then ever now!
RFLink Gateway was a nice was to fix for the state of the lights, it can read the remote signals but isnt able to control them and I had to create 4 automations per light to keep the state really sync
I’ve got no idea what I’m doing wrong…
I’ve been using this for over a month and everything seems to be working perfectly, I can controll my bulbs through UDP packets, as a regular MiLight Bridge, that’s been working great, I can control my bulbs through MQTT as well… But it doesn’t update the state of the bulbs.
I flashed the latest firmware, 1.4.1. When I click the buton on the remote I can see the NodeMCU blink, so I guess the flashing went OK. But the GUI of the server stays the same… I looked through the Wiki page on GitHub.
I have no “listen_repeats” in the settings… And no “mqtt_update_topic_pattern”… I tried clicking the update Web UI button in the check for updates section, but this is what I get in the serial monitor:
/repos/sidoh/esp8266_milight_hub/releases/latest
.
Exception (29):
epc1=0x4000e1b2 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000004 depc=0x00000000
ctx: cont
sp: 3fff2ea0 end: 3fff3520 offset: 01a0
stack>>>
3fff3040: 3fff9e1e 402317a4 3fff9e1e 4025c323
3fff3050: 00000001 3fff9fdc 3fff7c4c 4025c4bc
3fff3060: 00000000 00000000 0000001f 3fffb0ec
And then the NodeMCU reboots… How do I fix this?
EDIT:
I’ve read the blog post again. I’ve forgotten to update the index.html file. I’m having some trouble with using curl on Windows… But that should be OK. It’s still a bit surprising that I have to do this even though I uploaded the firmware with Atom and PlatformUI…? Strange.
curl keeps saying:
Note: Unnecessary use of -X or --request, POST is already inferred.
Trying 192.168.43.139…
TCP_NODELAY set
Connected to 192.168.43.139 (192.168.43.139) port 80 (#0)
POST /data/web HTTP/1.1
Host: 192.168.43.139
User-Agent: curl/7.54.1
Accept: /
Content-Length: 32905
Expect: 100-continue
Content-Type: multipart/form-data; boundary=------------------------a4c961417c3b1154Done waiting for 100-continue
< HTTP/1.1 404 Not Found
< Content-Type: text/plain
< Content-Length: 20
< Connection: close
< Access-Control-Allow-Origin: *
<
Not found: /data/web* Closing connection 0
Is there a way to check if it’s a problem with my curl or the NodeMCU?
OK! It’s working! Instead of /data/web, i used /web. Hope this helps if someone runs into the same problem.
@arielpod - the exception you’re seeing is because it’s trying to do some SSL stuff when there’s not enough RAM and it’s crapping out when the heap overshoots the stack.
I removed the GitHub/SSL dependency in 1.5.0-dev1. Instead of putting the webpage on SPIFFS, it’s built into a C++ byte array and compiled as part of the firmware. Makes it so you can’t update the webpage without updating the firmware, but I think this is a good tradeoff. Means UI will always be in sync with the firmware, and you won’t ever have to worry about uploading it.
Cool! Thank you very much!
I little bit of help please, I just finished building the HUB, I have a led strip connected to the remote channel 2. When I run the sniffer in the GUI I see device ID 128A, I go to the top of the GUI and I ADD 0x128A and pick channel 2 but it’s not doing anything, I see the esp controller flashes blue but that about it. it’s not controlling the strip, everything works with the remote.
Did you select the “RGB” mode in the UI? I think a different mode is selected by default, and probably won’t work with an RGB strip.
Hi
Need a little help to get this to work.
I have tried both the image and building from source with the same output.
I can´t get pass this:
“Connect the device to your WiFi. Once it’s booted, you should be able to see an unsecured WiFi network named “ESPXXXXXX”, where XXXXXX is a random identifier. Connect to this network and follow the configuration wizard that should come up.”
After connecting to my ESP AP I have nothing… nothing is popping up so I can´t configure it for my WIFI.
I´m using a NodeMCU v3
Any ideas?
EDIT: Finally got the page to appear using my Samsung S7
