Feature request
Please add UniFi Protect privacy-zone / privacy-mask control to the official openHAB UniFi binding so that privacy can be controlled from an openHAB Item/rule.
Current state
The current Protect camera model already parses privacy-zone data:
Camera.privacyZones
Camera.lastPrivacyZonePositionId
and the private Protect client already has a generic updateCamera(cameraId, updates) path that is used by the camera handler for writable settings such as HDR, OSD, microphone, recording mode, motion detection, IR mode, etc.
However, there does not appear to be a user-facing privacy channel in the current binding, nor a privacy-related command path in UnifiProtectCameraHandler.handleCommand().
Relevant current files:
bundles/org.openhab.binding.unifi/src/main/java/org/openhab/binding/unifi/internal/protect/api/priv/dto/devices/Camera.java
bundles/org.openhab.binding.unifi/src/main/java/org/openhab/binding/unifi/internal/protect/api/priv/client/UniFiProtectPrivateClient.java
bundles/org.openhab.binding.unifi/src/main/java/org/openhab/binding/unifi/internal/protect/handler/UnifiProtectCameraHandler.java
Desired behavior
At minimum, expose a writable Switch-style channel that allows openHAB to enable/disable camera privacy while preserving the user's existing privacy-zone configuration.
Ideally:
- Read the current privacy-zone state/configuration from Protect.
- Allow privacy to be enabled/disabled from openHAB.
- Preserve existing zone names, IDs, geometry/points, colors, and unrelated camera settings.
- Reflect changes made directly in Protect back into the openHAB channel state.
- Fail safely if the Protect API behavior changes or a camera does not support the operation.
If Protect exposes per-zone enabled/disabled state, per-zone controls would be even better. If it does not, an overall privacy-mode channel would still be very useful.
Prior art / implementation note
The older third-party UniFi Protect binding had a privacy-zone request implementation that PATCHed privacyZones, including a full-frame privacy zone for privacy mode. That demonstrates that this has historically been controllable through Protect's private camera API.
I would not want a new implementation to simply send privacyZones: [] when turning privacy off if that destroys pre-existing user-configured masks. A safer implementation should preserve and restore the original zone list, or use whatever enable/disable mechanism the current Protect API provides.
Use case
The goal is to control indoor-camera privacy from openHAB rules (presence, occupancy, alarm state, etc.) without having to manually change each camera in the Protect UI.
This seems like a fairly contained addition now that the binding already uses the private Protect API and already models privacyZones.
Happy to test this against a live UniFi Protect installation/cameras if that would help.
Feature request
Please add UniFi Protect privacy-zone / privacy-mask control to the official openHAB UniFi binding so that privacy can be controlled from an openHAB Item/rule.
Current state
The current Protect camera model already parses privacy-zone data:
Camera.privacyZonesCamera.lastPrivacyZonePositionIdand the private Protect client already has a generic
updateCamera(cameraId, updates)path that is used by the camera handler for writable settings such as HDR, OSD, microphone, recording mode, motion detection, IR mode, etc.However, there does not appear to be a user-facing privacy channel in the current binding, nor a privacy-related command path in
UnifiProtectCameraHandler.handleCommand().Relevant current files:
bundles/org.openhab.binding.unifi/src/main/java/org/openhab/binding/unifi/internal/protect/api/priv/dto/devices/Camera.javabundles/org.openhab.binding.unifi/src/main/java/org/openhab/binding/unifi/internal/protect/api/priv/client/UniFiProtectPrivateClient.javabundles/org.openhab.binding.unifi/src/main/java/org/openhab/binding/unifi/internal/protect/handler/UnifiProtectCameraHandler.javaDesired behavior
At minimum, expose a writable Switch-style channel that allows openHAB to enable/disable camera privacy while preserving the user's existing privacy-zone configuration.
Ideally:
If Protect exposes per-zone enabled/disabled state, per-zone controls would be even better. If it does not, an overall privacy-mode channel would still be very useful.
Prior art / implementation note
The older third-party UniFi Protect binding had a privacy-zone request implementation that PATCHed
privacyZones, including a full-frame privacy zone for privacy mode. That demonstrates that this has historically been controllable through Protect's private camera API.I would not want a new implementation to simply send
privacyZones: []when turning privacy off if that destroys pre-existing user-configured masks. A safer implementation should preserve and restore the original zone list, or use whatever enable/disable mechanism the current Protect API provides.Use case
The goal is to control indoor-camera privacy from openHAB rules (presence, occupancy, alarm state, etc.) without having to manually change each camera in the Protect UI.
This seems like a fairly contained addition now that the binding already uses the private Protect API and already models
privacyZones.Happy to test this against a live UniFi Protect installation/cameras if that would help.