Perplexing Macro Behavior on Group Expansion

[matthewcbyington]

Hi team,

I wrote a macro in a Jinja2 file that would return entity names from a group that are in a certain state.

I’ve noticed some weird behavior when testing this and I wanted to see if someone can point out what’s going on or if it is a bug.

When defining the list manually things work OK, but when using the macro with the same code, the “join” is splitting on each character rather than each name in the list.

I might just be looking at this for too long and there’s something obvious.

It’s also odd to me that in both cases, the first item in the list is in double quotes but the remaining are in single quotes. Is the single quote in the entity name throwing things off? Thank you in advance.

Macro:

{% macro expandToNames(groupId, candidateState) %}
    {{ expand(groupId) | selectattr('state', 'eq', candidateState) | map(attribute='name') | list }}
{% endmacro %}

[matthewcbyington]

Probably can answer my own question here. I suspect the return value of the macro was a String, not a List (even though the template developer tools said it was a list?) and that’s why I saw what I saw. Would be nice for someone to confirm or deny that but that is my hypothesis.

Matt

[code-in-progress (Bill - I write code.)]

I actually thought the same thing… I think it might have to do with the join filter? Tbh, I’m not 100% certain, but I’ve seen the join filter get weird on some of my other jinja2 projects as well.

[123 (Taras)]

Macros return strings.

You can confirm it’s not a list with this:

{{ openWindows is list }}

It will report false.

Given that it cannot return anything other than a string, simply make it return a comma-delimited string (as opposed to a string that only looks like a list).

[code-in-progress (Bill - I write code.)]

@123

Macros return strings.

Seriously? all my years using jinja2 and I’m just now learning this…

[123 (Taras)]

I’ll qualify that with “Jinja macros in Home Assistant return strings”.

[matthewcbyington]

@123 thank you kindly for spending the time to answer the question and educate me. I really appreciate it.

It’s interesting that the developer tools says the macro’s return type is a list. I will file a bug on that.

Matt

[123 (Taras)]

@matthewcbyington

the developer tools says the macro’s return type is a list

Does it show that somewhere in the screenshot you posted above?

[matthewcbyington]

@123 no, not in that original screenshot, because I added the 4 items to try to highlight the issue better.

But please see this screenshot here, where it shows as a list.

Matt

[123 (Taras)]

When you change this:
{{ openWindows }}
to this:
{{ openWindows is list }}
what does it report?

[matthewcbyington]

@123 you’re, as usual, spot on in that it says no, it’s not a list, but it is a string.

Isn’t that odd that the dev tools shows it as a list in the screenshot from my post above? Shall I file a bug on that?

[123 (Taras)]

I wouldn’t put too much stock into what the Template Editor indicates in “Result type”. It’s inferring the value’s type based on its appearance (Looks like a list, so it must be a list).

[matthewcbyington]

@123 ah, got it. Understood. I won’t file it then.

Thanks again for your help.

Matt

[123 (Taras)]

FWIW, I know of two subtle differences between how Jinja2 is handled by the Template Editor and how it’s handled elsewhere (such as in a Template Sensor). I had reported one of them; it was never resolved (I kept the issue open for a long time but eventually let it auto-close because it was clear no one was interested in fixing it).

1. According to the documentation, expand can be used as a function and a filter. The Template Editor supports both ways but when used in a Template Sensor, it only works when used as a function. Perhaps it’s been fixed now but I haven’t bothered to check.

2. If you search for entities having a specific attribute value (such as device_class: temperature), the Template Editor doesn’t oblige you to first select entities that have the attribute. However, when the same template is used in a Template Sensor, it will fail with an error (because it can’t search for an attribute value if the entity doesn’t have the attribute).

There may be others but those two stand out because they allow you to create and test a template that subsequently fails to work properly when used in a Template Trigger/Condition/Sensor/etc.

[matthewcbyington]

@123 great finds on both counts. It’s good to know that. Appreciate you informing me / us. I’ll watch out for those pitfalls. I do often use the template editor prior to creating a template sensor, so it’s good to understand the delta better.

Matt