BluPhenix,

TSU/FRX only retry the datagrams if they miss the confirmation of the receipt. Overall, what they did for Pronto is a sort of “lightweight” TCP over UDP optimized for their specific usage. As a result it is robust enough for the remote control and, on the other hand, has very little overhead.

I now see what you actually meant by the lack of buffering – sure, if all the actions have not been pre-packed into a single multistep macro, like when the user wants to press a random button in the middle of execution of another macro, then he is out of luck.

Regarding multistep macros - just wanted to make sure that I say it clearly:

According to my observations and simulations, the physical structure of the message payload allows a series of individual commands packed into one datagram. With the latest PEP2/firmware, if a multistep macro assigned to a button contains commands sent to the same extender, then the entire macro gets sent in one message. One can observe it with an arbitrary mixture of Serial, IR, delay, relay and powersense steps, provided that those steps are included in the action list of one button. Powersense by itself is a 'macro inside a macro' - it contains the evaluation of the condition, command to execute if the condition is true and the optional delay after the command.

I am now running a working RFX9600/9400 simulator that can do the above. The TSU9300/PEP2 have no clue that on the other end is not an actual RFX, so they cooperate happily.