[BETA] ratgdo driver (w/ MQTT firmware)

Hi sky320 - thank you for your feedback - I haven't tried and don't know how to deal with the dashboard but I will figure it out.

Status is online/offline so I am wondering what Hubitat Dashboards expect there.

I didn't think the ratgdo supported a stop command but I'll look into that as well. If you have a MQTT client working, can you see what MQTT messages come through when you stop the door in HA and what status updates on door are displayed in those messages?

ratgdo has stop capability. The generic garage door driver in Hubitat doesn't include the 'stop' command.

@bill.d that's helpful. So presumably I'd need to add it as a custom action and but it wouldn't trigger if you were to hit the garage icon in the dashboard.

1 Like

the stop commands are going through

@sky320 that stop is actionned through HA, right? How do you trigger them?

in hubitat I exposed the stop command in the driver

Would you be able to have the driver create child device for the light?

Yes but is it really practical to have a stop command, how would you access it? I think reversing the action causes a stop, no?

Yes, I think I'd like to see the light as a child device as well. I don't know how to do that yet (this is the firs driver I wrote for Hubitat) but I'll figure it out. I feel that Homekit integration is getting confused a bit between its light and garage door functionality

1 Like

I really appreciate the work as I know nothing of coding. The stop feature is useful to me I have to hit the door control button multiple times to try and stop it where I want it. I like the door open less than 12 inches when i am working in the garage and this makes it easy to accomplish.

@sky320 is stop something you'd run from the device page, a Hubitat dashboard or Homekit? I want to make sure I test it in the right context

the device pageon occasion. The Hubitat dashboard is the main area I use from phone or wall panel (android tablet)

the ratgdo has the ability to report door level (like a window shade) so I imagine that it could be possible to include that in the driver and expose the setLevel command for a one click solution.

1 Like

I don’t remember seeming that in the documentation, @harold.min , is it available in the MQTT firmware, can you point me to a reference?

1 Like

My mistake, it appears that door position is only available in HA/ESPHome.

How are folks getting this working? After flashing the MQTT firmware for the 2.56 device, my ratgdo device just doesn't let me connect to the wifi UI anymore. When configuring my mqtt virtual device, it never connects to the mqtt broker. However, I can connect just fine to the broker with mqtt explorer. I'm so confused.

Do you mean firmware 2.56 on the 2.5 hardware? If so, I haven’t tried the new firmware.

If you can’t connect the ratgdo to WiFi, that’s a device issue, right?

What happens when you try connecting to the device via the web browser?

Yes, the new V2.56 firmware was released last week by Paul (it's replaced the V2.55 firmware on web flashing tool) - From what I've seen of the release notes, the changes are:

  • Bug fixes for Sec+ 1.0 protocol
  • Add lock support for Sec+ 1.0
  • Add mqtt toggle command for door, light and lock

Your HE driver picked up the new firmware version in the device state variables
Per the above, a "lock" status was added into the MQTT fields that RatGDO publishes - Your driver didn't seem to pick that up in current attributes. But I just did the upgrade from V2.55->V2.56, without issue, and MQTT explorer, and your driver are working as expected.

@thatcallfire - I would verify that you can ping the RaGDO IP, and connect to it's local browser, and while on the USB connection, you can look at the logs to verify the connection to the MQTT broker (or not) - But I've recently done the upgrade, and things seem to be OK (and even fixed a bug with light control, and added features around locking, that need to now be added to the device driver.

FYI - I'm running V2.5 of the RatGDO HW.

Hi, I finally figured it out lol, I have my broker in a different VLAN (my homevlan) which lives on my synology, and the ratgdo connecting to my iotvlan. I needed to make a rule to allow traffic between the subnets to make it work -- I'll get more restrictive now until it breaks and then make a rule to allow that

1 Like

FYI - I made a few code tweaks to expose locking (which the RatGDO firmware now supports).

--- Snip ---

Old:
void getLockStatus(status) {

if (status != device.currentValue("light")) { 
    infolog "Incoming MQTT Status via prefix/status/lock/ : " + status 
    if (status == "lock") {
        sendEvent(name: "lock", value: "locked")
    } else if (status == "unlock") {
        sendEvent(name: "lock", value: "unlocked")
    } else {
        infolog "unknown status event for lock"
    }
}   

}

New:
void getLockStatus(status) {

if (status != device.currentValue("lock")) { 
    infolog "Incoming MQTT Status via prefix/status/lock/ : " + status 
    if (status == "locked") {
        sendEvent(name: "lock", value: "locked")
    } else if (status == "unlocked") {
        sendEvent(name: "lock", value: "unlocked")
    } else {
        infolog "unknown status event for lock"
    }
}   

}

---- End Snip ---

I didn't see a Git Repo, so I couldn't do a pull request, but perhaps I just missed it's current home location

2 Likes

@GuyMan I obviously didn't test this thoroughly. Please do issue a PR: GitHub - edasque/hubitat: Hubitat Applications & Device Drivers (Feel free to add release notes and a new release to HPM)

I also couldn't update to 2.56 via the web client, is that what you did or did you do it via USB? When I tried to update it from the web, it just did nothing: Unable to flash ratgdo_esp8266_hV25_sV2.56 on v2.5 hardware (MQTT) currently running v2.51 · Issue #40 · ratgdo/mqtt-ratgdo · GitHub

One more item - It seems there is an additional condition for the door status, that's unhandled - specifically a "syncing" status - I just spotted the following in my logs, after the flash upgrade:

I've haven't made any additional changes to the driver to support this additional status - I think a change is needed in the "getDoorStatus" function, but I didn't dig that deep into what exactly "syncing" is all about.

--- SNIP ---

2023-12-28 10:08:47.469 AM [info] Garage Door: Incoming MQTT Status via prefix/status/door/ : closed

2023-12-28 10:08:36.449 AM [info] Garage Door: Incoming MQTT Status via prefix/status/door/ : closing

2023-12-28 10:08:34.756 AM [info] Garage Door: unknown status event for door

2023-12-28 10:08:34.755 AM [info] Garage Door: Incoming MQTT Status via prefix/status/door/ : syncing

1 Like