Oui c’est que l’energie n’était pas encore disponible. Ca peut arriver de façon très temporaire au démarrage et dans ce cas là on met « unavailable » dans l’état, qui n’est pas un entier. Ca évite d’avoir des 0 tout d’un coup dans tes graphes ce qui va polluer le dashboard energie.
{% set energy = state_attr('climate.convecteur_lou_ann', 'total_energy') %}
{% if energy == 'unavailable' or energy is none%}unavailable{% else %} <--- vous etes ici
{{ ((energy | float) / 1.0) | round(2, default=0) }}
{% endif %}
Bon y a un énorme piège:
une date heure comme ça : 2023-02-18T19:36:44.830063+00:00 est en UTC (Donc Paris time - 1h en ce moment en France),
alors qu’une heure comme ça: 2023-02-18T20:58:16.023186 est en heure locale.
Le +00:00 donne la timezone et je me suis fait avoir a mon propre piège.
Il n’y a donc que 22 min entre les 2 dateheures et non pas 1h22.
C’est juste un problème d’affichage, les calculs sont bons car tout est converti en UTC avant les calculs, et ça change rien aux explications que j’ai données au dessus. Je vais changer ça dans la prochaine release.
Autre point important si des fois ce n’était pas clair : le capteur de température extérieur est pris en compte dans le mode sécurité. Il faut que les 2 capteurs soient à jour, sinon sécurité.
Autre info importante sur les courbes figées.
courbes figées peut vouloir dire que l’historique (qui sert aux courbes) n’est plus alimenté.
Et ça ça se configure dans la section recorder de votre configuration.yaml.
Si vous avez ajouté le bout de configuration que j’ai donné plus haut:
recorder:
include:
domains:
- sensor
Il se peut que ça vienne de là. Il faut adapter ce que vous avez déjà pour être sur que le sensor soit archivé et pas forcément simplement recopier ce bout de config (surtout si vous avez déjà une section recorder quelque-part).
Chez moi je suis configuré comme ça:
configuration.yaml: recorder: !include recorder.yaml
parce-que je liste explicitement ce que je veux archiver pour diminuer la taille de la base. Ce n’est pas forcément votre cas et il faut adapter à votre configuration.
Pour votre info et grace à l’aide précieuse de @frankb, un bug sur les timezone a été fixé en release 2.3.0.beta3.
Le bug provoquait un passage en mode sécurité intempestif. A priori ça ne le fait que sur certains thermometre pour lesquels le timestamp du sensor n’était pas comme les autres.
Donc si vous constatez une incohérence dans les états sur les dates heures des températures, vous êtes certainement concernés: last_ext_temperature_datetime: 2023-02-18T18:18:12 last_temperature_datetime: 2023-02-18T18:18:12 last_update_datetime: 2023-02-18T19:19:39. <— une heure d’écart
Toutes les date heures sont maintenant en timezone locale, ce qui est beaucoup plus simple à lire et à comprendre.
Encore merci à @frankb pour son aide sur le sujet.
Oui. Normal, c’est pas encore dans la doc mais il faut avoir la gestion de la puissance pour pouvoir donner une puissance de consommation à ton radiateur lorsqu’il est allumé.
C’est ça qui manque ici. Donc tu coches la case « Gestion de la puissance » et tu donnes une puissance ton radiateur. Ca devrait remettre le truc.
je vais corriger le message pour avoir qqe-chose de plus propre.
Ok, mais pourquoi devoir cocher gestion de puissance si on veut pas s’en servir ?
Edit 22/02/23:
J’ai cocher gestion de puissance, j’ai rien configurer sur les entités et laisser par défaut ( mon chauffage tourne a 1000w, j’ai laisser sur 1 la puissance de l’équipement ) et j’ai sauvegarder et recharger le thermostat.
Je ne reçois plus d’erreur, mais si je reconfigure le thermostat la gestion de puissance n’est pas cocher.
donc juste le faite de cocher l’option et sauvegarder, supprime l’erreur.
Faudrait le renseigner dans la doc ou modifier c’est façon de gérer la puissance si l’utilisateur veut pas sans servir.
Les valeurs par défaut pour coef_int et coef_ext sont respectivement : 0.6 et 0.01. Ces valeurs par défaut conviennent à une pièce standard bien isolée.
Pour régler ces coefficients, gardez à l’esprit que :
1. si la température cible n’est pas atteinte après une situation stable, vous devez augmenter le coef_ext (le on_percent est trop élevé), 2. si la température cible est dépassée après une situation stable, vous devez diminuer le coef_ext(le on_percent est trop bas)
Ce n’est pas l’inverse ? Si la température cible est dépassé c’est que le on_percent est trop haut ?
J’ai finis isoler une chambre en RE 2020 : la température dépasse la cible pourtant le radiateur est à 0 de puissance . ( la baisse de température c’est l’ouverture de la fenêtre )
Tu corrigerais quel paramètre afin d’avoir encore un one percent plus faible avant l’atteinte de la cible
J’avoue que j’ai du mal à comprendre tes courbes. C’est jamais stable. Au bout d’un moment c’est censé être stable et c’est qu’on peut ajuster. Là ca bouge tout le temps avec des gros écarts. Il a du se passer un truc vers 16h non ? Ca a chuté jusqu’à 16,8 alors que ça s’est remis à chauffer 1h avant.
Au début, lors de la montée en température, la puissance varie trop vite et tu dépasses la consigne de près d’1/2 degré. Je commencerai par baisser coef_int. Essaye 0,4 peut être.
Après il faut attendre une période stable pour en savoir plus.
Hello !
Pour ceux à qui cela intéresse, je vous partage une petite amélioration de l’affichage du thermostat et des courbes via apex-chart avec 2 onglets en utilisant tabbed-card
Oh tu peux le reprendre sans me citer, je n’ai aucun mérite !
La puissance est affichée, tu le vois sur la 1ere capture, l’icône éclair qui est à 0 (je ne l’avais pas précisé…)
Oui l’idée de faire un 3eme onglet énergie ça peut être intéressant ! je vais fouiller ça
Salut de même pour moi, après avoir installer sur 4 de mes convecteurs et en beta 3 rien a remonter ca tourne très bien.
Question : est ce que , ca serais pertinent d’avoir un confort + dans les réglages possible ?
exemple dans la chambre de la petite :
j’ai 18.5 en eco (absence ) 19.5 confort et 21 booste
pour un meilleur confort (ca chambre est plutôt fraiche a la base)
je voudrais pouvoir mettre eco 18 confort 19 confort + 20 et boost a 21
je m’aperçois que je suis souvent en bascule a gérer de 19 a 19.5 suivant le court de la journée pour un meilleur confort dans la maison
Ou tout simplement utiliser le réglages Boost et le mettre a 20 car c’est rare de monter plus haut sauf humidity extérieurs.
J’ai pas bien compris le pourquoi du comment du confort+. Si tu as besoin de 20° occasionnel je vois plusieurs possibilités avec l’existant:
tu passes en manuel et tu mets 20°. Au prochain changement de preset automatique, ça se remettra en mode preset avec la valeur programmée (si tu as un scheduler ou équivalent),
tu assignes 20° au boost et tu passes en boost (mais tu perds le 21 du coup),
Tu changes la température du preset confort avec le service qui sert exactement à ça. Regarde dans la doc au § Services. Ca permet de changer la température d’un preset et si le preset est sélectionné, ca change tout de suite la consigne.
Je préfèrerai que ca aille avec les possibilités existantes plutot que de rajouter un preset qui va servir assez peu j’en ai peur.
. ( la baisse de température c’est l’ouverture de la fenêtre )
