Action de Répétition d'une condition ne marche pas

Entraide Home Assistant
21

Parfait.

J’espère que ça t’aura aider à bien comprendre les fondamentaux des automatisations.

22

Oui, encore un Grand MERCI.
Auparavant j’avais essayé comme ceci

alias: Tempo OFF- Puissance-Temps
description: ""
trigger:
  - platform: numeric_state
    entity_id:
      - switch.tongu2_pac_ext
    attribute: current_consumption
    below: 350
condition:
  - condition: time
    after: "05:55:00"
    before: "06:45:00"
action:
  - type: turn_off
    device_id: 07ea003b34187
    domain: switch
  - service: notify.persistent_notification
    data:
      message: PAC OFF
      title: PAC OFF
mode: single

mais toutes les 4 à 6 minutes jusqu’à 6h45, il y a eu des ordres de déclenchement PAC OFF !!! Peut-être qu’en utilisant un BOOLEEN pour maîtriser l’état du switch état 0 (ou 1) ??? pour ne pas redonner l’ordre une 2ème fois, puis une 3ème fois, etc,… Comment faudrait-il faire alors avec BOOLEEN ? Merci d’avance

23

Tu ajoutes dans tes conditions que l’état du switch 07ea003b34187 soit ‹ ON ›…

Là a chaque fois que la conso passe sous 350 l’automatisation se déclenche.

Tu tests alors la plage horaire ET que l’état du switch 07ea003b34187 soit ‹ ON ›

Et tu réalise les actions seulement si la PAC est ON, sinon tu t’arrêtes…

24

Je comprends ton explication qui me va bien, je suis d’accord avec toi… ça devrait aussi marcher : solution à tester - wait & see
Laquelle des 2 solutions est le meilleure pour switcher OFF la PAC ?

  • solution A= trigger à 5h55, pas de condition, action attendre courant devient < 350
    OU
  • solution B= trigger courant < 350, condition entre 5h55 et 6h45 ET switch ON ?
    Merci pour tes bons conseils
25

En informatique ou en domotique, comme dans la vie d’ailleurs, il y a souvent plusieurs solutions pour aboutir à un résultat équivalent…

La « bonne » solution dépend beaucoup de la manière dont tu cherches toi même à l’évaluer, il y a une infinité de critères:

  • la plus simple,
  • la plus facile à expliquer à d’autres
  • la plus facile à maintenir dans le temps
  • celle qui utilise le moins de lignes de codes
  • celle qui est la plus performante
  • celle qui se lance le moins de fois possible
  • celle qui est la plus élégante
  • celle qui est utilisée dans un cas particulier qui impose un fonctionnement atypique
  • celle qui consomme le moins de ressources
  • celle qui appelle le moins de variables différentes
  • etc…

En l’état, les deux arrivent à réaliser ta fonction, mais:

  • l’une ne va se déclencher qu’une fois à 5h55 et réaliser en un coup ton action en regardant l’état du courant quitte à attendre jusqu’à la baisse de courant.
  • l’autre va se déclencher à chaque fois que le courant devient <350, mais ne s’exécuter que quand tu es dans la bonne fenêtre (heure + PAC ON)

A ton avis, pour toi laquelle est la meilleure?

26

C’est vrai : un problème donné a toujours plusieurs solutions.
Dans notre cas, compte tenu des différents critères que tu indiques, je dirai que la meilleure est la solution 1.
Je garderai en réserve pour une prochaine automatisation le fonctionnement de la 2nde solution qui pourrait me servir un jour, on ne sait jamais… MERCI encore une fois pour toutes tes explications.

27

Pour moi les aspects les plus important de ce choix sont:

  • dans le premier cas tu as une attente, donc si il y a perte de HA pendant l’attente (reboot par exemple) ton automatisation n’ira pas au bout et tu ne coupera pas ta clim
  • dans l’autre cas tu effectues de nombreuses fois le test « pour rien », mais tu es sûr de couper (du moins dans la bonne fenêtre temporelle), donc tu utilises plus de ressources.

Les deux présentent donc des avantages et des inconvénients…
La première est plus simple, oui, mais en cas de pépin au mauvais moment (la probabilité reste faible…), tu vas chauffer tout le jour rouge…
La deuxième « coute plus » en terme de performances et de ressources (donc tous les jours), mais elle est plus systématique… (au passage, si l’objectif est d’assurer qu’on a bien coupé, tu peux étendre la fenêtre temporelle bien au delà de 6h45… pourquoi pas jusqu’à 20h).

Tout n’est jamais blanc ou noir… ici on peut ajouter dans les critères la probabilité que ça rate, ou la robustesse à une panne…

1 « J'aime »
28

Excellente analyse… dans une autre vie je faisais des AMDECS. Donc je suis d’accord que dans les automatismes HA, il faudrait effectivement et systématiquement rechercher des modes de défaillance qui ne viennent pas toujours à l’esprit dans la première approche quand on cherche à satisfaire son besoin immédiat. En d’autres termes, il faudrait prendre en compte des dysfonctionnements potentiellement possibles de sensors, d’actionneurs voire de HA, afin de sécuriser au mieux l’automatisme par plusieurs boucles ou automatismes supplémentaires si nécessaires.

29

En tout cas ravi que ton problème initial soit résolu !