EspMilightHub new binding for milight limitlessLED and easybulb

matt1 · January 27, 2019, 1:17pm

New build 28-01-2019 new changes are:

2.5 snapshot version, be careful to not have more than 1 JAR of this binding in the addons folder. Any issues clear your tmp and cache folders.
New feature, the binding now detects remote group 0 states and replicates them so the controls in Openhab will update and reflect any changes made with a remote on group 0. Note you need the 1.9 dev firmwares and newer for this to work and if you notice an issue please work out if it is a bug in the binding or the firmware and report it to the correct person/github project. You can fault find it by watching the MQTT messages with the command in post 2 of this thread and also the readme file.

@butteryak
After updating my firmware my remote does the same thing on colour temp. I reported it to the github project.

matt1 · January 28, 2019, 11:12pm

Yes use localhost, if for example your network card crashes the local traffic will stop if you use the IP of the network card, using localhost uses a virtual loopback device and is the way to go.

mcqwerty · January 29, 2019, 2:45am

Hi @matt1 I have been using your binding since the early days and loving it but recently I ran into an issue:
I updated to OH v2.4 release build and decided to use the new built in MQTT server and uninstall Mosquitto.
There are no issues other than on a restart of OH your binidng is unable to connect to the MQTT sever as reported in the logs:

28-Jan-2019 07:58:24.687 [DEBUG] [g.espmilighthub.handler.EspMilightHubBridgeHandler] - Initializing Bridge handler.
28-Jan-2019 07:58:26.744 [ERROR] [g.espmilighthub.handler.EspMilightHubBridgeHandler] - Error: Could not connect to MQTT broker.{}
org.eclipse.paho.client.mqttv3.MqttException: Unable to connect to server
	at org.eclipse.paho.client.mqttv3.internal.TCPNetworkModule.start(TCPNetworkModule.java:94) ~[?:?]
...

If I do a bundle:restart then it connects fine:

28-Jan-2019 20:32:28.991 [DEBUG] [g.espmilighthub.handler.EspMilightHubBridgeHandler] - Initializing Bridge handler.
28-Jan-2019 20:32:29.010 [INFO ] [g.espmilighthub.handler.EspMilightHubBridgeHandler] - MQTT sucessfully connected

I strongly suspect this is an issue with the way the core OH framework starts up the bindings such that your binding is started before the built in MQTT server is fully initialised. But I imagine it would be possible to work round this in your binding?
Maybe add a setting to to delay the attempt to connect to the specified MQTT broker by a given time or probably better, add auto retries to connect if the first connection fails on binding start.

Would you be open to adding somethign like this to your binding?
Thanks

matt1 · January 29, 2019, 4:23am

Yes this is the better way and it is how I do it with my IP camera binding. I can copy the code over and have this done in probably 15 minutes of spare time. I took a very quick look at the code and yes it does appear that it will not try again if the first attempt fails, if it connects the first time it will then auto re connect if a network issue occurs…

If I get some spare time tonight I’ll take a look as I can’t believe I missed this How often should it check, is once every 30 seconds often enough?

@mcqwerty
EDIT: Build 29-01-2019 now available with these changes:

First Connection fix, will now check every 30 seconds.
RGBW_WHITEMODE_SAT_THRESHOLD now defaults to 12 by default.
DELAY_BETWEEN_MQTT defaults to 140 (was 250) to match the default setting of the esp firmware.
Updated the readme to give more details on setting the delays of the binding so people can optimise the speed.

If you upgrade be sure to clean the cache and tmp folders and restart, I had a re-occuring error until I did that on my setup and have not seen it since.

mcqwerty · January 30, 2019, 2:54am

Thanks! Installed the new version and it reconnected automatically on restart. Took 2 minutes on my system from the first attempt to a successful connection so I think a 30s poll time works well.

ingop · February 14, 2019, 8:57pm

Hi. Great project, did me took only 2 hours to build the hardware together, install the firmware and connect to my mosquitto on openhabian.
I can see mqtt entries when using my milight fut089 remote. Also I have used your examples to add an entry in my sitemap.
Only one thing is not working: when sending something from the sitemap i see the mqtt event but 1 char in the id is missing (0x5961 vs 0x596).
entry from remote (working): milight/states/0x5961/fut089/1 {“state”:“ON”,“bulb_mode”:“white”}
entry from sitemap (not working): milight/states/0x596/fut089/1 {“state”:“OFF”,“level”:48,“color_temp”:270,“bulb_mode”:“white”}

Isn’t that strange???

Here my .things:

Bridge espmilighthub:esp8266Bridge:001 [ADDR="tcp://192.168.1.75:1883", 
MQTT_USERNAME="openhabian", MQTT_PASSWORD="xxx"]
{
	Thing fut089 0x5961 "Wohnwagen"  	//comments are possible after double /	
}

Here my .items:

/* Light */
Switch Milight_ID0xEC59_G1_State     "Light On/Off"         {channel="espmilighthub:fut089:001:0x5961:level"}
Dimmer Milight_ID0xEC59_G1_Level     "Front Hall"           {channel="espmilighthub:fut089:001:0x5961:level"}
Dimmer Milight_ID0xEC59_G1_CTemp     "White Color Temp"     {channel="espmilighthub:fut089:001:0x5961:colourtemperature"}
Color  Milight_ID0xEC59_G1_Hue    "Front Hall" ["Lighting"] {channel="espmilighthub:fut089:001:0x5961:colour"}
String Milight_ID0xEC59_G1_Cmd 	    "Command to Send"       {channel="espmilighthub:fut089:001:0x5961:bulbcommand"}
Switch Milight_ID0xEC59_G1_SndCmd    "Send Command" 	    {channel="espmilighthub:fut089:001:0x5961:sendbulbcommand"}

Here my .sitemap part:

Frame label="Licht" {
Text label="EntryHallway" icon="light" 
{
	Switch 		item=Milight_ID0xEC59_G1_State
	Slider 		item=Milight_ID0xEC59_G1_Level
	Slider 		item=Milight_ID0xEC59_G1_CTemp
	Colorpicker	item=Milight_ID0xEC59_G1_Hue
	Selection	item=Milight_ID0xEC59_G1_Cmd mappings=[next_mode='next_mode', previous_mode='previous_mode', mode_speed_up='mode_speed_up', mode_speed_down='mode_speed_down', set_white='set_white', pair='pair',unpair='unpair',level_down='level_down',level_up='level_up',temperature_down='temperature_down',temperature_up='temperature_up',night_mode='night_mode',favourite_white='favourite_white']
	Switch 		item=Milight_ID0xEC59_G1_SndCmd mappings=[ON="Send"]
}
}

Thanks a lot for that great project and your help.
Ingo

matt1 · February 14, 2019, 11:12pm

Try changing the channels from this

{channel="espmilighthub:fut089:001:0x5961:level"}

to this…

{channel="espmilighthub:fut089:001:0x59611:level"}

Note the extra number I added.

This is from the readme…

Key concept to understand for you to succeed

To get this working you need to know that the Milight globes are 1 way and do NOT have any kind of ID code. Only the remotes have a non editable code in them and when you LINK the globe to a remote, the globe learns this code which is referred as the remotes “Device ID”. The remote has a “Group ID” of 1 to 4 if the remote supports 4 groups (some remotes support more than 4). The binding requires you to place these two numbers together to create the things unique ID. By looking at the manual configuration example below this may make it clearer for you. The DeviceID can be in hex or decimal format but it must end with the number that is the GroupID (usually 0 for all in a group or 1 to 9 can be used). If you do not understand this key concept please post a question.

The formula is
ThingUID = DeviceID+GroupID

examples:

HEX
0xb4c1 = DeviceID is 0xb4c and GroupID is 1

Decimal (I don’t recommend using decimal as it confuses too many people)
21 = DeviceID is 2 and GroupID is 1

matt1 · February 16, 2019, 8:54am

New build 2019-02-16 has these changes:

Fully re-worked the connection routine. Binding now only makes the connection to the broker once instead of twice for older builds and the way the retained messages are requested from the broker have changed. This fixed an issue for me where the connection failed to work correctly due to my RTC changing the system time and causing a MQTT reconnect right in the middle of connecting. When you reboot your server you should see all the saved states load into Openhab so you do not need to setup persistence as the broker handles this task for you.
Built using the latest changes away from ESH.

X-Ray181 · February 16, 2019, 12:19pm

Hallo @matt1
Love this binding, keep up the good work!
Where can I download the new version?

matt1 · February 16, 2019, 12:46pm

Thank you for your kind words. Where to download and how to setup the binding are found in the first two posts of this thread, I edit those posts so they are always up to date and also far easier to find then reading hundreds of posts looking for the latest info…

rastus_rob · February 18, 2019, 4:50pm

Hi there, thanks for all the work on this project.

I’m having a problem with the mqtt side of things.

In the instructions is says to format the MQTT Topic in this order:
milight/commands/:device_id/:device_type/:group_id

Yet in the items file the order seems to be:
epsmilighthub/:device_type/:device_id/:group_id/command

If I format it like this (:device_type/:device_id) it doesn’t record the :device_id, it either comes up as blank or as 0x0 but kind of works and the mqtt messages are showing up in mosquitto_sub but with no :device_id of course.

