Set Security Mode with Rules API

I’m sure it’s been asked, but i can’t seem to find the answer… Can SecurityMode be set using the Rules API?

i see that location mode can be, although it doesn’t match the documentation for locationMode
this says the command is setMode (not sure which device to use to send the command to)

Production Capabilities documentation

but i found that location mode was being updated in a sample, this doesn’t have a command per sae, just

             "actions": [
	            {
	                "location": {
	                	"mode": "fdbde3da-97be-472d-8f3d-723aaa373be6"
	                }
	            }   
	        ]

found in the sample scheduled_mode_change.json

This seems to be working, so no complaints there.

Is there some other hidden gem that allows me to set the security mode (Armed Stay, Armed Away, Disarmed? I can do this in the app Routines, but i’d like to consolidate all my actions to one spot and include it in the Rule set i’ve create (42 and counting)

So, recently, @TAustin was able to add the ST app Routines to his API Browser+ and I took at look at the setup for one of my Routines. So, I have an app Routine to disarm STHM when location mode changes:

which when viewed as JSON in the API Browser, looks like this:

{
  "if": {
    "equals": {
      "left": {
        "location": {
          "locationId": "b355f7f5-7de9-4294-883d-d31b6c96b166",
          "attribute": "Mode",
          "trigger": "Always"
        },
        "type": "location"
      },
      "right": {
        "array": {
          "operands": [
            {
              "string": "84f1bcd3-81ca-46d1-a8ee-793045b2161a",
              "type": "string"
            },
            {
              "string": "97a869cf-b63d-4de0-a3f7-ddedd1fd165e",
              "type": "string"
            }
          ]
        },
        "type": "array"
      }
    },
    "type": "equals",
    "then": [
      {
        "location": {
          "locationId": "b355f7f5-7de9-4294-883d-d31b6c96b166",
          "security": {
            "armState": "Disarmed"
          }
        },
        "type": "location"
      },
      {
        "notification": {
          "push": {
            "title": "Security Mode Home - Disarm",
            "message": "Security mode disarmed - Home/Daytime Mode"
          },
          "type": "push"
        },
        "type": "notification"
      }
    ],
    "sequence": {
      "then": "Parallel",
      "else": "Parallel"
    }
  },
  "type": "if"
}

Now, it’s been pointed out that the Rules API may or may not support everything that the Routines can support (and vice versa), but I think this could work given that location mode setting in the Routines JSON looks similar to the JSON in the Rules API.

"then": [
      {
        "location": {
          "locationId": "b355f7f5-7de9-4294-883d-d31b6c96b166",
          "mode": "09af3ea4-53f7-4c2c-bde8-a1826a157e7a"
        },
        "type": "location"
      }

Let us know if it works for you or not.

2 Likes

whole crap… it works!

the proper values are

Disarmed, ArmedStay, ArmedAway (no spaces)

at first, i tries to combine it with mode


"location": {
	"security": {
		"armState": "Disarmed"
	},
	"mode": "39d2fbe6-c52b-4097-9115-85cc03c54c4c"
}

this resulted in a error

"Requires one property only","details":[]}]}}

but that was easily solved

{
	"location": {
		"security": {
			"armState": "Disarmed"
		}
	}
},
{
	"location": {
		"mode": "39d2fbe6-c52b-4097-9115-85cc03c54c4c"
	}
}

at least, it was accepted… we’ll see if the states will change properly

thanks @h0ckeysk8er and @TAustin !!!

Rules API doesn’t seem to like the notifications though :face_with_raised_eyebrow:

Hmm, strange since Notifications are only executable in the cloud.

yeah, got the ‘unrecognized field’ error

{
	"notification": {
		"push": {
			"title": "Security Mode Home - Disarm",
			"message": "Security mode disarmed - Home/Daytime Mode"
		}
	}
}

that was a stretch anyway.

@nayelyz , do you have the notification capability in the request list?

@orangebucket would this have any to do with what we’re talking about?

Not really no.

The only thing the error message above told me is that something has been changed on the back end recently and that the error messages are a lot messier than they used to be, but at the same time more meaningful.

The bottom line remains that the API the mobile apps are using accepts more than the public API does.

2 Likes

Would that imply the syntax would work via the client.smartthings.com API vs the api.smartthings.com API?

Well I was just being hopeful.

It would, but it wouldn’t help because https://client.smartthings.com/rules is the Routines. So you would end up creating a Routine, and there is a strong chance that it will look broken in the mobile app because it reverse-compiles them on the fly (for want of a better expression).

1 Like

Ah, makes sense.