So IIUC, once at beta3, HPM should pick up the MQTT installation? Because right now I upgraded to b3b manually (I deleted everything, app/driver/etc. since I was just testing things) but HPM doesn't detect it when I do the match-up of installed apps/drivers.
Or probably I didn't understand and you are waiting for b3 to be spread before publishing MQTT to HPM.
Great to know we're close to a release version. 
exactly - well actually I will probably include it in HPM once it goes to release. If I add it now it will probably pick up beta 2 installs which I don't want it to. (I'll check)
Thanks for clarifying.
So I'm going backwards on this and just realized this is rather recent. So question, does this look correct?
I don't own a Garadget so hopefully @hovee will check them over but
door MQTT command topic
is certainly wrong as [open,close,stop] isn't a topic value
I think your [closed,open] should be [close,open]
PS I know my data field editor has a mind of its own at times - just persevere and they'll become correct - watch out for errant spaces at the beginning of fields.. If Trent can post a screenshot of his Garadget device data values that would help I think.
Thanks @kevin!
@jrfarrar I made a post over here that shows screen shots of the correct settings.
Looking at your pictures...
I think you meant to put an 'I don't really mean that' emoji by that.
Thank you for the update - I was a bit surprised to see this post in a different thread TBH and, assuming it wasn't working I didn't want to mislead @jrfarrer with incorrect info. Much appreciate your post Trent.
Haha no way! You’ve helped me a ton!
I noticed that, thanks! Had a heck of a time clearing out a field. FYI I think using a space was the way I did it.
Ok I don't know how I manged to get so much wrong with so much info from @hovee that I thought I followed...WOW.
Swear I thought I followed that. Clearly I was tired or drunk or both.
Thanks you both. FYI the status was working...however the commands were hit and miss. Sometimes it would close (or open) and sometimes it wouldn't. We'll see how it goes now.
Haha! What you drinking?
Also, just so you know, pressing open from Hubitat will open the door immediately, but pressing close, there is a 5 second delay before the close command is sent. @kevin is aware of this and this is partially due to the transition time logic for a Virtual Garage Door controller. Make sure you have your transition time set to 5 seconds. (See pic below) I think it'd be great if the Virtual Garage Door Controller would let you select No Transition Time/0 Seconds, but 5 is the best it can do right now. Not a big deal, as the 5 second wait hasn't cause me much annoyance.
Well that's wildly helpful too! As you know in Garadget's terms "transition time" is how long it takes the door to open or close. That might explain my delay. Lots of changes and testing today!
Yesterday was a Dark and Stormy kind of day...
I'm hoping I can work around that 5s delay before the door gets the close command (by watching the door attribute) although in practice I hope it's not an issue. On the list..
I thought that was Jun 23rd .... might have a try..
@kevin Just noticed something you might be interested in. I have 3 of the virtual garage door devices setup with my garadgets (I have 3 doors). All is working great at this point!
However events for virtual door 1 are not showing up in the log. So the door is working and i can see the events on the events page of the device. Like this:
and I have logging turned on for that device:
but in my logs the events never show up....but here's the kicker....just for this 1 door. The other two work as expected. Same settings as above and when the door opens/closes I see the events of that in the log.
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.
Download the Hubitat app
