New 2FA email every 24hrs

[swerb73]

Been working with RC2, with some adjustments I've been able to stabilize it a bit but I definitely can't run a script more than once every 2-3 minutes as it surely barfs on me within that windows. Does anyone ever hit the blink servers that often and have issues?

Also I notice that it always sends me a new key each morning, I think it's about every 24 hours now. Still makes me think I'm using this wrong (I'm using the cred file mechanism per the other discussions), I generate a cred file initially by forcing it to send me a key then all subsequent requests I reference the cred file specifically before blink.start.

Any ideas how to prevent this or troubleshoot it?

Also any other ideas on how to better be able to run scripts more often than once every few minutes (I do this when opening/closing doors - worst case I suppose I can add a delay in my motion/door events but would rather avoid that).

Thanks!

[fronzbot]

I definitely can't run a script more than once every 2-3 minutes as it surely barfs on me within that windows

Yeah that's on the edge of being too quick. I think I call the built in refresh() method once every five minutes, at most and have been ok.

Also I notice that it always sends me a new key each morning, I think it's about every 24 hours now.

I've been seeing this too with a script I run. I do not see this with the v3 endpoint used in 0.15.0 so I have to dig in some more. I'm not sure what's happening.

Also any other ideas on how to better be able to run scripts more often than once every few minutes (I do this when opening/closing doors - worst case I suppose I can add a delay in my motion/door events but would rather avoid that).

Running a script that calls blink.start that often is not a good idea, since it hits a bunch of endpoints to perform setup. What you want is something persistent. I assume you're using door sensors of some kind? Your use case screams home-assistant. Up until recently, I had geofencing set up with home assistant allowing me to arm/disarm cameras based on my phone's gps. Very easy to set up. The benefit is that home-assistant will only call the blink.start method once at startup and retain a persistent instance. So when you go to arm/disarm a camera, it's a single API call instead of several.

[fronzbot]

On that note, I'm going to see what it takes to bypass the API calls in start() if the cred file is given. Just need to see what info will need to be stored so it's loaded next time. That might be an acceptable fix for the API throttling at least.

[fronzbot]

I should be able to just incorporate blinkpy into flask since it's python and avoid the multiple script calling.

Yeah I think that would help. With that said, I haven't tested the 0.16.0-rc versions with that method yet so I don't know for sure if that's the root issue.

Question - this things stay running for weeks or months on end. If the connection to blink fails mid-stream will the library take care of reestablishing a connection?

It should. I've added as many checks I can think of to make sure this happens. If blink locks you out and you need to enter a new 2FA key, it can't handle that. With that said, I just tested with a week-old token and the library updated fine and I only noticed later that I got a new 2fa key from blink...so I think there's still something wonky on their end (or maybe I'm hitting an endpoint that generates a new 2fa key automatically or something).

Also - guessing I should save the cred file periodically also in case I have to restart flask so the new creds are picked up on restart?

No harm in doing that. My opinion is that doing it once after initial log in is fine. The only thing that will really change will be the token and the library will handle refreshing that when you start up again if it's stale. So if you have a flow like start() --> save(), then you will always save a "good" token, even if it changes some time in the future. Hopefully that makes sense.

Yah, I'm so invested in SmartThings I just haven't made the jump to home-assistant...

Worth mentioning: Smartthings integrates into Home-Assistant: https://www.home-assistant.io/integrations/smartthings/

[swerb73]

Well initial testing looks good. I've incorporated it into flask. I'm getting periodic processing errors but I can now much more quickly call arm/disarm functions since I don't need to do a full blink.start() each time. I'll work with it the next few days and report back including if I get the verification code requests coming through daily.

[swerb73]

Checking in. I've made some additional tweaks after realizing that I'd need to do a refresh before checking state of cameras and making changes (arm/disarm, etc). That seemed to work well and returns quite quickly not taxing like blink.start(). So far things seem to be working ok as I work through ways to optimize this approach.

Also NOTE: I've confirmed I didn't need to use the new key that was emailed to me this morning, normal 24 hour cycle - maybe a bug on Blinks end?

[fronzbot]

Awesome!

