Just checked the release notes of the latest tasmota and in fact it (only?) mentions arduino for the available binaries:
ESP8266 or ESP8285 based
The following binary downloads have been compiled with ESP8266/Arduino library core version 2.7.4.9.
and
ESP32, ESP32-C3, ESP32-S2 and ESP32-S3 based
The following binary downloads have been compiled with ESP32/Arduino library core version 2.0.3.
and then a list with a stunning 166 (
) different binaries to choose from 
Oh I prob took this too literally as was like why would I install tasmota to OTA to esphome ?!? I guess it was just if I wanted to swap.
I am 54 (An age when I have to look at the calendar for some quick math)
I am often caught flashing 
but yeah OTA is super handy
Its definitely proprietary by definition as both open and closed source can be proprietary, still curious to this, just because its open doesn’t mean its not proprietary.
Just some feedback as device qty I went on
Tasmota https://templates.blakadder.com/ and at 1st glance there seems to be more than
https://esphome.io/ but bear in mind it was just 1st impressions I think its just that much front of house was modules/boards and turned off as find the made for cases so much less hassle and strangely often find its cheaper than trying to find a housing yourself dunno why plastic boxes seem to cost so much when not wrapping a product.
So yeah I was talking end product rather than microcontroller but also got in my head that was true as it seemed to be very esp82xx
Its sort not correct yeah the 1st version was but the latest version 5 is a few years or something?
Also unencrypted MQTT port is 1883 encrypted TLS port is 8883? with payload encryption also but its choice whether to employ not that it doesn’t have?
Sort of undecided on that one being honest it just sounds a bit like choice words than reality, doesn’t matter but being honest my eyebrows are still slightly raised on this one
So like usual but often when your just reading up and getting 1st impressions you can often go wrong
Also I am not arguing just saying what I think as it will just take time to absorb.
On another note I have these for sale and to get rid prepared to do some one a deal. Which I just thought of at this minute as was going to bung em on ebay but someone might want 1st dibs and will go to a good home.
esp32-s3-wroom-2, esp32-s3-wroom-1 N32R8V think the other is N8R2
esp32-s3-box, esp32-s3-box-lite.
I got the esp32-s3-box as I was thinking I could hack that out to use 2x I2S mics but it uses a 3rd ADC from the DAC for the AEC so my idea came to an end.
I then got a esp32-s3-box-lite as they must of realised they could just count the clock cycles of the I2S output and just use a 2 channel ADC, which prob means you can hack in a 2x I2S mics on a normal dev board.
I have got the tensflow part of KWS dataset and building off to quite a fine art as to boot the relatively crappy hi-esp model and replace with a custom, but you just know when something is going to gather dust.
£50 for the lot but otherwise it will just be an ebay auction might be less might be more dunno.
I have done quite a bit of work with the Pi and did a delay-sum beamformer on the Pi with some hacky C/C++ ProjectEars/ds at main · StuartIanNaylor/ProjectEars · GitHub
Someone here might be interested in checking out the new box framework.
I think its not worth the load as you can prob fit KWS & websocket single mic broadcast on a core and esphome device on the other. Its just better to have a single mic on a device not playing audio as the resonance even with the best AEC is cruel.
My idea of a distributed array of mic devices using softmax to get the best one of a common model still is good but you know when something is going to gather dust.
Doesn’t matter as they where going on ebay but as I was replying I just thought hey one of you guys might be interested.
Indeed, once you “own” a device (got rid of the stock firmware) you change the software the way you want.
What definition would that be in particular? I was thinking about proprietary software 
Proprietary software, also known as non-free software or closed-source software, is computer software for which the software’s publisher or another person reserves some licensing rights to use, modify, share modifications, or share the software, restricting user freedom with the software they lease. It is the opposite of open-source or free software.
I suspect that probably every device you find on templates.blakadder.com works with esphome too. The site esphome-devices.com lists complete yaml’s for a few devices but many esphome users typically consult the blakadder templates for the needed gpio’s pins 
The thing is that it is a different approach (might wanna read this thread because I wrote it down already in “numerous lengthy posts” @123 likes to say 
).
With esphome all you have is one “recipe” in which you define every aspect of a device.
As an example this device here: ESP-01S 5V Relay Module V1.0 Relay Board (ESP-01S-Relay-v1.0) Configuration for Tasmota which is essentially a relay and not much more. The site on the right lists the gpio pins:
In the “esphome” world that could be simply a gpio switch and all is needed to get a switch is this:
switch:
- platform: gpio
pin: 0
name: "Super Duper Relay Switch"
Thank’s to the magic 
of the native api this will be visible and controllable in ha directly:
Well, it’s all backwards compatible and only “new functions” are added from what I know. The core is still the old architecture released 1999 and that never had local highspeed networks in mind (that is what we have at home with wifi 
)
MQTT
It is designed for connections with remote locations that have devices with resource constraints or limited network bandwidth.
In the end it’s your choice and
And if you get a smart plug with power monitoring for £12 which is already pre flashed with tasmota sticking to mqtt for the start sounds like the easiest option. You are always free to change your firmware in the future and flash whatever you want or need over it
Yeah I will just see as 1st will try the mesh and if depending on what is inside OTA
I saw the topic heading and was intrigued…
I use two tasmotized Sonoff RF Bridges (for redundancy) to allow various 433MHz RF “light” switches operate with HA via MQTT and suitable automations.
Having seen the debate, my first thought was to see how hard/easy is it to upgrade my current RF Bridge Tasmota firmware. The answer - an absolute breeze to go from v9.4.0 to v12.0.2 (latest I think). Just clicked on the OTA url Firmware Upgrade and both done within a minute.
That’s not to say that ESPHome might have been just as easy, but the initial point was about migrating.
So, all other things being equal, are there any real benefits to me migrating to ESPHome for my basic user case?
In particular, is there likely to be any latency/speed improvement? It works reasonably consistently and reliably with Tasmota, but there is a slight lag between switching and lighting. Not unbearable, but noticeable.
I’ve switched to esp long time ago, mainly because i had some issues with a dual channel dimmer. Once i did that, it didn’t take long before all my tasmotised devices went over to ESPhome, found it better and easier than tasmota.
However, I’m still stuck with one last tasmota device, it being a RF433 bridge. If i’m not mistaken, it can be done, but it’ll require some hardware modifications. Not that i am scared to do that, i have all the equipment and expertise; I just didn’t have the time to do it, nor do i see the real need for it; i just need something to control my RF433 devices.
btw, just saw someone mentioned ram shortage, be aware there is a tasmota-minimal.bin, just for that purpose, the only thing it will allow you to do is re-flash it OTA (in my case with an esphome bin😉)
PS:
I never measured it, but i think esphome is faster (and smoother for the dual channel dimmer i had)
Indeed, but don’t ask the users that flashed tasmota months or even years before you and running Tasmota Versions 5,6,7. They are essentially trapped and can leave there vulnerable devices running for ever or bite the apple and start essentially from scratch when they are not adventures in trying the “upgrade flow”
Don’t forget that you navigated to both of the devices before in the browser, entered your password (hopefully) as well as entered the correct menu to start the ota upgrade.
As a comparison. With the esphome dashboard (running on ha for example) it is one click on “update all” to update all my esphome nodes in my network at once, we are talking about 90 devices here
You can essentially get rid of mqtt. A nice way of getting your rf “payloads” into home assistant is (ab)using the tags so you can make use of this nice interface here for your rf thingies:
from the esphome side all is needed is the homeassistant.tag_scanned action
Another way to achieve the same directly on the esphome device without having anything configured in ha (like a automation or something) is to trigger the (ha) action directly inside the esphome node, with something like this (that is how I do it with my IR thingie)
binary_sensor:
- platform: remote_receiver
raw:
code: 0123456789
on_press:
- homeassistant.service:
service: homeassistant.toggle
data:
entity_id: switch.tv_set
In theory (like already extensivly written in this thread) the native api from home assistant outperforms mqtt with it’s performance focus on low latency and efficiency.
In practices the lag you are experiencing could also be introduced from the RF part of the light switching scenario.
OK, thanks both.
It looks like the answer for me is no point in migrating to ESPHome.
The hardware hack isn’t strictly necessary - it just allows to get “more” out of the box.
When using it without modifications with esphome there is a RF Bridge Component which does the communication with the efm8bb1 mcu
And turns out there is another “premium” way (beside the two I just explained) to have the rf payloads handled between esphome, ha and the power of the native api
RF Bridge Component
[…]
Getting started with Home Assistant
The following code will get you up and running with a configuration sending codes to Home Assistant as events and will also setup a service so you can send codes with your RF Bridge.
Sorry, @orange-assistant but I’m just not convinced that a hardware hack isn’t required.
According to @dancem in the thread you referenced…
And in any case, it still may not cure the minor lag issue, as we all agree.
I appreciate your enthusiasm and what ESPHome may do for you, but please put the evangelising to rest for my case. It really just doesn’t seem to be worth it for this scenario.
The post you are referencing is over three years old, the link to the official esphome documentation for the RF Bridge Component (one post over yours) was last updated about 4 months ago and the first sentences states:
The RF Bridge Component provides the ability to send and receive 433MHz remote codes without hardware hacking the circuit board to bypass the efm8bb1 MCU.
Any reason to don’t trust official documentation?
the minor lag issue
Yep, I also had lags with MQTT and that is why switched to native ESPHome connection almost immediately (no lags since then).
The post you are referencing is over three years old, the link to the official esphome documentation for the RF Bridge Component (one post over yours) was last updated about 4 months ago
Good point. I did not check latest changes, but if the team found a way to bypass it - that’s perfect!
If sonoff RF bridge is anything like RF receiver in sonoff dimmer etc… then it’s pretty much useless anyway, since it can trigger randomly, while sometimes triggers by itself, or it just doesn’t “see” pressed remote - you have to press mulitple times in order to get a response. The one in dimmer is know to have that behaviour…
Could someone point me towards an ESPHome or Tasmota solution for an idea I have? I want to mount a distance sensor to measure the distance that my patio door is open so I can auto open/close the vertical blind to match the door open position so the verticals aren’t flapping in the breeze!
I got the idea in my head from the Open Garage sensor…
Don’t know if the HC-SR04 Ultrasonic Sensor will work since I have a screen on the outside of the door opening; the detection “beam” would need to be narrow… Thoughts?? Other ideas??
That’s simply: Nonsense 
Did and have to do it from time to time for customers and never ran into problems. The worst I have experienced is that I had to repeat a step for a second time while doing the “upgrade flow”. Harmless and far from “adventurous”.
However, wondering why this topic was turned into some kind of ideological conflict within the thread.
Why not simply letting it be to each his own without the zeal for conversion? 
I have yet to find a single person who can unequivocally tell me they have done it and that it works.
But if someone knows otherwise, I’m ready and willing.
I may try with one of my bridges at some point in that case.
But I’d love to hear from someone who has done the migration without a hardware hack first - if there is anyone…
I am considering it, I only need reception.
But still,it would be nice if i had a second sonoff bridge (just in case it wouldn’t work🤔)
I would advise against the use of esphome in that case because working with the (official) docs is kind of mandatory!
Just backup you present firmware and you can role it back anytime you want. As this is all esp here no risk of bricking involved.