Awesome video, pretty much the same conclusions I've come to: 1. Tasmota is easy and works really well for pre-defined products 2. ESPHome can allow non-programmers to get a "good enough" configuration for their home built projects, but if you already know how to write code in Arduino you are probably still better off writing your own custom firmware. For the OTA tasmota deep sleep on the roof problem: Send an MQTT message with retain, that way when Tasmota wakes up the next time it will grab that message and prevent deep sleep. After you make your update just send a blank retained message to that MQTT topic to clear it out.
I saw the trick with the MQTT message and I thought I mentioned it in the video. The only problem is that I have to wait until it wakes up the next time. This is no problem if it is every 10 minutes... I assume not many people use these frameworks with deep-sleep. Otherwise, maybe somebody would have included this function into the administration: MQTT message sleep off, OTA, MQTT message sleep on... But anyway, I do not update my running devices that often.
@@AndreasSpiess The only way to shorten the deepsleep is an external reset switch that you can reach. Maybe coupled with the deepsleep switch I mentioned above. To have no access to the device during the deepsleep is the nature of this feature. You can use rules to check is there is a new OTA update and go for this. But this will increase the uptime again and does not make sense in my mind.
@@AndreasSpiess, true, you can *deep-sleep.prevent* *on_message* and it's generally always good thing to *fast_connect: true*, unless you have really complex Wi-Fi roaming.
I tried both. ESPHome is much more powerfull. You can do data treatment on the device itself before sending it to Home Assistant and avoid ugly data entering Home Assistant.
Thank you Andreas! Again a great video! In the current version of ESPHome (2024.6.6) there are now four different methods availabel to flash the device. 1. via Network 2. plug USB in your PC 3. plug USB in your HomeAssistant-Server eg. Rasperry Pi 4. manual download (as you referred in the video at 10:10)
I wanted to take a moment to thank you for making this video. I'm running HA in a virtualbox VM at the moment while I await my pi to arrive. You provided some key information that I could not find in other videos regarding getting the first binary into my NodeMCU so that I can continue with OTA uploads. All the other videos had demos of ESPHome Add-on having ESPHome-Flash built in, which mine doesn't. You pointed me in the right direction with the download binary, and I found ESPHome-Flash executable for windows on the web and downloaded it.. All went well after that.. This NOOB thanks you very much for that, as well as the comparison which helped me to know what kind of options I have for working with these devices. I too have been writing code in C++ in the Arduino IDE for my ESP8266s and Arduinos for years doing all sorts of projects, some with web front ends. I'm just now starting to come up to speed in the world of Home Assistant, MQTT, and this way of building applications for integration of many devices not wanting to reinvent the wheel that so many others have worked so hard to build, and nicely.
Great video, as usual. If you’re using Home Assistant, to me it seems like the logical choice is ESPHome - purely because of the integration. I really like the YAML approach. I have around 23 devices in ESPHome, however they’re mostly Shelly 1PMs. Using YAML, I’m able to create templates and then include them into the device config using a YAML directive to avoid having to copy and paste the same thing dozens of times. The individual device scripts define variables to hold the unique device parameters (such as names), and these are used as tokens in the template. I also use variables to control the logic of how the particular device behaves e.g. Does it power on after a power failure, stay off or return to its previous state? Does it automatically switch on after being switched off (useful for stuff you might want to remotely switch off, but want to guarantee it switches back on - imagine using this to switch off your modem remotely to force it to power cycle). I feel it’s all very neat, tidy and modular. The YAML also has some pretty powerful directives and logic. For example, I’m able to detect the device temperature or current draw and act on it (e.g. to shut down when the device overheats or draws too much power). I can even write persistent data to the ROM to put the device in a “fail safe” state so that it won’t reenergise the relay until the overheat condition has been cleared manually. I wouldn’t like to put this kind of automation at a higher level. It really needs to be on the device itself in case Home Assistant is unavailable for some reason during an overheat. I like that I have the YAML that defines the full functionality of the device - that’s all I need. If I lose my device, I buy a new one and reflash it with the firmware derived from the YAML, and it behaves exactly as the device it replaced. The integration with the Home Assistant native API is also excellent. No need for MQTT. Add a sensor, and it just magically shows up in Home Assistant. You can even pass data from Home Assistant back into the device (such as acting on a button being pressed on another device).
@@AndreasSpiess Home Assistant and Node Red work well together. Automations in Home Assistant are quite basic, whereas in NodeRed the sky is the limit. Note that you can run ESPHome in docker, so you don't 'need' to use the ingress version within Home Assistant.
@@c1ph3rpunk basically, split your sensors and switches out into separate files and include them all in the top-level device file: substitutions: # Unique name for the device, also acts as the host name. name: "shellypmbathroomfan" # Friendly name for display in Home Assistant. friendly_name: "Shelly PM Bathroom Fan" # Supports ALWAYS_ON and ALWAYS_OFF, however the latter is somewhat # meaningless if force_switch_back_on is true. This would cause the relay to # switch off during a reboot then switch back on after the # "force_switch_back_on" timer expires. RESTORE_DEFAULT_X are not supported # as this would require flash writes on each relay toggle, whereby reducing # the life of the device. default_mode: ALWAYS_ON # Set to true to force the switch back on after a delay when switched off. # Useful for a remote powercycle that would cause the remote client to lose # connectivity during the power cycle. force_switch_back_on: "false" # Disabling this is sometimes required for devices that consume a high amount # of current for prolonged periods. support_overheat_protection: "true" # Never a good idea to disable this as the device could catch fire or be # fried. support_overcurrent_protection: "true" ### Timer-related settings ### # Enables or disables the automated power-off timer. timer_enabled: "false" # Sets the duration, in seconds, after which the switch to turn off once # it has been turned on. default_timer_duration_seconds: "0" ### End timer-related settings ###
If it weren't for Andreas' videos, I would never have dared to enter the world of ESPs. Now I make my own boards from ESP12F modules, both solar and battery powered. Thank you!
Great side-by-side video. I think you definitely captured the fundamental pros and cons of each. Personally, I think of tasmota as excellent control software (button, switch, relay devices) and ESPHome as very good data collection software (sensor nodes). I still primarily write my own software for many of my devices but have found that if I want to control something or get simple data, I gravitate to one of these two.
As usual the scientific attitude in measuring based on real facts! Nicely done Andreas! I think an intermediate layer between ARdiuno IDE and tools like EspHome and Tasmota is the microPython. Flexible and simple enough at the same time...
I've huge respect for the hours of work that must have gone on in the background, that allows you to display this level of experience! Well done GWTSA :) (Not my best English sentence :) )
The video became a little longer than anticipated. But I was without ghost this week. So it was no problem. I had to look up GWTSA. Google said: Gamma-Weighed Two-Stream Approximation ;-)
@@AndreasSpiess I'm never without my Gamma Weighted Two Stream Approximation but it will not be too long before it switches to 'guy with ....' as a tribute :)
I started using Tasmota after I lost IFTTT support for my lightbulbs and smartplugs. Using Tuya-convert made this possible. I went with Tasmota by default and like it so far, but have not used ESPHome or ESPEasy yet (I was too afraid of bricking my lights/plugs to explore much). As someone who has written code using Arduino/libraries for sensors/automation and then again in micropython, I was hesitant to use a framework, but didn't have a choice on these limited devices. I'll still use my own code for those things that require a more custom approach, but it's nice to let someone else worry about bug fixes for some things! And some things are just not possible with micropython for timing reasons (like IRremote) which I have to say works very well with Tasmota at least. I do as much using micropython as possible. Also use MQTT with HASS in docker. Thanks Andreas for the video and nudge to look at some of the other options!
Thanks for pointing it out :) @Andreas Spiess, I am the maintainer of ESPEasy, so if you run into things, you can always ask. I will now continue watching your videos, to hopefully learn something myself as I usually do from your videos. @TZ500J, the ESP32 is also supported, even with Ethernet if you need it. Just a few more links: github.com/letscontrolit/ESPEasy ReadTheDocs: espeasy.readthedocs.io/en/latest/
And as it turns out, "it depends"... 🤓 I switched from Tasmota to ESPhome a year ago, as I like to have more control over functions and scripts inside the controller. But then, I am quite well versed in programming. For people getting started in home automation, I still recommend Tasmota.
I agree. I love ESPhome because I come from a coding background and its workflow is super convenient to me (aka I'm used to compiling / uploading all from the command line and I can easily parse and edit YAML in various IDEs / editors). It's highly extensible with a bunch of its modules as well and I like that you can talk to Home Assistant directly without running through MQTT. Tasmota is a lot more of a pain for me, but I can see how people less enamored with coding would prefer it.
Thanks for the great comparision. I use the old fashion method for the most of my ESP-based sensors. But I also tested Tasmota for sonoffs. ESPEasy for a simple S0 counter and ESHome for a CO2 sensor, because only here I could switch off the autocalibration of the CO2 sensor and could easily use an ESP32. All are running stable. BTW, the coolest sensor is the MLX90614ESF Far IR sensor. Using this and ambient temp , I calculate the cloudage. Helpful an unusual.
Interestingly you mention the MLX90614. I have one here, but not in the box "IR sensors" because I bought it as a temperature sensor ;-) I definitively have to try this one. Thanks.
@@AndreasSpiess Yes, that is correct, it is a contactless temp sensor using the IR Radiation of an object.. Max Planck's groundbreaking finding and formula shows the realtionship to temp. I insert the sensor in a cable gland, facing it directly to the sky. no glass or anything else. in front of it
Btw: I wrote more on the topic of measureing cloudage in ioBroker Forum and Homematic Forum forum.iobroker.net/topic/32195/himmelstemperatur-bew%C3%B6lkung-scheibenvereisung and homematic-forum.de/forum/viewtopic.php?f=27&t=40624&start=20#p574687
And once again, I go looking and you have the answer. It’s been a year since this was made but here’s a couple things I’ve found in the past few days. I have HA on a Pi 3 and under the current version you can install ESPHome firmware OTA, directly or via a serial connection (if so connected, ttyUSB, etc). It lists 4 ways to install it, can’t remember all 4 off the top of my head. I started with Tasmota on a Sonoff and a NodeMCU and discovered you can use Tasmotizer to flash the ESPHome firmware as well. I run a Pi 4 as my lab “workstation” and found that to be more reliable than every other method I tried. The ESPHome flasher won’t run on armhf/arm64/Linux, Tasmotizer does. My current complaint on ESPHome, which I do seem to prefer, is the lack of syslog support that Tasmota has. I want to centralize logging for debugging and security monitoring (using Splunk) and syslog is almost universally the glue we use to hold that all together. For the deep sleep can you force it to sleep when the work is done using the deep_sleep.enter action?
1. Another viewer wrote that many things changed since I made the video. Sometimes my videos help such changes ;-) 2. If I remember right I managed to get deep sleep working. But I do no more remember, how.
@@AndreasSpiess yea, was hoping my comments might help future content or folks watching the video, 90% of it still applies despite how fast the IoT world moves. Sleep is next up on my list to try on the NodeMCU (8266) and an ESP32 and I’m guessing you’ll have something to help. I really need to support your Patreon, excellent work my friend, excellent work.
Hi Andreas, the TASMOTA deepsleep is optimized for minimum uptime and/or long deepsleep. You have to change the teleperiod to 10 seconds to get the immediate execution of your sensors. In this case, the complete uptime of an ESP8266 is less than 14 seconds as long as the sensors do not need to much time for the LUX calculation. This also works on the ESP32. Regarding your problem to keep the device awake after restart: There are two options. Option one is defining a deepsleep SWITCH. If this is "ON" the device stay awake even if deepsleep defined. The other option is to push "deepsleep 0" as a retain MQTT message. After start, the device will read the message and disable deepsleep. Let me know if you miss more functionality. I have many devices with deepsleep and battery only powered running. works like a charm. The NTP function is to calibrate the deepsleep. As you might have seen a 3600 second deepsleep has a quite big shift. With the function, you can assure that your devices e.g. wake up properly exact at the beginning of the hour. Also very convenient, because predictable if the device runs for months.
Good to know that run-time is optimized. I did not find information on it (did not search for hours). I will try it once (maybe if I get all three sensors in the standard ?) Concerning the MQTT message: I mentioned this possibility very briefly towards the end of the video. The one with the button is ok, but, if I sit across the device, I also can press reset and upload. At least in my case, it worked. Good idea to calibrate the timing with NTP. Maybe not needed for all purposes. And I am glad I read "ESP32". Another commenter mentioned that this CPU will not be strategically supported by the team. And good to know that you are an expert. Last time a guy called "efelle" on discord helped me with rules for my brother's special wishes...
@@AndreasSpiess Regarding the ESP32: TASMOTA was invented for the ESP8266 with all of its limitations. Many drivers and enhancements are already enabled for ESP32 and work well. You cannot commit anymore a change that crashes on ESP32 and everybody adds some nice compiler options to have TASMOTA on ESP32. There is still a lot of work because sometimes the differences are tiny but important. For example, the sleepmode on ESP32 is much more flexible. Currently, the implementation supports the current mode at ESP32 but did not make use of all the nice wakeup-functions the ESP32 offers. Already the ESP32 bin file uses everything that is available. No more selection of functions based on memory.
Both projects are great IMO!; It gets you balls deep into the software engineering process. Learning the rules / automations really makes a device smart.
You never cease to amaze me. Like a heroin addict I am a "knowledge addict". So just like a junkie on the streets of Amsterdam who strolls the streets (That's what they used to do in the 90's. Perhaps Amsterdam has become more genteel these days.) for their next hit, I troll the internet for my drug. Unexpectedly I discover your UA-cam "hit of knowledge" just as a junkie might find a loaded syringe to feed their addiction, your video satisfied my addiction for knowledge just now. This video was very interesting and drove home how difficult it is to keep up with technology. As soon as I begin to believe that I might understand a subject, I come to the realisation how little I really know. Your videos lay the foundation for further research. I often stop your video mid stream because unintentionally you mention one little thing (such as Adafruit's I2C addresses info in this video) and I'm off making "research notes". Keep pushing your "drugs". There's plenty of addicts out there who need them. I'm sure the next "hit" is going to be as good as the last.
Thank you for your nice words. I usually have people like you in mind when I create my videos. I invest some time and you get a quick overview, but not wothout some details.
Thank you for this video. I've chosen for Tasmota already, because I don't use Home Assistant and I wanted a GUI. And for the devices I wanted to setup, the available tutorials and how-to's seemed easier to do in Tasmota. But the biggest plus for me is that Tasmota already is prepared for talking to the Domoticz home automation. ESP-Easy was mentioned in the comments. This project follows the Tasmota route: it has a webgui for adding sensors and you can use rules. There are also different firmwares for sets of devices. And you would give 0.5 points to the deep-sleep-functionality. As far as I know: no ESP32 support. Thank you for pointing out Tasmota-Admin. I will definitely look into that. Unfortunately, none of these are suitable for a remote control: battery-operated and immediate response on a push of a button. There's always the time needed for connecting WiFi. I am currently using ready-made 433MHz stuff for that. An RrxTrx433 directly connected to the Domoticz and 'klik-aan-klik-uit'-devices. Could this be solved with LORA? I'm curious for the response time. I think that you are familiar with my problem: my wife says that the light should turn on immediately when clicking the switch.
HiAndreas. Love your work! I like you and many others use both ESPHome and Tasmota, it depends on the use case. One thing I would point out for ESPHome is that if you are using Wemos D1 Mini, NodeMCU or TTGO ESP32 Cams you can use a standard micro USB to upload your ESPHome config. Just plug the USB into the Home Assistant Host and restart the ESPHome Add-On. Then you will see something like /dev/ttyUSB0 (USB2.0 - Serial) as an option for upload. This helps avoid the need for connecting jumpers to a UART connector. After that it is easy to do OTA updates.
Thank you very much for video, really appreciate it. One important think: how are both integrate with HA, at this point I will give a point to EspHome as it have direct integration with HA. Tasmota is using a middleman, MQTT, to do this job.
Thanks Andreas, very clear and understandable video. Your videos are still the best in the business!. My favorite is Tasmota, this is where I learned all about MQTT. Tasmota documentation is also very high quality. I use my Tasmota devices with Hass.io, I really like that, as well as controlling a Tasmota device with a controller (Hass.io) you can make your device work autonomously with rules, so if the device becomes isolated from the controller, it can still be useful with working with its own rules-based "automatons" . P
Excellent content, thanks for the informative video. Both Tasmota and ESP Home are winners as they help the DIY community have more choices, which help look at the same problem from different perspectives. Maybe in the future we could look at this sensors abstraction from scripting perspective ? Python and Javascript on microcontrollers ?
Maybe these languages will get their space also on micros. Till then we have to select between C++ and libraries or frameworks like the ones shown here.
I've never made the Tasmota firmware work reliably on any of the multiple hardware platforms I have. They hang. However, most of the more recent (a year or more) Arduino ESP8266 WiFi Server examples seem to be very reliable. I've had one that controls a single relay work perfectly for about 6 months straight. Same hardware I tried with Tasmona. But I must say I had two extended power outages (two hours and ten hours), and after power was restored, it came back up without any intervention. Also, I have another ESP8266 WiFi Server that controls 20 GE Low Voltage relays, and it's worked perfectly for about 3 months so far.
EspHome allow direct upload from USB. Espeasy is great that’s true but it is quickly a complex way to do : you have to compile yourself it with some options to have the sensors that you need. The development seems less organized. But I recognize that it is powerful too since a long time.
@@AndreasSpiess There was nothing to set up with the standard raspberry pi 4 image from home-assistant.io and the community version of ESPHome. I just plugged in my ESP32 on usb and got the first image installed.
Same here too, I plugged in devices and it just worked to flash via USB to ESPhome. Occasionally I've seen it where ESPHome didn't refresh the USB list, restarting the server resolves for me if that happens.
Yes I also use the USB method, after you plug the USB in, just restart the esphome plug-in, to register the USB serial port, but thank for the great videos, I really enjoy your videos and find them very informative.
Very well done overview! I've tried Tasmota a little bit, but found it harder to understand, and ESPhome covers my needs so far. But it's good to know how the two differ. Maybe I'll need Tasmota for something in the future. Thanks! Protip: ESPhome (in Docker) can upload over usb, but you need to first connect your ESP device to the computer running ESPhome, and then restart the ESPhome container. Then you should be able to select something like /dev/ttyUSB0 instead of OTA. (On Linux, I don't know about Windows.) And you can run the ESPhome dashboard without HA, if you install ESPhome manually with the "getting started through command line" guide. So it's not as straight forward, but possible.
1. I assume it depends on the docker setup if you can use USB. I used IOTstack 2. As mentioned the video I tried to set it up but, as a Linux noob, I gave up after a while :-(
Hi Andreas, first off, thanks again and again for all the content you are delivering. There's been significant development lately around both Tasmota and ESPHome. I would really love having a follow up video including those feature and your updated ranking. Also I have heard about ESPEasy but did not have time to have a deeper look. Looks like more an easy & straightforward way to integrate ESPxx...but probably not for the advanced users....
Because I changed to Home Assistant, I usually use ESPhome. It is good enough for most cases. I think, the differences between the two platforms became very small. HA users will use ESPhome because it is so easy to setup. And the rest uses Tasmota (because it is so easy to setup) ;-) But the next video will be about another specialized platform: OpenMQTTGateway. You will see, why.
One important bonus of ESPhome is its direct integration in HA. You don't even need to pass data via MQTT. After, it's also possible to use any sensor with ESPhome as soon as there is an existing arduino lib. You need to build "custom sensor" with ESPhome.
@@AndreasSpiess To add a little to the confusion about the PyPA recommended tool for installing Python packages: On Windoze: Python versions from 3.3 come with a launcher. You can do: py -3 -m pip # Run latest Python 3 found on the system with its pip. py -2 -m pip # Use latest Python 2 instead. On Linux: Your pip may be a soft-link to pip2. Check it with $ ls -l `which pip` $ ls -l `which pip2` $ ls -l `which pip3` use $ pip show pip $ pip3 show pip to get more details On a python2-free system, pip may become the same (via link or copy) as pip3. But this can also break some packages. BTW using sudo pip on distros that provide native Python packages (apt-get install python-numpy, etc.) is calling for trouble. Keep that in mind.
I'm learning something new every time I watch Andreas!!! Andreas, you put smile in my heart and brain and I learn and learn more and more! Thank you for your hard work. (PS: I was under the Corona with my wife, so it took little time out of learning - that was the hardest part! Now we are like new again!)
@@AndreasSpiess At 65 I'm in the zone where it could go either way, but despite many other health problems it was "doable" and I didn't need any special medicine. If they would give me the same stuff as to the President Trump, I think I would take it. But it was like a cold and ZINC and lots of water and little food with apples and oranges helped also. Thank you very much Andreas!!!
@@AndreasSpiess You are right, but once your age is over 65, it takes a long time to regain just most of your previous energy and brain! I'm glad not much damage so far, but it keeps testing you weeks and weeks after your main symptoms and temperature are gone.
I like to think we're of the same age and we probably have similar backgrounds in education and profession. I'm sure we share the same interests and hobbies. You always impress me by being so productive and skilled in the field. Today again! Thank you for sharing!
@@AndreasSpiess Here is why I said ".. I LIKE to think..." 1. I am older (67) 2. I do not hold a PhD 3. Long ago I was a trained EE, but then I became a manager of large high tech development groups. I now try to do small scale what I always talked about :) I am - like you - interested in computers and electronics (digital and analog). RF is still a lot of "magic" to me.... :) Again THANK YOU for your channel! PS On being a Linux noob we can shake hands..... after Covid19 by the way. :)
I'm running both for different things. If you're using Home Assistant you can't really beat ESPHome. It's very well integrated, has great support and works well for most things. The deep sleep/battery support is crappy though, when trying to use that with the ESPHome protocol (as opposed to MQTT) it spams your ESPHome logs because it can't reach the device most of the time. As for Tasmota, it's actually far more powerful than you might think at first glance. In addition to the web interface you can send many advanced commands through the console. I'm using it for a door opener relais for example, with Tasmota it's trivially easy to trigger the relay for 2 seconds and kill it after. And since it's using plain HTTP it's easy to get some other device to trigger it for you.
I’m a big fan of the fact that ESPHome uses the native API. It eliminates the need for the MQTT server and then defining sensors. They just automagically show up in HA when you add the integration for that device. esphome-configs.io/ has some definitions similar to blackadder but still very early days
IoT devices with built-in ESP8266, like Sonoff, Gosund, Blitzwolf, ... --> ESPurna or Tasmota But you have to keep in mind all the MQTT traffic is unencrypted. Because of performance and memory, no TLS secured communication to MQTT server with ESP8266 chips by default. But as always a good content here.
Greart and informative video, as usual!! At 9:42, you describe, that only OTA is available. I found on my RPI4 that when I connect the ESP to the USB connector of the RPI and then restart the ESPHome service in Home Assistant, the board will show up in ESPHome and I can Choose betwenn OTA and USB update. With this method, I can program virgin Boards directly from Home Assistant
Thanks for the video. Previously I have used balena os for pi(grafana, mqtt, db and custom application for data processing etc) and mongoose os for esp, found it pretty easy to use. Now want to try ESPhome.
Edit: Name corrected - sorry. I'd like to see you compare espruino and mongoose OS. Both use JavaScript interpreters with on board hardware management dashboards and web based IDEs. Please Andreas, please compare those two was I'm really struggling to decide between them. There's nowhere that compares the two. You'd be helping a lot of people out.
@@AndreasSpiess I got my first answer from Andreas!!! I'm so happy this has made mt day!!! Seriously I think if you google a comparison of the two there's very little out there and it would at the very least give your channel a boost due to the lack of competition on the comparison of the two subject. :)
Just today, a new version of Tasmota for the ESP32 (8.5.0.1) was released. Upload via esptool.py and it runs smoothly. If Tasmotizer gets the update to support the ESP32 as well as the ESP8266, it will be much easier to flash Tasmota32. One feature, i'm missing in tasmota32 is the support of the touch-pins - might come soon enough.
Great video. All your videos are great. I did want to add to this one though: you gave a point to Tasmota in the section that discussed the OTA as the only option for ESPHome on initial flash and as a work around had to download the binary and use the flasher. Actually that is how I do it too but only because the computer running ESPHome is upstairs for me. If on the same computer running Docker, simply map the usb port to the docker container (or run in privileged mode). Then the USB device will be in the dropdown as well. Believe you also said that Tasmota has a nice one place to see all Tasmota devices but ESPhome does not, yet you show the page where the OTA drop down is which shows all the devices. It is for this reason I use a custom panel to being ESPHome in home assistant so I can see all esp devices in one place. So, anyway, just those 2 minor things I wanted to comment on. Going either route (Tastmota vs ESPhome) is 50/50 in most cases and probably will remain that way. I like ESPHome, especially being able to use any arduino library to make a custom component or even write my own.
You are right with Docker. I used IOTstack and it is not implemented there. Maybe they will change it in the future. It was not a big deal for me. Concerning TasmotaAdmin: I said that it shows much more information.
That's a very good summary. I also like your comparison between efficiency and flexibility, I think many people don't really realize this. For me personally, when I can, I like to use ready-made software like tasmota. But many times such software or even some libraries don't offer exactly the functionality that I want. So I end up having to write my own program. I have even written some assembly programs. But very rarely, since apart from memory and speed efficiency, assembly doesn't have many advantages compared to C. You can do almost anything you can do with assembly also with C. But assembly takes so much longer to write that for complex projects it's really not worth the time. At least not for me.
@@AndreasSpiess Yeah, I can understand that. I mean, I think assembly is actually kinda cool. Usually there aren't that many of instructions, so it's fairly easy to learn. And I like that assembly translates direction into machine code, without the need of any compiler. But on the other hand, having to learn different instruction sets for different processors is rather annoying. So yeah, in general I definitely prefer C/C++. Or even python, but not really on microcontrollers, since they usually have fairly limited resources and I consider python is just too high level to really be efficient (in my opinion). Anyway, I'm also certainly glad we have more sophisticated languages than assembly (or just writing pure machine code, as the used to do before assembly).
It is not about the instruction set. Here you are right. It is about the complexity because you have no variables, only memory locations. And with the 8-bit CPUs we only had numbers up to 256. Above that you had to do all the calculations by yourself. Maybe you look at how a simple division has to be programmed in assembler ;-) And the readability of this "spaghetti code" was also horrible. Anyway, sometimes it has to be used up to today if you have special needs where you can not use a higher language.
@@AndreasSpiess Yes I know... And if you have numbers higher than 255 you need to use two registers, which is kinda also a mess. But I guess it's still better than working with a 4 bit processors. Conditional code is also kinda annoying, cause there is no if or else, so you basically have to figure out how to get it working, by skipping instructions or jumping to a different address based on some condition. But I mean, that's the normal trade off, the way it works is simple, but it's complicated to work with. But you know, there are things about assembler I like. For example that you know exactly how much time each instruction takes to process (or can take to process). C/C++ is clearly superior when it comes to programming. But since you basically give some of the programming work to the computer (compiling the code) you lose the insight into exactly what the processor is doing at any given time. Obviously I'm not saying Assembler is better. It is quite elegant in certain ways. But assembler quickly gets to the point where the processor speed is not the bottleneck, but instead the speed of the human programmer. And at that point of course it makes sense to sacrifice some efficiency for quicker and easier programming.
Configuring deep-sleep on esphome, you could instead of the timeout, create an automation on the device (although i have not tested this): sensor: - platform: dallas on_value: then: - deep_sleep.enter: deep_sleep_1
FWIW, if you connect a USB-serial to your Home Assistant machine, ESPHome will discover it and let you flash firmware. This works even with a dockerized install of HA running on a virtual machine hosted on my home NAS. (The only funky step there was remembering to assign the USB port on the NAS to the virtual machine). The port can be found as an alternate selection to OTA in the selection list. As far as startup time for the deep sleep problem, if you assign the address yourself (or make a DHCP reservation for the node once one has been assigned, and configure it as static in the node configuration), startup time is much better. And if the OTA update is problematic with sleeping systems, they can always be taken back to the development environment and programmed with the USB connection.
You are right with the definition inside Docker. Maybe they add it in hte IOTstack prokect. Concerning fixed IP address: This trick works for all ESP sketches, not only the frameworks. For some nodes I am really happy they have OTA because it is a pain in the a... to remove them where they are ;-)
Hi Andreas, one small point, for most ARM MCUs, there's no real advantage between C/C++ and assembler. This made me sit up and think and I've noticed that modern compilers can make very efficient code without having to use (very hard) C shortcuts. It makes for much more portable and readable code without sacrificing speed!
@@AndreasSpiess LUA too for the ESP boards but I do like my C for crushing quarts into tiny spaces while annoying older C programmers by writing verbose code that compiles to almost nothing while remaining readable!
I guess I'm not complete beginner but I would disagree to the "both have steep learning curve". I was shocked at the simplicity of ESPHome when I started using it. To get started all I had to do was install ESPHome, create the config, define the pins and flash it. It felt really intuitive and somewhat like a magic. And their documentation is excellent. Later on I also realized that you can use custom components for things that are not supported out of the box. And you can use existing Arduino libraries for that job. Check out their "Custom Sensor Component" guide in documentation. Oh, and I use Home Assistant, so auto discovery and fully automatic integration for ESPHome devices helps as well.
Greetings Andreas, There's a lot of hardware and software solutions for the maker to tinker with these days. I thank you for creating these in depth reviews and tutorials on what there is and how to go about it. i currently have a bme280 connected to an ESP32 which is sat outside on my windowsill upstairs. It is nice being able to see the weather outside from my browser on my pc or my smartphone. I must get act together and arrange for it to talk to Profilab, as that does data capture well and can do the controlling of actuators if need be. We had snow in the western Cape on Friday and it's interesting to see that the air pressure drops by 10 hectopascals in Johannesburg at the same time, that's 1400 km away. It takes 2 days for the cold air to reach us here afterwards. Very interesting. I also had fun doing data capture by loading a 0.5 Watt pv array with a resistor, connecting it to an esp32 analogue input and graphing the solar radiation using Profilab. Very interesting how the solar intensity varies with changing weather conditions. Anyhow, taking up your valuable time by making you read a long text. Thanks for the video, it's approved. Kind regards, Duncan
You are welcome! We also had snow this weekend in higher altitudes and it became quite cold where I am. The idea of my light sensor is exactly to see the correlations between the different components of sunlight throughout the year and find out, which one is best to steer my awning, for example.
Many things changed with Tasmota 9.4 I have successfully flashed ESP32 with the latest tasmota and I see that it has support for mqtt, knx and many sensors. Already tested with RF and IR, works perfect, using mqtt and knx to control them
Thanks for an interesting video, Andreas. I can only really comment for Tasmota. It find it fine for simple easy jobs, and I like that they have added syslogd telemetry (syslog to UDP port 514), which is lighter weight than MQTT for interval based telemetry. But when it comes to automation on the sensor itself (not centralized via say Node-Red), I feel I want a little more flexibility. The Rules of Tasmota are a pain to edit, and they are sometimes a little cryptic. For example, if you want rules to only trigger once on change, you have to enter this command Rule 5. Doh? It's cool in ESPHome that you effectively write the C++ and upload, but that's still a pain to debug. What I actually want is an easy to use interpreter with web-based debugging/breakpoints so that I can mess with it in its installed location until I'm happy. Almost like MicroPython, but that is way too sparse to really use. The closest I have found is this Annex RDS platform (sites.google.com/site/annexwifi/home) - it's BASIC (yes really, welcome to the 1980's :-), but with a file manager, breakpoint and single-step debugging, and really cool webserver integration if you know a little about web programming. I am not involved in that project, so this is not an advertisement :-) I just find it a quite useful alternative.
Thanks for sharing your experience. You describe exactly what I wanted to say about the layering. You get different things on different levels. It is always a trade-off between "speed of deployment" and "flexibility".
With ESPHome it is possible to add additional libraries and code in the yaml. This makes it a mix between an custom sketch and finished framework which makes it possible to support new sensors. This also allows for more advanced automations. But in my opinion, with several devices ESPHome quickly becomes a bruden to maintain and keep them all updated.
@@AndreasSpiess ohh, sorry, guess I zoned out for a second. Anyway, a few months ago I switched my setup from Tasmota to ESPHome due to the more advanced automation possibilities. Very flexible, but a pain to maintain. Thanks for the video 😀
I've been using Tasmota since the project started. I thought it was weird, you posting a video about Tasmota, since I built a custom ESP32 Tasmota (beta) firmware last Monday for an unsupported device. The .bin uses about a third of the available space on a WROOM-32U module. The project has been in use since last Monday evening and does what it needs to do. I only see Tasmota as the easiest way to get a web interface, MQTT, and OTA onto an Espressif project in a short time frame (usually an hour or so). I don't see its shortcomings as shortcomings, but as features *I* didn't implement yet. Using Git effectively is key to keeping my code and ever-changing Arendst's code in sync. I looked at ESPHome & decided that it's more difficult to use as a standalone device. I'll look at it again in a year. I don't like Home Assistant, its interface, its runtime architecture, or its functionality. I installed it for three days, realized HA is trying to be all things to all people, does none of those things well, and will always be one bad update away from everything in my house breaking and an angry spouse giving me That Look. Again. She's tiny, but scary.
I decided to not compile Tasmota because I assume most people will not do it. I also did not implement custom sensors in ESPhome, because I tried for one hour and was not successful. The charm of framework is that they are easy to use and Tasmota would not be so successful without Tasmotizer and the bin files. Look at Espurna which was probably earlier than Tasmota...
Thanks for the great video. I have not heard of tasmoadmin before. I use tasmota most often (also because of tuya-convert of several Gosund SP111 power monitor plugs). Also ESPeasy for an S0 counter.
Programming via USB is enabled on HASS/ESPHome addon when a supported device is detected, ie serial port. The device will show an item in that drop down that always says `OTA Over the air`. To see this plug a device into the hardware that runs HASS and check the drop down list.
Thanks for the advice. I have to try the trick with CH1. BTW: I programmed the redit talkgroup on my DMR radio and already talked with a US guy. So it seems to work also for DX ;-)
Good comparison. But to be honest, I can not understand why you did not include ESPEasy in the comparison. ESPEasy is by far the most common and sophisticated project for ESPs. Since I tried ESPEasy, I barely write my own code as so much is covered by ESPEasy.
@@carlosrodrigues6863 Just FYI, in ESPEasy there are lots and lots of ways to get data in or out or control using commands. MQTT is only one of them and it is very easy to exclude the MQTT controllers and MQTT import plugin, so you don't have the "MQTT crap". But I'm open for suggestions, so maybe you can give an example of where things can be improved?
Great video You missed the point where if your home assistant goes down you still can control esphome devices through AP But you cant control MQTT devices
I use tasmota and esphome for many cots devices but I use mysensors for all my home built sensors. It has an important benefit in that it uses its own wireless mesh so only a single IP address and you don’t load your wifi with more sensors!
I use node red for my home automation, I tried home assistant but I think you have a lot more control using node red. For instance my LoRa sensors all require some level of processing and I find this easy to do in node red and to display that information is simple. Same with the RF bridge and send and receiving raw codes. Im not sure if you can go down this far down the layers on the home assistant. The main draw back is remote access but thats no issue since I run ipsec server on my router and just dial in from my phone. Notifications are by email or text . I dont have to rely on an external systems this way
It is well possible you could get everything done by HA using tricks. But as a casual user I forget a lot of these tricks. This is why I stick with Node-red for the moment. A little bit of JS is "unforgettable" for me...
I flasged 3 Sonoff Basic with Apple Homekit and I’m using them right from the iPhone. Also I built a neopixel strip connected to a ESP node and flashed with Apple Homekit too.
Isn't there a ESPhome admin page add-on in HASS? I've downloaded it recently but not used it yet, using Tasmota mostly and not extensively. Also a superb video, a Belgian beer goes your way sir! A typical Swiss decision at the end 🤣
You can display esphome in hassio menu. Base status check is innode panel - red means not working, green ok. To check another things you can use special sensors (uptime, restart node, wifi status etc.). ESHome talks to HA via API - it is better and faster then mqtt (also more reliable). Tasmota is cross platform solution. ESPHome is designed to work with HA - with all its benefits. If you using HA ESPHome is only one good choice :)
I used the Home Assistant add-on. But mine did not show a lot of info. It mainly was used for the deployment of the firmware. And I based everything on MQTT because this is an open standard and many of my subscribers do not use Home Assistant.
Oh... And on the command line, ESPHome gives you (or me) the option to flash connected devices via USB (yes even on my containerised raspberry installation).
@@AndreasSpiess thanks, this answers a question i had on the homeassistant discord server: Is there a problem when i use ioStack, looks like the answer is "No, but you have to setup something manually."
@@AndreasSpiess They need this in the configuration github.com/slimcdk/home-server/blob/9d5e598c8da8666fc6e5c01a6fbc129b3d2fa71a/docker-compose.yaml#L147 Or even just - /dev:/dev
For me, ESPHome runs on my windows machine rather than on my server. I make a yaml file, write my code in it with Notepad++ and connect the esp module via usb to my PC. I mainly buy wemos d1 mini clones, since they have usb for programming onboard and are also available on amazon, since i dont like waiting for my packages from china. After the initial flash with basic config (wifi, home assistant, etc), i disconnect it and than build my pcb for the boards (soldering LED driver circuits for normal LED´s onto a prototype pcb, adding headers for external sensors via i²c, screw terminals for external components and so on), prepare a case for it (most of the time boxes for electrical wiring for houses, thats easy to do, fairly cheap and commonly available in every home improvement store), building the complete node together, powering it on, and than starting to add its configs one after one in the yaml with test flashes in between via ota. For this to work, you only need to install python3 and pip3, and then install esphome via "pip3 install esphome". Im using my windows machine for compiling since its a lot faster at compiling (i5 8400, 32gb memory in my win machine vs core 2 duo and 3 gb ram on my server for Home Assistant from late 2006) and i think i dont need a newer server for running HA, a few addons and samba since my dad found that pc in the attic and it works well for my use case. And its easier to maintain or add more drives to for me than a raspi. I had a raspi3b+ running with sd card as HA server, switched to a hard drive as boot drive and got problems (i live on a tight budget, so i cant easily buy a new ssd, that why im using what i find in my "devices meant for repuposing"-drawers) with stability and switched to a normal x86_64 cpu, where i can easily install a new drive, install any distro i like and have freedom which package im installing, without beeing limited to use compatible packages ( i had a use case for an old ndas drive, where i had to compile its drivers to use with the raspi, and i gave up its build process).
I heard of some other viewers who also use windows machines instead of Raspberries. It seems to work ok. Here I have no Window PC for 27/7. So I use a Pi.
@@AndreasSpiess Its almost the same on the pi. Install python3 and pip3 via apt-get, pip install esphome, write your code in a yaml, cd on the console to its folder, type "esphome [filename] run" for uploading, it will upload the compiled firmware and give a log output. And through this you can decide to flash via usb or ota (for the initial flash ota obviously wont work).
This is your first video where there's something that I disagree... At 11.26: 'it is still summer with lots of sunlight'.... You should have a look over here (Belgium)... and also in the alps, I noticed lots of fresh snow. I can only imagine that your on some exotic place other than Switserland when you recorded this. Btw, excellent video. Right to the point.
You are right if I have a look outside now. Cold and rainy. Completely different as when I started the filming. You see how long it takes to create such a long one ;-)
Good video, I use Tasmota with iobroker over MQTT this work pretty well. In Tasmota firmware i use normal sleep - for deep sleep i need to google more, to find the best practice. FOR power a normal 10 watt solar panel and a small akkupack.
Nice video. However, if you're a developer like me you probably prefer ESPHome. The amount of supported devices is not that bad. Big Plus: You can drive sensor and actuators the same time. And you can define own, new devices as well or even 'inject' own C++ code. BTW: There are even more frameworks like ESPEasy or MySensors.
You can also run ESPHome from the command line without docker. You only need python and in that case you have easy access to the USB port. The ESPHome web interface can also be run from the command line with the `dashboard` command and is the same interface as the HA integration. I run ESPHome in Home Assistant, but just last night I also installed it on my Macbook with python so I can easily flash a new device by plugging it in to the USB port. I had a 4 channel Sonoff flashed and working in no time. You can also do this on the Raspberry PI and Home Assistant by adding the USB device to the docker command, however I find it easier to just connect it to my Macbook. Also if there is not a configuration available for a particular device I find it quite easy with the documentation how to add switches, buttons and lights for instance. For automation I still prefer to use Node-Red. I have written my own firmware for my ESP-CAM security camera's, however ESPHome is my default framework to go to if I don't need anything specialised, because I can get it up and running so easily and quickly. I takes a lot of the hard work out of building a firmware by hand. (and I have 30 years programming experience). For deep sleep you can use the deep_sleep.enter Action to go to deep sleep when you have sent your sensor data.
Awesome video, pretty much the same conclusions I've come to:
1. Tasmota is easy and works really well for pre-defined products
2. ESPHome can allow non-programmers to get a "good enough" configuration for their home built projects, but if you already know how to write code in Arduino you are probably still better off writing your own custom firmware.
For the OTA tasmota deep sleep on the roof problem: Send an MQTT message with retain, that way when Tasmota wakes up the next time it will grab that message and prevent deep sleep. After you make your update just send a blank retained message to that MQTT topic to clear it out.
I saw the trick with the MQTT message and I thought I mentioned it in the video. The only problem is that I have to wait until it wakes up the next time. This is no problem if it is every 10 minutes... I assume not many people use these frameworks with deep-sleep. Otherwise, maybe somebody would have included this function into the administration: MQTT message sleep off, OTA, MQTT message sleep on...
But anyway, I do not update my running devices that often.
@@AndreasSpiess The only way to shorten the deepsleep is an external reset switch that you can reach. Maybe coupled with the deepsleep switch I mentioned above. To have no access to the device during the deepsleep is the nature of this feature. You can use rules to check is there is a new OTA update and go for this. But this will increase the uptime again and does not make sense in my mind.
@@AndreasSpiess, true, you can *deep-sleep.prevent* *on_message* and it's generally always good thing to *fast_connect: true*, unless you have really complex Wi-Fi roaming.
I like the way you covered these two very thoroughly. Thanks for this video!
Glad you liked it!
Me too.
I tried both. ESPHome is much more powerfull. You can do data treatment on the device itself before sending it to Home Assistant and avoid ugly data entering Home Assistant.
Also an interesting aspect. Thanks for mentioning
Yeah, it's actually very useful for noisy and unreliable sensors!
Thank you Andreas! Again a great video!
In the current version of ESPHome (2024.6.6) there are now four different methods availabel to flash the device.
1. via Network
2. plug USB in your PC
3. plug USB in your HomeAssistant-Server eg. Rasperry Pi
4. manual download (as you referred in the video at 10:10)
You are right. Things became easier.
I wanted to take a moment to thank you for making this video. I'm running HA in a virtualbox VM at the moment while I await my pi to arrive. You provided some key information that I could not find in other videos regarding getting the first binary into my NodeMCU so that I can continue with OTA uploads. All the other videos had demos of ESPHome Add-on having ESPHome-Flash built in, which mine doesn't. You pointed me in the right direction with the download binary, and I found ESPHome-Flash executable for windows on the web and downloaded it.. All went well after that.. This NOOB thanks you very much for that, as well as the comparison which helped me to know what kind of options I have for working with these devices. I too have been writing code in C++ in the Arduino IDE for my ESP8266s and Arduinos for years doing all sorts of projects, some with web front ends. I'm just now starting to come up to speed in the world of Home Assistant, MQTT, and this way of building applications for integration of many devices not wanting to reinvent the wheel that so many others have worked so hard to build, and nicely.
Thank you. You find also other videos about this topic on the channel...
Great video, as usual.
If you’re using Home Assistant, to me it seems like the logical choice is ESPHome - purely because of the integration.
I really like the YAML approach. I have around 23 devices in ESPHome, however they’re mostly Shelly 1PMs. Using YAML, I’m able to create templates and then include them into the device config using a YAML directive to avoid having to copy and paste the same thing dozens of times. The individual device scripts define variables to hold the unique device parameters (such as names), and these are used as tokens in the template. I also use variables to control the logic of how the particular device behaves e.g. Does it power on after a power failure, stay off or return to its previous state? Does it automatically switch on after being switched off (useful for stuff you might want to remotely switch off, but want to guarantee it switches back on - imagine using this to switch off your modem remotely to force it to power cycle). I feel it’s all very neat, tidy and modular.
The YAML also has some pretty powerful directives and logic. For example, I’m able to detect the device temperature or current draw and act on it (e.g. to shut down when the device overheats or draws too much power). I can even write persistent data to the ROM to put the device in a “fail safe” state so that it won’t reenergise the relay until the overheat condition has been cleared manually. I wouldn’t like to put this kind of automation at a higher level. It really needs to be on the device itself in case Home Assistant is unavailable for some reason during an overheat.
I like that I have the YAML that defines the full functionality of the device - that’s all I need. If I lose my device, I buy a new one and reflash it with the firmware derived from the YAML, and it behaves exactly as the device it replaced.
The integration with the Home Assistant native API is also excellent. No need for MQTT. Add a sensor, and it just magically shows up in Home Assistant. You can even pass data from Home Assistant back into the device (such as acting on a button being pressed on another device).
Thanks for sharing your experience. A lot of interesting use cases to consider. I first have to get into HA. Currently I am on node-red...
@@AndreasSpiess Home Assistant and Node Red work well together. Automations in Home Assistant are quite basic, whereas in NodeRed the sky is the limit. Note that you can run ESPHome in docker, so you don't 'need' to use the ingress version within Home Assistant.
I’m interested in this templating approach in the YAML, can you share some example code or pointers to show how it’s implemented?
@@c1ph3rpunk basically, split your sensors and switches out into separate files and include them all in the top-level device file:
substitutions:
# Unique name for the device, also acts as the host name.
name: "shellypmbathroomfan"
# Friendly name for display in Home Assistant.
friendly_name: "Shelly PM Bathroom Fan"
# Supports ALWAYS_ON and ALWAYS_OFF, however the latter is somewhat
# meaningless if force_switch_back_on is true. This would cause the relay to
# switch off during a reboot then switch back on after the
# "force_switch_back_on" timer expires. RESTORE_DEFAULT_X are not supported
# as this would require flash writes on each relay toggle, whereby reducing
# the life of the device.
default_mode: ALWAYS_ON
# Set to true to force the switch back on after a delay when switched off.
# Useful for a remote powercycle that would cause the remote client to lose
# connectivity during the power cycle.
force_switch_back_on: "false"
# Disabling this is sometimes required for devices that consume a high amount
# of current for prolonged periods.
support_overheat_protection: "true"
# Never a good idea to disable this as the device could catch fire or be
# fried.
support_overcurrent_protection: "true"
### Timer-related settings ###
# Enables or disables the automated power-off timer.
timer_enabled: "false"
# Sets the duration, in seconds, after which the switch to turn off once
# it has been turned on.
default_timer_duration_seconds: "0"
### End timer-related settings ###
You are drawing me in to creating my own sensors and actuators for my home. The structured way you explain things is very helpful. Many thanks!
You are welcome!
One can do a request to the tasmota developers to add a sensor it is frequently updated, that's really good!
Good to know...
If it weren't for Andreas' videos, I would never have dared to enter the world of ESPs. Now I make my own boards from ESP12F modules, both solar and battery powered. Thank you!
Great! I am glad I had a positive impact.
Nice to see that the weekly publishing is back ... thanks for the video
You are welcome! The holiday are over ;-)
Great side-by-side video. I think you definitely captured the fundamental pros and cons of each.
Personally, I think of tasmota as excellent control software (button, switch, relay devices) and ESPHome as very good data collection software (sensor nodes). I still primarily write my own software for many of my devices but have found that if I want to control something or get simple data, I gravitate to one of these two.
So I think we are in line...
As usual the scientific attitude in measuring based on real facts! Nicely done Andreas! I think an intermediate layer between ARdiuno IDE and tools like EspHome and Tasmota is the microPython. Flexible and simple enough at the same time...
That was my idea when I made the video about it. But read once the comments :-(
I've huge respect for the hours of work that must have gone on in the background, that allows you to display this level of experience! Well done GWTSA :) (Not my best English sentence :) )
The video became a little longer than anticipated. But I was without ghost this week. So it was no problem. I had to look up GWTSA. Google said:
Gamma-Weighed Two-Stream Approximation ;-)
@@AndreasSpiess I'm never without my Gamma Weighted Two Stream Approximation but it will not be too long before it switches to 'guy with ....' as a tribute :)
I started using Tasmota after I lost IFTTT support for my lightbulbs and smartplugs. Using Tuya-convert made this possible. I went with Tasmota by default and like it so far, but have not used ESPHome or ESPEasy yet (I was too afraid of bricking my lights/plugs to explore much). As someone who has written code using Arduino/libraries for sensors/automation and then again in micropython, I was hesitant to use a framework, but didn't have a choice on these limited devices. I'll still use my own code for those things that require a more custom approach, but it's nice to let someone else worry about bug fixes for some things! And some things are just not possible with micropython for timing reasons (like IRremote) which I have to say works very well with Tasmota at least. I do as much using micropython as possible. Also use MQTT with HASS in docker. Thanks Andreas for the video and nudge to look at some of the other options!
Thank you for sharing your experience. IFTTT seems to go "pro" and "paid" anyway...
As usual nice video :-)
There is another good project especially for esp8266, called ESPeasy. There are a lot of sensors, displays etc. supported
Thanks for the hint. I will have a look at it.
Yes that is the one I have used - here is more info www.letscontrolit.com/forum/viewforum.php?f=1
or here ;-) www.letscontrolit.com/wiki/index.php?title=ESPEasy
@@LarryKapp1 Thnxs Larry ! It looks interesting !
Thanks for pointing it out :)
@Andreas Spiess, I am the maintainer of ESPEasy, so if you run into things, you can always ask. I will now continue watching your videos, to hopefully learn something myself as I usually do from your videos.
@TZ500J, the ESP32 is also supported, even with Ethernet if you need it.
Just a few more links: github.com/letscontrolit/ESPEasy
ReadTheDocs: espeasy.readthedocs.io/en/latest/
And as it turns out, "it depends"... 🤓
I switched from Tasmota to ESPhome a year ago, as I like to have more control over functions and scripts inside the controller. But then, I am quite well versed in programming.
For people getting started in home automation, I still recommend Tasmota.
So we are "on the same page"... My Tasmota works fine on my Sonoff Dual for the lab.
I agree. I love ESPhome because I come from a coding background and its workflow is super convenient to me (aka I'm used to compiling / uploading all from the command line and I can easily parse and edit YAML in various IDEs / editors). It's highly extensible with a bunch of its modules as well and I like that you can talk to Home Assistant directly without running through MQTT.
Tasmota is a lot more of a pain for me, but I can see how people less enamored with coding would prefer it.
Thanks for the great comparision. I use the old fashion method for the most of my ESP-based sensors. But I also tested Tasmota for sonoffs. ESPEasy for a simple S0 counter and ESHome for a CO2 sensor, because only here I could switch off the autocalibration of the CO2 sensor and could easily use an ESP32. All are running stable.
BTW, the coolest sensor is the MLX90614ESF Far IR sensor. Using this and ambient temp , I calculate the cloudage. Helpful an unusual.
Interestingly you mention the MLX90614. I have one here, but not in the box "IR sensors" because I bought it as a temperature sensor ;-) I definitively have to try this one. Thanks.
@@AndreasSpiess Yes, that is correct, it is a contactless temp sensor using the IR Radiation of an object.. Max Planck's groundbreaking finding and formula shows the realtionship to temp. I insert the sensor in a cable gland, facing it directly to the sky. no glass or anything else. in front of it
Btw: I wrote more on the topic of measureing cloudage in ioBroker Forum and Homematic Forum forum.iobroker.net/topic/32195/himmelstemperatur-bew%C3%B6lkung-scheibenvereisung and homematic-forum.de/forum/viewtopic.php?f=27&t=40624&start=20#p574687
Hi Andreas, thanks for all these videos. I've learned a lot from you. You're a good teacher. 👍👍👍🦾
Thank you for the compliment!
And once again, I go looking and you have the answer.
It’s been a year since this was made but here’s a couple things I’ve found in the past few days. I have HA on a Pi 3 and under the current version you can install ESPHome firmware OTA, directly or via a serial connection (if so connected, ttyUSB, etc). It lists 4 ways to install it, can’t remember all 4 off the top of my head.
I started with Tasmota on a Sonoff and a NodeMCU and discovered you can use Tasmotizer to flash the ESPHome firmware as well. I run a Pi 4 as my lab “workstation” and found that to be more reliable than every other method I tried. The ESPHome flasher won’t run on armhf/arm64/Linux, Tasmotizer does.
My current complaint on ESPHome, which I do seem to prefer, is the lack of syslog support that Tasmota has. I want to centralize logging for debugging and security monitoring (using Splunk) and syslog is almost universally the glue we use to hold that all together.
For the deep sleep can you force it to sleep when the work is done using the deep_sleep.enter action?
1. Another viewer wrote that many things changed since I made the video. Sometimes my videos help such changes ;-)
2. If I remember right I managed to get deep sleep working. But I do no more remember, how.
@@AndreasSpiess yea, was hoping my comments might help future content or folks watching the video, 90% of it still applies despite how fast the IoT world moves.
Sleep is next up on my list to try on the NodeMCU (8266) and an ESP32 and I’m guessing you’ll have something to help.
I really need to support your Patreon, excellent work my friend, excellent work.
Very nice, as always, and precisely relevant to my current project. Thanks again.
Glad to read that it helped. I had this since quite some time on my list. It is always good if you know such things before you start to program...
Hi Andreas, the TASMOTA deepsleep is optimized for minimum uptime and/or long deepsleep. You have to change the teleperiod to 10 seconds to get the immediate execution of your sensors. In this case, the complete uptime of an ESP8266 is less than 14 seconds as long as the sensors do not need to much time for the LUX calculation. This also works on the ESP32. Regarding your problem to keep the device awake after restart: There are two options. Option one is defining a deepsleep SWITCH. If this is "ON" the device stay awake even if deepsleep defined. The other option is to push "deepsleep 0" as a retain MQTT message. After start, the device will read the message and disable deepsleep. Let me know if you miss more functionality. I have many devices with deepsleep and battery only powered running. works like a charm. The NTP function is to calibrate the deepsleep. As you might have seen a 3600 second deepsleep has a quite big shift. With the function, you can assure that your devices e.g. wake up properly exact at the beginning of the hour. Also very convenient, because predictable if the device runs for months.
Good to know that run-time is optimized. I did not find information on it (did not search for hours). I will try it once (maybe if I get all three sensors in the standard ?)
Concerning the MQTT message: I mentioned this possibility very briefly towards the end of the video. The one with the button is ok, but, if I sit across the device, I also can press reset and upload. At least in my case, it worked. Good idea to calibrate the timing with NTP. Maybe not needed for all purposes.
And I am glad I read "ESP32". Another commenter mentioned that this CPU will not be strategically supported by the team.
And good to know that you are an expert. Last time a guy called "efelle" on discord helped me with rules for my brother's special wishes...
@@AndreasSpiess Regarding the ESP32: TASMOTA was invented for the ESP8266 with all of its limitations. Many drivers and enhancements are already enabled for ESP32 and work well. You cannot commit anymore a change that crashes on ESP32 and everybody adds some nice compiler options to have TASMOTA on ESP32. There is still a lot of work because sometimes the differences are tiny but important. For example, the sleepmode on ESP32 is much more flexible. Currently, the implementation supports the current mode at ESP32 but did not make use of all the nice wakeup-functions the ESP32 offers. Already the ESP32 bin file uses everything that is available. No more selection of functions based on memory.
Both projects are great IMO!; It gets you balls deep into the software engineering process. Learning the rules / automations really makes a device smart.
I had to do it for a device for my brother. But I needed help. It was too complicated for me :-(
You never cease to amaze me. Like a heroin addict I am a "knowledge addict". So just like a junkie on the streets of Amsterdam who strolls the streets (That's what they used to do in the 90's. Perhaps Amsterdam has become more genteel these days.) for their next hit, I troll the internet for my drug. Unexpectedly I discover your UA-cam "hit of knowledge" just as a junkie might find a loaded syringe to feed their addiction, your video satisfied my addiction for knowledge just now. This video was very interesting and drove home how difficult it is to keep up with technology. As soon as I begin to believe that I might understand a subject, I come to the realisation how little I really know. Your videos lay the foundation for further research. I often stop your video mid stream because unintentionally you mention one little thing (such as Adafruit's I2C addresses info in this video) and I'm off making "research notes". Keep pushing your "drugs". There's plenty of addicts out there who need them. I'm sure the next "hit" is going to be as good as the last.
Thank you for your nice words. I usually have people like you in mind when I create my videos. I invest some time and you get a quick overview, but not wothout some details.
Thank you for this video. I've chosen for Tasmota already, because I don't use Home Assistant and I wanted a GUI. And for the devices I wanted to setup, the available tutorials and how-to's seemed easier to do in Tasmota. But the biggest plus for me is that Tasmota already is prepared for talking to the Domoticz home automation.
ESP-Easy was mentioned in the comments. This project follows the Tasmota route: it has a webgui for adding sensors and you can use rules. There are also different firmwares for sets of devices. And you would give 0.5 points to the deep-sleep-functionality. As far as I know: no ESP32 support.
Thank you for pointing out Tasmota-Admin. I will definitely look into that.
Unfortunately, none of these are suitable for a remote control: battery-operated and immediate response on a push of a button. There's always the time needed for connecting WiFi. I am currently using ready-made 433MHz stuff for that. An RrxTrx433 directly connected to the Domoticz and 'klik-aan-klik-uit'-devices.
Could this be solved with LORA? I'm curious for the response time. I think that you are familiar with my problem: my wife says that the light should turn on immediately when clicking the switch.
I added mySensors to the list of a future review particularly because its 433MHt support...
HiAndreas. Love your work! I like you and many others use both ESPHome and Tasmota, it depends on the use case.
One thing I would point out for ESPHome is that if you are using Wemos D1 Mini, NodeMCU or TTGO ESP32 Cams you can use a standard micro USB to upload your ESPHome config. Just plug the USB into the Home Assistant Host and restart the ESPHome Add-On. Then you will see something like /dev/ttyUSB0 (USB2.0 - Serial) as an option for upload. This helps avoid the need for connecting jumpers to a UART connector.
After that it is easy to do OTA updates.
As mentioned: In my case it was a Docker customizing which prevented USB upload (I used IOTstack).
My google search last night: Tasmota vs ESPHome
So I had a nearly perfect timing...
Thank you very much for video, really appreciate it.
One important think: how are both integrate with HA, at this point I will give a point to EspHome as it have direct integration with HA. Tasmota is using a middleman, MQTT, to do this job.
Thanks Andreas, very clear and understandable video. Your videos are still the best in the business!. My favorite is Tasmota, this is where I learned all about MQTT. Tasmota documentation is also very high quality. I use my Tasmota devices with Hass.io, I really like that, as well as controlling a Tasmota device with a controller (Hass.io) you can make your device work autonomously with rules, so if the device becomes isolated from the controller, it can still be useful with working with its own rules-based "automatons" .
P
Thank you! I also found the Tasmota documentation very useful. However, rules are not easy for a beginner ;-)
Great Scott released a video on esphome today. What a coincidence.
I saw it, too. Amazing.
Excellent content, thanks for the informative video. Both Tasmota and ESP Home are winners as they help the DIY community have more choices, which help look at the same problem from different perspectives. Maybe in the future we could look at this sensors abstraction from scripting perspective ? Python and Javascript on microcontrollers ?
Maybe these languages will get their space also on micros. Till then we have to select between C++ and libraries or frameworks like the ones shown here.
Wow. Very helpful. This explains in plain language what I was seeing but not coalescing in my brain. Thank you. ❤❤❤
You are welcome!
I saw esp home some weeks ago, and had not the time to read deeply into it. Thanks for the overview.
You are welcome!
I've never made the Tasmota firmware work reliably on any of the multiple hardware platforms I have. They hang. However, most of the more recent (a year or more) Arduino ESP8266 WiFi Server examples seem to be very reliable. I've had one that controls a single relay work perfectly for about 6 months straight. Same hardware I tried with Tasmona. But I must say I had two extended power outages (two hours and ten hours), and after power was restored, it came back up without any intervention. Also, I have another ESP8266 WiFi Server that controls 20 GE Low Voltage relays, and it's worked perfectly for about 3 months so far.
Thank you for sharing your experience. Fortunately I do not have a lot of power outages here...
You really should have a look at ESPEasy!
Noted!
Ahh , well, I thought, damn why am I using something so exotic
Or ESPecial, for dynamic automation on esp32
A lot has changed since you made this video. A new comparison may be in order as both tools have evolved significantly.
So far it is not on my list. But HA is there. Maybe I will cover this aspect then.
EspHome allow direct upload from USB.
Espeasy is great that’s true but it is quickly a complex way to do : you have to compile yourself it with some options to have the sensors that you need. The development seems less organized. But I recognize that it is powerful too since a long time.
You are right, if you set your containers up the right way it should work. It was no problem for me because it only has to be done once.
@@AndreasSpiess There was nothing to set up with the standard raspberry pi 4 image from home-assistant.io and the community version of ESPHome. I just plugged in my ESP32 on usb and got the first image installed.
Same here too, I plugged in devices and it just worked to flash via USB to ESPhome. Occasionally I've seen it where ESPHome didn't refresh the USB list, restarting the server resolves for me if that happens.
Yes I also use the USB method, after you plug the USB in, just restart the esphome plug-in, to register the USB serial port, but thank for the great videos, I really enjoy your videos and find them very informative.
Thanks for your excellent videos Andreas! Did not know about tasmota-display, but now I know✌
I never used it, I just saw it during the making of this video
Very well done overview! I've tried Tasmota a little bit, but found it harder to understand, and ESPhome covers my needs so far. But it's good to know how the two differ. Maybe I'll need Tasmota for something in the future. Thanks!
Protip: ESPhome (in Docker) can upload over usb, but you need to first connect your ESP device to the computer running ESPhome, and then restart the ESPhome container. Then you should be able to select something like /dev/ttyUSB0 instead of OTA. (On Linux, I don't know about Windows.)
And you can run the ESPhome dashboard without HA, if you install ESPhome manually with the "getting started through command line" guide. So it's not as straight forward, but possible.
1. I assume it depends on the docker setup if you can use USB. I used IOTstack
2. As mentioned the video I tried to set it up but, as a Linux noob, I gave up after a while :-(
Hi Andreas, first off, thanks again and again for all the content you are delivering.
There's been significant development lately around both Tasmota and ESPHome. I would really love having a follow up video including those feature and your updated ranking.
Also I have heard about ESPEasy but did not have time to have a deeper look. Looks like more an easy & straightforward way to integrate ESPxx...but probably not for the advanced users....
Because I changed to Home Assistant, I usually use ESPhome. It is good enough for most cases. I think, the differences between the two platforms became very small. HA users will use ESPhome because it is so easy to setup. And the rest uses Tasmota (because it is so easy to setup) ;-)
But the next video will be about another specialized platform: OpenMQTTGateway. You will see, why.
@@AndreasSpiess looking forward to it thanks !
One important bonus of ESPhome is its direct integration in HA. You don't even need to pass data via MQTT. After, it's also possible to use any sensor with ESPhome as soon as there is an existing arduino lib. You need to build "custom sensor" with ESPhome.
I think I showed that there is a way to integrate new sensors. I tried it for about an hour and then gave up ;-)
@@AndreasSpiess Well it's a bit tricky the first time but I managed to integrate like that many many I²C sensors...
8:15 they want python3, you can see that at the command below ("pip3", which indicates pip from python3)
Thank you! You see, I am still a Linux noob :-(
Python2 has also been deprecated for almost a year, so that wouldn't make any sense to support it anymore www.python.org/doc/sunset-python-2/
@@AndreasSpiess To add a little to the confusion about the PyPA recommended tool for installing Python packages:
On Windoze: Python versions from 3.3 come with a launcher. You can do:
py -3 -m pip # Run latest Python 3 found on the system with its pip.
py -2 -m pip # Use latest Python 2 instead.
On Linux: Your pip may be a soft-link to pip2. Check it with
$ ls -l `which pip`
$ ls -l `which pip2`
$ ls -l `which pip3`
use
$ pip show pip
$ pip3 show pip
to get more details
On a python2-free system, pip may become the same (via link or copy) as pip3. But this can also break some packages. BTW using sudo pip on distros that provide native Python packages (apt-get install python-numpy, etc.) is calling for trouble. Keep that in mind.
I'm learning something new every time I watch Andreas!!! Andreas, you put smile in my heart and brain and I learn and learn more and more! Thank you for your hard work. (PS: I was under the Corona with my wife, so it took little time out of learning - that was the hardest part! Now we are like new again!)
I hope everything went well! It seems that younger people generally suffer less. And now you are most probably immune, which is a good thing.
@@AndreasSpiess At 65 I'm in the zone where it could go either way, but despite many other health problems it was "doable" and I didn't need any special medicine. If they would give me the same stuff as to the President Trump, I think I would take it. But it was like a cold and ZINC and lots of water and little food with apples and oranges helped also. Thank you very much Andreas!!!
@@AndreasSpiess You are right, but once your age is over 65, it takes a long time to regain just most of your previous energy and brain! I'm glad not much damage so far, but it keeps testing you weeks and weeks after your main symptoms and temperature are gone.
I'm very glad to hear about "the son off switches" again, thanks.
You are welcome!
The TSL2591 can be used on the precompiled Tasmota sensors binary by deactivating the TSL2561 driver: I2CDriver16 0
Thanks for the tip. I will try it!
Prepare for a fast ride today:
"Fasten seatbelts!" 😁😮😂
And still, it became long...
You are really a great teacher, sir. I appreciate your efforts.
Thank you!
I like to think we're of the same age and we probably have similar backgrounds in education and profession.
I'm sure we share the same interests and hobbies.
You always impress me by being so productive and skilled in the field. Today again! Thank you for sharing!
You are welcome! I am 64, a trained EE with a PhD in Business Administration. An interest in computers and RF...
@@AndreasSpiess Here is why I said ".. I LIKE to think..."
1. I am older (67)
2. I do not hold a PhD
3. Long ago I was a trained EE, but then I became a manager of large high tech development groups.
I now try to do small scale what I always talked about :)
I am - like you - interested in computers and electronics (digital and analog).
RF is still a lot of "magic" to me.... :)
Again THANK YOU for your channel!
PS On being a Linux noob we can shake hands..... after Covid19 by the way. :)
I'm running both for different things. If you're using Home Assistant you can't really beat ESPHome. It's very well integrated, has great support and works well for most things. The deep sleep/battery support is crappy though, when trying to use that with the ESPHome protocol (as opposed to MQTT) it spams your ESPHome logs because it can't reach the device most of the time. As for Tasmota, it's actually far more powerful than you might think at first glance. In addition to the web interface you can send many advanced commands through the console. I'm using it for a door opener relais for example, with Tasmota it's trivially easy to trigger the relay for 2 seconds and kill it after. And since it's using plain HTTP it's easy to get some other device to trigger it for you.
I also saw these "not reachable" messages during deep sleep. But I did not pay too much attention.
I’m a big fan of the fact that ESPHome uses the native API. It eliminates the need for the MQTT server and then defining sensors. They just automagically show up in HA when you add the integration for that device.
esphome-configs.io/ has some definitions similar to blackadder but still very early days
Thanks for the link. Concerning API: Many of my subscribers do not use HA. And I like open standards...
Thanks Andreas. Fantastic analysis and presentation as always.
Glad you liked it!
IoT devices with built-in ESP8266, like Sonoff, Gosund, Blitzwolf, ... --> ESPurna or Tasmota
But you have to keep in mind all the MQTT traffic is unencrypted. Because of performance and memory, no TLS secured communication to MQTT server with ESP8266 chips by default.
But as always a good content here.
You are right. I do not care too much about encryption. My sensor values are not very valuable and I have all my sensors in a IoT network.
Greart and informative video, as usual!!
At 9:42, you describe, that only OTA is available. I found on my RPI4 that when I connect the ESP to the USB connector of the RPI and then restart the ESPHome service in Home Assistant, the board will show up in ESPHome and I can Choose betwenn OTA and USB update. With this method, I can program virgin Boards directly from Home Assistant
Yes, with HA it is possible.
The answer to this kind of question is always the same: "it depends" :) The most engineering answer there can be.
That is why the goal and the criteria are so important...
@@AndreasSpiess I agree
Thanks for sharing your observations. Well done Sir!
My pleasure!
Thanks for the video. Previously I have used balena os for pi(grafana, mqtt, db and custom application for data processing etc) and mongoose os for esp, found it pretty easy to use. Now want to try ESPhome.
It should nicely fit into your Pi tools (I made my tests with node-red).
Excellent video. Please do it again, updated for a current comparison. THANKS!
So far I have no such plans. But you never know ;-)
Woooow it's really a great work. Thank you so much for this detailed long video.😊❤
My pleasure 😊
if I could I'll hit to like your video ten times. Very informative!
Thank you!
Edit: Name corrected - sorry.
I'd like to see you compare espruino and mongoose OS. Both use JavaScript interpreters with on board hardware management dashboards and web based IDEs.
Please Andreas, please compare those two was I'm really struggling to decide between them.
There's nowhere that compares the two. You'd be helping a lot of people out.
I once did a video on microPython. Maybe I will return to the topic of higher level languages.
@@AndreasSpiess I got my first answer from Andreas!!! I'm so happy this has made mt day!!!
Seriously I think if you google a comparison of the two there's very little out there and it would at the very least give your channel a boost due to the lack of competition on the comparison of the two subject. :)
Maybe you read the comments of my "Godby Arduino" video...
Just today, a new version of Tasmota for the ESP32 (8.5.0.1) was released. Upload via esptool.py and it runs smoothly. If Tasmotizer gets the update to support the ESP32 as well as the ESP8266, it will be much easier to flash Tasmota32. One feature, i'm missing in tasmota32 is the support of the touch-pins - might come soon enough.
Good news. Thanks!
Great video. All your videos are great. I did want to add to this one though: you gave a point to Tasmota in the section that discussed the OTA as the only option for ESPHome on initial flash and as a work around had to download the binary and use the flasher. Actually that is how I do it too but only because the computer running ESPHome is upstairs for me. If on the same computer running Docker, simply map the usb port to the docker container (or run in privileged mode). Then the USB device will be in the dropdown as well. Believe you also said that Tasmota has a nice one place to see all Tasmota devices but ESPhome does not, yet you show the page where the OTA drop down is which shows all the devices. It is for this reason I use a custom panel to being ESPHome in home assistant so I can see all esp devices in one place. So, anyway, just those 2 minor things I wanted to comment on. Going either route (Tastmota vs ESPhome) is 50/50 in most cases and probably will remain that way. I like ESPHome, especially being able to use any arduino library to make a custom component or even write my own.
You are right with Docker. I used IOTstack and it is not implemented there. Maybe they will change it in the future. It was not a big deal for me.
Concerning TasmotaAdmin: I said that it shows much more information.
That's a very good summary. I also like your comparison between efficiency and flexibility, I think many people don't really realize this.
For me personally, when I can, I like to use ready-made software like tasmota. But many times such software or even some libraries don't offer exactly the functionality that I want. So I end up having to write my own program. I have even written some assembly programs. But very rarely, since apart from memory and speed efficiency, assembly doesn't have many advantages compared to C. You can do almost anything you can do with assembly also with C. But assembly takes so much longer to write that for complex projects it's really not worth the time. At least not for me.
When I was young we only had assembly language and we were happy when the higher languages were developed. I never looked back ;-)
@@AndreasSpiess Yeah, I can understand that. I mean, I think assembly is actually kinda cool. Usually there aren't that many of instructions, so it's fairly easy to learn. And I like that assembly translates direction into machine code, without the need of any compiler. But on the other hand, having to learn different instruction sets for different processors is rather annoying. So yeah, in general I definitely prefer C/C++. Or even python, but not really on microcontrollers, since they usually have fairly limited resources and I consider python is just too high level to really be efficient (in my opinion). Anyway, I'm also certainly glad we have more sophisticated languages than assembly (or just writing pure machine code, as the used to do before assembly).
It is not about the instruction set. Here you are right. It is about the complexity because you have no variables, only memory locations. And with the 8-bit CPUs we only had numbers up to 256. Above that you had to do all the calculations by yourself. Maybe you look at how a simple division has to be programmed in assembler ;-)
And the readability of this "spaghetti code" was also horrible.
Anyway, sometimes it has to be used up to today if you have special needs where you can not use a higher language.
@@AndreasSpiess Yes I know... And if you have numbers higher than 255 you need to use two registers, which is kinda also a mess. But I guess it's still better than working with a 4 bit processors.
Conditional code is also kinda annoying, cause there is no if or else, so you basically have to figure out how to get it working, by skipping instructions or jumping to a different address based on some condition.
But I mean, that's the normal trade off, the way it works is simple, but it's complicated to work with.
But you know, there are things about assembler I like. For example that you know exactly how much time each instruction takes to process (or can take to process).
C/C++ is clearly superior when it comes to programming. But since you basically give some of the programming work to the computer (compiling the code) you lose the insight into exactly what the processor is doing at any given time.
Obviously I'm not saying Assembler is better. It is quite elegant in certain ways.
But assembler quickly gets to the point where the processor speed is not the bottleneck, but instead the speed of the human programmer. And at that point of course it makes sense to sacrifice some efficiency for quicker and easier programming.
Andreas, very much appreciate your content. Learned a lot on this one!
Glad it was helpful!
Configuring deep-sleep on esphome, you could instead of the timeout, create an automation on the device (although i have not tested this):
sensor:
- platform: dallas
on_value:
then:
- deep_sleep.enter: deep_sleep_1
Thanks. I think I would have to wait till the MQTT messages are sent before I start deep-sleep. I will have a look at it in the future.
FWIW, if you connect a USB-serial to your Home Assistant machine, ESPHome will discover it and let you flash firmware. This works even with a dockerized install of HA running on a virtual machine hosted on my home NAS. (The only funky step there was remembering to assign the USB port on the NAS to the virtual machine). The port can be found as an alternate selection to OTA in the selection list. As far as startup time for the deep sleep problem, if you assign the address yourself (or make a DHCP reservation for the node once one has been assigned, and configure it as static in the node configuration), startup time is much better. And if the OTA update is problematic with sleeping systems, they can always be taken back to the development environment and programmed with the USB connection.
You are right with the definition inside Docker. Maybe they add it in hte IOTstack prokect.
Concerning fixed IP address: This trick works for all ESP sketches, not only the frameworks.
For some nodes I am really happy they have OTA because it is a pain in the a... to remove them where they are ;-)
Hi Andreas, one small point, for most ARM MCUs, there's no real advantage between C/C++ and assembler. This made me sit up and think and I've noticed that modern compilers can make very efficient code without having to use (very hard) C shortcuts. It makes for much more portable and readable code without sacrificing speed!
And there are other languages like Micropython around the corner...
@@AndreasSpiess LUA too for the ESP boards but I do like my C for crushing quarts into tiny spaces while annoying older C programmers by writing verbose code that compiles to almost nothing while remaining readable!
I guess I'm not complete beginner but I would disagree to the "both have steep learning curve".
I was shocked at the simplicity of ESPHome when I started using it.
To get started all I had to do was install ESPHome, create the config, define the pins and flash it. It felt really intuitive and somewhat like a magic. And their documentation is excellent.
Later on I also realized that you can use custom components for things that are not supported out of the box. And you can use existing Arduino libraries for that job.
Check out their "Custom Sensor Component" guide in documentation.
Oh, and I use Home Assistant, so auto discovery and fully automatic integration for ESPHome devices helps as well.
If I remember right I used the "steep learning curve" for the automation part. I agree, the simple things are easy for both (as shown in the video).
Greetings Andreas,
There's a lot of hardware and software solutions for the maker to tinker with these days.
I thank you for creating these in depth reviews and tutorials on what there is and how to go about it.
i currently have a bme280 connected to an ESP32 which is sat outside on my windowsill upstairs.
It is nice being able to see the weather outside from my browser on my pc or my smartphone.
I must get act together and arrange for it to talk to Profilab, as that does data capture well and can do the controlling of actuators if need be.
We had snow in the western Cape on Friday and it's interesting to see that the air pressure drops by 10 hectopascals in Johannesburg at the same time, that's 1400 km away.
It takes 2 days for the cold air to reach us here afterwards.
Very interesting.
I also had fun doing data capture by loading a 0.5 Watt pv array with a resistor, connecting it to an esp32 analogue input and graphing the solar radiation using Profilab.
Very interesting how the solar intensity varies with changing weather conditions.
Anyhow, taking up your valuable time by making you read a long text.
Thanks for the video, it's approved.
Kind regards,
Duncan
You are welcome! We also had snow this weekend in higher altitudes and it became quite cold where I am.
The idea of my light sensor is exactly to see the correlations between the different components of sunlight throughout the year and find out, which one is best to steer my awning, for example.
@@AndreasSpiess Yes, you need statistical data to build your control algorithm model on.
Going to be interesting.
Many things changed with Tasmota 9.4
I have successfully flashed ESP32 with the latest tasmota and I see that it has support for mqtt, knx and many sensors.
Already tested with RF and IR, works perfect, using mqtt and knx to control them
Thank you for your info. Just upgraded one of my Sonoffs today...
Wow! a very comperhensive comparison, thanks Sir!
My pleasure!
Thanks for an interesting video, Andreas.
I can only really comment for Tasmota. It find it fine for simple easy jobs, and I like that they have added syslogd telemetry (syslog to UDP port 514), which is lighter weight than MQTT for interval based telemetry. But when it comes to automation on the sensor itself (not centralized via say Node-Red), I feel I want a little more flexibility. The Rules of Tasmota are a pain to edit, and they are sometimes a little cryptic. For example, if you want rules to only trigger once on change, you have to enter this command Rule 5. Doh? It's cool in ESPHome that you effectively write the C++ and upload, but that's still a pain to debug. What I actually want is an easy to use interpreter with web-based debugging/breakpoints so that I can mess with it in its installed location until I'm happy. Almost like MicroPython, but that is way too sparse to really use. The closest I have found is this Annex RDS platform (sites.google.com/site/annexwifi/home) - it's BASIC (yes really, welcome to the 1980's :-), but with a file manager, breakpoint and single-step debugging, and really cool webserver integration if you know a little about web programming. I am not involved in that project, so this is not an advertisement :-) I just find it a quite useful alternative.
Thanks for sharing your experience. You describe exactly what I wanted to say about the layering. You get different things on different levels. It is always a trade-off between "speed of deployment" and "flexibility".
With ESPHome it is possible to add additional libraries and code in the yaml. This makes it a mix between an custom sketch and finished framework which makes it possible to support new sensors. This also allows for more advanced automations.
But in my opinion, with several devices ESPHome quickly becomes a bruden to maintain and keep them all updated.
I mentioned it for one of the sensors. So far I only tried it for an hour or so and was not successful :-(
@@AndreasSpiess ohh, sorry, guess I zoned out for a second. Anyway, a few months ago I switched my setup from Tasmota to ESPHome due to the more advanced automation possibilities. Very flexible, but a pain to maintain.
Thanks for the video 😀
I have been building most of my own devices using ESP32 with micropython and MQTT. Much more flexible, but more work.
Me too. This was when my question for the video came to my mind ;-)
Great comparison. Thank you for all your research work and sharing.
Glad you enjoyed it!
You have the Developer tools in Home Assistant for seeing the sensors and everything else :D it is awesome check it out.
Maybe I will do that in the future...
Esphome ftw
You can compare everything....
I've been using Tasmota since the project started. I thought it was weird, you posting a video about Tasmota, since I built a custom ESP32 Tasmota (beta) firmware last Monday for an unsupported device. The .bin uses about a third of the available space on a WROOM-32U module. The project has been in use since last Monday evening and does what it needs to do.
I only see Tasmota as the easiest way to get a web interface, MQTT, and OTA onto an Espressif project in a short time frame (usually an hour or so). I don't see its shortcomings as shortcomings, but as features *I* didn't implement yet. Using Git effectively is key to keeping my code and ever-changing Arendst's code in sync.
I looked at ESPHome & decided that it's more difficult to use as a standalone device. I'll look at it again in a year. I don't like Home Assistant, its interface, its runtime architecture, or its functionality. I installed it for three days, realized HA is trying to be all things to all people, does none of those things well, and will always be one bad update away from everything in my house breaking and an angry spouse giving me That Look. Again. She's tiny, but scary.
I decided to not compile Tasmota because I assume most people will not do it. I also did not implement custom sensors in ESPhome, because I tried for one hour and was not successful.
The charm of framework is that they are easy to use and Tasmota would not be so successful without Tasmotizer and the bin files. Look at Espurna which was probably earlier than Tasmota...
very nice and concise video Andreas..keep at it mate!
Thanks, will do!
Your English is very clear,
Hi from Mexico
Thank you!
Thanks for the great video. I have not heard of tasmoadmin before. I use tasmota most often (also because of tuya-convert of several Gosund SP111 power monitor plugs). Also ESPeasy for an S0 counter.
You are welcome!
Programming via USB is enabled on HASS/ESPHome addon when a supported device is detected, ie serial port. The device will show an item in that drop down that always says `OTA Over the air`. To see this plug a device into the hardware that runs HASS and check the drop down list.
Thank you. I think it was because I ran it inside Docker.
Nice job selecting those AMS sensors. 😉. FYI that TSL2561 was the sensor used in the first iPhone.
DE N5BOC
Oh and you can get IR from the TSL2561 if you read only CH1. Throw away the data from CH0.
Thanks for the advice. I have to try the trick with CH1. BTW: I programmed the redit talkgroup on my DMR radio and already talked with a US guy. So it seems to work also for DX ;-)
Good comparison. But to be honest, I can not understand why you did not include ESPEasy in the comparison. ESPEasy is by far the most common and sophisticated project for ESPs. Since I tried ESPEasy, I barely write my own code as so much is covered by ESPEasy.
I did not know the project well. Maybe in another video...
No its not, i started with espeasy but its not that easy.... With esphome you have the API so you did not need to use the MQTT crap
@@carlosrodrigues6863 Just FYI, in ESPEasy there are lots and lots of ways to get data in or out or control using commands.
MQTT is only one of them and it is very easy to exclude the MQTT controllers and MQTT import plugin, so you don't have the "MQTT crap".
But I'm open for suggestions, so maybe you can give an example of where things can be improved?
Excelent work Andreas!
Glad you like it!
Great video
You missed the point where if your home assistant goes down you still can control esphome devices through AP
But you cant control MQTT devices
you can still control all tasmota devices by each of their AP's and create rules for connected switches
I like MQTT. But all my sensors need some sort of "collaboration" to work because the sensor and the actuator are not the same device.
I only use tasmota and few self made projects, thanks to your platformio-video!
Good choice!
Thank you very much for your videos. For battery operated sensors I would like to mention mySensors with a mqttEthernetGateway.
Mysensors support also other RF technology. Which is very good for deep sleep. Thanks for the tip!
I use tasmota and esphome for many cots devices but I use mysensors for all my home built sensors. It has an important benefit in that it uses its own wireless mesh so only a single IP address and you don’t load your wifi with more sensors!
I use node red for my home automation, I tried home assistant but I think you have a lot more control using node red. For instance my LoRa sensors all require some level of processing and I find this easy to do in node red and to display that information is simple. Same with the RF bridge and send and receiving raw codes. Im not sure if you can go down this far down the layers on the home assistant. The main draw back is remote access but thats no issue since I run ipsec server on my router and just dial in from my phone. Notifications are by email or text . I dont have to rely on an external systems this way
It is well possible you could get everything done by HA using tricks. But as a casual user I forget a lot of these tricks. This is why I stick with Node-red for the moment. A little bit of JS is "unforgettable" for me...
I peronally i use homeassistant as the central hub, but NodeRed (as an add in) for all the automations.
Very good video. Saved me a lot of time researching
Glad it helped
I flasged 3 Sonoff Basic with Apple Homekit and I’m using them right from the iPhone. Also I built a neopixel strip connected to a ESP node and flashed with Apple Homekit too.
Very good!
I like both of them very much.My house is a mix of both devices.
I think both have advantages and disadvantages. Glad we have choice...
Isn't there a ESPhome admin page add-on in HASS? I've downloaded it recently but not used it yet, using Tasmota mostly and not extensively.
Also a superb video, a Belgian beer goes your way sir!
A typical Swiss decision at the end 🤣
You can display esphome in hassio menu. Base status check is innode panel - red means not working, green ok. To check another things you can use special sensors (uptime, restart node, wifi status etc.). ESHome talks to HA via API - it is better and faster then mqtt (also more reliable). Tasmota is cross platform solution. ESPHome is designed to work with HA - with all its benefits. If you using HA ESPHome is only one good choice :)
I used the Home Assistant add-on. But mine did not show a lot of info. It mainly was used for the deployment of the firmware. And I based everything on MQTT because this is an open standard and many of my subscribers do not use Home Assistant.
Oh... And on the command line, ESPHome gives you (or me) the option to flash connected devices via USB (yes even on my containerised raspberry installation).
I assume it depends on your container setup. I used IOTstack for this video.
@@AndreasSpiess thanks, this answers a question i had on the homeassistant discord server: Is there a problem when i use ioStack, looks like the answer is "No,
but you have to setup something manually."
If you want you can head over to the IOTstack Discord and tell them what to change...
@@AndreasSpiess They need this in the configuration github.com/slimcdk/home-server/blob/9d5e598c8da8666fc6e5c01a6fbc129b3d2fa71a/docker-compose.yaml#L147
Or even just - /dev:/dev
@@c7ndki am not sure this is done in container config... on my installation all serials are mounted and dismounted from the container automatical
For me it is ESPHome and HomeAssistant because its available as a plugin in Freenas :)
I did not consider Freenas as something important for the decision. Thank you for the tip!
For me, ESPHome runs on my windows machine rather than on my server. I make a yaml file, write my code in it with Notepad++ and connect the esp module via usb to my PC. I mainly buy wemos d1 mini clones, since they have usb for programming onboard and are also available on amazon, since i dont like waiting for my packages from china. After the initial flash with basic config (wifi, home assistant, etc), i disconnect it and than build my pcb for the boards (soldering LED driver circuits for normal LED´s onto a prototype pcb, adding headers for external sensors via i²c, screw terminals for external components and so on), prepare a case for it (most of the time boxes for electrical wiring for houses, thats easy to do, fairly cheap and commonly available in every home improvement store), building the complete node together, powering it on, and than starting to add its configs one after one in the yaml with test flashes in between via ota.
For this to work, you only need to install python3 and pip3, and then install esphome via "pip3 install esphome".
Im using my windows machine for compiling since its a lot faster at compiling (i5 8400, 32gb memory in my win machine vs core 2 duo and 3 gb ram on my server for Home Assistant from late 2006) and i think i dont need a newer server for running HA, a few addons and samba since my dad found that pc in the attic and it works well for my use case. And its easier to maintain or add more drives to for me than a raspi. I had a raspi3b+ running with sd card as HA server, switched to a hard drive as boot drive and got problems (i live on a tight budget, so i cant easily buy a new ssd, that why im using what i find in my "devices meant for repuposing"-drawers) with stability and switched to a normal x86_64 cpu, where i can easily install a new drive, install any distro i like and have freedom which package im installing, without beeing limited to use compatible packages ( i had a use case for an old ndas drive, where i had to compile its drivers to use with the raspi, and i gave up its build process).
I heard of some other viewers who also use windows machines instead of Raspberries. It seems to work ok. Here I have no Window PC for 27/7. So I use a Pi.
@@AndreasSpiess Its almost the same on the pi. Install python3 and pip3 via apt-get, pip install esphome, write your code in a yaml, cd on the console to its folder, type "esphome [filename] run" for uploading, it will upload the compiled firmware and give a log output. And through this you can decide to flash via usb or ota (for the initial flash ota obviously wont work).
This is your first video where there's something that I disagree... At 11.26: 'it is still summer with lots of sunlight'.... You should have a look over here (Belgium)... and also in the alps, I noticed lots of fresh snow. I can only imagine that your on some exotic place other than Switserland when you recorded this. Btw, excellent video. Right to the point.
You are right if I have a look outside now. Cold and rainy. Completely different as when I started the filming. You see how long it takes to create such a long one ;-)
Good video, I use Tasmota with iobroker over MQTT this work pretty well. In Tasmota firmware i use normal sleep - for deep sleep i need to google more, to find the best practice. FOR power a normal 10 watt solar panel and a small akkupack.
For most Tasmota applications, deep-sleep probably is not needed.
an updated video to this topic would be really nice... a lot has changed on esphome side
You never know. So far I have no plans.
Nice video. However, if you're a developer like me you probably prefer ESPHome. The amount of supported devices is not that bad. Big Plus: You can drive sensor and actuators the same time. And you can define own, new devices as well or even 'inject' own C++ code.
BTW: There are even more frameworks like ESPEasy or MySensors.
I started a list of other frameworks. Maybe I will make an extended overview...
You can also run ESPHome from the command line without docker. You only need python and in that case you have easy access to the USB port. The ESPHome web interface can also be run from the command line with the `dashboard` command and is the same interface as the HA integration. I run ESPHome in Home Assistant, but just last night I also installed it on my Macbook with python so I can easily flash a new device by plugging it in to the USB port. I had a 4 channel Sonoff flashed and working in no time. You can also do this on the Raspberry PI and Home Assistant by adding the USB device to the docker command, however I find it easier to just connect it to my Macbook. Also if there is not a configuration available for a particular device I find it quite easy with the documentation how to add switches, buttons and lights for instance. For automation I still prefer to use Node-Red. I have written my own firmware for my ESP-CAM security camera's, however ESPHome is my default framework to go to if I don't need anything specialised, because I can get it up and running so easily and quickly. I takes a lot of the hard work out of building a firmware by hand. (and I have 30 years programming experience). For deep sleep you can use the deep_sleep.enter Action to go to deep sleep when you have sent your sensor data.
Good information. Thank you!