Too many updates for ESPHome; too often

[tom_l]

@GoodyGizmos

if the latest ESPHome update only affects light entities

That’s the problem with your proposal. Breaking changes rarely affect the whole domain. Usually only one component of that domain. Should everyone be prevented from updating just because they use an unaffected component that happens to be in the same domain?

Additionally what you have proposed would produce three times as many updates for people to track. This makes the problem worse not better.

@GoodyGizmos

Also, on the 2024.7 Release Party, Paulus directly addressed the frequency of ESPHome updates specifically:

And they implemented what we have been trying to tell everyone to do in this topic since the start. Disable the individual device update entities. This now happens by default so you don’t have to. You will still be notified that ESPHome has an update available and your ESPHome dashboard will still show which devices need updating.

[GoodyGizmos]

Yes, that’s what they implemented. I was just sharing it here. But, I also don’t think it will be the end of the ESPHome update story.

I don’t think I understand your question, but I’ll try…

No because if the user sets an ESPHome device to any of my proposed …changes only for affected and online devices/entities options, then an ESPHome device that has any light entities would still process the update (false pass on the filter) IF the update contains updates for any light entities.

Again, what are some examples of a “component” as you use it in this context?

@tom_l

Additionally what you have proposed would produce three times as many updates for people to track. This makes the problem worse not better.

This suggests there’s something fundamental I’m not communicating well. It’s ok, I’ll just stop. I certainly don’t have all the answers or coding chops, but I gotta’ believe something along these lines is possible.

[sparkydave (🇦🇺 Dave)]

@GoodyGizmos

Again, what are some examples of a “component” as you use it in this context?

If you look at Lights, only one of these might need an update but highlighting all Light components means people who aren’t affected will be notified.

[tom_l]

@GoodyGizmos

Again, what are some examples of a “component” as you use it in this context?

In ESPHome a component is loosely equivalent to an integration in home assistant.

Lets take one of the last update’s breaking changes as an example. The Dallas sensor component was changed to one_wire.

Your proposal would stop anyone that used any sensor in ESPHome from seeing the update. Not just the people who used the Dallas component, because:

@armin-gh

HA knows that a ESPHome integration provides for example a temperature entity, but it doesn’t know if this temperature is provided by a Dallas-Sensor or Bosch or DHT or any other sensor.

[GoodyGizmos]

@tom_l I think I understand what you’re saying now. How frequent are these kinds of updates that change the ESPHome component platform and HA entity type? It seems like a pretty big change compared to the frequent bug fixes. If infrequent, it seems to be an acceptable tradeoff to have those sort of updates relegated to the ESPHome dashboard (the same fallback you proposed for those who would disable their update entities under the current system)? But again, this would only be for those who set their update entity to one of the proposed filter options.

[tom_l]

More than one component breaking change in each of the last few major release change logs I just looked at.

[GoodyGizmos]

So those are always in major releases?

[tom_l]

Not necessarily. Just the last few I looked at.