Bonjour,
pour ma part, ce serait également un vote pour le central configuration panel.
Hello @Grogu ,
Tu parles de ces modèles là ?
J’en possède une dizaine également.
Ce n’est pas tout à fait exact. Pour utiliser Vtherm avec les modules FP ADEO,
Vtherm fonctionne en mode Switch (ON / OFF).
Il n’envoie pas de consigne FP (Anti-freeze, Eco, Comfort-1, Comfort-2,etc…).
Vtherm ON => correspond au mode Comfort du module FP ADEO
Vtherm OFF => correspond au mode Anti-Freeze du module FP ADEO.
Enfin, c’est ce que je constate chez moi 
A++
C’est exactement ceux là oui. Et en effet, j’ai le même comportement chez moi. C’est pas un soucis, ça fonctionne très bien comme ça. Je me demandais juste l’intérêt d’avoir un module qui gère le fil pilote au final
Ok Merci. J’ai modifié la configuration pour indiquer la puissance cumulée théorique de mes chauffages du coup. Et pas grave pour les modules, au final c’est Vtherm qui gère bien.
1 « J'aime »
Il faut prendre pleinement conscience de la chance que nous avons d’avoir quelqu’un qui a non seulement développé une superbe intégration, mais qui est aussi à l’écoute et travaille à l’améliorer en permanence…
Merci @Jean-Marc_Collin !
3 « J'aime »
Bonjour Jean-Marc,
c’est a mon tour de te remercier pour cet excellent travail sur le thermostat, l’interface et le suivi de tout ce petit monde !
l’hiver dernier, j’avais un chauffage piloté par le thermostat par défaut de HA et j’ai mis, en fin d’hiver un autre radiateur avec ton thermostat pour me faire la main.
Cette année, j’ai mis tout ma maison sur VTherm (8 radiateurs électriques) pilotés avec des modules ZB ou Wifi par fil pilote
Tout fonctionne a merveille pour le moment et je suis en train d’affiner les réglages pour avoir une chauffe correcte, sans trop monter au dessus de la consigne
j’ai aussi remarqué, comme le poste de @Yannickinlive26 872 que j’avais parfois le message 'internal temp : xxmin", je peut le comprendre sur des sondes zigbee sur pile, mais cela m’arrive aussi sur des sondes branchées, dont je suis certain d’avoir une mise à jour de la température chaque 3mn
j’ai même été obligé de faire un ‹ recharger › sur certains thermostats qui semblaient complètement bloqués en mode ‹ Dangereux ›.
Je me pose une autre question sur l’arrêt des chauffages en cas d’absence, vaut il mieux laisser descendre a 15°, voir en dessous, en sachant que remettre tout en chauffe le soir va forcer sur tous les radiateurs pendant plus d’une heure pour arriver a remonter ou laisser un peitit 17 toute la journée, sachant que çà va chauffer toute la journée, mais le soir la montée sera plus rapide et moins consommatrice. Je suppose qu’il n’y a pas de bonne réponse a cela et que çà dépend du type de chauffage et de la perte thermique de la maison… mais quel est ton avis sur la question ?
en tout cas encore merci a toi
Stéphane
Bonjour,
Quand je crée le template j’ai cette erreur à la vérification:
Invalid config for [sensor.template]: [switches] is an invalid option for [sensor.template]. Check: sensor.template->switches. (See ?, line ?).
avec le code :
sensor:
- platform: template
switches:
bureau_heating:
unique_id: bureau_heating
friendly_name: Bureau heating
value_template: "{{ is_state_attr('climate.bureau', 'preset_mode', 'comfort') }}"
icon_template: >-
{% if is_state_attr('climate.bureau', 'preset_mode', 'comfort') %}
mdi:radiator
{% elif is_state_attr('climate.bureau', 'preset_mode', 'away') %}
mdi:snowflake
{% else %}
mdi:radiator-disabled
{% endif %}
turn on:
service: climate.set_preset_mode
entity_id: climate.bureau
data:
preset_mode: "comfort"
turn_off:
service: climate.set_preset_mode
entity_id: climate.bureau
data:
preset_mode: "eco"
Comme c’est un switch j’ai remplacé le sensor par switch
switch:
- platform: template
switches:
bureau_heating:
unique_id: bureau_heating
friendly_name: Bureau heating
value_template: "{{ is_state_attr('climate.bureau', 'preset_mode', 'comfort') }}"
icon_template: >-
{% if is_state_attr('climate.bureau', 'preset_mode', 'comfort') %}
mdi:radiator
{% elif is_state_attr('climate.bureau', 'preset_mode', 'away') %}
mdi:snowflake
{% else %}
mdi:radiator-disabled
{% endif %}
turn on:
service: climate.set_preset_mode
entity_id: climate.bureau
data:
preset_mode: "comfort"
turn_off:
service: climate.set_preset_mode
entity_id: climate.bureau
data:
preset_mode: "eco"
et dans ce cas j’ai l’erreur suivante :
Invalid config for [switch.template]: [turn on] is an invalid option for [switch.template]. Check: switch.template->switches->bureau_heating->turn on. (See ?, line ?).
A préciser que je suis en mode package dans le configuration. yaml
Je me réponds le code fourni n’est pas correct.
Il manque des tirets devant les services :
switch:
- platform: template
switches:
bureau_heating:
value_template: "{{ is_state_attr('climate.bureau', 'preset_mode', 'comfort') }}"
icon_template: >-
{% if is_state_attr('climate.bureau', 'preset_mode', 'comfort') %}
mdi:radiator
{% elif is_state_attr('climate.bureau', 'preset_mode', 'away') %}
mdi:snowflake
{% else %}
mdi:radiator-disabled
{% endif %}
turn_on:
- service: climate.set_preset_mode
entity_id: climate.bureau
data:
preset_mode: "comfort"
turn_off:
- service: climate.set_preset_mode
entity_id: climate.bureau
data:
preset_mode: "eco"
En revanche comment utiliser ce switch? l'integration demande un climate
Slt…
Effectivement mal écrit dans ton yaml !
Saisie ou ?:
- configuration.yaml ?
- template.yaml [ appelé depuis le configuration avec un include !] ?
- switch.yaml [ appelé depuis le configuration avec un include !] ?
Si tu fais dans le switch.yaml reformule comme
- platform: template
switches:
Bien sûr aligne comme il faut la suite [identation]
Non comme je suis en mode package j’ai créé un radiateur.yaml. et mis le code corrigé au dessus.
En revanche avec mon radiateur heatzy glow cela ne fonctionne pas.
Ok c’est idem…
Mais je comprends pas trop!
- tu lis un état de ton climate [ le preset mode]
- tu fais un switch, qui va modifié la cde de ton climate avec ce switch, donc le preset !
Moi je le fais pour mettre mes radiateurs avec fonction [eco, confort, etc] en concordance pour ne pas faire du ON/OFF, mais en automation !
C’est ce qui me parait étrange. Mais dans la doc c’est recommandé pour les heatzy.
Ok la doc! Je crois que trop bien fait Merci @Jean-Marc_Collin
Donc tu mets ce virtuel comme switch !
Bonjour @Jean-Marc_Collin,
Encore moi avec quelques questions.
- Est-ce que c’est normal qu’un VTherm over_climate où la régulation est sur light réagisse comme ça ?
Voici quelques infos récoltées dans les attributs :
regulated_target_temperature: 15
auto_regulation_mode: auto_regulation_light
regulation_accumulated_error: -10
-
D’ailleurs,
regulated_target_temperatureest bien la valeur de la température cible appliquée au climate sous-jacent n’est-ce pas ? Si c’est le cas, le thermostat régulé par ce VTherm est réglé sur 20 au lieu de 15 (C’était ce matin, maintenant c’est repassé en 19.5 dans les deux). Je pense que je vais créer un capteur pour récupérer la valeur et la stocker pour pouvoir comparer. -
Est-ce qu’un VTherm configuré en over_climate avec 2 climates sous-jacents peut ne pas envoyer la même température de consigne aux deux ? J’ai le cas pour 2 Vtherm chez moi (C’était aussi le cas ce matin. Mais ce soir, c’est le cas sur un des deux seulement).
-
Est-ce que c’est possible d’avoir un VTherm avec 2 climates qui ont des auto-régulations différentes ? Je ne pense pas puisqu’il y un seul attribut d’auto-régulation par VTherm quel que soit le nombre de climates sous-jacents.
Hello @steph96
Merci pour les compliments, ca fait toujours plaisir 
C’est le mode sécurité qui s’active lorsque la température n’est plus reçue. Vous êtes plusieurs à me signaler que des fois le VTherm se met en sécurité et n’en sort pas alors que la température remonte (cf. Security State seems to never stop after having been activated ? · Issue #241 · jmcollin78/versatile_thermostat · GitHub). Le soucis c’est que je n’arrive pas à le reproduire. Comme expliqué dans Github, si ca se produit j’aurai besoin des attributs du VTherm au moment où il semble bloqué et des logs au même moment.
C’est une excellente question. J’avais lu je sais plus où (peut être la notice de mes radiateurs électriques) qu’il fallait pas avoir plus de 3° entre le mode Eco et le mode Confort pour éviter de trop pomper lors d’une remise en température. J’ai mis 17° en Eco et 19° en Confort et 20° en Boost de mon coté. Donc je respecte cette espèce de règle. Si qq’1 en sait plus et saurait étayer cette affirmation, ça m’intéresse beaucoup. Comme tu le dis, je suppose que ça dépend de plein de choses. Avec une forte inertie, je suppose que c’est trop. Si il faut 3 heures pour chauffer et qu’on change toutes les 3 heures, on n’est jamais à la cible et ça me parait pas bon.
Ce que j’ai remarqué aussi, c’est qu’en regime stable, le % de puissance doit être autour de 20% (30% max). On chauffe 20% du temps pour garder la température constante. Ca peut être un signe de bon réglage. Exemple (mais je viens de remettre en Confort):
Clairement, en regardant la courbe non, c’est pas bon. T’es toujours très largement au dessus et pourtant
la temp régulée (celle envoyée au sous-jacent est de 15° pour une consigne à 20 (à priori).
Et les barres oranges (y a pas la légende mais je suppose qu’il s’agit du hvac_action et que c’est orange quand ca chauffe) font n’importe quoi. Ca chauffe quand tu es 4° au-dessus…
C’est quoi comme chauffage en dessous ? (regarde le post en dessous pour y voir plus clair)
1 « J'aime »
Pour y voir plus clair sur les VTherm de type over_climate avec régulation
Y a une super intégration citée dans ce forum qui se nomme Plotly (ici) et qui permet de naviguer dans les courbes de zoomer, etc. Bref, c’est le pied pour comprendre si ça régule bien ou pas.
Voici mon code:
- type: custom:plotly-graph
entities:
- entity: '[[climate]]'
attribute: temperature
yaxis: y1
name: Consigne
- entity: '[[climate]]'
attribute: current_temperature
yaxis: y1
name: T°
- entity: '[[climate]]'
attribute: ema_temp
yaxis: y1
name: Ema
- entity: '[[climate]]'
attribute: regulated_target_temperature
yaxis: y1
name: Regulated T°
- entity: '[[slope]]'
name: Slope
fill: tozeroy
yaxis: y9
fillcolor: rgba(100, 100, 100, 0.3)
line:
color: rgba(100, 100, 100, 0.9)
Remplacez les [xxx] par les entités qui vont bien et vous aurez qqe-chose qui ressemble à ça :
On peut voir sur une même courbe zoomable, déplaçable, etc tout ce qu’on a besoin :
- la consigne,
- la T° courante du capteur,
- l’Exponential Moving Average (la moyenne mobile de la température courante),
- la température régulée (envoyée au sous-jacent),
- la Pente de la courbe (Slope). En positif si ça chauffe et en négatif si ca refroidit.
l’EMA et le Slope sont utilisés pour la détection automatique de portes et fenêtre ouvertes typiquement, mais ça donne pleins d’infos intéressantes sur la vitesse de chauffe d’une pièce, la vitesse de refroidissement quand ça chauffe plus, l’isolation de la pièce, etc.
Par exemple sur ma courbe, quand ça chauffe, je gagne entre 5 et 6° par heures et quand ça ne chauffe pas, cette pièce perd jusqu’à 1° / heure environ, que la température régulée dépasse de 1° la température cible…
Si vous avez des difficultés à faire les réglages, je vous le conseille vivement.
Evidemment il faut installer l’intégration Plotly qui est dispo sous HACS pour l’avoir.
2 « J'aime »
j’ai peut être une piste a creuser a ce sujet,
je viens d’avoir le cas dans ma chambre, avec le mode sécurité qui s’est activé car plus de température depuis 63 min. pourtant je suis sur un wemos connecté qui me retourne la température toutes les 2mn, en regardant ma courbe de température, elle est stable, mais si le capteur renvoir pendant 1h la même température, que se passe t’il ?
est ce que le souci ne pourrait pas venir de là ?
Radiateur à eau équipé d’une vanne Zigbee.
C’est intéressant comme piste oui. Normalement, je prends la dateheure de l’évènement que ca ait changé ou pas. Est-ce que tu es sûr qu’il y a des points de mesure sur la partie plate de la courbe ?
Si oui, est-ce que ce serait possible de passer en mode DEBUG et de me trouver les logs suivants lorsque le problème se produit ? Ce serait génial :
_LOGGER.debug(
"%s - Temperature changed. Event.new_state is %s",
self,
new_state,
)
Comme le mode debug est super verbeux, peut être tu peux changer le _LOGGER.debug par _LOGGER.info et rester en mode INFO.
Pour activer les logs, il faut des lignes comme ça dans la conf (logger.yaml chez moi) :
default: warning
logs:
custom_components.versatile_thermostat: info <----- ou debug en fonction de ton choix