I’ve got several smart plugs of the same type. So I followed the instructions and split my config into three parts: wifi configuration, model configuration, device configuration (friendly_name, power calibration etc.). As of now I’ve deployed only one device, but I’ve spotted an issue I would probably stumble upon. There is no way to indicate that smartplug-efcd02.yaml should be deployed only to a particular device. The mdns discovery code in zeroconf.py looks like it would match all devices named smartplug which isn’t what I want.
Is there a way modularize configuration on one hand, and on the other be able to deploy to a single device without setting different name in each configuration file? (Or is the name actually the field that is actually meant to distinguish devices and I am trying to do it the wrong way?)
Do you think it’s worth taking a time and developing a way identify a particular device in the configuration file the file should be deployed to (e.g. via setting MAC address in the file)?
FWIW, it sounds to me as though you are over-thinking and confusing yourself by even looking at python code. Everything you should need is in the ESPHome documentation - though I admit it’s not particularly user friendly.
I have several Arlec PC191HA smart wi-fi power sockets; and (being rather old-school) I choose to manually allocate IP addresses for each via my router’s DHCP Server.
For each smart plug I have a short yaml file which I choose to name with the device type and the last octet of the IP address. For example this is pc191ha-111.yaml:
#
# I have a number of Arlec PC191HA smart plugs with Power Monitoring,
#
# This contains the parameters specific to this individual device.
# device-specific values moved out of common files
substitutions:
deviceIP: "111" # last octet of the IP Address
currently_used_for: "chest freezer"
wifi_ssid: !secret upstairs_ssid ### which wi-fi to connect to
wifi_password: !secret upstairs_password
pc191ha_version: "v1" # versions 1 and 2 use different chips with different pinouts
update_interval_network: "30 min" # How often to report network quality values
update_interval_energy: "10 min" # How often to measure and report energy values
packages:
common_wifi: !include _common_wifi.yaml
device_base: !include _common_pc191ha-v1.yaml
What is in your smartplug-efcd02.yaml file ? Since spacing is critical in YAML, use the </> button on the editor toolbar (it may be hidden, if so click the on the right) or wrap your block in three backticks (```).
I believe @namleets concern is how does he prevent pushing the compiled code for smartplug1 to smartplug10.
If you are using the CLI (which is what I use) there is nothing that prevents you from doing this. This is by design it seems. I have used this to change the name of a device. I don’t have multiple of identical devices so not an issue I have experienced.
I believe one of the dashboards might have some support for this, assuming there are unique YAML files for each device.
@donburch888 your pattern for dealing with multiple devices that are similar looks good. I do something similar for the common parts of mine.
My smartplug-efcd02.yaml is quite similar to yours.
substitutions:
# Higher value gives lower watt readout
current_res: "0.00280"
# Lower value gives lower voltage readout
voltage_div: "775"
packages:
- !include smartplug.common.yaml
- !include waw.common.yaml
esphome:
friendly_name: !secret smartplug-98dbef_friendly_name # not to reveal too much about my home
How do you use deviceIP in _common_pc191ha-v1.yaml, because this looks like the bit I am looking for?
how does he prevent pushing the compiled code for smartplug1 to smartplug10.
More like: how do I rebuild and flash ten different images with one command and they all make to their destination. Think Ansible or Colmena, even if done half manually like for f in smartplug-*.yaml; do esphome upload $f; done.
You definitely could do that with Ansible, just not sure not sure what the syntax would be exactly.
ESPHome Device Builder Dashboard probably has something for this.
But, think about if you really want to update all of them all of the time. You really do need to read the release notes and see if the new things matter to and impact what you are doing with your devices. There is a tradeoff in how frequently you update things. The longer you wait the harder it will be. The more frequently you do it, the more likely something will go wrong.
Since I have a controlled network, I have some Tasmota devices that have not been updated in over 5 years to as much as a decade. The task they need to do hasn’t changed and they use the same protocol that they were using back then. I have a middle layer (that has changed many times) to handle the differences from the many iterations of Tasmota and esphome that I use. If you just use HA and the API in particular, you will need to keep things updated with greater frequency.
I believe the dashboard is designed to help with this, but I have not tried it yet. It is on my list for the next upgrade project.
I am not an expert but I think it may be an overkill (-;
think about if you really want to update all of them all of the time
Changing configuration also means rebuilding. If I want to change for example wifi password I need (or do I?) rebuild all my devices.
Anyway, as a software developer I love how make(1) can do the right thing after I change a single line in my project and I’d like to have the same convenience with esphome. And I prefer CLI to GUI. (I am also learning Nix and I like it too. In fact, I finally reached fro esphome because I could easily install it with nix-shell)
Ansible has a learning curve (like most things). It can also be like a hammer (if you have a hammer everything can look like a nail).
Changing the Wi-Fi password is a challenging exercise. Think at least 27 times before deciding to do that. But, yes if you want to change just about anything on the configuration of an esphome device it requires recompiling. That is the primary model for esphome (a config defined by YAML that gets converted to c++ code/config that then gets compiled into something you can flash on to a device.
It is not the only model/path available, but it is the one that standard esphome leads you to. Tasmota has a different model with most config stored in non-volatile. Initial configuration is more manual (is possible to automate) but updates could be easier since one binary can go to many devices.
One pattern isn’t necessarily better than the other in all cases, but you need to understand the differences to make a good choice (or just use the model that is default).
That is exactly what esphome does behind the scenes, but it mostly hides it from you.
esphome has a CLI (it is what I use along with VS Code).
CLIs generally assume you are an advanced user and know all the details. Getting to that level with esphome is hard, but not impossible. The docs assume you are an accomplished developer and reasonably familiar with many of the nitty gritty details on the low level architecture and code. When I first started I found it incredibly hard to figure what was the “right” way to do things. Turns out there isn’t one. There are many paths to getting something working-ish. Most of the docs are how to do something that is not very structured/sustainable. There is some discussion about patterns that can be used to make things better when you have many devices, but there are tricky bits. Since the software is under active development, the “right” way has changed a few times.
The good news is that it is all open source, so you can always “use the source (Luke)” to help you. I have done that a few times when things didn’t make sense.
Ahh, i misunderstood. I think I have done the same thing. Every now and then when something isn’t working and I want to ask a question about it here, I create a new test version of the YAML and strip out all of the unrelated code. The goal is to get the shortest test yaml that people can follow without getting sidetracked. Because it uses the same value for $deviceIP substitution, either the original or the test can be loaded into the device, and both show as Online at the same time.
One of my favourite phrases - and one I see here far too often. Particularly in the way that old timers advise newbies that you MUST do a custom install of HA in a docker container; or that MQTT is the ONLY way to communicate between HA and an ESPHome device.
100% agree. As a former programmer myself i do understand the desire to get back to adding the next feature … but as someone fairly new to this project that assumption creates a huge barrier.
One pattern isn’t necessarily better than the other in all cases
I believe I understand the difference. I use Tasmota, where I need a one off automation of a single. I know it’s more capable than that, but manual “provisioning” doesn’t feel right to me. Now that I am going to deploy some more devices esphome feels more appropriate.
Changing the Wi-Fi password is a challenging exercise. Think at least 27 times before
That was just an example.
I love how make(1) can do the right thing
That is exactly what esphome does behind the scenes, but it mostly hides it from you.
As far as I can tell esphome does it for a single device. What I am looking for here is to automate the deployment of all my devices (or groups of them).
CLIs generally assume you are an advanced user and know all the details.
I kind of feel I am not yet, bot on the other hand, I’ve used so many CLI tools, that I am not keen on learning a GUI.
Thank you very much, @neel-m and @donburch888, for sharing your knowledge. It appears the bits I am looking for aren’t (yet?) in esplhome and probably not in CLI, but you showed my how to deal with it. See you around.
on the right) or wrap your block in three backticks (```).