Subscription
API Subscription Websocket
Full functionality of Subscription Websocket is described in the connect call below.
Last updated
API Subscription Websocket
Full functionality of Subscription Websocket is described in the connect call below.
Last updated
© 2023 MobiusFlow® - All Rights Reserved - MobiusFlow® is a registered trademark of Infrastructure Software Solutions Limited trading as MobiusFlow® - All other brand names, product names, or trademarks belong to their respective owners
Upon making this request, the server will upgrade to websocket connection. The websocket can then be used to manage subscriptions to MobiusFlow object COVs (change of values), resource COVs, service status changes and broadcast commands. Once the connection is initally established, the websocket server sends back a connected message, featuring the topic 'connected' as shown below. Once the upgrade is complete, all subsequent subcription communications are performed via websocket messages.
Following the inital http connect call, the now upgraded websocket connection expects a follow up authorization websocket message within 10 seconds. The authorization websocket message must feature the topic 'authorize' and a payload containing the API bearer token. An example message is shown below:
On successful authorization, the websocket server will send back a confirmation message, containing the topic 'authorized' as shown below.
If no authorization message is received by the websockeet server within 10 seconds, the connection is dropped by the server.
Each subscription or unsubscription message must contain topic 'subscribe' or 'unsubscibe' respectively. Additonally, each message must feature a payload containing both the subscription type and subscription URI. Valid subscription types are denoted in the following table:
Note, the URI field may contain MQTT style wildcards where appropriate.
An example subscibe message is shown below:
Following a successful subscription or unsubscripton message, the websocket server will echo the message back to the client, confirming the action has been made.
Each event response will feature a timestamp, topic and payload. The topic will be one of the valid event types as denoted in the above table. The payload will contain uri and value fields, the form of the latter varrying based on the type and nature of the event. An example response is shown below:
The values for each event type are as follows:
Switching Protocols
Topic name, will always be "connected"