Hello Everyone.
I have been struggling for many days to find a solution which - in my mind - is a common use case.
I want to put together 10 ESP32 “multisensors”. I have 10x ESP-WROOM-32s and 10x various sensors (temp,hum,presence,motion etc.).
I successfully put together (hardware wise) my first one and created a working yaml file for it (ie. flashing it with esphome web through wired connection, recognized wirelessly in esphome and recognized as well in HA). All good.
Since all 10 of them have exactly the same hardware, I wanted to compile a “generic” bin file, from a “generic” yaml file so as to flash the same bin file to all of my 10 devices and then be discovered and recognized in both ESPHome and HA.
The only configuration that works as intended for a single device is this:
Using the the api key and ota password the esphome provides when adding a “New Device”.
My issue is with the api key, ota password and device name.
I have tried all possible combinations and none works:
Without an api key & ota pass by removing the encryption, key and password lines. Though the documentation mentions they optional, ESPHome doesn’t get a successful “handshake” with the device.
Flashing the same bin file using the same hardcoded api key, ota pass with and without “name_add_mac_suffix = true”
Flashing the same bin file using the same api key, ota pass in secrets file (ex. !secret api_key) with and without “name_add_mac_suffix = true”
Replacing “arduino” with “esp-idf”.
The main issue is that they either not discovered in esphome and or not making a successful api handshake in it (ie. I can see the device working through esphome web wired logs but not connecting wirelesly…)
What is the correct api key, ota, name syntax for the yaml to achieve my goal? Is there a working “common practice”?
I personally don’t mind having a key and a pass (though preferable for security).
PS: I am not a developer, just a normal user who understands basic yaml syntax.
Thank you all in advance!
Instead of sharing a bin file I use packages to include generic setups for esp’s. They all get their own basic stuff like name, api keys etc, but the rest is a package. The packages contain yaml like the base yaml would have. If needed, you can even pass parameters to the packages.
Downside is they each need to compile, upside is that I can combine packages if an esp has multiple sensors etc. or shares the same board resources.
“they each need to compile”. I could also compile them one by one with different names, keys and pass. I did it this way for a second device and works. That is what I want to avoid though. The more than 15 minutes compilation process of the bin file whereas the flashing process is just 2 minutes. That is why I am focusing on the “same bin file”.
I’m not sure, but I think all these things to tell them apart like name_add_mac_suffix are settings for compilation. So once the bin is made, all is fixed and multiple boards would get conflicting ids. But that is just guessing. edit - scratch that: it is meant to be used for what you are trying.
It also says though that after adopting users would set their own keys, so they would not remain sharing their bin file. I assume you used this doc to get started. This docs say you cannot have ota without a user specific yaml.
Up to a point…maybe. The issue to solve is WHAT should the yaml contain - therefore the bin file (ie. what is the correct syntax/use of name, api key and ota pass parts of the yaml) to achieve this. Maybe esphome is not designed to do this through the yaml. Maybe I am missing something. But seeing that “name_add_mac_suffix” option is possible, I am trying to find how to handle the api and ota parts (though optional in documentation, handshake with esphome is not possible if removed).
After days of trial and error I have managed to create a process and files to achieve this but WITHOUT the use of API Encryption (key), OTA Password and WIFI credentials in secrets. The only way I made this work is by hardcoding keys and passwords in the yaml files (which is not 100% safe solution… I think) or generally edit yaml files and/or secrets file which is not the objective The objective is for the user (after the bin flashing to not mess at all with yaml and/or secrets). It is not the desired end game but… its a start. I even created a repository for this for anyone who wants to fork it. GitHub - djgenesis/esp32-multisensor: esp32-multisensor. If anyone can achieve the same process but including API Encryption (key), OTA Password and WIFI credentials in the yaml files please do try. Fork it and publish it. It will help not only me but the whole community. Also any suggestions for the current repository would be surely welcome. Thanks.
Look at Tasmota if you want one binary to work/rule them all. That is the general model it uses.
Esphome uses the opposite model, unique binary for every single device, even if they have identical sensors.
I suppose it is possible to make each one closer to the other, but you will likely find it hard, since there are assumptions that will no longer be valid.
Tasmota has a way to configure pretty much everything on the fly, so one binary can be used on devices that have widely different sensors and configuration including Wi-Fi.
Esphome has a model that says you must compile everything for every device so it hard-codes most things. This typically leads to much smaller binaries that have only what is needed now (and not what you might want to add later).
If you have identical devices, Tasmota might be a better choice. All of my esp8266 based devices use it, since it existed long before esphome did. When I started using esp32 based devices I started using esphome, since compilation of Tasmota for esp32 was taking 5+ min and that was more than I was willing to wait (and it needs different binaries for the different varieties of esp32 anyway).
Thanks for the feedback. Correct me if I am wrong though as I don’t know a lot about Tasmota. Been handling Esphome all this time. With Tasmota you need to flash a generic bin at first to each esp32 and then for each one set the pins, mqqt and whatever else. If so, this is not the objective. The objective is to create… somehow… a single bin (with the configuration) to flash it to multiple esp32s. The same bin.
You can create a custom bin with Tasmota that has the components you want. You might be able to create one that also has most of not all the config of those components that you want.
I used one bin that I installed on each device. None of mine were identical and you need to have unique names. I would install the binary and then visit the webpage of each device and finish the config. The last part could be automated. For an update, it is generally just necessary to ota update the binary, since the config is in a different part of flash.
It is a different model for thinking about the way things should be. It has its advantages and its disadvantages. If you are heavily invested in the esphome way of doing things learning the Tasmota way will be hard. If you are only doing simple things, either is fine. Tasmota has been around for years when esphome started, so presumably they felt there was a better way of doing it. I started using esphome for the faster compile times and better separation of concerns in the code. Both projects have steep learning curves if you want to go beyond basic things.
If you are just using it (not adding support for missing sensors or features) the learning curve is easier, but Tasmota doesn’t require compiling at all (it has pre-built binaries).