Het grote Deye inverter (en accu) topic

[zalkc]

hannibal2206 schreef op donderdag 1 oktober 2026 @ 23:31:
[...]

Ik heb sinds kort een Deye 6K 3 fase, met daarbij 4 stuks Yixiang v2 accu's.

Bij aansluiten van BMS kabel aan 1e pack wordt dat correct uitgelezen zoals je hierboven zegt, maar als ik het 2e pack ook aansluit wordt die waarde niet verhoogd ? Ik zou verwachten dat als max bv 90 A is ingesteld als max charge/discharge in het BMS voor 1 pack, maar je hebt 4 packs dat de Deye dan met 4 * die waarde rekent ?

Ik heb 2 yixiang's, de instelling van maximaal aantal ampère zijn de grenzen voor de Deye zelf (kunnen oo afwijken tov de BMS), zaken als totaal Ah moet die wel oppikken

[Yaldair]

n13l6 schreef op donderdag 1 oktober 2026 @ 10:17:
Hi all

Ik hoop dat ik dit niet dubbel post.

Gisteren ben ik door Deye geupdated naar: Main: 2107-1185-1809 en HMI: 1001-C060

Tot mijn opperblije verbazing en het vele, vele zeuren is de work mode aangepast en is er een extra rij knoppen toegevoegd: sell.

Dit was toch al beschikbaar met de laatste versie? in ieder geval, ik heb heel mijn nodered flows al ingeregeld op die sell functionaliteit, omdat ik het 3mnd geleden al ergens zag...(ik moest alleen zelf nog 1 versie updaten, dus had de functionaliteit nog niet). Of is er dan nog iets anders bijgekomen?

[scoobs]

@n13l6 Setpoints worden in theorie elk kwartier geschreven, maar het hangt een beetje af van de modus, en of ik de 20A deadband voorbij kom. Zeg een 20-30 writes per dag in de praktijk voor een individueel register. Daarnaast heb ik zitten spelen met het opschroeven van inverter en battery stress in EMHASS icm de MILP end state lager te zetten naar 0.001 ipv 0.01. Die combinatie voorkomt bijvoorbeeld flutter op dagen waarop solar charge meer is dan wat er in de accu komt, en er vooraf al een deel naar het net kan (of geblokkeerd) terwijl de accu's op halve kracht doortanken. Of als stroomprijzen min of meer 0 zijn 's middags, en er vanuit het grid wordt bijgetankt.

As we speak is er een NoM policy gepland voor over een uur: stroomprijzen zijn dan laag, maar nog niet zo laag dat het loont om actief uit het grid te laden, als we de extra verliezen meenemen die gepaard gaan met part-load in/out. Voor solar is dat anders: doordat er sowieso productie plaatsvind is er hoe dan ook een verlies, de marginale verliezen om het via de accu te routen wegen op tegen de lagere prijzen die later volgen.

Het huis hangt aan UPS. Het zou zonde zijn om deze feature van de Deye onbenut te laten. Zelfverbruik kan worden afgedekt, maar dat is prijsgestuurd, niet zozeer een doel op zich. Omdat ik nu zonneplan heb is er geen prijsprikkel om NoM te doen. Vanaf 1 januari komt die er in de vorm van post-salderen. Incidenteel zie ik NoM voorbij komen, maar dat is een resultaat van de ingebouwde efficienties in de writer. Als besloten wordt dat het na het doorrekenen van de efficientie goedkoper is om solar nu op te slaan dan nu te verkopen en later terug te kopen, dan volgt daar vaak een NoM policy uit. Maar omdat ik precies 0 buy en sell spread heb door mijn zonneplan contract icm salderen is dat iets dat alleen voorkomt als de prijs zo rond de 110-115% van de laagste prijs van de dag is. Post salderen zal dit veel meer voorkomen. Hieronder twee screenshots, waarbij ik bij eentje de salderingsoptie heb uitgevinkt





Deze screenshots illustreren trouwens waarom het nog in beta staat: nog niet alle deadbands staan op 20A, en modbus glitches kunnen het EMS triggeren tot bepaalde acties. Maar je zou het kunnen gebruiken ter inspiratie

https://github.com/scobbyd/deye-dayahead-ems/tree/main Voor als je eens wilt kijken.

[n13l6]

scoobs schreef op vrijdag 2 oktober 2026 @ 11:30:
@n13l6 Setpoints worden in theorie elk kwartier geschreven, maar het hangt een beetje af van de modus, en of ik de 20A deadband voorbij kom. Zeg een 20-30 writes per dag in de praktijk voor een individueel register. Daarnaast heb ik zitten spelen met het opschroeven van inverter en battery stress in EMHASS icm de MILP end state lager te zetten naar 0.001 ipv 0.01. Die combinatie voorkomt bijvoorbeeld flutter op dagen waarop solar charge meer is dan wat er in de accu komt, en er vooraf al een deel naar het net kan (of geblokkeerd) terwijl de accu's op halve kracht doortanken. Of als stroomprijzen min of meer 0 zijn 's middags, en er vanuit het grid wordt bijgetankt.

As we speak is er een NoM policy gepland voor over een uur: stroomprijzen zijn dan laag, maar nog niet zo laag dat het loont om actief uit het grid te laden, als we de extra verliezen meenemen die gepaard gaan met part-load in/out. Voor solar is dat anders: doordat er sowieso productie plaatsvind is er hoe dan ook een verlies, de marginale verliezen om het via de accu te routen wegen op tegen de lagere prijzen die later volgen.

Het huis hangt aan UPS. Het zou zonde zijn om deze feature van de Deye onbenut te laten. Zelfverbruik kan worden afgedekt, maar dat is prijsgestuurd, niet zozeer een doel op zich. Omdat ik nu zonneplan heb is er geen prijsprikkel om NoM te doen. Vanaf 1 januari komt die er in de vorm van post-salderen. Incidenteel zie ik NoM voorbij komen, maar dat is een resultaat van de ingebouwde efficienties in de writer. Als besloten wordt dat het na het doorrekenen van de efficientie goedkoper is om solar nu op te slaan dan nu te verkopen en later terug te kopen, dan volgt daar vaak een NoM policy uit. Maar omdat ik precies 0 buy en sell spread heb door mijn zonneplan contract icm salderen is dat iets dat alleen voorkomt als de prijs zo rond de 110-115% van de laagste prijs van de dag is. Post salderen zal dit veel meer voorkomen. Hieronder twee screenshots, waarbij ik bij eentje de salderingsoptie heb uitgevinkt

[Afbeelding]

[Afbeelding]

Deze screenshots illustreren trouwens waarom het nog in beta staat: nog niet alle deadbands staan op 20A, en modbus glitches kunnen het EMS triggeren tot bepaalde acties. Maar je zou het kunnen gebruiken ter inspiratie

https://github.com/scobbyd/deye-dayahead-ems/tree/main Voor als je eens wilt kijken.

Mega bedankt voor de uitgebreide uitleg. Ik was al onder de indruk van wat ik snel had geknutseld maar wat jij doet is next level lol. Ik ga er later even goed induiken hoe jij het hebt gebouwd. En op zich is zelfverbruik inderdaad geen doel am sich, maar is de optimalisatie van kosten/winst.

Heb net nog even wat verder gegraven, en als EMHASS een vermogenssetpoint uitstuurt voor de omvormer dan houdt hij al rekening met het gemiddelde stroomverbruik per uur van het huishouden zelf. Als je dan een waterkoker aanzet dan kan deze kortstondig over het limiet heen gaan, maar dat is niet heel erg want het gaat niet om veel energie. Dan is de nieuwe software van Deye wel super want die kan wel dit doen in de ToU tabel wat gigantisch vaak schrijven voorkomt.

Wat ik nog wel raar vind, is dat als je bijvoorbeeld 1000W insteld op Sell dat deze dan 1000W-je verbruik van het huis teruglevert plus de zonnestroom die je op dit moment aan het opwekken bent... Beetje vermoeiend wel die instellingen van Deye, elke keer totaal onverwacht gedrag. Je zou verwachten dat als je hem op 1000W power hebt staan in de ToU tabel je deze niet ook nog hoeft te beperken met de maximale power setting.

[scoobs]

@n13l6 @n13l6 Dat gedrag bij Sell klopt wel, het vermogen in de ToU tabel is geen grid setpoint maar een limiet aan de batterijkant. Wat er naar het net gaat rekent de Deye zelf uit als restpost, ontlading + PV - huisverbruik. Wil je de export begrenzen dan moet je via max sell power.

Daarom stuur ik ook niet via ToU maar via laad- en ontlaadstroom icm work mode en export surplus. ToU heeft (op mijn SG04LP3 iig) maar 6 slots per dag, en dan ben je de kwartier resolutie kwijt. Met deadbands kom ik op een 20-30 writes per register per dag, prima te doen. Wel handig als vangnet: als je controller crashed blijven die registers gewoon staan.

Wat ik qua volgorde van belangrijkheid zou aanhouden, grotendeels doorgerekend in backtests:

EV als deferrable load, als je er een hebt. Ongepland laden maakt je verbruiksvoorspelling waardeloos, en echt laten plannen leverde in mijn simulatie ~100 euro per jaar op bovenop een simpele timer.

Plannen op kwartieren ipv uren, zo'n 70 euro per jaar, meer dan alle voorspel-verbeteringen bij elkaar.

De losses kloppend krijgen. EMHASS telde bij mij de verliezen dubbel (round trip ca 25% gepland, 13% gemeten). Voorzichtigheid stop ik nu in aparte knoppen: een minimale marge per cyclus, stress costs tegen flutter.

De uitvoering, een writer die het plan ook echt netjes neerzet. Daar zit het meeste werk in. Zie de github.

Pas als laatste de voorspellingen. AC heeft bij mij een eigen controller en de rest van het verbruik is de mediaan van de afgelopen 7 dagen per kwartier. Zelfs een perfecte voorspelling scheelt maar een euro of 6-20 per jaar, ML modellen haalden er weinig meer uit. Je controller zal wat tekorten/overschotten hebben als het plots flink wijzigt in temperatuur en je electrische climate control hebt, mjah, gerommel in de marge, en binnen een paar dagen trekt zich dat wel recht. (Los van dat de planner gewoon herplant en op dagelijkse basis al flink wat opvangt.)

[ Voor 70% gewijzigd door scoobs op 02-10-2026 12:36 ]

[n13l6]

scoobs schreef op vrijdag 2 oktober 2026 @ 12:22:
@n13l6 @n13l6 Dat gedrag bij Sell klopt wel, het vermogen in de ToU tabel is geen grid setpoint maar een limiet aan de batterijkant. Wat er naar het net gaat rekent de Deye zelf uit als restpost, ontlading + PV - huisverbruik. Wil je de export begrenzen dan moet je via max sell power.

Daarom stuur ik ook niet via ToU maar via laad- en ontlaadstroom icm work mode en export surplus. ToU heeft (op mijn SG04LP3 iig) maar 6 slots per dag, en dan ben je de kwartier resolutie kwijt. Met deadbands kom ik op een 20-30 writes per register per dag, prima te doen. Wel handig als vangnet: als je controller crashed blijven die registers gewoon staan.

Wat ik qua volgorde van belangrijkheid zou aanhouden, grotendeels doorgerekend in backtests:

EV als deferrable load, als je er een hebt. Ongepland laden maakt je verbruiksvoorspelling waardeloos, en echt laten plannen leverde in mijn simulatie ~100 euro per jaar op bovenop een simpele timer.

Plannen op kwartieren ipv uren, zo'n 70 euro per jaar, meer dan alle voorspel-verbeteringen bij elkaar.

De losses kloppend krijgen. EMHASS telde bij mij de verliezen dubbel (round trip ca 25% gepland, 13% gemeten). Voorzichtigheid stop ik nu in aparte knoppen: een minimale marge per cyclus, stress costs tegen flutter.

De uitvoering, een writer die het plan ook echt netjes neerzet. Daar zit het meeste werk in. Zie de github.

Pas als laatste de voorspellingen. AC heeft bij mij een eigen controller en de rest van het verbruik is de mediaan van de afgelopen 7 dagen per kwartier. Zelfs een perfecte voorspelling scheelt maar een euro of 6-20 per jaar, ML modellen haalden er weinig meer uit. Je controller zal wat tekorten/overschotten hebben als het plots flink wijzigt in temperatuur en je electrische climate control hebt, mjah, gerommel in de marge, en binnen een paar dagen trekt zich dat wel recht. (Los van dat de planner gewoon herplant en op dagelijkse basis al flink wat opvangt.)

Ik lijk een redelijke relatie te hebben met Deye, als jij de ideale werkmodus zou mogen definieren, wat zou dat dan zijn? Tabel met laad en ontlaadvermogens naast de grid/gen/charge knop? De 6 sloten voor ToU moeten we sowieso mee dealen dus kwartierdata gaat m niet worden denk ik. Kan zelf ook wel met die 70 euro verschil leven, de aansturing die ik nu heb is erg eenvoudig t.o.v. de jouwe.

Verbeteringen kan ik dat meegeven aan het team daar, ze staan zeer open voor feedback.Ik vind het alsnog erg ingewikkeld hoe het nu moet worden opgelost. Sowieso zou het veel fijner zijn als we gewoon naar ram zouden schrijven en (near) real time kunnen sturen.

Hier onder een overzichtje.
Bovenaan links:
- Live sturen tabellen aan/uit (4x per dag update van de tabellen)
- Hoe groot de blokken moeten zijn: 1 tot 4 uur
- Manuele override van de 6 uur wachttijd
- Waarden terugzetten naar standaard Deye

Daaronder:
Tabel met rolling window vanuit EMHASS

Daaronder:
De virtuele setpoint voor de ToU tabel (lampje) en eronder de huidige, werkelijke setpoints van de ToU tabel.



Nog te doen:
- 3x deferabble loads + live inlezen SoC / temp
- Testen testen testen!

[hannibal2206]

zalkc schreef op vrijdag 2 oktober 2026 @ 10:14:
[...]

Ik heb 2 yixiang's, de instelling van maximaal aantal ampère zijn de grenzen voor de Deye zelf (kunnen oo afwijken tov de BMS), zaken als totaal Ah moet die wel oppikken

Het lijkt er bij mij op dat alleen de BMS data van de 1e accu gezien wordt door de Deye; waar zie jij precies dat de data van de 2e accu (of het totaal) opgepikt wordt ? En, hoe heb je de Ethernetkabels lopen en dip switches staan; ik heb daarmee ge-experimenteerd maar zie nooit verschil ..

[Yaldair]

Modbus writes naar TOU gaan nog steeds via EEPROM. De deye heeft naar mijn weten geen RAM. Waarom EEPROM: als je de deye restart/spanningsloos maakt, blijft je oude TOU tabel in place. Dus, het is niet vluchting, dus niet RAM. vandaar dat ik bij mij erg voorzichtig ben met writes naar de Deye. Ik misbruik YAMBMS nu als man in the middle, om zo een laad instructie te geven (EOC target) en eventueel ontlading te regelen (DCL dynamisch aanpassen). Ik heb nu m.b.v mijn aanpak en Claude wat complexe nodered flows opgezet. Doel is die ook op github te plaatsen als het goed werkt (en ik het wat robuster kan maken voor anderen). (waarom claude: ik bepaal de strategie, maar claude kan het waarschijnlijk efficienter coderen).

Hoe dan ook even de mindset: i.p.v. uit te gaan van exacte stromen uit de forecasts van EMHASS, kijk je naar de achterliggende intentie per kwartier. Want, EMHASS weet niet of je echt zoveel PV hebt als voorspelt, of je loads net zo hoog liggen als voorspelt. Wat hij wel doet is een sluitende berekening maken per kwartier met een achterliggende intentie, op basis van de vermogens distributie:
laden van de accu (met alle beschikbare PV, of maar een subset), de accu op een bepaalde SOC laten staan (i.e., hold), de accu ontladen. Laden met/zonder grid, verkopen aan grid...etc.

Dan reduceer je de writes naar TOU tabel in principe tot een aantal acties per dag: t.SOC = 100 (laden via grid, hold), of t.soc = 15% (of whatever je wil) --> ontladen, of laden via PV. Eventueel dan nog grid charge aan/uit vinken. En nu dan ook sell aan/uit vinken. Vermogen is dan maximaal vermogen dat YAMBMS toe staat (met EOC time in yambms regelt hij zelf dynamisch de CCL). En in geval dat de auto aan het laden is (ook voorspelde load zodat emhass er van af weet) limiteer ik dynamisch de DCL in yambms (dus de accu wordt alleen gebruikt voor de standaard huis loads en niet voor de auto).

Hoofd gedachtegang: EMHASS e.d. geven alleen een intentie, en als je die intentie volgt heb je de meeste winst/minste verlies. Maar, ze weten nooit de actuals dus je kan niet letterlijk de berekende vermogens gebruiken. Ik cluster dan ook nog de intenties per kwartier indien gelijk, zodat ik een juiste end of charge time/target kan aansturen richting yambms. Scheelt weer writes naar Deye.

[n13l6]

Er zit trouwens een extra nieuwe feature in op pagina 3 van de use modes, ik had bij Deye nagevraagd wat dit doet, hopelijk is dit interessant voor jullie:

hard export：
This feature enforces a hard limit on the power sold. If the hard limit is exceeded, the machine will be disconnected from the grid, switching from grid-connected to off-grid. This feature is available in all modes.

When the power export exceeds the Hard export control set value, the inverter will disconnect the grid-side relay, trigger alarm W13 to stop inverting output, and automatically switch to off-grid mode operation. After 2 minutes, the system will re-close the grid-side relay and re-evaluate; if the power export has returned within the hard limit range at that time, the inverter will resume grid-connected operation.
It is recommended that the maximum power export setting be ‌less than the hard limit value‌, otherwise, the hard limit may be easily triggered, causing the grid-side relay to disconnect and the inverter to switch to off-grid mode.

Regarding the other issues you raised,
I will report them to the R&D department for review.

[MarcoPolet]

Ik werk met 1 vaste TOU, van zeg maar 0:00 tot 23:59 oid. En sturing doe ik met Maximum battery charge current, Maximum battery discharge current en de target SOC van het ene timeslot (Time point 1 capacity). Hierboven werd geopperd dat de Deye geen RAM zou hebben, maar dat kan natuurlijk niet, er draait een heel besturingssysteem op, dus zeker weten ook RAM. Dat zegt natuurlijk nog niets of wel of niet alle settings via EPROM gaan, daar heb ik ook geen zicht op. Ik hoop dat mijn registers in RAM zitten :-)

[hannibal2206]

Ik heb een gebruikte Deye 3 fase via MP overgenomen en daar zitten de CT klemmen niet bij; weet iemand of die los te krijgen zijn ? Of kan het met een Eastron net zo goed ?

[scoobs]

Afhankelijk van wat je setup is heb je ze ook niet nodig. Maar eastron werkt, en volgens mij elke 2000:1 ct coil.

[ Voor 32% gewijzigd door scoobs op 03-10-2026 19:47 ]

[jadjong]

Je kan de verhouding ook instellen in de omvormer.

[rvdgaag]

hannibal2206 schreef op zaterdag 3 oktober 2026 @ 19:44:
Ik heb een gebruikte Deye 3 fase via MP overgenomen en daar zitten de CT klemmen niet bij; weet iemand of die los te krijgen zijn ? Of kan het met een Eastron net zo goed ?

Ik heb nog een ongebruikt setje liggen als je wilt, pm me maar. De eastron oplossing is ook prima

[PieterL]

Jullie als Deye gebruikers, ik wil Deye 32 of 48k . Heb 40 zonnepanelen en geen EV. Ben geen technicus. Lukt het toch Deye eenvoudig te programmeren? Of is BE een beter idee?

[dingo35]

Laat de installateur m programeren, als je geen technisch inzicht hebt is het een hopeloze zaak.

[PieterL]

dingo35 schreef op zondag 4 oktober 2026 @ 20:13:
Laat de installateur m programeren, als je geen technisch inzicht hebt is het een hopeloze zaak.

Is helder. Is BE een optie? Is goedkoop maar 2 jaar lang bepalen zij alles en jij niets ...

[scoobs]

hier stond een rant zonder inhoud.

[ Voor 151% gewijzigd door teacher op 04-10-2026 21:01 ]

[scoobs]

Aangezien de moderators bovenstaande post een rant zonder inhoud vonden, refereer ik nu naar een eerder euvel dat ik met ze had.

scoobs in "Ervaring Balans Energie: TenneT BSP aFRR"

Daarnaast is mijn ervaring dat er 1,5-2x zoveel te verdienen valt met dezelfde hardware en een eigen EMS - zoals ik een paar posts terug besprak - dan wat BE doet met hun EMS.

Daarnaast zijn er tal van issues te lezen waarbij (hardware) problemen niet tijdig opgelost worden. Ik raad het ten zeerste af om met ze in zee te gaan.

[ Voor 16% gewijzigd door scoobs op 04-10-2026 21:12 ]

[deejeebv]

PieterL schreef op zondag 4 oktober 2026 @ 20:23:
[...]

Is helder. Is BE een optie? Is goedkoop maar 2 jaar lang bepalen zij alles en jij niets ...

Bij Balansenergie moet je het vooral hebben van de dagen met een extreme onbalansprijs.

Dit was bijvoorbeeld mijn resultaat op 1 oktober.

[Bart1201]

scoobs schreef op vrijdag 2 oktober 2026 @ 09:59:
En als je export first doet met grid peak shaving off en max sell power als export target?

Ik liep tegen hezelfde probleem van de ToU tabel als @n13l6, waar de deye de limiet gebruikt voor de batterij. Dus ik heb dit ook met export first en max sell power geprobeerd. In mijn ervaring limiteert max sell power ook de export uit de batterij.

Wat mij wel opviel was dat het aanpassen van max sell power ook (advanced function ->) export power limiter veranderde (zelfde waarde)

n13l6 schreef op vrijdag 2 oktober 2026 @ 09:46:
Net maar weer even een feature request naar Deye gestuurd...

Ik ben benieuwd naar de reactie, want dit is waar ik met het aansturen via EMHASS wel tegenaan loop.

[ Voor 19% gewijzigd door Bart1201 op 05-10-2026 08:46 ]

[n13l6]

Bart1201 schreef op maandag 5 oktober 2026 @ 08:42:
[...]

Ik liep tegen hezelfde probleem van de ToU tabel als @n13l6, waar de deye de limiet gebruikt voor de batterij. Dus ik heb dit ook met export first en max sell power geprobeerd. In mijn ervaring limiteert max sell power ook de export uit de batterij.

Wat mij wel opviel was dat het aanpassen van max sell power ook (advanced function ->) export power limiter veranderde (zelfde waarde)


[...]

Ik ben benieuwd naar de reactie, want dit is waar ik met het aansturen via EMHASS wel tegenaan loop.

Ik ga denk ik zelf een manuele override maken als EMHASS aangeeft op modus "disabled" te willen staan maar dan met een laag vermogen omdat dat uit de voorspelling komt. Ik wil gewoon als ik s nachts energie verbruik dit 100% uit de accu komt. Ik laat de EMHASS vermogenm doelwaarde gewoon overschrijven naar de maximale waarde van de omvormer om zo altijd mijn eigen gebruik te kunnen faciliteren. Bij kopen en verkopen van stroom geloof ik dat het wel goed gaat.

[fmb]

fmb schreef op zondag 20 september 2026 @ 18:43:
[...]

Op basis van jullie bruikbare input en verder uitzoekwerk heb ik het aansluitschema verbeterd en wat uitgebreid. Uiteraard neem ik graag nog een tweede ronde advies mee, dus zien jullie hier nog wat in?

Ik ben met de aanvullende tips nu op dit schema uitgekomen - dank voor de input!
Heb de onderbouwing voor een aantal keuzes/onderdelen hier ook aan toegevoegd. Dat is vooral voor mezelf, maar wie weet heeft iemand er nog wat aan. Mocht er nog wat volgen uit de NEN1010 keuring dan zal ik dat laten weten later.



Ik heb besloten om voor de 12 kW variant te gaan. Dat is voldoende voor ons. En dan voelt het wel logischer voor mij om voor de nieuwe versie te gaan.

Los van het extra vermogen zou de 15kW versie als voordeel hebben dat de 2 accu's hier direct op aangesloten kunnen worden en er geen extra busbar nodig is. Maar het voordeel van de extra busbar is weer iets meer flexibiliteit in de aanleg van de DC kabels (voor beide accu's de kabels even lang houden) en het gemakkelijker kunnen toevoegen van een DC schakelaar. Tot slot is de 15 kW versie +- 300 euro duurder en daarmee ontloopt het elkaar qua kosten nauwelijks

Ik ben nog wel een paar weken bezig, dus sta open voor aanvullende input en ik zal af en toe een update plaatsen hier.

[Wodan89]

ik sta op het punt om een Deye SUN-30K-SG02HP3-EU-AM3 te bestellen voor mijn dyness BF100-C140. nu komt deze 55M van de meterkast te hangen icm 5g16 yvmk SS, ivm huidige hoofdzekering 3x25a C automaten moet deze strak begrenst worden op 25A inport en export. wat regeld het snelste? modbus inline meter ? of de meegeleverde CT,s gebruiken via 7x1mm2 afgeschermde stuurstroom kabel?

[-Niels-]

de Eastron modbus meter lezen ze in elk geval 8x per seconde uit. Hoe snel dit gaat met de CT's is alleen een intern feestje dus moeilijker te zeggen.

Ben je bang voor de deye zelf die een te hoge stroom vraagt of externe (piek) belasting?

Bart1201 schreef op maandag 5 oktober 2026 @ 08:42:
Ik ben benieuwd naar de reactie, want dit is waar ik met het aansturen via EMHASS wel tegenaan loop.

Even nieuwsgierig, ik heb mn deye nu net een beetje up and running via DAO. Daar zie ik eigenlijk nooit "halve" belasting. T is of maximaal laden of maximaal ontladen, alleen als de batterij bijna vol of leeg is nog wel eens onder t maximum omdat de energie op in binnen t kwartier.
Verschilt EMHASS hier dusdanig in dat dit een groot issue is?

[ Voor 55% gewijzigd door -Niels- op 05-10-2026 21:33 ]

[genesisfm]

Even een vraag over een gedachte welke in mijn hoofd rond ging, ik heb nu 2x 16kwh accu's staan in een mooie behuizing. Als er ooit eens iets mis gaat dan laat de interne cel zijn gassen los via het ventiel bovenop de cel en de gassen zullen dan ergens in die behuizing zijn en uiteindelijk lekken de ruimte in (in mijn geval de schuur).

Stel voor ik maak op de behuizing een aansluiting met een gat van rond 40mm (als voorbeeld) en aan die aansluiting bevestig ik een stalen slang welke ik naar naar buiten lijd. Het idee hier achter is dat de vrijgekomen gassen/rook (en mogelijke overdruk, hitte?) dan niet in de ruimte blijven maar netjes afgevoerd worden.

Ik ben benieuwd naar jullie ideeën hierover?

[Wodan89]

-Niels- schreef op maandag 5 oktober 2026 @ 21:29:
de Eastron modbus meter lezen ze in elk geval 8x per seconde uit. Hoe snel dit gaat met de CT's is alleen een intern feestje dus moeilijker te zeggen.

Ben je bang voor de deye zelf die een te hoge stroom vraagt of externe (piek) belasting?


[...]


Even nieuwsgierig, ik heb mn deye nu net een beetje up and running via DAO. Daar zie ik eigenlijk nooit "halve" belasting. T is of maximaal laden of maximaal ontladen, alleen als de batterij bijna vol of leeg is nog wel eens onder t maximum omdat de energie op in binnen t kwartier.
Verschilt EMHASS hier dusdanig in dat dit een groot issue is?

ivm met handelen en het formaat accu wil ik behoorlijk strak op de 25A zitten kwa laden en ontladen. als er dan een waterkoker of kookplaat binnen aangaat wil ik wel dat hij dan zo snel mogelijk terugregeld om te voorkomen dat de hoofd automaat klapt.

[ybos]

genesisfm schreef op maandag 5 oktober 2026 @ 21:31:
Even een vraag over een gedachte welke in mijn hoofd rond ging, ik heb nu 2x 16kwh accu's staan in een mooie behuizing. Als er ooit eens iets mis gaat dan laat de interne cel zijn gassen los via het ventiel bovenop de cel en de gassen zullen dan ergens in die behuizing zijn en uiteindelijk lekken de ruimte in (in mijn geval de schuur).

