Je viens de passer du plugin Hue à Deconz et je constate quelques écarts, particulièrement les lampes avec le pont hue avait un comportement naturel : interrupteur éteint l’info d’état remontée était à 0. Avec le plugin Deconz l’ampoule est vue dans le dernier état ! (donc allumée cad 1).
Voici ce que je suis en train de tester
1/ crée l’information de retour d’état « joignable »
Pour info deconz remonte l’état transmis par la lampe . Si cette dernière est sur un réseau électrique qui est ouvert physiquement par un interrupteur alors son état restera inchangé tant que la lampe ne sera pas de nouveau alimentée électriquement (jusque là rien que du normal) et donc potentiellement incohérent de son dernier état transmis (par exemple si la lampe était allumée avant d’être éteinte physiquement).
Changer sous Jeedom cet état en testant si la lampe est « reachable » pourquoi pas mais pas sur que l’état reachable soit rafraichi assez vite lors du retour a l’état allimenté de la lampe et donc à l’état allumé. Dans ce cas c’est l’incohérence inverse qui se produira (Eteint sur Jeedom alors que Allumé réellement). Pour sur c’est moins pire que le premier cas.
Pour éviter cela il suffit de remplacer les inters physiques par des inters zigbee et de binder les lampes avec ces inters.
Avant
Lampe allumée inter ouvert : lampe vu en arret OK
Lampe allumée inter fermé : lampe vu en marche OK
Lampe allumée inter ouvert (donc lampe éteinte) : lampe vu en allumée NOK
Inter zigbee necessaire
Solution coûteuse et complexe
Après :
Lampe allumée inter ouvert : lampe vu en arret OK
Lampe allumée inter fermé : lampe vu en marche OK
Lampe allumée inter ouvert (donc lampe éteinte) : lampe vu en éteinte OK
Désolé, pas compris ta question.
Et je n’ai pas de zigbee moi donc de toute façon ca ne va rien changer pour moi
En l’occurrence c’est moi qui avait une question: j’avais compris que dans ton cas lorsque l’interrupteur physique était ouvert (circuit ouvert, donc plus de courant), que la lampe / module n’était plus alimentée donc forcément impossible de l’allumée via domotique: il est nécessaire de refermé le circuit via l’interrupteur.
Hors il me semblait qu’avec la solution de @Yves19 il n’y avait se désavantage (qui est un désavantage d’après moi mais c’est mon avis)
Voilà, ce n’était nullement une critique ni pour dire « il faut faire ceci ou cela », juste une réflexion pour donner des idées…
Ben perso une lampe non joignable n’est ni allumé, ni éteinte pour moi, elle est non joignable et peut être allumée comme éteinte.
Ensuite en zigbee, on ne coupe jamais les routeurs. Et tu m’expliques comment tu allumes ta lampe via la domotique si ton inter physique est sur « off » ?
Inter off :
1er raison humaine, ma femme ou mes enfants ont coupé l’interrupteur
2eme raison humaine : personne externe (invité) à coupé l’interrupteur
Dites moi que ça ne vous arrive jamais ?
Il est également possible de forcer l’état à « 2 » (serait un état intermédiaire)
J’ai exactement le même comportement avec une ampoule Lexman Zigbee.
Lorsque l’interrupteur est actionné par erreur, l’ampoule reste vue comme allumée par Jeedom alors qu’elle n’est plus joignable.
Merci SWR pour ton tuto que je vais mettre en application également.
Normal : le dernier état transmis par la lampe ets celui allumé puisque alimentée en directe .
Si tu coupes physiquement son alimentation elle s’éteint puisque plus alimentée mais n’est pour la même cause plus en mesure de transmettre quoi que ce soit. Donc la box domotique reste sur la dernière info reçue à savoir ON.
Tu peux corréler éventuellement cette information d’état à celle de la visibilité de l’équipement sur le réseau pour générer une information composée.
J’illustrais les propos de Yves19 quant à la possibilité de récupérer l’information de visibilité de l’équipement avec le cas de mes ampoules Zigbee.
Il s’agit de l’information « Reachable » qu’on retrouve dans les informations brutes de nombreux périphériques Zigbee (tous ?), information à mettre en Logical ID d’une commande créée tout exprès. Je n’ai pas trouvé cette info en aussi facilement accessible sur mes périphériques Z-Wave.
Mais je ne suis pas non plus un cador des protocoles domotique !
Ai-je répondu à ta question, ou s’agissait-il de préciser la création de cette commande (chez moi « Sous tension ») ?
En zwave, il y a le script de nerchry qui permet de tester le noeud, fonctionne sur tous les périphériques connectés au 220v.Pour les autres, ça semble, plus compliqué, mais l’informatique existe, donc doit être récupérable.
Autrement, c’est le job du plug-in watchdog
J’avais à l’époque commencé à mettre en place des scénarios de surveillance de ces commandes « Sous tension » (comme sur ton premier post, mais sans aller jusqu’à modifier l’état), puis j’ai en effet finalement adopté Watchdog ensuite.
J’ai par période, sur certains périphériques Zigbee, des séries de mini pertes de liaison (qq secondes à qq minutes) qui sont à ce jour encore inexpliquées. Du coup, chez moi Watchdog (avec son délai paramétrable avant d’agir, fixé par exemple à 10 mn) est plus simple que des scénarios de surveillance avec le « reachable » en déclencheur, scénarios qui se lanceraient à chaque mini perte de liaison.
Ces « informations composées » me sont toutefois toujours utiles quand il s’agit par exemple d’allumer une ampoule à partir du dashboard : en un regard, on voit si le périphérique est connecté ou non, et donc si le clic est effectif ou non (quand l’ampoule n’est pas visible !), y compris en cas de mini-coupure pas signalée par Whatchdog.
Quand j’aurai fiabilisé mon réseau Zigbee, je pense remettre tout ça à plat. Ça serait utile .
.