EspMilightHub new binding for milight limitlessLED and easybulb

Add-ons Bindings
, ,
141

@matt1
Last version under test, will report any issues
Thanks!

142

Hello everybody,

Could you please tell what is milight, is it protocol or company ?

I saw in internet there are few websites with milight name such as (https://milight.pro, http://www.milight.com, http://www.mi-light.com)

Which one is the original, and what is limitlessLED ?

143

https://wikidevi.com/wiki/MiLight

144

Hi, all. I am just rewriting rules from OH2 Milight Binding into this tuned ESPMilight Binding. I am wondering, can someone share rules definition/example, how to work with

bulbcommand and sendbulbcommand chanels to send command to buld over rule?
Also how to send exact color to bulb 


Thanks a lot.

145

To send exact colours with a rule use lines like this which takes variables for hue sat and level and sends it to the Color channel.

Using variables

MiLight_colour.sendCommand(sHUE+","+sSATURATION+","+sLEVEL)

Not using variables

MiLight_colour.sendCommand(5,10,10)

The commands are a little harder and it may be time to rethink how they work. What command did you want to send?

146

What i understand you send one of these commands over bulbcommand channel and than have to “execuded” it with channel sendbulbcommand by sending only command ON always using “sendCommand()”.

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'

Ex.: change to white

MiLight_bulbcommand.sendCommand('set_white')
MiLight_sendbulbcommand.sendCommand(ON)

If i want associate button press with reduce brightness down, I just use this in button rule?

MiLight_bulbcommand.sendCommand('level_down')
MiLight_sendbulbcommand.sendCommand(ON)

I was wondering, why there is the sendbulbcommand channel? When you send somethig over bulbcommand its clear, that you want execute that 
:slight_smile:

Also Queston: How do you manage in rules to turn lights slowly off or on (slowly dim from 100% to 0% or 0% to 100%)?
With loop and change dimmer from 100% to 0% in steps?
Or repeating command level_down also in loop “fewtimes”?

 to make it look smooth without “sharp changes”.

To change colors like this? SendCommand or postUpdate?

MiLight_colour.sendCommand("5,10,10")

Thanks a lot

147

I have not tested the commands from rules before so I am guessing how they will respond based on the code I wrote, the commands were tested in a sitemap with basic controls.

Bulbcommand if selected to a new command will send right away, but at least in the ui you can not select a command that is already selected a second time. This caused a problem when you wanted to send multiples of the same command like dim down. Some older globes can not jump direct to a brightness level and needed multiple commands sent, this is what the sendbulb command was for. It makes sense when you use it via the UI panels, but I do not like the fact it is not consistent for using in rules. I am happy to change this I just need some time to think how best to proceed. One way would be to add the option to not auto send the command and wait for the sendbulbcommand to trigger it to be sent.

BTW if you want night mode the binding has the ability to place that as 1% making it very easy to trigger.

If you are wanting this for smooth level changes I doubt that can be done with only 100 discrete levels of light. For the commands I think it is even less resolution. Does the milight binding do it? If so how?

148

OK, I will play with rules and let you know.

WIth 1TRIGGERS_NIGHT_MODE=true in Bridge definition, right? Yes thats cool!

With original Mililght Binding i did it with loop and increase or desce dimmer by steps (5-10) with 400ms delay in between. But not always go smooth, as opehab delay sending sometimes or bulbs not get some commands - basically it was too fast for the path to each bulb. And the main problem was, bulbs always remember last dimmer state and i was not able change it. So turning on always start with 100%flash. The rule is in this post.

149

Yes it would be very difficult to get it to be smooth due to many factors. I have done my own hardware design for my own light dimmers for my non milight lights in the house and you need 1024 “steps” / levels of light for a fade to be seen as smooth minimum. I can specify the target look and the time to morph into the new look and my hardware handles it smoothly with no rules needed


The only way with milight is to bend your fade to use any smoothing that is done at a globe firmware level, which as you are finding it is critical on timing being consistant. The new hub does allow raw RF packets to be sent and that may be worth looking at to remove some sources of variable timing but that would make things harder to setup


First up I would recommend you look at 2 things before playing with rules and timing.

  1. RF repeats in the esp8266 control panel. This slows down how fast the next command can be sent if you have high or changing number of repeats. By default the hub is setup to ‘throttle’ the repeats which will create a different delay (and unpredictable) so that will need to be stopped and the lower the repeat value the better.

  2. The binding has a delay between MQTT setting. Older firmwares would freeze if too much data was sent to the hub before it could process older commands. Buffer overflow. This was the fix implemented and it is possible it is no longer needed, however with the IOS app if you drag your finger around the colour wheel/chooser it really floods the MQTT messages and fills buffers up. Take this delay into your calcs or reduce it down to improve the response.

150

If I like to use ESP Milight bridge with diyHue which use REST API to talk to ESP Milight bridge, is there any way to speed up bulbs reactions - tune up radio/FR settings or better use more bridges? 

What you said, does it apply only when “commands” come over MQTT or any input like REST API/UDP

151

Point one will apply even if you use udp and the esp bridge. Rf repeats by default are not a consistent number as the more commands waiting to be sent it throttles back the repeats creating a differing delay.

152

I have a problem with the binding/configuration: I set up an ESPmilighthub. It is connected to mosquitto and is working well. I can sent messages and can control bulbs. I than set up the binding as documented, hopefully, and can control bulbs from openhab. But if I use the remote control, a fut089 device, I can control the bulbs but I don’t see it in openhab. Items are not changed. I have linked items:

Dimmer Milight_ID0x7785_G1_Level	"Helligkeit"			{channel="espmilighthub:fut089:001:0x77851:level"}
Dimmer Milight_ID0x7785_G1_CTemp	"Farbtemperatur"		{channel="espmilighthub:fut089:001:0x77851:colourtemperature"}
Color  Milight_ID0x7785_G1_Hue		"Kranz Farbe"			{channel="espmilighthub:fut089:001:0x77851:colour"}
String Milight_ID0x7785_G1_Cmd		"Modus"				    {channel="espmilighthub:fut089:001:0x77851:bulbcommand"}
Switch Milight_ID0x7785_G1_SndCmd	"setze Modus"			{channel="espmilighthub:fut089:001:0x77851:sendbulbcommand"}

and I receive messages:

11:03:54.020 [DEBUG] [ub.handler.EspMilightHubBridgeHandler] - * Recieved the following new Milight state:milight/states/0x7785/fut089/1 : {"state":"ON","level":33,"mode":0,"bulb_mode":"scene"}

but unfortunately I don’t see items changing.
Want I’m doing wrong?

Thanks.

153

@joga
So to summarize, you can control the globe by moving openhab controls it is only getting the remote to move the controls in openhab that does not work for you? If that is not correct please post a correction


This one is interesting as you clearly have MQTT connection working and the binding is seeing the state coming in. What happens if you change to white mode instead of a SCENE? Are there anymore lines in the log following the one you posted?

If moving a control in openhab does not work then it would make more sense and I would then suspect a setup issue and want to see your item, sitemap and thing files.

With openhab when weird things happen the first thing you should try is deleting the tmp and cache files and rebooting, have you tried that yet?

154

You understand completely correct. I can control the globes from openhab controls. All modes and all values. I see all mqtt statements. If I publish the commands manually it also works as expected. If I use the remote control the globes are controlled and I see the mqtt statements too. But openhab controls don’t move. If I use mqtt binding the openhab controls are moved.
Thanks for investigation.

But I will try your last hint and report.

155

I wiped tmp and cache after stopping oh and than restarted. Unfortunately same result. No feedback from remote control to oh controls. Maybe I change items to mqtt binding. There it works.

156

@joga
I just ran a test and used PaperUI to auto add the globe, at first it would not work, then after moving all the controls in openhab manually it then started to work and I can not reproduce it not working anymore. Have no idea why and now I can not reproduce it to work out the cause. What I need is the log output when it does not work showing where it stops to know where to look for a bug. This is an example of it working and I used the same remote and even remote code and group ID to try and reproduce this

I never use the remotes myself so it would be easy for a bug to slip by un-noticed as I pretty much use google home or the android app for all control and lots of rules to auto change the lights based on events.

2018-09-16 11:29:59.268 [DEBUG] [e.h.EspMilightHubBridgeHandler:284  ] - * Recieved the following new Milight state:milight/states/0x778/fut089/1 : {"state":"ON","level":100,"hue":256,"saturation":63,"bulb_mode":"color"}
2018-09-16 11:29:59.280 [DEBUG] [e.h.EspMilightHubBridgeHandler:145  ] - Processing new incoming MQTT message to update Openhab's controls.
2018-09-16 11:29:59.280 [DEBUG] [e.h.EspMilightHubBridgeHandler:146  ] - Message	={"state":"ON","level":100,"hue":256,"saturation":63,"bulb_mode":"color"}
2018-09-16 11:29:59.280 [DEBUG] [e.h.EspMilightHubBridgeHandler:147  ] - globeType	=fut089
2018-09-16 11:29:59.280 [DEBUG] [e.h.EspMilightHubBridgeHandler:148  ] - remoteCode	=0x778
2018-09-16 11:29:59.280 [DEBUG] [e.h.EspMilightHubBridgeHandler:149  ] - remoteGroupID	=1
2018-09-16 11:29:59.280 [DEBUG] [e.h.EspMilightHubBridgeHandler:150  ] - Chan Prefix	=espmilighthub:fut089:Auto001:0x7781:
2018-09-16 11:29:59.280 [DEBUG] [e.h.EspMilightHubBridgeHandler:151  ] - bulbState	=ON
2018-09-16 11:29:59.280 [DEBUG] [e.h.EspMilightHubBridgeHandler:152  ] - bulbLevel	=100
2018-09-16 11:29:59.280 [DEBUG] [e.h.EspMilightHubBridgeHandler:163  ] - iBulbLevel	=100
2018-09-16 11:29:59.281 [INFO ] [smarthome.event.ItemStateEvent:53   ] - espmilighthub_fut089_Auto001_0x7781_level updated to 100
2018-09-16 11:29:59.282 [INFO ] [smarthome.event.ItemStateEvent:53   ] - espmilighthub_fut089_Auto001_0x7781_bulbmode updated to color
2018-09-16 11:29:59.283 [INFO ] [smarthome.event.ItemStateEvent:53   ] - espmilighthub_fut089_Auto001_0x7781_discomode updated to -1
2018-09-16 11:29:59.284 [INFO ] [arthome.event.ItemCommandEvent:53   ] - Item 'espmilighthub_fut089_Auto001_0x7781_bulbmode' received command color
2018-09-16 11:29:59.284 [INFO ] [smarthome.event.ItemStateEvent:53   ] - espmilighthub_fut089_Auto001_0x7781_colour updated to 256,63,100
2018-09-16 11:29:59.284 [INFO ] [s.event.ItemStateChangedEvent :53   ] - espmilighthub_fut089_Auto001_0x7781_level changed from 41 to 100
2018-09-16 11:29:59.285 [INFO ] [smarthome.event.ItemStateEvent:53   ] - espmilighthub_fut089_Auto001_0x7781_bulbmode updated to color
2018-09-16 11:29:59.285 [DEBUG] [.s.c.t.i.p.ProfileCallbackImpl:101  ] - Delegating update 'color' for item 'espmilighthub_fut089_Auto001_0x7781_bulbmode' to handler for channel 'espmilighthub:fut089:Auto001:0x7781:bulbmode'
157

Would you mind to show your item definition? But I wonder to only see a message like the first in your log. But than nothing follows. I only see more than one line when the binding is started and all retained messages are processed.

158

There is none on my test setup, I used paperUI to find and add everything then used the CONTROL tab of paperUI to test with. Perhaps give that method a go if you think it is an issue with your item setup.

159

It must have something to with the mqtt subscription. At the moment I can see the messages on the mosquitto server by subscription of milight/# with mqtt.fx but I don’t see the incoming messages in the binding. I still see the messages when I move the oh controls. Really weird.

160

I think I found the problem although I don’t see a solution yet. Because I use some wifi-switches I also enabled standard MQTT binding. There seems to be an interference between those two bindings. When standard mqtt starts first this milight binding doesn’t get notified when new messages arrive. Other mqtt messages are dispatched correctly. So only standard mqtt binding is working well.
When esbmilighthub binding starts first this binding receives all new messages and all other mqtt messages are also dispatched to the right items. So it lookes like both bindings are working well.

In both cases I can see mqtt broker messages are being published. So I don’t think it is a broker problem.

So for me it is hard to decide where the problem can be found.

Any ideas?