Also NOTE: I've confirmed I didn't need to use the new key that was emailed to me this morning, normal 24 hour cycle - maybe a bug on Blinks end?

Yeah, seems like it. Although I have to imagine the library is hitting an endpoint in such a way that it triggers an email so I'll have to look into that.

[swerb73]

NOTE: I loaded RC6 yesterday and 24 hours later I did get another verify login message.

[Kirbyrc]

Re-igniting this thread: I have been using blinkpy for over six months, until 2FA and release 0.16.0, it has been working great. After that I started having authentication issues. I am currently using the released version, currently 0.16.3. I need to re-authenticate every 24 hours to keep it working. I was pleased to see that code was added to automatically refresh expired tokens, but it doesn’t seem to be working in my case. Below is a diff of a log of a working session and one that needed re-authentication. I have enclosed my auth.py script that I use to re-authenticate. When I run this after 24 hours, I get the email and need to type in the code otherwise it just runs.

Are others still seeing this issue?

cah 4105> diff auth.log auth.log.save
3a4,8

DEBUG:urllib3.connectionpool:https://rest-u007.immedia-semi.com:443 "GET /api/v3/accounts/85451/homescreen HTTP/1.1" 401 44
INFO:blinkpy.auth:Token expired, attempting automatic refresh.
INFO:blinkpy.auth:Attempting login with https://rest-prod.immedia-semi.com/api/v4/account/login
DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1): rest-prod.immedia-semi.com:443
DEBUG:urllib3.connectionpool:https://rest-prod.immedia-semi.com:443 "POST /api/v4/account/login HTTP/1.1" 200 347
4a10
DEBUG:urllib3.connectionpool:https://rest-u007.immedia-semi.com:443 "POST /api/v4/account/85451/client/384371/pin/verify HTTP/1.1" 400 75

#! /bin/python3
import os
import logging
logger=logging.getLogger(name)
logging.basicConfig(filename='auth.log', filemode='w', level=logging.DEBUG)

from blinkpy.blinkpy import Blink
from blinkpy.auth import Auth
from blinkpy.helpers.util import json_load

cred_file="newcred.json"
cred_file_last="newcred.json.last"
blink = Blink()
auth=Auth(json_load(cred_file))
blink.auth=auth
blink.start()
os.rename(cred_file, cred_file_last)
blink.save(cred_file)

[fronzbot]

Use no_prompt=True when initializing the Auth class (like here).

Due to the 24hr email oddity, when the library goes to grab a new token it sees a new email has been sent and so will prompt you for a new code. But, at least in testing, you only need the 2FA code once when you login to get your first token and all refreshes after that do not need a token, despite the email implying the contrary. Starting with no_prompt=True will allow the library to just ignore the newly generated 2FA key (just make sure to call blink.setup_post_verify() after blink.start()).

[Kirbyrc]

OK, I gave your suggestions a try and I wanted to wait 24 hours to see if they worked. They did with one caveat, I still got a 2FA email, but apparently I can just ignore it. Per your suggestions, I modified my code as follows. This modification was not obvious from the documentation. Please feel free to add it to the documentation if you desire. Thanks for helping me solve this issue. Now I have one less thing to do every morning, except to delete the email.

#code to startup blinkpy 0.16 with credential file

from blinkpy.blinkpy import Blink
from blinkpy.auth import Auth
from blinkpy.helpers.util import json_load

blink = Blink()
auth=Auth(json_load(“cred.json”), no_prompt=True)
blink.auth=auth
blink.start()
blink.setup_post_verify()
.
.
.

[fronzbot]

@Kirbyrc glad it worked. As for the documentation, that exact code (sans cred file loading which is in another section) is called out in the quick start guide already here (same thing I linked earlier): https://github.com/fronzbot/blinkpy#starting-blink-without-a-prompt

[swerb73]

Hi guys, just wanted to confirm the setup_post_verify(), I haven't been using it but have been observing the desired behavior, 2FA email comes daily but I don't need to use the code. I use:

from blinkpy.blinkpy import Blink
from blinkpy.auth import Auth
from blinkpy.helpers.util import json_load

blink = Blink()
auth = Auth(json_load("c:\Blinkpy\cred.json"), no_prompt=True)
blink.auth = auth

opts = {"retries": 5, "backoff": 2}
blink.auth.session = blink.auth.create_session(opts=opts)
blink.start()
blink.save("C:\Blinkpy\cred.json")

Should I Be adding a blink.setup_post_verify() behind blink.start()?

Also @fronzbot - I noticed with the latest release I'm having very few, I think actually zero, HTTP errors, timeouts, etc. Since you released I've been up for almost the entire week now and not one error back on the interface. I only changed one thing in my integration which was to disarm the sync module before I go through my routine of individually disarming a series of cameras (due to timeouts I have this can take a few minutes to complete), then I rearm the sync module afterwards... Not sure if you've seen this behavior, that a camera connected to a disarmed sync module doesn't require as much of a resource on Blink's end to disarm?

[fronzbot]

So one of the changes was to make the http requests look like a browser. I think that's where most of the old errors were coming from. The default python requests library sends some info like "hey, this is coming from a python requests library" but when I changed how I was handling that, the new methods didn't identify themselves and Blink started throttling those heavily (I couldn't even access anything for a few days until I figured that out).

As for setup_post_verify() you should only need to call that once after submitting your 2FA token for the first time. The start() method will do that for you if no key is required. But I'm not 100% confident that when Blink tells me a key is required that one is actually required. Sounds like it's been working fine on your end so it's likely you do not need to add it in and the API is working the way I think it works.

EDIT- and on your comment about arming/disarming- not sure. I suspect that the improved behavior is solely due to the browser identification I send (I can't think of the right term right now) so maybe they were just hyper sensitive about seeing arm/disarm requests coming from an unidentified request

[miccico]

Hi!

There is an integration for Blink in FHEM which seems not have the issue of the constant emails. What i noticed there is that they use the v4 of the login api instead of the v3 used here. As the pin validation is part of v4 as well i wonder whether that might help with the problem.

The source code for v4 login can be found here: line 174, 683 ff
https://github.com/viegener/Telegram-fhem/blob/master/Blink/48_BlinkCamera.pm

The function call cited from above source file also features a parameter called "reauth" which i assume could be linked to the problem here

my $BlinkCamera_loginjsonV4 = "{ \"app_version\": \"6.0.10 (8280) #881c8812\", \"client_name\": \"fhem q_name_q\", \"client_type\": \"ios\", \"device_identifier\": \"fhem q_fuuid_q\", \"email\": \"q_email_q\", \"os_version\": \"13\", \"password\": \"q_password_q\", \"reauth\": q_reauth_q, \"unique_id\": \"q_uniqueid_q\" }";

I am not a python programmer so I am not really capable of implementing this change but maybe it helps.

best regards

Michael

[fronzbot]

We use the v4 endpoint, v3 hasn't been used for some time.

I have tried various permutations of the reauth parameter but that never seemed to change the result, but I'll go through that code to figure out if something different is happening (or there's a different implementation). Thanks for pointing it out!

[swerb73]

Just noting I ran rc0 without luck, still got the reath in 24 hours. Just installed rc1, fingers crossed...

[fronzbot]

@swerb73 yeah same. The minute I got the email I pushed the rc1 change (which returned a slightly different response after login) so hopefully it works. Getting really annoyed with these emails haha

[fronzbot]

Ok still haven't gotten any auth emails so I think this may be fixed! I'll push 0.17.0 out some time today

[fronzbot]

With the release of 0.17.0, I'm considering this closed. Hopefully we never have to re-open this 🤞

[swerb73]

I upgraded to 0.17.0 and am still getting the code very 24 hours, should I change any of the parameters to stop this?

[fronzbot]

You will need to clear your session file to generate a new uuid and token.

[swerb73]

OK, I should have thought of that! Just did it now and restarted the service (which normally generates a new key) and didn't get the new key message - so we might be on the right track!

[swerb73]

Confirming that seemed to do it for me! Man the library is clean now!

[Kirbyrc]

I wanted to wait several days before replying to make sure it works. I too can confirm that this version works! Thanks @fronzbot

[han88]

hi I m using vers 0.18.0, but no way to get access nor getting an email with the access key...Is there an actual workaround?