ESPHome stability - too much breaking changes compared to Tasmota?

ESPHome
1

I found out that there are two main competing standards for ESP32 - ESPHome and Tasmota. Despite not knowing too much about them, I chose ESPHome to control my NSPanel using external component. ESPHome is logical and elegant but after using it for a while I noticed that every time I click upgrade in HA, the new ESPHome breaks the external component. It can be a configuration option deprecation, different API response, anything but it requires some manual effort on the external repository to make it alive again.

So far there are people in community to do these fixes, but I am curious why these have to happen? I was thinking that project with 10k+ stars will have some stability already but I was shocked to see that every release has at least 10 changes marked “#breaking-change”. This aligns with my experience really.

Do you think migrating from ESPHome to Tasmota can bring more stability? I like HA for being open to tinkering with, but also it is preety stable and I never had like “oh, my buttons do not work anymore”. I dislike having to tinker with configuration each time I want to change something small, like add a new subpanel to my nspanel. Glancing the Tasmota repo shows a lot less of “Breaking Change” marked commits.

2

Change (to support new features or new ways of doing things) typically requires (other) things to change.

I started with Tasmota and still use it on all on my esp8266 based devices. Many of them have not been touched for years, since they are doing exactly what I need and I have no reason to update them.

I started using esphome not too long ago when I wanted to do custom things and also use the esp32. Compile time for Tasmota on the esp32 was exceeding my (admittedly short) threshold. I spent some time figuring out how to eliminate things I didn’t need, but Tasmota is not well tested for that.

I decided to try esphome and see what it could do. The models/view of the world are very different. The Tasmota model is closer to everything is included and you can configure it at run time to get the behavior you want. esphome is you must include EVERYTHING you need (and good luck figuring that out) at config time, which is before compile time. Compiling is typically much faster, but you have to it individually for each device.

So, both are good choices but they are very different in the way they are used and the knowledge you must gain to use them well.

3

Disagree, there are different ways to introduce changes. ESPHome feels more-or-less like v0.35 or sth when changes are just pushed whenever somoeone finishes them

But this is the state:

3.8 fix
3.10 fix
3.11 fix

And this is possibly why ESPHome is also having a 3rd party repo that keeps the old versions of it just for people that forgot to click this one button in the upgrade screen

4

the examples linked above are for an external component. It’s true that changes within ESPHome can break external components, though attention is given to at least making authors of those aware of changes that may affect them, but anything built into ESPHome will be updated as part of any internal changes.

It is up to the authors of external components to maintain them but once a component is submitted as a PR and accepted, it becomes ESPHome’s job to maintain it, and while there are some external components that might never be accepted, generally speaking anything useful will be if the code quality is adequate.

There have been a lot of internal changes recently, many of which have been aimed at reducing the memory footprint and improving speed, which itself widens the scope of ESPHome’s application.

3 Likes
5

This is definitely not the case - as a seasoned contributor I can assure you that nothing gets merged unless independently reviewed. That’s not to say nothing ever slips through the cracks but the standards for PRs are quite high.

4 Likes
6

My experience with ESPHome has been very different over the past five years. It’s been more stable, in terms of things I have to fix with each update, than HA.

For a while I simply ignored ESPHome updates. I mean, if my devices are working, why mess with them? This is a perfectly valid approach, and if updates are bothering you, don’t do them. For me, the updates have been going so smoothly that I’ve been updating them all about once per month now.

The nice thing about ESPHome updates is that you can do the compile for all your devices before updating a single one. Depending on how that goes, you can decide to do the device updates, or not.

For most software these days, I dread updates. Even HA always comes with baggage like changes for change’s sake, stupid UI updates which add no functionality, and breaking changes. Usually these are not show-stoppers, but still a chore to deal with.

On the other hand, lately I’ve been looking forward to HA updates. Everything just works, and each of the last 3-4 versions have slightly improved performance and reduced memory utilization; things which actually benefit the user. What a novel idea!

1 Like
7

Hey!! He’s a paying customer of Esphome and he wants to complain about his customer service and has that right!!.. Oh wait, Esphome is a free service and you’d have to be a certain type of special person to do more complaining than showing appreciation for it and IMO when i see regular updates and fixes and even if one causes an issue, I still see it as a very good sign that people are frequently adding new things or improving things and from where im sitting, that’s a far better view than if we weren’t seeing hardly any updates or fixes because that starts looking like some firmware on it’s death bed just waiting to be put out to pasture… What do i know though? Im just another a-hole with an opinion i guess.

3 Likes
8

You are just being rude and reality is that we see different things and we put more emphasis on different behaviors. I started to use esphome just recently and was really surpised about the how nice and easy cli is, that i do not even have to use it cause its builtin to HA, and how docs are clear to understand (mostly). But my honest experience is that for a long time of using ha and esphome, only the latter (and random zha bugs) makes me do special things to fix stuff. I use pretty basic HA features, I do not do fancy ui (tried, not for me), maybe that is why.

I do not know if this integration could be upstreamed to be more maintaned but also the naming does not help. Are they really external components, something not intented to be there forever, but only to be polished and merged? Ot these are effectivelly plugins and there should be internal api and plugin api to not break them so often? Maybe we can bring this discussion to GH to get creator to tall about this possibility?

Gaining more performance or mem efficiency is nice, but I gained nothing because of it. My panel is still in there on the wall, working as usual. So my view is basically “I have to do work that I do not have time to do, gives me nothing, and is Independent from me”

9

So if you are not interested in improvements why you update in the first place?
I have some boards on latest esphome, others on 2022.x.

Ps. running continuously “growing” esphome on 10 years old hardware without getting out of resources is quite impressive to me.

2 Likes
10

That’s up to the author - it’s the same situation as HA plugins via HACS, they are not maintained by the ESPHome core team (and can’t be.)

Many external components are PRed and merged, but many others aren’t and many are not maintained by the original author.

1 Like
11

Never thought of that before but it’s true. Same can be said more or less for Tasmota as well.
I would also add that each time something breaks is an oppertunity to learn.

12

100%. I tried to upgrade an old Sonoff with Tasmota on it last year. It just wouldn’t accept the new bin, but ESPHome worked onetime.

1 Like
13

Unless you are using NSPanel for experimenting and constantly tweaking, you should consider slowing down the pace of ESPHome updates. I’ve ~70 ESPHome devices in my house and now I apply updates once every 2-3 months.

I’d used Tasmota in the past but the integration of HA with ESPHome is much better and the communication is encrypted. But Tasmota has way more functionality, configurability and compatible devices.

PS: I also gave up on NSPanel two years back, it was lot of work, in favor of Sonoff TX (wall plates) and also bought two refurbished Android tablets ($39 each) for wall mounts!!

1 Like
14

Why do you feel the need to upgrade them? I just leave mine, unless there is a new feature I want or there’s a bug fix available.

15

Expected because the esphome team doesn’t/can’t check external components - the internal ones (probably over 100) are the ones everyone is focused on! :keyboard:

If you want stability you will not make use of external components in the first place. :1st_place_medal:

On a side note: What exactly is forcing you to do the updates which involves the breaking changes due to the external components you use? :thinking:

16

… The perennial debate!

With ESPHome, I’d be comfortable recommending regular updates, OR never updating unless absolutely necessary.

Regular updates means that, if and when you do finally update, you won’t have as much research and testing to do, and you’re less likely to have a long list of breaking changes to wade through.

On the flip side, when you buy a ready-made appliance or device off the shelf, you seldom worry about regular updates. If it worked when you bought it, it should continue to perform the same function for the rest of its working life. Another good reason to avoid software updates for some systems (I’m looking at you, HA) is that they tend to get “bloated” over the years with unnecessary features and inefficient code designed to run best only on newer hardware.

I’ve personally found breaking changes rare in ESPHome, so this second approach is defensible.

I migrated to the former approach because I consider my HA and ESPHome environment to be much more dynamic than a “set it and forget it” device. I might want to take advantage of new features. I don’t want a mix of “new” and “old” ways of doing things as I add devices. And, most of all, I’ve found that the ESPHome code gets more efficient over time, not less. This says a lot about the quality of the development team.

2 Likes
17

I’m definitely one of those…

But the point of regular updates is good and valid.
Fresh breaking changes are usually discussed and solved here on the forum in short time. No-one remembers them after few years, so to get support from the forum might get trickier.

18

As Tasmota doesn’t present updates as often I find I can’t help but update. One or two devices at a time.

19

So I update because the HA shows ESPHome update pending, and it is annoying notification. Also I have a habit to upgrade things regularly everywhere, all my machines have machine-update script that does use system utilities likewinget/scoop, apt/apk/dnf, or flox/nix to update everything. This is first time authors of a project actively discourage updates in minor version that I found

Also the ESPhome in HA is shared, meaning if I have one device with a bug that need update, I have to update them all, there is no version-per-device. This means there always can be a case on of the devices will unable to make changes.

Ofc solution to that is to not use ESPHome system in HA, which loses most of the convenience but also gives more control. Nix packages are available, at least for Linux:

λ flox show esphome --verbose | head
esphome - Make creating custom firmwares for ESP32/ESP8266 super easy
    [email protected] (aarch64-linux, x86_64-linux only)
    [email protected] (aarch64-linux, x86_64-linux only)
    [email protected] (aarch64-linux, x86_64-linux only)
    [email protected]
    [email protected]
    [email protected]
    [email protected]
    [email protected]
    [email protected]

As for why I am using external component - I believe because it’s convenient. Original Lovelace NsPanel has a configuration for pages and this component translates it to the needed code. I do not know if native Nextion component and lambdas can do all of this but even if, the code will be much more complicated.

20

Hi Dawid,

Thanks for sharing those specific commits, it helps us understand exactly what’s happening. Looking at the three fixes in the nspanel-lovelace-native component, I can explain why these broke and how to prevent it in the future.

The component is manually constructing protobuf messages directly:


api::HomeassistantServiceResponse resp;

resp.service = service;

resp.data.push_back(...);

send_homeassistant_service_call(resp);

This is using internal implementation details that aren’t part of ESPHome’s public API. Protobuf message structures, field names, and encoding details are internal and will change as we optimize memory usage and add features.

There is a stable alternative. ESPHome provides CustomAPIDevice (custom_api_device.h) specifically for external components to call Home Assistant services:


// This is stable public API

call_homeassistant_service("light.turn_on", {

{"entity_id", "light.my_light"},

{"brightness", "127"},

});

fire_homeassistant_event("esphome.something_happened", {

{"my_value", "500"},

});

This abstraction layer hides all the protobuf details and hasn’t changed signature across any of those releases. Components using CustomAPIDevice instead of raw protobuf construction wouldn’t have needed any fixes.

Our public API documentation clarifies what’s stable:

  • For components: only features documented at esphome.io are public API

  • Protobuf message internals are explicitly internal implementation

The three changes that broke nspanel-lovelace-native were:

  1. String field setters optimized for zero-copy (internal)

  2. Message type renamed for consistency (internal)

  3. Vector fields converted to FixedVector for flash savings (internal)

None affected the CustomAPIDevice public API.

If you’re in contact with the nspanel-lovelace-native maintainer, pointing them to CustomAPIDevice would prevent future breakage. If the current CustomAPIDevice API doesn’t cover their use case (e.g., they need data_template or variables support), that would be a valid feature request we could address.

5 Likes