Bonjour,
Je suis en train de tester l’intégration des modules zigbee avec une conbee 2 au lieu de passer par une GW Xiaomi.
Petit problème: j’ai l’impression que les retours d’état sont juste… n’importe quoi.
Je m’explique:
1/ j’ai une prise xiaomi qui fonctionne bien
2/ je la déconnecte, j’attends, je me prends bien mon alertes communication timeout que j’ai configuré
3/ je clic sur « power on », et la… Ca me dit « Action exécutée avec succès », et j’ai même le logo qui change comme si c’étai vraiment allumé!
Bonsoir @Yves19,
Désolé, j’ai effectivement omis plusieurs info importantes. J’éspère que tout le nécessaire est la maintenant, mais si besoin de plus je complèterais bien sur!
Alors deja il est déconseillé de débrancher les appareils routeurs.
Ensuite quand tu envois une commande a deconz, celui ci envoit d’abord une commande pour dire que tout est bon via reponse a la requete, du style [{"success":{"/light/4/action/on":false}}].
Ensuite c’est l’appareil en question qui va dire ok j’ai changé d’etat, voici mon etat mais la, deconz previent en utilisant le websocket, un truc du genre 'state': {'reachable': True, 'alert': None, 'bri': 127, 'on': True, 'ct': 535, 'colormode': 'ct'}
Je n’ai jamais regardé le code de jeedom, mais phoscon fonctionne comme cela, en utilisant le retour de la requete, et pas le retour du websocket, Même si tu debranches une lampe, tu pourras faire changer d’état la lampe dans l’interface, même si en réalité rien ne change car lampe non connectée au réseau. Et ce sera comme ça jusqu’à ce que deconz soit sur a 100% que la lampe soit hors réseau.
Ils ont du choisir ce systeme car il est très rare qu’une lampe quitte le réseau.
Et si cela arrive, au moment ou la lampe reviens dans le réseau, elle redonne son état via websocket (donc pas de réponse via http), et phoscon re synchronise le tout.
Je suis bien d’accord qu’il ne faut pas débrancher les routeurs, il s’agit la juste d’un test, une simulation de coupure, perte de signal, ou autre defaut.
Cependant, je veux avoir de la fiabilité (par exemple le soir j’envoie la commande off sur la prise de ma pompe, puis je check l’état de la prise, je veux donc être sur que ma pompe est bien éteinte!).
Sauf erreur de ma part, ca ne fait pas du tout ca en zwave - dois-je en conclure que le zwave est plus fiable ?
Non ca fonctionne pareil, c’est juste un choix des développeurs.
Fais le test, éteints ton plug, débranches le, envois une commande allumage et regarde les « données brutes » du plug (c’est un code JSON), dans « state » tu as marqué quoi comme état ?
Alors je ne sais pas ou on peut voir ces données brutes, mais j’ai fais les actions suivantes:
"éteints ton plug, débranches le, envois une commande allumage .
Ca reste bien en status « off » dans le dashboard, et j’ai le noeud en dead peu de temps après:
Ok je viens de faire le test chez moi, meme le websocket anticipe la réponse, donc pas possible d’avoir la vraie valeur.
Ça n’a rien a voir avec Zigbee / Zwave, les deux fonctionnent pareil, et ont le retour d’état, c’est un choix des développeurs, et la dans ce cas de deconz.
Deconz « anticipe » le changement d’état, avant d’avoir le retour de la lampe.
Ils ont du choisir ce mode pour la rapidité, vu que dans tout les cas le plug va répondre, ou alors tu aurais eu un message comme quoi il etait hors réseau, dans le cas contraire, au prochain report l’appareil renvoi son état qui est mit a jour dans deconz.
Bizarre.
Chez moi j’ai bien la vraie valeur remontée et pas une valeur « anticipée ».
Exemple : j’allume une ampoule deduis Jeedom . Je l’éteins puis la débranche. Je commande de nouveau l’ampoule depuis Jeedom et là son état reste bien éteint avec en plus une alerte d’équipement non joignable . => Jeedom n’anticipe pas l’état commandé.
Exemple 2 : j’allume une ampoule depuis Jeedom. Je coupe l’interrupteur de ladite ampoule. Je commande éteint depuis Jeedom. L’état Jeedom reste à allumé plus erreur de communication remonté par Jeedom => Fonctionnement normal puisque le dernier état renvoyé par l’ampoule était « Allumé », Jeedom n’anticipe pas éteint.
Ça dépend du matériel, pour d’autres, il peux falloir plusieurs minutes avant que deconz voit l’appareil en non joignable (j’ai fais des tests avec ikea). C’est exactement la ou est son probleme, pendant cette période, pour deconz l’appareil est encore la, donc il anticipe les commandes sans avoir de retour pour valider.
Par contre maintenant que tu le dis
je la déconnecte, j’attends, je me prends bien mon alertes communication timeout que j’ai configuré
Du coup si il a un message comme quoi la prise est déconnectée, la je comprend plus …
Yes Philips pour les HUE. Ou sinon ampoule Philips et micromodules ZIgbee Legrand. Dans les deux cas aucune anticipation de Jeedom. C’est bien l’état remonté par les équipements qui est affiché et pas un pseudo état Jeedom.
Le reste c’est des spots encastrés pilotés KNX donc pas de soucis pour ces derniers
Bon je viens de faire le test avec du Ikea → pareil que les modules Xiaomi.
Du coup c’est vraiment con, car si je perd une prise (qui sert de répeteur pour modules ouvertures de porte / mouvement) je ne suis pas alerté que mon alarme ne fonctionnera plus…
Une possibilité de faire du « réveil domotique » en zigbee de la même manière qu’en zwave ?
Ca permettrait a minima de faire passer les modules ouvertures / mouvement en timeout et d’avoir une alerte?
Pour les prises comme il s’agit de modules toujours up je peux rajouter une condition dans les scénarios, mais pas d’idées pour la partie modules sur pile
Assujettir une alarme à un réseau radio c’est déjà pas terrible mais si en plus elle est en relai mesh sur un seul répéteur alors là c’est carrément à revoir.
Je recommande très fortement de bien séparer la domotique de ce qui est sécuritaire (ma maxime :quand on traverse l’Atlantique à pédalo, ce n’est pas le système pour écoper sur lequel on doit se focaliser mais le pédalo).
Oui c’est pas l’idéal, mais la perso je ne peux pas tirer des fils de partout, donc je vais faire au mieux.
Mon but n’est pas d’avoir un seul répeteur bien evidement je vais en mettre plusieurs
Et pas de transformer ce topic en débat sur un topic alarme ou autre
Cependant je veux du monitoring, en l’état actuel je ne suis même pas capable de connaitre l’état de mon réseau, de savoir via quel noeud les hops se font, …
D’ou ma question initiale: Est-ce une limitation du Zigbee ? Des modules Xiaomi/Ikea ? De ma config ? De Jeedom ?
C’est pas une limitation, c’est réalisable, pour ce cas la et uniquement celui la, c’est un choix des dev de deconz. C’est eux qui ont choisit d’envoyer une information disant que la lampe a changé d’état avant que celle ci ne dise qu’elle la vraiment fait.
Dans tout les cas tu seras prévenu si ça ne marche pas, c’est très rapide sur Philips apparemment, beaucoup plus lent sur ikea, par contre pour un capteur sur pile, il peut falloir plus d’une heure pour être sur que la capteur n’est plus la.
Philips marche avec du pooling, la passerelle spamme le réseau aussi vite qu’elle le peut, donc la vérification est très rapide.
Ikea utilise du reporting, c’est toi qui configure la lampe pour donner sont etat tout les X minutes.
Les capteurs Xiaomi passent en veille et ne donnent une info que toutes les heures, Legrand peut passer plusieurs jours en veille.
Bonsoir. À défaut de pouvoir modifier ce comportement (que je connais aussi), j’avais proposé une façon de « faire avec » en Zigbee dans une discussion un peu semblable, mais sur le Z-Wave. Ici :
S’agissant d’une discussion Z-Wave, je n’avais pas développé. La commande créée est très simple :
Le résultat sur le Dashboard est assez visuel pour juger de la fiabilité du retour d’état (ici avec un soufflant sur une prise Zigbee) :
Et s’agissant d’une commande, elle peut-être incorporée dans des scénarios et des tests. Si « hors tension », alors « information de retour d’état pas fiable ».
Autre bug vu aujourd’hui, le module de porte xiaomi est vu en NOK (porte non ouverte depuis 3 jours).
J’ouvre la porte, ca me remonte bien les infos…
Ces comportements aléatoires m’ont bien décidés: zwave, jamais eu ce genre de problème.
Je vais donc garder que les choses non importantes (boutton xiaomi surtout) en zigbee et tout va passer sur un truc qui remonte des vrais état = zwave
EDIT: @HugoVal11 - c’est quoi un OS qui le permette pour la GUI deconz ? Pas possible via jeedom ?
C’est quoi le niveau de batterie du module de porte ? Quand ces modules arrivent en fin de batterie, ils arrêtent le reporting pour économiser les piles, et a mon avis il y a quelque chose qui a du se dire que 3 jours sans aucunes infos, c’est qu’il devait être déconnecté.
Jeedom n’est pas un OS, ce n’est qu’une application, si tu as Jeedom sur Buster avec Desktop (et ça m’entonnerait), ca va te prendre 5 mn pour switcher, dans le cas contraire, je connais le mode d’emploi, certains l’ont deja essayé sur ce forum, mais perso j’ai jamais testé cette méthode, Le X-fowarding > Access deCONZ GUI in headless setups · dresden-elektronik/deconz-rest-plugin Wiki · GitHub
Les infos NOK ou OK de la page du plug in Deconz sont non formelles càd indicatives (je crois que c’est dans la doc)
Ainsi un capteur en mode veille qui économise ses piles sera vu comme NOK. Mais s’il est réveillé par activation ou évolution de ce qu’il surveille alors il repasse de lui même en OK.
Sous Z-wave (j’ai les deux) c’est tout pareil mais en pire pour les modules FLIRS car leur réveil est parfois fort difficile voire impossible.
