Goodbye Tasmota

[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.

[herbertgoat (Mike Norris)]

@dancem

Yep, I also had lags with MQTT and that is why switched to native ESPHome connection almost immediately (no lags since then).

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…

[aceindy]

@herbertgoat

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🤔)

[kvhrs (ojggiszommmwfrshuf)]

@herbertgoat

@system

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.

I would advise against the use of esphome in that case because working with the (official) docs is kind of mandatory!

@aceindy

in case it wouldn’t work

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.

[kvhrs (ojggiszommmwfrshuf)]

@Tamsy

Did and have to do it from time to time for customers and never ran into problems.

Probably not your intention but why would a user pay (if you are not working for free) some one for applying updates when the user just could do it by themself?

@dbrunt

Thoughts?? Other ideas??

Best is to open a own thread to discuss this and I would suggest to use a ToF like the VL53L0X or TOF10120 for your adventure.

[Tamsy]

@kvhrs

Probably not your intention but why would a user pay (if you are not working for free) some one for applying updates when the user just could do it by themself?

Have you never heard about people buying packages with SLA’s which also include updates/upgrades up to a certain point?