I talk about Tasmota and ESPHome, along with Home Assistant, in many videos. Most of them focus on how to flash and integrate devices and sensors that are easily available. But which working environment is better also for our DIY sensors, for ESP32 boards and for sleep mode? Tasmota or ESPhome? Or none? You will know the answer at the end of the video. Greetings youtubers! The guy with the Swiss accent is speaking to you. With a new episode and innovative sensor ideas and microcontrollers. Remember that if you subscribe, you will always be in the front row. Most sure be happy to buy some Sonoff, switches, LED bulbs and other devices like Alexa, and control them with Home Assistant. A task that is really not easy. But there are videos on how to do that. If you want to go a bit further with automation, quickly you need more sensors. And, because the sensors are usually not connected to the electrical network, they must be energy efficient and have sleep mode. And wireless upgrade, which is somewhat of a contradiction, as we will see.
Usually, like many others, I have built my sensors using libraries for sensor chips. For integration, I used the two libraries ArduinoJSON and PubSub to create MQTT messages. I recently built an outdoor light sensor using the method traditional and an ESP32. But then I asked myself: Is this still modern technology? Am I outdated? That is why we will talk about the following: A brief overview of ESPhome and Tasmota. How is your personalization method? What boards are they compatible with? especially when we talk about the ESP32. How do we upload the firmware to the devices? What is the "ecosystem" like? For example, what sensors are supported out of the box? How can we add new sensors? How can we manage our devices? And how does wireless programming work? Is suspension allowed? And, in the end, what is my verdict? Let's start with the introduction.
In this video, we talk about devices that contain an ESP8266 or ESP32 with Wi-Fi connection. We can divide these devices into two categories: actuators such as relays to change energy, and sensors as buttons to initiate wireless actions. Some also have other sensors, generally to measure energy, temperature or humidity. When we makers buy any of these devices, we immediately flash them with our own firmware, usually based on the Arduino framework.
To be more productive, we use libraries for all kinds of tasks. Libraries are already a great improvement over simple code and luckily there is an Arduino library for almost everything, plus a tutorial on how to use it. But we can go further: we can use environments like Tasmota and ESPHome, that are one layer above. They use the layers below, but hide them from users.
The objective of this framework is similar to that of libraries: more productivity and simplicity. But, as with all simplifications, flexibility is also lost, and we have to decide if this compensation is right for us. If we want to automate some Sonoff, obviously the compensation is in favor of the use of a frame, and many of us use Tasmota, Espurna or ESPhome for a long time. But what if we want to build our own sensor? To answer this question, we first have to understand how these frames handle variation. Not all devices are the same. For example, there is a Sonoff Dual with two switches. Or a Shelly with a power meter. Or a homemade sensor with one or more unusual sensors. How do environments deal with that? Each level has its own way of handling variability. The microcontrollers are programmed in Assembler, the Arduino IDE in C ++, which has less possibilities than Assembler, but more productivity because C ++ is a "higher level" than Assembler. Tasmota and ESPhome also need such a programming language, which, ideally, is even "higher level". The higher the language level, the more specialized it is. Therefore, the languages of Tasmota and ESPhome must be adapted to "Home Automation".
As with any language, we must decide: Do we want a compiled or interpreted language? Tasmota, for example, settled on an interpreted language. So all devices are flashed with the same software and "customization" is done during operation. Therefore, we can change all the parameters during the operation. without loading a new code. The downside is that the firmware that is flashed to the devices it must include all the possibilities and it can become quite large. This is seen in the Tasmota project. Because they have to run on Sonoff's small flash, They couldn't integrate all the functions into one .bin file. That's why they have a different version per language or, more important for our project, also a different version for the sensors. The standard firmware does not contain the code needed to deal with with the sensors. By the way: they also have a version for screens. Which can't deal with sensors either. Therefore, you must decide which firmware you want to install on each device. ESPhome decided to go the "compiled" way. In this case, customization is done before flashing and each device is installed a personalized code.
If you want to change something, you need to recompile and upload the code, which is not a big deal because it can be done wirelessly. However, to customize Tasmota, you only need a browser. To customize ESPhome, you need software to write some "code" and compile it. So let's take a look at it and install Sonoff Basic, the most common device we can find.
Both frameworks offer preconfigured settings for Sonoff Basic. With Tasmota, we download “Tasmotizer”, we choose the firmware for our language, and we upload it to the Sonoff. I will not talk about how to flash the firmware to the Sonoff. I presume you already know. Next, we add the Wi-Fi and MQTT credentials and a call "template" and we press "save". Now our Sonoff does just what we expect. If you get an MQTT message, it turns on or off, for example. By the way, Tasmota has a template repository for all kinds of devices. For ESPhome, it's a bit different. If we are going to "start", we see two versions: one for the command line and one with a Home Assistant plugin. It's easy if you already have Home Assistant and you know how to install a plugin.
If we choose the "command line", we will surely get lost after a few minutes. We have to install python, pip3, docker, etc., etc. As a Linux newbie, I gave up when I didn't know if they wanted Python 2.x or 3.x, and when I saw that it does not work on a Raspberry. I used the IOTstack project from video # 352 to install all necessary and useful software packages. In particular, Home Assistant, Portainer and Mosquitto. Then, I started Home Assistant and installed the ESPHome plugin. Now we are ready to deal with the ESPhome work environment.
It is not that complicated. For the Sonoff Basic, we created a new node based on an ESP8266. ESPhome uses YAML files to configure devices. You might be wondering: what kind of programming language is that? Wikipedia knows, of course: is "a recursive acronym for" YAML is not a markup language. " Now you realize it's made for nerds … Luckily, like Tasmota, they have a repository for some of the usual devices. Also for the Sonoff. So we can copy and paste the content. Contains items such as Wi-Fi credentials, button, the relay and the LED. It is not much different from the Tasmota. However, the device repository is much smaller.
As we said before, this file must be compiled and loaded, just like with an Arduino. But wait: it only offers "wireless" charging. Which is great if the Sonoff is already flashed with ESPhome and you can receive the code. Why don't you offer USB charging like Tasmotizer? The answer is pretty obvious: ESPhome, like Home Assistant, runs in a container it does not have access to USB. Fortunately, there is a trick: if we press "download binary", we found a bin file in the download folder of our PC. Now we have to download the ESPhome flashing tool for PC or MAC and flash the bin file in Sonoff. From now on, we can use the wireless update. The containers can communicate with Wi-Fi, thankfully. The first round definitely goes to Tasmota. Especially if we look at the compatible devices. Here, ESPhome loses out, and you have to write YAML files for almost all devices. Tasmota doesn't need a programming tool either. With a browser it is enough. But we don't want to add another Sonoff. We want to build our light sensor capable of measuring IR, Lux, RGB and UV using the following sensors: TSL2561, TCS34725 and VEML6070.
Exactly like my ceiling sensor. And I want to use an ESP32 for the sensor. Why? Because it runs on solar power, and I found a decent board with all components. Certainly not as good as our "Superpower" board from video # 351 will be. but enough for now. It is still summer and there is a lot of sunlight. ESPhome supports ESP32 boards in its standard version. For Tasmota, we have to choose an "experimental" version. With Tasmota I would probably go with an ESP8266 on a Wemos Mini, and would add some hardware to manage the battery and solar charging. At least for now.
This point goes to ESPhome because we want to use the newer ESP32 boards. Now: How do we personalize devices? Like I said before, Tasmota, after flashing, is like a baby: a lot of potential and not a lot of capacity. You can change this through the interactive console where you enter commands, configuration options, and rules to change its behavior. By the way: you can also enter these commands via MQTT, which can be very useful. It is usually sufficient to define the functions of the GPIOs. This is done manually or using templates, as already shown, where we enter such template in Tasmotizer. Each pin is assigned a particular function and behavior. If we look at the generic template, we see all the available pins. If we apply the Sonoff Basic template, most of the pins disappear because they are already assigned to the button, the relay and the LED. We can only assign the unwired pins. If you need more, you can add a lot of options and even rules, they behave like a programming language.
With each release, their number increases and the limit is the memory of the ESP8266. You can even create and compile your own version of Tasmota, which is probably a bit against the concept of using a pre-built frame, and need a lot of reading. This point goes for both because both concepts have their advantages and disadvantages. For simple projects, Tasmota's method of using templates is best. If you want to add many sensors and rulers, a YAML file is likely to be easier to maintain and also to distribute to various devices if necessary. The following is how we configure the firmware on the device. Both frameworks offer wireless programming. There's no difference. One point for each. We get to the heart of the matter: How do we connect sensors? Luckily all my sensors used in the project use I²C, so it should be easy to connect them.
At ESPhome we start with a generic ESP32 device, we add MQTT and I²C and look for the first sensor: the TCS34725. It is in the repository, as well as a sample configuration. Copy and paste, compile and load. And we really see the MQTT messages coming from Mosquitto. Cool. How is this done with Tasmota? First, we have to know that we have to flash the file "tasmota-sensors.bin" on the device. The standard firmware is not compatible with all sensors. After that, the I²C sensors are also very conveniently connected. Just set the SCL and SDA pins to D1 and D2, respectively. Save and restart Tasmota. Because the sensors have different I²C directions, we can connect them all to the same bus. Tasmota, after boot, scan the bus and ok with the addresses found, enable the correct sensor.
Automatically. Too good for a sloth like me. I'm happy to give up some flexibility for such convenience. But wait: if we look for the TCS34725 and Tasmota, We only found a Tasmota fork. It seems that the standard is not compatible with this particular sensor. RGB values are not that important. The bad thing is that we also lose infrared, which would also be delivered by this sensor. But at least we want to measure Lux with a TSL2561. This is necessary for the control of my awning, the reason light sensor main. Yes! Tasmota is compatible. So hurry up and plug it in. Restart Tasmota, and it will display illuminance in Lux. Amazing. By the way: in this Adafruit list, you will find many sensors with their I²C addresses. Because most sensors, such as the TSL2561, they can use more than one address, things are not that easy for automatic detection. For the TSL2561, the programmer had a good idea and enabled all three directions. Thus, the TSL2561 is detected even when its address changes.
Unfortunately, 0x29 is also used by his new sister, the TSL2591. If you replace the TSL2561 with a better one, Tasmota thinks it's an old one with a changed address. Which, of course, does not react to the same commands. So even if both sensors are compatible, the newer one doesn't work. The third sensor, the VEML6070 for UV, by the way, it is also supported and automatically detected. Its newer sister, VEML6075, is defined, but not implemented in standard firmware. As we already saw, Tasmota's main problem is too many wishes and a small ESP8266 memory. Anyway, the number of functions they already included on this little chip it is amazing.
And ESPHome? Let's start with the TCS34725. Yes, it is compatible. Just copy and paste the example configuration in our YAML file. An advantage. Now follow the TSL2561. It is also compatible. Copy-paste, and you're done. Let's look for VEML6070 or 6075. Unfortunately, it is not supported natively. You would have to add it manually, a process that is not very well documented. So we have to live without UV in the ESPhome. After finishing the YAML file, we can validate the script. Everything is fine. Hit "load" and review the MQTT messages. Works! If we look at the sensors offered by ESPhome, we see that there are much more than Tasmota.
And although auto-detection is great, I like YAML better here. It's easy to add a sensor and we can control the directions if we need to. This point goes to ESPhome. Due to its limited space, Tasmota and its concept flashing everything on the chip cannot compete with ESPhome. If we look at the size of the current ESPhome sketch, we see that there is a lot of space available. I assume this is because ESPhome compiles and loads only the necessary code. The last question is key for battery-powered devices: Can these environments put the processor to sleep? Yes, both can.
With ESPhome, we just add these lines to the end of the YAML file. Run_duration tells how long the microcontroller runs after power on, and sleep_duration, how long is it idle. Pretty simple. And it works, as we see here. But I do not like. Why? Because we have to define how long it remains activated. We all know that ESPs sometimes take a little while to connect to Wi-Fi. So we have to include some kind of "worst case" in the run_duration calculation. But we all know that most of the energy is used when the device is on. It would be better to enable suspend as soon as the job is done. Maybe this exists and I still haven't found it? Please comment if you know more. If we type “DeepSleepTime 120” in the Tasmota console, the ESP8266 suspends for 120 seconds, it wakes up, does its thing, and goes back to sleep mode.
Downtime management is very sophisticated at Tasmota and it also calls an NTP server to calculate the next wake-up time. With the consequence that the time is safe here too necessary is not optimized. This point is a tie. Both can do it and both are not optimized for minimal power consumption. For a solar powered device like my light sensor, it should be possible to use it.
For a battery powered device, only if the intervals are long. So they both get 0.5 points. Please note: the wireless function does not work if the ESP is inactive. Both frameworks propose ways to send an MQTT message to ESP to keep it activated. The next time ESP is started, it will remain active and you can update wirelessly. After the update, you can send an MQTT message to return to sleep mode. Thus, you need a minimum of energy. The same goes for Tasmota, by the way. Of course, your HTML page does not react if it is in sleep mode. During my tests, I pressed the reset button and entered DeepSleepTime x0 as soon as the console was accessible. Of course, this can no longer be done when the sensor is on the ceiling. The last question is how to integrate the new sensor into the home automation system. Both systems offer a management platform that can be integrated into Home Assistant.
TasmotaAdmin also runs without Home Assistant. It is already part of IOTstack. ESPhome does not have an easy-to-install standalone tool. TasmotaAdmin provides much more information on the status of all nodes. I did not find a similar function for ESPhome. So this point goes to Tasmota. Both frameworks offer tools for automation. In Tasmota, they are called "rules" and in ESPhome, "Automations". Sure there is more than general description in a YAML file than when entering rules in the console. They both have a steep learning curve and there aren't many tutorials, especially for ESPhome.
Therefore, this is definitely nothing for the weak. For sensor nodes, automation should not be important. Also, it is better to do most of the automation on a higher level. So they both get that point. In summary, we see the result: 5.5 points for both. This surprised me. If we highlight the differences, we see that both frames they have different strengths. While Tasmota is well prepared for standardized devices commercially available, ESPhome is more suitable to build our own sensors. Certainly something will change over time. Tasmota on the ESP32 will become mainstream. And if the developers play the cards right, they will use the extra flash space to add support for more sensors.
Then the result will be very different. Now my verdict and decision for my sensor: I still have to keep my homemade sketch because I want all the sensors. And also, because I can better optimize the suspension. So I have to live without all the convenience that frames offer. At least for now. As always, all the important links are in the description. Hope this video was helpful or at least interesting. If so, consider supporting the channel for more videos in the future. Thanks. Goodbye!.