One thing that would be great is if we could enable a notification (Push, SMS, etc) on a per sensor basis rather then creating automations for every possible combination… The concept would be to set a threshold on a sensor that when changed for X minutes it triggers a notification, and stops the notification when the threshold resumes… imagine something like an air quality monitor, or a door sensor being open for too long, or a light being on for too long etc… most of this can be done through automations but it just takes lots of duplication to make it work that way.
Should be achieveable with a Blueprint.
Can you sketch the configuration workflow you have in mind?
Your idea of having notifications set per sensor is awesome! It would be super convenient to set thresholds for each sensor, triggering notifications when there are changes for a specific duration. This could be especially handy for monitoring things like air quality, open doors for too long, or lights left on. It would make things a lot easier without the need to create tons of automations for each scenario.
Neither; just a blueprint (or two).
I suggest you work with eXtatic to develop one because it’s unlikely this FR will be implemented.
1 Like
Blueprints just create automations, this would be crazy to manage and not a best practice for anyone who has a lot of sensors.
Just think about leak sensors, smokes, power sensors, air quality, etc… blueprints are great for use one or two repeatable use cases not when it could be dozens or even more.
Blueprints are ideal for this application. Each automation produced by a blueprint contains only data. For this particular application, just the data that’s unique to each sensor. The logic remains centralized in the blueprint.
Your Feature Request effectively asks to put the logic into each integration that produces a sensor entity and store the sensor’s “notification” data in its configuration. That’s a significant architectural change, adds more data to the state machine (the opposite of the dev team’s recent efforts), and unlikely to be implemented given the goal can already be achieved via a convenient existing method.
What is wrong with one automation (mode parallel) that has all the sensors you want as triggers (give each trigger an ID), then on the condition and action sections use the trigger ID in your yaml logic? In your logic you can group the sensors etc. etc., At least it doesn’t have to be an automation for every single sensor? If you do it this way, if it makes it easier, you can have one automation for each sensor type (so you might not even need to bother with a trigger_id in the condition or action sections). Even if you find yourself rewriting the same kind of logic in the action section over and over with a certain number and type of entities (like I have), then create a script that accepts those entities as arguments and you can just call that script with the appropriate entities from the action section of a bunch of different automations as well…
I don’t think it needs to be in the state machine per-se but there needs to be some work around notifications in general… for example, mobile notifications need to be re-worked any time a device name changes… too much is left to advanced data / yaml elements etc.
The concept of adding / exposing voice services has been added to the UI for each sensor / device along with other controls, why not add some threshold logic which would trigger the alert. The alert itself could still be triggered by an automation but moving the threshold / triggering element to the sensor it self makes the workflow more natural vs a massive single automation with a ton of sub-rules or many individual automations.
My suggestion is primarily to add the logic of what the threshold would be and who to notify at the sensor level and some auto-magic message generation i.e. “Downstairs air quality has increased to 1500PPM”. or “Basement leak sensor has detected water”, or. “UPS 1 batter has decreased to 80%”
Each of those would be different threshold logic… and yes, this can all be done through automations today and thats how I do it, its just very cumbersome and discouraging to use at scale.
2 Mockups of what I mean in case I was confusing in my statements.
Post your “cumbersome and discouraging” automation(s). It’ll give eXtatic an idea of what is needed for a blueprint.