I guess it does. Actually, it's the standard driver provided by HE. Plz see screenshots:
Hi Kevin,
Thank you so much for your app., it works very well for me, really appreciate it.
I created a Virtual Illuminance Sensor within your app. and get the following output
Current States
- illuminance : [Illuminance:115]
As indicated in your post, the current version does not support nested json, is there a way to get around it?
Thanks agian.
Regards,
Wade
What originates the illuminance value ? Can you post a payload example of what you would like to be publishing out to MQTT with the nested json ?
Are you using NodeRED at all currently ?
Hi Kevin,
Thanks for the quick reply.
It's originated from a DIY Tasmota ESP8266 device.
Here is the original payload:
RFB/tele/SENSOR={"Time":"2021-01-12T11:00:02","BH1750":{"Illuminance":65}}
I'd like to get something like
- illuminance : 65
instead of
- illuminance : [Illuminance:65]
Yes NodeRED is being used, but not preferred, try to make things as simple as possible.
Regards,
Wade
OK - no sorry, I don’t think you can handle that currently - only using NodeRED to massage the payload.
Or maybe...
You might be able to republish the HE sensor to mqtt which would result in a single level json (ish) payload [Illuminance:65] and then re-import with a new virtual sensor to just pick up the single integer.. but messy. The [] might not be recognised though.
I don’t think the next beta will help either....
OK - I am back trying out this MQTT App & Driver having failed to get MQTT Link to work. 
I have deleted MQTT Link and reinstalled this App / Driver.
I did have a problem with the install but reading the thread I saw a suggestion that deleting the Child Driver would kick it into action, which indeed it did.
So I have set-up one virtual device (a motion sensor) and I can publish that to MQTT. I see it in MQTT like this:
What I haven't achieved yet is to be able to alter the motion from MQTT explorer - this is at the high level the issue I was having with MQTT Link. I have tried this, but to no effect:
Not sure what I am missing, must be something?
Add /set to the end of the topic when publishing to it.
Thanks for the suggestion. 
I tried this:
Topic: homie/home/indigo-sensor-01/motion/set
Payload: true
and got these messages in the log:
app:1322021-01-18 16:50:29.172 warnMQTT: ... only 'onoff' 'dim' 'color' 'color-temperature' 'window shades' 'valve' 'garage doors'and 'locks' are settable currently
app:1322021-01-18 16:50:29.170 warnMQTT: Trying to 'set' a sensor value motion for indigo-sensor-01
app:1322021-01-18 16:50:29.141 debugMQTT: Everything Lookup for indigo-sensor-01 is INDIGO_SENSOR_01 [null]
app:1322021-01-18 16:50:29.092 debugMQTT: MQTT set command received for indigo-sensor-01 motion true [topic:homie/home/indigo-sensor-01/motion/set, payload:true] [true]
It should be more like homie/indigo-sensor-01/motionsensor/motion/set
You may also try homie/indigo-sensor-01/motionsensor/motion/status/set <= 'active'. Supposedly, both work.
Hi Jon. My Internet area (Virgin) is down with a scheduled repair time of 4pm tomorrow. I missed this post sorry.
What actually originates the state of this sensor ? Is it coming from elsewhere onto MQTT ? Outline me what you’re goal is here.
How are you creating the virtual device in HE - from within my app or from HE direct? I suspect HE directly and sensors (even virtual) are not changeable from MQTT. Maybe they should be (thinking) . However if created from within my app they are.
In the device topics for the sensor on MQTT does it have a $settable payload and if so what is it? A screen grab of the whole device from MQTT with sub topics expanded would help me.
I will get you going on this as it can be done, maybe just not as you’re attempting. If it turns out it can’t I’ll quickly issue a hot fix.
1 Like
Internet back Jon - looking at this - answering my own question from above..
Virtual Sensor devices originated from HE and created directly in the HE app are not settable from MQTT. Let me look at creating them within my app now. Would that suit your need?
I'm still not sure what you're trying to achieve and where the sensor status payload originates from? Can you control the status topic for the device and the topic it monitors for its set commands? (If it supports 'set' not sure why it would..)
Have a question.
Now after adding new device - need to change MQTT App settings by adding device/capability.
Right ?
Is it Ok to have a switch(es) - send All Temperature measurements (just example) for all existing & new sensors.
And reinitilaize App periodically to include new sensors ?
Can you explain a little more. When you say 'add new device' where are you adding it and where does it's state originate from - a HE inbuilt device or an MQTT device ?
Your second Q implies that sending to MQTT all HE devices that are switches and temperature sensors ? So they are HE devices ? As you enable HE devices through the Publish these HE devices to MQTT option and click next then yes those get added to MQTT immediately. Notice there is an 'all' option but I am not sure if you use that and then you add devices to HE if it continually enables newer ones. I don't think it does.
Previous devices that you disable will however still be visible on MQTT (as it retains messages) but you can ignore them and they aren't controllable from MQTT or updated with correct state
Is this what you are meaning or are you importing devices from MQTT where the status is coming originally from say Homey, Home Assistant or another controller or device directly?
sums it up really
'should' or 'could' ...I am thinking this might suit your needs - but I would just like to check - so I'll wait on your 'use' case explanation to see if virtual MQTT originated devices suit first....
Just to expand on that - you could create a device on MQTT that is updated from 'somewhere' and then you import that HE as a virtual Motion Sensor. When you configure that correctly it will display the status payload as shown or updated on MQTT.
You could also (I believe) add a 'command' function so that HE will send a command to update the sensor to the remote device. It is up to your remote device to handle this and feedback a new status to MQTT.
Think about HE hub devices.
This one select all existing (and listed below) devices.
It will not enable new devices, for sure.
I'm thinking about feature to add new HE temperature sensor to MQTT App config 'on the fly', w/out specifically selecting it in MQTT App configuration. Just because it is temperature/etc. sensor.
Sorry my bad English. I tried.
OK - there is a sensible security restriction imposed by Hubitat. You have to specifically enable individual devices to be 'accessible' by my app via the user interface.
I can't pickup new devices without the user doing this - to stop an app hijacking your devices. So I can't do this automatically , it will require as you suggest enabling new devices manually and re-running the app.
2 Likes
I am trying to use MQTT as a bridge between Hubitat and Indigo. I want to be able to go both ways i.e. a change to a device in Hubitat will get sent via MQTT to Indigo - that works OK. In reverse, I want to be able to reflect a change in an Indigo device onto a Hubitat device (via MQTT). So in this specific case, if I have a motion sensor in Indigo that turns on/off, I want to reflect that in a Virtual Motion Sensor device in Hubitat.
Connecting Indigo to MQTT is comparatively easy. So whatt I am testing, is trying to get a message published via MQTT Explorer to update the Hubitat Virtual Motion Sensor. Once I know that works and the structure (i.e. topic and payload) required, I can then send that message from Indigo.
For the current testing, I created the Virtual Motion Sensor device outside of the MQTT App.
Thanks for looking at this and hopefully that gives an overview of what I am trying to achieve. 
We can do that now - what you need is to decide on a topic that the status of the motion sensor (from Indigo) will be sent to and the payload. If you can use 'active' 'inactive' that makes it easier in HE but you can use anything. Don't create the topic inside the homie/... tree - place it elsewhere.
Let's assume you use
Indigo/sensor1/motion
and the payload is either active or inactive
When this is working from Indigo (or MQTT Explorer) - i.e. it updates as the sensor in Indigo does then we will import this 'arbitrary' device into HE
Select a Device Type of Virtual Motion Sensor and enter a name at the bottom eg "Indigo One" - click outside the name field and then 'Create Device Indigo One'
Now enable this device in the second dropdown and click 'Edit this Virtual Motion Device' and select your device Indigo One and 'Update' You will see some extra data for the device. You should fill in the motion status topic with the MQTT topic you chose. Check there is no leading space.
Note that further down inactive|active are already the default value for status of this device. If you choose other values then they should be entered here.
Now click
Next and Done..
(You may have to re-run the app once more through to done)
You have now created your virtual device and it is linked to the status topic that Indigo is updating so it will reflect the Indigo motion sensor status. You can't control the Indigo sensor from HE though - that doesn't make sense and you didn't want to anyway.
Let me know if that works for you
The difference to your initial approach here is that the virtual motion sensor was created from within the MQTT app and is thus a child device of the app. If you look within the device itself it will have the following extra data.
Thanks for the detailed response.
I will try that out in a short while and report back.
