Adding MQTT Features

[nazmibojan]

Hi All,

I'm just curious the possibility to add MQTT features inside Realtek linux environments.
I want to get your opinion related to implementing bluetooth features to configure ethernet setting, wifi ssid and mqtt endpoint.
So we can communicate with device via MQTT.
is that possible?
if yes, I want to explore more about this.

Thanks,
Nazmi

[jnilo1]

Hi Nazmi,

I dug into both points. Short version: MQTT is doable, BLE-for-provisioning is not realistic on your specific module.

Bluetooth on your TYZS4

Your module is a TYZS4-IPEX, built around the EFR32MG1B232F256GM48 (Series 1, 256 kB flash / 32 kB RAM) — the same radio chip family this project uses, documented with @lornys in discussion #85.

The silicon does support Bluetooth LE. The problem is the use case you have in mind — provisioning over BLE while keeping Zigbee running — needs Dynamic Multiprotocol (DMP, BLE + Zigbee concurrently), and Silabs requires at least 512 kB of flash for DMP (docs.silabs.com, AN1133). Your chip has only 256 kB — below that floor. The GSDK 4.5.0 DMP examples confirm it: they target MG13/MG12, never MG1.

So your options are:

• A BLE-only firmware: flashable, but it replaces the Zigbee firmware — you lose Zigbee while it runs. Not useful for a coordinator.
• BLE + Zigbee at the same time: not possible on this 256 kB part.

My recommendation: don't provision over BLE. Do network/MQTT-endpoint config on the Linux (RTL8196E) side — a small local web page or a config file over SSH. No extra radio firmware, no contention with Zigbee.

MQTT

Running an MQTT broker on the RTL8196E is fine: Eclipse Mosquitto is open source (EPL 1.0 / EDL 1.0), lightweight, has an OpenWrt package, and cross-compiles for MIPS — so it builds with this project's Lexra-MIPS toolchain (same path as BusyBox/OTBR), and easily fits in the ~20 MB free.

Just note what you'd carry over MQTT: the Zigbee→MQTT translation is Zigbee2MQTT's job, and Z2M (Node.js) is far too heavy for this SoC — that's why the project bridges the radio over TCP:8888 to a remote Z2M/ZHA. So Mosquitto here makes sense for gateway telemetry/admin, not as an on-device Z2M replacement.

[nazmibojan]

Hi @jnilo1 ,

Thanks a lot for your explanation regarding my previous question. I also try to explore the Bluetooth possibility, and like you said, it is not possible for the current chip.
My idea is turning this module as standalone zigbee host which can publish zigbee data to my MQTT broker at the cloud.
So, my approach will be:

• run an mqtt client inside the linux to forward the zigbee data to the cloud. this mqtt client also act as subscriber to receive a command from server.
• implement EZSP host to communicate with Zigbee chip to receive response from Zigbee chip, manage coordinator pairing method, etc.

Do you think my approach is possible to implement?

[jnilo1]

Hi Nazmi,

Yes, your goal — Zigbee data to a cloud MQTT broker, with commands coming back — is absolutely achievable. But before you write an EZSP host yourself, it's worth knowing where the real work is: EZSP framing is the easy part; the hard part is the ZCL / device-interview / pairing / attribute-reporting layer on top of it. That upper layer is exactly what Zigbee2MQTT and ZHA already implement. So you have two routes.

Route A — let an existing stack do it (recommended, no Zigbee code to write)

Keep the NCP-UART-HW firmware on the EFR32 and the in-kernel UART↔TCP bridge (port 8888). Then run Zigbee2MQTT in your cloud, pointed at your gateway:

serial:
  port: tcp://<gateway-ip>:8888
  adapter: ezsp

Z2M already publishes every Zigbee device/event to MQTT and subscribes for commands — which is exactly your bullet list, with zero code on the gateway. It also handles coordinator pairing, interview, ZCL parsing, OTA, etc.

One thing to fix: the TCP:8888 bridge is plaintext and meant for a trusted LAN. Exposing it to the internet would expose your Zigbee network, so tunnel it — WireGuard/VPN, an SSH tunnel, or a TLS wrapper (e.g. stunnel) between the gateway and your cloud.

Route B — on-device EZSP host + MQTT bridge (what you described)

This works too, and the individual pieces are light:

• MQTT client: Eclipse Mosquitto / libmosquitto or Eclipse Paho — both cross-compile for this MIPS target.
• EZSP host: the framing/transport layer is small.

The catch is everything above EZSP — coordinator management, device join/interview, ZCL attribute reads/reports — which you'd be reimplementing from scratch. That's the bulk of a Zigbee host stack, and it's a lot of work for a 200 MHz / 32 MB device. If you only need a few fixed device types and simple commands, a minimal custom host is feasible; for a general-purpose coordinator it's a large project.

My recommendation

Run the Zigbee stack where you have CPU (your cloud, via Route A) and let the gateway be the radio bridge it's designed to be. You get cloud MQTT in both directions immediately, and you keep the door open to ZHA/Matter later. Reach for Route B only if you have a specific reason to keep everything on-device.

Could you also have a look at #104 (comment) ? Thanks !

[nazmibojan]

Thank you for your explanation @jnilo1 !
Very clear explanation. I've started the development of your Route B because I only need a small group of fixed devices.
Thanks!