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é.
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 )
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.
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 :
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.
@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
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.
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é ?
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 .
C’est l’intégration la plus utilisée lorsque l’on veut être maître de la définition de son entité
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.
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.
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-test.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
.
