Import esp8266 program

Bit of a longshot.
Spend ages writing a yaml to get an esp8266 to control my pond systems. Relays (pump and filter), temperature, lights with an RTC to time switching everything on/off if HA ever isn’t available.

It all works well. But I had a problem with HA and had to restore a backup but unfortunately it contains an older version of pond.yaml.

Is it possible to read the program that is stored on the esp back into esphome?

The data on the ESP is stored in binary.
Before the binary step everything is probably converted to c++.
So that means you probably need to do two conversions which I doubt is easier than just starting with what your old config is.

A backup of your HA config files is your best (and perhaps only) bet here.
(please don’t say you don’t make - and test - backups; and if you don’t make them, it’s never too late to start.)
Binary object code in a machine can only be reversed into source code with a great deal of effort and expected inaccuracy in the outcome - AFAIK it’s just not done (except perhaps by those with massive resources).

Thanks for the quick answer.

I suspected that was the case, was a slim hope that there was a utility somewhere. :slightly_frowning_face: :

My backup was a week too old. A lesson learnt backup after editing something you don’t want to have to do again :slight_smile:

When you say “-and test-” what is the verification method?

Do you have a backup of the problem image? Full backups can be partially restored. If the problem was with HA and not esphome, you can restore the newer backup of esphome.

The answer depends on the level of confidence that you want, balanced against the amount of effort required to test.

If you want high-confidence, testing can entail starting with a bare-metal box and rebuilding - using only your backup - to be sure you can in the event of a total-disk failure, for example.

Other methods include just reviewing the backup contents and logs. Perhaps your backup utility provides a tool to verify that it matches the original files and is intact and readable (nothing like a mysterious error message from the restore utility that says “backup archive failed integrity check - archive unusable”).

To avoid the latter scenario (and there are plenty of other ways to avoid it), I use a backup tool (Backintime, which provides a UI to control tried-and-true ‘rsync’ which for incremental backups creates hard-links to unchanged files, to save space) that keeps the backups as a plain old filesystem, so I can just browse the backup filesystem to confirm stuff is there.

Oh, and never keep backups in the same place as the original (fire destroys both), and always make copies of the backup (backup media can fail). This is the easy part. Just keep a copy of your backup at a friend’s house, etc. Just so it’s not nearby if/when something takes out the onsite copy.

How much effort you put into testing your backups should be driven by how much you rely on the backup working when you need it to.