Weird... I have not heard of anyone doing this before so it will be interesting. I assume the UNVR has a different IP and you are going to that one?
Did you try setting it to be a non-Dream Machine controller?
Are you doing anything to support the AI Port? I have one ordered and should be here before to long. Let me know if you need any testing from it in anyway. My understanding is it may be able to support multiple devices including non AI 3rd party cameras.
Depending on how it works out, I can certainly try to add whatever possible to the main driver and of course I can create a child driver to support it. Not something I am going to purchase personally, but happy to work with you to get it added and whatever it does provide. It will be a bit interesting to see if it works out like it is detecting things or if it just acts as an overlay (so detections either it makes a detection or the detections are still on behalf of X camera).
1 Like
Got to do some testing today.
Testing both the Fingerprint sensor and the AI Port associated with my new G4 Doorbell pro.
I know I had asked before about the fingerprint sensor. Just trying it out again and what i noticed in the logs are a few entries that seem to related to a GUID. Here is a example of what I observed.
metadata:[fingerprint:[ulpId:aa8231a0-xxxx-xxxx-xxxx-d4257b0183a2]]
I also saw:
FingerprintUserID = nullnull
Which that of course is useless.
So if we are suppose to use the guid included in the first items where is that found on the device details to run rules against?
From what I can tell right now the big thing the AI Port will enable is Facial and License plate recognition. I only walked in front of it a couple of times and i am getting recognized by the camera now. The facial recognition events it generates currently in HE are simply "SmartDetectType" events with a number.
Only reference i see of them is this in the log:
Unifi Protect - Child Event: smartDetectType = 97, null
Yeah, the huge IDs are what you would have to identify per user and match up with a Rule or something... very painful. Since commands and such are not dynamic (that I know of yet) I cannot come up with a way to cross-reference a user's name and the ID, then populate a command list with User names (or even just the ID) to make it easier to select something for someone. They can also provide a null value when the user's fingerprint is not identified.
If you set it to Trace logging (and feel like punishing yourself with WebSocket events) you can set that and provide whatever information it is sending (I recommend by private message or a separate method) so I can review it and try to make more sense out of it (if possible). Obviously a smartDetectType of 97 is not something I have seen before... It would be interesting if it CAN be more readily tied back to an individual user (especially if they ID, while painful, is matched with a specific profile in general so it gets the same ID whether fingerprint or facial recognition).
Yea.. I Imagine it would be a pain to setup initially. But not to hard if you only have a few users. My point though was though I found that in the logs I don't see it on the devices anywhere for me to match to RM. I was hoping I just missed it. I think preferably at the least we would have a currentState value that gets the Event when the Fingerprint is passed into HE. Something like lastFingerprintSeen. I didn't see anything like that or did I miss it.
In the 2.4.0 beta I brought up the need for dynamic commands again and it looks like the explination may have triggered some tough. Hopefully it is slated for a future release.
As far as getting a cross reference, my first thought would be a parent app that manages all of the setup and then either a flat file or simply a state variable in the parent that contains a map with a way to edit it. Kind of like the Scene extract stuff I deal with on the Govee side though better. I think the biggest issue with that at this point is getting started on a management app that could do that among managing any other stuff that might make sense.
A easier option from a development side I suspect would be to create a simple way for a flat file to be used to load the matching data with Json formatted data in it. Then it would just be a matter of users populating the info as needed and uploading the file. It could be attached to the parent Protect NVR devices and then all of the children could retrieve that data as needed.
That said I am not clear on the concern of dynamic commands with this as I look at this as largely being about just giving a name with the long number or facial recognition id. Is there something I am not thinking about?
I expect that a null value should always be able to be handled because it is very possible someone could try to use it and not be registered or setup. Now I don't think they should just be sending null in that case, but if they are it needs to be handled and it seems like you already got that covered.
When I get another chance to run through some tests and ensure I am generating good testing data I will do that.
I suspect this isn't the case. When I step the fingerprint I had to select a associated profile so it certainly matches back to me and my UI account. I think that is because of the potential Unifi Access tie-ins. When I setup the facial recognition it is a much more basic setup. It is literally 2 fields a star to enable to make the person, a person of interest. Here is the below setup screen shown when setting it up. You can also setup alarms for that person from that screen as shown below
I can see how this make sense in a commercial environment, and why it wouldn't make sense to attach it to a Unifi account local or otherwise, but that doesn't help you or the use case for home users.
The AI port so far has been pretty nice though I do have one fairly big dissapointment. When I decided to get it one of the encouraging things I kept hearing was the ability for one port to support multiple devices. That currently isn't true. It only supports 1:1 right now.
I found this on UI's site this morning with a bit more research.
The ID should be stored in the "FingerprintUserID" attribute/Current State on the Doorbell child device. It gets set if there is a webSocket event of type "fingerprintIdentified" at this time.
Maybe the facial recognition is meant more for tracking someone around an environment between cameras? Ubiquiti is certainly making a stronger push into commercial (and blatant educational) networking environments.
I need to check my setup as this doesn't appear to work for me right now. I don't see the attribute at all or an event for it. The logs from yesterday's test already rolled off the HE so I had to turn to my syslog server. When I searched for the "fingerprintIdentified", I did find two sets of events as shown in the below image from Grafana. All of them are from the Unifi Protect parent devices and nothing from the doorbell.
Here are the details from one set of the events.
Unifi Protect - WebSocket Data = [actionPacket:[actionHeader:[packetType:[1], payloadFormat:[1], deflated:[0], payloadSize:181], actionPayload:[action:add, id:676c3c7203904503e40015ce, modelKey:event, newUpdateId:e3f16413-9f87-4765-9af1-639bacda61a8, recordId:6752570203286203e4004af0, recordModel:camera]], dataPacket:[dataHeader:[packetType:[2], payloadFormat:[1], deflated:[0], payloadSize:354], dataPayload:[camera:6752570203286203e4004af0, end:1735146610909, id:676c3c7203904503e40015ce, isFavorite:null, locked:false, metadata:[fingerprint:[ulpId:aa8231a0-xxxx-xxxx-xxxx-d4257b0183a2]], modelKey:event, partition:null, score:0, smartDetectEvents:[], smartDetectTypes:[], start:1735146610909, type:fingerprintIdentified, user:null]]]
Followed by:
Unifi Protect - No userID found: [camera:6752570203286203e4004af0, end:1735146610909, id:676c3c7203904503e40015ce, isFavorite:null, locked:false, metadata:[fingerprint:[ulpId:aa8231a0-xxxx-xxxx-xxxx-d4257b0183a2]], modelKey:event, partition:null, score:0, smartDetectEvents:[], smartDetectTypes:[], start:1735146610909, type:fingerprintIdentified, user:null]
I then dug into the log server to see if there was any reference to it in the G4 Doorbell device that didn't reference that event as it appeared to be directly related to the webhook.
I found these two events:
Does HE not post null events? Below you can see the devices and the "FingerprintUserID" is not present.
Restarted Unifi Protect to see if that helps kick something to behave better. I have seen mentions of that helping with certain stuff on their forums. I will let you know after my next set of tests.
I think something has changed in Protect since @snell used the info I provided as it isn't working correctly for me currently. I don't have time to do much testing today.
Something interesting I may have just found that could be helpful. I clicked the button to "Get Protect Info" from the Protect Parent device page. It returned a long bootstrap string. In that string I did find my user id information and the GUID that was passed with the Fingerprint event. So that may work for profiles that are established fully in Unifi to link to a name, email address, ect.
I think you are right. I think I found the solution as well.
Lines 445 and 446 need to be replaced in the UnifiProtectAPI driver with
if( Data.dataPacket.dataPayload.metadata.fingerprint.ulpId != null ){
PostEventToChild( "${ Device }", "FingerprintUserID", "${ Data.dataPacket.dataPayload.metadata.fingerprint.ulpId }", null, true )
It looks like Unifi changed the identify key used from userId to ulpId so that just needed to be updated on those two lines. It is showing up now for me.
One thing I am not sure of is if this is a version thing. I am running the latest release of Unifi Protect (5.1.85) on my UCG Max and ER firmware for Unifi OS (4.1.11) and Network (9.0.101).
1 Like
Updated Version(s):
- UnifiProtectAPI.groovy = 0.2.48
Change(s):
- Changed the Fingerprint ID to match the new data seen by @mavrrick58.
- Some additional data handling.
2 Likes
Working again.
Me too.
1 Like
Updated Version(s):
- UnifiProtectAPI.groovy = 0.2.49 0.2.50
Change(s):
- Change to how SmartDetectType string value is created in some scenarios... not sure what I had going on with the old method of it.
- Added a bit of additional data handling (posting to State Variable) for new data coming from the API.
- Added a new websocket type that I saw returned, still need to work out the details of it and what it actually provides before I decide if it needs to become an Event, since it only has appeared with my NVR and has had no actual data associated yet...
- Corrected typo the previous version introduced.
Have been getting an error Excluded attribute image size of attribute > 1024 characters. After some troubleshooting. I can relate it back to the Unifi Camera devices. My troubleshooting is that i turned all the UNIFI protect device both parent and child devices to a disabled state. Then i tried access the application and the error goes away. As soon as i enable the devices the errors are back.
HEre is the driver version i am running for protect
I am running on a C8Pro with latest version
2.4.0.151
Not sure what additional information you need.....
Thanks
Most likely that is caused by an attribute receiving too much data. I assume it is for an image, so something the camera is returning is too big for the attribute being checked to hold and display. However, I am not hitting this with mine, so a bit of investigation is in order. If you want, you can send me information as a message so it does not show to everyone on the thread (if you have any ID information or anything you do not want shared with everyone).
- Which specific device is the error being reported on?
- Is there a specific command being run when the error occurs?
- If it appears to be image related, do you get the error when you use the Take command in the specific child device?
On another note, unrelated to the error... do you actually have every type of Unifi device? You do not need every child driver, only the ones for devices you have (and you can remove the extras that have no devices associated with them).
EDIT:
One correction to this... some attribute types have a limit of 1024 characters but it is not an absolute. So that may not actually be the issue in this case. It could also be impacted if this is being used by something other than just the Hubitat or my drivers themselves.
Is there a way to get the snapshots created by this integration into Dashboards or something of the such. I see that it stores the image to a current state value, but I don't see a method to use that outside of viewing the devices.
Hopefully. It is something I have worked on a few times unsuccessfully. I have a different driver that posts the image to the hub's file manager and then creates a URL for the image attribute to use, which works just fine. But that has not carried over to this driver for some reason.
But your asking has prompted me to start attempting again... so hopefully I will have something soon.
1 Like
Updated Version(s):
- UnifiProtectAPI.groovy = 0.2.51
- UnifiProtectChild.groovy = 0.1.12
- UnifiProtectChild-Camera.groovy = 0.1.12
- UnifiProtectChild-Doorbell.groovy = 0.1.14
- UnifiProtectChild-PTZCamera.groovy = 0.1.2
Change(s):
- Changed how snapshots are handled. Instead of directly posting the image within the child device data it now saves the image to the hub's file manager then sets the image attribute to the URL for that image. This allows it to be used in dashboards easier and should eliminate the >1024 error because the attribute will no longer be a long string containing the image data.
- Thumbnail state variable has been added to provide a small version of the image on the device page. As a state variable it cannot be used on the dashboard or such, but it will still allow someone to see the image on the device's data page.
- The ability to send the results of a WebHook to individual child devices has been added. Courtesy of @mavrrick58, a new command has been added to the parent to allow you to send the Type and Value to a particular Camera ID. These will then show up in the AIRecognitionType and AIRecognitionValue attributes/events for the particular child device. This helps with the newer AI features Ubiquiti is adding that do not appear to be getting added to the WebSocket or other API areas.
- The Tile method has been completely revised on the above child drivers to handle changes to the Hubitat code. There may still be "oddities" so let me know if you spot anything. This updated method will eventually reach all my drivers as I work on them.
2 Likes
