Hi @kevin,
Do you have an ETA for the next beta release?
Thanks. 
Remind me - what is the feature you're awaiting or is not working ?
I have got slightly delayed in adding an additional significant feature that is taking a little while to finish but I could release a version 3e almost immediately if needed
Pressure missing + the issue with the initial install and trying to get a connection to the broker.
Once you have installed this is not an issue though and it's an easy workaround
Do you want to try the pre release 3e ?
Correct but I am currently working with another Hubitat user who is trying to install MQTT and is having difficulty getting it going with multiple copies of the MQTT app appearing and no broker connection. We are working through your post # details to try and resolve - not there yet..
Yes that would be great 
Just delete ALL the MQTT Client devices, make sure you only have only one copy of the beta3d MQTT app loaded and reboot the hub. You should then get only one MQTT client device automatically recreated at boot. You state above you a seeing multiple versions of the app - are you sure ?
(Do not delete the device or app code)
To be clear it wasn't me, it is another Indigo user who has just got a C7 that I am trying to help. The three apps appeared after a reboot.
Apps only get added if you use the 'Add User App' button. I do not currently use child apps.
I would suggest he deletes all three, and any and all MQTT client device drivers and reboots and then adds just one app. Now run the app and then delete the child driver instance it creates and then reboot again and a correct child driver will be recreated.
I've sent you a PM. However you may not redistribute beta3e (pre) I'm afraid even though this is fixed in that version.
Bonjour
I am new to hubitat, can work my self in computer but now I am stuck... I rarely ask for help... but there something I do not get.
I did flash Tasmota on a ESP8266 and set a Contact door and DHT11 sensor on it to monitor my mailbox outside... I have been able to set everthing into MQTT server, data flows from contact and DHT11... Works great.
I use Hubitat to only display data (or rules) based on event. I do not have other device I want to talk to. Have installed App then driver (as writtne at top of the page) ... everithing seems to work fine, but there is 1 little something I did not get that makes it not working.
My DHT 11 (topic : SENSOR/Tas-Mailbox/SENSOR ) returns this :
how can I write my status topic to get temperatre, or Humidity or else.....
here's my problem
I have been trying pretty much all options and I have read the complete thread.... I still can't figure it out. If I get this working, I will make you a simple thread to install from scratch and set the sensors... it looks to be working better that all other MQTT apps, but can't make it work.... the data of the device is not working good... can't get the value (it would show Temperature of 72... were if is +1C... even in F it dosent work.
Thank you very much (great work)
This isn't going to work for you (easily). The reason is the nested json in the payload.
SENSOR has a json payload that within itself contains another json payload containing the humidity temperature and dewpoint . I do not currently support nested json.
What you could maybe do, as a real kludge, is load the json 'DHT11' topic into a variable or an MQTT text device and then republish that now HE device back to MQTT - that will reduce the json to a single level. Then you can create a second virtual device that will link to that topic and allow you to select one of the values 'temperature' , 'humidity' etc.
Actually on thinking about that I am not sure that will work as I block reading adhoc devices back from within the homie tree. You may be able to 'discover' it though. It would still be messy.
Do you use Node-RED ? If so I can show you how you could do this ?
I understand this could be a relatively popular request for Tasmota and I did start to implement a recursive json key recovery. I will look into how difficult it would be to at least support two levels in the next beta3e
Can you post (as text) the two payloads STATE and particularly SENSOR so that I can copy paste and test against.
Hope this is right
There is another aspect that may be problematic. There is no identifier for the device/endpoint within the topic hierarchy Tas-MailBox/SENSOR . The particular sensor identified is DHT11 I believe which is a key within the higher level json who's payload is then json containing it's values. Is that right ?
If so does the SENSOR value topic payload keep getting overwritten by values coming from other sensors ? Say DHT10 ? That is going to be more awkward than the nested json as my topics currently are mapped to devices.
Or.. have you named DHT11 as SENSOR somewhere ? You quote the topic as below. Is that 3rd level a name you chose for DHT11 ?
If you would prefer to take this to PM please do...
Good evening....
DHT11 is a type of thermometer that you can setup in Tasmota.... I did not change anything from tasmota data out... it is as is... so if people put a sensor, it does provide that info... the Tas-Mailbox/SENSOR is my stuff... the rest is from tasmota.
As a matter of fact, I just install node-red tonight and have sucessfully parse the data in news MQTT topics... but haven't been able to display on Hubitat yet.... looks like the driver (not yours) is getting data out from MQTT into Hubitat, but the data is not UNKNOWN in dashboard....
Will try your driver later to see how data is flowing from MQTT to Hubitat
Thanks for answer
As a m
A little unsure of your reply here re where the DHT11 payload appears,what originates it and what you mean by
anyway - if you need further help let me know. I am looking at including a second level of json in beta3e - it may be quite easy but I would really like recursive/unlimited levels and that needs more thought.
If a device identifier is not included in the topic then I'm probably going to pass for two reasons.
- It doesn't fit my current architecture and I believe it's badly implemented - the topic structure
- If left 'as is' recovering a device identifier from the payload requires parsing all the payloads to determine th target which is hugely inefficient
Hello! Hoping someone can point me in right direction.
Attempting to go through the setup of the app:
- Configure this device to access your existing MQTT broker using the 'Preferences' section on the next screen in the device driver then click 'Done'. You must enter the IP (or URL) e.g. tcp://192.168.1.78:1883 , username / password are only required if your broker needs them. NB include tcp:// at the start of the entry.
After I add a virtual device, and proceed to the next screen it mentions updating the preferences screen, but I don't see anything there I can update. Any thoughts? (likely something very dumb on my part!)
Thanks!
The instructions are out of date here..
Don't add a virtual device for the MQTT broker , the app creates it automatically.
From where you are delete the virtual device(s) that you have for MQTT brokers. You may have two. Do not delete the driver code you installed.
Now importantly reboot the hub and open the MQTT app and configure the broker within that.
Thanks for the info, you rock!
I'm going through Method F to add devices.
I go to virtual devices, add a virtual switch, select 'or create a new virtual Virtual Switch device called...' and then create device.
I then go to select MQTT Enabled Virtual switch device and then get an error when I click Update as:
Cannot invoke method publishMsg() on null object.
Any thoughts there? My (likely incorrect) thought was you enable it, then select 'Edit this virtual switch device' afterwards to configure it.
Yes - you give the device a name and create the device using the 'Create Device XYZ' button. At this stage it will be included in your devices on HE. You should also enable it for MQTT from the enable dropdown and click update. It seems you are maybe getting an error here which would imply you didn't create the device correctly - is it listed in the HE Devices menu correctly ?
If you wish to edit the device use the 'edit this device...' dropdown and select the device then 'Update' and the details of the device should appear below like this.
You're stepping right into the most complex area within the MQTT app - adding an ad hoc MQTT device to HE - that's definitely what you're wanting to do is it ? What is the actual device you are adding from MQTT ?
The included editor provided is a bit quirky btw - just edit one device attribute at a time and save and then check the entry - sometimes they take two edits to stick. The devices page in HE will always show the correct values in the data section at the bottom of the device page. You can open two windows if that helps but refresh the HE device page after each edit.
After I create the virtual device and go to enable it, I get the error. Cannot invoke method publishMsg() on null object. 
I'll try another complete removal of app/driver and do a reboot, see if I get any more luck
I have some devices that are hooked up with webhook/Tasmota Device Manager (Tasmota 8.5.1), I'm currently playing around with a Raspberry PI and set up a MQTT Server, which I can interact with MQTT Explorer on my Desktop. My end goal is to hopefully get my devices set up with MQTT and integrated directly into Hubitat.
If that option is seen as the more complex, I could configure Home Assistant for it, but (in my head) figured it would be more reliable going directly to the Hubitat as there would be one less bounce for the device. Still a relative MQTT newbie, so it's possible I'm going about that completely wrong.
Your issue with the virtual device is not one I've had reported and not one I can reproduce here (although I may have a slightly later version). Let me know how you get on. A re-install shouldn't really alter the behaviour.
The app is very capable of importing the devices providing the payload is text or one level of JSON. If it is more 'nested' levels you can't currently extract data from the deeper levels. If you post a sample payload I can advise.
