search

home-assistant / architecture

Repo to discuss Home Assistant architecture
313 stars 100 forks source link

PTZ platform #454

Closed Kane610 closed 1 year ago

Kane610 commented 3 years ago

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:

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

hunterjm commented 3 years ago

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.

Kane610 commented 3 years ago

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.

frenck commented 3 years ago

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.

Kane610 commented 3 years ago

The main thing is that we can identify additional support for the frontend so it is possible to render a full PTZ control interface

frenck commented 3 years ago

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.

hunterjm commented 3 years ago

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.

Kane610 commented 3 years ago

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

Kane610 commented 3 years ago

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

frenck commented 1 year ago

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