Posting this in case it saves someone else the days of debugging it cost me — not asking anyone to fix it, just flagging a genuinely confusing gotcha.
My automations occasionally lose the native Python type (datetime, float) of a value computed in one variables: step when it’s referenced by a later step or condition in the same run. The value sometimes comes back as its string representation instead of the actual object, even though the template is a single {{ }} expression that should qualify for native-type rendering.
This caused two real, hard-to-diagnose bugs for me: (1) a condition: template doing now() < some_computed_datetime intermittently threw TypeError: '<' not supported between instances of 'datetime.datetime' and 'str'. Because a condition that errors inside a choose: block seems to get treated as false rather than surfacing visibly, my automation silently fell through to the wrong branch — it looked exactly like a bug in my own YAML logic, and took days of trace-history digging to pin down. (2) A similar issue with a computed number caused TypeError: can't multiply sequence by non-int of type 'float' a few steps later, once I’d worked around the first one.
The workaround: explicitly re-cast every reused variable with as_timestamp() (dates) or | float (numbers) at the point of use, rather than trusting the type to survive the handoff between steps.
Running 2026.9.0. Curious if anyone else has run into this, or knows the actual mechanism behind the type loss.