Follow the IoT Planet to track the dynamics of the Internet of Things! “IoT Planet” aligns with global industry trends, focusing on the integration of IoT and industry, and sharing technologies and applications related to IoT.
Mainflux is a modern, scalable, and secure open-source IoT platform written in Go. It connects devices through various network protocols (such as HTTP, MQTT, WebSocket, CoAP, etc.) and establishes a seamless bridge between them, serving as middleware for building complex IoT solutions.
-
Protocol Bridging (i.e., HTTP, MQTT, WebSocket, CoAP)
-
Device Management and Configuration
-
Fine-Grained Access Control
-
Platform Logging and Instrumentation Support
-
Container-Based Deployment Using Docker
-
Data Ingestion, Processing, and Storage.
-
Scalable and Distributed Design
-
-
Scalability and Customization Support

The Mainflux IoT platform consists of the following services:
Service |
Description |
User
|
Manages users of the platform and authentication issues related to users and groups |
Thing |
Manages things, channels, and authentication issues related to things and channels |
HTTP Adapter |
Provides an HTTP interface for sending messages via HTTP |
MQTT Adapter |
Provides MQTT and MQTT over WS interfaces for sending and receiving messages via MQTT |
WS Adapter |
Provides a WebSocket interface for sending and receiving messages via WS |
CoAP Adapter |
Provides a CoAP interface for sending and receiving messages via CoAP |
OPC-UA Adapter |
Provides an OPC-UA interface for sending and receiving messages via OPC-UA |
LoRa Adapter |
Provides a LoRa server forwarder for sending and receiving messages via LoRa |
Mainflux-CLI |
Command Line Interface |
The platform is built around two main entities: User and Thing.
A User represents a real (human) user of the system. Users are represented by their email address as identity and password as secret, which they use as access credentials to obtain access tokens. Once logged into the system, users can manage their resources (i.e., groups, things, and channels) in a CRUD manner and define access control policies by connecting them.
A Group represents a logical grouping of users. It simplifies access control management by allowing users to be grouped. When users are assigned to a group, we create a policy that defines what actions that user can perform on the resources of that group. Thus, a user can be assigned to multiple groups, and each group can have multiple users. Users in a group can access other users in the same group as long as they have the required policy. A group can also be assigned to another group, creating a group hierarchy. When users are assigned to a group, we create a policy that defines what actions that user can perform on that group and other users within the group.
A Thing represents a device (or application) connected to Mainflux that exchanges messages with other “things” using the platform.
A Channel represents a communication channel. It serves as a message topic that can be used by all things connected to it. It also acts as a grouping mechanism for things. A thing can connect to multiple channels, and a channel can connect multiple things. Users can also connect to channels, allowing them to access messages published to that channel and things that connect to that channel with the required policies. A channel can also be assigned to another channel, creating a channel hierarchy. Both things and users can be assigned to channels. When a thing is assigned to a channel, we create a policy that defines what actions that thing can perform on the channel, such as reading or writing messages to it. When users are assigned to a channel,
Due to the lightweight and high-performance characteristics of NATS, Mainflux uses NATS as its default messaging backbone. You can think of its topics as physical representations of Mainflux channels, where the topic names are constructed using channel unique identifiers. Mainflux also offers the ability to change the default message broker to RabbitMQ, VerneMQ, or Kafka.
Generally, there are no restrictions on the content exchanged through channels. However, for post-processing and standardization, messages should be formatted using the SenML format.
The Mainflux platform can also run at the edge. Deploying Mainflux on gateways enables it to collect, store, and analyze data, organizing and validating devices. To connect a Mainflux instance running on a gateway to Mainflux in the cloud, we can use two gateway services developed for this purpose:
Running Mainflux on a gateway shifts computation from the cloud to the edge, decentralizing the IoT system. Since we can deploy the same Mainflux code on both the gateway and the cloud, there are many benefits, but the biggest advantage is ease of deployment and adoption – once engineers learn how to deploy and maintain the platform, they will be able to apply those same skills to any part of the edge-fog-cloud continuum. This is because the platform’s design is consistent, allowing engineers to move easily between them. This consistency saves engineers time and effort and also helps improve the platform’s reliability and security. The same toolset can be used, and the same patches and bug fixes can be applied. The entire system is easier to reason about, maintenance is easier, and costs are lower.
The Mainflux IoT platform provides services that support edge device management. Typically, IoT solutions include devices (sensors/actuators) deployed remotely and connected through some proxy gateways. While most devices can connect directly to Mainflux, using gateways can decentralize the system, reduce the load on the cloud, and make setup less complicated. Additionally, gateways can provide extra data processing, filtering, and storage.
This diagram shows the minimal deployment of edge gateways running Agent, Export, and Mainflux services. The Mainflux services support device management and the MQTT protocol, with NATS as the central message bus, as it is the default message broker in Mainflux, also becoming the central message bus for other services and any new custom Agent development Export services, which can be built to interface with devices that have any hardware support on the gateway, these services will publish data to the message broker, and Export services can retrieve data from the message broker and send it to the cloud.
Agents can be used to control deployed services and monitor their activity by subscribing to the heartbeat Message Broker topic, where services should publish their active status like Export services.
-
Platform: https://github.com/mainflux/mainflux
-
Management Interface: https://github.com/mainflux/ui
-
Documentation: https://docs.mainflux.io
Previous Recommendations
-
List of IoT Platforms at Home and Abroad (as of 2023, a must-see for IoT platform technology selection)
-
KubeEdge: A Cloud-Native Edge Computing Framework Built on Kubernetes
-
Open Source IoT Platform: ThingsBoard
-
Common IoT Protocols List (Collectible Edition, please bookmark)
AIoT Planet: Technical Communication · Add a Friend
IoT technical communication community is about to be formed
Every little view is the biggest support!