The easiest way to tell is to look at the learn button on the GDO. If it’s yellow and you don’t have a jackshaft opener, then it’s Security+2.0. The wallpanel you linked to does say Security+2.0, though, and it looks like a recent enough style that it probably would be, anyways.
I was wondering is there any way to add a hc06 Bluetooth to the 2.5 version since it uses the 8266 chip which doesn’t have Bluetooth.
Well, the answer is probably yes, but is there any reason why you wouldn’t just want to use an ESP32, instead? Since the v2.5 is a RATGDO edition that doesn’t have the microcontroller module already integrated, it would probably be easiest to swap the ESP8266 D1 mini for the ESP32 D1 mini for bluetooth capabilities.
I’ll have to check, but I thought it is soldered to the board.
Ah, in that case you have a v2.5i or newer. Small change in name, big change in ease of modification.
In that case, I would recommend you start by checking out the schematics in the RAT-RATGDO repository. The ones in the kicad_files directory are a little more up-to-date based on my original-flavor v2.5 board. You can get a feel for what components are used for the RATGDO functions, though there will be extras not on the schematic that are just necessary for the microcontroller module to generally function.
Assuming that the HC-06 module is compatible with ESPHome (I don’t really know myself, so you should probably check if you don’t either), the process looks like it would go something like connecting the VCC to the 5V power coming from the USB port, GND to GND, and soldering wires from the TXD and RXD pins to available GPIOs on the microcontroller module for a basic setup. Available GPIOs can include the dry contact pins if you are not otherwise using them, but do watch out for D4, since it pulls HIGH at boot, which is why it isn’t used anymore. Then, you can generate the firmware in ESPHome by modifying the basic configuration file to include the bluetooth functionality and assign (or reassign) the GPIO pins that you used.
1 Like
Hello everyone. Got my RatGDO in, but am having constant struggles getting it to connect to my Wifi. Running an Asus ZenWifi XT12 mesh system with 3 unique SSID’s (connecting all of my IoT stuff like the RatGDO to the 2.4g band). After doing some research, found this reddit. Changed my 2.4g network to stay on control channel 1, and the ratgdo will connect the first time after I load the ESPHome firmware for HA. But any time I cycle power to the RatGDO or my router, it struggles to connect. Normally it takes about 200-400 attempts to connect, and sometimes won’t connect at all until I power cycle.
Followed part of that reddit and changed my 2.4g control chanel to 1, but a bit confused on the 2nd part where it says to go into the ESPHome yaml and input the bit of code that keeps it connected to 802.11g only. I tried putting this code into my config.yaml but get an error stating that the ESPhome integration doesn’t support yaml config directly. Any ideas here?
Thanks
I may have just answered my own question by looking at @foreverimagining 's reply to the previous post. This is my first experience with any ESPHome device. If I’ve understood my own question properly, I need to update the yaml code in here.
Edit: I followed the ESPHome guide, put the config into the yaml file, and updated and downloaded using the ESPHome add-on. I can’t believe how easy that was considering I had no idea it even existed an hour ago! Will see how it does on restarts and the like.
Edit: After multiple restarts and moving the Ratgdo from my workshop PC into the garage, no issues with Wifi now!
It looks like the only open pins would be D4 which you advised against (thank you) and the TXD and RXD. I wish there was an easier way.
I wrote most of this response before I took more of a gander through the bluetooth section of ESPHome.
I’m not seeing anything offhand that looks like a separate bluetooth device being connected to a microcontroller like the HC-06. From the looks of it, the bluetooth components are so far designed for devices and microcontrollers that have bluetooth capabilities already built in and the ESPHome firmware is just tapping into the preconfigured hardware.
That doesn’t mean that it’s not possible. I could have missed something since I didn’t dive too deep, but more likely, it means that it will require some custom code to be used in conjunction with the other ESPHome functions, much like how the RATGDO does it. I’m afraid I won’t be able to help much with that.
I will, however, post the rest of my response because it may still prove useful if you want to consider further pursuit, or at least it could come in handy for someone at some point if they want to tack on an ESPHome-compatible component like the ultrasonic sensor that I added to my chimera RAT-RATGDO.
So, it’s not that you can’t use D4, but that you have to make sure that it won’t make funny things happen during boot when it is pulled HIGH. In the case of RATGDO v2.0, I believe the problem became that it would occasionally cause the GDO to trigger during boot and randomly open some people’s doors, if I remember correctly.
As for the others, I think I was probably mostly thinking of microcontrollers with more GPIOS, but this is where reassigning them comes into play. If you have, say, a Security+2.0 (or 1.0) GDO and only use the standard 3-wire installation technique, then you are only actually making use of the GPIOs D1, D2, and D7. If your GDO isn’t that smart and you have to use the Dry Contact side of the board to “manually” trigger the open, close, and light functions, you would probably only be using GPIOs D3, D5, and D6 and maybe D0 and D8 for statuses. If you are using everything, then you have a very interesting setup, and I might recommend going custom and making your own RAT-RATGDO.
What you would have to do physically, after choosing your GPIOs, would be to either solder a wire directly to the microcontroller pin, bypassing the extra components (diodes or mosfets and resistors), or you could probably solder the wire to the side of the component that goes to the pin (for this you would need a multimeter with a continuity function or something similar to determine which specific component goes to which pin).
Then, in the ESPHome configuration file, you can reassign the pin(s) you used like so:
substitutions:
status_obstruction_pin: none #assign no pin
bluetooth_tx_pin: D8 #assign the GPIO that goes to status_obstruction_pin
You can see the list of pins and their variable names in the substitutions section of the configuration file I linked to previously, then bluetooth_tx_pin or whatever you want to name your new variable can be used as a substitution or you could actually just assign the freed pin directly in the component configuration section.
I have a ratgdo running in esphome. I can open it to a specific percentage using
service:cover.set_cover_position
and providing a number (for example 20 for 20 percent. If i run the same call to the service the garage door closes. I was hoping it would see it is already at 20 and do nothing. Anyone know why it behaves this way?
I think it has to do with the way the ratgdo fakes knowing cover position. There isn’t anything exposed by the gdo itself that controls specific position. The only “thing” exposed to ratgdo (besides the light & obstruction sensors) is a basic momentary button (i.e. the same as an old doorbell, your original gdo button, etc.).
Pushing it once will start movement in one direction. Pushing it again (before it completes the open/close process) just stops it where it is. Pushing it a third time reverses the direction.
Behind the scenes, the ratgdo is just using this existing rudimentary logic to emulate opening to a specific position. What really happens is that the ratgdo (on first full open/close) counts the time required for the operation to complete. It then uses that total time to guess when to perform the second “stop” press of the button for a specific percentage. E.g. if the gdo takes 10 seconds to fully open and you want it open 20%, it does the following math: 10s * .2 = 2s. It then triggers the first “opening” event and waits 2 seconds and then triggers the button again, which stops it at (hopefully) roughly 20% of the way open.
There’s some flaws in that logic though - the open percentage is not totally linear in relation to the door speed. The motor takes longer to start so there might not actually be movement for a second or so, but that initial “warming up” is not accounted for in the calculations. Additionally, most of the gdos that I’ve seen don’t respond to well when the button is pushed in rapid succession. E.g. if you want to open in 15% and it takes 800ms for the door to really start moving, the second “stop” button push might occur too soon to the starting button push and it won’t recognize it all, opening the gdo all the way.
In general, these rough approximations make the cover position aspect of the ratgdo not very useful. In your specific circumstance, I would think that if the ratgdo received a request to open it to the exact same percent (or even a different amount in a very close range), it would be able to completely ignore the request. However, given that you are experiencing this issue, I’d venture to guess that this check is not in place right now.
1 Like
Thanks. That makes sense. I was testing an automation that runs when I am home and the garage gets over 90 degrees. It would raise the door partially. So I tested today. Door raised and garage cooled to below 90. But then it went back over 90 an hour or so later and it ran and closed the door ;). Not sure I really plan to keep the automation.
If it’s in an automation, you could work around it by adding a conditional that only trigger the set position call if the current state is closed (or at least a certain delta away from the desired open percentage). Not perfect but it should suffice for your intent I think?
Use service cover.set_cover_position
EDIT
Disregard. Weird bug
If you call cover.set_cover_position for same position the second call closes cover. That doesnt seem correct
I’m relatively sure you’re incorrect here, at least as it pertains to the full Security+ 2.0 implementation.
If I use my remote (a system totally outside the ratgdo wireline observation), ratgdo knows that the door is moving. If I stop it halfway up, then close it, it knows it is closed. Also, if the door hits something on the way down and auto-reverses, ratgdo knows it is open.
While I believe you’re correct in your understanding of percent-open (it’s based on timing the door open/close, then pausing it on the way), the ratgdo cover entity maintains exactly how open the door is, and I would have expected that instructing it to 10%, then again to 10% would mean it didn’t move.
I expected same as you. No movement if call same percentage.
I tested on my door after my initial post becase i wanted to confirm it will work as expected since i never tested but recommended to another user.
cover.set_cover_position 29% >> garage open 29% >> cover.set_cover_position >> garage close
This was result
I confirm on 2 garage door in UI only but I think result is good. Both door are different model with different ratgdo but same esp config
At least one door is security+ 2.0. Pretty sure both are
I was speaking in terms of ratgdo knowing how open the gdo is, not the fact that it is moving. It does know when the motor is spinning, but the actual calculation of percentage is a guesstimate at best. I haven’t looked too deeply into the esphome code for ratgdo, but if @billraff was saying that issuing the same exact set cover position multiple times was causing the gdo to move, it likely doesn’t have checks in place to prevent this. I used to run the esphome version, but had some interference issues (e.g. pressing the open button immediately after entering the garage wouldn’t register, as I think the motion sensor command was hogging the wireline comms), so I can’t fully test this. I’m just going by what seemingly a couple people have now reported.
Your comment seemed to be saying that ratgdo didn’t even know if the door was open or closed except by assumption.
It is true that ratgdo would only know if the door was open, opening, closing, or closed… Because that’s all the gdo knows.
I’d be interested to know if it always closes, too. I don’t have time to play with it right now, but it is possible starting from closed and asking for 20% twice would result in a different end state than starting from open and asking for 20% twice.
From my experience, the opening % is a guesstimate, and seems (to me) to be based on the “taught” open and close time you input into the ratgdo. From there, the percentage is just a percentage of those open and close times. For me, it’s pretty repeatable if your GDO opening and closing cycles are repeatable, and you time them properly.
I haven’t had any issues with delays or the ratgdo not registering. My responses are lightning fast, and have never not registered any of my inputs through HA.
Yes, the times are generally repeatable, e.g. my GDO always takes almost exactly 9 seconds to fully open/close. My point, however, is that it is not completely linear (at least for my GDO).
From the moment the command is issued to the time my GDO actually starts moving is around 700ms. Given my 0-100% time is approximately 9000ms, using linear extrapolation, it should be almost 8% open at the 700ms mark (700 / 9000). However, due to that small initial delay (getting the motor started, gear fully engaged and torqued up enough to start moving the door), the open percentage at 700ms is actually 0%. I initially thought about trying to “correct” this by artificially adjusting the total open/close time to account for the delay. However, since it’s non-linear, you can’t just add the 700ms; you’d need a firmware update that essentially allows for a manual start delay before it begins calculating percentage open.
Also, regarding the non-registering events, when I said “pushing the open button”, I was referring to my physical GDO switch at the garage entrance. I have a separate zigbee motion sensor paired with an automation that calls the light.turn_on service for the GDO light (I disabled the built-in motion sensor as it wasn’t responsive enough and the positioning wasn’t great for initial detection).
What I think is happening is my motion sensor detects motion as soon as I enter the garage and the automation sends the light.turn_on command to the ratgdo. However, at almost the exact same time, I also happen to be pushing the GDO wall switch. It’s a bit of a race condition, where either the switch or the automation tries to communicate with the GDO, blocking the other almost simultaneous command (seems to be a 200-300ms blocking window from my manual testing). If I pause just an extra quarter/half second when entering the garage before pressing the button it works fine, but it’s muscle memory for me when going to my car to just press it as soon as I open the door 
I don’t know why, but I don’t experience the same blocking conditions with the MQTT version. I tried briefly going through the code differences but the MQTT and ESPHome have diverged quite a bit and I’m not familiar enough with C++ to easily spot possible differences in the communication protocol.
Outside this minor blocking issue with simultaneous commands, the responses are indeed lightning fast. Perhaps that speed is part of the reason that I’ve even run into this race condition with my hand 
In any event, I did like the ESPHome variant overall, but the seemingly longer blocking period when issuing commands, along w/ the somewhat inaccurate open/close percentage convinced me to switch back to the MQTT version. If others don’t experience these (minor) issues, that’s awesome! I love ESPHome in general and am glad that it’s a viable option for many!