Thanks and yes it is much easier than using rules and also has many more features behind the scenes.
Lights work really well at our place with a google home mini for voice control.
Matt, sorry to bother you,
Playing around with this amazing solution in autodiscovery mode via PaperUI
Noticing Bind discover and create different Thing if multiple Remote control is paired with the same bulbs
I understand, this is normal beahviour with this method, I supposed
Now I change seriously and wanted to create the real environment, removing the OEM Bridge, since this object is no more usefull with the new fantastic home made
Wanting to adopt the Manual Text configuration the question is:
after mapping the bridge and my different bulbs type (RGB_CCT, CCT, RGBWW,âŠ) I got in my house (twenty) assigning them the right âcustomâ label aka the custom deviceid in the rights text files, what is not so evidente in the process is that I have to send a pair command to each. Is that right?
Another pratctical hints, have I to completly reset my OH installation or simply delete one by one all the Things previosly discovered and mapped in PaperUI? Is it enought to clean the actual environment?
hope youâre so patient to answer everything as you get the time to.
My personal appreciation to your job
Thank you
1 Like
Yes it is normal as milight uses remotes for the ID and the globes have no id number. This is how the one way protocol milight uses works. You can always press the eye icon with a cross through it to ignore one of them in paper ui. However reconsider having two remote linked to a globe because that will cause issues if someone moves a remote that is not linked to the openhab controls. You could work around that with rules to make both remotes move the same
Control. I hope that makes sense.
There are many ways to set up the lights and my personal way is to have no real remotes for people to use and to use tablets on the wall with habpanel and use google home mini for voice control and rely on rules to do real automation with no user input needed. I do actually have a single remote that is linked to every globe in the house for a backup.
As for pair commands that depends. If you use the remote code that is already paired to the globe then no you do not need to pair again. If however you want individual control over every globe and donât have enough physical remotes then yes you will need to invent a random remote code and pair it up with the hubs control panel.
You donât need to reinstall openhab, just delete the things one by one. Once you see how much easier it is with text files you wonât go back. Move or rename the text file and they are all gone, far quicker to remove as well as to setup.
1 Like
Thanks for the binding, I was able to set up a T3 Wall Controller (rgbw) to controll 2 Hue Lamps and an LED Strip through ArtNet.
However Iâm unable to set up a T1 Wall Controller (only has level). In MQTT and PaperUI The controller shows up as âfut091â. When I add the controller as a thing through my config file, it will still be discovered in PaperUI (it does not recognize the thing as it does with the T3 rgbw controller). Because of this neither my items nor my rules using the T1 controller work.
I saw that there is support for the fut089 (should be B2 & T2). Maybe you can add support for the fut091 (B1 & T1) the same way?
Does the hubs firmware support this remote? If not raise it as a request at the below github link and let me know when the hub supports the remote at the firmware level. I am using old firmware and have not tried the newer ones yet so no idea soz.
The Hub does support the remote, the messages get send to the correct MQTT topic.
Thanks for the heads up, I am downloading Firmware 1.8.1 now to do some testing and I note that your remote only got added 9 days ago! It also appears that Milight have a number of new remotes some which have new RF protocols and finally support more groups (99 groups from the one remote) which will mean at some point I will need to change the way the things are defined which is a major change in my code. If anyone is using paperUI to setup there things, I would recommend you change over to file based definitions as it will be so simple to make this change compared to using paperUI. Great to see that the firmware is still very active and now has multiple people making changes.
New Build 08-08-2018 now available and has following changes:
- UI changes to group settings.
- Support for new remote FUT091 (needs testing as I only did a quick check and it has been awhile since I looked at this code) @wertzui enjoy and let me know what needs further testing or if everything is fine.
- Bug fix for helping controls display accurately if you have a switch and slider linked at the same time to the level channel.
- Logging changes.
- Reentrant locks now used to try and address a minor bug.
- Removed a workaround fix for old CCT globes that was only needed in very old firmware, if you have issues upgrade the firmware for your hub as the bug has not been around in the firmware for a long time now so I wanted to clean up the code.
I just tried the new build, but it does not seem to work with the fut091 remote.
This is how it shows up in Paper UI:
This is my bridge thing with the working rgbw (T4) controller and the non working fut091 (T1) controller:
Bridge espmilighthub:esp8266Bridge:001 "Milight Bridge" @ "Abstellkammer" [ADDR="tcp://server:1883"] {
// GĂ€stezimmer
Thing fut091 0x23CA1 "GĂ€stezimmer 1" @ "GĂ€stezimmer"
Thing fut091 0x23CA2 "GĂ€stezimmer 2" @ "GĂ€stezimmer"
Thing fut091 0x23CA3 "GĂ€stezimmer 3" @ "GĂ€stezimmer"
Thing fut091 0x23CA4 "GĂ€stezimmer 4" @ "GĂ€stezimmer"
// Schlafzimmer
Thing rgbw 0x78251 "Schlafzimmer 1" @ "Schlafzimmer"
Thing rgbw 0x78252 "Schlafzimmer 2" @ "Schlafzimmer"
Thing rgbw 0x78253 "Schlafzimmer 3" @ "Schlafzimmer"
Thing rgbw 0x78254 "Schlafzimmer 4" @ "Schlafzimmer"
}
These are my items:
Dimmer Gaestezimmer_Wallcontroller_1_Level "GĂ€stezimmer Wall Controller 1 Level" <light> {channel="espmilighthub:fut091:001:0x23CA1:level"}
Dimmer Gaestezimmer_Wallcontroller_2_Level "GĂ€stezimmer Wall Controller 2 Level" <light> {channel="espmilighthub:fut091:001:0x23CA1:level"}
Dimmer Gaestezimmer_Wallcontroller_3_Level "GĂ€stezimmer Wall Controller 3 Level" <light> {channel="espmilighthub:fut091:001:0x23CA1:level"}
Dimmer Gaestezimmer_Wallcontroller_4_Level "GĂ€stezimmer Wall Controller 4 Level" <light> {channel="espmilighthub:fut091:001:0x23CA1:level"}
Color Schlafzimmer_Wallcontroller_1_Color "Schlafzimmer Wall Controller 1 Color" <light> {channel="espmilighthub:rgbw:001:0x78251:colour"}
Dimmer Schlafzimmer_Wallcontroller_1_Level "Schlafzimmer Wall Controller 1 Level" <light> {channel="espmilighthub:rgbw:001:0x78251:level"}
Color Schlafzimmer_Wallcontroller_2_Color "Schlafzimmer Wall Controller 2 Color" <light> {channel="espmilighthub:rgbw:001:0x78252:colour"}
Dimmer Schlafzimmer_Wallcontroller_2_Level "Schlafzimmer Wall Controller 2 Level" <light> {channel="espmilighthub:rgbw:001:0x78252:level"}
Color Schlafzimmer_Wallcontroller_3_Color "Schlafzimmer Wall Controller 3 Color" <light> {channel="espmilighthub:rgbw:001:0x78253:colour"}
Dimmer Schlafzimmer_Wallcontroller_3_Level "Schlafzimmer Wall Controller 4 Level" <light> {channel="espmilighthub:rgbw:001:0x78253:level"}
Color Schlafzimmer_Wallcontroller_4_Color "Schlafzimmer Wall Controller 5 Color" <light> {channel="espmilighthub:rgbw:001:0x78254:colour"}
Dimmer Schlafzimmer_Wallcontroller_4_Level "Schlafzimmer Wall Controller 5 Level" <light> {channel="espmilighthub:rgbw:001:0x78254:level"}Can you provide a little more info please? IE, I am trying to do this⊠but it does thisâŠ
So far I have tested to work:
- auto add with paperui, it searches and finds and adds any already setup MQTT globes.
- Moving controls in paperUIâs control areas allows me to send MQTT to the broker in the correct format, so in theory if the firmware of the hub is working, it should then work. The binding only send MQTT and this is working here, use the command in my second post to watch all the topics being created.
mosquitto_sub -u usernamehere -P passwordhere -p 1883 -v -t 'milight/#'
I have not tested the remote in reverse, that is moving a control and seeing if it updates openhabs controls.
If you are having issues I would recommend the usual fix with openhab which is to try clearing out cache and tmp folders, which on linux servers use thisâŠ
sudo service openhab2 stop && sudo rm -rf /var/lib/openhab2/cache/* && sudo rm -rf /var/lib/openhab2/tmp/* && sudo reboot
@wertzui
I found that all my changes were being saved in the WS folder and not the build folder, this meant the JAR had zero changes in it whilst my test server worked. Please download the JAR again with todays date 09-08-2018 on it. Been a while since I created a JAR for this project so my apologies, fingers crossed this one works. I will be running the changes through my own server the next few days to iron out any bugs, make improvements and clean up the logging to be useful when needed and silent when things are working smoothly.
To see more detailed logs you can do this in the openhab console:
log:set TRACE org.openhab.binding.espmilighthub
change TRACE to INFO to go back to normal default output in your logs.
Whilst still in the console you can type
log:tail
And this shows the log output, CTRL + C ends it.
After I got my brightness only lights to work, Iâm now trying color 
I have an RGBW Controller (T3). The ON/OFF switches and the brightness dimmer are working fine. However I cannot see any color updates in the openHAB events.log.
In the bridge I have the following group_state_fields configured:
state, level, hue, saturation, mode, color_temp, bulb_mode
When I tap the color slider on the controller, I get the following MQTT message (Iâm trying to controll light #3):
Topic: milight/states/0x7825/rgbw/3
Message: {"state":"ON","level":100,"hue":258,"bulb_mode":"color"}
These are my items:
Color Schlafzimmer_Wallcontroller_3_Color âSchlafzimmer Wall Controller 3 Colorâ {channel=âespmilighthub:rgbw:001:0x78253:colourâ}
Dimmer Schlafzimmer_Wallcontroller_3_Level âSchlafzimmer Wall Controller 3 Levelâ {channel=âespmilighthub:rgbw:001:0x78253:levelâ}
I already tried changing the channel from colour to color but this did not work.
The level/brightness is working without any problems.
Iâm looking at the events.log file to exclude any errors that may happen with my light bulb (Philips Hue) that Iâm trying to control in the end.
The level/brightness updates are written to the events.log, but the color is not.
I also tried using the web interface of the bridge to exclude any problems with my controller, but both the controller and the web interface are sending the same MQTT messages.
It is missing a saturation value in the mqtt message, try going into the control panel and untickinging and then re ticking the saturation. See post two for the setup details.
If this only happens when u use the new remote then I would suspect you may have found a bug in the firmware as the remote is only just implemented.
I donât own rgbw globes but I did borrow one and test a very long time ago. I would need to check the firmware sends saturation for the other rgbw remotes and you can do that with the control panel. You donât need to own a remote to do some testing as the control panel has the controls and it will send mqtt that you can see.
I know, that I donât need a remote and I do most of the testing in the bridge web interface 
I found out that a remote of type rgbw does not send a saturation, only a remote of type rgb_cct sends a saturation value.
EDIT: New build 15-08-2018 now available to address @wertzui bug with RGBW remotes.
Sorry I missed your earlier post where you said you had tried it already
Iâll take a look at the code later tonight as I suspect this is something that has been missed in the binding and no one has reported, or a firmware update has changed this behaviour. Iâll assume saturation is 100% for RGBW globes, so expect that whenever you use your finger on an openhab control it will from now on jump to that position when the hub makes its MQTT reply. If you could test that the âwhite modeâ still gets triggered when you move the openhab control below the threshold set in the bindings options that would be great.
Thanks for reporting this.
The new vresion does not work for me.
Could you post your things and bindings that you have used to test it?
New build 16-08-2018 new changes are:
- Improved response when the light is in a turned off state and the colour temp control is moved in openhab2. Now it moves the level/brightness fader back to its previous state.
@wertzui
I downloaded the last release and it tests fine on my setup, downloaded it in case it uploaded badly but all good⊠I made the above change and then tested the newer build some more and it tests fine here, but I only have rgb-cct and cct globes. Try clearing the cache and tmp folders and restarting your server. I also discovered the auto colour temp feature is broken in Openhab 2.3 but is working on 2.2 narrowed down the cause to bulb mode not updating. I added some changes to filter this away from your new remote type as it may have been causing issues due to the CCT globes not having a bulbmode as they do not have colours.
I tried the new release and it is still not working. To exclude the Philips Hue bulb as a possible cause of problems, Iâm looking directly at the events.log file but nothing is written there when I change the color (using hte bridges web interface).
Would you mind posting a complete setup with thing and item that is working for you, so I can copy it and try to find the error?
I have no idea whats wrong. Try fault finding with the long previous replies I gave you. Sure, all you need is in post 2 of this thread.
I just spent a few hours testing the new remote and found no issues in the latest builds. Used paperUI to auto find the globe and then I can use the virtual remote in the esp8266 and have openhabs controls move so this is not a binding issue unless you give more info. All the info you need to fault find has already been given.