Le routeur solaire YaSolR ☀️

[mathieucarbou]

Le routeur solaire YaSlR

En tant que développeur de profession et spécialiste en librairies Arduino / ESP32 liées à l'énergie, je bosse depuis fin 2023 sur un projet de logiciel de routage Open-Source nouveau genre, appelé YaSolR (Yet Another Solar Router), que je vais vous décrire ici.

• Site web: https://yasolr.carbou.me
• Projet GitHub: https://github.com/mathieucarbou/YaSolR

Qui suis-je ?

Pour ceux qui ne me connaissent pas, je suis très actif dans le milieu Arduino / ESP32 / Home Assistant.

Profil: https://github.com/mathieucarbou

Je suis notamment l'auteur des librairies (toutes utilisées par YaSolR):

• MycilaJSY: librairie qui supporte les JSY en TTL et RS485 sur ESP32
• MycilaPZEM004Tv3: librairie qui supporte le PZEM-004T v3 sur ESP32
• MycilaPulseAnalyzer: librairie d'analyse de pulse de circuit Zero-Cross
• MycilaESPConnect: librairie de gestion réseau pour ESP32 qui supporte l'Ethernet

Et je suis également un des développeurs des fameuses librairies AsyncTCP et ESPAsyncWebServer.

Et pour finir, je suis également le concepteur de ces 2 autres routeurs solaires que vous trouverez dans la section blog du site YaSolR et aussi sur ce forum:

• Routeur solaire basé sur Shelly Dimmer Gen 3
• Routeur solaire basé sur Home Assistant

Pourquoi avoir fait YaSolR ?

J'ai analysé BEAUCOUP de code source de routeur solaire, et malheureusement, la plupart des solutions ont des lacunes.
N'étant donc pas satisfait des solutions de routage solaire existantes (soit d'un point de vue fonctionnalité, précision, rapidité de réaction, ou qualité du code, ou license, ou autre), j'ai décidé de créer ma propre solution, Open-Source.

Le but de YaSolR est donc de fournir une solution de routage solaire de qualité, précise, réactive et compatible avec la plupart du matériel existant et bien plus encore, comme le LSA avec un DAC DFRobot!

YaSolR est UNIQUEMENT le logiciel: donc pour l'utiliser, vous devez être capable d'assembler votre propre routeur avec le matériel compatible, et installer le logiciel sur un ESP32.

Je ne fournis pas de routeur pré-monté pour des raisons de sécurité, normes, support après-vente, etc.

Particularités de YaSolR:

• Réactivité et rapidité des mesures: YaSolR est capable de faire une mesure toutes les 42 ms, et ajuste le routage au moins 3 fois par seconde.
• PID: YaSolR est le seul routeur à utiliser un algorithme PID à proportionnelle aux mesures pour ajuster le routage, ce qui permet de contrôler les corrections avec plus de précisions et en évitant les à-coups (overshoot) qui provoquent des oscillation, sur-consommations ou sur-injections.
• PID Tuning: YaSolR propose un écran de tuning PID pour ajuster les paramètres du PID en temps réel, sans recompiler le code.
• Fréquence: YaSolR est capable de fonctionner sur une fréquence de 50 Hz et 60 Hz, mais aussi sur une fréquence de 51 Hz (par exemple sur génératrice Enedis).
• Résolution: YaSolR a une résolution de routage de 12 bits, donc est capable d'être précis au watts prés avec une charge de plus de 4000W. Les routeurs ayant une telle précision sont rares. La plupart des routeurs ont une précision de 100 pas, soit 30W pour une charge de 3000W.
• Analyse de pulse Zero-Cross: YaSolR analyse les pulses du circuit Zero-Cross pour détecter les positions du front montant et descendant, ce qui permet de synchroniser le déclenchement du TRIAC le plus précisément possible lors du vrai passage à zéro. La plupart des routeurs basé sur circuit ZC calculent une fausse valeur de déclenchement à partir du front montant du pulse, qui se trouve à être avant le passage à zéro.
• Matériel: YaSolR est le seul routeur qui n'impose pas de matériel et offre une grande compatibilité.
• Supporte le concept de "virtual grid power" qui permet une compatibilité avec un second routeur ou une borne de recharge EV
• Fonctionnalités de contrôle de phase: remapping du dimmer (comme les Shelly Dimmer), limite de puissance, etc
• Bypass (marche forcée) selon horaires et / ou température
• Simplicité: YaSolR est l'un des rare routeurs à supporter directement le régulateur de tension LSA via un DAC, sans passer par un module Zero-Cross, ni une second alimentation!
• Configurable: YaSolR permet de reconfigurer ses GPIO afin d'être compatible avec les setup existant du prof solaire et F1ATB entee autres.

