Open monkmad opened 3 years ago
You should not receive (discover) a device from HA statestream and then republish it back from HE to be discovered by HA using the HA Discovery protocol. The statestream feature does not support commands and the automations are provided to supplement this by adding such a capability - not via the homie/.... topic structure.
I will be with you shortly to assist - just finishing up something. What I would say is that the next beta has HA Discovery directly into HE which you may find more useful. It does away with the automations for 'supported' devices.
Thank you for your response @GledholtHall
It seems I had things backwards:
So, here is how I thought it works:
Looks like this is not correct. Is bi-directional control even possible? Meaning, the devices are mirrored in both systems (HA and HE), and regardless of origin we can control either copy of the devices?
Sorry.. I am also xAPPO - the author of the MQTT app.
Is bi-directional control even possible? Meaning, the devices are mirrored in both systems (HA and HE), and regardless of origin we can control either copy of the devices?
Yes
The way it works is HA provides 'status' of its own devices to HE via the statestream topic - however statestream has no ability to send commands back to HA for these devices as statestream doesn't support that. Virtual devices are created in HE from the statestream info. Instead automations are installed on HA that listen to certain topics (within statestream) for commands from HE and when triggered these change the state in HA. The homie/.. topic is not used at all.
For HE originated devices you enable them to publish to MQTT and their status will be published in the homie/... topic tree and a command topic ending in .../set is also subscribed to by HE so you can control these devices via MQTT. You can also enable HA Discovery to the appropriate topic. This sends a configuration message (that HA listens for) that details what the device is and how it can be controlled by providing references to the topics HE is sending within the homie/.. tree. HA then automatically creates a devices and starts subscribing to these homie/.. topics
So yes you can create 'virtual' devices at both ends for your devices - a real device in HA with virtual in HE or a real devices in HE with a virtual device in HA. Control and status should be in synch from both ends but you will need automation script(s) installed on HA for the HE to HA device control to work.
In the next version it can also be implemented slightly differently with no automation scripts required. You install an addon within HA that automatically provides the HA Discovery information to MQTT and hence to HE. This then allows HE to control the HA device directly. If you wish I can point you to the repository for the next version as I am not going to make any changes to this beta 3d version even if there are bugs discovered. Please email me on hubitat@gledholt.com for the link. I think beta3e will make life easier for you.
Here is the HA addon I am referring to - it is not authored by myself and is limited to the supported devices he has implemented.
https://community.home-assistant.io/t/mqtt-state-stream-to-mqtt-discovery/258591
Some types are still being worked on - please don't say it's a climate device you're trying with !!
Thanks again, your explanation makes it clearer. I did not realize that statestream was being utilized by HA and HE for publishing device states and commands. 👍
Also, it looks like I need to move to the next beta version, mine doesn't have some of the options shown in the screenshot above. Sending you an email.
@GledholtHall With your suggestions, I have got beta3d in a better state, while I wait to upgrade to beta3e. However, I seem to have found another issue. The HE MQTT App is not showing all the statestream devices published by HA, many of them are missing. It seems to be under multiple device types. I've checked switches, lights and sensors so far. I haven't been able to decipher a pattern or order yet. Please let me know how to troubleshoot this one please. Thanks
The devices that are 'missing' probably do not have complete information provided by HA that is needed to recognize them. IIRC I am using device_class
and friendly_name
and the former is the most likely missing. I wouldn't worry too much as beta 3e can use more information to add devices into HE. I'll check my emails and send you a link to that version.
Hi,
I installed beta3d and am trying to connect HomeAssistant and Hubitat. I've followed the setup instructions, including deleting the Child Device and restarting Hubitat. Messages from HA to Hubitat seem to work fine, under the hastatestream topic I setup in HA config. However, messages from Hubitat to HA, while working, do not seem to follow the same topic structure as the (HA --> Hubitat) messages. Specifically, if a switch device originates in HA, named "TestDevice", the statestream message topics are of the form:
<HAStateStreamPrefix>/switch/TestDevice/state/...
However, message topics for the same device (after configuring it in Publish HE Devices, and in Virtual Devices) are if the form:
homie\hehubname\TestDevice\onoff
with a payload of true or false (corresponding to on or off actions).As you can see, this structure breaks the automations provided in the repo (automations.yaml), because they expect second subtopic to be "switch" and not "hehubname". Moreover, this topic also restricts the possibility of one automation to handle all switches, or lights, as the device type is not in the topic at all.
I am using a tool to connect to Mosquitto server, and view ALL messages being sent back and forth, to ensure I'm not missing a topic. I've also tried all combinations of options under the message format page in the Hubitat MQTT app (like homie publish, complete and compliant, HA MQTT Discovery et al), but no matter which combination I try, the message topics are always of the
homie/...
format, without device type in topic.Any suggestions are welcome. Please let me know if you need more details about my setup.