The previous answer to this question was, in my opinion, inaccurate. There is also a homebridge plugin for blink, and not knowing the IP address of your raspberry pi (or hubitat) is no guarantee this project, or any homebridge plugin, will not get shut down. As can be seen from the github page for that homebridge plugin, blink regularly monitors the requests to their server. Should they find anything that is outside of an official integration, they have been known to block user accounts. Until the offending integration is removed you would then be without access to your blink cameras.
I have the latest drivers, but new cameras are not being added to hubitat. Granted, these are the same cameras I DID have added, but I needed to switch to a new sync module. Since then, even after removing the old devices in hubitat and pressing gethomescreen and any other button, there is no updated list of cameras.
Would you mind sending me a copy of the log for when you run the GetHomescreen command? I wonder if the API is reporting them differently somehow and the driver cannot account for it...
If there is a private message capability here I am not seeing it, otherwise I'll post it
Just FYI I see the missing cameras (Porch and Garage) in this data, but they are not being created as child devices.
How so?
Everything after the quote.
To which post are you referring?
Quoting specific posts in your own replies can help avoid confusion.
1 Like
Well I was replying to the person who asked, so I know they’ll know. But someone asked how do we know this integration won’t be shut down like the rboy smartthings integration. The answer was that the smartthings cloud is a known address and that essentially blink would need to end the internet to prevent this integration. Going off of the numerous people with blocked accounts for the home bridge plug-in, that is not the case. Blink is able to differentiate between their official channels and unofficial integrations in some way. I don’t know how this integration was managed but it stands to reason Blink may block a user at any point for a violation of their TOS
It is true that an individual user could be blocked, but blocking the entire Hubitat user base would be infinitely harder than blocking a cloud dependent user base. Easy to attack an answer if you ignore full scope of the question and answer.
Well considering I didn’t attack your answer, nor did you give the full scope, I think I’m good here. The person to which you responded may have appreciated having that additional information. Which, you’ll notice, is why I said, in my opinion.
Updated Version(s):
- BlinkAPI.groovy = 0.2.8
Change(s):
- Found a couple instances where if your child device (camera or minicamera) did not have it's Network ID yet it would cause a null error. These have been corrected.
- Added a new preference Use Custom Labels for Children.
- Disabled by default, the child labels are based on the names returned from the API. Either the defaults or whatever you have set them to be in Blink. The downside is that if you set your own label in Hubitat it will get overwritten by what the API responded with (in case you ever changed it on Blink).
- If Enabled, you can set your own labels for the children and they will NOT be changed by the API response unless they are blank. So a newly created camera may not have a label yet. If you do not add one, it will get whatever the API provides. If you set a label for it (or change an existing one) the driver will leave that alone and not override it. Of course if you change a device in the Blink app, it will not be changed on the corresponding child.
2 Likes
I’ve just installed this driver and it works great! Nice work!
Really hoping you will be able to find how motion notifications are transmitted. I have a use case where that would be very useful - High winds move the support for my camera and I get a lot of “false” motion events. I could just disable when wind speed is above a certain number, but what I really want to do is to combine this with a high number of notifications, and then disarm the camera until the wind dies down a bit...
I really hope there is a way... but I have not seen any sign of it in any of the API responses to date. Maybe there is some method to check for it that nobody has found yet (the API is undocumented after all) or they are using some other method like a websocket event.
That and thumbnails... the two big gotchas even I want.
2 Likes
Hi, I just tried changing the device label of my cameras and noticed they keep getting reset back to the original name I gave them. Is this a known issue? I'm on the latest version of the drivers
I haven't tried changing the device name field - just the label
I think you need to enable the following button in the parent device to keep the custom name/label:
As @Sebastien stated, you need to enable the "Use Custom Labels for Children" option. Otherwise the driver assumes you want whatever the API returns as the label for that device (which would keep it synched with the app, but may not be what you want Hubitat to show).
Of course if you enable this it will not change if you change it in the app from now on (until disabled).
1 Like
thanks guys! i feel dumb for not seeing that option now.. i didn't think about changing the name in the app either.. i just thought the names listed were custom names I gave the cameras through the driver a while ago
1 Like
No worries. That is a fairly new feature specifically for the scenario you ran into.
I would like to share it with the community an issue I am having. I am using RM with my garage door (Ring Contact) to disable my cameras while I am taking the trash out and enable them back once I close the garage door. I have seen issues of enabling/disabling the cameras not being effective so I created an action to notify me if the cameras have not been enabled back after I close my garage door.
I have no problem disabling the cameras when I open the garage door. However, when I close the garage door to enable the cameras, I noticed an additional action (almost simultaneously) to turn them off before finally are turned on. I started with 2 min delay for the notification but looking the events I needed at least 2min and 5 seconds for the final notification. Please see both cameras event below, the trigger to turn them ON both cameras was recorded at 2021-01-03 07:39:19.625 pm
I am OK living with the delay but just want to see if this is normal or there is anything I need to do on my end. Thanks everyone for your help.
