Problem with controller not changing the state of the home assistant entity

[roydestroy]

Hello everyone!

I have successfully paired the hub and the controller to the mqtt topic (I have even unpaired the controller and have it only work through the Home Assistant automation (MQTT Forwarder). The lights are working in both cases (Both when I toggle them throught the hub via home assistant and when toggling them through the CCT controller). The only problem is, if I toggle for example the lights off through the controller, even though the lights do successfully turn on or off, the state of the entity in Home Assistant does not change.

This is the automation I am using

`alias: MiLight Forwarder
description: ""
trigger:

• platform: mqtt
  topic: milight/updates/0x45F/cct/+
  condition: []
  action:
• service: mqtt.publish
  metadata: {}
  data:
  topic: milight/commands/0xC9A6/cct/{{ trigger.topic.split('/')[4] }}
  payload_template: "{{ trigger.payload }}"
  retain: true
  mode: single
  `
  Here are the outputs

{"firmware":"milight-hub","version":"1.11.2","ip_address":"192.168.1.27","reset_reason":"Software/System restart","variant":"d1_mini_PRO","free_heap":18568,"arduino_version":"3.1.2","free_stack":1520,"flash_used":13303,"flash_total":957314,"flash_pct_free":98,"queue_stats":{"length":0,"dropped_packets":0}}

{"admin_username":"","admin_password":"","ce_pin":4,"csn_pin":15,"reset_pin":0,"led_pin":-2,"radio_interface_type":"nRF24","packet_repeats":50,"http_repeat_factor":1,"auto_restart_period":0,"mqtt_server":"192.168.1.42:1883","mqtt_username":"","mqtt_password":"","mqtt_topic_pattern":"milight/commands/:device_id/:device_type/:group_id","mqtt_update_topic_pattern":"milight/updates/:device_id/:device_type/:group_id","mqtt_state_topic_pattern":"milight/states/:device_id/:device_type/:group_id","mqtt_client_status_topic":"milight/client_status","simple_mqtt_client_status":false,"discovery_port":48899,"listen_repeats":3,"state_flush_interval":10000,"mqtt_state_rate_limit":500,"mqtt_debounce_delay":500,"mqtt_retain":true,"packet_repeat_throttle_sensitivity":0,"packet_repeat_throttle_threshold":200,"packet_repeat_minimum":3,"enable_automatic_mode_switching":false,"led_mode_wifi_config":"Fast toggle","led_mode_wifi_failed":"On","led_mode_operating":"On","led_mode_packet":"Flicker","led_mode_packet_count":3,"hostname":"milight-hub","rf24_power_level":"MAX","rf24_listen_channel":"LOW","wifi_static_ip":"","wifi_static_ip_gateway":"","wifi_static_ip_netmask":"","packet_repeats_per_loop":10,"home_assistant_discovery_prefix":"homeassistant","wifi_mode":"g","default_transition_period":500,"rf24_channels":["LOW","MID","HIGH"],"device_ids":[51622],"gateway_configs":[],"group_state_fields":["state","status","brightness","mode","device_id","group_id","device_type","color_mode"]}

Can you please explain to me what I am doing wrong?
Thank you in advance!

[garmck]

Why dont you use the same device ID from the controller in the MiLight hub?
You wont need an automation in that case.

[roydestroy]

I tried that just now, but since the controller only sends the commands to the lights and not to the hub, the hub's state won't update. So I still do not have the ability to have the states change both when using the hub and the controller in Home Assistant

[ristomatti]

It should update. You'll need to run the sniffing mode, toggle something with the remote and take a note of the remote's device id. Then add create the device alias, fill/pick the settings in this order:

[markg85]

I figured it out (again).

In your MQTT settings of this milight hub you have:

This is important!

In home assistant in the MQTT integration this hub advertises:

So in my case it looks for state values (that includes updates) in milight/states/0x3/fut089/2.
Any light change i do doesn't end up in the state topic! It ends up as incremental update in the updates topic! So the topic home assistant looks for never changes state thus light switches won't either.

A, perhaps temporary, fix is to let states and updates both go to the states topic. That does fix the state for me in home assistant.

There are possibly 2 bugs

1. The state topic should update with the new value too. Currently incremental updates are only in the updates topic. This, as a side effect really, already fixes home assistant integration but i'm not sure if this is a real fix.
2. When reading the home assistant docs it seems to me that the state_t value should be the updates topic instead. But this is just an assumption on my part based on the sparse info i could find on it.

@sidoh, could you have a look at these?

[sidoh]

probably the same issue as this one #827

@markg85, state is the correct topic. HomeAssistant expects to receive the full state. The issue is HomeAssistant keeps messing with the schema for light.mqtt. They have made breaking changes to this schema like 4 times since I started this project.

I probably won't get around to this for a while. If anyone else wants to take a stab at it the relevant files are:

https://github.com/sidoh/esp8266_milight_hub/blob/master/lib/MiLightState/GroupState.cpp (this is where internal state is formatted as json)

and potentially

https://github.com/sidoh/esp8266_milight_hub/blob/master/lib/MQTT/HomeAssistantDiscoveryClient.cpp (this is where mqtt discovery messages are sent)

probably there needs to be a new field which matches the name and format homeassistant expects.

[markg85]

Am i looking at the wrong place?
light.mqtt has no stat_t, it does have a stat_topic https://www.home-assistant.io/integrations/light.mqtt/#json-schema which is described as The MQTT topic subscribed to receive state updates. hence my thought that it should point to the updates topic instead.

But the mqtt integration plugin does have a stat_t but no description of it that i could find.

If you can provide me with the pointers to base things of the right information then i'll have a stab at this. I just bricked my esp that was handling my lights so i need to do some work on this anyhow now :(

[sidoh]

Sweet!

I think you're looking in the right place. HomeAssistant supports a bunch of abbreviations (reference), which helps keep the MQTT messages from getting too enormous.

light.mqtt has no stat_t, it does have a stat_topic https://www.home-assistant.io/integrations/light.mqtt/#json-schema which is described as The MQTT topic subscribed to receive state updates. hence my thought that it should point to the updates topic instead.

It's a fair guess, but I don't think HASS attempts to keep track of state (nor should it). The updates topic is a fairly direct translation of the raw packets sent to the bulbs, and some state updates include multiple packets (e.g., color can involve hue and saturation).

I haven't looked closely at exactly what the issue is, but it looks like the discovery client is advertising capabilities using now-deprecated syntax (it honestly drives me nuts that they make so many breaking changes to this schema).

For example, looks like I'm using a collection of boolean flags, eg:

https://github.com/sidoh/esp8266_milight_hub/blob/master/lib/MQTT/HomeAssistantDiscoveryClient.cpp#L115

config[F("rgb")] = true;

and according to docs, this should be something like:

// short for supported_color_modes
JsonArray colorModes = config.createNestedArray(F("sup_clrm"));

// Flag RGB support
if (MiLightRemoteTypeHelpers::supportsRgb(bulbId.deviceType)) {
  colorModes.add(F("rgb"));
}
// same pattern for other color modes

[markg85]

So, i've got an update here. And i don't understand how/why...

As i reported above (and i think a couple months earlier too), the states topic in some cases isn't being updated with light changes. In the settings page when i submit them, i all of a sudden get state updates inside states again.

Note that i left the updates channel alone and in it's separate channel.

Now everything works as expected.
WHY? How? I don't get this....

Which code triggers a state update (in the states channel)?

[sidoh]

It's here:

https://github.com/sidoh/esp8266_milight_hub/blob/master/lib/MQTT/BulbStateUpdater.cpp#L39

I'd check serial logs if it's still happening.

[ristomatti]

It's frustrating how often HA breaks MQTT related integrations. I think they're moving too fast. It's great to get new features but for something like this, stability should be the key IMO.

@sidoh This project has been a core part of my home automation for so many years. Thank you so much! While I have a few Milight lights, I primarily use ESP8266 Milight Hub just for the great remotes Milight sells, to control LIFX lights via Node-RED. It took one evening to map the MQTT messages to the format used by node-red-contrib-node-lifx which I took the responsibility of maintaining. It just hasn't really needed any maintaining. Node-RED team is careful not to break things, LIFX LAN API has stayed the same since the start and so has this projects. Everything just works, year after yeer! I've since setup Home Assistant and use it for various things, but to this day I've kept using the same setup for controlling lights and I'm planning to do so for a long time. 🙂

[sidoh]

Should be fixed in the 1.12.0-beta1 build. Can I get some folks who were having trouble with this to try it out?

[gatd]

Hi could someone please help me
I have the latest 1.12.0 beta1 i have followed all the instructions but cant get this working the remote controlls the lights fine
on sniffing my remote Device id is 005B and the request type is B8
I created a new device id 0x005B and selected remote type FUT089/ B8 in the hub
trouble is it doesnt work ie wont control the lights from the hun and homeassistant does not update the light status when using the remote.
your help would be greatly appreciated
thanks

[Jojo-1000]

Not sure if this is related to your problem @gatd
What I noticed is that when I specifically use the group 1 on the remote to control the light, it is updating correctly both on the hub website and on home assistant. But, when you use group 0 (all lights), none of the configured lights has a state change.

The way to switch between controlling one or all is using the numbered on/off switches instead of the big ones on the remote. After that, the commands are only sent for the last used group.