I had tried that before, too. Here you can see availability from the ratgdo device, and command - get-status from the Hubitat driver on the exact same topic:
However, nothing here:
And device states are still unlisted. This is where I continue to get stumped...
Looking at the driver code, it looks like we're looking for the topics under the root homeassistant topic. Could you expand that and send a screenshot? Ideally with some levels of the subtopics expanded as well.
This is the config payload:
{
"~": "ratgdo/garage/dan",
"name": "Door",
"unique_id": "dan_08:F9:E0:4B:1A:15",
"availability_topic": "~/status/availability",
"device_class": "garage",
"command_topic": "~/command/door",
"payload_open": "open",
"payload_close": "close",
"payload_stop": "stop",
"state_topic": "~/status/door",
"device": {
"name": "dan",
"identifiers": "dan_08:F9:E0:4B:1A:15",
"manufacturer": "Paul Wieland",
"model": "ratgdo",
"sw_version": "2.57",
"configuration_url": "http://10.0.0.157/"
}
}
Based on these lines in the groovy code:
input name: "doorName", type: "text", title: "ratgdo Door Name(Topic name)", required: true
(topicFull.startsWith("${haDiscoveryPrefix}/cover/${doorName}/config"))
Make your ratgdo Door Name(Topic name) --> dan
That made another topic under ratgdo/dan where you can see the hubitat driver looking for information, but still zero events and no states set in Hubitat.
The problem seems to be the ratgdo prefix that's embedded in the code (I highlighted it above). Let me try changing my the homeassitant prefix (in the ratgdo device) from homeassistant to ratgdo and see if that gets everthing pointing to the right (or at least the same place).
Cleaned up all the duplicate topics from MQTT so it's easier to know what's active now. This set-up looks like it should work... the device and the Hubitat driver are both looking in ratgdo/garage/dan. But, nothing in Hubitat... not one event shown for the device.
The logs don't offer much, either...
Wish I could help more, but it looks like @825d60685b34c4f304ab will need to chime in here...
I appreciate all your help! This one has been perplexing...
Gives us something to do in Chicago while we wait for the perfect time to shovel snow!
Ah, yeah, I don't miss that! I used to live around the western suburbs there... then Fort Lauderdale/Miami, and now Atlanta. Not exactly warm here today but now snow 
Times like this that I miss Atlanta... 
Grew up in Athens (go Dawgs), then Decatur, and finally Midtown.
Hey guys, sorry I've been AWOL recently. Trying to get back into the driver to help people today. Stay tuned.
@825d60685b34c4f304ab Welcome back!
In my humble opinion, it might be useful for you to add configuration instructions to the very first post in this topic covering both the Ratgdo and Hubitat steps. Could cut down on any confusion.
Agreed though this started as a WIP post so it's more of a stream of consciousness for willing testers until we reach a point where it works well for most and is easy to set up for all.
And this post will be a stream of consciousness as well as I regained familiarity about that piece of code.
UPDATE: I pushed 0.9.7 through HPM. Please update, I removed a lot of code we didn't need anymore from the garaget sample code I used to get started.
I did incorporate the code fix from @GuyMan
Next update: Child devices (once I understand how to make them work
{MQTT Topic Prefix}{Device Name} - these are the two fields of the same name configured in the WebUI for the ratgdo device (not the Hubitat device)homeassistant/cover/{device-name} topic with a config message that tells us the device supports cover (i.e. roller shutters, blinds, and garage doors)My driver today subscribes to that topic (only cover right now) and outputs the following in the log "Got Home Assistant Discovery message" when it does (when the Hubitat device is Initialized or the ratgdo itself is rebooted).
If the message deviceName matches our Hubitat Device name, it will use the content of that message to set up Stave Variables such as the: unique_id, configuration, model, manufacturer, sw_version. This is cute and helpful information but the homeassistant messages do not affect the device operation in Hubitat today.
They might be helpful in the future to set up child devices when I move to that setup.
Device Name in the ratgdo webUIratgdo/. I can make that configurable in the future but it is not today.{MQTT Topic Prefix}{Device Name} (WebUI references) and the Hubitat Device driver will subscribe and publish to the same topics i.e. ratgdo/${doorName}/ - the topic suffixes are status/door, status/lock, status/light, status/availability, status/obstructionWhen in the Hubitat Device you click on "On" (for the light), it writes to the ratgdo/{ratgdo Door Name(Topic name)}/command/ the command light:"on"
The device then produces a message in ratgdo/{ratgdo Door Name(Topic name)}/status/ that says light=on.
When in the Hubitat Device you click on "Open" (for the door), it writes to the ratgdo/{ratgdo Door Name(Topic name)}/command/ the command door:"open"
In the Info level log you'll see something like this:
Garage Door: Incoming MQTT Status via prefix/status/light/ : off
The device then produces a message in ratgdo/{ratgdo Door Name(Topic name)}/status/ that says door=opening then door=open.
In the Info level log you'll see something like this:
Garage Door: Open command sent...
Garage Door: Incoming MQTT Status via prefix/status/door/ : open
Inversely when you trigger closing in Hubitat, the device will produces a message in ratgdo/{ratgdo Door Name(Topic name)}/status/ that says door=closing then door=closed.
@erik.tank , @michicago - please update to the latest and look at your MQTT explorer and see if those command and status messages are being produced in the same one topic root (versus produced in one and subscribed/consumed in another)
Do not change the Home Assistant Discovery Prefix, leave it as homeassistant. It doesn't affect the operation of the Hubitat Driver other than preventing the state variables to be set.
To help further please provide a screenshot of your Hubitat device preferences and your ratgdo web config.
Remember that the Topic Prefix (in the WebUI for ratgdo) HAS TO BE ratgdo/ right now and that the Device Name (in the WebUI for ratgo) has to match the ratgdo Door Name(Topic name) in the Hubitat device configuration.
A good way to test things outside of the Hubitat driver to confirm that the ratgdo can in fact open and close the garage door would be to publish in MQTT Explorer
topic: ratgdo/ratgdo-8229/command/door the message open (RAW)
Replace ratgdo-8229`` with your device name (Device Name & Web Config Username``` in the ratgdo web UI)
Verify that the MQTT Topic Prefix is set to ratgdo/
Then send the command open
This will confirm that your ratgdo can open and close the door, that is that your device is compatible with your garage opener and that it's wired correctly.
@michicago got it working. @erik.tank do you need help?
I could only get my ratgdo to show online and clear for obstruction. It would not work with my chamberlain garage door from 2005. I bought a Meross and it works fine in HomeKit and Alexa. Still can’t get it to work in hubitat either. I’m guessing there is something defective in mine, but maybe the multiple days and hours troubleshooting wasn’t enough.
Mine did the same for a bit - the issue turned out to be a poor connection on the white wire into the garage door opener header. Try trimming more exposed wire on all 3 going to your garage door header and see if that works? Worked for all 3 of mine and they haven't so much as hiccupped since.
Cheers.
Download the Hubitat app
