Corrected handling for battery "ok" handling... not sure how this was missed for so long. Also changed it to report the "BatteryValue" event, with that being added as an attribute in the applicable child drivers
Updated Tile, event, and state methods in all child drivers
Updated event and state methods in parent driver (for both the parent and sending to the children)
Updated the default "User-Agent" that will be used for communicating with the Blink servers.
Note(s):
@Bloodtick_Jones: Changed the battery handling, thanks for pointing that out (I have no idea how long this has sat unchanged and unnoticed). The BatteryValue should now be an attribute (I am trying to no longer use spaces in new attributes, which is also helped by the way Hubitat's new UI displays them).
@Terk: Mini cameras cannot have their motion enabled/disabled directly. It does not work (never has, and to my knowledge nobody has ever figured out why). The Rosie device you see is the pan-tilt mount associated with a mini camera. However, there is no controls known within the API to handle the Rosie... so it is effectively a placeholder using the BlinkChild driver. BlinkChild has more commands than can be used with it because it is meant to be a generic "placeholder" driver until something better can be made for individual devices. Unfortunately, nothing better has been possible for a Rosie yet (I have one myself).
Ever since Package Manager updated the drivers 2 days ago, the battery level on all 6 of my Blink Gen 4 cameras are at 75%. If I open each camera in device manager and run Get Camera Info it updates to the correct level, some are 25%. As soon as I exit, it goes back to 75%. I've reboot Hubitat and the Blink Sync Module. API driver is at 0.5.27, Network is 0.1.5 and SyncModeule is 0.1.4. Any suggestions?
I did make a change to the Battery-related code in the latest release. It appears in this case your devices are getting their battery info in two methods. One is the "battery" value the API returns, which is an "OK" or not value that I translate to 75% or 0%. The second (IF provided) is the "battery_voltage" which equates to a greater range of possible % (where the 25% comes from).
So basically, what is happening is that some of your devices are getting the "OK" and some are also getting the voltage (which also has 75% as a possible value).
I will have to make a change to ignore the "OK" data if it has the voltage data... I think I had that before but removed it (because I forgot the reason for it) when I made the change.
That sounds like what happened. I have a Hubitat Dashboard where the device is a Blink camera and template is "Battery". It used to show 25%, 50%, 75% and 90%. I found it very helpful to know approximately where the levels were. It would be great if I could get that feature back. Thank you!
Yes, it is coming back. I already did a fix on my Hubitat and am just letting it sit a couple days to make sure it seems to be working properly (since I did not notice I broke it).
Changed checking for the API's return of the battery state. It will prioritize setting the value based on the battery voltage data if provided (that will always set the battery value). But if it returns the other "ok" method it will set battery to "75%". If that method returns the failure/battery bad notices, it will check the battery state variable first and only set it to 0% if the value is null OR if it was 75% (so it had been "ok" before, most likely). So this could still get some flipping in some cases... but it should minimize it while allowing devices that only do ok/bad to be give a battery value.
Hopefully you have installed the driver via the HPM (Hubitat Package Manager) app.
Open the app and click Update.
There will be a list of all updates for your system from contributors and you can tick what you want and update.
If you used HPM, you can do what @dnickel indicated.
If you do not use HPM (I do not use HPM myself), it is not too bad:
Go to the Drivers code page on Hubitat
Select the driver in question
On the code page that will display, choose the ... menu option on the top right of the code window (next to save) and select the Import option
The Import window will appear (all of my drivers have an Import URL defined) and select the Import button
Click Yes to override the code already in the editor, then hit the Save button for the code
The driver is now updated. You will NOT see the updated version # nor update message go away from the device for ~24 hours. To minimize checks I only run that once a day. If you want to "force" the version to be updated you can Save Preferences for the device (that will set the version to whatever the driver code is).
Null state variable checking around some things within the ProcessVideoEvents command (thanks to @hrgauthier for sending me logs on this, although I still do not know why it could have happened).
Removal of "Forced" event code that was common to other drivers but not used in this one and is being removed (slowly) from the others as well.
I'm just configuring my first Hubitat device (C-8 Pro). I am trying to add my Blink cameras.
After step 5 of the setup, where I am Verifying the Pin from Blink, I see the following in my log: "error" and "400 from Blink".
I've tried this twice. I run the Authorize command with "false". Then I get texted the pin from Blink, so I enter the pin in the Verify PIN command and run it. My "Status" field under "State Variables" remains "Still requires PIN verification." and if I look at the log, I see a "400 from Blink" with the corresponding time I ran the Verify PIN.
I am definitely sending the pin before it times out.
Did Blink perhaps change the authorization process on their end?
Fantastic work! Everything ran as expected and all child devices were created per my setup.
Do you have an up-to-date post/doc anywhere (I looked in here but it's rather lengthy and I couldn't find what I was after) as to what at this now-mature stage of development we can do with it. For example:
what triggers are useful
what works fully and what doesn't (perhaps motion notification or thumbnails)
ideas for rules
For me, and I'm still dabbling so may well stumble upon it myself, I'd like to trigger a rule based on a doorbell push. I tried 'digital switch' but alas that didn't fire. I also tried a custom attribute (which is a rich and lengthy enumeration to say the least) but haven't found the right attribute to trigger off of yet.
