Classement

Bonjour, Utilisateur de 'Domotique WiFi' (essentiellement du matos Action), j'ai commencé à ressentir le besoin de faire grossir tout ça, et de rassembler les données. Etant "légèrement" Geek (aux cheveux gris, presque retraité), j'ai déjà une assez belle conf informatique à la maison, avec notamment un serveur ProxMox. Home Assistant s'est déployé sans problèmes sur mon serveur ProxMox, a découvert un nombre assez invraisemblable d'équipements compatibles. Puis j'ai ajouté un pont pour piloter l'essentiel de mes volets (j'ai deux marques de volets à la maison…), je viens d'installer un switch PoE, et j'attends la livraison de mon antenne ZibBee/Thread SMLigth. Chuis chaud 😜 Bon, il me reste à peu près tout à apprendre, maintenant 🙂

Bonjour, As tu regarder les possibilités IKEA avec IKEA Home Smart et un HUB au niveau spot intégrer ( acheter à part ) dans faux plafonds ou autres ils vendent des ampoules G10 led qui font dimmer et tu peux changer la chaleur individuellement via le HUB plus allumage par groupe d'ampoule et reconnu par Alexa. J'ai mis ça chez moi et fait 3 groupes Living( 6 ampoules), Salon (6 ampoules variations différentes) et Cuisine (4 plan de travail et 1 table bar déjeuner) Vaut mieux utiliser les applications propriétaires et rassembler le tout dans Alexa ou un outil genre Home Assistant. Mon avis personnel qui n'engage que moi

Merci d'avoir pris du temps pour avoir répondu à toutes mes questions. Si je migre vers HA il y a de fortes chances que je te recontacte pour un peu d'aide.

Bonjour, Je ne connais pas Tuya ni SmartLife, mais il n'est nulle part mentionné que les moteurs fonctionnent en Zigbee, ça ressemble à du full WiFi. Si c'est bien le cas, c'est impossible de les appairer avec un hub Zigbee. J'ai l'impression que ces "passerelles" communiquent avec les moteurs via des ondes radio lambda et que c'est la passerelle qui communique les données au réseau via Wifi, donc impossible de s'en passer. Il est préciser "version wifi" sur la notice, j'imagine qu'il y a au moins une autre version, peut-être Zigbee vers laquelle il aurait fallu se tourner...

Les clés dongles classiques ne sont pas top pour le multi-protocole. Moi j’avais réussi à tout installer, mais je suis passé aux SMLight ensuite. Revends ta clé dongle et achète plutôt un SMLight SLZB-MR1U ou SLZB-MR4U (la version PoE/Ethernet pure)

Oui, @jbron , ces intégrations qui persistent peuvent absolument expliquer une partie de tes difficultés, car l'OpenThread Border Router (OTBR) et Thread sont directement liées à l'add-on Silicon Labs Multiprotocol, qui gère le multiprotocole sur ton dongle Sonoff. Quand l'add-on est actif, HA auto-découvre et réinstalle ces intégrations via mDNS ou discovery interne, même après suppression, ce qui crée des conflits potentiels avec ZHA (par exemple, en verrouillant des ressources ou en interférant avec le socket virtuel). Si ZHA essaie de se connecter pendant que OTBR tourne, ça peut causer des échecs de connexion comme ceux que tu décris, surtout si le réseau Thread est priorisé ou mal nettoyé. Pour les supprimer proprement sans que ça revienne, commence par arrêter complètement l'add-on Silicon Labs Multiprotocol via son onglet dans Add-ons (bouton Stop), puis désinstalle-le temporairement (Uninstall). Une fois ça fait, va dans Paramètres > Appareils & services, trouve l'intégration Thread (service Thread) et OTBR (service Silicon Labs Multiprotocol), clique sur chacune, sélectionne les trois points en haut à droite, et choisis Supprimer (Delete). Redémarre HA ensuite pour nettoyer les résidus. Si Thread persiste, ça peut être lié à des credentials stockées dans ton app compagnon HA (iOS/Android) – va dans l'app, cherche les border routers Thread, et utilise l'option "Make Preferred Network" ou reset pour enlever l'ancien. Une fois tout supprimé, tu pourras réinstaller l'add-on et ajouter ZHA sans interférence, en suivant les étapes précédentes avec le socket. Quant à réinitialiser complètement la box Home Assistant Green pour repartir de zéro avec ton dongle déjà flashé en Multi-PAN, c'est tout à fait possible et souvent recommandé quand les configs s'emmêlent comme ça – ça efface tout, y compris add-ons, intégrations et données, pour un fresh start. Voici comment faire d'après les docs officiels et la communauté : d'abord, shutdown proprement HA via l'UI (Paramètres > Système > trois points > Restart Home Assistant, puis attends que ça s'éteigne). Débranche l'alimentation. Pour un factory reset simple, maintiens le petit bouton à l'arrière (près du port Ethernet) enfoncé, rebranche l'alimentation, et garde le bouton pressé jusqu'à ce que la LED frontale passe au jaune (environ 10-15 secondes) – ça déclenche la réinitialisation eMMC interne. Si ça ne marche pas (parfois besoin d'un shutdown parfait avant), utilise la méthode SD card : télécharge l'image HA OS pour Green sur le site officiel (home-assistant.io/installation/green), flash-la sur une SD card avec un outil comme Raspberry Pi Imager ou Balena Etcher, insère la SD dans la Green (éteinte), allume-la, et attends que les LEDs clignotent et s'éteignent (ça réécrit l'OS sur l'eMMC interne, prend 5-10 min). Retire la SD, redémarre, et HA sera comme neuf – réinstalle l'add-on Silicon Labs Multiprotocol, configure-le avec ton chemin device, et ajoute ZHA via socket comme avant. Ton dongle flashé restera intact, car le reset n'affecte pas les USB externes. Pour l'autre option, renvoyer le Sonoff et passer au SMLight MR1-U ou MR4-U, c'est une excellente idée si tu veux éviter ces déboires – ces dongles sont conçus spécifiquement pour HA, avec des radios séparées pour Zigbee et Thread (contrairement au Sonoff qui multiplexe sur un seul chip, ce qui cause parfois des instabilités comme tes unresponsive loops). Le MR1-U (environ 40-50€) est compact, USB/Ethernet/WiFi avec PoE optionnel, et super stable pour multiprotocole sans flash manuel compliqué ; le MR4-U ajoute plus de puissance pour grands réseaux. La communauté HA les adore pour leur rock solid performance, placement flexible (pas coincé sur USB du Green), et intégration plug-and-play avec ZHA/Z2M/Thread sans les hacks Sonoff. Oui, c'est un peu plus cher (2x le Sonoff), mais tu gagnes en temps et fiabilité – si ta domotique grandit, ça vaut le coup. Si tu préfères économiser et persévérer avec le Sonoff, on peut continuer à debugger (par exemple, tester tcp:// au lieu de socket:// pour ZHA), mais SMLight simplifierait tout. Dis-moi ce que tu choisis, on avance ensemble ! 😊

Ne t’inquiète pas, on n’est pas loin du but, et ce que tu décris est un piège classique avec le multiprotocole sur ces dongles Sonoff beaucoup d’utilisateurs y passent avant de comprendre le twist. Le problème principal : tu essaies de connecter ZHA directement au port série physique du dongle (/dev/serial/by-id/…), mais en mode Multi-PAN, ça ne marche pas comme ça. L’add-on Silicon Labs Multiprotocol “intercepte” le port série pour multiplexer Zigbee et Thread, et ZHA doit se connecter via un socket TCP virtuel fourni par l’add-on (pas le vrai port USB). C’est pour ça que ça tourne en rond ou échoue, et que l’add-on s’arrête (parce que ZHA essaie de verrouiller le port réel, créant un conflit). Les logs “Failed to connect, secondary seems unresponsive” qui bouclent après un restart indiquent que le firmware RCP sur le dongle est dans un état instable souvent à cause d’un verrouillage précédent ou d’un reset incomplet. Ça arrive fréquemment quand on switch entre configs, mais c’est réparable sans tout recommencer. Voici la séquence exacte pour tout remettre d’aplomb, pas à pas, en évitant les conflits. D’abord, assure-toi que rien ne touche au dongle : supprime toute intégration ZHA existante (si résidu), et arrête l’add-on Silicon Labs Multiprotocol via son onglet (bouton Stop). Débranche physiquement le dongle USB du HA Green, attends 10 secondes, rebranche-le (sur le même port ou un autre pour tester). Redémarre ensuite tout Home Assistant (Paramètres → Système → Redémarrer) ça libère tout verrouillage potentiel sur le port série. Une fois HA redémarré, va dans l’add-on Silicon Labs Multiprotocol : vérifie ta config YAML (device: ton chemin /dev/serial/by-id/… complet, baudrate: 460800, flow_control: false, autoflash_firmware: false pour garder ton flash récent). Enregistre si besoin, puis démarre l’add-on (bouton Start). Surveille les logs : tu devrais voir “Connected to Secondary”, “Secondary Protocol v4”, “Daemon startup was successful”, et les services zigbeed/otbr-agent se lancer sans boucle infinie. Si ça boucle encore sur “unresponsive”, re-flash le firmware Multi-PAN une fois de plus via darkxst.github.io/silabs-firmware-builder (choisis rcp-uart-802154-v4.x.x la plus récente, baud 460800, no flow) – connecte le dongle à un PC pour flasher, puis rebranche sur HA et redémarre l’add-on. Ça reset tout proprement. Maintenant, avec l’add-on qui tourne stable (confirme dans les logs qu’il est “Waiting for client connections” sans erreurs), ajoute ZHA comme suit : Paramètres → Appareils & services → + Ajouter une intégration → Zigbee Home Automation (ZHA). À la fenêtre “Sélectionnez le port série”, choisis “Enter Manually”. Puis, à “Choisissez votre type d’adaptateur Zigbee”, sélectionne “EZSP = Silicon Labs EmberZNet protocol”. Là, à la fenêtre des params du port : NE mets PAS le /dev/serial/by-id/… physique. Au lieu de ça, dans “Chemin d’accès du périphérique série”, saisis exactement : socket://core-silabs-multiprotocol:9999 (c’est le socket virtuel exposé par l’add-on pour Zigbee). Pour la vitesse du port série, laisse par défaut ou mets 115200 (ça n’importe pas vraiment pour un socket, mais EZSP attend souvent ça). Pour le contrôle de flux, choisis “none”. Valide – ZHA devrait se connecter via l’add-on sans toucher au port réel, évitant les conflits. Si ça passe, ZHA va scanner et tu pourras re-pairer tes deux appareils Zigbee (ils perdront leur config précédente, normal après changement de firmware, mais c’est rapide à refaire). Tes ampoules/prises devraient rejoindre sans problème, tant que le canal Zigbee n’interfère pas avec WiFi (vérifie dans ZHA config si besoin). Pour Thread/Matter, une fois ZHA OK, l’intégration OpenThread Border Router devrait pop-up automatiquement (ou ajoute-la manuellement si pas). Les warnings DuaManager dans les logs s’ignorent tant que pas de devices Thread. Si après ces étapes précises tu as encore un échec de connexion sur ZHA ou des boucles dans les logs, copie-moi les 20 dernières lignes des logs de l’add-on après un fresh start – on affinera (peut-être un ajustement baud ou une version firmware spécifique). Mais normalement, avec le socket au lieu du port physique, tout débloque

Hourra ! Super nouvelle que le re-flash ait marché, le dongle répond enfin à CPCd 🎉 Ton add-on Silicon Labs Multiprotocol démarre correctement maintenant : Connected to Secondary → connexion UART OK Secondary Protocol v4 + Secondary CPC v4.3.1 → c'est une version stable et compatible avec la plupart des add-ons HA en 2026 (les problèmes graves venaient souvent de mismatch v5 vs v4 dans les CPCd plus anciens ; ici, tout est aligné, pas d'assert fatal) Daemon startup was successful. Waiting for client connections → le cœur tourne bien zigbeed-socket, zigbeed-tcp lancés otbr-agent lancé (Thread/OpenThread Border Router) et il devient leader de son réseau Thread (Partition ID 0xf53f0a1, rôle leader) Les petits messages "inoffensifs" dans tes logsCannot open file /usr/local/etc/zigbeed.conf : C'est courant et normal dans l'implémentation HA du add-on (zigbeed utilise des params par défaut ou via env vars quand le fichier conf manque ; ça n'empêche pas le fonctionnement de ZHA via socket). Pas besoin de s'inquiéter tant que ZHA se connecte. Les DuaManager----: Failed to perform next registration: NotFound (et parfois InvalidState au début) : Ce sont des warnings bénins au démarrage ou quand aucun dispositif Thread/Matter n'est encore pairé. DUA = Device Unique Address (IPv6 global pour Thread devices). Le Border Router essaie d'enregistrer une adresse unique auprès du Backbone (ton réseau WiFi/Ethernet), mais comme tu n'as pas encore ajouté de device Matter/Thread, il n'y a rien à trouver → il réessaie périodiquement sans bloquer. Une fois que tu ajoutes ton premier device Thread/Matter, ces messages disparaissent (ou deviennent rares). C'est documenté comme normal dans beaucoup de setups OTBR multiprotocole. Prochaines étapes pour tout faire tournerAjoute ZHA (Zigbee) Paramètres → Appareils & services → + Ajouter une intégration → Zigbee Home Automation (ZHA) Quand il demande le radio type : Entrer manuellement Adresse du radio : socket://core-silabs-multiprotocol:9999 (ou tcp://core-silabs-multiprotocol:9999 si socket pose problème) Valide → ZHA devrait se connecter via le multiprotocole, scanner le réseau Zigbee et tu pourras ajouter tes ampoules/prises. Si erreur : vérifie les logs de l'add-on pour voir si zigbeed reçoit la connexion. Pour Thread/Matter L'intégration OpenThread Border Router devrait être auto-découverte (via le discovery envoyé : "Successfully sent discovery information to Home Assistant"). Ajoute Matter (via l'intégration Matter Server si pas déjà installé). Quand tu ajoutes un device Matter sur Thread : utilise ton phone/tablette, il rejoindra automatiquement via OTBR. Les warnings DuaManager s'arrêteront une fois le réseau actif avec devices. Conseils finaux Laisse autoflash_firmware: false dans la config de l'add-on pour garder ton firmware v4 stable. Si tu veux upgrader plus tard : surveille les releases de l'add-on et re-flash avec une version RCP qui match (généralement via darkxst builder pour v4.x ou v5.x quand CPCd sera upgradé). Redémarre HA une fois pour rafraîchir les discoveries si besoin. Tu es vraiment à deux doigts du setup complet multiprotocole ! Ajoute ZHA d'abord, dis-moi ce que ça donne (logs ou succès), et on passe à Matter si tu veux. T'as géré comme un chef, bravo ! 🚀🤗

Super nouvelle : le chemin du device est maintenant correct ! CPCd lit bien /dev/serial/by-id/usb-Itead_Sonoff_Zigbee_3.0_USB_Dongle_Plus_V2_c0b58a3f7f12f0119e580514773d9da9-if00-port0 (c'est le bon ID pour ton Sonoff ZB-Dongle-E V2), le baudrate 460800 est standard, flow control désactivé → tout ça est nickel. Le blocage actuel est clair dans les logs : [2026-01-11T10:11:15.117681Z] Info : Connecting to Secondary... [2026-01-11T10:11:17.117998Z] Info : Failed to connect, secondary seems unresponsiveEt ça boucle. Le "Secondary" = le firmware RCP (Multi-PAN) qui tourne sur le EFR32MG21 de ton dongle. CPCd arrive à ouvrir le port série, mais il n'arrive pas à communiquer avec le firmware → le dongle ne répond pas aux pings/init du protocole CPC. Causes les plus probables en 2026 (avec ton setup)Firmware pas compatible ou mal flashé Le firmware Multi-PAN que tu as flashé (via le site Sonoff) n'est probablement pas à jour ou pas la bonne variante pour la version actuelle de l'add-on (qui utilise CPCd v4.6.1.0 avec RCP Protocol v5). En 2025-2026, Sonoff a sorti des versions MultiPAN V4.6.0+ stables, mais beaucoup d'utilisateurs ont eu exactement ce symptôme avec des firmwares anciens ou Zigbee-only par erreur. Problème de reset/init du chip Le dongle est dans un état "gelé" (souvent après un flash raté ou plusieurs restarts). CPCd fait un reset logiciel, mais parfois ça ne suffit pas. Moins probable : Mauvaise détection hardware flow control (mais tu as false, et le Sonoff E n'en a pas), ou conflit USB. Étapes pour corriger (dans l'ordre recommandé)Étape 1 : Réinitialisation physique simple (souvent magique) Débranche le dongle USB du HA Green. Attends 10-15 secondes. Rebranche-le (essaie un autre port USB si possible). Redémarre l'add-on Silicon Labs Multiprotocol (ou redémarre tout HA Green pour être sûr). Regarde les logs : si toujours "unresponsive", passe à l'étape 2. Étape 2 : Re-flasher le firmware Multi-PAN (solution la plus fiable) Utilise un flasher web récent et compatible 2026 (darkxst est toujours la référence communautaire, même si Sonoff a ses propres outils) : Va sur : https://darkxst.github.io/silabs-firmware-builder/ (ouvre dans Chrome/Edge) Sélectionne ton modèle : Sonoff Zigbee 3.0 USB Dongle Plus V2 (ou E) Choisis rcp-uart-802154- (MultiPAN RCP) – prends la version la plus récente (souvent v4.6.x ou plus haut en 2026) Baudrate : 460800 Hardware flow control : No (désactivé) Connecte le dongle directement à ton PC portable (pas via HA Green), lance le flash (ça prend ~1 min). Une fois flashé : Rebranche sur HA Green Dans l'add-on config : garde autoflash_firmware: false (pour ne pas qu'il réécrase ton nouveau flash) Redémarre l'add-on. Alternativement, si tu préfères l'outil officiel Sonoff : utilise leur SONOFF Dongle Flasher (sur dongle.sonoff.tech ou leur guide récent) et choisis explicitement MultiPAN firmware. Étape 3 : Si toujours pas après re-flash Installe l'add-on Silicon Labs Flasher (si disponible dans ton store HA) pour vérifier/flasher depuis HA directement. Vérifie dans Paramètres → Système → Matériel que le dongle est toujours vu après rebranch. Poste les nouveaux logs si ça boucle encore. Une fois que CPCd dit "Connected to Secondary" puis "Secondary Protocol v5" sans crash → c'est gagné, l'add-on tournera, et tu pourras ajouter ZHA via socket://core-silabs-multiprotocol:9999. C'est un problème très courant avec ces dongles E + multiprotocole, mais 99% du temps résolu par un bon re-flash du bon firmware. Vas-y, flash-le et reviens avec les logs après, on termine ça ensemble ! 💪

Salut @jbron ! Bienvenue dans le monde de la domotique avec Home Assistant, c'est un super choix pour une maison ancienne (et c'est souvent plus fun que de rester sur Alexa + ampoules connectées). Le message d'erreur que tu vois : "Missing required option 'device' in Silicon Labs Multiprotocol" est très classique avec le add-on Silicon Labs Multiprotocol sur Home Assistant Green. Ça veut dire que le module complémentaire ne sait pas sur quel port série (USB) il doit parler avec ton dongle Sonoff ZB-Dongle-E. Pourquoi ça arrive ?Home Assistant Green est un peu particulier : les dongles USB ne sont pas toujours montés automatiquement sous /dev/ttyUSB0 (ou autre nom fixe). Le add-on attend explicitement que tu lui indiques le chemin du device dans sa configuration. Étape par étape pour corriger çaLe problème vient du fait que le add-on Silicon Labs Multiprotocol exige maintenant explicitement le champ device dans sa configuration YAML (c'était déjà le cas avant, mais sur HA Green c'est souvent oublié car l'auto-détection n'est pas toujours parfaite). Voici la marche à suivre précise pour corriger ça rapidement : Va dans Paramètres → Add-ons → Silicon Labs Multiprotocol → Configuration Active le mode YAML (bouton en haut à droite si ce n'est pas déjà fait) et assure-toi que ça ressemble à ça : device: /dev/ttyUSB0 # ou mieux : le chemin by-id complet (voir ci-dessous) baudrate: 460800 flow_control: false autoflash_firmware: true # ou false si tu préfères gérer toi-même Le plus fiable sur HA Green : utilise le chemin stable /dev/serial/by-id/ Pour le trouver : Paramètres → Système → Matériel Descends jusqu'à "Ports série" ou clique sur "Tout le matériel" Cherche l'entrée qui mentionne Silicon Labs, Sonoff Zigbee 3.0 USB Dongle Plus ou EFR32 Copie le chemin complet genre : /dev/serial/by-id/usb-Silicon_Labs_CP210x_USB_to_UART_Bridge_Controller_0001-if00-port0 (le nom exact varie mais commence toujours par usb-Silicon_Labs_... ou usb-Itead_Sonoff_...) Colle ce chemin dans device: et enregistre. Redémarre ensuite l'add-on (bouton Restart). Regarde les logs de l'add-on juste après : tu devrais voir qu'il se connecte au dongle, initialise le multiprotocole et lance à la fois Zigbee + Thread/OpenThread. Une fois que l'add-on tourne bien : Ajoute l'intégration ZHA → choisis Entrer manuellement le radio → mets socket://core-silabs-multiprotocol:9999 (ou tcp:// si socket ne passe pas) Pour Thread/Matter : l'intégration Thread devrait apparaître automatiquement après redémarrage de HA si multiprotocole est OK. Si après ça tu as toujours l'erreur ou un nouveau message dans les logs (genre connexion refusée, baudrate mismatch, firmware pas compatible), copie-moi les 10-15 dernières lignes du journal de l'add-on, je t'aiderai à affiner. Ton Sonoff ZB-Dongle-E avec firmware Multi-PAN récent devrait marcher nickel en 2026 (les versions 4.x.x sont stables maintenant). Courage, t'es à deux clics de tout faire tourner ! Petits conseils bonus pour ton setupUtilise le chemin by-id plutôt que ttyUSB0 → plus stable sur le long terme. Si tu changes de firmware plus tard (ex. : revenir à un firmware Zigbee-only EmberZNet), il faudra refaire la manip flashage. Pour ton Sonoff ZB-Dongle-E, le firmware Multi-PAN le plus récent et stable en ce moment est généralement la série rcp-uart-802154-v4.x.x (460800 baud). Essaie ces étapes et dis-moi si ça démarre correctement ou si tu as un nouveau message d’erreur. On va le faire marcher, t’inquiète ! 😊