How to setup 20 devices with 70 sensors = 1400 sensors with templates?

Configuration
,
1

Hey all,

I’ve got 20 modbus kWh meters that I want to connect to HA. Well, I don’t need ALL sensors, but I can read-out 70 sensors per device = 1400 sensors to add to HA.
First I wanted to create one working yaml configuration, copy/paste it 20 times and find/replace the needed changes. But that takes an insane amount of time. Plus, quite frankly stupid, when you work with software.

Now I’m a rookie when it comes to HA, but i was playing with tempates in the dev tools. In it I got a tiny working proof of concept.

{% set meters = '[
{"id": 100},
{"id": 116},
{"id": 117}
]'|from_json %}

modbus: 
  - name: 100_hub
    type: tcp
    host: 192.168.0.30
    port: 502
    sensors: 
    {% for meter in meters %}
      - name: {{meter.id}} - Total system power
        unique_id: {{meter.id}}_total_system_power
        scan_interval: 5
        count: 2
        data_type: float32
        precision: 2
        address: 52
        input_type: input
        slave: {{meter.id}}
        unit_of_measurement: W
        state_class: measurement
        device_class: power
{% endfor %}

This renders what I would expect to see hard-coded in a config yaml file.

Question:
How can I implement this idea working in the configuration.yaml file?

Bonus question:
Can I conditionally !include a template from an external files and pass the variables?
This way I can add a meter type to the json object and us if/else in the yaml to load the right file. I hope to get this working, because If I have 3 types of meters I still need 3 times 70 sensors in one long template file. And this making it less human readable.

2

Using the Template Editor to generate YAML is not an uncommon usage. However you can’t paste the Jinja2 code you created directly into configuration.yaml.

On startup, Home Assistant processes YAML first, then Jinja2. Your code requires the opposite: process Jinja2 first (to generate YAML), then process the YAML.

Simply execute the Jinja2 code you have created, in the Template Editor, and copy-paste the generated YAML into the configuration.yaml file. That’s the usual way of doing it and has been suggested to others facing the same situation.

You may also wish to familiarize yourself with YAML Anchors and Aliases. It’s helps to minimize duplicated lines of YAML. Another example here.

3

You could build a script with your code above that writes the output to a file that you would !include in your configuration.yaml.

You would need a file type notify to write the file and a shell script to remove the heading lines that the file notify puts in there.

You can see an example of the script to write to a file along with the shell script using sed to remove the two lines here:
Food in the Freezer Tracker - Share your Projects! - Home Assistant Community (home-assistant.io)

4

Oh, wow… I find this almost mind boggling. I understand it’s because of the run order. But I find it hard to grasp that the only way to add entities is through hard-coding. That defies the whole logic behind software.

I mean, to pre-generate the code is a workable work around if you don’t touch it that often. The YAML Anchors and Aliases is nice when you work with a few entities. But still I would have to pre-hardcode 70 entities and then also hardcode 1330 aliases.

I guess I started with the wrong expectations. Yaml is 99% static, I expected some flexibility like SASS.
Maybe I’ll create a separate docker container that would manage my custom generator script files. At least this way I don’t need to safely store, copy/paste code “all the time”

Thanks for your answers. I’ll just mope to myself for a few days before excepting the reality :slight_smile:

5

Yes, because that’s how you must configure entities for the Modbus integration.

Many other integrations have discoverable entities so the user has no need to configure them individually.

In your case, you have an uncommonly large number of Modbus sensors so the task of configuring them is understandably non-trivial. You’re on the right track to create a script (or whatever) to generate their configuration. Whatever aspects that are shared among all sensors can be easily automated. The unique data for each sensor will, of course, have to be hard-coded somewhere (like in a dictionary) so that your script can iterate through it and customize each sensor’s configuration (name, unique_id, etc).

1 Like