[OLD] MQTT app beta1 and pre beta2 - please use beta3 thread

Please do ensure that only one MQTT driver is installed. Two will cause problems currently as they will alternately kick each other off the broker and interact with the app.

Does your one driver now show that it has a normHubName that matches you HE and also connected true ?

image

It should also have presence : present in it's attributes (it acts as a presence sensor when connected)

image

If so you're good to go.

I'm being overly aggressive with the driver which is very persistent at maintaining the broker connection. This was to combat problems people had with poor MQTT connections people had in their own setups. I'll look at backing that off a bit and having a 'disconnect' command available too. I won't be able to look at that for a day or so though as it's after 3am here now and I have unfortunately to be out for lunch tomorrow.

You should also see a heartbeat payload in your broker incrementng away every 20 seconds

image

My existing MQTT drivers use
``mqttbroker = "tcp://" + settings?.MQTTBroker + ":1883"
mqttInt.connect(mqttbroker, "hubitat_${device}", settings?.username,settings?.password)
and yours uses
mqttInt.connect(settings?.MQTTBroker, "Hubitat_${state.normHubName}", settings?.username,settings?.password, lastWillTopic: "Hubitat/${state.normHubName}/LWT", lastWillQos: 0, lastWillMessage: "I died")

They should not be conflicting because they use different client names. I'll file a github issue when I try again, assuming I still have an issue.

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

dev:9362020-01-25 10:53:13.560 pm warnMQTT> ## Restarted ##

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 :frowning:

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 :slight_smile:

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 !

5 Likes

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

image https://community.hubitat.com/uploads/default/original/3X/c/5/c5fb81ed2f1ddd6221c6f23536aa1c04a6fa9a86.png

Apologies.. This is obviously something I need to improve .. I’ll take a look tomorrow.

1 Like

I found a null in the mqtt topics! How do you get rid of a retained topic named null?Screenshot%20from%202020-01-25%2022-25-19

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.

1 Like

@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 ?