ActionId of Commands with > 1 response not traced correctly about libbidib HOT 7 OPEN

@BLuedtke I had just a quick look at the linked response queue and if I understand it correct, there is 1 queue per node.

Example: If you set an aspect on 2 accessories on the same node (almost simultaneously). The first aspect takes very long to complete, and the second is very short. The "final" execution state of the second aspect is delivered before the "final" execution state of the first aspect.

If I get it right then the evaluation is currently not correct, right? You should be able to test it with 2 macros (1st with multiple steps of delay, 2nd with only a short delay).

I'm not sure if moving the entry is the solution. If you move the entry (because you got the wait message) and then an error happens during execution (Murphy ...), the node will send an error response immediately, before the other entry is received. Now the entry is in the wrong position.

Maybe I didn't get the problem right, but maybe this examples help you.

from libbidib.

@BLuedtke The expected wait time is sometimes a guess. I have seen nodes that send weird wait time values ...
... and I'm pretty sure the error response is sent immediately :-)

from libbidib.

A perfect solution probably does not exist because the BiDiB boards themselves do not track requests with their respective feedback. We can only make an educated guess on what feedback we expect for each request type.

from libbidib.

Maybe you can adjust the logic:
You can evaluate the bit 7 and bit 0 of the EVALUATE parameter of MSG_ACCESSORY_STATE. If both bits are 0 the "last" message of normal handling was received and you can remove the entry.
If bit 7 is 1 the "last" message of error handling is received and you can remove the entry.

from libbidib.

Yeah, that works for knowing when the "last" reply of type MSG_ACCESSORY_STATE is received. Thanks for the input!
However, this does not get around the queue problem: A response to a different command may be expected between the first and second MSG_ACCESSORY_STATE response. If we do not pop the head of the response queue after the first MSG_ACCESSORY_STATE, the response to the unrelated command would be compared to the "wrong" response queue entry. However, there might be some tricks to get around that.

Edit: One workaround just came to my mind. In the response queue entries we do save the "creation time". Now, when receiving the first message of MSG_ACCESSORY_STATE, this message tells us how long we'll have to wait. In the example, that was 0.3 seconds. If we could manipulate the queue, we could move the response queue entry for MSG_ACCESSORY_STATE backwards when receiving the first reply, moving it until its (creationtime + wait time) is later than the creationtime of the previous response queue entry. That would also have to be done when new messages are added to the response queue afterwards.

from libbidib.

I'm not sure if moving the entry is the solution. If you move the entry (because you got the wait message) and then an error happens during execution (Murphy ...), the node will send an error response immediately, before the other entry is received. Now the entry is in the wrong position.

I'm not sure if the error response would be sent immediately. Based on the spec, I'd expect to receive a message with the appropriate error code after the wait time of the first message. Of course, if something such as a short circuit occurs, we can not rely on the rest of the messages being received as we expect. They would time out after roughly 3 seconds.

from libbidib.

Interesting. With our use of the Fichtelbahn control boards, the wait time seems to be directly related to how we configure the servo motor PWM settings with the BiDiB Wizard. But definitely good to know about the error being sent immediately.
I think a bigger overhaul of the implementation of response tracing in our source is needed eventually. Both the current datatypes and functions for parsing are unsuitable for modification and/or rather hard to read.

from libbidib.