IoT Protocol

A sketch for a simple IoT protocol for typical star network topology.

A lot of inspiration is taken from https://www.mysensors.org

But the way actuators are handled are quite strange.

• Handling incoming messages

However there are a smartSleep() function that handles receive of messages on heartbeats.

• Sleeping

Each sleep function has a "smart" variant, which sends heartbeat and process incoming messages before going to sleep. This is useful for sending out firmwares or commands for sleeping nodes. The controller must support buffering of messages and send them when node wakes up.

I think this is the way to go to always allow the sensor initiate communication.

Introduction

The architecture should be suitable for a star network configuration with one or several (redundant) gateways to many sensors and/or actuators.

• The gateway should only work as a dumb intermediate between sensor nodes and a controller program.
• The controller can either be hosted on a local host or via intermediate in the cloud.
• But the controller program and sensor nodes need to understand the exact protocol used.
• Gateway may be a simple USB stick connected to a computer with the controller program.

Data Model

• Data is divided in sensor data and sensor configuration.
• Sensor data is owned by sensor and updated regularly to controller for storage.
• Sensor configuration is owned by controller and retrieved regularly from controller to sensor.

Data Format

Data is represented as simple key/value pairs.

The key is a string.

The value is one of the supported data types.

Data can represented as:

• As a radio message where values are ordered in a compact format
• As string with key/value pairs

Each data format (sensor data or configuration) has a unique identifiers which mandates its format.

The following types should be supported:

• uint8/int8
• uint16/int16
• uint32/int32
• float32
• binary
• string
• bool

All formats have an empty value which means that is not entered e.g. 255 for uint8. This permit that only some values are updated in a message. For datatypes with variable length these can be very short.

A data format is specified as follows:

• format id (uint16)
• orderd list of: key, value type, ...

A generic parser can be used to translate between string and binary representation from the spec.

binary = to_binary(format, keys, values)
keys, values = from_binary(format, binary)
string = to_string(format, keys, values)

Radio message format (sensor/gateway)

Messaging over radio has the following format

• Node ID (uint32)
• Settings (uint8) - settings like if its encrypted etc.

Following parts may be encrypted with pre-shared node key.

• Count (uint8)
• Message kind (uint8)
• Data format (uint16)
• [Value0, Value1, ...]
• Message CRC (uint16)

Values are MSB (most significant byte/bit first)

The same format is used both for upstream and downstream messages.

Encryption may be supported using a device unique key installed at factory.

Message types

Attach a new sensor to network

• Sensor attach to network
  • Node ID may be empty if network should allocate an ID
  • Data format spec ?
• Attach response
  • Allocated node ID
  • Device key

Get sensor configuration

• Get sensor configuration
  • Node ID
• Get sensor configuration response
  • Node ID
  • Data format
  • Preferred communication channel
  • Preferred update interval
  • Ack preferred
  • ...

Upload sensor data to controller

• Upload sensor data
  • Node ID
  • Data format
  • Values ...
• Upload sensor acknowledge
  • Node ID
  • Config hash (to notify if config need to be requested)

Data format may be empty (i.e. heartbeat) and contain no information.

Typical Sensor Data (owned by sensor)

• Node ID
• Sensor values
  • The different sensor values

Typical Sensor Configuration (owned by controller)

• Preferred channel
• Always on
  • This allows for instant actuators
• Heartbeat period
  • This is the maximum time before an action is performed on the sensor
• Wanted actuator state
  • This should be set the actual state of the sensor
• Sensor should be mostly in control of process i.e. update frequency, need for ack etc.

Design Criteria's

• Keep messages short ...
  • By forcing a single format i.e. predefined sequence of values without keys
  • Use empty values to exclude update on some values
  • Don't use value separators because value size is enough
• A device may use different message formats to allow more flexibility
• A controller may not need to know data format on beforehand
  • Only the message format must be understood which can be uploaded at network attach

TODO

• How to handle attach securely?
  • Only user with access to controller can add node identities to network
• Possibly sensor could provide sensor data spec on attach
  • But config data spec need to be known by both
• How to handle fast response time for actuators
  • Power connected devices should be possible to ping for an instant update

Simulator

Build a simulator to evaluate the system before implemented in hardware.

• Controller
• Gateway (multiple)
• Sensors

IoT Gateway

Operations

Gateway -> Device

• SendControlMessage : Index -> Format -> Data -> Success

Device -> Gateway

• SendSensorUpdate : Index -> Format -> Data

Controller -> Gateway

• GetSensors : [ DeviceId, Index, CRC ] -> [ DeviceId, Index, CRC, Data ]
• SendControl : [ DeviceId, Index, Format, Data ] -> Success

Attach device

• AttachRequest : DeviceId -> [D:Format] -> [C:Format]
• AttachConfirm : same as SendControlMessage with pre-defined control format
• User and controller may be involved in accepting an new device

Security

• Encryption key kan be installed at factory or installed once at attach

Data Formats

TBD.

TODO

• Security using control messages
• Device attach network

References

• MySensors Serial API
• PubSubAlternative
• GatewayDesign

Tags: MQTT, Gateway

This site is maintained by Peter Ljung using the powers of OpenBSD, Ruby, Sinatra combined as WebFactory