Lots going on here.
First, using Group to propagate commands to your individual devices. Here you blast out 8 commands in a few tens of milliseconds. I expect they’ll all get delivered eventually, but there will be quite a bit of churning about on your network, as the devices are probably trying to respond at the same time.
Don’t expect instant response.
Then there’s dimmer ramping, depending on the device. It may deliberately take time to change from X to Y. Potentially it could issue status updates along the way. So command 50 might be followed by response 40, then later by response 50. Under some circumstances, you could get a response 40 soon after the command, but not get the “final” 50 until much later. It takes very careful unpicking of logs to unravel this.
Alongside that, your Items have autoupdate at work. To speed up apparent response at the UI, the system guess the likely outcome of each command and updates the Item state (these are the predictions you see). That gives you some jitter effects if coupled to realtime updates from a ramping dimmer e.g 35->50->40->50. See
For some dimmers it is better to disable autoupdate, it’s your choice, but it’s only a visual effect really. For some types I think the Zigbee binding does this for you.
Then there’s the ‘master’ Group status, calculated from member states each time one updates. As we’ve seen, the member states are going to be all over the place, then so will the calculated Group state.
Again you may get visual effects in the UI.
That shouldn’t matter … but there was a UI bug that transformed slider state updates back into commands, so creating a loop cycle of chaos, but that should be fixed at OH3.1 I think. No sign of the ‘extra’ commands you would get from that bug, so I do not think it is a factor here.