Matériel supportés:

ESP32 boards

• Dev Kit boards,
• S3 Dev Kit boards
• ESP32s
• WIPI 3
• Denky D4
• Lilygo T Eth Lite S3 boards (Ethernet support)
• WT32-ETH01 boards (Ethernet support)
• Olimex ESP32-POE boards (Ethernet support)
• Olimex ESP32 Gateway boards (Ethernet support)
• etc

Circuits Zero-Cross:

• basés sur JSY-MK-194G (ce JSY a un pin Zx pour détecter le Zero-Cross)
• basés sur BM1Z102FJ
• basé sur un pulse court comme Robodyn ou le module ZCD de Daniel S. sur PCB Way

Outils de mesure:

• PZEM-004T v3
• JSY-MK-333 (tri-phasé)
• JSY-MK-193
• JSY-MK-194T
• JSY-MK-194G
• JSY-MK-163T
• JSY-MK-227
• JSY-MK-229
• JSY Remote par UDP
• MQTT

Dimmers supportés en contrôle de phase avec un module Zero-Cross:

• Robodyn 24/40A
• Triac + détection Zero-Cross
• SSR Random + détection Zero-Cross
• Régulateur de tension LSA ou LCTC + module de conversion PWM->Analog 0-10V + détection Zero-Cross

Dimmers supportés en contrôle de phase qui fonctionnent via PWM (sans détection Zero-Cross):

• Régulateur de tension LSA ou LCTC + module de conversion PWM->Analog 0-10V

Dimmers supportés en contrôle de phase qui fonctionnent via DAC (sans détection Zero-Cross):

• Régulateur de tension LSA ou LCTC + DFRobot DAC GP8211S (DFR1071)
• Régulateur de tension LSA ou LCTC + DFRobot DAC GP8403 (DFR0971)
• Régulateur de tension LSA ou LCTC + DFRobot DAC GP8413 (DFR1073)

Exemples de configurations:

Le site YaSolR propose plusieurs exemples de configurations, mais à vous de jouer pour créer la votre.
Par exemple. YaSolR est compatible avec le matériel de F1ATB, Prof solaire, etc. Donc il vous suffit d'installer et configurer les GPIO.

YaSolR est aussi l'un des rare routeurs à supporter directement le régulateur de tension LSA via un DAC, sans passer par un module Zero-Cross, ni une second alimentation!
Il est donc possible de construire un routeur solaire avec un ESP32, un DAC DFRobot et un LSA uniquement!

YaSolR Pro

YaSolR est Open-Source et disponible gratuitement.

Cependant, une version Pro est aussi disponible avec une interface graphique plus jolie et complète, qui se base sur ESP-DASH Pro, une librairie graphique commerciale dont la license ne permet pas son intégration dans les projets Open-Source.
Je rends donc disponible cette version Pro aux utilisateurs qui soutiennent le projet via un don, ce qui permet d'aider à financer le développement, maintenance et achat de matériel afin que le projet puisse continuer à évoluer et son code rester accessible gratuitement.

[karalel]

