Yes, although it is a raw format I prefer this to an external program (not having to re-install on OS upgrades or host changes).
You should have at least two topics for each light: one for command and one for state. I suggest monitoring both topics and then do the tests turning on the light from HA and then from the remote and see what gets posted to each topic (one at a time). Basically one event from HA (on/off/change brightness/ect) should translate to one MQTT payload in command topic and one in state topic. If there are more payloads in either topic should investigate where those came from (probably some zombie forgotten automation).
Having this behavior would mean that either both lights are sharing the same topics for commands and state (unlikely based on your posting of setup) or all the messages in the MQTT broker get deleted immediately after a new topic is posting (try the retain: true flag mentioned below).
Here’s my config. The difference compared to yours (except for bulb type) are the last three: qos (it is 0 by default anyway thus it shouldn’t be a problem), retain (so that when the MQTT broker or HA losses connection and reconnects the last state would be loaded) and optimistic (although I have the state topic defined I still use optimistic mode so that HA considers the light bulb already acknowledged the message even before receives the payload on the state topic).
If it still doesn’t work post here also the payloads for each command and state topic.
What fields did you select in the State group fields in the MQTT menu of the gateway?
When using physical remote, nothing shows up on command topic but when I turn on the light from HA it publishes the following: { “state”: “OFF” } / { “state”: “ON” }. (I still used MQTT lens because I don’t know how to use “d” flag method)
Is this correct behaviour?
Anyway, turning off a group with physical remote sends data to last state topic “used” even though I am turning off some other group (behavior I mentioned in previous post). And this only happens with physical remote. Turning off a group from HA publishes data to right states topic
Thanks!
Ps. I also added retain, optimistic, qos but it is still not working.
I have selected the following fields in the MQTT menu (both gateways):
And the state_topic and command_topic for the light in HA match that format, right?
(milight/0x1111/cct/1 and milight/states/0x1111/cct/1 respectively)
The -d option for the mosquitto_sub command prints the entire topic (not only the payload).
I tried putting states topics to both gateways. Other one (1.8.5) is sending off command to the right topic but 1.6.5 is sending off command to last topic used.
Well, I think there’s something wrong with the MQTT topics on the gateway (1.8.3): I made a minor change to the topics names and afterwards the state topic did not show any messages.
I only managed to get it working by restoring config from another gateway…
Hello guys
I have the same problem. Control works great out of box but brightness nor color temp is not updating.
Has any of you solved it yet?
My setup is MiLight ESP gateway 1.9.0-dev6 (nodemcuv2) and Home Assistant
0.86.3 running in Docker.
Thanks
Exception in state_received when handling msg on ‘milight/states/0x660C/fut091/0’: ‘{“brightness”:89}’
Traceback (most recent call last):
File “/usr/src/app/homeassistant/components/mqtt/light/schema_json.py”, line 203, in state_received
if values[‘state’] == ‘ON’:
KeyError: ‘state’
Hello Petrica
I do not remember exactly and I’m not at home to check but I think it was status, brightness, color_temp and color.
Problem is that when say brightness is changed only brightness is listed in the state message and not the other three. So I wonder if HA is expecting always all four listed?
When I’m back on weekend I will try downgrade the firmware to see if that would work.
Thanks
I think so (or, at least “state”:“on/off” would be needed). I haven’t yet updated to 1.9.x on the gateway, however, until now, on a working config, I didn’t see any payload without the “state” field in the state topic.
@filiplaznicka Did you find a solution to this? I think I am having the same issue.
If I use HA interface everything works properly and updates correctly even though I am getting errors in HA’s log
2019-02-20 11:48:48 ERROR (MainThread) [homeassistant.components.mqtt.light.schema_json] Exception in state_received when handling msg on 'milight/updates/0x2DA5/rgbw/2': '{"hue":105}'
HomeAssistant Heart-Of-Gold Traceback (most recent call last):
HomeAssistant Heart-Of-Gold File "/usr/src/app/homeassistant/components/mqtt/light/schema_json.py", line 208, in state_received
HomeAssistant Heart-Of-Gold if values['state'] == 'ON':
HomeAssistant Heart-Of-Gold KeyError: 'state'
HA will update on/off but not hue nor brightness.
I am using 1.9.0-dev7
I have tried downgrading to 1.8.5 with no difference
I have disabled the automation I had in place to sync the remote but the remote still seems to be syncing on and off and generating the same errors for hue and brightness which is confusing me greatly.
my device setup is as follows
- name: "Office Ceiling"
# The command topic is derived by substituting real values for the
# tokens in the setting mqtt_topic_pattern (e.g., "rgb_cct" for ":device_type"):
# ______________ Device ID
# | ________ Device Type
# | | ___ Group ID
# | | |
# v v v
command_topic: "milight/commands/0x2DA5/rgbw/0"
# This is the same structure as above, but for the setting
# mqtt_state_topic_pattern. esp8266_milight_hub sends state updates
# to this topic.
state_topic: "milight/updates/0x2DA5/rgbw/0"
# Use a YAML anchor for common settings so we can just reference
# them for other lights.
<<: &MILIGHT_PARAMS
platform: mqtt
schema: json
# Colour changing bulb
rgb: true
# Dimmable bulb
brightness: true
# True the light will be an ordinary button in HA - false it will a toggle button
optimistic: true
# Quality Of Service - 0 = At most once, 1 = At least once, 2 = Exactly once
qos: 0
# Should the state be sent out to subsquent subscribers
retain: false
# Without this google fails to change the lights to white
white_value: true
color_temp: true
effect: true
effect_list:
- white_mode
- night_mode
- 0
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- name: "Office One"
command_topic: "milight/commands/0x2DA5/rgbw/1"
state_topic: "milight/updates/0x2DA5/rgbw/1"
<<: *MILIGHT_PARAMS
- name: "Office Two"
command_topic: "milight/commands/0x2DA5/rgbw/2"
state_topic: "milight/updates/0x2DA5/rgbw/2"
<<: *MILIGHT_PARAMS
- name: "Office Three"
<<: *MILIGHT_PARAMS
command_topic: "milight/commands/0x2DA5/rgbw/3"
state_topic: "milight/updates/0x2DA5/rgbw/3"
- name: "Office Four"
<<: *MILIGHT_PARAMS
command_topic: "milight/commands/0x2DA5/rgbw/4"
state_topic: "milight/updates/0x2DA5/rgbw/4"
on the esp I have
MQTT topic pattern
milight/commands/:device_id/:device_type/:group_id
MQTT update topic pattern
milight/updates/:device_id/:device_type/:group_id
Group state fields
state, status, brightness, hue, color, mode, color_temp, bulb_mode
I have tried several combinations of group state fields but nothing seems to make any difference
I feel I am almost grasping what it going on but just not quite
Thanks