Tout est dans le titre !
Pensez vous que le support de capteurs de température soit impératif ?
Bonjour GCE,
pour mesurer quoi?
T° air, T° du chauffe-eau, … ?
Connectées comment? bus? 1Wire?
Plus les questions émergent et plus je suis convaincu que GCE va nous faire un produit sympa et abouti… 
Bonne journée
Bonsoir @grocrabe
L’objectif c’est de ne pas se perdre dans des fonctions qui finalement vont être utilisées par une minorité.
Maintenant si des clients ont des cas concret ou l’usage d’un capteur de température est impératif dans un gestionnaire d’énergie, je suis preneur 
En ce qui me concerne, je trouverais ça bien utile.
De là à dire que c’est impératif, non quand même pas. Mais si ça ne complexifie pas trop le développement, c’est toujours bon à prendre. Ou alors via un module externe optionnel.
J’ai déjà une sonde dans mon cumulus, mais ça pourrait me servir pour monitorer mon coffret réseau tout à coté du tableau électrique. Avec un ventilateur sur une sortie relai, on pourrait se faire une régulation de température basique très simplement.
Perso, pas de cas d’usage.
1 « J'aime »
Bonjour à tous,
pour moi la seule température indispensable dans un modèle de suivi de la performance énergétique c’est la température extérieure.
Cela permet d’évaluer correctement la rigueur de l’hiver qui impact les consos énergétiques
Pour l’instant c’est dispo via une XTHL connectée.
Cela pourrait également être récupéré par un PUSH dans un autre IPX en réseau, mais il faudrait avoir des analogiques virtuelles…
Ce qui manque aujourd’hui dans les EcoRT c’est la possibilité de flaguer les compteurs qui sont ou non contributif du chauffage pour observer l’efficience énergétique.
La proportionnelle avec les heures et jours qui passent n’est pas 100% pertinente si on n’intègre pas l’ensoleillement et la rigueur…
1 « J'aime »
Bonjour @Yoko
La température extérieure est récupérable avec une API…
Ce serait pas mal, par contre, d’ enregistrer la température extérieure pour faire une corrélation avec l’énergie consommée en superposant la température avec une courbe de consommation de chauffage. ça donnera une idée de l’impact de la température extérieure sur sa consommation ce qui est déjà très bien. Je ne pense pas que ce soit pertinent d’allez plus loin sur ce genre de produit.
1 « J'aime »
Bonjour,
La température extérieure historisée est également importante pour comparer la consommation d’une année à une autre.
Il faut garder la compatibilité avec le XTHL, la température extérieure est liée à la conso pour le chauffage. Bien sûr on peut n’enregistrer que la température moyenne de la journée, pas besoin d’un suivi par 5 minutes.
cela signifie que l’EDRT3 aurait besoin d’un autre appareil pour la récupération d’une température locale, sinon il faudrait se contenter d’une donnée météo qui ne correspond pas toujours à la donnée locale. Cela fait perdre la précision d’analyse. Dans les 2 cas je ne suis pas fan.
1 « J'aime »
Oui et une température extérieure par API ne permettra pas d’être reprise dans un scénario pour changer le mode de délestage ou autre…
Bonjour,
Il s’agit d’un outil pour la suivi de la consommation / production…Pas forcément un outil pour gérer son chauffage.
Les scénarios doivent etre simples et focus sur la conso/prod.
Je produit trop → Je déclenche des postes de consommation
Je consomme trop → Je coupe certains postes de consommation.
La température doit rester simplement un marqueur pour comprendre sa consommation.
On est daccord, et ce marqueur pourrait être relevé par l’EDRT3 pour plus de pertinence et d’autonomie.
Oui mais on va aussi prévoir de pouvoir injecter la température depuis une ipx ou un capteur lambda.
Ça évitera la multiplication de capteurs .
2 « J'aime »
oui, mais comme dit plus haut je ne suis pas fan
Moi je suis fan 
Pas facile de contenter tout le monde !
Moi ce que j’en dis c’est qu’il faudra encore recourir à des outils externes simplement pour l’analyse des données, et je trouve ça dommage, d’autant que l’edrt2 supportait déjà le xthl.
@fgtoul je crois que tu n’a pas compris
1: On prévoit 1 ou 2 entrées pour X-THL mais ce ne sera que pour corréler la température avec les mesures. (Pas de scénarios)
2: On prévoit une API pour injecter une température depuis un appareil tiers. Cette température sera logué avec les mesures de conso (Pour ceux qui ont déjà un capteur en extérieur et une IPX800 par exemple).
3: On intègre Open weather pour ceux qui préfère avoir la température de la météo.
Comme ça c’est complet non ?
1 « J'aime »
je ne crois pas avoir parlé de scénario non plus
donc on souhaite la même chose
avec plus d’infos, on arrive à mieux se comprendre car j’étais resté sur le fait que l’EDRT3 n’aurait pas de capteur de temp en local mais seulement par API.
1 « J'aime »
Je trouves que 2 entrées c’est bien et cela peut servir dans un cas précis pour moi : la ventilation pour réchauffer l’air intérieur en journée ou le rafraichir la nuit avec des scénarios simples
TempConsigne =20
-
SI TempInt < TempConsigne ET TempExt > TempConsigne ALORS
ON VentiloExtVersInt
SINON
OFF VentiloExtVersInt -
SI TempInt > TempConsigne ET TempExt < TempConsigne ALORS
ON VentiloExtVersInt
SINON
OFF VentiloExtVersInt
C’est aussi une belle économie d’énergie et qui met en plus l’intérieur de la maison en surpression ce qui repousse l’humidité vers l’extérieur !
2 « J'aime »
Bonjour,
C est malin, facile et efficace
pas si simple car il faudra gérer les saisons dans les scénarii, sinon la maison sera invivable (trop chaude l’été, trop froide l’hiver)
les ventilos vont changer sans arrêt le sens du flux d’air mais ce sera inefficace sans saisonnalité (la température intérieure s’équilibrera avec l’extérieur. ;), pas sûr non plus que cela fasse des économies de chauffage 