After the relative success of my Unifi Network API driver (previously just the Unifi API driver) I decided to branch into what else my UDMP is capable of. One of those functions is the Protect area. I do not have much in the way of Protect hardware but I am able to enable it and start digging around into the features so I felt it would be useful to provide a driver for those interested.
I will obviously be expanding on it and supporting it to the best of my abilities (like all my drivers).
Features:
Create child device(s) and populate with general status such as label (device name), uptime, and hardware type
Additional features for the Floodlight devices (like turning it on/off)
Additional features for Camera and Doorbell devices (like capturing a snapshot)
Additional features for NVRs including the CPU temperature, as well as memory and storage percentages
WebSocket support for immediate device event notifications
Available within the Hubitat Package Manager (HPM).
Caveat(s):
A really big one at this time... I have limited samples of actual Protect data responses to add device hardware support and capabilities. If anyone is willing to send me a Trace log when they perform a Refresh or GetProtectInfo (they are the same at this time) I would appreciate it and can start to build more in.
Driver Links:
You MUST have the parent driver of course... children are needed for particular devices you have on Protect. So if you have a camera, also install the Camera driver. Bridges are very typical as Unifi Protect defaults to including your Access Points as bridges, so in most cases you will need that child driver.
Add UnifiProtectAPI.groovy driver to your Drivers Code section on your Hubitat (you can Import using the URLs above) then Save the driver. Repeat with the UnifiProtectChild.groovy driver and any specific additional child drivers (as they are added) that you might need for your system.
Add a Virtual device and set the Type to be UnifiProtectAPI (user-added drivers are going to be at the bottom of the list), then Save Device.
Enter your Unifi Controller's IP/Hostname, Username, and Password into their respective fields in Preferences, select your Unifi controller type, then Save Preferences. REQUIRED: If you use the "Other Unifi Controllers" controller type, after you Save Preferences a new preference field will be displayed "Controller Port #". You should set this to the port number your controller uses for the Protect API. Default is the "standard" 7443 but just in case there are changes in newer versions of the controller software (like there has been for the Network API).
OPTIONAL - Enable WebSockets (enabled by default) if you want to receive immediate notification of various events like motion, recording, light, etc...
The driver should automatically attempt to login and refresh the basic information from the Protect system and will attempt to refresh it per the Stats Refresh Rate preference from then on. It will also automatically create child devices from that point forward.
Not sure. The Unifi Network driver does work with non-UDMP controllers and I tried to incorporate information I could dig up from Ubiquiti's site. That is why there is the Unifi Controller Type preference. It should attempt to use a path appropriate for non-UDMP controllers.
Obviously I cannot test it myself though. If you do try it, let me know how it goes and it might get listed as an additional feature. If it does not work, I will be happy to try to get it working.
I will have to look at it a bit later. I do know your login method won't work with the URL you are constructing just by the quick glance. I am focusing on new Rule Machine issues with Time/Date. I did my update Friday to test some things out and I would say I found a few bugs.
UniFi Protect only runs on the Cloud Key Gen2 Plus, not the original CK or the non-Plus CK G2, in addition to the UDMP and NVR. All of the Protect controller targets are UniFi OS, so that simplifies things compared to the different controller types with the UniFi networking stuff.
I haven't used @snell's drivers, but I can say that my UniFi Protect drivers work the same on UDMP and CK G2 Plus. So I would expect that these would also work on the different controller types
Aggreged I have a UDM in a downtown Chicago location but my old C4 that I used for testing is resting in my graveyard of dead technology. If it was still alive I would take it down there this week and validate for @snell. Other sites I am supporting have various G2 and self hosted. My interesting in this goes behond protect. If there was a way to use the API to see in a wifi device arrives or departs my client would be better able to clean up the AirBNB location when the visitor's are away. I have been asking him for a year since he stood up the location that we need to add automations to the interior accent lighting and to use a Hubitat and some smart devices.
The UniFi networking API supports the functionality you described (sending events when network clients connect and disconnect). As you said, that is separate from Protect.
In my "UniFi Events" driver, I support presence sensors for known devices. I use this to determine when a given wireless client (like my cell phone) is connected, which indicates that I am home.
It would not be difficult to generalize this to display the number of presently connected devices, if I'm understanding your use case correctly. I'm not sure if @snell's UniFi Network API drivers may already support this.
My UnifiNetworkAPI driver can check the presence of particular MAC addresses on the network.
I felt keeping the two drivers separate at this time is the better idea. Especially since someone can easily make 2 separate virtual devices that go to the same controller (that is how mine is operating).
Read-only support for Lights, based on the Ubiquiti Smart Floodlight. This will allow reading if the light is on, what it's level is set for (converted to 10-100%), whether it currently has detected motion, etc... Obviously this information is EXTREMELY impacted by your refresh rate. Also note that this is all read-only at this time, there are no commands to DO anything with the floodlight. My goal is to make it read/write in the future when I get that worked out, so people can control if the light is on, when it will be triggered, etc...
Request for anyone that is using this driver... If you have any devices OTHER than a Floodlight on your system could you do a couple things for me?
Set your logging for TRACE and capture a log when you run "GetProtectInfo". You can redact any tokens/IDs/usernames... any of the field values (just please mark that you REDACTED the value or something similar), just please leave the field name.
Please send all information as PMs... do NOT post it here in the thread.
As a hint... I have an upcoming major change to the driver. Not only will I be starting to break out the types of children BUT it is not going to be just READ ONLY anymore! However, it is impossible to figure out commands without seeing samples of data (it was really tough figuring out how to do it for my floodlight even with all the samples). So I do not want to leave most devices sitting with the read-only generic child driver...
As I was making my summer road trip in Michigan to get my friends clients to move to Hubitat and to update hubs and drivers if needed I had one client that was running a full Unfi stack at their business along with protect. I tried to talk them into a Hubitat for some automations and it would have been a good way of testing out your drivers. But luck wasn't on my side they went with Comcast services a month ago for all their other needs outside of the cameras and network from Unifi.
Oh well now they are stuck with a high Comcast bill and locked into the business class internet and the add on costs for door locks and sensors. I am glad they didn't ditch the Unfi setup. Comcast is actually worse that ADT and they mandate a extended maintenance contract for their supported devices. I think they actually subcontract ADT for the alarm services.
Thanks for keeping it in mind, but no problem. I have gotten the basics of my floodlight to be controllable (light on/off and brightness). Still want to do some tweaks for the "less important" stuff. I really wish I was able to get hold of one of their sensors or cameras. But the sensors are in Early Access never available... and the cameras seem to be permanently stuck in the out of stock abyss. Every time I get a notice for anything being in stock it is sold out again when I check.
Of course I could go on eBay or elsewhere and pay 2x the normal price.
First and foremost this introduced a major change to how I am creating child devices for my Unifi Protect driver (and it will likely eventually spread to other drivers). Rather than have a single driver "UnifiProtectChild" anymore there is a new driver with a -Light extension. This driver is meant for LIGHTS on the Unifi Protect system (at this time I only know of the floodlight). This means that if someone has a floodlight AND they have the -Light driver also installed they will have different capabilities and commands available to them.
Support for Unifi Floodlights. As the only device I really have besides the UDMP and an AP that acts as a bridge... I started digging into this more. In the process I figured out how to "manually" control the light, change it's settings, etc... In order to do this without having all sorts of code to block other devices from trying to do things they cannot the easiest way was to make the aforementioned -Light child driver.
Removed Light-related data processing from the parent driver. Going forward when/if more child devices are added I intend to keep their data processing in them. However most of the commands the child devices perform will actually call a command in the parent driver. I wanted to have most of the actual data transfers happening via the parent (to help keep logging reasonable) and for reuse between similar child commands.
Removed Light-related attributes from the UnifiProtectChild driver and put them all in the specific Light child driver. This is to keep the generic child driver just for children that really are pretty generic and do not seem to have much control available (the NVR and Bridges so far) and for when I do not know anything about a child device yet and have not made a separate driver. This one will continue to be the "default" child driver.
Made changes to the driver version checking that is done daily to make it easier for me going forward and to identify other status information I may sometime use (or could have used previously). You should SAVE PREFERENCES after loading these new versions to make sure you get the new scheduling method for the version checks.
Hi @snell,
I've just installed the unifi driver on my UDM Pro, and finally got the presence detection for my iPhone working after years of nightmares. So, thank you.
I also have the Protect ecosystem on my UDMPro, with a bunch of G3 cameras.
Are you interested in getting info on the cameras? I have 12 x G3Flex and 1 x G3 Pro (so it has the Zoom feature)?
I thought I should check before installing this, as without some kind of camera support, there's virtually no reason for me to install it. I'd be interested in getting motion notifications (as the protect app geolocation on iOS is broken and does not register when I'm away, so I either get notifications always or never).
I would love additional information to try to make this better. But I will admit it is going to be a tough road for camera support.
I need to see if I can set up websockets to get notification of motion, which is not something I have ever done (all of my current network drivers use HTTP/s). I also am not sure I can get thumbnails or anything like that and I have been kindof leaving it on the backburner due to Christmas and correcting other drivers.
BUT... all that being said, I am not giving up on getting more features in this one. I am even still working on a Unifi Access driver.
I also have a UniFi Protect driver which supports motion detection (including smart detect) and other features on various cameras, plus most features of the G4 doorbell. Ubiquiti Unifi Protect cameras - #37 by tomw
I don't have all of the nice controller stats and info or the floodlight support that @snell has, so you could probably choose whichever driver has the features you're most interested in.
@tomw and I always seem to be working on similar things and trading information back and forth. If I was not trying to learn more of this stuff myself and do as much on my own as possible I would look over his drivers and copy out the methods mine lack.
But... since I AM trying to learn and such, people mostly need to wait for me to figure things out if they are counting on my drivers.
I cannot get my Unifi Protect Controller device to access info from my Protect cameras. The problem is that I have vlans set up, #20 for my IOT device which includes Hubitat and #30 is for all the Unifi cameras. I have firewall rule that does not allow IOT devices access to gateways.
I need some info on how to make a firewall rule that will allow Hubitat only to access the correct vlan gateway so I can connect to Protect. I am not sure if I need to access the camera gateway or the main gateway that the Unifi equipment is on. I believe I need the main gateway because the Cameras are on a vlan but the Protect controller is on the UDM Pro on the main gateway #1.
I know enough about vlans and firewall rules to be dangerous and really screw up everything. I followed Youtube videos to set up everything up and pretty much understood what I was doing but this is a horse of a different color. When it comes to IP address and ports I get confused. Any help will be appreciated.
