I don't show 2 but I did get stuck installing this part way thru so deleted device, app, drivers code, & app code then started over. I have rebooted hub since a few times. The MQTT Connect Device does show present.
I just tried restarting the app by clicking thru, turned off and turning on HA MQTT Discovery protocol and even re-booted hub. Still no dice and MQTT Explorer still isn't showing homeassistant in there.
At the beginning of the log page I put in previous post, it says "MQTT> MQTT subscribing to: homie/hubitat-hub-mqtt-beta/+/+/+/set". Should that be pointing to "homeassistant" instead?
Also, can someone post their MQTT Explorer screen that shows where "homeassistant" should appear?
I don't know how it could matter but I did have this Flow that Chris created running on my Pi 4 but never finished it and deleted when I saw that you released your beta.
Let's take this to PM Stephen as we're in the wrong topic anyway.. I'll get in touch there. I'm just going to go through the devices you've enabled to check these are supported by HA.
Sorry you're having an issue - I'll post back the resolution here.
OK an update. Rather than enable devices individually under the capability drop downs e.g. dimmers, switches etc. Stephen was relying on using the 'Everything, all capabilities and attributes' drop down only , which should have worked but actually manifested two issues.
homeassistant doesn't populate.
The devices are incomplete within homie.
This is a a bug on my behalf that I will now look to fix (grateful to everyone who finds these)
So FTTB please enable devices under the individual capability dropdowns.
Please to report then HA discovers devices correctly.... and he's up and running..
I am just getting back to RM variables now. I found a way to get around the residual selections in screen 2 and create the RM Connector Variable from the MQTT app. It did indeed create the subscription and set the value in the connector. I also see it updating the value.
I don't see a way to hook that connector to the RM global variable though, so I can do things like you describe (named access in rules). Is that not a possibility? If not, I am not sure now, how I would use the RM Connector Variable created by MQTT app. Hmm.
That’s what I was musing about here Troy , it’s possible RM loses the connectivity to the variable as a named variable and it becomes retrievable as an attribute value only. I’ll look at this as an exception meaning I would like to support it as a real device created in HE.
Currently you would have to implement it as an exported device within the homie tree that you update the variable value using ..variable/set. I’ll see if I can somehow link that to an arbitrary topic to update from too. I guess the parent connector device handles the association with RM.
Hmm , I'm not sure what you're trying to do that isn't working? It doesn't appear as a 'named' Global var but it's fully accessible and settable from RM.. and can be linked to a named variable should you wish..
MyGlobalVar is a variable created in RM and RMvarOne was created in my app and is linked to an arbitrary MQTT payload.
Thanks @kevin. I missed that approach. I will check that when I can get back to this. Unfortunately, my USB-to-RS485 adapter being used in this solution, crapped out on me last night. So no incoming data until new one arrives.
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!!!
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.
So no incoming data until new one arrives.
), 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.
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.
