I plan to rewrite the Messages tool in python with Qt in the future.
A systematic solution to distinguish between a normal field and an index field would be nice indeed. Maybe it could just be a simple rule like:
The index field shall be the first field of the message and shall be named "id".

The pprzlink message header has a field for class/component id. For now, only the class part (4 bits) is used. The idea of components was to remove stuff like sensor_id, and display messages correctly in tools like messages. However the max ID is 16, so it means that the IDs should be allocated at compile time to avoid limitation ?
The other solution is indeed to use a field of message with a standardized name. We already have comp_id for some sensors. I think only the name and type of the field should matter, not the position in message.

• Either defined in the header of the message: <message name="AIRSPEED_RAW" id="138" index="sensor_id">
• or any message with a uint8_t comp_id if you prefer

Could e.g. fill an array like:

This would be indeed be nice, also for the real-time plotter

The ABI_ID is a logical way to find out who sent which ID, but in case of actuators (e.g. ESC message) the 4 bit comp would be a little insufficient.

By defining in the messages.xml which field is an index, we do not need to change anything anywhere to the transmission nor reception nor logging. It would just be a visualization thing. If the message has an index, a visualizer like messages or real-time-plot could either filter by index (e.g. plotter shows temp of 1 motor) or show both (messages show both airspeed_raw's). But nothing needs to change in the drone, server, or anything else.