msunpv + batterie marstek

Bonjour,

Comme j'ai dit au début, je ne connais pas le comportement des Marstek.

Néanmoins, elles ont l'air de se comporter comme les Zendure, et c'est ce que tu décrits:
1) La nuit si tu actives Autobal ou Manubal, les batteries ne se vident pas. Donc pince dans le bon sens, tes batteries ne voient pas le ballon.
2)Tu confirmes que le jour avec Autobal, les batteries ne voient toujours pas le ballon; ce que tu décrits est le comportement normal:

En revanche, de jour, le problème que je decrivais initialement (charge batterie quand charge forcée Ballon durant les horaires d'apres-midi du timer Ballon si Temp Ballon < seuil - cf post #8 ) reste et c'est ce que tu decris ci-dessus:

Tes batteries chargent alors avec la valeur de conso ballon.

Ne voyant pas le ballon, elle prennent le surplus, mais le ballon consomme à pleine puissance, normal.

Si maintenant tu souhaites que les batteries se vident dans le ballon, retire la phase ballon de la Shelly.
Le surplus ira alors dans le ballon lors de l'autobal de la journée....et si insuffisant complété par les batteries. La nuit si autobal, tes batteries se videront dedans.
Et par sécurité mettre un timer qui coupe le routage la nuit.

Par contre tu fais référence au post 8, et là tu ne décris pas la même chose, puisque tu disais que les batteries voyaient le ballon comme surplus et consommaient le double?
Est tu sûr, si oui je sais pas, demande Nicod, s'il rencontre le même problème (si problème) que toi.

3)Pour tes pinces, oublions l'écuC, comme tu dis, sa pince ne sert à rien.
Après qu'il y ait un écart entre elles, ben oui c'est pas des instruments de mesure; elle ne sont pas du même constructeur etc...

Oui avec MsunPV tu peux jouer sur le gain pour t'aligner. Est ce utile, je sais pas. Mais si j'avais à le faire je m'alignerai sur la Shelly, puisque tu souhaites priorité batterie.
Mais la shelly n'est pas si réactive que ça, en tous cas, moins vive que le routeur, donc ça varie tellement vite, que ça doit pas être facile à faire.
Perso, j'ai une pince du routeur, sur la phase de mes batteries, donc je vois les puissances de charge et décharge. J'ai ajusté son gain pour que mes compteurs charge et décharge correspondent à ceux de zendure.
Peut être peux tu prendre cette méthode pour l'aligner, par exemple en regardant ton compteur conso, s'il correspond à ton compteur Marstek.


Bon WE.

Bonjour et merci Robin. Après quelques tatonnements complémentaires, voici mon retour d'expérience:
J'ai questionné le problème de fiabilité de la mesure du zero injection du Shelly PRO EM-50 sur le forum Shelly: il n'y a pas (ou pas encore) de moyen d'ajuster la mesure par parametrage de la sonde CT (comme le MSunPV le permet - merci Patrick). Je pourrais m'accomoder des quelques 50W soutirés sur le réseau pendant les phases de charge et de décharge de la batterie mais cela crée le dysfonctionnement décrit ci-dessous. Lorsque la batterie est pleine, on passe sur le routage du MSunPV vers le Ballon et là tout devient correct: 0W réel soutiré sur le reseau durant cette phase.
Le problème est qu'il perdure des conflits entre les 2 systemes Marstek et MSunPV dus probablement aux glitchs autour du zero injection peut-être explicables par les differences de fréquence de lecture entre les 2 systemes comme tu le soulignes, Robin. Et une des conséquences est que cela active des mini pics de charge Ballon, en pleine nuit notamment (quand la batterie se decharge dans le circuit maison) et même des declenchements intempestifs d'une sortie en ToR pilotée sur seuils de SOL1+SOL2 (voir un autre post sur ce sujet). Comment eliminer ce phénomène ?
En attendant, j'ai donc créé un timer pour couper le routage de nuit (en fait l'autoriser durant une plage horaire de jour) tel que décrit dans d'autres fils sur ce sujet. J'ai galéré pour le mettre au point tout simplement en raison de la taille des caractères du menu de MSApp. En effet dans Timers/Sorties Validation/Solaires je ne vois pas l'entête de ligne et j'avais mis pour Sol1 et Sol2 sans m'en rendre compte aussi 1 et 1 dans la 2ème ligne qui s'avère être celle de "Val Off" (vu dans une copie d'ecran ailleurs sur ce forum). Y-a-t-il un moyen de jouer sur la taille des caractères de l'appli MSApp ? J'ai essayé de changer la résolution de mon écran ou de mettre la taille de caractères la plus faible, ça ne change rien.
Merci
Bertrand

Regarde dans les paramètres d'affichage, la mise à l'échelle qui peut faire merdouiller.

Et une des conséquences est que cela active des mini pics de charge Ballon, en pleine nuit notamment (quand la batterie se decharge dans le circuit maison) et même des declenchements intempestifs d'une sortie en ToR pilotée sur seuils de SOL1+SOL2 (voir un autre post sur ce sujet). Comment eliminer ce phénomène ?

Chez moi, j'ai 2 pinces, une a coté du Linky et dans l'autre j'ai passé la phase qui commande TOUS mes équipements (Donc le ballon et mes radiateurs: SOL1, SOL2 et SOL3) pilotés par le routeur. Mon tableau est conçu comme cela.
Ainsi j'arrive à faire pince 1-pince 2.

Toi ne pouvant faire cela, tu as passé en inversant la phase ballon dans la pince Marstek.
Ben fait de même avec la phase de SOL2, de mémoire la résistance de ton Spa, ainsi tes batteries ne devraient pas voir ni ton ballon, ni ton spa.
Ainsi même si tu veux charger ton ballon ou faire un spa nocturne, tes batteries ne se videront pas si tu utilises la fonction Autoxx ou Manuxx.

Quant à tes pics la nuit, je sais pas comment Marstek voit ton ballon ou ton Spa et qu'il essaie de router????
Mais tu as la solution, coupes le routage par timer du ballon et de ton spa.

Bonne soirée.



Bonne soirée.

Bonjour. Je vous partage une mise à jour de mon retour d'experience après quelques mois d'été d'utilsation conjointe du MSunPV et de la batterie Marstek Venus E3:
Le système fonctionne globalement correctement avec la charge de la batterie en début de journée et ensuite le routage vers le ballon d'ECS quand la batterie est pleine. Grace aux conseils de Robin (cf posts plus haut), j'ai bien fait passer le fil de phase ballon à l'envers dans la pince de lecture du CT batterie (Shelly Pro EM-50 pour moi) de la phase réseau pour neutraliser la charge ballon (et eviter la decharge de la batterie dans le ballon).
En revanche, le système n'est toujours pas optimisé pour 2 raisons:

1- il y a toujours un écart de 30 à 50W entre la valeur lue par le CT du MSunPV (qui est a priori la vraie valeur - confirmée par le suivi de consommation horaire d'Enedis) et le CT de la batterie (Shelly Pro EM-50) ce qui est problématique en situation de zéro conso / zéro injection, donc autour du 0W. Pour info, Shelly n'a toujours pas intégré une option de calibration du CT (ajout d'un offset et éventuellement coeff mutiplicateur comme dans le MSunPV mais ce dernier aspect n'a pas d'impact visible pour le problème autour du 0W).

2- en phase de charge / décharge / routage, il y a des pics de quelques dizaines voire centaines de W soutirés ou injectés (visibles sur la courbe du fichier MSunPV, PowReso). Je suspecte que cela provienne comme je le disais en avril dernier, de la non synchronicité entre les lectures de la pince réseau du MSunPV et de celle de la batterie (EM-50). Cependant, je ne comprends pas pourquoi, en remettant le routage 24h/24, le MSunPV n'arrive pas à au moins rediriger les pics négatifs (brusques décharges de la batterie en pleine nuit) vers le ballon d'ECS, au moins cette energie ne serait pas perdue / réinjectée gratuitement sur le réseau. Pour les pics positifs, dus probabalement à des trous de lecture du CT EM-50 par la batterie Marstek Venus, donc occasionnant des pics de charge brefs au max de 2.5kW, c'est un peu dommage (car en journée surtout c'est de l'excedent de production solaire seul qui est censé partir en charge batterie) mais ce n'est pas perdu car stocké dans la batterie.

Pour info, je viens de connecter les 2 systèmes (CT Shelly EM-50 et batterie Marstek Venus E3) en connectivité filaire (WLAN / RJ45) et non plus en WiFi pour m'affranchir des aléas de qualité de réseau WiFi. Pour info aussi, j'ai mis les 2 systèmes en adresses IP fixes (comme je l'ai fait pour le MSunPV - qui est lui toujours bien évidemment en connectivité WiFi).

Merci pour vos conseils éclairés.
Bertrand

Bonsoir Bertrand.

Je pense que tes pics sont plus liés a une perte de données momentanée entre ton Shelly et la batterie. Tu indiques 2,5kw, c'est le max de ta venus, donc pas de rapport avec le msunpv.

Tu as passé un câble RJ45.... ce dernier est blindé et bien éloigné du 230?

Tu pourrais vérifier la présence ou l'absence de ces derniers en coupant totalement le routeur la nuit.

Pourquoi le msunpv ne prend pas le pic injecté, j'imagine que le pic doit être trop bref pour que le routeur agisse significativement pour effacer totalement celui ci.

Essaie de passer dans l'onglet system l'intervalle d'enregistrement sur la carte SD a 10 secondes pour mieux visualiser le pic et combien de w a pu exploiter le routeur.


Tu as compris que je n'ai aucune certitude, juste des pistes a gratter.

Bonne soirée.

Merci Robin pour ta réponse pertinente. J'ai attendu quelques jours pour observer le comportement modifié avant de répondre.
Le problème de pics d'injection semble donc en effet correspondre à des pertes de communication entre la batterie Marstek et le CT de mesure Shelly EM-50.
J'ai recablé la connection WLAN / Ethernet en cable STP (blindé) en place du UTP (Unshielded Twisted Pair). Les pertes de connexion semblaient moins importantes mais persistaient alors qu'en repassant en WiFi, le phenomène n'apparaissait plus.
J'ai contacté le support Marstek qui a reconnu des problèmes liés à la communication WLAN dans la version V150 installée (la dernière à ce jour) et a envoyé une mise à jour inverse pour repasser en V148.
Depuis cela fonctionne beaucoup mieux. Il y a encore eu un pic (-1.5 kW) ce matin mais c'est plutôt rare. Je n'ai pas encore repassé la fréquence de log du MsunPV à 10 sec mais je vais le faire pour mieux comprendre ce qui se passe.
J'ai voulu regarder aussi le log du Shelly EM-50 qui selon la datasheet, permet de télécharger les données relevées toutes les minutes durant les 60 derniers jours mais je n'y parviens pas: les 2 solutions proposées par le support Shelly (réponse automatisée hélas), via les menus Shelly en local ou via une commande rpc, ne sont pas applicables.
A suivre.
Bertrand