[PROJECT] Driver for Unifi Protect Controllers

⚙️ Custom Apps and Drivers Custom Drivers
408

As for using UniFi Protect for contact, leak, and motion sensors, I am very happy with the outcome. Coupled with all new switches, I have no complaints (other than the memory leak, lol). I would say the motions are a bit finicky for locations, more so than my old sensors, it’s how they’re designed.

Whether it’s mesh strength, types of devices, number of devices, quality of devices, etc, we all get and see different versions of HE. I see people talk about their 5 switches spread around the house in a mesh configuration, or not having repeaters for battery powered devices, etc, as if any hub can fix a lack of understanding. You never know who you’re talking to or their skill level. Although one can draw conclusions.

My level of commitment and my means to do so, may not be typical, but it works well for me and my family (kids are grown, so mostly my wife and pups).

Back on topic - the sensors work great, but you need to plan appropriately. Good luck to anyone heading down this path. Take care!

409

Superlink is in a weird space at the moment in my opinion. I have an alarm system with similar functionality that also gets me software and hardware to interface with other systems. I'd like to see more options for dry contact relays for unifi.

You aren't all that unique when it comes to the ability to spend on Unifi. It's a special addiction many of us share.

I wish they had Superlink hidden door contact sensor like my Qolsys powerg sensors.

The Yolink Lora products are strong competitors esp with the local hub and Hubitat integration.

1 Like
410

Updated Version(s):

  • UnifiProtectAPI.groovy = 0.2.67
  • UnifiProtectChild-Camera.groovy = 0.1.19
  • UnifiProtectChild-PTZCamera.groovy = 0.1.10
  • UnifiProtectChild-Sensor.groovy = 0.1.11
  • UnifiProtectChild-Doorbell.groovy = 0.1.23

Change(s):

  • Changes to better identify motion from SuperLink motion sensor. Still not perfect as the API does not provide direct websocket feedback for this, so a workaround is required. The sensor also does not provide an "inactive" notice, which also requires a workaround. Still waiting for some feedback from Ubiquiti on what the motion timeout internal to the sensor is.
  • Sensor child driver now has a Sensor Type preference to try to narrow down the Preferences available to ones only applicable to the specific sensor. For example, the motion sensor does not need Preferences related to light. The parent will attempt to set this automatically based on device info.
  • Additional data handling for numerous websocket and API data responses.
  • Some general minor code cleanup.
  • All camera-capable children (Camera, PTZ Camera, and Doorbell) had a correction for the automatic image rate set in Preferences. If it was set before to an automatic value (other than Manual) then changed back to Manual, the automatic rate was not being turned off. It would change the rate if one time was changed to another, but not disable if it was set to Manual. This is now corrected.
411

Updated Version(s):

  • UnifiProtectChild-Doorbell.groovy = 0.1.24

Change(s):

  • Correction to notification timeout to have it be seconds (I was accidentally sending it milliseconds).
  • Previously added but forgot to mention, changes to correct the doorbell notification message that can be displayed and to give it possible timeouts like what the Protect app does on the controller webpage.
412

NOTICE:
Apparently when I posted the updated UnifiProtectChild-Sensor.groovy, I pasted over it with the UnifiProtectAPI driver code.

So... If you updated the Sensor child in the last week, you might want to pull it again. Sorry about that. Thanks to @michael23 for noticing the goof.