Ok, et le Quattro ne fait pas ça ? Ca n’a pas l’air sorcier de détecter qu’il n’y a plus de tension en AC in et de couper l’injection. A plus de 3000 euros l’onduleur…
Ca veut dire que je suis obligé de rajouter ce relais de tension à mon système si je veux utiliser l’ESS ? Je ne veux pas réinjecter dans le réseau. En cas de non injection il n’est pas possible de blesser un intervenant non ?
Merci
Ca travaille sur des plages de tension et de fréquence avec des seuils de détection assez précis (j’ai eu un Ziehl en place pendant une courte période chez moi, donc j’ai eu le loisir de le mettre en œuvre et de le configurer (ce qui était instructif pour le coup 
- maintenant il dort dans un placard)
Si je me fie aux certificats de Victron :
Tu bloques au choix du code grid car ton quattro n’a pas de système de protection/découplage intégré. La procédure que t’a indiqué ton revendeur permet de te faire avancer avec l’ESS, mais présume quoi qu’il en soit que ton installation est conforme.
Pour disposer d’une installation conforme, à partir du moment où tu as le réseau physiquement connecté sur l’AC In de ton onduleur, tu es obligé d’ajouter ce dispositif.
Matthieu
Ok, je comprends. Ce qui est étrange c’est que le revendeur ne m’a pas parlé de ce relais et d’ailleurs il n’est pas dans le pack 10Kw qu’il propose. Un ami a pris le même pack et n’a pas ce relais non plus.
Je suis en Virtual switch c’est peut être pour ça que ce relais n’est pas nécessaire même si le réseau est connecté en AC-In. Par contre chez mon ami le revendeur a paramétré son système avec l’ESS.
C’est étrange que le revendeur n’intègre pas ce relais dans ses pack, il sait pertinemment que le réseau va être branché en AC-In dans 99% des cas. Je ne pense pas que mon revendeur présume que j’ai un relais de tension car la première étape de son guide est de choisir “Other” dans le menu Grid mais de désactiver la fonction UPS. Bizarre que cette fonction soit présente dans le Quattro, elle est censé faire le job d’un relais de tension justement.
Merci encore pour les explications 
Salut,
Je continu mon voyage dans le Node Red en apprenant pas mal de chose et je dois dire que c’est assez excitant 
J’ai compris comment lire les data présent dans les msg, les supprimer, les combiner etc… J’ai un début de flux qui va chercher les données Tempo et qui me Set des valeurs suivant la couleur du lendemain.
J’utilise pour l’instant un “Trigger” manuel pour les tests qui sera par la suite défini pour s’exécuter tous les jours à 22h.
Dans la fonction “Format Date” je mets la date sous le même format que donne le http request qui suit et je l’envoi via un msg custom (msg.datePayload).
Ensuite je récupère les infos Tempo dans le “http request”. J’utilise cette adresse qui ma foi est simple mais suffisante.
https://www.services-rte.com/cms/open_data/v1/tempoLight
Dans la fonction “Tomorrow Color” je récupère msg.datePayload et msg.Payload et je les combine pour n’avoir qu’un seul msg qui contient tout ce dont j’ai besoin pour extraire la couleur du lendemain.
Dans le “Set Value” bah je définis une valeur à envoyer suivant la couleur du lendemain
Je n’ai pas encore passé mon système en ESS car nous baignons dans les jours rouges en ce moment et ce serait con de devoir se brancher en direct sur le réseau suite à une fausse manip ou autre contretemps.
En attendant j’arpente les différents forum, vidéo etc… concernant la programmation via le node red ou autre.
Suite à ton long message msevestre j’ai regardé quelles étaient les solutions pour récupérer des infos de prévisions solaires afin de fine tuner mon futur flux.
J’ai vu que ce genre d’info pouvait être prises dans le VRM via le node VRM API. J’ai donc créer un token dans mon VRM pour avoir accès à cette myriade de data via ce node. Ce qui m’intéresse c’est les prévisions solaires du lendemain et plus particulièrement le Solaire Total Prévisionnel que l’on voit ici en bas à gauche.
Mais bon je n’arrive pas a extraire cette valeur là. Faut dire, il y a beaucoup de paramètres disponibles et quoi que j’essaye je n’obtient pas une valeur qui ressemble de près ou de loin à 18.7 kWh
Vous avez une idée de comment paramétrer le VRM API pour qu’il nous sorte cette valeur ?
A bientôt et merci
Salut
Pour le coup, tu peux réutiliser mon flux pour cela. Il fonctionne parfaitement, et va puiser directement chez RTE (cf les post sur NodeRed et Tempo sur ce forum).
Clairement pas des jours pour des tests
Ce noeud a un usage un peu tordu (et non documenté, ce qui n’aide pas) - je me demande même si l’API ne présente pas de bugs… m’enfin, voici mon retour d’expérience:
Pour récupérer la prod estimée à J+1 durant le jour qui précède (ce que je fais à 22h par ex) :
Intervalle, qui doit être en “days”, afin qu’il te retourne bien le cumul par jour (si tu sélectionne Hours, il te retournera l’estimé par heure par ex)
Enfin, on demande à partir du lendemain (“beginning of tomorrow”) et sur une période de 48h.
Pourquoi un intervalle de 48h alors qu’on s’attendrait à demander 24h (puisqu’on est “à partir du lendemain”) ?
Et ben, c’est comme ca…
C’est le résultat de la constatation que j’ai fait pour configurer le noeud et récupérer, de manière certaine un jour J, l’estimé de production du jour J+1 affichée sur VRM. Ca se trouve alors dans msg.payload.records.solar_yield_forecast[0][1] (on s’attendrait à retrouver la valeur d’estimé pour J+2 aussi dans la structure renvoyée… mais non, l’autre donnée ne correspond pas à ce qu’on a sur VRM).
Astuce: dans la fenêtre de debug, si tu as une structure de donnée JSON qui s’affiche, tu peux récupérer facilement le chemin d’une donnée qui s’y trouve (il faudra juste préfixer de “msg.” pour l’utiliser dans tes noeuds):
Note: mon installation est récente, le prévisionnel de VRM s’avère très (trop) optimiste. Ce qui est vendu par Victron est que le système fait de l’apprentissage (il ajuste dans le temps l’observé vs prévu (pour rappel: on ne configure rien de relatif au champ PV dans leur solution d’estimé de prod)) - si ceci s’avère vrai, alors plus il y aura de recul sur le système, meilleures seront les prévisions.
Pour pallier ce temps d’apprentissage, j’ai pour le moment d’autres sources de forcast qui sont poussées depuis Home Assistant par MQTT (SolarCast et Forecast Solar), et pour ma stratégie de charge sur NodeRed, je prends l’estimé de production le plus pessimiste entre Victron et la moyenne de ce que je récupère de Home Assistant.
Matt
Ha non, je suis trop fier de l’avoir setuper tout seul Mais pour la suite je vais peut être te piquer des bout de flux.
Concernant l’api VRM j’ai ces résultats en +24h et +48h. Alors je disais que c’était très loin de 18kWh mais finalement c’est pas si mal. Peut être qu’il retranche une autre donnée à celle que je vois dans le VRM. Si je trouve les 4kWh manquant je te tiens au courant.
Autre chose, j’obtient les mêmes résultats quel que soit l’intervalle. 1h 2h 1jour 2jour. Ce qui est étrange au vu des résultats de ton coté.
Une estimation à la louche me suffit. Mais il faut que ça concorde. Si les estimations sont amputées de 4kWh à chaque fois c’est un détail qui peut être corriger dans le flux
De toute façon, si les prévisions ne sont pas celle d’une très belle journée ensoleillée je provoquerais la charge des batteries et tant pis si le lendemain un soleil voilé aurait suffit. A 75 cents le kWh mieux vaut être sur, puis il n’y a que 22 jours rouge.
A bientôt
Edit : le temps que je te réponde, je fais un autre test et la ça correspond… Je vais faire un fichier de log dans le flux (ça doit être possible) qui enregistre les prévisions heure après heure pour voir comment ça évolu. J’ose espérer que c’est à cause de la météo.
Re
il ne faut pas que tu regardes le champs total du retour, mais dans les “records”. C’est là où tu auras le résultat selon les tranches temporelles de la configuration de ton noeud.
Le total se contente de faire la somme de tout ce qui est dans le record '(et vu que ce qiu est dans les records n’est pas toujours cohérent (un +48h à partir de demain matin donne bien les première 24h OK par rapport à VRM, mais il n’est pas cohérent sur la seconde journée)
Ils ont peut être corriger quelque chose car maintenant ce que je vois dans le node red correspond à ce que je vois dans le VRM. Pour +24h et pour +48h. Mais bon c’est peut juste une coïncidence car toute la journée il m’affichait autre chose. Ou peut être qu’il faut que ce soit en fin de journée pour que ça corresponde. Mais j’aimerais quand même savoir pourquoi c’est différent à un instant t
Salut
à cet instant précis l’estimé J+1 avec le réglage +24h et +48h à compter de “Beginning of Tomorrow” me donnent aussi les mêmes résultats que VRM.
Ce n’était pas le cas plus tôt dans la journée - et c’est un comportement que j’avais déjà observé qui qui fait que je reste sur le combo ““Beginning of Tomorrow” & +48h”, qui m’a toujours retourné la valeur affichée de VRM dans msg.payload.records.solar_yield_forecast[0][1] (ca ressemble plus à un bypass d’un bug ou je ne sais quoi d’autre, mais en fine, c’est un combo fiable pour récupérer l’estimé J+1 depuis le jour J et c’est tout ce qui compte ).
Ok je comprends. A voir si la valeur retournée le soir est toujours bonne. Pour moi ce sera suffisant pour l’instant. Les changements de comportement seront de toute façon effectifs à 22h.
A bientôt
Autre chose, tu connais le chemin d’accès à la mémoire du cerbo ? On peut y écrire un fichier ?
Avec le réglage +48h, le champs que je t’ai indiqué est correct - c’est ce que j’ai en place comme flux à 22h
(J’en ai un autre à 4am mais je suis pas sûr de le conserver)
Non mais j’ai vu des choses sur cela dans l’usage des variables de contexte de node red.
Pour quels usage souhaites tu cela ?
(En ce qui me concerne, a défaut de connaître la nature du composant utilisé et comment il est utilisée par le système, je m’affranchirais de lui rajouter des cycles d’écriture inutilement)
Pour écrire un fichier de log
Mais c’est bon j’ai trouver un dossier dans lequel node red à la permission d’écrire
/data/home/nodered/ tout simplement
Tu cherches quelque chose qui serait résiliant à un redémarrage de node red ou du cerbo ?
Si ce n’est pas le cas tu peux aussi utiliser le Dashboard et des champs texte
Oui je cherche à écrire un log avec date heure et Solar_Yield_Forecast que je pourrais lire plus tard.
Ok
J’ai un besoin similaire que j’ai traité par un envoi sur MQTT, récupéré par Home assistant qui gère cet historique
Salut,
Aujourd’hui jour blanc, mise en place du ESS. Ca y’est ça tourne. Par contre il consomme un peu du réseau alors que j’ai de la batterie et de la production PV.
Je crois connaître la réponse mais il n’y a pas un moyen pour qu’il ne prenne rien du réseau jusqu’à que le SoC soit atteint ?
Quels paramètres de l’ESS changez vous pour provoquer la charge de la batterie ? Juste le SoC ? Le mettre à 100% par exemple ?
msevestre voici les relevés du solar_yield_forecast que j’ai loggé :
2024-12-12 / 07:59:20 - 84.4489009776064
2024-12-12 / 09:59:20 - 1434.0478095934473
2024-12-12 / 11:59:20 - 10145.025268554688
2024-12-12 / 13:59:20 - 14269.98794555664
2024-12-12 / 15:59:20 - 4213.748515051681
2024-12-12 / 17:59:20 - 4329.287734897005
2024-12-12 / 19:59:20 - 4286.674729162646
2024-12-12 / 21:59:20 - 3934.968832015426
2024-12-13 -- 22:00:00 / 14057.699417114258
2024-12-14 -- 22:00:00 / 21208.762768279135
2024-12-15 -- 22:00:00 / 19405.64842224121
2024-12-16 -- 22:00:00 / 15702.590876930008
On voit que les valeurs dessine une courbe, comme celle de l’ensoleillement tout au long de la journée alors que sur le VRM la valeur reste sensiblement la même toute la journée. Par contre les relevés de 22h sont les mêmes que ce que m’affiche le VRM. Y’a une boulette dans les rouages !
Un peu de conso du réseau n’a rien de grave. Pour ma part, je suis à environ 0,2kWh d’importation par jour tant que la batterie est suffisamment chargée pour passer la nuit et la journée qui suit compte-tenu de la prévision de production. S’il n’y a pas assez d’énergie dans la batterie, je laisse la batterie au repos en heure creuse pour l’utiliser en heure pleine. Uniquement la veille d’un jour Tempo Rouge, la batterie pourrait être rechargée jusqu’à une valeur cible.
Pour ce faire, je modifie avec Node-RED les valeurs Minimum SoC, Active SoC Limit et ESS State.
Avec l’ESS State 8 ou 12 et un Minimum SoC à la valeur souhaitée (supérieur à la valeur actuelle), la batterie entame sa recharge automatiquement. L’inconvénient est que lorsqu’on abaisse le Minimum SoC, il faut également diminuer l’Active SoC Limit. Ceci fausse entièrement l’algorithme BatteryLife. Alors il suffit de le réécrire. Très simple.
Pour donner une idée :
Pour éviter tout usage même minime du grid, le seul moyen est de passer en Inverter Only. Tant que tu es sur ON, tu ne seras jamais à zéro dans un sens ou dans l’autre.
Pour assurer une charge quoi qu’il arriver (et bypasser toute “intelligence” du système Victron, que je n’apprécie pas), tout besoin de charge passe par le réglage du Min SOC à 100%. L’atteinte de la charge au SOC souhaité est géré par une boucle dans node Red (qui, lorsque le SOC cible est atteint, repasse le Min SOC à 5% (stoppe la charge) et on se met en ON ou Inverter Only selon la stratégie que j’ai adopté).
est-ce que tu récupères bien J+1 comme je te l’ai indiqué, cad le forecast configuré en “beginning of tomorrow”, avec delai +48h et récupérer la valeur de msg.payload.records.solar_yield_forecast[0][1] ? Pour moi, cette donnée est à longueur de journée cohérente avec le J+1 sur VRM - toute autre donnée ne l’est pas.
Pour ma part, les prévisions sont récupérées ainsi :
Et traitées ainsi :
let j0_timestamp = msg.payload.records.solar_yield_forecast[0][0];
let j0_prevision = msg.payload.records.solar_yield_forecast[0][1];
let j1_timestamp = msg.payload.records.solar_yield_forecast[1][0];
let j1_prevision = msg.payload.records.solar_yield_forecast[1][1];
let j2_timestamp = msg.payload.records.solar_yield_forecast[2][0];
if (typeof j0_timestamp === 'number' && typeof j0_prevision === 'number' &&
typeof j1_timestamp === 'number' && typeof j1_prevision === 'number' &&
typeof j2_timestamp === 'number') {
flow.set('vrm_j0_timestamp', j0_timestamp);
flow.set('vrm_j0_prevision', j0_prevision);
flow.set('vrm_j1_timestamp', j1_timestamp);
flow.set('vrm_j1_prevision', j1_prevision);
flow.set('vrm_j2_timestamp', j2_timestamp);
let date = new Date();
let hhmm = date.getHours()+'h'+date.getMinutes();
node.status({fill:"grey",shape:"dot",text:hhmm+': '+j0_prevision.toFixed(0)+' - '+j1_prevision.toFixed(0)});
}
return null;
Merci pour vos réponses. J’ai plusieurs questions :
Est ce que tous les paramètres que vous citez peuvent être changés via la console à distance dans VRM ou uniquement via node red ? (Je ne vois pas l’ESS State dans la console par exemple).
Quelle est la différence entre Minimum SoC et Active SoC ? Je ne peux pas changer l’active SoC via la console VRM est ce normal ?
Avec quel node changes tu de ON à Inverter Only et vice versa ? C’est bien avec le node VE.bus System ?
Le minimum SoC à 5% ce n’est pas dommageable pour les batteries ?
En soit non mais si on peut l’éviter pourquoi s’en priver
Je ne comprends pas. “Il suffit de le réécrire”, tu veux dire de le re-paramétrer ? L’active SoC limit est géré automatiquement par le système non ?
Merci à vous !