IoT Implementation Series – Design the Data

As part of the IoT Implementation series, this topic covers the best practices in designing the data communication between the edge device and the Central Platform.

IoT Device to Cloud response

Humans always expects a response for every action. The response can be emotional, physical, visual or in any human understandable form. The same is the norm when we interact our intensions via an IoT device. Developers often miss the point that the edge device too need them for a completion of the response back to the humans. The acknowledgement user need is different from what the protocol provides. The protocol level ack message only confirms the receipt of the data at the edge or the server. But the action happens after the protocol ack is sent back. So you need to make sure you send back a message from the device or the server once the intended action is complete. The response should be a success or a fail message based on the outcome. Check the outcome before the message is triggered.

Design the right message handle

All IoT Protocols have an identifier for the event and command messages between device and manager application. MQTT calls it by the name Topic. It is very important to define good and clear topics for the communication. The topics should be very relevant as it should be understandable by the Humans too. It is advisable to have a mandatory device identifiers on the subscriptions, as we will be able to know where the command is going. For the events, it is the implementors choice to use the topic.

Send relevant Data to MQTT Cloud

An half baked data is equivalent to having no data. So make sure you put all the data available into the cloud from the edge. For example, when we collect a machine status from the edge device, the core information is about the health of the machine like temperature, coolant flow, vibration level. But we often loose sight of the time relevance at the edge. It is better to get the time from the edge device than use the time on the server. Add the device identifier also as part of the data which can help a lot during the data analysis. There will some more core information which may not be of interest today. But it is better to have them for future analysis.

Identify & Group the Devices

Different IoT Cloud application has different kind of device identification process. Most of them get this done when they add the device. But this process increases the human effort to add these devices. Bevywise IoT Platform allows any device to connect if they have the right auth keys. The device can send additional data later. Most of the IoT Protocols today does not allow you to send more information while connecting to the server. So identify the register command and the list of data requested by the IoT Platform and send it as a separate message based on the protocol.

On the platform side, you will be able to create device specific user interface for your operators based on their roles. The IoT Platform mostly need to know the type of the device, manufacturer, location, etc. But you can always customise it to have more information as needed for your IoT Device management and inventory

Mobile integration

One of biggest deceiving point in the IoT Implementation is that the developers tend to use the same protocol to connect your mobile applications. But that is not the right IoT implementation of the mobile application. The mobile application should be built over the REST API of the IoT Platform and should be integrated with messaging system like Firebase Cloud messaging for the notification. As an option, developers can use the protocol based communication when the app is open for instant messages to the server, but should not depend on it end to end.

Bevywise Networks is an end to end solution provider for IoT Implementation for any vertical from Edge devices to IoT Cloud Platform. We would be happy to help you get your solution tailored by us.