Loss of WiFi and loss of power may show the same. I would expect that signal/connection would be weak in case of WiFi disconnect or you would see some communication errors.
Logs may show reboot and definitely show WiFi connections
Loss of WiFi and loss of power may show the same. I would expect that signal/connection would be weak in case of WiFi disconnect or you would see some communication errors.
Logs may show reboot and definitely show WiFi connections
@actran70 . Thanks for your info. I am using the original MQTT firmware. I am not familiar with ESPHome having not used it before.
I think I have fixed the wifi signal problem by switching the Wifi to a different channel in the router.
What’s interesting is that I have a second ratgdo attached to a newer Sec 2.0 opener and I can see that it was also losing Wifi and also sending a “close” command on reconnect. But Since it’s Sec 2.0 and knows the correct status of the door, since it is already closed, the close command has no effect.
Thanks again
Nesan
@tmjpugh . Thanks for your help. I think I have fixed the problem by switching to a different channel in the router. Wifi has been stable for 18 hours now with no reconnects.
Thanks
Nesan
So I think I figured out what was causing the door open… In looking at my MQTT messages with MQTT Explorer, I found a retained open door command. From my limited understanding of MQTT, I believe this means that any client who subscribes to the topic will receive retained messages. So presumably that is why it was opening the door on reconnection or reboot.
I unchecked the retain flag and all seems to be OK. I still see door open/close messages upon reconnect in HA but nothing happens on the door. Now when I open or close the door through HA, I see the open/close command in MQTT Explorer but it is not retained.
Thanks
Nesan
@Nesan ESPHome firmware will give you access to more controls and sensors (versus original MQTT based firmware). In my experience with both, it is also more responsive because it communicates directly with HA and not via MQTT.
Side note, if you are ambitous and you know ESPHome, you can then modify ratdgo behavior via firmware yaml.
If you haven’t done so, install ESPHome add-on to your HA first.
Great, that did the trick . Thank you very much, how could I have known?
Anyway the light status seems not to be correct in every case, the switch acts more like a toggle. Means if light is “on” after opening/closing the garage and switches off automatically after some time, the status in home assistant does not change to “off”. If I toggle the HA switch to “off”, the light turns on and so on. Any idea for this ?
I setup my 2.5i board today and yesterday! ESPHome was not able to control anything or get any information on my RJO20 jack shaft – which is apparently a mix between security 1/2. So, I flashed back to the MQTT version (after some time figuring out how to setup a broker with an HA docker installation) and I now have controls I need.
I really wish it would work with ESPHome if there truly are more controls with it.
I installed my second ratgdo today with MQTT firmware. The first opener is a Security+ 1.0 opener and worked as expected, including preventing the wall button from operating the light or locking out external remotes.
The second door is older and was setup using dry contacts. I bought these magnetic reed switches from Amazon, and wired the NO to open, NC to close, and COM to GND on the ratgdo. The door seems to work fine, but I’ve noticed that it doesn’t close with the service call cover.toggle, which works fine on my Security+ 1.0 opener.
EDIT: I was using action: call-service
and service: toggle
in a custom button card to toggle the door, which worked fine with MyQ integration and ratgdo/Security+ 1.0 doors. However, this doesn’t work with my dry contact door. Instead, action: toggle
works fine with both types of doors, so I’ve updated my custom card to use the new action. The following can correctly open and close the door, which wasn’t working with the previous service call:
type: custom:button-card
entity: cover.maxgarage_door
show_icon: true
show_name: true
tap_action:
action: toggle
name: Max's Garage
icon: hass:garage
state:
- value: open
icon: hass:garage-open
color: rgb(255,0,0)
- value: closed
color: rgb(68,115,159)
It’s not even a momentous improvement over the standard button card. It’s just more visually appealing to me to have blue for closed and red for open.
I cannot get my ratgdo to respond at all. I think I have doa hardware. I sent email to the gmail address listed for support but no reply so far. The ch341 does not show up on lsusb on multiple Linux systems and it doesn’t show up on system report on multiple macs. Other ch340 series chips are recognized as expected on those systems.
I’m not upset about the doa hardware, stuff happens, but I’d really like to know how to get it replaced.
Hi all, I’m not sure if this is the right thread to post this question: My ratgdo shipment was messed up by USPS, and they could not find it even after a package search. How do I get in touch with @PaulWieland to figure out a way through this situation?
I cant wait to get my hands on the board and install it
I received my board a few weeks ago and set it up with ESP home firmware. Everything worked exactly as I would expect. I could control the light. I got motion sensor events. I could open and close the garage. However, 2 weeks ago it just quit working. I would get all of the status updates like when the light changed or motion sensor event happened, but I could not control anything even directly from the device web interface. I tried to push button trick with sync and open/close of the garage door but no luck. With the great advice from this thread, I pulled out my wires and carefully push them back in but not too far. Making sure that I had a good connection. I pulled on the wires a little bit just to make sure nothing came out. Now everything is working again. It seems implausible to me that the wires connected just enough to work initially and then apparently one wire must have lost a connection but not enough that I wouldn’t get status updates from the garage door opener. It seems to be working now. I measured the exact time it took to open and close from pushing a button and then updated that number in my ESP home device interface page.
I had a similar issue trying to set up the ratgdo on my Linux Mint system. Tried a bunch of different things, and then tried an old Windows system which was able to init the board without any issues.
I don’t have any windows systems to try, and as near as I can tell, the esp module isn’t even booting up when usb power is applied. (No onboard led indicator, nothing). I am pretty sure I have DOA hardware and hopefully Paul will respond somewhere soon-ish.
I just received mine a couple days ago, but am in the process of flashing mine too. I had the same exact issue, and it was the USB cable. I had to go through 3 cables before I found one that was power AND data. Most of my cable turned out to be power only. Which should be fine for operation, but obviously not for flashing.
Also make sure you have the drivers for the device loaded
CH341SER.EXE - NanjingQinhengMicroelectronics (wch-ic.com)
I’m using the cable shipped with my ratgdo and it seems to work with other ch340 series uarts. So pretty sure that’s not my issue.
@PaulWieland Rec’d my ratdgo 2.5i kit – many thanks.
Home Assistant (HA) – ratgdo will not open or close or stop garage door.
Flashed ratgdo using web interface for my mqtt broker. All went well. Connected ratgdo to my LiftMaster JackShaft Model 8500 garage door opener. Verified all wiring, and verified solid wire connections in terminals.
Original garage door opener wiring:
Mqtt broker has added ratgdo. It shows as a device in mqtt.
HA auto discovered ratgdo. Verified all LiftMaster 8500 garage door opener remotes work, external keypad and indoor push button all function normally, as does the obstruction sensor.
Verified on HA, when obstruction sensor is blocked, HA displays not clear. When obstruction removed, HA shows cleared.
But – select up or down arrow or stop square on HA….nothing happens.
(Note: I have a jackshaft model and there is no light on this garage door.)
Since all remotes and wall switch work, this – to me – verify the wiring is correct.
Took logs of attempts to open and close garage door via HA/ratdgo.
QUEUE MSG ARRIVED [garage_doorratgdo-garage/command/door]
open
MQTT: open the door
rolling code for 88|door1 : 5xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxXXXXXX
rolling code for 88|door2 : 5xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxXXXXXX
Write successful
QUEUE MSG ARRIVED [garage_doorratgdo-garage/command/door]
close
MQTT: close the door
rolling code for 89|door1 : 5xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxXXXXXX
rolling code for 89|door2 : 5xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxXXXXXX
Write successful
QUEUE MSG ARRIVED [garage_doorratgdo-garage/command/door]
stop
MQTT: stop the door
The door is not moving.QUEUE MSG ARRIVED [garage_doorratgdo-garage/command/door]
close
MQTT: close the door
rolling code for 90|door1 : 5xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxXXXXXX
rolling code for 90|door2 : 5xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxXXXXXX
Write successful
{l l��| �l�|�l�c|���e�s�#�c��og�$g'���bx��${$sd8�o��l��co�<���#��gn� l��l`�e'o�alan{���o{;�`x�'�;������c'�|�#��gn� �l`�eno�adaorǛ�gr$`{��o{d`���lsl ��'�d
Mounting LittleFS...
[setup.json]
JSON parsed
Storage OK, restoring WiFi and MQTT config.
DPsoftware domotics
Connecting to:
"myWifi"...
Using static IP address
Set WiFi output power to: 20.50
.
WIFI CONNECTED
IP Address: xxx.xxx.x.xx
nb of attempts: 1
IMPROVhttp://xxx.xxx.x.xx�
WiFi connected
Local IP: xxx.xxx.x.xx
SoftAP IP: (IP unset)
Server started
Launching webserver for improv
Starting ArduinoOTA service
doorCommandTopic: garage_doorratgdo-garage/command/door
lightCommandTopic: garage_doorratgdo-garage/command/light
lockCommandTopic: garage_doorratgdo-garage/command/lock
Setup Complete
_____ _____ _____ _____ ____ _____
| __ | _ |_ _| __| \| |
| -| | | | | | | | | | |
|__|__|__|__| |_| |_____|____/|_____|
version 2.1
Syncing rolling code counter after reboot...
rolling code for 91|reboot1 : 5xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxXXXXXX
rolling code for 92|reboot2 : 5xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxXXXXXX
rolling code for 93|reboot3 : 5xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxXXXXXX
rolling code for 94|reboot4 : 5xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxXXXXXX
rolling code for 95|reboot5 : 5xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxXXXXXX
rolling code for 96|reboot6 : 5xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxXXXXXX
Write successful
IMPROVhttp://xxx.xxx.x.xx�
### MQTT DISCONNECTED ###
Connecting to
MQTT Broker...
MQTT Last Will Params:
willTopic: garage_doorratgdo-garage/status/availability
willPayload: offline
qos: 1
retain: 0
clean session: 1
MQTT CONNECTED
Reading data from
the network...
TOPIC SUBSCRIBED [garage_doorratgdo-garage/command/#]
TOPIC SUBSCRIBED [garage_doorratgdo-garage/set_code_counter]
QUEUE MSG SENT [homeassistant/cover/ratgdo-garage/config]
{
"~": "garage_doorratgdo-garage",
"name": "ratgdo-garage",
"unique_id": "ratgdo-garage_xx:xx:xx:xx:xx:xx",
"availability_topic": "~/status/availability",
"device_class": "garage",
"command_topic": "~/command/door",
"payload_open": "open",
"payload_close": "close",
"payload_stop": "stop",
"state_topic": "~/status/door",
"device": {
"name": "ratgdo-garage",
"identifiers": "ratgdo-garage_xx:xx:xx:xx:xx:xx",
"manufacturer": "Paul Wieland",
"model": "ratgdo",
"sw_version": "2.1",
"configuration_url": "http://xxx.xxx.x.xx/"
}
}
QUEUE MSG SENT [homeassistant/light/ratgdo-garage/config]
{
"~": "garage_doorratgdo-garage",
"name": "ratgdo-garage Light",
"unique_id": "ratgdo-garage_xx:xx:xx:xx:xx:xx_light",
"availability_topic": "~/status/availability",
"command_topic": "~/command/light",
"payload_on": "on",
"payload_off": "off",
"state_topic": "~/status/light",
"device": {
"name": "ratgdo-garage",
"identifiers": "ratgdo-garage_xx:xx:xx:xx:xx:xx",
"manufacturer": "Paul Wieland",
"model": "ratgdo",
"sw_version": "2.1",
"configuration_url": "http://xxx.xxx.x.xx/"
}
}
QUEUE MSG SENT [homeassistant/binary_sensor/ratgdo-garage/config]
{
"~": "garage_doorratgdo-garage",
"name": "ratgdo-garage Obstruction",
"unique_id": "ratgdo-garage_xx:xx:xx:xx:xx:xx_obs",
"availability_topic": "~/status/availability",
"device_class": "motion",
"state_topic": "~/status/obstruction",
"payload_on": "obstructed",
"payload_off": "clear",
"device": {
"name": "ratgdo-garage",
"identifiers": "ratgdo-garage_xx:xx:xx:xx:xx:xx",
"manufacturer": "Paul Wieland",
"model": "ratgdo",
"sw_version": "2.1",
"configuration_url": "http://xxx.xxx.x.xx/"
}
}
QUEUE MSG SENT [garage_doorratgdo-garage/status/availability]
online
Obstruction status clear
QUEUE MSG SENT [garage_doorratgdo-garage/status/obstruction]
clear
Your help in this matter to resolve this issue and get the garage door to function is greatly appreciated.
The only issue I have with using two Ratgdo devices is maintaining the WiFi connection. Both devices are actually very close to the router, which is less than 20’ through drywall/wood joists/flooring in the story above.
The connection sporadically drops, say once a week on one device or the other, and remains down for a few hours. Cycling power seems to work most of the time, if I even bother with it; usually I just wait for the connection to come back as it usually does. The last time it happened was last night for a few hours; I’ve set up an automation that turns on an LED indicator to show me when one or both of the garage doors becomes “unavailable.”
Anyone have insight into this?
Assuming there are times when both are connected just fine (i.e. they didn’t happen to end up with the same hardware address by chance), the issue is likely with your network config.
Have you checked to see that the size of your DHCP pool is ~50% bigger than the maximum number of devices you would connect?
You could also consider assigning these two devices reserved IPs in your router – that way they always get the same addresses.
Bottom line, this is almost certainly not a ratgdo deficiency, but an issue with your router, router configuration, or other network issue.
OK, I’m willing to accept that… but all devices (including the ratgdos) have assigned IPs at the router, and these are the only two devices that are having disconnect problems. Most devices are much farther away from an access point.
My DHCP pool is 200 addresses, I think, and I probably have less than 70 connected. I’ll make sure that’s the case in the next few hours.
It sounds like there’s nothing inherent in the device that would result in disconnects. It’s right on the edge of being inconvenient enough to add a power-cycle automation, but that’s a last resort.
EDIT: Ah, I allotted x.200 - x.254 to DHCP. All of the known devices get assigned an IP between x.1 - x.199. 45 devices connected at present (including the ratgdos), with several others inactive.
I have no real insights.
ESPHome or mqtt firmware? I’m using ESPHome.