by Ranjith Kumar DSM | Mar 21, 2018 | IoT Platform | 0 comments
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.
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.
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.
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.
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
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.
Please take a moment to fill this form