I’m chasing my tail attempting to integrate MQTT.
Can someone please explain to me or better yet provide a detailed example on how to integrate an Insteon device, specifically a dimmer, with MQTT.
I currently have MQTT Broker, Generic MQTT Thing and Mosquitto running.
I have had for years Insteon dimmers integrated with openHAB and can control via the UI, the physical switch and even Alexa via Hue Emulation.
I am attempting to now integrate with Home Assistant and it appears that MQTT is my only option.
I have been able to write to the CMD topic via the UI and at one point the dimmer was turning on. HOWEVER I have not been able to get anything into the STATE topic UNLESS I forcefully PUBLISHED it via a script.
It is my understanding, though I could likely be wrong, that the STATE topic should come from the PHYSICAL DEVICE and not from a script.
I hope someone with a far better grasp of this will guide me in getting this to work. I have read numerous post and have tried various things and am getting no where.
I’ve said it before and will say it again. OH does not write to the STATE topic. OH never writes to the STATE topic. The STATE topic is how something else outside of OH tells OH that the device changed state or needs to change state.
So, going back to those data flows I mentioned on the other threads (which is a problem unto itself, you’ve got at least three threads going? Maybe more?):
- HA receives a command to turn on the Insteon Switch →
- MQTT message on the /blah/blah/blah topic →
- OH is configured to subscribe to the /blah/blah/blah topic as the state topic. OH only subscribes to the state topic, never publishes. →
- OH receives the message and commands the OH Item Linked to the MQTT channel →
- the command gets forwarded to the Item linked to the Insteon Switch (perhaps using a rule) →
- command received by the binding and sent on to the actual Insteon Device.
What about the reverse direction?
- Insteon switch changed state →
- Item linked to Insteon switch receives an update →
- state change is forwarded to the Item linked to the MQTT Channel (perhaps using a rule) →
- the OH MQTT binding receives the command and publishes the new state to the /foo/foo/foo topic (different topic from above) which is configured on the command topic. OH only *publishes on the command topic, never subscribes
- HA receives the message on the /foo/foo/foo topic and does what ever it needs to to represent the device’s new state.
Forget about the word “state” and “command”. When configuring the MQTT Channels, mentally replace “state” with subscription and “command” with publish.
- The name of the topics are irrelevant.
- It’s possible and reasonable for OH to have a topic with “state” in it configured for the command topic and a topic with “cmd” in it to be configured for the state topic. Usually OH doesn’t get to dictate what the MQTT topics are.
- There is no magic here. MQTT is a low level binding. You have to configure everything. OH will not automatically publish or subscribe to any of the topics.
I agree with this. It could be I/like/green/bananas and it would work in either channel. I think of the setup as messages I send (cmd) and messages I receive (state). The M in MQTT stands for Message afterall.
I mentioned this before, but to eliminate at least one variable in the messaging format, put this in your configuration.yaml file (and restart HA):
# Example configuration.yaml entry
It publishes every state change in HA to MQTT. Turn your lights on or off and go to MQTT Explorer and find the message. All the messages coming from HA will have the defined format looking something like this:
Find the message in MQTT explorer and use that in OH as your state topic (MQTT Explorer has an easy copy function, just select the line “state”). If it isn’t there you aren’t publishing correctly from HA, maybe something about your MQTT setup (config in HA).