Generalized things message subject schema

[rcurrie]

Starting a thread to discuss and finalize a generalized way to configure and control our various 'things' via messaging subjects and parameters. Proposal is for a simple set of start/stop/set/get set of predicates that will work across all the sub-systems.

Here's a bit of a narrative to illustrate:

Experimenter decides to use "buzz" which consists of 3 pi's controlling imaging, spikes, and vitals respectively. They pick an experiment uuid and generate an associated github issue to track the experiment and any long form details:

buzz/vitals/set {"temperature": 37.0}
Set the temperature target on buzz

buzz/vitals/get
Tells buzz to broadcast its current settings and vitals to which it responds by broadcasting:
buzz/vitals {"temperature": 35.1, "running": false}
It's not running so the heater is not on, but we still bet the current temperature.

buzz/vitals/start {"uuid": ... "issue": ... }
Tells buzz to start which causes it to turn the heater on and try and get to 37.0. Querying the temperature via get would then show running to be true and the latest temperature reading. Any data for future analysis will be appended to archive//vitals/...

buzz/imaging/set {"stack_size": 8, "delay": 7200}
Tells buzz to take 8 layers of images per well every 2 hours (2 * 60 * 60 = 7200 seconds)

buzz/imaging/start {"uuid": ... "issue": ... }
Tells buzz to start taking images according to its current settings. Images will be appended to archive//images/

Each Pi pushes data up to its respective experiment sub paths on the prp object store and updates the associated manifest.json:

archive/<uuid>/vitals/... archive/<uuid>/spikes/... archive/<uuid>/imaging/...

All message bus events would be ephemeral, anything important for analysis would need to be exhausted into the object store.

@pvbaudin @sseiler @kvoitiuk @ashsrobbins @nahawtho @surygeng @yoheirosen Thoughts?