Zigbee2MQTT arrêtera de supporter les systèmes 32 bits en avril 2027, quand Node.js 22 arrivera en fin de vie. L’annonce a été faite par Koen Kanters, le mainteneur du projet, le 31 octobre 2026. Elle concerne les vieux Raspberry Pi, les Raspberry Pi OS 32 bits encore très répandus, les images Docker armv6/armv7/i386, mais aussi certaines installations sous Proxmox montées il y a quelques années. Vous avez six mois pour vérifier votre installation et migrer. Voici comment faire sans réappairer un seul appareil. On fait le point.
Zigbee2MQTT et le 32 bits : ce qui a été annoncé
Le support 32 bits de Zigbee2MQTT prendra fin le 30 avril 2027, date de fin de vie de Node.js 22 sur lequel est bâti Z2M. Koen Kanters (Koenkk) l’a annoncé dans l’issue #33552 GitHub, ouverte le 31 octobre 2026 et épinglée sur le dépôt. Son titre initial ne visait que les images Docker, mais il a été élargi le 1er novembre à tout le 32 bits.
Concrètement quels changements :
- Node.js 24 devient le minimum après avril 2027. Z2M a déjà suivi ce rythme : la 2.13 avait abandonné Node.js 20 à sa fin de vie.
- Les images Docker 32 bits sont figées :
linux/386,linux/arm/v6etlinux/arm/v7ne recevront plus de mises à jour. - Les installations natives sur un OS 32 bits ne pourront plus faire tourner une version de Node.js supportée.
- La cible recommandée : un OS 64 bits,
amd64/x86_64ouarm64/aarch64.
Z2M refusera pas de démarrer sur un hôte 32 bits après cette date, mais il ne recevra plus de mise à jour. Dans les faits, une installation figée continuera de tourner, mais sans nouveaux appareils supportés, sans correctifs de sécurité ni mises à jour OTA ajoutées ensuite. C’est pourquoi il faut considérer cette annonce et préparer les choses.
Pourquoi Zigbee2MQTT lâche le 32 bits ?
La décision vient de Node.js, pas de Zigbee2MQTT. EN effet, Z2M est une application Node.js : il suit le cycle de vie des versions LTS. Or Node.js 24 ne publie plus de binaires officiels pour aucune plateforme 32 bits. Une fois Node.js 22 en fin de vie, il n’existe plus de Node supporté pour ces machines.
C’est la même logique qui a poussé Home Assistant à déprécier i386, armhf et armv7 en mai 2025. L’écosystème domotique local tourne désormais en 64 bits. Ce n’est pas non plus une grande surprise car beaucoup de systemes informatiques ont déjà lâcher l’architecture 32 bits depuis bien longtemens.
Comment vérifier son installation Zigbee2MQTT
La plupart des utilisateurs Home Assistant OS qui utilise Z2M directement dans Home Assistant ne sont pas concernés : l’add-on officiel Zigbee2MQTT n’est déjà publié qu’en aarch64 et amd64 (config de l’add-on). Tout le reste mérite deux minutes de vérification.
| Installation | Risque |
|---|---|
| Add-on Z2M sous Home Assistant OS | Aucun |
| Raspberry Pi 1, 2 v1.1, Zero, Zero W | Bloquant : matériel 32 bits |
| Raspberry Pi 3 à 5 (et Zero 2 W) sous Raspberry Pi OS | Élevé si l’OS est en 32 bits |
| Docker sur Pi, NAS ou mini-PC | Moyen |
| NAS Synology en Docker | Faible sur x86, élevé sur les vieux modèles ARM |
| LXC ou VM sous Proxmox | Faible sur l’archi, réel sur Node.js |
⚠️ Le piège classique : un Raspberry Pi OS avec un noyau 64 bits mais un espace utilisateur 32 bits. uname -m répond aarch64 alors que tous vos paquets, Node.js compris, sont en armhf.
Fiez-vous plutôt à ces quelques commandes à jouer dans le terminal qui vous donneront une information complete :
# Architecture des paquets (armhf = 32 bits, arm64/amd64 = 64 bits)
dpkg --print-architecture
# Taille des mots de l'espace utilisateur (32 ou 64)
getconf LONG_BIT
# Version et architecture de Node.js
node -p "process.version + ' ' + process.arch"
# Architecture de l'image Docker utilisée
docker image inspect koenkk/zigbee2mqtt --format '{{.Architecture}} {{.Variant}}'
Zigbee2MQTT sous Proxmox : le vrai sujet, c’est Node.js
Sous Proxmox, l’architecture pose rarement problème : Proxmox VE ne tourne que sur amd64, donc vos LXC et VM sont en 64 bits par défaut. Le risque est ailleurs. Dans un LXC Zigbee2MQTT installé en natif, Node.js vit dans le conteneur et ne bouge pas tout seul. Un conteneur créé en 2024 ou 2025 tourne souvent encore en Node.js 20 ou 22.
Cas 1 : LXC installé avec les community-scripts
C’est la méthode de notre guide Comment installer Zigbee2MQTT LXC sous Proxmox. Bonne nouvelle : le script actuel installe Node.js 24, et sa routine de mise à jour remonte Node.js en 24 sur les conteneurs Debian existants.
- Sur l’hôte, prenez un snapshot du conteneur Z2M avant de lancer les operations.
- Dans la console du LXC, vérifiez la version actuelle :
node -v.
(si la commande retourne v24.x.x vous n’avez rien à faire) - Sinon, lancez la commande
updatedans le conteneur. Le script sauvegarde/opt/zigbee2mqttetdata/, met à jour Node.js et pnpm, télécharge la dernière release puis recompile. - Contrôlez :
node -vdoit afficherv24.x, puissystemctl status zigbee2mqtt. - En cas de souci restaurez votre snapshot.
Cas 2 : LXC monté à la main
Si Node.js vient du dépôt NodeSource, basculez-le sur la branche 24, réinstallez puis recompilez Zigbee2MQTT. Le changement de version majeure impose de reconstruire les modules natifs comme serialport. Dans ce cas, la meilleure approche reste de réinstaller une base propre avec la dernière version et de procéder à la restauration de votre configuration pour ne rien perdre. Je vous explique déjà tout pas à pas dans un guide.
Comment sauvegarder et restaurer ZigBee2MQTT
Dans ce guide, nous allons vous expliquer comment sauvegarder la configuration de ZigBee2MQTT en vue d’une mise à jour ou d’une migration. En effet, toute mise à jour peut provoquer des problèmes et voir sa configuration et les périphériques associés…
Cas 3 : Docker dans une VM ou un LXC
Docker récupère l’image correspondant à l’hôte, donc amd64. Rien à faire, sauf si vous avez forcé --platform ou pinné un tag ancien : vérifiez avec docker image inspect.
Cas 4 : VM Home Assistant OS
L’add-on Z2M est déjà en 64 bits. Rien à faire.
Les exceptions à surveiller
- Une vieille VM ou un vieux template i386 créé « pour économiser de la RAM » : à recréer en
amd64. - Proxmox sur Raspberry Pi (portages non officiels type Pimox ou PXVirt) : ils sont en
arm64, donc compatibles. Seuls les LXCarmhfsont concernés.
Le passthrough USB du dongle ne change pas. Profitez-en pour déclarer le coordinateur via /dev/serial/by-id/ plutôt que /dev/ttyUSB0, ou passez à un coordinateur réseau (SLZB-06 et consorts) avec tcp:// : plus aucun passthrough à gérer.
Migrer Zigbee2MQTT vers 64 bits sans réappairer
Tout votre réseau Zigbee tient dans le dossier data/ de Zigbee2MQTT. Si vous gardez le même coordinateur et que vous restaurez ce dossier, aucun appareil n’est à réappairer. Que vous réinstalliez le Pi en 64 bits, passiez sur un mini-PC, un LXC Proxmox ou l’add-on Home Assistant, la procédure est la même.
- Ne mettez rien à jour pour l’instant : notez la version installée, puis arrêtez Zigbee2MQTT.
- Sauvegardez
data/en entier, au minimum :configuration.yaml(canal,pan_id,ext_pan_id,network_key)database.db(appareils appairés)coordinator_backup.json(sauvegarde du coordinateur)state.jsonet un éventuelsecret.yaml
- Installez la nouvelle cible en 64 bits : Raspberry Pi OS Lite 64 bits, Debian
amd64, LXC Proxmox ou add-on HA. - Installez Zigbee2MQTT dans la même version, sans le démarrer : image Docker
arm64/amd64, ou installation native avec Node.js 24. - Restaurez
data/au bon endroit et branchez le même coordinateur. - Adaptez
serial.portsi le chemin a changé (préférez/dev/serial/by-id/...) et l’adresse du broker MQTT si besoin. - Démarrez, puis vérifiez dans l’interface que les appareils remontent et que Home Assistant retrouve ses entités via la discovery MQTT.
Laissez tourner 24 heures avant de valider complètement la bascule, les appareils sur batterie peuvent mettre du temps à se manifester.
Vous changez aussi de coordinateur ? coordinator_backup.json permet de restaurer le réseau sur un nouvel adaptateur, en restant dans la même famille de puces. Changer de famille (Texas Instruments vers Silicon Labs, par exemple) est une autre opération, plus risquée : à faire à part.
Zigbee2MQTT 2.14.3 : attention au nouveau transport de zigbee-herdsman 11
Sortie le 1er novembre 2026, la 2.14.3 embarque zigbee-herdsman 11.0.0. Cette bibliothèque, qui dialogue avec le coordinateur, intègre un transport unifié marqué comme changement cassant. Il réécrit toute la couche de communication avec le port, série ou tcp://.
- Aucun changement de configuration n’est annoncé : vos options
serialrestent valables. - Adaptateurs testés par l’auteur : Ember (EFR32MG24), Z-Stack (CC2674P10) et ZoH. ZBOSS n’a été testé qu’en
tcp://. deCONZ et ZiGate ne sont pas cités. - Plusieurs correctifs ont été ajoutés pendant la revue (fuite de timers, timeouts ZBOSS, gestion des déconnexions au démarrage).
Notre conseil
si vous combinez cette mise à jour avec une migration, faites-les en deux temps. Migrez d’abord vers 64 bits à version égale, puis mettez à jour vers 2.14.3. Sous Proxmox, prenez un snapshot avant chaque étape. Si votre coordinateur n’est ni Ember ni Z-Stack, attendez quelques jours de retours avant de mettre à jour.
FAQ
Non, une installation existante continuera de tourner. Mais elle ne recevra plus de mises à jour : ni nouveaux appareils, ni correctifs, ni corrections de sécurité de Node.js.
Le matériel est compatible 64 bits. Seul l’OS compte : si dpkg --print-architecture répond armhf, réinstallez Raspberry Pi OS en 64 bits.
Non. Il n’est publié qu’en aarch64 et amd64.
L’architecture, non : Proxmox est en 64 bits. En revanche, un LXC natif doit passer à Node.js 24 avant avril 2027. Avec les community-scripts, la commande update s’en charge.
Non, si vous restaurez le dossier data/ et gardez le même coordinateur.
Node.js 24 dès maintenant. Node.js 22 reste accepté jusqu’à sa fin de vie, le 30 avril 2027.








