Goodbye Tasmota

ESPHome
11

That’s a peculiar reason given that the two technologies don’t have the same design goals.

One was designed to provide an efficient, universal means of sharing data and the other for programming devices and communicating with them exclusively by Home Assistant.

If one needs to promote ESPHOME’s advantages, one can simply say it was designed to efficiently integrate hardware devices with Home Assistant so it stands to reason it’s optimized for that sole purpose.

MQTT continues to be an efficient means of sharing data among disparate devices and that’s why it has been adopted by virtually all software applications related to home automation. Nevertheless, if one only needs to integrate a device with Home Assistant, then ESPHOME is a bespoke option.

14 Likes
12

My two cents. I like esphome for sensors, but if it controls anything still prefer tasmota (I even have one thing still on espurna). Integrated Alexa makes me happy. Having to add alexa support by adding a configruation.yaml setting does not feel elegant. It would be nice to be an onboard option like tasmota.

13

Well, that’s not quite correct. Beside it is ha focused (under the same roof of nabu casa :house:) it also works with other platforms (for example iobroker) too. Pure to the fact the thing is open source it will be already very hard to have it “exclusive” for home assistant :wink:
People following the esphome discord will also know that a lot of people build stuff around esphome without ha and using the native api for there purposes.

That’s true and there is nothing wrong with it.

But I guess it is like with cars, once you get used to benefits like a automatic starter, servo steering and brakes, remote unlock & lock and various other “goodies” which are all not necessary to run the thing but just makes your life so much more comfortable. After you tried the “new standard” you never want that oldtimer again (for every day use at least :stuck_out_tongue:) because you value all the benefits you came to know :star2:

image

3 Likes
14

Others are free to adopt it but the project is controlled by the development team at Nabu Casa and their primary goal is to make it work best for Home Assistant. They won’t have qualms about making changes that negatively impact iobroker’s users or anyone else who adopts it.

Other open-source projects operate the same way. For example, some while ago, the Tasmota project chose to deprecate support for Home Assistant’s MQTT Discovery and implement their own MQTT-based discovery protocol (emontnemery created the Tasmota integration to accomodate this change). You can still choose between the two (it defaults to Tasmota’s own discovery method) but the Tasmota project is one or two versions away from removing the deprecated code from its compiled release versions. Anyone still relying on Home Assistant’s MQTT Discovery will be obligated to switch to Tasmota’s discovery method (or compile a custom version of the firmware containing the deprecated code).

15

I use any solution. Tasmota, ESPHome etc

I giveup the idea of Only Tasmota or ESPHome

4 Likes
16

Sounds like a good time to try out esphome then and might stick with it when it fits :wink:

I’m really grateful for Theo bringing us Sonoff-Tasmota (now Tasmota) as it was clearly the beginning to open the whole esp ecosystem. Maybe without him Otto would have never invented esphome!

But for the same reason I choose Home Assistant over any other solution I also choose esphome over any other solution. Afaik there is simply nothing comparable out there which gives so much freedom but at the same time the maximum “output” with the minimum input possible.

And well, it’s not only down to the fact that with esphome you can avoid mqtt completely (which is just 100% win for me because I don’t waste any time here!) but also about the whole architecture.

Tasmota still tries (and somewhat still succeeds) with one (actually last time I looked there were over 100) pre-compiled binaries to “rule them all”. At the same time space is rare since always and so it comes that not all configurations are actually accessible in the menu but hidden in different corners. Some things nneed special commands in the command line or some stuff even needs to manually compiled upfront to get it working.

Actually I think this is also a “weak point” of tasmota. Many users stay on old (or very old) tasmota versions because it “ain’t broken”.

But the saying “never touch a running system” is actually dangerous for connected devices like esp’s.

Every now and then there is still users out there running a ota exploitable tasmota versions like 6 or 7 just because it “works” and they know (had) the pain of updates going south already.

Why is it bad to don’t give users the easiest way updating like we are used from computers or phone (known as ota update)? Because then they will not update and over time start to have vulnerable devices. It’s enough that manufactures often give a :poop: about updates but if someone takes control over a device (replacing the stock firmware) it is also the responsible to keep it up2date.

And well, here is esphome superior in probably every aspect and it’s down to a ota “one-click-update” (for all devices at once).

