Shaker and environmental-controller events#
Each listed semantic operation emits started, completed, or failed lifecycle records.
Shaker#
The instrumented legacy.shaking.Shaker frontend emits:
Operation |
Primary fields |
|---|---|
|
|
|
|
Temperature controllers#
Instrumented temperature-control frontends emit the operations their public APIs support. The
legacy TemperatureController does not have a separate activation method; direct frontends such as
the HighRes sample stores do.
Operation |
Primary fields |
|---|---|
|
|
|
|
|
|
|
|
|
|
hold_temperature records a protocol-requested dwell while the controller remains at its existing
configuration. It does not send a new temperature command and does not assert that a resource has
reached the configured target.
For wait_for_temperature, current_temperature is the controller’s final sensor reading that
satisfied the requested tolerance. It is emitted only on successful completion and does not imply
that a loaded resource itself reached that temperature.
If a resource is assigned when an operation starts, the event’s resources contains that direct
loaded resource. If the holder is empty, resources is omitted rather than inferred from
surrounding deck state.
New direct temperature-controller frontends, such as vendor-specific Inheco frontends, should
implement this semantic EventBus contract at their own public API boundary. They do not need to
inherit from the legacy TemperatureController class.
Humidity and gas controllers#
Environmental-control frontends use the same set/activate/deactivate lifecycle for humidity, CO2,
and O2. Targets are fractions: 0.90 means 90% RH and 0.05 means 5% gas concentration.
Operation |
Primary fields |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The HighRes sample stores currently emit these operations for their installed controllable channels. See the device event reference for model coverage.