EspMilightHub new binding for milight limitlessLED and easybulb

UPDATE: For all OH3 users please update to minimum of 3.1.0 Milestone 1 and the latest binding is merged and built in from now on.

Just wanted to let other users of Milight globes know that I have completed a new Binding that allows a single opensource Bridge (bridge created by Chris Mullins aka Sidoh) to automatically find and add Milight globes into OpenHab. The first question Openhab users may have is “Why another binding when one already exists?”, The short answer/s to this is the new OPENSOURCE bridge allows:

  1. Almost unlimited groups so you can have individual control over an entire house of Milight globes without multiple OEM bridges. A single bridge uses less power for one of many advantages of having only 1 hub/bridge.

  2. If using the Milight remotes to control the globes, this binding will update the openhab controls the moment a key is pressed on the remote.

  3. Auto scan and adding of the globes via paper UI.

  4. If you reboot Openhab the state of the globes will refresh and display correctly after the reboot due to the hub tracking the states and recording them in the MQTT broker. Even if people are using a remote whilst openHAB is rebooting.

  5. Many other reasons besides just being opensource and hence can get firmware updates to support new globes and wifi KRACK patches.

See post two of this thread for details on how to setup and use the binding.

In depth details on how to build and what the bridge is can be found here:
http://blog.christophermullins.com/2017/02/11/milight-wifi-gateway-emulator-on-an-esp8266/248

A quick overview of the steps to get the hardware going are:

Connect a nodemcu/esp8266 to your computer via USB
Download the latest BIN file from here https://github.com/sidoh/esp8266_milight_hub/releases101
Download esp8266flasher if you are on windows GitHub - nodemcu/nodemcu-flasher: A firmware Flash tool for nodemcu
Check the blog above on more info on how to do it from mac or linux.
Open the flasher tool and make sure the flash size is 4mb or whatever your esp8266 board has.
Flash the bin and then press the reset button on the nodemcu board when complete.
Connect to the wifi access point of the esp directly and setup to connect to your network. Blog has more info.
Login by using the IP address of the esp8266 in a web browser and the control panel will show up.
Connect 7 wires between the two ready made PCBs as shown in the above blog.
You then need to get MQTT running as this method uses the faster and lightweight MQTT protcol and not UDP.

13 Likes

All the steps to getting this binding running are found in the readme at the link below. If something is confusing or not clear then post so it can be changed or create a PR.

Readme for openHAB V3.1
EspMilightHub - Bindings | openHAB

4 Likes

This is awesome! I’ll be interested in it.

Very interested. Got some 2.4 GHz antennas a few weeks ago and I’ve been wanting to make a bridge with an esp, just haven’t had the time. I’d definitely wait for this to come out, i already have the parts. Neat!

For anyone that has the esp8266 based hardware bridge and a mqtt broker setup the binding is now available as a BETA. I have spent 2 weeks putting it through stress tests on my own setup whilst writing some documentation found in post 2 of this thread.

Currently I am testing:
5 globes auto changing to different settings when Kodi is playing paused or stopped.
Google home mini controlling the lights via voice commands.

Next release of the binding will support these new things:
MQTT keep alive supported to ensure a better connection is made on bad networks. Feature already added and under going testing.
Auto re-connect if the MQTT broker can not be reached due to network issues. Feature already added and under going testing.
Changing to make 0% brightness to mean the globe is OFF as google assistant requires this change to be made. Working on this now and when complete I will test for a few days and then be happy to share.

An update on new features now supported to make using google assistant/home easier:

When the binding matches a hue of 36 AND a saturation of 32 the binding will automatically switch the globe to using the real white leds and does not use the RGB leds to fake white. Google assistant/home uses these values when you use voice command to set the colour to white. I allowed these values to be user configurable in case different ones are needed for Amazon Echo or any device in the future. Setting them to -1 disables the feature.

I also added a feature that allows the user to specify their favourite white which will be used by the above google assistant feature OR it can be assigned to be sent via a single button push.

I also wrote the code to allow multiple BRIDGES in case people want different settings on some globes, since all bridges go back to a single MQTT server you only need a single hardware hub if doing that.

I have around 23 Milight globes now spread across my house all with individual control using COLOR/HSB controls which google can now set colour, brightness and turn the globes on and off. Working great.

1 Like

did you have GU10 bulbs ? I have some of these bulbs but sometimes they don’t work. And wan you send me your binding for testing ?

