Remember that weird command that comes in during the middle of the macro send? Well, I figured I would use it to work on incoming command handling. Big mistake!!! This command turns out to be an ACK from the remote device with the new status in the "command one" byte. Not such a big deal I hear you say, except that it also doesn't send "command two" so if you are waiting for 9 bytes, you will wait for a very long time! Fortunately the documentation doesn't mention this, so I was the lucky guy that spent most of the evening trying to understand why the incoming command was not long enough and how to detect when it would not be long enough. Needless to say, there is some special handling of ACK messages now and it seems to work. The NAK message probably needs more special handling but I have not been able to generate such a command so I cannot test it.

Now I have to get the devices to send me their status changes, I think I can put them into the "All-Link table" and listen for group cleanup messages, but we will have to see.