Thin Industrial Internet Protocol

TIIP is a wire protocol using JSON as its infoset. It is created for lightweight messaging in IoT solutions. It is loosely defined to support API creation.

The name/ID of the protocol (including version). Ex: "tiip.1.0"

Seconds since 1 Jan 1970, as String. Include as many decimals as needed for increased accuracy (millisecond accuracy is often convenient). Handeled centrally - for instance set by the server for each messages on their arrival. See also clientTime.

The timestamp set by clients (devices) when a message is constructed. This is separate to timestamp because it can not be trusted by the central point (server) to be correct or same as every other message creator in the system.

Message ID. To identify an answer to a request for instance, in asyncronous communication.

Session ID. To identify a session in case of non-implicit sessions.

Some different standard values are:

• init, kill: Messages for persistant connections, a "login" message (answered with rep) and a disconnect message.
• req, rep: Request-reply pattern.
• sub: Publish-subscribe pattern: Subscription request.
• pub, unsub: Publish-subscribe pattern: Publication and unsubscribe messages (no replies).
• create, read, update, delete: The standard "CRUD": the four basic functions of persistant storage, to use instead of req if desired.

Simple boolean key in reply messages only, that indicates the outcome - if it was successful or failed.

ID of a tenant in a multi-tenancy solution.

Origin ID, with prepended nodes further along the communication chain if needed.

The targeted process or sub-system. An ID or address that the receiver can use to route the message internally.

A possible sub-process to target inside the target. If for example target is an external node of some sort, and it is needed to specify a targeted process inside that.

Parameters/switches to specify the message even deeper. Often regarded as the "arguments" to the requested API "function" specified in signal. Not to confuse with payload which is actual data or content.

The data channel, as a string, that carries the message. Suitable in the pub/sub pattern.

Meant to be used as the "function" of the API between 2 communication nodes -- the command to the receiver. (payload contains the functions "arguments".)

Content to be sent, as a list.

Ex:

• Sensor values (push data from a device)
• User records (as answer on a request to a database module)
• Notification records published on an internal bus channel
• An error message
• etc.

A gateway sends position data to the server:

{
    "protocol": "tiip.1.0",
    "clientTime": "1379921889.4",
    "type": "pub",
    "signal": "updatePosition",
    "arguments": {"channelId": "x72iuP"},
    "source": ["gpsSensor239"],
    "payload": [{"long": 59.21625, "lat": 10.93167}]
}

Message from the server to a gateway that the motor should be stopped:

{
    "protocol": "tiip.1.0",
    "timestamp": "1387345934.702",
    "type": "req",
    "target": "g13",
    "subTarget": "motor",
    "signal": "stop"
}

Message from a web client to make a change in the configuration data of a user:

{
    "protocol": "tiip.1.0",
    "clientTime": "1387349004.221",
    "type": "req",
    "target": "configuration",
    "signal": "updateUserDashboard",
    "arguments": {"id": "4Xd0hN3z", "widgets": ["map", "temperature", "alarms"]}
}

"-" ignored or not present

Further, target, signal and payload can be used for specific purposes. As an example, target can be used to target the use of a certain client controller or session type.

"-" ignored or not present

* In case of older data and/or client hierarchy