“This would seem to be based on the assumption that this section of code will be reached _AT LEAST_ once each second. If for some reason it took longer, that could explain the results I saw. ” ==> yes this is correct, and is likely the cause of the issue you are seeing. When the remote station feature was implemented, I was assuming only a very small number of zones are set up as remote zones and didn’t anticipate a situation where a lot of zones are set up as remote. So you are right that if one HTTP call takes longer than a second, then it would miss that cycle and would have to wait for the next cycle. The reason each remote zone was given 2*MAX_NUM_ZONES (in your case, 2*200=400) seconds of run time each time is so that it will get two chances before the remote zone shuts off. In any case, I think there is already a pull request in Github to address this issue so I will take a look as soon as possible. This can be easily addressed without much difficulty.
Next, the question regarding “why not give the remote zone the correct run time” — this is harder to do because of the way remote zone is implemented: it is at very low level, in OpenSprinkler::apple_all_station_bits function. It’s done this way so that the remote zone is guaranteed to trigger independent of how the scheduler is implemented. At that low level, it does not know what is the scheduled run time, all it knows is whether it should turn on the zone or turn it off.
And about the API document, yes will correct that part about /cm command.