-
|
I am not sure if this is an issue yet, so I wanted to ask here first. Is anyone else having an issue with I have been using a text sensor as my alert tracker and as of recently, I think And with/without the then it works, but that seems inefficient and also incorrect for how the Happy to move this over to issues if it's truly that, but perhaps I've misconfigured something. I'm on the following versions: |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
|
Hi! This is caused by a behaviour change introduced in v1.3.2.5 — and your config is hitting it directly. What changed in v1.3.2.5 Before v1.3.2.5, on_change: true fired on any state change and completely ignored state / operator. Those fields were silently skipped in the on_change path. In v1.3.2.5, state + operator were made to act as a current-state filter: the alert still fires on any change, but is only displayed while the entity is actually in the declared state. This fixed a real use-case (#83) but broke configs that relied on the old "ignore state in on_change mode" behaviour. Why your config stops working
Fix — remove the state filter if you just want any change: alerts:
alerts:
Sorry for the disruption — I'll add a note to the docs to clarify this behaviour. |
Beta Was this translation helpful? Give feedback.
Hi! This is caused by a behaviour change introduced in v1.3.2.5 — and your config is hitting it directly.
What changed in v1.3.2.5
Before v1.3.2.5, on_change: true fired on any state change and completely ignored state / operator. Those fields were silently skipped in the on_change path.
In v1.3.2.5, state + operator were made to act as a current-state filter: the alert still fires on any change, but is only displayed while the entity is actually in the declared state. This fixed a real use-case (#83) but broke configs that relied on the old "ignore state in on_change mode" behaviour.
Why your config stops working
operator: "="
state: on # ← this is the liter…