Hello !!
Alors ca avance à grand pas ! je commence à comprendre la mécanique. Voici où j’en suis et mes points de blocages :
Télécharger le blueprint “Thermostat TPI” OK
Créer un “input_number” pour la consigne de la pièce. OK
Créer un “input_number” pour la puissance de la pièce. OK
Créer un “binary_sensor” pour simuler le contact de fenêtre sur off dans configuration.yaml. OK
4b : Inversion de la commande du chauffage (option). Pas besoin pour mon cas
Créer le Thermostat TPI (Blueprint) OK
Installer depuis HACS : button-card, hui-element et number-box. OK
Ajoutez la carte en manuel sur votre vue. (suivant code). OK
Créer un “input_select “chauffage salon mode” avec les différents modes. OK
Ajouter “scheduler” depuis HACS OK
Ajoutez la carte du scheduler sur votre vue. (suivant code). OK
Créer les différents modes de chauffage depuis cette carte. OK
Télécharger le blueprint “chauffage_pilotage" OK
Créer l’automatisme depuis ce blueprint OK, mais j’ai l’impression que cela ne fonctionne pas :
Voici la capture du chauffage_pilotage:
Cela n’active pas le scheduler, ni ne change la consigne Et je ne sais pas pourquoi. Par contre si je passe en manuel, et que je change la consigne, l’ordre est bien pris en compte, et allume bien mon chauffage, c’est un bon signe.
Par ailleur la carte « chauffage » ne fonctionne pas, j’ai mis ce code :
Edit (désolé je n’arrive pas à éditer mon post…) :
Si j’active le scheduler manuellement soit le auto-confort soit le auto-eco de ma capture à droite, cela change bien la consigne. Je pense que mon souci vient de l’automatisation… mais où…
Redit (si vous avez l’astuce pour éditer les posts je suis preneur, désolé pour mes 3 posts…)
Je viens d’intégrer mon réseau zigbee avec mes capteurs de fenêtres de la marque xiaomi (MCCGQ11LM) Ils sont bien reconnus en tant que binary_sensor (binary_sensor.fenetre_s_contact) mais il m’est impossible de l’ajouter dans le thermostat tpi, je ne comprends pas pourquoi
Je suis en train de faire un test sur une pièce pour voir si j’ai tout ce qu’il me faut.
J’ai juste une interrogation sur les 2 planifications auto-confortet auto-eco.
Pourquoi 2 différentes alors qu’on met les consignes par plages horaire ?
Une seule planification peut couvrir toute la journée, non ?
Je veux bien des éclaircissements si quelqu’un a 5 mins.
suivant les captures que tu as mis, cela vient des noms de modes qui sont différents entre tes entrées salon mode et les noms qui sont dans le chauffage_pilotage.yaml
Tu as écris les noms « auto-confort, et auto-eco » , et dans chauffage_pilotage.yaml tu as « Auto - confort, et Auto - eco » ( subitlité tu as deux espaces entre le « - » ).
Avoir deux planifications te permet de gérer ton chauffage selon un rythme de vie qui peut etre différent quotidiennement et non routinier.
Exemple : le dernier de la famille qui sort plus tard que prevu cela active le mode auto eco ou absent, tu reviens a une heure tot que prévu, le mode auto confort se ré enclenche.
Merci pour ta réponse, je comprends le principe mais je vois pas très bien quoi mettre dans la plannification ? Si dans la plannification auto-confort je definis le Lundi de 08h - 12h = 19°C, pour moi c’est en fait le mode eco 19°C
Tu peux me faire un screen de 2 de tes plannifications STP ?
Un samedi à 15h, tu es dans la maison => mode confort
Un samedi à 15h, tu es parti faire une rando et ne rentre que le soir => mode eco.
C’est en fait un mode absence, qui permet d’abaisser la température si il est détecté qu’une pièce ou la maison est inoccupée (mis manuellement ou automatiquement si par exemple l’alarme est mise). Le nom peut prêter à confusion.
Et en confort, pour les plages horaires, tu mettra des températures différentes en fonction de la pièce :
Une chambre sera plutôt chauffée la nuit et moins la journée
Une cuisine sera chauffée aux heures des repas et moins la nuit.
Enfin, en mode eco, une solution simple serait de reprendre les températures des plages du mode confort en enlevant 1 ou 2 degrés. Et donc ta cuisine à l’heure du repas sera moins chauffée si tu es parti en rando que si tu es à la maison.
Hello
j’ai reussi a tout mettre en place mais je bute sur la création d’une planification pour le week end @Argonaute c’est vrai qu’un blue print + un poil de doc cela pourrais aider
OK j’ai saisi en fait les plages horaires sont le « standard » d’une journée et on reprend ce standard en enlevant des °C à la consigne pour le mode eco.
Pour ceux qui veulent piloter leur radiateur via une une sortie de câble Legrand connectée Zigbee compatible fil pilote 3000W ON-OFF et mesure conso. modele 064879:
il faut créer un switch qui permet de gérer le fil pilote selon le mode comfort et off , exemple pour le salon
Hello,
Super, j’ai enfin compris mon erreur ! ça fonctionne comme je le souhaite
Il me reste un petit détail que je n’arrive pas à trouver ça concerne mes capteurs de fenêtres :
Je viens d’intégrer mon réseau zigbee avec mes capteurs de fenetres de la marque xiaomi (MCCGQ11LM) Ils sont bien reconnus en tant que binary_sensor (binary_sensor.fenetre_s_contact) mais il m’est impossible de l’ajouter dans le thermostat tpi, je ne comprends pas pourquoi
Edit : c’est bon, je les ai mis en dur sur le yaml
Par contre j’ai 2 fenêtres dans la pièce avec 2 capteurs. Comment pourrais-je inclure la 2eme ?
Hello,
Il me semble que j’ai eu le même problème avec mes Tuya: ils n’apparaissait pas dans la liste déroulante. Par contre en collant l’ID de l’entité dans le champs c’est passé.
J’ai rencontré un problème avec les modules Heatzy qui ne prennent plus en charge la fonction switch dans l’intégration… J’ai donc effectuer une modification sur le blueprint « thermostat_TPI » pour qu’il effectue directement les changements sur le base du mode de chauffage directement. Basiquement, c’est un Off ou Heat.
Il faut néanmoins penser à mettre initialement le mode de chauffage. Peut sans doute être évolué mais j’ai fais ça rapido ce matin.
Le blueprint est dispo là pour ce que ça intéresse :
blueprint:
name: Thermostat TPI Heatzy
description: Thermostat TPI (Time Propertional & Integral)
domain: automation
input:
coeff_c:
name: Coefficient C
description: coefficient multiplicateur de la différence entre la consigne et la température intérieure pour le calcul de la puissance (0.6 conseillé)
selector:
number:
min: 0.0
max: 1.0
step: 0.01
coeff_t:
name: Coefficient T
description: coefficient multiplicateur de la différence entre la consigne et la température extérieure pour le calcul de la puissance (0.01 conseillé)
selector:
number:
min: 0.0
max: 0.1
step: 0.001
entity_consigne:
name: Consigne
description: Champ d'entrée de la température de consigne (input number).
selector:
entity:
domain: input_number
entity_temp_ext:
name: Température extérieure
description: Sonde de mesure de la température extérieure (sensor)
selector:
entity:
domain: sensor
device_class: temperature
entity_temp_int:
name: Température intérieure
description: Sonde de mesure de la température intérieure (sensor)
selector:
entity:
domain: sensor
device_class: temperature
entity_fenetre:
name: Fenêtre
description: Capteur d'ouverture de fenêtre (sensor)
selector:
entity:
domain: binary_sensor
device_class: opening
entity_puissance:
name: Puissance
description: Champ d'affichage de la puissance (input_number)
selector:
entity:
domain: input_number
entity_chauffage:
name: Chauffage
description: Définition du module heatzy en "climate"
selector:
entity:
domain: climate
# Récupération des paramètres
variables:
coeff_c: !input coeff_c
coeff_t: !input coeff_t
entity_temp_int: !input entity_temp_int
entity_temp_ext: !input entity_temp_ext
entity_fenetre: !input entity_fenetre
trigger:
- platform: time_pattern
minutes: "/10"
- platform: state
entity_id: !input entity_consigne
- platform: state
entity_id: !input entity_fenetre
action:
- alias: récupération des données
variables:
entity_consigne: !input entity_consigne
consigne: "{{states(entity_consigne)}}"
temp_ext: '{{ states(entity_temp_ext) }}'
temp_int: '{{ states(entity_temp_int) }}'
fenetre: '{{states(entity_fenetre)}}'
puissance: >-
{%set val = coeff_c * (consigne - temp_int) + coeff_t * (consigne -
temp_ext) %} {% if val > 1 and fenetre == 'off' %} {% set val = 100 %} {% elif val < 0 or
fenetre == 'on' %} {% set val = 0 %} {% else %} {% set val = ( (val *
100) | round(0)) %} {% endif %} {{val}}
temps_chauffe: '{{ puissance * 6 }}'
- alias: Met à jour l'indicateur de puissance
service: input_number.set_value
target:
entity_id: !input entity_puissance
data:
value: '{{puissance}}'
- choose:
- conditions:
- condition: template
value_template: '{{puissance == 0}}'
sequence:
- service: climate.set_hvac_mode
data:
hvac_mode: "off"
target:
entity_id: !input entity_chauffage
- conditions:
- condition: template
value_template: '{{ puissance > 99}}'
sequence:
- service: climate.set_hvac_mode
data:
hvac_mode: "heat"
target:
entity_id: !input entity_chauffage
default:
- service: climate.set_hvac_mode
data:
hvac_mode: "heat"
target:
entity_id: !input entity_chauffage
- delay: '{{temps_chauffe}}'
- service: climate.set_hvac_mode
data:
hvac_mode: "off"
target:
entity_id: !input entity_chauffage
mode: restart
merci pour l’info, j’essaye de configurer pour mes radiateurs en fil pilote sur des sortie de câbles connectées.
Mais est ce que tu pourrais compléter ton explication, car étant novice, je ne vois pas ou placer les fameux switches dans Home assistant.
J’en profite aussi je pense que c’est l’étapes des switches qui me bloque, je n’obtiens pas les modes auto-confort et auto-eco, j’ai en direct la gestion des ordres des fils pilotes
En ligne 12 tu as : entity: select…cable_outlet_mode
===> ca doit etre quelque chose comme ceci : - entity: input_select.chauffage_salon_mode
(c’est le input select que tu crée avec les noms des modes)
Et je ne sais pas pourquoi. Par contre si je passe en manuel, et que je change la consigne, l’ordre est bien pris en compte, et allume bien mon chauffage, c’est un bon signe.
Merci beaucoup !!
en fait les plages horaires sont le « standard » d’une journée et on reprend ce standard en enlevant des °C à la consigne pour le mode eco.