As I have also gained like 2 years experience with tasmota, espeasy, espurna (my favorite before esphome btw.) and more I can say that updates on this systems were often a hit and miss. Sometimes parts of the configuration got lost, some times the update was to big so two updates were needed, some times everything looked fine but the device behaved differently like before - I know all these pains and hours wasted just to get the working state from before! My last device I migrated over from tasmota to esphome were one I didn’t update with intention because I had so much pain with the update before and I was just so fed up wasting so much for a (in theory) simple update.

Since I moved to esphome I just had :zero: updates which went wrong and if there was a breaking change (which lies in the nature of actively developed systems) I actually get the information before it updates the esphome node. This year I think I had :one: update which didn’t work because of a breaking change - and guess what, the error message actually just tells you what to do to make the update work, one line in the yaml edited, saved and update flys :rocket:

I can imagen that on tasmota things would just fail silently, the sensor would stop working, need to do some research in the end a reset of the device and completely new configuration would have been the way… 1 hour wasted just to get what I had before!

I stay with esphome :wink:

6 Likes
17

Well, i can tell about one example where i can’t see how i’d do in tasmota:
i open my (yard) automatic gates via HA and esphome module. The (minor) problem of gate electronics is that at power failure door state is unknown when power comes back, which is kinda logical, since they don’t have any end switches. So i programmed esphome module in a way that at boot gates open for 1 sec and close again. That way i always know status of gates.
Supposely there is (or will be…?) a way with some scripts in tasmota, but… :sob:

BTW…regarding my “complaints” against esphome and xiaomi’s: i just set-up another esp32 for receiving xiaomi BT modules with esphome. I used esp-idf framework instead arduino, since now it works with “normal” esp32 boards, too (some months ago it only worked with C3/Sx versions). Now it’s a waiting game…

1 Like
18

why update a switch its ON or OFF

my every first Tasmota is the Sonoff basic its still running 5.10.0b

image
image1312×51 3.09 KB

never done any its a on/off switch

and

if ESPhome had been around for as long as Tasmota is they would have the same problem.

We, humans, are the problem we leant how to put MORE into smaller Spaces and want more in that space.

1 Like
19

Because it’s not just a switch but a IP connected device you have in your network :warning:

Well, you are a perfect example for users running insecure firmware :point_down:

Plainly spoken someone from outside your home (but within wifi range) can take over your Tasmota device (because it has security vulnerabilities), dumb the firmware and extract your wifi password. The person then essentially is inside your house network and can do as he please like infecting other systems watching you on your own camers (if you have some) or just playing master of disaster. :hammer:

Like said before:

And this is so bad. What you would need is dumb on/off switch and not a smart one!

image
image471×510 78.9 KB

Dumb switch:tm: (Live time updates included :registered:)

No, because they have a completely different approach. Tasmota (tries) to pack everything (also mainly the stuff you don’t need) into the pre-build binaries. Esphome on the other side crafts a custom binary for each and every device which is build from a “recipe” (yaml) and it only contains the stuff you want/need and nothing else.

Well, totally unnecessary if you ask me… Your switch has lot’s of code you never use. It’s like always carrying around a big bag :baggage_claim: with lot’s of stuff and you never use it…

20

If you have the time to manage it all that’s nice. But if you are like be and don’t bother with stuff already deployed and rather go all in on new projects.

I like my homogen system with soon 100 esphome nodes combined with ha because it’s a ease to manage/update and I have the whole configuration in one place. I don’t need to spend or waste time on stuff that would be “edge cases” in tasmota for example which would need scripts or manual compiling and stuff. Also the system is just rock solid (which is different to the tasmota I came to know that sometimes “looses” it’s memory :brain::no_entry_sign:) because everything is “burned” into the firmware and there is no volatile settings. Also esphome makes it obsolete to check proactively for beaking changes which is mandatory for other systems like tasmota before the update otherwise things go south quickly…

But well, we are all free to choose and there are (luckily) viable options so everybody can do as he please (but please keep your devices up2date even can be a pita on some systems!)

1 Like
21

I use the best of two worlds.

I have private ota for my tasmota users.

Underhood esphome = tasmota.

I change from tasmota to esphome and vice-versa via ota. Just use same “board” settings.

And again I use ESPHome, Tasmota, … xD

22

Disable recovery mode:

If you have a weak power grid or
frequent power brownouts its best to disable
this feature with
SetOption65 1
immediately
or you’ll end up with firmware default
devices after a brownout event.

Thank you :upside_down_face:

23

That might be right to some extend even though the last time I checked tasmota used a forked(?) arduino framework while esphome allows you to use the vanilla/mainline(?) arduino framework or esp-idf. :trophy:

