Zigbee2mqtt: Support for SMLIGHT keys via network

prohand · February 23, 2026, 8:58am

Hello,

Following my tutorial here:

https://community.gladysassistant.com/t/connexion-cle-smlight-a-zigbee2mqtt-sur-gladys-full-ssl-tls-mqtt-et-z2m-externe

I am opening this feature request regarding support for SMLIGHT keys over the network on gladys’ zigbee2mqtt

Thanks

pierre-gilles · August 17, 2026, 8:31am

Hi @prohand,

Claude did this development in this PR:

github.com/GladysAssistant/Gladys

Zigbee2mqtt: support network Zigbee coordinators (SMLIGHT SLZB-06/07…) (#2901)

master ← claude/z2m-network-adapter

ouvert 05:36PM - 15 Aug 26 UTC

Pierre-Gilles

+1120 -124

Implements feature request: https://community.gladysassistant.com/t/zigbee2mqtt-…prise-en-charge-des-cles-smlight-via-reseau/10045 This PR was opened by an automated Claude Code run. It needs human review and real-hardware testing: no network Zigbee coordinator (SMLIGHT SLZB-06/SLZB-07 or similar) was available in the environment, so the Docker/Zigbee2mqtt side was only validated through unit tests, not against a real gateway. ### Description Until now the Zigbee2mqtt integration only supported a Zigbee coordinator plugged in over USB: the setup page listed USB serial ports and the generated Z2M container always got the USB device passed through with `HostConfig.Devices`. Network coordinators (SMLIGHT SLZB-06/SLZB-07, ZigStar, TubesZB…) are reached over TCP instead — `serial.port: tcp://<host>:<port>` plus an explicit `serial.adapter` in Zigbee2mqtt's `configuration.yaml` — which was impossible to configure from Gladys. The author of the request had to run MQTT and Zigbee2mqtt manually outside Gladys ([his tutorial](https://community.gladysassistant.com/t/connexion-cle-smlight-a-zigbee2mqtt-sur-gladys-full-ssl-tls-mqtt-et-z2m-externe/10041)). The "Installation from Gladys" setup mode now asks how the Zigbee coordinator is connected: - **USB dongle** — unchanged, still the default (existing installations keep working exactly as before, the stored variable is simply absent); - **Network coordinator** — the user enters `tcp://<host>:<port>` (the `tcp://` prefix is optional) and picks the Zigbee2mqtt adapter type (`ember`, `zstack`, `deconz`, `ezsp`, read from the existing `/api/v1/service/zigbee2mqtt/adapter` route). Server side: - 3 new service variables following the existing `Z2M_*` pattern: `Z2M_ADAPTER_MODE` (`usb` / `network`), `Z2M_NETWORK_ADAPTER_URL`, `Z2M_NETWORK_ADAPTER_TYPE`. They are part of `SETUP_VARIABLES`, saved/loaded like the others and destroyed by the reset route. - New `services/zigbee2mqtt/utils/validateSetup.js`: validates the adapter mode and the adapter type against the known Z2M adapter keys, validates and normalizes the URL (host shape, `tcp://` scheme, port between 1 and 65535) and throws `BadParameters` (HTTP 400) otherwise, like the neighbouring routes. - `configureContainer` writes `serial.port` / `serial.adapter` for a network coordinator, and restores the USB device path when switching back. A USB configuration that is already in place is left untouched. - `installZ2mContainer` creates the container without any device passthrough in network mode, and removes/recreates the container when switching between USB and network so the device binding stays in sync. - `init` treats a configured network coordinator like a connected dongle to start the MQTT + Z2M containers; a new `networkAdapterConfigured` flag is exposed in the service status. Front side: USB/network radio choice, the two new fields, updated summary and setup requirements, i18n in **en**, **fr** and **de**. Notes: - The MQTT broker and Zigbee2mqtt containers are still managed by Gladys in this mode — only the coordinator is remote. - The Zigbee2mqtt service has no README documenting the setup, so no documentation file was updated. ## Forum Forum: https://community.gladysassistant.com/t/zigbee2mqtt-prise-en-charge-des-cles-smlight-via-reseau/10045 ### Checklist - [x] Tests pass: `cd server && npm run coverage` (Codecov requires 100% coverage on changed lines) and Cypress (`npm run cypress:run`) if the UI changed - The Zigbee2mqtt suites were run with coverage: 330 passing, 100% statements/branches on every file changed by this PR (the only uncovered lines in `configureContainer.js` are the pre-existing `portfinder` fallback). The full server suite was run too; the only failures are pre-existing environment ones in this sandbox (`sqlite3` binary missing for the backup/restore tests, outbound calls for the gateway/AI tests) and are unrelated to this change. - **Cypress was NOT run**: the Cypress binary is not installed in this environment. The existing Zigbee2mqtt setup specs and fixtures were updated for the new request payload and status field, but they have not been executed — please let CI run them. - [x] Linter and prettier pass on both front and server (`npm run eslint`, `npm run prettier`) — plus `npm run compare-translations` and `npm run build` on the front. - [x] No undocumented breaking change --- _Generated by [Claude Code](https://claude.ai/code/session_013yxguVaLdJ8ZKmw5x3HePT)_ ## Summary by CodeRabbit - **New Features** - Zigbee2MQTT setup now supports network-connected coordinators alongside USB dongles. - Configure connection mode, network address, and adapter type. - Setup summaries, requirements, and status now reflect the selected coordinator. - **Bug Fixes** - Improved network address validation, normalization, and port checks. - Switching between USB and network coordinators now updates container configuration correctly. - **Localization** - Updated English, German, and French translations for network coordinator setup.

I’m up for testing

There is an amd64 build on this image:

ghcr.io/gladysassistant/gladys-preview:claude-z2m-network-adapter

prohand · August 17, 2026, 8:58am

Thanks

I’ll test it tonight and get back to you

prohand · August 17, 2026, 3:52pm

Good news, this doesn’t break the existing installation

So on my dev installation I completely reset zigbee2mqtt and on startup of zigbee2mqtt I get this:

[2026-08-17 15:47:34] error: zh:zstack:znp: Socket error Error: connect ECONNREFUSED 192.168.xx.xx:7638
[2026-08-17 15:47:34] error: z2m: Error while starting zigbee-herdsman
[2026-08-17 15:47:34] error: z2m: Failed to start zigbee-herdsman
[2026-08-17 15:47:34] error: z2m: Check Zigbee2MQTT fails to start/crashes runtime | Zigbee2MQTT for possible solutions
[2026-08-17 15:47:34] error: z2m: Exiting…
[2026-08-17 15:47:34] error: z2m: Error: Error while opening socket
at Socket. (/app/node_modules/.pnpm/zigbee-herdsman@10.4.0/node_modules/zigbee-herdsman/src/adapter/z-stack/znp/znp.ts:160:24)
at Socket.emit (node:events:520:35)
at emitErrorNT (node:internal/streams/destroy:170:8)
at emitErrorCloseNT (node:internal/streams/destroy:129:3)
at processTicksAndRejections (node:internal/process/task_queues:90:21)
[2026-08-17 15:47:34] info: zh:zstack:znp: Port closed

/app/node_modules/.pnpm/readable-stream@3.6.2/node_modules/readable-stream/lib/_stream_writable.js:264
var er = new ERR_STREAM_WRITE_AFTER_END();
^
Error: write after end
at writeAfterEnd (/app/node_modules/.pnpm/readable-stream@3.6.2/node_modules/readable-stream/lib/_stream_writable.js:264:12)
at File.Writable.write (/app/node_modules/.pnpm/readable-stream@3.6.2/node_modules/readable-stream/lib/_stream_writable.js:300:21)
at DerivedLogger.ondata (/app/node_modules/.pnpm/readable-stream@3.6.2/node_modules/readable-stream/lib/_stream_readable.js:629:20)
at DerivedLogger.emit (node:events:520:35)
at addChunk (/app/node_modules/.pnpm/readable-stream@3.6.2/node_modules/readable-stream/lib/_stream_readable.js:279:12)
at readableAddChunk (/app/node_modules/.pnpm/readable-stream@3.6.2/node_modules/readable-stream/lib/_stream_readable.js:262:11)
at DerivedLogger.Readable.push (/app/node_modules/.pnpm/readable-stream@3.6.2/node_modules/readable-stream/lib/_stream_readable.js:228:10)
at DerivedLogger.Transform.push (/app/node_modules/.pnpm/readable-stream@3.6.2/node_modules/readable-stream/lib/_stream_transform.js:132:32)
at DerivedLogger._transform (/app/node_modules/.pnpm/winston@3.19.0/node_modules/winston/lib/winston/logger.js:337:12)
at DerivedLogger.Transform._read (/app/node_modules/.pnpm/readable-stream@3.6.2/node_modules/readable-stream/lib/_stream_transform.js:166:10)

The error is very likely coming from my production which is already connected to the network controller SLZB’s socket
Since there is a risk that my production is broken I won’t be able to go further in testing on my side

Edit: I’m looking into it but there is a second radio on the SLZB-MR01 so I’m setting it up to work with Zigbee

prohand · August 17, 2026, 4:05pm

@pierre-gilles

I confirm that everything is okay

pierre-gilles · August 17, 2026, 5:06pm

Amazing, thanks for the tests!!

mutmut · August 17, 2026, 7:06pm

So if I understand correctly, we’ll be able to select the SMLIGHT via IP in Gladys with an internal Z2M?
Currently, my SMLIGHT configuration is linked to my external Z2M.

It would be great to have a direct link to connect to it when we need to update the firmware (like the link to Z2M).
If I push it even further, having a notification when there’s a new firmware (like on HA)

prohand · August 17, 2026, 7:10pm

Yes, that’s exactly it

Topic		Replies	Views
Pouvoir utiliser un Zigbee2mqtt externe dans Gladys Demandes livrées zigbee2mqtt , feature-integration	66	823	May 6, 2024
Zigbee2mqtt 2.0 : Approche à prendre? Développement	12	271	May 22, 2025
Zigbee2mqtt - services démarrés mais croix rouge pour le lien Configuration	59	1894	May 13, 2023
Gladys Assistant 4.2 est disponible avec la compatibilité Zigbee2mqtt ! 🚀 Actualités	146	5874	May 17, 2021
[Z2M] Tests en zigbee2mqtt 1.42.0 > 2.1.3 >..> 2.4.0 >..> 2.6.1>...>2.7.2 Développement zigbee2mqtt	33	1266	December 8, 2025

Zigbee2mqtt: Support for SMLIGHT keys via network

Related topics