PTZ auto-tracking causes position loss when hitting physical limits — soft limit proposal

[w35m17h]

Model: GK-200MP2B
Sonoff-hack version: 0.2.0
Frigate with ONVIF auto-tracking enabled

Problem

When using Frigate's PTZ auto-tracking, the camera will occasionally
track a subject past its physical hard stops. Since the GK-200MP2B uses
an open-loop stepper system with no limit switches, once the motor stalls
against the hard stop the firmware loses its position reference. All
presets then become inaccurate until the camera is rehomed (ptz_drv.ko
unload/reload).

This makes auto-tracking unreliable for production use — it works well
until it doesn't, and recovery requires manual intervention.

Proposed Solution

Implement soft limits in the ONVIF server. After a rehome the position
is known. Track position with every move command. Before executing a move,
check if the new position would exceed configurable soft limits (set just
inside the physical hard stops). If the move would exceed the limit, ACK
the command but don't send it to the motors. Position reference stays valid.

Example logic:

• LIMIT_X = 3400 (just inside Horizontal=3500)
• LIMIT_Y = 850 (just inside Vertical=900)
• On move command: if (current_pos + requested_move) > LIMIT then ACK
  without moving

Current position is already available via: ptz -a get_coord

The intercept point should be in onvif_simple_server since all PTZ
clients (Frigate, web UI, MQTT) go through ONVIF. Intercepting at the
ptz binary or ptz.sh layer would miss direct ONVIF calls from Frigate.

Would you be open to implementing this? Happy to test on GK-200MP2B
with Frigate auto-tracking if you build it.

Current Workaround

As a workaround, I have implemented a "Rehome Camera" button in the
PTZ web UI that reloads the PTZ kernel module (unload/reload ptz_drv.ko)
without a full reboot. The stream stays up during rehome.

This was confirmed working in Discussion #200 by ZeynepKlc.

This involves three files:

• www/cgi-bin/rehome.sh — CGI script that unloads/reloads ptz_drv.ko
• www/pages/ptz.html — adds Rehome Camera section with button
• www/js/all.js — adds click handler for the rehome button

Happy to submit a PR for these files if you are interested — they
address the symptom while the soft limits fix addresses the root cause.

[roleoroleo]

The intercept point should be in onvif_simple_server since all PTZ
clients (Frigate, web UI, MQTT) go through ONVIF. Intercepting at the
ptz binary or ptz.sh layer would miss direct ONVIF calls from Frigate.

onvif_simple_server uses ptz binary to move the cam, so probably the best place to add this control is ptz binary.
All hack processes use ptz binary, only original sonoff processes use a different way (so library).

The question is: why the current control inside ptz binary doesn't work?
Yes, current implementation doesn't contain a margin but simply set the position to the limit when the x/y coordinates is bigger or lower.
But the cam should not exceed the limits, based on the current ptz.c code:

        fin_x = cur_x + x;
        if (fin_x > MAX_X) fin_x = MAX_X;
        if (fin_x < MIN_X) fin_x = MIN_X;
        fin_y = cur_y + y;
        if (fin_y > MAX_Y) fin_y = MAX_Y;
        if (fin_y < MIN_Y) fin_y = MIN_Y;

This problem can occur only using ptz continuous move (when switch on and switch off are two different commands) or ptz absolute move if you set a coordinate over the limits.
But, if I remember correctly, the tracking feature uses relative movement function, so the code above should intercept the problem.

Please, open a PR for your workaround, but I would like to understand why the problem occur.
Maybe you could try to log the output of the ptz binary, it's not easy but it's possible.
Edit /tmp/onvif_simple_server.conf and change ptz options adding debug parameters. For example...
From:
jump_to_rel=/mnt/mmc/sonoff-hack/bin/ptz -a go_rel -X %f -Y %f > /dev/null
To:
jump_to_rel=/mnt/mmc/sonoff-hack/bin/ptz -d -a go_rel -X %f -Y %f >> /tmp/debug.txt