The IoT technologies are evolving fast, but old ones still exist, therefore an IoT architecture must support both old and new ones . Some examples include traditional cellular connectivity technologies like EDGE (2G), HSPA (3G), LTE (4G) and Low Power Wide Area (LPWA) technologies for IoT . The LPWA are low-power and low-cost technologies that are capable of covering a wide area network . The most widely used LPWA are LoRa and Sigfox. Furthermore, multiple connectivity technologies exist for shorter area cover. Short-area connectivity technologies are implemented mostly for HEMS and Building Energy Management Systems (BEMSs) to cover areas up to 100 meters. The most widely used short-area technologies are Bluetooth and Wireless-Fidelity (Wi-Fi) . Moreover, nowadays other technologies like Thread, WirelessHART , Z-Wave, Mod-Bus and Zigbee are mostly used in HEMS and BEMS.
As a result, a low-cost IoT architecture supporting multiple connectivity technologies is of key importance. CERTH deployed a method for deploying a low-cost machine-to-machine (M2M) centric architecture that supports multiple protocols and interoperability.
The suggested Machine-to-Machine (M2M) system utilizes a modular and layered architecture to increase the system’s overall robustness. Each gateway utilizes its own MQTT broker . The broker is used by all the sub-modules’ services to redirect the BMS server. The use of a local broker for each gateway solves many networking problems that may arise. The gateway can be connected to the internet without the use of static IP while its IP is not stored or used by the system. Additionally, by using the MQTT protocol, different modules of the system can be coded in various programming languages as long as they are compatible with MQTT and post their data to the predefined topics. Each protocol’s software is linked to a Linux service which monitors its network state, manages the sensor
data streams, and publishes the data to the gateway’s MQTT broker under predefined and mapped topics.
The ”Mqtt2Bms” service subscribes to all the topics in the broker using the same predefined mappings, gathers all available data, and periodically posts them to the BMS server’s API. This type of architecture allows the future addition of more protocols to the system without obstructing the existing modules’ functionality.