La télé information c’est super pratique, par contre il faut bien reconnaitre que c’est devenu une usine à gaz, a tel point que certains fournisseurs ne mettent meme pas à jour le Linky. La, c’est galère car du coup on enregistre des index au mauvais endroit dans l’Ecodevices. (Problème vu fréquemment avec EDRT2)
Du coup dans la mesure ou aujourd’hui, on peut récupérer les informations par API, est ce toujours utile de récupérer les index via la télé information ?
Par contre je trouve que certaines étiquettes sont vraiment importantes comme PAPP par exemple qui peut servir de balise pour faire de l’autoconsommation
L’autre soucis est le mix va/wh du Linky qui prête vraiment à confusion car PAPP c’est des VA et non des Watts. Le truc c’est que tous le monde n’est pas forcément au courant de cette différence; La encore c’est quand meme un peu le bazar.
Voila j’attend votre point de vu sur cette téléformation
Pour moi la teleinfo est indispensable sur cet équipement. Les infos via API ne sont pas en temps réel et souvent en panne.
La on a l’info en temps réel et c’est super intéressant. Je voudrais les utiliser pour des automatisations mais je ne le fais pas car le dialogue EDRT2 et IPX800 est impossible.
Mon souhait serait que le futur EDRT puisse être autonome ou esclave d’un IPX pour une intégration temps réel des datas de l’EDRT, TIC comprise par le Bus EBX.
Bonjour,
autre cas de figures à prendre en compte : les régies locales d’électricité ne sont souvent pas mis à disposition via l’appli Enedis et pour certaines, elles propose une solution spécifique ou rien.
Chez moi E.S.= Electricité de Strasbourg dispose de sa propre entité de réseau et ne permet pas d’autre télérelève que la TIC !!!
Il y a d’autre régie locales partout en France…
Je voudrais les utiliser pour des automatisations mais je ne le fais pas car le dialogue EDRT2 et IPX800 est impossible.
Les Push fonctionnent très bien et tu peux pousser les informations que tu souhaites dans un IPX pour les y traiter.
Les scénarios de l’EDRT2 permettent d’actionner les sorties relais internes ou via Push une sortie Relai d’un IPX.
Si tu es plus à l’aise dans la partie programmation v4 ou v5, alors c’est plus un EcoDevice light dont tu aurais besoin qui serait une extension d’un IPX mais sans la partie traitements et actions ???
j’aime bien l’idée de faire un EDRT sur le principe du X-Pool, c’est à dire un module qui pourrait fonctionner de façon autonome avec quelques fonctions standard (HC/HP, délestage,… ) et, pour celui qui voudrait aller plus loin, connecté par le bus comme une extension d’une V5 .
Très interressant, ça permet d’avoir une vision plus réaliste du terrain.
Faire un module qui peut passer en esclave, c’est une bonne idée mais pour un ecodevices, ça fait quand meme un sacré paquets de données…va falloir bien formater l’API
Je pense également que la TIC est indispensable.
La possibilité aujourd’hui d’éditer, d’ajouter des étiquettes permet de faire presque tout.
On l’a vu récemment encore en pouvant remonter des alertes de la couleur du lendemain dans le mode STANDARD alors que cette étiquette n’existe pas en clair.
Il ne manque pas grand chose pour gérer des abonnement spécifiques, en donnant la faculté de créer des « abonnements » pour faciliter la gestion des abonnements multiples compte tenu de l’ouverture du marché.
Concernant les VA et Wh, effectivement c’est vite compliqué.
Mais ce qui peut être le plus gênant, c’est les écarts de mesures entre la TIC et les TORES.
Déjà, les mesures des tores devraient être moyennées sur les mêmes spécifications que le LINKY pour éviter le ballotage des mesures.
Peut être, se servir de la mesure du TIC pour « améliorer » la mesure des TORES. En partant du postulat effectivement que la mesure de référence est celle du TIC, probablement parce que c’est celle que l’on paye.
Il faudrait également améliorer le RFPULSE et ou tolérer un ETL tiers pour remonter la TIC en non filaire.
Le couple RFPULSE EDRT2 ne fonctionne pas avec les abonnement TEMPO, production …
Il serait intéressant que le module puisse être alimenté par le LINKY et que ce module conserve la faculté de traiter aussi des compteurs a impulsion notamment pour remonter un compteur GAZPAR.
La mesure des tores sera beaucoup plus précise que celle de EDRT2 grâce a un chipset dédié.
Par contre il y aura toujours un petit delta entre l’index de TIC et l’index d’une pince mis sur le général.
Dans la mesure ou les index sont en kw/h, pourquoi ne pas tout faire en Watts et oublier les VA.
Concernant un ETL, on s’interdit pas de faire un RF PULSE 2
Bonsoir,
La conservation de la TIC le semble indispensable aussi. C’est ce qui m’a fait découvrir l’EDRT2
L’appel des API externes repose sur trop de facteurs externes et n’est pas en temps réel. Pour gérer le délestage de la maison ca risque d’être compliqué
C’est tentant et j’ai longtemps pensé la même chose… jusqu’à ce mois de janvier, la petite vague de froid et les multiples jours Tempo Rouges consécutifs, pendant lesquels j’ai massivement décalé mes consommateurs en HC.
Résultat, chaque nuit, j’étais à la limite de mon abonnement (9 kVA soit 45A) et j’ai dû jongler pour ne pas faire sauter.
Dans un scénario d’optimisation du max soutirable / délestage, la surveillance de la puissance apparente reste importante. Enfin, plutôt du courant pour être précis, c’est le calibre du disjoncteur qui fait office d’arbitre.
En dehors de cet usage un peu particulier, clairement il vaut mieux faire abstraction de la puissance apparente et ne regarder que les puissances active (W) et énergies actives (kWh), car seule celle-ci est facturée.
Pour revenir à la question initiale, il serait top de pouvoir faciliter la transmission de la TIC vers une autre solution domotique (box/logiciel). Par exemple avec des requêtes HTTP ou un flux MQTT.
Le pb de la TIC en MQTT, c’est que ça change trop vite et va nécessiter beaucoup de mise à jour côté souscripteur, pas certains que tous suivent, et on a souvent un seul broker pour tous les paramètres.
Pour moi, une des caractéristiques les plus importante des produits GCE, c’est la gestion local des donnée.
Faire appel à un serveur distant pour relever une information qui se trouve à quelques mètres casse cette caractéristique.
Donc pour moi, il faut garder cette fonctionnalité.
Je rejoins la majorité des avis sur la partie Electricité sur ce que doit comporter l’ECO RT3… la gestion de la TIC pour conserver cette acquisition locale des données, avec gestion des différentes offres populaires (HP/HC, TEMPO). A la rigueur avec une option pour aller chercher dynamiquement les évolutions tarifaires par API… et donc pouvoir réactualiser seuls les prix dans le suivi économique. A date, toute réactualisation du prix s’opère aussi sur les consommations antérieures… ça fausse tout.
Continuer de développer/améliorer la partie Autoproduction/Consommation.
Etendre la période de conservation des données (4 ans il me semble), et améliorer l’export des données et améliorer le dialogue/récupération de données par API Restful dito IPX800 v5.
D’ailleurs j’aime beaucoup la suggestion de @grocrabe d’envisager cette v3 sur le modèle du X-POOL, autonome pour les fonctions de base et plus évoluée en mode esclave d’un IPX.
Sinon autre aspect, conserver les entrées pour compteurs incrémentaux. J’utilise l’ECO RT2 pour mon acquistion des compteurs eau (un sur Eau Potable, l’autre sur Récup Eau Pluviale).
En fait il faut gommer la frustration de ne pas pouvoir faire la même chose en matière de comptage d’énergie entre l’EDRT et la v5. Par ex, mon EDRT est dans une dépendance au compteur électrique, et ma v5 dans le tableau de ma maison.
Du coup, les tores de la v5 ne me permettent pas de calculer la conso facilement, mais uniquement de monitorer l’intensité.
Je vote pour aussi…
le mode « extension V5 » permettrait à un plus grand nombre d’entre nous des dialogues entre IPX et RT3… on est pas tous informaticiens…
Je vote aussi pour !
Pour moi tout le module devrait pouvoir être une extension de l’IPX.
Je rajouterai qu’il serait bien que RT3 est nativement une com en radio (MESH) et un module autonome pour la TIC .
Il faut pas oublier que les PUSH et API utilise le réseau ; ce qui augmente le risque d’anomalie même en étant ondulé.
