Only first template sensor using state_attr gets defined, the rest gets ignored

jprates · December 22, 2024, 1:03pm

OK, so I’m probably going mad, but bear with me… among many others already existing template sensors I added a few using state_attr, something I had none so far:

  - name: "Estado termostato cozinha"
    unique_id: "hvac_action_cozinha"
    state: >
      "{{ state_attr('climate.cozinha_termostato', 'hvac_action') }}"

  - name: "Estado termostato sala AV"
    unique_id: "hvac_action_sala_av"
    state: >
      "{{ state_attr('climate.sala_av_termostato', 'hvac_action') }}"

After the hvac_action_sala_av I have a few more, all following the same logic.

The problem I’m facing is that only the first sensor, the hvac_action_cozinha appears available on HASS, all others remain unknown. Why on earth???

I have copied all value strings and pasted them into developer tools, and they all return the correct hvac_action values, so I’m sure the state_attr used are correct and with no typos.

And before anyone asks, yes, I’ve disabled all custom integrations and it did not help, it’s not integration related.

Any idea of what is going on?

Thanks in advance.

Core 2024.12.5
Supervisor 2024.12.0
Operating System 14.1
Frontend 20241127.8

mirekmal · December 22, 2024, 1:26pm

You should use value_template: instead of state:. Also you do not need double quotes around template if not in line, but using >.

  - name: "Estado termostato cozinha"
    unique_id: "hvac_action_cozinha"
    value_template: >
      {{ state_attr('climate.cozinha_termostato', 'hvac_action') }}

  - name: "Estado termostato sala AV"
    unique_id: "hvac_action_sala_av"
    value_template: >
      {{ state_attr('climate.sala_av_termostato', 'hvac_action') }}

jprates · December 22, 2024, 1:48pm

I probably should have added some more background.
From my configuration.yaml:

template:      !include template.yaml

The template.yaml starts with sensor:

sensor:
  # producao para diagrama de energia tesla-style, ignora carregamento de bateria da rede
  - name: "pv_producao_global_w"
    unique_id: "pv_producao_global_w"
    unit_of_measurement: "W"
    state: >
      {%set mylist = states('sensor.upac_electric_consumption_w')  | float,
                     0 | float %}
      {{ mylist | max }}

I have literally several dozens of template sensors in there, all using “state”.
Moreover, if I try to change it to template_value…

  - name: "Estado termostato cozinha"
    unique_id: "hvac_action_cozinha"
    value_template: >
      {{ state_attr('climate.cozinha_termostato', 'hvac_action') }}

… since I’m already in the template section, I get:

Invalid config for 'template' at template.yaml, line 813: required key 'state' not provided Invalid config for 'template' at template.yaml, line 815: 'value_template' is an invalid option for 'template', check: sensor->83->value_template

On the double quotes, yeah, I know, I don’t use them anywhere in the template.yaml, they are there as one of my desperate tries to get around this issue, I just forgot to remove them before posting, but they are harmless.

tom_l · December 22, 2024, 2:09pm

No they should not. This is the new template integration, not the legacy template sensor platform.

You do not need to use that filter there. 0 is already a number. And that is not a list. This is a list:

{% set mylist = [states('sensor.upac_electric_consumption_w')  | float, 0] %}

You are going to have to post the whole template.yaml file for us to spot the issue.

jprates · December 22, 2024, 2:29pm

Hi @tom_l , thanks a lot for chiming in!

Old habits from programming too many languages with distinct behaviours, one can never be sure if 0 will not be interpreted as an int, so this way I make sure it’s a float, or so I hope eheheh.

All I can tell you is that it works

I really don’t take any pleasure of disagreeing with you of all people, but I really don’t see the point in sharing the file contents.

All sensors on that file are working fine, the only ones not working are the ones added today which use state_attr, the exception being that the first one works, for whatever reason.