If I format it in the same order as the MQTT Topic (:device_id/:device_type) , then the :device_id is parsed (according to the logs), but it doesn’t show up in mosquitto_sub.

Which is the best items file order for these to work correctly please?

EDIT: see next post for more info.

rastus_rob · February 19, 2019, 8:37am

Hi there,
I have a problem with my :device_id not populating. I’ve tried using hex and decimal numbers, same result.

Logfile (set to trace on espmilighthub):

2019-02-19 01:22:08.777 [DEBUG] [b.handler.EspMilightHubBridgeHandler] - Processing new incoming MQTT message to update Openhab's controls.
2019-02-19 01:22:08.778 [DEBUG] [b.handler.EspMilightHubBridgeHandler] - Message        ={"state":"ON","level":100}
2019-02-19 01:22:08.778 [DEBUG] [b.handler.EspMilightHubBridgeHandler] - globeType      =rgbw
2019-02-19 01:22:08.778 [DEBUG] [b.handler.EspMilightHubBridgeHandler] - remoteCode     =0x0
2019-02-19 01:22:08.778 [DEBUG] [b.handler.EspMilightHubBridgeHandler] - remoteGroupID  =1
2019-02-19 01:22:08.778 [DEBUG] [b.handler.EspMilightHubBridgeHandler] - Chan Prefix    =espmilighthub:rgbw:4666:0x01:
2019-02-19 01:22:08.778 [DEBUG] [b.handler.EspMilightHubBridgeHandler] - bulbState      =ON
2019-02-19 01:22:08.778 [DEBUG] [b.handler.EspMilightHubBridgeHandler] - bulbLevel      =100
2019-02-19 01:22:08.778 [DEBUG] [b.handler.EspMilightHubBridgeHandler] - iBulbLevel     =100
2019-02-19 01:22:09.520 [DEBUG] [b.handler.EspMilightHubBridgeHandler] - started timer because it was null.
2019-02-19 01:22:09.525 [DEBUG] [b.handler.EspMilightHubBridgeHandler] - MQTT message just sent, there are now 0 more messages in the queue
2019-02-19 01:22:09.666 [DEBUG] [b.handler.EspMilightHubBridgeHandler] - MQTT sending queue is getting cancelled
2019-02-19 01:22:09.669 [DEBUG] [b.handler.EspMilightHubBridgeHandler] - * Recieved the following new Milight state:milight/states/0x0/rgbw/1 : {"state":"OFF","level":100}

mosquitto_sub output:

milight/commands//rgbw/1 {"state":"OFF"}
milight/states/0x0/rgbw/1 {"state":"OFF","level":100}
milight/commands//rgbw/1 {"state":"ON","level":100}
milight/states/0x0/rgbw/1 {"state":"ON","level":100}
milight/commands//rgbw/1 {"state":"OFF"}
milight/states/0x0/rgbw/1 {"state":"OFF","level":100}

things file:

Bridge espmilighthub:esp8266Bridge:4666 [ADDR="tcp://192.168.0.10:1883"]
{
    Thing rgbw 0 "All Lights" @ "RaSTuS' Home"
    Thing rgbw 1 "Lamp" @ "Bedroom"
    Thing rgbw 2 "Bedroom Light" @ "Bedroom"
    Thing rgbw 3 "Lounge Light" @ "Lounge"
    Thing rgbw 4 "Bathroom Light" @ "Bathroom"
}

items file:

Switch Bedroom_LightSw  "Bedroom Light - On/Off"        (Bedroom, Lights)       ["Lighting"]  channel="espmilighthub:rgbw:4666:1:level"}

But if I reorder the item so that it’s “epsmilighthub:4666:rgbw:1:level” then the :device_id populates but nothing works.

items file:

Switch Bedroom_LightSw  "Bedroom Light - On/Off"        (Bedroom, Lights)       ["Lighting"]    {channel="espmilighthub:4666:rgbw:1:level"}

Logfile (set to trace on espmilighthub):

2019-02-19 16:50:19.238 [DEBUG] [b.handler.EspMilightHubBridgeHandler] - Processing new incoming MQTT message to update Openhab's controls.
2019-02-19 16:50:19.238 [DEBUG] [b.handler.EspMilightHubBridgeHandler] - Message        ={"state":"OFF","level":100,"bulb_mode":"white"}
2019-02-19 16:50:19.238 [DEBUG] [b.handler.EspMilightHubBridgeHandler] - globeType      =rgbw
2019-02-19 16:50:19.238 [DEBUG] [b.handler.EspMilightHubBridgeHandler] - remoteCode     =0x123A
2019-02-19 16:50:19.239 [DEBUG] [b.handler.EspMilightHubBridgeHandler] - remoteGroupID  =1
2019-02-19 16:50:19.239 [DEBUG] [b.handler.EspMilightHubBridgeHandler] - Chan Prefix    =espmilighthub:rgbw:4666:0x123A1:
2019-02-19 16:50:19.239 [DEBUG] [b.handler.EspMilightHubBridgeHandler] - bulbState      =OFF
2019-02-19 16:50:19.239 [DEBUG] [b.handler.EspMilightHubBridgeHandler] - bulbLevel      =100
2019-02-19 18:22:00.413 [DEBUG] [b.handler.EspMilightHubBridgeHandler] - started timer because it was null.
2019-02-19 18:22:00.416 [DEBUG] [b.handler.EspMilightHubBridgeHandler] - MQTT message just sent, there are now 0 more messages in the queue
2019-02-19 18:22:00.557 [DEBUG] [b.handler.EspMilightHubBridgeHandler] - MQTT sending queue is getting cancelled
2019-02-19 18:22:00.790 [DEBUG] [b.handler.EspMilightHubBridgeHandler] - * Recieved the following new Milight state:milight/states/0x0/rgbw/3 : {"state":"ON","level":100}

mosquitto_sub output:

milight/states/0x123A/rgbw/1 {"state":"ON","level":100,"bulb_mode":"white"}
milight/states/0x123A/rgbw/1 {"state":"OFF","level":100,"bulb_mode":"white"}

Which is the best items file order for these to work correctly please?

matt1 · February 19, 2019, 9:21am

Your first item file example was missing an opening curly brace, try this as the colour channel is best for tagging as google home or Alexa can control the light best with this channel…

things

Bridge espmilighthub:esp8266Bridge:4666 [ADDR="tcp://192.168.0.10:1883"]
{
    Thing rgbw 0x123A0 "All Lights" @ "RaSTuS' Home"
    Thing rgbw 0x123A1 "Lamp" @ "Bedroom"
    Thing rgbw 0x123A2 "Bedroom Light" @ "Bedroom"
    Thing rgbw 0x123A3 "Lounge Light" @ "Lounge"
    Thing rgbw 0x123A4 "Bathroom Light" @ "Bathroom"
}

items

Switch Bedroom_Light "Bedroom"        (Bedroom, Lights)       ["Lighting"]    {channel="espmilighthub:rgbw:4666:0x123A2:colour"}

rastus_rob · February 19, 2019, 9:57am

Thanks muchly, works great now I added the device_id to the group_id in the things and items file.

Don’t know what happened to the missing curly braces, must have bumped a key when copy/pasting or something. They are there.

Thanks again.

matt1 · February 23, 2019, 9:02am

New Build 2019-02-23 has these changes:

Bug fixes for the new way of connecting. MQTT was failing to connect if you edited a setting in PaperUI or items files after the system has started, now fixed.
Bug fix for the Halogen emulation feature.
Logging changes. DEBUG gives single line cut down information and TRACE will give more detailed output.

@rastus_rob
It is possible the above bug was causing issues for you, please upgrade to this newer build.

rastus_rob · February 23, 2019, 5:50pm

Thanks Matt, will do.

furax54 · February 24, 2019, 5:29pm

Hello,
@matt1 : I thing there is a little bug but I don’t know if it’s really a bug. When I tell my GoogleHome to turn ON the light, it send ON to the color channel (via item) and then I can see the Color item changed to X,Y,100. But the level channel (and the associated item) stay to 0. The same apply when you want to turn off. I know I can add a rule but perhaps you could add it into the binding. Thank you.

matt1 · February 24, 2019, 11:20pm

I did a test today with GHM and mine is working great. The incoming MQTT messages on the status topic are what make the controls move, so if your hub is setup wrong or is using older firmware with an issue it will not update.

Can you do the following and retest?

Upgrade firmware of hub to the latest dev7 which is what I am using.
Upgrade the binding to the latest version and clear out the cache and tmp folders.
Watch the MQTT messages and see what they return as the status.
Post what settings you have in the bindings setup, I doubt that will be the cause but I need to run a test here with the same settings to try and reproduce.

furax54 · February 25, 2019, 11:29am

Thank you for you help @matt1.
After writing a long post, I delete all becasue I finally find why it doesn’t work
In my items and things files, I use for example ID b58d but I have to use B58D (capital for letters).

furax54 · February 25, 2019, 5:40pm

Hmmm. It’s not bijective ! When you send OFF to level channel the last argument of color channel stay to 100 (ie X,Y,100) and not X,Y,0.