Bonjour,
petit nouveau dans le monde de Home Assistant, après un passage par Domoticz puis Jeedom, je suis confronté à de nouvelles problématiques de performance auxquelles je n’étais pas habitué 
: la multitude de commandes, montée/descentes de volets, extinctions de lumières et appareils multiples, envoyées au moment où l’on change le mode de fonctionnement de la maison (départ/arrivée) surcharge le réseau zwave. J’ai des commandes puis des retours d’état qui se perdent aléatoirement lors de ces grosses sollicitations.
Outre n’envoyer strictement que les commandes zwave nécessaires, je suis passé d’une approche « parallèle », de multiples automations déclenchées par certains triggers communs, à une approche séquentielle : une grosse automation qui lance les commandes zwave espacées d’un délai d’1s.
Je cherche également à encapsuler des automations dans une automation maitresse, qui les enchainerait de manière séquentielle. Apparemment il faut que je creuse du côté des wait_for trigger et autre wait_template: "{{ is_state( automation…
Je vois que beaucoup utilisent des scènes ou des groupes pour effectuer des actions multiples. Il y aurait un paramétrage quelque-part, empêchant de faire trop de choses en même temps dans ces contextes ?
Comment abordez-vous ce genre de problématique ? Un paramétrage zwave ou Home Assistant m’aurait échappé peut-être ?
Salut,
Alors c’est juste un point de vue mais uen grosse automatisation, séquentielle, c’est pas non plus idéal. A gérer c’est compliquer, quand ça plante en plein milieux c’est pénible et si en plus tu ajoutes des wait_for etc, elle prends du temps et les autres actions à coté s’accumulent.
Tu n’as pas indiqué le nombre de choses que tu pilotes, mais j’irai plutôt dans le sens de :
- rationnaliser à max les commandes, à ton retour de vacances, les volets reçoivent 1 ordre chacun au max. Pas plusieurs sinon c’est que l’approche est mauvaise.
- plus les automatisations petites, moins elle trainent, plus tu peux les enchainer
- c’est le dernier ordre qui est important, ouvrir/fermer/ouvrir, ça reviens à ouvrir 1 seule fois, les autres, tu dois pouvoir t’en passer.
- Pour les automatisations, il y a des mécanismes de file d’attente, parallélisme de remplacement
Merci pour ce premier retour.
Le réseau comporte autour de 115 modules, sans souci de maillage mais avec pas mal de trafic.
Je pense faire les choses proprement par rapport aux 3 premiers points, pas d’ordres inutiles (si on est déjà dans la cible on ne fait rien) et pas de yoyo possible (sauf si bien sûr l’utilisateur bidouille mais ce n’est pas le cas ici).
Pour rester sur l’exemple des volets. J’ai des templates qui calculent une hauteur cible par façade selon la température, le soleil etc. , avec une automation par volet pour synchroniser sa hauteur.
En fonction du contexte, tous les volets d’une seule façade peuvent être concernés, et tout se passe bien, mais si tous les volets se synchronisent, le comportement peut devenir aleatoire. En gros 5 volets d’un coup tout fonctionne, mais plus de 10 ça peut coincer…
Bonjour,
J’ai 14 modules volets en zwave qui sont ouverts ou fermés par une seule automatisation et pas de soucis, on voit bien qu’ils se ferment les uns à la suite des autres mais pas plus visible que cela.
Tu enchaînes combien de commande vers tes modules en 1 fois pour avoir des problèmes ?
En gros 14 automations qui lancent 1 commande de fermeture ou d’ouverture.
La commande est effectuée dans 95% des cas et le retour d’état final est bon à 50%…
Pourquoi ne pas regrouper tes volets par groupe : RDC, étage, chambres… et faire une automatisation sous condition, comme ceci par exemple.
alias: Volets - Maison - Ouverture
description: ""
triggers:
- trigger: state
entity_id:
- schedule.planning_jour
from: "off"
to: "on"
conditions:
- condition: state
entity_id: schedule.planning_jour
state: "on"
- condition: state
entity_id: calendar.jours_feries_en_france
state: "off"
- condition: state
entity_id: input_boolean.gestion_volet
state: "on"
- condition: state
entity_id: input_boolean.mode_vacances
state: "off"
actions:
- action: cover.open_cover
data: {}
target:
entity_id:
- cover.volets_rdc
- cover.volets_parents
- cover.volets_etage
- alias: Boys
choose:
- conditions:
- condition: state
entity_id: input_boolean.boys_at_home
state: "off"
sequence:
- action: cover.open_cover
data: {}
target:
device_id: 7567968c663a9cd7b3d797744c2bb7a8
- alias: Enfants
choose:
- conditions:
- condition: state
state: "off"
entity_id: input_boolean.presence_enfants
sequence:
- action: cover.open_cover
data: {}
target:
entity_id: cover.volets_enfants
mode: single
Vue groupe
Vue détaillée par volets
Ca semble être le noeud de mon problème : j’ai l’impression que le résultat est plus instable si on a une multitude de petites automations qui sont succeptibles d’envoyer des commandes zwave en même temps, que d’enchainer des actions dans une automation plus globale (et forcément un peu plus complexe).
Vous confirmez ?
Je pencherais plus pour un maillage réseau pas suffisant. Ta clef est bien sur une rallonge loin d’interférence éventuelle ? Tu utilise quelle clef ? Elle est bien maj avec le dernier firmware ?
Il s’agit d’un contrôleur Zooz ZST39 au dernier firmware sur un hub alimenté.
J’ai une bonne quantité de modules alimentés par secteur, les modules à pile sont principalement en périphérie, pas d’obstacles radio particuliers.
Je jongle actuellement encore avec la VM Jeedom qui comporte la totalité des fonctionnalités que je termine de migrer sur Home Assistant, et avec laquelle je ne parviens pas à saturer le zwave de la sorte. Mon interprétation était que Jeedom était moins réactif que Home Assistant et ralentissait les commandes envoyées au matériel, m’épargnant ces soucis.
Je vais tenter d’ajouter une rallonge USB.
Techniquement Jeedom (si à jour avec les plugins supportés) et Home assistant utilisent le même composant ZwaveJS
Ils sont sur la 9.20 apparemment (en tout cas c’est ce que dis la release note). Donc y a de la marge… Et pas toutes les améliorations de la gestion de la file d’attente.
1 « J'aime »
En regardant de plus près dans les logs, j’ai remarqué qu’un de mes modules inclus en sécurisé génère des erreurs de Security2CCMessageEncapsulation invalid avec des timeouts sur les modules qui tentent de communiquer ensuite dans les contextes de très fort trafic. En le neutralisant, je parviens maintenant à ce que 100% de mes commandes passent, même sans délai d’espacement d’1s 
.
Il reste que lorsque je fais bouger tous les volets, il y en a toujours 2-3 qui ne rafraîchissent pas leur position d’arrivée même si elle est dans la cible, ce qui met en défaut mon mécanisme de débrayage de l’automatisme (à chaque commande je lance un timer de la durée max de déplacement du volet et je fais le point lorsqu’il est écoulé). Est-il possible de forcer le rafraîchissement de la position, puis de s’assurer que ce rafraîchissement s’est vraiment produit dans une automation ? (mes modules sont des Fibaro FGR222)
Après plusieurs séances de reconstruction des routes du maillage zwave (la version plus récente du composant doit jouer, on constate des résultats immédiats) et de l’optimisation des automations (protection contre les répétitions, simplification) j’ai pu stabiliser la situation, merci pour vos pistes.
