MQTT
In some scenarios, e.g. to handle a lot of updates, Storage Manager may use an MQTT client to listen to events and store data from these instead of using HTTP POST to update the database. A message queue (MSMQ) may be used as a buffer to handle rapid bursts of events.
Event Topic Structure
The event topic structure is /[PROJECT]/[EVENTTYPE]/[PAYLOAD]/[ENTITYID] /[PROPERTYID]/, e.g. “/test1/observations/iotentity/CNetOffice-3308/3308Occupancy/“.
PROJECT
We start the topic with the project name (“/TEST1/”) in case we have other applications on the same LinkSmart nodes or start re-using existing sensor installations that publish with different topic structures to the same event broker
EVENTTYPE
The “purpose” of the event within the system, suggested values are “observations”, “metadata”, “DF”, “SYSTEM”. Sensor proxies will send measurement data (“observations”) and IoT entity definitions (“metadata”) when new sensors are discovered or updated.
PAYLOAD
This is used to distinguish between different payloads ; e.g “iotentity” for events using the IoTEntity (JSON) format like measurements (“observations”) and entity definitions (“metadata”). This classification depends on the selected “EVENTYPE”, and is currently 1:1, but it’s included for extensibility and to allow migration to alternative formats should the need arise. The current set of values are “iotentity” for EVENTTYPE=”observations” or EVENTTYPE=”metadata”.
ENTITYID/PROPERTYID
For the event types “observations” and “metadata”, the entity and property id will follow the PAYLOAD classification. Subscriptions to observations for a specific property from a specific sensor will look like “test1/observations/iotentity/CNetOffice-3308/3308Occupancy/#”, and all observations from a specific sensor like “test1/observations/iotentity/CNetOffice-3308/#”.
OTHER
Other (sub) classifications may be added to the topic as needed, depending on the event type.
Examples
/[PROJECT]/[EVENTTYPE]/[PAYLOAD]/[ENTITYID] /[PROPERTYID]/
/test1/observation/iotentity/WasteBin_843582/843582_FillLevel/
/test1/observation/iotentity/CNetOffice-3308/3308Occupancy/
/(test1/observation/senml/CNetOffice-3308/3308Occupancy/)
/test1/metadata/iotentity/CNetOffice-3308/3308Occupancy//
(TEST1/metadata/json-ld/CNetOffice-3308/3308Occupancy/)
/TEST1/query/dfl/[TARGET_DFM=instance_id?]
/TEST1/query/dfl/water-plant
Payload examples
The topic is just to enable filtering and subscriptions to different levels/dimensions – we should not depend on parsing the topic to find out which property the value belongs to, so id:s for sensors or system components (“SYSTEM”) should included be in the payload. In the Iot Entity JSON format the payload would look like this for an observation:
{ "About": "CNetOffice-3308", "Properties": [ { "About": "3308Occupancy ", "IoTStateObservation": [ { "Value": "0.69", "PhenomenonTime": "2014-06-09T18:08:40.968Z", "ResultTime": "2014-06-09T18:08:40.968Z" } ] }, ]}
One could also send several observations in one message (and several properties as well):
{
“About”: “CNetOffice-3308”,
“Properties”: [
{
“About”: “cddf5b70e8c711e3ac100800200c9a66”,
“IoTStateObservation”: [
{
“Value”: “3.000000 7.000000”,
“PhenomenonTime”: “2014-06-09T18:08:40.968Z”,
“ResultTime”: “2014-06-09T18:08:40.968Z”
},
{
“Value”: “2.999996 7.000000”,
“PhenomenonTime”: “2014-05-09T18:08:40.968Z”,
“ResultTime”: “2014-05-09T18:08:40.968Z”
}
]
},
{
“About”: “3308Occupancy”,
“IoTStateObservation”: [
{
“Value”: “0.69”,
“PhenomenonTime”: “2014-06-05T15:33:35.058Z”,
“ResultTime”: “2014-06-05T15:33:35.058Z”
}
]
},
{
“About”: “3308Number of vehicle”,
“IoTStateObservation”: [
{
“Value”: “1.0”,
“PhenomenonTime”: “2014-06-05T15:33:35.058Z”,
“ResultTime”: “2014-06-05T15:33:35.058Z”
}
]
}
]
}