Je reviens sur cette partie qui pourrait intéresser plusieurs personnes (dont moi) :
J’ai commencé à rédiger le besoin ici : Add the device power and device energy into attributes · Issue #25 · jmcollin78/versatile_thermostat · GitHub
et je me rends compte que ça ne va pas être aussi simple dans certains cas.
Si l’équipement plioté à une puissance constante lorsqu’il est on, c’est facile et je pourrais tout à fait exposer un attribut device_power calculé comme : device_power * on_percent. Ca serait la puissance moyenne sur le cycle.
Pour rappel, device_power est donné dans la configuration de la gestion de la puissance (page 6).
Je pourrais aussi tout à fait exposer l’énergie consommée comme étant : somme (device_power * cycle) en kWh.
Ca me parait simple mais (parce-que y a un mais) : ca ne peut marcher que si la puissance de l’équipement piloté est constante dans le temps. Ma clim reversible par exemple, n’est pas du tout constante et le calcul sera faux:
Donc la question c’est est-ce que c’est acceptable d’exposer une valeur potentiellement pas très juste voire fausse dans le cas d’une clim par exemple ?
Chez moi, tous mes switchs sont équipés de ‹ Power mesurement › (Shelly ou Sonoff) donc j’ai une mesure juste fourni par le switch lui même.
bonjour @Jean-Marc_Collin, en effet, cela ne s’applique pas à tous type de chauffage, peut être ajouter l’option avec un message spécifiant les restrictions (puissance constante, radiateur, …) ?
De mon côté, ayant un radiateur de 2000W, j’ai fait plus ou moins ce que je voulais avec quelques sensors et template, pour convertir la durée en Kwh puis en euros, si ça peut aider et que je me soit pas planté dans les calcul, ça donne :
sensor :
# Temps d'allumage du radiateur
- platform: history_stats
name: Chauffage (Durée Aujourd'hui)
entity_id: switch.radiateur
state: 'on'
type: time
start: '{{ now().replace(hour=0).replace(minute=0).replace(second=0) }}'
end: '{{ now() }}'
# Conso Journalière
- platform: template
sensors:
chauffage_conso_jour:
friendly_name: "Chauffage (Conso Aujourd'hui)"
value_template: "{{ states('sensor.chauffage_duree_aujourd_hui')| float * 2}}"
# Temps d'allumage x 2 (radiateur de 2000W) = conso en KWh
unit_of_measurement: "kWh"
unique_id: chauffage_conso_jour
# Coût Journalier
- platform: template
sensors:
chauffage_cout_jour:
friendly_name: "Chauffage (Coût Aujourd'hui)"
value_template: "{{ (states('sensor.chauffage_duree_aujourd_hui') | float * 2 * states('input_number.linky_cout_kwh')|float)|round(2) }}"
# Temps d'allumage x 2 (2kw soit 2000W) x 0.19cts = coût en €
# "input_number.linky_cout_kwh" est réglé à 0.19 (prix moyen du Kwh dans mon cas)
unit_of_measurement: "€"
unique_id: chauffage_cout_jour
Dans lovelace , ça donne ça :
Puis j’ai aussi ajouté des utility_meter pour historisé la conso et le coût :
Un autre suggestion d’amélioration, serait d’ajouter la possibilité de renseigner deux sonde de température et que le thermostat prenne en compte la moyenne, ça éviterais de faire un capteur supplémentaire min/max/mean comme j’ai fait pour gérer deux sondes
Merci en tous cas pour ton investissement sur ce beau projet déjà très aboutie
Beau résultat. Par contre, si tu as les heures creuses / pleines ou l’offre TEMPO les calculs sont beaucoup plus compliqués. Tes calculs fonctionnent avec un cout fixe par jour je pense.
La où je pourrais très facilement aider c’est sur le calcul de la durée d’allumage et la conso du jour où ce serait possible de fournir des valeurs approchées par le thermostat lui-même. Je réfléchis à y faire qqe-chose car j’ai aussi des templates, des utility-meter, des intégrales de Riemann, etc ce qui complexifie pas mal la gestion de l’énergie avec Home Assistant.
Le résultat dans le custom:simple-thermostat est très propre et me donne des idées. Bravo !
Un autre suggestion d’amélioration, serait d’ajouter la possibilité de renseigner deux sonde de température
Ca me parait très spécifique a ton cas et je ne pense pas y faire qqe-chose. L’idée d’un helper qui fait la moy/min/max est certainement la bonne dans ton cas.
… et merci pour les compliments, ca fait toujours plaiz
Tarif Fixe dans mon cas en effet, et oui oui j’ai bien vu le device_power, je pense que c’est la première pierre pour cette fonction mais pour une puissance constante effectivement, l’ajout de la fonction avec mention « puissance constante uniquement » serait déjà un premier pas.
Pour les HC et HP c’est plus compliqué et faudrait pas mal de sensor mais réalisable (pas simplement ) d’après ce que j’avais pu lire sur le net. Sur le blog de @mycanalettoil y a ce post qui traite le sujet, ça peux aider pour les calcul
@Bob intéressant, dans mon cas (avec un sensor min/max/mean) si un capteur reste bloqué à une température (car plus dispo) la moyenne est faussé, avec ton code ça changerais rien si je comprend bien car le capteur serait plus dispo mais une temp toujours connu de HA ?
L’idéal serai que si la T° d’un des deux capteur n’a pas changer depuis un certain temp alors on bascule de la moyenne vers un autre capteur.
Oui moyenne si les deux capteurs OK, sinon je prends celui qui est OK (sur ESP32), sinon je bascule sur le Aqara Zigbee.
Sur ESP32 si souci ils sont « unavailable ».
Dites moi si ça vous intéresse ou si vous avez d’autres idées / précos pour cette fonction, y a peut être mieux à faire que de faire un climate sur un climate (puisque concrêtement c’est ça qui va se passer).
En français:
Nous voulons pouvoir utiliser un VersatileThermostat sur une entité climate existante qui contrôle le une climatisation ou autre.
Pour que,
le thermostat sous-jacent bénéficiera des fonctionnalités du thermostat polyvalent,
chaque entité climatique pourra bénéficier des fonctionnalités du Versatile Thermostat
la mise en oeuvre restera simple
Pour ce faire, nous devons configurer :
une première page avec le nom et le type VersatileThermostat (climatisation sur interrupteur ou climatisation sur climat) et les fonctionnalités dont nous avons besoin pour ce thermostat (fenêtre, mouvement, puissance, présence),
avoir une deuxième page qui peut configurer le commutateur de climatisation contenant la configuration du capteur de température, du cycle et de l’algorithme
avoir une deuxième page pour le climat sur le type de climat. Dans cette page, nous devrions configurer le climat sous-jacent et peut-être d’autres options (non identifiées maintenant)
les pages suivantes ne s’afficheront que si les fonctionnalités ont été revendiquées pour ce thermostat
Cela ne devrait pas être très difficile à mettre en œuvre.
Option :
devons-nous implémenter une entrée de configuration V2 et une migration entre elles ?
il devrait être préférable d’implémenter également l’entité Suggérer/sélectionner dans une liste sur les écrans de configuration Problème #16
Problèmes/questions potentiels à résoudre :
remplacer les presets ou utiliser des presets sous-jacents ?
la gestion de la presence, remplace la température des preset. S’il s’agit de preset sous-jacents, ils ne peuvent pas être mis à jour à priori.
→ remplacement des éventuels presets du sous-jacents par les notre ??
Bonjour à tous,
Bravo pour ce thermostat.
Une idée, pour ceux qui n’ont pas de capteur d’ouverture fenêtre/porte, est-il possible de mettre en option qui vérifie les variations de température.
Ex.: si la température baisse de 1° en 15 min alors que le chauffage est en route, alors le système suppose qu’une porte/fenêtre est ouverte.
Si aucune action de l’utilisateur n’est faite au bout d’un certain temps, le régulateur se remet en route.
Faudra qu’on se définisse des critères (comme -1° en 15 min par exemple), les conditions de retour à la normale (un certain temps ? combien ? la température remonte ?), l’aspect paramétrable de ces critères ?
Oui intéressant et comment on déclencherait ce boost temporaire ? On va manquer de bouton d’action. Ou alors par un service mais ça oblige à se développer son propre bouton.
Les hvac-mode ne sont pas paramétrables. Si tu vois une intégration qui en a plus, ca m’interesse que tu me dises laquelle, j’irai voir comment ils ont faits.
Salut, oui ça doit être possible mais là c’était plus une suggestion d’amélioration du thermostat
Via un automatisme ça sera pas forcément simple dans la mesure ou il faudrait prendre en compte le mode avant l’activation du mode Boost puis revenir sur ce même mode après le délais de 1H sauf si via sheduler le mode à changer, ça risque d’être compliqué
) d’après ce que j’avais pu lire sur le net. Sur le blog de 