So the issue is localized on these last sensors, which all look alike.
Here’s the last sensors on file:

  - name: "custo_mensal_wb_poente_lts"
    unique_id: "custo_mensal_wb_poente_lts"
    device_class: monetary
    state_class: total
    unit_of_measurement: "Eur"
    state: >
       {{ states('input_number.custo_mensal_wb_poente') | float | round(2) }}

  ## estado dos termostatos

  - name: "Estado termostato cozinha"
    unique_id: "hvac_action_cozinha"
    state: >
      "{{ state_attr('climate.cozinha_termostato', 'hvac_action') }}"

  - name: "Estado termostato sala AV"
    unique_id: "hvac_action_sala_av"
    state: >
      "{{ state_attr('climate.sala_av_termostato', 'hvac_action') }}"

  - name: "Estado termostato escritorio"
    unique_id: "hvac_action_escritorio"
    state: >
      "{{ state_attr('climate.escritorio_termostato', 'hvac_action') }}"

  - name: "Estado termostato sala amarela"
    unique_id: "hvac_action_sala_amarela"
    state: >
      "{{ state_attr('climate.sala_amarela_termostato', 'hvac_action') }}"

  - name: "Estado termostato wc visitas"
    unique_id: "hvac_action_wc_visitas"
    state: >
      "{{ state_attr('climate.wc_visitas_termostato', 'hvac_action') }}"

  - name: "Estado termostato quarto Alex"
    unique_id: "hvac_action_quarto_alex"
    state: >
      "{{ state_attr('climate.quarto_alex_termostato', 'hvac_action') }}"

  - name: "Estado termostato wc miudas"
    unique_id: "hvac_action_wc_miudas"
    state: >
      "{{ state_attr('climate.wc_miudas_termostato', 'hvac_action') }}"

  - name: "Estado termostato quarto Cati"
    unique_id: "hvac_action_quarto_cati"
    state: >
      "{{ state_attr('climate.quarto_cati_termostato', 'hvac_action') }}"

  - name: "Estado termostato corredor"
    unique_id: "hvac_action_corredor"
    state: >
      "{{ state_attr('climate.corredor_termostato', 'hvac_action') }}"

  - name: "Estado termostato suite"
    unique_id: "hvac_action_suite"
    state: >
      "{{ state_attr('climate.suite_termostato', 'hvac_action') }}"

  - name: "Estado termostato quarto vestir"
    unique_id: "hvac_action_quarto_vestir"
    state: >
      "{{ state_attr('climate.quarto_vestir_termostato', 'hvac_action') }}"

  - name: "Estado termostato wc suite"
    unique_id: "hvac_action_wc_suite"
    state: >
      "{{ state_attr('climate.wc_suite_termostato', 'hvac_action') }}"

I’ve included the last one before the new section, the custo_mensal_wb_poente_lts so everyone can see what’s immediately before the new section.

This custo_mensal_wb_poente_lts sensor works fine as do every single sensor before it, and then in the new hvac section only the first one ( hvac_action_cozinha) works, all the others following are ignored and get unknown inside HASS.

tom_l · December 22, 2024, 2:39pm

Because I can’t see anything wrong with the snippets you provided. I still can’t. Though what you have now provided is sufficient, as long as nothing was cut out between the working and not working sensors.

Perhaps you have a hidden tab instead of a space in there somewhere?

Anything in your logs that might help?

Have you confirmed in Developer Tools → States that all these attributes exist?

tom_l · December 22, 2024, 2:44pm

For a moment I thought this might be the issue