Stel voor ik maak op de behuizing een aansluiting met een gat van rond 40mm (als voorbeeld) en aan die aansluiting bevestig ik een stalen slang welke ik naar naar buiten lijd. Het idee hier achter is dat de vrijgekomen gassen/rook (en mogelijke overdruk, hitte?) dan niet in de ruimte blijven maar netjes afgevoerd worden.

Ik ben benieuwd naar jullie ideeën hierover?

Hoe vaak komt het voor

Je introduceert ook weer een ander risico. Als de verzekeraar erachter komt dat je hebt lopen boren in de behuizing -> eventuele goedkeuringen vervallen direct -> mogelijk keren ze na brand niet uit. (puur hypothetisch aangezien je zelf ook met een issue komt met een zeer kleine kans)

[ybos]

Wodan89 schreef op maandag 5 oktober 2026 @ 21:35:
[...]

ivm met handelen en het formaat accu wil ik behoorlijk strak op de 25A zitten kwa laden en ontladen. als er dan een waterkoker of kookplaat binnen aangaat wil ik wel dat hij dan zo snel mogelijk terugregeld om te voorkomen dat de hoofd automaat klapt.

Paar seconden is echt geen probleem en de Deye regelt redelijk vlot terug.

Ik heb met mijn hoofdzekering van 25A ook vrij kort enkele keren 50A gezien. Moet wel zeggen dat ik nog zekeringen heb, die kunnen wat meer hebben dan automaten.

[-Niels-]

Wodan89 schreef op maandag 5 oktober 2026 @ 21:35:
[...]

ivm met handelen en het formaat accu wil ik behoorlijk strak op de 25A zitten kwa laden en ontladen. als er dan een waterkoker of kookplaat binnen aangaat wil ik wel dat hij dan zo snel mogelijk terugregeld om te voorkomen dat de hoofd automaat klapt.

Dat zal sowieso wel goed gaan, dit regelt een deye met een seconde wel bij.
Een C automaat kan tot een seconde of 2 met een factor 5 overbelast worden. (wel bij 30 graden etc maar de 10A extra van een waterkoker is wel ruim binnen de marge)

[genesisfm]

ybos schreef op maandag 5 oktober 2026 @ 21:35:
[...]

Hoe vaak komt het voor

Je introduceert ook weer een ander risico. Als de verzekeraar erachter komt dat je hebt lopen boren in de behuizing -> eventuele goedkeuringen vervallen direct -> mogelijk keren ze na brand niet uit. (puur hypothetisch aangezien je zelf ook met een issue komt met een zeer kleine kans)

Je hoopt nooit natuurlijk, maar ik was er gewoon nieuwsgierig na en het klonk mijn ook wel logisch in de oren.

Dit zegt AI trouwens:

Bij jouw kasten zou ik daarom niet zomaar gaan boren. Daarmee kun je namelijk de constructie, IP-bescherming, brandwerendheid en eventueel garantie/typegoedkeuring veranderen. Bovendien weet je zonder testgegevens niet of één zelfgemaakte aansluiting voldoende is voor ventgas of overdruk.

Praktisch zijn er drie opties:

1. Kast ongemoeid laten en de schuur als veiligheidsruimte behandelen. Dan zorg je voor rook/CO-detectie en een goede afvoer/ventilatie van de schuur naar buiten. Dit is de minst ingrijpende optie.
2. Een aparte omkasting rond beide accukasten maken. Bijvoorbeeld een metalen compartiment/kast rondom de batterijen met eigen ventilatie naar buiten. Dan hoef je de -behuizingen niet te wijzigen. Voor jouw situatie vind ik dit technisch de netste oplossing als je echt gecontroleerde gasafvoer wilt.
3. De accukast zelf modificeren. Dat kan technisch, bijvoorbeeld met een metalen flens bovenin, maar ik zou dit pas doen als duidelijk is hoe de kast constructief is opgebouwd en of de leverancier daar eisen of voorzieningen voor heeft.

Er is nog een belangrijk detail uit PGS: de gewone ventilatie-eis M19 gaat vooral over betreedbare EOS-ruimten. Typical 3, de categorie met niet-betreedbare batterijbehuizingen, staat zelfs niet in de lijst waarop M19 van toepassing is. Daardoor kun je niet zomaar zeggen dat PGS eist dat jouw kleine batterijbehuizing continu geventileerd moet worden. Publicatiereeks Gevaarlijke Stoffen

Daarom zou ik bij jouw 2 × 16 kWh opstelling niet als eerste gaten in de kasten maken. Ik zou eerder kijken naar een soort veiligheidsomkasting:

[Yaldair]

Ik kwam er gisteren achter dat we de Deye ook realtime kunnen aansturen zonder naar de TOU (EEPROM) te schrijven. Blijkbaar is er een "remote" optie waar je naar RAM schrijft en dan specifiek hoeveel stroom je naar net/uit net haalt, of uit accu e.d. Ik ga daar deze dagen eens wat meer naar kijken, want dan kan ik mijn eeprom writes nog meer verminderen. Even hoe ik de registers nu in de sunsynk addon heb gezet:

code:

1100  remote mode        0 = uit, 1 = aan (2/3 bestaan, betekenis onduidelijk)
1101  watchdog (s)       65535 = niet gezet
1104  stuurzijde         0 = AC, 1 = accu, 2 = net
1105  accu-submode       2 = vermogen, 3 = SOC, 4 = spanning+stroom, 5 = vermogen+SOC
1106  fasemodus          0 = 3 fasen samen, 1 = per fase
1107/1108  spanning / stroom   x10
1109  accuvermogen       % van nominaal x10 (signed?)
1110  SOC-doel           x10 (uitgelezen: 800 = 80%)
1111-1113  per fase      % x10
1114  totaal netvermogen % x10 (signed?)
1115  max solar          % x10 (65535 = niet gezet)

Voor de sunsynk/deye add-on (mysensors.py) heb ik ze zo gedefinieerd:

code:

from sunsynk.rwsensors import NumberRWSensor, SelectRWSensor
SENSORS += (
    SelectRWSensor(1100, "RC mode", options={0: "Uit", 1: "Aan"}),
    NumberRWSensor(1101, "RC watchdog", "s", min=10, max=600),
    SelectRWSensor(1104, "RC side", options={0: "AC", 1: "Accu", 2: "Net"}),
    SelectRWSensor(1105, "RC battery mode", options={2: "Vermogen", 3: "SOC", 5: "Vermogen+SOC"}),
    SelectRWSensor(1106, "RC phase mode", options={0: "3 fasen samen", 1: "Per fase"}),
    NumberRWSensor(1109, "RC battery power", "%", -0.1, min=-45, max=45),   # + = ontladen, - = laden; 1 % = 120 W
    NumberRWSensor(1110, "RC soc", "%", 0.1, min=10, max=100),
    NumberRWSensor(1111, "RC total power", "%", -0.1, min=-20, max=20),     # net: + = afname, - = teruglevering
    NumberRWSensor(1115, "RC max solar", "%", 0.1, min=0, max=99.9),        # >= 100 % geeft 0 W
)

Iemand anders die dit al zo gebruikt? ik moet nog wat testen met precies wat er weggeschreven wordt en hoe het gedrag van de Deye is. AI vond het op akkudoktor forum...bij mij bestaan de registers in ieder geval wel, dus lijkt me dat ik ze moet kunnen gebruiken. Als ik tijd heb even goed gaan uitwerken om zo helemaal dynamisch de deye aan te sturen, i.p.v. ieder kwartier yambms/deye aan te passen.

Update: de (vertaalde) Deye-documentatie uit het Akkudoktor-topic gevonden. Correcties:
- 1109 accuvermogen: 100 = 10% van nominaal (12K: 1% = 120 W), positief = ontladen, negatief = laden.
- 1110 doel-SOC x10. Met 1105=5 (vermogen+SOC) laadt/ontlaadt hij met 1109 tot 1110 en stopt dan zelf; klopt de combinatie niet, dan doet hij niets.
- 1106 = 0/1: totaal (1111) of per fase (1112-1114), alleen voor AC- en netmodus. Totaalvermogen is dus 1111, niet 1114.
- 1111 in netmodus: + = afname, - = teruglevering.
- 1100 kent in de Deye-doc alleen 0/1. De "remote mode 2/3" uit de ha-solarman-PR-wiki heeft geen bron; die wiki wijkt vanaf 1106 ook af van de Deye-doc
- Laad/ontlaadvermogen blijft begrensd door de max. accustroom (BMS); in off-grid werkt remote mode niet.

[ Voor 17% gewijzigd door Yaldair op 06-10-2026 23:27 ]

[HarDus]

Heeft iemand gekozen voor 1-fase en zijn netaansluiting verminderd van 3x25A naar 1x35A. De 1-fase maakt aanzienlijk minder lawaai (1 groot kanaal ipv 3 kleine) en zou voldoende zijn na het plaatsen van de batterij. Geen gedoe met scheve belasting etc. Veel meer voordeel van ongelijktijdigheid.

Verdere voordeel is dat ik in de garage ook 1 fase met batterij krijg voor PV en battery boost. Dan kan ik twee gelijke omvormers kiezen.

Zou graag met iemand overleggen die dit zo heeft aangepakt? Ken niemand die “de weg terug” belopen heeft.

[Jerra]

Hoewel het geluid en scheefbelasting wel degelijk een voordeel kunnen zijn lijkt het me niet zeer voordelig. Er is geen lager nettarief voor deze veel kleinere aansluiting.

Je verliest de mogelijkheid om dynamisch te handelen, ook als dat nu niet interessant is weet je niet hoe de toekomst verandert, mogelijk is het wel interessant vanwege tijdsafhankelijke nettarieven bijvoorbeeld.

[reputatio]

fmb schreef op maandag 5 oktober 2026 @ 21:02:
[...]

Ik ben met de aanvullende tips nu op dit schema uitgekomen - dank voor de input!
Heb de onderbouwing voor een aantal keuzes/onderdelen hier ook aan toegevoegd. Dat is vooral voor mezelf, maar wie weet heeft iemand er nog wat aan. Mocht er nog wat volgen uit de NEN1010 keuring dan zal ik dat laten weten later.

[Afbeelding]

Ik heb besloten om voor de 12 kW variant te gaan. Dat is voldoende voor ons. En dan voelt het wel logischer voor mij om voor de nieuwe versie te gaan.

Los van het extra vermogen zou de 15kW versie als voordeel hebben dat de 2 accu's hier direct op aangesloten kunnen worden en er geen extra busbar nodig is. Maar het voordeel van de extra busbar is weer iets meer flexibiliteit in de aanleg van de DC kabels (voor beide accu's de kabels even lang houden) en het gemakkelijker kunnen toevoegen van een DC schakelaar. Tot slot is de 15 kW versie +- 300 euro duurder en daarmee ontloopt het elkaar qua kosten nauwelijks

Ik ben nog wel een paar weken bezig, dus sta open voor aanvullende input en ik zal af en toe een update plaatsen hier.

Laat ik vooropstellen dat ik geen elektricien ben, maar wel in hetzelfde proces zit. Dus vandaar dat ik het bekijk vanuit mijn ervaring tot nu toe (ben al iets verder namelijk), maar ik reageer ook vooral om (als ik iets verkeerds zeg) ik er zelf ook van leer.

Wat mij opvalt is de keuze van 5x10mm2 heen en terug. Ik heb 5x10mm2 vanuit de omvormer terug naar de meterkast, maar van de meterkast naar de omvormer 5x6mm2, omdat hier max 3x25A overheen gaat. Het kan geen kwaad zover ik weet, dus niets om aan te passen, maar dat viel mij op.

Daarnaast de Victron Lynx Distributor. Ik had na veel lezen de Adler EF3 zekeringen gekozen, omdat deze een hogere breaking capacity hebben van 50kA ipv 2kA tov de Victron. Deze ook in 200A genomen. Ik heb wel de Dyness PowerBrick Plus ipv de Deye accu’s, maar zelfde principe. Ook 2, beide leveren 120A.

Dan nog de DC breaker. Ik heb de Beny BDM-250, omdat ik daar een data sheet van kon vinden. Deze is 250A ipv 300A, maar mijn gevoel was beter bij Beny. Wellicht dat ik mijn 12K omvormer wat afknijp naar 230A om deze reden.

Dan, wat ik zelf nog was vergeten, is hoe ik van de Lynx naar de DC breaker & omvormer ging. Daarvoor heb ik nog een Adler EF3 300A besteld, zodat ik daar een zekering heb voor in de busbar. Je kunt hem wellicht aansluiten op de M10 aansluitingen, zonder zekering er tussen, maar dan kun je de kabels niet netjes wegwerken. En om via de normale route op de busbar de kabels aan te sluiten heb je iets nodig wat de plus verbindt. Ik zet er een 300A zekering tussen, zodat ik een stukje veiligheid heb en een verbinding, en omdat mijn DC breaker 250A is, is het een stukje selectiviteit.

[thomvh]

Yaldair schreef op dinsdag 6 oktober 2026 @ 09:20:
Ik kwam er gisteren achter dat we de Deye ook realtime kunnen aansturen zonder naar de TOU (EEPROM) te schrijven. Blijkbaar is er een "remote" optie waar je naar RAM schrijft en dan specifiek hoeveel stroom je naar net/uit net haalt, of uit accu e.d. Ik ga daar deze dagen eens wat meer naar kijken, want dan kan ik mijn eeprom writes nog meer verminderen. Even hoe ik de registers nu in de sunsynk addon heb gezet:

code:

1100  remote mode        0 = uit, 1 = aan (2/3 bestaan, betekenis onduidelijk)
1101  watchdog (s)       65535 = niet gezet
1104  stuurzijde         0 = AC, 1 = accu, 2 = net
1105  accu-submode       2 = vermogen, 3 = SOC, 4 = spanning+stroom, 5 = vermogen+SOC
1106  fasemodus          0 = 3 fasen samen, 1 = per fase
1107/1108  spanning / stroom   x10
1109  accuvermogen       % van nominaal x10 (signed?)
1110  SOC-doel           x10 (uitgelezen: 800 = 80%)
1111-1113  per fase      % x10
1114  totaal netvermogen % x10 (signed?)
1115  max solar          % x10 (65535 = niet gezet)

Voor de sunsynk/deye add-on (mysensors.py) heb ik ze zo gedefinieerd:

code:

from sunsynk.rwsensors import NumberRWSensor, SelectRWSensor
SENSORS += (
    SelectRWSensor(1100, "RC mode", options={0: "Uit", 1: "Aan"}),
    NumberRWSensor(1101, "RC watchdog", "s", min=10, max=600),
    SelectRWSensor(1104, "RC side", options={0: "AC", 1: "Accu", 2: "Net"}),
    SelectRWSensor(1105, "RC battery mode", options={2: "Vermogen", 3: "SOC", 4: "Spanning+stroom", 5: "Vermogen+SOC"}),
    SelectRWSensor(1106, "RC phase mode", options={0: "3 fasen samen", 1: "Per fase"}),
    NumberRWSensor(1109, "RC battery power", "%", -0.1, min=-20, max=20),
    NumberRWSensor(1110, "RC soc", "%", 0.1, min=10, max=100),
    NumberRWSensor(1114, "RC total power", "%", -0.1, min=-20, max=20),
    NumberRWSensor(1115, "RC max solar", "%", 0.1, min=0, max=200),
)

Iemand anders die dit al zo gebruikt? ik moet nog wat testen met precies wat er weggeschreven wordt en hoe het gedrag van de Deye is. AI vond het op akkudoktor forum...bij mij bestaan de registers in ieder geval wel, dus lijkt me dat ik ze moet kunnen gebruiken. Als ik tijd heb even goed gaan uitwerken om zo helemaal dynamisch de deye aan te sturen, i.p.v. ieder kwartier yambms/deye aan te passen.

Moet eens uitvogelen wat Solar Assistant bij mij gebruikt voor aansturing. Want ik kom sommige van die nummers wel tegen in logs.

[bommer]

fmb schreef op maandag 5 oktober 2026 @ 21:02:
[...]

Ik ben met de aanvullende tips nu op dit schema uitgekomen - dank voor de input!
Heb de onderbouwing voor een aantal keuzes/onderdelen hier ook aan toegevoegd. Dat is vooral voor mezelf, maar wie weet heeft iemand er nog wat aan. Mocht er nog wat volgen uit de NEN1010 keuring dan zal ik dat laten weten later.

[Afbeelding]

Ik heb besloten om voor de 12 kW variant te gaan. Dat is voldoende voor ons. En dan voelt het wel logischer voor mij om voor de nieuwe versie te gaan.

Los van het extra vermogen zou de 15kW versie als voordeel hebben dat de 2 accu's hier direct op aangesloten kunnen worden en er geen extra busbar nodig is. Maar het voordeel van de extra busbar is weer iets meer flexibiliteit in de aanleg van de DC kabels (voor beide accu's de kabels even lang houden) en het gemakkelijker kunnen toevoegen van een DC schakelaar. Tot slot is de 15 kW versie +- 300 euro duurder en daarmee ontloopt het elkaar qua kosten nauwelijks

Ik ben nog wel een paar weken bezig, dus sta open voor aanvullende input en ik zal af en toe een update plaatsen hier.

Ik blijf onder de 3m DC kabel, red je dat met je powerin opstelling? Kabel is best duur.

De Deye handleiding geeft aan een aardlekautomaar (RCD) op de load uitgang, jij hebt alleen een B40 automaat opgenomen.

[Bart1201]

Yaldair schreef op dinsdag 6 oktober 2026 @ 09:20:
Ik kwam er gisteren achter dat we de Deye ook realtime kunnen aansturen zonder naar de TOU (EEPROM) te schrijven. Blijkbaar is er een "remote" optie waar je naar RAM schrijft en dan specifiek hoeveel stroom je naar net/uit net haalt, of uit accu e.d. Ik ga daar deze dagen eens wat meer naar kijken, want dan kan ik mijn eeprom writes nog meer verminderen. Even hoe ik de registers nu in de sunsynk addon heb gezet:

code:

1100  remote mode        0 = uit, 1 = aan (2/3 bestaan, betekenis onduidelijk)
1101  watchdog (s)       65535 = niet gezet
1104  stuurzijde         0 = AC, 1 = accu, 2 = net
1105  accu-submode       2 = vermogen, 3 = SOC, 4 = spanning+stroom, 5 = vermogen+SOC
1106  fasemodus          0 = 3 fasen samen, 1 = per fase
1107/1108  spanning / stroom   x10
1109  accuvermogen       % van nominaal x10 (signed?)
1110  SOC-doel           x10 (uitgelezen: 800 = 80%)
1111-1113  per fase      % x10
1114  totaal netvermogen % x10 (signed?)
1115  max solar          % x10 (65535 = niet gezet)

Voor de sunsynk/deye add-on (mysensors.py) heb ik ze zo gedefinieerd:

code:

from sunsynk.rwsensors import NumberRWSensor, SelectRWSensor
SENSORS += (
    SelectRWSensor(1100, "RC mode", options={0: "Uit", 1: "Aan"}),
    NumberRWSensor(1101, "RC watchdog", "s", min=10, max=600),
    SelectRWSensor(1104, "RC side", options={0: "AC", 1: "Accu", 2: "Net"}),
    SelectRWSensor(1105, "RC battery mode", options={2: "Vermogen", 3: "SOC", 4: "Spanning+stroom", 5: "Vermogen+SOC"}),
    SelectRWSensor(1106, "RC phase mode", options={0: "3 fasen samen", 1: "Per fase"}),
    NumberRWSensor(1109, "RC battery power", "%", -0.1, min=-20, max=20),
    NumberRWSensor(1110, "RC soc", "%", 0.1, min=10, max=100),
    NumberRWSensor(1114, "RC total power", "%", -0.1, min=-20, max=20),
    NumberRWSensor(1115, "RC max solar", "%", 0.1, min=0, max=200),
)

Iemand anders die dit al zo gebruikt? ik moet nog wat testen met precies wat er weggeschreven wordt en hoe het gedrag van de Deye is. AI vond het op akkudoktor forum...bij mij bestaan de registers in ieder geval wel, dus lijkt me dat ik ze moet kunnen gebruiken. Als ik tijd heb even goed gaan uitwerken om zo helemaal dynamisch de deye aan te sturen, i.p.v. ieder kwartier yambms/deye aan te passen.

Update: de (vertaalde) Deye-documentatie uit het Akkudoktor-topic gevonden. Correcties:
- 1109 accuvermogen: 100 = 10% van nominaal (12K: 1% = 120 W), positief = ontladen, negatief = laden.
- 1110 doel-SOC x10. Met 1105=5 (vermogen+SOC) laadt/ontlaadt hij met 1109 tot 1110 en stopt dan zelf; klopt de combinatie niet, dan doet hij niets.
- 1106 = 0/1: totaal (1111) of per fase (1112-1114), alleen voor AC- en netmodus. Totaalvermogen is dus 1111, niet 1114.
- 1111 in netmodus: + = afname, - = teruglevering.
- 1100 kent in de Deye-doc alleen 0/1. De "remote mode 2/3" uit de ha-solarman-PR-wiki heeft geen bron; die wiki wijkt vanaf 1106 ook af van de Deye-doc
- Laad/ontlaadvermogen blijft begrensd door de max. accustroom (BMS); in off-grid werkt remote mode niet.

Hm, voor zover ik kan zien zitten deze registers niet in mijn 1-fase omvormer (SUN-6K-SG06LP1-EU-BM2). Hoewel ik wel nog een manier zoek om met deye in contact te komen qua firmware.

-Niels- schreef op maandag 5 oktober 2026 @ 21:29:

Even nieuwsgierig, ik heb mn deye nu net een beetje up and running via DAO. Daar zie ik eigenlijk nooit "halve" belasting. T is of maximaal laden of maximaal ontladen, alleen als de batterij bijna vol of leeg is nog wel eens onder t maximum omdat de energie op in binnen t kwartier.
Verschilt EMHASS hier dusdanig in dat dit een groot issue is?

EMHASS heeft wat opties om dat soort "pendelgedrag" wat temperen door de optimizer meer constraints mee te geven.

[ Voor 8% gewijzigd door Bart1201 op 06-10-2026 17:38 ]

[-Niels-]

Bart1201 schreef op dinsdag 6 oktober 2026 @ 17:35:

EMHASS heeft wat opties om dat soort "pendelgedrag" wat temperen door de optimizer meer constraints mee te geven.

waarom zou dit "aan/uit" niet wenselijk zijn? als t op een gegeven moment verstandig is om 1kwh van t net te importeren dan is t binnen dat kwartier waarschijnlijk ook optimaal voor kwh 2 en 3.

voorbeeld van vandaag, de enige kwartieren dat t vermogen van de deye niet de limiterende factor is zijn de kwartiertjes na 20.15u als ik t vermogen van de batterij beperk bij een lage SOC.
heb je een voorbeeld hoe EMHASS dit doet? ik vind t erg lastig alle half dozijn EMS'en met elkaar te vergelijken en te bepalen welke nou beter/makkelijker/etc is.
Dit zeker ook omdat elk pakket al dan niet zn eigen aansuringsmodule naar een omvormer heeft waardoor t zelf binnen een pakket soms nog niet vergelijkbaar is.

[Yaldair]

Ik heb met claude een testflow opgezet in nodered om het gedrag van de 1000-range modbus registers te testen. En vervolgens heb ik hem gevraagd het samen te vatten en een post te schrijven voor me. Dus hier een domme "plak-actie"

Deye SG0xLP3 "Remote Control Mode" (Modbus 1100+) – testresultaten

Vervolg op mijn eerdere post. Ik heb de registers uitgebreid getest op een SUN-12K-SG05LP3 (MAIN 1175), aangestuurd via de sunsynk/deye HA-add-on (write multiple registers, 0x10) vanuit Node-RED. Accu: 16 kWh LFP, JK-BMS + YamBMS via CAN, Victron SmartShunt als controle. Bron voor de registers: de (vertaalde) Deye-EMS-documentatie uit het Akkudoktor-topic "Remote Control Mode von Deye Hybrid WR (Modbusregister 1100ff)".

Registers (accuzijde, wat ik gebruik)

code:

1100  remote mode        0 = uit, 1 = aan
1101  watchdog (s)       telt af zodra 1100 = 1; bij 0 -> 1100 terug naar 0
1104  stuurzijde         0 = AC, 1 = accu (DC), 2 = net
1105  accustrategie      2 = vermogen (1109), 3 = SOC (1110), 5 = vermogen + SOC
1109  accuvermogen       % x10 van nominaal, signed: + = ontladen, - = laden
1110  doel-SOC           % x10
1111  totaalvermogen     AC: + = uitvoer / net: + = afname, - = teruglevering (niet getest)
1115  max PV (MPPT)      % x10; 1000 of hoger = 0 W! (niet relevant zonder DC-PV)

Let op: de register-wiki in de ha-solarman-PR wijkt vanaf 1106 af van de Deye-doc (en van wat ik uitlees). 1100 = 2/3 staat niet in de Deye-doc.

Wat ik gemeten heb
- Schaal en teken kloppen precies: 1 % = 120 W bij een 12K. +5 % gaf 598 W ontladen, -5 % gaf 600 W laden, ±10 % gaf ±1199 W. Reactie binnen ~5-10 s.
- Watchdog werkt: na afloop valt hij zelf terug naar normaal (bij mij zero-export/zelfconsumptie). De timer start pas bij 1100 = 1, en 1101 telt zichtbaar af.
- Keepalive: alleen 1101 opnieuw schrijven verlengt de timer. 1109 of 1100 opnieuw schrijven doet niets. Met watchdog 120 s en elke ~70 s 1101 herschrijven bleef hij 30 minuten stabiel aan.
- Mode 5 (vermogen + SOC): laden met -5 % tot doel-SOC stopt netjes zelf op het doel. Ontladen ook, maar binnen ~0,5-1 % van het doel knijpt hij af (ik zag ~210 W in plaats van 600 W). Doel 3 % lager gaf gewoon de volle 600 W.
- Tegenstrijdige combinatie (laden gevraagd, doel onder huidige SOC): accu doet niets (~20 W), huis draait volledig op het net. Dus een "hold".
- BMS-limieten blijven leidend: DCL van YamBMS op 10 A gezet en +10 % (1200 W) gevraagd: hij ontlaadt ~580 W. CCL/DCL via CAN begrenzen dus het remote-setpoint.
- Zero-export geldt niet in remote accumodus: 1200 W ontladen bij ~500 W huisverbruik gaf ~700 W teruglevering. Handig voor verkopen, maar alles wat je plan mist, gaat naar/van het net.
- RAM: een register dat elke seconde aftelt kan niet in EEPROM staan. Ik ga ervan uit dat het hele blok in RAM zit (forum zegt dat ook). Mijn uitlezing vóór de eerste write (1104 = AC, 1110 = 80 %) lijken de standaardwaarden.

Hoe ik het ga inzetten
Niet alles via remote. Normale zelfconsumptie en PV-laden blijven native (zero-export op de CT volgt de last per seconde, dat kan een setpoint per kwartier nooit). Remote gebruik ik alleen voor geforceerde stromen uit het EMHASS-plan:
- netladen: 1105 = 5, 1109 = -plan, 1110 = SOC aan einde segment (max 95 %)
- verkopen: 1105 = 5, 1109 = +plan, 1110 = bodem (1 % lager i.v.m. het afknijpen)
- hold: 1105 = 2, 1109 = 0 (en de Deye-doc zegt dat remote off-grid niet werkt, dus bij netuitval neemt de accu het gewoon over)
Watchdog 300 s, keepalive elke minuut op 1101. Valt HA/Node-RED weg, dan staat hij binnen 5 minuten weer native. De TOU-tabel wordt statisch, dus geen EEPROM-writes meer per kwartier (alleen nog bij een rebulk naar 100 %, die laat ik bewust native via de BMS lopen).

Testflow (Node-RED, met read-back per write en automatische veiligheidsstop) deel ik graag als iemand het zelf wil proberen.


---
Einde plak actie: deze remote functie werkt wel handig denk ik. Ik ga nu even in schaduw modus draaien met wat ik al had opgezet, maar daarna kan ik dan mijn TOU tabel standaard op 15% t.soc zetten. En op basis van EMHASS output dan mijn SOC op accu gelijk houden (hold), laten opladen via grid, verkopen aan grid (zonder eeprom writes of sell vinkjes). Het enige moment wanneer ik nog een EEPROM write forceer dan is wanneer ik mijn rebulk actie heb (gepland door yambms). Even een paar dagen aankijken (en eens proberen te verkopen / curtailen van PV) en dan kan ik mijn nodered flows hier ook delen denk ik. (al zijn ze redelijk complex geworden...hoop dat de gedachtegang te volgen is. Ook puur gericht op EMHASS).

[Domba]

@Yaldair Modbus RTU met oa spaanse TOU, die ook deze remote heeft is pas vanaf fw 1140.

Let op: de register-wiki in de ha-solarman-PR wijkt vanaf 1106 af van de Deye-doc (en van wat ik uitlees). 1100 = 2/3 staat niet in de Deye-doc.

Deze zijn wel in Deye-doc aanwezig als je weet wat remote mode 1, 2 of 3 is.
Firmware die geschikt is voor Lora gebruik, gebruikt deze Modbus RTU versie. (fw117x of nieuwere)

[Yaldair]

@Domba thnx. Maar, weet jij dan wat modus 2 en 3 doen bij 1100? 1 is blijkbaar gewoon aan zetten. ZIt nu ook te denken dat mogelijk de cloud-sturing vanuit Deye dit ook gebruikt, i.p.v. de TOU tabel.

[Gieliovd520]

Ik twijfel tussen een systeem bouwen met Deye of Victron, maar ik kom er écht niet uit wat de verschillende Deye modellen nou inhouden en wat het verschil is. Heeft iemand de gouden tip?

Ik zoek een 3 fase model, die mijn 7500 WP panelen gebruikt en 32 kWh accubank gaat laden/ontladen.

Ik zie allemaal series, dan nog versies... SG04, 05- 06? De website van Deye helpt me geen stap verder in vergelijken. Dit topic kom ik qua modellen ook niet echt uit.

[scoobs]

Sg04/05/06 zijn volgens mij allemaal kleine incrementele verschillen, maar ik houd me ook aanbevolen voor iemand die het beter weet.

[Initial G]

de sg06 lijkt wel behoorlijk beter, is vooral kleiner en 40% lichter tov sg05. De 3 fase versies gaan helaas maar tot 8kW.

[arjenhiemstra]

Gieliovd520 schreef op woensdag 7 oktober 2026 @ 09:54:
Ik twijfel tussen een systeem bouwen met Deye of Victron, maar ik kom er écht niet uit wat de verschillende Deye modellen nou inhouden en wat het verschil is. Heeft iemand de gouden tip?

Ik zoek een 3 fase model, die mijn 7500 WP panelen gebruikt en 32 kWh accubank gaat laden/ontladen.

Ik zie allemaal series, dan nog versies... SG04, 05- 06? De website van Deye helpt me geen stap verder in vergelijken. Dit topic kom ik qua modellen ook niet echt uit.

Check naast specs misschien ook support mogelijkheden.
Ik heb sinds aug. een issue met mijn Deye en ben al 1,5 maand met Deye in de weer om het juiste onderdeel hier te krijgen. 3 keer hebben ze een verkeerde PCB opgestuurd en wegens tijdverschil met China gaat er maar 1 mail per dag heen en weer. Behoorlijk frustrerend.

[Jerra]

scoobs schreef op woensdag 7 oktober 2026 @ 10:03:
Sg04/05/06 zijn volgens mij allemaal kleine incrementele verschillen, maar ik houd me ook aanbevolen voor iemand die het beter weet.

Naar wat ik hier lees is de SG05 wel echt heel veel stiller dan de SG04, zo veel dat het mogelijk wel acceptabel is om deze in een (aangebouwde) garage te plaatsen.

Voor mij was dit de reden om de SG04 in een tuinkast buitenshuis te plaatsen, en mijn schoonouders geadviseerd tegen plaatsing in de inpandige schuur, zij geven nog meermaals aan dat advies echt heel erg gewaardeerd te hebben. Het geluid is zoveel dat de 40m extra kabellengte het wel waard was...

Helaas zelf niet in-persoon het geluidsverschil kunnen ervaren, dus ja een incrementele verbetering, maar eentje die mogelijk heel wat andere kosten drukt door flexibelere plaatsingmogelijkheden.

[Develve]

De ventilators en het hoogfrequentte pieptoon van de SG05 is ook niet bepaald stil

[Domba]

Yaldair schreef op woensdag 7 oktober 2026 @ 09:11:
@Domba thnx. Maar, weet jij dan wat modus 2 en 3 doen bij 1100? 1 is blijkbaar gewoon aan zetten. ZIt nu ook te denken dat mogelijk de cloud-sturing vanuit Deye dit ook gebruikt, i.p.v. de TOU tabel.

Ik heb geen technische info wat precies de verschillende remote doen.
Het is net zo goed mogelijk, dat bedoeld is voor verschillende remote app's.
(lastig want het EU-model wordt op 3 verschillende continenten gebruikt)

@Gieliovd520 G04, 05 06 geeft de generatie aan van wanneer het ontwerp is.
Zo is SG04LP3 ontwerp van 2021 en SG05LP3 van 2024, de laatste zitten verbeteringen wat betreft geluid, maar ook nieuwe vereisten van toezichthouders van diverse landen zijn er in verwerkt etc, maar recentere is ook beter geschikt voor M11/M12, zoals half cell PV panelen met 13-14A , waar de oude M5, M6 celtechnologie nog resp met 7-8A en 9-10A was.

[fmb]

reputatio schreef op dinsdag 6 oktober 2026 @ 10:35:
[...]

Wat mij opvalt is de keuze van 5x10mm2 heen en terug. Ik heb 5x10mm2 vanuit de omvormer terug naar de meterkast, maar van de meterkast naar de omvormer 5x6mm2, omdat hier max 3x25A overheen gaat. Het kan geen kwaad zover ik weet, dus niets om aan te passen, maar dat viel mij op.

Een te zware kabel kan geen kwaad een te lichte wel. Mijn onderbouwing was tweeledig:
* Geeft meer opties naar de toekomst toe
* Minder kabelverliezen

Je zet me wel aan het denken: 6mm tussen netaansluiting en Deye en 10mm van Deye naar meterkast is een mooi compromis. Scheelt weer wat in de kosten én biedt ook nog ruimte voor de toekomst. Dus misschien doe ik dat ook wel.

Dan nog de DC breaker. Ik heb de Beny BDM-250, omdat ik daar een data sheet van kon vinden. Deze is 250A ipv 300A, maar mijn gevoel was beter bij Beny. Wellicht dat ik mijn 12K omvormer wat afknijp naar 230A om deze reden.

Ik heb de manual 12K-SG05LP3-EU-SM220260319en erop nageslagen en zie daar ook staan dat er een 300A DC breaker wordt voorgeschreven door Deye. Dus dat was een goed advies dat ik eerder kreeg.

[fmb]

bommer schreef op dinsdag 6 oktober 2026 @ 16:59:
[...]

Ik blijf onder de 3m DC kabel, red je dat met je powerin opstelling? Kabel is best duur.

Ik ga de accu's zo dicht mogelijk bij de Deye zetten. Dus ik hoop max 1m van accu naar busbar en ook max 1 m van busbar naar Deye.

De Deye handleiding geeft aan een aardlekautomaar (RCD) op de load uitgang, jij hebt alleen een B40 automaat opgenomen.

Ik haal wat anders uit de manual. Waar lees jij dit of zijn er verschillen tussen de versies?

In 3.5 staan AC breakers genoemd, en dat zijn geen aardlekautomaten maar "gewone" installatieautomaten.



In 3.8 staat dat als je een aardlekautomaten toepast omdat dit vanuit lokale regelgeving moet, dit minimaal een Type A 300mA moet zijn. Eigenlijk zou ik de aardweerstand moeten laten meten om zeker te stellen dat dit noodzakelijk is.

Hier blijkt ook dat Deye correct Engels gebruikt, dus
* AC breakers = "gewone" installatieautomaten.
* RCD = aardlekautomaten

[bommer]

fmb schreef op woensdag 7 oktober 2026 @ 21:00:
[...]

Ik ga de accu's zo dicht mogelijk bij de Deye zetten. Dus ik hoop max 1m van accu naar busbar en ook max 1 m van busbar naar Deye.


[...]

Ik haal wat anders uit de manual. Waar lees jij dit of zijn er verschillen tussen de versies?

In 3.5 staan AC breakers genoemd, en dat zijn geen aardlekautomaten maar "gewone" installatieautomaten.

[Afbeelding]

In 3.8 staat dat als je een aardlekautomaten toepast omdat dit vanuit lokale regelgeving moet, dit minimaal een Type A 300mA moet zijn. Eigenlijk zou ik de aardweerstand moeten laten meten om zeker te stellen dat dit noodzakelijk is.

Hier blijkt ook dat Deye correct Engels gebruikt, dus
* AC breakers = "gewone" installatieautomaten.
* RCD = aardlekautomaten

[Afbeelding]

Op de eerste 2 aansluitschema’s staand RCD’S getekend. Zowel aan de grid als loadzijde.
Volgens de NEN1010 is het een vast aangesloten toestel, dus is een aardlek niet verplicht.

Ik heb 2 onderverdelers, daar heb ik ook 2 normale automaten op. Toch denk ik wel eens, ik weet waar die kabel loopt. Weet de volgende eigenaar het ook.
Of draait die per ongeluk er een schroef in.
Ik denk dat ik ze toch ga vervangen.

[fmb]

bommer schreef op woensdag 7 oktober 2026 @ 21:44:
[...]

Op de eerste 2 aansluitschema’s staand RCD’S getekend. Zowel aan de grid als loadzijde.
Volgens de NEN1010 is het een vast aangesloten toestel, dus is een aardlek niet verplicht.

Scherp, naar dat aansluitschema had ik nog niet gekeken. Lekker onduidelijk.

[desalnietemin]

Hallo allemaal,

Ik lees dit topic met interesse en wil graag mijn ervaringen delen en een vraag stellen over de aansturing van een Deye-batterijsysteem.

Mijn installatie bestaat uit:

• Een Deye SUN-15K-SG05LP3-EU-SM2.
  Firmware: HMI 1001-C05F, MAIN 2107-1184-1809 en ARC D20A. Deye heeft mijn omvormer bijgewerkt en aangegeven dat dit op dat moment de nieuwste firmware was.
• Circa 23,5 kWp zonnepanelen.
• Drie batterijpakketten met Seplos BMS v3, samen circa 51 kWh.
• Home Assistant met EMHASS voor optimalisatie op basis van Tibber-prijzen, verwachte PV-opwek en verbruik.

SolarAssistant gebruik ik voor omvormermonitoring. Via een aparte Seplos-MQTT-lezer heb ik inmiddels ook alle 48 individuele celspanningen en de packstatussen beschikbaar in Home Assistant.

De batterijsturing loopt via de lokale LSW-5/Solarman-verbinding en de Deye-TOU-tabel. Daar zit mijn belangrijkste uitdaging: EMHASS berekent 48 halfuurperioden, maar de omvormer heeft slechts zes TOU-vakken. Daardoor moeten laad-, ontlaad- en rustvensters worden samengevoegd en gaat een deel van de optimalisatie verloren.

Heeft iemand Deye EMS Remote Mode daadwerkelijk werkend op deze SG05-serie?

Deye heeft mij documentatie gestuurd voor de Remote Mode-registers 1100–1110 via directe RS485. Ik heb SolarAssistant gevraagd deze functie te ondersteunen via hun bestaande USB/RS485-verbinding. Zij hebben mijn voorstel doorgestuurd naar hun ontwikkelaars, maar nog geen implementatie of termijn toegezegd.

Ik ben vooral benieuwd naar praktijkervaringen met Deye EMS Remote mode sturing:

• Welk omvormermodel en welke firmware gebruiken jullie?
• Werkt het enkel via directe RS485, of ook betrouwbaar via LSW-5/Solarman?
• Hoe regelen jullie de periodieke opdrachten, watchdog en terugval bij communicatieverlies?

Mijn uitgangspunt is één systeem dat de opdrachten schrijft, terwijl de BMS-beveiligingen leidend blijven. Ik test graag mee en kan meetgegevens en de ontvangen Deye-documentatie delen.

Groet en dank voor het meedenken

[hannibal2206]

Ik heb een SUN-6K-SG04LP3-EU met daar aan 4 stuks 16kWh Yixiang v2 boxes; gekoppeld aan HA via Solarman app en wifi stick.

