Implementation of Custom MQTT API for Extending the Platform’s Functionality

Table of contents:

At a certain point in the development of the 2Smart IoT platform, the existing communication format between devices and the platform became insufficient. Initially, devices only transmitted telemetry to the platform and received state change requests for their sensors. We needed to handle requests from devices on the platform side. The first client request was to change device ownership, necessitating process automation and the creation of an API for firmware integration across all clients.

Challenge

Analyzing the client’s request, we identified the following requirements:

1. Protocol Selection: We considered HTTPS, MQTT, and TCP. We chose MQTT due to its existing mandatory use for device-platform communication.
2. Secure Communication: The communication channel had to be secure for transmitting credentials to connect the device to a new account.
3. Request-Response Integrity: A clear request-response mechanism was needed to ensure data integrity.
4. Access Control: Access to MQTT topics needed to be controlled to prevent message interception.

Solution: MQTT API Implementation in 2Smart

Topic Structure

Addressing the above issues, we expanded the task to develop custom requests via MQTT API for each client. Two communication topics were created: REQ (request) and RES (response):

• REQ Topic: <user>/req/<device-id>/<api-endpoint>
• RES Topic: <user>/res/<device-id>/<api-endpoint>

The topic structure includes:

• <user>: User’s topic for all communication with their devices and the platform.
• <device-id>: Device identifier on the platform.
• <api-endpoint>: API method name the device is calling.

Security Measures

Given the topic structure, there are potential “threats” where a user’s devices might “listen” to each other’s REQ/RES. To prevent this, access control ensures that a device can only publish to its REQ topic <user>/req/<device-id>/+ and subscribe to its RES topic <user>/res/<device-id >/+. The “+” in the topic path means the device could send/receive any API.

This way, we have separated access to REQ and RES so that no device can intercept platform requests (REQ), but each can receive all responses (RES).

Additionally, to ensure that an intercepted RES packet doesn’t reveal any information, we have encrypted the RES packets.

Limitations

The MQTT API functionality in 2Smart is exclusively available within the Business Platform, designed for managing an enterprise’s device fleet. This limitation is due to the specific requirements of device manufacturing. During firmware installation, the Business Platform generates a special encryption key integrated into the firmware, which is subsequently transmitted within REQ messages.

Data Format

REQ Topic Data

{
   "data": <any_object>,
   "key": "<encryption_key>",
   "id": "<random_number>"
}

• data: Object containing necessary API parameters.
• key: Encryption key for RES.
• id: Unique request identifier to match the RES with the corresponding REQ.

RES Topic Data

{
"status": "<status>",
"code": "<HTTP_RES_CODE>",
"id": "<id_from_req>",
"data": "<encrypted>"
}

• data: Server response encrypted with the REQ key.
• id: Identifier from REQ to match the response.
• status: Request execution status (0 – error, 1 – success).
• code: HTTP code for precise error identification, as defined in the platform API.

Results

Implementing this new communication mechanism has opened additional opportunities for us and our clients to develop custom solutions for specific needs. For example, we use this API within the platform to manage MyBox electric vehicle charging stations, where it facilitates user authorization via RFID tags to initiate charging sessions. The MQTT API also enables a convenient mechanism for installers to create these authorization tags.

Conclusion

The development and implementation of the MQTT API on the 2Smart platform have significantly enhanced our ability to manage and interact with IoT devices. By addressing the initial challenges and ensuring secure, efficient communication between devices and the platform, we have paved the way for more customized and scalable solutions. The use of MQTT not only streamlines the communication process but also enhances security through robust encryption and controlled access.

Our Business Platform now stands as a comprehensive solution for enterprises, offering advanced features for device management, secure data transmission, and seamless integration with existing systems. The success of our implementation with MyBox electric vehicle charging stations demonstrates the potential and versatility of our MQTT API. Moving forward, we are excited to explore new applications and continue delivering cutting-edge IoT solutions to our clients.

Frequently Asked Questions

Why did 2Smart choose MQTT over other protocols like HTTPS and TCP for the API?

We selected MQTT because it is already a mandatory protocol for communication between devices and the platform, offering reliable, low-latency messaging suited for IoT environments. Its lightweight nature and efficient use of bandwidth make it ideal for the requirements of our platform.

How does 2Smart ensure the security of data transmitted via the MQTT API?

We implement multiple security measures to protect data. Access control ensures that devices can only publish to and subscribe from their respective topics, preventing unauthorized interception. Additionally, all RES packets are encrypted, ensuring that even if a packet is intercepted, it cannot be deciphered without the proper key.

Is the MQTT API functionality available for all users of the 2Smart platform?

The MQTT API functionality is currently exclusive to the Business Platform, designed for managing enterprise device fleets. This is due to the specific manufacturing and firmware integration processes that generate and utilize encryption keys for secure communication.

What are the potential applications of the MQTT API on the 2Smart platform?

The MQTT API opens up numerous possibilities for custom IoT solutions. For instance, it is used in MyBox electric vehicle charging stations for user authorization via RFID tags. The API’s flexibility allows it to be adapted for various other applications, providing a robust framework for secure and efficient device management.