Other key differences I explained already in this thread.

I’m aware of this weird “default” setting from tasmota and that there is some cryptic command to turn it off. In any way I don’t plan to use tasmota any times soon for various reasons you can read above. :point_up:

From a security point of view I also don’t understand why Tasmota is doing it that way and spawns a open AP so literally everyone in range could connect to a device and control it. :unlock:

ESPHome also does have a “recovery mode” (safe mode it is called) but it doesn’t come with the negative side effects of a unencrypted wifi AP and most importantly it doesn’t active it for “no reason” :lock:

I have over 5 years of experience with esp’s and my first device (the good old sonoff s20) was indeed flashed with tasmota. It got the basic job done toggling a appliance in that socket but the system wasn’t resilient enough to use it for something “serious” because it just was prone to fail. I discovered various possibilities for around two years (espurna and espeasy included) but the break-even point was literally when esphome (esphomeyaml & esphomebin it was called in the beginning) was around the corner. :wave:

It literally was the first time I could even consider using esp’s for “serious” tasks. And well, today you will find like 100 esp’s around my place controlling stuff like lights, fans, pumps and more including “mission critical” stuff. That’s possible because esphome allows me (a person without programming skills) to do advanced stuff in a easy way and have it working on the device :muscle:.

As a example my pumps all are toggled by sonoff pow r2 which include power metering and that I use to detect if they run dry (they are old pumps and don’t have dry run protection build in :warning:) and it will then turn of the pump directly. That is directly integrated on the device so even if wifi or ha is not available for that esphome node it will protect my hardware from breaking.
Probably with tasmota this is also somewhat possible but it will probably need programming skills to do some scripts and even if I would get this done (only with external help or learning programming before) I would still not trust that to be 100% available because of my experience I had with tasmota in the past. Also the constant worry that a update will break the functionality (maybe silently?) makes it a no-go for me.

So, I will continue with my rock solid setup which is a ease to maintain and don’t waste my time with other solutions I tried already and that didn’t convince me at all to use it for “mission critical” applications. :rocket:

Still, if someone just want’s to try out things or only needs a simple esp based plug to toggle some light a solution like tasmota or espurna for sure is inviting to get the job done and it probably doesn’t matter much if there is no high availability because it’s nothing of importance. The only hope I have is that these users than do regular updates (even if they are not that “comfortable” as they could be) and don’t “sit” there and do nothing while not only there devices getting vulnerable (like @myle’s office light as a bad example :grimacing:) but with it there whole network and all devices from all people that are connected to it :boom:

24

Converting from Home Assistant’s MQTT Discovery to Tasmota’s MQTT Discovery is as easy as changing one parameter (SetOption19 0) and ensuring the Tasmota integration is installed. However, let’s say you’re right and now is a good time to try out ESPHOME.

Perhaps you can described the process of converting the firmware of a simple smart plug I have from Tasmota to ESPHOME.

Originally, all I needed to do to configure the device for Tasmota was use the template posted here. That template allowed me to control the switch and take advantage of it’s energy-monitoring feature.

The device appeared in Home Assistant as a switch with ten sensors for energy monitoring and another nine (hidden) sensors for miscellaneous things (like firmware version, IP address, WiFi strength, etc).

So what steps are needed to duplicate the same functionality using ESPHOME?

25

Not sure if this topic is really the right place for your endeavor but if this links :point_down:

https://www.reddit.com/r/homeassistant/comments/hbipb0/ce_smart_plugs_w_em_from_costco_esphome_config/

don’t help you to achieve your goal feel free to open a new topic and me (and others) will be glad to assist you :+1:

5 Likes
26

Given that you’ve written numerous lengthy posts heralding the benefits of ESPHOME, I thought this would be an opportunity to demonstrate just how easy it is to configure the device I mentioned. Possibly as easy, or even easier, than copy-pasting the template I mentioned. However, now I have the impression I will need to invest a lot more time and effort to merely duplicate what I already easily configured in Tasmota.

Don’t get me wrong, I do believe ESPHOME is a powerful means of compiling custom firmware. However, for something simple like a switch with energy monitoring, it seems like Tasmota is easier and faster to configure (no development application to install and learn, no YAML code to piece together from various examples, no compiling, etc).

2 Likes
27

You might got me wrong? I never claimed that something is “easier” or “faster” to install or configure.

I essentially shared my experiences I had over the last 5 years including the pains with tasmota and how I found hope in esphome :pray:

One can('t) forget that something like taking full control and “freeing devices” is probably a thing for less than :one:% of the user base of “connected” electronics. If you are one of the few then you are willing to learn new stuff like setting up a home assistant server or flashing a mcu like a esp. With it always comes the need to work with new software and getting used to it.

For sure it could be true that for a first time user flashing tasmota is faster than installing esphome but

Actually! Out of curiosity I just looked right now and installing esphome or tasmota on a esp for the first time can actually be identical because tasmota adopted the esp-web-tools to flash directly in a supported browser (as does esphome because they developed it) and also supports direct provisioning via improv (again like esphome) :point_down:

:one: click to install the esphome (dashboard) addon or :one: click the mosquito broker for tasmota :man_shrugging:

“simple yet powerful configuration files” that’s the good part! Instead of potential configurations distributed over 4 corners (web ui, command prompt, scripts, pre compiled stuff, …) it’s all together in one place which makes it an ease to work with it. :raised_hands:

That’s again a good thing. I’m quite confident that tasmota will take in the future a similar approach crafting individual binaries for device because there is simply no chance to compile all functions (including all the not used ones) into the flash of a esp already. That’s why tasmota has so many flavors like Sensors or Displays and others to choose from which each only supports a certain (sub)set of hardware. And compiling btw is nothing that the users must do - in case of esphome it all happens automagically :rainbow:

Feel free to tell us about your experiences once you know esphome better. I’m quite confident you fill find things that tasmota does better because like esphome it is in constant development and gets permanently improved :muscle:

that’s about it :wink:

5 Likes
28

I never claimed that you did. I was responding to the comment you made in reply to the upcoming need for users to switch to Tasmota’s MQTT Discovery (if they haven’t already done so). You said it might be a good time to try out ESPHOME.

I took you up on your suggestion and asked for an explanation of how to configure one of my existing devices. What proceeded clearly involves far more work than what it takes to switch to Tasmota’s MQTT Discovery.

For someone who just wants their Tasmotized device to continue working with Home Assistant, executing SetOption19 0 and installing the Tasmota integration is an expedient choice. The alternative, switching to ESPHOME, isn’t nearly as simple.

Therefore the impending requirement to use Tasmota’s MQTT Discovery method may not be a sufficiently compelling reason (i.e. a “good time”) to switch to an entirely different firmware. Not unless one has sufficient time to learn and experiment with a completely different firmware development environment.

29

Well, that only happens when the responsible person for a device takes action and updates their device at first I guess. That this not always the case was already written :point_down:

and in this very thread it turned out that this was even underestimated

:sob:

I’m not a programmer and I don’t work with firmware development environments so not quite sure what that point is about? You don’t need programming skills nor download any tools - esphome will handle all the hard work for you. :muscle:

I linked to a “template” for your device so it will essentially just be copy and paste (if you are actually interested in trying it out - but be aware! Satisfaction could be on the road ahead :wink: )

And time is indeed always rare. That’s also a good point too why I’m so glad (while also experienced other solutions in depth) with esphome and for e.g. the possible to share configurations across devices. Thank’s to packages deploying a device is often not more than giving it a essentially a name and click install :rocket:

A good reason might be a bullet (and idiot) proof update mechanism that de facto guarantees you a straight update path from essentially every version before and that with one click for all of your devices :raised_hands: So the responsible person can have a “good time”, having a :coffee: and enjoying the service of getting all his devices updated almost magically :rainbow:

3 Likes
30

If you are using ESPHOME then you are using a firmware development tool. You are composing high level instructions, in YAML, that are converted into executable code stored in a format that becomes the firmware of the chosen device. (No development tool is needed for Tasmota)

The need for programming skills largely depends on the complexity of what one wants the device to do. Skimming the ESPHOME section of this community forum shows that some challenges require more than merely the ability to copy-paste someone else’s YAML code.

As for not downloading any tools, it’s clear one must download and install the ESPHOME application before one can produce anything.

In contrast, there’s no development tool required for Tasmota. It’s released as pre-built firmware whose behavior is customized using commands (submitted via its built-in web interface). Yes, you can compile a custom version of the Tasmota firmware but most users don’t need to do that.

You linked to YAML code (in a Reddit post) that reproduces some of the functionality of my Tasmotized device. I appreciate it but it highlights the challenge of converting from Tasmota (available large library of one-line configuration templates) to piecing together the needed YAML keys and values to build a desired feature set for a given device.

Sounds great. Where’s a library of packages that contains my device?