Bonjour à tous,
J’ouvre un autre débat sur les tores de mesures.
En effet les tores peuvent détecter le sens du courant. Cependant beaucoup de clients ne font pas attention et mettent les tores à l’envers. La encore c’est une source d’erreur. Du coup que pensez vous si on supprime la détection du sens du courant. En gros pour ceux qui font de la production, il faut simplement mettre une pince en sortie de micro onduleur pour la production et on utilise PAPP pour détecter l’autoconsommation.
Bonjour,
supprimer le sens de détection est une bonne idée qui va bien simplifier l’utilisation des tores.
Par contre je pense que décider si on est en consommation ou production doit être un choix sur l’interface pour chaque tore.
Combien de tores possibles, en natif et sur X400 V2?
Bonne journée
On a pas encore pris de décisions sur ce sujet car on a plusieurs choix possible.
Concernant l’attribution des fonctions , c’est ce qu’on a prévu.
L’assignation se fera bien pour chaque tore.
Bonjour,
Supprimer une fonction parce qu’elle est mal compris n’est pas forcément le mieux à faire je pense.
Je n’ai pas encore mis les tore sur mon ED, mais j’ai déjà lu beaucoup de chose là dessus sur le forum et sur la doc. Résultat, je n’ai toujours pas compris dans quel sens ça s’installe.
Je ne me souviens pas avoir vu un schéma expliquant simplement le sens d’installation. Souvent ce sont des mots qui peuvent prêter à interprétation.
Donc à mon avis, garder la fonction (éventuellement désactivée pas défaut) et plus de pédagogie pour expliquer l’installation
extrait de la doc :
- entrer côté K
- sortir côté L pour aller vers le disjoncteur
Si je veux mesurer la consommation d’une ampoule, le courant va du disjoncteur vers l’ampoule, donc je met le disjoncteur coté K (« l’entrée »), Le L étant la « sortie », ça va vers l’ampoule.
Mais la doc nous dit de mettre le disjoncteur coté L !!
Bonsoir,
C’est clair que si la doc n’est pas claire, c’est pas top.
La vrai question qui se pose c’est: Est ce que ça va vraiment servir ?
Car au final la détection du sens du courant, c’est surtout pour détecter la commutation Prod/Conso.
Or cette détection peut etre faite par PAPP par exemple, qui fournit une valeur sure.
Cdt
Bonsoir,
Si l’on parle de l’étiquette PAPP de la TIC du LINKY, celle ci existe seulement en mode HISTORIQUE.
Elle impose aussi le raccordement a la TIC.
Comme @GwenLR j’ai souvenir d’avoir bien vérifié la doc pour la pose du tore, et d’avoir du inverser après coup …
Bonjour,
Personnellement, j’aurais conservé la détection du sens du courant mais en inversant cette détection, si possible, de façon à ce que les tores soient posées sur les câbles comme elles le sont sur d’autres appareils : c’est à dire avec la flèche dans le sens du courant EDF.
Attention, en contrat CACSI / zéro injection, la TIC ne donne pas la puissance envoyée, elle donne uniquement le soutiré qui passe à 0 et le reste pendant tout le temps où on injecte… résultat on ne sait pas ce qu’on injecte.
Et puis un EDRT2 devrait pouvoir fonctionner sans TIC (il y a des utilisateurs qui ne peuvent pas la brancher, car trop éloigné du Linky par ex)
Cette absence de remonté du champ SINSTI m’a longtemps gêné et la sortie de la v3 pour l’EDRT2 était salutaire, car grâce à la détection du sens du courant, j’ai enfin pu « voir » ce que j’injectais en temps réel et adapter mes scénarios d’autoconsommation.
A noter que la définition statique du sens du courant pour les pinces ne me convient pas, car je suis dans l’incapacité d’installer une pince sur ma prod solaire, car celle-ci est branchée au garage sur un tableau divisionnaire (avec d’autres consommateurs)
La détection du sens du courant par la pince reste donc indispensable et est une vraie valeur ajoutée de l’EDRT2 en v3 actuel.
Si ce n’est pas trop compliqué, est-il envisageable de proposer un mode hybride combinant les 2 modes de fonctionnement ?
Par exemple, par défaut la configuration du sens du courant se fait de façon statique (paramètres production/consommation sur chaque pince) afin de ne pas tenir compte du sens de la pince.
Et puis une option permet d’activer la prise en compte du sens de la pince avec détection automatique du sens du courant.
Et l’expliquer clairement dans la doc, un simple schéma avec le sens de la flèche sur la pince est plus efficace qu’un long discours.
Je ne pense pas qu’il faille faire un lien entre la TIC et les tores. Pour moi, c’est plutôt distinct.
J’ai un tore aussi sur l’arrivée Enedis. Et je suis aussi bien les infos de la TIC que du tore, le tore étant plus réactif de fait que la TIC.
Après, j’aime bien l’idée de dire par configuration si le tore est producteur ou pas, c’est bcp plus simple à l’installation je trouve. Par contre, il faudrait pouvoir mesurer le bidirectionnel car chacun a un diagramme de flux différents dès qu’il a des panneaux solaires.
Idéalement, ou via la v5 dans l’idee d’une extension esclave, il faudrait pouvoir faire un schéma de son réseau de type arbre, positionner les tores dessus, configurer leur sens, et avoir de manière automatique la reprensation de la répartition de la conso electrique.
Sur le nombre de tores, 4 est aujourd’hui vite trop peu, on a souvent besoin de 6 ou 8 surtout au tableau principal.
Une autre idée, perso j’utilise souvent les tores juste pour savoir si le consommateur est actif ou si plusieurs consommateurs sont actifs, du coup avoir une virtual IO avec un seuil d’A qui la fait passer à 1 serait top, ça évite de créer une règle dans l’IPX. Et du coup dans un mode esclave, on pourrait décider de paramétrer ce qui remonte ou pas sur le bus EBX, la valeur mesurée, l’IO, ou les 2 selon le besoin.
Une dernière idée plus raffinée :
Pouvoir identifier des patterns de consommation de plusieurs consommateurs sur un seul tore. Je donne l’exemple du local piscine, j’ai un tore qui mesure le départ de la ligne vers le local, l’idée est selon l’intensité mesurée de savoir qui de la pompe, la PAC ou ma pompe de puit est actif.
Dernier point, calculer automatiquement, à minima au niveau de la v5 les différentes valeurs Va Wh … c’est trop compliqué à chaque fois pour les utilisateurs amateurs.
Disposer directement de la valeur instantanée et du compteur cumulé dans la bonne valeur permet de l’intégrer ensuite directement dans home assistant.
Prévoir dans ce cas la subtilité du tore Enedis ou il faut pouvoir paramétrer si on compte l’injection ou pas. Pour les utilisateurs qui sont en CACSI mais ne respectent pas la stupide et d’ailleurs contraire à la loi interdiction d’injection d’ENEDIS.
Bonjour à tous,
C’est un vrai sujet 
Du coup pourquoi ne pas dire si un tore est sur production, consommation ou injection et mettre la détection du sens du courant uniquement sur le tore sensé être sur la sortie linky. Du coup le tore injection compte la consommation totale, sert à avoir l’instantanée et compte l’injecté totale quand il y a surproduction.
Dans tous les cas, le tore qui a la détection du sens du courant est quand même sensé être sur la sortie compteur linky, sinon je ne vois pas où le mettre ailleurs ?
Le truc c’est Il faut bien faire le distinguo entre consommé / Produit / Injecté.
Concernant la télé information ce qui est gênant c’est les tarifs et les multiples abonnements. Ça va nécessiter de faire des maj chaque fois qu’un nouvel abonnement sort. Ça fait des coûts de maintenance vraiment important.
Du coup est ce que mettre le coût en euros, ça vous paraît nécessaire ? Pourquoi ne pas être à fond sur les abonnement et le parsing des index et oublier les tarifs associés. Ça limiterait pas mal les soucis de tarification qui change tous le temps. ?
Oui tout à fait.
Malheureusement ce n’est pas toujours possible, et en l’occurrence ce n’est pas possible chez moi, comme dit dans un message précédent, la topologie de mon réseau électrique ne le permet pas.
Ce n’est pas gênant vu que je récupère la production avec la passerelle de mes onduleurs, mais simplement ça ne remonte pas dans l’EcoDevice.
Il faut donc que l’EcoDevice puisse rester suffisamment générique, comme c’est le cas avec l’actuel firmware v3, pour s’adapter à tous les cas de figure, et ne pas partir du postulat que tout le monde peut placer les pinces à l’endroit idéal du circuit (et dans le bon sens 
)
Personnellement je n’exploite pas les fonctionnalités de suivi des coûts dans l’EcoDevice, c’est ma box domotique Fibaro qui agrège tout cela avec 12 ans d’historique.
Je pense qu’on est très nombreux ici à utiliser une box/logiciel domotique tiers qui concentre toute l’intelligence, il est important que l’EcoDevice conserve la mise à disposition des informations comme c’est le cas habituellement avec l’API, les Push, ou encore MQTT comme évoqué sur un autre topic.
Cette dernière remarque s’applique aussi bien au sujet des indexes de consommation que des puissances instantanées mesurées par les tores.
Dans votre cas l’Ecodevices ne fait que mettre à disposition des données Index, instantanée, abonnement etc… et ne gère pas la prise de décision pour par exemple faire de l’autoconsommation C’est bien ça ? SI c’est le cas alors un mode esclave avec une API vous conviendrait parfaitement…
Oui, ça me paraît bien. Le truc qu’il faut garder en tête dans votre design, c’est que le point de raccordement du producteur PV n’est pas toujours en tête d’installation, par ex, ce qui est mon cas, quand les panneaux sont sur une dépendance. Du coup, dans une branche de l’installation, il peut y avoir un producteur plus gros que le consommateurs, ce qui peut complexifier le positionnement des tores. Du coup une question ? Est-ce que la partie tore ne devrait pas être un module de l’EDRT ? Pour pouvoir en positionner, un ou plusieurs à différents endroits, mais avoir une gestion centralisée avec un seul cerveau.
Ou autrement dit, l’idéal serait en fait que l’EDRT soit une appli dans une v5 et pas un équipement dédié. Est-ce que ça ne serait d’ailleurs pas pour vous plus simple d’avoir une base de code commune de cette fonction sur un hardware v5, quitte à sortir une version tout en 1 pour le marché du plug en play, mais aussi répondre aux besoins des power user qui ont des maisons compliquées ?
Oui en général, mais il y a aussi le cas évoqué au dessus.
Pensez également demain aux batteries des véhicules électriques, on pourra stocker son surplus solaire dans sa voiture, et tirer dessus hors période de production si on le désire. La voiture peut aussi devenir un producteur au coeur de la maison.
Personnellement, je n’utilise pas la partie coût, je la calcule à côté pour des usages très particuliers, comme le coût de recharge de ma voiture électrique. Donc oui, ça me semble suffisant comme proposition.
Effectivement, c’est bien ça.
Clairement je sous-exploite les possibilité de l’EcoDevice car je n’utilise pas du tout son « intelligence », toute la prise de décision est centralisée dans la box domotique qui agrège plein de données (provenant de l’EcoDevice RT2, d’un IPX800, mais aussi d’autres appareils)
Vu sous cet angle, le mode esclave pourrait bien me convenir, tant qu’on conserve l’API disponible via une connexion Ethernet filaire.
Pour répondre à @mcc37 si on pouvait mettre plusieurs tores en mode production
On pourrait additionner ainsi toutes les productions…
Donc en fait il faudrait prévoir des sous comptages de production et un index global production. Idem pour les consommations. Avec ça on couvre quand même pas mal de cas. Pour la partie géographique de l’installation, il faudrait prévoir des tores radios qui pourraient etre développés dans la foulée…
Si vous allez jusque là, ça va couvrir effectivement beaucoup voir tous les cas de figure.