This is why I asked for events log of the problem.
Predictions come from the autoupdate feature of each Item.
It’s essentially an internal guess of the likely result of a command, to speed up the command-response-newstate loop for a snappy UI.
Where it goes wrong is if device response is screwy.
Command ON → predict ON (hurrah)
Device responds “I’m OFF at the moment” → state changes back to OFF
Devices reports again “Now I’ve turned ON” → state changes again to ON
Note the multiple changes, each one kicking your cross-link rule with another round of commands.
This is especially a problem for devices that poll periodically for status - a read poll can be in progress at the moment you issue a command and turn in its “old” response just after the command. I’ve no idea if this is possible with zigbee2mqtt, does it poll? Devices on the real Zigbee binding can.
It also crops up for dimmers that take time to ramp from here to there, with multiple reports of new % brightness along the way.
If you have that problem and if you cannot circumvent it with careful binding configuration, you can turn off autoupdate for affected Items. This eliminates the interim “guess” state so that you only get one (possibly delayed) change in response to a command.
Background