architecture
architecture copied to clipboard
home-assistant
PTZ platform
Context
PTZ is right now a custom service for a few different integrations; Agent DVR, Amcrest, Foscam, Onvif and I'm planning on implementing support in the Axis integration and it would all be preferable to be in a standardised way.
Proposal
Creating a new platform ´ptz´, that will allow different inputs to control a device supporting a combination of panning, tilting and zooming. Also allowing going to different presets and stopping movement.
Required features:
- Direct control
- Pan (absolute coordinates or relative in degrees)
- Tilt (absolute coordinates or relative in degrees)
- Zoom (absolute coordinates or relative in degrees)
- Move
- Home, Up, Down, Left, Right, Up left, Up right, Down left, Down right, stop
- Speed
- Continuous movement
- Calling preset positions in device
- Creating preset positions in device
- Calling preset positions in home assistant
- Creating preset positions in home assistant
- An additional service could be to allow a camera to progress between different preset positions together with a travel time parameter
- Defining supported feature set similar to the lights platform
- Not everything will support both pan, tilt and zoom
It could also be of value to offer data when a PTZ operation is active. Or allowing a camera to take a snapshot every time it reaches a preset position.
Consequences
Standardize the way PTZ is implemented across different integrations.
Vetted by @hunterjm prior to posting
What entities do we envision the new ptz platform creating, or will the platform only contain services? Assuming this proposal for a new platform is based on the possibility on non-camera devices having similar functionality, have you considered an Entity mix-in in the same vein as DataUpdateCoordinator where entities can extend PTZEntity to provide the services? This way, the initial implementation can be on the base Camera entity, but made available for DIY integrations using step motors and/or custom logic to also implement.
Its a bit complex so I don't know myself, I envision something along the line of a thermostat in complexity if it where to be an entity. You can send coordinates, or you can send preset positions where Home is probably always existing, you can send string "left", "right", or continuous movement, you might want to know if an action is active.
Honestly, I think this should just be part of the camera entity component.
While "movements" by itself could be nice as a separate entity component, things like "zoom" is definitely a camera thing.
The main thing is that we can identify additional support for the frontend so it is possible to render a full PTZ control interface
That makes no sense IMHO.
The frontend could generate an additional frontend item for camera's having PTZ capabilities, or, allow for a Lovelace cards that has a camera with PTZ capabilities as input.
That is making a backend decision based on frontend outcome, which is backward.
Do we know of any other integrations that have "movement" in a similar vein, or is it just cameras for now? I'd also caution over engineering a solution to try to match potential use cases that don't currently exist. It can always be refactored in the future if needed.
That makes no sense IMHO.
The frontend could generate an additional frontend item for camera's having PTZ capabilities, or, allow for a Lovelace cards that has a camera with PTZ capabilities as input.
That is making a backend decision based on frontend outcome, which is backward.
No I meant what you wrote ;), declaring the capability
Do we know of any other integrations that have "movement" in a similar vein, or is it just cameras for now? I'd also caution over engineering a solution to try to match potential use cases that don't currently exist. It can always be refactored in the future if needed.
It was only a starting point, a suggestion. Im perfectly fine with doing something simple if that's what's best for this feature
This architecture issue is old, stale, and possibly obsolete. Things changed a lot over the years. Additionally, we have been moving to discussions for these architectural discussions.
For that reason, I'm going to close this issue.
../Frenck