XAV59213

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)

Patch releases2026.1.1 - January 12Fix Hikvision NVR binary sensors not being detected (@ptarjan - #160254) (hikvision docs) Bump eheimdigital to 1.5.0 (@autinerd - #160312) (eheimdigital docs) Bump ZHA to 0.0.84 (@TheJulianJES - #160440) (zha docs) Bump pyOverkiz to 1.19.4 (@iMicknl - #160457) (overkiz docs) Fix JSON serialization of time objects in anthropic tool results (@dcermak - #160459) (anthropic docs) Add asyncio-level timeout to Backblaze B2 uploads (@ElCruncharino - #160468) (backblaze_b2 docs) Fix Requirement parsing in RequirementsManager (@epenet - #160485) Add Nettleie optimization option (@osohotwateriot - #160494) (osoenergy docs) Bump python-otbr-api to 2.7.1 (@emontnemery - #160496) (thread docs) (otbr docs) fix rain sensor for some rare velux windows (@wollew - #160504) (velux docs) Fix trigger selectors (@bramkragten - #160519) (climate docs) (light docs) (humidifier docs) Bump Intergas Incomfort-client to v0.6.11 (@jbouwh - #160520) (incomfort docs) Revert “Update voluptuous and voluptuous-openapi” (@synesthesiam - #160530) Bump serialx to v0.6.2 (@puddly - #160545) (zha docs) (homeassistant_hardware docs) Catch any migration failures in Teslemetry (@Bre77 - #160549) (teslemetry docs) Fix AttributeError for missing/incomplete health data in Tractive (@bieniu - #160553) (tractive docs) Bump pysilero-vad to 3.1.0 (@synesthesiam - #160554) (assist_pipeline docs) Fix for older Fritzbox models which do not support smarthome triggers (@mib1185 - #160555) (fritzbox docs) Bump google-air-quality-api to 2.1.2 (@Thomas55555 - #160561) (google_air_quality docs) Fix Climate signal in Teslemetry (@Bre77 - #160571) (teslemetry docs) Bump pysma to 1.1.0 (@kellerza - #160583) (sma docs) Bump opower to 0.16.1 (@tronikos - #160588) (opower docs) Fix config flow bug in Tesla Fleet (@Bre77 - #160591) (tesla_fleet docs) Add missing segment speed icons for WLED (@Tommatheussen - #160597) (wled docs) Better handling of ratelimiting from Tibber (@Danielhiversen - #160599) (tibber docs) Change device class to energy_storage for some enphase_envoy battery entities (@catsmanac - #160603) (enphase_envoy docs) Fix Z-Wave creating notification binary sensor for idle state (@MartinHjelmare - #160604) (zwave_js docs) Bump pynintendoparental to 2.3.2 (@pantherale0 - #160626) (nintendo_parental_controls docs) Update frontend to 20260107.1 (@bramkragten - #160644) (frontend docs) Bump pyhik to 0.4.0 (@ptarjan - #160654) (hikvision docs) Bump greeclimate to 2.1.1 (@cmroche - #160683) (gree docs) Bump pysilero-vad to 3.2.0 (@synesthesiam - #160691) (assist_pipeline docs) Revert bthome-ble back to 3.16.0 to fix missing data (@Ernst79 - #160694) (bthome docs) Fix missing key for brew by weight in lamarzocco (@zweckj - #160722) (lamarzocco docs) Bump pytado 0.18.16 (@erwindouna - #160724) (tado docs) Bump python-homewizard-energy to 10.0.1 (@DCSBL - #160736) (homewizard docs) Fix fitbit icon (@joostlek - #160750) (fitbit docs)

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 ! 😊

Tu dois avoir ça en bas de chacune de tes réponses :

Merci @bernhara 🥹

Félicitations 🎉🎈🍾 Oublie pas de clôturer le post😜

C’est le CA qui plante ton z2mqtt Voici celui que tu doit mettre server: mqtt://core-mosquitto À tu configurer ton mosquito en tls ? Vérifiez l’add-on Mosquitto : • Assurez-vous qu’il est en marche (Supervisor > Mosquitto > Start si besoin). • Dans ses logs, regardez s’il y a des erreurs de connexion refusée quand vous essayez de démarrer Z2M. • Si vous avez activé SSL dans Mosquitto (port 8883), il faut générer et placer les certificats corrects dans Z2M (mais je recommande de commencer sans SSL pour simplifier).

Oui mqtt://core-mosquitto Envoie moi ton fichier complet trois petit point modifier en yaml modifie le passe et user pour pas que quelqu’un capte tes infos que je puisse te corriger l’erreur

1 Dans ton module z2mqtt configuration trois petits points modifier en yaml 2 Supprimez la ligne ca: /etc/ssl/mqtt-ca.crt (ou toute référence à un certificat CA si vous n’utilisez pas SSL). Si vous avez d’autres options SSL comme key ou cert, supprimez-les aussi à moins que vous n’ayez configuré Mosquitto avec TLS (ce qui n’est pas le cas par défaut).

Ok 👍

Salut @philou83 , D’après les logs que vous avez partagés, le problème principal semble venir de la configuration MQTT dans Zigbee2MQTT. L’erreur “ENOENT: no such file or directory, open ‘/etc/ssl/mqtt-ca.crt’” indique que Zigbee2MQTT essaie d’ouvrir un fichier de certificat CA pour une connexion SSL/TLS, mais ce fichier n’existe pas. Cela arrive souvent si l’option ca est définie dans la configuration, mais que vous n’utilisez pas de connexion sécurisée (mqtt:// au lieu de mqtts://). De plus, je remarque une petite faute de frappe dans l’URL du broker : c’est “mqtt://core-mosquitto” (avec deux “t” à “mosquitto”), pas “core-mosquito”. Le nom correct pour le broker Mosquitto dans Home Assistant est bien “core-mosquitto”.

De rien, ravi d’aider ! 😊 Allons droit au but sur tes questions concernant la migration vers Home Assistant (HA). Je vais répondre en détail. 1. Récupérer tes appareils SmartLife sans reconfigurer Oui, absolument ,tu peux intégrer la plupart de tes appareils SmartLife (basés sur Tuya) directement dans HA sans les réinitialiser ni les reconfigurer dans l’app SmartLife. L’intégration LocalTuya (disponible via HACS, le store communautaire de HA) permet un contrôle local en scannant ton réseau pour détecter les appareils déjà connectés. Tu auras besoin des clés API Tuya (obtenues via un outil comme Tuya Developer ou un script simple), mais une fois fait, HA prend le relais sans toucher à ta config existante. Si tu gardes SmartLife en parallèle au début, les deux apps coexisteront sans conflit. Pour ton module Yokis/Somfy, ça marchera via l’intégration Overkiz (native à HA), qui supporte les motorisations Somfy comme la Lockyvia. 2. Automatisation du portail : Garder celle de SmartLife ou en créer une nouvelle dans HA ? Les deux sont possibles, mais je recommande fortement de recréer l’automatisation directement dans HA pour plus de fiabilité et de flexibilité. L’automatisation SmartLife “redescendra” partiellement via LocalTuya (tu pourras la déclencher depuis HA), mais elle restera dépendante du cloud Tuya ce qui peut causer des lags ou des ratés si internet plante. Dans HA, tu pourras faire une automatisation locale 100% (basée sur geofencing via l’app HA Companion sur ton iPhone), avec des conditions avancées comme “arrivée + connexion Wi-Fi maison” ou un délai pour la fermeture. C’est plus stable, et tu évites les problèmes aléatoires de SmartLife. Si tu veux tester, commence par importer tes devices, puis duplique l’automatisation dans HA c’est simple via l’interface Automations. 3. Compatibilité HA avec Atlantic Cozytouch Oui, HA est compatible avec Atlantic Cozytouch ! L’intégration officielle passe par Overkiz (native dans HA), qui supporte de nombreux appareils Cozytouch comme les pompes à chaleur ou chauffe-eau Atlantic. Pour les modèles non couverts (comme certains anciens ou spécifiques comme l’Aqueo/Excellia), il y a une intégration custom fiable via HACS : “Atlantic Cozytouch” (de gduteil sur GitHub), qui utilise l’API cloud mais avec un fallback local possible. Ça marche bien pour la plupart des users configure avec tes identifiants Cozytouch, et tu auras contrôle total (températures, modes, etc.) dans HA. Si tu as un modèle précis, vérifie sur le forum HA pour des retours spécifiques. 4. Marques recommandées pour objets connectés avec HA HA est ultra-compatible (plus de 2000 intégrations !), mais priorise les marques avec support local (sans cloud obligatoire) pour éviter les déconnexions. Voici mes recos basées sur fiabilité, prix et intégration en 2026 je vise un mix abordable/avancé, compatible Matter/Zigbee/Z-Wave pour l’avenir : • Lumières : Philips Hue (top pour intégration locale via Hue Bridge, couleurs riches, fiable ; ~20-50€/ampoule). Alternative budget : IKEA Tradfri (Zigbee/Matter, bon marché ~10-20€, excellentes pour automatisations). Ou TP-Link Kasa (Wi-Fi local, dimmable, ~15€). Évite les marques pure cloud si possible. • Caméras : Reolink (local-only via ONVIF/RTSP, excellentes pour surveillance sans abo ; ~50-150€, support Frigate dans HA pour détection AI). Alternative : Amcrest/Dahua (qualité pro, local, ~80€). Pour sans fil : Eufy (batterie/solaire, intégration via HA sans cloud). Évite Nest/Arlo si tu veux du pur local. • Thermostats : Ecobee (intégration locale parfaite, capteurs intelligents, ~150-200€ ; top pour économies d’énergie). Alternative budget : Honeywell T6 Z-Wave (~100€, local via Z-Wave). Ou Meross/Venstar (Wi-Fi local, simples et fiables). • Modules (relais/switches) : Shelly (Wi-Fi local, minuscules pour intégration discrète, ~15-30€ ; excellents pour automatisations avancées). Alternative : Zooz (Z-Wave LR, fiable et bon marché ~20-40€). Pour dimmers : Leviton ou TP-Link Kasa (Matter-compatible). Le HA Green est parfait pour débuter plug-and-play. Si tu migres, installe HA d’abord en test sur un vieux PC/Raspberry pour importer tes devices sans risque. Si besoin de liens ou tutos précis (ex. : config LocalTuya ou autre), dis-moi !

OK, on va y arriver, pas de souci ta patience est aussi impressionnante, et tes logs sont en fait excellents : “Daemon startup was successful. Waiting for client connections” est bien là (juste avant le lancement de zigbeed), et le reste (otbr-agent becoming leader, Backbone Router Primary) confirme que le multiprotocole tourne stable pour Thread. Les warnings DuaManager sont standards et inoffensifs sans devices Matter actifs. Pas de boucles “unresponsive” cette fois, c’est du progrès net ! Puisque le re-flash a remis les choses en ordre, concentrons-nous sur l’échec de connexion ZHA. Le piège ici (et c’est courant en 2026 avec ces setups Sonoff + HA Green) : le socket virtuel pour ZHA via multiprotocole est bien “socket://core-silabs-multiprotocol:9999”, mais l’échec vient souvent d’une variante subtile dans les params lors de l’ajout – baudrate mal matché pour EZSP (le protocole Zigbee), ou un switch à “tcp://” au lieu de “socket://”. HA essaie parfois de valider le socket comme un port série réel, d’où le blocage. Séquence ajustée pour ajouter ZHA sans fail 1. Préparation (pour éviter conflits) • Si tu as déjà une intégration Thread/OpenThread Border Router ou Matter qui pop-up (via le discovery), supprime-la temporairement (Paramètres → Appareils & services → clique sur l’intégration → Supprimer). Ça libère les ressources et évite que OTBR “bloque” le multiprotocole pendant l’ajout ZHA. Tu pourras la ré-ajouter après. • Confirme que l’add-on Silicon Labs Multiprotocol est running et stable (logs comme les tiens, sans erreurs). Ne le stoppe pas. 2. Ajout de ZHA avec params précis • Paramètres → Appareils & services → + Ajouter une intégration → Zigbee Home Automation (ZHA). • À “Sélectionnez le port série” : “Enter Manually”. • À “Choisissez votre type d’adaptateur” : “EZSP = Silicon Labs EmberZNet protocol”. • À la fenêtre “params du port série” : • Chemin d’accès du périphérique série : socket://core-silabs-multiprotocol:9999 (exactement ça si ça fail, essaie la variante tcp://core-silabs-multiprotocol:9999 comme alternative courante en 2026 pour contourner des bugs socket Unix dans HA Green). • Vitesse du port série (baudrate) : 115200 (c’est la valeur standard pour le socket EZSP en multiprotocole, même si ton UART physique est à 460800 ! ne mets pas 460800 ici, c’est un piège fréquent qui cause l’échec). • Contrôle de flux : none. • Valide et attends si ça connecte, ZHA va demander de créer un nouveau réseau Zigbee (choisis “créer un nouveau” si tes anciens devices ne sont plus compatibles post-flash). Si toujours “Échec de connexion” : • Regarde immédiatement les logs de l’add-on Silicon Labs pendant la tentative (tu devrais voir une ligne comme “New client connection using library vX.X.X” pour ep#12 ou similaire, indiquant que ZHA essaie de se connecter via socket). Si rien, ou une erreur comme “ConnectionRefused”, c’est souvent le baudrate ou le protocol mismatch. • Alternative : Essaie baudrate 460800 avec tcp:// (certains firmwares v4 exigent ça pour EZSP). • Poste-moi les logs add-on juste après l’échec (les 10-20 lignes post-tentative), plus le message exact d’erreur ZHA si plus détaillé (parfois c’est “ConnectionRefusedError” ou “serial protocol error”). Une fois ZHA connecté, re-paire tes deux appareils Zigbee (ils rejoindront vite), et ré-ajoute Thread/Matter le multiprotocole gérera les deux sans souci. Si le re-flash change rien (inutile si logs déjà bons), saute-le et focus sur ces tweaks baud/protocol. Croisons les doigts ensemble 🤞 teste ça et reviens avec les résultats🤓

Bonjour @Aurel Ravi de te voir revenir aux forums ,c’est sympa de bricoler un peu de domotique pour ajouter du confort à la maison. Ton projet de projecteur extérieur avec détection de mouvement, pilotable via interrupteur et domotique, sans ajouter de fils, est un bon premier pas. C’est simple, scalable, et ça permet d’étendre ensuite à d’autres éclairages. Je vais donner mon avis, des critiques constructives, et répondre à tes questions spécifiques basées sur ce que j’ai pu vérifier. Avis général sur ton setup proposé Ton idée avec un projecteur contrôlé en parallèle par un détecteur PIR filaire classique et un relais Zigbee (comme le SONOFF ZBMINIR2) est solide. Ça permet : • Une détection autonome via le PIR (pas de dépendance au réseau pour l’allumage basique). • Un contrôle manuel via un interrupteur Zigbee intérieur (qui pilote le relais). • Une intégration domotique pour des automatisations futures (ex: allumage via app ou scénarios). Avantages : • Pas besoin de tirer de nouveaux câbles, ce qui est parfait pour un retrofit. • Scalable : Tu pourras ajouter d’autres relais ou capteurs Zigbee pour étendre l’éclairage (ex: plusieurs spots synchronisés). • Budget-friendly pour commencer, surtout post-fêtes. Critiques et points d’attention : • Sécurité électrique : Assure-toi que le relais Zigbee est bien dimensionné pour la puissance du projecteur (le ZBMINIR2 gère jusqu’à 10A, ce qui est ok pour la plupart des projecteurs LED extérieurs, mais vérifie la conso). Utilise un boîtier étanche pour l’extérieur et respecte les normes (terre, etc.). Si tu n’es pas à l’aise, fais appel à un électricien pour l’installation. • Fiabilité du PIR filaire : Les PIR classiques sont robustes, mais ils peuvent avoir des faux positifs (animaux, vent). Un capteur Zigbee pourrait le remplacer plus tard pour plus de flexibilité (ex: ajustements via app). • Interrupteur Zigbee : Choisis-en un compatible avec ton hub (ex: Aqara ou SONOFF). Si tu veux un look “classique”, opte pour un modèle sans fil qui se pose sur un mur existant. • Extension future : Pense à la topologie du réseau Zigbee – place des routeurs (comme des prises connectées) pour renforcer le maillage si ton jardin est grand. Globalement, c’est un bon plan pour ne pas louper la première marche. Pas besoin d’un autre thread! Sur le direct binding Zigbee Oui, c’est possible ! Le “direct binding” (ou simplement “binding” en Zigbee) permet à des dispositifs de communiquer directement entre eux sans passer par le hub/coordinateur. C’est une feature du protocole Zigbee pour augmenter la fiabilité : si le hub ou internet plante, les liens directs restent opérationnels. Par exemple, un interrupteur peut contrôler un relais/lumière sans round-trip via le hub, ce qui rend la réponse plus rapide et résiliente. Comment ça marche : • Le hub initie le binding (il “lie” les endpoints des dispositifs). • Une fois lié, les commandes passent en peer-to-peer. • C’est idéal pour ton cas : l’interrupteur Zigbee pourrait binder directement au relais, et un capteur de mouvement Zigbee pourrait binder au projecteur/relais. • Limitations : Pas tous les dispositifs le supportent. Ça marche bien avec des “sources” comme des remotes, boutons ou capteurs (ex: IKEA Tradfri, Philips Hue remotes, certains SONOFF). Pour les “cibles” comme des lumières ou relais, c’est variable certains Aqara ne le font pas, et certains Hue bulbs ont des limites (ex: on/off ok, mais pas couleur). Sources claires : • La doc Zigbee2MQTT explique bien : Tu peux binder via MQTT (ex: lier un interrupteur à un groupe de dispositifs). • Des tutos sur Reddit et Medium montrent des exemples concrets, comme binder un bouton à une ampoule pour un contrôle offline. • Dans Home Assistant (ZHA ou Zigbee2MQTT), c’est intégré via l’interface : Tu sélectionnes “bind” sur le dispositif source vers la cible. Pour le SONOFF ZBMINIR2 spécifiquement : Il supporte le binding, car c’est un relais standard Zigbee 3.0. Des utilisateurs l’ont testé avec Zigbee2MQTT pour binder à des interrupteurs ou capteurs. Ça devrait marcher sans hub, une fois le binding configuré. Si tu ajoutes des capteurs Zigbee, vérifie leur support (ex: via la liste de compatibilité de Zigbee2MQTT). Compatibilité avec Tahoma comme hub temporaire Bonne idée pour démarrer sans gros budget – la Tahoma Switch peut servir de hub Zigbee basique. Cependant : • Pas tous les périphériques Zigbee sont compatibles nativement avec Tahoma (Somfy est sélectif pour éviter les bugs). • Pour le SONOFF ZBMINIR2 : Il est compatible ! Des retours indiquent qu’il fonctionne pour l’ON/OFF. Mais attention : Avec un interrupteur externe, seul un toggle switch (bascule) est supporté, pas un poussoir momentané (à cause de la façon dont Tahoma gère les états). Si tu utilises un interrupteur standard, ça ira. • Direct binding avec Tahoma : Pas nativement supporté dans l’interface Tahoma (c’est plus pour des scénarios simples). Tu devras attendre une box plus avancée comme Home Assistant pour le configurer facilement. • Liste officielle Somfy : Elle inclut des produits comme Izymo, mais pas explicitement SONOFF cependant, des users l’ont intégré via Zigbee générique. Si ça coince, teste avec Zigbee2MQTT sur un PC temporaire pour valider. Pour la box future : Nabu Casa Home Assistant Green vs homeassitant sur Raspberry Les deux sont excellents pour harmoniser tout • Home Assistant Green (Nabu Casa) : Prêt à l’emploi, facile pour un débutant. Grande communauté (50k+ users Zigbee), interface intuitive, automatisations puissantes. Avantages : Mises à jour auto, addon Zigbee2MQTT ou ZHA pour binding facile. Inconvénients : Moins “français” que Jeedom, mais traductions ok. Prix ~150€. Idéal si tu veux du plug-and-play. • Home Assistant sur Raspberry 3 ou 4 : Plus flexible, communauté francophone forte. (RPi + dongle ~150€). Mon conseil : Si tu aimes bidouiller (comme tes sites web), va sur Home Assistant sur Raspberry ou vieux pc

Salut @philou83, Peux tu envoyer les logs du journal de z2mqtt

Salut @wakyky Merci pour tes questions précises ! Je vais répondre point par point 1. Suppression de l’adresse domicile dans SmartLife Non, supprimer uniquement l’adresse domicile (utilisée pour le geofencing) ne devrait pas t’obliger à réinstaller l’ensemble de tes appareils. L’adresse est un paramètre spécifique pour les automatisations basées sur la localisation, et elle est indépendante de la configuration de tes devices (comme ton module Yokis). Tu peux la supprimer et la recréer sans toucher au reste de ta “Home” dans l’app. Attention cependant : si tu supprimes accidentellement la “Home” entière (pas juste l’adresse), là oui, tu perdras tout et devras ré-ajouter les appareils. Pour éviter ça, va précisément dans les paramètres de la Home > Localisation, et supprime seulement l’adresse – pas la Home elle-même. 2. Activer le GPS en haute précision sur iPhone Sur iPhone (iOS 19 ou supérieur en 2026), c’est simple et rapide. Voici les étapes : 1. Ouvre Réglages > Confidentialité et sécurité > Services de localisation. 2. Assure-toi que les Services de localisation sont activés (toggle en vert). 3. Fais défiler jusqu’à l’app SmartLife (ou Tuya), tape dessus. 4. Sous “Autoriser l’accès à la localisation”, choisis Toujours ou Lors de l’utilisation de l’app (pour le geofencing, “Toujours” est recommandé). 5. Active l’option Localisation précise (toggle en vert) – c’est ça qui améliore la précision GPS. Ça utilise le GPS pur, Wi-Fi et cellulaire pour une meilleure précision. Si ton iPhone est en mode économie d’énergie, ça peut réduire la précision – désactive-le temporairement pour tester. 3. Home Assistant (HA) : Installation, fiabilité et compatibilité J’avais mentionné HA comme alternative plus avancée à SmartLife pour des automatisations locales et plus fiables. Voici les détails : • Moyen le plus simple d’installer HA : L’option la plus plug-and-play en 2026 est d’acheter le Home Assistant Green (environ 100-150 €), un petit boîtier prêt à l’emploi avec HA OS préinstallé. Tu le branches, tu le connectes à ton réseau, et c’est parti en 5-10 minutes via l’app mobile ou le navigateur. Sinon, sur un Raspberry Pi 4/5 (avec SSD pour la vitesse), télécharge HA OS depuis le site officiel, flash-le sur une carte SD/USB avec un outil comme Raspberry Pi Imager, et boot dessus – ça prend 15-20 minutes max. Pas besoin de compétences avancées ; l’interface web guide tout. Évite les installations complexes comme Docker si tu débutes. • Est-ce vraiment plus fiable que SmartLife ? Oui, globalement bien plus fiable pour plusieurs raisons : HA fonctionne localement (pas besoin d’internet pour contrôler tes appareils une fois configurés), ce qui évite les lags, déconnexions cloud ou pannes serveur comme avec SmartLife/Tuya. Les automatisations sont ultra-personnalisables (ex. : geofencing plus précis via ton téléphone ou capteurs), et il y a moins de dépendance à des serveurs distants. SmartLife est pratique pour débuter, mais HA est plus stable à long terme, surtout si tu as beaucoup d’appareils. Des utilisateurs rapportent des réponses quasi-instantanées avec HA vs des délais sur SmartLife. • Compatibilité avec tes appareils (Yokis sur Somfy Lockyvia) : Oui, la plupart seront compatibles via des intégrations dédiées. Pour ton module Yokis (souvent basé sur Tuya), HA a l’intégration LocalTuya qui permet un contrôle local sans cloud – super fiable. Pour Somfy Lockyvia, c’est via l’intégration Overkiz (qui supporte Somfy nativement, y compris les motorisations de portail). Si tu as un hub Somfy (comme TaHoma), active le mode développeur pour une connexion locale. Tes autres appareils SmartLife/Tuya migreront facilement – tu pourras même garder SmartLife en parallèle au début.

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

Salut @wakyky Désoler je n'avait pas activer M’avertir lorsqu’une réponse est postée.🫣 Merci pour ces précisions ! On va essayer de résoudre tes deux points un par un, en se basant sur le fonctionnement typique des modules Yokis/Tuya/SmartLife pour une motorisation de portail comme la Somfy Lockyvia (qui est généralement commandée par impulsion sèche). 1. Le paramètre « Relay Status » (ON / OFF / Remember last status)Ce paramètre définit le comportement du relais après une coupure de courant (ou remise sous tension du module). Pour une motorisation de portail/garage commandée par impulsion (comme presque toutes les Somfy), il faut absolument choisir « Remember last status » (mémoriser le dernier état). Voici pourquoi : Le portail n'a pas de position « ON » ou « OFF » permanente, c'est une impulsion courte qui déclenche l'ouverture ou la fermeture. Si tu mets « ON », le relais resterait collé après une coupure → risque de déclencher en boucle ou de griller quelque chose. Si tu mets « OFF », le relais serait ouvert → pas de souci immédiat, mais pas logique. Avec « Remember last status », le relais revient à l'état inactif (ouvert) après la coupure, ce qui est le comportement le plus sûr et le plus adapté pour ce type d'usage. → Ma recommandation : positionne-le sur Remember last status. 2. Problème de localisation GPS dans SmartLife (adresse décalée de ~300 m une fois enregistrée)C'est un problème assez fréquent avec SmartLife/Tuya, surtout en zone résidentielle ou péri-urbaine. Le décalage vient souvent de : Une imprécision du GPS au moment de l'enregistrement (bâtiments, arbres, voiture...). Une correction automatique par les serveurs Tuya qui "snap" sur une adresse approximative. Le mode de localisation du téléphone (mode économie d'énergie qui utilise plus le Wi-Fi/cellulaire que le vrai GPS). Solutions à essayer dans l'ordre : Supprime complètement l'adresse domicile actuelle dans SmartLife (dans les paramètres Maison / Home → éditer la localisation). Va physiquement au milieu de ton entrée/portail, téléphone en main, avec : GPS activé en mode haute précision (Paramètres → Localisation → Mode haute précision). Mode avion OFF, données mobiles + Wi-Fi activés. Attends 1-2 minutes que le GPS se stabilise très bien (tu peux ouvrir Google Maps pour vérifier que tu es pile au bon endroit). Recrée l'adresse domicile en pointant manuellement le plus précisément possible sur la carte (tu peux souvent déplacer le pin). Si ça persiste, beaucoup d'utilisateurs règlent un rayon de géolocalisation un peu plus grand (ex. : 200-300 m au lieu de 50-100 m) pour compenser le décalage et rendre le déclenchement plus fiable. Vérifie aussi que SmartLife a l'autorisation de localisation « Tout le temps » (paramètres téléphone → Applications → SmartLife → Localisation). Le geofencing SmartLife reste malheureusement assez aléatoire (délais parfois longs, ratés occasionnels), même quand l'adresse est bonne. C'est une limite connue de l'app. 3. Automatisation pour fermer le portail une fois le véhicule stationné (sans cellules/capteurs)Sans capteur physique (détecteur de présence voiture, contact fin de course, etc.), c'est très compliqué de faire ça de manière fiable et sûre uniquement avec SmartLife. Les options réalistes (et leurs limites) : Solution la plus simple et courante : ajouter un délai fixe après l'arrivée Exemple d'automatisation : Déclencheur : Arrivée à domicile (geofencing) Action 1 : Ouvrir le portail Action 2 : Attendre X minutes (ex. 3 à 5 min, le temps de rentrer et se garer) Action 3 : Fermer le portail → C'est ce que font la majorité des gens sans capteur. Pas parfait, mais pragmatique. Variante un peu plus fine : utiliser une seconde condition sur ton téléphone Exemple : arrivée + « téléphone connecté au Wi-Fi de la maison » (ou Bluetooth si tu as un détecteur compatible) → mais ça reste approximatif. La vraie solution fiable (recommandée si tu veux vraiment éviter les oublis) : ajouter un capteur de présence voiture (PIR extérieur robuste + IP65, compatible Tuya/SmartLife Zigbee ou Wi-Fi) pointé sur l'emplacement parking. Tu pourras alors faire : Arrivée → ouvrir Présence voiture détectée + délai 1-2 min sans mouvement → fermer Sans capteur supplémentaire, on reste limité au délai fixe (le plus robuste reste 3-4 minutes pour la plupart des gens). N'hésite pas si tu as besoin d'aide pour la formulation exacte des automatisations ou si tu veux tester une capture d'écran de tes scénarios actuels. Bon courage, et prudence avec le portail ! 🚗🚪

Il y a des projets qui arrivent au bon moment. Vous savez, ces moments où on regarde son dashboard Home Assistant, on voit qu’il fait parfaitement le job, mais on se dit quand même qu’il manque un petit quelque chose. Ce petit truc qui transforme un tableau de bord utilitaire en véritable interface vivante, agréable à consulter même quand on n’a pas spécialement besoin de piloter quoi que ce soit. C’est exactement ce que j’ai ressenti quand je suis tombé sur HA-Animated-cards, grâce à un tip d’un pote du forum qui m’avait dit « tu vas voir, c’est con mais c’est génial ». Il avait raison. J’utilise Home Assistant depuis assez longtemps pour avoir connu les phases successives : le dashboard tout moche en yaml brut, puis les premiers thèmes sombres qui donnaient déjà meilleure mine, les cartes Mushroom qui ont vraiment fait basculer pas mal d’entre nous vers quelque chose de plus propre et moderne, les mini-graph-card pour visualiser les tendances sans se prendre la tête… Et puis arrive un jour où on se dit que ça reste quand même assez statique. Une icône d’ampoule qui reste figée quand la lumière est allumée, un ventilateur dont les pales ne bougent jamais, un lave-linge qui affiche « On » sans qu’on voie le tambour tourner. C’est fonctionnel, mais ça manque de vie. HA-Animated-cards de Anashost change ça avec une collection impressionnante de 67 cartes animées, toutes basées sur des animations SVG très bien fichues. On parle ici de vraies petites animations subtiles et contextuelles : le lave-linge qui fait tourner son tambour avec des bulles quand il est en cycle, le ventilateur dont les pales tournent vraiment (et même à vitesse variable si vous couplez avec un capteur), la cheminée qui crépite doucement, les pales de l’aspirateur robot qui bougent, le projecteur qui s’allume avec son faisceau, la serrure qui se verrouille/déverrouille en animation fluide… Il y en a pour quasiment tous les usages qu’on rencontre dans une installation domotique un peu complète : prises intelligentes, rubans LED, capteurs environnementaux (température, humidité, qualité de l’air avec des halos respirants), mais aussi des trucs plus fun comme les setups gaming, PC/serveur, Nintendo Switch ou horloge Awtrix. Ce qui m’a vraiment plu, c’est que l’auteur n’a pas fait dans le bling-bling tape-à-l’œil. Les animations sont discrètes, élégantes, et surtout parfaitement intégrées au style Mushroom que beaucoup d’entre nous utilisent déjà. Ça ne casse pas l’harmonie du dashboard, ça le sublime. La mise en route est étonnamment simple pour un projet aussi visuel GitHubGitHub - Anashost/HA-Animated-cardsContribute to Anashost/HA-Animated-cards development by creating an account on GitHub.Pas besoin d’installer une custom card dédiée qui va charger des tonnes de javascript. HA-Animated-cards fonctionne uniquement avec du card-mod (pour le style CSS) et la bonne vieille mushroom-entity-card (ou parfois la legacy-template si vous avez besoin d’un peu plus de flexibilité). C’est tout. Concrètement, on va dans le repo GitHub, on choisit la catégorie qui nous intéresse (appliances, environnement, prises, éclairage, etc.), on copie le bloc de code YAML correspondant à l’équipement qu’on veut animer, on le colle dans une carte existante ou une nouvelle, on adapte l’entity (et parfois une entity secondaire si on veut un mode « number » basé sur une valeur numérique comme la puissance consommée), on choisit la couleur d’icône qui nous plaît… et c’est parti. Les premières fois, on passe cinq minutes à comprendre les variables à changer dans le gros bloc card_mod (state_entity, active_value, number_operator, threshold…), mais une fois qu’on a pigé le principe, ça devient très rapide. L’auteur a bien fait les choses : les commentaires dans le code sont clairs, et il y a même des modes différents selon que vous voulez que l’animation se déclenche seulement quand l’appareil est « on », ou en permanence selon une valeur numérique (très pratique pour les ventilateurs ou les variateurs). J’ai commencé par le plus évident chez moi : la carte lave-linge. Voir le tambour qui se met à osciller doucement, à vibrer légèrement puis à prendre de l’ampleur quand le cycle passe en mode essorage, avec ce petit mouvement de balancement réaliste qui imite parfaitement le brassage du linge, ça change vraiment la perception. C’est bête comme chou, mais à chaque fois que je passe devant l’écran mural du salon et que j’aperçois cette petite animation en train de tourner en fond, je souris tout seul. On sent presque le bruit du moteur et les vêtements qui dansent à l’intérieur. Avant, c’était juste une icône mdi:washing-machine figée avec « On » écrit à côté, et même si ça indiquait bien l’état, ça restait froid. Là, l’animation apporte une vraie sensation de vie, surtout quand le cycle est bien lancé : le hublot virtuel semble s’agiter, le corps de la machine tremble subtilement comme sous l’effet des vibrations, et tout ça reste élégant, sans verser dans le cartoon. C’est ce genre de détail discret qui rend le dashboard beaucoup plus attachant au quotidien, et qui fait que même les non-initiés captent instantanément que « ah ouais, ça tourne vraiment là ». Bref, une petite modification de rien du tout qui donne tout de suite plus de personnalité à l’ensemble. Au quotidien, ça change quoi ? Honnêtement, la stabilité est excellente. Pas de saccade, pas de lag visible même sur un dashboard chargé avec une quinzaine de ces cartes animées. Les animations sont légères (SVG pur), donc ça ne plombe pas l’interface, même sur un vieux Raspberry Pi 4 ou une tablette Android un peu fatiguée. La portée « psychologique » est plus importante que ce qu’on pourrait croire. Les membres de la famille qui ne sont pas du tout dans la domotique trouvent soudain le dashboard beaucoup plus intuitif et agréable. Ma femme m’a dit un jour : « ah ouais là on voit direct quand le lave-vaisselle a bientôt fini ». Avant elle regardait surtout le texte, maintenant elle voit l’animation des bulles ralentir progressivement et ça suffit. Côté intégration Home Assistant, rien de particulier à dire : tout se fait en YAML pur dans les dashboards, pas besoin d’intégration HACS spécifique pour le projet lui-même (seulement card-mod en dépendance). Ça reste donc très propre et maintenable. Si vous bidouillez déjà pas mal vos cartes Mushroom, vous serez en terrain connu. Ce qui est vraiment top et ce qu’on aimerait voir évoluer Les points forts sautent aux yeux : le nombre d’animations disponibles (67 et ça continue d’augmenter), la qualité visuelle très cohérente, la discrétion des effets (pas de néons clignotants partout), la facilité relative d’adaptation, et le fait que ça reste gratuit et open-source sous licence Creative Commons, donc modifiable à volonté. Ce qui pourrait être amélioré ? Peut-être un peu plus de documentation sur certains cas avancés (par exemple quand on veut combiner plusieurs conditions pour déclencher l’animation), ou un petit outil en ligne pour générer le code directement en choisissant les entités (mais bon, ça enlèverait une partie du plaisir du bidouillage). Et puis, forcément, on rêve toujours d’encore plus de catégories : des animations pour stores/volets, pour les fontaines d’intérieur, pour les humidificateurs… mais c’est le propre des bons projets communautaires, ça donne envie d’en demander toujours plus. Au final, après plusieurs semaines à l’utiliser tous les jours, je ne reviendrais pas en arrière. Mon dashboard n’est plus juste un outil, il est devenu un petit objet de plaisir visuel. Il reste parfaitement lisible et fonctionnel pour les actions rapides, mais il gagne en personnalité et en chaleur. C’est exactement ce que je recherche dans ce genre de projet : quelque chose qui fait sourire sans sacrifier l’utilité. Si vous êtes comme moi, un peu lassé de votre belle interface trop sage, et que vous avez déjà Mushroom + card-mod en place, je vous conseille vraiment de tester HA-Animated-cards. Pas besoin de tout refaire d’un coup : commencez par trois ou quatre cartes phares (le lave-linge, le ventilateur, une prise intelligente, un capteur de qualité d’air), et vous verrez que vous aurez du mal à vous arrêter là. Bonne bidouille à tous, et comme d’habitude, n’hésitez pas à partager vos propres adaptations en commentaire ou sur le forum. C’est aussi ça qui fait vivre ces projets. 😊

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 ! 💪

Le log que tu partages est très clair : le problème vient du CPCd (le daemon qui gère la communication avec le firmware RCP sur le dongle Silicon Labs). Voici la ligne critique : FATAL system call in function 'driver_uart_open' in file /usr/src/cpc-daemon/driver/driver_uart.c at line #425 : Input/output errorEt juste avant : uart_file = /dev/ttyS0Le add-on Silicon Labs Multiprotocol essaie d'ouvrir /dev/ttyS0 alors que ton dongle Sonoff ZB-Dongle-E est branché en USB et devrait apparaître comme /dev/ttyUSB0 (ou /dev/serial/by-id/...). Solution : Corriger le chemin du port série dans la configurationVa dans Paramètres → Add-ons → Silicon Labs Multiprotocol → Configuration Passe en mode YAML (bouton en haut à droite si ce n'est pas déjà fait) Modifie (ou ajoute) la ligne suivante : device: /dev/ttyUSB0 # OU mieux, le chemin stable : # device: /dev/serial/by-id/usb-Silicon_Labs_xxxxxxxxxxxxxx-if00-port0 # (remplace par le vrai nom – voir étape suivante)Trouver le bon chemin (recommandé) Paramètres → Système → Matériel Cherche dans la section Ports série Tu devrais voir une ligne qui ressemble à : /dev/serial/by-id/usb-Silicon_Labs_CP210x_USB_to_UART_Bridge_Controller_... ou /dev/serial/by-id/usb-Itead_Sonoff_Zigbee_3.0_USB_Dongle_Plus_... Copie exactement ce chemin long et mets-le dans device: Enregistre la configuration Puis Redémarre l'add-on (bouton Restart) Vérifications rapides après redémarrageDans les logs de l'add-on, tu devrais ne plus voir l'erreur Input/output error Tu devrais voir des lignes indiquant que CPCd démarre correctement et que la connexion UART est établie Exemple de configuration complète minimale qui marche bien avec Sonoff ZB-Dongle-Edevice: /dev/serial/by-id/usb-Silicon_Labs_CP210x_USB_to_UART_Bridge_Controller_0001-if00-port0 baudrate: 460800 flow_control: false autoflash_firmware: false # si tu as déjà flashé le bon firmware toi-mêmeSi ça ne marche toujours pas après correctionVérifie ces points : Le dongle est-il bien détecté ? (dans Matériel → Ports série) As-tu plusieurs dongles USB ? Débranche tout le reste pour éviter les conflits es tu mis une rallonge usb ? Le firmware est-il bien Multi-PAN ? (pas un firmware Zigbee-only ou Thread-only) → Si doute, tu peux re-flasher avec le dernier Multi-PAN de Silicon Labs (via le site Sonoff ou directement avec le outil de Silicon Labs) Dis-moi ce que donnent les logs après avoir corrigé le device, on devrait pouvoir avancer rapidement !

Pourquoi ça brick probablement quand tu flashes un YAML ESPHome ?Tu as sûrement utilisé un YAML pour ESP32 / ESP32-S3 générique (ou pour SLZB-06) → l'en-tête du firmware est incompatible avec le bootloader/bootmode du MR4U. Le message que tu vois : invalid header: 0xfE ESP-ROM:esp32s3-20210327 Build:Mar 27 2021 rst:0x7 (TG0WDT_SYS_RST),boot:0x2b (SPI_FAST_FLASH_BOOT)→ C'est typique quand on flash un firmware qui n'est pas fait pour la puce réelle (ou mauvais mode flash, mauvais variant, mauvaise taille de flash, etc.). Le bootloader essaie de démarrer mais détecte un header invalide → watchdog reset en boucle.

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 ! 😊

Salut @benet Non pas encore testé, je vais sûrement le faire la semaine prochaine.