Using wireless communication technologies and protocols in embedded systems is not a trivial undertaking, since it frequently requires an exhaustive understanding of protocols and APIs. The goal of this work is to address the issue by providing a unified interface (API) for developers to utilise various communication protocols in a black-box manner. This interface is provided by Hermes, the library we developed. Hermes uses the object-oriented programming paradigm and it is written entirely in C++ using the Arduino libraries. The library supports ESP-NOW for short-range wireless communications, as well as WiFi Mesh and LoRa Mesh for mesh network construction, with the first one supporting point-topoint communications over small distances and the second one supporting long-range communications. Although this library is useful in any context, it has been specifically designed to enable distributed communication between the agents of Democle, a declarative multi-agent platform for agent-based edge computing, which we will briefly describe. This paper presents an overview of Hermes, including its architecture, capabilities, and utility inside the Democle platform.
The Internet of Things (IoT) has transformed the digital world, introducing novel concepts and technologies into our daily lives. Such innovations have become an integral part of our everyday lives, both at home and at work, and have contributed to the improvement of the quality of life for many people. One of the most fascinating aspects of such technologies is network communication since these devices are primarily used to gather data using suitable sensors or to give services through novel modes of engagement. Given the nature of the applications, research in the field focuses on reducing energy consumption for transmissions, as well as developing self-managed networks and attaining long-range communication.
In light of these considerations, several network technologies and protocols have been developed to address these issues to the specific requirements of the intended usage scenario. Unfortunately, developers are often required to possess a comprehensive understanding of such protocols to utilise them efectively. Furthermore, if it is determined through empirical testing that the technology is unsuitable for a particular purpose, it is necessary to rewrite the code.
In this paper, we put forth the concept of a library, called Hermes, which is designed to provide a unified application programming interface (API), thereby resolving the problem in question. The protocols supported by Hermes include ESP NOW, WiFi Mesh and LoRa Mesh, which collectively permit the library to address the majority of potential usage scenarios. Later, in Section 4, we will give a summary of the features of these protocols and their operational context.
Another outcome that we will briefly discuss is the integration of Hermes into software
agents and multi-agent systems (MAS) to develop autonomous distributed systems. In particular,
we integrated our library within the Democle [
In [
The authors of [
In [
A similar approach is proposed in [
Democle is a C++ multi-agent framework that allows a developer to write multi-agent systems using a declarative approach. Democle is based on the BDI paradigm and lets developer to write agent’s behaviour by means of plans triggered by events and subject to a condition based on the agent’s knowledge. An agent in Democle is an instance of a subclass of the basic Agent class whose run() method is overridden to implement the specific agent’s behaviour. Moreover, the agent has a knowledge-based (KB) which stores agent’s knowledge in terms of beliefs, which are defined using atomic formulas with zero or more ground terms. Plans in Democle are expressed using a specific syntax and are made of the following parts: • triggering event: it is the assertion or retraction of a belief with a given pattern, or a definition of a procedure that can be explicitly called; • condition: it is a predicate checking the presence in the KB of one or more beliefs with given parameters; here variable unification is also possible; • action: it is the code that is executed when the triggering event occurs and the condition is met.
Figure 1 reports the code of an agent running on an embedded device that samples data from an analog to digital converter and applies a low-pass filter according to a parameter (i.e. alpha); data is then processed by another piece of code (not shown in the example).
The main reason tied to the development of Democle is that, since it uses C++, it can run not only standard PCs but also in boards equippend with MCUs (in particular it has been tested in ESP32 and STM32 environments), making it perfect for IoT agent-based application; its memory footprint is small and, when it runs in an MCUs, additional features are enabled such as the interface with the peripherals (GPIO, timers, etc.) thus making it possible to trigger plans following the occurrence of events in a specific peripheral.
The only feature missing in the original design of Democle is the possibility of exchanging messages among agents running in diferent devices, a feature that is now added by Hermes that is described in the paper.
For a comprehensive description of the features and the architecture of Democle, we refer
the reader to the original paper[
Hermes is a library for embedded systems whose purpose is to provide a single interface for
network communication supporting diferent transmission protocols. The main objective of our
project is to provide a straightforward interface for wireless network protocols, allowing the
developers to utilise them in a black-box mode. Hermes supports ESP NOW[
Furthermore, to facilitate the communication between the nodes in the network, we have included a name management service in Hermes. During the initialization phase, a name is associated with each node of the network. As we discuss later in this paper, this service simply allows each node to send data to another node without knowing its network address.
In the following subsection, we will first describe the software architecture of Hermes and then its integration with the Democle platform.
The Hermes library is written in an object-oriented way using the C++ language[11] and the Arduino libraries1. The design of Hermes is made by a few classes which, in fact, represent its object-based architecture, which is shown in Figure 2.
The main class of the project is called Hermes. This class models a generic network protocol and, for this reason, it is implemented as an abstract class. This class defines the attributes and methods to be implemented by the subclasses. Each instance of Hermes has a name, which represents the name of the running node, a NameService, which is used to store and retrieve the network addresses associated with a node name, and a MessageQueue, which is used to store the messages that cannot be sent at that time. Finally, there is a hermes_recv_cb_t within the class that allows us to define the desired behaviour of our device in response to a received message.
Each subclass of Hermes represents the implementation of a specific network protocol. At present, as shown in Figure 2, we have implemented three subclasses: HermesEspNow, HermesWiFiMesh and HermesLora, which are the supported protocols by Hermes. In the following paragraphs, we explain the main features of the protocols and other details on Hermes architecture.
ESP NOW It is a connectionless wireless communication protocol designed by Espressif[
WiFi Mesh [
LoRa Mesh [9, 10] It is a widely used technology for low-power and long-range communications. LoRa’s communication range can be up to 5 km in urban areas and 15 km in rural areas. In our work, we used this technology to allow mesh network realization through the usage of the LoRa Mesher library [9] which, in turn, makes use of the well-known RadioLib library [13]
to interact with the LoRa radio chip. The list of supported radio modules is available on github2. This library uses a proactive distance-vector routing protocol as proposed in [14]. Message It is the class that represents messages in Hermes. The attributes of the class are the following: • type: the type of message which is set to DEFAULT_MESSAGE in the case of ordinary messages, WHO_IS_REQUEST for node name resolution requests; • buffer: a bufer of bytes containing the message data; • size: the bufer size in bytes.
In addition, there is a simple data serialisation function, which is necessary for sending and receiving methods.
MessageQueue This class is used to store messages that cannot be sent at a particular time because the NameService does not know the address of the receiving node. These messages are placed in a queue associated with the recipient’s name and are processed by the NameServer when it receives the address associated with that node.
NameService It is the class which manages node names in the Hermes network, regardless of the chosen protocol. This class has a name-address map, which records the known address by the node. This map is updated whenever we send a message to an unknown node. In particular, when we execute the send function to an unknown node (i.e., not existing in the map), Hermes broadcasts a WHOIS_REQUEST_MESSAGE containing the node’s name and waits asynchronously, with an ad hoc task, to receive a WHOIS_REPLY_MESSAGE from the target node. This message is sent in response to the WHOIS_REQUEST_MESSAGE directly from the node with that name. Furthermore, once the node address has been saved, the NameService takes care of sending the messages in the message queue for that node, emptying it as it goes.
Obviously, this approach works in a legitimate context, i.e. one that has no malicious nodes. Without this assumption, we would have to consider the usage of some authentication mechanism.
Tests Hermes has been tested on several devices including ESP32-S3, ESP32-C6 and TTGOLoRa32-V2.1 (with a SX1276 LoRa module) using the PlatformIO tool.
As mentioned in Section 1, Hermes has been implemented as a stand-alone library, but this was primarily designed to provide a communication module for the Democle platform introduced in Section 3. In the same section, we discussed how the platform implements the agent communication feature and stated that communication is constrained to the agents present on the running device. We solved this limitation by integrating Hermes into Democle and, as a
- name: String - name_service: NameService - message_queue: MessageQueue - recv_cb: hermes_recv_cb_t + init(): bool + start(): bool + stop(): bool + send(): bool + send_to_addr(): bool + broadcast_send(): bool
HermesEspNow - instance: HermesEspNow - channel: uint8_t
HermesWiFiMesh - instance: HermesWiFiMesh - mesh_cfg: mesh_cfg_t
HermesLora - instance: HermesLora NameService
Message
MessageQueue + address_table: std::map
+ type: MessageType + add(): void + exists(): bool + get(): [uint8_t] + remove(): void result, expanded the platform’s usage scenarios. We can imagine a large number of nodes with multiple running agents cooperating over short or long distances to achieve a shared goal.
To accomplish this, we had to slightly modify the Democle syntax for sending messages. Specifically, it is now required to indicate the protocol to be utilized, the name of the node on which the agent is running and the agent’s name in the destination variable using the following conventions: • local@agent_name when the destination agent is running on the same node; • espnow:node_name@agent_name to send a message to an agent running on another node, using EspNow; • wifimesh:node_name@agent_name to send a message to an agent running on another node, using WiFi Mesh; • loramesh:node_name@agent_name to send a message to an agent running on another node, using LoRa Mesh.
It is important to note that Hermes must be properly initialized before being used on the Democle platform by calling the init function for the chosen communication protocol.
This work has introduced Hermes, a C++ library which allows developers to send and receive messages using diferent wireless network protocols through a single library interface.
The project is currently still under development and the introduction of some new features is planned, e.g. encryption, authentication and compression of the messages.
Hermes is an open-source project released under the GNU-GPLv3 licence and available on Github at https://github.com/Herbrant/Hermes/.
(i)This work is supported by the MIUR project "T-LADIES" under grant PRIN 2020TL3X8X. (ii) The contribution of Federico Fausto Santoro was supported by MUR under Mission 4, Component 2, Investment 1.4 under the project HPC. (iii) “PIACERI”, funded by the University of Catania; [9] J. M. Solé, R. P. Centelles, F. Freitag, R. Meseguer, Implementation of a lora mesh library,
IEEE Access 10 (2022) 113158–113171. doi:10.1109/ACCESS.2022.3217215. [10] S. Devalal, A. Karthikeyan, Lora technology-an overview, in: 2018 second international conference on electronics, communication and aerospace technology (ICECA), IEEE, 2018, pp. 284–290. [11] B. Stroustrup, The C++ programming language, Pearson Education, 2013. [12] espressif, esp-idf: Espressif IoT Development Framework. Oficial development framework for Espressif SoCs., https://github.com/espressif/esp-idf, 2016. [13] jgromes, RadioLib: Universal wireless communication library for embedded devices, https: //github.com/jgromes/RadioLib, 2018. [14] R. Pueyo Centelles, Towards LoRa mesh networks for the IoT, Ph.D. thesis, Universitat Politècnica de Catalunya, 2021.