OK, I will check this weekend. It’s probably a bug. With normal programs, the same zone is not allowed to be queued twice, so if it’s already running, a new schedule for it will be ignored. However, for /cm, the firmware accepts the new time and overrides the existing schedule, this may have messed up the time for master zone activation, resulting in the symptom. The corresponding line of code is here:
I suppose that instead of accepting the new time, if you ignore the new request (while the same zone is still running) it should not have messed up with master zone activation. In any case, I will check and find a fix soon.