It would be great to have a native field to utilize for a hysteresis parameters when using the numeric trigger for automations. I see most users are utilizing the threshold sensor as a work around.
You could do two separate numeric_state triggers, one for above and one for below.
I’m not sure that would accomplish what I’m after. I’m wanting a deadband setpoint. Say I’m monitoring humidity greater than 70% and I want a hysteresis of 5. I should not receive another high humidity notification unless it has dropped below 65% then climbed to trigger my 70% threshold again.
You can achieve your goal with a input Boolean used as memory and 2 automations.
First Automation:
Trigger: Humidity> 70%
Condition: Memory = FALSE
Action: Notification + Set Memory to TRUE
SecondA Automation:
Trigger: Umidity <65%
Action: Set Memory to FALSE
1 Like
And you can create a Boolean as a threshold sensor and have one automation. The nature of my request is to integrate this all into the numeric trigger so it’s factory.
3 Likes
Much later… having the same problem.
It sounds very simple for the logic, but quite complicated workaround.
I have an idea how this could be implemented in a generic way.
It would be nice to have a section similar to trigger, but as an “arming” for the actual trigger. Or think about it like a 2 stage trigger.
Whether it should be called “arming”, or “pre-trigger”, I don’t know (or care 
)
The logic would be: the pre-trigger (stage 1) is just enabling the normal trigger (stage 2).
This way one can implement time hysteresis (e.g. a device must be off a certain duration before allowing turning on again), or numerical hysteresis like you wanted here…