I’m a bit puzzled by an automation that used to work so far I recall and is now spitting out weird error messages. It’s a fairly straightforward one, creating a snapshot of cameras and notifying if cameras are catching something important at night or when we’re not home.
The point of those two condition tests is to 1/ debounce the execution of this automation (if executed less than 60s ago, don’t fire again) and 2/ check if we are home or if it’s during night.
The full error messages, as seen in automation traces, are:
“Error in describing condition: Cannot use ‘in’ operator to search for ‘and’ in {{ (as_timestamp(now()) - as_timestamp( state_attr(‘automation.frigate_camera_alert_v2_2’, ‘last_triggered’), 0)) | int > 60 }}”
And I get instantly below a second one:
“Error in describing condition: Cannot use ‘in’ operator to search for ‘and’ in {{ states(‘group.homies’) == ‘not_home’ or today_at(‘00:00’) <= now() <= today_at(‘08:00’) }}”
I’m not really sure why this error message is showing up since I’m not doing any kind of IN lookup, like is “bla” contained in “blablabla”. It’s a pure simple template evaluation.
Here is the complete automation for reference:
(I use packages)
That is strange. I wonder if it’s something to do with the UI description of your YAML coding, but I pasted your automation into my UI automation editor and it didn’t have any problems with displaying it. I obviously cannot run it though.
Interesting that in the trace, the group.homies condition is showing up as the first condition.
My first test would be to start adding brackets to further reduce potential ambiguity, but it shouldn’t make a difference. Example:
To isolate the problem, I made a super-duper simple automation:
group:
homies:
name: Cool People
entities:
- person.person1
- person.person2
- id: "819913"
alias: TEST - Homies state test
triggers:
- trigger: time_pattern
minutes: "/1"
conditions:
- "{{ is_state('group.homies','home') }}"
actions:
- action: system_log.write
data:
logger: "TEST"
level: warning
message: "TESTING Group homies test {{ states('group.homies') }}"
And this one spits an error too!
It seems the behavior of a group of trackers (home/not_home) is somewhat different from what it used to be in previous versions. And when I test in the automation editor, the state of a person and the state of a group, the test of a person offers home/not_home. Still, the test of a group of person trackers visually shows this instead (unknown/unavailable):
But if I test it in the developer tab in a template with: {{ is_state('group.homies', 'not_home') }}
It renders correctly ‘true’ or ‘false’.
@123@petro any clue? I know this type of group is the “Old style group” as per the documentation, but it’s still supposed to work in manual Yaml automation. Anyway “new” groups don’t seem to handle device trackers do they?
2025-07-02 11:00:00.395 INFO (MainThread) [homeassistant.components.automation.group_test] group test: Running automation actions
2025-07-02 11:00:00.395 INFO (MainThread) [homeassistant.components.automation.group_test] group test: Executing step call service
2025-07-02 11:00:00.395 WARNING (MainThread) [TEST] TESTING Group homies test home
I think that’s normal. To work how you want it to, the UI editor would need to be able to determine what sort of group it is to give you the possible states. You can always manually type in the state to be checked against.
The group is declared within a package with the classical structure:
group:
xyz
automation:
xyz
But I think it’s related to the “old style” group. How did you declare your group? Is it through YAML config? If so in a package or through flat files? If through the UI what type are the members of the group? (because tracker isn’t offered in my UI)
Old school groups haven’t changed in years. They have been made legacy, which means no code changes.
Old school groups have never offered state options in the dropdown list either. So you’re miss remembering that. You have to manually type out home or not_home.
Ah, showing the trace, I see why it’s not working for you. You have exterior quotes on your template. Those should only exist in yaml, when you use the fromend, it should look like what I had above.
I did more tests. It’s just a visual glitch with shorthand conditions, indeed, but the automation still proceeds, which is tricky because, in some cases, this message relates to a real error.
This form gives a visual error in the automation tracer, to all conditions even if only one seems to be triggering this (the tracker group test), but the automation still proceeds:
