Bonsoir à tous,

Avant tout je tenais à remercier André pour tous ces contenus très riche ainsi que toutes les personnes participantes de près ou de loin au forum qui m’ont permis de créer mon routeur.

Jusque là j’ai réussi à router sur mon ballon d’eau chaude ce qui m’a permis de faire des économies.
 Je souhaite faire évoluer mon installation afin de tenter encore plus l’auto consommation, avec l’installation de batterie plug and play ( Titan de chez mater France bientôt dispo).
J’ai fini par comprendre à travers mes recherches sur le forum et sur le net que l’utilisation d’un « smart meter » était obligatoire n’es ce pas ?

Ensuite concernant les paramètres à intégrer au routeur je ne comprends pas trop ce qu’il faut mettre dans « action » pour que mon ballon puisse utiliser en priorité la surconsommation, puis ensuite charger la batterie.
Je suis désolé je sais que le sujet a déjà été abordé mais sincèrement j’ai du mal à comprendre.
Si vous pouvez me dire exactement les réglages à mettre dans le routeur pour pouvoir réaliser cela.

Je vous remercie par avance 

Cordialement 
Nicolas

Comme régulièrement, mon routeur se met à dérailler avec une courbe de consommation oscillant fortement, je consigne ici quelques essais.  J'imagine que ça pourra toujours être utile au moins pour les néophytes, afin de comprendre comment paramétrer les actions. 
A un moment le routeur avait plutôt bien marché, mais clairement, en tous cas avec les dernières versions officielles, ce n'est plus le cas. 

Premier essai: charge 100%, réactivité 13, seuil -300W. Mode: train de sinus. 

Ce n'est vraiment pas brillant...


Ce que confirme d'ailleurs le graphique interne de Tasmota (puissance effectivement facturée par EDF): 




Essayons de changer la réactivité, avec une valeur nettement plus basse: 5


Malheureusement, la réactivité ne change rien au problème. C'est même plutôt plus mauvais. 

Et en descendant la réactivité à 2, ce n'est pas mieux:



C'est encore pire qu'avec 5. 

Dernier essai avant de tout envoyer par la fenêtre:  je passe en "multi-sinus", au lieu du "train de sinus".

Ah tiens, on dirait que c'est tout de suite nettement mieux !

Confirmé d'ailleurs au niveau du Linky (à gauche en train de sinus, à droite en multi-sinus):


Avec même un Cos(phi) soudain très stable: 

Durant mes derniers essais, et comme j'ai amélioré mon outil de suivi des puissances afin d'afficher aussi les puissances apparentes (et pas seulement actives), j'ai constaté qu'en fait ce qu'on affiche ce n'est pas la puissance apparente, mais plutôt le résultat après traitements, qui du coup n'a plus grand chose à voire avec les valeurs mesurées. 

Essai avec charge 100%, réactivité 13, seuil -300W.

Sur cette courbe ne montrant que la puissance active, on pourrait penser que la régulation marche presque. 


Si on ajoute la puissance active, alors on constate que cette puissance apparente est particulièrement instable. Et surtout avec des pics de production de plus de 24kVA (pour un abonnement 12kVA, des panneaux 3kWc et un ballon 3kW), ça manque nettement de cohérence. Il est peu probable qu'avec un ballon ECS (élément quasi resistif) de 3kW, on puisse consommer jusqu'à 20kVA, de même que 3kWc de panneaux puisse faire monter la production apparente à près de 29kVA ponctuellement.


En fait si on analyse les courbes de façon plus systématiques (en comparant les puissances apparentes et actives, aussi bien du Linky et du Shelly), le résultat est un peu déroutant. 
Comme j'ai un contrat CACSI, le Linky n'affiche pas les puissances négatives (injection). Mais il semble y avoir une différence de fond entre le Shelly et Linky (via Tasmota Téléinfo): la puissance apparente que je mesure sur le Shelly est élevée mais aussi assez stable (courbe bleue pale). Cette courbe est très différente de celle affichée par le routeur pour la puissance apparente ! 

On voit bien sur les courbes du Linky que la consommation est très mauvaise, avec une alternance de séquences d'une minute environ, l'une consommant 500W environ,  suivi d'une période ne consommant rien. Donc l'objectif du routeur d'avoir une puissance consommée proche de 0 n'est clairement pas atteinte, malgré un seuil très prudent de -300W  et un ensoleillement constant. 

Et le fait que les courbes affichées par le routeur et celles mesurées effectivement par le Shelly soient aussi différentes montre clairement que la courbe de puissance apparente affichée par le routeur n'est pas la courbe brute issue des mesures, mais plutôt le résultat après traitements, essentiellement un filtrage type RC que l'on reconnait bien sur les courbes - avec un pic à chaque changement brutal de la valeur mesurée, et un retour progressif vers 0 quand le valeur mesurée est plus constante.

Pour ce qui est de la puissance active, là la courbe affichée par le routeur semble plus propre (bleu foncé vs captures précédentes du routeur). 

Par ailleurs on constate aussi que la puissance apparente telle que mesurée par le Shelly (courbe bleu clair) est très différente de celle remontée par le Linky (vert clair).
Et comme ces courbes ne reposent pas sur l'estimation du cos(phi), on peut supposer que la courbe affichée est fiable.
Cela s'explique probablement par une approche différente sur les deux appareils au niveau des cadrans de mesures. Dans le cas du Linky, il semble que la puissance apparente puisse être positive ou négative selon le déphasage, et comme on est en CACSI, le Linky donne 0 quand c'est négatif. De son côté, le Shelly semble toujours renvoyer une puissance apparente positive. 

Ce que confirme d'ailleurs le graphique interne de Tasmota pour la consommation mesurée par le Linky: 


Avec toujours un cos(phi) très faibles quand la régulation est active: 



Conclusion: mieux vaut cacher la puissance apparente. C'est déjà à la base une information assez compliqué à interpréter, mais comme en plus elle est très différente des valeurs effectivement mesurées, elle n'est guère exploitable si on n'a pas bien compris ce qui est réellement affiché.

Bonjour André et toute la communauté des codeurs ,

Serait il envisageable d'avoir une commande logicielle, ie un "bouton" - "Reset Alarm" qui apparaît quand un UxLx3 est sélectionné et qui permet l'envoie de la commande logicielle de "reset" à l'interface JSY-MK-333.

La commande qui remet à zéro le statut de la led de droite qui s'allume définitivement sans cette commande , si il y a une "erreur" comme la déconnection live d"un des trois capteurs...

Merci beaucoup!

Eric 

Ps: car évidemment la mienne s'est allumée suite à une manip et impossible de l'éteindre ! Je ne vois pas de solution autre que l'envoie d'une commande soft?

Bonjour,  dernière modif le 18/09/2025 19h
Voici un programme pour esp32 avec gestion complète.
Gère, météo, vent, tension, batts s'il y a etc, etc .
2 axes ou 1 seul (soit élévation soit azimut)
Se déplace par calcul azimut et élévation par rapport à la position gps du tracker "à rentrer"
voici quelques photos

                   

Faites-moi un retour .

programme dans resources sur https://tracker.theguilde.fr/

carte utilisée pour les vérins ou moteurs https://fr.aliexpress.com/item/328218357...pt=glo2fra

La je travail sur une version avec des capteurs de distance pour la position des axes, ce sera plus le temps qui sera geré mais les distances .
Donc version a venir. capteur VL53L0X https://www.amazon.fr/dp/B0D3PRSV3B?ref=...asin_title
version terminée mais pas testé "les 2 variantes sont incluses , l esp prend capteur si present si non comme avant"
GPIO 32 → XSHUT Capteur Azimut
GPIO 33 → XSHUT Capteur Élévation
https://mega.nz/file/QiAhhbJA#JpyfcyEVNo...7aYC5FR-Ew

Bonne journee

Bonjour A tout le monde.

je voudrais tout d 'abord dire merci pour ce site et ce routeur. 
J'ai installé mes panneaux il y a deux ans maintenant. tout va bien mais je j'injecte un peu trop dans le reseau.
j'ai un cumulus thermo dynamique, il tourne en pleine journée quand je consomme pas trop d'elec. mais je me suis rendu compte que parfois il s'enclenche alors que j'ai pas de production ou bien le contraire Du coup l'idée du routeur solaire a germé avec l'idée de faire relais directement sur la resistance du cumulus. j'ai vu plusieurs type de produit mais j'avoue que le faire soi-même est plutôt fun.
voici la version 1.0
   
Le boitier a été realisé par un ami sur imprimante 3D et l'assemblage également.
c'est un SSR 40A avec un shelly pour les mesures.
j'ai fait les premiers essais avec un chauffage infrarouge
   
je ne sais pas trop si les courbes sont normales.
et voici un autre essais avec un radiateur basique 
   

par rapport a ce que j'ai pu voir sur le forum, la courbe semble cohérente avec les oscillation mais il m'avait semblait qu'elle doit être plus proche de 0. j'ai fait plusieurs essai de paramétrage en limitant a -100W et autre mais j'ai pas l'impression que ca change beaucoup.

Est ce que vous pouvez me dire si vos courbes correspondent a ca aussi ?

dans quelques jours je vais essayer avec un triac pour voir la différence.

Merci pour vos retour

Pascal

Bonjour,

J'essaie d'installer manuellement remsdr sur une base bookworm.
Avez vous prévu de faire une migration sur cette nouvelle distribution ?
L'installation des pré requis est beaucoup plus simple car tout est disponible en package.

L'idée est de faire tourner remotesdr sur le pluto lui-meme.

73
Evariste F5OEO

Bonjour@all,
Comme je n'ai pas trouvé l'endroit exacte pour se présenter, voici : 
J'habite dans le nord ( pompeusement déclaré Haut de France par un ministre démissionné depuis )
Je viens de faire installer 12 panneaux pour 6Kw sur notre toiture coté plein sud  régulé par une passerelle Envoy-S / IQ Gateway Metered sur mon installation en "triphasé" je suis en HC & HP chez Enedis avec un contrat de vente de misère à 0.04€ ! et ce depuis fin juillet .
( là les graphiques de production étaient super régulé : de belles courbes)
Mon intérêt est de chauffer mon cumulus 3000lt triphasé en priorité par le solaire évidemment.
J'ai commencé par installer une horloge shuntant le fil de jour et nuit et passant les ordres de commande de mon contacteur J&N sur une plage 15/19h et programmé de 21 h 30 à 5h30 pour les HC. Bref de la bidouille évidemment !
je m'aperçois que cela n'est pas optimal car maintenant dans ce plat pays ,on est passé sur un ciel assez nuageux ! mais avec des belles pointes d'ensolleillement 
Pour contrecarrer cela, sur mon tableau principal maison j'ai ajouté un interrupteur afin de pouvoir forcer "au besoin".
Et Bingo !, en demandant des infos par Copilot, je fus dirigé vers ce site .
Me reste évidemment à bien lire vos posts afin de réaliser pour passer à un system m'évitant les contraintes solaires/manuelles.
Sachant que je suis plus de formation électro-mécano qu'informaticien, j'aurais certainement recours à vos aides.
Dans mon cas, cela serait d'abord de pouvoir piloter mon contacteur triphasé avec des seuils luminosité et des délais de contacts et coupures assez large et non plus au pif , manuellement !
( excusez si je ne mets pas les bonnes informations techniques)
Je suis à l'écoute de vos conseils et informations /liens etc..
merci de m'avoir lu.

Bonsoir André,
Voila je suis en train de faire une doc pour connecté et paramétrer l'afficheur. Je me suis aperçu que quand je me connecte en hotspot 192.168.4.1 j'arrive sur la page du scan Wifi que je lance par le bouton Scan et il me trouve bien, enfin surement des box internet, mais il ne les m'affiche pas de noms des box et donc je ne peux rien sélectionner, il m'affiche le textbox pour le mot de passe et bien sur si je clique sur envoyé cela ne marche pas étant donné que je n'ai pas sélectionner de box. Est il possible que si l'afficheur à eu déjà une box en mémoire, il n'y à plus de possibilité par le hotspot.
Merci.
Alain    

Bonjour, 

je reste confronté au problème récurrent du temps d'accès au Shelly (Pro 3EM dans mon cas) par l'API REST.
A tel point que j'ai plusieurs messages de TimeOut au niveau du routeur chaque jour. 

Dans 80% des lectures, j'ai un temps d'accès très correct autour de 80ms. 
Il y a environ 15% des requêtes restantes qui se font en-dessous de 120ms, ce qui reste correct. 
Mais pour les 5% restant, ça peut monter jusqu'à 1200ms voire plus (moins de 1% des requêtes dépassent 800ms).

J'ai essayé de supprimer tout ce qui n'est pas nécessaire au niveau du Shelly (tout désactivé sauf la connexion Ethernet): aucun changement flagrant. 
Et en arrêtant les autres clients qui se connectent au Shelly, là c'est sensiblement mieux, mais trop contraignant !



J'ai donc tenté une autre approche: expérimenter l'accès avec ModBus. Mais si en l'activant au niveau du Shelly, celui-ci semble bien à l'écoute du port dédié (502), mais c'est tout. 
Je n'est pas réussi à lire le moindre registre par ModBus (Par exemple le registre 1013 qui devrait contenir la puissance active). 

Et cela aussi bien avec une implémentation perso, qu'avec des outils dédiés comme ModPoll et Modscan64 en testant toutes les plages de registres possible dans les 4 modes. 

Quelqu'un aurait-il réussi à communiquer avec un Shelly Pro en utilisant ModBus ?

Sinon, il reste bien d'autres options: MQTT (en s'abonnant aux notifications), ou les WebSockets (mais il semble que ce soit limité à un seul client).

Ce que je n'aime pas avec MQTT, c'est que le Shelly publie des messages à rallonge, avec des tonnes d'informations inutiles. On peut toujours les filtrer, mais ce n'est pas très optimal comme implémentation. De plus le fait de passer par un broker MQTT augmente d'autant la latence (donc le délai entre lequel la mesure est effectuée et le moment où le routeur en prend connaissance). On peut espérer des temps de l'ordre de 100 à 300ms d'après des retours utilisateurs. Donc à priori nettementmoins bons que par l'API REST dans au moins 80% des cas.