It could be interpreted as being part of the template above. Use {# #} for comments in templates.

But that would mess up a sensor you say is working. So unlikely to be the issue.

tom_l · December 22, 2024, 2:45pm

Oh. I see it.

Remove the quotes from around your mult-line templates. Only quote single line templates.

Like so:

  - name: "Estado termostato cozinha"
    unique_id: "hvac_action_cozinha"
    state: >
      {{ state_attr('climate.cozinha_termostato', 'hvac_action') }}

Or like so:

  - name: "Estado termostato cozinha"
    unique_id: "hvac_action_cozinha"
    state: "{{ state_attr('climate.cozinha_termostato', 'hvac_action') }}"

jprates · December 22, 2024, 8:14pm

Nope, it was not that.

After spending an entire afternoon chasing the issue, I finally understand what is going on, the only thing I do NOT understand is how did we get here!

Take a look:

Somehow the Template integration decided that from the second sensor on, it would disregard my unique_id string, and would create its own from the sensor’s name.

Reloading the template.yaml file over and over again, change after change, try after try, did not change these Entity IDs, hence all efforts on our part were useless.

Now I’m trying to delete all of those entities and create them all over again, this time I’ll put the name=EntityID and see if it goes smoothly.

Then again… this seems like a catch 22 situation… chasing my own tail…

Any ideas of how to clean this mess?

jprates · December 22, 2024, 8:37pm

So, removed all sensors from template.yaml, restarted HASS, then I was able to delete the entities.

Put them back on template.yaml, restarted once again, and now all is ok:

Maybe I misunderstood the way templates work, in particular what “name” and “unique id” are intended for?

I was under the impression that the “name” was for a friendly name, just a string with no use at all, while the “unique id” was for us to define the entity name/suffix.

Anyhow it does not make sense to take one approach for the first sensor and a different one for the rest, it seems like a bug to me.

tom_l · December 22, 2024, 10:43pm

It was certainly part of it.

The template integration always uses the name to generate the entity_id. It has nothing to do with the unique_id. That is a separate thing altogether.

The unique_id is only for tracking the entity in the entity registry. It actually allows you to change the entity_id manually in the frontend (among other things).

Make sure you fix your other issues too. e.g. Not a list. No need to filter number to numbers, and quoting multi-line templates.

jprates · December 23, 2024, 12:31pm

I struggled in deciding if I should or should not reply, and hopping you don’t take offense, just for the sake of clarifying, here it goes:

I’m not sure, but I’ll take your word here.
In truth I did not see any difference in results, either with or without quotes.

I stand corrected!
Thanks a lot for clarifying that, I was with the wrong idea since ever.
The fact that 99.9% of time I use the same on both did not help notice the difference sooner.

However, it still does not explain the different behaviour for the first definition, where it used the unique_it its name. Let me remind you the template definition:

- name: "Estado termostato cozinha"
    unique_id: "hvac_action_cozinha"
    state: >
      "{{ state_attr('climate.cozinha_termostato', 'hvac_action') }}"

  - name: "Estado termostato sala AV"
    unique_id: "hvac_action_sala_av"
    state: >
      "{{ state_attr('climate.sala_av_termostato', 'hvac_action') }}"

Now look again at the template editor snip and you’ll see it knew sensor.hvac.action.cozinha, which looking at the definition above should be named sensor.estado_termostato_cozinha. Something went wrong there, and from that point on I was always trying to access sensor.hvac_action_something with no sucess.
Unfortunately none of us did notice (or knew in my case) I was using the wrong name.

And this is where we go apart.
There are no other issues, or better said, I’m sure there are, but not these ones you mention. Let me clarify in more detail:

Can you then clarify why it works either way?

When one wants to make sure you get a float (explicit decimal part), not an int, it’s the best way I know.
And the results speak for themselves, the result is not the same:

That’s a wrap from here, major solution/issue was that I was using the wrong sensor names from a misconception that sensor names came from unique_id.

Hope it helps others that eventually come here with the same problem.

Merry xmas everyone, and once again thanks to @mirekmal for trying to help, and specially to @tom_l that effectively explained why my code was not working.

tom_l · December 23, 2024, 1:36pm

It’s your system. If you don’t want to fix it that’s up to you.

jprates · December 23, 2024, 2:31pm

That was uncalled for.
I was genuinely asking in an attempt to learn, and I did give you credit where credit was due IMHO.

tom_l · December 23, 2024, 2:36pm

All I can do is tell you where you have made mistakes. I can’t force you to fix them as you seem to be unwilling to accept the advice. I have better things to do.