I am in the process of testing a potential fix... Just want to give it a bit longer (darn reauth every 12 hours)... Anyways, there were a couple things Blink did including changing their expectation for the ClientID (UniqueID) sent to them. So I reworked that and found some other tweaks. My last couple reauthorizations have NOT resulted in any PIN texts being sent, so I might be on to something. Hopefully I will be able to post something tomorrow night. This WILL require people to run a new authorization (as if they are completely new) and verify the PIN because the driver needs to generate the new ClientID style.
6 Likes
Great news and very much appreciated.
Fingers and variables crossed.
IMPORTANT
After this update you MUST manually authorize again with the Authorize command's Reauthorize parameter set to false (picture below). This is so it will generate a new ClientID for the device to match the newest ID structure Blink is apparently using. You will get a new PIN and you must perform the Verify PIN command to be fully authorized.
Updated Version(s):
- BlinkAPI.groovy = 0.3.0
Change(s):
- Rework of reauthorization to match Blink's new standard for how ClientID (UniqueID) should be formatted.
- Rework of reauth request being sent to Blink as part of Authorization, this appears to solve the repeated PIN requests at this time (until Blink changes something again maybe).
- Authorize command now has a true/false parameter for whether it is a reauthorization or not. By default this will be true (reauthorize) but the first time a user uses this command (upon a new install OR after this update) they should use the false (do not reauthenticate) setting. This will generate a new ClientID (the first bullet) and request a PIN from Blink to match that new client. So you will need to run the Verify PIN command after that to verify the client.
1 Like
I'm giddy 
Did the update but sadly 5 minutes no PIN has arrived.
It seems to be wanting it though
Current States
- Armed System(s) : [284174, 118478]
- Authorization : Still requires PIN verification.
- Camera(s) With Motion Enabled : []
- Status : OK
- Updated : 2021-03-16T15:07:16+00:00
- Version : Up to date
EDIT I logged off on my phone and back on get to get a PIN.
I now have Auth in Current States and I never had that before.
Hi Folks, I have been following this thread for a while now and have decide to give it a try. This might be a completely ridiculous question but I have the devices installed, authorized and can arm and disarm from the Parent device screen, but it appears I can't arm and disarm from the dashboard with the Blink API Parent device. What I can do is arm and disarm using the "network" Child device as a switch in the dashboard tile. Is this the correct way to do it? Should we be able to arm and disarm from the Parent or just from the Child?
The parent device does have commands for it so you can control it as an Actuator (in Rules for example) but it does not have a Switch or Button itself to control it on a Dashboard. This is because there are multiple commands and which one would be mapped to what?
If you want a switch to arm/disarm all on the dashboard (through the parent) you could create a virtual switch and have a Rule that triggers on it to use the Actuator action to run the custom commands.
Thanks Snell! So the way I currently have it is correct. I used the child "network" device linked to the dashboard tile as a virtual switch to arm and disarm all at once. It works great. One more question, the tile I have created will follow the Blink App Arm / Disarm if I only hit refresh in the Blink API device. I assume this is why you have a refresh in the preferences, what's a reasonable refresh rate to use?
BTW this development is really great, appreciate your hard work.
It is more personal preference. On my normal-use one I have it set for 3 hours. I do not change it much outside of Hubitat (in the Blink App for example) and there is not much reason for my family to change it (with someone home almost all the time now).
If there was a field in the API that represented the motion detection or an easy way to import the thumbnails for display... I would probably refresh more frequently. But, if there IS a way to see if a camera notices motion, nobody appears to have found it in the API yet. With the way the thumbnails need the auth-token to be obtained... the current dashboard and file save methods on Hubitat do not allow it to be of much use either. So for now, I (personally) do not need a quick refresh rate.
Others probably have their own opinions on it. Of course it is fairly easy to change (just being a preference) if someone wants something different.
1 Like
So far I'm still Auth and no texts yet.
@dnickel I was in the same place as you, but finally got a PIN email after about 5 minutes. I did a Verify PIN and it seems to have worked.
Because apparently I'm unable to follow instructions, I did it with reauthorize set to "true" but everything seemed to work ok, got the pin, entered it, etc. Do I need to redo it with it set to "false"? I haven't received any more verification codes, going on 5 hours now.
edit: looking at the state variables, I do have a ClientID assigned already
Everyone would already have a ClientID assigned (unless they JUST started using it) but it is an old format apparently. Blink used to have them formatted as "########-####-####-####-############" but now they are apparently formatted as "BlinkCamera_####-##-##-##-######". Using the old one obviously still worked BUT I changed it to the new format while changing the reauthorization activity as well.
So... in order to have Blink properly verify the client on mine I had to use the new ClientID and the new reauthorization. Without it, things looked fine (and worked just fine) but the next time I would get yet another PIN upon Authorizing.
1 Like
Just got a text from Blink with a pin verification code 
1 Like
Awesome, thanks for that clarification. I just re-authed and I have the new style ClientID now. Will report back if I run into any issues.
1 Like
@snell
Sadly I am now unauthorized again. I knew getting that PIN earlier was a nail in the Blink coffin.
I did an Auth again with False set, we'll see. I do have the new format for the ClientID.
If you enable Trace mode you can check the log right after the Authorize. In the headers there are the "answers". When you first Authorize the header should return that the client is not verified:
Authorization headers ...< bunch of stuff >... Client-Verified:0 ... < more stuff >
That means it will need a PIN Verification. Once you perform the PIN verification you should get a similar header:
Pin verification headers ...< bunch of stuff >... Client-Verified:1 ... < more stuff >
It should just be able to reauthorize after that point.
I've updated and followed the instructions. All seems good so far but will see in a couple of days.
I was needing to manually re-authorise every day so I'm hoping this fixes it.
Thanks again
