So the "ESPHome-API-Library.groovy" file does not implement the type 46, 47 and 48 (climate) part of the ESPHome API. Looks like I'll have to get this added before I can really get this thing working.
For those looking for RatGDO Disco support (presence, led, laser, etc... support), I have a version in my repo, not merged to the main one yet - looking for any feedback before I submit a PR.
So what am I doing wrong here. I've got a ratgdo 32 with newly flashed firmware and connected to a 2.4ghz wifi. On my home wifi I put in it's IP and it shows up and I can control the garage. So I know it's connected and functioning.
I've installed the api helper library and created a driver from brianschmitts repository.
I created a virtual device, and put in the IP which I made static on my router.
It appears to be trying to connect over and over again. I can see when I open my door it connected for about 20 minutes, then went back to this state.
I'm sorry I don't have advice on the issue, I am running into the same thing.
I even tried reflashing, didn't work. Tried altering the YAML with no encryption key and added static IP, but still getting the same thing. Door was working fine until a couple of weeks ago, then just constantly going offline (like every two minutes). Runs fine in Home Assistant though. (also the synced time is wrong because of a power outage today, still have to go back and change that).
I was able to fix my issue. I think I had a different Ratgdo driver. But then I also noticed that one of the static IP's I had set wasn't taking effect. I just powered off the device for 2-3 minutes and when it reconnected took the right one, and I was able to get it all connected and working in Habitat. Feel like a dope. I should have poked at it more, but I had spent all day getting a MQTT server going only to be unable to find Ratgdo MQTT firmware, so I was throwing a hail mary to ESPhome and hoping it would work, I was so close and sick of trying to trouble shoot, I'll be honest. I just mashed the easy button....
For anyone seeing the message type 3 retries it appears that there were ESPHome changes in ESPHome 2024.12.0 (API 1.12). If your device was compiled with 2024.12.0 or later you will get the errors. I went around and around with ChatGPT, but finally found a fairly simple patch that should be backwards compatible.
You need to replace private void espHomeConnectRequest() starting at line 1105 of ESPHome-API-Library.groovy that is in the library zip file. The patch is:
private void espHomeConnectRequest(String password = null) {
//
// ESPHome API handshake rules:
// - Old ESPHome (API <= 1.11) sends ConnectResponse (type 4).
// → We must wait for it.
//
// - New ESPHome (API >= 1.12 / ESPHome 2024.12+) does NOT send type 4.
// → We must NOT wait for it or the connection will stall.
//
// Version values come from HELLO_RESPONSE (msg type 2).
//
boolean havePassword = (password != null && password != '')
log.info "ESPHome sending connect request (${havePassword ? 'using' : 'no'} password)"
// Build ConnectRequest tags: only field 1 (password) is valid.
Map<Integer, List> tags = [:]
if (havePassword) {
tags[1] = [ password as String, WIRETYPE_LENGTH_DELIMITED ]
}
// Determine whether we're talking to old or new API
boolean oldApi = false
if (state.apiVersionMajor != null && state.apiVersionMinor != null) {
oldApi = (state.apiVersionMajor < 1 ||
(state.apiVersionMajor == 1 && state.apiVersionMinor <= 11))
}
if (oldApi) {
// Old ESPHome requires ConnectResponse
sendMessage(
MSG_CONNECT_REQUEST,
tags,
MSG_CONNECT_RESPONSE,
'espHomeConnectResponse'
)
} else {
// New ESPHome does not send ConnectResponse — continue handshake immediately
sendMessage(MSG_CONNECT_REQUEST, tags)
runInMillis(10, 'espHomeDeviceInfoRequest')
}
}
I did add climate in the library and it seems to work for the parts that I did test, I can get reporting from the climate device and see all reported settings that my A/C reports. But did not yet manage to get Hubitat to control the A/C unit (although I did not try very hard at this point in time),
I'm hoping to get back to it at some point but just don't have time at the moment for this. I can share the base library with the mods I made to it if you wish to try your hand at it.
I'm new to HE and just picked up a RATGDO32 to control the garage door. It's connected and I can control it from the device page accessible by its static IP in the browser. I was successful in installing ESPHome via Hubitat Package Manager and did select the RatGDO driver and verified that it installed. I've set up a virtual device and added the proper static IP under preferences, but it just constantly tries to connect. I do have an instance of HA that I can fall back to (it works great there), but I'm really trying to keep everything as simple as I can, so thought it would be ideal to get the direct connection working. Am I missing something simple here?
EDIT: I went to the browser page using the device IP for the RatGDO and it is showing this in the log:
14:16:08
[D]
[api.connection:2230]
Hubitat House (192.168.11.239): disconnected
14:16:09
[W]
[api.connection:2236]
Hubitat House (192.168.11.239): Reading failed CONNECTION_CLOSED errno=128
14:16:11
[D]
[api:222]
Accept 192.168.11.239
14:16:11
[D]
[api.connection:2230]
Hubitat House (192.168.11.239): connected
14:16:11
[D]
[time:085]
Synchronized time: 1969-12-31 19:00:00
14:16:41
[D]
[api.connection:2230]
Hubitat House (192.168.11.239): disconnected
14:16:41
[W]
[api.connection:2236]
Hubitat House (192.168.11.239): Reading failed CONNECTION_CLOSED errno=128
14:16:44
[D]
[api:222]
Accept 192.168.11.239
14:16:44
[D]
[api.connection:2230]
Hubitat House (192.168.11.239): connected
14:16:45
[D]
[time:085]
Synchronized time: 1969-12-31 19:00:00
Looks like it is trying to connect and failing for some reason.
You already have an HA instance. Use HADB to bring the RatGDO over to Hubitat from HA. That's what I do, has always worked perfectly. Easier to update the RatGDO firmware from HA.
The underlying library is out of date - the connection mechanism has changed, I am seeing this in another handler as well but its doesnt seem to have any effect and you can ignore it if the driver is working fine. The problem with this solution is that ESPHome changes very rapidly and no one is keeping the libarary up to dates. I have updated the underlying lib to match ESPHome Feb 2026 release, need to test it a little more and then I will raise a PR to @jonathanb hopefully he will merge the code.
That's why I use HADB to bring ESPHome devices to Hubitat from Home Assistant rather than going directly from ESPHome to Hubitat. The breaking changes on the Home Assistant side are just too frequent.
I wish HADB was better maintained and it was cleaner, I started with that but I couldn't find a thermostat control in HADB, thats the reason I took this path. Or may be I am too thick and didn't look close enough. I agree that HADB is a better solution and will have a longer shelf life ESPHome can keep changing and they HA / ESPHome folks can keep them updated, other interfaces probably have a longer shelf life and covers a larger set of devices.
HADB has come a long way, with many improvements and additions as requests have been made. @ymerj and others have done a great job keeping HADB updated. As a matter of fact, an update was just made today.