Tasmota in 2019
August 28, 2019Today on the hookup I’m going to show you everything that tasmota can do in August of 2019. We’re going to cover topics like flashing methods, templates, commands, rules, and group topics. Even if you’re a long time tasmota user, stick around, you might just learn something.
For so many people, flashing their first store bought device with Tasmota represents the beginning of their home automation journey. Tasmota started out as a custom firmware meant only for sonoff devices but and has transformed into an incredibly powerful tool for controlling anything with the ESP8266 wifi chip. As tasmota has matured new options have popped up to try to unseat defacto standard, but I’m going to show you today why, in my opinion, tasmota is still the best option in most cases.
If you don’t know what tasmota is, this is my quick 45 second sales pitch for it: Tasmota is an open source custom firmware that runs on any ESP8266 based device. Tasmota gives users local control of their devices through either MQTT, HTTP, or Web UI. Tasmota comes packed with drivers to support basically every popular sensor or chip that you’d find in off the shelf smart home products. Tasmota is extremely stable and reliable and allows your devices to be manually controlled in the event of a total network outage. Tasmota is simple enough for a novice user and has enough advanced options to keep even the most seasoned automater happy. The more devices you have with tasmota on the more standardized your smart home will become and the easier it will be to manage.
This video is going to cover everything from flashing to advanced rules, and I’ve included timestamps in the description for you to find what you need, or link to as a reference for helping out other users.
We’re going to start with the flashing process, which will always be the first step in adding tasmota to your device.
There are two general methods for flashing tasmota: Over the air, or hardwired using a USB to serial FTDI adapter. In my opinion, OTA is always easier when it works, but most OTA methods rely on exploiting vulnerabilities in the factory firmware, so when companies like ITEAD and Tuya learn about these vulnerabilities they are usually pretty quick to patch them. Unfortunately, that means that depending on the manufacture date of your device there’s a good chance that attempting the OTA method will end in failure and frustration. That being said, when it works it’s a huge timesaver. I’ll leave the link to a Tuya Convert walkthrough, and a Sonoff DIY mode tutorial down in the description.
If that fails, then your next option should be to flash using the hardwire method. Some companies like shelly make the process extremely simple by providing you with a set of female header pins and a wiring schematic, while some other products make it nearly impossible by gluing the outer shells of the device together. In order to flash your device you’ll need access to 5 different pins: RX, which is the serial pin that receives data, TX, the serial pin that transmits data, 3.3 volts and GND, which provide power to the chip, and finally GPIO-0. GPIO-0 is necessary because attaching that pin to ground during the boot process of the ESP8266 causes it to go into a special flashing mode and prevents any other code from running on the device.
Since my FTDI adapter has male header pins and most boards will either have female headers or through holes on the circuit board I have a set of female to male jumpers that I always use. I also created a splitter that connects both GPIO-0 and GND on the device that I’m flashing to the GND pin of the FTDI adapter.
Once all the wires are hooked up, plug the FTDI adapter into your computer and the ESP will boot into flash mode since GPIO-0 is grounded.
Next you’ll need to download one of the precompiled .bin files for Tasmota. Head on over to the thehackbox.org/tasmota/release where you’ll find the current stable versions of tasmota compiled on different versions of the ESP8266 Arduino core. At the top of the list you’ll see a few variations of the compiled code. The difference between each of these bin files is that each one includes different driver files for various sensors and outputs. As more driver files are included the size of the image increases and in some cases your device may not have enough on board memory to handle the largest version, however, in that case you likely wouldn’t need all the driver files anyway. As a general rule I tend to use the sonoff.bin file for my devices.
The other option that you have on this page is to choose which version of the ESP8266 arduino core you want to use. Tasmota offers versions compiled with core 2.3.0, 2.4.2, or 2.5.2. Core 2.3.0 is widely regarded as being the most stable version of the ESP8266 core and 2.4 and 2.5 both introduced some serious memory leaks that negatively impacted performance when they were first released. The .2 revision of these versions are both supposed to be free of memory leaks, but many users still report a decrease in reliability in these versions. The major downside of core 2.3.0 is that it is vulnerable to the KRACK exploit that allows a hacker to possibly compromise the encryption of WPA2 by forcing the reinstallation of an already known encryption key. That exploit has been patched in all versions of the ESP core after 2.4.0. Personally I use 2.4.2 for my tasmota devices and I haven’t noticed any stability issues. Let me know down in the comments if you’ve had any issues with versions of the core over 2.3.0.
At this point I use a program called NodeMCU Py Flasher to upload the .bin file to the device. If you go to the NodeMCU Py Flasher github page (and don’t read the directions) it seems like you’d need to compile the program from source, but if you go to releases you can download the precompiled .exe file and get started immediately. A major advantage of NodeMCU Py Flasher over the popular ESPEasy tool is that it gives you the option to erase the chip completely before putting your new program on. In some instances this is necessary due to variables that can be stored in the SPIFFS filesystem that could mess up your new install, so I always recommend checking that box.
Plug in your FTDI serial to USB adapter if you haven’t already, and press the refresh button, and select autodetect to find your ESP device. Select the sonoff.bin file that you downloaded earlier, and choose 115200 as the baud rate, DOUT as the flash method, and “yes” to wipe all data.
Once you get the message that the flash was successful you should see a new SSID pop up with the name “Sonoff” with some numbers after it. If you connect to that SSID you’ll usually be automatically directed to a captive portal to input your wifi information. If you are not automatically redirected you can open up a browser and go to 192.168.4.1 to access this web interface.
After you input the necessary information and press save your device will reboot and you can find its IP address on your network by looking on your router or with a network inspection app like fing. If you have mDNS enabled on your network you can also access the webUI by entering the name of the SSID that was being originally broadcast into your browser with http:// in front of it.
Whatever method you used, you should now be looking at a very basic tasmota home page with “sonoff basic” as the module and “sonoff” as the name. To avoid random restarts due to reconnection attempts, my first action in the tasmota interface is to setup MQTT. You’ll find that option by going to configuration, and then configure MQTT.
If you are going to use only HTTP to control your tasmota devices because you don’t have an MQTT broker you’ll want to disable MQTT completely, not only for security, but also to avoid any random reconnect restarts. To do that you’ll go to console, then type setOption3 0 and press enter.
The next task is setting up the pins for your specific device and it’s connected relays, sensors, and outputs. This used to be the most time consuming part of a new tasmota installation, but with templates all that headache went away.
After my Tuya convert video it was my goal to setup a database for Tuya devices on my website, but at the same time another user BlakAdder set up a similar database on github. His database is great and uses github’s pull request format to allow users to submit new templates and make corrections, it’s so good in fact that I actually just link to his template page on my website now.
The BlakAdder template database allows you to browse devices by region or type, and each device includes a picture since many of these devices are white label products that are being sold by many different resellers and should work with the same template.
Once you find your device, all you need to do is copy the JSON text from the devices database, paste it into the Template field of the “configure other” menu in tasmota, check the box that says activate and press save.
Once your device is restarted you should have a fully functional device with controls for each relay or light and a display for each of your sensors.
At this point you are finished with the general configuration of Tasmota, but you’ve barely scratched the surface of what is possible. Next you’ll want to integrate tasmota with your home automation platform of choice. I’m not going specifically cover each configuration in this video since we’re talking about tasmota, and not automation platforms, but I’ve got links in the description for how to integrate tasmota into Home Assistant, OpenHAB, Smart Things and Hubitat.
If you’re trying to stay hub-free Tasmota also supports local Amazon Echo integration via the ESPAlexa library. The major upside to the ESPAlexa library over other options for echo local discovery is that recent improvements allow it to be discoverable by both newer and older echo devices.
To enable echo integration go to Configuration and then Configure Other. Here you can select “Hue Bridge” for your alexa integration and change your device’s friendly name. The friendly name is what will show up in your amazon echo app when you discover devices. If your device has multiple relays you can create a friendly name for each one and your echo device will discover each one separately.
If you ARE integrating into a hub both home assistant and openHAB use MQTT to issue commands to tasmota, while smart things and hubitat use http, but the great thing is that all the commands are actually the same, and no matter what you need to do, whether you’re changing the mode of a switch, turning off an LED status light, or calibrating your power usage you’ll probably find a command for that option in the extensive tasmota documentation.
When issuing commands via http you just point your web browser to the IP address of the tasmota device, and tack on “cm?cmnd=” then the command you want to issue, %20 which is how you input a space in a URL, and then the value that you want to issue to that command. For instance, if you wanted to change switch1 from a momentary switch, to always following the state of the lightswitch you’d send this command:
“ http://<Device_IP>/cm?cmnd=switchmode1%201”
and the tasmota device will respond with a JSON formatted state message showing that your command was accepted and a specific setting was changed.
If you are issuing commands via MQTT the topic will be “cmnd/deviceID/<Specific_Command>” with a payload of whatever you want to change it to. So to change switch one back to a pushbutton switch I’d send an MQTT message to this topic:
“cmnd/cabinetLights/switchmode1” With a payload of 5, and tasmota will respond with a JSON formatted state message on the result topic, which for this device would be “stat/cabinetLights/RESULT”.
A huge benefit of using MQTT is that you can issue the same command to every tasmota device at the same time by using your tasmota group topic. By default the group topic is “sonoffs”, so lets say you wanted all of your tasmota devices to report their current relay state to you, you could send an MQTT message to the topic cmnd/sonoffs/power1, if you then sent a payload of 1 it would turn all of your devices on, or a payload of 0 would turn them all off, but if you send an invalid payload like “check” it will cause all of your devices to send whatever their current state is. This method is commonly used to solve the problem of home assistant not knowing the state of MQTT devices after a restart.
The group topic also makes things like changing your SSID and password super simple since you can issue a single MQTT command to change every tasmota device in your house.
If you choose to issue commands via the web interface, you’ll just open up the console, type in your command, then a space, and then the value that you want to change it to, so to change our switch to a edge switch, or one that sends the toggle command every time the switch changes state we’ll enter “switchmode1 7” and you’ll see the result issued in the console on the next line.
In certain cases it may be beneficial to use something called the backlog command to enter many commands at once. An example of this would be if you are trying to change your wifi SSID and password. If you just issued the command “ssid1 MyNewNetwork” it would immediately change the wifi network to that new value which would trigger a device reboot. However, if you also needed a new password then your tasmota device wouldn’t be able to join the new network and you’d have no way of issuing the command to set a new password.
Instead, you’d use the backlog command, separate each different command with a semicolon and tasmota will process them all in order before trying to restart. For instance, changing our wifi network like before would be done with the backlog command “backlog ssid1 MyNewNetwork; password1 MyWiFiPassword” which will prevent tasmota from rebooting until all of the commands have been issued so your SSID and password will change together and your device will be able to properly connect to your new network.
In the very rare event that your specific need isn’t already baked into the tasmota firmware you can also get a little more advanced and setup rules to let tasmota handle some logic. The tasmota rules engine is event based so you’ll always need some trigger to begin the rule.
Lets say for instance that we wanted to control a fan that turned on when the temperature was above 100F and off when it dropped below 90F. If we had a device with a relay and a temperature sensor we could write a rule for that.
We start our rule by telling tasmota which of the three tasmota rule sets we are defining, which will be rule 1 in this case and our trigger is going to be the temperature of our AM2301 temperature sensor, so to start our rule we’ll type
Rule1 on AM2301#Temperature>100
Then we need to give it an action, or something to do, so we’ll add
Do power1 1
And since we don’t need to do anything else on that trigger we’ll end that statement with endon. Then in the same rule we can add the other trigger to the same rule by following those steps again, so our final rule will look like this:
Rule1 on AM2301#Temperature>100 do power1 1 endon on AM2301#Temperature<90 do power1 0 endon
The last thing you’ll need to do after entering this command in the console is to turn on that specific rule by typing rule1 1 and hitting enter.
You can even use rules to allow your devices to talk to each other without the need for a smart home hub. By changing the just a few things in the previous rule set we can have a device with a temperature sensor issue a command to a separate device to turn a relay on or off, which would utilize the WebSend command to send http and would like something like this.
There are a ton of different triggers that you can use to start your rules, and you can use any of the commands we talked about earlier as actions, including the backlog command, so you can have a single trigger cause multiple actions, and you can even add delays between them. There’s a great page in the tasmota documentation that has different rules that you can use as templates for your own specific needs.
As you can see, tasmota is an absolutely insanely powerful firmware that gives you local control and thousands of configurable options that don’t require any knowledge of C++ and are relatively intuitive to use. I’m a firm believer that MQTT and home assistant are the best way to manage IoT devices, but as you can see, the native amazon echo integration, the ability to send commands over http, and rules that can create automations directly on your devices makes tasmota a great choice, even if you don’t have a smart home hub.
As always, if you enjoyed this video, make sure to hit that thumbs up button so it gets shared with other people who haven’t found the channel yet. If I got something wrong, let me know down in the comments. Thank you to all of my awesome patrons over at patreon for supporting my channel and allowing me to make videos that feature free and open source software like tasmota and home assistant. If you’re interested in supporting my channel please check out the links in the description.
If you enjoyed this video, please consider subscribing, and as always, thanks for watching the hookup.
