As suggested in comment on !103 (closed), I think keeping 10 Hz saturation monitoring updates on an output channel preferable.
It can, however, be a different output channel than the one for fast data such that it can bind to different interface.
I had to update the interface between correction device and addons a bit for this:
Addon needs to know its prefix in the schema
It used to only be passed to extend_device_schema (where we can add an OUTPUT_CHANNEL)
To actually writeChannel at runtime, we need to know the full name of the channel
Addon needs to know train ID per input such that matching works
Could extract from hash (and initially did), but that's cumbersome - and breaks in my testing environment where timeserver is made up, but replayed data has actual train IDs
David Hammer authored92c6c04d