User:Delson9536/sandbox

SimplyTiny for IoT

The SimplyTiny data exchange format is an invention of (Delson) Dan I. Osunde Fogbel and it is a spin-off from his invention/patent GB2498236 (data transmission over signalling). SimplyTiny for IoT is a string delimiter based method designed for exchanging IoT data (opaque or structured data) between IoT device objects and their associated IoT platforms in a simple but highly efficient way with barest minimum impact to the (micro) processors of low complexity IoT devices. The SimplyTiny formatting method supports message acknowledgements. It also offers flexibility in allowing the IoT device to use a range of delimiter to mark each header field position as well as the end of the header section (start of the payload content).

The SimplyTiny format works as follows, the character in the first position specifies the delimiter (field boundary marker) to look for. The delimiter can be any one of the following safe characters (does not include whitespace): _.+!*',. One of these characters can be used as the delimiter for the data transfer session. The preferred delimiter is placed in the first character position and will be used to separate the header fields. The end of the header section / start of the payload content data section is marked with the said delimiter combined with the right parenthesis character: ) For example if the asterisk * character is the preferred delimiter to be used for sending a message from a device, then the message would look like:

*header1*header2*header3*)any-data-content-goes-here It is recommended to always choose a delimiter that will not be used in any of the header fields. The complete SimplyTiny header field names are as follows (assuming asterisk as delimiter):

*udid*token_id*message_id*message-type-indicator*gps_lat*gps_long*signal_strength*power_usage_info*unixtimestamp*)large_or_tiny_data_content The udid field is a mandatory field which holds the IoT device (hash) id. All other fields are optional. Optional fields can be left empty. For example a device wants to send some opaque base64 encoded data bXkgc2Vuc29yIGRhdGE= with message_id 101 with no other header fields then format would look as follows: *54ed2597a78b651334*S105*)bXkgc2Vuc29yIGRhdGE=

Another example is a device wants to send JSON payload: {"sensor1":400, "sensor5":"low"} and the device object on the IoTGtw platform is configured to validate the device token with the one pre-configured. In this case the IoT device must provide a valid token (i.e. Kh_12rD2w). Assuming the device is also configured to add a timestamp (i.e. 1348276362) of when the data left the device for diagnostics and analytics purposes. The IoT device would construct the data as follows and inserts this as the payload of the transmission protocol such as UDP or TCP. *54ed2597a78b651334*Kh_12rD2w*******1514936975*) {"sensor1":400, "sensor5":"low"} In another example if message_id (i2356) is required to be sent along for each message (recommended) the payload would look as follows: *54ed2597a78b651334*Kh_12rD2w*i2356******1514936975*) {"sensor1":400, "sensor5":"low"} To indicate that this payload is expected to be acknowledged then the the it would look as follows: *54ed2597a78b651334*Kh_12rD2w*i2356*3*****1514936975*) {"sensor1":400, "sensor5":"low"}

The message-type-indicator field can be used to indicate if the message requires an ACK receipt or not. The following are the valid values and their description.


 * 0 or empty =  No Settings on device side, use the service template setting (device assisted ack rules) to determine whether or not the message should be ACK’d or not.
 * 1 = this message is an ack message
 * 3 = This is a confirmable message, an ACK response is expected.
 * 2 = Do not send an ack for this message (ACK will be skipped by the platform even if device assisted ack is enabled)

The type of ACK response to send/expect back is based on the rule configured in the IoT platform. In the TrillionThings IoT platform the ack configuration is configured in the service template with the “device assisted ack” feature. ACK responses can be configured echo back: received message_id, payload_length or a pre-defined static string. In this example if the ACK response is setup to return message_id then the ACK response would look as follows: Note: The same delimiter character received in the original message is used as the delimiter for the ack response. Also note that all non-required fields after the last field can be left out for efficiency: *54ed2597a78b651334** i2356*1 If the ACK response is setup to return payload (data content) length then the ACK response would look as follows: *54ed2597a78b651334***1*)32 If the ACK response is setup to return a static string of “ack-1001” then the ACK response would look as follows: *54ed2597a78b651334***1*)ack-1001