Local Control of IoT Devices Without Cloud Using the 2Smart Mobile App

Table of contents:

The architecture of the 2Smart Cloud platform implies that IoT devices are connected to the internet, and their management occurs through the cloud. These devices can be connected via Wi-Fi, Ethernet, or GSM, directly linked to the cloud, or operate through a gateway. However, users, service providers, and corporate clients often encounter situations where cloud-based management is temporarily impossible or an alternative means of communication between the device and the interacting human is required. One solution for such situations is the use of Bluetooth protocol. In this publication, we want to share our experience in solving another task of local control and configuration of devices, using the example of our client MyBox, a manufacturer of charging stations for electric vehicles.

Why the Need for Finding a Way for Local Control of Electric Vehicle Charging Stations Arose

The primary reason for the need for this task is the scenario involving the installation of charging stations in locations with unstable/poor or completely absent internet connectivity. The necessity for local control can be relevant for end-users, installers, or service providers. Here are typical examples:

1. Standalone charging mode. A charging station may be installed in the backyard of a private residence, where the Wi-Fi network partially reaches or is completely absent, as well as Ethernet. Charging rarely needs reconfiguration, and it just performs its task – charging the electric vehicle. However, there might be occasions when the user needs to adjust charging settings (reduce the maximum current available for the charging station, edit the list of RFID tags for authorization (e.g., for guests/neighbors), connect an additional controller for solar panels, etc.).
2. The installer arrives at the client’s location and, to avoid requesting access to the client’s network or account wants to have access to the charging station configurations.

The functionality of local control addresses both of the issues described above.

Solution Approach

To address the task at hand, we conducted research into suitable technologies and concluded that the optimal solution is to utilize the mDNS (Multicast DNS) protocol. This service enables the fulfillment of two necessary tasks:

1. Device search within the network.
2. Resolving the local IP of the device for further communication.

The principle of mDNS operation involves devices sending requests to discover other devices on the local network via multicast messages. When a device in the network wants to find another device, it broadcasts the request to all devices in the network using a special IP address known as the multicast address.

Every device on the network that supports the mDNS protocol listens to these multicast messages. If it responds to the request (for example, it matches the hostname or has the required service), it sends a response to all devices that sent the request. This allows devices to find each other and interact without a centralized DNS server.

The mDNS protocol is commonly used in home networks for automatic device discovery, such as printers, media players, smartphones, computers, etc., and for accessing them using names or hostnames instead of IP addresses.

mDNS Protocol: Pros and Cons

Pros of mDNS:

1. Easy Setup: mDNS allows devices on the network to automatically discover each other without the need for manual configuration of DNS servers or settings.
2. Autonomy: With mDNS, devices can communicate with each other without relying on a centralized server or external administrator.
3. Wide Applicability: mDNS is used in various scenarios such as automatic detection of printers, file servers, media players, and other network devices.

Cons of mDNS:

1. Increased Network Traffic: In networks with a large number of devices, mDNS can generate additional network traffic due to the constant transmission of multicast messages.
2. Potential Security Issues: While mDNS can be useful for automatic device detection, it can also pose potential security risks, such as the possibility of devices being discovered by malicious actors.
3. Network Visibility: Using mDNS can reveal device names and services on the network, which may raise privacy concerns.

Communication Options for Devices Using mDNS

The diagram below illustrates how mDNS works:

Here, we see two devices connected to the network. The first one is connected via WiFi, and the second one is connected via Ethernet. The user sends an mDNS Query to find all available devices on the network, and the WiFi Router responds with an mDNS Response containing information about the two devices. The address of the first device is device1.local, and the address of the second one is device2.local. The user sends requests to each of these devices using the obtained addresses, and the router resolves these addresses into IPv4 and forwards the requests to the devices.

The next diagram shows how interaction between devices occurs when one of them opens a WiFi access point and the other one connects to it:

Except for the absence of the router in the scheme, everything else is similar to the example in the first diagram. The device sends an mDNS Query to retrieve available devices (mDNS Response), and then communication occurs with the device using its local address (device1.local).

Within the MyBox project, charging stations utilize both of the described scenarios depending on the usage scenario of local management for these devices.

FAQ

• What if the user and the charging station are connected to different networks?

For such cases, the charging station implements a special mode called service mode, which is when the charging station creates its own Wi-Fi network, allowing users to connect directly to it regardless of their existing network connection. This ensures that users can still access and interact with the charging station even when they are not connected to the same network. Once connected to the charging station’s Wi-Fi network, users can utilize mDNS to discover and communicate with the charging station seamlessly, enabling them to perform tasks such as configuration, monitoring, and control as needed. This approach enhances the flexibility and accessibility of the charging station, ensuring uninterrupted operation and user convenience in various network environments.

• If mDNS is a general technology that can be used by any device, how do we know that it’s specifically a charging station?

Within the mDNS protocol, TXT records are used. These records allow any textual information to be included, which can be useful for the identification or configuration of the device or service. For example, they can contain information about the manufacturer, software version, service description, configuration parameters, etc.

By configuring the charging stations to include specific TXT records containing identifying information such as the manufacturer’s name (MyBox), model name, or any other relevant details, devices searching for charging stations can use these records to filter and identify MyBox charging stations specifically. This ensures that only the desired devices are discovered and communicated with, enhancing the efficiency and accuracy of device discovery within the network.

• However, mDNS is only a tool for device discovery, not for communication with them. How does communication with the charging station work?

The charging station has its own web admin interface, where users can monitor and modify available device settings.

Within the project, we refer to this page as “JTree” because the configuration page has a tree-like structure of data, where all device configurations are divided into groups (nodes), have their own data type (boolean, string, number, float, enum), have R or R/W permissions (read-only or read-and-write), and some current values.

Communication with the device occurs through a WebSocket server running on the charging station, and the data structure itself is self-declarative and has a JSON structure.

Local control also operates through JTree. Here’s an example of how it looks in the mobile application:

• Why use local control through the mobile application when you can do the same through the browser in the web admin interface?

Firstly, the mobile version of the admin interface is not very well optimized for use on smartphones, while in most cases, the need for local control arises specifically via smartphones.

Secondly, the mobile application offers additional features. For example, it stores information about devices that were previously discovered and displays their current status (online or offline).

Thirdly, it was relatively easy to “reuse” the functionality since the backend part (JTree API) was already implemented for the web admin interface in the firmware. All we had to do was add this functionality to the mobile application.

• What sets apart managing a device via a mobile application locally versus through the cloud?

The cloud platform features a fixed layout for each device, primarily designed for a simplified user experience. The device management interface in the mobile application is greatly simplified and not overloaded with specific configurations. Instead, local control is tailored specifically for advanced device configuration.

• What are some other examples of using mDNS?

Within the MyBox project, the mDNS protocol is utilized for a range of other needs:

1. Device pairing
2. Internal communication between devices

MyBox solution is a comprehensive product where the charging station may consist of multiple components. It could be a charging station with a solar panel controller or charging stations with a DLM system for dynamic current distribution between them. In both cases, setting up communication between two or more independent devices is necessary, and the most convenient option for us was mDNS because this protocol covers all the needs of device pairing:

1. Discovery process. For example, if we want to connect a charging station to the DLM system, mDNS can discover all MyBox devices and locate the DLM based on its description in the TXT record.
2. Pairing process. Once we have the local address of the device, we can configure communication between them.
3. No need to change configuration when switching networks. This is a huge advantage when network changes are required, or, for example, when devices need to be transported from one exhibition to another and reconfigured. Because the devices have static local addresses, regardless of the network they are connected to, we don’t need to worry that at some point, the device’s IP address will change, and the devices will stop communicating with each other.

• How is connection security ensured?

Indeed, due to mDNS’s openness, malicious actors can easily find devices within a network, so any API should be additionally protected from external interference.

That’s why, within JTREE and device pairing, an additional authentication mechanism is implemented, conducted by the devices before continuing communication.

Wrapping Up

In conclusion, the integration of local control and mDNS technology marks a significant advancement in IoT device management, particularly in scenarios where internet connectivity is limited or unreliable. MyBox, with the expertise and support of 2Smart, exemplifies the seamless integration of these innovations, offering users unparalleled flexibility and efficiency in controlling and configuring their IoT devices.

By leveraging local control, users can now manage their IoT devices with ease, regardless of internet availability, ensuring uninterrupted operation and enhanced security. With 2Smart’s dedication to innovation and MyBox’s commitment to quality, the future of IoT device management is brighter than ever.

Join us in embracing this new era of connectivity and control. Explore the possibilities of local control with MyBox EV Chargers and discover the limitless potential of IoT technology. Together, let’s shape a smarter, more connected world.

For further inquiries or to discuss any IoT implementation case, don’t hesitate to reach out to us at contact@2smart.com. We’re here to help you navigate the world of IoT solutions and drive your business forward.