Migration Open Zwave vers Zwave JS - Automatisation ne fonctionnent plus

Bonjour à tous,

Je suis nouveau sur le forum et ravi de découvrir une communauté francophone autour de l’univers Home Assistant.

Je possède dans ma maison des volets roulants et BSO (Brise Soleil Orientable) pilotés par des modules QUBINO ZMNHCD.

Vu que Open Zwave n’est plus officiellement maintenu, j’ai récemment migré mon intégration Open Zwave vers Zwave JS. Tous s’est globalement bien passé. Je constate une nette amélioration de la réactivité du réseau Zwave, c’est effectivement environ deux fois plus rapide comme j’ai pu lire dans d’autres topics. Je suis satisfait, j’ai juste eu à renommer mes périphériques et à revoir quelques scripts.

Il me reste par contre un problème à résoudre. Certains de mes scripts ne fonctionnent plus. J’ai un petit script pour mettre mes BSO en position basse mais avec les lattes ouvertes horizontales. Mon module ne pilote pas l’inclinaison tilt, c’est un module volet simple et ça me convenait très bien jusqu’à présent. Du coup, mon script fonctionne en 3 temps, le but est d’arriver en position 8% d’ouverture mais en arrivant depuis le bas sinon les lattes sont fermées :
1- fermer entièrement le volet.
2- attendre que le volet soit fermé
3- remonter à 8% (ce qui correspond à avoir le BSO tout en bas, avec les lattes ouvertes à 180°)

Pour la phase d’attente, j’utilisais le script YAML suivant :

- wait_template: '{{ is_state(''cover.bso_ouest_level_2'', ''closed'') }}'

Cette ligne de script ne fonctionne plus. J’ai remis à jour avec la nouvelle entité :
- wait_template: '{{ is_state(''cover.bso_ouest'', ''closed'') }}'

Mais, ca ne fonctionne toujours pas, comme si le statut ‹ closed › n’existait plus sur mon appareil via la nouvelle intégration Zwave JS.

Auriez-vous une idée pour m’aider ?

Merci beaucoup !

Ma configuration


version core-2021.11.1
installation_type Home Assistant OS
dev false
hassio true
docker true
user root
virtualenv false
python_version 3.9.7
os_name Linux
os_version 5.10.17-v7l
arch armv7l
timezone Europe/Paris
Home Assistant Cloud
logged_in false
can_reach_cert_server ok
can_reach_cloud_auth ok
can_reach_cloud failed to load: timeout
Home Assistant Supervisor
host_os Home Assistant OS 6.6
update_channel stable
supervisor_version supervisor-2021.10.8
docker_version 20.10.8
disk_total 27.8 GB
disk_used 5.5 GB
healthy true
supported true
board rpi4
supervisor_api ok
version_api ok
installed_addons Samba share (9.3.0), Terminal & SSH (9.2.1), File editor (5.3.3), Duck DNS (1.12.5), Let’s Encrypt (4.11.0), Z-Wave JS (0.1.46)
Lovelace
dashboards 1
resources 2
views 3
mode storage

Salut

Tu peux facilement vérifier dans les Outils de développement à partir de son nom

par exemple

Bonjour Pulpy et merci pour ta réponse très rapide.

Je ne connaissais pas cette fonctionnalité des Etats dans Outils de développement, ca m’aide à éclaircir un peu les choses même si je m’arrache encore un peu les cheveux…
Dans le panneau Etats, sur mon entité cover.bso_ouest, l’état passe bien de open à closed en fonction des mouvements.

Par contre, le script ne fonctionne toujours pas. Si je pars d’une position haute, ouverte à 100%, le bso descend et s’arrête à la position 10% finale sans passer par la position 0% et la phase d’attente du statut closed.

Voilà mon script complet qui ne fonctionne.

alias: BSO Ouest 180°
description: ''
trigger: []
condition: []
action:
  - device_id: d669c7c77b0ffa31bb8bf28ad502303f
    domain: cover
    entity_id: cover.bso_ouest
    type: set_position
    position: 0
  - wait_template: "{{ is_state('cover.bso_ouest', 'closed') }}"
    timeout: '30'
  - device_id: d669c7c77b0ffa31bb8bf28ad502303f
    domain: cover
    entity_id: cover.bso_ouest
    type: set_position
    position: 10
mode: queued
max: 10

J’ai également tenté ceci :

- wait_template: '{{ (state_attr(''cover.bso_ouest'', ''current_position'') | int) == 0 }}'

Le résultat est le même. Bizarre non ? D’autres idées pour que cela fonctionne ?

Là c’est la première des deux conditions qui déclenche la suite … donc es-tu sur que 30s c’est assez long pour arriver à 0 (closed) en partant de la position la plus haute ?

Tu peux aussi tester "{{ is_state('cover.bso_ouest', 'closed') }}" dans l’onglet modèle toujours dans les Outils de développement

Bonsoir,

Merci énormément pour tes conseils, ça m’a permis de faire pas mal de tests.

Ce qu’il se passe :
Quand mon BSO est ouvert à 100% (statut open) et que je lance la fermeture : au moment où j’appuie sur le bouton, la current_position passe à 0 et le statut à closed, le temps qu’un premier retour d’état soit envoyé par le module. Quand le retour d’état est arrivé au bout de quelques secondes et que le volet continue sa course vers le bas, le statut repasse à open et la current_position à sa valeur courante (exemple 80 puis se décrémente petit à petit le temps que le volet arrive en bas). Enfin, quand le volet est entièrement fermé, le statut repasse à closed et la current_position à 0. Je comprend maintenant pourquoi la condition du wait_template est validée dès le début du script…

Reste plus qu’à trouver une stratégie pour contourner ce comportement. Une idée ?

En tout cas, merci de ton aide !

Etant donné que le retour d’état prend environ 5 à 6 secondes, une solution qui fonctionne est de rajouter un délai de 8 secondes entre le lancement de la première action et le test de l’état « Closed » :

alias: BSO Ouest 180°
description: ''
trigger: []
condition: []
action:
  - device_id: d669c7c77b0ffa31bb8bf28ad502303f
    domain: cover
    entity_id: cover.bso_ouest
    type: set_position
    position: 0
  - delay:
      hours: 0
      minutes: 0
      seconds: 8
      milliseconds: 0
  - wait_template: "{{ is_state('cover.bso_ouest', 'closed') }}"
  - device_id: d669c7c77b0ffa31bb8bf28ad502303f
    domain: cover
    entity_id: cover.bso_ouest
    type: set_position
    position: 8
mode: queued
max: 10

Ce n’est pas parfait car ça donne un temps incompressible de 8s pour faire le cycle mais ça fonctionne ! Une autre idée ?

Merci encore