[PROJECT] Driver for Blink API

Developers
,
#1

Drivers for polling the Blink API for your Blink cameras and related devices.

Features:

  • Can request a PIN be emailed to your account from Blink (Authorize)
  • Can validate PIN received from Blink (Verify PIN)
  • Can check Blink account for any "networks" of devices and pull basic information
  • Can check Sync Modules, Cameras, and more for basic information
  • Can arm/disarm systems individually or all for the account
  • Can enable/disable motion detection on cameras individually or all for the account
  • Devices are "Actuators" so they can be given custom actions to trigger commands in Rules
  • Re-authorizes the auth-token every 12 hours based on when you last Saved Preferences
  • Child devices have a number of commands they can also perform such as Arm/Disarm (Cameras, Doorbells, MiniCameras, Networks, or Sync Modules) or Enable/Disable Motion Detection (Cameras only, NOT Doorbells or MiniCameras)

Major Caveats

  • Display a thumbnail image from a camera (cannot save images to Hubitat from driver)
  • Display video in Hubitat (it DOES provide an RTSP link though so you can put that in your own RTSP viewer)
  • Report camera detecting motion
  • Enable/Disable Motion Detection for Doorbells or MiniCameras

Setup

  1. Add BlinkAPI.groovy driver to your Drivers Code section on your Hubitat (you can Import using the URLs above) then Save the driver. Repeat with the BlinkChild.groovy driver, both drivers are REQUIRED.
    OPTIONAL - But RECOMMENDED Add additional BlinkChild-xyz.groovy drivers for types of devices you have.
  2. Add a Virtual device and set the Type to be BlinkAPI (user-added drivers are going to be at the bottom of the list), then Save Device.
  3. Enter the email and password used for your Blink account into the Account Email and Account Password fields in Preferences then Save Preferences.
  4. Select the "Authorize" command with the Reauthorize parameter set to "false". Check your email for a PIN sent to you from Blink.
  5. Enter the PIN received from Blink into the field for the Verify PIN command then select the "Verify PIN" command. NOTE: Step 5 must be done within 40 minutes of receiving the PIN from step 4. If it expires, repeat from step 4.
  6. Once the initial authorization is all set, I recommend using the GetHomescreen command to pull in your devices. This will create child devices to match up with whatever information the API returns for your account. If you have added the optional drivers it should automatically set each of those child devices to the correct type, making it easier to have the correct commands and attributes applicable only for that device.

Enjoy checking out the features!

Added Notes:

  • If you need to re-authorize for some reason after you have already completed the PIN verification, you can do it by using the Authorize command with the Reauthorize parameter set to true.
  • If you post logs (my drivers are designed to get pretty verbose if you set them for Trace, but mostly use debug for unhandled variables I need to add and such) please make sure there are no account emails, passwords, IDs, or AuthTokens in them. Or you can send them to me directly as a PM. I have no interest in messing with other people's systems.
  • If you already have the drivers installed and attempt to update them (since I have posted many updates since the original version), sometimes your browser will have cached the old version. You will need to refresh the driver's page (the link's above) so that the newest version can be imported or just copy/paste it in once you have forced your browser to refresh.
15 Likes
Blink Camera support
[RELEASE] Hubitat Dashboard - Android dashboard app
Blink or HA Link
Thoughts on an enhancement to Hubitat Package Manager
IFTTT now offers paid plans
Blink compatability with hubitat
Considering Hubitat - a few questions
Arm/Disarm Arlo using Node-RED
Making a driver for a WiFi device (or bribing someone to do it)
How to get Homebridge Temperature
Custom Device Drivers (Wiki)
#2

Great. Thanks for getting this out. I’ll have to give it a go!

1 Like
#3

Very nice will give it a try tomorrow. Thank you for doing this.

#4

Many, many thanks for this. I have fully tested the installation routine and the arming and disarming of blink systems via webcore automation and can happily confirm all is working perfectly.
The only additional feature I'd like would be to just arm/disarm an individual camera rather than the whole SyncModule.
Great work, I'm sure many people will find this incredibly useful especially with the current situation with smartthings and ifttt.

UPDATE:
With regards enabling a single camera rather than the whole sync module. It is possible in the Blink mobile app although it is a bit of a fudge.
Basically you have to enable the whole syncmodule and then manually disarm each camera by clicking the running person icon, just leaving the one's you want armed.
I tried to replicate this using webcore by enabling the sync module and then trying to disarm the unwanted cameras using the camera ID instead of the NetworkID but this didn't seem to work.
Maybe this information though will help you determine whether it's possible to just arm or disarm cameras individually.

2 Likes
#5

That looks to me like it is not actually disarming each camera. Instead it is disabling the motion detection. If you have motion detection disabled on all and arm the system in the app you get a warning and all those icons are grey to begin with.

So the driver could do the same thing. Arm the system, then send commands to disable the motion on particular cameras.

1 Like
#6

Great!

I can now arm and disarm without IFTTT. Thank you.

But the device status does not update; it still show disarm even tho it has been armed.
The other thing is I can't figure out how to do this with rule machine. Can't find the blink device anywhere in action.

2 Likes
#7

Ok... that is because I am not polling again after sending the change. But I do get a "success" response so I should be able to change the status. Good thing to point out there and it should be easy enough to do.

As for the Rules... also a good point. I think I need to add the "Actuator" capability to the driver so it can be sent commands. Right now all I think might show are the cameras with their temperature settings or such.

1 Like
#8

I'm excited to try this driver out too. Before I do, is this driver part of the Hubitat Package Manager? I imagine there's going to be updates coming and it'd be cool to have an easy way to update them.

#9

