Cooldown before reconnecting on expected disconnect #397
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If the esp gets an OTA or requests a disconnect because its rebooting, we would reconnect too quickly before the device had shutdown accepting socket connections and end up trying to talk to a device that was moments away from rebooting which would delay reconnecting once the device came back up
If the esp gets an OTA or requests a disconnect because its rebooting, we would reconnect too quickly before the device had shutdown accepting socket connections and end up trying to talk to a device that was moments away from rebooting which would delay reconnecting once the device came back up
|
|
reconnect is way faster now for wifi ones as well because we don't have to fail first |
|
Much cleaner on the log watcher as well |
|
and a power pull still reconnects right away |
|
Did you try this on:
I think 8266 needs different treatment... |
|
Tried on all 3 of those. They all behave the same. Why would the 8266 be different? |
|
This is from an s31 I did an OTA with: |
|
Just did another 8266 to be sure it behaves the same |
|
8266 needs more time after OTA due to different flash layout... Is this also in your testing custom component? |
The cooldown is only enough time for the esp to stop accepting new connections right before the reboot. 1s probably would be enough to make sure it's down enough to not accept connections but I did 3s just to be sure since there is no chance it will be back up by than.
Yes it is |
|
Testing... |
|
I still see inconsistent behavior during OTA. Depending on flash size, network etc, it may take longer to upload the firmware on some nodes than the others. Some nodes go offline in HA when starting OTA, some during OTA somewhere in the middle, and some don't go offline at all (or only for a very short time, unnoticeable in GUI). I guess on ESPHome side special care should be taken to deliberately say goodbye to HA before starting to write the flash. There even is on_begin but it doesn't seem to be respected because of blocking... |
Is that from testing with this PR, or are these previous observations? I would expect #395 improves the situation and reduces (probably not possible to eliminate all instances) the chance of premature disconnect during ota |
|
Yes, with testing. But can be considered as "cosmetic" as sooner or later the nodes do come back. |
|
How long is the ota taking on the esps that are getting disconnected during the ota? I expect anything that takes more than 10s before #395 to ota would have gone offline before. I expect you get at least 70s, maybe even the full 90s before you get a disconnect. I don't have any devices that take that long to ota so I don't have a good test case to validate that. |
I feel it around 5 seconds... |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If the esp gets an OTA or requests a disconnect because its rebooting, we would reconnect too quickly before the device had shutdown accepting socket connections and end up trying to talk to a device that was moments away from rebooting which would delay reconnecting once the device came back up