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
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 
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. 
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. 
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. 
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” 
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. 
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 
.
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 
) 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. 
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 
) but with it there whole network and all devices from all people that are connected to it 
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?
Not sure if this topic is really the right place for your endeavor but if this links 
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 
5 Likes
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
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 
One can('t) forget that something like taking full control and “freeing devices” is probably a thing for less than 
% 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)
click to install the esphome (dashboard) addon or click the mosquito broker for tasmota 
“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. 
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 
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
that’s about it 
5 Likes
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.
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
and in this very thread it turned out that this was even underestimated
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.
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 )
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
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 So the responsible person can have a “good time”, having a 
and enjoying the service of getting all his devices updated almost magically
3 Likes
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?
So we are now moved from “firmware development environment” to a “firmware development tool”?
Still I’m not really convinced that I do any kind of “development” at all, let’s consult wikipedia about it
Software development is the process of conceiving, specifying, designing, programming, documenting, testing, and bug fixing involved in creating and maintaining applications, frameworks, or other software components.
So for me it more sounds the esphome and tamosta are getting actively developed (you can check the progress for both on github actually) and that the user “just” makes use of applications. For sure esphome has a different approach that it always gets “configured” before esphome does all the rest automatically (like crafting that unique binary for your device and uploading it) but that this actually is a benefit is already explained extensively in this thread anyways and it is actually nothing the user need to care about (hence I would not call it “development” at all and nether I am a person you could call a developer).
In your point of view I’m also a excel developer if I copy an paste some numbers into spreadsheet and a home assistant developer because I have a configuration.yaml? 
Fun fact: The last time I actually wasted time with manual compiling (for which a development environment tool actually were necessary) was back in the days with tasmota. I think the usable amount of one wire sensors had a hard limit at the time in the pre-compiled version so I were “forced” to get into this if I wanted to have my setup working. Actually I even succeeded after lots of trial and error but it was a long walk (like installing tools, setting up the development environment and resolving stuff with libraries) - luckily I only needed to do this once before esphome came to rescue 
In fact you can’t even separately download and install the esphome (dashboard) addon as previously described it is only one click and it is the same “amount” of work like “download and install” the mosqito broker for tasmota. Both will take like 5 seconds of your attention and do the rest in the background…
I would even call it more work to download a dedicated program that needs to run locally like tasmotizer or esphome-flasher - luckily the days we needed them are over and everything can be done in the browser
Well and at this point it looks to me like you are just trolling around in this thread and actually have 0 intentions even to try esphome. On the other hand you are not ashamed to post in the (de facto official) forum of esphome your sometimes weird theories of how you think stuff works while obviously never tried it yourself.
Looking at your forum actives it doesn’t look at all that you are a troll (maybe you just came a little off track in this thread?) and reading some of your posts I see that your yaml and ha skills are actually quite or very advanced (far more that I even can understand all the stuff you are posting). Based on that I’m confident you wouldn’t even need five minutes (after you invested that one click to install the esphome (dashboard) addon) to get your device up and running if you just wanted too (but that is what I really doubt at the moment). 
And about your behavior here in this very thread - think a minute (or second) of a analog situation that some in the home assistant forums actually makes claims like “ha is unintuitive and not easy to navigate” without ever having used it? And then the troll could continue with something like “it takes more time to install ha so I will just stick with my already installed solution XYZ”. What would be your thoughts about that @123
6 Likes
I’m detecting pedantry because the two terms are interchangeable in this context.
It was an honest question and the fact you evaded it and pivoted to three paragraphs about “my behavior” suggests the answer is “No”.
Wrong. Once i tried to use MCP 23017 on tasmota and i very much DID need development tool, because pre-compiled binaries doesn’t exist for this chip (at least didn’t at time).
But, as already said: tasmota has tons of “garbage” included, which is not needed at all for one specific module, hence (too) big bin file. On the other hand, when you need some extra thing you must compile this manually and this is way more complicated than in esphome. In this regard esphome is way more friendly.
Also tasmota requires (at least) two actions when updating fw. Directly won’t work because bin file is too big, so first you must flash basic fw, only then the new one. If all goes ok (which doesn’t always…).
2 Likes
Well to this point @123 filled this thread already with so much (even repeating) false information about something he never used (hence no idea how it works) but at the same time he also clearly has no ambitions to change anything about it (like testing esphome to be able to really speak about it 
)
Best might be at this point to stop feeding the troll 
5 Likes
If you review what I posted, I had qualified my statement with the following:
The fact that the release binary didn’t include what you needed (at the time) put you in the minority of users who need to compile a custom version. Most don’t. So not “wrong” but you just chose to focus exclusively on one part of my full statement.
I detect projection.
1 Like
Thou dost protest too much might be the right idiom for you?
It’s obvious that you never wanted to try esphome because nether do you lack the skills, nor the information needed (the 3 links I posted were on point to get your firmware changed within approximate 5 minutes) and certainly you didn’t had any time constraints as you had time to fabricate your own “facts” in this thread (or pollute it with “fake facts” on might say).
So in the end the only one which is in your way is yourself @123 - and you are also the only one holding the power to change it
4 Likes
Wrong again. Tasmota forums are full of guys who want to use something, not included in precompiled binaries. Why do you assume that most are “only basic users” and use only basic integrated functions? They aren’t. And they don’t.
3 Likes
If you look at the posts in this community forum by Home Assistant users who employ Tasmota, the questions are limited to configuring the release firmware. Those who have the skills to compile their own binaries aren’t posting garden-variety questions here (they’re the minority). What transpires in the Tasmota forum covers a broader range of applications and I can’t comment on its stats.
You followed that first sentence with what can only be described as two more paragraphs of protestation.
To put a finer point on this subject… 
From my experience with both projects:
Tasmota:
Pro:
I think that Tasmota is way easier to implement for any standardized commercially produced device since it comes with all of the functionality built-in to the precompiled binary. You flash it to your device, go to the web UI and configure the device. Done. Easy(ish)
Con:
But making non-standard/custom devices using Tasmota is very hard to to for the end user. I’ve never done it. Every time I needed a customized device I always fell back to the ArdiunoIDE and coded it there.
and you need to have another server (MQTT)in between your device and HA.
and it comes with more bloat than ESPHome due to the above mentioned pre-compiled binary approach (but that has no effect on the user since they won’t ever see it after install).
I think I ran into a problem one time where I actually ran out of room in device memory when I tried to update the Tasmota firmware (it needs to install the new firmware before removing the old firmware and there wasn’t enough room for both) so I ended up needing to erase the device before installing the new firmware. So obviously OTA update wasn’t available then. It ould have been a PITA if the device was buried away somewhere.
Conclusion:
So if you JUST want to have a quick and easy way to flash some code onto a standard device and quickly set it up then Tasmota is the way to go.
ESPHome:
Pro:
Direct integration with HA thru it’s API. No additional broker needed. And easy automatic discovery out of the box via the API too.
Very powerful so you can make totally customizable devices using YAML instead of coding things in the ArduinoIDE.
Con:
No pre-configured binaries for standardized devices. You have to code everything in yaml. Not that there is anything wrong with that. I’m OK with yaml. the point is that there is no pre-packaged code as there is with Tasmota. So that makes it harder to get started with.
You kind of need the development environment (dashboard) to make things easier to do. I think there is another way over CLI (maybe…?) but I just installed the dashboard right away so I’ve never used it without one. It really isn’t too big of a deal tho. I use ESPHome in docker and installing the dashboard was as easy as adding an environment variable.
Conclusion:
use it if you want customized devices and want to use yaml instead of arduino. Or if you don’t want to run a middle-man broker. But t will be harder than Tasmota for standard devices.
I have pretty much switched everything over to ESPHome from Tasmota but I can’t really specifically say why.
I think it was more of a “keep everything in one place as much as possible” thing.
I have three ESP8266 devices that don’t use ESPHome and they use Arduino code along with MQTT. I already had those working and/or couldn’t easily figure out an equivalent functionality in ESPHome to switch over.
I no longer have any Tasmota devices.
If you already have a device running Tasmota then it won’t be “easy” to switch to ESPHome and likely won’t be worth it for you. But if you want to try it out then it won’t be overly difficult either, especially if you know your way around yaml.
6 Likes