Config-template-card not updating?

I am trying to build a Lovelace Card that will display a Gauge (to match the style of others in the Dashboard) with a sensor value in the name: field. Unfortunately my attempts are not going very well :cry:.
If I place one sensor in a Gauge Card and the other in an Entity Card they both update fine.
But if I put the two sensors in a config-template-card card as shown (on left) below, the updates stop after about an hour. I can force an update by refreshing the web page. Swapping browsers (gecko/blink engines) make no difference. Clicking and examining the “age” in the config-template-card is MUCH older than the age in the Entity Card.


Note, that the values are synced in the above image but that is because I have been re-drawing to compose this question.

… and this is my effort at the config-template-card:

type: custom:config-template-card
variables:
  - states['sensor.my_battery_state'].state
  - states['sensor.givtcp_dy2216g525_battery_soc'].state
entities:
  - entity: sensor.my_battery_state
  - entity: sensor.givtcp_dy2216g525_battery_soc
card:
  type: gauge
  entity: sensor.givtcp_dy2216g525_battery_soc
  name: ${ states['sensor.my_battery_state'].state }
  severity:
    green: 50
    yellow: 20
    red: 0
  needle: true
  min: 0
  max: 100
  card_mod:
    style: |
      .name {
         font-size: 50px !important;
         }

Three question:

  1. Should the config-template-card update when the referenced sensors change?
  2. Is my .yaml code correct? (most likely error)
  3. Is there another way to achieve the look that I’m after?

Regards, Martin

you only need variables if you plan to use them (you aren’t using them). Second, your template isn’t in quotes. You need to use quotes for single line templates in yaml or you need to use multiline yaml notation.

Besides, placing Gauge card into config-template-card will cause a needle to reset on every update (unless you do prefer this animation - as you said in another your similar thread).
As for “another way” - already explained you in details where to get an auto-entities-based solution.
In case you keep digging into config-template-card - suggest to use the main dedicated thread instead of creating new similar threads.

that is not the case here, this works alright.

          - type: custom:config-template-card
            entities:
              - input_number.history_span
              - input_select.domain
            variables:
              span: states['input_number.history_span'].state
              domain: states['input_select.domain'].state
            card:
              type: custom:auto-entities
              card:
                type: history-graph
                hours_to_show: ${span}
              filter:
                include:
                  - domain: ${domain}
2 Likes

Thanks for clarification, been a while since I’ve used this card.

well I was surprised too as it’s not what is documented

Hmmm, placing AE into CTC…

Will be documented. There are some PRs in progress.

I guess it was safe, as those variables only change every now and then, and are not sensor entities of temperature or power…

btw, I do believe we can do the same in core automations and scripts. I had all templates on multiline , but theFes showed me it wasnt required at all times (need to find the example…)

Interesting , would like to see these examples. Using multiline myself.

we’d need to ask him again, I cant find it anymore, believe it was in Discord

anyways, this works:

  test_cloud_say_label_singleline:
    mode: restart
    sequence:
      - action: tts.cloud_say #tts.google_say
        data:
          cache: false
          language: >
            {{states('sensor.tts_taal')}}
          entity_id: >
            {{label_entities('alarm_speler')}}
          message:  dit is een test over {{label_entities('alarm_speler')}}

but the language and entity_id need the quotes or the multiline

it’s probably as with using the *.
when a line starts with that *, we need the quote, if characters precede it, we dont (see decluttering card, auto-entities, but also customize (globs)

Yes, here quotes are not needed since the value starts with a string.

Sorry, I don’t understand!
Or are you “talking” amoung yourselves over my head?

Rehards, M.

not entirely…
I gave you the correct syntax for using variables above in a working config.

this is a working example for your search in the gauge:

type: custom:config-template-card
entities:
  - entity: sensor.my_battery_state
variables:
  state_as_name: >
    states['sensor.my_battery_state'].state
card:
  type: gauge
  entity: sensor.my_battery_sensor_battery
  name: ${ state_as_name }
  severity:
    green: 50
    yellow: 20
    red: 0
  needle: true
  min: 0
  max: 100

so the order of things:

  • list the entity/entities you want the card to update on: in this config sensor.my_battery_state
  • create a variable based on any of those entities: in this case the variable state_as_name
  • use that variable in the config: by using ${ state_as_name }

as Petro said, do the above only for entities you use. Its no use creating a variable if you dont use it in the config

btw, a little trick, since you are already using card_mod in the styling:

  • use an empty name,
  • create a ‘pseudo class’ and
  • inject a jinja template :wink:
type: gauge
entity: sensor.my_battery_sensor_battery
name: ''
severity:
  green: 50
  yellow: 20
  red: 0
needle: true
min: 0
max: 100
card_mod:
  style: |
    .name {
      color: green !important;
      font-size: 35px !important;
    }
    .name::before {
      content: "{{state_translated('sensor.my_battery_state')}}";
    }

No need for config-template-card
(note that in this case the quotes around the template

content: "{{state_translated('sensor.achter_deur_node_status')}}";

are required, and can not be replaced by multi-line notation either. (has to do with the way card-mod processes the modification)

Thank you very much Marius,
I shall be marking your last post as a solution but I wanted to say that I really appreciated your (and others) help and the “little trick”. It makes the code so much cleaner and readable for me. And I can remove the config-template-card package from my system.
Apologies for not responding sooner but I wanted to watch for a good 24 hours and (of course) it is working flawlessly.

Regards, M.

1 Like