@nutcracker:
Ok. One more question then, which device are you showing on your dashboard for it? The parent device or one of the children? Right now there are minimal Events pushed to the parent device (certainly not arm/disarm or enable/disable directly) because they are for the children. There is an Event that should show which systems/cameras are armed/enabled but that had a flaw that should be fixed when I release the updated version in a little bit.
future question.. any idea how fetching thumbnails would work? I'm guessing you can't just return the URL since it had the auth token in it.. or maybe that it possible. it's certainly be the easiest way.
anyway just curious
Updated Version(s):
BlinkAPI.groovy = 0.1.7
Change(s):
- Logging level now set correctly for video events, still not being processed yet though
- Revision to the General Response handling (for arm/disarm & enable/disable) so those SHOULD be all set now for their responses. It should help with not seeing an updated status for them when triggered within Hubitat (does not affect polling for other changes though).
- Addition of GetNetworkStatus. This now polls information regarding a network specified (or all if none specified) for the account. This also includes the name of the Network(s) so people should see the label for those changed correctly. The only piece of new information included was a "Deleted" field that seems to indicate when a network was deleted in the account. Maybe Blink keeps old ones around and just flags them as deleted? Will just have to see how that all functions if someone has such a thing.
Different Topic(s):
- @jpage4500: That is one thing I am trying to figure out. My tests on my own devices did not appear to work for just using a URL like that (or trying from browsers) so it is not quite as easy as I hoped because of the auth-token. I have gotten some recommendations of things to look at. My goal would be to provide the thumbnails though, that is for sure.
2 Likes
See above:
@snell just updated to the latest version and network status is being reported correctly now! Thank you.
One other thing, on my dashboard Iām showing the updated attribute from the network child device so I can see the date/time stamp of when the network status changed. Is it possible for this field to be updated as well?
Thanks!
Itās possible to obtain the image data from Blink but youād need to set the content type to an image to be able to pipe it to the web browser. Back in the day, Iāve built a web portal for ease of access to the thumbnails (and video) but I think Blink pulled it from their forums after asking me to take the hosting of it down.
The challenge once youāve got the image is how to get it to display within HE. The below may help @snell.
I have pulled in the thumbnail data without issue from the URL they provide (with auth-token sent of course). But it is the data itself, so it needs to be put into an actual file for reading since nobody is going to be able to take the giant string and read that as an image. 
Need to make a change for the Updated. While it should be match on the children for most cases I noticed that the GeneralResponse (arm/disarm & enable/disable) only posts an Updated event on the parent. The next update will include that going to the respective children as well.
2 Likes
Following this project with great interest. I have 8 (3 outdoor, 5 indoor) cameras divided over 2 sync modules (inside/outside). Previously I used Rboys integration on Smartthings (until Amazon pulled the plug), now I only use the scheduling in the app but sorely miss automatic arm/disarm based on presence.
Getting motion alerts would be great. Camera thumbnails is nice, but not a necessity for me as I usually open the Blink app when notified about something.
Keep it up!
1 Like
Motion alerts would be tough due to the way the driver polls for data. The lowest poll is set for 5 minute intervals. Plus, I have not identified a field that I can confirm is "there is motion active right now" from the existing data. Of course, there is more data I still need to pull in. I have to think it is there somewhere.
1 Like
So I was playing a bit with the new driver. I have 3 camera's each with their own sync module. What I found is that if I use the parent device to arm/disarm, the Blink camera's respond within 15-20sec. However the dashboard child tiles do not update (also not after the set 5min interval); but if I manually push Get Network Status on the parent device the tiles update immediately. If I arm/disarm via the child device the tiles respond immediately but the Blink camera's do not respond at all (ie they do not arm/disarm).
just curious, why 3 sync modules? was it to have a schedule per camera? I was considering that but was hoping blink would just make it work with 1.. with this new driver I'm hoping I can do that
With the Blink app, one arms/disarms a sync module. The only way to create zones that are armed and disarmed together is to have a sync module for each one.
Me too. And I don't know why they won't, but they haven't.
Updated Version(s):
BlinkAPI.groovy = 0.1.8
BlinkChild.groovy = 0.1.4
Change(s):
- Fixes to response handling for arm/disarm & enable/disable area. This should hopefully make those responses happen properly.
- Added the CheckSyncModule command, does not do a lot except provide more data for the sync modules
- Added the GetCameraLiveView command... which provides the RTSP link for the video feed, but RTSP is not handled by the dashboard or really any browser so you would need to feed it to something else or convert it before it expires.
- Finished adding in all the additional attributes from the Camera Info.
4 Likes
When arm/disarming of Blink, what device/attribute should we now use to determine the date/time of last status change? I was using the ānetworkā child device, attribute of āupdatedā but in the last driver update this is set to null. Is there such a thing now?
Iāve also noticed that for camera devices, battery status attribute returns a number where as before it showed āokā. All fine if thatās what itās meant to be now... I have a RM rule that detects for battery level changes.
Update: actually, it looks like the battery status changes every 10mins (as per my schedule) from āokā to a number... 10 mins later, switches to āokā and then a number.
Correct. Besides I found that the signal range of the sync module/camera is rather limited rendering it irresponsive at times.
With the new drivers it works. Using the child device to arm/disarm the drivers correctly update the dashboard and the camera (it doesn't update the dashboard using the parent device which might be useful to arm/disarm all my camera's/sync modules at once but I guess that is how it was designed). Now the only thing I am missing is that the driver updates the status when I arm/disarm from the Blink app (which it does not seem to do)..... would that be possible?
Let me see if I can answer in order:
@nutcracker:
Updated should still exist for the children as well, I do not think I even changed anything there (it should also populate for the Parent, any time a child is updated). I will take a look. As for the battery... Ugh. That means that there are multiple battery responses spread across the data (I have been focused on getting all the data in first before consolidating). One of them must be returning OK but something else responds with numbers, so it is getting swapped around a bunch. I will have to pick one. Any preference?
@joeysliamg:
Glad to hear it is working better... I hate to be the bearer of bad news, but there is really no way for detecting changes made by the app UNLESS a poll occurs. If you make the change, then the Hubitat driver polls... it will show the latest the API has regardless of how it got set. But that response will be delayed by the polling interval at least.
1 Like
Thanks for the quick feedback. The poll didn't seem to work but I will try to do some testing later. In ST this was working via IFTT (and RBoy's device handler) but the whole point for me is to abandon IFTT. No worries....your drivers are already capable of integrating which is great stuff! Thanks.
1 Like
Could we have both? Visually knowing the batteries are āOkā is good... but knowing that they are at a 1 (not sure what the level is before Blink says change them - but knowing they are moving that way is useful if you know what I mean...).
@joeysliamg:
Hmm... poll should be working off of the Homescreen data, which is supposed to be a general overview of everything. I will have to put that on the list for tonight.
@nutcracker:
Yup. I generally prefer to have all data reported somewhere unless it really is of no apparent use. BUT... I can only report one of them to the "battery" event so it can be easily used in Rules and such. Since that is expecting % value, I will have to figure out which to include there. There is actually ANOTHER battery related value reported "Battery Voltage". Looking over my 3 cameras:
- Camera 1 has Battery Number = 3, Battery Status = ok (or a number at times), Battery Voltage = 165
- Camera 2 has Battery Number = 3, Battery Status = ok (or a number at times), Battery Voltage = 167
- Camera 3 has Battery Number = 3, Battery Status = low (or a number at times), Battery Voltage = 134
If I assume the max battery voltage is ~3v (MAYBE 300 here?) due to there being 2 regular AA in series... I could work a % value from there (although if those 160s represent 1.6x volts... that seems pretty low and they say OK). I will have to see what happens when I change out the batteries in #3 and separate out what the # value shown in Battery Status is also.
2 Likes
