Sounds good. When I get some more time I'll add a good bit more detail and send it to you in a direct message.
If a person doesn't have a newer PTZ camera set up they wont be able to see all of the options when creating a system alarm webhook. This is what it looks like:
You create the alarm and you get a trigger ID for it. You need to have an API key that you send in the header for auth. That's where RM out of the box is a barrier since you cannot add a header there. No auth header no webhook call. Perhaps there is a way hidden in the API to trigger an alarm with the triggerID vs actually making a webhook call. I do not know.
Alarms have lots of options so putting logic in the alarm VS hubitat can make a lot of sense. In the image there I am configuring the alarm to trigger a configured Patrol on a PTZ camera. You can set how many times you want the patrol to run. The patrol has its own configurations on delay between favorites etc. You can configure a patrol to make it sweep the full view etc etc. You can then also stack the actions on the alarm so you can call other webhooks or notify etc. If you have other Unifi products they also have actions. At the moment I do not have Access, the horn or sensors so those are not enabled for me. I'm waiting on availability and delivery.
Yes, I understand you can control the camera. Alarms are out of band and run independently and also show in the logs. For some that has value. I don't see it as a replacement for what you are doing already. More or less just rounding out the feature set.
Thank you for being flexible and open minded... and thank you for your service. I appreciate the hard work.
Not sure what you mean... I just checked my site and the 0.1.14 version of that file is posted, and both the HPM manifest and my own version-tracking json files have the correct version listed.
Addition of basic control over recording mode within each camera device's commands. This will allow you to set the camera to Always be recording or Never be recording. You cannot set it to Schedule within the driver because it requires substantial additional information (the timings) that are easier done in the Protect UI. Plus, you could handle all the scheduling within Rule Machine by just turning the recording from Always to Never as needed... so Schedule becomes irrelevant. It also added an attribute to show the RecordingMode as an event, and it WILL show if the camera is set for Schedule.
Addition of basic control (Enable/Disable) for each of the three streams available. This allows someone to Disable any/all of the streams for a camera device. Even though 3rd party cameras (mine at least) do not show this option in the Protect UI, the API responds and does change them within itself... so maybe that is a hidden feature. In any case, it is now possible to enable/disable the streams. Each device has added attributes to handle events for each of the streams so someone can see if each is Enabled or Disabled. These can each be controlled using other Hubitat means such as Rule Machine. This one also required capturing the Channels data which is shown within the State Variables section for devices.
You should use the UDMP controller type. Almost any newer controller or newer version controller software is going to be that. But there is not a clear differentiation or term I have figured out to use otherwise.
As for 2FA, no, that account would not work. You could create a new account directly on the controller that is locked in as "local" only. That way you do not need to worry about it working from ui.com or in the app, but it will work fine for Hubitat.
Thanks for the info, I'll create the dummy account (hey, guess what my local account name is going to be?!) and get things set up. Thanks again for this.
Do you think you will be supporting all of the Superlink stuff that is coming out. It looks like it had door/window, motion and a few others coning in a month or so.
I have had two ring gen 2 contact sensors just stop talking and then just refuse to reset. Doubt it would be as cost friendly, but wondering if it is a potential option. Starting to think about switching to a different sensor brand.
I would try to. I held off on buying a Superlink while there were no sensors for it. The other day when it said there were the new multisensors I tried to buy one and the Superlink... but it kept removing the sensor from my cart saying there were none available and the next time I refreshed the site it showed they were sold out.
The attributes related to this area are:
AIRecognitionType
AIRecognitionValue
There was also some WebHook support added to tie into that portion of the Unifi capabilities.
@mavrrick58 might be able to answer the actual usage better as he worked with me to get the basics in and working (as I do not have any of their doorbells).
Sorry that is not a quick/easy answer... But I just do not remember for myself at the moment either.
Ok i am going to break this down into two items: Fingerprint or Facial recognition.
For fingerprint, there is actally a websocket call triggered to @snells integration natively without any other needs. The problem with it is that it doesn't exactly explain what the fingerprint is related to. So what you need to do is create the fingerprint ID in the Unifi configuration for the doorbell. Then trigger it so the current state for "fingerPrintUserID" is updated. Once it is triggered the ID is passed to the doorbell device in Hubitat. Now you can capture that information to be used in RM. Now ceate a rule in RM to triggerbased on the state of the fingerPrintUserID for the device to change for a given value. You could use the fact it changes at all, or you can track who it is based onthe GUID provded in the call.
Another option is to use Unifi Alarm Manager. You can create alarms in Unifi Alarm Manager to call a Websocket URL on Hubitat. This will potentially give you a different kind of control over how it works, or in the case of Facial Recognition is the only way to do it. Simply put to do it this way you create the alarms in Unifi Alarm Manager with the last action to place a websocket call to Hubitat. The call is slightly different depending on if you use Maker API or my Unifi Integration Manager app. For Maker API you will want to share the Unifi Protect device and then make calls on that device to the applyWebHook Command. If you use my Unifi Integration Manager app. The inbound URL will look something like this:
There should be an example posted in the app for you to base your call on.
My integration manager app actually calls the same command you would use with Maker API so the information is the same in the websocket call. It is just ordered a little different. Let me know if you need any further assistance with it.
Something else to consider is that though the AI port does properly capture the face it also seems to misses it allot. Or Atleast mine seems to have. Perhaps it is getting better though it doesn't seem like it has missed me recently.
That was a great start! i got fingerprints working. im still confused about webhooks though. I dont know how to translate it into a trigger for a rule. I got Alarm manager to pass the webhook, but it doesnt show up as a custom attribute or anything i can use as a trigger in rule machine, just a log entry. is there somewhere i can read up on webhooks?
You are using "Known Faces" instead of "Specific Faces" in Unifi Alarm manager. These means you can't link a specific person to the alarm. Update the Alarm in Unifi Alarm Manager to use specific face and then update the webhook to specify "Face" for the "type", and then include the value item with the persons name associated with the alarm.
The unfortunate thing is that Unifi Alarm manager doesn't have a way to send variables through through the webhook call. This means you need to have it be very specific when you setup the alert and setup a different alarm for each person.
These should update the AIRecognitionType and AIRecognitionValue shown in the image below. I will take a closer look at it since as you see mine didn't update either.
I just noticed a bug in my code which was prevening the Value from being passed. I just updated the code and posted it to be downloaded. You should be able to download the updated code now if you are using HPM
Got it! it triggers well from hitting the test button in alarm manager.
But i stood in front of the doorbell, the live view in the browser showed a face recognition, but nothing happened.
Is that a limitation of the AI port? delayed recognition?
Also, thank you guys! this kind of community help is why hubitat is awesome
has anyone got the smart detect type attribute to work with this version?
