Mes 10 volets ne se s'actionnent pas en même temps (Zigbee2MQTT)

Bonjour,

J’ai 10 volets roulants connectés en Zigbee via Zigbee2MQTT.

Dans Zigbee2MQTT j’ai fait plusieurs groupes de volets (maison, RDC, étage, derrière)
Dans HA j’ai plusieurs scripts et automatisations qui pilotent ces groupes plutôt que les 10 volets individuellement.

Par contre j’ai un script qui doit obligatoirement piloter les 10 volets individuellement pour gérer des positions intermédiaire de fermeture, qui n’est pas la même pour chaque volet (positions paramétrées via 10 input number).

Ce script appelle 10 scripts un après l’autre pour chaque volet :

alias: Volets - Position Tous
icon: mdi:window-shutter-settings
mode: queued
max: 10
sequence:
  - service: script.volets_position_cuisine
    data: {}
  - service: script.volets_position_salon_terrasse
    data: {}
  - service: script.volets_position_salon_sud
    data: {}
  - service: script.volets_position_salon_ouest
    data: {}
  - service: script.volets_position_chambre_v
    data: {}
  - service: script.volets_position_bureau_c
    data: {}
  - service: script.volets_position_sdb
    data: {}
  - service: script.volets_position_buanderie
    data: {}
  - service: script.volets_position_bureau_a
    data: {}
  - service: script.volets_position_chambre
    data: {}

Et chaque script actionne 1 volet avec le paramètre correspondant :

alias: Volets - Position Cuisine
mode: single
icon: mdi:window-shutter-settings
sequence:
  - service: cover.close_cover
    data: {}
    target:
      device_id: 0a9b7076188365927d96153cc9c26454
  - service: cover.set_cover_position
    target:
      entity_id: cover.volet_cuisine
    data:
      position: "{{ states('input_number.volet_cuisine_pourcentage_entreouvert') | int }}"

Mais quand je déclenche le script global, seuls quelques volets répondent aux actions (4 ou 5, et pas toujours les mêmes j’ai l’impression). Je n’arrive pas à actionner tous les 10 volets …
J’ai déjà essayé tous les modes : parallèle, unique, redémarrage, file d’attente
Mais ça ne change rien …

Quand je déclenche manuellement à la chaine les 10 scripts, via 10 boutons dans une carte, cela fonctionne, les 10 volets s’actionnent dès l’appui.

Quelqu’un aurait une idée ?

Bonsoir

Je pense que sur les 10 messages envoyer il y a de la perte au feu.
Je testerais d’envoyer les messages 2 par 2 par exemple avec 1 seconde d’écart par exemple.

1 « J'aime »

Bonjour,

Avez-vous essayé avec un groupe zigbee dans lequel il y a les 10 volets ?
Il me semble avoir lu qu’il n’y a que par le biais d’un groupe zigbee que l’on peut avoir une bonne synchronisation

Dans ce cas précis je ne peux utiliser un groupe puisque chaque volet a besoin d’un paramètre de position qui lui est propre. Et ça c’est impossible via un groupe.

Il ne reste plus qu’à faire de la gestion par 2 ou 3 volets.
Moins pratique certes mais ça marche et je pense que quelques secondes d’écarts ne va pas mettre en péril la maison :stuck_out_tongue_winking_eye:

J’ai essayé hier, par groupe de 2 volets, puis 2 sec d’attente, mais sans plus de succès :confused:
Faut que je creuse …

Salut alju

Je ne sais pas si cela peut t’aider mais j’ai rencontré le même soucis à l’allumage d’un groupe de 12 ampoules Zigbee via Zigbee2MQTT, comme si les signaux s’envoyaient les uns après les autres, de la première à la douzième ampoule. Leur regroupement via un « Group Helper » n’y changait rien.

J’ai ensuite acquis le dongle Zigbee « SkyConnect » (indépendamment de ce problème) qui m’a poussé à migrer de Z2M vers ZHA. La migration fut plutôt laborieuse mais l’intégration ZHA inclut la possibilité de regrouper des appareils/entités au sein d’un même groupe, ce qui me permet maintenant de les contrôler instantanément.

Autrement dit, la solution à ton problème réside peut-être dans l’utilisation de ZHA plutôt que de Z2M. Cette vidéo pourrait t’aider à la migration (qui reste délicate je trouve et nécessite la plus grande prudence !)

Etant donné que tes 10 volets doivent s’ouvrir selon des % variables. Peut-être pourrais tu agir en deux étapes:

  1. créer un groupe parent contenant les 10 volets pour lancer leur ouverture/fermeture de manière instantanée sans tenir compte d’un quelconque état intermédiaire.
  2. gérer le réglage des positions intermédiaires à travers une automatisation/script comme interrompre tel et tel volet lorsqu’il atteint 50% de fermeture par exemple.

Salut,

Migrer de z2m vers zha ça me semble quand même bien compliqué pour un gain minime. D’autant plus que la liste de matériel supportés, n’est pas du tout équivalente entre les 2.
Mon avis personnel : c’est quand même plus rapide d’ajouter 1 secondes entre les appels pour éviter d’en perdre, comme le suggère @jerome6994 . Comme de toutes façons les positions des volets sont toutes différentes, on est pas à 9 secondes près pour finir les actions.

1 « J'aime »

pourquoi appeler le service close_cover puis le set_cover position ? Logiquement le set_cover position est suffisant non ?

Pour palier un autre soucis :

Si je ferme le volet directement sur une position intermédiaire donnée (disons 10%), à la prochaine ouverture, il ne s’ouvrira pas complètement, mais va s’arrêter avant d’arriver en butée (à peu près 10% aussi).

Ça me faisait déjà ça avant que je ne passe à HA, quand j’avais juste par ma passerelle Tuyau avec l’application Android.

Je pense que c’est inhérent au module de VR que j’ai.
La montée/descente étant gérée par le temps et non pas par butée, je pense que c’est un bug du module (mes modules sont bien calibrés en fonction de la hauteur de chaque volet).

C’est le seul moyen que j’ai trouvé pour ne pas avoir ce soucis à la remontée.

Mais dans le cas de mon script, ça n’a pas vraiment d’importance, puisque mon script principal ferme d’abord tous les volets à 0%, puis seulement après déclenche les scripts individuels pour mettre les différentes positions.
Et comme tous les volets sont déjà en position 0, cette action ne s’exécute pas réellement.

Salut

tu es certain de la dernière affirmation ? A mon avis il n’y a rien coté action sur le volet, mais l’ordre est bien envoyé au module.
Donc ça fait 3 ordres par volet (2 x 0% + 10%) sur 10 volets. Donc 30 ordres envoyés en un temps restreint… ça pourrait quand même bien expliquer la perte de certains d’entre eux

2 « J'aime »

C’est quel modèle tes modules cover ?
Comme sur la majorité des modules le positionnement se base sur le temps, mais vu que le temps de montée est souvent bien plus long que la descente, sur les miens j’ai « triché » en ajoutant quelques secondes au temps de calibration. Les butées mécaniques des moteurs faisant le reste en fin de course.
Ca fausse évidemment le positionnement de mi course et j’ai donc adapté mes auto à 40 % lorsque c’est un positionnement reel à 50 % en descente

C’est ce modèle :

J’ai aussi ajouté quelques secondes pour tenir compte de la remontée plus longue.

Alors je vais l’avouer je ne suis pas remonté tout en haut tu as quoi comme clé Zigbee sur ton z2m ?

J’utilise une Conbee 2

Tout est dit…

Je viens de commenter un post sur z2m et conbee 2 :

En complément, sur le site z2lm il est bien indiqué des pb de pertes de paquets à partir d’une certaine version de firmware

J’ai fais un post sur le sujet z2m et instabilité du réseau.
Sur le site de z2m et dans la documentation des adaptateurs à la rubrique z2m il est indiqué de manière très précise le dernier firmware stable on va dire.

Je suis passé en 15 jours d’un réseau à 15% de pertes de device à 1% c’est clair que c’est le jour et la nuit.