Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

1.8.2 - RATGDO Bootloops / unrecoverable if SEC+ is selected for Door Protocol #252

Open
zacshann opened this issue Nov 23, 2024 · 5 comments

Comments

@zacshann
Copy link

After upgrading from 1.8.1 to 1.8.2 on two v2.53 boards both units went unresponsive after installation, I let them sit overnight and they had not recovered so I went about trying to reflash them. After multiple tests / reinstalls of 1.8.2 it appears if the device is set to SEC+ for the door protocol before upgrading to 1.8.2, or is switched to it after installing 1.8.2 the device boot loops and becomes unresponsive / cannot recover.

Both showed similar symptoms after initial upgrading from 1.8.1 to 1.8.2:

  • Unit shows up in client devices on Unifi controller as active
  • Units has sporadic pings / timeouts loop (6 responses, 2/3 timeouts, 6 responses, 2/3 timeouts)
  • Web Interface unavailable
  • Homekit unresponsive

After initial reflash of firmware 1.8.2:

  • Unit shows up in client devices on Unifi controller as active
  • Unit has consistent pings again, no timeouts
  • Web Interface available

Testing 1.8.2:

-- Changing a no reboot required setting like the name works as expected, device still responsive
-- Rebooting the unit with no settings changes works successfully, device still responsive
-- Changing a reboot required setting that isn't the door protocol like Wifi TX power reboots and applies setting successfully, device still responsive
-- Changing Door Protocol to SEC+ from SEC2.0 causes device reboot as expected by device does not recover and goes into boot loop (see attached log file) and experiences same symptoms as the initial upgrade from 1.8.1 to 1.8.2 mentioned above, log files hint to panic/abort and loop sequence.

If I can provide any additional information or help please let me know.

Log File from one unit in active boot loop after setting SEC+:
esp-web-tools-logs.txt

@dkerr64
Copy link
Collaborator

dkerr64 commented Nov 23, 2024

Thanks for reporting this. I will investigate later today.

dkerr64 added a commit that referenced this issue Nov 23, 2024
Quick fix for #252 as it appears using IRAM heap in HomeKit module does not work for Sec+1.0... which I cannot explain because it should have nothing to do with that part of the code.
@dkerr64
Copy link
Collaborator

dkerr64 commented Nov 23, 2024

Fixed in 1.8.3

Thank you for reporting this, and my apologies for introducing this bug. It highlights the importance of more thoroughly testing before pushing a new release.

Even though I do not have a ratgdo connected to a Sec+ 1.0 door, I was able to reproduce this bug. It is an odd one, as the "fix" reverts a memory management change made to the HomeKit component that should have nothing to do with which door protocol is selected.

Unfortunately the crash is so early in the boot process that the only way for you to recover will be to flash the new release using the USB cable, just like an original install. Do not select to erase the device so all your settings are preserved.

Thank you, and again my apologies.

@zacshann
Copy link
Author

zacshann commented Nov 23, 2024

Hey @dkerr64,

You're very welcome, and no apologies necessary! Its definitely a strange bug that's for sure. I'm just glad my report was helpful. :)

Thanks for fixing so quickly (and on a weekend), I can confirm after flash 1.8.3 & enabling SEC+ 1.0 everything appears to be working as expected. No worries on preserving settings. I wiped both units a few times to make sure I was able to reproduce the original issue consistently before submitting the bug report, luckily a lot of the QoL updates you've added make reconfiguring these units super easy so its really no big deal.

Regardless I really appreciate all the effort and time you put into this project, thanks again and have a great rest of your weekend.

@dkerr64 dkerr64 closed this as completed Nov 23, 2024
@hectcastro
Copy link

Hey @dkerr64,

Apologies for waking up this thread a few weeks after it closed, but I believe I encountered this same issue with my v2.53i after upgrading to version 1.8.2. In an attempt to fix tings after seeing this thread, I flashed version 1.8.3. However, I am still experiencing issues that weren't occurring with 1.8.1:

  • Unit shows up in client devices on UniFi controller
  • Unit has consistent pings, no timeouts
  • Web interface unavailable (requests timeout)

The HTTP server generally isn't responsive, but on some occasions it responds with bits and pieces of the administrative UI, but not all of it. I've attached the logs in case something in there stands out.

esp-web-tools-logs.txt

@dkerr64
Copy link
Collaborator

dkerr64 commented Dec 9, 2024

@hectcastro this does look very similar, I don't have any ideas right now but I'll look at it more thoroughly when I get time.

@dkerr64 dkerr64 reopened this Dec 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants