Does custome cards (like auto-entities) can combine a template with a hold_action?

Configuration Frontend
1

My journey of this problem started with a combination of naming convention, syntax, indentation and a non-working tab_action. After a lot of more reading my last question is:

“Can I combine in a card a template with the hold_action”

But it started with:

I am looking for a card where tabbing will perform a specific action. I found custom card “auto-entities” but I do not get it to work. Hopefully I am using the new correct syntax due to the replaced ‘call-service’.

f.y.i I simplified my problem to settings which most likely can be found in 99% of all HA-configurations (only change of the entity_id is likely required or change line into ‘entity_id: this.entity_id’').

type: custom:auto-entities
card:
  type: glance
filter:
  include:
    - options:
        hold_action:
          action: light.turn_on
          target:
            entity_id: light.voorkamer
          confirmation:
            text: Is this working?
      domain: light

Confirmation tells me I do go inside the hold_action. What am I doing wrong? Is it still the syntax or should my starting point nowadays be a different card? Help appriciated.

2

The purpose of the auto-entities card is that you set it up to filter a specific subset of entities based on your criteria, e.g. all light entities that are currently reported as being on.
As soon as a light turns off it will not show up in the card any more - see the example from the card’s documentation:

type: custom:auto-entities
show_empty: false
card:
  type: glance
  title: Lights on
filter:
  include:
    - domain: light
      state: "on" # Remember that "on" and "off" are magic in yaml, and must always be quoted
      options:
        tap_action:
          action: toggle

If you tap on one of the entities shown in the card it will turn off - and disappear from the card until it’s turned back on again.

What you’re trying to do - at least that’s what it seems to me with the limited information you’re providing with your simplified problem - is to show a specific entity in a glance card and turn it on when you tap & hold the icon.

Although one might be able to make it work, this is not a problem for the auto-entities card.

I don’t have a working example for a ‘hold_action with a confirmation’ but take a look at this simple example of a glance card:

type: glance
entities:
  - entity: cover.shutter_office
    name: Office
    double_tap_action:
      action: call-service
      service: cover.open_cover
      service_data:
        entity_id: cover.shutter_office
    hold_action:
      action: call-service
      service: cover.close_cover
      service_data:
        entity_id: cover.shutter_office
3

Thanks for this answer, your answer did not give straight away the solution but forced me to examine possibilities even further.

So far it looks that the hold_action is more responsive than the tab_action. The tab_action is still going to to the logbook details. I also prefer the hold_action because you can make a more deliberate and visible decision.

I moved away from a direct action to a script because a script can show me traces of what I am doing (wrong). Also I needed either a partial entity_id (“{{ entity_id[-20:-8] }}”) or the attribute.public_key. But I failed to do that directly (or not and it is too much invisible because the action is performed on the device of the integration). Isn’t the devil is in the syntax detail?

So these problems are tackled but the last problem is that I want to use a template because my selection is more complex than what is possible with the standard include section. Got this template working but the tab_action looks like a part of the empty include section and does not do anything more. So the question arise how do I integrate it with the template?

hold_action is working tab_action not (do not mind this minor problem)

type: custom:auto-entities
card: null
filter:
  include:
    - options:
        hold_action:
          action: call-service
          service: script.meshcore_remove_contact_script
          service_data:
            entity_id: this.entity_id
        tab_action:
          action: call-service
          service: script.meshcore_remove_contact_script
          service_data:
            entity_id: this.entity_id
      integration: 01K1JG8Z9Q0CF1YPW759T2QSXS
      state: stale
      attributes:
        type: 3
sort:
  reverse: true

With a more complex selection in a template but how to get the hold_action back to work?

type: custom:auto-entities
card: null
filter:
  include:
    - options:
        hold_action:
          action: call-service
          service: script.meshcore_remove_contact_script
          service_data:
            entity_id: this.entity_id
  template: >-
    {% set tijd = now() | as_timestamp | int %}  {% set type =
    states['input_select.meshcore_contact_type'].state[:1] |  int %}  {% set
    days_old = states['input_number.meshcore_days_old'].state |  int %}

    {{ states.binary_sensor 
      | selectattr('entity_id', 'search', 'meshcore_') 
      | selectattr('entity_id', 'search', '_contact') 
      | selectattr('state', 'eq', 'stale')
      | selectattr('attributes.type', 'eq', type ) 
      | selectattr('attributes.lastmod', 'lt', tijd - days_old*60*60*24) 
      | map(attribute='entity_id') | list 
    }}

The simplified version of the use of a template in a card is given in examples like (which can be copied in a empty card, working effect is better after dark).


type: custom:auto-entities
card:
  type: entities
filter:
  template: "{{states.light 
  | selectattr('state', '==', 'on') 
  | map(attribute='entity_id') | list}}"

