Implementing a Custom Method of Communication of IoT Devices with a Mobile Application Using BLE

Table of contents:

While not the only method, a common approach in the IoT industry for the interaction between a mobile application and devices involves their connection through the cloud. This is precisely how it works in 2Smart Cloud, where there is no direct connection between the application and the IoT device; both act as clients of a cloud MQTT broker. This setup is optimal for numerous user scenarios, as the cloud enables device management from anywhere with internet access without being tied to a specific location. However, in some cases, there is a need to utilize other technologies for a quick direct connection between the mobile application and the device.

In this article, the 2Smart team shares their experience in solving a business challenge for their client by implementing custom functionality for device-to-application communication via Bluetooth. We will delve into detail about a special feature of the MyBox mobile application, developed for their 2Smart platform instance, to address a specific task related to organizing the electric vehicle charging process.

Unusual Application Use Case and a Task Set by the Customer

One of 2Smart’s key clients is a Czech manufacturer of electric vehicle charging stations operating under the MyBox brand. This client utilizes a white-label instance of the 2Smart platform, which includes a web platform for device developers (a branded counterpart to the publicly available 2Smart Cloud platform), a business platform, and a branded mobile application.

The task of implementing a new method of communication between the MyBox mobile application and devices was set by the client during the modernization of the owner authorization process before starting the charging session for electric vehicles.

Before the modernization, most public MyBox charging stations operated in the following manner: each station was equipped with an RFID reader, and users were required to purchase an RFID card in advance for its use. The user would then tap the card on the reader before starting the charging process, thereby completing their identification. Subsequently, it was easy to determine who used the charging station and the amount of energy received, enabling the generation of invoices for payment.

Such a user authentication method was not ideal. Firstly, charging station customers had to carry an additional item in the form of an RFID card, which could be forgotten at home or misplaced. Secondly, different charging stations might require individual cards, necessitating users to carry multiple cards simultaneously.

MyBox aimed to improve the user authentication process and eliminate the need for physical cards by introducing “virtual cards” (tags) in the mobile application. Together with the client, we had to devise a way to implement and utilize them to enhance the user experience for MyBox customers.

Key Challenge and Chosen Solution

The key challenge for us was to implement a new usage principle for our mobile application. While the 2Smart Cloud platform allows users to manage and view data from their owned devices, the usage scenario described by the client indicated a different business scenario:

• Suppose a café, as the entity, has its own parking lot and purchases a charging station so that visitors can charge their electric vehicles while at the establishment.
• This charging station will be owned by the café (the account manager or administrator) rather than the café visitor who downloads the application. Consequently, the user will not be able to see the charging station in the application because they are not the owner, but they still need to charge their electric vehicle somehow.
• The user must contact the café administrator to request the creation of a tag for authorizing the charging session.
• Upon receiving the tag, the client connects their vehicle to the charging station and should be able to find the relevant charging station in the application, authenticate, and start charging.

From the last point, it becomes clear that the mobile application needed to incorporate the following functionality:

1. Search for nearby devices.
2. Authorization on the selected device.

After discussing various implementation options, we, along with the client, decided that Bluetooth Low Energy (BLE) was the optimal technology. It’s perfect for implementing the device search functionality, and it can also successfully handle authorization (although there are many possible options in this case). Importantly, MyBox charging stations are based on ESP32 microcontrollers, which support BLE technology, so no hardware architecture changes were necessary.

To implement this functionality, we needed to prepare the appropriate updates for the platform, mobile application, and charging station firmware. Within the platform, we created a tool for managing “virtual cards” (tags), accessible to platform administrators. Within the mobile application, we provided end-users with the ability to select the appropriate tag for authorization before starting the charging process and an API for authorizing the selected tag with the charging station. As for the firmware, we developed an API that uses BLE technology. It accepts the tag, validates it, and initiates the charging process or notifies the client of any errors.

Implementation of the Solution

To facilitate device discovery and data exchange, we utilized the following profiles as part of the BLE technology:

1. GAP (Generic Access Profile) is used for device discovery and connection in BLE devices.
2. GATT (Generic Attribute Profile) facilitates data exchange between BLE devices.

These profiles collectively cover the tasks of device discovery and authorization.

On the firmware side, we implemented GAP, operating in advertisement mode, to enable devices to be discovered through the mobile application, which operates in scan mode. At the advertisement level, the charging station broadcasts specific metadata necessary for display in the mobile application and allows filtering of other nearby BLE devices (on the mobile application side).

Once the desired device is discovered, GATT comes into play. The charging station acts as a GATT server, while the mobile application acts as a GATT client.

The Generic Attribute Profile (GATT) is a Bluetooth profile that governs how data is transmitted between Bluetooth devices. It is based on attributes and collections of attributes organized into services and characteristics. Below is the expanded structure of GATT:

1. Services:
   • Services are identified by a unique 128-bit Universally Unique Identifier (UUID).
   • Each service can contain one or more characteristics.
   • A device can contain multiple services.
2. Characteristics:
   • Characteristics define specific data or functions that a device can provide.
   • Characteristics are also identified by 128-bit UUIDs.
   • Each characteristic has several attributes, such as descriptors and access permissions.
3. Descriptors:
   • Descriptors provide additional information about characteristics.
   • They are also identified by UUIDs.
   • Descriptors can contain metadata, such as characteristic descriptions or access rules.
4. Notifications and Indications:
   • GATT allows devices to subscribe to notifications about changes in characteristic values, enabling asynchronous data exchange between devices.

The GATT server on the charging station is quite simple and consists of one service and two characteristics:

• Read/Write (R/W) characteristic for the tag (where the mobile application sends the tag for authorization).
• Read-only (R) characteristic for reading the authorization result.

The authorization process is implemented through two characteristics for a specific reason. The charging station can use several different methods for tag verification, including APIs. Therefore, upon receiving the tag, the charging station cannot immediately respond to the GATT client about the success or failure of the authorization. Due to the asynchronous verification process, we designed the authorization process using two characteristics. The characteristic for the authorization result not only allows read-only access but also sends notifications to connected clients about changes in its state. This means that the GATT client does not need to constantly poll this characteristic but will receive an event after the charging station obtains the verification result.

Here’s how these two characteristics are described in the firmware (arrows indicate permissions and the fact that the second characteristic has NOTIFY):

Here’s how it looks in the mobile application. The end user of the charging station sees the device on the dashboard with the status “Plugged”. By tapping on it, they are taken to a list of available BLE tags for authorization. Afterward, a search for the device is initiated, resulting in the discovery of one charging station. The user simply needs to press the “Authorize” button to authenticate. Towards the end of the video, we see that the device on the dashboard changes its status to “Charging”.

BLE in IoT

Above, we described a specific use case of BLE technology, illustrating communication between a smartphone and the MyBox mobile application, as well as electric vehicle charging stations. However, due to its advantages, BLE is widely used in IoT across various industries.

Here are the key reasons for the prevalence of Bluetooth Low Energy in IoT:

1. Low Power Consumption: One of the primary advantages of BLE is its low energy consumption. This allows IoT devices to operate on batteries or other power sources for extended periods without the need for frequent replacement or recharging.
2. Small Data Payloads: BLE is designed for transmitting small amounts of data, which is well-suited for most IoT applications where typically only small packets of information are transmitted.
3. Wide Support: BLE is a standard supported by many modern devices, including smartphones, tablets, computers, and other devices, making it ideal for facilitating interaction between IoT devices and users.
4. Ease of Connection: BLE enables easy establishment of wireless connections between devices without the complexities associated with traditional protocols like Wi-Fi or Bluetooth Classic.
5. Flexibility: BLE supports various modes of operation, including slave and master modes, allowing for diverse scenarios of interaction between IoT devices.

Here are possible areas of application for this technology:

1. Sports and Fitness Devices: BLE is used to connect smartphones with fitness trackers, health sensors, sports watches, etc., to measure physical activity, heart rate, and other biometric data.
2. Medical Devices: In the medical field, BLE is used to establish connections between medical devices such as health monitors, electrocardiographs, insulin pumps, and mobile devices for collecting, tracking, and analyzing patient data.
3. Smart Devices: BLE is widely used in smart watches, glasses, headphones, bracelets, etc., to provide wireless connectivity with smartphones and other devices.
4. Location and Navigation: BLE can be used to create indoor positioning and navigation systems in areas where GPS signals may be unavailable, such as shopping malls, airports, museums, etc.

Conclusion

The integration of IoT devices with a mobile application using BLE technology exemplifies the custom functionality we implemented individually for the client within the white-label instance of the 2Smart IoT platform. The client identified the challenge they faced with authorizing end-users at charging stations using RFID cards and proposed a solution in the form of virtual cards. Together with the client, we found the optimal way to implement the idea, which did not require changes to the hardware architecture but effectively became a new software feature. Devices already serving users received this feature after a firmware update over the air, and end-users gained access to the new functionality after updating the mobile application. Charging station administrators received the necessary tools in the web application without any additional actions on their part.

This case serves as an example of how we at 2Smart prioritize customer care for those who have deployed a white-label instance of our platform. Recognizing that it’s practically impossible to foresee the exact functionality customers may require in advance, we adhere to an approach of being open to customer requests.

If you are interested in the capabilities offered by the platform for developers, the business platform, and the 2Smart Cloud mobile application, you can schedule a meeting with our experts. Perhaps the functionality your business needs is already available out of the box. If not, we are open to discussing solutions for your custom tasks, regardless of the specificity of the devices and their application areas.