ZM Perl Control API, etc.

[chris_19]

I have dug around and googled ad nauseum and cannot seem to find this information. Forgive me if I have overlooked the obvious.

1. Is there developer documentation which outlines the API between ZoneMinder::Control and the various subclasses for particular cameras?
2. Is there documentation outlining the API between zncontrol.pl and the various callers of that script?
3. Is there documentation outlining the function of the various fields of the zm.Control table?

I have read over the code for ZoneMinder::Control and zmcontrol.pl and enabled debugging and watched the logs. From that I have a general understanding of how things interact. One thing (among several) which I have not figured out is what controls things like the calls to 'moveConUp' versus calls to simply 'Up.' Evidentially the former is a call for continuous movement and the latter just a call for upward movement. it appears that in in this case, the selection of which one to call is decided by the setting of zm.Control.CanMoveCon and that setting that field to 'true' results in the caller of zmcontrol.pl selecting 'moveConUp' rather than 'Up.' This is the sort of thing I am looking to confirm.The answer to #3 above would be most helpful.

I'm hoping that such docs would help resolve this sort of thing:

Code: Select all

web_php[9800]: ERR [Invalid control parameter: DownRight]

Which appears for various movement commands even though the DownRight (etc.) control results in the expected camera response.

TIA for any help pointing me in the right direction.

Kind regards,
Chris

[bbunge]

https://zoneminder.readthedocs.io/en/latest/api.html

[chris_19]

I have read and reread that doc and it does not have the information I'm looking for.

I'm not looking to interface with ZM via its outward-facing API. I'm looking at its internals.

Thanks!

[chris_19]

So part of what I was looking for is here.

This explains how zm.Control.CanMove and related fields play. More specifically (and maybe this is documented somewhere other than the code):

If the camera CanMove, then examine the three types of movement available, Abs[olute], Rel[ative], Con[tinuous], in that order of priority. Since the logic here is exclusive, take the first one and run with it. If none of these three are available, set the command and mode to null (effectively) and run with that.

The "problem" here is that the code allows for a case which, in theory, should not exist. This is the case of zm.Control.CanMove being set true and all other related fields being set false. Higher level code appears to attempt to keep this from happening by not permitting the user to save settings which would result in this condition. However, for the unaware or uninitiated who may construct their zm.Control record from scratch in SQL and end up with this condition, the code does not throw a meaningful error and (perhaps adding to the deception) permits camera control.

The apparent solution to this fringe case would be to trap the undesirable condition (probably at the end of the conditions above), bail out, and pass a meaningful error message back to the UI along with a more detailed message in the logs. This should, IMHO be a fatal error. Otherwise, why bother enforcing the relation in the UI?

Maybe I'm out in the woods on this, but that's what I see. It would be great to have documentation of the details of interaction in the camera control code at all levels. If someone in the know can validate my thinking above, I'll be glad to at least start such a document if it does not already exist somewhere in the ether....

Thanks again for all the help.