So does anyone know how to can this be extended with a hold_action?

4

There might be your issue with reliability of the tab_action => tap_action

Yup!

Sorry, can’t help you much on the other stuff - just not good at templating :frowning:

5

The whole point “Does custome card auto-entities still work with the new ‘call-service’?” is incorrect since the auto-entities card simply passes a list of data into a defined card (entities in Entities card, cards into Horizontal stack card, …).

6

I fully agree, this was the beginning of my journey where cards still talk about " "action: call-service" and in automation this is renamed into “Perform Action”:

image
image940×400 12.2 KB

This in combination with the badly working “tab_action” made me jump to a wrong conclusion. Will adjust the question but if you know this answer feel free to share.

7

check out this :arrow_down:

8

Thanks for the suggestion, on second thought and reading the instructions of this card more carefully, I read it was a wrapper and the wrapped card takes care of the selection, and the card itself for the action:

  • So far, so good :+1:
  • It is working with the card “auto-entities” :+1:
  • Both versions (include and template) can be used :+1:
  • The tab_, hold_ and double_tab_action are separate from selection :+1:

Promising but the selection of the auto-entities card will not be a single selection and it looks like that at the moment it is impossible to pass a flexible entity_id in the service_data like "entity_id: this.entity_id"

If this was possible it is the solution I am looking for.

9

It is possible.

1 Like
10

So you say it is possible but could you please explain why the following combination is not working as desired:

type: custom:actions-card
card:
  type: custom:auto-entities
  card:
    type: entities
  filter:
    include:
      - options: {}
        domain: light
    exclude: []
tap_action:
  action: toggle
hold_action:
  action: toggle
double_tap_action:
  action: toggle
prevent_default_dialog: false

And yes it is a simplified version of my problem not covering the template and pass an entity_id to the service_data.

11

The question was about auto-entities card, but you are showing some different card.

12

Again agree, but not fully because the question contains the like, but English is not my native language and this topic is my journey to find a card which can handle a template combined with a hold_action. Any help is welcome, even statements like “It is possible” but perhaps it is time now you extend the given example with a working hold_action. It would be much appreciated.

And for argument sake yes this template can be replaced with the standard include section and the hold_action will work. But looking for a template variant. Pick up the challenge (and make your words com true).

13

Sorry, away from a PC, cannot give an example. The “this.enyity_id” variable which you asked should be used for an INNER card which is filled by auto-entities. But in your example with that action-card you asked about actions for a card which CONTAINS the auto-entities.

14

You can skip to the end.

To be honest you more confused me than helped me :wink:. The action-card does not look to give added value for cards who already have the ‘hold_action’ in their ‘tool-set’ so for me that was already a past station.

I hope to get some guidance how to to extend the template with a hold_action because the normal location as option inside include did not work.

I found my solution inside in the official topic Auto-entities - Automatically fill cards with entities. In the six years and over 1800 comments I found the desired solution in record #853 but first I required a more simplified example which would open doors for me, this was found in #893. Unluckily this person published a picture over preformatted text and I needed to deploy my 2 fingers typing skills (yes, another :wink:).

After all this I think I may not forget to publish my solution:

type: custom:auto-entities
show empty: false
card:
  type: entities
  title: Open Doors
filter:
  template: |-
    {% set DEVICES = states.binary_sensor
      | selectattr('attributes.device_class', 'eq', 'door' )
      | selectattr('state', 'eq', 'on' )
      | list  
    %}  
    {% if DEVICES | length > 0 %}
      [
      {% for DEVICE in DEVICES -%}
        {{{
          'entity': DEVICE.entity_id,
          'name': area_name(DEVICE.entity_id),
          'secondary_info': 'last-updated',
          'hold_action': {
            'action':'call-service',
            'service' : 'script.open_door',
            'service_data' : { 'entity_id' : DEVICE.entity_id }}
        }}},
      {% endfor %}
      ]
    {% endif %}

Two observations:

  1. I prefer the hold_action because it is a more distinct and visible action
  2. A script has traces which will help you to examine potential problems.