Probably totally unrelated, but thought I would throw this observation out there. When I was using IFTTT trying to arm or disarm two sync modules sequentially, the second operation would fail almost all the time. Then I put an 8 second delay between the two and it never failed again.
This could very well have been IFTTT/Webhooks doing it (and that's still my best guess), but the possibility exists that Blink debounces commands received on the API.
I will take a look at adding a delay. Not a bad idea to "give it a second" if the first reauth fails.
Also looks like I left some extra debugging in there. More work this weekend, but it will be a good change of pace from my main task (climbing around in the attic replacing and rerouting a bathroom fan).
@nutcracker, I am doing something wrong.
My only options are: HMS Status, Mode Status, Last Updated, and switch. When I choose mode, I get the current mode of my hubitat. I do not see an Arm String option or any way to enter that string.
I was trying to setup this last night and not able to. I've got a virtual switch and tried creating a new Rule.. I assume I need 3 rules but hopefully I'm wrong.. 1 to set the switch to the "armed" value of a camera. 2 to call "setArmed" if switch is turned on and "disarm" if turned off. Anyway, I could use some pointers how to accomplish this with the rule manager if you've got time.
The end goal in my case is to be able to arm/disarm the system via google voice.. I assume Google Voice needs a switch to know what to do with it
I deleted the partially working Blink device and decided to try again.
hub logs:
dev:3642020-10-08 02:50:19.091 pm traceBlink - PIN response = {"account":{"id":36734,"verification_required":false,"new_account":false},"client":{"id":545742,"verification_required":false},"authtoken":{"authtoken":"<SNIP>","message":"auth"},"region":{"tier":"u008","description":"United States","code":"us"},"lockout_time_remaining":0,"force_password_reset":false,"allow_pin_resend_seconds":60}
dev:3642020-10-08 02:50:18.257 pm traceBlink - ClientID = 51385968-5859-6659-5993-<SNIP>
dev:3642020-10-08 02:50:18.240 pm infoBlink - Requesting PIN for validation.
dev:3642020-10-08 02:49:45.880 pm debugBlink - Driver version up to date
@snell - this response makes it look like the server doesn't need any additional verification. Does the driver look at that value?
"verification_required":false
I did hit 'get homescreen' button and everything was fetched correctly.. so, ultimately I think everything is working. But, the hourly refresh is failing because I never entered a PIN:
So in my above screenshot, the Blink ArmDisArm is the name of my virtual switch.
You add that to your dashboard using the below:
To see the status of the Blink system, you need to use the Network child device. For illustration purposes, I've called this House.
On the dashboard, you do the following:
Use RM or Simple Automation Rules to control it. See my other reply on that!
So in my earlier screenshot, the Blink ArmDisArm is the name of my virtual switch.
I have a RM rule that when the status of the switch changes, it informs the Blink system to arm/disarm.
I use Simple Automation Rules to control when the Blink system is armed/disarmed. Here's an example of arming.
If the mode is Day and I leave the house, I also have this RM rule:
These are just examples that I'm using to test the great work that @snell has put together!
Hope that helps!
Unfortunately I do not have enough evidence one way or another with the verification_required to know for sure... Which is why I have been trying to err on the side of caution.
But I have already altered my code so that when the next version comes out, it should no longer as for a PIN if the device has already been Verified from a successful response. This should help with the Refresh issue. Previously I had it make sure email and password were set, client ID, then PIN... but we have enough people proving it can get authorized even without the PIN now.
@nutcracker - thanks for the detailed steps - i'll try that out tomorrow. 1 thing I wasn't sure I see in here though is -- if you arm/disarm Blink from the app (for example) - are you able to update the virtual switch state to match the blink system? Otherwise, would the virtual switch get out of sync with the actual state of the system?
Hi, yes it’s possible that the switch would get out of sync with the actual status of the Blink if you used the app as well. The Blink status on the dashboard will update on the next poll. You would end up in a loop if you watched for the Blink status to change to then update the status of the switch... don’t think you can do much about that.
Personally for me, if I can automate the setting of the Blink system as much as possible then I shouldn’t need to use the app itself to arm/disarm.
Just need @snell to get the images/video pulling down and visible now...! 
(either by cracking the driver render issue... or may be turning this into an app/driver setup???)
No pressure. I REALLY do not want to have to learn apps for some reason, but I really want the thumbnail to be available. It is really annoying to me that I have the data but cannot figure out how to display it readily. There needs to be a functional "image" attribute.
Maybe I need to submit that as a feature request.
I was wondering about that a while back.. are you getting the actual image data? and then are you looking to return an image URL that can be used by a dashboard?
Not sure about storage on HE - but can the data be saved to the hub using some name that won't lead to multiple image files per camera (ie: filling up storage)? Or, maybe it'd be possible to upload it to an image sharing service like imgbb.com? (the latter might not be ideal for security reasons though..)
It is indeed receiving the image data (it takes a bit also). The hub does not allow storing image files locally from a driver (at this time). You CAN store files from Rules, but that does not help in this case (because of the auth-token needing to be in the header not the URL).
Not sure about sending it elsewhere, like you said it seems like a security risk. If/when it is possible to save the image file locally (it IS just a jpg) it would be very easy to name them specifically so they would just get overwritten (like they currently do when you take a new thumbnail). They are not very large.
I am trying to follow your example from above on how to use this in RM. I am fairly new to HE but have been learning a lot in the last couple of weeks.
My question is this. What action are you choosing in the drop down to be able to put "ArmSystem" in as an action?
Here you go, custom action.
Select the Actuator to be the Blink network device and from there you can choose ArmSystem.
Perfect! Thanks so much for the help and quick responses. Great community here!
This seems new - it happens when I try to call arm or disarm on any of the camera devices. This was working before - not sure what changed.. I did remove and re-add the device last week. I also confirmed that the armed state didn't change via the Blink app
dev:3642020-10-11 02:24:37.229 pm errorjava.lang.Exception: No response data exists for async request on line 1192 (GeneralResponse)
dev:3642020-10-11 02:24:36.791 pm traceBlink - Disarm System Params = [uri:https://rest-u008.immedia-semi.com/api/v1/accounts/36734/networks/39640/state/disarm, headers:[token-auth:<SNIP>]]
Download the Hubitat app