No, it is not. Right now the easiest way to update is to run the Import command from the driver code window. I will post on here whenever new versions are made and the driver itself checks daily and will have an event stating if a new version is available in it.

1 Like
#10

no worries - i just installed it and it seems like it's working! I know it's early so I won't try to integrate it into my dashboard just yet - but I did add the main device and cameras to the MakerAPI list of devices just to see what's being sent.

I know these cameras aren't that responsive - likely b/c of being battery powered. Trying to get a thumbnail or video from the Blink app can take several seconds so I'm not expecting anything like live video feeds on the dashboard.

But, just being able to arm/disarm cameras from the dashboard as well as automating it via rule manager is going to be huge for me!

Question -- and I know it's been asked here - but just so I understand - is it possible to arm individual cameras? I went into the Blink app and only see 1 arm/disarm switch for the whole system (sync module). What I'm unclear on is - what's the difference between disarmed and armed but with motion detection off for all cameras? Meaning, is there any reason not to just keep the system armed and only toggle individual cameras on/off?

#11

You are correct, there is not really any functional difference between the system being disarmed and all the cameras having motion detection disabled. In fact, if you disable the motion detection on all of them you will get a warning about it when arming (or disarming even) in the app.

However, if the system is disarmed and some cameras have motion detection enabled you will not get any notices from those. That means you would not get false positives if you were home (for instance) and forgot to turn off motion detection on a particular camera.

#12

Updated versions posted (run Import in the Driver code window to get the latest):
BlinkAPI incremented to 0.1.3
BlinkChild incremented to 0.1.1

Features added:

  • Arm/Disarm System & Enable/Disable Motion Detection now change state (if needed) in the child devices upon successful command
  • Parent device got "Actuator" capability so it can now be sent custom actions (run it's commands) as Rules
  • Driver will now attempt to reauthorize (get a new token) if commands fail due to unauthorized (This started happening to me and I do not know how long a token is good for, but a Request PIN command solved it and got a new token assigned, without a new PIN showing up in my email. After this all the commands started working again.)
1 Like
#13

Awesome

#14

The single camera arming work around copying the blink mobile app procedure of enabling the SyncModule followed by disabling motion detection of the specific cameras works perfectly.
At the moment it's all doing everything I want of it.
I guess the only suggestion I'd make right now is to integrate with Hubitat Package Manager.
Again many thanks for all the work.

2 Likes
#15

I had the unauthorized errors this morning after updating to the latest versions of the drivers.
I presume that the authorization process links the app or in this case the driver to the corresponding blink systems. If the app/driver is updated could this be seen to be a different app/driver to what was originally authorized by the blink systems? Maybe the authorisation process uses some kind of hashing method of the app/driver to generate a code. If the app/driver changes then potentially so could the generated hash. The same as when a file is modified the file hash value changes. Does that make any sense?
I know that I've not had to re-authorise my android mobile blink app, at least not that I can remember anyway, so presumably the authorization is not designed to expire within a day or so.

#16

The driver version is not it. That is not sent to Blink at any point.
What I think is happening is that the auth-token expires after about 24 hours. But sending another Request PIN sends your email/password and refreshes it, getting a new auth-token. Things should work after that (they did for me) so I basically made the Reauthorize portion do that, with 5 attempts before it gives up.

I think the app just does that all behind the scenes. The driver has a randomly generated client ID it makes but then retains it from then on as a state variable. This identifies the driver to Blink during initial auth (and reauthorization) and does not change.

Have to see how it holds up over a couple days.

#17

I just updated to the latest.. I hadn't updated a driver before using Import but that was super simple.

I also checked the logs and I see some errors like this one (last night so not related to updating)

dev:3352020-09-22 08:25:27.856 pm errorBlink - Exception in addChild: java.lang.IllegalArgumentException: A device with the same device network ID exists, Please use a different DNI
dev:3352020-09-22 08:25:26.852 pm errorBlink - Video Event Data null

I haven't tried using any of the functions yet other than refresh and homescreen

#18

This is outstanding! So glad you are working on this! Much appreciated.

We might need a little definition on the terms: System, Network, Sync Module, Camera. The latter two have definition in the Blink app, so they are obvious. Specifically, in the Blink app, one arms a Sync Module as a group of cameras connected to that sync module. It's the only way I know of the implement zones of cameras such as Indoors and Outdoors.

But Network is a new wrinkle. It appears that with the API, one arms a Network rather than a Sync Module, although they appear to be functionally the same (but different IDs) for my setup. Perhaps the distinction is for future use, and today they have 1:1 relationship? It's a bit confusing that the parent API device has a network ID.

System isn't a term that I've used before with Blink.

As a by the way, something I did while renaming Networks to friendly names created a new child device Network-null. Looks harmless and I'm sure I can just remove it. Just making an observation.

1 Like
#19

quick question - is there a state variable or something else that would say when the last update was done? I don't know if the variables below are set automatically or not. Anyway, I'm ultimately asking b/c if I could get the last refresh time via MakerAPI I'd be able to display it on the dashboard.. not critical in any way but seems like it'd be useful for a polling API driver IMO

image
image751×190 5.6 KB

#20

@jpage4500:
*I will have to check... It should not be trying to add a second device of the same name, it is specifically designed to only add it if it does not already exist. So I might have broken something there but have not seen it on mine yet. That is why users also checking is a good thing.
*There should be an Updated Event on the children and MAYBE a state one on the parent (cannot remember and cannot check where I am) but I will make sure to get that added if it is not.
@HAL9000:
*Good call. I will try to describe them in the driver, but if I find network and sync module are the same overall (despite differences in terminology in the API) I might combine them going forward.

1 Like

Download the Hubitat app