Garage Ouvre Toi!

Mon problème

Bonjour,
J’ai investi tout doucement dans du Shelly pour domotiser mon garage.
J’ai installer un module shelly1 pour émettre une impulsion pour ouverture ou fermeture
Et j’ai deux Door/window2 pour savoir si c’est ouvert ou fermé.

Voici le lovelace brute de décoffrage

1/ lovelace,
Je souhaite avoir une vue unique sur l’état.
Ouvert : shelly_garage_ouvert : Fermé, shelly_garage_fermé : Ouvert,
Fermé : shelly_garage_ouvert : Ouvert shelly_garage_fermé : Fermé,
Entre-Ouvert : shelly_garage_ouvert : Ouvert, shelly_garage_fermé : Ouvert,

Bon j’avoue c’est un peu tordu, mais c’est l’idée…

a/ Est ce possible de combiner ces deux information suivant ces conditions pour ne creer qu’une seule vue ?
b/ est ce possible de jouer les attributs suivant les conditions (ex : affichage en rouge si ouvert )

Merci a vous tous.

Hello @lilian76 ,

J’imagine que tu veux faire ce type de chose ?
image

Pour l’interface, le plus simple pour cela est d’utiliser une custom card appelée button-card. Il faut l’installer via le community store.

Ensuite, tu pourra afficher une couleur différente, un logo différent en fonction de l’état de la porte. Tu peux même faire clignoter lors de l’ouverture et la fermeture de la porte.

  - type: 'custom:button-card'
    entity: sensor.etat-porte-garage
    show_state: true
    show_name: false
    layout: icon_state
    state:
      - value: Ouverte
        icon: 'mdi:window-shutter-open'
      - value: Fermée
        icon: 'mdi:window-shutter'
      - value: Entre-ouverte
        icon: 'mdi:window-shutter-alert'
        color: red
      - value: Ouverture...
        icon: 'mdi:window-shutter-open'
        styles:
          card:
            - animation: blink 2s ease infinite
      - value: Fermeture...
        icon: 'mdi:window-shutter'
        styles:
          card:
            - animation: blink 2s ease infinite

Pour ramener l’état de la porte dans une seule entité et l’utilisée dans le button-card, le plus simple est d’utiliser un template sensor.

Puis adapté le code suivant, en testant la valeur de tes 2 capteurs et ton actionneur.

sensor:
  - platform: template
    sensors:
      etat-porte-garage:
        friendly_name: "Etat Porte Garage"
        value_template: >-
          {% if is_state('moncapteur', 'xxx') %}
            ouvert
          {% elif is_state('moncapteur', 'yyy') %}
            fermé
          {% else %}
            entre-ouvert
          {% endif %}

Pour aller plus loin, je rajouterai donc 2 états à ouvert, fermé et entre-ouvert : ouverture… et fermeture…
Pour cela, tu peux créer des boutons qui appel des scripts plutôt que directement des services, et gérer le temps d’ouverture dans les scripts. J’ai rajouté un bouton pour mettre à jour l’état de la porte dans le cas ou tu ne veux pas que le capteur le lise en permanence quand la porte est ouverte ou fermée (la mise à jour de l’état est alors à rajouter dans les scripts).

Voila un exemple de code des boutons qui appellent les scripts :

  - type: horizontal-stack
    cards:
      - type: button
        tap_action:
          action: call-service
          service: script.ouvre_porte
        name: Ouvre
        icon: 'mdi:window-shutter-open'
        icon_height: 30px
      - type: button
        tap_action:
          action: call-service
          service: script.stop_porte
        name: Stop
        icon: 'mdi:stop'
        icon_height: 30px
      - type: button
        tap_action:
          action: call-service
          service: script.ferme_porte
        name: Ferme
        icon: 'mdi:window-shutter'
        icon_height: 30px
      - type: button
        tap_action:
          action: call-service
          service: homeassistant.update_entity
          target:
            entity_id: sensor.porte_etat
        icon_height: 30px
        name: Etat
        icon: 'mdi:sync'

Une alternative est d’utiliser à la place du template sensor et des boutons directement un template cover, fait pour cela. Il permettra à la fois de gérer l’état et appeler les services. Pertinent si le visuel du template cover te convient. Perso, je préfère des boutons dessinés spécifiquement.

Enfin, tu remarquera que l’état de la porte et les boutons sont dans la même carte. Pour cela, je te propose d’utiliser une autre custom card : stack-in-card.

Cette carte s’utilises à la place de vertical-stack, sous laquelle tu aura mis le button card et les boutons, mais permettra de tout avoir dans une seule carte.

type: 'custom:vertical-stack-in-card'
cards:
  - type: 'custom:button-card'
    entity: sensor.etat-porte-garage
    show_state: true
    show_name: false
    layout: icon_state
    state:
      - value: Ouverte
        icon: 'mdi:window-shutter-open'
      - value: Fermée
        icon: 'mdi:window-shutter'
      - value: Entre-ouverte
        icon: 'mdi:window-shutter-alert'
        color: red
      - value: Ouverture...
        icon: 'mdi:window-shutter-open'
        styles:
          card:
            - animation: blink 2s ease infinite
      - value: Fermeture...
        icon: 'mdi:window-shutter'
        styles:
          card:
            - animation: blink 2s ease infinite
  - type: horizontal-stack
    cards:
      - type: button
        tap_action:
          action: call-service
          service: script.ouvre_porte
        name: Ouvre
        icon: 'mdi:window-shutter-open'
        icon_height: 30px
      - type: button
        tap_action:
          action: call-service
          service: script.stop_porte
        name: Stop
        icon: 'mdi:stop'
        icon_height: 30px
      - type: button
        tap_action:
          action: call-service
          service: script.ferme_porte
        name: Ferme
        icon: 'mdi:window-shutter'
        icon_height: 30px
      - type: button
        tap_action:
          action: call-service
          service: homeassistant.update_entity
          target:
            entity_id: sensor.porte_etat
        icon_height: 30px
        name: Etat
        icon: 'mdi:sync'

Je n’ai pas peaufiné et il faudra bien entendu adapter tout ça…
En espérant aider.

1 « J'aime »

Géniale, oui c’est cela !
Merci pour ta réponse très complète.
Je vais étudier ça de prés, je tiens au courant sur ce post :slight_smile:

@Argonaute je vois que dans ta carte lovelace tu as
« Ouvert » « Stop » « Ferme »

Pour ma part je n’ai pas le choix que faire une impulsion avec un shelly1 mais suivant le cas il peux monter ou descendre. je ne pas prédire dans quel sens il va partir.

Tu as la possibilité sur ton moteur de choisir 1 commande = 1 sens ?

Beaucoup de moteur de porte de garage fonctionne sur le principe du « cycle ».

Partons du principe que la porte est fermée, une première impulsion sur le Shelly1 ouvrira la porte. La prochaine impulsion stoppera la montée. La suivante enclenchera la descente… et ainsi de suite.

L’état est donc « prédictible ». Après, comment l’implémenter dans HA, ça c’est autre chose et pour le moment, c’est toujours dans ma todo-list :slight_smile:

Oui prédictible, mais pas véritable !

Il se peux qu’un enfant clique et inverse le sens.

Voici ma bidouille théorique pour palier à ca :
Imaginons je laisse mes deux gosses jouer dehors, il veulent la trotinette. j’ouvre le garage, servez vous…
Je m’en vais lire le forum.hacf.fr tranquil, a mon insu ils s’amuse avec le bouton poussoir de commande (présent a coté de la porte)

Je reçois ma notification a 22h comme quoi la porte du garage est ouvert. je lance une impulsion, il m’est impossible de savoir avec 100% de réussite que ma porte va partir vers le sens de la fermeture… D’ailleurs c’est aussi valable si un objet (genre une trotinette rose) bloque la fermeture et que la porte retour en ouverture (sécurité) … toi tu t’endors tranquil… mais le garage est ouvert.

Donc j’ai pensé que quand je lance une commande de fermeture (je ne sais pas le sens de « partance » réel de ma porte en réalite), je scripte une tempo de 30 seconde qui va consulter mon sensor de fermeture… si c’est OK, on ne fais rien, la porte est alors bien fermé, si c’est le sensor d’ouverture qui est OK, c’est que la porte est soit :
1 Partie dans le mauvaise sens (en ouverture)
2 Dans le bon sens (fermeture) mais bloqué par un objet elle est reparti en ouverture

Alors HA relance une impulsion pour fermer (parce qu’on la on est sur du sens)
Si 30 secondes, après j’ai mon sensors fermer OK alors c’est bon.
Si j’ai toujours mon sensors ouvert c’est qu’il y a un objet qui bloque (ou un enfant … lol )

Tu vois ce que je veux dire par rapport a l’exatitude de l’informations Ouverture ou Fermeture ?
Certains modele de motorisation sont (visiblement) pilotable avec des shelly2.5, comme des volets roulants… l’information de fermeture et d’ouverture est directement accessible.

Effectivement mon code est pour un système permettant de lancer une commande ouvrir, fermer ou stop.
Avec ton portail et le shelly, il est possible de prédire effectivement si on ouvre ou on ferme en connaissant l’état initial, mais sans certitude. Une solution simple serait alors de faire un script qui relance la commande si le capteur indique que la porte est ouverte alors que la commande était supposée l’avoir fermée.

Yes @Argonaute Merci,
Je bosse sur les template, j’arrive a sortir des « trucs » rien de définitif.
A+

Ralala je galere :
Received invalid cover is_on state: entre-ouvert. Expected: open, opening, closed, closing, true, false

Dans le template Jinja impossible de mettre d’autre valeurs que celle indiqué (et encore… )
Je souhaite avoir « ouvert » « fermé » « entre-ouvert »… il doit bien avoir moyen de personnalisé le libellé ?

voici mon code :

cover:
  - platform: template
    covers:
      gestion_garage:
        friendly_name: Garage
        value_template: >-
          {% if is_state('binary_sensor.shelly_garage_fermer_door', 'off') and 
                is_state('binary_sensor.shelly_garage_ouvert_door', 'on') %}
            open
          {% elif is_state('binary_sensor.shelly_garage_fermer_door', 'on') and 
                  is_state('binary_sensor.shelly_garage_ouvert_door', 'off') %}
            closed
          {% else %}
            entre-ouvert
          {% endif %}
        open_cover:
          - service: script.ouvrir_garage
        close_cover:
          - service: script.ouvrir_garage
        stop_cover:
          service: script.ouvrir_garage

Si vous avez une réponse a cette contrainte étrange dite moi.

je répond a ma question .
je suis passer sur un template sensors.

ça m’arrange je pense préférer avoir l’état dans une case.
et avoir deux boutons script séparé « ouvrir » et « fermer » sont garage.
Je suis crevé, je vois ça demain, a bientot

Tu aurais pû mettre opening ou closing comme le l’indique l’interpréteur.

Le libellé c’est la clé friendly_name et non value_template.

Tu utilises une plateforme qui t’indique que la valeur du volet ne peut être que : open, opening, closed, closing, true, false et ce pour des dépendances de code derrière, rien d’étrange :wink: .

C’est l’intégration la plus utilisée lorsque l’on veut être maître de la définition de son entité :+1:

Perso, je serai tenté de créer :

  • un input text pour sauver l’état de la porte (ouvert, fermé, entre-ouvert) ou l’action en cours (ouverture, fermeture)
  • 3 scripts ouvre, ferme, stop, appelés par les boutons, qui envoient le nombre d’impulsions au shelly en fonction de l’état précédent, puis met a jour l’état ou action en cours.
  • 2 automations qui se déclenchent quand les capteurs de butée changent d’état. Si ouverture en cours et capteur ouvert déclenché alors etat = ouvert. Si ouverture en cours et capteur fermé déclenché alors renvoyer au shelly pour relancer l’ouverture.

Dans les scripts ouvre et ferme, il faut rajouter une attente et mettre l’état a entre-ouvert si la porte n’est pas fermée au bout de n secondes.

Comme tout cela reste relativement compliqué et doit être testé facilement, utiliser node-red plutôt que des scripts et automations peut être tentant ( mais dépend de tes affinités). Perso je pense privilégier les automations, pour le code compact et les possibilités de blue print.

Alors je ne connais pas tout de node red, mais ça a l’air vachement puissant.
pour ma part j’ai utilisé les scripts, et ça fonctionne pas trop mal :

Fermeture porte garage:
(Je pars du postula… que je connais jamais avec certitude la direction que va prendre le moteur)

fermeture_garage:
  alias: Fermeture Garage
  sequence:
  - service: script.interrupteur_garage
  - wait_for_trigger:
    - type: not_opened
      platform: device
      device_id: 4df297f77cfa6c99f55f18297b2c5dee
      entity_id: binary_sensor.shelly_garage_ouvert_door
      domain: binary_sensor
      for:
        hours: 0
        minutes: 0
        seconds: 2
        milliseconds: 0
    timeout: '60'
    continue_on_timeout: false
  - condition: state
    entity_id: binary_sensor.shelly_garage_fermer_door
    state: 'on'
  - service: notify.persistent_notification
    data:
      title: Garage bloqué
      message: Garage dans le mauvais sens ou bloqué au premier passage en fermeture,
        deuxième tentative en cours
  - service: script.interrupteur_garage
  - wait_for_trigger:
    - type: not_opened
      platform: device
      device_id: 4df297f77cfa6c99f55f18297b2c5dee
      entity_id: binary_sensor.shelly_garage_ouvert_door
      domain: binary_sensor
      for:
        hours: 0
        minutes: 0
        seconds: 2
        milliseconds: 0
    timeout: '60'
    continue_on_timeout: false
  - condition: state
    entity_id: binary_sensor.shelly_garage_fermer_door
    state: 'on'
  - service: notify.persistent_notification
    data:
      title: Garage bloqué
      message: Garage bloqué au deuxieme passage en fermeture
  mode: single
  icon: hass:arrow-down

Mon cycle garage dur MAX 30 secondes !
Lors d’un cycle de fermeture, mon garage se réouvre entierement en cas d’obstacle (le chat… la belle mère…)

ALORS :

HA lance une commande shelly interrupteur_garage
j’attend un declencheur pendant 60s.
S’il ne se passe rien c’est ok
S’il le declencheur « garage_est_ouvert » est 1 (ou fermé… c’est une peu ambigu) pendant deux secondes. cela prouve que mon garage est parti dans le mauvais sens ou un objet bloque
HA relance une commande Shelly + un message, maintenant je suis sur du sens car je pars de l’état ouvert.
j’attend un déclencheur pendant 60s.
S’il ne se passe rien c’est ok
S’il le declencheur « garage_est_ouvert » est 1 (ou fermé… encore) pendant deux secondes. cela prouve que mon garage est bloqué et qu’il est encore remonté en ouverture
j’envoie un message.

Voila le principe etablie pour le moment, on verra a l’utilisation, j’ai fait la meme chose dans le sens inverse pour l’ouverture.

et voici ce que j’obtient avec le « natif »
Capture d’écran du 2021-03-18 00-57-12

j’ai mis pile verticale
avec entité cover template Garage
Et en desous j’ai reintegre un pile horizonal (dedans la pile vertical)

Excellent ! Cela devrait marcher.
A voir cependant comment le système se comporte si tu lances une ouverture, puis une fermeture 10 secondes après. C’est pourquoi je serai plus parti sur la mémorisation du dernier état demandé (dans un input text).
Il te manquerait un stop dans ta gestion.
Enfin peut être intéressant d’utiliser le custom button card pour avoir par exemple un icone avec une couleur rouge si la porte ne s’est pas correctement fermée ou ouverte.

Pas obligatoirement besoin de carte personnalisée (même celle que tu cites), tu peux utiliser le module Custom-ui :wink:

Oui je vais améliorer.

etat : la porte est fermé,

1er cas; quand j’appuie sur fermer, alors il s’ouvre (ben oui… on connait pas le sens) pour faire le check et se refermer apres. Donc il faut que j’écrive une condition pour dire « on ne fais rien » ou « bouton invisible »…

2eme cas, je me retrouve avec des script qui pour un cycle de 30s de mouvement de porte, sont actif pendant 1min voir 2min… c’est pas tellement le reflet de la réalité

Merci @Clemalex, je ne connaissais pas custom-ui. Intéressant pour juste gérer les icones. Si j’ai bien compris, c’est juste une ressource à rajouter dans lovelace et qui permet de garder les types originaux en rajoutant juste une clé template avec icon_color ou icon (?)
Après j’aime bien le custom button-card car il permet d’éviter trop de javascript, et le templating est intéressant…

J’ai par ailleurs été très intéressé par la présentation de ton dashboard (https://forum.hacf.fr/t/mon-dashboard-clemalex/737). Je n’ai pas encore décidé quel bouton je vais utiliser pour gérer par exemple les lumières et j’aime bien ton choix. J’imagine que tu utilises justement des custom button card ? Aurais tu le yaml d’un bouton ?
Merci :slight_smile: