Het grote Victron aansturing topic

[Japie.G]

V_ger schreef op dinsdag 19 mei 2026 @ 22:17:
Mijn ve.bus ellende blijft voortduren. Gisteren alles wat ik kwa software kon updaten geupdate en vandaag blij dat ik 3 uur lang heb kunnen terugleveren zonder problemen.

En dan 10 minuten nadat ie naar 0 op de meter is gegaan, 2x achter elkaar ve.bus weg....

Dus het ligt niet aan het sturen van set-points, niet aan storing op de kabels door hoge DC stroom. Ik snap er niets van. Iemand een suggestie over welke logfiles ik door zou moeten spitten?

Ik kan het nergens meer vinden en kan het me niet helemaal meer goed herinneren, maar ik heb ooit een filmpje gezien van iemand die dat soort problemen had door een aardlus en grounded / shielded utp kabels. Gebruik je gewone simpele utp kabels?

[V_ger]

Q schreef op dinsdag 19 mei 2026 @ 23:30:
[...]

Dat zou ik niet weten, mocht je het nog niet geprobeerd hebben:

- alle speciale devices loskoppelen van de cerbo en alleen vebus + energie meter aansluiten en testen, dan langzaam als het een periode goed gaat een voor een devices gaan toevoegen.

- Heb je echt niets recent veranderd en is de Ve.bus error altijd op 1 specifieke multiplus of willekeurig?

Dat weet ik dus niet. De bus herstart gewoon. Ik probeer te achterhalen waardoor, maar ik weet niet waar ik moet zoeken naar errors.

Punt is dat ik lastig dingen kan ontkoppelen omdat het soms erg lang duurt voordat een fout optreedt. Ik verdenk mijn nieuwe usb FT232's TTL adapters.

[Q]

V_ger schreef op woensdag 20 mei 2026 @ 07:16:
[...]

Dat weet ik dus niet. De bus herstart gewoon. Ik probeer te achterhalen waardoor, maar ik weet niet waar ik moet zoeken naar errors.

Punt is dat ik lastig dingen kan ontkoppelen omdat het soms erg lang duurt voordat een fout optreedt. Ik verdenk mijn nieuwe usb FT233's TTL adapters.

Gaat dit helpen?

Heb je ergens in de remote console van de cerbo iets gevonden qua notificaties, of wat dit docje beschrijft?

De open deur - waar je mogelijk niet veel zin in hebt - is om die FT233 TTL adapters om te switchen naar de oude versies die - zoals ik het begreep - zwaarder op de cerbo cpu zijn. Ik snap dat dit nadelen heeft, maar ik vrees inderdaad dat je systematisch oorzaken moet gaan uitsluiten.

[ Voor 24% gewijzigd door Q op 20-05-2026 07:34 ]

[Noord27]

@V_ger is dit soort situaties is het meest logische om reverse Engineering toe te passen. Terug werken wat er gewijzigd is tot aan het moment dat het probleemloos heeft gewerkt.

[V_ger]

Q schreef op woensdag 20 mei 2026 @ 07:28:
[...]

Gaat dit helpen?

Heb je ergens in de remote console van de cerbo iets gevonden qua notificaties, of wat dit docje beschrijft?

De open deur - waar je mogelijk niet veel zin in hebt - is om die FT233 TTL adapters om te switchen naar de oude versies die - zoals ik het begreep - zwaarder op de cerbo cpu zijn. Ik snap dat dit nadelen heeft, maar ik vrees inderdaad dat je systematisch oorzaken moet gaan uitsluiten.

Je link werkt niet. Het maffe is, er zitten maar 4 apparaten op de ve.bus. Drie MPs in 3 fase en de cerbo... Ik heb mijn CH340s USB-TTL nog. Maar die zijn USB A. En mijn nieuwe adapters USB-C. Heb de kabels dus vervangen.... En de oude doorgeknipt om ze eruit te kunnen krijgen. Dus dat wordt dan weer een projectje.

[V_ger]

Japie.G schreef op woensdag 20 mei 2026 @ 07:15:
[...]

Ik kan het nergens meer vinden en kan het me niet helemaal meer goed herinneren, maar ik heb ooit een filmpje gezien van iemand die dat soort problemen had door een aardlus en grounded / shielded utp kabels. Gebruik je gewone simpele utp kabels?

Yep gewoon eenvoudige cat5e kabels. Ze zijn wel blauw, ik dacht dat dat beter was 😉

Claude zegt overigens dat ik mijn usb hub moet voorzien van een externe voeding. Dat zou moeten helpen tegen slechte signalen. Die hub zit aan de cerbo. In de hub zitten nu dus 1 CH340 en 3 FT232 adapters. In de cerbo zit ook nog een USB rs485 adapter voor de ET 340 grid meter.

Maar dan zou eventueel een USB issue een herstart van de ve.bus triggeren?

