Goodbye Tasmota

[orange-assistant (the real one)]

@123

Possibly as easy, or even easier, than copy-pasting

Just received my esp muse luxe

I was really keen making a direct compression with the most recent tasmota and while it looks like it has support for i2s (at least some github comments look a like) I didn’t found any template or way getting this device functional with it. Also I couldn’t find anything useful in the tasmota docs how to control/use a i2s dac or how to make it work together with home assistant.

So instead I used the usual (fast) route and supercharged it directly with esphome

now I have a network/smart speaker that is perfectly integrated into ha without mqtt or any other hassle involved

And for everybody who missed it https://www.youtube.com/watch?v=SEH-DxOsywg

[stuartiannaylor (Stuart Naylor)]

I am a HA noob and also interested in BLE Mesh as more and cheap devices seem to be coming avail.
When I am looking at buying a device my 1st priority is to find non cloud interoperable devices so BLE Mesh seems quite interesting.
When I look though ESPHome seems to run on arduino drivers which seems to be a limiting factor whilst Tasmota uses the Esspressif SDKs to create binaries?

Espressif seem to be better than both as they have a wide range of support but with BLE Mesh & something new called Matter that used to be CHIPS which also runs on the C3 which Tasmota calls ‘solo’ devices?

Announcing Matter (previously ‘CHIP’) on ESP32

As a noob tasmoto seems to support more devices and my 1st reaction to the esphome-api is why create another proprietary system on opensource as surely its better to use open standards that are commonly used?

I don’t really know as still doing research and still have to play with some new switches I purchased but for feedback from a noob would say I am leaning towards Tasmota as a secondary to non cloud devices I can get that do not need firmware change.

Its not that I have fear of flashing or even a bit of C programming be it what ever IDE its just to not have the hassle and to know faults are with the device supplied and not 3rd party firmware as really my 1st choice is neither.

[orange-assistant (the real one)]

@stuartiannaylor

When I look though ESPHome seems to run on arduino drivers which seems to be a limiting factor whilst Tasmota uses the Esspressif SDKs to create binaries?

I thought the opposite actually. In the past tasmota used the (mainstream) arduino framework versions but then switched to it’s own custom fork probably because of space “problems”. But actually not sure about what the state is today as I didn’t used it recently - maybe they moved on to esp-idf?

Esphome on the other hand allows you to make use of ether the arduino framework or the esp-idf (and even choose the versions if you need to).

@stuartiannaylor

As a noob tasmoto seems to support more devices

Are you talking about the MCU’s (esp82xx, esp32, esp32-c3 etc.) or about peripheral hardware like sensors and actors?

Regarding MCU’s I think they both support the identical espressif chips while recently a pico w (rp2040) was showed off running esphome (work in progress). Also a nice progress to see in the github is the work on tuya MCU’s (RTL8710, BK7231, etc.).

@stuartiannaylor

1st reaction to the esphome-api is why create another proprietary system

Well, proprietary things from my point of view are closed source stuff. The native api on the other hand is open-source - like the whole esphome ecosystem including stuff like esp-web-tools and improv which was adopted by other projects like wled, tasmota or espeasy and could be called “open standard” if you would like

@stuartiannaylor

better to use open standards that are commonly used?

When the “common” alternative is a 20 year old protocol which lacks most “modern” features and has no encryption build in? Beside it needs setup and maintenance? Why not establish something new then which can be commonly used in the future?

The esphome site explains all the advantages of the native api in detail like efficiency, stability, low latency, one-click setup, etc.

@stuartiannaylor

Its not that I have fear of flashing

That term doesn’t even exists anymore in esphome. It’s only “installing” now.

I’m no friend of detechnicalizing wordings but it might just be easier for users. The term “flashing” always includes in the sub line the technical risk of bricking (rendering broken) but that is what’s literally impossible with espressif chips due to there design (being able to always activating flash mode even when a “broken” firmware is loaded).

@stuartiannaylor

or even a bit of C programming

I don’t even have programming skills but I make heavy use of esphome (with it’s yaml syntax)

ESPHome is a system to control your ESP8266/ESP32 by simple yet powerful configuration files and control them remotely through Home Automation systems.

[Protoncek (Pavel)]

