Hello @Petrica and thank you so much!
Gonna set them up, a great addition to my lights 
I’s working like a champ!
@Petrica This is great thanks so much.
Interestingly, for me when the mqtt switch turns on night mode, the main lights shows as “on” which is helpful.
Also i’ve set a mqtt sensor which displays current bulb mode, (white, color, night, scene)
- platform: mqtt state_topic: "milight/update/0x1/rgbw/1" name: "Night Light" value_template: '{{ value_json.bulb_mode }}'
I will try and work out if this can be useful in anyway for state.
I have finally got a night light bulb set up using the below.
- platform: mqtt_template
name: "Night Light"
state_topic: "milight/update/0x1/rgbw/1"
command_topic: "milight/command/0x1/rgbw/1"
command_off_template: '{"state":"off"}'
command_on_template: '{"command":"night_mode"}'
state_template: >
{% if value_json.bulb_mode == 'night' %}
on
{% elif value_json.bulb_mode %}
off
{% endif %}
brightness_template: '{{ value_json.brightness }}'
This now works via HASS and state updates when the remote has set light to night mode.
This looks interesting!
Is there a simple way making this to only small script for transition one light over a set period of time?
Hi,
It actually depends on what you need. The platform I mentioned (MiLight) doesn’t support transition so I had to reside to several scripts (which probably work on any light platform). If using Hue or Lifx then transition is supported natively.
You can find below an over simplified version of the scripts referred in my post above (going from brightness 0 to 255 with increments of 1 at 3 seconds so it will take about 13 minutes to complete; I removed all the intermediary steps). For personal use I’ve done a few modifications since that initial version (such as adding an input boolean for ensuring proper exit of the script at demand).
Or you can have a look at the flux platform if you need to have the light follow the circadian rhythm (doesn’t involve setting a new script).
wakeup_room:
alias: 'Wakeup'
sequence:
- service: light.turn_on
data_template:
entity_id: light.light1
brightness: 0
rgb_color: [1,1,1]
- delay: '00:00:03'
- service: script.turn_on
entity_id: script.wakeup_room_turnon
wakeup_room_turnon:
alias: 'Wakeup turnon'
sequence:
- service: script.turn_off
entity_id: script.wakeup_room_iterate
- service: light.turn_on
data_template:
entity_id: light.light1
brightness: '{{ states.light.light1.attributes.brightness | int + 1 }}'
rgb_color: [1,1,1]
- delay: '00:00:03'
- service: script.turn_on
entity_id: script.wakeup_room_iterate
wakeup_room_iterate:
alias: 'Wakeup iterate'
sequence:
- service: script.turn_off
entity_id: script.wakeup_room_turnon
- service_template: >
{% if states.light.light1.attributes.brightness|int < 255 %}
script.turn_on
{% else %}
script.turn_off
{% endif %}
data:
entity_id: script.wakeup_room_turnonHello,
How can I get the status updatet in home assistant (groups 1-4) when I press the master ON/OFF button on my remote?
- name: "All lights"
state_topic: "milight/states/0x2DA6/rgb_cct/0"
command_topic: "milight/commands/0x2DA6/rgb_cct/0"
<<: *MILIGHT_PARAMS
This does not seem to work.
0x2DA6 is my remotes ID
Thank you in advance!
Hi @jussbba
This is intended behavior. Group 0 state updates over MQTT doesn’t work anymore on firmware higher than 1.7.x (I think that it is 1.7 although I might be mistaken; 1.6.x should be safe, though). However, if you send commands to group 0 from the gateway, the payload is sent; it is only group 0 not being updated anymore in the state topic.
As an workaround you can pair ALL the bulbs from groups 1-4 of the remote 0x2DA6 to ANY of the groups 1 to 4 from an arbitrary remote (let’s say 0x0001). There are some other stuff you can look in the github:
Thank you very much!
However, this automation does not seem to work. Do you have any idea why?
- alias: 'All Off'
initial_state: True
trigger:
- platform: mqtt
topic: 'milight/states/0x2DA6/rgb_cct/0'
action:
- service: mqtt.publish
data_template:
topic: 'milight/states/0x2DA6/rgb_cct/2'
payload_template: '{{ trigger.payload }}'
- service: mqtt.publish
data_template:
topic: 'milight/states/0x2DA6/rgb_cct/3'
payload_template: '{{ trigger.payload }}'
Thanks!
If you still use the gateway with 1.8.x firmware then the automation posted won’t work and you need to downgrade.
The workaround mentioned above was in regard of:
-
Keep firmware on 1.8.x
-
Pair all the bulbs with an arbitrary ID (0x0001) and group 1
-
Set a new light in HA (“all lights new” or something like that):
- name: "All lights new" state_topic: "milight/states/0x0001/rgb_cct/1" command_topic: "milight/commands/0x0001/rgb_cct/1" -
Modify the trigger part accordingly:
topic: 'milight/states/0x0001/rgb_cct/1'
With the above setup you can still use the physical remote (I assume 0x2DA6 is a physical device ID) and control any of the groups (including group 0, that is groups 1-4 and 0) and HA will keep track of groups 1-4 on 0x2DA6 and groups 0-4 on 0x0001
If you downgrade gateway to 1.6.5 then there is no need for any change and automation posted should work (if it doesn’t then the cause is in other place such as topics in HA not being the same as the one used on the gateway).
Another workaround (this is what I recommend in order to improve reliability and range) is to have two gateways: one updated with the latest firmware and one on 1.6.5. Only the 1.6.5 gateway should post states update while both of them are to be connected to the command topic (simply delete state topic on the 1.8.x gateway).
Hello,
Thank you for your help Petrica!
However, it is not working perfectly. If I turn all the lights off from 0x0001 and then try to turn on one specific group from home assistant, lights turn on but the state goes back to off after 1 second in home assistant. I used MQTT Lens and it shows that it is only sending data to command and update topics but not to state topic. Any ideas?
- alias: ‘All lights on/off’
initial_state: True
trigger:- platform: mqtt
topic: ‘milight/states/0x2222/rgb_cct/1’
action: - service: mqtt.publish
data_template:
topic: ‘milight/states/0x2DA6/rgb_cct/3’
payload_template: ‘{{ trigger.payload }}’ - service: mqtt.publish
data_template:
topic: ‘milight/states/0x2DA6/rgb_cct/2’
payload_template: ‘{{ trigger.payload }}’
- platform: mqtt
One more thing. For me, it would be important to turn all the lights off from physical remotes master button.
You said that “With the above setup you can still use the physical remote (I assume 0x2DA6 is a physical device ID) and control any of the groups (including group 0, that is groups 1-4 and 0)”
–> Does this mean that it is also doable? To turn all the groups off from remotes master button and get the status updated in home assistant.
Please include details in regard of the gateway:
- what firmware is currently running;
- if you’re able to setup another physical gateway;
The options are:
a) single gateway with older firmware (1.6.5) -> use the light with remote 0x2DA6, group 0 and automation as is; you will be able to use the physical remote to turn any group from 0 to 4 (thus also master) and it will be updated into HA; you need the automation that you posted which will forward state from remote 0x2DA6, group 0 to groups 1 to 4 in order to have HA in sync with the physical state of the bulbs;
b) single gateway with newer firmware (1.8.3) -> you cannot have group 0 updated into HA (unless the developer agrees to bring back this specific functionality which is unlikely 
); in this situation you are not able to update group 0 from the physical remote into HA so I will not post any workaround;
c) one gateway with 1.8.3 (going forward update this gateway to the latest firmware) and one with 1.6.5 (and keep it on this firmware) -> you will be able to use it as described at point a) with the advantage of having a wider area covered. Also, as sometimes packets from the gateway are lost (either due to defective NRF24L01 modules, or due to light bulbs being on different frequency), this is able to improve reliability of the entire MiLight network (when I first started with MiLight in HA I was using a single gateway and turning on/off the switch triggered an automation that sent the payload to bulbs three times in a row with 100 milliseconds delay however I’ve switched to a multi-gateway solution). The setup of the two gateways will be similar except the fact that the gateway with 1.8.x will have a blank field for state topic. You can use as many gateways as needed to cover a very large area but at least one with 1.6.5 to have the physical remotes synced back to HA.
You can setup another physical remote (either FUT092/FUT089 for handheld remote with multiple groups/FUT088 for single group remote or B4/B8 for wall mounted with multiple groups/B0 for single group) by pairing it with the existing bulbs (a bulb can be paired with a maximum of 4 remotes, either physical or virtual) and forward states from that remote to the one that you already have. FUT088 and B0 can be used to control lights in a room (similar to using group 0 on a multi group remote) which should be easier than the multigroup remotes to use for non-residents 
Also, you can use MiLight remotes to control (through HA) other brands of light bulbs (such as Philips Hue) - that is not only send on/off but also color/saturation/brightness commands.
Thank you for your effort!
I have a spare nodemcu and nrf24l01 module so I might try to make another gateway with firmware 1.6.5. My current firmware is 1.8.3
If I have 2 gateways, does the master on/off switch turn on in home assistant even if only one group (1-4) is turned on?
Let’me know if I understood correctly your question: you have only one group from the remote (let’s say 2) and want to turn it on from HA then have the group 0 light topic update it with the same settings as the ones for group 2?
If this is the case, then you can define group 0 as a separate light in HA. In the automation above you would change group 2 to be in the trigger part and group 0 in the action (so it will forward state from 2 to 0).
I meant that if I have for example turned groups 1, 2 and 3 on seperately, and then want to turn all them off simultaneously from HA.
I guess the state of group 0 is not changed so I can not turn them off since the group 0 switch state is already off?
edit: you probably answered for that already: “If this is the case, then you can define group 0 as a separate light in HA. In the automation above you would change group 2 to be in the trigger part and group 0 in the action (so it will forward state from 2 to 0).”
Thanks!
Actually the answer is yes (even if state of light setup for group 0 is off you can still send off payload from HA to gateway and will send group 0 off state again). The fact is that you should set the light as two separate buttons in HA instead of a toggle by setting into customize_glob part:
"light.*":
assumed_state: true
For example if you have the following state:
light A (group 0 - remote 0x0011): state off
light B (group 1 - remote 0x0011): state on
light C (group 3 - remote 0x0011): state off
light D (group 1 - remote 0x0022): state on
And, with the following automation can set group 0 of remote 0x0011 to off to all bulbs (even if from another remote) - replace only light1, light2, etc. with your owns.
- alias: "Press master lights off"
initial_state: True
trigger:
- platform: mqtt
topic: 'home/milight_gw/state/0x2DA6/rgb_cct/0'
condition:
condition: and
conditions:
- condition: template
value_template: '{{ "OFF" in trigger.payload }}'
- condition: or
conditions:
- condition: state
entity_id: light.light1
state: 'on'
- condition: state
entity_id: light.light2
state: 'on'
- condition: state
entity_id: light.light3
state: 'on'
...etc...
action:
- service: light.turn_off
data_template:
entity_id: >
{%- for device in dict(states.light|groupby("state"))["on"] %}{%- if loop.first %}{% else %}, {% endif %}{{device.entity_id | lower }}{%- if loop.last %}{% endif %}{%- endfor %}I built another gateway and it actually works, now the group 0 is working! 
Next I will focus on automation you posted!
I really appreciate your help!
Hello,
My white bulbs are not cooperating at all. Here is my automation for them (2 gateways):
- alias: ‘All Off’
initial_state: True
trigger:
- platform: mqtt
topic: “milight/states/0x8224/cct/0”
action:- service: mqtt.publish
data_template:
topic: ‘milight/states/0x8224/cct/1’
payload_template: ‘{{ trigger.payload }}’- service: mqtt.publish
data_template:
topic: ‘milight/states/0x8224/cct/2’
payload_template: ‘{{ trigger.payload }}’- service: mqtt.publish
data_template:
topic: ‘milight/states/0x8224/cct/3’
payload_template: ‘{{ trigger.payload }}’- service: mqtt.publish
data_template:
topic: ‘milight/states/0x8224/cct/4’
payload_template: ‘{{ trigger.payload }}’
When I turn off for example group 3 from my physical remote, MQTT publishes these:
-
milight/updates/0x8224/cct/3 ← which is the correct group
-
milight/updates/0x8224/cct/1 ← group 1?!
-
milight/states/0x8224/cct/1 ← group 1?!
And randomly, every groups state goes to off, when I am turning off only one group.
Any idea what is going on?
For one you don’t need the updates topic at all (as you’re not using them in HA; the updates are in terms of delta vs. previous state) so remove it from the MQTT topics of the gateway (less strain on the MQTT broker this way).
I think there might be some other automation that pushes state update. I cannot reproduce the issue (I only have rgb_cct and rgbww bulbs but when sending cct packages from the gateway seems the correct group is received all the time).
I don’t think it is related to https://github.com/sidoh/esp8266_milight_hub/issues/306 as the gateway identifies the cct package (although to a different group…).
Could you look into the MQTT topics with “-d” flag (that is mosquitto_sub -h 192.168.x.x -d -t "#")?
How are the cct bulbs set into HA?
Hello,
Could you look into the MQTT topics with “-d” flag (that is mosquitto_sub -h 192.168.x.x -d -t "#" )?
→ does this provide the same information as using mqtt lens? There is only one topic now, states topic.
It seems that the gateway sends off command to the last topic used.
For example:
If I first turn on group number 1 and then group number 2 and then try to turn off group number 1, it will turn off group number 2 because it was the last group used.
Or, if I turn on all groups from master on/off (group 0) and then try to turn off for example group number 2, it will turn off all the groups because last group used was group 0. It will do it until I turn on some other group and then it sends off command to that topic when turning off some other group etc.
Here is my config:
name: “Living room”
state_topic: “milight/states/0x8224/cct/1”
command_topic: “milight/commands/0x8224/cct/1”
<<: &MILIGHT_PARAMSS
platform: mqtt_json
color_temp: true
rgb: false
brightness: truename: “Kitchen”
state_topic: “milight/states/0x8224/cct/2”
command_topic: “milight/commands/0x8224/cct/2”
<<: *MILIGHT_PARAMSSname: “Spots”
state_topic: “milight/states/0x8224/cct/3”
command_topic: “milight/commands/0x8224/cct/3”
<<: *MILIGHT_PARAMSSname: “TV”
state_topic: “milight/states/0x8224/cct/4”
command_topic: “milight/commands/0x8224/cct/4”
<<: *MILIGHT_PARAMSSname: “All lights”
state_topic: “milight/states/0x8224/cct/0”
command_topic: “milight/commands/0x8224/cct/0”
<<: *MILIGHT_PARAMSS
0x8224 is physical remotes id.
And this is my only automation for cct bulbs:
- alias: 'All Off/On'
initial_state: True
trigger:
- platform: mqtt
topic: 'milight/states/0x8224/cct/0'
action:
- service: mqtt.publish
data_template:
topic: 'milight/states/0x8224/cct/1'
payload_template: '{{ trigger.payload }}'
- service: mqtt.publish
data_template:
topic: 'milight/states/0x8224/cct/2'
payload_template: '{{ trigger.payload }}'
- service: mqtt.publish
data_template:
topic: 'milight/states/0x8224/cct/3'
payload_template: '{{ trigger.payload }}'
- service: mqtt.publish
data_template:
topic: 'milight/states/0x8224/cct/4'
payload_template: '{{ trigger.payload }}'
Thanks!
I turned off the gateway with firmware 1.65 and it worked fine, without group 0 ofc. I think there is some problem with firmware 1.65 