Advantage is easier to integrate and much faster to respond. No need for MQTT server. Disadvantage is it’s only going to work with HA. No brainer if your only working with HA.
Is there an easy way to use a single build of ESPHome firmware that I can deploy on multiple devices of the same configuration, yet somehow have each device have a unique name, MQTT topic, etc?
I can do this in Tasmota - the compiled-in defaults I use will bring it up on my WiFi network, and then I use the web interface to configure unique parameters that are stored in some configuration storage on each device. I’d be happy to do this any reasonable way on ESPHome (e.g., sending an MQTT message to some topic, HTTP PUT of a JSON structure, or even a web server).
I’m really trying to avoid having 8 different directories with the same code and just a few configuration differences just because I have 8 Sonoff Basic devices.
1 Like
Yes you can use variable substitutions. Take a look at the docs the “configuration types” section.
You can just use mqtt if you want to use it with something else.
Dev version works with both HA and mqtt if you want to use it with HA + something else.
Very true, note that currently MQTT and HA methods don’t seem to work together correctly. I guess my point was that if you were going to use MQTT, there are better options available.
Last I checked, variable substitutions is a compile-time mechanism; I still need to compile and link multiple binary images, one for each device.
I’d like some sort of run-time substitution. Perhaps even a way to have the MQTT topic (and client-id) vary based on, e.g., the MAC address of the device or some other unique value? I had in mind sort of what Tasmota does, which is allow some run-time configuration data/variable be stored in the SPI flash file system on the ESP8266 device.
Then I guess the answer is no. Is designed that way ATM. Don’t know if there is any intention of changing the fw creation flow. @OttoWinter might give you more inside if it has anything like this on plan.
Nope, run-time substitution will not be officially supported because that breaks some fundamental assumptions esphome_yaml_ makes (for example for log output etc).
That being said, with custom code you can totally add run-time substitution if you like (just call all the set_name(), set_x_topic functions).
But I also want to question the fundamental thing you’re trying to do here. Why do you want run-time substitution? ESPHome supports all of HA’s config include syntax. So you can have a central YAML file common.yaml like this:
esphomeyaml:
name: ${name}
sensor:
- platform: adc
name: ${name} Voltage
# whatever
and then create a simple YAML file for each ESP like this
substitutions:
name: esp1
<<: !include common.yaml
With the dashboard, managing the ESPs will then also be quite simple. Heck you could even write a quick bash script that deploys the latest changes to each ESP (which would spare you the need to go to each ESP’s web interface individually like you’d have to do with tasmota)
3 Likes
Hi @OttoWinter!
Please forgive my ignorance but what is the “<<” notation from your substitutions example? I have not seen that used in .yaml before.
1 Like
What I initially wanted was some configuration data that could be changed; someone else suggested “substitution” as a means to achieve my goals.
The driver for this is, say, I have 3 instances of a “multisensor” scattered around my house. And 8 Sonoff Basic devices. If each class of device is intended to have common behavior, it would be nice from a management perspective to avoid duplicating 23MB of platformio build directories to generate a bunch of 900K bin files that really only differ by less than 100 bytes each.
This isn’t the end of the world or anything. Disk space is cheap these days, I suppose, just trying to avoid wasting it if there’s was some obvious alternative I was missing.
It seems like the <<: !include tool would come in handy. I didn’t know that was present.
1 Like
Well, I’ve gotten pretty much everything switched to ESPHome using Docker and I have to say that it was pretty painless aside from me not being able to get the USB port to be recognized on my NUC. It showed up once but when I unplugged it and plugged it back in to verify it was the right one it never came back. It wasn’t an issue since I just used the downloaded binary file on my Windows PC and used ESPEasy flashtool to load the binary.
using “substitutions:” and !include files worked great.
Do you know of anyone who has figured out a config to mimic the tasmota functionality for the iFan02 yet?
I do not. Though AFAIK the iFan just has a few relays that control the speed, when more are on, you get more power - that should be fairly easy with esphome automations.
I’ve been digging thru the Tasmota firmware and the iFan schematics and it doesn’t look too bad. The only thing that complicates things a bit is the remote.
When (if…
) I figure something out I’ll post it to the main ESPHome thread.
@OttoWinter
I am playing around with ESPhome and so far I like it. One question, last week AT&T decided to disrupt our internet service for about 12 hours! I have Hassio on a RP3 and Tasmota firmware on about 20 devices. I was still able to control my devices like normal with no internet. Can I do this with ESPhome? Thanks for all you do!
in a word… yes
Regarding which is best … is the following consideration any value in that decision –
I use Tasmota because I use some less common devices, many very nice switches built upon the Tuya (ESP8266 w/custom firmware) platform. Using Tasmota, someone has generally already created a Tasmota config or fork, for every one of these devices.
I’ve never used ESPHome because I’ve always just assumed that I don’t have the knowledge to get it running on a device that it hasn’t been designed for, such as these Tuya dimmers, etc.
Is my assumption valid, and if so – would you consider this a “pro” for the Tasmota, considering it is, by far, the most widespread custom firmware for mains-switching?
I agree with you that it’s definitely a pro in tasmota’s favor in your case.
I have a couple of devices that I haven’t switched over to esphome yet for exactly the reason you stated. One is a Sonoff fan controller and the other is a security laser device that runs a custom firmware i made up in arduinoide.
The latter will be fairly easily able to be switched over but i just havent gotten around to doing it yet.
The fan controller will be more complicated but I’ve just got to get more comfortable with esphome for more than just the basic stuff before I tackle that one. But tasmota made it very easy since it had a standard component already ready to go out of the box.
1 Like
hello!
just quited esphome because of wifi conection dropping on the router… after adding 9 node the router just drops the wifi and cannot connect anymore. tried 3 router same thing. On the other side it is very easy to configure with esphome. nice work!
Another ‘negative’ to ESPHome is that it is much newer than Tasmota - and therefore there’s a lot less examples out there to learn from. As someone that learns a lot from others (I have zero coding experience) that makes ESPHome a bit harder in some respects. However, I’ve decided to start using it anyway - it seems a hell of a lot easier to setup than Tasmota and it’s biggest advantage is that it can in effect run on the device without needing HA.