Good plan - makes sense using the reply to mean something. In that case we might as well give that reply command number 0 (i.e. "!"[OIN][00][LL][00][Manufacturer...). Perhaps "Broadcast" messages can be sent using a Receiver ID of FF or something. I'm a little hesitant to suggest this, since some commands may make no sense as a broadcast, but let's keep it in the back of our minds for now.

Incidentally, most commands that treat the unit as a specific piece of equipment would have a different prefix - for example, a "Sense temperature on probe 1" sent to the thermometer device with OID 4 might look like "*"[00][04][02][00][01]. The difference here is that it's not the empeg firmware that's sending the request, but another piece of software. I don't know whether this means that empeg commands get priority over device commands, because it's a fairly simple link and I can't see there ever being a priority issue that would really matter to the user. But it's there.

Another thought is that one of two things should happen to the current set of empeg commands, which are all single characters and not at all like this multi-byte mainly-nonprintable-ASCII-characters protocol. One, perhaps rather drastic, option is for them to be deprecated and moved into this protocol. Perhaps a more sensible option is to keep them, supply working "ESLP" commands as well, and advise that we'd prefer that devices directly wanting to control the empeg's playback use the more modern commands.

A thought on the 'multidrop single-connector vs single-drop in-out-connector' problem. To my mind the firmware necessary to drive what is essentially a CSMA/CD network, even over these relatively small distances, is quite complex. It seems simpler to me to implement two buffers and just stuff irrelevant commands from one port to the other via the buffer.

Hmmmm.

Save the whales. Feed the hungry. Free the mallocs.