Is your MQTT published data being created by your own implementation - if so perhaps you could (additionally) publish to /homie..../set topics too ?
Unfortunately (or fortunately 
), the impl publishing was not written by me, but I do have the source. Source code is C, which is not my strong language, so haven't wanted to edit it yet. Especially since it is working as I need. I do have some config I can alter to set the initial MQTT tree root node name.
In case your curious what your app is being used for, its a pool automation solution. (I'm sure you gathered that from the MQTT node names.)
Essentially:
Jandy Aqualink <-> RS485 serial <-> RaspPi <-> daemon software that reads/writes Jandy protocols and publishes/subscribes MQTT <-> Mosquitto <-> Hubitat <-> your MQTT app.
This is providing me the full pool automation I desire from Hubitat.
BTW...I did bail on the virtual thermostat usage from MQTT app. I simplified my devices to a temperature sensor and two switches for each physical heating device. This kept MQTT app simple, since it seems solid with those two virtual devices. I then used RM to bring changes from those individual devices into a virtual thermostat. Still reconsidering the virtual thermostat use here as well, but its a very close fit for those physical heating devices.
Well I'm glad it's working and thanks so much for the coffees - much appreciated.
FTTB I would be cautious in using virtual devices with multiple 'boolean' attributes or even those with multiple attributes beyond a 'boolean' and a 'level'. There aren't many of these fortunately.
I think it's mainly my editor that is messing up topic values and maps - placing them in the wrong data value. Certainly steer clear of Omni and Thermostat devices. I'll get these fixed over time - I might hide these virtual devices temporarily in beta 2 until they work correctly.
Thank you @kevin for your awesome app! It has been working really well publishing my devices to MQTT. I've been trying to set up the virtual MQTT device to control my garadget garage door control, but I'm having issues and it doesn't control the door or get status. I believe it is because of the json for the garage door opener, as I believe you mentioned that above that json support would be coming for the virtual device.
Attached are some pics of the set up just incase I configured something incorrectly. Love the app!!!
Garadget MQTT Documentation:
https://community.garadget.com/t/mqtt-support/3226/5
MQTT Explorer:
Virtual MQTT Configuration:
GarageMQTT Device Page:
GarageMQTT Logs:
That'll be it I'm afraid - I currently don't parse json payloads, and unfortunately because there is other content in the json you couldn't paste the whole value in either
I see where you're going with this 
Curiously I was just looking at another device on my MQTT broker that posts json payloads that I'd like to get into HE... I do intend to support json but it's not imminent either.
I don't know if you could kludge it via bringing the json into a variable using my app and then extracting the required value with RM (or more likely WebCore) ? Or if you use NodeRED you could split the json and repost to MQTT as individual payloads which then would be useable in my app.
BTW - just looking at the data in your device you have attributes with the same MQTT topic. The two _Topic and _Cmd ones. Only one of these will update (receive the data). This maybe my editor that has duplicated these data values - its a bit quirky currently. I'm working on that for beta 2 but it's still likely each attribute will need a unique topic. As you will gather this also overlaps with json because several attribute values can be sent in one payload / topic, so I will need to provide an ability to handle this too.
Just as a teaser - beta 2 will be a lot faster in reacting to /set commands and instructing the device to update. Over twice as fast - thanks Andy for testing. The state update back to MQTT will be correspondingly faster too but still happens only when the device reports it has physically changed state so varies based on the device involved.
Great ideas! Thanks for the reply! I have the garadget working in homeassistant through mqtt. I may try and split it up like you suggest.
I also tried grabbing the "cover" (garadget) from the Home Assistant Statestream on the 3rd page of your app, but it had issues bringing it over. It successfully saw it as a cover, but it didn't work. I will have to try and set it up again and provide logs.
I went through the process of adding the garadget as a cover from home assistant statestream, however it doesn't work properly. The logs show it as an unrecognized device and set it as a shade. I tried changing it to a virtual garage door, but that didn't work either.
Just wanted to provide some follow up as I mentioned it above.
I've noticed that when I restart home assistant, all mqtt devices from HE become unavailable. I fix, I need to open the MQTT app in HE, and click next through the pages, then it spins for a while, returns me to the HE app screen and everything comes back in home assistant. Any ideas?
@andrew2 In configuration under MQTT Publish Formats there’s a drop down labeled
Home Assistant MQTT Discovered Topics
Set it to ‘Remember’
@hovee - I built the cover implementation based on an IKEA blind published from HA - it discovers and reflects status fine in HE but...I may have not finalised this until beta 2. You might have to wait a short while .. I have not implemented an HA automation script to control the cover from HE (back to HA) however yet.
Ah yes that works. Thanks!
That makes sense! I’ll try and get it working by splitting stuff up for the time being. Appreciate all the work you’re doing!
I have a feature request... Audio Zones.
I have written a python driver and flask API for a Monoprice 6-zone audio system (I have 2 stacked for 12 zones). I'd like to make this thing support the homie3 schema and bring it into the HE via your MQTT app.
Here's the JSON I generate for zone 21 (unit 2, output 1) to give you an idea of all of the attributes for each zone:
{
"21": {
"balance": "10",
"bass": "14",
"dnd": "00",
"keypad": "01",
"mute": "00",
"name": "Office",
"pa": "00",
"power": "01",
"source": "06",
"sourcename": "Sonos",
"treble": "13",
"volume": "05"
}
}
This would be pretty easy for me to convert my python app into a daemon that supported MQTT/homie3.
A zone is an output, which can be modified. Notice there is an attribute for the source and sourcename. There are 6 total inputs, but there's nothing on these that can be modified settingwise. So I don't think I have to publish inputs to mqtt. I could just say that $source is an integer between 01-06.
I was going to write an HE app that talked to my flask-based API for this, but I would rather do this via MQTT and python.
My lighting bridge publishes to homie3/lt2000/. I would presumably just publish this to homie3/mp6z/. Or, is that not possible for the app to have multiple homie3 devices right now?
The app only imports from one other homie device currently home/device...
Is homie3 a sub topic (device) of /homie i.e. /homie/homie3 ? homie 3 is not a valid root level topic. Perhaps you could implement this currently as nodes within your parent device though. homie/homie3/mp6z-nodes
It is likely that I will support multiple homie top level devices shortly as subscribes and publishes 'mostly' work already if you configure them (or even change the discovery topics after completion). Just not the startup wildcards. In beta2 subscriptions are made to individual enabled devices (as mentioned above) for both HA and homie rather than relying on wildcarding so that effectively enables devices in other topics (as long as I create the /set topic subscriptions).
If you do propose a homie AV topic make sure that it is complete and well thought through to encompass not just your own device and it's nodes , capabilities / attributes but all such devices such that it is useful as a template for others.
Then it makes sense to homie discover such a device and import it into the HE AV capability (virtual AudioVolume) and possibly others. There is not a HE virtual driver for zones as such. An AV amp would comprise multiple capabilities
Otherwise the best approach would be to treat it as a custom 'zones' device and import it manually. Which device driver(s) would you use for such a device ?
Sorry, I meant to say "homie" as the top level topic, not "homie3". My lighting controller is under "homie/lt2000". I wanted to put the audio controller under "homie/mp6z".
As for the audio control on HE and required drivers for it, the main thing I need is to be able to change the input on individual zones, and the volume. For now, I don't care about the rest of the stuff, but it would be nice to have at some point. I also have a rackmount AM/FM radio that is controllable over serial, and was thinking of making a serial->MQTT bridge for this also.
@kevin Understood that Thermostats aren’t supported yet. Just wondering if they will be and if so any timeframe? Love to get my aircon into HE from HA.
It's on the ToDo but not at the top yet - I just want to ensure HE/MQTT is solid and then pay some attention to HA <> HE
You can import the individual 'climate' payloads already into HE via virtual device if you only need limited functionality, like on/off or temperature change.
@kevin First off thanks for the great work on this. I have HE -> MQTT -> HA working and I can see my devices from HE in HA and can control most of them from both ends. The only one I can't seem to control from HA is my Zwave connected August Lock. I can see the lock status and lock the door however I cannot unlock the door from HA over MQTT to HE. New to MQTT and HA but thought I'd see what the expected behavior is.
Thanks Huy, glad it's working for you - tell me in the first page configuration do you have this enabled ?
It might just be the security restriction..
Someone has reported the MQTT status not updating when a lock is manually unlocked/locked - are you seeing that too ? I don't have any locks to check against.
