This section describes the communication protocol between the control system and SDM using RPC calls using the JSON-RPC 2.0 protocol



Commands must be formatted as defined in the JSON-RPC 2.0 protocol
All commands sent over TCP transport must end with <LF>
All replies are formatted as defined in the JSON-RPC 2.0 protocol
All replies over TCP transport end up with <LF>
<LF> stands for “line feed”, corresponding hex is 0x0A

Transport protocols

JSON-RPC 2.0 commands can flow over different transport protocols, once enabled in the api section of the config files. Per default they might not be enabled. Edid the config file to suite your needs and restart sdm service

Transport Config Datatype Example Supported Versions
TCP jrpc2TCPInterface string enp1s0 >v1.8.50
TCP jrpc2TCPPort int 64823 >v1.8.50
TCP jrpc2HTTPInterface string enp1s0 >v1.8.50
TCP jrpc2HTTPPort int 64880 >v1.8.50

In subsequent pages all methods are described that can be used.


All JSON-RPC 2.0 services do support asynchronous message processing. 3rd party control Systems must keep tracking of the id’s to determine whether a request was successful or not

TCP transport

Any TCP capable application can be used to test commands. Do not forget to end up with <LF>

HTTP transport

The body of the HTTP POST request must contain the complete JSON-RPC request message, encoded with Content-Type: application/json. Either a single request object or a list of request objects is supported. If the request completes, whether or not there is an error, the HTTP response is 200 (OK) for ordinary requests or 204 (No Response) for notifications, and the response body contains the JSON-RPC response. If the HTTP request method is not “POST”, SDM reports 405 (Method Not Allowed). If the Content-Type is not application/json, SDM reports 415 (Unsupported Media Type).

Test from a linux shell:
curl –header “Content-Type: application/json” –request POST –data ‘{“jsonrpc”:“2.0”,“id”:1,“method”:“sdm.Get”,“params”:{“property”:“version”}}’ http://host:64880