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.

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