# Publishing service state
For any services with a remote client (UI), it is desirable to publish current service state and sensor readings. This state tends to be a superset of the published history data, and may include non-numerical values.
We reserved topic space for these messages under
Because detailed state data requires support from consuming clients, we do not define a global payload format for messages.
The payload schema for Spark state events can be found here.
Service state events should be published to a topic matching
brewcast/state/<Service ID>. You should NOT publish directly to the
You can use any valid value for the
qos flag in MQTT.
It is common to set the
retain flag for state events.
This allows quick synchronization with newly connected clients.
Empty messages are used to clear retained messages (opens new window) set for a topic.
If a payload is set, it must be a JSON-serialized object. There is no pre-defined schema for message payloads. Each service is free to define its own.