esphome / feature-requests

ESPHome Feature Request Tracker
https://esphome.io/
404 stars 26 forks source link

Idempotent configuration #2205

Open zarko-a opened 1 year ago

zarko-a commented 1 year ago

Describe the problem you have/What new integration you would like

I have almost 40 esphome devices and I started thinking how to improve managing them "at scale". I started using Jinja templates to render esphome YAMLs in a consistent fashion to make it easier to add/remove common settings (like deprecation of API password recently). Then I wanted to use a loop to compile and upload firmware for each device. This will work, however it would upload firmware for all devices no matter what the change is and if it's relevant for a specific device. It be great if there was a way to see if running configuration already matches the new desired state and skip compiling/uploading altogether. This would be generally useful, not just situations where one is trying to update multiple devices.

Something like this can be accomplished by calculating YAML hash before compiling and embedding the same hash into esphome firmware and exposing it via API. Then subsequent esphome run executions can compare their local YAML hash with the one already present on the device and simply exit with a message along the lines "Current esphome configuration matches desired state". Obviously you could have a force option to compile/upload esphome no matter the configuration check.

Please describe your use case for this integration and alternatives you've tried:

I would like to manage multiple esphome devices in declarative idempotent fashion. Similar to how Ansible manages files, it checks the hash and only changes them if current state doesn't match the desired state.

I tried searching through existing issues, feature requests and simply googling to see if there was a way to accomplish this with esphome right now, but I couldn't find anything.

Additional context

nagyrobi commented 1 year ago

What a great idea!

LordMike commented 2 months ago

See also #2171