This is OK - the homie topic structure is somewhat fixed and requires a number of payloads to be present for discovery to work.
You will have to use the second page 'Virtual MQTT Data' of the app and add virtual device(s) to take the payloads in from your devices. This is usable for any payload (except json formatted) but it's the more advanced of all the options. It is f) in the read me.
That should be fine.. it's two of my drivers that mustn't be installed at the same time as they would then use duplicate clientID's. If there is an issue then please create one on github. Concurrency in even a single driver is possible , and only a reboot will remedy that. The logs with duplicate messages would indicate to you that two concurrent threads might be running
I can see where some awkwardness might be coming from though, by it's nature an MQTT connection is essentially constantly running a 'parse' loop. Once running happily it's fine and so it's not so apparent to me with the app resident to pickup these new installation issues. At install I launch straight into this loop and so the 'save' does not complete as such. I could and probably should install to a disconnected state.
I'll remove completely and install on one of my other hubs on Sunday evening when I get back in.
Ok I've tried multiple times with complete deletes of driver and client and reboots in between. I'm getting the same install failure as ccoupe had above.
The add virtual device screen stalls at adding the virtual device, I waited longer than 10 minutes. But it does create the device.
If I try to complete the rest of the installation as per the instructions it never connects per the logs
dev:9362020-01-25 10:53:18.717 pm infoMQTT> MQTT connect failed attempt:[null], try again in 10 secs
dev:9362020-01-25 10:53:17.717 pm infoMQTT> Connecting as Hubitat_temporary to MQTT broker null
dev:9362020-01-25 10:53:17.714 pm infoMQTT> MQTT> client beta 1 initialising
dev:9382020-01-25 10:53:15.825 pm infoMQTT> MQTT connect failed attempt:[null], try again in 10 secs
dev:9382020-01-25 10:53:14.822 pm infoMQTT> Connecting as Hubitat_temporary to MQTT broker null
dev:9382020-01-25 10:53:14.820 pm infoMQTT> MQTT> client beta 1 initialising
app:8142020-01-25 10:53:14.284 pm infoMQTT: ================== Startup complete ==================
app:8142020-01-25 10:53:14.283 pm infoMQTT: [1] Total Hubitat endpoints enabled on MQTT
app:8142020-01-25 10:53:14.281 pm infoMQTT: [0] Total Hubitat devices are enabled on MQTT
app:8142020-01-25 10:53:14.215 pm infoMQTT: ==================================================
app:8142020-01-25 10:53:14.211 pm infoMQTT: Initialize exit
app:8142020-01-25 10:53:14.194 pm infoMQTT: Skipping homie MQTT discovery
app:8142020-01-25 10:53:14.190 pm infoMQTT: HE device publishing to MQTT has completed in 0 secs
app:8142020-01-25 10:53:14.135 pm infoMQTT: Resynch MQTT device states and HA discovery topics
app:8142020-01-25 10:53:13.933 pm infoMQTT: Starting HE device publishing to MQTT for 0 HE devices with 0 attributes
app:8142020-01-25 10:53:13.752 pm warnMQTT: All discovered devices forgotten
app:8142020-01-25 10:53:13.684 pm warnMQTT: All atomicState devices cleared
app:8142020-01-25 10:53:13.570 pm warnMQTT: Deleted all discovered child devices
dev:9362020-01-25 10:53:13.562 pm infoMQTT> Log Level set to 2
Mike
Sucess story with Kevin's MQTT app, a free review from me
tagging @bravenel for sharing the good mood.
If you read my first post on HE, 5 months ago, I was looking for solutions.
I'm in Home-Automation since forever. And I have plenty of modbus (industrial) plc's in my home to control... everything but lights and motion. That's the reason I came for HE. And I'm happy of it
But I realize very quickly that HE supported devices were not including modbus devices 
5 months, adding sensors, lutron caseta (very nice choice for an old house), you know the usual story. Same for everybody.
2 concurrent home-automation systems running in parallel. Nice people here, friendly and ready to help. @cybrmage (thanks again) reprogrammed an existing (but non functional) app for my Venstar thermostat !
I learned a lot here, discovered node-red (but I'm not - for the moment - a Raspberry Pi guy) but was always stuck with my lonely devices.
And then Kevin came with his alpha MQTT App 
Of course, asked to be part of the alpha.
Since then, I was able to learn more about MQTT (mosquitto with 2 T's) and the way it works.
Now, with his help (he always replied quickly to my newbie requests) and Installed a running MQTT app that send data to HE, extracted from my [no more alone] devices !!!
I have now important data coming from my plc's (energy of my house and my geothermal unit, temperatures of coils, air blowers and water loops), no need to launch Internet Explorer (...) to see values from my plc's. And I can now deploy rules with values harvested from my hvac system.
Thank you again Kevin and enjoy your coffees !
I’m not at my PC now but it looks like you don’t have an IP address for your broker entered in the MQTT driver.
I just went through another complete remove and replace of the device/app/driver and now it connected.
Mike
If you read above you can see it could be an issue that I will take a look at tomorrow evening. The stall happens I think because I’m launching directly into a maintained loop connection. Everything saves OK though.
The app doesn’t pass the IP that is configured directly in the driver, but yours shows as null. It does pass the hub name however. Do you or have you had two drivers installed ? Make sure there is only one. I would also try a reboot and configure the driver again as maybe there are two instances running. The log says the broker address field Is null
Apologies.. This is obviously something I need to improve .. I’ll take a look tomorrow.
I found a null in the mqtt topics! How do you get rid of a retained topic named null?
With MQTT Explorer.
Yes MQTT Explorer is the easy way... that's the 'null' name of the hub from the first time the driver didn't run correctly. You have a temporary tree that you can delete too. Mike might have these too. They do no harm - just untidy.
Very impressive!!
I also had failures to connect last night and then this morning, but after a series of forced hub reboots it finally connected.
Unfortunately it appears that this and OpenMQTTGateway don't play well. It claims to make HA discoverable devices but the 9 Mi Flora's were not found with this. I could try and edit it to tweak the data output, but given that my ESP32 testbed keeps rebooting and I lose my whitelist and it starts hitting medical devices I'm going to shelve it and just run that python script on my Pi. It supposedly uses Homie so I hope this works better.
This app does not support HA Discovery into Hubitat. I support statestream from HA into HE and HA Discovery from HE into HA. I may look at adding this in the future though. You would be able to manually import these devices should you wish.
This helps me accomplish everything I've wanted to do! Generally speaking, that's piping things through node-red for various reasons. Importantly, controlling custom displays and using custom interfaces.
I had a bit of difficulty connecting with mosquito. I'm not sure exactly what the issue was, but after rebooting HE it was fine.
Yes it seems to be an issue for new installs. Updates don’t experience this. A reboot after install fixes it for the time being but beta 2 should too.
@kevin: current Beta 1 seems to be having issues with updating from HA StreamState (at least for presence)
Didn't see anything in the logs really but the one odd thing I saw was in the client driver the "Subscriptions" is showing -7 but that seems to be more just a glitch somewhere.
Rerunning the scan of devices though, I'm not seeing where it's actually subscribing to the StreamState topics outside of "FriendlyName"
I'll do more digging but here's the logs from the HA Scan:
EDIT: Found the issue... subscribeHADeviceEvents isn't being called.
Updated start_HADiscovery(evt) and added it in based on what we were using in the alpha and states are being updated now.
if(settings?.HAStatestream){
log ("HA stateStream enabled", "INFO")
delay=0
runIn (delay, "subscribeHADevices")
+ delay += 5 //TODO tweak
+ runIn (delay, "subscribeHADeviceEvents")That’s because I was trying to keep a running count but it doesn’t match up because I’m subscribing using wildcards but unsubscribing individually, hence goes negative.
So are any HA devices coming in via statestream ? HA Discovery is enabled and runs ?
See my edit in the above post. subscribeHADeviceEvents isn't being called in the current code so the state changes weren't picked up (or subscribed to I should say)
Good spot Jeff , I removed all those enforced delays for max speed as it self paces now. That delay += 5 and the runIn() we’re removed and subscribeHADeviceEvents() should run as soon as unsubscribeHADevices() starts but it looks like it doesn’t.
So it needs calling from within unsubscribeHADevices()
I have just posted beta1a that has this fix.
def unsubscribeHADevices(evt=null) {
+ subscribeHADeviceEvents()
// Can't wildcard these as the subs were setup individually
log ("Unsubscribing from HA switches, lights and sensors friendly names topics ", "INFO")
mqtt.subscribeTopic ('homie/'+atomicState.normHubName+'/$fw/version') //using this as it returns after all other messages have arrived so know done
mqtt.unsubscribeTopic(atomicState.HA+'/switch/+/friendly_name')Download the Hubitat app
