This feature is a little bit confusing, because it combines 2 different logical functions:
- Start/Stop/Restart of the ZM service
- A kind of “preset” for monitor activities
I agree that the first option is not needed in the binding, as it belongs more or less to the system maintenance. But the second one is quite a useful function for automation. In the ZM faq there are a couple of scenarios, where it can be applied. The function was also mentioned in this topic. These “presets” are available in the main UI page:
From the technical perspective, the function can be implemented as a string channel, which contains current value of the “run state” (GET /api/states.json) and can receive commands with a new state. The only one thing to check: if a new state is the same as the current one, it should be ignored, as ZM has no such check. It tries to set the new status even if it is the same, which leads to a needless restart of monitors and a pause in the capturing.