# Eclipse Paho MQTT C Client for Embedded Platforms > Eclipse Paho MQTT C client library provides packet serialization, a C++ client, and a C client for embedded platforms. It suits projects that need MQTT protocol handling with selectable network integrations, but application developers still own several integration choices. **eclipse-paho/paho.mqtt.embedded-c** — Paho MQTT C client library for embedded systems. Paho is an Eclipse IoT project (https://iot.eclipse.org/) - Repository: https://github.com/eclipse-paho/paho.mqtt.embedded-c - Website: https://eclipse.org/paho - Stars: 1,550 · Forks: 791 - Language: C - License: NOASSERTION - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/eclipse-paho-paho-mqtt-embedded-c ## What Eclipse Paho MQTT C Client Solves Eclipse Paho MQTT C client library targets embedded systems that need to communicate through MQTT while avoiding a large platform-specific networking abstraction. The repository is organized around three related pieces. MQTTPacket handles serialization and deserialization of MQTT packets. MQTTClient adds a higher-level C++ client with replaceable networking classes. MQTTClient-C provides a higher-level C client for platforms where C++ is unavailable or is not the project convention. The intended users are embedded and IoT developers who need MQTT protocol functionality but may already have a preferred network interface. The README specifically says that MQTTPacket is the lowest-level C library and has the smallest requirements. It also says that the developer is mainly responsible for reading from and writing to the network. That division makes the project suitable for custom transports, constrained systems, or existing platform networking code. The project does not present itself as a complete application framework. It provides MQTT packet and client layers, samples, documentation configuration, and build files. Broker selection, transport behavior, application callbacks, and much of the surrounding system integration remain outside the core library. ## MQTTPacket, MQTTClient, and MQTTClient-C Architecture The repository uses a layered design rather than one universal client interface. MQTTPacket is the foundation. Its routines serialize MQTT packets for transmission and deserialize packets received from a connection. The higher-level MQTTClient and MQTTClient-C packages build on that layer and provide a higher-level programming model. MQTTClient places networking code in separate classes so that the network implementation can be replaced. The README lists Linux, Arduino, and mbed implementations, and identifies ARM mbed as the first platform for which the C++ client was written. This separation is the main architectural decision for adopters with a nonstandard embedded network stack. It allows the MQTT client logic to remain independent from the transport mechanism, subject to the interfaces supplied by the project. MQTTClient-C is described as a C equivalent of MQTTClient and, as far as possible, a direct translation. That distinction matters when a device toolchain supports C but not C++. Teams should choose the C package when its API matches their language constraints, or use MQTTClient when the available network integrations and C++ tooling are more suitable. MQTTPacket is also usable independently when only packet encoding and decoding are needed. The README does not document broker configuration, automatic reconnect behavior, persistence guarantees, or a complete transport-neutral connection API. Those behaviors should be checked in the relevant package headers and documentation before treating the library as a full MQTT client for a production device. ## Building the Repository on Linux The documented Linux build creates a separate build directory, runs CMake, and then invokes make. This sequence is the repository's basic build method. It builds the packages available to the current CMake configuration, while the repository's travis-build.sh file is identified as the full Linux build and test sequence. Run the documented commands from the repository root: ```bash mkdir build.paho cd build.paho cmake .. make ``` The directory `build.paho` is created as a separate output location, so generated build files do not need to be placed directly in the source tree. The reader should inspect the generated build output for the libraries and samples produced by the configured packages. The README does not give a separate installation command for the CMake workflow, so it does not establish that `cmake --install` is supported. The repository also contains a Makefile. Its default source directory is `MQTTPacket/src`, and its default build directory is `build/output`. It defines the library name `paho-embed-mqtt3c` and includes sample names `pub0sub1` and `qos0pub`. The README's CMake instructions are the more general documented build path. The Makefile provides a lower-level alternative whose full targets are defined in that file rather than in the README. ## First Use Through the Paho Samples The README directs users to the samples directories for examples of intended API use. It does not include a complete connection, broker address, callback, or publish example in the text provided here. For that reason, the safest first use is to inspect the sample corresponding to the chosen package, then adapt its documented API calls to the target's transport and broker settings. The repository's Makefile identifies sample programs named `pub0sub1` and `qos0pub`. The naming indicates samples for publishing and subscribing, including a QoS 0 example, but the README does not state the exact broker parameters or runtime behavior for those programs. Those details must be taken from the sample source rather than inferred from the names. MQTTClient can produce debug tracing for sent and received MQTT packets when `MQTT_DEBUG` is defined as a preprocessor definition. This is useful when checking whether the embedded application is producing the expected packet flow, but tracing is a diagnostic feature rather than a substitute for transport validation. The documentation does not describe where trace output is routed or how it is formatted. A first integration should therefore establish the network path independently, inspect the relevant sample, and verify that the chosen client layer is compatible with the device's C or C++ build. The repository documentation identifies the sample locations and build tools, but does not supply a complete production connection configuration. ## Where the Embedded C Client Is the Wrong Choice The clearest limitation is the division of responsibility around networking. MQTTPacket does not provide the network connection itself. The README says that writing to and reading from the network is mainly left to the developer. If an embedded product expects a ready-made TCP, TLS, or device-specific MQTT connection stack, MQTTPacket alone will not provide that expectation. The higher-level clients reduce the amount of application work, but the README describes MQTTClient networking as pluggable and lists implementations for Linux, Arduino, and mbed. It does not claim support for every MCU SDK, RTOS, radio, or custom network interface. A project using another platform would need to inspect the repository and port the networking layer or use a different library with a matching integration. The C and C++ clients are not interchangeable without checking the API. MQTTClient-C is a translation of MQTTClient, not a promise that both packages expose identical behavior in every case. Code written for a C++ compiler, exceptions, classes, or C++ networking types cannot be assumed to compile against the C package. There is also a release-history consideration. The listed recent release is `v1.1.0`, dated 2017-07-14. The repository is not archived and its last push was on 2026-07-03, so the maintenance signal is mixed: recent repository activity is present, but the documented release line is old. Readers should verify the current source and package documentation rather than assuming that the old release description defines current compatibility. ## MQTTPacket Versus the Higher-Level Paho Clients Paho provides a useful internal choice rather than requiring every embedded application to adopt the same layer. MQTTPacket offers the smallest requirements and the narrowest responsibility: packet serialization, deserialization, and helper functions. It is the appropriate choice when the product already owns its MQTT session logic or needs packet operations inside another networking design. MQTTClient goes further by supplying a higher-level C++ client and separate networking classes. The documented platform implementations are Linux, Arduino, and mbed. This can reduce the amount of code an application writes around packet exchange, but it also introduces a dependency on the client API and its transport integration. MQTTClient-C addresses the case where C is the supported or conventional language. Its direct-translation relationship to MQTTClient makes the two client packages comparable at a high level, while their language and API details still need to be checked separately. A C application should not assume that C++ examples or class-based networking code can be copied directly. For an application with a custom network stack, MQTTPacket may provide the cleanest boundary. For an application that wants Paho's higher-level client structure and its existing platform support, MQTTClient or MQTTClient-C is more relevant. The decision should be based on transport ownership, language support, and the amount of session logic the device application already implements. ## Licensing, Maintenance, and Upgrade Surface The repository is dual licensed under the Eclipse Public License and the Eclipse Distribution License. The README states that the EDL allows the code to be embedded in an application and distributed in binary or source form without contributing application code or changes back to Paho, subject to the exact conditions in the EDL. The repository also contains `LICENSE`, `about.html`, `notice.html`, `epl-v20`, and `edl-v10` files. License selection and compliance should be checked against those files for the intended distribution model; this is not legal advice. The maintenance record requires two separate observations. The repository is not archived. Its last push was on 2026-07-03, which is within six months of the current date. However, the only listed recent release is `v1.1.0` from 2017-07-14. Recent source activity does not by itself establish that a new release was published or that an old deployment can upgrade without review. An upgrade may therefore involve checking source changes, sample behavior, supported MQTT packet features, and platform-specific networking code rather than changing only a version number. The README points to package documentation and samples, but it does not publish a compatibility matrix or a formal migration procedure. License file changes and target-platform build behavior deserve direct inspection when the library is embedded into a distributed product. ## Conclusion Adopt this library when an embedded product needs the Paho MQTT packet format and can supply or integrate its own network transport. Do not choose it merely because a complete managed MQTT client is wanted, since MQTTPacket leaves network I/O to the application. Before integration, verify that your target platform has a suitable MQTTClient network implementation, inspect the relevant sample, and review the current source and license files. ## FAQ ### Which Paho package should I use for an embedded C project? MQTTPacket is the lowest-level C package for MQTT packet serialization and deserialization. MQTTClient-C is the higher-level C client for platforms where C is supported or preferred. The README does not provide a universal selection rule beyond these descriptions. ### Does Eclipse Paho MQTT C client handle networking automatically? Not for MQTTPacket. The README says that writing to and reading from the network is mainly left to the developer, while MQTTClient provides separate networking classes with implementations listed for Linux, Arduino, and mbed. ### How do I build the repository on Linux? The documented basic build creates `build.paho`, runs `cmake ..`, and then runs `make`. The repository also includes `travis-build.sh` for the fuller Linux build and test sequence. ### Can I enable MQTT packet tracing? Yes. The README states that the `MQTTClient` API has debug tracing for MQTT packets sent and received when the `MQTT_DEBUG` preprocessor definition is enabled. ## Sources - [eclipse-paho/paho.mqtt.embedded-c on GitHub](https://github.com/eclipse-paho/paho.mqtt.embedded-c) - [Issues](https://github.com/eclipse-paho/paho.mqtt.embedded-c/issues) - [Project website](https://eclipse.org/paho) - [README](https://github.com/eclipse-paho/paho.mqtt.embedded-c/blob/master/README.md) - [Releases](https://github.com/eclipse-paho/paho.mqtt.embedded-c/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/eclipse-paho-paho-mqtt-embedded-c