In light of the changes to IFTT, I have created a piston below to utilize API endpoints for arming and disarming of Blink camera systems. As with IFTT, you can still only arm/disarm the module itself, not individual cameras (unless you setup a mini as its own system for example). Note: this is one way communication, if you change the armed status by other means (i.e. Blink App) it will not be reported to ST.
Variables
blinkSTdevices - a device list of virtual switches in ST, I made these previously for use with IFTT
blinkNames - a string list of system/camera names as they exist in Blink, listed in the same order as the above virtual switches. For example, Switch 3 is actually called Blink Front, module 1 name in blink is Front.
Triggers - any change in any of the defined virtual switches
Logic
- To access certain API endpoints, a auth token is required and the endpoint can sometimes be regionally defined. Luckily both these values are retrievable via the login endpoint.
- The piston first attempts a GET request to retrieve your system data, if either the auth token or region is invalid, a new login request is generated and those values are retrieved to be passed along with future requests. (Results in fewer calls to the API if we only login when necessary)
- The piston then determines the active ST device, matches it to the blink device, sending the correlating network id and command.
Turning on/off virtual switches too quickly can interrupt the piston resulting in missed commands. Please keep this in mind. I have a schedule piston that arms/disarms (turns on/off the virtual switches) under various conditions. To ensure each run of the piston is complete, I have set a wait of 1 sec between on/off commands (average run time of 500ms).
Open to suggestions, piston is below…