[PROJECT] Driver for Blink API

I did not even know there WAS a catalina! I did not remember that type (I thought my xt was in the category for first outdoor camera). Looking back in the thread I do see two previous references people sent in logs though. Huh...

If the clips are not stored on Blink's servers... is the app able to get them?

Different thing to check... Your camera's DNI is actually "Camera-871516" correct? No space in it?

Lastly, can you send me a message with the Trace logging when you run the command? In particular I am interested in the line that starts with "New Video response for".

Yes. There is a tab for Blink Sync Module 2's that have an attached USB thumb stick. Looks like this in the app (note the absence of a thumbnail in the clip list).

Correct, looks like this
image

Will do. Did not see that line though EDIT: ok found it.

I think it's because the app caches images so if the URL doesn't change it'll just use the cached version. I have an image tile which adds logic to force refresh the image every X seconds (user configurable)

I will get the latest driver and test it out (possibly today but I've got kids activities so it might be this week). I can add an option to auto-refresh and default it to something. How often does the image update?

I sent you a separate message going into this in more detail, including about the image tile (I tried it in my HD+). But it sounds like what I was thinking might be it (cached images).

There is no specific refresh interval for the thumbnail as it is manually triggered (or by a Rule or such). I am not making it an automatic thing at this time. So if there was an auto-refresh interval that could be set (like the image Tile) OR the image tile used (depending on what I mention in my message) then it could be handled that way.

I had a thought.. if the thumbnail/image URL had a timestamp in it -- like the one for Thumbnail File that would work for the caching logic. Meaning if the Thumbnail attribute added ?ts=1698672204&ext= to the end of the image URL then HD+ would reload the image whenever the ts= value changes but would still cache it when it doesn't. Which seems like a good idea since the image may never change or could change often in a future driver update.

Thumbnail: <img height=\"25%\" width=\"25%\" src=\"http://192.168.0.201/local/Camera-89002_Image.jpg\">
...
Thumbnail File : /api/v3/media/accounts/36734/networks/39640/xt2/89002/thumbnail/thumbnail.jpg?ts=1698672204&ext=

Hi @snell - I have some changes almost ready for the new Blink image attribute.. hopefully OK that I post them here but I'll post to HD+ thread when deployed.

I'm displaying the image from Thumbnail if it's present

When you click on the tile I'm showing this detail screen which lets you arm/disarm, enable/disable motion and also an option to update the image (it calls GetNewThumbnail on the driver)

The only thing that would help is if you can add the timestamp to the URL in Thumbnail attribute. If that's not possible I can try to manually do it using the Thumbnail File attribute but it'd be a lot messier.. just let me know!


side-note - I haven't looked at the changes in a while; is there any other changes that I could make work/look better? I see a GetCameraLiveView command -- has that changed? I kind of remember a while back that it didn't work for BlinkXT2 cameras

1 Like

Updated Version(s):

  • BlinkAPI.groovy = 0.5.16

Change(s):

  • Added some additional triggers for the "Updated" attribute on parent and child devices.
  • Additional processing of video event data specifically for Doorbell devices.
1 Like

FWIW - I released an update to HD+ to support images

I did add a comment about possibly doing some kind of auto-fetch of the image every X minutes or hours.. I know my cameras at least are battery powered so I wouldn't want to do it too much. But, I can still add the option if it would make this feature better

2 Likes

No changes to the parent driver at all. Just for the generic child driver which is only meant for use if you have an unidentified device. If one of your devices still shows as using BlinkChild, it should work better if you switch to the child-specific driver for that type of device. BlinkChild primarily attempts to handle activities like a Camera. BlinkChild had not seen an update since 2022...

Updated Version(s):

  • BlinkChild.groovy = 0.2.3

Change(s):

  • Revised BlinkChild to perform the new thumbnail capture method.
  • Revised BlinkChild functions to conform to how I currently perform them in the other child drivers.
  • Minor logging cleanup.

While poking around to see about using the new thumbnail option between this driver and the HD+ dashboard I noticed that I have two MiniCamera drivers. They are both the same version and doing a diff compare between them show there are no differences. Not sure how this happened, or if it has any harm. (Or if needed for some code clean up in the next release.)

EDIT: Don't know where the extra driver went, but I am only seeing one now and not two. (And no my coffee wasn't spiked this morning.)

You got photo evidence there... I have no idea how that could have happened either. Maybe a weird visual "fluke" by the Hubitat? Since any driver with the same name will override an existing one (ex: if you had one driver named "Test", but then created a whole new driver and named IT "Test" also you would only have the new one remaining). I do not put versioning or such in the names... so new versions should always overwrite the old ones.

1 Like

Maybe my coffee was spiked. My local hub is fine. I swore I was on my local hub this morning, but I guess I was on my remote hub. That is the hub that has two MiniCamera drivers. Using HPM it says there is an update for the Blink Drivers. I update it and all is well. However if I do a Match Up it finds a Blink Mini Camera driver. When I match that HPM says there is an update for it again. My guess is that it is updating the driver but failing to remove/replace the old one. Is it safe to just delete one of the two and repeat the match up process again?

EDIT: I just deleted one of the extra drivers. Re-matched, and re-updated. I only have 1 driver now and matching/updating doesn't go into that odd loop again.

Very strange behavior indeed. I have no idea how/why that could have happened. Maybe it got out of sync with HPM? I do not know/use HPM much so maybe that is something that can happen (or not).

Hello @snell,

Thanks for creating this driver. I'm looking forward to getting it working and removing my IFTTT integration (which only works with entire systems, not individual cameras).

I am also having the issue described in earlier posts with "Conflict detected" and it seems to be pretty regular and with all devices. I've thought maybe it was because I needed delays between events but that hasn't proven true. It's seemingly random but can happen to any one of my cameras.

For example, I'm working on a rule for turning off my indoor cameras when "Day" is activated. I've done one camera at a time with a 5 second delay between them and still sometimes one or more will remain armed (with this error).

I'm not sure what to do to troubleshoot at this point. The Blink app will disable the camera just fine.

From the log there a LOT of those are happening very close together, within just a few seconds. The "Conflict detected" message is because the API is returning an HTTP 409 error... which, as far as we have managed to figure out, is when too many requests are being sent to the Blink API for your system and it has not completed processing the previous request.

They remain unchanged when this error happens, because the API did not perform the task (it returned the error). If you manually tried that particular camera again after a bit of a wait it likely would work.

How many cameras are you enabling/disabling in a group? The easiest solution is to put a bit more delay between commands in your Rules... since there is not much I can do from my end except maybe force more of a delay than I already have in there (and that only applies when someone uses the "all camera" method, not selecting them individually).

I was doing two at a time with a 5 second delay between them. I wound up creating rules for groups of cameras that I wanted to arm / disarm at the same time (with a momentary virtual switch as the trigger, so I could trigger that switch from other rules) and did one camera at a time with 5 seconds between each change and so far, so good.

1 Like

Where are the beta drivers for Blink?

Are these the latest beta versions (getting from HPM)?

  • Blink Drivers
    • BlinkAPI v0.5.17 (driver)
    • BlinkChild v0.2.3 (driver)
    • BlinkChild-Camera v0.1.5 (driver)
    • BlinkChild-Doorbell v0.1.4 (driver)
    • BlinkChild-Network v0.1.1 (driver)
    • BlinkChild-SyncModule v0.1.1 (driver)

There are no separate beta drivers for this project. On the rare occasion where I do make a driver for someone testing something out specifically, I name them differently and do not publish them. But even that is pretty rare for any of my projects.

So the ones you get off HPM or directly from the links in the first post are going to be the latest.

Silly question as I know the answer :wink:
Still no way to access motion event from a camera?
I'm trying to avoid an outdoor motion sensor to turn on the lights.

Does not hurt to ask. At this time though I still do not know of a way to get a push notification from the API or an alternative method like a websocket. Sorry.