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.
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).
