Het grote Victron aansturing topic

[Ersus]

@V_ger Hier de nodes gekoppeld met handmatige inject en de cron node, de cron tijden heb ik op 2025 laten staan zodat er in ieder geval niets vanzelf uitgevoerd wordt als je de code importeert.

code:

[
    {
        "id": "b010db0acb5aa278",
        "type": "cronplus",
        "z": "10d901f9c3a26388",
        "name": "Charge limit Planner",
        "outputField": "payload",
        "timeZone": "",
        "storeName": "",
        "commandResponseMsgOutput": "output1",
        "defaultLocation": "",
        "defaultLocationType": "default",
        "outputs": 1,
        "options": [
            {
                "name": "schedule1",
                "topic": "topic1",
                "payloadType": "num",
                "payload": "2",
                "expressionType": "cron",
                "expression": "0 45 23 2 10 * 2025",
                "location": "",
                "offset": "0",
                "solarType": "all",
                "solarEvents": "sunrise,sunset"
            },
            {
                "name": "schedule2",
                "topic": "topic2",
                "payloadType": "num",
                "payload": "4",
                "expressionType": "cron",
                "expression": "0 59 23 20 9 * 2025",
                "location": "",
                "offset": "0",
                "solarType": "all",
                "solarEvents": "sunrise,sunset"
            },
            {
                "name": "schedule3",
                "topic": "topic3",
                "payloadType": "num",
                "payload": "2",
                "expressionType": "cron",
                "expression": "0 00 00 21 9 * 2025",
                "location": "",
                "offset": "0",
                "solarType": "all",
                "solarEvents": "sunrise,sunset"
            }
        ],
        "x": 1280,
        "y": 540,
        "wires": [
            [
                "b1255cb9029c80dd"
            ]
        ]
    },
    {
        "id": "6a48873b4cb97a6b",
        "type": "inject",
        "z": "10d901f9c3a26388",
        "name": "",
        "props": [
            {
                "p": "payload"
            }
        ],
        "repeat": "",
        "crontab": "",
        "once": false,
        "onceDelay": 0.1,
        "topic": "",
        "payload": "38.4",
        "payloadType": "num",
        "x": 1330,
        "y": 600,
        "wires": [
            [
                "b1255cb9029c80dd"
            ]
        ]
    },
    {
        "id": "b1255cb9029c80dd",
        "type": "victron-output-dess",
        "z": "10d901f9c3a26388",
        "service": "com.victronenergy.settings",
        "path": "/Settings/DynamicEss/BatteryChargeLimit",
        "serviceObj": {
            "service": "com.victronenergy.settings",
            "name": "Venus settings"
        },
        "pathObj": {
            "path": "/Settings/DynamicEss/BatteryChargeLimit",
            "type": "float",
            "name": "Battery charge limit (kW)",
            "mode": "both"
        },
        "name": "Set Dynamic ESS Battery Charge limit",
        "onlyChanges": false,
        "x": 1590,
        "y": 600,
        "wires": []
    },
    {
        "id": "afd811906fae85fe",
        "type": "global-config",
        "env": [],
        "modules": {
            "node-red-contrib-cron-plus": "2.2.1",
            "@victronenergy/node-red-contrib-victron": "1.6.55"
        }
    }
]

[V_ger]

Ersus schreef op vrijdag 9 januari 2026 @ 18:11:
[...]


Ah ok, dat zou je dan via de DESS batterij laad capaciteit moeten doen.

Ik denk dat je het hiermee kan doen:
net getest, dan geef je DESS de lagere laadwaarde mee voor de batterij, dan zou die de planning daaraan moeten aanpassen.

code:

[
    {
        "id": "6a48873b4cb97a6b",
        "type": "inject",
        "z": "10d901f9c3a26388",
        "name": "",
        "props": [
            {
                "p": "payload"
            }
        ],
        "repeat": "",
        "crontab": "",
        "once": false,
        "onceDelay": 0.1,
        "topic": "",
        "payload": "2",
        "payloadType": "num",
        "x": 1330,
        "y": 600,
        "wires": [
            [
                "b1255cb9029c80dd"
            ]
        ]
    },
    {
        "id": "b1255cb9029c80dd",
        "type": "victron-output-dess",
        "z": "10d901f9c3a26388",
        "service": "com.victronenergy.settings",
        "path": "/Settings/DynamicEss/BatteryChargeLimit",
        "serviceObj": {
            "service": "com.victronenergy.settings",
            "name": "Venus settings"
        },
        "pathObj": {
            "path": "/Settings/DynamicEss/BatteryChargeLimit",
            "type": "float",
            "name": "Battery charge limit (kW)",
            "mode": "both"
        },
        "name": "Set Dynamic ESS Battery Charge limit",
        "onlyChanges": false,
        "x": 1590,
        "y": 600,
        "wires": []
    },
    {
        "id": "38406eac69a3d2ba",
        "type": "global-config",
        "env": [],
        "modules": {
            "@victronenergy/node-red-contrib-victron": "1.6.55"
        }
    }
]

Thanks, ik zal weer eens een poging wagen.

[ditbenikecht]

Oeps, kan beter in ontwerp topic.

[ Voor 97% gewijzigd door ditbenikecht op 09-01-2026 22:28 ]

[Japie.G]

Hmm ik zet er net een schema in voor 3 uur laden vanaf 2 uur vannacht, maar wat ik ook doe, hij blijft op inactief staan. Iemand een idee?



Heb er wel een schema onder zitten die ingeschakeld is. Dess aan of uit verandert ook niets.

[gertvdijk]

Japie.G schreef op vrijdag 9 januari 2026 @ 23:16:
Hmm ik zet er net een schema in voor 3 uur laden vanaf 2 uur vannacht, maar wat ik ook doe, hij blijft op inactief staan. Iemand een idee?

Dat betekent gewoon dat het nog geen tijd is. Zodra een schedule het laden activeert zal er 'actief' staan.

[Japie.G]

gertvdijk schreef op zaterdag 10 januari 2026 @ 02:20:
[...]

Dat betekent gewoon dat het nog geen tijd is. Zodra een schedule het laden activeert zal er 'actief' staan.

Oeps, my bad! Tnx! Dacht dat ik dat getest had. DESS op aan overruled deze programma’s dus. Met DESS uit werkt het inderdaad zoals gepland.

[Flesdop]

Bij hoeveel cent laten jullie DESS niet meer handelen? Bij mij handelt die momenteel bij 8 cent verschil maar ik twijfel of dat wel rendabel is.

[reneeke1970]

Flesdop schreef op zaterdag 10 januari 2026 @ 12:36:
Bij hoeveel cent laten jullie DESS niet meer handelen? Bij mij handelt die momenteel bij 8 cent verschil maar ik twijfel of dat wel rendabel is.

Je moet niet naar centen kijken maar procenten.
Voor 2 cent inkopen en 10 verkopen is vette winst.
Voor 30 kopen en 38 verkopen is vet verlies.
Je rte verlies moet het prijs verschil zijn.
Voor mezelf is de inkoop prijs plus 50 procent pas quit spelen, erboven is de winst

[DanTm]

Flesdop schreef op zaterdag 10 januari 2026 @ 12:36:
Bij hoeveel cent laten jullie DESS niet meer handelen? Bij mij handelt die momenteel bij 8 cent verschil maar ik twijfel of dat wel rendabel is.

Het is geen vast bedrag, er moet het percentage van je efficiency tussen inkoop en verkoop zitten.
Dus bv verkoop*0.8>inkoop.
Dus bij 100cent verkoop, moet er minimaal 20cent tussen zitten, bij 10cent verkoop maar 2cent.

[V_ger]

Ik doe het volgende.
Alles tussen inkoop en 1.2*inkoop gebruik ik van het net.
Tussen 1.2-1.35* inkoop gebruik ik uit de batterij. Bij meer dan 1.35*inkoop EN >10 cent verschil ga ik actief verkopen.
Geen zin in bak warmte en herrie voor 10 cent winst per uur.

[Beer070]

reneeke1970 schreef op zaterdag 10 januari 2026 @ 13:13:
[...]

Je moet niet naar centen kijken maar procenten.
Voor 2 cent inkopen en 10 verkopen is vette winst.
Voor 30 kopen en 38 verkopen is vet verlies.
Je rte verlies moet het prijs verschil zijn.
Voor mezelf is de inkoop prijs plus 50 procent pas quit spelen, erboven is de winst

Even op het betweter vlak reageren… je hebt helemaal gelijk, maar er zijn ook bepaalde vaste kosten/kwh opslag en transmissie die meespelen. Ik heb ze niet uitgerekend, en ze zouden verwaarloosbaar kunnen zijn in het bereik van elektra prijzen, maar als je inkoopt voor 0,002 cent, en verkoopt voor 0,003 cent dan gaat de procenten aanpak niet op.
Heb jij enig inzicht in waar de 50% van jou uit opgebouwd is? Ik snap kabel weerstand (heen en terug), accu en omvormer verliezen, in/verkoop vergoeding enzovoort, maar dan voelt 50% nog steeds aan de hoge kant.
Misschien is er iets in mijn blinde vlek..?

[Japie.G]

Als ik morgen mijn pv overschot gewoon het net op wil laten gaan, en niet in de accu wil laten laden (dat doet ESS standaard als ik DESS uitzet) Wat is dan de makkelijkste manier om de hele boel gewoon inactief te krijgen? Of gewoon DESS aanzetten en hopen dat die de pv opwek het net op laat gaan?

[Ersus]

Japie.G schreef op zaterdag 10 januari 2026 @ 19:20:
Als ik morgen mijn pv overschot gewoon het net op wil laten gaan, en niet in de accu wil laten laden (dat doet ESS standaard als ik DESS uitzet) Wat is dan de makkelijkste manier om de hele boel gewoon inactief te krijgen? Of gewoon DESS aanzetten en hopen dat die de pv opwek het net op laat gaan?

De CCL (Maximum charge current) op 0 zetten in de console interface, dan gaat ook met DESS ingeschakeld alle overschot het net op.

[reneeke1970]

Beer070 schreef op zaterdag 10 januari 2026 @ 14:29:
[...]

Even op het betweter vlak reageren… je hebt helemaal gelijk, maar er zijn ook bepaalde vaste kosten/kwh opslag en transmissie die meespelen. Ik heb ze niet uitgerekend, en ze zouden verwaarloosbaar kunnen zijn in het bereik van elektra prijzen, maar als je inkoopt voor 0,002 cent, en verkoopt voor 0,003 cent dan gaat de procenten aanpak niet op.
Heb jij enig inzicht in waar de 50% van jou uit opgebouwd is? Ik snap kabel weerstand (heen en terug), accu en omvormer verliezen, in/verkoop vergoeding enzovoort, maar dan voelt 50% nog steeds aan de hoge kant.
Misschien is er iets in mijn blinde vlek..?

Ik heb gemeten met mijn slimme meter wat er op vol vermogen de accu in gaat, en weer eruit. Rte is 69 procent. Geloof dat mijn rekenmachine op 42 procent kwam, maar beetje afschrijving erbij, en gewoon gemakkelijk getal maakt 50 procent.
Een victron produceert een niet zo mooi stroompje, de slimme meter registreert meer vermogen dan losse kWh meters...
Dus als ik zie dat inkoop 10 cent is en verkoop 15 dan doe ik niks met de accu.
Oh PS... Ik heb zonne plan, en voor de verkoop prijs moet ik er wel overdag de zonne bonus bij tellen, soms wat lastig maarja het zij zo. De app geeft het niet aan helaas

Zal sommetje maken, er gaat 19.5 kWh de accu in ,voor bv 10 cent, oftewel 1.95 euro.
Er komt uit de accu 13.5 kWh voor verkoop 15 cent, oftewel 2.02 euro, maakt 7 cent winst. Dus vandaar bij 50 procent prijs verschil doe ik niks

[ Voor 15% gewijzigd door reneeke1970 op 10-01-2026 20:39 ]

[Beer070]

reneeke1970 schreef op zaterdag 10 januari 2026 @ 20:23:
[...]

Ik heb gemeten met mijn slimme meter wat er op vol vermogen de accu in gaat, en weer eruit. Rte is 69 procent. Geloof dat mijn rekenmachine op 42 procent kwam, maar beetje afschrijving erbij, en gewoon gemakkelijk getal maakt 50 procent.
Een victron produceert een niet zo mooi stroompje, de slimme meter registreert meer vermogen dan losse kWh meters...
Dus als ik zie dat inkoop 10 cent is en verkoop 15 dan doe ik niks met de accu.
Oh PS... Ik heb zonne plan, en voor de verkoop prijs moet ik er wel overdag de zonne bonus bij tellen, soms wat lastig maarja het zij zo. De app geeft het niet aan helaas

Zal sommetje maken, er gaat 19.5 kWh de accu in ,voor bv 10 cent, oftewel 1.95 euro.
Er komt uit de accu 13.5 kWh voor verkoop 15 cent, oftewel 2.02 euro, maakt 7 cent winst. Dus vandaar bij 50 procent prijs verschil doe ik niks

Dank. Ik snap de uitleg.

[g1n0]

Wij zijn van een simpele ats naar een wat uitgebreidere gegaan voor de generator. Voorheen schakelde we relay 1 op de cerbo waardoor de genset aan ging, nu starten we extern.

Ik zou dit graag wel terugkoppelen aan de cerbo (ookal is het volgens mij niet nodig). Digital input is ivm afstand geen optie meer. Dus ik zou dit graag via nodered/dbus doen, maar ik weet niet welke… (zowat alles met “gen” erin geprobeerd).

Iemand hier een idee?

[cyclone]

@g1n0 voor mij ook nog onontgonnen gebied maar zou graag van jou wat willen leren :-)
Hoe ziet jouw setup eruit ?

Ik heb een 3 fase MultiPlus-II 48/5000/70-50 setup die nu met de AC in aan het Grid hangt.
Tevens heb ik een generator staan voor "in geval van nood" die ik als het Grid er niet is aan wil sluiten op de AC1 ( voor de puristen onderons dan heb ik hem dus volledig geisoleerd van het Grid).

Hoe doe jij dat en hoe heb jij de instellingen staan van jouw AC in ? Ik heb her en der gelezen dat i.v.m. de minder "schone" sinus / spanning die een generator levert de Multiplussen kunnen gaan zeuren / instellingen nodig hebben om goed samen te kunnen werken met een generator.

Ben nu dus beetje huiverig om zomaar de boel om te zetten en een test te gaan doen, niet omdat ik het niet aandurf maar gezien mijn hele huis op dit moment achter de Victrons hangt en ik thuis wat minder enthousiaste reacties krijg als ik een black out creëer :-)

[g1n0]

cyclone schreef op maandag 12 januari 2026 @ 11:31:
@g1n0 voor mij ook nog onontgonnen gebied maar zou graag van jou wat willen leren :-)
Hoe ziet jouw setup eruit ?

Hey, ik heb quattro’s. Precies om de reden die jij aangeeft.
Je kan het met een ats/omschakelautomaat voor de ac in proberen. Ergste wat er kan gebeuren is dat de MP afkoppelt omdat de frequentie te veel uit de pas gaat lopen (is al snel met een 1 cilinder aggregaatje met mechanische gouverner).
De ups functie moet meestal wel uit (anders is victron te picky vanwege de frequentie die bij een genset snel +/- 2-3Hz afwijkt), maar aangezien ik achter fase 2 en 3 nog 2 aparte ups’s heb voor mn servertjes (feed a en b) is dat bij mij geen probleem.
Daarnaast kan LOM ook issues geven bij generator input. Dit was voor mij ook een reden om voor quattro’s te gaan. Ik heb op ac-in2 (genset) LOM dus uitstaan.
Ik ben zelf dus wel van een 1 cilinder aggregaat naar een 2 cilinder gegaan vanwege de meer stabielere frequentie en spanning. Maar dat moet ook in je budget passen, aangezien die prijs vaak tweevoud (of meer) is van de 1 cilinders. (2cilinder 1500rpm model zou nog mooier zijn, maar dat viel dan weer buiten mijn budget )

[cyclone]

Jip de Quattro vond / vind ik te prijzig ten op zichte van de multiplus II, maar dat is wel de beste oplossing als je met een generator aan de gang gaat.
Dat was ik ook niet van plan maar iets met een verveeld moment en een veiling site waar ik "per ongeluk" opeens een 3 fase 8kva generator had gekocht :-) Tis overigens een 1 cylinder 3000RPM

Kortom leuk als ik het allemaal automatisch aan de praat krijg if not ook dikke prima dan configureer ik de boel wel om als de nood aan de man komt.
Nu even aan het kijken of er lot genoten zijn die een zelfde soort setup hebben / of mogelijk al aan de praat hebben gekregen.

[ Voor 3% gewijzigd door cyclone op 13-01-2026 16:52 ]

[Japie.G]

Is er binnen nodered ook een setting te vinden die het hele ESS of DESS in idle zet? Gewoon inactief? Niet laden, niet ontladen?

[DanTm]

Japie.G schreef op dinsdag 13 januari 2026 @ 21:16:
Is er binnen nodered ook een setting te vinden die het hele ESS of DESS in idle zet? Gewoon inactief? Niet laden, niet ontladen?

Je kunt hem op external control zetten, of zelfs helemaal uit via node red. Je kunt hem dan ook weer aan zetten, hij is dus niet helemaal uit. Scheelt standby verbruik. Ik zet die van mij uit als er niet geladen of ontladen wordt.

[ Voor 25% gewijzigd door DanTm op 13-01-2026 21:40 ]

[Japie.G]

DanTm schreef op dinsdag 13 januari 2026 @ 21:38:
[...]

Je kunt hem op external control zetten, of zelfs helemaal uit via node red. Je kunt hem dan ook weer aan zetten, hij is dus niet helemaal uit. Scheelt standby verbruik. Ik zet die van mij uit als er niet geladen of ontladen wordt.

Oh das slim denk ik. Via welke control node doe je dat?

[DanTm]

Japie.G schreef op dinsdag 13 januari 2026 @ 21:40:
[...]


Oh das slim denk ik. Via welke control node doe je dat?

Zie screenshot bij mijn reactie

[V_ger]

Maar dan springt ie ook niet aan als de stroom uitvalt ...

[Japie.G]

Ook waar,

Ik zet de ESS mode nu op 3 (external control), dan gaat het hele zaakje naar inactief. Voor nu doet dat wat ik wil. Dank!

Het is voor een tijdelijke manual override van DESS. Som ook prima om het handmatig in te stellen. Het ellendige is, mijn auto wordt 'slim' geladen door Frank Energie. Ik kan dus vooraf nooit zien precies wanneer. Ik wil dat als de prijzen laag zijn de batterij geladen wordt, maar als de EV lader aanspringt moet de victron max charge current naar 0, zodat de auto ruim baan krijgt. Als de auto weer klaar is met laden mag de victron weer doorgaan met laden. Maar aan het einde van het door mij ingestelde tijdsblok moet hij niet weer lekker gaan ontladen op de accu. Dus dan moet de boel even inactief, totdat ik weer tijd heb om hem vrij te geven of anders in te stellen ;-). Dat noodstroom dan even niet werkt is niet handig, maar optimaliseer ik later wel

[ Voor 74% gewijzigd door Japie.G op 14-01-2026 08:36 ]

[DanTm]

V_ger schreef op dinsdag 13 januari 2026 @ 22:06:
Maar dan springt ie ook niet aan als de stroom uitvalt ...

dan zet je 'm ff aan (kan via node-red weer) maar als je directe noodstroom heel belangrijk vind dan moet je dat niet gebruiken inderdaad.
Het scheelt iig 30 watt.

[ Voor 3% gewijzigd door DanTm op 14-01-2026 09:21 ]

[V_ger]

DanTm schreef op woensdag 14 januari 2026 @ 09:15:
[...]

dan zet je 'm ff aan (kan via node-red weer) maar als je directe noodstroom heel belangrijk vind dan moet je dat niet gebruiken inderdaad.
Het scheelt iig 30 watt.

Maar als de stroom uitvalt en de Victron schakelt niet in, dan is mijn netwerk ook weg en kan ik dus niet bij de Cerbo om instellingen te wijzigen... Of dan moet je een local AP hebben ingesteld ofzo.

[DanTm]

V_ger schreef op woensdag 14 januari 2026 @ 09:40:
[...]

Maar als de stroom uitvalt en de Victron schakelt niet in, dan is mijn netwerk ook weg en kan ik dus niet bij de Cerbo om instellingen te wijzigen... Of dan moet je een local AP hebben ingesteld ofzo.

Mijn cerbo zit op de batterij.. met een kabeltje en een laptop kom ik er wel bij. Anders moet je idd een AP op de batterij hebben.
Ik heb de noodstroom optie voor als er echt nood is, een gewone stroomstoring van een paar minuten (of een paar uurtjes) vind ik prima.
Je zou ook een knopje aan een digitale input van de cerbo kunnen hangen, waarmee je de Victron weer kunt inschakelen.

[ Voor 9% gewijzigd door DanTm op 14-01-2026 10:05 ]

[DanTm]

Japie.G schreef op woensdag 14 januari 2026 @ 08:32:

Ik zet de ESS mode nu op 3 (external control), dan gaat het hele zaakje naar inactief. Voor nu doet dat wat ik wil. Dank!
Dat noodstroom dan even niet werkt is niet handig, maar optimaliseer ik later wel

volgens mij werkt noodstroom wel als hij op external control staat, maar je zou het kunnen testen natuurlijk.
https://www.victronenergy.com/live/ess:ess_mode_2_and_3
`When no grid is available, it will seamlessly switch to inverter mode, unless the switch is set to charger-only. While in inverter mode, the Power setpoint is ineffective.`

[Rimco]

@DanTm mode 3 is inderdaad gewoon inclusief noodstroom. Mode 3 gebruik ik ook met mijn eigen regellus. Alleen als je in mode 3 geen setpoint meegeeft gaat hij in pass-through uit voorzorg, maar dat heeft geen effect op de backup.

Als je de mode op "off" zet heb je inderdaad ook geen backup.

[DanTm]

Rimco schreef op woensdag 14 januari 2026 @ 12:35:
@DanTm mode 3 is inderdaad gewoon inclusief noodstroom. Mode 3 gebruik ik ook met mijn eigen regellus. Alleen als je in mode 3 geen setpoint meegeeft gaat hij in pass-through uit voorzorg, maar dat heeft geen effect op de backup.

Als je de mode op "off" zet heb je inderdaad ook geen backup.

ik heb zelf maar even een 'on' gemaakt via de digital input op de cerbo, dan hoef ik niet met een laptop te prutsen. Als ik dan echt noodstroom nodig heb kan ik hem met een knopje (of een draadje) weer aan zetten door de DI1 te triggeren.

[Rimco]

@DanTm Hier hangt het hele huis achter de AC-out, dan zou dat minder handig zijn. Maar dan zou je alsnog die instelling softwarematig of fysiek aan een "grid lost" signaal kunnen hangen. Simpel relais die aan AC-in hangt kan je DI1 al aansturen bijvoorbeeld, wellicht wel eentje met een vertraging als het net terug komt

[DanTm]

Rimco schreef op woensdag 14 januari 2026 @ 15:41:
@DanTm Hier hangt het hele huis achter de AC-out, dan zou dat minder handig zijn. Maar dan zou je alsnog die instelling softwarematig of fysiek aan een "grid lost" signaal kunnen hangen. Simpel relais die aan AC-in hangt kan je DI1 al aansturen bijvoorbeeld, wellicht wel eentje met een vertraging als het net terug komt

Ac-uit doet het niet meer als je de Victron op Off zet, lijkt me dan niet handig.

[KrL]

Ik heb recent mijn Victron installatie op basis van Multiplus 2 4k5, Cerbo GX en EM24 als GRID meter afgerond en ben nu bezig met configureren/tweaken. Ik heb problemen om de data uit de EM24 (ethernet) stabiel in de Cerbo en VRM/virtual console te krijgen: ofwel de EM24 disconnect om de ca 15 seconden (en connect dan weer na ca 15 seconden) of hij blijft verbonden maar de Grid data in VRM/virtual console update om de 10 a 15 seconden, veel te lang om ESS te draaien (flinke overshoots). Firmware van zowel Cerbo als EM24 is up to date en heb zowel geprobeerd via een switch als via een directe ethernet kabel direct van EM24 naar Cerbo. Iemand enig idee wat het kan zijn?

[gertvdijk]

KrL schreef op woensdag 14 januari 2026 @ 17:45:
Ik heb recent mijn Victron installatie op basis van Multiplus 2 4k5, Cerbo GX en EM24 als GRID meter afgerond en ben nu bezig met configureren/tweaken. Ik heb problemen om de data uit de EM24 (ethernet) stabiel in de Cerbo en VRM/virtual console te krijgen: ofwel de EM24 disconnect om de ca 15 seconden (en connect dan weer na ca 15 seconden) of hij blijft verbonden maar de Grid data in VRM/virtual console update om de 10 a 15 seconden, veel te lang om ESS te draaien (flinke overshoots). Firmware van zowel Cerbo als EM24 is up to date en heb zowel geprobeerd via een switch als via een directe ethernet kabel direct van EM24 naar Cerbo. Iemand enig idee wat het kan zijn?

Ik heb hier twee VM-3P75CT's maar het principe is volgens mij hetzelfde; de Cerbo gebruikt modbus/tcp of modbus/udp op het 'gevonden' IP. Als de Cerbo hem niet meer ziet kan dat komen doordat hij op dat IP dat ding niet meer kan bereiken. Je verhaal klinkt wel als een IP-adres conflct op het netwerk waarbij de ene keer het verkeer naar het ene apparaat gaat en de andere keer naar een andere omdat ze hetzelfde IP-adres claimen. (Wellicht is dat andere apparaat helemaal geen Victron/modbus iets.)

Als je een kabel direct naar de Cerbo gebruikt, zet je dan ook zelf een statisch IP? En op je normale netwerk via switch, gebruik je dan DHCP? Kan het zijn dat dat IP-adres niet uniek is? Misschien heb je een statisch adres ingesteld binnen de DHCP-range die dan later alsnog werd uitgedeeld aan een ander apparaat.

Ik heb zelf de VM-3P75CT's en de Cerbo een statisch IP-adres gegeven met de Victron Connect app, via een switch in een apart VLAN en het is nog nooit weggevallen. Mijn router/server kan wegvallen, maar onderling communiceren ze nog in het eigen LAN.

Hoe dan ook, kan je iets meer vertellen over je netwerkconfiguratie?

[ Voor 14% gewijzigd door gertvdijk op 14-01-2026 19:32 ]

[KrL]

gertvdijk schreef op woensdag 14 januari 2026 @ 19:27:
[...]

Ik heb hier twee VM-3P75CT's maar het principe is volgens mij hetzelfde; de Cerbo gebruikt modbus/tcp of modbus/udp op het 'gevonden' IP. Als de Cerbo hem niet meer ziet kan dat komen doordat hij op dat IP dat ding niet meer kan bereiken. Je verhaal klinkt wel als een IP-adres conflct op het netwerk waarbij de ene keer het verkeer naar het ene apparaat gaat en de andere keer naar een andere omdat ze hetzelfde IP-adres claimen. (Wellicht is dat andere apparaat helemaal geen Victron/modbus iets.)

Als je een kabel direct naar de Cerbo gebruikt, zet je dan ook zelf een statisch IP? En op je normale netwerk via switch, gebruik je dan DHCP? Kan het zijn dat dat IP-adres niet uniek is? Misschien heb je een statisch adres ingesteld binnen de DHCP-range die dan later alsnog werd uitgedeeld aan een ander apparaat.

Ik heb zelf de VM-3P75CT's en de Cerbo een statisch IP-adres gegeven met de Victron Connect app, via een switch in een apart VLAN en het is nog nooit weggevallen. Mijn router/server kan wegvallen, maar onderling communiceren ze nog in het eigen LAN.

Hoe dan ook, kan je iets meer vertellen over je netwerkconfiguratie?

Op de switch hadden ze beide een uniek static IP in een range waar geen DHCP op wordt uitgegeven, nu direct aangesloten met de netwerkkabel wederom een static IP (192.168.10.1 en 192.168.10.2) dus het kan bijna niet dat het aan een IP conflict ligt. Toen ik ze nog via de switch had aangesloten heb ik vanaf mijn computer een ping gedaan naar zowel de EM24 als de Cerbo en voor beide lag deze rond de 1ms zonder drops/lost packets. Ook bekabeling lijkt me uitgesloten als het zowel via de switch als een directe (andere) kabel gebeurt.

[cyclone]

@KrL Je hebt het over EM24's en over IP adressen / aangesloten via een netwerkkabel.
Echter de EM24 specs die ik kan vinden heeft het totaal niet over ethernet / wifi aansluit mogelijkheden alleen over modbus en Zigbee



Kortom ik snap het eventjes niet weet je zeker dat je de EM24's hebt en niet de VM-3P75CT die is namelijk wel met een ethernet aansluiting uitgerust.

Inmiddels opgehelderd door @habbekrats

Dat even daargelaten je zei immers dat je aan het pingen was geslagen vanaf een andere computer.
Echter wil je de verbinding tussen je Energie meter (even daargelaten welke dit nu precies is) goed controleren dan moet je ook de ping uitvoeren vanaf de Cerbo zelf omdat je dan het volledige netwerk pad controlleert.
Je kunt gelukkig ook op je Cerbo met SSH inloggen en vanaf de CLI dan een ping uitvoeren.
Hier staat beschreven hoe je SSH aanzet / toegang krijgt en moet verbinden.

Als dan de ping ook stabiel is, kun je iig uitsluiten dat het geen netwerk issue is (overigens is het sowieso geen IP conflict als je netjes de boel op static IP hebt staan zoals je hebt beschreven, maar kan er toch wellicht ergens een slechte verbinding zitten / packet loss zijn dat je issue nu veroorzaakt.
Dat kun je dus uitsluiten door direct de ping uit te voeren vanaf je Cerbo.

[ Voor 36% gewijzigd door cyclone op 14-01-2026 22:09 ]

[habbekrats]

cyclone schreef op woensdag 14 januari 2026 @ 21:49:
@KrL Je hebt het over EM24's en over IP adressen / aangesloten via een netwerkkabel.
Echter de EM24 specs die ik kan vinden heeft het totaal niet over ethernet / wifi aansluit mogelijkheden alleen over modbus en Zigbee

[Afbeelding]

Kortom ik snap het eventjes niet weet je zeker dat je de EM24's hebt en niet de VM-3P75CT die is namelijk wel met een ethernet aansluiting uitgerust.

Dat even daargelaten je zei immers dat je aan het pingen was geslagen vanaf een andere computer.
Echter wil je de verbinding tussen je Energie meter (even daargelaten welke dit nu precies is) goed controleren dan moet je ook de ping uitvoeren vanaf de Cerbo zelf omdat je dan het volledige netwerk pad controlleert.
Je kunt gelukkig ook op je Cerbo met SSH inloggen en vanaf de CLI dan een ping uitvoeren.
Hier staat beschreven hoe je SSH aanzet / toegang krijgt en moet verbinden.

Als dan de ping ook stabiel is, kun je iig uitsluiten dat het geen netwerk issue is (overigens is het sowieso geen IP conflict als je netjes de boel op static IP hebt staan zoals je hebt beschreven, maar kan er toch wellicht ergens een slechte verbinding zitten / packet loss zijn dat je issue nu veroorzaakt.
Dat kun je dus uitsluiten door direct de ping uit te voeren vanaf je Cerbo.

kwestie van juiste type zoeken https://zonnepanelensuper...WoL1tMfcforn_M-GRornzFQEu

[cyclone]

@habbekrats thanks die had ik idd niet gevonden.

Anyway ik heb zelf ook even SSH aangezet en een ping aangezet naar mijn VM-3P75CT, deze bevindt zich overigens in een ander VLAN dan mijn Cerbo kortom dit moet over een aantal switches naar mijn firewall en dan weer terug (en dit werkt al ruim een jaar zeer stabiel).

Je ziet wat fluctuatie in de ping tijden maar ik acht dat niet vreemd, als het goed is reageren dergelijke devices wel op ICMP (ping) maar geven ze daar een lage prio aan en kan dat resulteren in wat minder strakke ping tijden maar dat is geen reden tot zorg (zeker niet als er geen packet loss optreedt.
Als je Packet loss ziet dan heb je wel een issue want dat is killing voor dit verkeer gezien het UDP based is (zie screenshot bovenaan "Modbus UDP" en de EM24 of andere meter geen retransmits of uberhaupt weet dat pakketten niet aankomen)

[KrL]

Als dan de ping ook stabiel is, kun je iig uitsluiten dat het geen netwerk issue is (overigens is het sowieso geen IP conflict als je netjes de boel op static IP hebt staan zoals je hebt beschreven, maar kan er toch wellicht ergens een slechte verbinding zitten / packet loss zijn dat je issue nu veroorzaakt.
Dat kun je dus uitsluiten door direct de ping uit te voeren vanaf je Cerbo.

Dank je, ik heb SSH enabled en voer de ping uit direct vanaf de Cerbo over de dedicated kabel direct tussen Cerbo en EM24. Sneller/stabieler kan bijna niet dus lijkt me geen netwerk issue.

code:

root@einstein:~# ping 192.168.10.2
PING 192.168.10.2 (192.168.10.2): 56 data bytes
64 bytes from 192.168.10.2: seq=0 ttl=128 time=0.447 ms
64 bytes from 192.168.10.2: seq=1 ttl=128 time=0.436 ms
64 bytes from 192.168.10.2: seq=2 ttl=128 time=0.406 ms
64 bytes from 192.168.10.2: seq=3 ttl=128 time=0.368 ms
64 bytes from 192.168.10.2: seq=4 ttl=128 time=0.391 ms
64 bytes from 192.168.10.2: seq=5 ttl=128 time=0.390 ms
64 bytes from 192.168.10.2: seq=6 ttl=128 time=0.397 ms
64 bytes from 192.168.10.2: seq=7 ttl=128 time=0.392 ms
64 bytes from 192.168.10.2: seq=8 ttl=128 time=0.451 ms
64 bytes from 192.168.10.2: seq=9 ttl=128 time=0.380 ms
64 bytes from 192.168.10.2: seq=10 ttl=128 time=0.518 ms
64 bytes from 192.168.10.2: seq=11 ttl=128 time=0.383 ms
64 bytes from 192.168.10.2: seq=12 ttl=128 time=0.403 ms
64 bytes from 192.168.10.2: seq=13 ttl=128 time=0.474 ms
64 bytes from 192.168.10.2: seq=14 ttl=128 time=0.378 ms
64 bytes from 192.168.10.2: seq=15 ttl=128 time=0.360 ms
64 bytes from 192.168.10.2: seq=16 ttl=128 time=0.764 ms
64 bytes from 192.168.10.2: seq=17 ttl=128 time=0.381 ms
64 bytes from 192.168.10.2: seq=18 ttl=128 time=0.394 ms
64 bytes from 192.168.10.2: seq=19 ttl=128 time=0.861 ms
64 bytes from 192.168.10.2: seq=20 ttl=128 time=1.536 ms
64 bytes from 192.168.10.2: seq=21 ttl=128 time=0.376 ms
64 bytes from 192.168.10.2: seq=22 ttl=128 time=0.372 ms
64 bytes from 192.168.10.2: seq=23 ttl=128 time=0.372 ms
64 bytes from 192.168.10.2: seq=24 ttl=128 time=0.406 ms
64 bytes from 192.168.10.2: seq=25 ttl=128 time=0.402 ms
64 bytes from 192.168.10.2: seq=26 ttl=128 time=0.471 ms
64 bytes from 192.168.10.2: seq=27 ttl=128 time=0.397 ms
64 bytes from 192.168.10.2: seq=28 ttl=128 time=0.392 ms
64 bytes from 192.168.10.2: seq=29 ttl=128 time=0.378 ms
64 bytes from 192.168.10.2: seq=30 ttl=128 time=0.377 ms

[cyclone]

Je ping is stabiel over de directe kabel dus als je nu nog onstabiel gedrag ziet kun je de netwerkverbinding nu uitsluiten. Die krijg je niet stabieler dan dit.

Nu je toch SSH enabled hebt zou je nog eens kunnen kijken hoe druk je Cerbo is met het commando TOP
Als daar je ziet dat er nog voldoende CPU tijd beschikbaar is heb je de basics wel gechecked.
Zo ziet hij er bij mij uit op dit moment


Dan kom ik ook niet verder dan de basics die je wellicht allang gedaan hebt en de EM24 een factrory default geven. Van de handleiding wordt je ook niet veel wijzer kortom als dit allemaal niet helpt ben je denk ik aangewezen op de support van Victron zelf. Maargoed je hebt dan wel alle basics al uitgeprobeerd dus daarmee heb je alle eerste en tweede lijns support vragen beantwoord

[KrL]

Processor/mem lijkt het ook niet te zijn:

code:

Mem: 365772K used, 663220K free, 6008K shrd, 8592K buff, 117972K cached
CPU:   7% usr   4% sys   0% nic  86% idle   0% io   1% irq   0% sirq
Load average: 0.45 0.85 0.53 2/263 5105

Kwam met wat zoeken op de logfile van de dbus-modbus-client uit, deze lijkt elke 50 seconden ofzo te herstarten vanwege een watchdog timeout. Vreemde is dat hij dit ook doet zonder dat ik de EM24 heb toegevoegd dus dat zou impliceren dat het wellicht helemaal niet een de EM24 ligt maar dat dit het meest zichtbare symptoom is?

code:

root@einstein:~# tail -F /data/log/dbus-modbus-client*/current | tai64nlocal
2026-01-15 08:31:49.009297500   File "/opt/victronenergy/dbus-modbus-client/dbus-modbus-client.py", line 270 in update_timer
2026-01-15 08:31:49.009344500   File "/usr/lib/python3.12/site-packages/gi/overrides/GLib.py", line 497 in run
2026-01-15 08:31:49.009355500   File "/opt/victronenergy/dbus-modbus-client/dbus-modbus-client.py", line 452 in main
2026-01-15 08:31:49.009424500   File "/opt/victronenergy/dbus-modbus-client/dbus-modbus-client.py", line 455 in <module>
2026-01-15 08:31:49.068705500 *** starting dbus-modbus-client ***
2026-01-15 08:31:51.061207500 INFO     dbus-modbus-client.py v1.71
2026-01-15 08:31:51.072508500 INFO     Waiting for localsettings
2026-01-15 08:31:51.125248500 INFO     registered ourselves on D-Bus as com.victronenergy.modbusclient.tcp
2026-01-15 08:32:07.406185500 INFO     [tcp:192.168.10.2:502:1] Found Energy meter: Carlo Gavazzi EM24DINAV23XE1X
2026-01-15 08:32:07.904615500 INFO     registered ourselves on D-Bus as com.victronenergy.grid.cg_BX2150061002C
2026-01-15 08:32:21.065043500 ERROR    Watchdog timeout
2026-01-15 08:32:21.065227500 Thread 0xb47ae400 (most recent call first):
2026-01-15 08:32:21.065232500   File "/opt/victronenergy/dbus-modbus-client/mdns.py", line 40 in recv
2026-01-15 08:32:21.065235500   File "/opt/victronenergy/dbus-modbus-client/mdns.py", line 114 in run
2026-01-15 08:32:21.065238500   File "/usr/lib/python3.12/threading.py", line 1012 in run
2026-01-15 08:32:21.065241500   File "/usr/lib/python3.12/threading.py", line 1075 in _bootstrap_inner
2026-01-15 08:32:21.065282500   File "/usr/lib/python3.12/threading.py", line 1032 in _bootstrap
2026-01-15 08:32:21.065312500 
2026-01-15 08:32:21.065314500 Current thread 0xb5214400 (most recent call first):
2026-01-15 08:32:21.065316500   File "/opt/victronenergy/dbus-modbus-client/watchdog.py", line 21 in run
2026-01-15 08:32:21.065347500   File "/usr/lib/python3.12/threading.py", line 1012 in run
2026-01-15 08:32:21.065375500   File "/usr/lib/python3.12/threading.py", line 1075 in _bootstrap_inner
2026-01-15 08:32:21.065401500   File "/usr/lib/python3.12/threading.py", line 1032 in _bootstrap
2026-01-15 08:32:21.065428500 
2026-01-15 08:32:21.065429500 Thread 0xb69ab020 (most recent call first):
2026-01-15 08:32:21.065454500   File "/usr/lib/python3.12/site-packages/pymodbus/client/sync.py", line 293 in _recv
2026-01-15 08:32:21.065465500   File "/usr/lib/python3.12/site-packages/pymodbus/client/sync.py", line 89 in recv
2026-01-15 08:32:21.065515500   File "/usr/lib/python3.12/site-packages/pymodbus/framer/__init__.py", line 49 in recvPacket
2026-01-15 08:32:21.065526500   File "/usr/lib/python3.12/site-packages/pymodbus/transaction.py", line 367 in _recv
2026-01-15 08:32:21.065572500   File "/usr/lib/python3.12/site-packages/pymodbus/transaction.py", line 299 in _transact
2026-01-15 08:32:21.065634500   File "/usr/lib/python3.12/site-packages/pymodbus/transaction.py", line 175 in execute
2026-01-15 08:32:21.065681500   File "/usr/lib/python3.12/site-packages/pymodbus/client/sync.py", line 109 in execute
2026-01-15 08:32:21.065691500   File "/opt/victronenergy/dbus-modbus-client/client.py", line 32 in execute
2026-01-15 08:32:21.065743500   File "/usr/lib/python3.12/site-packages/pymodbus/client/common.py", line 125 in read_input_registers
2026-01-15 08:32:21.065754500   File "/opt/victronenergy/dbus-modbus-client/client.py", line 41 in read_registers
2026-01-15 08:32:21.065803500   File "/opt/victronenergy/dbus-modbus-client/probe.py", line 113 in probe
2026-01-15 08:32:21.065814500   File "/opt/victronenergy/dbus-modbus-client/probe.py", line 43 in probe
2026-01-15 08:32:21.065869500   File "/opt/victronenergy/dbus-modbus-client/dbus-modbus-client.py", line 168 in probe_devices
2026-01-15 08:32:21.065880500   File "/opt/victronenergy/dbus-modbus-client/dbus-modbus-client.py", line 259 in update
2026-01-15 08:32:21.065936500   File "/opt/victronenergy/dbus-modbus-client/dbus-modbus-client.py", line 304 in update
2026-01-15 08:32:21.065946500   File "/opt/victronenergy/dbus-modbus-client/dbus-modbus-client.py", line 270 in update_timer
2026-01-15 08:32:21.065996500   File "/usr/lib/python3.12/site-packages/gi/overrides/GLib.py", line 497 in run
2026-01-15 08:32:21.066007500   File "/opt/victronenergy/dbus-modbus-client/dbus-modbus-client.py", line 452 in main
2026-01-15 08:32:21.066054500   File "/opt/victronenergy/dbus-modbus-client/dbus-modbus-client.py", line 455 in <module>
2026-01-15 08:32:21.115372500 *** starting dbus-modbus-client ***

[cyclone]

Ik denk wel dat je hier iets te pakken hebt, dit is mijn output als ik zelfde logfile pak gebeurt amper iets in de logfile :



Ben je al in conclaaf met Victron support ? of heb je het daar al in de community gegooid (volgens mij lezen daar ook Victron engineers mee)

[gertvdijk]

KrL schreef op donderdag 15 januari 2026 @ 09:35:
Kwam met wat zoeken op de logfile van de dbus-modbus-client uit, deze lijkt elke 50 seconden ofzo te herstarten vanwege een watchdog timeout. Vreemde is dat hij dit ook doet zonder dat ik de EM24 heb toegevoegd dus dat zou impliceren dat het wellicht helemaal niet een de EM24 ligt maar dat dit het meest zichtbare symptoom is?
[...]

Goede find, dat lijkt meer op de oorzaak inderdaad, maar kan alsnog met de EM24 te maken hebben indien dat stukje software van victron een beetje onhandig is geschreven wellicht en zich zo gedraagt als één device zich al misdraagt.

Je hebt nu één event. Zie je elke keer 'sync.py", line 293 in _recv' voorbij komen daarin? Indien ja, dan impliceert dat toch wel een communicatieprobleem met een modbus device - bijvoorbeeld eentje die vastloopt, traag reageert of dat er ergens packet loss is. Als we dat laatste uitsluiten ruikt het toch wel sterk naar die firmware bugs van de EM24. Is die wel goed geïnstalleerd en gereboot na update enzo?

[KrL]

cyclone schreef op donderdag 15 januari 2026 @ 10:45:
Ben je al in conclaaf met Victron support ? of heb je het daar al in de community gegooid (volgens mij lezen daar ook Victron engineers mee)

Nee nog niet, via NKON al wel aanbod gehad om support partner mee te laten kijken maar wilde nog even eea uitzoeken/uitsluiten.

Je hebt nu één event. Zie je elke keer 'sync.py", line 293 in _recv' voorbij komen daarin? Indien ja, dan impliceert dat toch wel een communicatieprobleem met een modbus device - bijvoorbeeld eentje die vastloopt, traag reageert of dat er ergens packet loss is. Als we dat laatste uitsluiten ruikt het toch wel sterk naar die firmware bugs van de EM24. Is die wel goed geïnstalleerd en gereboot na update enzo?

Ik zat hierdoor ook meer te denken aan een algemeen modbus issue dus heb geprobeerd de Cerbo een factory reset te geven (lukte niet) en vervolgens alles maar losgehaald/uit de configuratie gewijzigd en opnieuw stap voor stap geconfigureerd. Hij vond vervolgens direct de EM24 en en hij lijkt stabiel met nagenoeg live updates, ook na een herstart. Vervolgens Multiplus en BMS aangesloten en ook hiermee geen problemen, het lijkt in de communicatie met mijn 2x Solaredge SE omvormers te zitten (via Sunspec met ID 126): deze had ik handmatig als modbus device toegevoegd in de Cerbo terwijl dat achteraf niet hoeft, waarschijnlijk zorgde dit voor timeouts. Inmiddels is alles verbonden en geconfigureerd en lijkt het te werken zoals het hoort, fingers crossed dat het zo blijft!!

[HRV]

KrL schreef op donderdag 15 januari 2026 @ 12:32:
[...]
het lijkt in de communicatie met mijn 2x Solaredge SE omvormers te zitten (via Sunspec met ID 126): deze had ik handmatig als modbus device toegevoegd in de Cerbo terwijl dat achteraf niet hoeft, waarschijnlijk zorgde dit voor timeouts. Inmiddels is alles verbonden en geconfigureerd en lijkt het te werken zoals het hoort, fingers crossed dat het zo blijft!!

Hoe heb je de SolarEdge nu dan verbonden?

[KrL]

HRV schreef op donderdag 15 januari 2026 @ 12:51:
[...]
Hoe heb je de SolarEdge nu dan verbonden?

Ik heb op beide Modbus aangezet (port 502) en SunSpec (Non-SE Logger) met Device ID 126, vervolgens en scan gedaan binnen Settings - Integration - PV Inverters waarna ze verschenen. Blijkbaar niet nodig (en mogelijk dus zelfs nadelig) om ze ook nog als Modbus device toe te voegen.

[cyclone]

Jep daar gaat het mis, ze horen bij PV inverters te staan (en ook hier heb je de mogelijkheid om ze handmatig op basis van IP adres toe te voegen als ze niet automatisch verschijnen).

[ Voor 47% gewijzigd door cyclone op 15-01-2026 14:02 ]

[Srednier]

Ik draai nu een paar weken DESS, maar dat lijkt nog niet goed te gaan. Elke dag dat de zon er een beetje doorbreekt gaat die opwek voor een aanzienlijk deel het net op terwijl ik met de instelling zou verwachten dat het systeem de accu de nacht ervoor voor eigenverbruik zou gebruiken om overdag de stroom op te kunnen slaan.

In dit plaatje varieerde het accuniveau tussen de 80% en 98%
Iemand een idee waar dat aan kan liggen?

[DanTm]

Srednier schreef op zaterdag 17 januari 2026 @ 15:40:
Ik draai nu een paar weken DESS, maar dat lijkt nog niet goed te gaan. Elke dag dat de zon er een beetje doorbreekt gaat die opwek voor een aanzienlijk deel het net op terwijl ik met de instelling zou verwachten dat het systeem de accu de nacht ervoor voor eigenverbruik zou gebruiken om overdag de stroom op te kunnen slaan.
[Afbeelding]
In dit plaatje varieerde het accuniveau tussen de 80% en 98%
Iemand een idee waar dat aan kan liggen?

Omdat bij een systeem verlies van 80% de zonnestroom beter direct verkocht kan worden, dan later gebruikt.
Maar af en toe zijn er wel dagen dat er wat verdient kan worden, naar het ligt ook erg aan je DESS instellingen natuurlijk wat hij gaat doen.

[Japie.G]

Green mode zo te zien? Ws met default efficiency, hij had nog meer het net op moeten gooien 😉

[Srednier]

DanTm schreef op zaterdag 17 januari 2026 @ 15:45:
[...]

Omdat bij een systeem verlies van 80% de zonnestroom beter direct verkocht kan worden, dan later gebruikt.
Maar af en toe zijn er wel dagen dat er wat verdient kan worden, naar het ligt ook erg aan je DESS instellingen natuurlijk wat hij gaat doen.

een heen en weer verlies van 80% lijkt me wel erg hoog. Als ik ruw schat zou mijn werkelijke verlies tussen de 20 en 30 % moeten liggen, maar ik weet natuurlijk niet waar DESS mee rekent, want dat kan ik kennelijk niet meer instellen.
Verder heb ik bewust het prijsgrafiekje er bij gepost, hij kocht dus 's nachts voor ca 24 cent en verkocht overdag voor 10 cent. Ik heb accukosten ingesteld van 4 cent. Dan zou hij dus breakeven komen bij een rendement van 50% zoals ik het zou rekenen.
Het lijkt mij er op dat DESS denkt dat ik veel minder PV heb dan werkelijk, maar dat kan ik nergens instellen naar ik weet

[Srednier]

Japie.G schreef op zaterdag 17 januari 2026 @ 16:55:
Green mode zo te zien? Ws met default efficiency, hij had nog meer het net op moeten gooien 😉

Verder de instellingen, trade mode zonder net beperkingen, cap 76kWh, 10kW max laden/ontladen
Kun je me dan uitleggen waarom hij dan meer direct het net op had moeten gooien? Kan het zo zijn dat hij intern helemaal niet met de ingestelde prijzen rekent, maar toch nog iets met salderen doet?

[Srednier]

Overigens het DESS plan van morgen, hij plant dat hij alle PV energie wel in de accu gaat stoppen zonder dat het net op te laten gaan. Echter zie ik dat het hier morgen volle bak zon is en er zeker 2x zo veel energie opgewekt gaat worden als dat DESS denkt

[Japie.G]

DESS rekent default met een RTefficiency van 90pct, das veel te rooskleurig in de meeste gevallen. Wat voor multi's heb je? In ieder geval kun je die RTE via bijvoorbeeld NodeRED naar een realistischer waarde zetten. Waarom zit er zo'n groot verschil tussen inkoop en verkoop prijs? Lijkt me ook niet realistisch. Verder doet trade mode in mijn ervaring uberhaupt niet aan self consumption. Vandaar dat ik dacht dat je in green mode draaide. Wellicht is het anders met zulke grote accu capaciteiten? Wellicht gaat je solar inschatting naar verloop van tijd beter kloppen? Ben er ook nog niet helemaal uit wat hij nou doet als je meer pv opwek hebt dan gepland.

[ Voor 13% gewijzigd door Japie.G op 17-01-2026 22:44 ]

[Ersus]

Srednier schreef op zaterdag 17 januari 2026 @ 21:01:
[...]

Verder de instellingen, trade mode zonder net beperkingen, cap 76kWh, 10kW max laden/ontladen
Kun je me dan uitleggen waarom hij dan meer direct het net op had moeten gooien? Kan het zo zijn dat hij intern helemaal niet met de ingestelde prijzen rekent, maar toch nog iets met salderen doet?

DESS saldeert niet, handelt alleen op basis van jouw instellingen.

Accu kosten hoog zetten betekend dat DESS de accu juist minder inzet dan je zou verwachten. Een SOC meting met de Victron SmartShunt geeft ook een beter resultaat.

Accu kosten op €0,01 geeft DESS meer ruimte om de accu in te zetten. De accu is er immers om werk te verzetten. Die kosten zijn al gemaakt.

DESS trade is idd niet op eigen verbruik gericht maar juist op traden waarmee je de eigen stroomkosten uiteindelijk verlaagd.

De stroomtarieven, zoals ze worden afgerekend, ongewijzigd aan DESS voeren geeft met een correct ingestelde RTE het beste resultaat. Als je de Victrons op zijn max laat laden of ontladen dan veroorzaakt dat grotere verliezen (lagere RTE).

Als je meer Trading wil zien verlaag dan het vermogen van de batterij in de DESS batterij instelling. Een lager vermogen betekend een hogere RTE en meer Trading momenten met over de long run een betere omzetting en minder teleurstellingen. Je past tarief manipulatie toe met de verwachting dat DESS het anders gaat doen, maar als de RTE niet overeenkomt met de daadwerkelijke Full load efficiëntie dan stelt het alleen maar teleur.

Het systeem draait met een gemeten efficiëntie van 88% op een ca 60% load van wat de setup kan leveren. En het stelt niet teleur. Integendeel, sinds dat ik stopte met tarief manipulatie en de correct gemeten RTE had ingegeven, leverde Trading ook meer op.

2096kWh import - 1233kWh export + 94,9kWh PV = 957,9kWh
€68,19 / 957,9kWh = €0,0711 per kWh all-in

[Japie.G]

Als je het vermogen voor laden/ontladen in de dess settings lager instelt is dat alleen voor de planning toch? Je stelt dan in de victron settings het laad/ontlaad vermogen gelijk in aan de dess settings voor een kloppend resultaat? Denk inderdaad ook dat het voor de rte beter is om een lager ‘pompvermogen’ te gebruiken.

[KrL]

KrL schreef op donderdag 15 januari 2026 @ 13:47:
[...]

Ik heb op beide Modbus aangezet (port 502) en SunSpec (Non-SE Logger) met Device ID 126, vervolgens en scan gedaan binnen Settings - Integration - PV Inverters waarna ze verschenen. Blijkbaar niet nodig (en mogelijk dus zelfs nadelig) om ze ook nog als Modbus device toe te voegen.

De meter is nu gelukkig stabiel, de SolarEdge monitoring niet: hij verlies regelmatig de verbinding met de omvormers. Is een topic over in de Victron community voor het geval iemand anders er ook last van heeft: https://community.victron...ery-few-minutes/39939/107. Voorlopige workaround: SolarEdge support de omvormers laten downgraden naar firmware 4.22.44

[Ersus]

Japie.G schreef op zondag 18 januari 2026 @ 08:56:
Als je het vermogen voor laden/ontladen in de dess settings lager instelt is dat alleen voor de planning toch? Je stelt dan in de victron settings het laad/ontlaad vermogen gelijk in aan de dess settings voor een kloppend resultaat? Denk inderdaad ook dat het voor de rte beter is om een lager ‘pompvermogen’ te gebruiken.

DESS Settings zijn alleen van toepassing op DESS, die settings waarmee het algoritme voor DESS gevoed wordt.

De andere instellingen voor vermogen in de console gelden voor het hele systeem op hardware level.

[Ersus]

Japie.G schreef op zondag 18 januari 2026 @ 08:56:
Als je het vermogen voor laden/ontladen in de dess settings lager instelt is dat alleen voor de planning toch? Je stelt dan in de victron settings het laad/ontlaad vermogen gelijk in aan de dess settings voor een kloppend resultaat? Denk inderdaad ook dat het voor de rte beter is om een lager ‘pompvermogen’ te gebruiken.

Op hardware level zou ik de waarden invullen zoals ze daadwerkelijk zijn. Dus alleen het DESS batterij vermogen verlagen zodat DESS die waarden neemt voor de handel. Maar de rest van het systeem laten zoals het is zodat er geen restricties zijn bij noodstroom of powerassist peakshaving.

[Japie.G]

Ersus schreef op zondag 18 januari 2026 @ 11:25:
[...]


DESS Settings zijn alleen van toepassing op DESS, die settings waarmee het algoritme voor DESS gevoed wordt.

De andere instellingen voor vermogen in de console gelden voor het hele systeem op hardware level.

Even een klein testje gedaan. De vermogens voor laden en ontladen die je in kW instelt in het DESS accusettings menu lijken toch wel echt gebruikt te worden door DESS. Ik dacht dat het alleen op de planning invloed had. Maar als ik 2kW instel als laadvermogen (in dess) gaat hij ook echt niet harder laden dan 2kW binnen DESS. Dacht ergens gelezen te hebben dat het enkel voor tijdsplanning gebruikt werd, maar ik zat fout :-)

[ Voor 7% gewijzigd door Japie.G op 18-01-2026 12:35 ]

[gertvdijk]

Japie.G schreef op zondag 18 januari 2026 @ 12:26:
Even een klein testje gedaan. De vermogens voor laden en ontladen die je in kW instelt in het DESS accusettings menu lijken toch wel echt gebruikt te worden door DESS. Ik dacht dat het alleen op de planning invloed had. Maar als ik 2kW instel als laadvermogen gaat hij ook echt niet harder laden dan 2kW binnen DESS. Dacht ergens gelezen te hebben dat het enkel voor tijdsplanning gebruikt werd, maar ik zat fout :-)

Ik denk dat je (nieuwe) analyse klopt. De Cerbo krijgt een sloot aan 'schedules' van een kwartier (of een uur). Globaal is er een charge rate, inderdaad. Een discharge rate lijkt er niet te zijn, maar middels de target-SoC en je batterijcapaciteit impliciet te worden bepaald.


(afbeelding uit MQTT-Explorer, DESS staat nu uit)

[Srednier]

Ersus schreef op zondag 18 januari 2026 @ 00:35:
[...]


DESS saldeert niet, handelt alleen op basis van jouw instellingen.

Accu kosten hoog zetten betekend dat DESS de accu juist minder inzet dan je zou verwachten. Een SOC meting met de Victron SmartShunt geeft ook een beter resultaat.

Accu kosten op €0,01 geeft DESS meer ruimte om de accu in te zetten. De accu is er immers om werk te verzetten. Die kosten zijn al gemaakt.

DESS trade is idd niet op eigen verbruik gericht maar juist op traden waarmee je de eigen stroomkosten uiteindelijk verlaagd.

De stroomtarieven, zoals ze worden afgerekend, ongewijzigd aan DESS voeren geeft met een correct ingestelde RTE het beste resultaat. Als je de Victrons op zijn max laat laden of ontladen dan veroorzaakt dat grotere verliezen (lagere RTE).

Als je meer Trading wil zien verlaag dan het vermogen van de batterij in de DESS batterij instelling. Een lager vermogen betekend een hogere RTE en meer Trading momenten met over de long run een betere omzetting en minder teleurstellingen. Je past tarief manipulatie toe met de verwachting dat DESS het anders gaat doen, maar als de RTE niet overeenkomt met de daadwerkelijke Full load efficiëntie dan stelt het alleen maar teleur.

Het systeem draait met een gemeten efficiëntie van 88% op een ca 60% load van wat de setup kan leveren. En het stelt niet teleur. Integendeel, sinds dat ik stopte met tarief manipulatie en de correct gemeten RTE had ingegeven, leverde Trading ook meer op.

2096kWh import - 1233kWh export + 94,9kWh PV = 957,9kWh
€68,19 / 957,9kWh = €0,0711 per kWh all-in

[Afbeelding]

Wat ik er beter eerder bij had kunnen vermelden is dat ik de DESS instelling zo heb gezet dat ik de meeste winst zou behalen uit een dynamisch Tibber contract waarbij er geen saldering meer is, maw ongelimiteerd trade mode maar wel de met een belastingverschil tussen inkoop/verkoop (10kW limiet). En aangezien ik veel winterverbruik heb met de warmtepomp is het dan juist belangrijk om de opwek van een zonnige korte piek het verbruik te spreiden over het etmaal.
Nu heb ik deze periode minder opwek dan verbruik, maar DESS probeert bijna elk etmaal de accu op 100% SOC te krijgen. Hierdoor gaat er vaak stroom het net op omdat er meer opwek is dan verwacht. Ik zou het logischer vinden dat hij in een lager stuk SOC bereik gaat plannen waardoor hij meer dan geplande opwek ook kwijt kan.
Ik teer nu nog even op een vast contract zonder terugleverkosten maar probeer het systeem alvast zo in te regelen, want in de nabije toekomst zal ik ook dynamisch moeten

[cyclone]

@KrL is hier ook al ruimschoots aan bod gekomen inderdaad met eenzelfde conclusie de downgrade van de SolarEdge omvormers.

Ik heb er 2 hangen (1 nog niet in productie) dus zal zodra ik mijn extra panelen heb liggen (ga ik dit voorjaar doen) eens experimenteren met 2 firmwares van de SolarEdges om te kijken wat hier nou de rootcause is.

[Ersus]

Srednier schreef op zondag 18 januari 2026 @ 12:56:
[...]

Wat ik er beter eerder bij had kunnen vermelden is dat ik de DESS instelling zo heb gezet dat ik de meeste winst zou behalen uit een dynamisch Tibber contract waarbij er geen saldering meer is, maw ongelimiteerd trade mode maar wel de met een belastingverschil tussen inkoop/verkoop (10kW limiet). En aangezien ik veel winterverbruik heb met de warmtepomp is het dan juist belangrijk om de opwek van een zonnige korte piek het verbruik te spreiden over het etmaal.
Nu heb ik deze periode minder opwek dan verbruik, maar DESS probeert bijna elk etmaal de accu op 100% SOC te krijgen. Hierdoor gaat er vaak stroom het net op omdat er meer opwek is dan verwacht. Ik zou het logischer vinden dat hij in een lager stuk SOC bereik gaat plannen waardoor hij meer dan geplande opwek ook kwijt kan.
Ik teer nu nog even op een vast contract zonder terugleverkosten maar probeer het systeem alvast zo in te regelen, want in de nabije toekomst zal ik ook dynamisch moeten

Als je DESS gebruikt dan valt er niet veel in te regelen dan alleen het ingeven van realistische data zodat het DESS algoritme zijn werk kan doen op basis van die juiste gegevens waaronder de RTE

Als je start met tijdverschoven injectie en dat op 100% systeemlast, omdat je op korte tijd veel kWh's kwijt wil, dan is het effect bijna hetzelfde als met een fiets de formule 1 doen, heel teleurstellend. Dito andersom als je gaat laden op 100%.

Traden zal eigen verbruik uit de accu laten komen als dat voordeliger is dan het resultaat van export, waarbij de verliezen van import en batterij kosten ook zijn betrokken. Daarom is het handiger om DESS de tarieven mee te geven zoals ze daadwerkelijk zijn, behalve de batterijkosten, die zou ik persoonlijk standaard op €0,01 zetten om eerder genoemde redenen.

[Japie.G]

Batterijkosten kunnen ook nog op 0,001 zie ik.

Ik zie nu ook DESS zijn plan van vandaag aanpassen nu de tarieven vanmorgen er zijn. Das wel nice!

[ Voor 52% gewijzigd door Japie.G op 18-01-2026 14:04 ]

[Ersus]

Japie.G schreef op zondag 18 januari 2026 @ 12:26:
[...]


Even een klein testje gedaan. De vermogens voor laden en ontladen die je in kW instelt in het DESS accusettings menu lijken toch wel echt gebruikt te worden door DESS. Ik dacht dat het alleen op de planning invloed had. Maar als ik 2kW instel als laadvermogen (in dess) gaat hij ook echt niet harder laden dan 2kW binnen DESS. Dacht ergens gelezen te hebben dat het enkel voor tijdsplanning gebruikt werd, maar ik zat fout :-)

Dat is het net, DESS is het algoritme voor traden of groen geoptimaliseerd eigen verbruik. Maar als je met handel gaat zitten roeien in zijn 100% last dan zijn de verliezen veel groter dan de meestal ingestelde (wens) RTE wat weer leidt naar teleurstellingen die wederom dan de schuld van DESS zijn....dus niet.

Als je de RTE vaststelt met testen van je 100% load en je gaat ook testen met minder load dan neem je de vermogens die een mooier RTE resultaat gaven tijdens je test. Die RTE stel je in en het geteste vermogen bij die RTE geef je in bij je batterij vermogen in DESS. Die invloed heb je omdat je DESS daarmee aangeeft dat er met dat vermogen gecalculeerd moet worden. Je past je parcours aan waarop je wel met je fiets iets van bevredigend resultaat kan behalen.

Als je de fiets wil aanpassen omdat je niet tevreden bent dan moet je er een parallel systeem aanhangen of een groter vermogen omvormer nemen zodat je gewenste vermogen niet meer in die 100% systeembelasting hoeft te werken. Je upgrade je fiets dan met een motor voor je parcours.

[Ersus]

Japie.G schreef op zondag 18 januari 2026 @ 14:03:
Batterijkosten kunnen ook nog op 0,001 zie ik.

Ik zie nu ook DESS zijn plan van vandaag aanpassen nu de tarieven vanmorgen er zijn. Das wel nice!

Heb ik ook eens geprobeerd en dat werd na opslaan veranderd in 0,01.
zal straks eens loeren.

[Ersus]

Japie.G schreef op zondag 18 januari 2026 @ 14:03:
Batterijkosten kunnen ook nog op 0,001 zie ik.

Ik zie nu ook DESS zijn plan van vandaag aanpassen nu de tarieven vanmorgen er zijn. Das wel nice!

heb je het vermogen van de batterij in en uit, aangepast?

[Japie.G]

Ersus schreef op zondag 18 januari 2026 @ 14:10:
[...]


heb je het vermogen van de batterij in en uit, aangepast?

Heb 3x een mp2 5000. Heb dess vermogen in en uit daarstraks op 9kW gezet (dus 3000w per mp) Wellicht moet die nog wat lager. Heb nog geen goede rte meting kunnen doen.

[Japie.G]

Ersus schreef op zondag 18 januari 2026 @ 14:05:
[...]


Heb ik ook eens geprobeerd en dat werd na opslaan veranderd in 0,01.
zal straks eens loeren.

Zie nu dat het is aangepast naar 0. Naja

[Srednier]

Ersus schreef op zondag 18 januari 2026 @ 13:55:
[...]


Als je DESS gebruikt dan valt er niet veel in te regelen dan alleen het ingeven van realistische data zodat het DESS algoritme zijn werk kan doen op basis van die juiste gegevens waaronder de RTE

Als je start met tijdverschoven injectie en dat op 100% systeemlast, omdat je op korte tijd veel kWh's kwijt wil, dan is het effect bijna hetzelfde als met een fiets de formule 1 doen, heel teleurstellend. Dito andersom als je gaat laden op 100%.

Traden zal eigen verbruik uit de accu laten komen als dat voordeliger is dan het resultaat van export, waarbij de verliezen van import en batterij kosten ook zijn betrokken. Daarom is het handiger om DESS de tarieven mee te geven zoals ze daadwerkelijk zijn, behalve de batterijkosten, die zou ik persoonlijk standaard op €0,01 zetten om eerder genoemde redenen.

Ik neem aan dat je met systeemlast van 100% het laad en ontlaad vermogen bedoelt, maar daar zit het bij mij nu geen beperking. Het probleem is dat de DESS planner denkt dat ik gedurende een dag 20kWh opwek heb, en dan van 75% naar 100% SOC gaat met die 20kWh. De werkelijke opwek is 40kWh, en dan moet die overige 20kWh wel het net op voor een paar cent. Dat terwijl ik 's nachts weer voor 25 cent moet kopen volgens DESS plan. Ik kan de kosten best verlagen van 4 naar 1 cent, maar de opbrengst is al zo'n 15 cent/kWh dus het zou volgens mij geen verschil moeten maken

[Ersus]

Klopt, als je systeem de handel met vollast uitvoert zul je hoge verliezen hebben. Juist die vollast beperken kan de RTE verbeteren en met de juiste tariefwaarden geef je DESS ook de mogelijkheid goed te functioneren.

Wat is je huidig ingestelde RTE? Weet je waar je dat kan vinden?

Maar die PV opbrengst geschat en gerealiseerd is best een groot verschil, maar normaal stelt DESS dat gaandeweg bij. Hier ligt 24.3kWp in de schaduw achter het huis, met bewolkte dagen is het, door strooiing van zonlicht, meer opbrengst dan met blauwe hemel. En ik zie dat DESS snel adaptief bijstelt. Soms idd met het laden vanaf Grid afhankelijk van het plan en de kosten die het DESS algoritme meeneemt.

Je zult echt moeten kijken naar je ingestelde RTE of dat wel klopt met de verliezen die je systeem heeft, want daarin zit de grootste oorzaak van teleurstellingen. De PV forecast heeft vraagt wel de nodige tijd om zich adaptief aan te passen naar de omstandigheden van de PV ligging en gerealiseerde opbrengst.

[aschoots]

Srednier schreef op zaterdag 17 januari 2026 @ 15:40:
Ik draai nu een paar weken DESS, maar dat lijkt nog niet goed te gaan. Elke dag dat de zon er een beetje doorbreekt gaat die opwek voor een aanzienlijk deel het net op terwijl ik met de instelling zou verwachten dat het systeem de accu de nacht ervoor voor eigenverbruik zou gebruiken om overdag de stroom op te kunnen slaan.
[Afbeelding]
In dit plaatje varieerde het accuniveau tussen de 80% en 98%
Iemand een idee waar dat aan kan liggen?

Het verschil tussen inkoop en verkoop prijs is erg groot. Daarmee 'ziet' DESS dat er eigenlijk niet valt te verdienen. Welke formule heb je in DESS ingevuld voor die prijzen?

<EDIT> Ik zie nu dat je dat al hebt aangegeven...

[Ersus]

Het allerbest zou wel een test zijn zodat je DESS de meest correcte mogelijke RTE meegeeft.

Om exact te bepalen wat er in de blauwe kastjes blijft hangen heb ik een VM-3P75CT direct na de Victron's geplaatst om onafhankelijk de in- en output te meten. Tussen de accu en de Victron's zit de SmartShunt1000A

VM vermogen / SmartShunt vermogen voor ontladen. (is hier ca +94%)
SmartShunt vermogen / VM vermogen voor laden. (dito ca +94%)

Beide devices zijn in NodeRed beschikbaar, en die device waarden neem je mee naar een functienode waarin je de berekening maakt en weergeeft.

Als ik zelf naar 100% systeembelasting zou gaan dan zakt de efficiëntie ook in elkaar. Ik doe nu de formule 1 (21kW parcours) met een sportwagen op halfvermogen met een betere efficiëntie.

Als de handel straks toch niet meer loont dan maakt het niet meer zoveel uit. Althans in mijn eigen geval wel nog omdat ik wel nog steeds het dagelijkse PV overschot tijdverschoven zal blijven injecteren om de winterfactuur te compenseren. Dan wil ik natuurlijk met hoge efficiëntie zoveel als mogelijk kWh's op de hoogste tariefmomenten kwijt.

[Ersus]

Japie.G schreef op zondag 18 januari 2026 @ 15:35:
[...]


Zie nu dat het is aangepast naar 0. Naja

Ik laat het op €0,01 staan als compensatie voor het beetje lading verlies door de batterij chemie.

[Srednier]

Ersus schreef op zondag 18 januari 2026 @ 16:01:
Het allerbest zou wel een test zijn zodat je DESS de meest correcte mogelijke RTE meegeeft.

Om exact te bepalen wat er in de blauwe kastjes blijft hangen heb ik een VM-3P75CT direct na de Victron's geplaatst om onafhankelijk de in- en output te meten. Tussen de accu en de Victron's zit de SmartShunt1000A

VM vermogen / SmartShunt vermogen voor ontladen. (is hier ca +94%)
SmartShunt vermogen / VM vermogen voor laden. (dito ca +94%)

Beide devices zijn in NodeRed beschikbaar, en die device waarden neem je mee naar een functienode waarin je de berekening maakt en weergeeft.
+
Als ik zelf naar 100% systeembelasting zou gaan dan zakt de efficiëntie ook in elkaar. Ik doe nu de formule 1 (21kW parcours) met een sportwagen op halfvermogen met een betere efficiëntie.

Als de handel straks toch niet meer loont dan maakt het niet meer zoveel uit. Althans in mijn eigen geval wel nog omdat ik wel nog steeds het dagelijkse PV overschot tijdverschoven zal blijven injecteren om de winterfactuur te compenseren. Dan wil ik natuurlijk met hoge efficiëntie zoveel als mogelijk kWh's op de hoogste tariefmomenten kwijt.

Dan kijk ik nog wel even aan of DESS over een paar weken mijn PV beter afschat...
Wat betreft RTE, als ik kijk naar AC geschiedenis waarden heb ik gedurende 365 dagen 3090 kWh geladen en 2619 kWh ontladen in ESS mode, dus lage ontlaad waarden maar hoge laad waarden. Dan was de RTE 84,7%. Dynamisch zal er nog wel een paar % af kunnen gaan, dus ik wil hem best instellen op 82%. Ik zou alleen niet weten hoe.

[Ersus]

Srednier schreef op zondag 18 januari 2026 @ 21:14:
[...]

Dan kijk ik nog wel even aan of DESS over een paar weken mijn PV beter afschat...
Wat betreft RTE, als ik kijk naar AC geschiedenis waarden heb ik gedurende 365 dagen 3090 kWh geladen en 2619 kWh ontladen in ESS mode, dus lage ontlaad waarden maar hoge laad waarden. Dan was de RTE 84,7%. Dynamisch zal er nog wel een paar % af kunnen gaan, dus ik wil hem best instellen op 82%. Ik zou alleen niet weten hoe.

Dat is een aardige RTE, dat heb je bereikt door die 10kW limit vermoedelijk.

RTE instellen kun je via NodeRed doen, ik heb de node nu niet bij de hand.

[Japie.G]

Srednier schreef op zondag 18 januari 2026 @ 21:14:
[...]
us ik wil hem best instellen op 82%. Ik zou alleen niet weten hoe.

Japie.G in "Het grote Victron aansturing topic"

Hoe kijk je precies die RTE na? Ik heb geen meter direct na de victrons

[ Voor 12% gewijzigd door Japie.G op 18-01-2026 22:27 ]

[Srednier]

Japie.G schreef op zondag 18 januari 2026 @ 22:22:
[...]


Japie.G in "Het grote Victron aansturing topic"

Hoe kijk je precies die RTE na? Ik heb geen meter direct na de victrons

Ben wel benieuwd welk getal jij krijgt als je ook kijkt vanuit de geschiedenis hoeveel kWh AC zijdig de accu in is gegaan en uit is gegaan binnen zeg een jaar, lijkt mij de RTE te zijn. Overigens zit daar niet het rustverbruik bij, want dat ziet het VRM als continu load. Maar voor de DESS input lijkt me deze RTE wel een goed getal. Rustverbruik verlies je toch altijd onafhankelijk van wat DESS plant.

Ik heb nu jullie input verwerkt, dus accu prijs op 1 cent en RTE op 82% power limiet op 10kW, ik ga het eens aankijken... Bedankt!

[HyperBart]

Jk BMS geeft in de summary weer wat er ingegaan is en uitgegaan is. In mijn beleving is dat de efficiency van de batterijkist zelf.
Daar zou je dan nog ergens de kwh van/naar de inverter(s) bij moeten rekenen en je bent er.

[DanTm]

HyperBart schreef op zondag 18 januari 2026 @ 23:36:
Jk BMS geeft in de summary weer wat er ingegaan is en uitgegaan is. In mijn beleving is dat de efficiency van de batterijkist zelf.
Daar zou je dan nog ergens de kwh van/naar de inverter(s) bij moeten rekenen en je bent er.

Ik zag laatst dat de home assistant Victron mqtt integratie ook waardes had van ac1 naar inverter en andersom. Die gebruik ik nu zelf om het ac gebruik te meten.

[RikHa]

@Srednier Heb je je locatie goed ingesteld? Dat is belangrijk! Zo niet doe dat eerst. Daarna (of als die al wel goed staat) zou je de voorspellingen kunnen resetten. Dat doe je via VRM. Instellingen -> Algemeen -> "Reset zon voorspellingen van deze installatie". Na een paar dagen zou het dan een stuk beter moeten zijn.

[Japie.G]

Ik zit nog steeds in de fase waarin ik probeer te doorgronden hoe het systeem werkt en denkt. Weet iemand waarom met DESS aan mijn systeem de hele tijd switcht van :

laden, externe besturing, ontladen

terwijl er in de planning verder niets staat over laden van pv naar accu, of net naar accu, of vice versa. Ik verwacht in zo'n tijdsblok gewoon dat het hele systeem inactief is.

[Flesdop]

Ik denk dat het de meetfout is van de BMS, bij mij gebeurt het ook. Wanneer bij mij de BMS 2A a 3A aangeeft en ik zelf met een stroomtang meet geeft die niet meer aan dan 0.5A. Ikzelf denk dat de BMS niet met hele lage stroomwaardes overweg kan.

[Knielen]

@Japie.G Draai je in Green Mode? DESS doet een voorspelling van de verwachte opbrengst en vraag, maar dit is natuurlijk nooit de werkelijkheid. Zo te zien probeert ESS de meter op 0 te houden, dus de PV opbrengst die over is gaat de accu in.
Het is een dynamisch systeem, zal nooit helemaal stil staan.

[Japie.G]

Knielen schreef op woensdag 21 januari 2026 @ 10:57:
@Japie.G Draai je in Green Mode? DESS doet een voorspelling van de verwachte opbrengst en vraag, maar dit is natuurlijk nooit de werkelijkheid. Zo te zien probeert ESS de meter op 0 te houden, dus de PV opbrengst die over is gaat de accu in.
Het is een dynamisch systeem, zal nooit helemaal stil staan.

Nee ik zit in trademode. Minimum SoC is 20%. Hij hangt daar nu iets boven. Ik zou dus nooit verwachten dat hij tot laden zou overgaan. Systeem inactief en de overtollige zonnestroom op het net gooien is voordeliger.

Ikzelf denk ook richting BMS die verkeerde waardes doorgeeft aan het systeem waardoor er vraag ontstaat ofzo? Wellicht toch een keer handig om te kalibreren. Er zit bij mij wel een smartshunt tussen die de batterijmonitor is, die kan duidelijk wel met lage stromen overweg. Als het systeem op inactief staat zie ik altijd -16w of iets dergelijks, ik ga ervan uit dat dat het verbruik van de cerbo is die direct op de DC bus hangt.

[ Voor 29% gewijzigd door Japie.G op 21-01-2026 11:06 ]

[DanTm]

Japie.G schreef op woensdag 21 januari 2026 @ 11:02:
[...]


Nee ik zit in trademode. Minimum SoC is 20%. Hij hangt daar nu iets boven. Ik zou dus nooit verwachten dat hij tot laden zou overgaan. Systeem inactief en de overtollige zonnestroom op het net gooien is voordeliger.

Ikzelf denk ook richting BMS die verkeerde waardes doorgeeft aan het systeem waardoor er vraag ontstaat ofzo? Wellicht toch een keer handig om te kalibreren. Er zit bij mij wel een smartshunt tussen die de batterijmonitor is, die kan duidelijk wel met lage stromen overweg. Als het systeem op inactief staat zie ik altijd -16w of iets dergelijks, ik ga ervan uit dat dat het verbruik van de cerbo is die direct op de DC bus hangt.

DESS doet ook in trade mode af en toe aan self-consumption. Tenminste toen ik het nog gebruikte (maand geleden). Dat is mijns inziens ook helemaal niet voordelig, een v/d reden dat ik de DESS aansturing niet meer gebruik (laat DESS nog wel steeds schedule's maken, die zijn wel goed).
Komt volgens mij door de reactive strategies die ze vorig jaar aan DESS hebben toegevoegd, je kunt hierover op het Victron Community forum wel ervaringen van anderen lezen.

Cerbo gebruik is ongeveer 3-5 watt, die -19 is waarschijnlijk standby gebruik van de Multiplus.
Helaas laat Victron in DESS trade mode ook buiten de geplande uren de Multiplus actief staan. Ikzelf schakel de Multiplus uit buiten de geplande uren, maar je kunt ook tijdelijk naar External Control schakelen (ess mode 3).

[ Voor 10% gewijzigd door DanTm op 21-01-2026 11:54 ]

[reneeke1970]

DanTm schreef op woensdag 21 januari 2026 @ 11:50:
[...]

DESS doet ook in trade mode af en toe aan self-consumption. Tenminste toen ik het nog gebruikte (maand geleden). Dat is mijns inziens ook helemaal niet voordelig, een v/d reden dat ik de DESS aansturing niet meer gebruik (laat DESS nog wel steeds schedule's maken, die zijn wel goed).
Komt volgens mij door de reactive strategies die ze vorig jaar aan DESS hebben toegevoegd, je kunt hierover op het Victron Community forum wel ervaringen van anderen lezen.

Cerbo gebruik is ongeveer 3-5 watt, die -19 is waarschijnlijk standby gebruik van de Multiplus.
Helaas laat Victron in DESS trade mode ook buiten de geplande uren de Multiplus actief staan. Ikzelf schakel de Multiplus uit buiten de geplande uren, maar je kunt ook tijdelijk naar External Control schakelen (ess mode 3).

Mijn cerbo en mp samen verbruiken 55 watt, een dikke kWh per dag

[gertvdijk]

DanTm schreef op woensdag 21 januari 2026 @ 11:50:
[...]
Ikzelf schakel de Multiplus uit buiten de geplande uren, maar je kunt ook tijdelijk naar External Control schakelen (ess mode 3).

Wat bedoel je precies met uitschakelen hier? Heb je niets boeiends achter je AC-out zitten en mag daar alles af of zit je huis wel op AC-out maar schakel je je huis over met een bypass ofzoiets?

Ik zit op bepaalde dagen met minimale prijsschommeling en 3x MP-II-5000 naar 100+W standbyverbruik te kijken en kan eventueel ook bypassen (met zeer korte onderbreking door schakelaar). Probleem is alleen dat ik soms wel meer dan 25A op een fase trek en dat ik semi-afhankelijk ben van de Victrons (PowerAssist/balancing) als dat gebeurt.

Weet iemand of je AES-mode, 'Zoekmodus' en UPS-mode dynamisch kan veranderen? Ik lees dat dat een invloed kan hebben op het standbyverbruik maar ook dat het alleen in VE.Configure zit. Tegelijkertijd zie ik knopjes in modbus/dbus/MQTT ervoor... Nog niet aan durven ziten.

[DanTm]

reneeke1970 schreef op woensdag 21 januari 2026 @ 12:04:
[...]

Mijn cerbo en mp samen verbruiken 55 watt, een dikke kWh per dag

1mp zou niet zoveel moeten verbruiken continue, 3 kan ik mijn voorstellen

[DanTm]

gertvdijk schreef op woensdag 21 januari 2026 @ 12:36:
[...]

Wat bedoel je precies met uitschakelen hier? Heb je niets boeiends achter je AC-out zitten en mag daar alles af of zit je huis wel op AC-out maar schakel je je huis over met een bypass ofzoiets?

Ik zit op bepaalde dagen met minimale prijsschommeling en 3x MP-II-5000 naar 100+W standbyverbruik te kijken en kan eventueel ook bypassen (met zeer korte onderbreking door schakelaar). Probleem is alleen dat ik soms wel meer dan 25A op een fase trek en dat ik semi-afhankelijk ben van de Victrons (PowerAssist/balancing) als dat gebeurt.

Weet iemand of je AES-mode, 'Zoekmodus' en UPS-mode dynamisch kan veranderen? Ik lees dat dat een invloed kan hebben op het standbyverbruik maar ook dat het alleen in VE.Configure zit. Tegelijkertijd zie ik knopjes in modbus/dbus/MQTT ervoor... Nog niet aan durven ziten.

ik heb een stopcontact gemonteerd op ac-out voor nood, gezien er nu geen nood is schakel ik inderdaad de hele multiplus uit (maar hij is niet volledig uit, ik schakel ik hem ook weer in zodra er geladen/ontladen moet worden).
Heb je AC-out continu nodig dan kom je er niet mee weg om geen standby te gebruiken. En voor power-assist kun je ook niet naar external-control schakelen (tenzij je zelf power-assist gaat bouwen dan).

Volgens mij zijn AES en zoekmodus alleen van toepassing op offgrid gebruik (but correct me if i am wrong).

[reneeke1970]

DanTm schreef op woensdag 21 januari 2026 @ 12:54:
[...]

1mp zou niet zoveel moeten verbruiken continue, 3 kan ik mijn voorstellen

Tja, mijn slimme meter zegt het, en de mp zelf ook. Maar het is met de cerbo erbij hè, die zit ingebouwd ,misschien dat er paar watt af mag voor de DC lader, maar dat is bijna niks

[Japie.G]

Hoe kan ik nou het standby verbruik bepalen van de multi's? Is dat puur wat je op de DC aan verbruik ziet als het systeem verder niets doet?

Srednier schreef op zondag 18 januari 2026 @ 22:38:
[...]


Ben wel benieuwd welk getal jij krijgt als je ook kijkt vanuit de geschiedenis hoeveel kWh AC zijdig de accu in is gegaan en uit is gegaan binnen zeg een jaar, lijkt mij de RTE te zijn. Overigens zit daar niet het rustverbruik bij, want dat ziet het VRM als continu load. Maar voor de DESS input lijkt me deze RTE wel een goed getal. Rustverbruik verlies je toch altijd onafhankelijk van wat DESS plant.

Ik heb nu jullie input verwerkt, dus accu prijs op 1 cent en RTE op 82% power limiet op 10kW, ik ga het eens aankijken... Bedankt!

Naar welke gegevens moet ik nu precies kijken om round trip efficiency te bepalen? Ik kom er niet lekker uit

[gertvdijk]

Japie.G schreef op woensdag 21 januari 2026 @ 15:48:
Hoe kan ik nou het standby verbruik bepalen van de multi's? Is dat puur wat je op de DC aan verbruik ziet als het systeem verder niets doet?

Ik zet max discharge rate op 0 en kijk naar het verschil tussen Grid en AC-out ("essential loads") omdat ik verder niks tussen Grid en AC-In heb zitten is dat het verlies.

[Srednier]

RikHa schreef op dinsdag 20 januari 2026 @ 16:07:
@Srednier Heb je je locatie goed ingesteld? Dat is belangrijk! Zo niet doe dat eerst. Daarna (of als die al wel goed staat) zou je de voorspellingen kunnen resetten. Dat doe je via VRM. Instellingen -> Algemeen -> "Reset zon voorspellingen van deze installatie". Na een paar dagen zou het dan een stuk beter moeten zijn.

Ja, dat stond goed. Ik heb nog wel een andere fout ontdekt in mijn instellingen. De DESS capaciteit stond op de volledige capaciteit, ik heb daar nu het stuk capaciteit ingesteld totaan de minimale SOC in VRM. Alles lijkt nu wel een stuk beter te gaan

[Japie.G]

Srednier schreef op woensdag 21 januari 2026 @ 15:55:
[...]


Ja, dat stond goed. Ik heb nog wel een andere fout ontdekt in mijn instellingen. De DESS capaciteit stond op de volledige capaciteit, ik heb daar nu het stuk capaciteit ingesteld totaan de minimale SOC in VRM. Alles lijkt nu wel een stuk beter te gaan

Is DESS standaard niet op de hoogte van minimum SoC dan?

[Srednier]

Japie.G schreef op woensdag 21 januari 2026 @ 15:59:
[...]


Is DESS standaard niet op de hoogte van minimum SoC dan?

Weet ik niet, maar met mijn 75kWh accu, minimum SOC op 40% (beetje buffer voor stroomuitval) heb ik nu 0.6*75 ingesteld als accu in DESS. Dat lijkt bij mij beter te werken.

[gertvdijk]

Srednier schreef op woensdag 21 januari 2026 @ 15:55:
Ja, dat stond goed. Ik heb nog wel een andere fout ontdekt in mijn instellingen. De DESS capaciteit stond op de volledige capaciteit, ik heb daar nu het stuk capaciteit ingesteld totaan de minimale SOC in VRM. Alles lijkt nu wel een stuk beter te gaan

Oh, raar. Volgens mij hoor je wel degelijk de brutocapaciteit van je batterij in te vullen, hoor. Ik wissel met DESS nogal eens van minimale SoC afhankelijk van de situatie en hij zit er maar een heel klein beetje naast soms per 15minuten-window (remt het laden/ontladen lichtjes af tegen het einde van het window). Bij wijzigen gaat het nieuwe minimum-SoC mee in het nieuwe plan ook (na zo'n 20 minuten wachten op het nieuwe plan, dat wel).

[ Voor 9% gewijzigd door gertvdijk op 21-01-2026 16:19 ]

[Flyerken]

Hier een nieuwe victron gebruiker uit België, Ik ben eigenlijk een beetje aan het zoeken naar hoe ik kan optimatiseren voor het capaciteitstarief. Ik was aan het spelen met de peakshaving optie in het menu maar ik denk niet dat die doet wat ik er van wil. Ik had begrepen dat dit ook via node red kan. Kan iemand die dat zo gebruikt mij zijn node red file doorsturen zodat ik een beetje een voorbeeld heb?