You've probably already done this but when I see quirky stuff like that I reboot the hub. So far it's worked every time. I don't mean to imply it's a frequent occurrence as it seems to happen only when I playing with a new device or app.
both my hubs get rebooted nightly on a schedule... 
I've got a better example here is the logs from the child device driver:
And here is what showed up in the logs for Door 1 for that exact same time frame.
It's the first time I've seen something sporadically create logs or not. You see it captured the last close...but not the previous open/close/open.
Sorry - just been engrossed in something else in non MQTT land - I'l take a look shortly..
@kevin, I had a thought that I might be able to use MQTT Text to send an arbitrary message to a script on a host. That script would take that message and do any number of things with it like send email, for example.
I installed the MQTT Text driver and played with it a bit but it doesn't seem that I could use it as I intended. It could be that I'm too "inside the box" to get it but I also seem to recall you saying that the MQTT Text driver was falling out of favor in some way.
So, what can you tell me about the viability of my idea?
The MQTT text device will send an arbitrary 'string' as an MQTT payload and update it's own state if that value changes. Is that what you want ? If so it's fine and can be driven by RM.
The HE variables can also be sent as a payload value and will update should that payload change. These are more straightforward mainly because have less features like the pre and post pend of a string and are directly identified in RM.
You would have to work out how to get the payload value out of MQTT and into you script but I would have thought there are other more direct ways of achieving this like http post ?
One of my MQTT users is also using Home Remote extensively with hundreds of devices. He stores all the 'theme' values for his HR layouts like color on MQTT and in a HE device so that he can in one sense have a backup and in another manage the appearance easily and dynamically should he wish. This could also I guess be applied to a lot of other UI elements like size, font, images I guess.
@kevin : Thnx so much for the development of this MQTT-app (I'm using beta3)! I have been trying to sync between domoticz and hubitat (using HTTP-calls) for some time and not been very succesfull, so my hopes are on mqtt.
But I'm having some trouble with Omni sensor devices. From domoticz, the values of my T/H-device are sent to my mqtt-broker (mosquitto), following the domoticz format (see screenshot). With nodered I remap the payload and publish on a different topic on the broker: domoticz/out/hubitat1/41 = {"temperature": 22.4, "humidity": 56}.
In hubitat I've created a virtual omni sensor device from within the MQTT app. I registered two topics, one for temperature and one for humidity (see screenshots): domoticz/out/hubitat1/41{temperature} and domoticz/out/hubitat1/41{humidity}.
Now something strange happens, see screenshot of log.
The values are mapped onto both properties resulting in only the humidity value set for both properties.
I deleted the virtual device in hubitat, reregistered topic-value, but nothing helps...
Am I doing something wrong?
Probably not... let me take a look.
My most 'dreaded' device the Omni Sensor 
Back soon, just on another chore
PS You shouldn't have to do that Node-RED topic remap - you can pickup 'svalue1' and 'svalue2' directly (that's not the issue though)
PPS I can replicate this issue.. on the case
More direct on the HE but then I'd have to run a http server on another host. I'm already using a shell script to act on another topic so I figure cloning it to pass messages to email (SMS, ultimately) is the easier way to go. But thanks for the suggestion.
And thanks for the elaboration in post 106. I can probably get it working now 
You will have to run some sort of MQTT client though on the host to do it the other way ? Or is that already taken care of.
That would be the cloned shell script. It's quite easy and short. Here's the one currently in use:
#!/bin/sh
report_back()
{
if [ $1 = 0 ]; then
mosquitto_pub -q 1 -h localhost -t motion-recording-status/set -m true
else
mosquitto_pub -q 1 -h localhost -t motion-recording-status/set -m false
fi
}
###
# Main body of script starts here
###
mosquitto_sub -q 1 -R -h localhost -t homie/steve-s-hubitat/video-motion/onoff | while read changed_state
do
if [ "$changed_state" = "on" ]; then
mosquitto_pub -q 1 -h localhost -t motion-recording-status/set -m false
echo "Starting motion..."
sudo systemctl start motion
report_back $?
elif [ "$changed_state" = "off" ]; then
mosquitto_pub -q 1 -h localhost -t motion-recording-status/set -m false
echo "Stoping motion..."
sudo systemctl stop motion
report_back $?
fi
done
1 Like
I didn't see how. The idx of the domoticz device is in the payload. From the topic you cannot distinguish which device it is. So I remapped the domoticz payload to a topic with device id, so I could register the correct topic in the hubitat virtual device.
Thnx voor investigating!
You're correct 
Sorry you do need some sort of logic somewhere to get that. Really a topic structure should identify a device but I guess they're just throwing everything out on one topic on MQTT as a quick solution. HA statestream does this too. I suppose I could' discover' devices from Domoticz but I haven't had many requests for that.
Having a _Topic ability like...
domoticz/out/mqtt/mqttdevices{idx:41,svalue:}
or something a bit nicer formatted would have been useful
Nearly there on the fix..
That would make things even more simpler So let me know when you plan to implement it.
But hey, I'm glad you developed this app and driver, i can get by with the nodered workaround.
@guido thanks for finding this issue, the fix will be in beta 3c. In the meantime you could either...
-
create two different virtual devices in HE, one for temperature and one for humidity.
-
Use Node-RED to create two separate topics for these psyloads, not the single combined values json payload one.
If I do I’ll let you know... This is a balancing act between not being intimidating for new users and yet being powerful
Option 1 will not work for me: I also use Sharptools and humidity devices are not supported. That's the reason I make use of the OmniSensor.
I'll give option 2 a try. I'm quite new to mqtt in general, your app and driver and nodered, I started playing with it this weekend and was quite proud to get things running at all. So I have to figure out how to split the payload into 2 separate topics with their own payload. I will have a go at it after work the next couple of days.
I'm happy to test your bugfix in beta3c, but I don't see it in github. Anyway, thnx for the quick respons!
1 Like
I’ll contact you later by PM re pre access
Re option 1) leave humidity in Omni and setup the other as temperature or another virtual Omni if that works for you ? Or you could force the humidity value into any attribute .. even a temperature attribute if you had too. But it will present as two distinct devices.
Option 2) will remain as one compound device.
I am going to be releasing beta 3c very shortly - a couple of bugfixes and a minor feature.
I'm conscious that the readme / instructions are now way out of line with the released version so that is my next focus ..
2 Likes
Hi @kevin,
I've been struggling with this for the past couple of days and feel its time to reach out 
I'm trying to get the devices from HE to HA, with some, but mostly no success.
This is my HE set up.
And I can see its connected to Mosquitto
Currently I have selected 25 devices for battery, 9 buttons, and 3 shades.
Yet all I'm managing to get across to HA are the batteries.
Any tips on what to check?
Cheers
