ratgdo / esphome-ratgdo

ratgdo for ESPHome
GNU General Public License v2.0
355 stars 104 forks source link

retrieve rolling code? Same as #51 #96

Closed odinb closed 1 year ago

odinb commented 1 year ago

Also getting the "Failed to communicate with garage opener on startup; Check the Garage-Door RATGDO East Rolling code counter number entity history and set the entity to one number larger than the largest value in history."

Found this response in #51: You can dig though the database to find the code from the old number entity. Look up the entity in states_meta and than link it to states. Or factory reset the GDO by pressing and holding the pair button 3 times for 15 seconds. Than repair the wall control by pressing it, and repair all your remotes. The ratgdo esp device should than be able to pair

How does one go through the database looking for "states_meta"? What commands should I use? I am not a DBA...

Can I get it via the REST_api? Like here: https://developers.home-assistant.io/docs/api/rest/ Could you give examples of what strings to use?

bdraco commented 1 year ago

You could change the client id instead If it still doesn’t work you likely have a wiring issue

alienator88 commented 1 year ago

Was going to open an issue for this as well, but might as well chime in here since I'm seeing the same "Failed to communicate" error.

Background:

Just got the shield today. I had a d1 mini flashed with v2.0 firmware for a month waiting for the backorder. Today I installed it on the shield and didn't think about checking if there was new firmware for v2.5 board since I got that one shipped to me instead of the v2.0 I bought, slipped my mind. Plugged it in and didn't seem to work, but also didn't check the rolling code unfortunately. I then took the d1 mini and flashed it again with the v2.5 firmware.

Status:

I can toggle the door, light etc. and the logs show it attempting, but nothing happens. Just seeing these constantly after every action:

20:49:34    [W] [component:214] Component preferences took a long time for an operation (0.06 s).
20:49:34    [W] [component:215] Components should block for at most 20-30ms.

But I do see live door stats, like if I turn the light on manually, it instantly updates in the entity. So it seems to be reading all the data fine, just unable to do actions to it.

Troubleshooting:

I tried changing the client id and setting the code counter to 0 and restarting the ratgdo. Not seeing anything different so far. Are there no instructions anywhere for resetting back to default and starting fresh? Only thing I haven't done is try to reset the GDO itself, was seeing if there's a way around this without having to re-pair everything. I rechecked the wiring a couple times already, just not much to check there, it's just 3 wires and they're inserted and snug in the holes on both ends. Can I get some debug logs from ESPHome? If that would help?

Just feel super stuck right now if anybody has any advice. Thanks!

odinb commented 1 year ago

You could change the client id instead If it still doesn’t work you likely have a wiring issue

Yup, that did the trick! Changed "Client ID" under "Actions" in the Web-GUI. But the number under "State" is still the same old one? On my west door, those 2 match. Anything I need to do to get them to match? Started working immediately after changing! Thanks!

Does this mean I will have an unused controller in memory until next time I reset remotes?

odinb commented 1 year ago

Updated the ESPHome version (2023.10.5 > 2023.10.6), and it seems the "client ID" changes when the RATGDO reboots? So I guess the concerns about IDs not matching and unused controllers are unwarranted, or?

mariusmuja commented 1 year ago

I tried changing the client id and setting the code counter to 0 and restarting the ratgdo. Not seeing anything different so far. Are there no instructions anywhere for resetting back to default and starting fresh?

Changing the client_id is like starting fresh from the GDO's point of view (it doesn't matter what the rolling code is when you change the client_id, but once you send the first command, the rolling code can only increase from that point on).

When you change the client_id is normal for the first command to be ignored, but the following ones should start working. A simple test is change the client_id and toggle the light from Home Assistant a couple times and it should toggle the GDO light. If that doesn't work, you have something wrong with the wiring. Since you seem to be able to receive the GDO status, the wiring from the board to the GDO should be correct, so you might be using the wrong TX pin (wrong firmware, for example board 2.0 was using pin D4 for TX and board 2.5 is using pin D1).

alienator88 commented 1 year ago

Tried the simple test and no changes unfortunately. Just seeing those same component errors when it attempts to save preferences to flash. Also tried upping the codes based on some info I saw on Paul's repo issues and then clicking sync. It tries for a while to save to flash and fails with Triggering sync failed actions

I hope it's something firmware related, here's my details: I'm using a d1_mini, but have the firmware for board 2.5 for d1_mini_lite flashed. Are the pins incorrect? This is what I'm using: https://www.amazon.com/Organizer-ESP8266-Internet-Development-Compatible/dp/B081PX9YFV

This probably doesn't matter, but I flashed v25board_esp8266_d1_mini_lite.yaml and the package url points to v2board: github://ratgdo/esphome-ratgdo/v2board_esp8266_d1_mini_lite.yaml@main Again, probably doesn't matter in this case if only pins changed. So maybe something to do with d1_mini vs d1_mini_lite? I've tried using the yaml directly as well and setting this to d1_mini:

esp8266:
  board: d1_mini_lite
  restore_from_flash: true

Thank you so much for replying!

bdraco commented 1 year ago

This probably doesn't matter, but I flashed v25board_esp8266_d1_mini_lite.yaml and the package url points to v2board: github://ratgdo/esphome-ratgdo/v2board_esp8266_d1_mini_lite.yaml@main

Actually thats probably the problem

alienator88 commented 1 year ago

Ah okay..wasn't sure if there was much in terms of firmware changed between v2 and v2.5, thought it was just the pins. Good to know, I'll keep an eye on the pull request and test it when ready.

alienator88 commented 1 year ago

That fixed it, thank you so much everyone!