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

[safe_mode] Allow user-defined interval for successful boot #6882

Merged
merged 4 commits into from
Jun 12, 2024

Conversation

NMartin354
Copy link
Contributor

@NMartin354 NMartin354 commented Jun 10, 2024

What does this implement/fix?

Adjusts the reboot timeout to a single function instead of serving two functions

Types of changes

  • Bugfix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Other

Related issue or feature (if applicable): fixes

Pull request in esphome-docs with documentation (if applicable): esphome/esphome-docs#3930

Test Environment

  • ESP32
  • ESP32 IDF
  • ESP8266
  • RP2040
  • BK72xx
  • RTL87xx

Example entry for config.yaml:

# Example config.yaml
ota:
  password: !secret ota_password
  reboot_timeout: 5min
  attempt_timeout: 5min

Checklist:

  • The code change is tested and works locally.
  • Tests have been added to verify that the new code works (under tests/ folder).

If user exposed functionality or configuration variables are added/changed:

Adding attempt time to the call
Adding definition of attempt time
@probot-esphome
Copy link

Hey there @jsuanet, @kbx81, @paulmonigatti, mind taking a look at this pull request as it has been labeled with an integration (safe_mode) you are listed as a code owner for? Thanks!
(message by CodeOwnersMention)

@kbx81
Copy link
Member

kbx81 commented Jun 10, 2024

In the doc update, you refer to attempt_timeout but have not exposed that configuration variable to the user via config. Please update this PR to do so.

Also, all CI/tests must be passing before we will review the PR. Thanks for working on this!

@kbx81 kbx81 changed the title Differentiate between the safe mode failed boot timeout and safe mode reboot timeout [safe_mode] Allow user-defined interval for successful boot Jun 10, 2024
@jesserockz jesserockz marked this pull request as draft June 10, 2024 22:16
@codecov-commenter
Copy link

codecov-commenter commented Jun 11, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 53.91%. Comparing base (4d8b5ed) to head (81888b2).
Report is 737 commits behind head on dev.

Additional details and impacted files
@@            Coverage Diff             @@
##              dev    #6882      +/-   ##
==========================================
+ Coverage   53.70%   53.91%   +0.20%     
==========================================
  Files          50       50              
  Lines        9408     9625     +217     
  Branches     1654     1698      +44     
==========================================
+ Hits         5053     5189     +136     
- Misses       4056     4112      +56     
- Partials      299      324      +25     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@kbx81 kbx81 marked this pull request as ready for review June 11, 2024 23:27
@probot-esphome
Copy link

Hey there @jsuanet, @paulmonigatti, mind taking a look at this pull request as it has been labeled with an integration (safe_mode) you are listed as a code owner for? Thanks!
(message by CodeOwnersMention)

@kbx81 kbx81 added this to the 2024.6.0b1 milestone Jun 11, 2024
@jesserockz jesserockz merged commit 7b60543 into esphome:dev Jun 12, 2024
59 checks passed
@NMartin354
Copy link
Contributor Author

I appreciate you taking care of it for me.

Just for growth, I committed the init.py twice and it still fell through, was that my fault?
(First pull)

@jesserockz
Copy link
Member

jesserockz commented Jun 12, 2024

@NMartin354 Aha, I just took a look at your fork, and you pushed it to a new branch which made it not part of this pull request.

The real fault lies in creating the original work and pull request on your fork dev branch. You should always make a new branch for any piece of work and make the pull request on that branch.

@jesserockz jesserockz mentioned this pull request Jun 12, 2024
@github-actions github-actions bot locked and limited conversation to collaborators Jun 14, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants