J’ai eu l’opportunité de réaliser récemment 2 installations Jeedom (uniquement pour des amis car je suis en retraite) visant à piloter des vannes thermostatiques Eurotronic Spirit Z-wave+.
Aucun souci avec une première réalisation comprenant 3 de ces vannes dans un petit appartement (résidence secondaire). Tout se passe à merveille et les vannes sont pilotées par une tuile de consignes globales et par le plugin Agenda pour une commutation à heure programmée Chauffage ↔ Eco. Le tout autour d’un RPi 3b+ et Jeedom en V4. Vu cet excellent résultat, je me suis lancé dans du plus compliqué !
Ma 2ème réalisation est nettement plus musclée puisque composée de 15 vannes du même modèle (maison individuelle). J’ai utilisé une Jeedom Smart en V4 elle aussi. Le dispositif de pilotage est similaire à l’autre installation hormis qu’il est répété 4 fois. Les vannes sont regroupées en 4 zones où la température doit être similaire soit les salles de bains (2 vannes), la zone à vivre (7 vannes), la zone au rez-de chaussée (4 vannes) et la zone à chauffage réduit (2 vannes). Une tuile de commande globale par zone et un agenda gère le tout avec des commutations Chauffage – Eco à des heures et des consignes de température adéquates. 2 équipements Z-Wave en plus : un œil Neo Coolcam pour mesurer la température au milieu de la véranda et un répéteur Aeotec Z-Wave+ Range Extender 7 pour mieux propager le signal entre les 2 étages de la maison. Rien d’autre !
Vu le nombre de vannes, l’installation a été mise en service progressivement. Et avec l’augmentation des vannes pilotées, j’ai constaté que parfois des ordres de commutation Chauffage <–> Eco ne s’exécutaient pas à chaque fois sur certaines vannes. Et pas toujours sur les mêmes vannes ! C’est sur ces constats que j’ai ajouté le répéteur Aeotec. Il a amélioré les choses mais des ordres se perdaient encore.
Aujourd’hui, l’installation fonctionne correctement mais j’ai dû fixer des heures de commutation légèrement différentes entre les 4 zones (5 minutes d’écart). En plus, j’ai ajouté plusieurs scénarios pour vérifier après 2 minutes que tout ordre envoyé avait été exécuté par la vanne concernée. En cas de différence consigne – info dans la vanne, l’ordre est répété une fois. En résumé, il est impossible d’envoyer un ordre vers les 15 vannes « simultanément » car il n’aboutit jamais à 100% dans les vannes (bien évidemment un message z-wave est nécessaire à chaque vanne) ! Et le plugin z-wave ne signale rien comme cela peut se passer avec d’autres équipements lorsqu’ils ne quittancent pas un message envoyé (« Death » par exemple).
La table de routage, la santé et le graphique du réseau ne montrent rien de spécial. Le répéteur fait correctement son job. Et même après avoir soigné le réseau, mon dispositif de répétition éventuelle de chaque ordre demeure nécessaire. Cela me laisse penser que le problème n’est pas dans le protocole domotique mais bien dans la vanne…. Erreur de jugement de ma part ?
Ma question : suis-je le seul à avoir constaté ce problème ? Une solution ?
Bonjour,
Donc 15 modules sur batterie, pour un (plus le contrôleur) sur secteur ?
Ma question : est ce que toutes les vannes sont à portée directe (quelques mètres) de soit le contrôleur soit l’extender ?
Si pas, il ne faut pas chercher plus loin je pense, les vannes supportent le flirs mais je ne pense pas que cela permet le routage mais uniquement de recevoir l’ordre pour elle même immédiatement.
Exact, une Jeedom Smart, 15 vannes + un oeil Neo sur piles et un répéteur Aeotec sur secteur. C’est une maison de 10m sur 25m environ avec un rez-de chaussée et un étage. La Jeedom est « au milieu » des 11 vannes du 1er étage et le répéteur a été placé au rez-de-chaussée juste au dessous de la Jeedom. Il y a environ 8 mètres au maximum entre la Jeedom et la vanne la plus éloignée du 1er étage. Même chose pour la position du répéteur et les 4 vannes du rez.
Hello,
J’ai fait le même constat que Phillou53, également avec des vannes Eurotronic SPIRITZ. J’ai des similitudes et des nuances néanmoins.
J’ai une zone commandée par une tuile (plugin thermostat chaudière), avec 3 vannes, soit 2 popp et 1 eurotronic.
Et de temps à autres, la vanne eurotronic de cette zone est oubliée. Je dois préciser que cette zone est à proximité du contrôleur z-wave et qu’il y a également à proximité trois modules Fibaro (dimmer) pour contrôler l’éclairage qui font aussi office de répétiteur.
J’ai également plusieurs autres vannes eurotronic, mais qui sont en mode plus individuel (1 vanne, 1 pièce), dans des chambres, salles de bain et un bureau. Je n’ai jamais constaté ce problème sur ces vannes. J’ai un jour interverti mes vannes eurotronic pour exclure un défaut dans le vanne de la zone de chauffe groupée, mais le problème a continuer à se poser avec l’autre vanne.
J’ai également un plug in agenda qui bascule en mode éco lors des absences programmées.
Je dois avouer que la fréquence à laquelle le problème se pose est relativement faible. J’ai pris l’habitude de contrôler régulièrement la vanne concernée, et je constate un souci peut-être une fois par mois, voire moins.
Par contre, je retiens l’idée d’un scénario pour vérifier si la commande a bien été intégrée.
Je le fais avec des box RPi. Avec la Jeedom Smart, le contrôleur z-wave est à l’intérieur du boitier et seule l’antenne est extérieure. J’ai justement choisi ce hardware Smart car le signal z-wave est meilleur qu’avec une clé z-wave Aeotec !
Sais tu si le problème set produit avec les mêmes vannes out c’est aléatoires?
On voit qu’effectivement certains noeuds on une (très) mauvaise latence; si c’est sur ceux là que cela se pose le plus souvent, c’est la même piste.
Et 8m c’est pas rien, les murs et entre sol c’est quoi ? Brique et béton ou plus léger ?
La plupart des vannes sont à vue de la Jeedom. Pour 3 d’entre elles du 1er étage (salles de bains), il y a un mur en brique entre la vanne et la Jeedom. Béton entre le 1er et le rez d’où le répéteur placé le plus près possible de la Jeedom mais à l’étage au dessous. Mes dernières observations montraient que le problème se passait aléatoirement sur les vannes mais j’ai fait des modifications il y a quelques jours (compteurs de répétition et « sleep » de quelques secondes entre l’envoi des commandes). Donc, il me faut encore un peu de recul pour voir si mes premières observations en sont affectées.
Une question : est-ce possible de remettre à zéro les statistiques de communication Z-Wave car ces chiffres sont perturbés par la mise en service ?
En effet, la relance du démon remet les statiques à zéro (vérifié sur mon RPi de test, Jeedom V4.0.61) mais tu perds la table de routage… Pas d’autre solution moins destructrice ?
Bon il est clair que ton réseau manque cruellement de routeurs (nœuds sur secteur) Trop de capteurs sur pile et le répéteur n’est pas suffisant. Choisis plutôt des wall plugs Z-Wave.que tu vas positionner de manière échelonnée géographiquement entre le coordinateur et les plus éloignées des équipements sur pile.
Ton réseau souffre de goulots d’étranglement lié à ce manque de routeur et pour l’imager ressemble à un arbre avec de grosses branches mais avec un tronc épais comme un brin de paille.
Merci pour vos conseils et j’ai donc commandé un répéteur supplémentaire (Aeotec ZW189, en cours de livraison). Je vous informerai des résultats. A l’heure actuelle, l’espacement de l’envoi des commandes et la répétition de celles-ci (si nécessaire) permettent un fonctionnement correct de l’installation. J’ai aussi introduit des compteurs de répétitions qui ont montré que ces dispositifs logiciels sont actuellement indispensables si l’on veut éviter la perte de commandes. Le réseau a été soigné mais n’est pas fondamentalement meilleur en terme de maillage.
La latence est toujours aussi élevée (de 500ms à 2000ms) sur toutes les vannes, mêmes les plus proches de la Jeedom Smart. Chose étonnante, en envoyant un ping sur une vanne, cette latence devient très correcte (200ms à 300ms), ceci étant le cas pour toutes les vannes, mêmes les plus éloignées. A suivre après l’installation du 2ème répéteur !
bonjour, l’ajout d’un second répéteur a t il amélioré la situation ?
De plus auriez vous remarquer une amélioration de l’autonomie des batteries en même temps ?
Il ne faut pas oublier qu’elles utilisent la fonctionnalité Flirs pour répondre quasi en temps réel alors que ce sont des modules sur piles. Néanmoins, elles ont plus de latence que les modules sur secteur (leur ping est toujours plus mauvais que les autres modules).
Comme je fais de la régulation manuelle avec certaines vannes, les scénarios leurs envoient des ordres toutes 5-10 minutes (ouais, ça fait 1 ou 2 centaines d’ordres par jour, ça bombarde bien). tatistiquement, ce sont celles là qui reportent le plus de dropping command.
Je trouve qu’augmenter la valeur du timeout (4s par défaut) à 8s améliore le de %OK de ces vannes. Avec 2 secondes, c’est le massacre général dans le réseau.
Dans le fichier /var/www/html/plugins/openzwave/resources/openzwaved/config/option.xml modifier la ligne et redémarrer le réseau.
Attention, lorsque certaines commandes sont mal supportées, la queue reste bloquée autant de de temps, soit 8s, ce qui entraîne d’autres problèmes inutilement, comme faire rater un ordre d’un autre module qui n’aurait pas eu de souci si la queue n’était pas bloquée à ce moment là. Autre conséquence, si un module sur pile a 2 commandes non supportées, il perdra 2x8 =16s pour l’interview lors de son réveil, et bien souvent, il n’aura pas le temps de le terminer et se rendormira avant, il lui faudra donc plusieurs réveils. Ce n’est pas dramatique en soi, mais il faut en avoir conscience.
