New plugin - ratgdo

Getting this:

Error device "Carport (ratgdo)" state key motion not defined (ignoring update request)

Where do I have define that state key?

JP

See https://github.com/FlyingDiver/Indigo-ratgdo/issues/3

Add comments there. This is not really a valid state. I need to do something with it, but I'm not sure what.

The Ratgdo integration was working perfectly for me for some time. Recently, sending commands via Indigo stopped working. Details:

- I can see the the command being received by my MQTT server from Indigo via the MQTT Explorer
- The Ratgdo is reliably on my wifi. I can connect to the web interface. I rebooted it for posterity.
- Status updates from the door is being published from the Ratgdo to the MQTT server, and the Ratgdo plugin is receiving those, and showing the right state in Indigo.

I'm kind of stuck. Any thoughts on what could be wrong?

The Ratgdo integration was working perfectly for me for some time. Recently, sending commands via Indigo stopped working. Details:

- I can see the the command being received by my MQTT server from Indigo via the MQTT Explorer
- The Ratgdo is reliably on my wifi. I can connect to the web interface. I rebooted it for posterity.
- Status updates from the door is being published from the Ratgdo to the MQTT server, and the Ratgdo plugin is receiving those, and showing the right state in Indigo.

I'm kind of stuck. Any thoughts on what could be wrong?

So MQTT messages from the ratgdo are going to the plugin and those updates work. But MQTT messages from the plugin to the ragdo do not? And MQTT Explorer is seeing both sets?

That's really strange. I'm assuming you're running MQTT Explorer on the Indigo server system. Try running on some other system just to make sure there's no firewall issue.

The Ratgdo integration was working perfectly for me for some time. Recently, sending commands via Indigo stopped working. Details:

- I can see the the command being received by my MQTT server from Indigo via the MQTT Explorer
- The Ratgdo is reliably on my wifi. I can connect to the web interface. I rebooted it for posterity.
- Status updates from the door is being published from the Ratgdo to the MQTT server, and the Ratgdo plugin is receiving those, and showing the right state in Indigo.

I'm kind of stuck. Any thoughts on what could be wrong?

So MQTT messages from the ratgdo are going to the plugin and those updates work. But MQTT messages from the plugin to the ragdo do not? And MQTT Explorer is seeing both sets?

That's really strange. I'm assuming you're running MQTT Explorer on the Indigo server system. Try running on some other system just to make sure there's no firewall issue.

I'm running my MQTT Server outside of my Indigo machine. It's on my HA install.

I'm guessing this will be a firewall issue. I do have the ratgdo on a separate VLAN, but again it was previously working and I have the rules in place to enable communication. I'll likely put it on the same network to diagnose as a next step.

Two questions to help me diagnose further:

1. How can I be sure that my ratgdo can, in fact, control my garage door? Do you know of a way to test manually? My hard wired door button works, which is wired through the ratgdo, so I doubt this is an issue, but would like to be sure.

2. I'm a novice at MQTT. How does a command get from MQTT to the Ratgdo? Is the Ratgdo polling MQTT? Does something get "pushed" to my ratdgo?

1. How can I be sure that my ratgdo can, in fact, control my garage door? Do you know of a way to test manually? My hard wired door button works, which is wired through the ratgdo, so I doubt this is an issue, but would like to be sure.

The only way I know to do it is to use an MQTT client to send the appropriate topic and payload.

2. I'm a novice at MQTT. How does a command get from MQTT to the Ratgdo? Is the Ratgdo polling MQTT? Does something get "pushed" to my ratdgo?

The ratgdo subscribes to messages from the broker you configured in the initial setup, and the broke relays the MQTT message from the plugin to the device. So it's a push, not a poll.

MQTT is a protocol, not a source. The source is the plugin (for commands) or the ratgdo (for status messages).

I moved the Ratgdo to the same VLAN as my MQTT Server and Indigo. Virtually eliminating firewall as the potential issue. No dice.

I'm feeling like I have a wiring issue now? Very strange that it would stop working all of a sudden though. And, doesn''t the physical wall switch route through the ratgdo? So, if I had a wiring issue, the wall button wouldn't work? Very strange.

I moved the Ratgdo to the same VLAN as my MQTT Server and Indigo. Virtually eliminating firewall as the potential issue. No dice.

