Rule engine: Location mode changes condition not executed

SharpTools.io (web)
1

Hi all,
I noticed recently that some rule conditions are not being executed accordingly when mode changes, the log was saying mode changed but condition not met.

For example, I’ve one of the rules that activates virtual device based on location mode changes. One rule is to turn on isAway when mode changes to away. However from the execution log it seems that condition was not met, and so it was skipped. See screenshot below.

Screenshot 2022-12-06 at 9.39.46 AM
Screenshot 2022-12-06 at 9.39.46 AM2526×1302 165 KB

Screenshot 2022-12-06 at 9.39.58 AM
Screenshot 2022-12-06 at 9.39.58 AM1522×1586 136 KB

Screenshot 2022-12-06 at 9.40.24 AM
Screenshot 2022-12-06 at 9.40.24 AM2390×464 55.3 KB

Inspecting the first IF condition evaluation, json block looks to be indicating location mode was “Home”, contrary to the statement above that indeed mode was changed to “Away” at that time:

[
  {
    "type": "state",
    "subtype": "location",
    "data": {
      "platform": "samsung-smartthings",
      "locationId": "xxx",
      "attribute": "Mode",
      "state": {
        "eventId": "0882b498-74f0-11ed-b165-0566839802a6",
        "timestamp": "2022-12-05T22:56:20.000Z",
        "value": "Home",
        "isStateChange": true
      }
    }
  },
  {
    "type": "state",
    "subtype": "location",
    "data": {
      "platform": "samsung-smartthings",
      "locationId": "xxx",
      "attribute": "Mode",
      "state": {
        "timestamp": "2022-12-05T22:56:20.000Z",
        "value": "Home",
        "eventId": "0882b498-74f0-11ed-b165-0566839802a6",
        "isStateChange": true
      }
    }
  }
]

Could this be a potential bug? Or is there anything wrong? Please help!

2

There’s a couple things that could be happening here:

  1. The event was received faster than SmartThings updated the location status
  2. SmartThings was having some service disruptions yesterday in North America
  3. The mode data isn’t updating for your location

Event Data Updating Faster than State

It’s possible that the mode change event is being received by SharpTools and triggering your rule faster than the state is being updated. In general, whenever you want to have a condition that’s based on the value from the Trigger, I would recommend using Context Variables.

This enables you to use the same exact event value that triggered the rule in your IF Condition. This not only results in faster Rule Execution, but avoids potential issues where the event is received faster than the state is updated.

Here’s an example showing how I might update an IF Condition to use context variables.

SmartThings Service Disruptions

I believe this was already resolved by the time your rule ran, but posting it here for posterity:

Mode State not Updating

You might double check that the mode state is updating as expected. The easiest way to do this is to add a ‘Mode Picker’ tile to your dashboard from the Locations section of the Add Item screen. This lets you manually control your mode and watch to make sure the mode is updating as expected.

1 Like
3

Thank you Josh! I guess it’s most probably event sent faster than mode changes, I’ll check on your suggestions.

1 Like
4

On second thought, I don’t quite understand the “event data updating faster than state”. Given the event is triggered by Smartthings API which is triggered by Smartthings app routine (my location mode change was initiated by app routine), that mode change would have already been completed no?

Or are you suggesting this could still happen as the mode change event is already created and sent to Sharptools, while actual mode change execution was still in progress?

5

Right, the event gets generated in parallel to the state being stored to the database. So the event might trigger the rule before the state is updated in the database.

You can test this by adding a few second delay before your IF Condition which should provide extra time to make sure the state is updated.

1 Like
6

Yeah that’s what I thought as I don’t have variable to use :grinning: