C’est réglé, suppression et re-création. Strange!
HACS pour ma part. J’ai suivi la proc.
j’avance bien, j’ai juste un souci: comment mettre un T° dans le scheduler avec des qubino fil pilot qui sont reconnus comme des light, et donc on allume ou on eteind, qque chose m’échappe
Hello,
Le scheduler pilote la consigne du thermostat (input number).
Puis le thermostat pilote les on-off du radiateur (switch) en fonction des températures et de la consigne.
Merci @Argonaute, je me suis rendu compte de ma question un peu stupide. Maintenant ca fonctionne parfaitement, mais je vais tout de même continuer à tester avant de tout basculer sur HA
Merci @Argonaute , voila ce que ca donne chez moi, avec quelques adaptations :
J’ai ajouté la Temp Extérieure dans le premier glance, puis ajouté une glance avec :
- un indicateur pour savoir si le planning est actif ou pas.
- un indicateur pour savoir si le chauffage est en marche.
- la consommation quotidienne de chacun.
J’ai intégré ensuite la scheduler card de chaque entité en dessous, puis un footer qui est un graph de l’évolution de la température de la pièce.
Et également un graph de la répartition de la consommation par heure et par jour :
Une question cependant, comment tu adapte les coef en fonction de la puissance/isolation de la pièce?
Si le radiateur est plus puissant, tu augmente le coef_c?
Merci pour ton travail.
bonjour à tous, dès que l’on passe dans un mode autre que auto, lorsque l’on revient en auto confort ou auto eco, on est obligé de les ré-activer manuellement, je suis le seul dans cette situation, ou est-ce normal? Merci.
Merci pour ton retour @djal. Cela fait vraiment plaisir de voir comment tu t’es approprié et a perfectionné ma première proposition ! C’est superbe.
Calcules tu la consommation en multipliant la puissance du thermostat par la puissance du radiateur ? Si tu peux éventuellement partager la carte consommation.
Pour le coefficient, le calcul de puissance est :
Puissance = coeff_c * (T consigne - T intérieure) + coeff_t * (T consigne - T extérieure)
Donc si on augment trop coeff_c, le radiateur va chauffer fort, et donc la pente de chauffe sera raide. La conséquence va être un radiateur bouillant puis ensuite froid, puis bouillant, puis froid… (oscillation et inconfort).
Si on baisse trop coeff_c, la pente de chauffe sera moins forte, avec un radiateur trop tiède. Plus d’oscillations mais la température de consigne mettra trop de temps a être atteinte.
Il faut donc trouver le juste milieu. Si radiateur puissant, il faut baisser le coeff_c.
Une méthode empirique est de vérifier la courbe de puissance et que la température atteint la consigne dans un temps correct, que la puissance diminue doucement puis se stabilise sans osciller. D’expérience, quand la température de consigne est atteinte, qu’il fait dehors entre 5-8 degrés environ, la puissance passe sous les 100% a 2 degrés sous la consigne puis devient stable à 25-30% environ. Le radiateur est alors juste tiède pour compenser la perte thermique, et donc apporte le confort voulu. Il serait impossible d’avoir un tel résultat avec le thermostat de base de home assistant.
Pour des gens ayant fait de la physique, une méthode plus scientifique serait de faire des calculs d’énergie thermique : on a la puissance injectée par le convecteur, le temps pour monter de 1 degré, le temps pour perdre 1 degré si chauffage coupé (pertes / isolation)…
Energie thermique q = m * c * dT ( masse * capacité thermique de l’air * différence température).
Mais je me lancerait pas dans le développement de cela
Hello @passyl,
Quand on passe de manuel a confort, l’automatisation auto-confort est activé, et les températures de consignes du mode confort sont automatiquement appliquées au thermostat.
Vérifie ce qui se passe dans les traces de l’automatisation du mode. Je crains qu’elle ne se déclenche pas, et n’active pas l’automatisation.
Vérifie aussi les paramètres du blue print de gestion des modes.
@djal . Pourrais-tu partager ta carte et notamment la consommation quotidienne ?
Merci.
Je relance ma question qui est passée à la trappe
Hello,
@Argonaute merci pour tes explications, je vais tenter de calibrer les coef.
Concernant la consommation voilà comment j’ai procédé :
-
D’abord la création d’un compteur de type input_number qui correspond à la consommation du chauffage (un index). Mettez la valeur maximale à un truc inaténiable (quoique ^^).
Pour la taille du pas, ca va dépendre de la puissance de votre chauffage. Si la puissance de votre chauffage varie, cette méthode ne fonctionnera pas (mais il ne me semble pas qu’il ait des convecteurs dont la puissance varie).
L’idée est de récupérer sa consommation en kWh à la seconde.Donc ca donne :
(Puissance/1000) / 3600 = Consommation en kWh/seconde
Puissance /1000 : consommation en kWh. (1kWh égale 1000W pendant 1heure)
/3600 pour ramener la consommation en kWh à la seconde. (1h = 3600 secondes)Chez moi, celui-ci fait 900w quand il est allumé.
Donc:900/1000 = 0.9kWh
0.9/3600 = 0.00025Je mets donc le pas de mon compteur à 0.00025.
- Ensuite, via une automation, on va incrémenter le compteur (il incrémente par défaut avec la valeur du pas renseigné) toutes les secondes.
alias: Chauffage Salon 1 - Compteur Index
description: ''
trigger:
- platform: time_pattern
seconds: /1
condition: []
action:
- service: input_number.increment
target:
entity_id: input_number.chauffage_salon_1_index
mode: single
- Et via une seconde automation on va activer/désactiver la première automation uniquement lorsque le chauffage est allumé (via la surveillance du switch du chauffage).
alias: Chauffage Salon 1 - Activation Compteur Index
description: ''
trigger:
- platform: state
entity_id: light.chauffage_1_qubino_salon
condition: []
action:
- choose:
- conditions:
- condition: state
entity_id: light.chauffage_1_qubino_salon
state: 'on'
sequence:
- service: automation.turn_on
data: {}
target:
entity_id: automation.chauffage_salon_1_compteur_index
- conditions:
- condition: state
entity_id: light.chauffage_1_qubino_salon
state: 'off'
sequence:
- service: automation.turn_off
data: {}
target:
entity_id: automation.chauffage_salon_1_compteur_index
default: []
mode: single
(Je pense qu’on doit pouvoir faire avec une seule automation, mais ca me va comme ca)
Et voilà, vous avez donc un compteur qui s’incrémente de sa puissance en kWh chaque seconde lorsqu’il est allumé.
@Dim33 @Argonaute Pour la carte de consommation, j’utilise la magnifique carte ApexCharts qui vous permet de faire les graphs que vous voulez, configurables à souhait.
Voici ma carte qui est composée de :
-
Une button-card pour le titre.
-
Une carte Apex-Charts pour les graphs en colonnes (avec les 3 entités correspondant à mes 3
chauffages). elle me permet de voir heure par heure la consommation de chaque convecteur, sur une durée de 24h de la journée en cours. -
Une autre carte Apex-Charts pour le donut qui représente la répartition de consommation entre les différents chauffages, toujours de la journée en cours.
Et le tout dans une carte « entities »
L’avantage d’utiliser Apex-Charts, bah déjà c’est que c’est joli , et ensuite c’est lui qui s’occupe de calculer la consommation (par heure/semaines/mois/années etc…), pas besoin de passer par un utility-meter, vous mettez juste votre entité compteur et il s’occupe de tout.
Voilà le code de ma carte : (vous pouvez vous passez des « styles » et du « card_mod », ca c’est pour mon design)
type: entities
entities:
- type: custom:button-card
name: Consommation
size: 0px
aspect_ratio: 10/1
show_icon: true
- type: custom:apexcharts-card
cache: true
update_interval: 5min
now:
show: false
label: Maintenant
header:
standard_format: false
show: false
show_states: false
span:
start: day
graph_span: 24h
y_axis_precision: 2
stacked: true
apex_config:
legend:
show: false
xaxis:
axisBorder:
show: false
axisTicks:
show: false
yaxis:
axisBorder:
show: false
axisTicks:
show: false
fill:
opacity: 1
type: solid
gradient:
shade: dark
type: horizontal
grid:
show: false
series:
- entity: input_number.chauffage_salon_1_index
type: column
name: Salon 1
float_precision: 2
color: 17AB48
opacity: 1
group_by:
duration: 1h
func: diff
show:
datalabels: false
- entity: input_number.chauffage_salon_2_index
type: column
name: Salon 2
float_precision: 2
color: 177DF7
opacity: 1
group_by:
duration: 1h
func: diff
show:
datalabels: false
- entity: input_number.chauffage_sam_index
type: column
name: Salle a Manger
float_precision: 2
color: EA4234
opacity: 1
group_by:
duration: 1h
func: diff
show:
datalabels: false
style: |
ha-card {
background: var(--background-card-color);
box-shadow: none;
font-size: 1px;
top: -2px;
margin: -18px
}
- type: custom:apexcharts-card
cache: true
update_interval: 5min
chart_type: donut
header:
standard_format: true
show: false
show_states: false
span:
start: day
graph_span: 24h
stacked: false
apex_config:
stroke:
show: true
width: 0.5
fill:
opacity: 1
type: solid
gradient:
shade: light
type: horizontal
grid:
show: false
series:
- entity: input_number.chauffage_salon_1_index
name: Salon 1
float_precision: 2
color: 17AB48
opacity: 1
group_by:
duration: 1d
func: diff
show:
datalabels: false
- entity: input_number.chauffage_salon_2_index
name: Salon 2
float_precision: 2
color: 177DF7
opacity: 1
group_by:
duration: 1d
func: diff
show:
datalabels: false
- entity: input_number.chauffage_sam_index
name: Salle a Manger
float_precision: 2
color: EA4234
opacity: 1
group_by:
duration: 1d
func: diff
show:
datalabels: false
style: |
ha-card {
background: var(--background-card-color);
box-shadow: none;
font-size: 1px;
top: -2px;
margin: -6px
}
show_header_toggle: false
card_mod:
style: |
ha-card {
--ha-card-background: #131313BF;
--ha-card-border-radius: 10px;
# --paper-item-icon-color: #6E6E6E;
# --paper-item-icon-active-color: #44739e;
--mini-media-player-background-opacity:0;
--ha-card-box-shadow: 0px;
--accent-color: #EA4234;
}
Ca donne ca :
Toujours avec Apex-charts, tu peux faire un graph qui te donne la consommation globale de tous tes convecteurs durant les 7 derniers jours par exemple (la en revanche il faut d’abord faire un sensor qui cumule la consommation des tous tes compteurs que tu mets dans la carte Apex) :
Et le sensor de cumul :
- platform: template
sensors:
cumul_chauffage_new:
unit_of_measurement: "kWh"
value_template: "{{ (states('input_number.chauffage_salon_1_index') | float) + (states('input_number.chauffage_salon_2_index') | float) + (states('input_number.chauffage_sam_index') | float) }}"
Voilà j’espère avoir aidé. Amusez-vous bien
Et @Dim33, concernant la possibilité de n’afficher uniquement les scheduler actifs, il ne me semble pas que ca puisse se faire directement depuis la carte scheduler, mais vérifies quand même Scheduler-Card
Tu pourrais, via une condition sur chaque entité scheduler dans la carte, l’afficher que si elle est active en revanche. Mais ca fait beaucoup de code si tu as beaucoup de scheduler.
Oups désolé @Dim33, j’ai zappé.
Si tu utilises la carte scheduler, a ma connaissance il n’est pas possible de filtrer dynamiquement les planifications affichées. Les clauses include et exclude du scheduler prennent des listes d’entités fixes.
Après le scheduler génère des switch pour chaque planification et il est possible de lister celles qui sont actives dans une carte entities, en les affichants sous conditions. Ci-dessous la syntaxe a reprendre pour chaque planification, mais tu perds bien entendu la possibilité de modifier les plages horaires offerte par le scheduler.
type: entities
entities:
- type: conditional
conditions:
- entity: switch.planif_eco_chambre
state: 'on'
row:
entity: planif_eco_chambre
J’avoue ne pas trop comprendre ce que tu cherches a faire, cela dit
Merci @djal pour le partage ! Excellent !
Je ne l’ai pas testé, mais j’avais en tête une alternative : un sensor template qui multiplie le % de puissance du thermostat par la puissance nominale du convecteur pour avoir la conso instantanée. Par ex 50% * 900 watts = 450w/h de conso instantané. Puis injecter cela dans une entité de type utility meter qui se charge de l’intégration. Cela évite ton automatisation d’incrément.
Les apex chart donnent de superbes résultats. Et donc pas besoin d’utility meter pour les périodes effectivement.
Ils ne sont pas trop longs a se rafraîchir ?
Hello @Argonaute, le soucis que je vois avec cette méthode, c’est qu’elle ne reflète pas la consommation instantanée justement, mais plutôt la consommation sur une période donnée (la fréquence de l’automation en fait).
Dans ton automation, quand on parle de puissance, en fait c’est une puissance virtuelle : pour une « puissance » de 50%, tu allume en fait le convecteur 50% du temps, ce qui correspond a une consommation de 50% de sa puissance nominale, mais sur x minutes, pas instantanée.
Parce que on est d’accord, pendant les 50% du temps, mon convecteur lui va bien chauffer a 100% de sa puissance.
Ce que tu veux faire est possible oui, mais moins précis, et il faut le réévaluer à chaque fois qu’un événement survient (changement de mode, ouverture…). Du coup ma méthode t’assure un calcul précis à la seconde, en fonction de l’état du switch de ton convecteur. (Et donc non dépendant d’autre événements)
Mais je le répète ma méthode n’est valable que pour un convecteur avec une puissance constante.
Concentrant Apex, le temps de rafraîchissement est raisonnable, en fonction du volume de donnée mais ca ne dépasse jamais quelques secondes. Et il y’a la possibilité de stocker les datas en cache du navigateur.
Merci @Argonaute … c’est tout simplement pour rendre la carte plus lisible. J’ai 4 zones avec 4 plannings donc 16 plannings au total.
Bien sûr.
J’ai fait quelques modifications, notamment le planificateur qui s’affiche sur la carte uniquement si le mode Auto est sélectionné :
type: entities
entities:
- type: custom:button-card
color: '#000000'
name: Salon 1
styles:
card:
- background-color: '#17AB48'
- height: 25px
name:
- font-size: 18px
- entity: input_select.chauffage_salon1_mode
name: Mode
- type: conditional
conditions:
- entity: input_select.chauffage_salon1_mode
state: Manuel
row:
entity: input_number.chauffage_salon_1_consigne
type: custom:numberbox-card
name: Réglage consigne
- type: custom:hui-element
card_type: glance
show_name: false
style: |
ha-card {
background: var(--background-card-color);
box-shadow: none;
font-size: 16px;
top: -10px;
margin: -24px;
}
entities:
- entity: sensor.limeil_brevannes_temperature
icon: mdi:cloud
- entity: sensor.lumi_lumi_weather_temperature
- entity: input_number.chauffage_salon_1_consigne
icon: mdi:target
- entity: input_number.chauffage_salon_1_puissance
icon: mdi:lightning-bolt
- entity: binary_sensor.fenetre_salon2_delai
icon: mdi:window-closed-variant
- type: divider
- type: custom:hui-element
card_type: glance
show_name: false
style: |
ha-card {
background: var(--background-card-color);
box-shadow: none;
font-size: 16px;
top: -10px;
margin: -24px
}
entities:
- entity: switch.schedule_chauffage_salon1_auto
- entity: light.chauffage_1_qubino_salon
icon: mdi:radiator
- entity: sensor.daily_chauffage_salon1_round
icon: mdi:calendar-today
- type: divider
- type: conditional
conditions:
- entity: input_select.chauffage_salon1_mode
state: Auto - Piloté
row:
type: custom:scheduler-card
standard_configuration: false
discover_existing: false
include:
- input_number
time_step: 15
tags: SALON1
show_add_button: false
title: ''
display_options:
primary_info:
- '{action}'
secondary_info: relative-time
style: |
ha-card {
background: var(--background-card-color);
box-shadow: none;
font-size: 16px;
top: 0px;
margin: -10px
}
- type: conditional
conditions:
- entity: input_select.chauffage_salon1_mode
state: Auto - Piloté
row:
type: section
footer:
type: graph
entity: sensor.lumi_lumi_weather_temperature
hours_to_show: 24
detail: 2
show_header_toggle: true
state_color: true
card_mod:
style: |
ha-card {
--ha-card-background: #131313BF;
--ha-card-border-radius: 10px;
# --paper-item-icon-color: #6E6E6E;
# --paper-item-icon-active-color: #44739e;
--mini-media-player-background-opacity:0;
--ha-card-box-shadow: 0px;
--accent-color: #17AB48;
}
Encore une fois, tu peux t’affranchir des éléments de design type « style » et « card_mod ».
Hésites pas si tu as des questions.
Hello @djal
Oui tu as raison, ta méthode sera plus précise.
Avec mon calcul plus basique : si sur 24 heures on a 10 événements type changement de consigne, mode ou fenêtre, alors le calcul ne sera potentiellement pas juste sur une période de 10*10 mn = 100 minutes sur 24 heures, soit 100 / (24 * 60) = 6,9% du temps. Si l’erreur de calcul est en moyenne de 50% (probablement moins en fait) sur ces 10 événements, on devrait avoir une erreur de l’ordre de 3.5%.
Merci beaucoup du partage, c’est exactement ce que je recherchais !
Je suis en cours d’implémentation et je voudrais partager mes petites difficultés :
N’ayant pas de sonde de température extérieure, je souhaitais récupérer l’attribut ‹ temperature › de l’entité ‹ weather › de mon domicile. Pour ce faire, il faut copier le code suivant dans le fichier ‹ configuration.yaml › :
sensor:
# Température extérieure domicile
- platform: template
sensors:
outside_temp:
friendly_name: 'Température extérieure'
device_class: temperature
value_template: "{{ state_attr('weather.ma_ville', 'temperature') }}" # Remplacer ma_ville par l'identifiant weather correspondant à votre domicile
unique_id: 'outside_temp_id'
Ainsi, on a bien une entité utilisable dans l’automatisation.