Hopefully, this lengthy post will explain what I am talking about and what your next steps need to be. My apologies if it appears pedantic, you appear bright but a bit inexperienced with ESPHome and Home Assistant.
It's not clear to me what is flashed on your ratGDO. It's been a year or so since I went through the steps myself. As I indicated above, the way I use ratGDO is by adding it to the Home Assistant ESPHome add-on, then bringing it to Hubitat from Home Assistant through HADB. I do it this way because it's easy to update the ratGDO firmware through the ESPHome dashboard from ESPHome. I only control ratGDO through Hubitat. Even though I only use Hubitat Dashboards when I am out of town, ratGDO, brought over by HADB, works fine from the standard Hubitat Garage Door tile. ratGDO did work well from the Hubitat Garage Door tile from the Hubitat ESPHome driver when the ESPHome API was unencrypted (see below).
However, as discussed above, ESPHome, while being an add-on to Home Assistant, is its own subsystem, and defines its own API. The ESPHome devices appear in Home Assistant as what Hubitat would call "child" devices of ESPHome.
That said, back when I first got my ratGDO, I did verify that it worked using the Hubitat ESPHome driver. At that time, ESPHome did not use encrypted communication to ESPHome devices. Subsequent to my initial installation, ESPHome changed its communication with child devices to be encrypted by default. The encryption can be disabled by commenting out two lines in an ESPHome device's yaml code (more on this below).
The ESPHome firmware that you flash to the ratGDO has many parts. One part communicates with the Home Assistant ESPHome add-on (or, in your case, the Hubitat ESPHome driver) using the ESPHome API protocol. The other part is a ratGDO driver that communicates with the ratGDO ESP chip.
The ESPHome firmware, periodically updated, is compiled anew each time you update the firmware. The compilation is modified according to a number of parameters that are passed to the compiler in a .yaml file. The ratGDO firmware flashing page has a bunch of pre-compiled ESPHome files that were compiled for the variant of LiftMaster/Chamberlain model you have, etc., and also that have preset parameters for the type of ESP chip on your ratGDO board, etc.
What I noticed, after my initial flashing of my ratGDO board, was that it stopped working after the subsequent ESPHome Home Assistant add-on update that turned on encryption for the ESPHome API. There is a discussion of this point upthread or in one of the Hubitat community threads I linked to above.
Just to help you understand, here is the .yaml file "ratgdov25i-e764e5.yaml" for my ratGDO (with the encryption key redacted). The "packages:" entry pulls in the current ESPHome driver for the ratGDO that is bundled with the ESPHome code, compiled, and uploaded. Except for redaction of the encryption key, it's unchanged from what was auto-generated. As documented in one of the posts to which I linked, I believe, if the "encryption:" and "key:" lines are commented out, it should allow compilation of an ESPHome firmware file for the ratGDO that will work with the Hubitat ESPHome driver, which does not support encrypted communication over the ESPHome API.
substitutions:
name: ratgdov25i-e764e5
friendly_name: ratgdov2.5i e764e5
packages:
ratgdo.esphome: github://ratgdo/esphome-ratgdo/v25iboard.yaml@main
esphome:
name: ${name}
name_add_mac_suffix: false
friendly_name: ${friendly_name}
api:
encryption:
key: *** redacted ***
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
If the encryption lines were commented out, they would look like:
api:
# encryption:
# key: ###
