Provide an explicit stop for Axis continuous PTZ movement

Bottom line: Build an explicit stop action into continuous PTZ operation. Accept the control only after an authorized release-and-stop exercise, rather than using the inactivity timeout as the operator’s normal stopping mechanism.

Source fact: documented behavior

Axis’s PTZ control WebSocket documents continuous movement ending on a zero-speed continuousMove stop command, a new command or a three-minute timeout; the use-case description conditions the timeout on no further commands being sent.

The documentation limits this API to cameras with Artpec7, excluding V59xx, and Artpec9, and explicitly excludes Artpec8.

The PTZ control WebSocket interface does not provide PTZ data polling; the documented status-streaming path uses Device Data Hub topics.

What the source does not establish

Do not infer that releasing a particular mouse, joystick or touch control automatically sends the required stop. Verify the client implementation and actual camera support. Keep command acceptance, observed motion and status reporting separate. Do not treat a protocol timeout as a safety-rated stop or authorization for unattended movement.

Applicability questions

• Does the exact camera fall within the documented hardware scope and expose the required interface?
• Which client event sends a stop for each active movement axis?
• How does the client behave when focus changes, a control is released or a response is rejected?
• Who will observe movement in a clear, authorized test area?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends defining and testing an explicit stop transition for every continuous PTZ control offered to operators.

1. Choose a representative supported camera and a safe observation window. Review the client’s movement and release handling before issuing commands. Write down which axes the proposed control can move and which stop request it should send. Set modest supported test speeds and a clear operator abort procedure; do not begin with unrestricted movement in an active security task.
2. Perform a brief proposed pan-only case, then the other supported axes as appropriate. Release the control and compare the client’s sent request, returned response and independently observed end of movement. For a combined-axis control, explicitly check the stop behavior for every axis that was active. Investigate a response without the expected physical result instead of retrying movement blindly.
3. Exercise the client’s intended cancellation and error paths with authorized test inputs. Include a rejected movement response and a user-interface exit case in the plan. If the stop path cannot be established, withhold that control from operator use and route the defect to the integration owner. Do not shorten the acceptance exercise to waiting for the inactivity timeout.

Verification and evidence

Retain supported hardware identification, the client revision, sanitized command/response timing and the observer’s movement record. Distinguish an intentional stop from a later timeout. If status streaming is used, preserve its evidence separately so a missing status sample is not silently recorded as a confirmed physical stop.

Ask an operator unfamiliar with the implementation to demonstrate start, release, cancellation and abort in the proposed pilot. Require an explicit outcome for each path before expanding use. This procedure defines checks to perform; it does not report a completed movement test or a certified motion-control function.

Official references

• PTZ control WebSocket — Axis Communications; official VAPIX documentation.

Source review completed October 29, 2026. Recheck the official documentation and the deployed device’s capabilities before changing production settings.