ici ça tourne avec un dfrobot 1071 depuis hier soir, peu de soleil aujourd'hui mais ça a l'air de bien fonctionner

[fxmx86]

Nice : beau projet, et open-source !
Bravo !

[ericg]

Joli projet.
Dans la lignée des routeurs que j'essaie, je tenterai bien celui ci.
J'ai actuellement une version F1ATB avec prise de mesure par pince ampèremétrique et transfo. A priori cette version n'est pas reprise dans YaSolR?

[mathieucarbou]

Joli projet.
Dans la lignée des routeurs que j'essaie, je tenterai bien celui ci.
J'ai actuellement une version F1ATB avec prise de mesure par pince ampèremétrique et transfo. A priori cette version n'est pas reprise dans YaSolR?

En effet, car André a écrit du code spécifique pour cela et ça requiert un assemblage de composants électroniques.
Je souhaite que YaSolR soit utilisable sur des composants "plug and play".

Ok est aussi bien mieux servi en terme de précision et vitesse par un module spécialisé dans la mesure énergétique comme le JSY, le 194G faisant aussi office de circuit zero-cross.

[ericg]

Ok, je vais donc commander les pièces nécessaires pour tester.

[ericg]

J'ai installé tout d'abord la version pro de test puis j'ai voulu installer la version "standard" pour voir la différence.
Malgré avoir fait un erase de la carte, je me retrouve sans menu:


C'est normal? Sachant que j'ai flashé la version: YaSolR-v1.0.0-rc17-oss-esp32-fr.FACTORY.bin

[karalel]

J'ai installé tout d'abord la version pro de test puis j'ai voulu installer la version "standard" pour voir la différence.
Malgré avoir fait un erase de la carte, je me retrouve sans menu:


C'est normal? Sachant que j'ai flashé la version: YaSolR-v1.0.0-rc17-oss-esp32-fr.FACTORY.bin

C'est normal oui, voir les différences entre les 2 versions ici https://yasolr.carbou.me/pro
En pas pro, pas de config "jolie", tout se fait sur /config

[ericg]

Ah Ok, j'avais mal visité cette page.

[mathieucarbou]

Oui, comme j'explique j'utilise ESP-DASH pour l'interface.
La version OSS est très limitée, j'ai achetée la version commerciale mais je ne peux pas distribuer ses sources donc le firmware avec la version pro du UI est dispo pour ceux qui sponsorisent le développement du projet

Je dois mettre à jour la version trial car elle comporte quelque bug pour le remapping. Je vais le faire maintenant.

edit

je viens de mettre à jour les trials à la rc17.

LSA + DAC DRRobot fonctionnent super bien, pour moi c'est le combo parfait. Pas besoin de circuit ZC.

[ericg]

Ca a du sens, pas de souci. J'attend de recevoir les pièces commandées pour valider l'usage. Je suis très interessé par la partie Virtual Grid Power pour piloter la recharge de batteries et piloter une borne de recharge .

[mathieucarbou]

C'est ce qu'un ami fait avec sa borne OpenEVSE. Il a le topic MQTT grid de l'OpenEVSE qui va chercher le virtual grid power, ce qui priorise la charge du VE et le routage se déclenche du coup avant et après, du fait qu'un charge VE requiert 5-6A, il fait démarrer sa borne quand le surplus est important, ce qui laisse le temps au routeur de chauffer l'eau de son ballon d'appoint avant que la borne ne démarre et après, lorsque le surplus est suffisant pour le routage mais pas pour une charge.

[mathieucarbou]

Bonjour,

J'ai enfin pris le temps de faire des schémas de câblage sympas et interactifs avec CirkitDesigner (https://app.cirkitdesigner.com) !

Vous obtiendrez des informations sur :

- Comment câbler u RobotDyn
- Comment câbler un random SSR
- Comment câbler un régulateur de tension contrôlé par PWM
- Comment câbler un régulateur de tension contrôlé par DAC DFRobot
- Comment câbler un bypass relay (marche forcée)
- Comment câbler JSY et PZEM
- Comment câbler les accessoires

Ici: https://yasolr.carbou.me/build#wiring

[ericg]

Pourquoi utiliser 3 GPIO pour les sondes 1-Wire? On ne peut pas les brancher en parallèle sur un seul GPIO?

[mathieucarbou]

Si tout à fait, c'est supporté en général par le bus 1-wire, mais pas sur YaSolR.

Les problèmes liés à ça:
- il faut faire une détection d'adresse, donc setup plus compliqué, surtout derrière une interface graphique
- la lecture est plus lente car séquentielle sur un même bus en général pour les DS18.

YaSolR utilise une fonction hardware de l'ESP32 pour communiquer avec les DS18B20: le RMT (Remote Control Transceiver).
Il y a 2 channels rx/tx qui fonctionnent en async pour chaque GPIO avec DS18.

Ça évite donc d'avoir à faire une lecture séquentielle bloquante de 3 sonde potentiellement, ce qui est couteux en millisecondes, et en CPU.
La plupart des implémentations DS18, incluant celle d'ESPHome, n'utilisent pas le RMT car elles doivent être compatibles sur plusieurs plateformes.
C'est le cas aussi de la plupart des routeurs solaires... YaSolR est le seul que je connaisse qui utilise une implémentation hardware.

Quand on ne supporte que ESP32, on peut faire des optimisations hardware, alors pourquoi s'en priver!

Le but étant dans tout ça de ne jamais faire d'appel bloquant afin de laisser libre le CPU pour l'exécutions des ISR liés à la gestion des dimmer et mesures, ce qui est critique au bon fonctionnement du routeur.

Voici la lib DS18 que YaSolR utilise: https://github.com/mathieucarbou/MycilaDS18

[lr83]

La lecture des DS n'est pas forcément bloquante. Y a une fonction setWaitForConversion() et ensuite suffit de faire une tache (par exemple toutes les secondes) qui fait un appel à isConversionComplete() pour lire les valeurs.
Mais votre méthode utilise pleinement l'ESP32 ce qui est génial.

[mathieucarbou]

La lecture des DS n'est pas forcément bloquante. Y a une fonction setWaitForConversion() et ensuite suffit de faire une tache (par exemple toutes les secondes) qui fait un appel à isConversionComplete() pour lire les valeurs.

Malheureusement, cette méthode évite juste au code d'attendre pour la conversion, mais le code qui s'occupe de la com, lui, est bloquant.
Vous pouvez aller voir le code de com et parsing et faire des mesures pour vous en convaincre

Il y a une succession de wire->write() suivi de wire->read(), et de plus, la méthode isConnected() appelées à plusieurs endroits fait elle même une com wire->write() suivie de wire->read().
Donc oui, c'est bloquant.

La lib OneWire elle-même dans ses write et read est bloquante, et pire, désactive les interruptions avec noInterrupts(); Elle doit se caller sur un protocole, donc envoie des successions de pulse avec des longueurs différentes, donc un write dans OneWire est en réalité transformé en une succession de LOW / HIGH entrecoupé d'attente (pauses). Idem pour les read().

Dallas appelle plusieurs fois write et read, donc ça s'accumule.

Un routeur solaire utilise les ISR de façon critique pour mesurer les fronts du ZCD et gérer les délais de déclenchements du triac. Donc les interruptions dans un routeurs solaire sont critiques et ne doivent pas êtes désactivées.

OneWire et Dallas visent à être compatibles sur plusieurs plateformes. Donc l'implémentation est non seulement bloquante, mais s'assure qu'elle fonctionne vis-à-vis de son protocole sans égard à l'application qui l'utilise.
Cette lib est à proscrire dans le cas d'un routeur au contraire.

Et démarrer une tache asynchrone avec une stack prise sur le heap pour la lecture ne résout pas les problèmes ci-dessus, et empiète 2-4k sur le heap (dépendent de ce que fait cette tache). C'est énorme pour un MCU qui tourne en général avec 140-150k de heap dispo.

L'implémentation de ESPHome aussi est bloquante (https://github.com/esphome/esphome/blob ... e_wire.cpp), mais au moins, ils ont refait le code correctement, ne désactivent pas les interruptions, et au contraire, le code peut se mettre en IRAM.

[bassman]

voilà un routeur qui m'intéresse

J'ai commandé quelques composants (dac +LSA) pour pouvoir monter un routeur YaSolR une fois que j'aurai installé mes panneaux (d'ici 1 mois ou 2).

Est-il possible de piloter une Led RGB en fonction de l'état du chauffe-eau ?

mon idée est :
- si l'eau est déjà chaude : led en vert
- si l'eau froide : led en bleu
- si l'eau est en train d'être chauffé par le solaire : led en jaune
- si on a déclenché la marche forcé via l'interface web ou HA ou un bouton poussoir physique: led en rouge

[mathieucarbou]

voilà un routeur qui m'intéresse

Est-il possible de piloter une Led RGB en fonction de l'état du chauffe-eau ?

Non car il n'y a pas de LED RGB: juste 3 leds une couleur (traffic light) qui sont pour l'états du système.
Par contre si vous avez HA ou de la domotique vous pouvez vous faire un truc à côté basé sur les envois MQTT de YaSolR, ou basé sur son API REST.

[lr83]

La lecture des DS n'est pas forcément bloquante. Y a une fonction setWaitForConversion() et ensuite suffit de faire une tache (par exemple toutes les secondes) qui fait un appel à isConversionComplete() pour lire les valeurs.

Malheureusement, cette méthode évite juste au code d'attendre pour la conversion, mais le code qui s'occupe de la com, lui, est bloquant.
Vous pouvez aller voir le code de com et parsing et faire des mesures pour vous en convaincre

Il y a une succession de wire->write() suivi de wire->read(), et de plus, la méthode isConnected() appelées à plusieurs endroits fait elle même une com wire->write() suivie de wire->read().
Donc oui, c'est bloquant.

La lib OneWire elle-même dans ses write et read est bloquante, et pire, désactive les interruptions avec noInterrupts(); Elle doit se caller sur un protocole, donc envoie des successions de pulse avec des longueurs différentes, donc un write dans OneWire est en réalité transformé en une succession de LOW / HIGH entrecoupé d'attente (pauses). Idem pour les read().

Dallas appelle plusieurs fois write et read, donc ça s'accumule.

Un routeur solaire utilise les ISR de façon critique pour mesurer les fronts du ZCD et gérer les délais de déclenchements du triac. Donc les interruptions dans un routeurs solaire sont critiques et ne doivent pas êtes désactivées.

OneWire et Dallas visent à être compatibles sur plusieurs plateformes. Donc l'implémentation est non seulement bloquante, mais s'assure qu'elle fonctionne vis-à-vis de son protocole sans égard à l'application qui l'utilise.
Cette lib est à proscrire dans le cas d'un routeur au contraire.

Et démarrer une tache asynchrone avec une stack prise sur le heap pour la lecture ne résout pas les problèmes ci-dessus, et empiète 2-4k sur le heap (dépendent de ce que fait cette tache). C'est énorme pour un MCU qui tourne en général avec 140-150k de heap dispo.

L'implémentation de ESPHome aussi est bloquante (https://github.com/esphome/esphome/blob ... e_wire.cpp), mais au moins, ils ont refait le code correctement, ne désactivent pas les interruptions, et au contraire, le code peut se mettre en IRAM.

Merci pour toute ces explications
C'est vrai que je n'étais pas rentré dans dans le code de OneWire.
J'ai trois lectures de DS et a priori je n'ai pas vu de problème dans le routage.