MQTT state_topic update not affected by group ALL

[vansoest]

MQTT state_topic update not affected by group ALL but by groups 1-4.

I send state on to 0 = ALL and groups 1-4:

$ mosquitto_pub -V mqttv311 -h 127.0.0.1 -t "/milight/commands/0x2/rgb_cct/0" -m '{"state":"ON"}' 
$ mosquitto_pub -V mqttv311 -h 127.0.0.1 -t "/milight/commands/0x2/rgb_cct/1" -m '{"state":"ON"}'
$ mosquitto_pub -V mqttv311 -h 127.0.0.1 -t "/milight/commands/0x2/rgb_cct/2" -m '{"state":"ON"}'
$ mosquitto_pub -V mqttv311 -h 127.0.0.1 -t "/milight/commands/0x2/rgb_cct/3" -m '{"state":"ON"}'
$ mosquitto_pub -V mqttv311 -h 127.0.0.1 -t "/milight/commands/0x2/rgb_cct/4" -m '{"state":"ON"}'

But I got only the state update for group_ids 1-4, group 0 is not affected:
$ mosquitto_sub -v -V mqttv311 -t "/milight/state/+/+/+":

/milight/state/0x2/rgb_cct/1 {"state":"ON","brightness":255,"color_temp":257,"bulb_mode":"white","color":{"r":255,"g":255,"b":255},"effect":"white_mode","device_id":2,"group_id":1}
/milight/state/0x2/rgb_cct/2 {"state":"ON","brightness":255,"color_temp":259,"bulb_mode":"white","color":{"r":255,"g":255,"b":255},"effect":"white_mode","device_id":2,"group_id":2}
/milight/state/0x2/rgb_cct/3 {"state":"ON","brightness":255,"color_temp":259,"bulb_mode":"white","color":{"r":255,"g":255,"b":255},"effect":"white_mode","device_id":2,"group_id":3}
/milight/state/0x2/rgb_cct/4 {"state":"ON","brightness":255,"color_temp":259,"bulb_mode":"white","color":{"r":255,"g":255,"b":255},"effect":"white_mode","device_id":2,"group_id":4}

Environment

MQTT is configured as follow:
MQTT topic pattern: /milight/commands/:device_id/:device_type/:group_id
MQTT update pattern: /milight/updates/:device_id/:device_type/:group_id
MQTT state pattern: /milight/state/:device_id/:device_type/:group_id

milight_hub version: 1.8.1

Context

The light switch in home assisant for the group ALL to controll all 4 bubls has always the value FALSE, because the mqtt state is never published. The bulbs 1-4 are working perfectly in home assisant.

But in the past all worked like a charm. Probably a homeassisant update change, probably a bug in this bridge?

Home assistant configuration

Configuration YAML snippet

light:
  - name: Livingroom  
    state_topic: "/milight/state/0x1/rgb_cct/0"
    command_topic: "/milight/commands/0x1/rgb_cct/0"
    <<: &MILIGHT_PARAMS        
      platform: mqtt_json      
      color_temp: true         
      rgb: true
      brightness: true         
      effect: true             
      effect_list:             
        - white_mode           
        - night_mode           
        - 0
        - 1
  - name: Bedroom
    state_topic: "/milight/state/0x2/rgb_cct/0"
    command_topic: "/milight/commands/0x2/rgb_cct/0"
    <<: *MILIGHT_PARAMS
  - name: Bedroom 1
    state_topic: "/milight/state/0x2/rgb_cct/1"
    command_topic: "/milight/commands/0x2/rgb_cct/1"
    <<: *MILIGHT_PARAMS
  - name: Bedroom 2
    state_topic: "/milight/state/0x2/rgb_cct/2"
    command_topic: "/milight/commands/0x2/rgb_cct/2"
    <<: *MILIGHT_PARAMS
  - name: Bedroom 3
    state_topic: "/milight/state/0x2/rgb_cct/3"
    command_topic: "/milight/commands/0x2/rgb_cct/3"
    <<: *MILIGHT_PARAMS
  - name: Bedroom 4
    state_topic: "/milight/state/0x2/rgb_cct/4"
    command_topic: "/milight/commands/0x2/rgb_cct/4"
    <<: *MILIGHT_PARAMS

Conclusion

If I send a state ON/OFF via MQTT to the group all, all bulb groups from 1-4 should be updated or the 0 group should be updated or all? What do you think? Or it's already implemented but only not workingfor me?

[PetricaM]

@vansoest

Group 0 doesn't update anymore state for groups 1-4 (or 1-8 on the FUT089/B8) #284

You can still use HA automation to sync groups 1-4 with the state of group 0 (this is also easier on the gateway as the machine running HA is likely way more powerful than an ESP8266):

- alias: Push Remote Group 0 state to Groups 1 - 4
  initial_state: True
  trigger:
    - platform: mqtt
      topic: 'milight/state/0x2/rgb_cct/0'
  action:
    - service: mqtt.publish
      data_template:
        topic: 'milight/state/0x2/rgb_cct/1'
        payload_template: '{{ trigger.payload }}'
    - service: mqtt.publish
      data_template:
        topic: 'milight/state/0x2/rgb_cct/2'
        payload_template: '{{ trigger.payload }}'
    - service: mqtt.publish
      data_template:
        topic: 'milight/state/0x2/rgb_cct/3'
        payload_template: '{{ trigger.payload }}'
    - service: mqtt.publish
      data_template:
        topic: 'milight/state/0x2/rgb_cct/4'
        payload_template: '{{ trigger.payload }}'

A similar automation can be used to sync multiple physical remotes (associated with one bulb) to a single light entity in HA (i.e push the state of remote 0x4/0x5/etc. to remote 0x2, which is the one was used in HA; remote 0x4/0x5 doesn't need to be defined in HA):

- alias: Sync physical remotes states
  initial_state: True
  trigger:
    - platform: mqtt
      topic: 'milight/state/0x4/rgb_cct/3'
  action:
    - service: mqtt.publish
      data_template:
        topic: 'milight/state/0x2/rgb_cct/3'
        payload_template: '{{ trigger.payload }}'

Some other thoughts:

• MQTT update topic is not used in HA config; removing it would only decrease load on the gateway;
• if wanting to use the "native" effects of MiLight (called modes) then set the effects as 0 to 8 and use an automation to forward the payload which is then changed into mode:

#Light config
...
  effect_list: [0, 1, 2, 3, 4, 5, 6, 7, 8]
...

#Automation

- alias: Effect2Mode
  initial_state: True
  trigger:
    - platform: mqtt
      topic: 'milight/commands/+/rgb_cct/+'
  condition: 
    condition: template
    value_template: '{{ "effect" in trigger.payload }}'  
  action:
    - service: mqtt.publish
      data_template:
        topic: "milight/commands/{{ trigger.topic.split('/')[-3] }}/rgb_cct/{{ trigger.topic.split('/')[5] }}"
        payload_template: '{ "mode": {{ trigger.payload_json.effect }} }'

[vansoest]

Thank you for this nice workaround! I'm using it now as follow:

- id: milight_push_group0
  alias: Milight Push Remote Group 0 state to Groups 1-4
  initial_state: True
  trigger:
  - platform: mqtt             
    topic: '/milight/commands/+/rgb_cct/0' 
  action:
  - service: mqtt.publish      
    data_template:             
      topic: "/milight/state/{{ trigger.topic.split('/')[-3] }}/rgb_cct/0"
      payload_template: '{{ trigger.payload }}'
      retain: True
  - service: mqtt.publish
    data_template:
      topic: "/milight/state/{{ trigger.topic.split('/')[-3] }}/rgb_cct/1"
      payload_template: '{{ trigger.payload }}'
  - service: mqtt.publish
    data_template:
      topic: "/milight/state/{{ trigger.topic.split('/')[-3] }}/rgb_cct/2"
      payload_template: '{{ trigger.payload }}'
  - service: mqtt.publish
    data_template:
      topic: "/milight/state/{{ trigger.topic.split('/')[-3] }}/rgb_cct/3"
      payload_template: '{{ trigger.payload }}'
  - service: mqtt.publish
    data_template:
      topic: "/milight/state/{{ trigger.topic.split('/')[-3] }}/rgb_cct/4"
      payload_template: '{{ trigger.payload }}'

Added also a payload to push the state as retain value to group 0.
Effect2Mode works also like a charm, thx!

[PetricaM]

Similar automations can be used to translate white_value (supported by HA) into saturation (used by ESPMH however in reverse: low white_value corresponds to high saturation and vice versa) and to convert scale for color_temp (color_temp is used by both however with different ranges: 0-370 vs. 153-500)

[sidoh]

Thanks for the super detailed report @vansoest, and @PetricaM for the detailed followup. You're both awesome.

As Petrica points out, this is now expected.

However, I do recognize that it might result in unexpected behavior, and I'm open to making changes if folks feel like it'd be worthwhile.

[FrankZZ]

@sidoh should sending a command to group 0 publish a state message for itself (I just understood it won't send a state message for 1-4 but what about 0)?

[sidoh]

I considered this in #284. The trouble is that you can't really keep state for group 0 in a way that makes sense in every situation. The reason for this is fundamentally that it's not a group.

Example:

• Turn group 0 "on" (turns groups 1, 2, 3, and 4 on)
• Turn groups 1-3 off individually

What, then, is the state for group 0?

I think it's just really messy to treat group 0 as a real group. Maybe the practical implications outweigh this conceptual fuzziness, but I think we'd need more data.

[FrankZZ]

Ah, I get it. I was going to use group 0 as a workaround for the "multiple bulbs in HA light group don't turn on at the same time" and when I want I can still trigger the individual bulbs (by not using group 0 but the actual bulb group)

[PetricaM]

Hi Chris,

"Group" 0 state would be useful case wanting to set the state of multiple bulbs without going through each and every one (for 6-7 lights takes about 20 seconds in Home Assistant to set each light).

Another case would be when having multiple lights the same room and setting different colors/intensity to each bulb (what Hue uses as scene): so have group 1 of the remote paired to light 1, group 2 to light 2, etc. For setting the scene Home Assistant would send the command to each light individually (takes about 2-3 seconds for 4 groups lights, using a 100ms delay between commands). However, for common use (about 98% of the time, thus when not trying to impress guests :) ) the four/eight groups should have the same setting. In this case, group 0 would be used to send the command and all bulbs react immediately.

The problem is that now, if sending a command that includes saturation to group 0, it activates white mode and the light flickers thus making commands from HA for group 0 quite useless (sending group 0 from a physical remote doesn't have this side effect). An workaround is to use, instead group 0 of a single remote the group 1 (or any other) of a different remote.
So pretty much the following situation:
Remote 0x1, group 1 -> Light 1
...
Remote 0x1, group 4 -> Light 4 (or even groups from 5 to 8, for FUT089)

Remote 0x2, group 1 -> Light 1, Light 2,.. Light 4

Physical vs. "virtual" remotes
For practical purposes remote 0x2 should be a physical remote (remote 0x1 can be either physical or virtual). There are several reasons for this: yelling at Alexa/Google in the middle of the night to turn on the light isn't the best approach so using the old way of pushing the button is still preferable; case of home automation software failure (from power failure or other reasons), then a virtual remote cannot be used. Also, if using a physical remote, by setting the state topic of the gateway to the one in HA ensures the light and HA are in sync.
The above involves actual pairing of the remotes to bulbs (not merely forwarding from remote 0x2 to remote 0x1 as these commands would take several seconds). The bad news with this is that there is a hard limit of 4 remotes to which a bulb can be associated (adding new remotes erases the old ones on a FIFO basis) so here comes in play state forwarding.

Forwarding
It is possible to forward commands (and states) from a remote to another (it does take about half of second for the command to be recorded by the gateway, published on the MQTT as state, forwarded to the command topic, then issue the command). However, if forwarding from state topic of one gateway to its command topic, then the gateway is knocked out after about 4-5 commands as it enters into a loop (see below: I forward state topic of gateway 2 to command topic, which is the same for all gateways; if I would forward state topic of gateway 1 then after a brief period of time, none of the gateways is online)

I have 3 MiLight gateways, for reliability (in order to cover the entire home as there are some blind spots if using only one remote) set as following. Gateway 1 publishes the state which is used by HA as state for the bulbs. Gateway 2 publishes the state but forwarded only in some cases (based on defined automation).

Gateway 1:
command topic
home/milight_gw/:device_id/:device_type/:group_id

state topic
home/milight_gw/state/:device_id/:device_type/:group_id

Gateway 2:
command topic
home/milight_gw/:device_id/:device_type/:group_id

state topic
sniff/milight_gw/state/:device_id/:device_type/:group_id

Gateway 3:
command topic
home/milight_gw/:device_id/:device_type/:group_id

state topic
no state topic

Other considerations:

• would it be possible for the gateway to send brightness equal to 1 each time the bulb is turned off? By setting brightness to 1 when bulb is powered off there would be a relatively smooth transition so that when turned on again it won't reach full brightness immediately (the bulb turns on with the last setting so case of a power failure the light would turn to full brightness when power comes back if that was the last setting; also, if using different brightness setting for day/sunset/night scenes then when turned on the light would have the setting from the previous mode). I do this now by sending first brightness 1 (then the off command) but wondering if it could be setup on the gateway.
• is it possible to send the effect to bulb with a certain time transition (slower transition) directly? Sending mode and then S- to light does slow down, however wandering if can be set directly at the slower transition pace with a command (at the moment sending slow down from the remote doesn't differentiate in the state published).

[sidoh]

Keep in mind that you can still send commands to group 0, state will just not be kept for it.

The hue/saturation thing can probably be solved for separately. As long as you send the state in one command, it should be possible to send the appropriate command packets to the bulb.

would it be possible for the gateway to send brightness equal to 1 each time the bulb is turned off? By setting brightness to 1 when bulb is powered off there would be a relatively smooth transition so that when turned on again it won't reach full brightness immediately (the bulb turns on with the last setting so case of a power failure the light would turn to full brightness when power comes back if that was the last setting; also, if using different brightness setting for day/sunset/night scenes then when turned on the light would have the setting from the previous mode). I do this now by sending first brightness 1 (then the off command) but wondering if it could be setup on the gateway.

Yes, possible. The request has come up before. It has in the past felt like it's most appropriately solved by some layer above espMH like HASS.

is it possible to send the effect to bulb with a certain time transition (slower transition) directly? Sending mode and then S- to light does slow down, however wandering if can be set directly at the slower transition pace with a command (at the moment sending slow down from the remote doesn't differentiate in the state published).

At least for all of the milight protocols I'm familiar with, it's not possible except by spamming down 10x and then pressing up the appropriate number of times. I implemented this for brightness/color temp for CCT bulbs and it has all sorts of funky quirks.

[PetricaM]

Keep in mind that you can still send commands to group 0, state will just not be kept for it.

Yeap, it works sending group 0 commands. Unfortunately, using group 0 is not logged anymore by the gateway :(

[PetricaM]

On a side note, would it be able to add some new custom fields to state topic? :)

• white_value (used by HA, similar to saturation except completely different :D : high saturation corresponds to low whites, low saturation/high whites);
• modified color temp to match the scale in HA (something like HA ct).

Current version can be used with some custom automation between HA and gateway back and forth:

• for color temp: (((trigger.payload_json.color_temp - 153 )*370)/347) and ((trigger.payload_json.color_temp/370)*347)+153);
• for saturation (((255 - (trigger.payload_json.white_value | int)) / 2.55) and (((100 - (trigger.payload_json.saturation | int)) * 2.55) respectively
  However, it is quite nagging as it require intermediate MQTT topics that add up to the delay of the commands.

[boschr]

This breaking change is really confusing and annoying. Still want to use group 0 to toggle all my groups. I'm not an HA expert, only did some small experimental, this is my situation:

Currently i'm not using the automations.yaml but just the configuration.yaml like this:

light:
  - platform: mqtt_json
    name: XXX
    state_topic: milight/states/0x6F/rgb_cct/0
    command_topic: milight/0x6F/rgb_cct/0
    brightness: true
    rgb: true

It's not clear to me if i still can use this setup.

[sidoh]

Hey @boschr, certainly understand that this issue can cause some frustration.

It's worth stressing that the change also fixed some different behavior that was also confusing and annoying.

Context here, in case you're curious: #318 (comment)

I would welcome any suggestions on how to resolve this in a way that solves both issues. I have some rough ideas, but they're not fully formed, and won't have a chance to pursue them for a little while.

In the meantime, you might consider reverting to 1.7.

[starkillerOG]

@sidoh first of all, thank you so so much for creating the esp8266_milight_hub!!!
Withouth your hard work, I would have never bought milight bulbs because buying a new bridge for every 4 light groups is just not an option, besides your esp8266_milight_hub is a way better bridge.

Since I liked your code for my milight bridge so much, I now have 9 milight bulbs and 3 physical remotes and another 3 virtual remotes that are used by automation software.
My setup is a little bit complicated:

• first off all I use the milight remotes to control non-milight lights
• I have multiple remotes controlling the same light bulb
• I have groups controlling multiple light bulbs at once
• 1 light bulb is sometimes part of up to 4 diffrent groups (this comes from diffrent physical remotes and 1 lightfixture containing multiple milight bulbs that can be controlled individually or all at once, or 2 at once (not wanting the delay off having to switch them one after eachother).

To manage all this madness and actually get the state of each physicall bulb, I wrote my own phython program to parse the commands that are received by the esp8266_milight_hub and sent over MQTT using the "MQTT update topic pattern".

Today I upgraded from v.1.6.4 to v.1.8.2.
First of all, a verry nice inprovement, the status LED and the new frontend is awesom!
Unfortunatly the group 0 updates in the "MQTT update topic pattern" were removed with this PR.
This totally rewens my setup, since I now have no way to receive the group 0 pakkets and parse them in my own programm.

What is verry weired is that I do somtimes get some mqtt messages from group 0, but it is verry unreliable, this only happens with group 0 for me.

I just want a way to get all the pakkets with MQTT that are beeing received by the milight_hub.

@sidoh, could you please please help me out?
Maybe make a setting to enable the old MQTT behaviour where we do get all the messages that are received?
For now I will be forst to revert back to v.1.6.4.

---

Sorry I was wrong in this post, group 0 pakkets are beeing sent to the update topic, just not the state topic. It was just a bug in version 1.8.2, in version 1.8.5 this bug has been fixed and now the update topic handles group 0 pakkets perfectly.

Thanks again for your amazing work on the esp_milight_hub @sidoh, I am using your code to control basically all the lights in my house. You did an amazing job!

[boschr]

@sidoh no problem. As a software developer i understand this kind of situations will happen.

As I told i'm not that familiar with HA. Is there someone who can explain how i can easily solve this problem? Or create a workaround. I tried the solutions of @PetricaM but seems to do nothing.

For example: i created for each room/space an "device id". And each light has its own group. Maybe this is not the best practice? Switching group 0 i want to control (toggle) all the light in one room.

[PetricaM]

Hi,

I see two solutions to the problem.

First involves 5 beers and 2 bottles of wine and at the end all lights will turn to any color of your desire simply by thought. It will be way faster than calling Alexa or Google to set the lights. Don't know how to achieve persistence, tough.

Second solution is to pair the lights in the room to a group between 1 and 4 (not group 0) and use that group ID instead of group 0.

That is either i) keep the current pairing and pair all the lights to a new remote id (either physical or virtual) or ii) unpair all lights (unpair has the effect of reset to factory settings, not remove one remote id) and then pair with any group (from 1 to 4) of your remote.

I'm using three gateways with 1.8.2 firmware (for coverage) and one with 1.6.5 (to sniff packages). Only one of the 1.8.2 gateways publishes states (the command topic is the same for all). I use both physical MiLight remotes (wall and handheld) and virtual remote IDs.

I have decoupled topics (for command and state; I'm not using delta) of the gateways and the lights in HA (see below) and I'm using an automation to forward payloads from command and state topics for 1.8.2 between the two (command to command and state to state). Also, for some remote IDs, state from 1.6.5 is forwarded to command for 1.8.2 (if forwarding state from 1.8.2 to command for 1.8.2 the gateways would enter a loop and would reset). For group 0 state from 1.6.5 is forwarded to groups 1, 2, 3 and 4 of state topic in HA (remember that HA state topic is not the same as state topic for 1.8.2 gateway).

The primary remote ID (set in HA) for each room is in all the cases from a physical remote (so that I can use physical remote to control the bulbs case HA or the wifi are down); B0 is quite nice to use. I have also a B4 wall remote that is paired with all the lights in the house and I can use group 0 on that.

More specific, I have 3 bulbs (A, B and C) and 3 remotes:
Remote ID 0x1 - physical, B0
Remote ID 0x2 - virtual, B4
Remote ID 0x3 - physical, B4

The pairing is as following:

• Lights A, B and C to group 1 of remote 0x1 (B0 has only one group);

• Light A to group 1 of remote 0x2

• Light B to group 2 of remote 0x2

• Light C to group 3 of remote 0x2
  (pairing one light to one group is completely optional and I have done it in order to be able to use scenes similar to Philips Hue, by having each light set to different color. However, it is not proactical to use it for day to day settings as it would take about 1 second for all three lights to turn on; using the group ID to which all three are paired ensures instant on/off).

• Lights A, B and C to group 2 of remote 0x3

In HA the light is set for group 1 of remote 0x1 as following:
Topics for HA:
command_topic: 'milight_gw/0x1/fut089/1'
state_topic: 'milight_gw/state/0x1/fut089/1'

Topics for gateway:
command_topic: 'home/milight_gw/0x1/fut089/1'
state_topic: 'home/milight_gw/state/0x1/fut089/1'

To turn all lights in the room I can use either:

• group 1 of 0x1 (already set) either with HA or with physical remote

• group 0 of 0x1 (not sniffable on 1.8.2 but works with 1.6.5) only from HA

• group 0 of 0x2 - only from HA

• group 2 of 0x3 (each group of remote 0x3 is paired with a different room)

• group 0 of 0x3

States for groups 0 are sniffed by gateway 1.6.5 for remotes 0x2 and 0x3 and then forwarded to group 1 of remote 0x1 (the remote that is set in HA).

I also have a fut088 handheld remote (0x4 - similar to B0 as it has a single group ID) which I haven't paired to any light but I'm forwarding state from the gateway 1.6.5 received for remote 0x4 to group's 0 command topic for remote 0x3 (on 1.8.2). There is a slight delay in the forwarding (if using a physical remote directly paired to the bulbs the change is instant) but it is not a problem.

Please mention if you need specific help with setup.

[boschr]

@PetricaM thank you for your detailed answer. But sounds way to complex to me (except solution 1). I have only one gateway: an ESP8266. The coverage is "not bad", but i agree this can be (much) better.

I don't use any physical device, but sounds like an solution for broken WIFI or if HA give no response for some reason (happends to often). I get tired of to turn on and off the lights every day since the hub is broken (group 0 issue).

[PetricaM]

Hi @boschr ,

Even with a single board you can increase the coverage (a capacitor between GND and VCC and/or a good 5V power supply if using a NodeMCU should help). Also, 1) there are some tweaks for the gateway settings that can improve reliability and 2) HA can resend the same message with a delay of several milliseconds.

In regard of group 0 issues you can simply pair the bulbs with any of the groups 1 to 4 of another remote ID (each bulb can be paired with up to 4 different remotes ID) and change the HA topics to the new remote ID (no change for gateway is needed). As you don't use a physical remote you can generate any remote ID for the new pairing.

[starkillerOG]

@PetricaM I was wondering what kind of capacitor you were using?
Do you only use a capacitor between GND and VCC of the power going to the NodeMCU, or also one between GND and VCC that goes to the NRF24L01+ Radio?

How did you hook up the NRF24L01+ Radio?
from the 3.3V of the NodeMCU, or 5.0V through an NRF24L01 socket adapter such as the one in this link:
https://www.aliexpress.com/item/New-Socket-Adapter-plate-Board-for-8Pin-NRF24L01-Wireless-Transceive-module-51/32714076729.html?spm=a2g0s.9042311.0.0.4cef4c4d3CoYNa

I am also trying to improve my reliability, speed and range of the ESPMilightHub.

[PetricaM]

Hi @starkillerOG

I use cheapest Chinese 4.7 uF electrolytic capacitors and only between the GND and VCC pins of the NRF24L01 module.

I connected NRF to ESP board directly; however, I think the largest improvements came from using good ESP boards (Wemos R1 D2) and from connecting the ESPs to 12V instead of the 5V microUSB.

The NRF boards I'm currently using (for more than 1 year) are from the same batch I was initially replacing them at a rate of 1 per week before deploying the above tweaks.

[jimmyEllis]

Hi, first off i love the hub. I have 8 physical remotes (all T4) in the house to control 18 milight bulbs. One room for example has 8 lights (in groups of 2 lights). Now here comes my problem, when leaving the room i use group0 to on the T4 to turn off all lights. But this way my HA gets out of sync since no mqtt messages are published by the hub for controlling group0 (not for group0 or group1-4). I understand why this is (group0 not being a physical group and syncing this group doesnt allways make sense). Is there a solution for keeping my HA in sync while controlling group0 on a physical remote? I have read solutions on this thread but seems to me these only work when controlling group0 in HA (i could be wrong, please feel free to tell me). Is there any way to let HA know group0 has been controlled from physical remote? I'm not that gifted in HA so it could be i looked over the solution in this thread (or just simply didnt understand it). If anyone can point me in the right direction it would be much appreciated. This is the only problem i have with my lights, for the rest everything is working beautiful. Thanks

[jussbba]

Hello,

It is possible. Check this thread:https://community.home-assistant.io/t/milight-status-feedback-with-nodemcu/17349/75

[jimmyEllis]

Hi thanks for replying, i'm a real noob (sorry). Does this peace of code take place in the firmware of the hub? Sorry if im asking stupid questions but im really lost.

If i understand correctly the code in the link above is a configuration of HASS. Is this allso possible for openhab?
Do you get an mqtt message from the bridge when group 0 is controlled on a physical remote? I dont seem to get any message when controlling group 0.

`
milight/states/0x611E/rgb_cct/1 {"state":"ON","level":100,"color_temp":370,"bulb_mode":"white"}
milight/states/0x611E/rgb_cct/2 {"state":"ON","color_temp":370,"bulb_mode":"white"}
milight/states/0x611E/rgb_cct/3 {"state":"ON","level":100,"color_temp":370,"bulb_mode":"white"}
milight/states/0x611E/rgb_cct/4 {"state":"ON","level":100,"color_temp":370,"bulb_mode":"white"}
milight/states/0x611E/rgb_cct/1 {"state":"OFF","level":100,"color_temp":370,"bulb_mode":"white"}
milight/states/0x611E/rgb_cct/2 {"state":"OFF","color_temp":370,"bulb_mode":"white"}
milight/states/0x611E/rgb_cct/3 {"state":"OFF","level":100,"color_temp":370,"bulb_mode":"white"}
milight/states/0x611E/rgb_cct/4 {"state":"OFF","level":100,"color_temp":370,"bulb_mode":"white"}

`
I get these mqtt messages when turning group0/1/2/3/4 on and then off. so i get messages from group 1-4 but not for group 0. I'm really lost

[starkillerOG]

@jimmyEllis since version 1.8.x of the esp_milight_hub software their are no group 0 pakkets anymore on the states topic. The tread that @jussbba mentioned is based on older firmware for the esp_milight_hub and theirfore this will not work anymore since version 1.8.x. (by the way that piece of code from the tread of @jussbba is supposed to run on HomeAssistant, not on the esp_milight_hub).

The update topic does still provide all commands received by group 0, there were some bugs in the intial release v1.8.1, but since version 1.8.5 the update topic seems to work perfect with group 0 commands. (sorry for my previous post in this tread, the update topic does work my fault, it were just some bugs in the initial release).

But as far as I can see @sidoh just merged a PR that is going to fix your problems @jimmyEllis. I think that PR will make sure that group 0 commands are also updating the states of all other groups that fall under the same ID. Just wait till version 1.9.0 is out of beta and the first stable version is released and then update, I guess that that wil fix you problems @jimmyEllis.

[jimmyEllis]

thank you very much, you made my day. What am i saying you made my month!!! Now (when 1.9 comes out) the wife can use group 0, no more problems. Thanks

[jimmyEllis]

Now i get it! I didnt have a update topic pattern defined in the hub. I did it now and now i get a mqtt message when i press the button for group 0 on or off. Now i can look for these messages in openhab and push the state to groups 1-4. Now all my problems are solved. Thanks again