EMQX Documentation
website·Indexed 37 days ago
https://docs.emqx.com/enA high-performance, distributed MQTT messaging platform for large-scale device connectivity and real-time message transmission. Features include MQTT over QUIC, multi-protocol gateways, distributed clustering, and a Rule Engine for data integration. Supports multiple deployment models including Serverless, Dedicated, and Enterprise, with comprehensive guides for installation on Docker, Kubernetes (via EMQX Operator), Debian, Ubuntu, CentOS/RHEL, and macOS.
What's inside EMQX
- EMQX Cloud integrates with HStreamDB to allow MQTT messages and client events to be saved into HStreamDB streams. This enables large-scale IoT data collection and real-time processing using standard SQL and materialized views. The data flow follows this path: IoT devices publish MQTT messages $\rightarrow$ EMQX Cloud Rule Engine (filtering, transformation, enrichment) $\rightarrow$ HStreamDB Sink $\rightarrow$ HStreamDB Stream.
Overview of EMQX and GCP Pub/Sub integration
EMQX integrates with Google Cloud Pub/Sub to enable real-time extraction and processing of MQTT data. The integration uses the EMQX rule engine to match MQTT messages based on topics, process them (filtering, converting, or enriching), and forward them to GCP Pub/Sub topics. Once in Pub/Sub, data can be consumed by Google Cloud services such as Cloud Functions, App Engine, Cloud Run, Kubernetes Engine, Compute Engine, Dataflow, BigQuery, Cloud Storage, and Firestore.Overview of Two-Factor Authentication (2FA) in EMQX Cloud
Two-Factor Authentication (2FA) provides an additional security layer for EMQX Cloud member accounts, requiring a verification code from an authenticator app or email in addition to standard credentials.
Key Constraints:
- Member accounts must be in an active state to configure 2FA.
- Accounts with Single Sign-On (SSO) enabled cannot use 2FA.
- Users who have already configured 2FA cannot set it up again without first having it removed.
- Only the root user has the authority to delete 2FA for any account; member accounts (including those with administrator privileges) cannot delete or reset their own 2FA.
Overview of EMQX Tables connector for Agents
The EMQX Tables connector allows an EMQX Agent to query and write time-series data using SQL. This is typically used to analyze telemetry history, enrich agent decisions with stored data, or write calculated results (like anomaly scores) back to EMQX Tables.Overview of EMQX to Snowflake data integration
EMQX integrates with Snowflake to forward IoT device events and telemetry data for long-term archiving and analytics. The workflow involves:
- Devices connecting to EMQX via MQTT.
- EMQX receiving messages on specific topics.
- The EMQX rule engine processing, transforming, or filtering the data.
- A Snowflake Sink writing the data to Snowflake tables using either Aggregated or Streaming modes.
Overview of JWT Authentication in EMQX
JWT (JSON Web Token) authentication in EMQX is a token-based mechanism where the server does not need to retain session information. Clients provide a JWT in either the username or password field during the MQTT connection process. EMQX verifies the token's signature using a configured key or certificate and validates claims such as
iat(Issued At),nbf(Not Before), andexp(Expiration Time).Note: JWT authentication is not supported in EMQX Serverless deployments.
Overview of EMQX Neuron Master-Backup Mode
EMQX Neuron supports a Master-Backup high-availability mode using Keepalived for failure detection and failover. In this setup, two servers are deployed: one primary (Master) and one backup. Only one node collects data at a time to avoid duplicate collection. If the primary node or its EMQX Neuron service fails, the backup node automatically takes over. When the primary recovers, the role switches back. Note that a short window of data loss and duplication may occur during switchover.Overview of EMQX OCPP Gateway
The EMQX OCPP gateway provides a protocol translation layer between OCPP 1.6-J (Open Charge Point Protocol) and MQTT. It enables charging station equipment to communicate with central management systems by bridging the gap between the two protocols, integrating with systems via rule engines, data integration, and REST APIs.Overview of EMQX Neuron Industrial Edge Gateway
EMQX Neuron is a lightweight industrial edge gateway software that integrates protocol conversion, data processing, and MQTT publishing. It is designed to solve the problem of protocol fragmentation (e.g., Modbus, OPC UA, Siemens S7, Ethernet/IP) and inconsistent data formats in factory environments. Key capabilities include support for 70+ industrial protocols, zero-code visual configuration, SQL-based stream processing, and AI algorithm integration (Python, ONNX).Overview of EMQX Cloud to PostgreSQL data integration
EMQX Cloud provides a built-in rule engine to bridge MQTT-based IoT data and PostgreSQL. The integration allows IoT devices to publish telemetry or status data to topics, which EMQX then processes (filtering, transforming, or enriching) and writes to PostgreSQL using SQL templates. This setup is also applicable to MatrixDB. Key benefits include flexible event handling for device lifecycles, GIS technology integration for location tracking, and runtime metrics for monitoring rule success/failure rates.Overview of EMQX Broker Connector for Agents
The EMQX Broker connector allows an AI agent to interact with an MQTT broker. It enables the agent to receive MQTT messages as event triggers (via subscriptions) and send MQTT messages as actions (via publishing). Common use cases include telemetry processing, anomaly detection, alert routing, and device command workflows.Overview of HTTP Service Data Integration in EMQX Cloud
The HTTP Service Data Integration allows EMQX Cloud to forward device events and MQTT messages to external HTTP services in real-time. This enables scenarios such as IoT device state notifications, alert systems, and data storage in external databases. The workflow involves: 1. Device connection/publication, 2. Rule engine processing (filtering, converting, or enriching data), and 3. Forwarding the processed data to a configured HTTP service via request headers, bodies, or dynamic URLs.