Rules API "changes" condition does not trigger for same value when state_change = true

Developer Programs Rules API
1

I wonder if there’s a nicer workaround than the one I ended up using and works fine.

I have a rule to copy the value of a device attribute to a command of another device, in particular a knob and the step brightness commad of a light. The knob can emit the same value multiple times, that’s why it uses a state_change = true to emit the event and trigger a change.

However, if you use changes condition in the rule, it will not trigger if the value is the same, even if there’s a forced state change. Like this:

    "if": {
      "changes": {
        "operand": {
          "device": {
            "devices": [
              "xxx"
            ],
            "component": "group3",
            "capability": "knob",
            "attribute": "rotateAmount",
            "trigger": "Always"
          }
        }
      },

I’m currently using a workaround which is using a greaterThanOrEquals condition that always evaluates to true and the changesOnly: false which will actually make the condition trigger whenever there’s a forced state change. Like this:

    "if": {
      "greaterThanOrEquals": {
        "left": {
          "device": {
            "devices": [
              "xxx"
            ],
            "component": "group3",
            "capability": "knob",
            "attribute": "rotateAmount",
            "trigger": "Always"
          }
        },
        "right": {
          "integer": -100
        },
        "changesOnly": false
      },

Is there any prettier way for a changes condition that triggers on state_change? I tried using changesOnly: false in the changes but the rule will not validate.

2

You’ve already found a good solution to the problem. At least I can’t think of a better one.

The changes condition requires for trigger that the value actually changes.

2 Likes
3

The changes condition is described as returning true if it evaluates to true and the previous evaluation was false (which sounds similar to changesOnly: true within conditions). I get that when it wraps a boolean condition like greaterThanOrEquals. I’ve never grasped what is going on when it wraps operand.

Indeed I thought operand was true if that was the current event being handled, so where is the false when it is used in mirroring?

4

Hi @mocelet

Our engineering team has confirmed this behavior.

The workaround you mentioned is appropriate for this case.
We checked with the team, and they confirmed that changes is only evaluated when there is an actual change in the attribute value (compared to the previous state). Even if state_change = true is sent, if the value itself does not change, the changes condition will not be triggered.

As an additional suggestion, based on another case the team is currently reviewing, they used a not condition (as in the example below). This approach allows the rule to run every time a new event is received, since the value is not equal to 0. However, whether this applies or not will depend on your specific use case.

Example:

{
    "name": "Not 0 Test - try 2",
    "actions": [
        {
            "if": {
                "not": {
                    "equals": {
                        "left": {
                            "device": {
                                "devices": [
                                    "{{device-id}}"
                                ],
                                "component": "main",
                                "capability": "switchLevel",
                                "attribute": "level",
                                "trigger": "Always"
                            }
                        },
                        "right": {
                            "integer": 0
                        },
                        "changesOnly": false
                    }
                },
                "then": [
                    {...}
                ],
                "sequence": {
                    "then": "Parallel",
                    "else": "Parallel"
                }
            }
        }
    ]
}
3 Likes
5

Thanks @Itati , at least I have the peace of mind that I wasn’t overcomplicating the rule :grin:

Also, I like the not approach, that’s less text and fits the use case of the knob since a step of 0 makes no sense.

1 Like
6

Not sure I grasp your user case but it occours to me there’s always the possibility of nesting an if and greaterThan or lessThan , with else if needed, within the changes condition, but the trigger will always be a value change.

7

The knob is a rotating dial that tells you how much you rotated it, like 10%. You can use that 10% to increase the brightness of a light a 10%.

If you rotate a 10% and later another 10%, a rule with changes will ignore the second rotation since it’s still 10%. That’s why changes cannot be used and the only workarounds are conditions that are always met (like greaterThan or not equals) with changesOnly false.

In the end I decided to keep my original workaround using greaterThanOrEquals since it has less indentation levels than not equals and is more readable.

2 Likes
8

Out of curiosity, do you get an absolute position of the dial too? Is there a limit to the relative rotation apart from your ability to generate it?

9

No, the knob capability attributes go from -100 to 100, with negative numbers meaning you rotated left and positive right. There’s no state or current position.

They made the capability for the IKEA scroll wheel and there’s no absolute position either the way it is implemented. There are 18 notches but you only know the direction and how many you scrolled. If you scrolled 18 that’s a total of 100%, that may be only one knob event of 100% but usually it’s multiple events like 20% and 80% since it reports while you scroll too. If you go past the full wheel scroll it will report the completion of the 18 notches scrolled and start over from 0.

1 Like