Template engine

[stoic apex]

Chat channel around the development of the Home Assistant template engine, which is build around Jinja2

[stoic apex]

https://tenor.com/kYvhPGrNvIl.gif

[scarlet pier]

You know where this gif is coming from ☺️?

[stoic apex]

Haha I have no ff-ing clue 😄

[kindred hedge]

The gif tab in discord

[scarlet pier]

Taxi 2 🙂
A great French comedy 😉

https://m.youtube.com/watch?v=FUExdpxhDCo&pp=ygUYVGF4aSAyIHRyYXVsZXIgc3VidGl0bGVz

I think every French teenager of my generation dreamt of this car. https://youtu.be/OArGuBHR9fY

[stoic apex]

Check, I've seen those movies 😄

[elder moat]

Is this the right spot to chat about template entity blueprints? I tried porting some of my template entities to blueprints to share, but then noticed a bunch of gaps (e.g. triggers, etc) and wanted to make sure i'm not just doing it wrong, and confirm there are some gaps we have yet to implement. (before i dive in to fill some gaps, wanted to make sure i'm not missing something)

I also know we have some plans to simplify triggers/conditions so also could pause if there is more to play out there

[scarlet pier]

Pretty sure we won’t touch the template engine at first when we will redesign the triggers and conditions. However it will allow users (and thus blueprint builders) to create more contextual triggers such as targeting all device of a specific domain / device classes in an area or a floor (or matching a label)

Things like “when a leak is detected in the first floor” or “if a window is open in the office” or “when a switch with the label always_on turns off”

[worn geode]

What gaps?

I've filled most of the gaps in the last 2 releases

Theres 2 gaps that I plan on filling:

1. trigger_variables
2. Blueprints in the UI ( no idea how to go about this yet, might just do it through config flow)

Outside those 2 gaps, template entities via blueprints seem like they are in an "decent" place. Aside from all the template entities that need to be ported over to modern style, which I'm working on

FYI, at the rate we are currently going, it's likely going to be a year or so before all platforms are fully ported to modern style because it's only Eric and I doing the work/reviewing

[elder moat]

I was trying to convert something with an action with template variables. Converting https://www.home-assistant.io/integrations/template/#trigger-based-handling-of-action-response-data to a blueprint like this https://github.com/allenporter/home-assistant-config/issues/19#issuecomment-2771261445

I think maybe its just missing template expansion for the actions

[worn geode]

what do you mean template expansion?

so that should work in the latest version of HA

Just understand that variables are executed between triggers and actions

[elder moat]

ok, i last looked two weeks ago before the last release

There are a lot of good LLM-ish things that are ready for template entity blueprints so wanted to make a bunch and share with the community

[worn geode]

Lemme double check when the PR that fixes that stuff was merged, it might be 2025.3 or .4

[worn geode]

It was merged in 2025.4

[elder moat]

i'll look out for any i run across

[worn geode]

so basically, before 2025.4 the variables section was completely ignored with trigger based template entities.

https://github.com/home-assistant/core/pull/139650

[elder moat]

As an example of the old style you're talking about like this? https://github.com/allenporter/home-assistant-config/issues/21#issue-2960806023

[worn geode]

yah, - platform: is old template styles

[elder moat]

Do you have an example PR of modernizing a platform? just could save me a minute of searching

[worn geode]

Yah

I have a few

so, let me explain a bit first

moving from legacy to modern requires 2 or 3 PRs and it depends on the platform

for example, switch only needs 2, light needs 3

the goal is to keep functionality identical between legacy, modern, and trigger style templates

so, PR1 is adding modern style

PR2 (optional) adds a base class that can be used for both trigger and non-trigger based entities

PR3 adds trigger based functionality

[elder moat]

Awesome, appreciate the "lay of the land"

[worn geode]

Light -> 3PRs
PR1: To modern -> https://github.com/home-assistant/core/pull/140326
PR2: Common Class -> https://github.com/home-assistant/core/pull/140588
PR3: Trigger based -> https://github.com/home-assistant/core/pull/140631

Switch -> 2PRs
PR1: To modern -> https://github.com/home-assistant/core/pull/140324
PR2: Trigger based -> https://github.com/home-assistant/core/pull/141763

Cover -> maybe 3 PRs??? Haven't figured that out yet.
PR1: To modern -> https://github.com/home-assistant/core/pull/141878

The hardest part about these are the tests

So, the updating to modern style takes me like 15 minutes at the moment, but the tests take 4 or 5 hours because they are all different. Every platform was added by a different person and it shows in the tests. Some of them make sense, some do not. So I've been adding common "theme" to all the tests, which is still a work in progress. I'll likely add common fixtures at some point.

Oh and last thing, if you plan to help, don't bother adding trigger functionality until this is merged -> https://github.com/home-assistant/core/pull/140660

I likely have to make changes to both switch and light trigger PRs to account for the changes in the resolution order.

last last thing, eric is on vacation and he's the only core team member who isn't afraid to review template integration PRs 🤣

[elder moat]

fantastic. that's a much richer response than i was expecting, thank you.

[worn geode]

so we are waiting for him to get back on the 27th to finalize many of these PRs

[worn geode]

I welcome the help! It's a ton of work and I keep finding more bugs and inconsistencies in each platform

[worn geode]

The main goal of the tests is so that we can easily just add an enum (ConfigurationStyle.LEGACY, MODERN, TRIGGER) as a pytest.mark.parameterize to let each test know which configuration to load. I.e. the number of tests don't increase when we add modern & trigger.

[worn geode]

@stoic apex what are your thoughts on making states() return native types in combination with an automated system (for UI entities) that makes an availability template based on update entities for the template?

[stoic apex]

I think that we shouldn't do that

as this would be extremely breaking for anything existing

I have considered it before myself as well

which resulted in my drive for the POC for an alternative syntax at the time

[worn geode]

Ok, then plan 2 would be a new method for native types and an additional property on the TemplateStates object for native types

non-native types is a major pain point in templating, anything we can do to mitigate the issue is sorely needed

[kindred hedge]

the_cooler_states()

[drowsy trench]

Or just state()? cuz it never made sense for it to be plural

[worn geode]

get out of here with your logic

but yes, I thought about that. Might be confusing though