I agree with this wholeheartedly. Having some way to connect a whole lot of boxes without having to swap them or build serial line splitters is a great thing. My idea for defeating the ID number problem is:

Modify the message format you give to be: [Prefix][Sender][Receiver][Length][Data...]

All commands give by the empeg firmware to receiver units have a prefix "!". These commands are the empeg unit directly commanding the receiver units to do something (rather than (possibly third-party) software in the empeg using functions of the receiver units. The first byte of the data is a command byte that tells the receiver unit what the empeg wants it to do.

When the empeg boots up in-car it sends a special init command outward, signified by the command byte being 0. In other words, this command is "!"[00][00][01][00] When a unit receives an init command, it takes the receiver ID, increments it, and learns this as its OIN (Operating Identification Number). It then passes this command outward with the new receiver number. This gives each unit a unique number at start-up which the empeg can use in communications. In other words, the empeg is always OIN 0, and each unit in turn outward is numbered sequentially.

The init command is the only command which is relayed outward in this fashion; all other commands are between the empeg and the receiver unit directly (i.e. using the correct sender and receiver).

Maybe the last device in the chain, recognising that there's no device attached to its outward side, can send back to the empeg a reverse-init command - "!"[OIN][00][01][00]. This tells the empeg the highest numbered device it has, which allows the creation of fixed-size memory arrays to deal with the devices and also allows troubleshooters to see how far along the chain the bad connector is.

The other important command at this stage is the Identify command. This takes the format "!"[00][OIN][01][01] and is sent by the empeg to each OIN in turn. The receiver unit sends back a message giving information about itself. My idea for this message is "!"[OIN][00][LL][01][Manufacturer ID][Model ID][Flags]

Manufacturer and Model are both 2 bytes; this allows a more heirarchial menu structure for those with many devices on their chain. The flags indicate the operational parameters of the receiver unit in question. I'm leaving these as a useful thing to fill out later, but I can think of things like "always on / must be switched on", "commercial / diagnostic" and other vague ideas.

Now it's someone else's turn.

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