Check again it should be there now, seems I hit the OK button before it had time to fully upload.
Hi Matt,
thanks for uploading. One question: I am replacing my original milight hub by the ESP based hub. When I use an Switch to turn on and off a rgbw bulb then it doesnât seem to remember its brightness settings. When switch the bulb âONâ then it always set the brightness to 100%. My item uses the following channel for the On/Off command:
channel=âespmilighthub:rgbw:001:0xB78E1:levelâ
I assume there must be a way to remember the brightness setting because it also works with the original remotes/hubs.
thanks,
Peter
Check what MQTT messages are sent and work out if it is a binding issue, or a ESP firmware issue. I donât have RGBW globes but I did borrow one from a mate when I was doing the testing and it all worked fine. Test using the ESP webpage controls and see if it does the same and look at the MQTT messages to work out where the issue lies.
When I turn a bulb on via openHAB I see the following two packets in the ESP sniffing tool:
rgbw packet received (7 bytes):
Request type : B0
Device ID : B78E
b1 : 00
b2 : BA
b3 : 0E
Sequence Num. : 0F
rgbw packet received (7 bytes):
Request type : B0
Device ID : B78E
b1 : 00
b2 : 02
b3 : 05
Sequence Num. : 0E
When I use the ESP tool to switch on the same bulb I see this:
rgbw packet received (7 bytes):
Request type : B0
Device ID : B78E
b1 : 00
b2 : 02
b3 : 05
Sequence Num. : 13
The mqtt command received from openHAB is {âstateâ:âONâ,âlevelâ:100}. So it looks like my switch is sending a brightness level of 100 and an ON command.
You really should be watching the MQTT messages not just the RF packets. The readme has the linux command to watch the traffic with.
You are correct the binding will or âshouldâ send {âstateâ:âONâ,âlevelâ:50} if you do thisâŠ
- Set the level to 50% brightness with openHAB.
- Turn off the light with openHAB.
- Turn on the light with openHAB.
The same should happen if you:
- Turn off the light at any brightness other than 50.
- Send the 50 command and the light should turn on directly to 50.
The binding saves internally the level everytime it is changed so you need to work out if the MQTT is sending the wrong state to the binding at any point in time that may cause the wrong value to get saved.
I cannot test this as I donât have any rgbw globes, but if you give me steps to reproduce it and what to look for it is not hard to fake it as the hub does not talk 2 ways with a globe. I use rgb-cct and also some dual white globes cct here.
It looks like I am having an issue with the state saving. First of all, I am running openHAB on a Windows machine, running Windows 10 with Zulu Java 8. For MQTT I have a mosquito running on the same machine. For this trial I used an RGB_CCT GU10 light. When I turn it on, it turns on at 100% brightness.
I use MQTT.fx to capture the traffic.
{âstateâ:âONâ,âlevelâ:100}
Next I change the brightness
{âstateâ:âONâ,âlevelâ:39}
Switch off again
{âstateâ:âOFFâ,âlevelâ:0}
Switch on again
{âstateâ:âONâ,âlevelâ:39}
So now it behaves exactly as it should 
Just before I logged all this I did exactly the same but then the brighnessâ state wasnât retained. I captured this part from the openhab logging where you can clearly see what happened:
Item âLivingroom_Light3â received command ON
Livingroom_Light3 predicted to become ON
Livingroom_Light3 changed from OFF to ON
Livingroom_Light3_Brightness changed from 0 to 100
Livingroom_Light3_Color changed from 0,0,0 to 0,0,100
Item âLivingroom_Light3_Brightnessâ received command 35.0
Livingroom_Light3_Brightness predicted to become 35.0
Livingroom_Light3_Brightness changed from 100 to 35.0
Livingroom_Light3_Color changed from 0,0,100 to 0,0,35
Item âLivingroom_Light3â received command OFF
Livingroom_Light3 predicted to become OFF
Livingroom_Light3 changed from ON to OFF
Livingroom_Light3_Brightness changed from 35 to 0
Livingroom_Light3_Color changed from 0,0,35 to 0,0,0
Item âLivingroom_Light3â received command ON
Livingroom_Light3 predicted to become ON
Livingroom_Light3 changed from OFF to ON
Livingroom_Light3_Brightness changed from 0 to 100
Livingroom_Light3_Color changed from 0,0,0 to 0,0,100
So it looks like it is working, but not always. I donât have the MQTT messages belonging to this openhab log, but yesterday I saw that the MQTT messages matched the log. Is there something I can do to get more debug info? Please note that I am not a programmerâŠ
See here:
It is important to work out if it is the firmware reporting back the wrong state that the binding then saves, or if the binding glitches. If you have installed multiple versions of the binding, it would be a good idea to clean the cache as that could explain it.
Currently I am not facing an issue, but I did find something in the log related to the binding when I had an issue. Maybe it is related?
I attached the log file.openhab.log (2.3 KB)
Peter, I can only confirm bind behaviour is correct, mine remember exactly last brghtness level. Here my items definitions (Bulbs are GU10 RGB_CCT):
// Spot
Switch Spot_Stato "Spot On/Off" (GMansarda) {channel="espmilighthub:rgb_cct:001:0x12341:level"}
Dimmer Spot_Cursore "Spot Dimmer" {channel="espmilighthub:rgb_cct:001:0x12341:level"}
Dimmer Spot_Ctemp "Spot Caldo/Freddo" {channel="espmilighthub:rgb_cct:001:0x12341:colourtemperature"}
Color Spot_Colore "Spot Colore" {ga="Light" [name="Spot"], channel="espmilighthub:rgb_cct:001:0x12341colour"}
String Spot_Cmd "Spot Command to Send" {channel="espmilighthub:rgb_cct:001:0x12341:bulbcommand"}
Switch Spot_SndCmd "Spot Send Command" {channel="espmilighthub:rgb_cct:001:0x12341:sendbulbcommand"}
Iâm also using in some case, to send on/off command to the same dimmer item since is accepted.
hi Elenio,
Thanks for verifying. I cleared my cache and temp folders and restarted openhab. Since then I havenât seen the issue. All my milight lights are responding as they should now for 2 days.
Thanks.
The issue returned after I had to reboot my pc 
When I change the brightness via openhab then the value is not retained after switching off and on again. It always turns the light on at the maximum brightness level. When I change the brightness by using the milight ESP web interface then it keeps that same level. Again I have many errors in the openhab log (which is attached) openhab.log (9.9 KB)
Today I noticed that the errors in the log and the issue are only there when I control my light with the android app. I donât know if it is an issue in the binding or in the app. I am running the app on Android 10. I also tried the beta version of the app, but the result is the same. The log is attached to my previous post.
Now I just found out that the Android app sends dimmer values with one decimal, like 20.0 while the web based version sends a value without a decimal, like 20.
I use the Basic UI to control the lights.
A value of 20.0 causes an error in the binding.
Mi-light and WLED can they be sync??
Via UDP or???
I have 2 servers, OH2 and OH3
on both servers, the bridge is registered in the file:
Bridge espmilighthub:esp8266Bridge:001 "hub" @ "milight" [ADDR="tcp://
In the log, there is a constant reconnection to the MQTT server.
I suspect that both are trying to connect with the same MQTT client name.
What is the customer name of MQTT? What do I need to change on one of the clients so that both can connect to the same MQTT server?
Thanks!
Yes that will be happening as it is hardcoded into the binding.
@Olymp
EDIT: the solution is simple. It uses espMilightHub:UIDofBRIDGE so just create a bridge with a different unique ID on each version of openhab and then it should work. If your allowing it to auto find the bridge it will call it auto001 from memory so the user will be espMilightHub:auto001
This was the first thing I did, but it didnât fix the problem. Now I did it again and restarting both servers solved the problem. Thanks!
Thanks for reporting and narrowing down the cause. The past few weeks I have been re-working this binding a lot and have now been able to remove the need for Paho library and use the built in MQTT methods. This has been the main road block as to why I have not bothered to submit for a mergeâŠ
Now this hurdle is mostly crossed I can address this issue you reported and have a new build out in a few days to a week, however it will be V3.x only so you will need to upgrade at some point to V3.
Also it will mean breaking changes, so for anyone moving to V3 I would suggest holding off setting up the globes until the new binding is out to save having to do the work a second time. All the changes I was not making that would cause breaking changes will all hit at the same time at the V3 binding as it seems a good time to clean up the code.
I remember you said that you will not make the binding as an official addon. The plans have not changed? I would really like it to be on the official list of addons.
Thanks for the work on this binding. I will not move to V3 before a released version, so I donât mind waiting a couple of weeks.
I would not call it the same binding anymore, it is 50% new and means breaking changes for setup, but after setup the operation and abilities should be the same. The new changes mean it may now be possible to get it merged. Before these new changes it was not worth submitting.
No problem, glad people are using it. Its currently what I call Alpha state now, working with some options missing. In a few days it should be feature parity and Beta status ready for testing.