Are we talking about the events.log snip here? Let’s clarify -
2020-05-17 00:08:00.200 [ome.event.ItemCommandEvent] - Item 'iDiningRoomLamp' received command ON
2020-05-17 00:08:00.211 [nt.ItemStatePredictedEvent] - iDiningRoomLamp predicted to become ON
2020-05-17 00:08:00.226 [vent.ItemStateChangedEvent] - iDiningRoomLamp changed from OFF to ON
There’s an Item command. The log doesn’t tell us who done it or when, rule or UI action for example. That’s fine, you can tell us that. Please do so, when showing logs - “what does it show, what happened.”
The log cannot tell us if there is some delay between the rule or UI event and the command appearing in the log. You can probably estimate that, if it’s you poking UI buttons.
If not, and you feel this part might be delayed, we might have to construct some kind of parallel action to see what the timing is about.
Frankly, this part - UI action to openHAB - is not likely to be the problem and there is other stuff we can look at more easily first.
So, first line of log squeezed for info.
Next, a “prediction”. This is the autoupdate feature at work, pre-empting the command by guessing the effect it will have.
That prediction is actioned in the next line, and the Item state updated to the auto “guess”. Great, this gives a snappy UI responsiveness, which is not affected by any turnaround delays in something happening at a remote device.
By design, autoupdate hides the effects of any delay with your external devices.
The “transaction” here is a fantasy transaction, and as you say is all over in 26mS.
So the log boils down to - “there was a command”.
It shows us nothing about what or when the binding is up to, or when any response might come back from the remote device.
That’s all fine, that’s why we need to look at binding debug logs.
Readers here didn’t even know if this log is associated with one of your observed delays or not. Please tell us the circumstances when sharing logs, don’t wait for an inevitable interrogation.
I couldn’t get the video to work really. I don’t doubt you have problems, made all the more frustrating by being intermittent.
“Show us the evidence” is not “don’t believe you”, it is “give us info for diagnosis”
We’re on post #26 of this thread with no recent debug log given here.
We do now have a log available elsewhere, but it spans many hours. We have not been told if it includes any delay incidents, nor when they occurred. We have been told there is stick-swapping going on, how much chaos and distraction that might add in that particular log I don’t know.
I have no zigbee expertise, and it sure won’t be me diagnosing at that level. I did spend an hour trying to figure out the meaning of two-serial-port issue, and still wonder if a broken bridge Thing might add retry delays - I don’t think so.
I can tell what you can do to make it easier for an expert to look. Tell them where to look e.g. “at 10:20 I clicked on Lamp X in UI, and it took 8 secs to light up. Here is the Thing/channel details for Lamp X, here is the debug log for several hours.”