I'm feeling like I have a wiring issue now? Very strange that it would stop working all of a sudden though. And, doesn''t the physical wall switch route through the ratgdo? So, if I had a wiring issue, the wall button wouldn't work? Very strange.

Which wall switch? The original or something you added with ratgdo? The original doesn't route through the ratgdo, it's on a shared bus. That is, it's connected to the opener in parallel with the ratgdo and the ratgdo looks like a wall switch to the opener. I think.

It's possible that the ratgdo itself failed and can no longer generate the commands needed to control the door, but is still receiving the status signals (and sending them to the MQTT broker).

Which wall switch? The original or something you added with ratgdo? The original doesn't route through the ratgdo, it's on a shared bus. That is, it's connected to the opener in parallel with the ratgdo and the ratgdo looks like a wall switch to the opener. I think.

This makes sense. I just figured that if the Ratgdo has a role to play in the wall switch working, even just being on the shared bus and relaying input and output, than I dont have a defective device. Who knows.

This is the advice on the site for my situation:

ratgdo is wired correctly and won’t control my door

Verify that you are using the correct control protocol for your door opener model.

Yellow Learn button openers (except for the jack shaft wall mounted 8500/RJ020 8500C/RJ020C) use Security + 2.0. Purple / orange and some red learn button openers use Security + 1.0. Everything else uses dry contact control.

If you are using Security + 2.0, you can try and reinstall the firmware and choose the “Erase” option which will force the generation of a new client ID for communicating with the door.

I'll give that a try this weekend. What a pain.

Update --

The ratgdo has a light on the board that turns on when you send it a MQTT command to open or close. I was able to see it turn on when sending commands from Indigo. But nothing was happening as result with the door. This confirmed I didn't have a networking or configuration issue.

I took pictures of my wiring and took down the board. I erased and reinstalled the firmware, and configured to the exact same settings I had before. Re-wired using the pictures, no changes. Door is now opening and closing as it should.

I'm guessing Liftmaster did something as per the FAQ to change the authentication and block my device. Hopefully this config sticks.

Stopped working again. I wonder if Chamberlin / Liftmaster is sending updates or figured out a way to block Ratgdo.

The dev doesn't have any support channels available to my knowledge. Not sure how I'll handle this next.

Found this: https://github.com/ratgdo/mqtt-ratgdo/issues/17

Some people have reported more stable behavior with ESP Home. I literally know nothing about ESP Home, but maybe that's a route to look at next and use the HA Agent plugin.

Interesting thread. I haven't done much with ESPHome devices. GlennNZ has a plugin that might work for it with that Firmware.

Thought just would clarify what Esphome is. It is the firmware/that the ratgdo uses as far as I can see. Basically it’s a microprocessor (esp32) ‘firmware’ of sorts that simplifies custom devices like this.

The Indigo EspHome plugin should find everything that the plugin supports and then create the devices in Indigo, for any ESPHome device. Certainly we don’t support everything - but most switches/binary devices and input in (temps/sensors/binary open/close) are all supported. Just need the Ip address of the ESPHOME device, or ratgdo here and plugin will do rest.

Here:
https://www.indigodomo.com/pluginstore/293/

Certainly won’t do harm, enter the IP address, create devices and see what is supported.

Glenn


Sent from my iPad using Tapatalk

Thanks Glenn-

I moved my Ratgdo to the ESP Home firmware. From what I can tell, the developer has done a far better job refining it as compared to the MQTT firmware. It comes with a much more complete web interface, and you can change the client id via the web interface (MQTT plugin requires flashing the firmware to do this). Debugging log available via the interface which is missing from the MQTT firmware.

To bridge to Indigo, I ended up going with Joe's HA Assistant plugin. So my communication chain goes: Ratgdo - HA - Indigo

I tried using Glenn's plugin to go direct Indigo - Ratgdo. It loaded all of the sensors and relay devices, but it wasn't clear which of the devices was the actual door control. I tried them and it was not controlling the door. I admit I did not spend much time looking into it. I'm happy to debug if you feel that others will benefit from looking into it. I also dont mind keeping HA in the middle, I'm now bought in that HA will have a critical bridge role for several of my proprietary devices.

I won't claim victory just yet. I want to let this run for a while with consistent results.