I agree, i SHOULD find it. When compiling links in log show that path, but in reality path is non existent nor in Terminal nor from SSH command line… that confuses me also…
But, i played with Syno docker: i manage to install ESPHome and portainer. I must say that compiling works quite faster than inside HA VM. And, surprise!! All above mentioned files and firmware.bin IS THERE! Now go and figure…
Ok, if this will work i can move all my ESPHome modules in docker and make backups with syno. It’s a shame that supervised HA is no longer possible in Synology…
Another question: @dougle03 : you say that using portainer is easy to switch versions. Correct me if i’m wrong: changing version should go like this:
i stop ESPHome in docker
i delete existing ESPHome image
i download older image
i run ESPHome in docker again.
Same procedue should be ok for future upgrades of ESPHome, correct?
Yes, using portainer to manage your docker containers is really quite easy.
I have a container called Watchtower that automatically downloads and updates all the other containers as they become available, so generally I don’t need to play with it much.
To manually update or change a container I do the following:
In Portainer I stop the container,
Then, in images, delete the existing container image file.
Then back in the ‘now stopped’ container, click duplicate/edit and change the image description,
so to go from esphome/esphome:dev to esphome/esphome:2021.8.0 - simply delete dev and type 2021.8.0.
Then, make sure Always pull the image is on
and click Deploy the Container .
Doing this, you can freely switch from version to version on demand. You could also run multiple containers of different versions (on different port numbers) but I’ve not tried that and there may be port sharing issues…
Ok, i think i managed to work this out pretty neat
Things i did:
installed ESPHome in Docker
installed Portainer - that was quite a jurney (at start i’ve got some errors when opening portainer page)
i moved all ESPHome files into docker. For new ESPHome page to “see” modules if they are online or not all yaml’s must be re-compiled or it shows “unknown status” - i did that (with “download”)
i created snapshot automatics in Synology DSM - it creates daily/weekly/hourly (selectable) snapshots of whole “docker” folder. So from now on i’ll have binary files to sell
Since i have quite some space left (3/10TB occupied) i set to whoopy 90 daily snapshots, each one is appr. 150MBytes. I’ll reduce this if space will become a problem (not likely yet, though…)
@dougle03 Thanks for your guide. From your instructions i managed to find a slightly different way directly inside Synology DSM: stop container, re-download image, reset, run container again. Which makes me wonder if i’ll ever need portainer at all…?
But, if i’ll have old binaries it’ll be rarely needed to do so anyway.
I’m kinda “panicking”, i know… but, better safe than sorry. And, if it’s feasible, why not?
(Now as i have all set up i bet that mr. Murphy will step in and make sure that it will never happen to me again… )
In the meantime i saw that i’m not the onlyone with ESPHome’s light problem, so i hope this will be resolved soon.
Thanks, guys for your time, answers, suggestions…! Many thanks!
I hope you moved them into a persistent folder that’s linked to the container? Anything in the container will be lost when it’s updated… And you only need to keep the yaml files, not the folders that are created when you compile a binary.
Ammm… i moved them to folder “docker/ESPHome”, into location where first test yaml was saved when i created it in new ESPHome page.
How / where to check if folder is persistent…?
And… i don’t update either. But, since last update (i believe it was 2021.8) ESPHome my lights were working a bit funny - transition interval was always default (2sec), even if i set it to shorter later. So, when 2021.9 came out i wanted to test if this is corrected. It turned out that it was even worse…
Synology Docker UI also calls them volumes but I think they can only be amended by re-creating the container.
As long as your esphome entry in Synology looks like the above (albeit with different File/Folder location then you’ll be all good. Otherwise any yaml you create in the UI will be lost when you update the container.
Persistent means that the files are not stored within the container.
It would be nice if the yaml files used to generate the bin were stored on the device, or locally with a checksum to tie it to the bin that’s flashed. I always find I’m iterating through cycles of development and testing, then it works, and I leave it alone until it breaks, which is long enough later for me to forget which script is on each device.
I “upgraded” my backups: i used “hyper Backup” in Synology. It allows use of filters, so now i have backup of only *.yaml and firmware.bin. Ordered by date, so they will be easy to find if needed. Bin files are located in subfolders with name of device - structure is retained, only folders are emtpy. Nice…
.
)
