Add your account as new device.
Login with your credentials.
Confirm your 2FA PIN code.
Your account is added as new device. That’s the central place for all communication with the Blink cloud.
Add your devices.
Select the device type (camera, SyncModule…).
Select your account, you want to add devices for.
Select your devices.
This app replaces the old unmaintained one. It has a new app ID and is not related. You can add this app, add your devices, adjust your flows and remove the old one.
It is not recommended to use them in parallel because that will raise a rate limit and block the cloud access to Blink due to the amount of API calls.
How does the app work?
The app communicates with the Blink cloud.
It retrieves periodically device states from your devices and refreshes the Homey devices. If you change the arming state of your system or the motion recognition of your camera in the Blink app on your mobile, it will appear a short time later in Homey. The polling interval can be set in the account device settings The default is one minute.
If you change a device in Homey, it will call the API to change the real device instantly.
You can change your devices manually in the Homey app or automated via flows.
Every device has it’s ows flow triggers like “motion alarm”, “offline alarm”…
But to make your flows easier, some alerts like motion or offline state can be used with the account device, too. So you can create one flow and use the camera name as token.
How to use?
Change device state / Motion regognition:
Easily change the device state with a klick. Switch a camera on/off to activate/deactivate motion recognition for this camera.
Change arming state of a system/SyncModule: Switch a system on/off to arm/disarm the system. Disarming a system will deactivate the motion recognition for all assigned cameras - like it’s done in the Blink phone app.
The app is checking for new videos. If a new video is found (recordey by a PIR event), it indicates, that there was motion at this camera.
But it’s not a realtime alarm. So you should better think like “there has been motion” instead of “there is motion”.
Dependent on your Blink account and subscription, new videos are stored in the cloud or locally on the SyncModule (USB).
3.1 The cloud check is much faster. The video is mostly recognized while recording and the check interval can be shortened to 5 seconds. So you will get your alarm in a timerange of about 5 seconds. Please do not use shorter intervlas. This will raise a rate limit and you get blocked by Blink for a time.
3.2 Reading the videos from SyncModule is a bit slower and conflicts can occour (SyncModule is answering on another request). The video can only be recognized if it’s finished. With a default interval of 15 seconds, you get the alarm perhaps too late for a direct action (30sec video recording + 15sec interval + another 15sec interval on connect errors).
That are details you have to keep in mind if you want to react on motion in your flows.
You can activate/deaktivate motion recognition or change the intervals in the account device settings.
Take a snapshot:
You can take a snapshot with a flow action.
Create a second flow with the “snapshot was created” trigger to react on. In this flow you can take the image as flow token to send it via push message.
Record a video:
You can rercuest the recording of a video. The video is stored in the cloud/SyncModule.
Check the camera state:
If a camera is offline, you will see an exclamation mark on the device tile. In addition you can create a flow to send you a push message. The flow can be set for a camera (if this camera gets offline) or for the account device (if a camera gets offline).
Checking the API state.
If you are experimenting a lot (taking snapshots, short reading intervals) you could get rate limited by Blink. Then you will see an exclamation mark on the account device. In the settings you can see the reason.
In the account settings you can define a time in minutes, that will be waited to raise the alarm. If the API connection is back in this time, you will not be disturbed. If you set the interval to 0 minutes, you will get a information about every API error - if you want as flow trigger to send you a push message.
… to be continued …
Thank you for supporting app development with a small donation via PayPal.
0.0.9 - 0-0.11
Small bugfixes and added buffered damera reading.
Fix for reading SyncModule/Storage data for missing USB drive.
Added repair function for account device. If you changed your Blink password, you can change the account device password via the device settings/repair function. This way you can re-auth your Homey device.
Extended snapshot action card for Advanced Flows. Added flow action for saving snapshots to an SMB share.
0.0.15 - 0.0.16
Added snapshot image to motion alert trigger - only available with cloud storage. Added motion alert trigger to camera devices.
Addes second flow action for ‘create snapshot’ for standard flows.
no, I have no contact to Blink. The app is using the (inofficial) API which is used by the Blink app (on phones), too. I implemented it without Blink, but using existing knowledge and examples (the old Homey app, API details available in the WWW, research). So like many other inofficial apps it’s a hacky cloud API access
Thank you, @RonnyW for your effort!
I just added my Blink System but it’s not working like it should:
Adding the account worked fine and I got some status values instantly, but it didn’t refresh since:
thanks for your report. I think I didn’t see the error because I testet with my existing account device. But I found a problem while changing the devie settings (API state…) after deleting and adding again.
That caused the device to stop the refresh.
I hope it’s fixed now. Please install the test version, delete the account and re-add it. You can keep all other devices but you have to adjust the account flows (if already added).
Both apps parallel could be ok. Bu I tzhink you will get a rate limit caused by the amaount of API calls. So if the new app is stable, xou could pause the old app and test the new one standalone.
Please keep in mind:
The app is tested by myself as far as I was able. But perhaps such constellations could still appear - it’s still a beta version
thanks for your tests.
I thought, 0.0.7 would correct the existing device. In my tests I was working. You could perhaps restart the app to initialize the device or delete the account device and add again. Then please check if the account id is shown in the settings.
Technical background: I think it’s caused by the setSettings method of the device (homey core). If the device updates the settings with only one (at this moment not existing) entry, it results in the error “invalid settings type”. If the two (not existing) settings are set in one call, it’s working.
I didn’t see this error during my tests, but I was able to reproduce the issue. My test at the moment with deleting/adding the accounts are ok. So I hope, for you, too.
I add a new test version 0.0.8 where the settings are set while paiting the device. So if a app restart doesn’t work, please use this version, delete the account and pair again. Many thanks
PS: The Github is still private while development/tests. I will open it later when there are less updates.
If the account is showing the account ID and the state, then the error is fixed.
You are running two apps parallel. That will cause in a rate limit by Blink.
You can pause the old app. After some minutes the 403 error should disappear and the account state should be “OK”. Then your devices should work.
PS: In the new app you can change the intervals, but not in the old one. So stopping the app would be the only solution I think - or adjust the motion interval (I think you are using cloud) to 30 or 60 seconds for tests). That will reduce the most amount of the API calls. Reading a image in the device is a bit expensive, too. It calls the API for some seconds to get the updated URL (it’s not a single call). So playing a lot with images will raise the API usage in addition to the default interval calls.
Neh I’m not running the old and the new at the same time . Removed the old everywhere
30+ blinkers running on 4 sync modules and 4 homeys so it’s great for testing all 4 sync modules on different external ips so that didn’t cause
The api polling block , I guess to much remove add restarts
Looks like only the first device reports came in
Since all cams have the stats from 4 hours ago
Would also be nice if the first page to open when you click a device is snapshot and with a auto collection of a snapshot . Those almost always fail the first time and takes some time . The device states would be better
Athom responded a few months ago that that would become definable or that you could turn of auto refresh at the first click on the thumbs page of a device . I don’t know if they have made this available already
Wow, so much Blinks
I think that is very much traffic. You should better reduce the intervals. Perhaps 5min for status and 15sec for motion alerts.
And your diagnostics report (it’s your I think) is showing a lot of http 403 errors (not allowed/rate limited). Your tests are raising the rate limit, I hink. I can see that some image request are resolved in 5sec (battery camaras need some time to wake up, connect, take snapshot and sent it, the mini cameras are much faster). After some tries, the limit is exceeded and you get 403 errors. That’s why you get error messages in snapshot view.
If the error in snapshot view appers after 10sec, the API is ok but the camera did not return a new image.
In the error occours directly, the API is responding with a http error.
You can see the errors in the device settings of the account device (API state). You can set the alarm waiting time to 0min to see the alarm on the tile. Don’t create a flow in that case. It will fire for every call . A flow is only good if you have a waiting time for the alarm (1 or 2 min).
I don’t know a possibility to change the order of device views. It’s predefined I think.
In the WebApp, the button is shown first, but at this moment, the image is requested, too (perhaps only if no image is present).
So I hope it will be usable for you and the big amount of devices. After the first play time it will be ok I think. I don’t check the images in the Homey device. I use it for automations like activation/deactivation of motion alerts and arm/disarm based on time or local situation (Open the doors will deactivate the camera alarm if Heimdall is disarmed to avoid too much recordings. I think this will be the main advantage of the Homey app.
a cloud video check will be one call for the account
a SyncModule video check will be 2 calls for each module.
a status check will be 2 calls (device date, subscription) and calls for each SyncModule
a snapshot request will need 2 or 3 calls for the camera/snapshot and calls every second until a new image url is available and another one to get the image.
I’m not sure I forgot some calls for device details.
You see, playing around will cause a lot of calls.
Edit: At the moment the cameras are read by API calls. I will use a buffered read to reduce the API calls. Perhaps that saves enough calls to prevent a rate limit for image retrival. I will post when a new version is ready.
I added a buffered reading of cameras where it is possible (camera actions like on/off).
Snapshot rertrieval can not be optimized because the snapshot url must be read directly. So the longer teh camera needs to take a snapshot, the more API calls are needed to read the URL/image.
Nevertheless it will be a small benefit if your ar switching the cameras often via flows.
I’m on 0.0.11 now and it works a little bit better. Camera* Snapshots now are shown on the Camera devices, but still no updated values. I can switch on/off motion detection for each camera but not the whole system (the on/off button shortly flashes but stays “on”, but the Blink system gets deactivated and can’t be re-activated afterwards**). I could share a screencast by request.
*I have three outdoor blinks.
**Edit: this seems to work at least in the web app
it’s a bit hard to say…what exactly do you mean with updated values?
The camera state is read from Blink cloud in the interval set in the account device (I think every 1 min).
The measures like WiFi signal will not change until you put the camera at another place. Perhaps the temperature is changing oftener. For me it’s updating (Outdoor camera).
In the situation where you clicked the button but nothing happened, you exactly acted in the second, the app was refreshing the cameras state. That happened sometimes for me, too
The app is retrieving the camera states (takes a second to get the API data) - and is getting the “activated system” state
You clicked the tile → the system gets deactivated in Blink
shortly after that, the retrieved data is set to the device → the tile gets activated again based on the before read state
This will be cleared with the next state retrieval. Then the Blink state is again read and the Hoemy system is set deactivated. It you click again in the meantime, Homey is sending the state to Blink and you can switch again.That you can check.
If you switch a camera/system state in Blink, it should appear after the next refresh interval.
Homey->Blink is real time
Blink->Homey is in request (refresh interval)
If that’s not the cause, sometimes a slow Homey app makes it hard to exactly click or long click the tile.
I think I have found a possible reason for th eproblem you see with the SyncModule.
You have no USB memory plugged in, right? It seems that’s causing an http error for reading the memory data and that’s recognized as API error in the app. I will check that wit my devices and adjust the app.