I run a “double” of tasmota BLE receiver with esp32 for…a week or so now (i mentioned it above). Esphome is on esp-idf and runs without problems so far, while tasmota went offline once and rebooted itself after a while.
As i already said, i did have problems with esphome a while ago, when esp-idf wasn’t available yet for “normal” esp32 (only for C version). So, i guess that arduino drivers indeed can make problems…

[orange-assistant (the real one)]

@Protoncek

So, i guess that arduino drivers indeed can make problems…

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

[stuartiannaylor (Stuart Naylor)]

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

Is there a general overview of "compatible" hardware?

I built this programming jig for the R1 and flash ESPHome on it directly. I don’t have an R2, but the wiring layout looks identical. If you go the OTA route with Tasmota, you can very easily use the Tasmota upgrade to flash ESPHome binary OTA.

@orange-assistant

Well, proprietary things from my point of view are closed source stuff.

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

@orange-assistant

When the “common” alternative is a 20 year old protocol

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.

[orange-assistant (the real one)]

@stuartiannaylor

I guess it was just if I wanted to swap.

Indeed, once you “own” a device (got rid of the stock firmware) you change the software the way you want.

@stuartiannaylor

Its definitely proprietary by definition as both open and closed source can be proprietary

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.

@stuartiannaylor

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 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:

@stuartiannaylor

Its sort not correct yeah the 1st version was but the latest version 5 is a few years or something?

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.

@stuartiannaylor

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

In the end it’s your choice and

@orange-assistant

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

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

[stuartiannaylor (Stuart Naylor)]

@orange-assistant

Proprietary

Yeah I will just see as 1st will try the mesh and if depending on what is inside OTA

[herbertgoat (Mike Norris)]

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.

[aceindy]

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:

@herbertgoat

is there likely to be any latency/speed improvement?

I never measured it, but i think esphome is faster (and smoother for the dual channel dimmer i had)

[orange-assistant (the real one)]

@herbertgoat

absolute breeze to go from v9.4.0 to v12.0.2

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”

@herbertgoat

Just clicked on the OTA url Firmware Upgrade and both done within a minute.

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

v5.14.0 v6.7.1 v7.2.0 v8.5.1 v9.1 Current release

@herbertgoat

So, all other things being equal, are there any real benefits to me migrating to ESPHome for my basic user case?

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

@herbertgoat

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.

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.

[herbertgoat (Mike Norris)]

OK, thanks both.
It looks like the answer for me is no point in migrating to ESPHome.

1. It needs hardware hacks for the RF Bridge as I suspected and @aceindy confirms.
2. As @orange-assistant remarks, the lag is just as likely due to the RF part of the chain, so dubious whether any gains to be had at all.

[orange-assistant (the real one)]

@herbertgoat

1. It needs hardware hacks for the RF Bridge

The hardware hack isn’t strictly necessary - it just allows to get “more” out of the box.

@123

This upgrade provides for the recognition of a wider set of remote control codes than those natively handled by the EFM8BB1 auxiliary microcontroller inside the sonoff bridge. The EFM8BB1 microcontroller is entirely bypassed, allowing the ESP8266 to take care of decoding and decoding the RC pulses in a more flexible way.

When using it without modifications with esphome there is a RF Bridge Component which does the communication with the efm8bb1 mcu

RF Bridge Component

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.

[herbertgoat (Mike Norris)]

Sorry, @orange-assistant but I’m just not convinced that a hardware hack isn’t required.

According to @dancem in the thread you referenced…

@dancem

Yes, it is required. As it was mentioned before, ESP8266 on Sonoff RF Bridge actually don’t have RF modules connected. So you cannot control them with ESPHome as they are absent. WIth this hack you are manually connecting the RF components to ESP8266.

TASMOTA works with RF through EFM8BB1 microcontroler, so no modifications needed. I heard, that EFM8BB1 firmware is pretty limited, don’t see some remotes, and in such case you cannot change this.
With ESPHome (and the hack) I also modified RF protocol later to get it working with on of the remotes (which ESPHome don’t support).

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.

[system]

@herbertgoat

not convinced that a hardware hack isn’t required.

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?

[dancem (Dance Macabre)]

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!

[Protoncek (Pavel)]

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…

[dbrunt (Daniel)]

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??

[Tamsy]

@orange-assistant

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”

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?

[herbertgoat (Mike Norris)]

@system

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?

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.