Blink Arming - IFTT Alternative using API


#1

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…


IFTTT PRO alternative?
#2

Nice work :+1:


#3

Thanks so much for this piston. I’m a newbie, was able to bring over the piston, setup the virtual switches, edit the piston with all this information. Put in my Blink login information, but nothing happens. The piston shows that it is run, but I never see anything change on the Blink side. How do I know if the API call to Blink is working, is there a way to test just this piece or do you have any suggestions to test out where it might be failing? Again thanks!!


#4

Nevermind - I got it working!! It was my newbie status of properly setting up the GET and POST commands. Once I properly set up the expressions and got all my variables right, it worked like a charm. Again thanks for this Piston!


#5

A follow up question - now that I have this working - when I trigger one of my 2 modules, I get an email from Blink indicating that they see a login into my account and asking me to verify it by entering a verification code into my Blink App, but since my App didn’t make this call, there is no way to do this. Am I missing some sort of authentication or is there something I need to do for validation that I missed from the piston? It is working, but just wondering whether Blink will shut down my account eventually because it thinks there is some sort of intrusion. Thanks again!


#6

Thanks for brining this to my attention, I did not get such an email but I was also using the bling desktop app so it is possible I have already authorized from my home network. Can you check the $response in the log? Should look something like:

account:[email_verification_required:false, email_verified:true, id:57405], app_updates:[code:105, message:An app update is required, update_available:true, update_required:true], cameras:....

Hoping email_verificaiton_required is true for you and I can use that as a flag in the piston.

I have found some documentation on submitting a PIN though I’m not certain the best way to build into the piston. I will test some possibilities, suggestions are also welcome.

You can submit manually via postman if you are so inclined.
Documentation is found here https://github.com/MattTW/BlinkMonitorProtocol/blob/master/auth/verifyPin.md
Use the most recent data from your piston (accout ID, client ID and auth token). Using a consitent client ID should prevent future PIN requests per the documentation.