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.
I did a bit of reworking on the networking logic and removed the "reboot on wifi disconnect" from the Networking class and made it a consumer of SystemState in SensESPApp. For this, I required Debounce to only trigger the reset if the state had been stable for 3 minutes.
First, I noticed that due to the Debounce template implementation, it was impossibly to instantiate Debounce. I did a quick benchmark to verify the claim in Issue #287 that "if you put the entire implementation in the header file (esp. the configuration stuff) the compiler will generate a TON of redundant code." (The issue sounded a bit peculiar because basically all of STL is, well, templates.)
I have a random SensESP test program that takes some changing AnalogInput, applies hysteresis and rounding and then Debounces the boolean and integer values. Compiled with the original implementation, the RAM footprint was 51.0 KB and flash footprint 1015.4 KB. I then refactored the code into a standard headers-only template class. The RAM footprint remained at 51.0 KB while the flash footprint dropped to 1011.0 KB. So, that is the first major change in this PR.
The second change relates to the Debouncing logic. I am debouncing the system state which gets regular WifiDisconnected updates (the same value all over again). The original logic reset the timer for every update, even if they repeated the same value. That didn't quite make sense to me - it would be impossible to debounce any polled values with this logic. I shuffled the code a bit around but the only change in the end was that repeated values are considered stable instead of resetting the timer every time.