If value changes by x or % or range to trigger routine

@nayelyz @jody.albritton can you tag the app product manager

An idea for automation routine triggers, if the value of an attribute changes by an absolutely number or by a percentage or if enters a range (not trigger again unless it exits the range)

For example

  • if the power level changes by 5% or by 50W
  • If lux is between 100-500

Etc

Essentially any attribute that supports a numeric range could use this automation as a trigger making for very powerful rules.

Things like the dehumidifier, fridge or ac kicked on or turned off based on changes in power consumption. If a static reference, example if dehumidifier power consumption is >100W, but the issue is that even a slight change in the value (eg 101W) will trigger the routine, which isn’t the intended behavior. The a range comparison or threshold change in value is a powerful automation rule.

2 Likes

Hi @RBoy
I wanted to let you know that this has now been officially passed along to the Product team.

1 Like

It’s an interesting topic because natural language is powerful but translating changes by to a rule / driver / code is not as easy.

While the simplest approach would be to just compare a new power report value to the previous one and if it’s 5% or 50 W more trigger the automation, that may work only for devices where power is constant over time, in many others it usually fluctuates a lot.

To do it right you need to look at averages or tendencies and that requires a time window and keeping a history plus fine tuning the parameters for the device in question to avoid false positives / negatives. In Home Assistant for instance they have two helpers, the Threshold and the Derivative.

There’s another problem with relying on changes and hence past values to trigger an automation: makes the automation stateful and less reliable. If the past values are lost because the driver restarted or there was an outage, the automation may not run when it should. If it’s a stateless automation based on the current power value you know it will run the next time a power report is received.

2 Likes

Yes, % changes can be tricky - I’ve seen some devices implement it.

However using a range is very straightforward. If the attribute enters a range then trigger and don’t retrigger until it exits and reenters the range.

There’s already a Range in the automation starters for numeric values, I’ve never used it but I would expect to only trigger once when entering the range and not retrigger while it’s in the range.

Edit: Just tested it with the brightness of a light, works as expected, runs once when entering the range and not anymore unless you exit the range and enter again.

1 Like

Yes that was the goal but doesn’t seem to do it consistently. I’ve seen multiple notifications show up when there’s a change within the specified range (going by the values reported in the history tab)

This is where sharptools Rules excel over ST Routines. With sharptools, there is a trigger for ā€œchangesā€ and then in the Flow logic you can evaluate if a value is within a range. This eliminates the entering/exiting issue you point out above.

If ST would simply add a ā€œvalue changesā€ trigger, then range could be used as a precondition to achieve the same behavior as sharptools.

Great idea, one can do a precondition on the range and value change part is also easy, if the value is > 0, however, the problem I see that I can’t select the same attribute in the same device two times in a single automation. @Itati this could be feedback for the team as well, a use case for allowing the same attribute on the same device to be selected multiple times in a single rule.

1 Like

Can you clarify the expected behavior of how the range value is supposed to work? Does it trigger whenever the value changes within the range or does it trigger when enters the range and shouldn’t trigger again until it exits and reenters the range?

This.

The generated JSON Rule for the test I did the other day, a brightness Range between 40% and 60%, looks like this:

    "if": {
      "between": {
        "value": {
          "device": {
            "devices": [
              "c7808b59-76c9-42b7-9053-612203f769ae"
            ],
            "component": "main",
            "capability": "switchLevel",
            "attribute": "level",
            "trigger": "Always"
          },
          "type": "device"
        },
        "start": {
          "integer": 40,
          "type": "integer"
        },
        "end": {
          "integer": 60,
          "type": "integer"
        },
        "changesOnly": true
      },
      "type": "between",
      "then":

Mind the "changesOnly": true, in other words, it will only trigger when the condition changes from false to true. Once inside the range, the condition doesn’t change, it’s still true. For it to trigger again it has to evaluate to false (going outside the range) and then evaluate to true (going inside again).

Looks like the Rules API supports both ways to handle the ranges depending on how you write the rule, as a ā€œdon’t trigger again while in the rangeā€ or ā€œtrigger for every value in the rangeā€.

I’ve just tested it, if you remove the "changesOnly": true then the range will trigger for every value change that falls into the range, without needing to go outside the range and re-enter. So you have the choice of what behaviour you want when using Rules API. If you use the app, the behaviour is not retriggering again while in the range.

Again, I don’t use ranges in my day to day so I can’t tell about the reliability, but the feature is there and should execute locally too.

2 Likes

Yep, changesOnly is also available for the =, >, >=, < and <= comparisons. The default is false but for Routines they tend to favour true which is why for example the greater than or less than conditions act like ā€˜rises above’ and ā€˜falls below’ for triggering purposes.

2 Likes

Hmm it not working that way for me. I’m getting repeat triggers within the range but not consistently. About every 15 minutes I’m getting a repeat trigger although the value is still within the specified range (atleast according to the event history).