Ca fait quasi 1 an que j’avais besoin de cette réponse
cool, ca marche !
Oui, le fait de passer le controleur GPIO d’une smart en SIS me semble bien résoudre le bug du ProtocoleInfo sur les smart.
En tt cas ca a marché pour moi !
Comme ci dessus,
Au passage
- tout à l’heure (post précédant) je n’avais rien dans les logs de zwavejsd ni zwavejs. Comme dit plus haut, je ne sais pas trop où regarder. Alors j’ai regardé ce que dit le tool concernant l’état SIS/SUC. Il dit none pour le Network Role :

A noter aussi, il n’y a pas de commandClass en bas

Ensuite, je fais la manip Set as SIS, comme ci dessus.
Cela change effectivement le Network Role de None à SUC, SIS, NodeIdServerPresent
(nb : j’ai cru un moment que je m’étais trompé en mettant SUC, mais j’ai refait : en mettant SIS, j’ai bien eu « SUC,SIS,NodeIdServerPresent »)
Fermeture du programme, on débranche, on remonte la smart. Elle boote.
Le plugin zwave met du temps à démarrer… suspens… puis c’est le server qui met du temps… encore suspens…
==> Et boom, en 2s, tous les noeuds filaires apparaissent en Complete (évidement ceux radio étaient en ProtocolInfo).
==> la commande d’un noeud filaire a été possible immédiatement.
Pour être sûr, j’ai bien rebooté la box, meme constat. Ca me semble ainsi fonctionnel.
Seul bémol, tout ca s’est fait sur une débian 10, (c’est ma box opérationnelle). Entre autres, la différence avec Débian 11, c’est que je ne peux donc pas mettre à jour mon plugin ZwaveJS ni Mqtt ; ils sont dans l’avant derniere version. Je ne pense pas que ca ait joué un rôle.
Dans un test suivant, je vais passer le controleur présent dans la box smart en debian 10, dans l’autre (celle dont je parlais 2 message ci dessus). J’y avais chargé le backup jeedom, et à défaut de pouvoir recharger le backup nvm, j’aurais le controleur original en SIS. Ca devrait marcher…