Hi @devax, could you explain how you did this, please?
New build 17-03-2018 has following changes:
- Support for fut089 remotes as it simply changes them into rgb_cct as the remotes can only control that type of globe.
- PaperUI should now correctly find and add fut089 globes as rgb_cct
- Globes will go offline if no valid bridge is selected with an error message to stop potential NPE.
- Change made to username and passwords that are empty, could not reproduce but made a change which may solve the issue.
- New parameter called DELAY_BETWEEN_SAME_GLOBE so you can have fast MQTT messages but slow down and reduce multiple messages to the same globe when swiping around a colorpicker. Recommend you leave on default and only play with the DELAY_BETWEEN_MQTT parameter.
1 Like
@vzorglub I more or less followed this instruction here: Mosquitto MQTT Bridge-Usage and Configuration
I have added these configuration lines to my mosquitto.conf:
connection milightworkaround
address mymosquittoservername:1883
topic # both 0 milight/states/0x66CA/fut089/ milight/states/0x66CA/rgb_cct/
remote_clientid localbridgeremote
local_clientid localbridgelocal
remote_username myusername
remote_password mypassword
The topic line is the rule that every message published in milight/states/0x66CA/fut089/ will be re-published into milight/states/0x66CA/rgb_cct/ (and vice-versa, but Iām not sure if this is needed; maybe āoutā would be sufficient instead of ābothā). Obviously you have to substitute my device id with your own.
EDIT: This seems to be obsolete now. Release 17-03-2018 works without using a MQTT bridge. Thank you @matt1! 
2 Likes
Thank you,
I have not implemented the ESP milight hub yet but I will definitely use that info for something else
Hi mcqwerty,
Can you explain to me how you control your LED strip?
Do you have your ESP8266 to control the MiLight LED Strip controller, where the led strip is connected to?
What settings need to be done in the ESP bridge so it can control the milight controller?
As per the link in my post:
I use the LED strip controller directly connected to my LED strip. The strip controller behaves exactly like an RGBW bulb but instead of lighting built in LEDs it controls the 4 (RGBW) channels connected to it.
No settings are required on the ESP bridge, just treat it exactly like any other RGBW bulb.
Thank you so much mcqwerty, I understand now!
Build 21-03-2018 changes are:
- Added ability for a paperUI search to add the first hub/bridge and better log messages to guide a new user.
No point upgrading to this build for people already setup. I also did some more testing on blank passwords and using multiple virtual bridges, could not find any issues. If you want to have different settings on some globes compared to others the binding seems to be working for doing this with multiple bridges that still go back to the same MQTT broker and the one physical esp8266 can still be used transmit the RF.
Builds are going to slow down now as I can not find bugs and the features are all working.
Build 23-03-2018 is a BETA (found in the subfolder beta) and has two new features which need testing:
-
POWERFAILS_TO_MINDIM new feature means if the power fails the globes will start back in the lowest level of light instead of potentially the max brightness. Then you can use a rule to turn globes back off. This week the power failed and I got woken up by all lights on maximum brightness in my bedroom, was not happy so this is the first step to fix. NOTE: will mean if you toggle the power switch it behaves the same way. Feature is off by default.
-
AUTOCTEMP_MAXDIMMED_TEMPERATURE This new feature allows the supported globes to change colour temperature based on brightness to emulate a halogen globe and how they become warmer as the globe dims. I find I like true whites when a globe is bright, but prefer a warmer tone when globes are dimmed down low for mood lighting. This feature was one of the main reasons why I wanted to create a binding.
Both features work better with lower packet_repeats and lower delays between MQTT packets as you do not see the lights change in multiple steps as you speed up the ability to change states faster.
What do people think of these new features? If you donāt like them, do they disable correctly?
Can someone help me clarifying how to set rgb_cct bulbs into a specific white state most effectively? Currently I can use one single command to bring the bulb into a specific color state, like this: MyLight_Hue.sendCommand("5,100,10"). When I want to set the bulb to white, this is what Iām currently doing:
MyLight_Cmd.sendCommand('set_white')
MyLight_SndCmd.sendCommand(ON)
MyLight_CTemp.sendCommand(100)
MyLight_Level.sendCommand(50)
Is there a way to send this four commands in one single commands? So that the state change will take less time to complete?
Currently the best way would be.
MyLight_Level.sendCommand(50)
MyLight_CTemp.sendCommand(100)
These two should turn the light on and set the brightness and the second one will set the light to white and the exact white temperature.
The globes at a firmware level do not allow changes when the globes are turned off. So you MUST always turn the globe on first and then send any changes.
1 Like
You should reduce your packet_repeats in the esp8266 control panel AND lower the bindings DELAY_BETWEEN_MQTT setting.
The default setting is 200ms from memory which sending 4 commands will mean it is almost a full second before the state is fully changed. Iām using 30ms in my setup as I can get my packet_repeats down to 8 and still have reliable transmission to the globes. More details on this are in previous posts.
1 Like
Thank you very much for the useful information. I will start playing around with these values once things produce reliable results. In order to make the state change work reliably in my rule, i had to insert some Thread::sleep statements in between. In this rule, Iām changing 6 bulbs in total, the change to white will not happen reliably with some bulbs in the middle, unless I insert a Thread::sleep somewhere in between.
Part of my hassles might come from me trying to use my lights with the FUT089 (8 group) remote in parallel with Openhab. Today I realised there is an other NPE when I define a thing for group 7 like this:
Thing rgb_cct 0x66CA7 "Lamps on Group 7"
The log will show this on startup:
2018-04-01 22:58:55.089 [ERROR] [ome.core.thing.link.ThingLinkManager] - Exception occurred while informing handler: null
java.lang.NullPointerException: null
at org.openhab.binding.espmilighthub.handler.EspMilightHubHandler.handleCommand(EspMilightHubHandler.java:82) ~[?:?]
at org.eclipse.smarthome.core.thing.binding.BaseThingHandler.channelLinked(BaseThingHandler.java:243) ~[?:?]
at org.eclipse.smarthome.core.thing.link.ThingLinkManager.lambda$0(ThingLinkManager.java:290) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
Strange enough, the light will be controllable through Openhab nevertheless, but there are weird side effects. Not sure what the differences are between rgb_cct and FUT 089 (if any), but currently the binding seems to have some struggles working in parallel with the FUT089 remote, at least when using group 7. Groups 1 to 4 seem to work fine, the other groups (besides 7) I have not used, yet.
New build 02-04-2018 is a beta and has the following changes:
- Better handling if globes details change due to a configuration file saved whilst the binding is running. Possible this was the cause of devax report in last post.
- Added back in some debug logging in case issue is not solved to assist in tracking problems.
- Added more support to handle FUT089 remotes correctly. This requires you to remove/change globes over to the new fut089 thing type. The milight protocol is all about remotes and this binding uses āglobesā to make it more user friendly, but in this case it can cause confusion when 2 remotes control the same globe type.
If upgrading to use the fut089 you probably only need to edit your āthingsā file.
change
Thing rgb_cct 0xEC591 āFront Hallā
to
Thing fut089 0xEC591 āFront Hallā
Fingers crossed it should be that easy to change over, otherwise if you used paperUI it will require the globe to be removed and re-added.
A few things to reply to you with, so please read all textā¦
I read your post on the github issues list and I suspect it is something in the hubs firmware caused by the way I was sending group 7 with rgb_cct type remotes. The only way I could solve this was to add another thing type which I was trying to avoid, but it would have caused other issues by not making the change. Since I donāt own a fut089 remote I can only guess at this stuff and do basic tests using the control panel of the hub.
My previous reply was wrong:
MyLight_CTemp.sendCommand(100)
MyLight_Level.sendCommand(50)
that order is the better way as the level may be wrong if the globe was in color mode before sending. I did write some shortcuts in to the MQTT messages but I found problems when trying to set too many things at the same time in the one MQTT payload. I have not tested it in more recent firmwares so it may be worth your time testing it as I could add a feature to send a raw MQTT string from the binding. About to get pretty busy and time is a premium for me due to a baby on the way.
Regarding the NPE error:
Please enable DEBUG log messages on the binding so you get more output if not already doing. Then please provide to me some of the output BEFORE the error occurs as that helps me understand what the binding was doing before the error occurs.
Also if you change files like the āthingsā definition whilst the binding is running please reboot your openhab server before reporting any issues, I could be wrong but the text in your post may have been channels re-linking just after having edited and saved a file. I have changed some code to handle this better but after you have things setup, best to reboot to get a clean state.
@matt1 The beta binding is awesome! In addition to the change in the āThingsā, I also updated the item bindings to the new channel names (fut089 instead of rgb_cct). The interference error with group 2/7 is gone. Also, no NPE left in the OH startup log (log excert was from a OH restart, btw). Thanks to the new thing type, no need for me for the MQTT bridge, so setup complexity further reduced. Thank you so much for your time and your great support!
PS: Second baby on the way here, too. My wife thinks Iām nuts spending so much time playings with the ligths. But a man needs a hobby ā¦ 
I might test the raw MQTT messages later for further improvement; for now Iām happy how it works.
Congrats on your second.
Having had time to think. You could easily use the mqtt binding to send the raw packets, when the hub responds with the state packet my binding will still update the openhab controls. No need to add this feature when it is pretty simple to do already.
Thanks for the feedback, always good to know it is working fine when so many changes are made. The fut089 remote uses different packets btw so using the wrong remote type as we were doing was probably the cause of your weird behaviour.
I stumbled across this.
Ey thanks you for that !
My setup is with an external antenna, but this is a good start point !
If you use exactly the same antenna as me, this might be something for you. I made this because i use an external antenna too and didnt want to resolder all connectors and use jumpers instead.
1 Like