Elements of a single serial driver are all showing a delay between sending out a command, and receiving/processing the response. All elements using the driver show the same behavior, also across different clusters.
The delay is pretty much exactly the same as the configured element time-out time. Confirmed by modifying the time-out time.
After manually checking the response, it seems to match with the structure defined in the protocol <Response> tag, and also the development logging does not indicate any mismatches. The elements are also not in a time-out state, and parameter values are all filled in.
Any ideas about what could cause this, based on the description above?
Hi Ruben,
Serial communication depends on trailers to know when a message has been concluded, otherwise it waits for the timeout time before sending the data to SLProtocol.
Can you check if the protocol has a trailer configured? Maybe the message format doesn't allow for a trailer to be defined, and you'll have to play with the timeout time. Perhaps even re-combine messages when they've been cut off.
There may be other solutions I'm not aware off, will check with my peers.
After further checking, we managed to work around this by defining a trailer parameter somewhere in the middle of the response, and making sure that one is only followed by parameters with a fixed length.
Follow-up on the follow-up, a header was already present and all values in the response were of fixed length, so we are investigating if there is a regression where these responses would no longer be closed when completed.
Response format (HEX) is: 00 00 00 00 00 05 01 01 02 00 00
There is indeed no trailer defined, and probably difficult because the last 2 bytes indicate status and are dynamic.
The final two parameters in the response are of LengthType ‘fixed’ and Type ‘group’, if that is relevant…
Any idea if that behavior might have been different at some point in the past?