Having written hundreds of device drivers over the years, and designed many protocols myself, I've manage to squeeze out a few ideas about what makes for a good control protocol. It's something that is at the heart of this thing of ours, but it often gets far too little attention by the folks who create the hardware we are all trying to beat into submission. It's too often an afterthought or written too much with the device's convenience in mind, not that of the automation system.
So, a while back, I wrote up this document to lay out what all is involved in creating a control protocol and how to create good ones, where 'good' means what's best for the consumers of that protocol, what's easiest, what's most robust, etc...
[Link: charmedquark.com]It may or may not be of that much interest to folks here. But, if you are interested, or you know someone who is starting down the road of creating a device that will need to be controllable, or you'd like to give a pointed suggestion to someone who already has and you aren't too happy with it, feel free to point them to this document.
The first sections are not particularly technical, so you might appreciate those bits even if you aren't ever going to be writing code to interface to a device.