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

Entraide Home Assistant
10

Ca tu le gardes bien sur… puisque tu veux boucler jusqu’à ce que le courant soit <750 avant la coupure…

1 « J'aime »
11

La base d’une automatisation sur HA c’est:

  • trigger
  • conditions
  • actions

Il faut bien comprendre que si les conditions ne sont pas réunies, les actions ne sont pas exécutées.

S’il y a plusieurs triggers : n’importe lequel des triggers déclenche.
S’il y a plusieurs conditions: il faut que toutes les conditions soient vraies

Alors et seulement dans ce cas, les actions s’effectuent. Et s’il y a des conditions dans les actions, elles permettent de faire des actions conditionnelles, mais ce n’est pas la même chose que l’attribut « condition » de l’automatisation.

1 « J'aime »
12

Ah oui, j’avais pas compris qu’il fallait carrément supprimer la condition. OK Je vais essayer demain. MERCI encore pour les explications complètes avec les nuances pertinentes.

13

Ou alors il te faut une deuxième automatisation pour le cas >750 qui serait basiquement:

  • declencheur : heure = 5h45
  • condition: courant >750
  • actions: attendre courant>750 puis coupure.

dans un cas comme ça il est plus simple de faire le choix dans les actions, pas dans la condition. La condition sert plutôt à éliminer les triggers (déclencheurs) indésirables.

Par exemple ici :

  • trigger : heure 5h45
  • condition : seulement si à 6h on sera en jour rouge:
  • action : si courant <750: coupure / sinon si courant >750: attendre courant <750 puis coupure
    (qu’ici on peut simplifier en attendre courant <750 puis coupure)
1 « J'aime »
14

D’accord, je vois maintenant comment faire pour stopper la PAC.

Maintenant question subsidiaire : comment faut-il gérer ceci ? Car pour le moment j’active ou je désactive manuellement l’automation selon la couleur du lendemain.

15

Tout dépend comment tu récupères les info tempo…

Je peux te donner ma méthode, qui marche avec un zlinky de lixee, mais ça ne marchera pas forcément chez toi…

[edit]
Ma methode est dispo dans ma description, là: Présentation + [Mon Dashboard] BBE

Post n°3, les automatisations: Présentation + [Mon Dashboard] BBE - #3 par BBE

1 « J'aime »
16

Oui j’ai l’équivalent du zlinky lixee, et j’ai les data avec l’api RTE

17

ouha, super boulot BRAVO ; je vais regarder cela, c’est bien documenté. MERCI

18

Comme j’ai des panneaux solaires + batterie, les jours rouges il fait froid car la couverture nuageuse est faible, donc il y a très souvent du soleil… qui me permet de redémarrer la PAC en HP mais gratuitement avec le soleil + la batterie que je recharge la veille en HC.

19

Alors ça a marché cette coupure?

20

Oui ça y est j’ai vérifié ce matin, impeccable ; la boucle (courant < 750 mA) a duré environ 12 minutes le temps que le cycle de la PAC se termine. MERCI beaucoup

1 « J'aime »
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 !