[Support]: PTZ: First command after idle period silently ignored, second command works #22684
Replies: 2 comments 34 replies
-
|
This behavior where the first PTZ command after an idle period is silently ignored is not something I can find documented as a known issue or expected behavior in the available sources. Your ONVIF configuration appears correct based on the reference configuration. (1) The required ONVIF parameters you have configured are: onvif:
host: 192.168.2.50
port: 8999
user: xyz
password: "abc"A few things to verify based on the documentation: 1. Camera compatibility: Frigate's PTZ functionality requires cameras capable of relative movement within the field of view as specified in the ONVIF spec ( 2. Firmware behavior: Some cameras have firmware issues with ONVIF. For example, some Hikvision PTZs are known to not update the 3. TLS setting: You may want to try adding Since the camera works correctly in ONVIF Device Manager but exhibits this behavior only in Frigate, and there are no errors in the logs, this appears to be a potential bug or timing issue specific to how Frigate handles ONVIF connections after idle periods. This would be appropriate to report on the Frigate GitHub repository for further investigation by the development team. 📚 Sources: Have another question? Just tag @inkeep. |
Beta Was this translation helpful? Give feedback.
-
|
I'll defer to @hawkeye217 but I don't see why the command would be dropped, that is not how the code works. |
Beta Was this translation helpful? Give feedback.
-
|
If other cameras work, it may be because their GetPresets response |
Beta Was this translation helpful? Give feedback.
-
|
to be clear, my point is that we do not have any timeouts, regardless of how long the init takes assuming it succeeds the original action will still be taken async def handle_command_async(
self, camera_name: str, command: OnvifCommandEnum, param: str = ""
) -> None:
"""Handle ONVIF commands asynchronously"""
if not self.cams[camera_name]["init"]:
if not await self._init_onvif(camera_name):
return
try:
if command == OnvifCommandEnum.init:
# already init
return
elif command == OnvifCommandEnum.stop:
await self._stop(camera_name)
elif command == OnvifCommandEnum.preset:
await self._move_to_preset(camera_name, param)
elif command == OnvifCommandEnum.move_relative:
parts = param.split("_")
if len(parts) == 3:
_, pan, tilt = parts
zoom = 0.0
elif len(parts) == 4:
_, pan, tilt, zoom = parts
else:
logger.error(f"Invalid move_relative params: {param}")
return
await self._move_relative(
camera_name, float(pan), float(tilt), float(zoom), 1
)
elif command in (OnvifCommandEnum.zoom_in, OnvifCommandEnum.zoom_out):
await self._zoom(camera_name, command)
elif command in (OnvifCommandEnum.focus_in, OnvifCommandEnum.focus_out):
await self._focus(camera_name, command)
else:
await self._move(camera_name, command)
except (Fault, ONVIFError, TransportError, Exception) as e:
logger.error(f"Unable to handle onvif command: {e}") |
Beta Was this translation helpful? Give feedback.
-
|
and there's no reason that this would be continuously re-producable because once a camera is initialized it won't be initialized again in Frigate. Your report suggests that if you wait some time this re-occurs continuously |
Beta Was this translation helpful? Give feedback.
-
|
Further analysis of the debug log reveals a consistent pattern: After any idle period, the first PTZ command is ignored. The second command always works. Example from the log: 2026-03-29 15:34:55.784598404 [2026-03-29 15:34:55] frigate.ptz.onvif INFO : Attempting ONVIF initialization for lootor (retry 1/5) The same pattern occurs every time after an idle period, regardless It is unclear whether the command is discarded by the dispatcher |
Beta Was this translation helpful? Give feedback.
-
|
This is almost certainly a camera firmware quirk rather than a Frigate issue. Here's why:
You could try setting up an MQTT automation that sends a periodic We've made it a policy to not implement workarounds or hacks for buggy cameras in Frigate, and adding retry/wakeup logic for one off-brand camera's quirk would add complexity and latency for all users. This is best handled at the camera firmware level or via external keepalive automation. Hopefully the automation above can help your situation. Beyond that, I'd suggest seeing if your camera manufacturer has a firmware upgrade available. |
Beta Was this translation helpful? Give feedback.
-
|
You previously wrote: "This does seem to be a consistent pattern with budget PTZ cameras." That is not camera-specific. it seems that a single GetStatus before each PTZ command would solve this for the entire class, not only for an isolated case. |
Beta Was this translation helpful? Give feedback.
-
|
I was referring more generally to problems with budget PTZ cameras. I have been contributing to Frigate and supporting users for several years now, and I have not seen your specific issue even once. |
Beta Was this translation helpful? Give feedback.
-
|
After further research, this does not appear to be as isolated as suggested. Discussion #14520 describes the same pattern with a The pattern across multiple cameras and multiple tools points to Frigate's ONVIF implementation as the common factor. Even if Frigate's implementation is strictly correct per the ONVIF specification, a single GetStatus before each PTZ command (or someting equivalent, that's up to your decision) would make it significantly more robust in practice. |
Beta Was this translation helpful? Give feedback.
-
|
No, that is a completely different issue and doesn't exhibit the same symptoms as your camera. |
Beta Was this translation helpful? Give feedback.
-
|
Maybe. The common denominator is the fact that ONVIF support for (in your judgement) cheap PTZ cameras is more robust with e.g. ODM or Synology than with Frigate. That's a nuisance. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Checklist
Describe the problem you are having
Camera: Jidetech P1-4X-5MP PTZ Dome, connected via ONVIF/PoE
Host OS: Ubuntu 24.04, Docker
Deployment: docker-compose
After any idle period (even just a few seconds without PTZ activity),
the first PTZ command is silently ignored. The second command works
reliably. This happens consistently and is reproducible.
There are no errors or warnings in the Frigate log related to ONVIF
or PTZ when this occurs.
The same camera was tested with ONVIF Device Manager (ODM) on Windows.
Even after long idle periods, the first PTZ command in ODM is
executed immediately and reliably every time. Only Frigate exhibits
this behavior.
Steps to reproduce
...
Version
0.17.1-416a9b7
In which browser(s) are you experiencing the issue with?
No response
Frigate config file
docker-compose file or Docker CLI command
Relevant Frigate log output
Relevant go2rtc log output
Operating system
Other Linux
Install method
Docker Compose
Network connection
Wired
Camera make and model
Jidetech P1-4X-5MP PTZ Dome
Screenshots of the Frigate UI's System metrics pages
Any other information that may be helpful
No response
Beta Was this translation helpful? Give feedback.
All reactions