Download the binding from here:
http://www.pcmus.com/openhab/
The zip files have a date code in the format DD-MM-YYYY for when the version was built. Always use the newest one as I will leave a few older ones in case they are needed.

No, i do not have any GU10 globes. They appear to use what the binding calls RGBW protocol so they should work. I have tested it with the following globe types:
RGB_CCT (edison and bayonet globes)
CCT (mini edison screw globes not the downlight ones)
RGBW (edison screw globes)

Version 03-03-2018 has the following changes:

  • FIFO buffers for incoming and outgoing MQTT messages in case the binding is used on slow hardware or your openhab server is kept busy with tasks.
  • MQTT message reduction, if you drag your finger over a colour wheel Openhab generates more data than the hub can handle and this feature reduces the traffic by throwing away multiple messages to the same globe and only sending the last command.
  • Slowing down multiple MQTT commands added by a configurable parameter. Sets how fast the binding processes the messages in the FIFO queue. Without this feature I could not turn all 23 globes on and off without issues with large RF packet repeat values, now it works (especially if I tweak the RF packet repeats to 70 found in the esp8266 control panel). RF packet repeats of 200 works better for globes a long way from the hub, whilst 70 is a lot faster. Interested to hear what others find.
  • Better broker session auto reconnects and session take overs now supported.

I changed a lot of things in this build so if you find an issue please enable debug logging on the binding and post the output as that greatly helps me fault find the issue if I know the last event the binding was doing before any errors.

matt1 this is amazing !
The other milight binding have so many workaround needed …

I’ll definitely give it a try as soon has I have some spare time and report back.

Thanks you for your work !

I have 12 GU10 bulbs, and with the Official Milight Gateway (the square one, not ibox), even if I send 5 time the order in the binding, I’ve got lot of issues.

But with the esp8266 based hardware bridge, I met the light xD, and it’s cheap and easy to setup !

I’m just looking for a 3D printed box schematic, but doesn’t found it at the moment.

@matt1 EDIT : Ok, can’t wait … everything is setup and seem to be running flawlessly. Google Home react like a charm with only Color item exposed, even with the white command, and the colors are correct, this is great !

Can’t manage to go back to white mode with the HABPAnel color picker, I must set up a separate Command button, this is not handy to find on the color wheel the exact value to go back to white mode :slight_smile: (The google value), but this is same as the other binding.

In my far dreams, I wonder if there are a trick to tell the binding to switch to night_mode at 1% dim and switch back at another dim level ? I was doing this with some rules, but my implementation was not very elegant …

Anyway, thanks you so much for this binding !

@MacFly, I’m using esp82266 (https://github.com/sidoh/esp8266_milight_hub) and it doesn’t works fine. I try different hardware without success. Can you send me your hardware specs and config if you use sidoh esp8266 ?
I’m waiting for official ibox to see if it’s better … but no MQTT :frowning:

oh ok @furax54 , so this is my hardware :


and I’m using the same software as you, this is my exported config : {"admin_username":"xxx","admin_password":"xxxx","ce_pin":16,"csn_pin":15,"reset_pin":0,"radio_interface_type":"nRF24","packet_repeats":50,"http_repeat_factor":1,"auto_restart_period":0,"mqtt_server":"192.168.0.100:1883","mqtt_username":"","mqtt_password":"","mqtt_topic_pattern":"milight/commands/:device_id/:device_type/:group_id","mqtt_update_topic_pattern":"","mqtt_state_topic_pattern":"milight/states/:device_id/:device_type/:group_id","discovery_port":48899,"listen_repeats":3,"state_flush_interval":10000,"mqtt_state_rate_limit":500,"packet_repeat_throttle_sensitivity":0,"packet_repeat_throttle_threshold":200,"packet_repeat_minimum":3,"device_ids":[24406],"gateway_configs":[[24406,8900,6]],"group_state_fields":["state","level","hue","saturation","mode","color_temp","bulb_mode","computed_color"]}

All my 12 GU10 spots are in my living room, and the bridge are not so far. I never do a range test. But I noticed a great improvement over the official bridge, no more glitch.

Good luck !

1 Like

I am having some trouble getting this up and running:

My ESPMilightHub thing is just sitting in the ‘UNINITILIZED’ state.

.things file:

Bridge espmilighthub:esp8266Bridge:001 [ADDR="tcp://localhost:1883", MQTT_USERNAME="espmilighthub"]
{
    Thing rgbw 0x684C1 "ch1"  	
    Thing rgbw 0x684C2 "ch2"
    Thing rgbw 0x684C4 "ch4"		
}

When I save the file I get the following in the logs:

04-Mar-2018 10:53:55.604 [DEBUG] [g.espmilighthub.handler.EspMilightHubBridgeHandler] - Initializing Bridge handler.
2018-03-04 10:53:55.605 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method 'ThingHandler.initialize()' on 'org.openhab.binding.espmilighthub.handler.EspMilightHubBridgeHandler@78dfcf98': null
java.lang.NullPointerException: null
	at org.openhab.binding.espmilighthub.handler.EspMilightHubBridgeHandler.connectMQTT(EspMilightHubBridgeHandler.java:329) [279:org.openhab.binding.espmilighthub:2.3.0.201803030925]
	at org.openhab.binding.espmilighthub.handler.EspMilightHubBridgeHandler.initialize(EspMilightHubBridgeHandler.java:419) [279:org.openhab.binding.espmilighthub:2.3.0.201803030925]
	at sun.reflect.GeneratedMethodAccessor105.invoke(Unknown Source) ~[?:?]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
	at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
	at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153) [109:org.eclipse.smarthome.core:0.10.0.b1]
	at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [109:org.eclipse.smarthome.core:0.10.0.b1]
	at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:?]
	at java.lang.Thread.run(Thread.java:748) [?:?]
