[PROJECT] Driver for Blink API

ARG! I just saw that in one of the other logs I was getting. That error on line 1391 is preventing multiple people from having theirs work properly... although I am not sure how mine DID. I have immediately tried to fix this. Please let me know if the new version solves it!

Updated Version:
BlinkAPI.groovy. = 0.1.11

Change:

  • It includes a fix that hopefully SHOULD prevent the 1391 error, if one of you folks can give it a quick try I would appreciate it (mine did not get it, but mine did not get the previous error either). Because this is such a "show stopper" there are no other fixes in this one. I am still working on another driver update likely for tomorrow at this point.
1 Like

It worked - all my cameras are there and no errors. Thanks!

edit - Also wanted to report that I do have 2 modules in my setup and both work for arming and disarming independently of each other as expected.

2 Likes

@iboma1:
THANK YOU! That is great news for both things. I will wait to see if it solves a couple of the other people having issues but thank you very much for the quick response.

1 Like

Updated Version(s):
BlinkAPI.groovy. = 0.1.12

Change(s):

  • Polling for both the Homescreen (refresh) or DailyCheck (all the general data) should not occur if the Verified state variable is "false". This should effectively pause the polling for data if your system has not been authorized yet or has failed to reauthorize 5 times. Verified is "true" if you verify your PIN successfully OR if you get successful data back from any command (meaning your system already has a valid auth-token, PIN or not).
  • The command "ListSchedules" has been added to the parent. It will push all the Schedule data for the respective Network(s) to the Network child(ren). Nothing that can be done with it at this time and I do not understand everything it contains. My goal is to make it so that schedules can be enabled/disabled in the future but I doubt I will make it possible to update them.

Known Issue(s):

  • I am adding this area this time around because there is an issue I noticed that I have been trying to resolve unsuccessfully. It is not a "break the driver" problem like the last couple but I am finding it difficult to deal with. Anyways, this is for the "Armed System(s)" and "Camera(s) With Motion Enabled" Events on the parent device. These are intended to show the list of which Network(s) and Camera(s) are Armed/Enabled by ID. It seems to work great if you only have 1 of each. Unfortunately, if you have more than one it can have issues where it will not necessarily show all the IDs Armed/Enabled (it does not add extras or invalid ones that I have seen, just does not add ones that should be added). I even am pretty sure why this is happening. The HTTP commands used are asynchttp. Meaning the responses can come back at any time and need to be handled then. What I think appears to be happening (from my logs) is that the responses are so close the Hubitat does not have time to complete setting the variable for one when the other starts working, so there is overlap. I have tried a bunch of ways to deal with it but decided to just let it go for now. The child devices have their states correct as is, so anyone relying on those is good anyways. This was just trying to be one more way to just "glance at the whole system".
2 Likes

Updated Version(s):
BlinkAPI.groovy = 0.1.13
BlinkChild.groovy = 0.1.7

Change(s) to BlinkAPI.groovy:

  • Tweaks to GeneralResponse to try to make it a bit cleaner (also was attempting to get the known issue solved, unsuccessfully).
  • Additional error checking performed in commands, mostly to make sure Network ID is not going to be null for requests that need it.
  • Passing an initial estimate of a battery % to the children, based on values returned as battery_voltage. These are ROUGH % values at this time, so once I see more data regarding what possible values there are and what ACTUALLY triggers the low notice I will update them.

Change(s) to BlinkChild.groovy:

  • Additional error checking and logging descriptions for existing commands.
  • Added the GetCameraInfo command. This gets a fairly large amount of data back, but the vast majority of it will be dumped as state variables at this time. As a note, I am leaving MOST things as state variables unless people ask for them to be "promoted" to events.

Known Issue(s):

  • Still having the issue where the Armed System(s) and Camera(s) With Motion Detection lists may not be populated correctly.
  • Still unable to get thumbnail images displayed correctly. Just so you folks know I am still working on such things. This was actually the vast majority of my time, but I had no success (I think I can get the data just fine, just cannot make it USEFUL). These commands are still commented out.
2 Likes

I noticed the refresh rate isn't working for me. I have it set to every hour. But, looking at the logs I see these entries show up every hour:

dev:3572020-10-07 02:17:06.183 pm errorBlink - Select the Request PIN command to request a PIN be emailed to you from Blink.
dev:3572020-10-07 02:17:06.172 pm traceBlink - Has ClientID
dev:3572020-10-07 02:17:06.171 pm traceBlink - Has Email and Password

