[Feedback wanted] How should unknown/unavailable flips affect duration-based triggers and conditions?

[nielsrowinbik]

We want to define what happens to a running duration when an entity briefly leaves its qualifying state by going to unknown or unavailable. We are looking for community input before deciding.

Take a "light turned on" trigger with a duration of 30 minutes. The intent is for the trigger to fire once the light has been on for 30 minutes. Now imagine the light to unknown or unavailable partway through the 30 minute window.

Question 1, what happens to the timer:

• Does it restart, treating the flip as the qualifying state being broken?
• Does it continue, treating the flip as a gap to ignore?

Question 2, if it continues and we ignore these flips, how long is too long? A drop of a few seconds probably should not reset the timer. A drop of several hours probably should. Where would you put the cutoff, and should it be fixed, configurable, or something else?

Please share what you would expect and the scenarios that shape your view.

[mitchellolsthoorn]

Unknown or unavailable is a technical state, not a state of intent. Therefore, I would go with option 2 (ignoring it). I do agree that there should be max. Otherwise, you might get unexpected results when an action fires when you do not expect it. Maybe we could make this threshold relative depending on the length of the duration. The length of the duration indicates the timeframe/responsiveness of an action.

For a 3-second duration, 1 minute is way too long. It would feel delayed
For a 5-minute duration, 1 minute is probably fine.

[ncodee]

I'd say option 2, and agree with what @mitchellolsthoorn said above: both are technical states rather than a change of intent, so I’d also expect the duration to continue through brief flips to these states and only reset if the gap exceeds some reasonable maximum.

Also, I think it would be clearer in the frontend to translate ‎unknown / ‎unavailable states to users as ‎offline instead. This matches the terminology with other ecosystems, and makes more sense to end‑users who don’t think in terms of internal entity states.