Hello good people,
I’m genuinely curious on what are the benefits of flashing Shelly devices to Tasmota? I will be installing some Shelly switches (Dimmer 2) that will be connected to Home Assistant.
Happy to hear your point of view on whether to leave stock firmware or to flash it; as far as I can see, their devices can be flashed via WiFi so shouldn’t be too much of a hassle.
PS: I searched a bit and I don’t think I’m duplicating a topic, but if I am - please feel free to delete my post.
That is an excellent question. When I bought my shellies, the only way to integrated them with HA was manually configure them using MQTT, or flash them with Tasmota. These days, there are 3 other ways to integrate them with HA : the custom component shelly4hass, the shelly mqtt discovery script and a native shelly integration.
So for me : the big advantage of Tasmota : my 10 shellies, my 40 sonoffs, my 30+ tuya devices and my 2 sinilinks are all flashed with tasmota. Just having to support 1 integration is a big benefit, but your mileage might vary.
Why not flashing them with esphome?
There is a 2way integration via the local api.
There is forth method still: manual configuration using mqtt integration. Which I prefer over discovery script btw.
From what I know tasmota provides more options to support multiple and configurable clicks/long presses (tbh it’s the only thing I miss from original fw). Also has built-in support for mqtt discovery.
But not all shelly devices are supported by Tasmota. So if you want to have as much homogenous architecture as possible you could want to stick with shellies.
Just looked at esp compatibility table: there is only support for relays. no rgbw2, no sensors (door/window, temp/hum, gas, smoke, flood), no bulbs and others. No dimmer too
Yes, but I have only shelly relays.
Same question here. I installed 2x 1PMs and a 2.5 connected to light switches over the weekend using the native Shelly discovery / integration - my initial / related observations are A) the native Shelly setup seemed a bit flaky (multiple update / save cycles to configure always on / detached etc.), B) they run between 43 c / 110 f (the 1s) and 65 c / 150 f (hotter for the 2.5 - servicing 2 switches), and C) they ping api.shelly.cloud once an hour (I did not add them to the Shelly cloud).
A and C had me leaning towards trying a Tasmota flash before installing the next one - but B has me a little nervous flashing away from the native firmware. I’m not quite used to having 65c + temps reported from inside my walls - sure, that’s well within specs and other existing in-wall elements may already run that hot or hotter, but seeing the data prompted some quick research on the subject. A ‘shelly runs hot’ search returns a few pages describing a Tasmota firmware update that resulted in materially higher Shelly temps (description of issue / resolution here).
The realization (/reminder) that a firmware bug could have this type of impact has me sticking with native Shelly for now - if I was to run a non-native firmware I’d definitely introduce a change management process to load / validate / monitor all updates in a test environment prior to flashing installed units (too much overhead for me at the moment).
It may be an old post, but I think it is worth to share my experience. For me it was a mandatory journey. As a matter of fact, Shelly 2.5 configured in roller shutter mode has a time limit set to 120 seconds. I needed 150 seconds and I gave a try to Tasmota. I was pleased to discover that it accepts up to 240 seconds. Strangely, Shelly support claims that 120 seconds is due to a hardware limit. My experience shows it is not true. Since I already had an MQTT broker setup, it has been an easy matter to integrate it to HA.
I discovered an another important missing feature in Shelly firmware: there is no way to save configuration, believe it or not, whereas you can do it with Tasmota
What kind of configuration are you trying to save that is not available on Shelly?
shelly 4pm for instance: AFAIK there is no way to save the whole set up which may be cumbersome to set-up again in case of hardware crash. I find it not very pro for so called pro devices
I very much appreciate the approach from esphome in such a case. No need to enter wifi credentials or even re-upload a cobfig backup via web server to the esp. Just use the esphome yaml of the old/broken device, hit install and call it a day. Beside the native api is a real treat for every one that used mqtt already and looks for something that works without any (comberstone) setup.
You are right, however I feel more confortable with Tasmota mainly because of documentation. ESPHome documentation albeit beeing extensive, lacks to my point of view in depth tutorials, but this is another story.
I gave Tasmota only a short try (in a desperate search of a reliable alternative to my forme zigbee setup) but despite the somewhat extensive documentation I were completly lost with all the ends were to setup things. Simple functions needed very crude scripts which reminds me to asembler - for other functions (like more than x one wire sensor) a manual compilation were necessery (same in case you want to use sensor Y with display X).
In the end someone recomended esphome as an easy alternative and I must admit, thats what is it. The docs are great (actually the best I know from the open source projects I use) and I actually like that they are spot on and not too lenghty. Last but not least the ha/esphome native api is really next level compared to mqtt (no setup/topics, more effecient…).
In the end it is great that all these projects exist because they can also improve each other. For example tasmota uses the web flasher which was made by the esphome/nabu casa team!
Based on what you said I must admit that I should put some effort to master this environment during winter time.