Tout d'abord, merci pour le travail réalisé sur le routeur solaire.
J'essaie actuellement de l'intégrer dans une installation Home Assistant et je pense avoir mis en évidence un comportement qui pourrait être un bug ou une limitation du firmware.
Mon installation
Ma mesure de puissance est réalisée par un Shelly Pro 3EM.
Toutes les données énergétiques sont centralisées dans Home Assistant.
Je possède également une Zendure SolarFlow SF2400 AC dont la gestion de l'autoconsommation est laissée en mode automatique.
Le routeur n'est pas encore déployé en production : je suis actuellement en phase de tests afin de valider son intégration.
Pourquoi j'utilise MQTT comme source de puissance:
Même si je dispose de la mesure du Shelly Pro 3EM, j'ai choisi volontairement de ne pas envoyer directement cette mesure au routeur.
À la place, Home Assistant exécute un script qui calcule la puissance réellement disponible à router, puis l'envoie au routeur via MQTT (Puissance_Maison).
L'objectif est de ne router que le surplus réellement disponible, sans que le routeur ne vienne solliciter la batterie Zendure. Cette approche me permet de maîtriser entièrement la logique de pilotage depuis Home Assistant tout en laissant la gestion interne de la batterie en mode automatique.
Le routeur reçoit parfaitement cette puissance MQTT et la régulation semble fonctionner correctement.
Mon objectif
Je souhaite utiliser les deux sondes DS18B20 du routeur :
une sonde placée dans le chauffe-eau ;
une seconde sonde placée dans le panneau solaire de préchauffage, installé en amont du chauffe-eau.
Ces deux températures sont très importantes pour Home Assistant. Elles me permettront d'adapter les priorités énergétiques de façon intelligente.
Par exemple, si la température du panneau solaire est suffisante, je peux laisser le préchauffage solaire faire son travail et éviter de consommer inutilement de l'électricité.
Mon objectif est donc de combiner les informations du routeur avec les autres données énergétiques de l'installation afin d'optimiser au mieux l'autoconsommation.
Le problème rencontré
Lorsque Source des mesures = MQTT :
le routeur reçoit correctement les messages MQTT ;
la régulation fonctionne normalement ;
Home Assistant découvre automatiquement le routeur via MQTT Discovery ;
les entités sont bien créées.
En revanche, aucune donnée d'état n'est ensuite publiée :
températures des sondes DS18B20 ;
puissance du routeur ;
état du routeur ;
etc.
Les entités restent donc sans valeur dans Home Assistant.
Vérification
Si je passe temporairement la Source des mesures sur NotDef (ou une autre source), puis que je redémarre le routeur, les publications MQTT reviennent correctement.
Le comportement semble donc spécifique au mode Source = MQTT.
Suggestion
Serait-il possible de rendre indépendantes :
la réception de la puissance via MQTT ;
la publication des états du routeur (températures, puissance, état, etc.) ?
Cela permettrait d'utiliser Home Assistant comme superviseur énergétique tout en conservant le retour d'information complet du routeur.
Je pense que ce cas d'usage va devenir de plus en plus fréquent avec les batteries domestiques (Zendure, EcoFlow, etc.), où Home Assistant orchestre les priorités énergétiques et fournit au routeur une puissance déjà calculée.
Je serais heureuse de pouvoir tester une éventuelle correction ou version bêta si cela peut être utile.
Encore merci pour votre excellent travail et pour le temps consacré au développement du routeur.
L'installation des panneaux est bloquée...........administrativement!
Qui l'eût cru?
Bon c'est pas le sujet.
J'ai réalisé deux routeurs , un de lecture sur linky et un de pilotage chauffage.
Les deux en version 13.3........pas taper j'avance plus sur ce sujet en attendant l'autorisation.
Le système fonctionne parfaitement depuis de longs mois, les transferts de mesure et tout ce qui peut à ce stade.
Merci André au passage pour ce boulot extraordinaire!!!
Depuis qques temps j'ai remarqué sur le routeur chauffage, donc celui qui reçoit les données du routeur linky, que la courbe " jour sur 1 an" m'affiche des valeurs journalières de "0" alors que celle du linky m'affiche une valeur plausible.
J'ai aussi remarqué des messages (des piles de messages) d'erreur sur le routeur linky:
Erreur checksum code "sinsts"
Erreur checksum code "east"
Et sur le routeur chauffage pareil des piles de messages
Connexion sur esp rms (ip du routeur linky) failed.
Si je déconnecte le routeur chauffage ça revient mais ça recommence qques joours plus tard.
Dans les paramètres je n'ai rien de rien bidouillé depuis que ça fonctionne cad des mois.
A part remplacer le routeur cause de wif qui déconnerait, si qq'un a une idée je reste preneur.
Bonsoir à tous
J’ai remarqué que le routeur se met en marche ce soir alors qu il est prévu qu il fonctionne de 13h00 à 17h00
Ai-je mal programmé la plage de fonctionnement ?
Je joins des photos pour que vous puissiez m aider
Pour info la led rouge ne clignote pas dans ce cas précis
Merci encore
Bonjour, lors des redémarrages de ma box suite à ,coupures, MàJ, ect.., mes routeurs déportés et connectés sur un répeteur wifi reviennent toujours se connecter sur le serveur, qui pourtant a un signal plus faible. je suis donc obligé de faire un scan réseau pour les rediriger vers le répeteur. y a t'il un moyen de corriger cela. je suis sur la version 16.10 et la box est une freebox pop.
Bonjour
J'ai un projet de mettre 16 panneau solaire en tout.
2 strings de 8 panneaux de (500W) tous identique.
Je le brancherais une un DEYE 12KW pour l'évolution.Cette onduleur a 3 string.
série, série, parallèle
en fait, je voulais brancher sur un seul string 8 panneaux en série et le 2eme 8 panneaux en série, en parallèle de l'autre.
il semblerait que cela soit possible directement avec les connectique du DEYE.
1) Est-ce bien le cas ?
de plus pour le coffret DC 2) est-ce obligatoire d'avoir un interrupteur rotatif pour le Consuel ?
3) par rapport à la distance de 25m est-ce ok d'avoir un cable solaire aussi long en 6mm2 ? j'ai posé la question à Gémini, il me dit que c'est OK, mais je voulais avoir un avis de quelqu'un qui s'y connait.
1 panneau fait 44V et 13.5A donc 8x44==352V et toujours 13.5A donc cela ne devrait pas trop chauffé en 6mm2.
La puissance serait max de 4000W (par série).
Bonjour,
J'ai une installation classique d'auto-consommation avec achat du surplus (donc statut de producteur).
Le système a été auto-installé, donc pas d'achat par EDF.
La boîte qui était censée acheter mon surplus et qui me servait de responsable d'équilibre a disparu sans laisser d'adresse (ni de chèque ), j'ai donc été sommé par Enedis de me trouver un nouveau responsable d'équilibre (c'est obligatoire si on est producteur > 3kWc).
J'ai souscrit un contrat auprès de 3ERL qui est mon nouveau responsable d'équilibre.
Ils m'apprennent au passage que désormais, les prix d'achat de l'électricité peuvent par moments être négatifs (!! Merci la libéralisation du marché de l'énergie...).
Aussi, ils demandent à leurs clients de brider "à la demande" (par périodes) leur injection dans le réseau pour ne pas pénaliser le prix global d'achat.
C'est expliqué sur cette page, un peu plus bas.
Pour faciliter la vie, 3ERL met à disposition une API qui indique s'il faut brider ou pas en temps réel, et une page d'information sur le statut en cours.
La station de charge VE RMS ne pouvant fonctionner avec un bridage de l'injection, j'ai bourriné un bout de code qui me permet de brider ma passerelle Enphase selon le flag "bridage" de l'API, mais aussi de la débrider si je veux charger mon VE.
Pour cela, je lis l'état du flag de bridage sur l'API et l'état du câble du VE (débridage si branchement du câble ou état "en charge").
Le code, destiné à la station de charge VE RMS, peut facilement être simplifié pour être ajouté au code RMS F1ATB standard.
Je suis conscient que c'est un cas bien particulier, mais je me suis dit que cela pouvait peut-être concerner d'autres forumeurs F1ATB.
Si cela vous intéresse, je mettrai à disposition le code. Il est probablement adaptable à d'autres API et d'autres marques de passerelles.
revue de la routine de mesure sur le Shelly pour l'adaptation VE en cours.
D'après la documentation de l'API Shelly pour les gen1 et pour les gen2+, il n'est pas nécessaire de faire les appels sur des voies séparées pour avoir la lecture de toutes les voies. Mon Shelly 3EM gen1 répond parfaitement à la demande /status en retrournant les 3 voies.
Est-ce que les propriétaires de Shelly pourraient confirmer que c'est le cas pour toutes les version existantes en lançant ces commandes:
- "adresseIP/status"
et - "adresseIP/rpc/Shelly.GetStatus" - "adresseIP/rpc/EM.GetStatus?id=0"
Merci de poster les résultats ici avec le type de Shelly.
Publication MQTT des états absente lorsque la source de mesure est MQTT
), j'ai donc été sommé par Enedis de me trouver un nouveau responsable d'équilibre (c'est obligatoire si on est producteur > 3kWc).