Wall button clock resets on update/reboot?

[hacsjalano]

I'm not sure if I'm the only one with this problem, but the wall button clock for the garage door opener resets to 12:00 whenever I apply an update or reboot the device.

As far as I know this is the only time it happens, but it is slightly annoying to have the clock flashing 12:00 and then I have to set it again manually.

Is the clock settable via the ratgdo, or is there something that can be done like shutting down the pins before applying an update that can prevent this?

[mariusmuja]

What hardware are you using for interfacing with the garage door opener?

I believe you might be using ratgdo version 2.0 which uses pin D4 (GPIO2) for TX. This pin is pulled high at boot and because the same line is used for power (+12V) and communication with the wall button, when the esp reboots and pin D4 is pulled high the communication/power line is pulled low and the wall button is without power for longer than the internal capacitor(s) can supply. This might be the reason why version 2.5 of the board switched to using pin D1 as TX instead of D4.

Unfortunately there is no change to esphome-ratgdo that can fix this, if you're comfortable with a soldering iron you could change the TX pin on your ratgdo shield to D1 and use version 2.5 of the firmware.

[hacsjalano]

Aha, that makes sense - I do have a version 2.0 board. It's a small annoyance, but I'm glad that it's behaving as expected. At first I was worried that I had wired up something wrong and this wasn't supposed to happen.

I can live with it. Thank you for your explanation and putting my mind at ease on this!

[hacsjalano]

Just did a bit more testing - it appears this happens whenever I reboot Home Assistant as well, with no firmware update. It seem the ESP attempts to reboot when it can't see Home Assistant?

As far as I can tell, this didn't happen with the MQTT version of the firmware. Is there something I can do to test this on my setup to confirm? Are there on-board logs for the ratgdo stored someplace I can examine?

[mariusmuja]

Just did a bit more testing - it appears this happens whenever I reboot Home Assistant as well, with no firmware update. It seem the ESP attempts to reboot when it can't see Home Assistant?

Yes, esphome reboots if no client (Home Assistant) connects to it for a certain period of time, see option reboot_timeout here. You could prevent this by setting reboot_timeout to 0 in v2board_esp8266_d1_mini_lite.yaml (assuming you use esp8266, otherwise use v2board_esp32_d1_mini.yaml):

api:
  id: api_server
  reboot_timeout: 0

and re-flashing with esphome run v2board_esp8266_d1_mini_lite.yaml

[hacsjalano]

Thank you - that works. For anyone else reading and for my future self:

The link to the documentation about the reboot_timeout is here:

https://esphome.io/components/api.html

In my case, when I added my device to Home Assistant it "adopted" it and created a new yaml file in /config/esphome/ratgdo.yaml (my device name was called "ratgdo") so I had a new, smaller stripped-down version of the file in my config directory.

The api: section looked different; it did not have the "id: api_server" but I did just add the reboot_timeout: 0s to it.

It appears it needs to be "0s" and not "0" for the compiler to be happy.

I can confirm that restarting Home Assistant now no longer resets my wall button unit!

[hacsjalano]

I celebrated too soon. :( On further inspection it appears the wall door unit loses power whenever I reboot my Home Assistant server to apply an upgrade or for any reason I need to restart it, in addition to whenever I update the ESPHome firmware on my ratgdo device. I also noticed that when I closed the door using the ratgdo, as the door closed the wall display would dim and often blink as if it was losing power.

So I decided to flash the official ratgdo firmware which uses MQTT only, version V2.2 and see if it has the same issue, since I was concerned that it may be my wall unit that is to blame (maybe it has weak or dying capacitors, which apparently is an issue with these wall units).

I've been using the official ratgdo firmware for a few days now and it has not lost the clock time, regardless of how often I've rebooted my Home Assistant instance.

So my theory is that the ESPHome firmware does something slightly more aggressive than the standard firmware, even when opening/closing the door. I'm not sure what that is.

I would like to go back to the ESPHome ratgdo firmware, because I really like the lock-out wireless remotes feature.

If there is anything I can do to help debug this issue let me know!

[hacsjalano]

Oh, and regarding changing the pin on my ratgdo shield - I am comfortable with a soldering iron, but maybe I'm missing exactly what modification I should make to change the pin - isn't that basically a trace on the circuit board? Am I cutting a trace to do this change?

[mariusmuja]

On further inspection it appears the wall door unit loses power whenever I reboot my Home Assistant server to apply an upgrade or for any reason I need to restart it

Can you watch the esphome console (in the eaphome web page for example) while you're restarting Home Assistant and see if it reboots? I don't see why else the wall button would be loosing power...

I also noticed that when I closed the door using the ratgdo, as the door closed the wall display would dim and often blink as if it was losing power.

This would happen any time a transmission happens on the line. When closing the door the esp is sending the button press command, then the button release command, then the GDO responds with the status command. For any transmission, depending on the bytes transmitted, the power line is lowered to ground very shortly, which would explain the dimming. But this should be the same (similar at least, timings might be different) on the ratgdo firmware.

[mariusmuja]

Oh, and regarding changing the pin on my ratgdo shield - I am comfortable with a soldering iron, but maybe I'm missing exactly what modification I should make to change the pin - isn't that basically a trace on the circuit board? Am I cutting a trace to do this change?

Yes, you'd be cutting the trace between resistor R3 and pin D4 and soldering a jumper wire from R3 to the other side of the board on the D1 pin.

[hacsjalano]

Is there a way to watch the logs directly on the device itself without using the ESPHome console? My Home Assistant instance is using the virtual machine which hosts ESPHome as a container on it. When I restart the virtual machine, all of the containers go down with it as well.

[mariusmuja]

Yes, you can look at the device's web server, just open the device ip address in a browser.

[hacsjalano]

These are my logs just after booting - this is without attempting to open/close the garage door yet. logs.txt

[mattfox27]

I have this same issue, so 2.5 fixes it?

[hacsjalano]

@mattfox27 I have the 2.0 hardware, and so use the 2.0 firmware, and it's still an on-going issue for me. I reverted back to using the official ratgo firmware that uses MQTT and that causes this to happen much less often. I still get the occasional "press to re-connect" on the wall unit, so i think it is losing power occasionally. It may be that my capacitors are weak on this unit; the wall unit is over 11 years old now. I debated about replacing the wall unit (it's an 880LMW) but it would cost me $50 and I'm not sure it's really worth it right now. The only feature it has is displaying the backup battery status; if the ESPHome firmware could show me the backup battery level then I could replace the 880LMW with a $11 883LMW simple switch (or even just disconnect it entirely) and I wouldn't have to worry about whether it lost power briefly.

[mariusmuja]

Yes, you'd be cutting the trace between resistor R3 and pin D4 and soldering a jumper wire from R3 to the other side of the board on the D1 pin.

You could convert a v2.0 board to a v2.5 firmware without any trace cutting: solder a wire on the ESP side of R3, route the wire to the back of the board and solder it to D1 pin. Then, break off the D4 pin from the ESP module and flash a v2.5 firmware on it.