Custom Templates

[Ildar_Gabdullin]

Piotr, hi.
Smth strange is happening in 2023.9.2 (may be happened earlier…)
This works:

Translated en: {{ "sun.sun" | ct_state_translated("en") }}
Translated ru: {{ "sun.sun" | ct_state_translated("ru") }}

but this does not:

Translated en: {{ ct_state_translated("sun.sun", "en") }}
Translated ru: {{ ct_state_translated("sun.sun", "ru") }}

Same for ct_translated:

Same for ct_state_attr_translated:

Also ct_all_translations - does not work:

For ct_eval - none of variants works:

---

Now the interesting part.
All this things work in Markdown:

**ct_state_translated**
State: {{ states("sun.sun") }}
Translated en: {{ ct_state_translated("sun.sun", "en") }}
Translated en: {{ "sun.sun" | ct_state_translated("en") }}
Translated ru: {{ ct_state_translated("sun.sun", "ru") }}
Translated ru: {{ "sun.sun" | ct_state_translated("ru") }}

**ct_state_attr_translated**
Attribute: {{ state_attr("automation.test", "mode") }}
Translated en: {{ ct_state_attr_translated("automation.test", "mode", "en") }}
Translated en: {{ "automation.test" | ct_state_attr_translated("mode", "en") }}
Translated ru: {{ ct_state_attr_translated("automation.test", "mode", "ru") }}
Translated u: {{ "automation.test" | ct_state_attr_translated("mode", "ru") }}

**ct_translated**
Translated en: {{ ct_translated("component.sun.entity_component._.state.below_horizon", "en") }}
Translated en: {{ "component.sun.entity_component._.state.below_horizon" | ct_translated("en") }}
Translated ru: {{ ct_translated("component.sun.entity_component._.state.below_horizon", "ru") }}
Translated ru: {{ "component.sun.entity_component._.state.below_horizon" | ct_translated("ru") }}

**ct_eval**
{% set template_text = "{{ states('sun.sun') }}" -%}
{{ ct_eval(template_text) }}
{{ template_text | ct_eval }}

I did not put a code with ct_all_translations - output is too large.

So, the plugin partly does not work in Dev tools → Template, but seems to work in Markdown.

[3_14 (Piotr Machowski)]

Please create an issue with your findings, that’s a really weird behavior

[Ildar_Gabdullin]

Some templates do not work in Dev tools -> Templates, but work in Markdown card

[3_14 (Piotr Machowski)]

Fixed in v1.2.2

[Ildar_Gabdullin]

Piotr, thank you!
Seems to be OK:

[Ildar_Gabdullin]

Piotr, any official news regarding adding your work into the Core?
Seems that this is your PR.

[3_14 (Piotr Machowski)]

Yup, it has been merged, so it should be included in HA 2024.3

[Ildar_Gabdullin]

Piotr, still using your original plugin in 2024.3 since the recently added “state_translated” function only works with a current system language. In some cases it is needed to have a translation for a different language.
Any chance the added function will allow using a different language?

[3_14 (Piotr Machowski)]

It was my first approach, but the problem was more on the architectural side - to not add additional configurations (especially yaml). A list of languages has to be known at the start of HA - to load appropriate translations to cache.

Add state_translated function to jinja templates

[SteffenDE (Steffen)]

I still using you original plugin in 2024.3 too, because there is no translation for attributes?

Please add attribute translation soon.

Thanks, Steffen

[3_14 (Piotr Machowski)]

I plan to, but wanted to add states first

[droans]

As requested, here’s a real life example for dict_merge.

For a lot of my sensor attributes, I will use a for loop to create a dictionary. Currently, that ends up involving me creating a list of items (eg, ['a',1]) and then adding that to the list. This is rather cumbersome and often ends up confusing.

Here’s the first example I found.

I use the Grocy integration to track my chores for my wife and I. I’ve added the ability to create and edit the chores in Grocy via HA along with marking chores off on an ESPHome based display.

The data itself is presented as a list of dictionaries, though. Since each dictionary has two unique items in it (the name and ID), it made more sense for the data to be arranged as a dictionary which would allow me to create automations that can quickly go through the data.

Here’s some example input data from the Grocy sensor:

