In the course of developing an IoT platform the packet data structure needs to be decided. This is the data structure that is proposed to be used to send data from the sensor to the server. The server will then need to interpret this data to correctly sort and store the data. The data contained in this packet is very much based on the hardware and inner workings of the parts involved, but it would be better to abstract this data to store it. In the end the person who views the data will not care about all these id numbers and the only data needed is a timestamp, location, type, data value, and unit. All the id information can be abstracted away from the user. This then leads to a proposed method of data abstraction. However we need to take into account multiple groups, sites, and locations.
The above proposed data structure would represent the sensor (and actuator) locations. Although the word “location” is refers to a single sensor or actuator. For example I might name one of these locations “Row 1 temperature” and another “Row 1 humidity.” In order to avoid an excess number of data tables it appears no issue to combine the “location” and “sensor type” into a single reference called “location.”
How we would read this diagram is that a group (or customer) might manage more than one site (building or area) and inside that site there will be a number of sensors or actuators. Each sensor or actuator is related to a physical location, which resides in a site, which is then managed by a group.
This still does not resolve how we will translate the data coming in from the sensors into this structure. This logic will be contained in the Python script on the server which will receive the raw sensor data, then decide which sensor or actuator id to assign to the data. The data is then written to the data store (database) with the timestamp, location, and value.
In order to handle the raw data coming from the sensors, and allow a way to link the sensors to this abstracted data another set of database tables will be needed. These database tables will track the various connections between the sensors/actuators, gateways, and hubs.
The above data structure illustrates the relationship between the various hardware devices in the platform to allow connectivity. We can read this by the following: one or more sensors are located in a sensor module, along with a radio module. When the data is transmitted to the gateway through the mesh network each packet will contain the node’s id and the sensor’s id, and other data specific to each sensor.
This data is then received by the gateway where the node id of the mesh coordinator is appended, then the gateway appends its own gateway id to the data and is sent through an MQTT channel to the hub that it is connected to. Once received by the server, the Python script, which is subscribed to the MQTT channel the data arrives on, will parse this data, use the the data table that links the hardware sensor/actuator to the abstracted sensor/actuator in the abstracted data structure. These table links will be performed ahead of time during the time of adding a new sensor to the system.
In the next section we will discuss about the database and what tables and relationships will be needed to store the above data structures.