.. _user/protocols/systemstate: *********** Systemstate *********** Systemstate is a special type of protocol that lets you listen for state change events on all of the Connectware resources. For any object that can be addressed by a :ref:`Resource ID `, the current state can be queried by `read` or be subscribed by `subscribe`. Commissioning File Specifics ============================ The following describes the general format of the commissioning file you will need to assemble to configure this protocol. You can find a fully working example below: :ref:`service-file` Connection Settings =================== The service using this protocol does not create a connection to somewhere outside of the Connectware but rather an internal connection that taps into the internal state of the Connectware. So you will need to configure the connection object the following way: .. code-block:: yaml :linenos: eventsConnection: type: Cybus::Connection properties: protocol: Systemstate connection: {} protocol Required. Must be ``Systemstate``. .. _user/protocols/systemstate_connection: .. include:: ../protocolSchemas/SystemstateConnection.rst Should be set to ``{}`` to confirm that there are not any properties. Endpoint settings ================= Each connection can have multiple endpoints. These define the operations that are supported. For the Systemstate protocol, ``read`` and ``subscribe`` are available as operations. You define an endpoint by adding a resource of type ``Cybus::Endpoint`` and protocol ``Systemstate``. The only property you need to configure for `read` or `subscribe` is a :ref:`Resource ID ` that identifies the component you want to receive updates from. This `Resource ID` is constructed from the `Service ID` and the `Resource ID`, separated by a hyphen character (a minus character: ``-``). On a `subscribe` endpoint, a message with the state notification will be sent on each state change of the respective resource. With a `read` endpoint, on the other hand, it is possible to query the current status by sending any message to the topic with suffix ``req``, then receiving the response on the topic with the suffix ``res``. .. _user/protocols/systemstate_endpoint: .. include:: ../protocolSchemas/SystemstateEndpoint.rst .. _examples: Examples ======== The examples are using the example commissioning file below. Thus, the MQTT topics might differ in your application but the payload needs to be the same (as long as no JSONata rules are being used). The protocol produce the following output messages: When enabling an endpoint: .. code-block:: json { "state": "enabling", "resourceId": "samplesystemstateservice-someEndpoint", "timestamp": 1621256032226 } When the endpoint is enabled: .. code-block:: json { "state": "enabled", "resourceId": "samplesystemstateservice-someEndpoint", "timestamp": 1621256032233 } When the initial subscribe operation was completed: .. code-block:: json { "state": "subscribed", "resourceId": "samplesystemstateservice-someConnection", "timestamp": 1621256032230 } .. _service-file: Sample Commissioning file: ========================== Download: :download:`systemstate-example.yml` .. literalinclude:: systemstate-example.yml :language: yaml :linenos: