Het grote Victron aansturing topic

[pgdodopgdo]

ahjwinth schreef op woensdag 20 mei 2026 @ 18:59:
Ik heb 2 fronius aangesloten op mijn mp gx, dit gaat via de LAN aansluiting, de fronius en cerbo moeten in hetzelfde netwerk zitten. Je kan dan de gegevens van de fronius in VRM zien. En het victron systeem kan de fronius aansturen

Bedankt voor de info, helemaal duidelijk, precies wat ik wilde weten.

[NTS]

V_ger schreef op woensdag 20 mei 2026 @ 20:28:
Mijn Cerbo zit direct op de DC bus. Uiteraard met zekering EN condensator parallel, want oud...

Dat zou dan ook niet het issue moeten zijn. Tenzij je condensator kapot is en de USB activity net genoeg is voor een brown out van de Cerbo ofzo.

[V_ger]

NTS schreef op donderdag 21 mei 2026 @ 21:20:
[...]

Dat zou dan ook niet het issue moeten zijn. Tenzij je condensator kapot is en de USB activity net genoeg is voor een brown out van de Cerbo ofzo.

Die condensator is alleen maar nodig bij inschakelen. Oude Cerbo's hebben een constructiefout waardoor ze kapot kunnen gaan bij inschakelen van een 48V bus. Dit is de workaround.

Anyway, ik dacht dat het wekte. 14 uur zonder probleem en toen vanmiddag toch weer..
Ik heb gevonden dat je de polling rate van battery-aggregator kan aanpassen. In mijn pogingen de load van de cerbo omlaag te krijgen heb ik nu:
- normal image, zonder nodered
- gui gedisabled, dat is alleen voor lokale display
- polling rate dbus-serial-battery driver 2.5sec
- polling rate dbus-battery-aggregator 2sec

De load is wel weer wat lager. Of het voldoende is en of dat überhaupt het probleem is, geen idee.

[Q]

V_ger schreef op donderdag 21 mei 2026 @ 22:09:
[...]

Die condensator is alleen maar nodig bij inschakelen. Oude Cerbo's hebben een constructiefout waardoor ze kapot kunnen gaan bij inschakelen van een 48V bus. Dit is de workaround.

Anyway, ik dacht dat het wekte. 14 uur zonder probleem en toen vanmiddag toch weer..
Ik heb gevonden dat je de polling rate van battery-aggregator kan aanpassen. In mijn pogingen de load van de cerbo omlaag te krijgen heb ik nu:
- normal image, zonder nodered
- gui gedisabled, dat is alleen voor lokale display
- polling rate dbus-serial-battery driver 2.5sec
- polling rate dbus-battery-aggregator 2sec

De load is wel weer wat lager. Of het voldoende is en of dat überhaupt het probleem is, geen idee.

Misschien heb ik niet goed opgelet maar de hoge load had je al langer, en toen had je deze problemen niet. Dus als dat klopt zullen deze stappen niet helpen. Ik zou nu als doel 1 een stabiele situatie willen realiseren van waaruit je stapje voor stapje wijzigingen kunt maken om te snappen wat exact de oorzaak is.

[V_ger]

Ik had al langer een hoge load, soms zo erg dat de cerbo herstartte. Daarom was ik al naar de normal image. Maar blijkbaar waren die CH340 adapters toch wel OK.. Ik had begrepen dat de FT232s beter waren. Maar mischien niet, of heb ik goedkope China clones. En 100% zeker weet ik ook niet dat het hiervoor de ve.bus OK was. Ik zit er nu met mijn neus op en log de ve.bus state in HA zodat ik het direct zie. Dat deed ik eerst niet. Een Cerbo herstart valt op. Dat duurt lang en de uptime is ineens laag. Een ve.bus herstart zonder verdere foutmeldingen kost 10-30seconden.
Maar ik kan niet eenvoudig terug door wijzigingen aan de bekabeling...

Misschien teveel zooi op de usb bus...
Misschien toch investeren in een BMS met can.

[Q]

Je vond de errors in de logs op de cerbo via de shell. Kun je die errors zover terug vinden met een grep van voor de wijzigingen, of gaan de logs niet zover terug? Als je zeker weet dat je de ve.bus errors had voordat je met alle wijzigingen begon dan is dat relevante info.

[V_ger]

Q schreef op donderdag 21 mei 2026 @ 23:29:
Je vond de errors in de logs op de cerbo via de shell. Kun je die errors zover terug vinden met een grep van voor de wijzigingen, of gaan de logs niet zover terug? Als je zeker weet dat je de ve.bus errors had voordat je met alle wijzigingen begon dan is dat relevante info.

De ve.bus gooit sowieso geen errors, die kapt er gewoon mee. Ik kan alleen constateren dat door de hoge load mijn Cerbo soms herstartte, dat is nu niet meer. Nou ja als nu slechts de ve.bus herstart is dat al een verbetering denk ik.. ofzo...
Cerbo is underpowered of ik vraag gewoon teveel of 4x serial-battery driver met usb-ttl is gewoon zwaar belastend.
Al die custom stukjes software zijn natuurlijk ook "unsupported" en voor nieuwe installaties denk ik ook niet meer relevant, want alle bms-en doen wel CAN tegenwoordig toch? Geen noodzaak tot USB-TTL gehobby. Helaas heb ik ook geen programmeerbare id in mijn oude JKs (v10). Anders had ik ze op 1 adapter kunnen zetten of als RS485 samen op 1 bus met verschillende IDs.
De vorige ve.bus herstart was circa 20 uur geleden, dus we gaan de goede kant op.

[Japie.G]

Hier nu ineens out of the blue ook vage problemen met de solar edge modbus tcp verbinding. Werkt een paar seconden, dan weer ff niet, dan weer wel…Draait volgens mij oude firmware. Dus dat zal het niet zijn? Geen enkele andere wijziging verder voor zover ik weet. Meer mensen spontaan last van?

[Beer070]

Japie.G schreef op vrijdag 22 mei 2026 @ 20:44:
Hier nu ineens out of the blue ook vage problemen met de solar edge modbus tcp verbinding. Werkt een paar seconden, dan weer ff niet, dan weer wel…

[Afbeelding]

[Afbeelding]

[Afbeelding]

Draait volgens mij oude firmware. Dus dat zal het niet zijn? Geen enkele andere wijziging verder voor zover ik weet. Meer mensen spontaan last van?

Heb je de software versie van SE al gecheckt? Misschien is er per ongeluk met een app update ook een firmware update gedaan?

[Japie.G]

Beer070 schreef op vrijdag 22 mei 2026 @ 21:03:
[...]

Heb je de software versie van SE al gecheckt? Misschien is er per ongeluk met een app update ook een firmware update gedaan?

Zie foto, 3.2537. Problemen zijn toch pas ergens ver na 4.xx?

[ Voor 7% gewijzigd door Japie.G op 22-05-2026 21:07 ]

[Beer070]

Japie.G schreef op vrijdag 22 mei 2026 @ 21:07:
[...]


Zie foto, 3.2537. Problemen zijn toch pas ergens ver na 4.xx?

Mijn go app wilde heel graag dat ik ging updaten. Maar net ontlopen. Dit staat er bij mij.

[NTS]

Ja de Solaredge Go app doet dat, bij mij heeft support hem vervolgens weer terug gezet.

[Plead]

Japie.G schreef op vrijdag 22 mei 2026 @ 20:44:
Hier nu ineens out of the blue ook vage problemen met de solar edge modbus tcp verbinding. Werkt een paar seconden, dan weer ff niet, dan weer wel…

[Afbeelding]

[Afbeelding]

[Afbeelding]

Draait volgens mij oude firmware. Dus dat zal het niet zijn? Geen enkele andere wijziging verder voor zover ik weet. Meer mensen spontaan last van?

Ik heb dezelfde versie en heb vanaf begin communicatieproblemen gehad totdat ik een paar maanden geleden wat aanpassingen in mijn Synology NAS heb gemaakt. Sorry maar ik heb geen idee wat ik toen precies gedaan heb (iets met DNS). Sinds die tijd is het stabiel. Cerbo GX versie
v3.80~25

[Japie.G]

Plead schreef op zaterdag 23 mei 2026 @ 10:48:
[...]

Ik heb dezelfde versie en heb vanaf begin communicatieproblemen gehad totdat ik een paar maanden geleden wat aanpassingen in mijn Synology NAS heb gemaakt. Sorry maar ik heb geen idee wat ik toen precies gedaan heb (iets met DNS). Sinds die tijd is het stabiel. Cerbo GX versie
v3.80~25


[Afbeelding]

Vanaf vandaag ineens weer stabiel

[V_ger]

Het zal het weer zijn. Ik ben ook al 48 49 uur probleem vrij!
Mijn voorzichtige conclusie is dat de cerbo bij een aanhoudende hoge load rare dingen gaat doen. Uiteindelijk grijpt er een watchdog in voor een reboot, maar zo erg was het bij mij blijkbaar niet. Wel erg genoeg om de ve.bus te herstarten...

[Q]

@V_ger volgens mij is je installatie al wat ouder, en is je cerbo ook wat ouder. Ik meen dat er nieuwere versies zijn van de cerbo met meer cpu, misschien is dat nog iets om te overwegen(nieuwere cerbo). Maar waarom heb je eigenlijk last van zoveel cpu gebruik op de cerbo?

[ Voor 12% gewijzigd door Q op 23-05-2026 18:40 ]

[V_ger]

Q schreef op zaterdag 23 mei 2026 @ 18:40:
@V_ger volgens mij is je installatie al wat ouder, en is je cerbo ook wat ouder. Ik meen dat er nieuwere versies zijn van de cerbo met meer cpu, misschien is dat nog iets om te overwegen(nieuwere cerbo). Maar waarom heb je eigenlijk last van zoveel cpu gebruik op de cerbo?

Er is wel een mk2 cerbo, maar die heeft alleen andere aansluitingen, zelfde CPUAnders moet ik naar een Ekrano, die heeft 4 cores. Maar veels te duur. Bovendien hoef ik geen scherm. Een pi wil ik ook niet, dan moet ik ve.bus, ve.can ook weer aparte boards of usb jetsers voor kopen. Teveel gedoe.

De grootste CPU vreters zijn de battery aggregator en de 4x serial-battery via USB. Dat zijn custom python scripts. Als het dan ook druk is op de bus met meetdata van import of PV stroom komt er ook veel data/load daarvan af. Dat is blijkbaar teveel.... Of de usb processen zijn ruk en wachten constant op elkaar.

Maar hij doet het nogsteeds!
De load was de laatste keer rond de 2. Maar voorheen toen ik dus ook reboots had ook wel 6...
Ik overweeg een VM3P75CT, dat scheelt een USB apparaat, maar wel veel meer meetdata door de hoge frequentie. Ik heb alleen weinig motivatie om de meterkast weet aan te passen. De ET is een doorgangsmeter en de VM gebruikt spoelen. Toch anders kwa kabel routing.

Edit: Zo te zien valt het nu wel mee.

code:

CPU:   0% usr   8% sys   0% nic  91% idle   0% io   0% irq   0% sirq
Load average: 1.54 2.27 2.09 2/395 23492
  PID  PPID USER     STAT   VSZ %VSZ %CPU COMMAND
23492 23471 root     R     2700   0%   5% top
  698   697 messageb S     4132   0%   2% dbus-daemon --system --nofork
 2276  2266 root     S     2836   0%   2% /opt/victronenergy/can-bus-bms/can-bus-bms --log-before 25 --log-after 25 -vv -c socketcan:can1 --banner
 1072  1067 root     S    55804   5%   0% {dbus-modbus-cli} /usr/bin/python3 -u /opt/victronenergy/dbus-modbus-client/dbus-modbus-client.py
 2581  2578 root     S    50596   5%   0% {mqtt-rpc.py} /usr/bin/python3 -u /opt/victronenergy/mqtt-rpc/mqtt-rpc.py
 1062  1054 shelly   S    49656   5%   0% {dbus_shelly.py} /usr/bin/python3 /opt/victronenergy/dbus-shelly/dbus_shelly.py
 2651  2574 flashmq  S    48228   5%   0% /usr/bin/flashmq
 1004   992 root     S    47260   5%   0% {vrmlogger.py} /usr/bin/python3 -u /opt/victronenergy/vrmlogger/vrmlogger.py
22000 21984 root     S    46876   5%   0% python /data/apps/dbus-serialbattery/dbus-serialbattery.py /dev/ttyUSB4
21992 21977 root     S    46876   5%   0% python /data/apps/dbus-serialbattery/dbus-serialbattery.py /dev/ttyUSB3
21999 21981 root     S    46876   5%   0% python /data/apps/dbus-serialbattery/dbus-serialbattery.py /dev/ttyUSB2
21974 21956 root     S    46876   5%   0% python /data/apps/dbus-serialbattery/dbus-serialbattery.py /dev/ttyUSB0
 1005   998 root     S    42100   4%   0% {venus-button-ha} /usr/bin/python3 -u /opt/victronenergy/venus-button-handler/venus-button-handler -D
21365  2028 root     S    42080   4%   0% python /data/etc/dbus-mqtt-grid/dbus-mqtt-grid.py
21366  2033 root     S    41784   4%   0% python /data/etc/dbus-mqtt-ev-charger/dbus-mqtt-ev-charger.py
 1017   994 root     S    39012   4%   0% /opt/victronenergy/venus-platform/venus-platform
 1877  1876 root     S    35456   3%   0% python3 /data/apps/dbus-aggregate-batteries/dbus-aggregate-batteries.py
 1060  1021 root     S    33876   3%   0% {localsettings.p} /usr/bin/python3 -u /opt/victronenergy/localsettings/localsettings.py --path=/data/conf
 1050  1019 root     S    32668   3%   0% {netmon} /usr/bin/python3 -u /opt/victronenergy/netmon/netmon
 1071  1065 mqtt-int S    30792   3%   0% {dbus-mqtt-integ} /usr/bin/python3 /opt/victronenergy/dbus-mqtt-integrations/dbus-mqtt-integrations.py
 1081  1052 root     S    29600   3%   0% {dbus_systemcalc} /usr/bin/python3 -u /opt/victronenergy/dbus-systemcalc-py/dbus_systemcalc.py
 1093  1076 root     S    28776   3%   0% {dbus_digitalinp} /usr/bin/python3 -u /opt/victronenergy/dbus-digitalinputs/dbus_digitalinputs.py /dev/gpio/digital_input_1 /dev/gpio/digi
26113 26111 root     S    27832   3%   0% /opt/victronenergy/dbus-cgwacs/dbus-cgwacs /dev/ttyUSB1
 1048  1036 root     S    26300   3%   0% {dbus_vebus_to_p} /usr/bin/python3 -u /opt/victronenergy/dbus-vebus-to-pvinverter/dbus_vebus_to_pvinverter.py
 1092  1086 root     S    24932   2%   0% {dbus-acsystem.p} /usr/bin/python3 /opt/victronenergy/dbus-acsystem/dbus-acsystem.py
 2572  2571 root     S    22880   2%   0% /opt/victronenergy/dbus-modbustcp/dbus-modbustcp
 1082  1074 root     S    22772   2%   0% /opt/victronenergy/dbus-fronius/dbus-fronius
 1047  1034 root     S    20820   2%   0% /opt/victronenergy/hub4control/hub4control
 1039  1000 root     S    20108   2%   0% /opt/victronenergy/venus-access/venus-access

[ Voor 75% gewijzigd door V_ger op 23-05-2026 20:19 ]

[Q]

V_ger schreef op zaterdag 23 mei 2026 @ 19:10:
[...]

Er is wel een mk2 cerbo, maar die heeft alleen andere aansluitingen. Anders moet ik naar een Ekrano, ja doei. Veels te duur. Bovendien hoef ik geen scherm. Een pi wil ik ook niet, dan moet ik ve.bus, ve.can ook weer aparte boards of usb jetsers voor kopen. Teveel gedoe.

De grootste CPU vreters zijn de battery aggregator en de 4x serial-battery via USB. Dat zijn custom python scripts. Als het dan ook druk is op de bus met meetdata van import of PV stroom komt er ook veel data/load daarvan af. Dat is blijkbaar teveel....
Maar hij doet het nogsteeds!
De load was de laatste keer rond de 2. Maar voorheen toen ik dus ook reboots had ook wel 6...

Helder verhaal, persoonlijk vind ik het gewoon gek dat een paar USB-serial devices (weet niet wat de battery aggregator precies is) zoveel load kunnen geven, zelfs met python, al is de cerbo qua cpu wel mager.

Ik zou eigenlijk serieus je eigen plan opnieuw overwegen om de BMS(sen) van je accu's te vervangen. Ook duur maar misschien long-term een stuk robuuster.

[V_ger]

Q schreef op zaterdag 23 mei 2026 @ 19:21:
[...]

Helder verhaal, persoonlijk vind ik het gewoon gek dat een paar USB-serial devices (weet niet wat de battery aggregator precies is) zoveel load kunnen geven, zelfs met python, al is de cerbo qua cpu wel mager.

Ik zou eigenlijk serieus je eigen plan opnieuw overwegen om de BMS(sen) van je accu's te vervangen. Ook duur maar misschien long-term een stuk robuuster.

Mooi excuus om een extra batterij te kopen. Zit te denken aan een eelbattery. 1 lege kist zodat ik 1 van mijn 4 banken daar in kan doen en 1 gevulde. Want meer opslag is altijd meer beter
Ik zit alleen met de breedte van die kisten. Ik heb de boel in een kast en die heeft een beperkte diepte...

Mijn batterij is in gebruik sinds januari 2023. Hier wat stats.


Volgens de BMSen zit ik met de oudere banken op iets van 620-640 cycles. De nieuwste op 300. Maar JK, dus als dat net zo nauwkeurig is als de SOC meting ;-) Ik heb ook geen instelbare resetwaarde op de BMSen, dus..
Ben begonnen met 32 kWh, half jaar later nog 16 erbij en jaar later weer 16 erbij.

[ Voor 5% gewijzigd door V_ger op 23-05-2026 20:50 ]

[Q]

V_ger schreef op zaterdag 23 mei 2026 @ 20:26:
[...]

Mooi excuus om een extra batterij te kopen. Zit te denken aan een eelbattery. 1 lege kist zodat ik 1 van mijn 4 banken daar in kan doen en 1 gevulde. Want meer opslag is altijd meer beter
Ik zit alleen met de breedte van die kisten. Ik heb de boel in een kast en die heeft een beperkte diepte...

Mijn batterij is in gebruik sinds januari 2023. Hier wat stats.
[Afbeelding]

Volgens de BMSen zit ik met de oudere banken op iets van 620-640 cycles. De nieuwste op 300. Maar JK, dus als dat net zo nauwkeurig is als de SOC meting ;-) Ik heb ook gene instelbare resetwaarde op de BMSen, dus..
Ben begonnen met 32 kWh, half jaar later nog 16 erbij en jaar later weer 16 erbij.

Altijd goed excuus voor meer storage. Je setup wordt goed gebruikt. Alles kost geld, maar die grote kast verkopen en alles gewoon in kisten doen is misschien ook een optie, heb je ook meteen BMS er bij. Zeker aan de prijs, maar je communicatie integratie met victron is prima.

SoC van de BMS is wat mij betreft niet relevant als je een Victron Shunt hebt, zolang je de BMS maar zo instelt dat die alleen reageert op voltages van de cellen (geen gek gedrag door onzin soc drift). En die data komt ook bij de Cerbo binnen dus dat kun je dan ook mooi tracken en eventueel iets mee doen. Jij bent volgens mij een van de mensen die er vroeg bij was en toen waren er nog geen knappe kisten (of prijzig) maar nu zijn er erg veel opties en als je 4 kisten koopt waarvan 1x gevuld.... Dan kun je wel iets met de prijs doen denk ik.

Je hebt ervaren hoe onprettig het is als je setup kuren vertoont, de vraag is wat het je waard is om er wat aan te doen, tot hoever je wilt gaan en dat is gewoon aan jou.

[habbekrats]

Heden middag was het niet best met het Enexis grid, nu voor de derde keer eraf. Victron draait wel lekker door accu vol met de Victron mppt lader. Postcode 9981

[MJ de Bruijn]

Wie Node Red gebruikt voor de aansturing van zijn (m/v) Victron systeem zal daar zeker af en toe veiligheidskopieën van maken. Toch?
Het belang van een backup als de installatie vervangen moet worden is evident. Maar wie herkent niet dat bij het wijzigen van flows (en met name functies) je opeens iets wijzigt wat eigenlijk niet had gemoeten. Zodra je op Deploy klikt werkt de herstel-toets <ctrl> + Z niet meer.
Omdat ikzelf daar meer dan eens mee te maken heb (gehad) heb ik enkele backup-scripts gemaakt. Wellicht vindt iemand anders deze ook interessant.

Dagelijkse backup van alle Node Red Flows in "Het grote Victron Node Red topic"

Dagelijkse backup van alle Node Red functie Nodes in "Het grote Victron Node Red topic"

[ Voor 6% gewijzigd door MJ de Bruijn op 25-05-2026 21:24 ]

[brigges]

Goedemorgen

Via HA stuur ik de feed-in aan om de teruglevering te beperken.
Bij 95% batterij level gaat de teruglevering starten, bij 90% stopt deze.
Echter ondanks de volle accu blijft er ook vanuit het net geleverd worden.
Is er een mogelijkheid om dit uit te zetten? Ik zou graag niks meer van het
net willen betrekken zolang de batterij nog boven de 30% is.

[NTS]

Bedoel je dat er een klein beetje uit het net geleverd wordt met schommelingen tussen ongeveer 0 en 100W? Dat is normaal gedrag omdat de load en solar opbrengst continu veranderen. Je kunt je ESS target (volgens mij default 50W) ook op -50W zetten dan heb je dezelfde schommeling maar meer naar de teruglevering kant.

[djazzy]

of gewoon eens optimize without battery life. aanzetten mischien (ESS)

[NTS]

Hoe zorgen jullie er met dit erg mooie weer voor dat de batterij niet al vroeg op de dag bijna vol is en dan lang op 100% SOC staat? ESS heeft niet echt een optie om te zeggen "stop maar bij 95%" behalve de override van max charge voltage.

[powerboat]

NTS schreef op dinsdag 26 mei 2026 @ 23:36:
Hoe zorgen jullie er met dit erg mooie weer voor dat de batterij niet al vroeg op de dag bijna vol is en dan lang op 100% SOC staat? ESS heeft niet echt een optie om te zeggen "stop maar bij 95%" behalve de override van max charge voltage.

Ik heb de Limit managed battery charge voltage aangezet en ingesteld op 55,5V hierdoor topt ie af op 98%

[pvg]

NTS schreef op dinsdag 26 mei 2026 @ 23:36:
Hoe zorgen jullie er met dit erg mooie weer voor dat de batterij niet al vroeg op de dag bijna vol is en dan lang op 100% SOC staat? ESS heeft niet echt een optie om te zeggen "stop maar bij 95%" behalve de override van max charge voltage.

In BMS RCV op 55.2V met 0.5u timer. Na een half uur op 55.2V zakt de spanning naar 53.6V (RFV) voor minimaal 12u (v15 JK BMS). Met DVCC aan luistert de victron netjes naar de BMS.
Ja, dan blijft SoC hoog, maar zakt wel af naar 99/98% door negatief grid setpoint (-20W).

[MJ de Bruijn]

NTS schreef op dinsdag 26 mei 2026 @ 23:36:
Hoe zorgen jullie er met dit erg mooie weer voor dat de batterij niet al vroeg op de dag bijna vol is en dan lang op 100% SOC staat?

Ik haal de zon verwachting op en de kwartierprijzen (met Node Red). Dan bereken ik de meest gunstige laad-momenten. Ik tel de te verwachten energie op tot ik voldoende zal gaan hebben.

Dit wordt iedere 10 seconden geactualiseerd op basis van de actuele SoC.

[reneeke1970]

NTS schreef op dinsdag 26 mei 2026 @ 23:36:
Hoe zorgen jullie er met dit erg mooie weer voor dat de batterij niet al vroeg op de dag bijna vol is en dan lang op 100% SOC staat? ESS heeft niet echt een optie om te zeggen "stop maar bij 95%" behalve de override van max charge voltage.

Gebruik maken van de laad schema functie

[djazzy]

Hier is de batterij de laatste dagen rond 15:00 vol en rond 17:00 uur begint de airco eraan te trekken . Rond die tijd is de opbrengst van de panelen niet genoeg meer.

Overschot aan opbrengst (kan) worden verminderd door scripje in HA in welke de omvormer terug regelt aan de hand van terug levering . Maar lever nu nog alles terug vast contract. 2027 word ander verhaal .


Goodwe3600dns niet de duurste omvormer maar goed ondersteund in HA.

[NTS]

reneeke1970 schreef op woensdag 27 mei 2026 @ 10:09:
[...]
Gebruik maken van de laad schema functie

Hoe stel je die in voor een maximum? Ik dacht altijd dat die andersom werkte, minimum SOC waar naar opgeladen wordt.

[NTS]

Als ik daar 95% instel gaat de batterij opladen vanuit het net om op 95% te komen.

[NTS]

powerboat schreef op woensdag 27 mei 2026 @ 06:10:
[...]
Ik heb de Limit managed battery charge voltage aangezet en ingesteld op 55,5V hierdoor topt ie af op 98%

En dan laat je dat gewoon staan tot er 's avonds weer verbruik is om het te verlagen?

[Q200]

Ozzi schreef op zondag 1 juni 2025 @ 18:36:
[...]

Dat blijkt maar weer. Hoewel die in mijn ecu-c dit in theorie wel zou moeten ondersteunen.

Ik ga denk ik wel een keer verder in de sourcode van beiden projecten duiken en kijken if ik het zelf kan implementeren.

De issues die ik had mbt de laad en ontlaadstroom lijken trouwens wel opgelost te zijn door nog maar 1 MP2 te gebruiken, dus geen gebruik te maken van deze parallel te schakelen.

Hallo Ozzi,

als ik de documentatie van de ECU-C lees, heeft deze een seriele modbus en kan je die instellen op het sunspec protocol, zie pag 21 van https://global.apsystems.com/wp-content/uploads/2024/03/4271801072_APsystems-Energy-Communication-Unit-ECU-C-User-manual_Rev4.0_2023-08-15.pdf
Dat is geen modbus-tcp, maar zou dan wel moeten werken. Heb je daar naar gekeken?

(ik wil mijn ECU-R eventueel vervangen door een ECU-C, en als dat werkt is dat een extra stimulans :-) )

[Ozzi]

Q200 schreef op woensdag 27 mei 2026 @ 14:25:
[...]

Hallo Ozzi,

als ik de documentatie van de ECU-C lees, heeft deze een seriele modbus en kan je die instellen op het sunspec protocol, zie pag 21 van https://global.apsystems.com/wp-content/uploads/2024/03/4271801072_APsystems-Energy-Communication-Unit-ECU-C-User-manual_Rev4.0_2023-08-15.pdf
Dat is geen modbus-tcp, maar zou dan wel moeten werken. Heb je daar naar gekeken?

(ik wil mijn ECU-R eventueel vervangen door een ECU-C, en als dat werkt is dat een extra stimulans :-) )

Nee, ik heb het nog niet werkend. De directe modbus heb ik ook aan zitten denken. Op dit moment kan ik dat alleen niet testen want mij ECU-C hangt momenteel op zolder (ivm buitenantenne op de schoorsteen) en mn victron systeen in de schuur voor mijn huis :+

Via sunspec heb ik in venus-os de ECU niet kunnen vinden en via modbus-tcp ook niet. Zelf deze implementeren in de victron dbus-florius ben ik verder ook nog niet aan toegekomen.

De webinterface van de ECU-C heeft trouwens ook "No longer maintained". Deze werd volgens mij gebruikt oa door de homeassistant-apsystems_ecu_reader ( https://github.com/HAEdwin/homeassistant-apsystems_ecu_reader ). Al staat daar nu wel dat er gewerkt wordt aan een manier om dit op een nieuwe manier mogelijk te maken.

[ Voor 14% gewijzigd door Ozzi op 27-05-2026 15:48 ]

[brt652]

Ozzi schreef op woensdag 27 mei 2026 @ 15:43:
[...]

Via sunspec heb ik in venus-os de ECU niet kunnen vinden en via modbus-tcp ook niet. Zelf deze implementeren in de victron dbus-florius ben ik verder ook nog niet aan toegekomen.

Ik heb sinds april ook een Victron systeem draaien en heb een Solaredge omvormer en 4 stuks DS3 APsystems omvormers zichtbaar in Venus OS, zie screenshot. Note: ik heb een ECU-R met SunSpec logo.



Met de EMA manager app moet de "Modbus Configuration" voor de ECU-R op "On" worden gezet en elke DS3 moet een eigen adres/unit ID krijgen, in mijn geval 1 t/m 4.

Venus-OS scanned voor PV als default modbus poort 502 en unit ID 126. Met deze default settings waren mijn DS3 omvormers met unit ID's 1,2,3 en 4 niet zichtbaar.

Nadat ik Venus-OS een update had gegeven naar Venus-OS large v3.72, kon ik additionele unit ID's 1 t/m 4 toevoegen en zijn de DS3 omvormers zichtbaar, zie screenshot:



Het mooie van Victron is dat zowel met Solaredge als met de APsystems DS3 omvormers dynamic power limiting mogelijk is. Ik heb het al wel getest, en het werkt, maar gebruik het zelf nog niet actief. Ga dit wel gebruiken wanneer ik overga naar een dynamisch contract om teruglevering te voorkomen bij negatieve prijzen.

[powerboat]

NTS schreef op woensdag 27 mei 2026 @ 14:11:
[...]

En dan laat je dat gewoon staan tot er 's avonds weer verbruik is om het te verlagen?

Die laat ik gewoon aanstaan die 2% neem ik wel voor lief dat zou ook beter moeten zijn voor de accu(s).

Ik heb DESS ingericht voor eigen gebruik en energie dumpen wanneer stroom iets waard is.

[V_ger]

Nou, mijn VE.bus probleem is weer terug. Niets gewijzigd, maar lijkt nu erger dan ooit. En dat na een paar dagen probleemloos te zijn geweest...
Hij lijkt er ook niet echt meer uit te komen.

Edit: Ik denk toch een hardware probleem. Met veel moeite de UTP kabel uit de cerbo kunnen krijgen (bij de nieuwe hebben ze de poorten omgedraaid zodat de klipjes van de kabel niet naar de muur wijzen) en in de andere ve.bus poort gestoken. En direct weer verbinding. Dus of de kabel, of de Cerbo (poort)?

[ Voor 21% gewijzigd door V_ger op 28-05-2026 08:08 ]

[Q]

V_ger schreef op donderdag 28 mei 2026 @ 06:19:
Nou, mijn VE.bus probleem is weer terug. Niets gewijzigd, maar lijkt nu erger dan ooit. En dat na een paar dagen probleemloos te zijn geweest...
Hij lijkt er ook niet echt meer uit te komen.

Edit: Ik denk toch een hardware probleem. Met veel moeite de UTP kabel uit de cerbo kunnen krijgen (bij de nieuwe hebben ze de poorten omgedraaid zodat de klipjes van de kabel niet naar de muur wijzen) en in de andere ve.bus poort gestoken. En direct weer verbinding. Dus of de kabel, of de Cerbo (poort)?
[Afbeelding]

EDIT: je hebt een sloot aan ve.bus issues gehad in de nacht als ik het goed lees.

• Wat is er recent gewijzigd dat dit nu opeens gebeurd?
• Was dat voor of nadat je aan de cerbo ve.bus poorten hebt gewerkt?
• Waarom heel veel in de nacht en daarna niet?
• Aarde issue?

---

Het kan ook nog een van de multiplussen zijn, dus ik zou niet te snel de cerbo gaan vervangen. Dat je het probleem nu vaker hebt kan te maken hebben met temperatuur omdat de afgelopen week het erg warm is geweest en dat is nieuw. Het kan ook komen door een van je recente wijzigingen.

Misschien even time-out pakken - take a deep breath - en ik adviseer om dit issue heel gestructureerd aan te pakken. ik snap dat je je systeem goed wil draaien, zeker in deze periode, maar helaas heb je pech, accepteer dat voor jezelf en ga je niet haasten, zou ik zeggen.

Heb je inmiddels de oorspronkelijke configuratie hersteld zoals die was toen je geen problemen had? Zo niet, dan lijkt mij dit de allereerste stap. Ik begrijp dat dit niet makkelijk is, maar ik zou het werk accepteren en de wijzigingen terug draaien. De hoogste prioriteit is een 'known-good' configuratie te herstellen, wat mij betreft. Dan heb je een solide basis om te achterhalen wat precies de oorzaak van dit probleem is. Want voor mijn gevoel is het proces nu wat teveel dingen aanpassen en dan maar hopen. Dat kost werk, tijd en lijkt tot nu toe niet te helpen.

Pas als je een known-good configuratie hebt kun je nadenken over het één voor één maken van de nieuwe wijzigingen en een periode draaien om te kijken of een van die wijzigingen de oorzaak is van de ve.bus problemen. Of de situatie laten zoals deze is.

Het kan helpen om even alles goed los te halen - hoe vervelend dat ook is, zodat je er makkelijk mee kan werken (zoals de cerbo) en geen risico loopt om dingen stuk te maken.

---

Mocht het issue toch blijven bestaan ondanks dat je alle recente wijzigingen hebt teruggedraaid, dan kan ook een multiplus de oorzaak zijn. Dan zou ik je 3-fase setup qua configuratie ontmantelen en alle multiplussen een 1-fase configuratie geven. Verrvolgens draai je je setup met één multiplus waarbij de andere drie uit staan. En zo switch je iedere multiplus om. Als het issue alleen terug komt bij één specifieke multiplus weet je wat er mis is.

[ Voor 7% gewijzigd door Q op 28-05-2026 13:14 ]

[Ozzi]

brt652 schreef op woensdag 27 mei 2026 @ 19:04:
[...]

[verhaal]

Volgens mij had ik de modbus wel enabled. Ik krijg het echter niet meer voor elkaar om nu verbinding te maken met de EMA manager app met de ECU. Wat ik ook probeer, ik kan het wifi netwerk van de ecu niet vinden. Ook niet na een restart ervan nadat ik de ethernet kabel eruit heb gehaald.

Wel moet ik zeggen dat ik nu nog venus OS 3.67 heb draaien volgens mij. Deze moet ik nog een keer updaten. Wellicht dat het in de nieuwere versie wel gefixed is.

- edit -
Nu uiteindelijk wel kunnen verbinden via de EMA manager app. Modbus stond al enabled, heb nog wel de ID's extra ingesteld voor de inverters die later zijn toegevoegd maar vinden in Venus OS wil nog niet echt

[ Voor 15% gewijzigd door Ozzi op 28-05-2026 13:30 ]

[V_ger]

Q schreef op donderdag 28 mei 2026 @ 13:07:
[...]

EDIT: je hebt een sloot aan ve.bus issues gehad in de nacht als ik het goed lees.

• Wat is er recent gewijzigd dat dit nu opeens gebeurd?
• Was dat voor of nadat je aan de cerbo ve.bus poorten hebt gewerkt?
• Waarom heel veel in de nacht en daarna niet?
• Aarde issue?

---

Het kan ook nog een van de multiplussen zijn, dus ik zou niet te snel de cerbo gaan vervangen. Dat je het probleem nu vaker hebt kan te maken hebben met temperatuur omdat de afgelopen week het erg warm is geweest en dat is nieuw. Het kan ook komen door een van je recente wijzigingen.

Misschien even time-out pakken - take a deep breath - en ik adviseer om dit issue heel gestructureerd aan te pakken. ik snap dat je je systeem goed wil draaien, zeker in deze periode, maar helaas heb je pech, accepteer dat voor jezelf en ga je niet haasten, zou ik zeggen.

Heb je inmiddels de oorspronkelijke configuratie hersteld zoals die was toen je geen problemen had? Zo niet, dan lijkt mij dit de allereerste stap. Ik begrijp dat dit niet makkelijk is, maar ik zou het werk accepteren en de wijzigingen terug draaien. De hoogste prioriteit is een 'known-good' configuratie te herstellen, wat mij betreft. Dan heb je een solide basis om te achterhalen wat precies de oorzaak van dit probleem is. Want voor mijn gevoel is het proces nu wat teveel dingen aanpassen en dan maar hopen. Dat kost werk, tijd en lijkt tot nu toe niet te helpen.

Pas als je een known-good configuratie hebt kun je nadenken over het één voor één maken van de nieuwe wijzigingen en een periode draaien om te kijken of een van die wijzigingen de oorzaak is van de ve.bus problemen. Of de situatie laten zoals deze is.

Het kan helpen om even alles goed los te halen - hoe vervelend dat ook is, zodat je er makkelijk mee kan werken (zoals de cerbo) en geen risico loopt om dingen stuk te maken.

---

Mocht het issue toch blijven bestaan ondanks dat je alle recente wijzigingen hebt teruggedraaid, dan kan ook een multiplus de oorzaak zijn. Dan zou ik je 3-fase setup qua configuratie ontmantelen en alle multiplussen een 1-fase configuratie geven. Verrvolgens draai je je setup met één multiplus waarbij de andere drie uit staan. En zo switch je iedere multiplus om. Als het issue alleen terug komt bij één specifieke multiplus weet je wat er mis is.

Het punt is, sinds mijn aanpassingen aan de timing in de drivers heeft het circa 10 dagen zonder problemen gedraaid. En vannacht ineens drama. En toen was het gewoon NOM, geen import, geen export, niets bijzonders. Ik ben er sinds 10 dagen geleden ook niet meer aan geweest. Niet kwa software en niet met mijn vingers.
Dus ik dacht dat het was opgelost... Voor nu blijf ik de ve.bus status loggen. Volgens mij heeft ie vanmorgen nog 1x gehikt nadat ik opnieuw had ingeplugd. Beetje jammer, ben ik de dag begonnen met een veel te volle accu en ben ik nu voor 0 cent aan het terugleveren, Nou ja als ie het vanavond maar doet.
Ik ga niet random zaken vervangen, daarvoor is het me te duur. Ik ben geen installateur die uit de grijpvoorraad even een andere kan proberen.
Ik zou nog mijn mk3 kunnen proberen. Dus ipv direct de MPs op de ve.bus aan de Cerbo, de MPs aan de mk3 knopen en die op de USB van de Cerbo hangen.

[bigricknl]

Denk dat ik het zelfe heb / had. Ik zag de D Bus round-trip naar 400+ gaan. Toen heb ik battery aggregate en serial battery verhuist naar een pi3 zodat die de data rustig kon doorsturen naar de cerbo.


Toen nog steeds problemen. Maar met hoge cpu load en andere dingen.

Heb claude code er op los gelaten en daar door draai ik nu 2 dagen stabiel en load is onder de 1.

Word tijd dat er een sterkere cerbo komt deze kan niks hebben als er fouten zijn

[Q]

V_ger schreef op donderdag 28 mei 2026 @ 13:44:
[...]

Het punt is, sinds mijn aanpassingen aan de timing in de drivers heeft het circa 10 dagen zonder problemen gedraaid. En vannacht ineens drama. En toen was het gewoon NOM, geen import, geen export, niets bijzonders. Ik ben er sinds 10 dagen geleden ook niet meer aan geweest. Niet kwa software en niet met mijn vingers.
Dus ik dacht dat het was opgelost... Voor nu blijf ik de ve.bus status loggen. Volgens mij heeft ie vanmorgen nog 1x gehikt nadat ik opnieuw had ingeplugd. Beetje jammer, ben ik de dag begonnen met een veel te volle accu en ben ik nu voor 0 cent aan het terugleveren, Nou ja als ie het vanavond maar doet.
Ik ga niet random zaken vervangen, daarvoor is het me te duur. Ik ben geen installateur die uit de grijpvoorraad even een andere kan proberen.
Ik zou nog mijn mk3 kunnen proberen. Dus ipv direct de MPs op de ve.bus aan de Cerbo, de MPs aan de mk3 knopen en die op de USB van de Cerbo hangen.

• Heb je nog iets in de cerbo logs kunnen vinden van voordat de eerste ve.bus errors terug kwamen?
• Als je door software aanpassingen 10 dagen stabiel draait - zonder ve.bus issues - denk ik niet direct aan hardware, memory leak?
• Was alles redelijk ok na een cerbo reboot, begrijp ik dat goed? Of puur alleen kabel uit en in?

[Q]

bigricknl schreef op donderdag 28 mei 2026 @ 13:59:
Heb claude code er op los gelaten en daar door draai ik nu 2 dagen stabiel en load is onder de 1.

Dus dan weet je helaas nog steeds niet wat er aan de hand was. Niet echt handig wat mij betreft.

Ik vind (D)ESS relatief belangrijke infrastructuur en dan zou ik goed willen snappen hoe en wat en niet afhankelijk willen zijn van AI, maar misschien ben ik gewoon een zure oude man die naar wolken schreeuwt.

[ Voor 27% gewijzigd door Q op 28-05-2026 14:03 ]

[V_ger]

Q schreef op donderdag 28 mei 2026 @ 14:00:
[...]

• Heb je nog iets in de cerbo logs kunnen vinden van voordat de eerste ve.bus errors terug kwamen?
• Als je door software aanpassingen 10 dagen stabiel draait - zonder ve.bus issues - denk ik niet direct aan hardware, memory leak?
• Was alles redelijk ok na een cerbo reboot, begrijp ik dat goed? Of puur alleen kabel uit en in?

Van de Cerbo logs word ik niet wijzer. Daar is alleen terug te vinden dat de verbinding met de multi's verloren is gegaan. Maar dat wisten we al.
Een herstart van de Cerbo vanmorgen had precies 0 effect. Het wijzigen van de actieve battery monitor ook niet. Op het moment dat de ve.bus unkown is gaat het low battery ledje op de MP aan, verder geen alarm, want geen communicatie. Bij het herinsteken van de ve.bus kabel ging direct de rode led uit. Volgens mij is ie daarna nog 1x naar unknown gegaan, maar niet precies gekeken naar hoeveel seconden dat was. Alles draait nu weer normaal sinds vanmorgen circa 8.00 uur.

[Q]

@V_ger heb je alle kabels van de ve.bus vervangen, dus tussen cerbo en alle multiplussen? Of bestaande kabels losgetrokken (en laten zitten) en ff tijdelijke kabels aangesloten?

Als je nadat je de kabel weer in de cerbo hebt gestoken het issue nog 1x is voorgekomen is het niet opgelost, denk ik.

Maar ik denk dat er op dit moment genoeg scenario's / opties zijn om verder te testen.

Het zou helemaal interessant zijn als je het issue actief zou kunnen reproduceren op de een of andere manier. Gooi eens een hoge load met dit command op de cerbo (herhalen per aantal cores)

yes > /dev/null &

(stoppen met killall yes of ps aux | grep yes en dan kill <pid> oid)

Of je kunt - als je dat nog niet gedaan hebt - eens rammelen aan die ve.bus connectors, die in de cerbo maar ook in de MP(s)

[ Voor 35% gewijzigd door Q op 28-05-2026 17:36 ]

[bigricknl]

Q schreef op donderdag 28 mei 2026 @ 14:00:
[...]

• Heb je nog iets in de cerbo logs kunnen vinden van voordat de eerste ve.bus errors terug kwamen?
• Als je door software aanpassingen 10 dagen stabiel draait - zonder ve.bus issues - denk ik niet direct aan hardware, memory leak?
• Was alles redelijk ok na een cerbo reboot, begrijp ik dat goed? Of puur alleen kabel uit en in?

Mja ai is toch wel handig als je errors hebt die je niet kan vinden en je totaal geen commando's kent en of programmeer skills hebt.

Stap voor stap heb ik met claude dingen getest uitgesloten en verbeterd.

[V_ger]

bigricknl schreef op donderdag 28 mei 2026 @ 17:48:
[...]

Mja ai is toch wel handig als je errors hebt die je niet kan vinden en je totaal geen commando's kent en of programmeer skills hebt.
Claude komt hier alleen maar met niet bestaande logfile locaties en andere niet correcte onzin. Zoals dat ik een nieuwe Cerbo zou moeten kopen omdat die sneller is. Beperkt van nut iig..

Stap voor stap heb ik met claude dingen getest uitgesloten en verbeterd.

Gast, ik weet niet wat je wil insinueren, maar er ZIJN geen errors in welke log dan ook. Dus bus kapt er gewoon mee.

@Q Als ik de ve.bus kabel uit een MP trek, dan sta ik in het donker. Net proefondervindelijk vastgesteld.
Als ik de ve.bus uit de Cerbo trek, dan niet. Dat impliceert dat de errors niet in de MP zelf zitten. Maar eerder in de Cerbo. Als de multiplussen vinden dat de bus weg is gaat ie uit, lijkt me een prima beveiliging. Wellicht omdat het een 3 fase systeem is.
Maar als de error dus niet in/tussen de MPs onderling zit blijven ze wel "in de lucht". Maar werkt de aansturing niet meer.

Nou ja dan is er nu iig een harde reset geweest ipv een softe. Had hier alleen geen rekening mee gehouden. Iets met servers die het minder leuk vinden als ze ineens uit gaan.

[ Voor 30% gewijzigd door V_ger op 28-05-2026 18:12 ]

[Q]

V_ger schreef op donderdag 28 mei 2026 @ 17:54:
[...]

Gast, ik weet niet wat je wil insinueren, maar er ZIJN geen errors in welke log dan ook. Dus bus kapt er gewoon mee.

@Q Als ik de ve.bus kabel uit een MP trek, dan sta ik in het donker. Net proefondervindelijk vastgesteld.
Als ik de ve.bus uit de Cerbo trek, dan niet. Dat impliceert dat de errors niet in de MP zelf zitten. Maar eerder in de Cerbo. Als de multiplussen vinden dat de bus weg is gaat ie uit, lijkt me een prima beveiliging. Wellicht omdat het een 3 fase systeem is.
Maar als de error dus niet in/tussen de MPs onderling zit blijven ze wel "in de lucht". Maar werkt de aansturing niet meer.

Nou ja dan is er nu iig een harde reset geweest ipv een softe. Had hier alleen geen rekening mee gehouden. Iets met servers die het minder leuk vinden als ze ineens uit gaan.

Helder verhaal. Op dit moment heb ik verder verder dan geen idee even, los van de mogelijke tests die we al besproken hebben.

[Q]

bigricknl schreef op donderdag 28 mei 2026 @ 17:48:
[...]

Mja ai is toch wel handig als je errors hebt die je niet kan vinden en je totaal geen commando's kent en of programmeer skills hebt.

Stap voor stap heb ik met claude dingen getest uitgesloten en verbeterd.

V_ger reageert misschien wat fel maar ik ben het wel met hem eens. Je trekt zonder basis conclusies over zijn kennis / kunde en begint wederom over AI. Persoonlijk heeft AI niets te zoeken in een context die gaat over serieuze onderwerpen als een (D)ESS met mogelijk serieuze consequenties.


Als je nou eens - gegeven het verhaal van V_ger - specifieke, beargumenteerde concrete tips zou hebben met motivatie, da's een heel ander verhaal, maar 'use AI' is het nieuwe 'gebruik google'. Overigens begrijp ik prima dat je nu geen zin meer hebt om te helpen, en dat is ook prima verder.

[bigricknl]

Mooi werk ger geen error maar hij reboot wel steeds... succes gast

Het gedeelte ai was een typfout bedoelde claude. En ja dat is ook ai ja. En was gebaseerd op mijn kennis. Nergens claim ik iets over iemand zijn kennis oid.

[V_ger]

bigricknl schreef op donderdag 28 mei 2026 @ 20:06:
Mooi werk ger geen error maar hij reboot wel steeds... succes gast

Het gedeelte ai was een typfout bedoelde claude. En ja dat is ook ai ja. En was gebaseerd op mijn kennis. Nergens claim ik iets over iemand zijn kennis oid.

Van Claude word ik niet wijzer. Die suggereert alleen maar niet bestaande logfiles te bestuderen. Als ik dan zeg dat die niet bestaan, Oh ja je hebt gelijk..
Of die komt met de suggestie om een nieuwere Cerbo te kopen omdat die sneller is. Maar de mk2 heeft alleen maar wat andere aansluitingen. Echt vrij kansloos als ik de AI moet gaan vertellen hoe het werkt.

[djazzy]

V_ger. Al aan spelen geweest met de baudrate ? even terug naar 9600 kan rust brengen

[V_ger]

djazzy schreef op donderdag 28 mei 2026 @ 21:30:
V_ger. Al aan spelen geweest met de baudrate ? even terug naar 9600 kan rust brengen

Baudrate, waarvan? Ik heb nergens iets ingesteld.

[djazzy]

de ft232 zouden instelbaar moeten zijn vanaf 300bps tot heel snel. Op zoek naar software dan .

https://www.waveshare.com/wiki/USB-TO-TTL-FT232 maakt het mischien wat

duidelijker wat ik bedoel

[V_ger]

djazzy schreef op donderdag 28 mei 2026 @ 21:44:
de ft232 zouden instelbaar moeten zijn vanaf 300bps tot heel snel. Op zoek naar software dan .

https://www.waveshare.com/wiki/USB-TO-TTL-FT232 maakt het mischien wat

duidelijker wat ik bedoel

Ik heb natuurlijk geen waveshares.. Volgens (ja daar komt ie) Claude is de baudrate afhankelijk van het BMS en is die voor JK 115200 en past de FT232 adapter zich daarop aan.
Maargoed na mijn ongeplande harde reset van de ve.bus gaan we ervaren hoe lang ie het blijft doen. Ik heb in HA een alert ingesteld voor als mijn ve.bus naar unknown gaat. Want het valt niet op, je ziet het achteraf pas.

[djazzy]

Geloof niet dat een FT232 zichzelf aanpast. Zou toch even naar de software zoeken al is het alleen maar om te weten wat de FT doet . En of de baudrate vast te zetten is op de juiste waarde

[Q]

@V_ger is het acceptabel om misschien even zonder die FT apparatuur te draaien, dus zonder communicatie met de accus? Lijkt mij geen probleem als je Cerbo gewoon veilig is ingesteld qua ESS en met name DVCC. Sluit je misschien meteen een mogelijke oorzaak uit.

[V_ger]

@Q Nu weer 13 uur stabiel. Als ie nog een keer hikt Vervang ik die FT232s voor iets beters. Die van Duppa bijvoorbeeld.

[bigricknl]

V_ger schreef op donderdag 28 mei 2026 @ 20:28:
[...]

Van Claude word ik niet wijzer. Die suggereert alleen maar niet bestaande logfiles te bestuderen. Als ik dan zeg dat die niet bestaan, Oh ja je hebt gelijk..
Of die komt met de suggestie om een nieuwere Cerbo te kopen omdat die sneller is. Maar de mk2 heeft alleen maar wat andere aansluitingen. Echt vrij kansloos als ik de AI moet gaan vertellen hoe het werkt.

Ik gebruik claude code via powershell. En die heeft volledig toegang tot de cerbo ed . Moet wel steeds ok geven op wat hij heeft gevonden en wil fixen. Maar hij gaat wel op input van wat je wil volledig automatisch zoeken en het probleem opsporen.


Weet niet of jij het op die manier ook doet met claude code rechtstreeks te laten comminuceren ?

[Q]

V_ger schreef op vrijdag 29 mei 2026 @ 07:11:
@Q Nu weer 13 uur stabiel. Als ie nog een keer hikt Vervang ik die FT232s voor iets beters. Die van Duppa bijvoorbeeld.

Wat is er nu veranderd dat het opgelost zou kunnen zijn?

[V_ger]

Q schreef op vrijdag 29 mei 2026 @ 15:31:
[...]


Wat is er nu veranderd dat het opgelost zou kunnen zijn?

Nou ja ik juich pas over 2 weken, maar de grote verandering is dat ik gisteren in het donker stond na het losklikken van de ve.bus kabel. Ofwel alles is stroomloos geweest. Verder is er niets gewijzigd.
22 uur en counting.

[V_ger]

En, ik tel niet meer. Wat was het 3 tot 4 dagen?

[Ersus]

V_ger schreef op maandag 1 juni 2026 @ 00:42:
En, ik tel niet meer. Wat was het 3 tot 4 dagen?

Ben benieuwd of het na de 'harde reset' nu goed blijft.

Ik zag een nieuwe FW update voor de CompID2621 v563

[V_ger]

Ik heb de kabelgoten en MP opengehad om de UTP kabel tussen de laatste MP en de Cerbo te inspecteren. Dit omdat het gedrag als de ve.bus tussen de multi's wegvalt anders is. UTP kabel zat ergens klem tussen een randje van de kabelgoot en een 70mm2 kabel. Verdacht plekje op de UTP kabel gevonden. Kabel eruit gevist, opnieuw geroute (nu boven de DC kabels langs ipv eronder) en het hele systeem inclusief de Cerbo is nu spanningsloos geweest. Tevens de hager omgezet zodat ik nu alles aan het net heb ipv aan de noodstoom kant. Dan kan ik eventueel updaten, kabels vervangen etc zonder dat het halve huis spanningsloos is.

De teller staat inmiddels op 15 minuten

[ Voor 24% gewijzigd door V_ger op 01-06-2026 11:00 ]

[Q]

Ik hoop voor je dat het is opgelost, maar nu je toch de moeite hebt genomen om alles los te halen is de kans groter dat je ook de stap kunt uitvoeren om alles helemaal terug te draaien qua sw en hw wijzigingen als het nodig is.

Is er verder geen enkele correlatie tussen de ve.bus events en de 'state' qua soc voltage, amperage, vermogens, etc etc?

[V_ger]

Ik had hoop, maar zojuist weer ve.bus eruit. Ik snap er helemaal geen jota van. Lijkt echt gewoon random te zijn. Nu dus iets meer dan 2 dagen goed gegaan. Nu midden op de dag. Soms hersteld de situatie zich en zoals nu blijft ie heen en weer klapperen tussen unknown - passthrough - unknown. Nu lijkt ie er weer niet meer uit te komen.

Ik zal een andere UTP kabel proberen. En dan maar meer afwachten.

Edit: De rest van de communicatie blijft het doen. USB, Ethernet, ve.can, modbus. Ik zie overal waardes van, behalve dus de ve.bus van de MPs.

[ Voor 54% gewijzigd door V_ger op 03-06-2026 15:46 ]

[Japie.G]

Zojuist een systeem met een victron lynx smart BMS in gebruik gesteld. Er viel me op de de soc gewoon doorliep naar 100 terwijl zowel het ingestelde charged voltage en de tail current NIET gematched / behaald waren. Is dat normaal gedrag voor een smart bms ?

[RikHa]

@V_ger Ik zie dat je nu al een week of twee aan het tobben bent met die ve.bus. Waarom haal je niet gewoon drie nieuwe utp kabeltjes? Het kost geen drol. Bovendien zeg je een verdachte plek te hebben gevonden. Kwel jezelf niet langer en vervang eerst de kabels.

[V_ger]

RikHa schreef op woensdag 3 juni 2026 @ 23:08:
@V_ger Ik zie dat je nu al een week of twee aan het tobben bent met die ve.bus. Waarom haal je niet gewoon drie nieuwe utp kabeltjes? Het kost geen drol. Bovendien zeg je een verdachte plek te hebben gevonden. Kwel jezelf niet langer en vervang eerst de kabels.

Kabel is vervangen. Kijken hoe het nu gaat. Issue is dat het probleem random optreedt. Na het opnieuw routen van de oude kabel deed ie het weer. Dan weet ik dus niet zeker of dat het was. Met elk uur dat verstrijkt denk ik dan het gevonden te hebben..
Nu dus andere UTP kabel via tijdelijke routing. Voor nu doet ie het, maar hij kan netzogoed over 20 minuten uitvallen. Of 2 uur, 2 dagen of zelfs 2 weken. Elke keer doe ik een aanpassing en werkt het weer (even).
Random zaken gaan vervangen is een slecht en potentieel kostbaar idee. Dat doen alleen monteurs in een garantieperiode.
Anyway de 1e 6 uur zitten er bijna op.

[Q]

V_ger schreef op woensdag 3 juni 2026 @ 23:31:
[...]

Kabel is vervangen. Kijken hoe het nu gaat. Issue is dat het probleem random optreedt. Na het opnieuw routen van de oude kabel deed ie het weer. Dan weet ik dus niet zeker of dat het was. Met elk uur dat verstrijkt denk ik dan het gevonden te hebben..
Nu dus andere UTP kabel via tijdelijke routing. Voor nu doet ie het, maar hij kan netzogoed over 20 minuten uitvallen. Of 2 uur, 2 dagen of zelfs 2 weken. Elke keer doe ik een aanpassing en werkt het weer (even).
Random zaken gaan vervangen is een slecht en potentieel kostbaar idee. Dat doen alleen monteurs in een garantieperiode.
Anyway de 1e 6 uur zitten er bijna op.

Volgens mij had je die UTP kabels voor de ve.bus al eens vervangen toch? Als dat zo is, is er niets opgelost denk ik.

Ik raad aan om nu als eerste die MKII USB ve.bus adapter in je Cerbo GX te prikken als dat kan en deze als ve.bus poort te gebruiken (als dat werkt) mits je dat nog niet geprobeerd hebt. Werkt dit wel lange tijd goed, dan kan het toch de ve.bus poort zijn van de cerbo.

Je kunt ook verder gaan door een Raspberry Pi met Venus OS te gaan draaien, je MKII USB te gebruiken voor ve.can connectiviteit en de rest kan vast via usb of netwerk.

Maar alles 100% qua hardware en software terug draaien naar de situatie voordat deze ellende begon heb je nog niet gedaan toch? Dat zou ik persoonlijk toch nu eerst prioriteit geven.

[The Lord]

V_ger schreef op donderdag 21 mei 2026 @ 22:39:
Ik had al langer een hoge load, soms zo erg dat de cerbo herstartte. Daarom was ik al naar de normal image. Maar blijkbaar waren die CH340 adapters toch wel OK.. Ik had begrepen dat de FT232s beter waren. Maar mischien niet, of heb ik goedkope China clones. En 100% zeker weet ik ook niet dat het hiervoor de ve.bus OK was. Ik zit er nu met mijn neus op en log de ve.bus state in HA zodat ik het direct zie. Dat deed ik eerst niet. Een Cerbo herstart valt op. Dat duurt lang en de uptime is ineens laag. Een ve.bus herstart zonder verdere foutmeldingen kost 10-30seconden.
Maar ik kan niet eenvoudig terug door wijzigingen aan de bekabeling...

Misschien teveel zooi op de usb bus...
Misschien toch investeren in een BMS met can.

In een heel andere setting paar jaar geleden tegen volgende aangelopen met 3 'USB RS232 converters'.:

Dbusserial leverde zeer hoge load (elkaar blokkerende taken binnen proces). Dit was met 'lekker niet van die dure' USB RS232 converters die USB->TTL deden en RS232 'emuleerden' in software.

Probleemeigenaar had op aanraden 'echte' USB-RS232 converters gekocht. Dat waren echter wederom 'lekker goedkope' versies en die gaven zeer random problemen op momenten van drukte. Ze hadden neppe FTDI chips die graag met ID's aan de wandel gaan en overlap (kunnen) hebben.

Toen er uiteindelijk echte USB-RS232 adapters werden gebruikt werkte het wel als een zonnetje.

Misschien heb je er iets aan.

[V_ger]

The Lord schreef op donderdag 4 juni 2026 @ 14:13:
[...]

In een heel andere setting paar jaar geleden tegen volgende aangelopen met 3 'USB RS232 converters'.:

Dbusserial leverde zeer hoge load (elkaar blokkerende taken binnen proces). Dit was met 'lekker niet van die dure' USB RS232 converters die USB->TTL deden en RS232 'emuleerden' in software.

Probleemeigenaar had op aanraden 'echte' USB-RS232 converters gekocht. Dat waren echter wederom 'lekker goedkope' versies en die gaven zeer random problemen op momenten van drukte. Ze hadden neppe FTDI chips die graag met ID's aan de wandel gaan en overlap (kunnen) hebben.

Toen er uiteindelijk echte USB-RS232 adapters werden gebruikt werkte het wel als een zonnetje.

Misschien heb je er iets aan.

Die staat hoog op mijn lijstje idd. Ik heb Goeiekope van Ali/Amazon. Ze hebben iig alle 3 hetzelfde ID. ik weet niet of dat een issue is.
Dus het zijn OF die converters, OF tijdens het installeren heb ik net de kabels voldoende bewogen om de ve.bus kabel over het randje heen te helpen. De load is soort van onder controle te krijgen door de update interval wat te verhogen.

Overigens zegt mijn UTP kabeltester dat de kabel goed is, ook na bewegen/buigen/draaien. Althans ik heb op alle 8 de aders een lampje. Wellicht dat de kabel ook soms goed is, maar bij een bepaalde temperatuur of kleine verstoring door andere kabels net het signaal kwijtraakt.

Inmiddels 20 uur. Inclusief ontladen, NOM en nu laden met netstroom.

[Japie.G]

Japie.G schreef op woensdag 3 juni 2026 @ 23:04:
Zojuist een systeem met een victron lynx smart BMS in gebruik gesteld. Er viel me op de de soc gewoon doorliep naar 100 terwijl zowel het ingestelde charged voltage en de tail current NIET gematched / behaald waren. Is dat normaal gedrag voor een smart bms ?

Iemand hier met een lynx smart bms? Zojuist weer gezien. Het ding lijkt settings compleet te negeren.

[Noord27]

@Japie.G Wat zijn je settings in VE.Configure?

[Japie.G]

Noord27 schreef op donderdag 4 juni 2026 @ 15:30:
@Japie.G Wat zijn je settings in VE.Configure?

Voorbeeld vandaag om 14:03:
Stroom 19,9A
Voltage 54,4
SoC loopt gewoon naar 100. Lineair voor mijn gevoel.

Settings van Lynx BMS battery monitor:



De Lynx BMS staat in VenusOS ingesteld als de actieve battery monitor. Ik snap niet waarom hij hier niets op uit doet...

Mijn eigen systeem blijft op 99,9 totdat aan de instellingen van de (in mijn geval non-lynx) Smart SHUNT is voldaan. Ik had dat hier ook verwacht...

[ Voor 6% gewijzigd door Japie.G op 04-06-2026 17:25 ]

[Noord27]

Is het bij andere gebruikers ook het geval dat de geplande balancering dagelijks wordt uitgesteld naar morgen (bij externe aansturing, in dit geval via JK BMS)? Zie dit nu al 2 weken gebeuren.

[ Voor 56% gewijzigd door Noord27 op 06-06-2026 16:03 ]

[DoMoFo]

Japie.G schreef op donderdag 4 juni 2026 @ 17:23:

De Lynx BMS staat in VenusOS ingesteld als de actieve battery monitor. Ik snap niet waarom hij hier niets op uit doet...

Mijn eigen systeem blijft op 99,9 totdat aan de instellingen van de (in mijn geval non-lynx) Smart SHUNT is voldaan. Ik had dat hier ook verwacht...

Bij voorbaat sorry dat ik niets bijdraag aan jouw probleem... Maar aangezien je de Victron SmartBMS gebruikt was ik benieuwd of jij die hebt gecombineerd met een Victron batterij of third-party batterij?

Aangezien dat ding hard-coded is voor specifiek Victron Lithium batterijen en een aantal config settings hard override...

Manual - Page 18:

Battery monitor settings:
Unlike other battery monitors, the Lynx Smart BMS battery monitor settings are mostly fixed settings and are not customisable.
The reason for this is that the Lynx Smart BMS is always used together with Victron Lithium Batteries Smart and a lot of battery
monitor parameters are therefore known because they relate to the battery type.

[ Voor 31% gewijzigd door DoMoFo op 06-06-2026 17:02 ]

[Japie.G]

DoMoFo schreef op zaterdag 6 juni 2026 @ 16:41:
[...]


Bij voorbaat sorry dat ik niets bijdraag aan jouw probleem... Maar aangezien je de Victron SmartBMS gebruikt was ik benieuwd of jij die hebt gecombineerd met een Victron batterij of third-party batterij?

Aangezien dat ding hard-coded is voor specifiek Victron Lithium batterijen en een aantal config settings hard override...

Manual - Page 18:


[...]

De BMS zelf is op de lynx gebypassed met het victron kabeltje (tis de NON NG versie en het is overigens niet mijn systeem). Het wordt gebruikt met third-party batterijen. Alle settings voor de BMS kunnen me dan ook verder gestolen worden, ik had echter wel verwacht dat de battery monitor hetzelfde zou functioneren als mijn smart shunt. Hij lijkt die settings dus echter gewoon volkomen te negeren. Ik weet dat er hier meer zijn die een dergelijk setup hebben dus ik vraag me af of iedereen dat zo heeft. In dat geval is het ding dus eigenlijk niet goed bruikbaar, enkel als DC breaker en precharger. Voor een goede SoC monitoring moet er dan als nog een shunt tussen. Heel gek! Ik zal er eens mee naar het victron forum gaan.

[ Voor 3% gewijzigd door Japie.G op 06-06-2026 21:32 ]

[Japie.G]

Noord27 schreef op zaterdag 6 juni 2026 @ 16:01:
Is het bij andere gebruikers ook het geval dat de geplande balancering dagelijks wordt uitgesteld naar morgen (bij externe aansturing, in dit geval via JK BMS)? Zie dit nu al 2 weken gebeuren.

[Afbeelding]

Hij haalt zn geplande 2 (of was het 3?) uur op 100 procent dan niet. Komt vanzelf een keer goed.

[DoMoFo]

Japie.G schreef op zaterdag 6 juni 2026 @ 21:31:
De BMS zelf is op de lynx gebypassed met het victron kabeltje (tis de NON NG versie en het is overigens niet mijn systeem). Het wordt gebruikt met third-party batterijen. Alle settings voor de BMS kunnen me dan ook verder gestolen worden, ik had echter wel verwacht dat de battery monitor hetzelfde zou functioneren als mijn smart shunt.

Ah, ok, vandaar dat ik even reageerde, want dit heeft mijn _volle_ interesse. Ook ik ga mijn (in aanbouw) systeem bypassen met de SmartBMS, puur voor de door jouw genoemde features en de mogelijkheid om de Cerbo nog een paar minuten te voeden als de breaker is gedisconnect (voor disaster shutdown). IPV een losse accu voor de Cerbo en externe RBS viel de prijs voor de (verder nutteloze) SmartBMS dus wel mee, het integreert ieg mooi in de Lynx voor die functionaliteiten.
Het zal nog wel even duren, maar als hier alles up-and-running is kan ik wellicht wel iets zinnigs bijdragen, tnx!

BTW, het bypassen is toch alleen het BMS extensie kabeltje (M/F) doorloopen in de Lynx SmartBMS ?!?!

[ Voor 5% gewijzigd door DoMoFo op 06-06-2026 21:47 ]

[Ersus]

Morgen is ‚dynamisch’ wel ideaal om te balanceren voor enkele uren.

[Japie.G]

DoMoFo schreef op zaterdag 6 juni 2026 @ 21:43:
[...]


Ah, ok, vandaar dat ik even reageerde, want dit heeft mijn _volle_ interesse. Ook ik ga mijn (in aanbouw) systeem bypassen met de SmartBMS, puur voor de door jouw genoemde features en de mogelijkheid om de Cerbo nog een paar minuten te voeden als de breaker is gedisconnect (voor disaster shutdown). IPV een losse accu voor de Cerbo en externe RBS viel de prijs voor de (verder nutteloze) SmartBMS dus wel mee, het integreert ieg mooi in de Lynx voor die functionaliteiten.
Het zal nog wel even duren, maar als hier alles up-and-running is kan ik wellicht wel iets zinnigs bijdragen, tnx!

BTW, het bypassen is toch alleen het BMS extensie kabeltje (M/F) doorloopen in de Lynx SmartBMS ?!?!

Klopt, meer dan het kabeltje is het niet!

[The Lord]

V_ger schreef op donderdag 4 juni 2026 @ 14:48:
[...]

Die staat hoog op mijn lijstje idd. Ik heb Goeiekope van Ali/Amazon. Ze hebben iig alle 3 hetzelfde ID. ik weet niet of dat een issue is.

Dat is bij 1 adapter geen issue, maar met meerdere al snel wel.

Als ik mij vaag ergens herinner wordt in de software virtueel de 'USB ID' gebruikt om onderscheid te maken tussen de adapters die dezelfde 'hardware ID' hebben i.p.v. dat dat hardware matig is geregeld. Dan moet alles in 1 thread sequentieel worden afgehandeld. Als het dan beetje 'druk' is met data pakt die ene thread alle rekenkracht op zijn core en gaat out-of-sync met de seriële bus data. En dan is de boel virtueel kapot.

[V_ger]

The Lord schreef op maandag 8 juni 2026 @ 09:27:
[...]

Dat is bij 1 adapter geen issue, maar met meerdere al snel wel.

Als ik mij vaag ergens herinner wordt in de software virtueel de 'USB ID' gebruikt om onderscheid te maken tussen de adapters die dezelfde 'hardware ID' hebben i.p.v. dat dat hardware matig is geregeld. Dan moet alles in 1 thread sequentieel worden afgehandeld. Als het dan beetje 'druk' is met data pakt die ene thread alle rekenkracht op zijn core en gaat out-of-sync met de seriële bus data. En dan is de boel virtueel kapot.

Wellicht dat dat de hoge load dan verklaart? Alhoewel er 4 separate serial-battery threads zijn, 1 per adapter.
Even zien, mijn laatste post was 3 juni 6 uur 'a avonds. Sindsdien doet ie het. Dan gok ik dat het toch de ve.bus kabel tussen de laatste multi en de Cerbo was. Bij het vervangen van de USB-TTLs de boel wat verschoven, kabels aangeraakt etc. Dus wellicht was dat de druppel voor de wat ongelukkig geroute UTP kabel.
Geen garantie dat het daadwerkelijk zo is, maar toch fijn dat ie het al wat langer normaal doet. Of het is de kleur, ik had geen blauwe meer, dus nu een witte gebruikt

Tja, te vroeg begonnen met deze hobby en BMSen die nu wat ouderwets/beperkt zijn in communicatie.

[Noord27]

Hoi,

Zijn er ook mensen die hun bestaande PV hebben uitgebreid met MPPT's van Victron? Ik zie versies met en zonder bluetooth (smart solar/blue solar). Kunnen de blue solar uitvoeringen met een GX apparaat middels vaste kabel gekoppeld worden; zoja zit hier een maximum aan? De opzet is om 3 stuks 100/20 (3x 2 panelen) extra te gaan leggen.

[Q]

Noord27 schreef op woensdag 10 juni 2026 @ 11:49:
Hoi,

Zijn er ook mensen die hun bestaande PV hebben uitgebreid met MPPT's van Victron? Ik zie versies met en zonder bluetooth (smart solar/blue solar). Kunnen de blue solar uitvoeringen met een GX apparaat middels vaste kabel gekoppeld worden; zoja zit hier een maximum aan? De opzet is om 3 stuks 100/20 (3x 2 panelen) extra te gaan leggen.

Vriend heeft 5 x MPPT draaien, gebruikt ve.direct aansluitingen op de cerbo en hopelijk GX multiplus. Maar draai je 48V of 24V/12V? Want ik vraag me af of die 100/20 wel 48V doen

[Noord27]

@Q Accu van 48V, tevens 48kWh. De 100/20 doet inderdaad 48V volgens de Victron website. Heb geen losse Cerbo, maar een Multiplus met GX ingebouwd. Daar zit ook een ve.direct poort op.

Met andere woorden is Bluetooth overbodig als je gebruik gaat maken via ve.direct met vaste verbindingen? Zijn de MPPT's door te lussen via ve.direct?

[ Voor 3% gewijzigd door Noord27 op 10-06-2026 13:13 ]

[teka1]

teka1 schreef op woensdag 20 mei 2026 @ 13:40:
[...]

Uiteindelijk gaat de MPPT wel naar absorptie toe, alleen duurt dat soms even. Ik heb eens de waardes vanuit de cerbo GUI naast elkaar gezet, zie onderstaande GIF.
Links de waarden van alle apparaten met de JK-BMS om in de gaten te houden, rechts de details van de MPPT. Wat mij opvalt is dat het voltage op de JK-BMS best wel snel veranderd, op de MPPT verloopt dat wat trager.

Interessant detail is ook, wanneer de spanning kort de 55.2V heeft aangetikt de MP in absorptiemodus is gegaan terwijl de MPPT nog in bulk laad.
MPPT is bedraad (VE.can) aangesloten op de cerbo.

Nu ik deze fluctuatie in voltage zie zat ik te denken om de absorptiespanning op de MP eens te verhogen naar 55.3V en op de MPPT op 55.2 laten staan. Zou dat een goed idee zijn om te zien of ze dan meer gelijktijdig in absorptie gaan? (of is er een manier om de voltage veranderingen sneller in de MPPT te krijgen)

[Afbeelding]

Om op mijn eigen suggestie terug te komen: Ik heb de VEConfig aangepast en de absorptiespanning verhoogt naar 55.3V, op de MPPT heb ik niets aangepast (laten staan op 55.2V).

Het lijkt er sterk op dat de VEConfig niet alleen de MultiPlus aanpast maar ook invloed heeft op de MPPT.
Ik zie namelijk dat de DC spanning op een gegeven moment boven de 55.2V komt, maar de MPPT gaat dan niet absorptie laden. Pas als de DC spanning boven de 55.3V komt gaat de MPPT absorptie laden, terwijl de MP al in absorptie laden stond.

Hiermee ben ik soort van terug bij af, de MP gaat eerder over op absorptie laden dan de MPPT, terwijl de bron voor de DC spanning voor alle apparaten gelijk is.

Heeft iemand een idee hoe ik de MPPT op hetzelfde moment naar absorptie laden kan krijgen als de MP. Of een suggestie wat ik nog eens kan aanpassen/uitzoeken?

[teka1]

Noord27 schreef op woensdag 10 juni 2026 @ 11:49:
Hoi,

Zijn er ook mensen die hun bestaande PV hebben uitgebreid met MPPT's van Victron? Ik zie versies met en zonder bluetooth (smart solar/blue solar). Kunnen de blue solar uitvoeringen met een GX apparaat middels vaste kabel gekoppeld worden; zoja zit hier een maximum aan? De opzet is om 3 stuks 100/20 (3x 2 panelen) extra te gaan leggen.

Ja heb ik! Ik gebruik de Smartsolar met VE.can aansluiting. Deze is gekoppeld aan mijn Cerbo. Je kan middels de VE.can 'daisychainen', dus meerdere MPPT's doorlinken. Ik weet zo niet wat de maximum is. Of je via VE.direct kan daisychainen weet ik niet.

Wellicht ten overvloede, maar gebruik ook de MPPT calculator om te bepalen welke/hoeveel MPPT's je nodig hebt: https://www.victronenergy.com/mppt-calculator
Ik heb één MPPT waar 6 panelen op zitten. Je moet goed kijken naar je series/strings om te bepalen of je wel meerdere MPPT's moet hebben.

[Q]

Noord27 schreef op woensdag 10 juni 2026 @ 13:12:
@Q Accu van 48V, tevens 48kWh. De 100/20 doet inderdaad 48V volgens de Victron website. Heb geen losse Cerbo, maar een Multiplus met GX ingebouwd. Daar zit ook een ve.direct poort op.

Met andere woorden is Bluetooth overbodig als je gebruik gaat maken via ve.direct met vaste verbindingen? Zijn de MPPT's door te lussen via ve.direct?

[Afbeelding]

[Afbeelding]

Je hebt een usb hub nodig met usb naar ve.direct nodig om de overige twee mppts aan te sluiten. Bluetooth is niet nodig, de GX regelt alles

[NTS]

Noord27 schreef op woensdag 10 juni 2026 @ 11:49:
Zijn er ook mensen die hun bestaande PV hebben uitgebreid met MPPT's van Victron?

Ja, ik ben daar mee bezig. Kwam nu uit op een SmartSolar MPPT 150/35 voor een klein setje extra panelen, die is vrij goedkoop bij Nkon bijvoorbeeld. Aansluiten kan op de VE.Direct rechtstreeks op een GX device, als je een vrije poort hebt. Volgens mij kan je die niet doorlussen.

[ Voor 4% gewijzigd door NTS op 10-06-2026 17:45 ]

[Noord27]

@NTS De maximale waardes van de Smart/Blue Solar MPPT's gaan exponentieel omhoog als je wat hogere waardes wil.

Een MPPT 100/20 is €66,- Een MPPT 150/35 is €132,-, een factor 2 zo duur. Maar kan dus (lang) niet zoveel aan als 2 stuks 100/20. Ik zit ook te kijken naar verschillende orientatie richtingen. Meer panelen op 1 MPPT klinkt als een prima oplossing, maar je bent wel gebonden aan 1 richting en exponentieel stijgen van de kosten van de MPPT zelf. Dan liever 3x 2 panelen op 3 losse MPPT's met 3 verschillende richtingen?

Een HUB voor ve.direct aanschaffen kost meer als wat de meerprijs is van 3x een SmartSolar ipv 3x BlueSolar. En dan lijkt het mij mogelijk om via BT met een GX te koppelen.

[ Voor 14% gewijzigd door Noord27 op 10-06-2026 19:14 ]

[simonj]

ik heb een Victron Phoenix multi plus 24V 3000va 70amp .die wil ik gebruiken met venus os large op een Raspberry pi + mijn 8kwh accu pakket. Voor 0 op de meter . Later komt ess erbij. Heb ik daarvoor ook de ac out nodig?

[Q]

Noord27 schreef op woensdag 10 juni 2026 @ 18:57:
Een HUB voor ve.direct aanschaffen kost meer als wat de meerprijs is van 3x een SmartSolar ipv 3x BlueSolar. En dan lijkt het mij mogelijk om via BT met een GX te koppelen.

Je kunt de MPPTs alleen bekabeld met een ve.direct kabel op een GX aansluiten. Bluetooth gaat niet werken.

[Q]

simonj schreef op woensdag 10 juni 2026 @ 19:49:
ik heb een Victron Phoenix multi plus 24V 3000va 70amp .die wil ik gebruiken met venus os large op een Raspberry pi + mijn 8kwh accu pakket. Voor 0 op de meter . Later komt ess erbij. Heb ik daarvoor ook de ac out nodig?

Nee, alleen de AC-IN. De AC-OUT is voor als de stroom uitvalt en je graag nog iets wilt draaien, zoals koelkast en/of verlichting. Misschien leuk om daar ergens een haspeltje voor neer te leggen

[simonj]

Q schreef op woensdag 10 juni 2026 @ 20:26:
[...]


Nee, alleen de AC-IN. De AC-OUT is voor als de stroom uitvalt en je graag nog iets wilt draaien, zoals koelkast en/of verlichting. Misschien leuk om daar ergens een haspeltje voor neer te leggen

goed idee.

[reneeke1970]

Noord27 schreef op woensdag 10 juni 2026 @ 18:57:
@NTS De maximale waardes van de Smart/Blue Solar MPPT's gaan exponentieel omhoog als je wat hogere waardes wil.

Een MPPT 100/20 is €66,- Een MPPT 150/35 is €132,-, een factor 2 zo duur. Maar kan dus (lang) niet zoveel aan als 2 stuks 100/20. Ik zit ook te kijken naar verschillende orientatie richtingen. Meer panelen op 1 MPPT klinkt als een prima oplossing, maar je bent wel gebonden aan 1 richting en exponentieel stijgen van de kosten van de MPPT zelf. Dan liever 3x 2 panelen op 3 losse MPPT's met 3 verschillende richtingen?

Een HUB voor ve.direct aanschaffen kost meer als wat de meerprijs is van 3x een SmartSolar ipv 3x BlueSolar. En dan lijkt het mij mogelijk om via BT met een GX te koppelen.

Bluetooth is enkel voor telefoon. Dus je moet de smart versie gebruiken met ve.can

Daarom heb ik de easy solar aangeschaft,daar zit mppt bij in.....

[Q]

reneeke1970 schreef op woensdag 10 juni 2026 @ 22:26:
[...]

Bluetooth is enkel voor telefoon. Dus je moet de smart versie gebruiken met ve.can

Daarom heb ik de easy solar aangeschaft,daar zit mppt bij in.....

De specifieke MPPTs die op het oog waren zijn niet ve.can maar ve.direct. Je hebt de smartsolar niet perse nodig.

[ Voor 5% gewijzigd door Q op 10-06-2026 23:06 ]