Bonjour,
Je possède un ZLinky Tic depuis peu pour connaitre la consommation électrique totale sur la journée.
J’ai rentré le capteur « sensor.lixee_conso_base » dans mon tableau d’énergie pour m’indiquer la conso totale de ma maison au jour le jour.
Je possède également pas mal de prises connectées et autre pour suivre la consommation d’appareils spécifiques.
J’aimerais rentrer ces appareils dans la section « Réseau électrique » comme pour la Lixee pour pouvoir suivre le prix et non dans la section « appareils individuels » que je trouve moins claire.
Par contre en faisant cela, ça additionne deux fois mes appareils individuels (la lixee les comptabilise également dans la conso totale)
J’ai donc essayé de faire un nouveau capteur en soustrayant tous les appareils individuels au lixee. Je pourrais comme ça ajouter ce nouveau capteur au tableau d’énergie en plus de mes appareils individuels qui seront comptabilisés une seule fois.
Mais j’ai une erreur:
Une idée ?
En espérant avoir été assez claire
Je vous remercie ! 
Salut,
il essaye de t’expliqué qu’il n’aime pas ta config 
Tu as mis quoi en « device_class » de ton nouveau compteur, ça devrait être « energy » comme c’est des kWh.
Pour state_class tu semble avoir mis measurement… mais pas certain que ce soit une bonne idée. ça devrait être « total » ou même rien potentiellement, ça dépend de ce que cette valeur représente… si c’est une sorte de compteur qui ne fait que augmenter, « total » c’est bien. Si c’est un conso journalière, c’est possible que ça passe avec aucun state_class
1 « J'aime »
Merci pour ta réponse.
Il ne l’aime pas, pourtant c’est lui qui l’a créé 
J’ai fait ce capteur en créant une nouvelle entrée via « combiner l’état de plusieurs capteurs » puis « étendu ».
Je vais chercher comment le créer en yaml pour faires des soustractions.
Conso total - Conso prise 1- Conso prise 2… = Nouveau capteur
@AlexHass
Pourrais tu me corriger, j’aimerais creer le capteur X qui est la soustraction de 4 capteurs.
A savoir le capteur Zlinky total Kwh Base (pour la conso totale de la maison) - les Kwh de la prise 1 - Kwh prise 2…
A mettre dans templates.yaml je presume ?
- sensor:
- name: "Capteur X"
device_class: energy
unique_id: capteur_x
unit_of_measurement: kWh
state: >
{{ ( states('sensor.sensor_1') | float(0)
- states('sensor.sensor_2') | float(0)
- states('sensor.sensor_3') | float(0)
- states('sensor.sensor_4') | float(0)) | round(4) }} # c'est bien round 4 ici ? :thinking:
availability: >
{{ states('sensor.sensor_1') | is_number and
states('sensor.sensor_2') | is_number and
states('sensor.sensor_3') | is_number and
states('sensor.sensor_4') | is_number }}
Salut,
la config que tu partages semble ok « techniquement ». Je n’ai jamais vraiment joué avec availability, mais de ce que j’en connais ça a l’air aussi ok.
Maintenant le truc auquel il va falloir faire attention c’est quelles valeurs tu prends. Il faudra des entités qui se remettent à zero à la même fréquence, soit des journalières, soit toutes qui ne se remettent jamais à zero (comme ton compteur électrique)
Sinon ça ne marchera pas.
1 « J'aime »
Je t’avoue que j’ai un peu de mal à comprendre à quoi ça sert "availability"
Ça peut marcher sans ?
Elles ne e remettent jamais à 0. C’est la consomation totale en Kwh de chaque prise connectée.
@AlexHass
Ca semble fonctionner par contre j’ai un message « statistics_not_defined ». J’ai l’impression que c’est par rapport aux statistiques long terme non ?
Une idée pour resoudre ce petit probleme ?
- sensor:
- name: "Autres Consommations Kwh"
unique_id: autres_consommations_kwh
device_class: energy
state_class: total
unit_of_measurement: kWh
state: >
{{ ( states('sensor.lixee_conso_east') | float(0)
- states('sensor.prise_pompe_garage_electric_consumption_kwh') | float(0)
- states('sensor.prise_machine_a_laver_le_linge_electric_consumption_kwh') | float(0)
- states('sensor.prise_seche_linge_energy') | float(0)) | round(4) }}
Encore merci ! 
Est-ce que ce ne devraitt pas être state_class: « total_increasing » ?
Bonne question.
Total seul semble fonctionner…
@axowhite Il me semble que tous les « utility meters » à utiliser dans le dashboard energy doivent être du type total_increasing. C’est le cas chez moi et tout fonctionne. As-tu essayé?
1 « J'aime »
Les 2 marchent, mais effectivement, dans le cas présent celui-ci est « théoriquement » total_increasing, car si les 4 entités ne font elles même qu’augmenter… ça devrait être le cas… mais si dans 2 mois tu ajoutes un autre là il va y avoir un souci…
Sinon le messahe « statistics_not_defined »… aucune idée… mais c’est peut-être lié au fait que c’est un tout nouveau sensor…?
Ou alors faut voir des outils de dev>statistics, s’il y a un souci sur ce sensor…
1 « J'aime »
Merci.
Je vais donc rester sur total car je vais ajouter au fur et à mesure des sensors.
Exact « statistics not defined » a disparu 
@AlexHass
J’ai un problème avec le sensor « sensor.autres_consommations_kwh_cost ».
C’est le sensor qui a était automatiquement créé avec mon capteur créé juste au-dessus.
À chaque redémarrage de HA il m’ajoute des nombres négatifs…
Une idée ?
Je pensais changer la class en total_increasing mais je ne crois pas que l’on puisse le faire sur un capteur créé automatiquement ?
J’ai dû également changer la class de mon capteur « autres_consommations_kwh » créé juste au-dessus, car lui aussi me mettait des kWh négatifs à chaque redémarrage…
EDIT:
J’ai reussi en créant le fichier customize.yaml et:
sensor.autres_consommations_maison_kwh_cost:
state_class: total_increasing
Il ne peut donc plus avoir de nombres négatifs.
Est ce la bonne solution ?
Salut,
c’est effectivement le risque, si certaines de ces entités ne sont pas prêtes au redémarrage, tu peux avoir des valeurs pas bonnes. Il faut peut être ajouter au calcul des vérification pour s’assurer que c’est ok avant de faire la soustraction.
Sinon pour le « total_increasing », ces options indiquent à HA comment le nombre évoluera… mais dans ton cas a part générréer un erreur dans le journal quand ça passera négatij, ça ne fera rien
Mince… Je pensais avoir résolu le problème !
As tu une idée ou une piste pour ces « verifications » avant soustraction ?
