EspMilightHub new binding for milight limitlessLED and easybulb

Add-ons Bindings
, ,
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?

161

I did a little more research: when the EspMilightHub binding is started normally with openhab it begins with initialization of milight things and receiving all retained state messages. All messages are processed. After a short while I see a disconnect in the broker log:

1537258867: Received DISCONNECT from espMilightHub:001
1537258867: No will message specified.
1537258867: Sending CONNACK to espMilightHub:001 (1, 0)
1537258868: Received SUBSCRIBE from espMilightHub:001
1537258868: milight/states/# (QoS 1)
1537258868: espMilightHub:001 1 milight/states/#
1537258868: Sending SUBACK to espMilightHub:001
1537258868: Sending PUBLISH to espMilightHub:001 (d0, q0, r1, m0, ‘milight/states/0x7785/fut089/1’, … (62 bytes))
1537258868: Sending PUBLISH to espMilightHub:001 (d0, q0, r1, m0, ‘milight/states/0x7785/fut089/8’, … (34 bytes))

When I force to restart the mosquitto broker I can see the connections coming up but I don’t see a disconnect and the connection is vivid.

So for me it looks like a special case in the EspMilightHub binding.

162

Is the sonoff bridge compatible with the milight? What RF chip sits inside the bridge? It comes soldered and inside a nice case, and it can easily be flashed with custom software, so I was thinking maybe this device could be used as the miilight hub, instead of soldering some components together.

http://ewelink.coolkit.cc/?p=886

163

No
The rf in the sonoff is 433mhz.
Not compatible with the milights.
You will need to follow the bridge instructions.
It works very well
No need for soldering. Jumper wires are fine.

164

@joga
Yes the binding does connect, disconnect a moment later and then re-connect a second time, I forget why just right now. Possibly it was to do with fetching the retained messages only on startup and not if there was a minor network issue that caused a short drop out.

Maybe the issue is to do with your broker is still busy with the disconnect when the second connection request is made. How fast is the machine that is running the broker?

165

@matt1 it is a limited hardware, a RPi2. Usually it is more than sufficient but that issue might be due to the lack of performance. And you are right, the disconnect occurs after fetching the retained messages. Can you add a feature that assures the vivid connection to the broker? That would be the best solution in my view.

Thanks for your time.

166

I’m trying to get this to work, but I don’t understand something. You mention that the binding is standalone (“You do not need to have any mqtt bindings installed as this binding is fully standalone”) but also that “You then need to get MQTT running as this method uses the faster and lightweight MQTT protcol and not UDP.” Which of these is true? :wink:

Also, is there some URI with the jar file so I can conveniently wget it on my linux machine? Right now I need SCP into it and that’s difficult with all kinds of permission issues. Still can’t get it to work…

Also when does this binding become an official one?