Je partage un projet sur lequel je travaille depuis quelques mois : un firmware custom complet pour la passerelle Zigbee Lidl Silvercrest.
Cette passerelle bon marché, souvent considérée comme dépassée, finit souvent au fond d’un tiroir. Le projet essaye de lui donner une seconde vie en la transformant en hub domotique 100% local, directement utilisable avec Home Assistant — coordinateur Zigbee, routeur Thread, ou routeur Zigbee mesh.
Ce qu’on peut en faire
Coordinateur Zigbee — compatible Zigbee2MQTT (ember) et ZHA, via le réseau (socket TCP)
Thread Border Router — otbr-agent tourne nativement sur la passerelle, intégration HA directe
Routeur Zigbee 3.0 — pour étendre un réseau mesh existant
Flashage radio OTA — pas besoin de sonde SWD, tout se fait par le réseau
Le mode (Zigbee ou Thread) se choisit au moment du flash — c’est une seule image firmware pour les deux.
Matériel
La passerelle embarque un Realtek RTL8196E (Linux, 200 MHz MIPS, 32 MB RAM) et une radio Silabs EFR32MG1B (Zigbee/Thread) reliée en UART. Le projet fournit le firmware des deux puces.
Installation
Un seul script fait tout : build de l’image, détection automatique de l’état de la passerelle, flash :
git clone https://github.com/jnilo1/hacking-lidl-silvercrest-gateway.git
cd hacking-lidl-silvercrest-gateway
./flash_install_rtl8196e.sh
Il faut un adaptateur USB-série (3.3V, 38400 baud) pour le premier flash uniquement. Ensuite, les mises à jour se font par le réseau (SSH + TFTP).
Ce qui a été fait
Bootloader custom avec auto-flash et notification UDP
Noyau Linux 5.10 recompilé avec driver Ethernet optimisé, IPv6, gpio-leds
Je confirme. La seule contrainte est de pouvoir mettre la passerelle en boot mode via la console série avec ESC. Pas la peine de récupérer le password d’origine (le hack de Paul Banks est inutile)
J’ai testé le firmware NCP-UART-HW avec zigbee2mqtt, cela fonctionne.
J’ai pu appairer un module.
Pour la version OTBR, je vais fouiller si je trouve des info. J’ai testé avec un débit différent du port série du module zigbee comme pu le voir dans des solutions mais toujours l’erreur.
Les erreurs « Wait for response timeout » + crash du Spinel driver signifient que otbr-agent n’arrive pas à communiquer avec la puce radio EFR32 sur le port série.
Le fait que Zigbee2MQTT fonctionne est une bonne nouvelle : ça confirme que l’UART et le hardware sont OK.
Quelques pistes à vérifier :
Firmware EFR32 : le mode OTBR nécessite le firmware OT-RCP sur l’EFR32. Si le firmware actuel est le NCP ou RCP Zigbee, otbr-agent ne pourra pas dialoguer avec la radio. Le firmware EFR32 se flashe séparément avec ./flash_efr32.sh (option OT-RCP dans le menu). flash_install_rtl8196e.sh ne modifie que le côté Linux (kernel + userdata), pas la radio.
Baudrate : otbr-agent attend 115200 baud (configuré dans S70otbr). Si le firmware EFR32 a été compilé avec un autre baudrate, ça timeout.
Conflit sur le port série : vérifier qu’aucun autre processus n’utilise /dev/ttyS1 en même temps (serialgateway est normalement désactivé en mode OTBR, mais au cas où : ps | grep serial).
La v2.1.0 vient de sortir avec quelques corrections notables :
Boothold : la commande boothold (reboot en mode bootloader depuis SSH) fonctionne maintenant de manière fiable — c’était aléatoire avant à cause d’un conflit de cache MIPS
LED OTBR : en mode Thread, la LED status s’allume quand le réseau Thread est actif
Persistance Thread : un daemon surveille le dataset Thread toutes les 30s et ne l’écrit sur flash que s’il a changé (en pratique, uniquement à la création/modification du réseau — pas d’usure inutile du flash)
Arrêt propre : tous les services sont stoppés proprement avant reboot
Mise à jour : ./flash_install_rtl8196e.sh gateway_ip
Je regarde cela asap. Je pense savoir ce qui s’est passé. En attendant essaye de remplacer le fichier passwd dans le skeleton de userdata (34-Userdata/skeleton/etc) par celui d’une version antérieure (v2.0.0 par ex). Supprime userdata.bin et relance flash_install
J’ai restauré le mdp par defaut dans le repo .
Tiens moi au courant de tes essais avec ot-br. Perso je n’ai que très peu de device matter et je n’ai jamais eu l’occasion de tester la passerelle gérant un réseau thread/matter « grandeur nature ». Donc tous les feedbacks me sont utiles
Ce we je me suis fait trainé à Ikea par ma femme … un samedi, l’horreur bref …
Mais j’en ai profité pour regarder les produits domotique.
J’ai acheté une télécommande Rodret en Zigbee (que j’utilise du coup avec mon slzb-06MU) et ça fonctionne très bien (je n’avais pas trop de doute).
Comme j’ai flashé ma passerelle lidl en otbr, j’ai voulu tester ça et j’ai pris 2 produits matter:
Un capteur d’ouverture MYGGBET
Un capteur de température TIMMERFLOTTE
Les 2 sont des matter (toute la nouvelle gamme Ikea l’est) et je n’ai eu qu’un problème pour l’appairage avec la passerelle Lidl flashé, via mon tel et l’app Home Assistant Companion:
Le QR Code ne marche pas, ça indique simplement un laconique « Une erreur est survenue » sans aucun détail … Le code lui a fonctionné et les 2 devices sont bien remontés dans HA, c’est ultra cool Merci au dev.
A noter une chose que je n’ai pas vu dans la doc (je suis peut-être simplement passé à côté) c’est que dans l’app companion de HA, j’ai dû aller dans Paramètres → Application Companion → Dépannage → Synchroniser les identifiants Thread … Sinon j’avais la même erreur avec le code qu’avec le QR Code.
Bizarre,car pour moi l’association via QR code marche parfaitement. Ma checklist perso:
1/ Coté HA :
S’assurer de la bonne intégration, dans cet ordre, de :
Open Thread Border Router (URL : http://<IP_PASSERELLE>:8081)
Thread (auto-détecté après l’ajout d’OTBR) — le réseau Thread créé par la passerelle doit apparaître comme « Réseau favori » dans la configuration Thread de HA
Matter — sur HAOS/Supervised, Matter Server est inclus. Sur HA Core (Docker), il faut lancer le container Matter Server séparément (le Docker Compose du repo le fait automatiquement sur localhost:5580)
2/ Device Matter en mode Association
3/ HA Companion : Téléphone avec activation du WiFi sur 2.4 GHz sur le même subnet que la passerelle. Bluetooth activé. En cas de doute (pré-existence d’un ancien réseau Thread) aller sur Paramètres/Application Companion/Dépannage/Synchroniser les identifiants Thread.
L’ajout d’un matériel via Matter et QR code devrait fonctionner. La configuration sans QR code également.
Si les devices sont visibles via ot-ctl router table et que le ping fonctionne, la passerelle fait son travail — le réseau Thread est opérationnel.
Le problème est probablement côté intégration ESPHome/HA. Quelques pistes :
mDNS/DNS-SD : vérifier que le service est publié sur le réseau local. Depuis le PC :
avahi-browse -art | grep <nom_device>
Si le device n’apparaît pas, c’est que la chaîne SRP → DNS-SD proxy ne fonctionne pas correctement.
SRP server : sur la passerelle, vérifier que le device est bien enregistré :
ot-ctl srp server host
ot-ctl srp server service
ESPHome + Thread est encore assez récent — vérifier la version d’ESPHome et les logs côté device. Certaines versions nécessitent une config spécifique pour Thread.
Je pense que c’est un sujet ESPHome plutôt que passerelle — ça vaudrait le coup de poser la question sur le Discord ESPHome.
Merci au dev.