Hmm... not sure how I would get that at this time. Right now the driver only polls the API for status information, it does not have a way to receive PUSH notifications (and Hubitat is more geared towards receiving responses than unsolicited broadcasts).
It MAY be possible with a websocket... but I do not have much experience with those. Nor do I have one of the doorbells (or almost any devices yet) so I do not know how the data might show up. Heck, I do not even have a Doorbell child device yet since I have not received any data samples that include it.
If you want to shoot me a PM with a Trace log of the response to the GetProtectInfo command, I can try to start building something.
Just a word of caution... the Protect API has even less data about it out there than the Network API... but I am willing to try.
EDITED AGAIN WITH CHANGED DRIVERS Updated Version(s):
UnifiProtectAPI.groovy = 0.2.5
UnifiProtectChild.groovy = 0.1.5
UnifiProtectChild-Light.groovy = 0.1.2
UnifiProtectChild-Bridge.groovy = 0.1.2 NEW, will be added to initial post
UnifiProtectChild-Camera.groovy = 0.1.3 NEW, will be added to initial post
UnifiProtectChild-Doorbell.groovy = 0.1.2 NEW, will be added to initial post
Change(s):
Added support for Doorbell separate from Cameras, with both now having child drivers.
Added child driver for Bridges
Moved device data processing from the child drivers to the parent driver, more in line with my Unifi Network driver.
Changed driver version checking method to my latest variety
Changed the method for Tile Templates (what used to be HTML Tile Templates) to my newer style due to the changes Hubitat made removing HTML from Preferences
Added the Unifi Protect drivers into HPM (Hubitat Package Manager) with the few of my other drivers in there. You will likely need to refresh the repository for it to show properly (mostly useful for users that are installing the drivers new)
Additional Change(s)
WebSocket support has been added to the parent driver. The complicated bits (decoding the byte data and such) are all provided from @tomw's Unifi Protect driver
WebSockets are providing immediate notification of events. At present that adds immediate motion detection to the camera, doorbell, and floodlight instead of the delayed method relying on refreshes. Additional notifications for light/dark, lastRing (a workaround for doorbell button based on @tomw's, I do not the real point to look at yet), is the camera recording, is the light on (floodlight), are also being gathered and used to show as events on the child devices
WebSockets are enabled by default in the Parent device although you will likely need to Save Preferences (if you already have the driver installed) just to make sure. If you do not want them, they can be disabled
The WebSocket connection is re-connected after each refresh although that frequency does not appear necessary (as a test mine was left on Manual refresh, and 4 hours later the WebSocket was still providing notifications)
Additional attributes were added to the Camera and Doorbell child drivers to support additional data the WebSockets provided
Doorbell child driver now has the Pushable Button capability as well
Second Set of Added Change(s):
Removed attributes and capabilities from Bridge, Camera, and Doorbell that they cannot perform that were originally based on the Light device.
Bridge cannot do much of anything anymore as the Protect interface does not really allow them to do much (they are just a "bridge" for when a new Protect device is being added to the system, nothing more). I may deprecate creating them as child devices in the future if there is not any value to having them. There is far more control over them from the Network driver side.
Camera and Doorbell have gained some preferences in order to save settings applicable to them. Namely things like the microphone sensitivity, whether they make system sounds, and such. No new commands or capabilities at this time.
I have never really tried as I only use my main account (I do not have multiple people allowed any access)... That said, I just tried a bit using the default roles:
Administrator role can read all data (which will create child devices if enabled), control features
Viewer role can read all data (which will create child devices if enabled) but cannot control features (they get a 403 Unauthorized error)
Member role cannot read data nor control features
Creating a Test role and setting application-specific settings:
UnifiOS - Does not appear to need any permissions (None worked fine)
Protect
Full Management - Allowed full read and control capabilities
View Only - Allowed read but could not control anything
Is "Enable WebSocket Monitoring" preference enabled for the parent device? That is required for notification-based detection. Otherwise it has to wait for the polling, which is pretty useless for motion detection.
I've applied the new version and let it run for a while, and strangely I'm get very occasional notifications from Camera #1 (by which I mean possibly once per day) and nothing from Camera #2
This is despite both Cameras being next to each other and pointing in exactly the same direction with exactly the same settings, whilst I'm testing. Notification from Unifi Protect work fine
Hmm... To summarize, camera #1 is not responding when it should and #2 never is.
If you set the parent driver to Trace logging, there should be evidence there if the websocket messages are being handled or not. You can message me a sample of those. I only have one camera so I do not know if there is a "weirdness" in the data with more than one. (Tough to justify another small/cheap camera like the instant when I already have Blink cameras around, and the other cameras I might be interested in are out of stock or WAY down my purchase priority list).
Was this when you ran a command manually, a scheduled task, and/or Saved Preferences?
Are you using latest public driver (0.2.7)?
Authenticating (itself) does not access the ReceiveData process... but most data commands DO. The particular line from the error (934) involves uptime data, but it makes no sense that it would error because lines 931-933 each should have errored then and lines 932 and 933 are ALMOST identical even to 934. They are all using the same base value returned to convert it all to a "human readable" uptime (the data provided is the number of seconds).
One request, if you set the parent to Trace logging and send me a private message with the logs when this is happening, it would be appreciated. DO NOT post it in here (they are usually long and can also contain MAC addresses, IPs, and other "secure" data). You can obfuscate anything you want from it but I promise not to look into it any more than trying to figure out why uptime did not work... or if it was some OTHER failure that cascaded to it.
The whole slew of initial errors is because the child driver is not loaded. You need to install the UnifiProtectChild drivers for your respective types of devices. That will cause a bunch of errors as it tries to pass data to them, does not find them, tries to add them, and fails to add them (getting an error).
I am posting a couple updates in a minute here... I also changed the driver not loaded error message to try to be specific about which driver it was looking for in that case.
Change to error logging when a child driver is not found. It will now attempt to include the specific child driver it was looking for in the error message instead of a generic message.
Added ImageCapture capability to both the Camera and Doorbell child drivers so those should now be available on the child devices. This also adds the "take" command to take a picture using the device. What it will try to do is query the API to capture a snapshot from the camera. That image SHOULD be available in the device's page. This required additional code in the parent API driver as well of course.
Known Issue(s):
I do not know a way to get the capture image into a Dashboard at this time. Even if I attempt to select the specific attribute it does not display anything. Still hoping for a workaround but even just having the image on the device's page is a plus in my opinion for the rare times I want to check.
Actually I can confirm you have a bridge. It shows up in your data as a Lite access point. Access points are added as bridges by default in Unifi Protect. You CAN disable them in the system (not via the drivers) if you really want. There is not really much you can do with them from the API... but I made them children just in case they came up and in case they ever DID get any features.
BUT... checking your bridge data just now did make me find where the uptime error was coming from. For some reason your bridge has a null value for the uptime(?!) so I will make a quick change to ignore null uptimes... Expect a new version for the parent in a few minutes.
