Add restore state from flash option

[OttoWinter]

Description:

Related issue (if applicable): Fixes esphome/feature-requests#73

Pull request in esphome with python changes (if applicable): esphome/esphome#459
Pull request in esphome-docs with documentation (if applicable): esphome/esphome-docs#181

Checklist:

• The code change is tested and works locally.
• The code change follows the standards

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

• Documentation added/updated in esphome-docs.

[placidorevilla]

This is awesome, but I think the documentation should be clearer in terms of the implications of this option:

1. AFAICS switch, light and fan use preferences to store state, which sounds pretty reasonable to me
2. Global variables also use preferences (which is the most interesting use case, IMO)
3. Surprisingly, the value range trigger does too, which will wear out the flash VERY quickly, depending on the input to the sensor (which might be out of control).
4. The OTA component also uses this to track the number of invalid boots to enter safe mode, but there are situations where safe mode reboots and reverts back to normal mode even without a new flash, perpetuating the boot loop. With this option, additionally, it kills the flash too. Even if this wasn't the case, I'm not sure persisting to flash the boot loop counter is the right thing anyway.

A different way to implement this would be changing the EspPreferenceObject API to explicitly state if an entry is to be persisted, and keep a map in RAM for these. Then at save time, build an entire page with the ones to be persisted and write that to flash. As an alternative, preferences to be persisted don't even have to live in the RTC space, since they can be restored from flash at boot time, so they can live in a separate space in RAM (allowing for a larger block of variables too, potentially spanning multiple flash sectors). This way, points 3 and 4 above can be avoided just by not persisting to flash at all, and having the user select the platforms they want to persist (instead of a global boolean flag). For global variables I would go further and specify persistence per variable (I have an use case where I have 2 variables, and I'd want one of them to persist in flash but I don't care about the other one, since I only use it as cross object communication).

Also, implementing a rotating algorithm to reduce flash wear out isn't terribly complicated (tasmota's algo is very simple), and in modules with high flash capacity (4MB) that could enable frequent updates without any major issue.

[OttoWinter]

re 2: yes contributions to the doca are welcome

re 3: true, though that could be updated to only store a bool which would solve 90% of the issue.

re 4: The ESP32 has actually handled it this way since the start and it's not been a real problem.

On the following points I would just say: Let's wait until someone actually notices it.

• Preferences size: you need to create a lot of objects for that to become a problem. The reason dynamic sizes were not implemented here is because then you need to allocate some buffer to store them too, and that buffer can be potentially huge.

Rotating algorithm also only adds more complexity - I'd wait until someone actually hits a flash or we have better numbers as to how many write cycles are possible.