2018-03-04 10:53:55.610 [ERROR] [ome.core.thing.internal.ThingManager] - Exception occurred while initializing handler of thing 'espmilighthub:esp8266Bridge:myhub': null
java.lang.NullPointerException: null
	at org.openhab.binding.espmilighthub.handler.EspMilightHubBridgeHandler.connectMQTT(EspMilightHubBridgeHandler.java:329) [279:org.openhab.binding.espmilighthub:2.3.0.201803030925]
	at org.openhab.binding.espmilighthub.handler.EspMilightHubBridgeHandler.initialize(EspMilightHubBridgeHandler.java:419) [279:org.openhab.binding.espmilighthub:2.3.0.201803030925]
	at sun.reflect.GeneratedMethodAccessor105.invoke(Unknown Source) ~[?:?]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
	at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
	at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153) [109:org.eclipse.smarthome.core:0.10.0.b1]
	at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [109:org.eclipse.smarthome.core:0.10.0.b1]
	at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:?]
	at java.lang.Thread.run(Thread.java:748) [?:?]

My MQTT servier is up and running fine. If I make a change to the ESP hub via the web interface I see entries in the MQTT server using MQTT.fx
Example:

{"state":"OFF","bulb_mode":"white","color":{"r":255,"g":255,"b":255}}

I don’t have a username or password configured on my MQTT server so I also tried with no MQTT_USERNAME specified in the .things file but that made no difference. I added it back because when I tried adding a bridge thing via PaperUI the username field was required. Creating the bridge via PaperUI resulted in the same issue, errors in the log and the bridge thing sitting in ‘UNINITILIZED’ state.

I also tried with the ip address of the MQTT server rather than localhost but that made no difference either.
I am using mosquitto and it is running on the same machine as openhab.
I am running OH 2.3 release build on Windows 10.

Any ideas what I messed up?
Thanks

Set a username and password in things file, both are required, a dummy one will work.

@MacFly Boom :boom: that was it! Thanks! :+1:
@matt1 Possible enhancement to avoid others having the same confusion - enable the MQTT_PASSWORD property to be omitted from the Bridge thing definition. The same probably also goes for the MQTT_USERNAME field.

Additional question just because I am curious - what Clinet ID is the binding using to connect to the MQTT server and can this be configured?
Additional, additional question - Since I already have the MQTT binding installed do I still need the paho MQTT client jar? If so, is it possible to make this an option in the binding config to use paho or the OH MQTT binding instead?
Ok, enough questions… I will get on with testing now… :slight_smile:

Thank you. I have approximatly same hardware. Today I made a wired esp8266 gateway. Seems to be better.

@matt1 First - THANK YOU! This binding is great! :smiley: Coupled with the ESP hardware bridge I am now planning on purchasing more milight hardware having previously given up on ever getting the stuff I have to work reliably.

Hardware compatibility info: I have a milight RGBW LED strip controller, your binding works great with it, just select the rgbw thing type.

I have two other bulbs both RGBW type and when using the ESP bridge directly via the web interface I am able to set the mode of these two bulbs and the LED strip controller directly using the combo box. This means that rather than having to cycle through each mode I can select a mode directly and the milight will immediately switch to it, no cycling or multiple commands required.

Enhancement request: Would you consider adding a number channel to the RGBW thing type to allow selection of the scene mode directly? If the milight is not in ‘bulb_mode’ ‘scene’ then the value of this channel could be set to UNDEF to avoid falsely suggesting there is any active mode.

On the subject of ‘bulb_mode’, I notice from watching the MQTT messages and playing with the ESP bridge web interface that the status of ‘bulb_mode’ breaks down as follows:

  • When a ‘mode’ is active - ‘scene’,
  • When the bulb is just steady white - ‘white’
  • When displaying a steady colour - ‘color’.

I think this is valuable information that would be useful to OH within rules. However exposing it as a settable channel doesn’t make much sense is it should not be set directly, only observed and reacted to - this brings me to my next…

Enhancement request: Using the Channel-based Triggers functionality in OH expose binding ‘events’ for the following:

  • On bulb_mode change - trigger event containing the new bulb_mode value
  • On level change - trigger event
  • On color change - trigger event
  • On ‘mode’ change - trigger event containing the new mode
  • On ‘state’ change - trigger event containing the new state

While this may seem like overkill, (and possibly it is for some of the properties), it would allow OH to distinguish between changes that were initiated by a command from OH and changes that were a result of an external controller (ESP hub web interface or milight controller hardware). I think this would really put the icing on the cake for milight control via this excellent binding.

Were you planning on opening this up on github for contributions? I have some experience adding trigger events to bindings but have been having trouble syncing my dev env with github to actually create a pull request… but that’s another story…

Thanks again

Edit: one other thing - This is likely so small it does not even qualify as a bug but thought I would mention it since I noticed it -
When running with debug logs on, I noticed this:

[DEBUG] [g.espmilighthub.handler.EspMilightHubBridgeHandler] - Could not find "color_temp": in the incomming MQTT message which was: {"state":"ON","level":32,"bulb_mode":"white","color":{"r":255,"g":255,"b":255}}

It is not causing any trouble and makes sense why it is missing from the payload since my rgbw type bulbs don’t support white colour temp. However since the ‘globetype’ is known to the binding it could avoid even looking for this property that will never exist by only looking for the color_temp property if the bulb type supports it.
Without seeing your code it’s hard to know if that is a big change or a small change or even a change worth making, but just wanted to mention it.

Cheers! :beers:

@furax54
The NRF2401 radios are very commonly counterfit / faked in China and have a large failure rate. If having troubles I would suspect that as the cause and order another one from a different supplier. The cheaper the board you order the higher the odds it is a fake. The picture/link Macfly gave has a built in PA+LNA and these are known to need more power than what the NodeMCU can deliever. You can order bases that allow you to inject extra power. Over the next few days I plan to test the 4 different NRF2401 boards that I sourced from different places and already I found some that were dead and clearly fake ICs.

@mcqwerty
Thanks for finding the bug, I’ll fix it in the next version which I will wait till I change enough things to warrant a newer build since it is easily worked around for now.
The client ID will be something like espmilighthub:001 and does not change as I use client take over features. No it is not configurable with no plans to do that. It will take on the name/uid of the bridge as eventually the binding will support multiple bridges, for now only setup 1 bridge as I have not tested multiples yet. The binding will also create a different clientID for the discovery Service but that should not get used unless you use paperUI and trigger a scan. In that case it uses a date and time hash to create a random clientID.
Re Paho, I have no idea, try it and see as I believe my code will work on most versions of Paho. No I will never support using my binding though another binding, if you want a stable reliable binding you stay away from doing things like that.

Part of this is already implemented, you will see a mode channel in paperUI. Just add controls for it by adding lines to your items and sitemap files. The hub actually allows you to set the mode directly so the channel can be used to set or display the mode. Your second half I can look at adding as a new feature so it displays white or colour modes when not in an active mode. Good idea.

Not sure I see the value in this. I am pretty sure you can already tell if the state change came from a milight remote or from an Openhab control movement.

In rules if you only want to know if it came from Openhabs controls use this type of rule:
Item received command []

If you only want remote control changes then use this
Item received update []

If you want both then use this.
Item changed [from ] [to ]

more detail here…
https://docs.openhab.org/configuration/rules-dsl.html#event-based-triggers

The problem is the hub ALWAYS sends a state change after it sees a command and if the state is off by a value of 1 which does happen at times then the wrong rule may trigger.
Have a play and see if this solves it for you.

I’ll take a look at your last logging suggestion, I may remove that for all globes as it was more for my testing purposes. Not a bug but I can probably do without it now.

Thanks for the feedback.