[
  ...
  {
    "id": 4,
    "name": "Clean Living Room",
    "description": null,
    "period_type": "weekly",
    "period_config": "saturday",
    "period_days": 1,
    "track_date_only": true,
    "rollover": false,
    "assignment_type": "in-alphabetical-order",
    "assignment_config": "2,3",
    "next_execution_assigned_to_user_id": 2,
    "userfields": null,
    "last_tracked_time": "2024-03-23T00:00:00",
    "next_estimated_execution_time": "2024-03-30T23:59:59",
    "last_done_by": {
      "id": 3,
      "username": "monica",
      "first_name": "Monica",
      "last_name": "Carroll",
      "display_name": "Monica Carroll"
    },
    "track_count": 0,
    "next_execution_assigned_user": {
      "id": 2,
      "username": "michael",
      "first_name": "Michael",
      "last_name": "Carroll",
      "display_name": "Michael Carroll"
    }
  },
  ...
]

To change this to a dict ordered by the ID, I’m currently using:

{% set chores = state_attr('sensor.grocy_chores','chores') %}
{% set ns = namespace(chores=[]) %}
{% for chore in chores %}
  {% set tmp = [chore.get('id'), chore] %}
  {% set ns.chores = ns.chores + [tmp] %}
{% endfor %}
{{ dict.from_items(ns.chores) }}

With ct_dict_merge, I instead can use:

{% set chores = state_attr('sensor.grocy_chores','chores') %}
{% set ns = namespace(chores={}) %}
{% for chore in chores %}
  {% set tmp = {chore.get('id'): chore} %}
  {% set ns.chores = ct_dict_merge(ns.chores, tmp) %}
{% endfor %}
{{ ns.chores }}

dict.from_items is rather an anti-pattern. It requires you to remember that each item inside the list is a list of two items, the first being the key and the second being the item itself. It also does not adjust the subitems; if one key has a value which should be a nested dictionary, you need to remember to turn it into a dictionary before adding it to the list.

ct_dict_merge is more straightforward. It takes two or more dictionaries and turns them into a single dictionary. You’re always working with the correct data type and don’t need to convert them just to work with it.

If you are just combining dictionaries, you don’t need to convert the items into lists, join them, and then convert back into a dictionary. You can just merge them.

[3_14 (Piotr Machowski)]

To fix compatibility with new Home Assistant versions you have to update to the latest release. Without this update integration will not work.

Release HA 2024.5+ compatibility ·...

[Ildar_Gabdullin]

Piotr, regarding the recent changes in 1.4.1.
Could you describe “real-life” use-cases for these new features:

1. Passing variables:
   Here you provided an example:

{% set foo = "FOO" %}
{{ ct_eval("{{ foo + bar }}", variables={"bar": "BAR"}) }}

which seems to be clear, but I do not see a practical use for it…

2. parse_result (“allows to disable result parsing for internal template evaluation”) - here I am also probably too stupid to see benefits((((

I am definitely missing lot of things, so asking for ideas )))

[3_14 (Piotr Machowski)]

1. it allows you to parametrize templates used inside “eval” function. You can set it’s content once and just pass appropriate variables. You can find an example scenario here

2. I’m not really sure, but there might be some uses for that. It is a parameter of template evaluation in HA, so I have just allowed user to use it

[Ildar_Gabdullin]

@3_14

You can find an example scenario here

Well, this was my issue)).
Still thinking about a possible use for passing variables.

@3_14

It is a parameter of template evaluation in HA, so I have just allowed user to use it

Thanks! Will keep looking. I will publish here if find anything useful.

[3_14 (Piotr Machowski)]

@Ildar_Gabdullin

Well, this was my issue)).

It was late when I wrote that reply

So with variables you can do exactly the same thing - create one “inner” template that will be parametrized by these variables. You can use it a bit like jinja macros

[Ildar_Gabdullin]

OK ))) will experiment & report then!

[Ildar_Gabdullin]

“Synthetic” example of using variables:

Assume we have this decluttering template:

decl_markdown_with_calc:
  card:
    type: vertical-stack
    cards:
      - type: entities
        entities:
          - "[[SENSOR_1]]"
          - "[[SENSOR_2]]"
      - type: markdown
        content: |-
          calculation:
          {{ ct_eval("[[TEMPLATE]]", variables={'VALUE_1': states("[[SENSOR_1]]"),'VALUE_2': states("[[SENSOR_2]]")}) }}

The 1st card in the stack (“entities”) shows 2 entities, the 2nd card (“markdown”) calculates smth based on states of these entities. A particular formula is passed as an input variable:

type: custom:decluttering-card
template: decl_markdown_with_calc
variables:
  - SENSOR_1: sensor.xiaomi_cg_1_humidity
  - SENSOR_2: sensor.xiaomi_cg_2_humidity
  - TEMPLATE: "{{VALUE_1|float(0) + VALUE_2|float(0)}}"

which gives

I have not decided about a particular practical use-case; but surely this new feature can be useful for decluttering cards & blueprints.