Of de AI uitspraak ergens op gebaseerd is weet ik niet.

[HRV]

Het zou heel goed kunnen. Veel USB poorten leveren een hub onvoldoende vermogen om de hub en meerdere devices van stroom te voorzien. Dat kan resulteren in USB devices die niet lekker lopen of wegvallen.

[Q]

V_ger schreef op woensdag 20 mei 2026 @ 07:50:
[...]

Je link werkt niet. Het maffe is, er zitten maar 4 apparaten op de ve.bus. Drie MPs in 3 fase en de cerbo... Ik heb mijn CH340s USB-TTL nog. Maar die zijn USB A. En mijn nieuwe adapters USB-C. Heb de kabels dus vervangen.... En de oude doorgeknipt om ze eruit te kunnen krijgen. Dus dat wordt dan weer een projectje.

Deze?

https://www.victronenergy.com/live/ve.bus:ve.bus_error_codes

mijn indruk als stuurlui aan wal is dat ve.bus erg stabiel is en de kans dat er iets stuk is lijkt me gering.

Persoonlijk denk ik dat de devices op je usb hub niet teveel power vragen, maar uitsluiten door er een paar los te halen en paar dagen draaien kan helpen. lijkt mij prio 1 of igg oude situatie herstellen met oude devices.

[ Voor 22% gewijzigd door Q op 20-05-2026 08:38 ]

[Japie.G]

V_ger schreef op woensdag 20 mei 2026 @ 08:05:
[...]

Yep gewoon eenvoudige cat5e kabels. Ze zijn wel blauw, ik dacht dat dat beter was 😉

Claude zegt overigens dat ik mijn usb hub moet voorzien van een externe voeding. Dat zou moeten helpen tegen slechte signalen. Die hub zit aan de cerbo. In de hub zitten nu dus 1 CH340 en 3 FT232 adapters. In de cerbo zit ook nog een USB rs485 adapter voor de ET 340 grid meter.

Maar dan zou eventueel een USB issue een herstart van de ve.bus triggeren?

Of de AI uitspraak ergens op gebaseerd is weet ik niet.

blauw is goed, dus daar zit het probleem niet

Die unpowered USB hub vind ik wel een interessante. Is de VE.Bus intern in de cerbo ook een USB device (denk het niet)? Wellicht kan het dan wel wat met elkaar te maken hebben? Je kun op die gedachte ook nog eens een USB->VE.Bus device op je cerbo gebruiken om te kijken of het probleem uit je cerbo hardware komt als andere dingen niet baten..

[MJ de Bruijn]

V_ger schreef op woensdag 20 mei 2026 @ 08:05:
Yep gewoon eenvoudige cat5e kabels.

Het moeten inderdaad (ook elders al genoemd) niet afgeschermde kabels zijn (UTP Unshielded Twisted Pair).

[HyperBart]

V_ger schreef op woensdag 20 mei 2026 @ 08:05:
[...]

Yep gewoon eenvoudige cat5e kabels. Ze zijn wel blauw, ik dacht dat dat beter was 😉

Claude zegt overigens dat ik mijn usb hub moet voorzien van een externe voeding. Dat zou moeten helpen tegen slechte signalen. Die hub zit aan de cerbo. In de hub zitten nu dus 1 CH340 en 3 FT232 adapters. In de cerbo zit ook nog een USB rs485 adapter voor de ET 340 grid meter.

Maar dan zou eventueel een USB issue een herstart van de ve.bus triggeren?

Of de AI uitspraak ergens op gebaseerd is weet ik niet.

Ik zou dat USB verhaal als eerste elimineren. Ik heb echt vage shit gezien met devices die net niet genoeg of zuivere spanning/vermogen konden afnemen.

[V_ger]

HyperBart schreef op woensdag 20 mei 2026 @ 11:43:
[...]

Ik zou dat USB verhaal als eerste elimineren. Ik heb echt vage shit gezien met devices die net niet genoeg of zuivere spanning/vermogen konden afnemen.

Ja, ik ga even kijken hoe ik dat ga doen. Mijn hub heeft een 12V voeding nodig, dat heb ik niet beschikbaar bij mijn Victron systeem. Uiteraard heb ik een netvoeding bij de USB hub, maar naast dat ik dat niet wil heb ik ook geen stopcontact daar.. Ik sluit hem wel even aan op een verlengsnoer. Als het dan een paar dagen stabiel is koop ik wel een DC-DC convertertje om het permanent aan te sluiten. En anders moet ik toch verder zoeken.

edit:
Volgens mij heeft het niet geholpen..Ik heb al weer een ve.bus unknown melding...Hmm voordeel van de twijfel. Ik heb HA herstart.

[ Voor 8% gewijzigd door V_ger op 20-05-2026 12:54 ]

[teka1]

NTS schreef op maandag 18 mei 2026 @ 22:47:
[...]


Met DVCC en je BMS als bestuurder zou dat eigenlijk niet moeten kunnen. Zie je dat ook bij volle zon? En wat is dan het voltage terwijl de MPPT nog bulk zegt?

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)

[V_ger]

OK, USB hub aangesloten met externe voeding. Probleem ve.bus blijft. Inmiddels wel iets gevonden in:
/var/log/hub4control/current

2026-05-20 11:16:14.906293500 Multi @ "" disappeared.
2026-05-20 11:16:25.995909500 Multi found @ "com.victronenergy.vebus.ttyS4"

Het is meer een constatering dan een foutmelding waar ik iets aan heb. Ik vul aan wanneer ik meer weet. De timestamp is in UTC en komt overeen met de laatste melding in HA.


Zelfde in dbus-aggregate-batteries logfile. Maar we wisten al dat ie weg was. De vraag is waarom...

2026-05-20 11:16:14.730364500 INFO:root:MultiPlus/Quattro is not connected
2026-05-20 11:16:25.734293500 INFO:root:MultiPlus/Quattro is connected

[Q]

V_ger schreef op woensdag 20 mei 2026 @ 14:15:
OK, USB hub aangesloten met externe voeding. Probleem ve.bus blijft. Inmiddels wel iets gevonden in:
/var/log/hub4control/current

[...]

Het is meer een constatering dan een foutmelding waar ik iets aan heb. Ik vul aan wanneer ik meer weet. De timestamp is in UTC en komt overeen met de laatste melding in HA.


Zelfde in dbus-aggregate-batteries logfile. Maar we wisten al dat ie weg was. De vraag is waarom...

[...]

Misschien gel*l achteraf maar dat van die USB hub power vond ik niet waarschijnlijk omdat die FTL devices maar minimaal verbruiken, zover ik weet.

Persoonlijk denk ik dat je eerst volgende test beter kan zijn om die oude FTL devices weer terug te plaatsen. Dat is - zoals ik het begrijp - de belangrijkste verandering geweest - zoals je zelf aangaf.

Dat je de disconnects in de logs ziet vertelt je volgens mij niets nieuws toch?

[ Voor 4% gewijzigd door Q op 20-05-2026 14:49 ]

[V_ger]

Q schreef op woensdag 20 mei 2026 @ 14:48:
[...]

Misschien gel*l achteraf maar dat van die USB hub power vond ik niet waarschijnlijk omdat die FTL devices maar minimaal verbruiken, zover ik weet.

Persoonlijk denk ik dat je eerst volgende test beter kan zijn om die oude FTL devices weer terug te plaatsen. Dat is - zoals ik het begrijp - de belangrijkste verandering geweest - zoals je zelf aangaf.

Dat je de disconnects in de logs ziet vertelt je volgens mij niets nieuws toch?

Nee disconnects in de logs zegt niets nieuws, daar was ik al achter. Had gehoopt iets te kunnen vinden wat daarvoor plaatsvindt, maar niet dus. Die externe voeding had ik al weinig hoop op aangezien die TTL adaptertjes bijna niets verbruiken. Maar volgens mijn LLM zou een externe voeding het signaal verbeteren....Nou ja ik heb er alleen een verlengsnoer voor hoeven uitrollen.

Zit alleen met de bekabeling. De CH340's zijn male USB A, de FT232's zijn female USB C. Dus ik kan niet makkelijk terug.
Ik heb nu de gui uitgeschakeld (scheelt load) en de polling interval in serial-battery verhoogd naar 2.2 seconden.
En anders moet ik toch aan een ve.can BMS, gridmeter etc.
De hele reden dat ik andere USB-TLL adapters wilde proberen is een veel te hoge load op de cerbo. Maar ik ben nu van de regen in de drop geraakt.

[NTS]

Hoe is de voeding van de Cerbo zelf? Rechtstreeks van de batterijen?

[pgdodopgdo]

Ik ben nog een systeem aan het samenstellen en heb een vraag over de Cerbo aangesloten op een Fronius Symo via UTP, modbus TCP zodat de Cerbo de Fronius kan terugregelen.
Vraag is kan de Cerbo ook het geleverde vermogen van de Fronius via de Modbus uitlezen en in display weergeven of moet ik een extra VM-3P75CT op de Fronius AC uit aansluiten?

[ahjwinth]

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

[Beer070]

NTS schreef op woensdag 20 mei 2026 @ 17:36:
Hoe is de voeding van de Cerbo zelf? Rechtstreeks van de batterijen?

Mag van de batterijen, als ik het goed heb 7-70volt DC, kan dus ook op een 12 of 24 volt DC deurbel voeding.

[V_ger]

Mijn Cerbo zit direct op de DC bus. Uiteraard met zekering EN condensator parallel, want oud...

[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.