šŸ“ 100% Templatable Lovelace Configurations

Thats awesome, appreciate the link to the Operator page as well, made a lot of sense!

I got it working on a single button with four items using:

    service_data:
      entity_id: >-
        ${vars[0] === 'Bedroom' ? 'media_player.bedroom' : vars[0] ===
        'LivingRoom' ? 'media_player.livingroom' : vars[0] === 'Kitchen' ?
        'media_player.kitchen' : 'media_player.bathroom' }
      method: Input.ContextMenu

And the logs look like its working fine :slight_smile:

I am running into an issue when ā€˜combiningā€™ the full remote and this card though - Invalid Config.

Working remote, no custom card
Non Working with custom:

It passes YAML but I dont know what the ā€˜Invalid Configurationā€™ is referring to? This card, or the stacks, or the buttons etc

If anyone could spot the issue that would be brill!

Your indentation is very wonky. This one for example:

          - hold_action: null
            action: call-service
            repeat: 100
            service: media_player.kodi_call_method
            service_data: null
            entity_id: >-
              ${vars[0] === 'Bedroom' ? 'media_player.bedroom' : vars[0] ===
              'LivingRoom' ? 'media_player.livingroom' : vars[0] === 'Kitchen' ?
              'media_player.kitchen' : 'media_player.bathroom' }
            method: Input.Up
            icon: 'mdi:arrow-up-bold-circle'
            tap_action:
              action: call-service
              service: media_player.kodi_call_method
              service_data: null
              entity_id: >-
                ${vars[0] === 'Bedroom' ? 'media_player.bedroom' : vars[0] ===
                'LivingRoom' ? 'media_player.livingroom' : vars[0] === 'Kitchen'
                ? 'media_player.kitchen' : 'media_player.bathroom' }
              method: Input.Up
              type: 'custom:button-card'

Change it to this:

          - hold_action:
              action: call-service
              repeat: 100
              service: media_player.kodi_call_method
              service_data:
                entity_id: >-
                  ${vars[0] === 'Bedroom' ? 'media_player.bedroom' : vars[0] ===
                  'LivingRoom' ? 'media_player.livingroom' : vars[0] === 'Kitchen' ?
                  'media_player.kitchen' : 'media_player.bathroom' }
                method: Input.Up
            icon: 'mdi:arrow-up-bold-circle'
            tap_action:
              action: call-service
              service: media_player.kodi_call_method
              service_data:
              entity_id: >-
                ${vars[0] === 'Bedroom' ? 'media_player.bedroom' : vars[0] ===
                'LivingRoom' ? 'media_player.livingroom' : vars[0] === 'Kitchen'
                ? 'media_player.kitchen' : 'media_player.bathroom' }
              method: Input.Up
            type: 'custom:button-card'

your hold_action criteria was not indented enough. your service_data for tap and hold was not indented enough and your type was indented too much and under the tap_action's options

Can somebody with some more experience/brain power please help me? Iā€™ve tried, but so far to no avail (and lots of time wasting).

What Iā€™m after is showing trains from leaving from certain platforms (sensor.wheretrainaā€¦) and then showing the time to train (sensor.train1ā€¦).

It would be easily achievable from a conditional card if conditions could be OR (instead of AND):

type: conditional
conditions:
  - entity: sensor.wheretraina
    state: "2114171"    
    state: "2114172"
card:
  type: entities
  entities:
    - sensor.train1

Thanks Ian for your efforts - very impressive card!

This templateable card is better at changing elements of a card. Not making the whole thing disappear (not saying it canā€™t be done, Iā€™m just not sure how).

What you could do is create a template binary sensor that is on if sensor.wheretraina is either of the states you posted. Then use that binary sensor in your conditional card.

Perfect - always now more than one way to do it!

Is there any way to get the last updated time of a sensor into this card?
Well, yes, I know you can but I want it in local time not UTC.
Is that possible?

Currently my best effort is:

card:
  type: custom:hui-entities-card
  title: "${'-- Trains from My Station (at ' + (states['sensor.next_train_to_stn'].last_updated).substr(11, 5) + ') --'}"

Which works but gives UTC.

Yes, I know that post and it is brilliant.
However this card uses javascript for the templates so I donā€™t think in this case it will help?

1 Like

not the exact same thing, but maybe a good pointer for the js script:

itā€™s on last_triggered, but maybe you can rewrite it for last_changed?

I tried, and failed :frowning:
My javascript skills werenā€™t good enoughā€¦

                - entity: sensor.abb_usage
                  name: "${'Last Update Requested' +'\xa0'.repeat(5) + Number.parseInt((new Date().getTime() - new Date(vars[10])) / 60000)+ '\xa0' + 'minutes ago'}"
                  icon: mdi:clock

Var[10]=states[ā€˜automation.update_abb_usageā€™].attributes[ā€˜last_triggeredā€™]

1 Like

Brilliant, thank you.

FWIW, I went with (but Iā€™d never have got there without your example)

title: "${'-- Trains from My Station (at ' + Date(vars[2]).substr(16, 8) + ') --'}"

What would be really nice would be to be able to style the bit in brackets to a smaller fontā€¦
No doubt ā€˜thereā€™s-a-card-for-thatā€™!!

building on Auto-entities: template lightning strikes of last hour? where I try to have the wwlln sourced lighting strikes in a card, I (think I have to) turn to the templater card to even have a chance of getting where I wantā€¦

Id love to have a Map, showing the strikes of the last hour, and since that seems not to be possible yet, (need a nifty template for that I havent yet been able to construct), I want to show the strikes within a radius of 50 km. Which is easier, because the state.state of the strikes is their distance in km.

so, Id hope the templater card do do something like

${ entities.attributes.source == 'wwlln' && entities.state < 50 }

used in the Map card.

could this be done?

  - type: conditional
    conditions:
      - entity: binary_sensor.lightning_active
        state: 'on'
    card:
      type: custom:config-template-card
      card: 
        type: custom:hui-map
        title: Lightning strikes conditional template map
        entities: `${ entities.attributes.source == 'wwlln' && entities.state < 50 }`

above wont work (and I have also tried entity.state, state.stateā€¦):

states.state:


please have a look ho to create a list of entities based on the above criteria?
thanks

1 Like

Your card creates a lot of ā€œrender_templateā€ and event websocket API requests, and by a lot I mean up to 4000 times in just a few seconds. This results in HA slowing down and/or crashing the UI due to exceeding the max number of pending http messages.

So if anyone sees something along the lines of
ā€œ[homeassistant.components.websocket_api.http.connection] Client exceeded max pending messages [2]: 512ā€, this card may be the cause of it. However, this isnā€™t the only one that could cause this. Anything that creates to many http requests could.

It doesnā€™t use the backend to render templates?

Canā€™t really say where exactly the problem lies, but I can confirm that those http requests are being made from your card. Removing it, removes those requests.

I activated the websocket debug logs, which confirmed those requests were coming from your card as well.

logger:
default: info
logs:
homeassistant.components.websocket_api: debug

Saying you removed my card doesnā€™t really mean it was my card. There are cards defined within. Off the top of my head for things I know that use the backend render are card-mod and the markdown card

sharing your configuration would help

Removing it may not necessarily mean itā€™s your card, yea, but along with all the other pointers thereā€™s almost no other possibility. Yes, card-mod and markdown card both do that, and both will cause the exact same problem if they create too many requests which can happen if you use the ā€œstyleā€ option from card-mod on too many cards. Unfortunately, I no longer have the configuration I was using while this was occurring as I was forced to remove it. Itā€™s possible that it was conflicting with card-mod which resulted in this happening.

I hope this didnt feel too personal. I just thought it was important to report this as there are a lot of integrations/plugins that unintentionally contribute to this problem without knowing. The result is a very slow running HA.

My guess would be that you didnā€™t restrict the config-template-card entities, which means it updates on every event and as you had it coupled with card-mod it was evaluating a lot of templates on the backend. The entities option should almost always be set, I really canā€™t think of a good reason that you wouldnā€™t and maybe it should just be required

Hey Ian, can you see what have I done wrong in the following template?

I expected to see a yellow image when the wind speed was 25 knots but I got green instead. I am getting blue images below 10 Knots.

- type: 'custom:config-template-card'
  entities: sensor.bom_hobart_wind_gust_kt
  variables:
    - states['sensor.bom_hobart_wind_gust_kt'].state
  card:
    type: 'custom:hui-picture-entity-card'
    entity: sensor.bom_hobart_wind_direction
    show_name: false
    show_state: false
    state_image:
      CALM: /local/icons/wind/CALM.png 
      E: "${'/local/icons/wind/' + ( vars[0] <= 10 ? 'E-blu.png' : 10 < vars[0] <= 20 ? 'E-grn.png' : 20 < vars[0] <= 30 ? 'E-yel.png' : 'E-red.png' ) }"
      ENE: "${'/local/icons/wind/' + ( vars[0] <= 10 ? 'ENE-blu.png' : 10 < vars[0] <= 20 ? 'ENE-grn.png' : 20 < vars[0] <= 30 ? 'ENE-yel.png' : 'ENE-red.png' ) }"
      ESE: "${'/local/icons/wind/' + ( vars[0] <= 10 ? 'ESE-blu.png' : 10 < vars[0] <= 20 ? 'ESE-grn.png' : 20 < vars[0] <= 30 ? 'ESE-yel.png' : 'ESE-red.png' ) }"
      'N': "${'/local/icons/wind/' + ( vars[0] <= 10 ? 'N-blu.png' : 10 < vars[0] <= 20 ? 'N-grn.png' : 20 < vars[0] <= 30 ? 'N-yel.png' : 'N-red.png' ) }"
      NE: "${'/local/icons/wind/' + ( vars[0] <= 10 ? 'NE-blu.png' : 10 < vars[0] <= 20 ? 'NE-grn.png' : 20 < vars[0] <= 30 ? 'NE-yel.png' : 'NE-red.png' ) }"
      NNE: "${'/local/icons/wind/' + ( vars[0] <= 10 ? 'NNE-blu.png' : 10 < vars[0] <= 20 ? 'NNE-grn.png' : 20 < vars[0] <= 30 ? 'NNE-yel.png' : 'NNE-red.png' ) }"
      NNW: "${'/local/icons/wind/' + ( vars[0] <= 10 ? 'NNW-blu.png' : 10 < vars[0] <= 20 ? 'NNW-grn.png' : 20 < vars[0] <= 30 ? 'NNW-yel.png' : 'NNW-red.png' ) }"
      NW: "${'/local/icons/wind/' + ( vars[0] <= 10 ? 'NW-blu.png' : 10 < vars[0] <= 20 ? 'NW-grn.png' : 20 < vars[0] <= 30 ? 'NW-yel.png' : 'NW-red.png' ) }"
      S: "${'/local/icons/wind/' + ( vars[0] <= 10 ? 'S-blu.png' : 10 < vars[0] <= 20 ? 'S-grn.png' : 20 < vars[0] <= 30 ? 'S-yel.png' : 'S-red.png' ) }"
      SE: "${'/local/icons/wind/' + ( vars[0] <= 10 ? 'SE-blu.png' : 10 < vars[0] <= 20 ? 'SE-grn.png' : 20 < vars[0] <= 30 ? 'SE-yel.png' : 'SE-red.png' ) }"
      SSE: "${'/local/icons/wind/' + ( vars[0] <= 10 ? 'SSE-blu.png' : 10 < vars[0] <= 20 ? 'SSE-grn.png' : 20 < vars[0] <= 30 ? 'SSE-yel.png' : 'SSE-red.png' ) }"
      SSW: "${'/local/icons/wind/' + ( vars[0] <= 10 ? 'SSW-blu.png' : 10 < vars[0] <= 20 ? 'SSW-grn.png' : 20 < vars[0] <= 30 ? 'SSW-yel.png' : 'SSW-red.png' ) }"
      SW: "${'/local/icons/wind/' + ( vars[0] <= 10 ? 'SW-blu.png' : 10 < vars[0] <= 20 ? 'SW-grn.png' : 20 < vars[0] <= 30 ? 'SW-yel.png' : 'SW-red.png' ) }"
      W: "${'/local/icons/wind/' + ( vars[0] <= 10 ? 'W-blu.png' : 10 < vars[0] <= 20 ? 'W-grn.png' : 20 < vars[0] <= 30 ? 'W-yel.png' : 'W-red.png' ) }"
      WNW: "${'/local/icons/wind/' + ( vars[0] <= 10 ? 'WNW-blu.png' : 10 < vars[0] <= 20 ? 'WNW-grn.png' : 20 < vars[0] <= 30 ? 'WNW-yel.png' : 'WNw-red.png' ) }"
      WSW: "${'/local/icons/wind/' + ( vars[0] <= 10 ? 'WSW-blu.png ': 10 < vars[0] <= 20 ? 'WSW-grn.png' : 20 < vars[0] <= 30 ? 'WSW-yel.png' : 'WSw-red.png' ) }"