J’ai des Woox pour piloter mon arrosage goutte à goutte. Depuis ma clé jusqu’aux Woox la qualité est correcte voire mauvaise - mais ça fonctionne. J’ai rajouté une prise qui fait routeur et du coup la qualité est bonne de la clé à la prise et bonne de la prise aux Woox.
En cas de panne de courant - qui survient admettons pendant l’irrigation - zigbee va t il essayer une route directe vers les Woox quand il faut couper l’eau ? Au-delà du fait que je vais faire des tests, quelle est la théorie zigbee là-dessus ?
En zigbee, les routes ne sont pas aussi dynamique qu’en zwave. En théorie comme vous dites, la route présente avant la coupure est conservée. Donc le passage par le routeur sera la route de base.
Je viens de tester ceci
Lampe buffet est le routeur du store cuisine.
Je retire l’alimentation électrique du routeur ( lampe buffet) et mon store continue à fonctionner malgé qu’il ne soit plus directement lié a ce dernier.
A vérifier chez vous
Alors ici lorsque je n’alimente plus la prise la commande n’atteint plus le Woox et a donné une erreur…
zigbee Erreur exécution de la commande [Terrasse][Woox Palmiers][On] : Erreur lors de la requete : http://127.0.0.1:8089/device/command(PUT), data : {« ieee »:« 54:0f:57:ff:fe:05:94:6c »,« cmd »:[{« endpoint »:1,« cluster »:« on_off »,« command »:« on »,« await »:1}],« allowQueue »:false} erreur : {« state »:« error »,« result »:« [0xfb58:1:0x0006]: Message send failure »,« code »:0}
Au niveau du menu zigbee, la disparition de la prise ne se fait pas immédiatement et le graphique du réseau et des rssi etc est inchangé en tous cas le temps de mon test :
Bon… je vais donc programmer une ou deux commandes AT pour éteindre l’arrosage en plus de la commande normale… ça m’évitera de noyer les plantes en cas d’occurence du problème.
Dans ton cas la perte de routage est logique puisque le réseau n’est pas assez maille pour trouver un chemin alternatif lorsque tu supprimes le seul routeur entre le coordinateur et le end point final.
Dans un réseau Zigbee il devrait y avoir au moins deux routeurs (Zigbee Router) possibles pour chaque End Device (Zigbee End device).
C’est le principe fondateur du zigbee. Ne pas respecter ce principe expose à des dysfonctionnements dont les arrêts de services.
L’extension géométrique du réseau ne peut se faire au détriment de ce principe de base. Il ne faut pas voir ton routeur comme un simple extendeur de portée ou un simple relai de signal.
il te suffit d’ajouter un petit scénario qui sur détection d’interruption du courant via le plugin NUT va suspendre l’irrigation tant que jeedom est encore alimenté
je fais ça pour d’autres utilisations sur des alims pilotées en zwave et ça marche très bien.
Seul solution ajouter des éléments pour améliorer ton maillage et offrir plus de route possible.
Et ne pas mettre les routeurs sur la même ligne électrique pour qu’ils ne tombent pas tous en cas de coupure partielle.
Je m’étais posé la même question, mais sur des modules bluetooth. Ma conclusion c’était que pour n’avoir aucun risque il vaut vraiment mieux prendre un contrôleur à qui on peut envoyer un ordre avec une durée (arrosage pendant x minutes).
Sinon plus simple pour sécuriser à coup sur ton arrosage, tu pourrais utiliser un contacteur temporiser mécanique genre :
Sur celui ci tu mets une tempo dépassent tous tes temps d’arrosage max et même en cas de coupure de courant tu es sur que ton arrosage sera coupé (car fonctionnement mécanique) et si pas de coupure il coupe au delà de ton temps d’arrosage max donc pas de soucis.
Edit : je viens de voir que woox est une chinoiserie sur batterie…
Dans ce cas la ma solution devient usine à gaz mais tu couple le contacteur temporisé avec un module télécommande en bind direct sur ton woox qui te le coupe une fois la tempo finie
Si tu mets près de ton module d’arrosage une tempo mécanique temporisé en Toff ( la tempo se déclenche quand ta bobine n’est plus alimenté, donc coupure de courant) la tempo mécanique qui est en résumé comme le minuteur pour faire cuire un œuf, se declencherai en cas de coupure et viendrai déclencher ton module qui enverrait un off par binding ( donc pas besoin d’avoir de coordinateur branché):