I am able to manually arm/disarm the system though via the devices page (camera -> arm/disarm)

Back when I installed the driver I never needed to enter a PIN -- I didn't get one actually but the driver was just able to connect and fetch everything it needs. I can delete the device and re-add if that might fix things too

I am going to start off by saying I am not a programmer nor do I have any interest in it. That being said, is there a way that I can get a dashboard icon for the Blink Sync Module that shows if it is armed or disarmed, and be able to toggle it by tapping on the icon?

I can do a virtual switch to arm/disarm. But that would only give me the status of the switch. Not if the system are armed by other means.

Yes you can show the status of whether your Blink is armed/disarmed by referencing your network device and the Arm String attribute.

Alternatively, you can use a virtual switch like this that will tell you if its on or off...
image
image

As @nutcracker mentioned, you could get the status. But at the moment there is no built-in switch, you are stuck with the virtual switch.

The closest capability would be the "SecurityKeypad" which provides the ability to Disarm, Arm Home, or Arm Away. It comes with a bunch of other commands for codes and such, which would not be used. I can add it on my list, as it does make sense to make it easy to arm/disarm AND have that be displayed easily from a dashboard.

1 Like

@snell I noticed that my Blink system didn’t automatically disarm this morning.

Disarming cannot be done, Network-????? network ID is unknown

I was able to disarm/arm fine manually.

Hmm... Looking over the code related to that error message... Just to confirm:

  1. You were using a Rule to trigger the disarm.
  2. The Rule is targeting a specific Network child.
  3. The child's DNI is NOT Network-?????, you just put the ????? instead of the ID #. If the child really is named that... What the heck!?
  4. The child does not have a state variable "Network ID".
  5. You manually disarmed it using the exact same
    child device and it work.

First thing I noticed is my code has a dumb mistake for that area, I forgot to put "break" statements in the switch section. So you could get that error even if it worked.

Second... It should have worked with a Network child because it gets the ID from the second portion of the DNI and passes that to the parent command. No matter what, I need to add a logging in that portion to make sure it worked.

Did your log show any reauth attempt or other messages around this area from the parent? I have it try to rerun a command if it reauthorized (the initial command hit unauthorized) but maybe I have a bug there somewhere? Tough to test when the code automatically gets it reauthorized and I cannot check that portion for another 24+ hrs.

Yes I'm using a Simple Automation Rule that detects the change of the Mode state which in turn changes the state of a virtual switch. This allows me to also control the Blink via the dashboard. A RM rule detects the change of the virtual switch that calls either ArmSystem or DisArmSystem on the Network child device.

Yes the Network child DNI is a number (and not ?), like Network-12345.

Looking back further in the log, I can see the below. So may be it did work... I wonder if you should add a small delay in between each retry attempt? (to avoid hammering the servers).

Let us know when the new version is up and I'll update and monitor this end.

dev:8652020-10-08 07:16:25.380 debugBlink - Camera List = [11111,22222,33333,44444,55555]

dev:8652020-10-08 07:16:25.045 debugBlink - Camera List = [11111,22222,33333,44444,55555]

dev:8652020-10-08 07:16:24.707 debugBlink - Camera List = [11111,22222,33333,44444,55555]

dev:8652020-10-08 07:15:58.354 debugBlink - Camera List = [11111,22222,33333,44444,55555]

dev:8652020-10-08 07:15:56.529 debugBlink - Camera List = [11111,22222,33333,44444,55555]

dev:8652020-10-08 07:15:56.275 debugBlink - SyncModule List = [55555]

dev:8652020-10-08 07:15:56.067 infoBlink - Reauthorizing auth-token.

dev:8652020-10-08 07:15:56.064 errorBlink - Unauthorized

dev:8652020-10-08 07:15:55.839 errorBlink - 429 from Blink

dev:8652020-10-08 07:15:55.726 infoBlink - Reauthorizing auth-token.

dev:8652020-10-08 07:15:55.723 errorBlink - Unauthorized

dev:8652020-10-08 07:15:55.385 infoBlink - Reauthorizing auth-token.

dev:8652020-10-08 07:15:55.376 errorBlink - Unauthorized

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).

1 Like

@nutcracker, I am doing something wrong.

  • I add my tile and I choose my Blink Device
  • I pick a template and choose Attribute

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.

1 Like

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.

  • added driver
  • enter email/pass and hit request PIN
  • I never got any verification email.. the last one I received was when I initially added this driver a few weeks ago but haven't gotten one since

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!

1 Like

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.

2 Likes