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.
- It needs hardware hacks for the RF Bridge as I suspected and @aceindy confirms.
- 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.
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!
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.
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?
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.
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?
I’m aware of that as I’m an it consultant myself. But I was not aware that private individuals would ask for such services. At the same time when something like this is offered I would expect the contractor to choose a solution with central roll outs like we are used from other client platforms.
That said I know that a good/superior technical solution often interferes to some extend with economic success/win.
Like 10 or more years ago I inherited a customer because the old contractor retired. It was a small company and at the day of the handover he was talking very bluntly when I asked if there is a technical reason to have a network without activated DHCP server but solely relying on static IP’s. His answer was that it guaranteed him more (payed) work that way but at the same time uses all benefits of DHCP at home.
First action was obviously to enroll DHCP network wide (some static leases for servers included). It included some initial work to get past this “legacy” solution but it was definitely worth it - specially for the customer (not necessary for me monetary wise) as now there were no on-site support necessary anymore for on-boarding new devices.
On a tangential point purely because I looked last night and never found it and find for opensource not having a wikipedia style donate what you can style buttons on most of its pages is an ommision.
https://www.nabucasa.com/ doesn’t interest me as I don’t want anything cloud but ocassionally on various opensource I do bung $5 - $10 when I can.