Repository navigation
Add CTronics camera adapter - #404
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## develop #404 +/- ##
========================================
Coverage 79.46% 79.46%
========================================
Files 6 6
Lines 852 852
========================================
Hits 677 677
Misses 175 175
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
MateoLostanlen
left a comment
There was a problem hiding this comment.
Review of the CTronics adapter. 8 correctness issues, 1 dead code block, 1 efficiency note. Details inline.
|
Hi @romainantes, Thanks a lot for the PR, and sorry for the late review! I left a few inline comments. I don't have access to the camera so it's not ideal for reviewing, but let me know what you think. Quick question by the way: why go through ONVIF rather than the camera's native API? I've heard ONVIF is often less well maintained on the firmware side. And following on from that, if it's pure ONVIF, I'm wondering if we should have a generic ONVIF adapter directly (reusable for other brands) rather than a CTronics-specific one. What do you think? |
Thanks for the review and for raising this! I chose ONVIF because the camera’s native API did not expose a sufficiently complete and reliable interface for all the operations required by the adapter. In particular, I had difficulty covering PTZ presets, absolute focus, focus status, and the different control paths consistently through the native API. ONVIF provided a single control interface for these operations, and I validated the relevant absolute-focus behavior on the available CTronics camera hardware. That said, I am aware that ONVIF support can vary between firmware versions and vendors. The adapter therefore still handles several CTronics-specific details, such as snapshot capture, connection defaults, profile selection, preset-token behavior, and the camera’s advertised Imaging/PTZ capabilities. I agree that a generic ONVIF adapter could be valuable in the future, especially for the PTZ and Imaging functionality. However, I would prefer to keep this PR CTronics-specific for now because the current implementation still contains vendor-specific behavior and has only been validated on CTronics hardware. |
|
Hi @romainantes Thanks for all the updates, that was a lot of work and the adapter is in much better shape now. I went through the ten points and checked the code, not just the replies. All of them are addressed: zoom no longer touches the focus motor, the preset index fallback is gone and now fails loudly, focus is clamped and seeded from the camera, ONVIF errors return 503, the CGI half is deleted, and the preset cache plus DEBUG logs are in. Camera API tests pass locally (73 passed, 7 skipped). Three things before this can merge:
A few small things I noticed while reading:
Also worth flagging: On the ONVIF question, your reasoning makes sense and I am fine keeping this CTronics specific. Just noting that after removing the CGI path, Last one: you mentioned absolute zoom could not be validated on your unit. Can we get it tested on a camera that supports it before we rely on it in the stream stop path? |
"In _ensure_onvif, self._ptz_service is assigned before _refresh_preset_cache(). If GetPresets fails once, the init raises but _ptz_service stays set, so the next call returns early and _imaging_service is never created. Focus then stays broken for good after a single transient failure. Assigning _ptz_service last, or resetting the attributes in the except, would fix it." "Also worth flagging: tests.yml only runs pytest tests/, so pyro_camera_api/tests/ never runs on CI. That is a repo-wide gap rather than something for this PR, but it means your new tests are not actually gating anything yet." "On the ONVIF question, your reasoning makes sense and I am fine keeping this CTronics specific. Just noting that after removing the CGI path, capture() is about the only vendor specific piece left, so splitting a generic ONVIF base out of this will be easy the day a second ONVIF camera shows up. No need to do it here." "Last one: you mentioned absolute zoom could not be validated on your unit. Can we get it tested on a camera that supports it before we rely on it in the stream stop path?" |
…adapter raises ValueError before calling GotoPreset or updating the tracked azimuth.
…d serialize presets safely
…s mechanism and removed the unused Hi3510 CGI implementation
…d during ONVIF setup,
92d022e to
702d46c
Compare
There was a problem hiding this comment.
Hi @romainantes
Sorry for the late reply, September was busy.
Thanks for the last round, the retry fix looks good. I took care of the rest:
Rebased on develop and fixed the README and uv.lock conflicts.
ruff: ignore[...] is not valid ruff syntax, so I replaced those comments with per-file ignores in pyproject.toml.
Fixed 3 small mypy errors.
Synced pyro_camera_api/uv.lock with onvif-zeep.
CI is green, merging. Thanks for the work on this one!
Adds support for CTronics cameras using HTTP snapshots and ONVIF PTZ/Imaging controls.
It also extends RTSP stream path customization and adds dedicated documentation for camera adapters.
Changes:
New Adapter: