trackerNum should not exists inside the protocol

[loucass003]

currently the tracker id holds the device id and the tracker num. like so

table TrackerId {
    /// The device the tracker is associated with. If there is no hardware device it is
    /// associated with, this should be `null`.
    device_id: solarxr_protocol.datatypes.DeviceId;
    /// There are possibly multiple trackers per device. This identifies which one.
    tracker_num: uint8;
}

but the issue with this is that you need to know the device id to change anything with the tracker. In many instance in the server code you have to do a lot of checks to make sure you are getting the right tracker.

also 99% of the time you are not changing settings to a device but to the tracker. So working with the device as the id is not that necessary.
And when you are mutating a device you will only send the device id anyway, no need to send a trackerNum.

here in the server code a function to get the tracker from its tracker id

	public Tracker getTrackerById(TrackerIdT id) {
		for (Tracker tracker : trackers) {
			if (tracker.getTrackerNum() != id.getTrackerNum()) {
				continue;
			}

			// Handle synthetic devices
			if (id.getDeviceId() == null && tracker.getDevice() == null) {
				return tracker;
			}

			if (
				tracker.getDevice() != null
					&& id.getDeviceId() != null
					&& id.getDeviceId().getId() == tracker.getDevice().getId()
			) {
				// This is a physical tracker, and both device id and the
				// tracker num match
				return tracker;
			}
		}
		return null;
	}

the protocol should hold unique ids for the device and the tracker.
lets see what a rewrite would look like

table TrackerId {
    id: uint8;
}


table TrackerData {
    tracker_id: solarxr_protocol.datatypes.TrackerId;
   // i removed everything below for convenience because it does not add any value to that topic
}

struct DeviceId {
    id: uint8;
}

table DeviceData {
    id: solarxr_protocol.datatypes.DeviceId;
    // i removed everything below for convenience because it does not add any value to that topic
}

[TheButlah]

I don't mind having tracker id as its own unique id. I believe this design was because originally we thought this protocol would also be sent from the firmware itself, and the firmware can't easily make a unique id for a tracker. It can only make a unique id for the device.

But that limitation of firmware is irrelevant to the application protocol that we have in SolarXR. So feel free to make the change.

[Eirenliel]

it could still be used for firmware protocol, but tracker_id on one side won't match tracker_id on the other, which is fine

[loucass003]

the firmware protocol wont be in that section of the schema. it will be its own schema anyway.
And from the looks of it there probably wont be a flatbuffers firmware protocol because of the footprint of the flatbuffers library

[TheButlah]

footprint of the flatbuffers library

footprint of the payload (not the library). But otherwise, yeah I agree

[Eirenliel]

that's not the reason to make different structures, a recepie for confusion