Yes it was the json blob and ALSO from memory sending manual Linux terminal mqtt pub commands that needed decimal to work. Have not tried it recently but I am sure I tried hex first in bash when testing and it failed to work till I used decimal.
Sniffer reports hex
Ui used hex only
Bash pub failed to work with hex
Bash pub worked with dec.
Have not tested since with newer firmwares as I used device ids that were the same in hex and dec for all my globes.
Thanks for the help and input guys.
@matt1 I can definitely wait till you have more time and be great if a binding is ever developed.
Right now, I just still think I have something wrong with my Item’s file as I can’t even get OH2 to show an update in the log when I use the remote. I see information being posted to Mosquitto, but nothing shows up in the logs.
fyi. my mqtt-eventbus.cfg file is empty. I think we do not need to enter anything here?
I currently decided to drop back to the 1.5 firmware as I can see more in mosquitto. So with the 1.5 firmware, when I use the remote, I see things like this.
{"device_id":26804,"group_id":1,"device_type":"rgb_cct","mode":96,"state":"ON"}
{"device_id":26804,"group_id":1,"device_type":"rgb_cct","mode":98,"state":"ON"}
{"device_id":26804,"group_id":1,"device_type":"rgb_cct","mode":100,"state":"ON"}
{"device_id":26804,"group_id":1,"device_type":"rgb_cct","hue":237,"state":"ON"}
{"device_id":26804,"group_id":1,"device_type":"rgb_cct","hue":236,"state":"ON"}
{"device_id":26804,"group_id":1,"device_type":"rgb_cct","hue":232,"state":"ON"}
{"device_id":26804,"group_id":1,"device_type":"rgb_cct","button_id":7,"argument":65,"state":"ON"}
{"device_id":26804,"group_id":1,"device_type":"rgb_cct","button_id":7,"argument":56,"state":"ON"}
{"device_id":26804,"group_id":1,"device_type":"rgb_cct","button_id":7,"argument":51,"state":"ON"}Note, the button_id appears to be the Saturation on the remote. The ESP 8266 Control Panel reports it as
{"device_id":26804,"group_id":1,"device_type":"rgb_cct","saturation":97,"state":"ON"}So I tried various items like this, but I get nothing in the log when trying the remote
Number TestMQTT "Test 1" {mqtt=">[mosquitto:milight/commands/26084/rgb_cct/1:command:*:default]"}
Number TestMQTT2 "Test 2" {mqtt=">[mosquitto:milight/updates/26084/rgb_cct/1:command:*:default]"}
Number TestMQTT3 "Test 3" {mqtt=">[mosquitto:milight/updates/26084/rgb_cct/+:command:*:default]"}
Number TestMQTT4 "Test 4" {mqtt=">[mosquitto:milight/updates/26084/1/rgb_cct/+:command:*:default]"}For publishing, both decimal and hexadecimal should work everywhere. If it doesn’t, it’s probably a bug. So let me know 
FWIW, if you use the -v flag with mosquitto_sub, you’ll see the topic the message was published on, which should include all of the same information that’s been removed from the payload in 1.6.
I’ll try some more tomorrow, but I’m still at a loss where I’m going wrong in getting the remote to process in MQTT and mosquitto.
I logged into the console I see all the bindings installed here.
openhab> feature:list | grep MQ
esh-tp-paho │ 0.9.0.SNAPSHOT │ │ Started │ distro-2.2.0-SNAPSHOT │ MQTT v3 Client
openhab-transport-mqtt │ 2.2.0.SNAPSHOT │ x │ Started │ distro-2.2.0-SNAPSHOT │ MQTT Transport
openhab-action-mqtt │ 1.11.0.SNAPSHOT │ x │ Started │ addons-2.2.0-SNAPSHOT │ MQTT Action
openhab-binding-mqtt1 │ 1.11.0.SNAPSHOT │ x │ Started │ addons-2.2.0-SNAPSHOT │ MQTT Binding
openhab-binding-mqttitude1 │ 1.11.0.SNAPSHOT │ x │ Started │ addons-2.2.0-SNAPSHOT │ OwnTracks (formerly MQTTitude) Binding
openhab-persistence-mqtt │ 1.11.0.SNAPSHOT │ x │ Started │ addons-2.2.0-SNAPSHOT │ MQTT Persistence
openhab>Using the -t options, I see the remote is logging with milight/updates
milight/updates/0x68B4/rgb_cct/1 {"device_id":26804,"group_id":1,"device_type":"rgb_cct","mode":45,"state":"ON"}
milight/updates/0x68B4/rgb_cct/1 {"device_id":26804,"group_id":1,"device_type":"rgb_cct","mode":56,"state":"ON"}
milight/updates/0x68B4/rgb_cct/1 {"device_id":26804,"group_id":1,"device_type":"rgb_cct","mode":68,"state":"ON"}
milight/updates/0x68B4/rgb_cct/1 {"device_id":26804,"group_id":1,"device_type":"rgb_cct","mode":86,"state":"ON"}
milight/updates/0x68B4/rgb_cct/1 {"device_id":26804,"group_id":1,"device_type":"rgb_cct","mode":100,"state":"ON"}But I can’t get any of these items to post anything to the logs to even attempt getting a rule started. Probably a very simple oversight or typo, and i’m just not seeing it.
Number TestMQTT "Test 1" { mqtt="<[mosquitto:milight/updates/0x68B4/rgb_cct/1:command:*:default]" }
Number TestMQTT2 "Test 2" { mqtt="<[mosquitto:milight/updates/26804/rgb_cct/1:state:*:default]" }
Number TestMQTT3 "Test 3" { mqtt="<[mosquitto:milight/updates/26804/rgb_cct/+:command:*:default]" }
Number TestMQTT4 "Test 4" { mqtt="<[mosquitto:milight/updates/+:command:*:default]" }First problem is your using number and not string. Since the mqtt message in our case is not purely a number u will need to use a string. Second issue you will hit is it is in json so openhab has a transformation add on for this. Third the values need to be scaled to fit a 0-100 slider correctly otherwise a feedback loop could form, and lastly the colour needs to be in a packaged HSB format so you need all three values to update the control.
There will be a limit to how much time I throw at this when it is better spent writing the binding. I probably will only get on and off hooked up and leave the rest for when a binding is done.
OK the coding went so well I ended up adding all the controls in around 2 hours, now even colour will update Openhab2 with any changes made with the milight remotes. The first post of this thread contains the following changes:
1.Updated mosquitto_sub that uses the v flag AND also only shows milight topics in case you use MQTT for other things. Thanks @sidoh for the suggestion.
The field called mqtt_state_topic_pattern in the espMH control panel needs to be filled in, and delete the contents of mqtt_update_topic_pattern. This is to take advantage of the new state tracking added in release 1.60 RC1 firmware so openhab should now have controls updated to display correctly if openhab is restarted. Also the UI has the ability to limit how often the state is sent to openhab which you should play with these settings to fine tune how fast you want the controls in openhab to be updated when the remote is moved. My settings are state-flush-int=0 and mqtt-state-rate-limit=500(default)
The new rules for allowing remotes to update the controls in openhab. Now tested 99% and it seems almost spot on. If you have issues you can remove or comment out the rule for remotes and the one way communication will work well.
A new item needs to be added for the remotes to work, see first post.
Made the on/off rule shorter. Trying to get this perfected before running a script on it to auto create the contents for all my 20+ globes.
Note: If your only testing this code with a single globe you only need to edit these two lines in your items file with the remotes device ID and the group number. You get these by using the espMilightHubs user control panel and using the SNIFF feature to capture a remote packet.
Example:
String Milight_ID1_G1_Light {mqtt=">[mosquitto:milight/commands/0xE6C/rgb_cct/4:command:*:default]"}
String Milight_ID1_G1_EspMilightHub {mqtt="<[mosquitto:milight/states/0xE6C/rgb_cct/4:state:default]"}
For those interested, I managed to port three of my existing (older type) bridges to this project using the UDP gateways. The end result work fantastically well, here’s a link to what I’ve done: https://community.openhab.org/t/the-new-milight-ibox-and-milight-binding/17621/275
Now that I’ve gotten my MQTT issues worked out, I’m trying to learn how to modify the rule a little to work and control Hue and Lightify bulbs.
For anyone else perhaps following this topic and if your having any MQTT issues, perhaps check this post here to see if you an old mqtt.cfg file in your var/lib… directory. It was causing my OH2 setup to not connect to the broker.
I figured out how to change the color of the hue bulb using the milight remote but I haven’t figure out how to actually turn on and off or change the brightness only of the Hue bulb yet when using the remote.
I added this at then end of the ‘color’ part of the rule to change a Hue bulb along with the MiLight bulb when using the remote and works good.
sendCommand(FF_Light_FamilyLeft,hsb)On a side note, it appears the Milight bulb has much better blue’s and greens then the Hue.
Great I have been wondering how they compare from someone with both. The HUE was released a while before these newer milight globes and LEDs have come a long way in that time. Which one is brighter on white? I feel ‘weird’ with the milight when I turn a fully saturated colour on and I can’t place what the feeling is, maybe it is because I am used to white light, does this happen with the HUE/you? Maybe it is just me 
I have 3-4 of these globes in each room of my house so I can really pump out bright bold colours.
Regarding your other comments, please create a new thread and mention my name with an @ on the front and it will let me know. Also edit your above post to have the link for others to follow should they want to do it also. Post a stripped down version of your items, sitemap and rules in the new thread and I’ll take a look.
Lastly it looks like your using an older version of my rules, I updated it last night after doing some more in depth testing and tweaking. The rules in the first post now create NewHSB which fixed a bug with brightness.
Updated the rules again in the first post.
Whats new:
If the light is turned off and any of the controls are moved, the light turns on first and then to the new state. Call this a shortcut as you need to move less controls to get what you want.
Some changes to how colour changes are made.
Updated to the new rules and things appear to working good. The one thing I’ve noticed that perhaps since I am attempting to control Hue Lights via passing the hsb values, etc to the Hue lights is that I am unable to turn them off easily. I added the below rule and it seems to work, although seems hit and miss on working perhaps because of an OH2 delay or other in sending the commands.
My Family Left and Right are Hue RGB color bulbs.
rule "Milight_ID1_G1_Off"
when
Item Milight_ID1_G1_State received update OFF
then
sendCommand(FF_Light_FamilyLeft, 0)
sendCommand(FF_Light_FamilyRight, 0)
endI also have gone and duplicated the items and rules creating Group0, Group1, and Group2 to control different specific Hue Bulbs. Do you think that is best approach?
If I understand you correctly then yes that is the best approach as this is not in a binding. Without a binding it means you have to edit and maintain heaps of rules. It can be made very simple if you learn how to use a script or mail merge to auto create the rules from my basic rules in the first post. The idea is you create a list of your globes, names, id and groups in a text file or in a spreadsheet file which you can edit this file with the raw data. Then you run the script or a mail merge and it will fetch your values from one file and output the rules into another file all perfectly created in seconds.
@ptmuldoon please create a new thread if wanting to discuss a different use OR for a question that may need multiple back and forth posting. Happy to help just wish to keep this thread on topic. This thread is linked to from the espmilighthubs wiki so keeping the thread on topic is important to save people going through heaps of posts that are not on topic.
Make sure you copy my code exactly before doing mods. I found that using received update was not reliable compared to received command for SWITCH items and it was the other way around for the other item types.
Try this rule:
rule "PhillipsHue_from_Milight_remote"
when
Item Milight_ID1_G1_State received command //OFF //change below code to handle on and off
then
sendCommand(FF_Light_FamilyLeft, 0)
sendCommand(FF_Light_FamilyRight, 0)
end
New rules added to the first post and new requirements to setup in the ESPMH control panel. This was to take advantage of some new features that I requested in the new 1.6 RC4 firmware that allows the brightness to stay in the 0-100 range for in and out messages. Same for Hue and Sat. Openhab uses 0-100 for sliders. This makes debugging far easier if the values going out match the incoming ones and prevented rounding errors from doing conversions. If that does not make sense to you, no worries it means the rules are shorter and the controls move more accurately.
Update: After doing extensive testing, the combination of these latest rules and 1.6 RC4 are working perfectly. Wont be updating rules anymore as I prefer to spend the time working on binding development as there are a number of features I wish to see implemented and the only way is by creating a binding.
Hello! Wonderful theme! I will be brief:
I use the light bulbs of the RGBW
Thanks, good work!
Yes that is the latest and the one to use. Rc4 stands for Release CAndidate 4 so that is older than the full release of 1.6.
Yes night mode should work I just have not included a control for it nor the disco modes as I wanted less controls taking up space. To get them working it just needs a different mqtt message sent.
Remote not working may be from not setting up the control panel of the espmilight hub as per my first post in this thread.
You need to untick brightness and tick level and the other stuff in my first post to get the remote working.
Also since you have rgbw and not the same as mine you will need to edit the lines to change the rgb_cct to rgbw as that needs to be in the mqtt topics being sent. If you still have issues please post what works and what does not, ie you can get the esp control panel to control the lights and what settings make that work as that helps work out what is wrong.
yes, I did it
can an example?
I did everything as you wrote. At me almost all works.
I do not understand what needs to be transferred to the mosquito to turn on the night mode and s+ s-
for mode I send:
items:
Number Milight_ID1_G1_mode "Mode"
sitemap:
Switch item=Milight_ID1_G1_mode mappings=[0='0',1='1',2='2',3='3',4='4',5='5',6='6',7='7',8='8']
rule:
rule "Milight_ID1_G1_mode"
when
Item Milight_ID1_G1_mode received command
then
Milight_ID1_G1_Light.sendCommand('{"state":"ON","mode":"'+Milight_ID1_G1_mode.state+'"}')
end
it works!
Night mode mqtt should be
{“command”:“night_mode”}
mode_speed_up is another command.
See here
Please post when u have it working and I’ll add it to the first post for others pending your ok.
Thank you! This I missed out of sight, with my bad English.
Command: set_white and night_mode, works for my bulbs (RGBW).
Command: next_mode it works, the mode changes from 0 to 8. But if the mode is changed through the mode, as I showed above: {“state”:“ON”,“mode”:“‘+Milight_ID1_G1_mode.state+’”}, then this command will continue from the place where it finished, and not from the last mode. Eg:
Command: previous_mode, changes mode 15,2,1,0,15,2,1,0 etc
Command: mode_speed_up and mode_speed_down, works, but it is not clear, the current state, what is the range from the minimum to the maximum? mosquito does not return status:
Maybe someone will be useful to know that the bulbs RGBW do not support saturation.
Is there any way to ask the light bulb for its current state?
Any spare time I have at the moment is spent working on learning binding development, once I have a binding working it will allow much better support and auto detection of the globes. This will work because if you connect to the MQTT broker it sends all known states from all known globes, I can use this to auto add the globes into Openhab and make it much easier for people to use Milight globes without writting as many rules. There are many other cool features I can add that are currently not possible and a binding is the only way to do what I wish to do.
items:
Switch Milight_ID1_G1_White "white"
Switch Milight_ID1_G1_Night "night mode"
rules:
rule "Milight_ID1_G1_White"
when
Item Milight_ID1_G1_White received command
then
Milight_ID1_G1_Light.sendCommand('{"command":"set_white"}')
end
//-----
rule "Milight_ID1_G1_Night"
when
Item Milight_ID1_G1_Night received command
then
Milight_ID1_G1_Light.sendCommand('{"command":"night_mode"}')
end
I deleted the saturation command in the rule “Milight_ID1_G1_HUE”:
Milight_ID1_G1_Light.sendCommand('{"state":"ON","level":'+iLEVEL+',"hue":'+iHUE+'}')
and in the rule “Milight_ID1_G1_HubStates”, you can transfer a fixed value of saturation:
Milight_ID1_G1_Hue.postUpdate(sHUE+","+ 80 +","+sLEVEL) //update color item
Update: