Message is nothing but a predefined data structure that can be preconfigured in the platform with a unique identifier for each types of messages that your device pushes to the platform.

Example Weather Data

{
    "latitude": 32.779167,
    "longitude": -96.808891,
    "temperature": 26,
    "humidity": 77,
    "precipitation": 0,
    "wind": 11
}

Definition

The above message structure can be defined in the platform like the image shown below. Menu => Home -> Message Definition -> Define Messages. Once you have one or more messages defined, you could start pushing messages to the platform from your IoT devices using different protocols. In the above example, we have defined a message with an unique message identifier as 1000

Messages are static in nature, once a message is received by the platform none of its attributes can be changed afterwards. Boodskap stores all the incoming messages into its default big data storage engine Cassandra.

By default the platform understands and works out of the box with plain JSON messages defined using the “Message Definition” module. Here we are going to see how we can send messages using different protocols. To send a message to the platform, you have to compose a json object with the below format, a header and a data section must be present in a well-defined message.

{
  "header": {
    "key": "xxxxxxxx",
    "api": "xxxxxxxx",
    "mid": 1000,
    "did": "ESP8266-12123123",
    "dmdl": "ESP",
    "fwver": "1.0.0"
  },
  "data": {
    "latitude": 32.779167,
    "longitude": -96.808891,
    "temperature": 26,
    "humidity": 77,
    "precipitation": 0,
    "wind": 11
  }
}

Header Structure

• Domain Key (key)
  • Domain key is your tenant identifier, it’s a fixed constant and it will generated upon registering a new domain in the platform, you can get it from the admin console home screen. Boodskap platform is multi-tenant capable, you can have more than one tenant registered, the platform separates the incoming data based on this tenant identifier and stores in separate indexes.
• API Key (api)
  • Every domain (tenant) has a unique API key identifier, this can be changed time to time, it’s like a password for the communication.
• Message ID (mid)
  • Unique message identifier of a defined messages, in this example, we use the preconfigured 1000 message identifier.
• Device ID (did)
  • A typical IoT solution may have multiple devices reporting to the platform, the devices may be similar in nature or could be entirely different, every individual that sends data to the platform should be identified by a unique constant.
• Device Model (dmdl)
  • In the hardware device world, the firmware developers will maintain a device model name for each unique variety of a device type, you may specify it here, or if you are not sure about it, you can leave it as a “-” value.
• Firmware Version (fwver)
  • Similar to the device model, the firmware developers will maintain a unique version of the firmware (software running on an embedded device) that ships with a hardware, you may specify such version here, or if you are not sure about it, you can leave it as a “-” value.