Variable ids in lambda scripts

ESPHome
1

The goal

I would like to use ESPHome to create a multi-sensor for each room, with temperature, brightness, movement, air quality, etc.
If I follow the usual instructions, the sensors are called the same (“temperature”) in all rooms, but they should be called livingroom_temperature in the livingroom device, kitchen_temperature in the kitchen device, etc. Of course, I don’t want to do this manually, so I work with substitutions.

substitutions:
  room: "livingroom"

Then I can use Ids like

sensor:
  - platform: bme680
    humidity:
      id: "${room}_humidity"
      name: "${room} Humidity"

and I just need to change the substitution in every device. Easy.

The problem

I need calculations in lambdas:

- platform: template
    name: "${room} Air Quality"
    id: "${room}_iaq"
    icon: "mdi:gauge"
    lambda: |-
      return log(id(gas_resistance).state) + 0.04 *  id(humidity).state;

I need access to the variably named sensors in the lambdas. Something like

    lambda: |-
      return log(id("${room}_gas_resistance").state) + 0.04 *  id("${room}_humidity").state;

which of course doesn’t work. I can’t access variable sensor names in lambda scripts.

The question

How can I make a device that changes its name, it sensors and calculations by a single substitution string? I already googled and searched this forum, but didn’t find a solution. I can’t believe that nobody already wanted to do the same.

2

IMHO there is no real reason to include your room names into the IDs. The IDs are internal identifiers and never visible to the outside world. Each of your nodes can use the same internal IDs.
So my proposal is:
Use the room names for your name attributes but not for your IDs.

sensor:
  - platform: bme680
    humidity:
      id: "humidity"
      name: "${room} Humidity"

lambda: |-
      return log(id(gas_resistance).state) + 0.04 *  id(humidity).state;
2 Likes
3

But I think if they all have the id “sensor.humidity”, HomeAssistant will rename them sensor.humidity2, sensor.humidity3 and so on. That’s a mess in using them, especially in scripts and automations. I have lots of sensors and they are getting more every day. :wink:

Bildschirmfoto 2024-01-02 um 23.09.15
Bildschirmfoto 2024-01-02 um 23.09.15884×214 31 KB

Bildschirmfoto 2024-01-02 um 23.02.36
Bildschirmfoto 2024-01-02 um 23.02.36906×874 47.4 KB

4

Nope. You are talking about the entity_id in Home Assistant. That is not the same as the id attribute in ESPhome.
The entity_id is derived from the (friendly) name in ESPhome, not from the id.
So your entities in HA will have entity_ids containing the room name if you follow my advice.

Example:

switch:
  - platform: template
    name: "${my_friendly_name}, Rauch simulieren"
    id: switch_simulate_alarm
    icon: mdi:test-tube
    optimistic: true

… creates this entity in HA…

1000020372
10000203721080×884 44.6 KB

1 Like
5

Really? That’s great, thank you.

That’s what I’m missing in HomeAssistant: an in depth documentation about all the internal stuff, how things really work, about the database, etc. And a guide on how to name devices and sensors syntactically and practically. Sometimes I think I should delete everything and start from the beginning with the knowledge I have now. :wink:

1 Like
6

I’ve managed to get the id from id(hmi_power_1).get_object_id()
Docs here

7

Looking at the code this does not return the internal id (as defined by “id: …”) but something related to the friendly name. Most likely it returns exactly the entity id as seen in Home Assistant.

8

I thought it was the esphome id: (as in the yaml) but it seems to be the “friendlied” name: instead (lower case, _ for spaces etc)
Shame, as I really wanted the esphome id:

9

I don’t really get what you are looking for.
The ESPhome id of that component is simply “hmi_power_1”.

10

I have a number of sensors in an array and I want to iterate them in a lambda retrieving the id, name and state for each.
I’ve resorted to a map where the key is the id and iterate that.
Hope this makes sense.

11

Ah, got it. Now it makes sense. Thanks!