In HA (of lokaal op het display kan ik de ToU tabel instellen, maar hierbij lijkt het er op dat ik wel kan opladen (uit PV of grid), maar ontladen met maar ca 80 Watt; waarbij dat grotendeels naar interne consumptie gaat, naar het grid gaat eigenlijk niets. Geen CT klemmen aangesloten, alleen kabel aan Grid. Work mode "export first", Energy pattern "Load first"

Voorbeeld: Prg 5, Charging disabled, SOC 25%, voltage 50,2 V, power 3000 W

Ik heb alle settings al nagelopen maar kan niet de begrenzing vinden die dat veroorzaakt.
Iemand suggestie ?

Edit: als ik parameter "Grid max export power" handmatig op 4000W zet wordt deze na 30 sec vanzelf op 160W gezet ?
De setting 'Export surplus power' komt overeen met wat op de Deye in Work mode scherm instelbaar is.

Er is ook een error "F19 Tz_inleg_Fault" waar ik verder niets over kan vinden ..

[ Voor 31% gewijzigd door hannibal2206 op 10-10-2026 18:16 ]

[dingo35]

@desalnietemin Wat volgens mij iedereen doet is de ToU twee entries geven: 00:00 - 23:55 en 23:55 - 00:00, en dan schrijf je het gewenste gedrag naar de eerste entry.

Maar de 1100-1110 registers zijn wellicht beter geschikt, kun je de info die je kreeg hier delen?

[KVan]

@desalnietemin wat ik doe is alle TOU entries exact op dezelfde tijd instellen (allemaal 01:00-01:00 bijvoorbeeld) dan gebruikt hij enkel het laatste tijdblok en heb je niet de verloren paar minuten.

[Yaldair]

desalnietemin schreef op vrijdag 9 oktober 2026 @ 21:14:

Heeft iemand Deye EMS Remote Mode daadwerkelijk werkend op deze SG05-serie?

Ik ben vooral benieuwd naar praktijkervaringen met Deye EMS Remote mode sturing:

• Welk omvormermodel en welke firmware gebruiken jullie?
• Werkt het enkel via directe RS485, of ook betrouwbaar via LSW-5/Solarman?
• Hoe regelen jullie de periodieke opdrachten, watchdog en terugval bij communicatieverlies?

Mijn uitgangspunt is één systeem dat de opdrachten schrijft, terwijl de BMS-beveiligingen leidend blijven. Ik test graag mee en kan meetgegevens en de ontvangen Deye-documentatie delen.

Groet en dank voor het meedenken

Bij mij lijkt het nu te werken. Alleen gebruik ik nog yambms met target Soc en eoc om niet vol snelheid te laden met PV. Ik gebruik een rs232 over TCP verbinding naar sunsynk addon (ingestoken waar je normaal de wifi module zou plaatsen), ook op de SG05. Fallback is ontladen naar 15% via tou tabel 6 (00:00).

Moet eens kijken if ik de flow in nodered behapbaar en deelbaar kan maken. Emhass berekent alles en op de achterliggende intentie stuur ii aan (verkopen, vol laden, langzaam laden, niks doen, etc).

[CORVETTE]

Ik ben aan het kijken naar een 3 fase hybride omvormer voor 1 accu.

Solis en Deye ben ik nu aan het bekijken van de rond de 10kw laag voltage. Qua specs ontloopt het elkaar niet zoveel. Ik zie wel dat de Solis wat duurder is. Zijn ze ergens nog goedkoop te krijgen ?

[desalnietemin]

Hoi @dingo35 , @KVan en @Yaldair , hartelijk dank voor jullie reactie en het meedenken.
Interessant om dynamische TOU-sturing en echte EMS Remote Mode naast elkaar te kunnen vergelijken.

Bijgesloten de docs die ik van Deye ontvangen heb:

• RS-485 Remote mode
• EMS control English version
• Modbus RTU Three-Phase Energy Storage Communication Protocol V105.4

Omdat daarin enkele tegenstrijdigheden staan, heb ik Deye aanvullende vragen gesteld. Hun technische medewerker heeft per mail bevestigd:

• Remote Mode wordt momenteel ondersteund via een directe RS485-adapter; de LSW-5/Solarman-route wordt daarmee niet bevestigd.
• Voor mijn firmware geldt bij register 1100: 0 = Remote Mode ingaan, 1 = verlaten. Dit wijkt af van de andere registerbeschrijving.
• Batterijvermogensregeling gebruikt 1104 = 1, 1105 = 2 en register 1109, met Modbus-functie 0x10.
• Register 1109 gebruikt stappen van 0,1% van het nominale omvormervermogen: negatief is laden, positief ontladen. Voor mijn 15 kW-model bevestigde Deye −20 ≈ 300 W laden en +20 ≈ 300 W ontladen.
• Voor de watchdog noemt Deye letterlijk “1S refreshing time minimum”. De exacte verversingshandeling is in het antwoord niet verder uitgewerkt.
• Volgens Deye verlaat de omvormer Remote Mode bij wegvallen van de watchdogverversing en hervat hij de bestaande TOU-configuratie. CAN-BMS-limieten en beveiligingen blijven actief; Remote Mode-commando’s zijn volgens hen niet permanent opgeslagen.

@dingo35 @KVan Voor jullie dynamische TOU-aanpak: op welke modellen/firmware werkt dit, welke regel wordt precies aangepast en hoe vaak? Wat gebeurt er als de controller uitvalt: blijft de laatste opdracht staan? En bij de gelijke-tijdenmethode: gebruikt hij ook rond middernacht en na een herstart consequent alleen de laatste regel?

Mijn doel is een fijnmazig EMHASS-plan uitvoeren zonder vooraf alles in zes vaste periodes te persen, maar wel met één commandoschrijver en een geteste terugval. Ik vergelijk graag ervaringen voordat ik mijn huidige productieaansturing verander.

Alvast dank en groet

[ Voor 11% gewijzigd door desalnietemin op 10-10-2026 19:10 ]

[Yaldair]

@desalnietemin ik heb op FW1175 (SG05) van de week al die remote opties geprobeerd. Zie ook mijn post:

Yaldair schreef op dinsdag 6 oktober 2026 @ 23:22:
Registers (accuzijde, wat ik gebruik)

code:

1100  remote mode        0 = uit, 1 = aan
1101  watchdog (s)       telt af zodra 1100 = 1; bij 0 -> 1100 terug naar 0
1104  stuurzijde         0 = AC, 1 = accu (DC), 2 = net
1105  accustrategie      2 = vermogen (1109), 3 = SOC (1110), 5 = vermogen + SOC
1109  accuvermogen       % x10 van nominaal, signed: + = ontladen, - = laden
1110  doel-SOC           % x10
1111  totaalvermogen     AC: + = uitvoer / net: + = afname, - = teruglevering (niet getest)
1115  max PV (MPPT)      % x10; 1000 of hoger = 0 W! (niet relevant zonder DC-PV)

De dynamische TOU tabel werkt trouwens op alle versies volgens mij, maar, dan maak je EEPROM writes. Doe dat dus niet elk kwartier en dan 6+ writes, mag je je omvormer bij 100k-1M writes vervangen(er is iemand die dat had op diysolarforum).

MIjn nodered flow is wel heel dedicated richting mijn usecase (PV via solaredge etc.). Ik moet even kijken hoe ik dat makkelijker te delen maak.

[dingo35]

In de source code van ha-solarman kan ik geen verwijzingen naar de 1100 serie registers vinden, dus dat wordt een PR aanmaken; helaas kan ik de komende maanden niet testen...

[Noordhorn]

Lees hier regelmatig over TOU tabellen.

Maak hier zelf helemaal geen gebruik van TOU tabellen (tenminste geen waarden of tijden). Heb HomeAssistant met EMHASS draaien met een schuivend horizon (max 33 uur vooruit, zolang er prijzen bekend zijn). Elk kwartier stuurt die de gegevens naar EMHASS

Verder gebruik ik een automation die de waarden van EMHASS omzet naar de de schakelaars, batterijen stromen en select mode van de Deye.

Schakelaar: "Grid charge", "TIME Of Use" en "Solar sell"
Stromen: Charge max, Discharge max en Grid charge (max)
Limit mode: Zero export to CT en Selling first


Zo zal het vandaag bij mij draaien





Verder heb ik er een aanpassing inzitten als de auto gaat laden via TIBBER (mag dan niet gaan ontladen en op dat moment wordt eigen gebruik ook van het net getrokken, bij laden wordt de maximum laadstroom gewijzigd van de Deye). Dit werkt nog niet optimaal, pakt dan ook volledig de PV opbrengst......(misschien is dat in 2027 wel verstandig)

[bommer]

dingo35 schreef op vrijdag 9 oktober 2026 @ 22:57:
@desalnietemin Wat volgens mij iedereen doet is de ToU twee entries geven: 00:00 - 23:55 en 23:55 - 00:00, en dan schrijf je het gewenste gedrag naar de eerste entry.

Maar de 1100-1110 registers zijn wellicht beter geschikt, kun je de info die je kreeg hier delen?

Ik schrijf modbus integraties voor Home Assistant, zou ook graag dat stukje register lijst willen hebben.
Doel is om aankomende winter (als mijn eigen 15K in bedrijf is) een intergratie te maken speciaal voor Deye
En de verschillende inverters, als eerste de 3F 15K en 12K versie en dan uitbreiden naar ook de enkelfase.

[genesisfm]

Noordhorn schreef op zondag 11 oktober 2026 @ 00:34:
Lees hier regelmatig over TOU tabellen.

Maak hier zelf helemaal geen gebruik van TOU tabellen (tenminste geen waarden of tijden). Heb HomeAssistant met EMHASS draaien met een schuivend horizon (max 33 uur vooruit, zolang er prijzen bekend zijn). Elk kwartier stuurt die de gegevens naar EMHASS

Verder gebruik ik een automation die de waarden van EMHASS omzet naar de de schakelaars, batterijen stromen en select mode van de Deye.

Schakelaar: "Grid charge", "TIME Of Use" en "Solar sell"
Stromen: Charge max, Discharge max en Grid charge (max)
Limit mode: Zero export to CT en Selling first


Zo zal het vandaag bij mij draaien
[Afbeelding]

[Afbeelding]


Verder heb ik er een aanpassing inzitten als de auto gaat laden via TIBBER (mag dan niet gaan ontladen en op dat moment wordt eigen gebruik ook van het net getrokken, bij laden wordt de maximum laadstroom gewijzigd van de Deye). Dit werkt nog niet optimaal, pakt dan ook volledig de PV opbrengst......(misschien is dat in 2027 wel verstandig)

Ik doe dit op dezelfde manier, ik heb er een software laag overheen liggen die deze informatie wegschrijft.

Bij mijn loopt het zo: EMS -> Home assistant -> RS485 -> Deye en dezelfde weg terug.

Dit werkt perfect, zo voer ik trouwens ook mijn batterij onderhoud uit. Dus de 2 accupacks van elkaar gaan afwijken (SOC) en/of een keer in de x dagen dan laad hij eens naar de 100% om een calibratie uit te voeren.

[timbak02]

Hallo allemaal,

Ik lees sinds kort ook mee in dit topic en heb onlangs een SUN-8K-SG04LP3 icm 2× Rosen LFP48V200AH aangesloten. Maar loop tegen een probleem aan in de "Zero Export to CT" work mode

Setup

• Deye SUN-8K-SG04LP3-EU (3-fase hybride)
• 2 strings van 10 zonnepanelen, elk op een eigen MPPT (10× 340 Wp en 10× 400 Wp)
• 2× Rosen LFP48V200AH parallel
• Netmeting via Eastron SDM630 Modbus V2 (adres 1, 9600 baud, 8N1), RS485-kabel van ca. 10 m, geen afsluitweerstand
• Geen CT-klemmen, LOAD-poort (backup) niet in gebruik
• Grid code VDE4105
• Phase type 0/240/120 (installatie heeft een omgekeerde fasevolgorde)

Probleem

In System Work Mode "Zero Export to CT" blijft de Deye off-grid: de relais klikken, maar hij koppelt niet aan het net. De grid status geeft in die mode ook "Off-Grid" aan (zie foto). Er komt geen alarm en er staat geen foutcode in de log. Zet ik hem op "Zero Export to Load", dan koppelt hij gewoon aan.



Wat ik al gecontroleerd heb

• Fasen en stroomrichting kloppen: met verbruikers op L2 en L3 komen de waarden per fase en met het juiste teken overeen tussen de Eastron, het Deye-display en de P1 van de slimme meter.
• Modbus-instellingen op de Eastron staan goed.
• A/B zit goed: als ik ze omwissel, krijg ik een alarm.
• In "Zero Export to Load" laat de Deye alle drie de CT-waarden live en correct zien.

Wat opvalt (zie filmpje)

In het filmpje zie je het Grid-scherm in "Zero Export to CT" en daarna de overgang naar "Zero Export to Load" (de klik bij ~19 s).

• -In Zero Export to CT heeft steeds maar één fase een waarde, de andere twee staan op 0 W. Bijvoorbeeld CT2 = 1241 W met CT1/CT3 = 0 W, en een paar seconden later CT3 = 2224 W met CT1/CT2 = 0 W. De 1241 W blijft ruim 15 seconden tot op de watt gelijk, dus het lijkt bevroren of oude data.
• Na de overstap naar Zero Export to Load hebben alle drie de fasen tegelijk een waarde, en die schommelen gewoon (bijv. 320 / 1270 / 2250 W). Dat klopt met de Eastron en de P1.

Dus: dezelfde meter, kabel en instellingen werken in Load-mode prima, maar in CT-mode komt de meterdata maar half binnen en geeft hij Off-Grid aan.

Mijn vragen

• Herkent iemand dit, eventueel in combinatie met phase type 0/240/120 of een Eastron SDM630?
• Is er een firmwareversie bekend die dit oplost?

Alvast bedankt!

[ Voor 4% gewijzigd door timbak02 op 11-10-2026 18:21 ]

[Domba]

@timbak02 Ik herken het niet.
Misschien overbodige vraag, je hebt op "advanced function" pagina wel een vinkje staan bij "EX_meter for CT" vanwege gebruik van een Eastron?

[timbak02]

Domba schreef op zondag 11 oktober 2026 @ 11:02:
@timbak02 Ik herken het niet.
Misschien overbodige vraag, je hebt op "advanced function" pagina wel een vinkje staan bij "EX_meter for CT" vanwege gebruik van een Eastron?

Die is goed geconfigureerd en de waarden komen goed door in "Zero export to load" maar in "Zero export to CT" komen die waarden dus niet goed door, althans, die worden niet goed getoond.

[desalnietemin]

@dingo35 @Yaldair dank voor jullie reacties!

Er bestaat al een PR #978 — Added remote control registers for Deye P3, die nog openstaat. Ik heb daar inmiddels gereageerd, de drie ontvangen Deye-documenten toegevoegd en aangeboden mee te testen.

Er zijn concrete verschillen tussen de PR en mijn Deye-documentatie, bijvoorbeeld:

• 1110: batterij-doel-SOC in mijn documentatie, maar Reactive power control mode in de PR.
• 1111: totaal AC-vermogensdoel tegenover Power factor setpoint.
• 1115: maximaal PV-vermogen tegenover een Volt-VAR-spanningspunt.

Ook spreken de Deye-documenten elkaar tegen over de aan/uit-waarden van 1100. Ik heb de PR-auteur daarom gevraagd welke protocol-/firmwarevariant zijn uitgangspunt is.

@dingo35 De generieke acties solarman.read_holding_registers en solarman.write_multiple_registers zijn bij mij al beschikbaar onder Ontwikkelaarstools → Acties, met een vrij registeradres. Specifieke Remote Mode-entiteiten ontbreken, maar generieke registeraanvragen kunnen dus wel worden verstuurd.

Deye antwoordde op mijn vraag over Remote Mode via de lokale LSW-5: “Currently only supported by RS485 adapter”. Dat bevestigt ondersteuning voor een directe adapter, maar bewijst niet dat de loggerroute technisch onmogelijk is. De LSW-5 is immers ook een netwerk-naar-seriële brug, alleen met eigen firmware en het Solarman-protocol.

@Yaldair Je schreef eerder dat je RS232-over-TCP gebruikt op de aansluiting waar normaal de WiFi-dongle zit. Vervang je daarmee de originele logger? Welk merk/type adapter gebruik je, en schrijf je via de Sunsynk-addon of rechtstreeks vanuit Node-RED? Is dat Modbus RTU over TCP of Modbus TCP?

Heb je Remote Mode ook via de originele LSW-5 op poort 8899 getest? Daarnaast ben ik benieuwd hoe je de watchdog ververst en of terugval naar TOU bij verbindingsverlies daadwerkelijk getest is.

Ik wil gezamenlijk testen op mijn SUN-15K-SG05LP3-EU-SM2 — HMI 1001-C05F, MAIN 2107-1184-1809, ARC D20A. Eerst mapping en uitlezen controleren, daarna eventueel begeleide nul-/laagvermogentests met readback, werkelijk batterijvermogen en veilige terugval. Met één commandoschrijver en zonder ongewenst netladen of batterij-export.

Een minimaal voorbeeld van je flow zou daarbij erg helpen!

Thanks all

[Domba]

@timbak02 Voor "zero export to load" wordt de externe CT's/Modbus meter niet gebruikt maar de interne LD CT's-set voor de interne regeling en ext CT's/modbus meter is slechts voor monitoring.
Voor "zero export to CT" wordt de interne set niet gebruikt maar wel de externe CT-set/modbus meter voor beide.
Wat ik niet totaal niet kan plaatsen is "off-grid" flag, als of CT/modbus meter niet gezien wordt (geen vinkje EXT-meter) of stekker op verkeerde connector (meter-485 vs Modbus), waardoor gedeelt gebruik (monitoring & regeling) niet goed gaat omdat die bezet is door de andere.
(vergelijkbaar met RTU-modbus topologie RS-485 vs RS232)

Want ik ga er niet vanuit dat je een SUN-8K-SG04LP3-EU hebt met serienummer die lager begint met 2206 of icm met FW lager (2e set van 4 cijfers) dan FW 2005-1116, waarvoor de communicatie aansluit manier anders is.

[timbak02]

Domba schreef op zondag 11 oktober 2026 @ 13:51:
@timbak02 Voor "zero export to load" wordt de externe CT's/Modbus meter niet gebruikt maar de interne LD CT's-set voor de interne regeling en ext CT's/modbus meter is slechts voor monitoring.
Voor "zero export to CT" wordt de interne set niet gebruikt maar wel de externe CT-set/modbus meter voor beide.
Wat ik niet totaal niet kan plaatsen is "off-grid" flag, als of CT/modbus meter niet gezien wordt (geen vinkje EXT-meter) of stekker op verkeerde connector (meter-485 vs Modbus), waardoor gedeelt gebruik (monitoring & regeling) niet goed gaat omdat die bezet is door de andere.
(vergelijkbaar met RTU-modbus topologie RS-485 vs RS232)

Want ik ga er niet vanuit dat je een SUN-8K-SG04LP3-EU hebt met serienummer die lager begint met 2206 of icm met FW lager (2e set van 4 cijfers) dan FW 2005-1116, waarvoor de communicatie aansluit manier anders is.

Juist in "zero export to load" worden eastron read values goed weergegeven.

Eastron RJ45 plug zit in de Meter-485 aansluting, ernaast zit nog een 'MODEBUS". Als ik de connector eruit haal dan krijg ik wel meteen een alarm. Wat betekend dat dat de meter als zodanig "herkend" word zou ik zeggen. Maar het off grid gaan in workmodus "Zero export to CT" vond je ook vreemd?? Het relais hoor dan wel periodiek schakelen en soms staat die heel even in "Grid mode"


Serie nummer begint met 2303, Omvormer heeft wel 1,5 jaar in een opslag gelegen en heeft nog de af fabriek software. Ik heb al een berichtje gedaan richting Deye voor een remote update.

Thxz voor je antwoord. Geeft even weer stof tot nadenken

[Domba]

@timbak02 Heeft wel iets langer in de opslag gelegen in een hoekje, de eerste 6 cijfers van serie nummer zijn de produktiedatum.
De fabrieks firmware zal dan zeer waarschijnlijk 2005-1135-xxxx of 2005-1140-xxxx met een HMI C03E firmware die een onbekende vreemde bug heeft. (ik tip op de laatste)
(onbekend omdat de HMI versie al teruggetrokken was, voordat de containers in EU waren door deze FW icm de oudere C037 te gebruiken.

[timbak02]

Domba schreef op zondag 11 oktober 2026 @ 19:01:
@timbak02 Heeft wel iets langer in de opslag gelegen in een hoekje, de eerste 6 cijfers van serie nummer zijn de produktiedatum.
De fabrieks firmware zal dan zeer waarschijnlijk 2005-1135-xxxx of 2005-1140-xxxx met een HMI firmware die een onbekende vreemde bug heeft. (ik tip op de laatste)
(onbekend omdat de HMI versie al teruggetrokken was, voordat de containers in EU waren door deze FW icm de oudere C037 te gebruiken.

Firmware: HMI 1001-C031, MAIN 2005-1128-1807

[Domba]

timbak02 schreef op zondag 11 oktober 2026 @ 19:04:
[...]
Firmware: HMI 1001-C031, MAIN 2005-1128-1807

Ik heb die versie voor SG04LP3 12K getest met CT's en niets zo bijzonder opgemerkt, alleen dat de regelruis wat groter is dan van voorjaar 2023 C037/ FW1135

[timbak02]

Domba schreef op zondag 11 oktober 2026 @ 19:08:
[...]


Ik heb die versie voor SG04LP3 12K getest met CT's en niets zo bijzonder opgemerkt, alleen dat de regelruis wat groter is dan van voorjaar 2023 C037/ FW1135

Deze versie had nog geen ferriet ringen.... Aangezien je het over ruis hebt

[Domba]

timbak02 schreef op zondag 11 oktober 2026 @ 19:14:
[...]
Deze versie had nog geen ferriet ringen.... Aangezien je het over ruis hebt

Met regelruis bedoel ik wat anders dan EMC, ramprate en reactietijd.
Als je een belasting bijv een 2kW waterkoker inschakelt, duurt het even voor hybride erop reageert en aantal seconden voor de volledige 2kW uit de accu komt.
Het omgekeerde heb je bij uitschakeling van een belasting, dat je van 0,1 tot enige seconden overshoot hebt.
Meer recente slimme meters zoals DSMR 5.0 die per seconden meten zien die pieken en heb je 1-2kWh per dag zowel ongewenste afname als teruglevering met FW112x
Terwijl met FW1135 uit zelfde periode, dat <0,5kWh is(ca 12-14kWh/mnd)

[Yaldair]

@desalnietemin

Ik heb deze RS232 kabel gekocht: https://www.amazon.nl/dp/B00A6GIV9K
Die heb ik ingestoken i.p.v. de normale datalogger. (reden waarom: mijn rs485 verbinding had te veel last van ruis op de lijn).
Ik had nog deze waveshares liggen: https://www.amazon.nl/Wav...485-422-POE/dp/B0BN61G4VF

Dus, de RS232 in die waveshare gestoken. Vervolgens de sunsynk addon verbinding laten maken met die waveshare (tcp verbinding met ip nummer van de waveshare, port 502). In de sunsynk addon kan je dan extra parameters toevoegen in mysensors.py
ik gebruik dus geen solarman o.i.d. Zie ook niet meteen de meerwaarde. Het is allemaal modbus, dus of dat via rs232 of rs485 maakt niet uit. De datalogger zet ook alles om in modbus (naar mijn weten).

Omdat mijn eigen flow niet te delen was (te specifiek) heb ik Claude wat "universele flows" laten maken. Deze haalt voorspellingen op uit EMHASS, bepaalt intentie, en stuurt op basis daarvan een commando naar de Deye. Ik heb een repo geopend. Daar staat ook een testflow op waarmee je alle modbus addressen kan uitproberen. Claude heeft alles gesimuleerd en zegt dat het werkt .

Bij mij werkt het en gebruik ik het nu continue.

https://github.com/yaldair/deye-control

[timbak02]

Domba schreef op zondag 11 oktober 2026 @ 19:30:
[...]


Met regelruis bedoel ik wat anders dan EMC, ramprate en reactietijd.
Als je een belasting bijv een 2kW waterkoker inschakelt, duurt het even voor hybride erop reageert en aantal seconden voor de volledige 2kW uit de accu komt.
Het omgekeerde heb je bij uitschakeling van een belasting, dat je van 0,1 tot enige seconden overshoot hebt.
Meer recente slimme meters zoals DSMR 5.0 die per seconden meten zien die pieken en heb je 1-2kWh per dag zowel ongewenste afname als teruglevering met FW112x
Terwijl met FW1135 uit zelfde periode, dat <0,5kWh is(ca 12-14kWh/mnd)

Ok het is opgelost.... Ooit wel een gehoord van linksdraaiend en rechtsdraaiend net aansluiting? Ik iig niet, dat is meer installatie vaktermen. Maar dit is wel het probleem dat mijn versie van Deeye icm met firmware waarschijnlijk niet om kan gaan met "linksdraaiende" stroomaanslutingen.

Het net komt bij mij linksdraaiend binnen. Mijn eigen bekabeling heb ik gecontroleerd en die is kleur-op-kleur correct, dus de verwisseling zit al bij de aansluiting van de netbeheerder. Met Fase Type 0/240/120 draait de Deye in Zero Export To Load prima, maar in CT-modus met externe meter dus niet.

Oplossing
L2 en L3 fysiek omgewisseld op de grid-klemmen van de Deye en Fase Type terug naar 0/120/240. Daarna werkt Zero Export To CT direct: hij blijft on-grid en de accu levert vermogen.
Claude kan je soms best wel eens op weg helpen

@Domba bedankt voor het meedenken iig

[Yaldair]

@timbak02 ik heb een SG05, maar ook een eastron bij GRID_CT en een linksdraaiend veld.

Ik had toen in de Deye settings het veld "rechtsdraaiend" gezet, en dan kreeg ik geen grid fault. Nu heb ik later maar heel mijn huis rechtsdraaiend veld "gegeven" (oftewel: direct na de hoofdschakelaar fase 1 en 3 omgedraaid waar ze de eastron in gaan). En toen het veld weer goed gezet bij de Deye (linksdraaiend). Oftewel: Huis rechtdraaiend komt niet overeen met Deye rechtsdraaiend. Dan had ik geen grid faults meer. Volgens mij zijn er meer in dit topic dat bij de Deye een andere draairichting van het veld moesten geven dan ze daadwerkelijk echt hebben.

Bij zero to load doet de deye volgens mij niks met de CT values. Mogelijk dat het daarom ook "goed" werkt. Ik kreeg heel soms meter errors, maar dan komen die in settings --> info --> log te staan. Dus dat geeft aan of je rs485 signaal wel goed loopt.

In principe heb je nu gewoon op de Deye lokaal een rechtsdraaiend veld gemaakt. Maar, dan levert hij dus terug over een andere fase dan dat hij verwacht. Lijkt me niet dat dat goed gaat.

Gedachte-oefeninkje: stel, je had net als bij mij de fases gewisseld voordat het je huis in gaat (dus, bij de Eastron) dan creer je daar (en voor de rest van het huis) een rechtsdraaiend veld. (let op: als je WP hebt e.d. kan je dit niet zomaar doen). Dan had de Deye ook een rechtstdraaiend veld gezien (als je de aders had aangesloten zoals voor je "fix"). Maar, wat hij ziet bij de CT meter e.d. zou dan nog steeds niet goed matchen, want er is in principe niks veranderd. Mogelijk dus alleen de faserichting binnen de settings. Die zou je dan moeten omwisselen.

Als dat het niet fixt: dan is er ergens toch een draad omgewisseld...kan dit? je weet zeker dat je L1 draad ook R is? en L2 = S, L3=T

edit:
dubbel-check gedaan: mijn Deye staat nu inderdaad op 0/240/120 terwijl hij een rechtsdraaiend veld binnen krijgt.

[ Voor 3% gewijzigd door Yaldair op 11-10-2026 22:01 ]

[timbak02]

Yaldair schreef op zondag 11 oktober 2026 @ 21:57:
@timbak02 ik heb een SG05, maar ook een eastron bij GRID_CT en een linksdraaiend veld.

Ik had toen in de Deye settings het veld "rechtsdraaiend" gezet, en dan kreeg ik geen grid fault. Nu heb ik later maar heel mijn huis rechtsdraaiend veld "gegeven" (oftewel: direct na de hoofdschakelaar fase 1 en 3 omgedraaid waar ze de eastron in gaan). En toen het veld weer goed gezet bij de Deye (linksdraaiend). Oftewel: Huis rechtdraaiend komt niet overeen met Deye rechtsdraaiend. Dan had ik geen grid faults meer. Volgens mij zijn er meer in dit topic dat bij de Deye een andere draairichting van het veld moesten geven dan ze daadwerkelijk echt hebben.

Bij zero to load doet de deye volgens mij niks met de CT values. Mogelijk dat het daarom ook "goed" werkt. Ik kreeg heel soms meter errors, maar dan komen die in settings --> info --> log te staan. Dus dat geeft aan of je rs485 signaal wel goed loopt.

In principe heb je nu gewoon op de Deye lokaal een rechtsdraaiend veld gemaakt. Maar, dan levert hij dus terug over een andere fase dan dat hij verwacht. Lijkt me niet dat dat goed gaat.

Precies dat is wat ik ook gedaan heb, setting op "0/240/120" geset en alarm was weg. Maar "Zero export to CT" werkt dus dan niet met een linksdraaiende setting, althans met mijn oude firmware versie.

Het feit dat je op een andere fase terugleverd maakt niks uit omdat je intern tussen de fase "saldeert"

Ik zal eens in dit topic zoeken op de draairichting. Zal Liander komen als je komt met deze constatering?

Gedachte-oefeninkje: stel, je had net als bij mij de fases gewisseld voordat het je huis in gaat (dus, bij de Eastron) dan creer je daar (en voor de rest van het huis) een rechtsdraaiend veld. (let op: als je WP hebt e.d. kan je dit niet zomaar doen). Dan had de Deye ook een rechtstdraaiend veld gezien (als je de aders had aangesloten zoals voor je "fix"). Maar, wat hij ziet bij de CT meter e.d. zou dan nog steeds niet goed matchen, want er is in principe niks veranderd. Mogelijk dus alleen de faserichting binnen de settings. Die zou je dan moeten omwisselen.

Als dat het niet fixt: dan is er ergens toch een draad omgewisseld...kan dit? je weet zeker dat je L1 draad ook R is? en L2 = S, L3=T?

Ik heb verschillende fase belast en gecontrolleerd met mijn P1 reader icm DSRM software in HA en de lezing op de Eastron en de waarden in de Deye die komen overeen. De aanmane is dus dat het voor de "Slimme meter" L2 en L3 omgedraaid zijn.

[Yaldair]

timbak02 schreef op zondag 11 oktober 2026 @ 22:11:
[...]

Precies dat is wat ik ook gedaan heb, setting op "0/240/120" geset en alarm was weg. Maar "Zero export to CT" werkt dus dan niet met een linksdraaiende setting, althans met mijn oude firmware versie.

Het feit dat je op een andere fase terugleverd maakt niks uit omdat je intern tussen de fase "saldeert"

Ik zal eens in dit topic zoeken op de draairichting. Zal Liander komen als je komt met deze constatering?


[...]

Ik heb verschillende fase belast en gecontrolleerd met mijn P1 reader icm DSRM software in HA en de lezing op de Eastron en de waarden in de Deye die komen overeen. De aanmane is dus dat het voor de "Slimme meter" L2 en L3 omgedraaid zijn.

Het kan zijn dat je op de slimme meter linksdraaiend binnen krijgt. Maar, dat ze de fases gewisseld hebben bij je hoofdgroep. En jij gaat van daaruit verder. Want...het boeit eigenlijk niet wat er op welke fase gebeurd. Dus er is geen garantie dat iets dat op je slimme meter op L1 binnenkomt,, ook de 1e draad is bij je hoofdgroep.

Je echte test moet eigenlijk zijn: kijk op display van je Eastron wat de vermogens zijn per fase. En vergelijk DIE met de DSMR meter. Dat zou in ieder geval overeen moeten komen. Of, zoals bij mij: nu expres niet meer. LIander zal hiervoor niet langskomen (en is ook te duur, en niet nodig).
(alles wat ik uitlees met de P1 meter moet ik nu wel L1 en L3 omdraaien in mijn geval. Maar, dat doe ik dan op de P1 meter data). De eastron meet wat mij betreft de echte waarheid.

je hebt verder gekleurde bedrading (bruin, zwart, grijs) zodat je zeker weet dat vanaf de eastron alles aan dezelfde fase hangt?

[dingo35]

timbak02 schreef op zondag 11 oktober 2026 @ 22:11:
[...]
Het feit dat je op een andere fase terugleverd maakt niks uit omdat je intern tussen de fase "saldeert"

Daar zou ik niet op durven vertrouwen; het gaat sowieso fout als je asymmetric feeding aanzet, je wil niet dat als iemand/iets dat later aanzet, je hele rare regeleffecten gaat krijgen....

[HarDus]

Consumentengarantie van Liander? Welke levensduur mag je van een aansluiting verwachten? Een half huis-leven? 100+jaar/2? Of mag je gewoon verwachten dat het goed zit?

Liander: 3x25A aanleggen kost €368,77; Laagste tarief aan huis is €304,22. Herstel draairichting zou voor minder moeten kunnen. Verzegelen is nog wel het meeste werk.

[ Voor 8% gewijzigd door HarDus op 11-10-2026 22:42 ]

[dingo35]

Enexis verving onlangs mijn geliefde ferrarismeter; geen draairichtingsmeter bij zich, "die blijft ongewijzigd"; dus als hij linksdraaiend was, jammer dan....

Maar zo lang je je P1 info van je meter niet gebruikt, kun je bij je hoofdschakelaar, vóór je Eastron/CT klemmen, zelf wisselen zo veel je wil...

[Initial G]

Ik had dit issue ook paar jaar geleden, p1meter fasen klopten niet met groepenkast (incl enphase) en linksdraaiend qua veld. Gedoe met Stedin gehad. Lang verhaal kort, verwacht hier geen hulp van.

Vanwege de al ingedeelde groepenkast en een licht eigenwijze inslag heb ik toen met gepaste bescherming aan de gridkant van de hoofdschakelaar kunnen aanpassen, tijdens een stroomstoring (uitval) van een paar uur lang. Dit is echter niet aan te raden gezien het gevaar.

Je kunt de fasen ook direct na de hoofdschakelaar omwisselen zoals je ze wil hebben, dan klopt het vanaf daar ook met de p1 meter en kun je gewoon veilig werken.

[bommer]

timbak02 schreef op zondag 11 oktober 2026 @ 21:23:
[...]


Ok het is opgelost.... Ooit wel een gehoord van linksdraaiend en rechtsdraaiend net aansluiting? Ik iig niet, dat is meer installatie vaktermen. Maar dit is wel het probleem dat mijn versie van Deeye icm met firmware waarschijnlijk niet om kan gaan met "linksdraaiende" stroomaanslutingen.

Het net komt bij mij linksdraaiend binnen. Mijn eigen bekabeling heb ik gecontroleerd en die is kleur-op-kleur correct, dus de verwisseling zit al bij de aansluiting van de netbeheerder. Met Fase Type 0/240/120 draait de Deye in Zero Export To Load prima, maar in CT-modus met externe meter dus niet.

Oplossing
L2 en L3 fysiek omgewisseld op de grid-klemmen van de Deye en Fase Type terug naar 0/120/240. Daarna werkt Zero Export To CT direct: hij blijft on-grid en de accu levert vermogen.
Claude kan je soms best wel eens op weg helpen

@Domba bedankt voor het meedenken iig

Je kan dit eigenlijk alleen met een speciale meter of een duspol vast stellen.
Het vector veld in de elektro techniek draait linksom
Je krijgt dan 0|-120|-240 voor een rechts draaien veld. -120 is +240 als je vector rechts om gaat.
De Chinezen kijken hier iets anders tegen aan.
Een rechts draaiend veld is in de Deye dus 0|240|120

[bommer]

Ik wat op merkingen voorbij komen dat het niet boeit hoe het binnenkomt.
Maar pas op
Met motoren, als die in eens de andere kant op draaien, krijg je gevaarlijke situaties.
Ik heb ik het verleden best wel wat bouw aansluitingen aangesloten. En je wilt niet een links draaiend veld op je zaagmachine.

[Yaldair]

bommer schreef op maandag 12 oktober 2026 @ 07:33:
Ik wat op merkingen voorbij komen dat het niet boeit hoe het binnenkomt.
Maar pas op
Met motoren, als die in eens de andere kant op draaien, krijg je gevaarlijke situaties.
Ik heb ik het verleden best wel wat bouw aansluitingen aangesloten. En je wilt niet een links draaiend veld op je zaagmachine.

Daarom dat ik ook aangaf dat als je een WPhebt je ook moet oppassen. Compressor verwacht soms ook een rechtsdraaiend veld (bij mij was het bij de krachtgroep weer omgedraaid t.o.v. wat er binnenkomt).
Wel benieuwd of @timbak02 gelijke fase belasting ziet op de Eastron (via schermpje) en de DSMR meter.

[jadjong]

Je zou denken dat apparatuur die afhankelijk is van een specifiek draaiveld iets ingebouwd heeft wat dat controleert. De PV omvormers in ieder geval wel.

[Daan_96]

In de praktijk wordt in het veld vaak gekeken of de motoren de goede kant opdraaien en zo niet dan worden er op de motor zelf even 2 fases omgedraaid.
Neemt niet weg dat de basis gewoon goed hoort te zijn en dus volgens mij rechtsdraaiend

[bommer]

jadjong schreef op maandag 12 oktober 2026 @ 09:49:
Je zou denken dat apparatuur die afhankelijk is van een specifiek draaiveld iets ingebouwd heeft wat dat controleert. De PV omvormers in ieder geval wel.

Zelfs de grote warmtepompen van Carrier enzo waar ik mee werk niet. Verantwoordelijkheid van de installateur en inbedrijfsteller.

[bommer]

Daan_96 schreef op maandag 12 oktober 2026 @ 11:10:
In de praktijk wordt in het veld vaak gekeken of de motoren de goede kant opdraaien en zo niet dan worden er op de motor zelf even 2 fases omgedraaid.
Neemt niet weg dat de basis gewoon goed hoort te zijn en dus volgens mij rechtsdraaiend

Eerst meten, bij een warmtepomp ben te laat en is de compressor terziele.

[Daan_96]

bommer schreef op maandag 12 oktober 2026 @ 11:38:
[...]

Eerst meten, bij een warmtepomp ben te laat en is de compressor terziele.

Eens, ik doelde ook meer op zaagmachines ect wat iets daarvoor werd benoemd.

[timbak02]

Yaldair schreef op maandag 12 oktober 2026 @ 09:38:
[...]

Daarom dat ik ook aangaf dat als je een WPhebt je ook moet oppassen. Compressor verwacht soms ook een rechtsdraaiend veld (bij mij was het bij de krachtgroep weer omgedraaid t.o.v. wat er binnenkomt).
Wel benieuwd of @timbak02 gelijke fase belasting ziet op de Eastron (via schermpje) en de DSMR meter.

Gisteren een snelle test gedaan met belastingen op verschillende fasen. P1 data mbv DSMR -> Eastron en daar lijken de fasen gelijk te zijn. Mijn vermoeden is dat voor de slimme meter L2 en L3 zijn omgedraaid.

[timbak02]

bommer schreef op maandag 12 oktober 2026 @ 06:58:
[...]
Je kan dit eigenlijk alleen met een speciale meter of een duspol vast stellen.
Het vector veld in de elektro techniek draait linksom
Je krijgt dan 0|-120|-240 voor een rechts draaien veld. -120 is +240 als je vector rechts om gaat.
De Chinezen kijken hier iets anders tegen aan.
Een rechts draaiend veld is in de Deye dus 0|240|120

Klopt dat heb ik idd ook gelezen, maar het heeft er alle schijn van. Maar wat je zegt over het rechtdraaiend veld, begrijp ik niet helemaal. Ik heb nu L2 en L3 verwisseld zodat ik richting de deye een rechtsdraaiend veld heb gecreerd en ik heb de grid setting van de deye op 0/120/240 wat ik lees is dat een een rechtsdraaiend veld.

[bommer]

timbak02 schreef op maandag 12 oktober 2026 @ 18:41:
[...]

Klopt dat heb ik idd ook gelezen, maar het heeft er alle schijn van. Maar wat je zegt over het rechtdraaiend veld, begrijp ik niet helemaal. Ik heb nu L2 en L3 verwisseld zodat ik richting de deye een rechtsdraaiend veld heb gecreerd en ik heb de grid setting van de deye op 0/120/240 wat ik lees is dat een een rechtsdraaiend veld.

Je hebt nu een links draaiend veld gemaakt.

Als een 2 fase motor rechts omdraaid (rechtsdraaiend veld) dan draait de vector wiskundig links om dan kom je als eerste tegen -120 graden (L2) en als tweede -240 (L3)
Als je dat in postitieve getallen schrijft wordt dat 0| 240 | 120 om de fase volgorde van L1,L2 en L3 aan te houden.

[timbak02]

bommer schreef op maandag 12 oktober 2026 @ 20:02:
[...]

Je hebt nu een links draaiend veld gemaakt.

Als een 2 fase motor rechts omdraaid (rechtsdraaiend veld) dan draait de vector wiskundig links om dan kom je als eerste tegen -120 graden (L2) en als tweede -240 (L3)
Als je dat in postitieve getallen schrijft wordt dat 0| 240 | 120 om de fase volgorde van L1,L2 en L3 aan te houden.

Ik had een linksdraaiend veld -> deye 0/240/120 ingesteld anders kreeg ik een alarm (W03 Grid pahse wrong). Dit zorgde ervoor dat mijn "Zero export to CT" niet werkte. Dit was verdacht aangezien in NL standaard rechtsdraaiend wordt uitgevoerd. daarom heb ik op de klemmen van de Deye L2 en L3 omgedraaid en de Grid Type op 0/120/240 (rechtsdraaiend) gezet. Geen alarm en de grootste winst is dat "Zero Export to CT". nu perfect werkt.

[bommer]

timbak02 schreef op maandag 12 oktober 2026 @ 21:55:
[...]

Ik had een linksdraaiend veld -> deye 0/240/120 ingesteld anders kreeg ik een alarm (W03 Grid pahse wrong). Dit zorgde ervoor dat mijn "Zero export to CT" niet werkte. Dit was verdacht aangezien in NL standaard rechtsdraaiend wordt uitgevoerd. daarom heb ik op de klemmen van de Deye L2 en L3 omgedraaid en de Grid Type op 0/120/240 (rechtsdraaiend) gezet. Geen alarm en de grootste winst is dat "Zero Export to CT". nu perfect werkt.

Oke nog een keer:


Een rechts draaiend veld op de deye is 0|240|120
Of 0|-120|-240

De wiskundige vector draait tegen de klok in (linksom)

Maakt verder niet uit, pas alleen op met het aansluiten van 400V apparaten, zoals een 3f WP en zaagtafels
De Deye veranderd niet de richting van het veld.

[ Voor 12% gewijzigd door bommer op 12-10-2026 22:26 ]

[Yaldair]

Mijn concern is dat @timbak02 nu lokaal bij de Deye het veld weer heeft omgedraaid (of per toeval de juiste fases op de juiste aansluitingen gezet). Maar, hoe ziet de topology eruit van je installatie @timbak02 ? zit er iets tussen de deye en grid / hangt er iets parallel aan de deye?

[bommer]

Yaldair schreef op maandag 12 oktober 2026 @ 22:39:
Mijn concern is dat @timbak02 nu lokaal bij de Deye het veld weer heeft omgedraaid (of per toeval de juiste fases op de juiste aansluitingen gezet). Maar, hoe ziet de topology eruit van je installatie @timbak02 ? zit er iets tussen de deye en grid / hangt er iets parallel aan de deye?

De 0|240|120 inatelling is de juiste, het klinkt tegenstrijdig.
De volgende fase ijlt 120 graden na op de vorige.
L1 begint op 0, dan moet L2 wel -120 zijn. Wat het zelfde is als +240

Hij draait L2 en L3 om op de Deye en stelt in 0|120|240 wat links draaiend is volgens de theorie.
Er was dus een rechts draaiend veld, dat nu links gemaakt is.

Volgens mij zat het goed, misschien een CT gedraait?
Ik weet niet wat de Deye zegt als je CT 2 en 3 verwisselt.

Met een installatie tester of een duspol meten, dan weet je het zeker.

[ Voor 4% gewijzigd door bommer op 13-10-2026 05:32 ]