bizarre, j’ai desactivé l’automatisme, les 2 voitures se sont arrétees de charger.
Je ré-enclenche l’automatisme, elles semblent attendre l’heure de declenchement. faut que je surveille quand meme à 22h ce qui se passe.
Question que je me pose tout de meme, si en branchant la voiture en arrivant à la maison avant les heures de declenchement, si elle ne va pas commencer à charger tout de meme…
Je ne vois pas trop comment tu arrive à te poser cette question 
Sauf à dire que le code n’est pas encore clair pour toi
Il n’y a rien dans les automatisations qui reflète l’état d’une voiture (branchée ou pas branchée) … c’est donc difficile que ces automatisations soient responsables d’un début de charge avant que les triggers soient déclenchés (et les conditions validées) :
22H c’est l’unique déclencheur des actions de la 1ère
Et pour la deuxième charge, c’est le 99% de la 1ere voiture
Donc de 6h à 22h, aucune charge ne devrait se declencher étant donné que l’automatisme n’enclenche qu’à partir de 22h. Le probleme est qu’en cas de charge à l’exterieur, le comportement risque d’etre identique. Je devrais peut-etre ajouter une position dans les conditions ?
Le demarrage de charge des 2 VE hier soir doit etre du au fait de la latence entre le branchement et l’envoi de l’info aux VE de demarrer la charge qu’à partir d’une certaine heure.
22H00 uniquement et rien jusqu’au lendemain. Et si tu arrive après 22H, il n’y a peut-être même
pas de charge du tout… (le déclenchement de la 1ère est dépassé, et si ça ne charge pas tu n’arrivera peut-être jamais à 99%)
Quel souci ? A mon avis, il y a peu de chances que tu arrives chez toi chargé >99 %…
Après tu peux effectivement ajouter plein de conditions complémentaires, mais attention à bien les écrire…
Ce qui est certain, c’est que c’est lié à un évènement extérieur : déclenchement manuel, programmation avec les applis des véhicules etc … A toi de faire le ménage pour eviter les conflits
Bonjour.
Juste pour ajouter un peu au débat, j’avais réalisé des automatisations du même type au début, mais j’ai finalement modifié ça pour gérer un peu plus finement le chauffage en jour tempo.
Si je suis bien ce que tu fais, tu gères ton chauffage en testant à 22h et 6h si tu es en tempo pour éteindre ou allumer le chauffage.
Ma question, pour aller un peu plus loin, comment gères tu ton chauffage le reste du temps ?
As-tu une programation ? Le gères tu de temps en temps « à la main »?
En l’état de tes automatisations, je vois deux soucis:
- si tu modifies quoi que ce soit après 6h, ton chauffage risque de rester allumé en jour rouge toute la journée.
- de nuit en jour rouge, tu vas allumer ton chauffage dans tous les cas (même si tu n’es pas là et que tu l’avais coupé manuellement…)
Pour palier à ça j’ai de mon coté traité ça différemment:
- J’ai défini un scheduler qui est une sorte de calendrier de la semaine sur laquelle tu définit des plages horaires de fonctionnement (par exemple de 18h à 23h le lundi, de 18h à23h le mardi, de 9hà23h le mercredi, etc…)
- j’ai créé un input booléen « mode auto » que je gère à la main
- j’ai créé un booléen « tarif rouge » qui bascule dans une autre automatisation en fonction du tarif tempo qui correspond à mon extinction de chauffage (dans mon cas tarif rouge n’est vrai qu’en HP Jour rouge)
- j’ai ajouté un booléen (optionnel mais pratique) « mode temporaire » que j’active à la main et qui se désactive automatiquement au prochain changement d’état du scheduler (donc je bascule temporairement en manuel jusqu’a la prochaine consigne).
Mon automatisation de gestion du chauffage teste régulièrement (toutes les 10min) l’état du scheduler et des booléens et:
- si mode auto off => ne fait rien
- sinon si mode temporaire ON => ne fait rien
- sinon si tarif rouge => coupe le chauffage
- sinon met ou coupe le chauffage en fonction du scheduler.
Les avantages que j’y vois:
- comme je teste toutes les 10min. Si il y a un reset de HA ou n’importe quel autre pépin, 10min plus tard tout rentre dans l’ordre…
- je peux basculer en manuel pour allumer ou éteindre mon chauffage sans avoir à désactiver l’automatisation, juste en switchant un booléen (via un bouton sur le dashboard)
- si quelqu’un augmente le chauffage « en local », 10min plus tard au pire, on revient sur la consigne…
- le mode temporaire permet de palier aux défauts du scheduler (par exemple un jour de congés où on est présent en semaine) en passant en manuel seulement jusqu’au prochain changement d’état du scheduler (pas d’oubli pour remettre en auto…)
La même philo (test periodique des conditions) est tout à fait possible pour la charge de tes VE et te permet peut être plus de souplesse dans tes scenario:
- en l’état, si le VE1 n’est pas là, le VE2 ne charge jamais (pas de passage >99%)?
- si le VE1 rentre après 22h, le VE1 se charge t’il ?
- Si le VE1 rentre après 22h, le VE2 se charge t’il de 22h jusqu’au retour du VE1 ?
Tu pourrais ainsi tester régulièrement (toutes les demi heure par exemple)
- si VE 1 présent et < 90% => VE1 charge uniquement
- si VE1 absent ou >90% => VE2 charge uniquement
- ajouter d’autre cas par exemple si un des VE est trop déchargé, il aurait la priorité sur l’autre…
- ajouter ton tarif dans l’équation…
- etc…
1 « J'aime »
Tu peux voir normalement dans l’historique qu’est ce qui a déclenché l’activation de la charge.
Oui, il y a plein d’optimisations à faire et tes idées sont bonnes.
ça sera l’occasion pour @cedric_jacquis de s’entrainer au fur et à mesure de la prise en main de ses HA, parce que c’est quand même un cran un peu au dessus des exemples crées ici
1 « J'aime »
L’idée de base derrière mon trop long message est surtout de proposer une alternative à la logique de basculement sur trigger uniquement.
On peut également faire dans certain cas des automatisation « periodiques », c’est parfois plus simple…
en gardant une logique simple, on peut vérifier l’état du booleen tarif rouge toutes les heures et agir en fonction…
Par exemple mon code:
alias: PAC - gestion auto chauffage
description: >-
En saison de chauffage.
En mode auto et sans override temporaire.
=> Chauffe à la temperature de consigne si planifié, sinon a la temperature
réduite ou off. Si tarif rouge => PAC off.
trigger:
- platform: time_pattern
minutes: /10
condition:
- condition: state
entity_id: input_boolean.chauffage_mode_auto
state: "on"
- condition: state
entity_id: input_boolean.saison_chauffage
state: "on"
- condition: state
entity_id: input_boolean.pac_override_temporaire
state: "off"
action:
- choose:
- conditions:
- condition: and
conditions:
- condition: state
entity_id: schedule.planning_chauffage
state: "on"
- condition: state
entity_id: input_boolean.tarif_rouge
state: "off"
sequence:
- device_id: 5b89093e82e42fe555148e26a107faba
domain: climate
entity_id: climate.pac
type: set_hvac_mode
hvac_mode: heat
- service: climate.set_temperature
data:
temperature: "{{states('input_number.temperature_confort_hiver')|int }}"
target:
entity_id: climate.pac
- conditions:
- condition: and
conditions:
- condition: state
entity_id: schedule.planning_chauffage
state: "off"
- condition: state
entity_id: input_boolean.tarif_rouge
state: "off"
sequence:
- device_id: 5b89093e82e42fe555148e26a107faba
domain: climate
entity_id: climate.pac
type: set_hvac_mode
hvac_mode: heat
enabled: false
- service: climate.set_temperature
data:
temperature: "{{states('input_number.temperature_reduit_hiver')|int }}"
target:
entity_id: climate.pac
enabled: true
- device_id: 5b89093e82e42fe555148e26a107faba
domain: climate
entity_id: climate.pac
type: set_hvac_mode
hvac_mode: "off"
- conditions:
- condition: state
entity_id: input_boolean.tarif_rouge
state: "on"
sequence:
- device_id: 5b89093e82e42fe555148e26a107faba
domain: climate
entity_id: climate.pac
type: set_hvac_mode
hvac_mode: "off"
mode: single
pourrait devenir dans l’exemple de @cedric_jacquis :
alias: extinction jour rouge
description: >-
Coupure chauffage si tarif rouge, allumage sinon.
trigger:
- platform: time_pattern
minutes: /10
condition: []
action:
- choose:
- conditions:
- condition: and
conditions:
- condition: time
after: "22:00:00"
before: "06:00:00"
weekday:
- mon
- tue
- wed
- thu
- fri
- condition: state
entity_id: sensor.tempo_aujourd_hui
state: TEMPO_ROUGE
sequence:
- service: climate.set_hvac_mode
data:
hvac_mode: heat
target:
entity_id: climate.chauffage_maison
- conditions:
- condition: and
conditions:
- condition: time
after: "06:00:00"
before: "22:00:00"
weekday:
- mon
- tue
- wed
- thu
- fri
- condition: state
entity_id: sensor.tempo_aujourd_hui
state: TEMPO_ROUGE
sequence:
- service: climate.set_hvac_mode
data:
hvac_mode: "off"
target:
entity_id: climate.chauffage_maison
mode: single
c’est bien comme ça que j’avais compris les choses
Plus simple pas certain, plus efficace, sans doute. J’ai volontairement éludé ce point là pour 2 raisons : du point de vue de la prise en main des automatisations, c’est une nouvelle notion. Et l’erreur fréquente c’est de tomber dans le travers d’un check toutes les minutes.
C’est sur que ce n’est pas optimal comme manière de faire. J’ai été un peu contraint dans mon cas car en cas de modification de la consigne « directement à la télécommande » n’importe qui pouvait bypasser l’effacement de la PAC en heure pleine rouge sans que je ne récupère facilement un trigger exploitable.
Et à 67c/KWh ça pique…
Pour mémoire il y a trois éléments clefs dans toute automatisation:
- Le(s) trigger(s)
- Les conditions
- Les actions
L’idée est la suivante:
l’automatisation est déclenchée par le trigger (déclencheur en bon français dans le texte).
Ceci signifie que tout ce que tu vas écrire ensuite ne sera étudié que si ton trigger est vrai.
Il existe une quantité énorme de trigger différents:
- Une heure (comme dans ton exemple)
- Un délai (comme dans le mien)
- un changement d’état d’une entité (passage de Tarif_rouge de off à on)
- un changement d’état avec confirmation (passage de detection de présence à faux depuis 5min)
- etc…
Par defaut si tu mets plusieurs triggers à la suite c’est un OU, chacun des trigger déclenchera l’automatisation indépendamment des autres triggers
Si et seulement si le trigger est vrai, on passe à la suite:
Les conditions
Celles ci te permettent de trier les cas où ton trigger déclenche, mais où tu ne voudrais pas effectuer d’action. Tu peux donc tester là aussi énormément de choses:
- Si l’heure correspond à une plage horaire à définir
- Si un booléen est vrai
- si une entité est dans un certain état (éventuellement aussi depuis un certain temps…)
- des combinaisons de ET et de OU
- etc…
Par défaut si tu mets plusieurs conditions à la suite c’est un ET on ne passera a la suite que si toutes les conditions sont vraies en même temps.
Si et seulement si le trigger a déclenché ET les conditions sont remplies on passe à la suite:
Les actions. Que faire dans l’automatisation…
- modifier des entités
- appeler des scripts
- utiliser des conditions pour choisir s’il faut faire certaines actions.
- utiliser des structures if/then/else pour realiser des actions
- etc…
C’est la base… ensuite ne pas hésiter à s’inspirer des autres…
Il y a quelques confusions courantes: le fait que les conditions soient vraies ne signifie pas que l’automatisation se déclenche. C’est uniquement le trigger qui déclenche.
Par exemple ton exemple plus haut:
alias: Coupure Chauffage rouge
description: ""
trigger:
- platform: time
at: "06:00:00"
condition:
- condition: and
conditions:
- condition: time
after: "06:01:00"
[etc...]
action:
[etc...]
le trigger déclenche à 6h
mais à 6h la condition « after 6h01 » est fausse
donc les actions ne seront jamais executées
Utiliser l’interface est souvent le plus simple.
Le Yaml permet par contre de partager ses automatisations et d’importer celles des autres. Mais au début l’interface c’est bien…
Comme je le craignais, meme avant 22h, en branchant les voitures, les charges s’enclenchent.
Sur un VE c’est automatique, des que la cable est detecté branché, ca charge.
Donc ca marche pas, faut que je trouve une autre solution…
En desactivant la charge de la e-up, ID3 branché, la charge id3 s’enclenche tout de meme alors que dans l’automatisme, on lui dit de ne s’enclencher qu’une fois la charge de la E-up à 99%…
alias: VE-Charge ID3
description: ""
trigger:
- type: battery_level
platform: device
device_id: 1bf821b2736824ee7fe5b0818aa5148e
entity_id: sensor.la_petrolette_battery_level
domain: sensor
above: 99
condition: []
action:
- type: turn_off
device_id: 1bf821b2736824ee7fe5b0818aa5148e
entity_id: switch.la_petrolette_charging
domain: switch
- service: volkswagen_we_connect_id.volkswagen_id_start_stop_charging
data:
vin: WVW***************
start_stop: start
mode: single
Ben, tu as une piste
Mettre 2 switchs, tous le temps à OFF, les wallbox ne sont pas alimentées quand tu branches les VE
Il y a juste à mettre les bascules à ON en plus, dans le début des automatisation respectives
un switch, j’en ai deja un, pas de problemes. Mais il est sur les deux wallbox. A moins de repasser un cable, je peux pas commander les 2 individuellement.
Et j’ai pas d’autres moyens d’actions electriques. (j’etais electricien, donc ca aide à ce niveau la)
C’est l’idée de la dernière version du message, oui
Ou alors, lors du branchement des VE, pensez à desactiver la charge depuis l’appli volkswagen… Pour qu’elle s’enclenche à l’heure des automatismes
Là il faut voir comment ça se comporte parce qu’en fonction de la latence, tu va quand même lancer une mini charge. Je ne sais pas si c’est très sain pour les batteries
Gérer le chauffage par une (ou des) automatisation est une erreur de mon point de vue.
Il est fortement recommandé de géré les chauffage par climate.
Après, par dessus, je te conseil d’utiliser scheduler card qui peut prendre des conditions.
Donc tu peut faire un programme pour les jours rouge et les autres
C’est un autre point de vue. Mais comme tous les chauffages ne sont pas forcement des climate, c’est pas une obligation. D’ailleurs j’ai pas vu ou on parle de cette recommandation.
Et ici on ne parle pas de régulation de la température
Un bête module DIO, une diode sur le fil pilote ça domotise un convecteur non connecté. Le thermostat d’origine fait le boulot de régulation, et tout va bien
1 « J'aime »