Créer une entité cover avec deux contacts secs

[protobock]

Mon problème

Mon volet roulant est actionné par deux contacts secs:
Un poussoir pour ouvrir ou pour arrêter le volet lorsqu’il est en train de s’ouvrir.
Un poussoir pour fermer ou pour arrêter le volet lorsqu’il est en train de se fermer.

Je le commande à l’aide de deux boutons-poussoirs physiques et également à l’aide d’une télécommande RF qui actionne un boîtier FS20 de chez Conrad. C’est ce boîtier qui joue le rôle de relai entre les poussoirs et les volets (d’où la nécessité de contacts secs).
Ce boîtier est certes un dinosaures mais il fonctionne à merveille et de façon très fiable, indépendamment du wifi, ce qui est essentiel pour assurer le « WAF ». Je désire donc le conserver.

Pour avoir accès à mon store depuis HA, j’utilise actuellement deux canaux en contacts secs en mode poussoir d’un module Sonoff (ou un clone) branchés en parallèle des poussoirs physiques.
Ca fonctionne bien mais je désire créer un modèle d’entité « cover » dans HA à partir de ces deux entités. L’idée est de finir avec trois boutons dans l’interface, comme si j’avais un Shelly 2.5: « Monter » « Stop » « Descendre ».
Malgré de nombreuses recherches, je ne trouve pas de solution idéale. Si j’ai bien compris, la principale difficulté vient du fait que les actionneurs doivent être en mode poussoir. Leur état ne permet donc pas de connaitre l’état du volet (à l’arrêt ou en train de s’ouvrir ou en train de se fermer).

Merci d’avance de votre aide.

Ma configuration

---

System Information

version	core-2023.3.6
installation_type	Home Assistant OS
dev	false
hassio	true
docker	true
user	root
virtualenv	false
python_version	3.10.10
os_name	Linux
os_version	5.15.90
arch	x86_64
timezone	Europe/Zurich
config_dir	/config

Home Assistant Community Store

GitHub API	ok
GitHub Content	ok
GitHub Web	ok
GitHub API Calls Remaining	5000
Installed Version	1.31.0
Stage	running
Available Repositories	1257
Downloaded Repositories	18

Home Assistant Cloud

logged_in	false
can_reach_cert_server	ok
can_reach_cloud_auth	ok
can_reach_cloud	ok

Home Assistant Supervisor

host_os	Home Assistant OS 9.5
update_channel	stable
supervisor_version	supervisor-2023.03.2
agent_version	1.4.1
docker_version	20.10.22
disk_total	228.5 GB
disk_used	18.4 GB
healthy	true
supported	true
board	generic-x86-64
supervisor_api	ok
version_api	ok
installed_addons	File editor (5.5.0), Samba share (10.0.0), Studio Code Server (5.5.5), Mosquitto broker (6.1.3), Home Assistant Google Drive Backup (0.110.3), Zigbee2MQTT (1.30.2-1), Leaf2MQTT (45), Node-RED (14.1.1), Terminal & SSH (9.6.1), Log Viewer (0.14.0), Cloudflared (4.0.14), Simple Scheduler (2.1), ESPHome (2023.3.1)

Dashboards

dashboards	2
resources	10
views	10
mode	storage

Recorder

oldest_recorder_run	1 novembre 2022 à 18:49
current_recorder_run	25 mars 2023 à 11:33
estimated_db_size	8162.89 MiB
database_engine	mysql
database_version	10.11.2

Sonoff

version	3.4.0 (5406fa7)
cloud_online	3 / 6
local_online	3 / 3

---

[Pulpy-Luke]

Hello.

tu dois pouvoir faire ça comme ici. On parle d’un module DIO mais le principe reste le même (on pour ouvrir puis on pour arrêter, et inversement)

Gestion de Volets roulants via module DIO 433Mhz

Mon problème Bonjour à toutes et tous, Je débute avec HA (venant de Jeedom) et je suis en train de réaliser les intégrations de mes équipements avant de passer à la phase gestion et automatisation. J’ai réussi à intégrer et mettre en place mon réseau Zigbee (combee2 avec vm mosquitto et vm Zigbee2mqtt) Je viens basculer mon rfxcom sur HA, c’est ok pour mes sondes Orégons, mais je cale avec la gestion des volets roulant (bubendorff 4 fils tant qu’à faire…) J’utilise des modules CHACON 54754 …

Pour info, l’intégration d’origine n’est plus maintenu mais il y a des solutions

Cover Time Based - Custom Repository

Hello ! Juste pour savoir si certain on déjà trouvé une solution suite à l’arrêt du dépôt de nagyrobi ? [image] Merci à vous

[protobock]

Merci beaucoup @Pulpy-Luke.
J’ai regardé ces liens avec attention et je m’y pencherai plus profondément plus tard dans la semaine.
Ceci dit, il me semble que ça ne fonctionne pas vraiment si on utilise un autre mode de commande en plus de l’intégration proposée. Ce qui est mon cas…

[Pulpy-Luke]

@protobock

Ceci dit, il me semble que ça ne fonctionne pas vraiment si on utilise un autre mode de commande en plus de l’intégration proposée. Ce qui est mon cas…

Tu penses à quoi avec un autre mode de commande… L’intégration fonctionne avec un script. Et dans un script tu peux mettre à peu près tout, y compris des commandes pour SONOFF. On doit même pouvoir balancer les ordres en WIFI directement

[protobock]

@Pulpy-Luke

Tu penses à quoi avec un autre mode de commande… L’intégration fonctionne avec un script. Et dans un script tu peux mettre à peu près tout, y compris des commandes pour SONOFF. On doit même pouvoir balancer les ordres en WIFI directement

Oups, je me suis mal exprimé.

Oui, je vais faire appel à mes relais sonoff dans le script.

Ce que je voulais dire, c’est que l’état « ouverture » ou « fermeture » est perdu si on actionne le volet à l’aide d’un des poussoirs physiques ou avec une télécommande via le module RF déjà installé pendant que le volet s’ouvre ou se ferme après avoir été actionné par le script.

Et le simple fait de l’écrire me fait réaliser que ce cas de figure peut être très facilement évité.
Je vais donc essayer de mettre en oeuvre ta solution dès que possible et je m’en réjouis déjà.

Merci.

[Pulpy-Luke]

@protobock

Ce que je voulais dire, c’est que l’état « ouverture » ou « fermeture » est perdu si on actionne le volet à l’aide d’un des poussoirs physiques ou avec une télécommande via le module RF déjà installé pendant que le volet s’ouvre ou se ferme après avoir été actionné par le script.

Et le simple fait de l’écrire me fait réaliser que ce cas de figure peut être très facilement évité.
Je vais donc essayer de mettre en oeuvre ta solution dès que possible et je m’en réjouis déjà.

Alors ça ressemble à bien ce que j’ai en tête, l’implémentation ci-dessus ce charge justement de se ‹ souvenir › quelle action (ouvrir/fermer) a été fait, pour pouvoir appliquer le ‹ bon › mécanisme d’arrêt.
En complément ça traite l’état du volet opened/closed/closing/opening/position

[protobock]

Ca marche… presque

Si je clique sur « descendre », le volet descend.
Si je clique sur « stop », il s’arrête.
Si je clique sur « monter », il monte.
Jusque là, tout va bien.

Le seul problème, c’est que, lorsque le volet est en train de descendre, le bouton « descendre » de l’interface n’est pas inactivé. Du coup, si je clique dessus, le volet s’arrête. En soi, ça n’est pas bien grave.
Mais si je clique sur « stop » à ce moment, le volet recommence à descendre. Et quand je veux arrêter le volet qui est reparti en descente, je dois cliquer sur « descendre » car le bouton « stop » n’a pas d’effet…

Et c’est pareil avec le bouton montée.

Voici mes scripts:

ouvre_store_3_bis:
  alias: Ouvre le store 3 bis
  sequence:
  - service: switch.turn_on
    data:
      entity_id: switch.sonoff_ouvre_store_3
  - service: input_text.set_value
    target:
      entity_id: input_text.store_3_last
    data:
      value: open
ferme_store_3_bis:
  alias: Ferme le store 3 bis
  sequence:
  - service: switch.turn_on
    data:
      entity_id: switch.sonoff_ferme_store_3
  - service: input_text.set_value
    target:
      entity_id: input_text.store_3_last
    data:
      value: close
stop_store_3_bis:
  alias: Stoppe le store 3 bis
  sequence:
  - service: "{% if is_state('input_text.store_3_last', 'open') %}
      script.ouvre_store_3_bis
      {% elif is_state('input_text.store_3_last', 'close') %}
      script.ferme_store_3_bis
      {% endif %}"
  - service: input_text.set_value
    target:
      entity_id: input_text.store_3_last
    data:
      value: "{% if is_state('input_text.store_3_last', 'open') %}
      stop_open
      {% elif is_state('input_text.store_3_last', 'close') %}
      stop_close
      {% endif %}"

[Pulpy-Luke]

@protobock

Le seul problème, c’est que, lorsque le volet est en train de descendre, le bouton « descendre » de l’interface n’est pas inactivé. Du coup, si je clique dessus, le volet s’arrête. En soi, ça n’est pas bien grave.

ça c’est juste la carte HA de base à changer.
Mushroom par exemple ça marche bien

@protobock

Mais si je clique sur « stop » à ce moment, le volet recommence à descendre. Et quand je veux arrêter le volet qui est reparti en descente, je dois cliquer sur « descendre » car le bouton « stop » n’a pas d’effet…

Là il faut peut-être ajouter un bout pour que le bouton stop ‹ vide › le input_text
Par certain que j’ai testé ce cas d’usage

[protobock]

@Pulpy-Luke

ça c’est juste la carte HA de base à changer.
Mushroom par exemple ça marche bien

C’est pareil avec Mushroom.
La carte HA de base marche parfaitement bien avec mes volets commandés par un Shelly 2.5.

[Pulpy-Luke]

Ici pas de souci…
Quand le volet est Ouvert, je ne peux pas l’ouvrir plus

Quand il est en position intermédiaire, je peux faire les 2

Et quand il est fermé, pas possible de fermé plus.

Et quand il est en mouvement le bouton est grisé (parce qu’il faut passer par un stop)

Et quand il est stoppé, je peux cliquer sur stop autant de fois que je veux, ça ne refait rien…

Ton cover est défini comment ? Notamment les valeurs de temps de montée/descente ?
C’est bien ce nouveau volet que tu mets dans la carte ?
Reprends l’exemple complet plus haut dans l’autre fil, si tu veux

[protobock]

@Pulpy-Luke

Ton cover est défini comment ?

Voici mon entrée dans le fichier covers.yaml:

- platform: cover_rf_time_based
  devices:
    store_3_bis:
      name: "Store 3 bis"
      travelling_time_up: 57
      travelling_time_down: 55
      close_script_entity_id: script.ferme_store_3_bis
      stop_script_entity_id: script.stop_store_3_bis
      open_script_entity_id: script.ouvre_store_3_bis
      send_stop_at_ends: False

@Pulpy-Luke

C’est bien ce nouveau volet que tu mets dans la carte ?

Oui. J’ai d’ailleurs essayé avec un autre (commandé par Shelly 2.5) et tout est alors parfait.

[Pulpy-Luke]

Je ne sais pas, ça marche impéccablement ici…
Essaye ça à la place de ton script stop

stop_store_3_bis:
  alias: Stoppe le store 3 bis
  sequence:
  - if:
      - condition: template
        value_template: "{{ not is_state('input_text.store_3_last', '') }}"
    then:
      - service: "{% if is_state('input_text.store_3_last', 'open') %}
          script.ouvre_store_3_bis
          {% elif is_state('input_text.store_3_last', 'close') %}
          script.ferme_store_3_bis
          {% endif %}"
      - service: input_text.set_value
        target:
          entity_id: input_text.store_3_last
        data:
          value: ""

[protobock]

Un énorme merci pour ton aide.
Malheureusement, ça ne change rien.

Tout vient du fait que les boutons ouvrir et fermer restent actifs sur l’interface utilisateur lorsque le volet est en train de s’ouvrir, respectivement de se fermer.
J’ai remarqué que si j’appuie sur « ouvrir » quand le volet est déjà en train de s’ouvrir, le volet s’arrête mais le input_text.store_3_last reste sur « open », ce qui crée la pagaille par la suite.

C’est quand même bizarre, cette histoire de bouton qui reste actif.
Si j’ai bien compris, la seule différence entre ton cas et le mien, c’est que toi tu as un switch que tu mets sur « on » pour ouvrir et sur « off » pour fermer alors que moi j’ai deux poussoirs à impulsion, un pour ouvrir et un pour fermer.

[Pulpy-Luke]

@protobock

C’est quand même bizarre, cette histoire de bouton qui reste actif.
Si j’ai bien compris, la seule différence entre ton cas et le mien, c’est que toi tu as un switch que tu mets sur « on » pour ouvrir et sur « off » pour fermer alors que moi j’ai deux poussoirs à impulsion, un pour ouvrir et un pour fermer.

Ton sonoff gère déjà le mode impulsion ?

Sinon tu peux faire ça à la place du open et du close

ouvre_store_3_bis:
  alias: Ouvre le store 3 bis
  sequence:
  - service: switch.turn_on
    data:
      entity_id: switch.sonoff_ouvre_store_3
  - service: input_text.set_value
    target:
      entity_id: input_text.store_3_last
    data:
      value: open
  - service: switch.turn_off
    data:
      entity_id: switch.sonoff_ouvre_store_3
ferme_store_3_bis:
  alias: Ferme le store 3 bis
  sequence:
  - service: switch.turn_on
    data:
      entity_id: switch.sonoff_ferme_store_3
  - service: input_text.set_value
    target:
      entity_id: input_text.store_3_last
    data:
      value: close
  - service: switch.turn_off
    data:
      entity_id: switch.sonoff_ferme_store_3

Après j’avoue j’ai plus de piste

[protobock]

@Pulpy-Luke

Ton sonoff gère déjà le mode impulsion ?

Oui, il est en mode « inching ». A chaque commande « ON » qu’on lui envoie, il se ferme pendant 0.5 secondes et il se rouvre. C’est une condition nécessaire pour qu’il puisse actionner le vieux relai RF FS20 de chez Conrad.

[Pulpy-Luke]

Et l’état du switch passe bien de off à on puis retour à off dans ha ?

[protobock]

Oui, sans aucun problème.

[protobock]

Une piste:
Ca doit être lié à l’option

always_confident

Si je la règle sur true, alors les flèches de l’interface se comportent normalement (comme chez toi).

Le problème, c’est que je ne peux pas me permettre ce réglage car si le volet est initialement fermé et que je l’ouvre à l’aide du bouton physique, alors HA n’en est pas conscient et la flèche « fermer » reste grisée. Du coup, je ne peux plus utiliser HA pour fermer mon volet.

Il me faudrait une condition intermédiaire: Une des flèche se grise lorsque le volet bouge dans son sens mais les deux flèches restent actives lorsque le store est statique, quelle que soit sa position supposée par HA.

[Pulpy-Luke]

@protobock

Ca doit être lié à l’option

always_confident

Si je la règle sur true, alors les flèches de l’interface se comportent normalement (comme chez toi).

Le problème, c’est que je ne peux pas me permettre ce réglage car si le volet est initialement fermé et que je l’ouvre à l’aide du bouton physique, alors HA n’en est pas conscient et la flèche « fermer » reste grisée. Du coup, je ne peux plus utiliser HA pour fermer mon volet.

J’ai rien setté dans cette option, donc j’utilise la valeur par défaut.
Malgré tout tu n’aura jamais une position réelle sauf à utiliser un capteur physique pour remonter l’info.
Et dans les faits, si effectivement le bouton est grisé sur le volet, rien n’empêche de lancer quand même un ordre de fermeture via la service (c’est ce qui sera de toutes façons fait avec les automatisations, la commande vocale etc).
Avec une gestion automatique le matin (ouverture) et le soir (fermeture), tu sera quand même rarement le cas d’une désyncho possible pendant la journée je pense, non ? Et la resynchro aura lieu le soir.
Par expérience, ‹ on › jouait aussi beaucoup avec les télécommandes, maintenant que c’est pris en charge, c’est beaucoup plus rare.

[protobock]

@Pulpy-Luke

J’ai rien setté dans cette option, donc j’utilise la valeur par défaut.

C’est vraiment bizarre qu’on n’ait pas le même comportement de l’intégration.

@Pulpy-Luke

Par expérience, ‹ on › jouait aussi beaucoup avec les télécommandes, maintenant que c’est pris en charge, c’est beaucoup plus rare.

Chez moi, ce volet n’est pas actionné par automatisation mais exclusivement manuellement (c’est une porte fenêtre).

Je vais encore investiguer un peu autour de l’intégration. Si je ne trouve pas de solution, je pense que je vais réussir à « vivre avec » la situation telle qu’elle est.