Blink block my account today and the support say:
Your accounts showed a large amount of arm/disarm and camera config commands from the third-party tool.
Problem is: they don’t say what the large amount value.
That’s a big problem because they only accept IFTTT and not home assistant. In my opinion it’s completely stup… to use IFTTT when you can do the same quickly and directly from HA. My scan_interval was 60. Now i try 360 but i think blink will block my account again…
I suppose i’m not the only one in that case. Is it Arlo system better with HA than Blink?
Also had my account blocked today:
My name is ******* and I’m a Technical Support Engineer from our main offices in the United States. Your account was brought to our attention by our Server Team who let us know that it has been flagged for generating back to back commands in short bursts over a long period of time. This has raised Server alarms which have disabled access to your account. At times, this is due to unauthorized third party software that may be in use with your system or a bad configuration of authorized integrations.
Please review your integrations and make the appropriate changes and we can have our Server Team reinstate access to your account.
I have asked for further clarification around API limits and also asked them to describe the pattern of traffic they are concerned about. I have a few automations that fire off when I leave and return home (so it could be that) or it could just be general high usage (from the component directly).
Will let you know if I hear anything more.
Nice speedy response:
We apologize that the access to your account was disabled but it is due to the unauthorized third party integration that flagged and revoked that access to your account. At this point, it would need to be disabled going forward. At the moment the only integration we support are both IFTTT and Amazon Alexa. I have requested to have your account reinstated so please attempt to regain access through the Blink App and let us know if you have any additional questions or concerns.
But also extremly concerning. I have reduced my update interval to 15 minutes for now… lets see what happens.
Cross linking to another thread on this here:
Yep me too - nice polite email as above, and the account has been disabled. For now I’ll disable HA access.
Reinstated - removed Blink from HA for now - have asked the question if I can use it or if there is an API call limit.
In my case i set the scan interval to 1 hour (that’s enough for the battery) and use only the battery sensor and motion detection. If they block me again…i will ask a refund to amazon for all the blink camera and accessories.
The problem is they don’t accept a third party, only IFTTT and never give the maximum call accepted for the api.
I’m sure they detect more call when i update HA and do some restart to fix a config problem.
1 Like
Nice scottsweb, it’s my post on their forum. I hope you receive more info than me. I ask the support to call me but the guy never say the maximum call to the api authorized. He always say: we only accept IFTTT
He always say: we only accept IFTTT
Which is ironic when you consider that the Blink forums are full of people complaining about the lack of reliability with IFTTT.
I’m still waiting for a response to my ticket raised at the beginning of yesterday (other than the auto-acknowledge).
I even resorted to calling them last night (UK time). Still nothing back. My two hubs have been bricks since at least Monday.
Arf that’s boring and you don’t receive a mail i suppose like me.
We are all ok here to say: IFTTT is ok for most people who don’t use HA. When you use HA, you can enable/disable motion detection with for example presence detection.
It’s completely stupid (in my opinion) to always open the app for that and not practice to use IFTTT when you can do the same directly from HA…
Technically, blink doesn’t have an API so asking how many API calls are allowed will get a wishy-washy response. The better question is how often does the Blink app poll the blink servers, since that’s what the home-assistant component is emulating. From my research, this is about once every 60s BUT it’s only polling very specific api endpoints, whereas the library I wrote takes more of a shotgun approach and updates from many endpoints. I THINK this, coupled with use of the blink.blink_update service in home-assistant, is what’s causing accounts to be flagged.
I’m going to try working on making the refresh routines more conservative and only update stuff that has been requested to update. I do not know the best approach here, so it may take some time and is not guaranteed to actually fix this issue.
With that said, I’m very confident that simply relaxing the scan_interval to a less-frequent interval will prevent accounts from getting banned. All the requests from home-assistant are the same requests being performed by the Blink app itself, so the only thing that can make your account stand out is increased traffic.
5 Likes
Similar situation here. No email. Sub 1hr reactivation from support.
I did however have a reasonable conversation with support operative. I have no way to confirm the validity of any of it. Points of note:
- operative maintained 3rd party integrations are not blocked.
- I had triggered a system designed to prevent malware attacks.
- IFTTT integration had triggered the rate limit! I probed this with further questions.
- Rate limit is not explicit request frequency, but based on having overlapping simultaneous requests.
- Being somewhat surprised they had identified IFTTT as the offending integration I asked if the logs could be shared. Now I do use IFTTT (with life360) to arm/disarm the system, as until recently this was the simplest way to work with 2 blink systems. Unsurprisingly the logs could not be shared, however I was told that at the time of the problem they received 10 arm and 9 disarm requests, with 18 total in 1 minute. I’ve not yet managed to see what IFTTT is doing, however as HA doesn’t arm/disarm my Blink I don’t really see how they could be confusing the calls.
2 Likes
Interesting, thanks for sharing that. It further convinces me I need to overhaul the refresh routine to prevent too many requests at one time (right now a handful of API requests are made during refresh which is probably way too aggressive).
1 Like
@fronzbot, if it helps here is what I have been able to ascertain happened on Monday (times in GMT) - I was locked out by Monday late afternoon.
Note that I had only just added a second sync module to my routines, armed and disarmed through separate automations as I was looking to use the associated camera externally (after testing).
Presence trigger at 09:15 + 10 minutes:
- Armed internal sync module
- Armed external sync module
Motion trigger at 10:46 (firing the automation detailed below).
NB: at this point the account was still active as I received the notification
Presence trigger at 11:42
- Disarmed internal sync module
- Disarmed external sync module
Motion trigger automation:
- id: camera_blink_motiondetected_notification
alias: 'Blink camera motion detected notification'
hide_entity: True
trigger:
- platform: state
entity_id: binary_sensor.blink_dining_room_motion_detected
from: 'off'
to: 'on'
- platform: state
entity_id: binary_sensor.blink_front_room_motion_detected
from: 'off'
to: 'on'
- platform: state
entity_id: binary_sensor.blink_front_door_motion_detected
from: 'off'
to: 'on'
action:
- service: input_datetime.set_datetime
data_template:
entity_id: >
{% if trigger.entity_id == 'binary_sensor.blink_dining_room_motion_detected' %}
input_datetime.last_dining_room_recording
{% elif trigger.entity_id == 'binary_sensor.blink_front_room_motion_detected' %}
input_datetime.last_front_room_recording
{% else %}
input_datetime.last_front_door_recording
{% endif %}
time: '{{ (as_timestamp(now()) | timestamp_custom("%H:%M:%S", true)) }}'
date: '{{ (as_timestamp(now()) | timestamp_custom("%Y-%m-%d", true)) }}'
- service: blink.blink_update
- delay: 00:00:05
- service: blink.save_video
data_template:
name: >
{% if trigger.entity_id == 'binary_sensor.blink_dining_room_motion_detected' %}
Dining Room
{% elif trigger.entity_id == 'binary_sensor.blink_front_room_motion_detected' %}
Front Room
{% else %}
Front Door
{% endif %}
filename: '/home/homeassistant/.homeassistant/snapshots/motion.mp4'
- service: shell_command.extract_motion_image
- service: notify.pushover
data_template:
title: "House Notification"
message: >
{% if trigger.entity_id == 'binary_sensor.blink_dining_room_motion_detected' %}
{% set camera_name = 'Dining Room' %}
{% elif trigger.entity_id == 'binary_sensor.blink_front_room_motion_detected' %}
{% set camera_name = 'Front Room' %}
{% else %}
{% set camera_name = 'Front Door' %}
{% endif %}
Motion was detected by the {{ camera_name }} camera at {{ now().strftime("%H:%M")}}
data:
priority: 0
sound: bugle
timestamp: true
file:
path: '/home/homeassistant/.homeassistant/snapshots/motion.jpg'
- service: shell_command.extract_motion_cleanup
Given @adamb’s post above about IFTTT and multiple sync modules, I wonder whether arming / disarming multiple sync modules is a common theme for those who’ve been locked out? Might it be possible to incorporate an arm / disarm all modules action to mitigate this?
If it is any help, my account was not blocked, I used a 60s scan interval with one sync module and one camera.
But I did not use arm/disarm or IFTTT at all. I recently changed my setup to take pictures instead of clips, which I forward with telegram depending on the state of Home Assistants alarm ( I had too many clips of cats passing by or clips with no movement at all ).
@TazUk - Interesting. Is it possible each of your binary sensors had a motion trigger event and so the automation action was called three times for effectively one event? Just a thought. The blinkpy library that the home-assistant component relies on has built-in throttling, but this is overridden when using the blink.blink_update service. Also, for what it’s worth, you don’t need to make a call to blink.blink_update if motion is detected, since a blink_update would have JUST been called in order to change the motion detect state.
As for whether or not you can arm/disarm all modules, as far as I know: no. The endpoint for arming/disarming relies on an identifier unique to each sync module, so there inherently has to be a different http request (at least using known api endpoints).
@DonTomato - yeah, I have a similar setup- 60s scan interval, one sync module, and have not been blocked either. I take pictures with all of my cameras in 30minute intervals and also arm/disarm based on presence.
I’m thinking that a fast scan_interval couple with too frequent use of blink.blink_update might be root cause here. Which should at least be mitigated with the increased default scan_interval that’ll be in the next HA release. But even then, if blink.blink_update got called (for some reason) multiple times in a row, that would still be an issue. I’ll have to think about how to prevent that (my first thought is to have a dummy routine that blink.blink_update maps to and is internally throttled).
Had one last email back from Blink:
We appreciate your patience. At the moment, Amazon is only allowing just IFTTT and Amazon Alexa enabled devices. I do understand that our Engineering are looking to expand towards more options in the future but I am a bit unsure as to where that is headed. I will share your feedback as I also agree that the Home Assistant Community is growing and the ability to expand our hardware with other features would be quite powerful.
Not a great deal of substance unfortunately.
Anicodotealy, I have a feeling that there might be two problems. One is the fairly frequent update interval (easily adjusted) and the second is hitting the API quickly in succession. I have an automation or two that modify the motion detection state of a number of cameras based on time of day etc. I have been noticing some of those fail (some cameras reamain with motion detection on/off). I think I will need to introduce a small artifical delay between each camera change in order for it to work again. The blink app is similar to this, it won’t let you make too many changes in quick succession. I am wondering if they have a check on the API side for this too now.
You can see one of my automations here: https://github.com/scottsweb/ham/blob/master/homeassistant/automations/sycamore-arrive.yaml#L24
@fronzbot - It’s unlikely I think. From the associated video clip the camera was triggered by one of our cats who’s a bit of recluse, but likes to walk through that room to look out of the back windows around 11am every morning. The other cameras don’t normally trigger at all in their current positions.
Our cat-flap logs show that the other cat was outside during the trigger time.
I’m more suspicious of the arm / disarm with two sync modules and taking @adamb’s IFTTT related lockout into account.
I’m wondering whether Blink have (partially at least) failed to account for multiple sync modules in the design of their analysis if the “approved” method can trigger it. Multiple sync modules came to the apps quite slowly if I remember correctly.
Good to know (and makes sense) - thanks for the code review 
@scottsweb - So I do know that there is an endpoint to check the status of a recently sent command and that the blink app does this. Basically it waits for a “go ahead” before sending the next command. Unfortunately, this type of behavior starts to get out of my comfort zone when it comes to implementing it in the blinkpy library, but the ability to do something like that is there… I just don’t know how to implement it 
With that said, you bring up a good point. I think adding artificial delays to automations is a very safe approach and maybe the docs should be updated to encourage that.
1 Like
Thanks @fronzbot, I have put some delays in today so will see how if that does the job and report back. I have started with just a shortly delay of 2 seconds between each request for now.