Het grote Deye inverter (en accu) topic

[jadjong]

Elmardus schreef op zaterdag 26 september 2026 @ 22:56:


Het weglaten van de aardlekbeveiliging aan de GRID-zijde is niet altijd verstandig, afhankelijk van het aardstelsel (TT / TN-CS). Als je geen aardlekbeveiliging plaatst, moet er (ook in island mode) voldoende foutstroom kunnen lopen om de normale zekeringautomaat af te laten slaan. Afhankelijk van de impedantie van de aardpen, de bekabeling en de aardfout zelf zou het kunnen dat de beveiliging dan niet aangesproken wordt.

Wat doet een aardlekbeveiliging aan de GRID-zijde in geval van island mode?

[Eddy Burnett]

arend20 schreef op zondag 27 september 2026 @ 11:54:
De bestaande Solar groepen op de Gen aansluiting moeten die ook worden voorzien van aardlekschakelaars? 1 x Solaredge en 1 x Growatt?

Naar mijn weten moet je PV inverter(s) die op de GEN poort van een Deye inverter wordt aangesloten, hetzelfde uitgangspunt hanteren alsof hij rechtstreeks op een verdeelinrichting/net zou worden aangesloten. De GEN-poort verandert de vereiste foutbescherming niet en vervangt geen aardlek(automaat).

[HarDus]

Als je niet de berekeningen van @bommer maakt, en niet afhankelijk wil zijn van de exacte weerstand van de aardpen is dan de eenvoudige oplossing voor een installatiemonteur:

300mA aardlek tussen grid en Deye en 30mA aardlek aan de gebruiker afname kant.

Die gebruikers afname zit ernaast of totaal/deels achter de load zit. Dat is ook wat ik uit de hier gedeelde tekst uit de Deye handleiding begrijp. Verschil tussen de totale toegevoegde huiscentrale en het verbruikersafnamebord/(bestaande) groepenkast?

[rvdgaag]

jadjong schreef op zondag 27 september 2026 @ 12:02:
[...]

Wat doet een aardlekbeveiliging aan de GRID-zijde in geval van island mode?

edit kijk verderop

[ Voor 48% gewijzigd door rvdgaag op 28-09-2026 14:05 ]

[bommer]

rvdgaag schreef op zondag 27 september 2026 @ 13:40:
[...]

Heel weinig tot niets wanneer je geen aparte aardpen hebt (in geval van een kabelbreuk in de grid). Levensgevaarlijk dus. Ik heb hiervoor afgelopen maand een aardpen laten slaan, de omvormer koppelt automatische de nul aan de aarde in geval van een wegvallen van de grid(setting in de interface). Mijn aarde kan dus niet wegvallen en de aardlekschakelaars achter de load uitgang doen het gewoon.

Ik heb de mijne gemeten met een installatie tester, maar daar kan niet iedereen over beschikken.
Mijn heipaal aarde is 1,74 ohm, dat zit wel goed. Maar toch nog best wel een verschil met de door net beheerder aangeboden aarde. Die ik op 0,13ohm meten.

[bommer]

Dit zegt het schema uit de handleiding. Hoewel aan de load zijde niets gezegd wordt over de fout stroom. Heb ik 300mA gedaan. De load kabel gaat rechtstreeks op mijn omschakelaar in de meterkast. De eindegroepen hebben alle een aardlek 30mA. Op deze manier is de kabel in de grond beveiligd (mocht iemand hem een keer raken. Nee ik heb geen AS kabel. dat hoeft niet meer van de NEN1010:2020) en als er in een eindgroep een fout is, blijft deze er in. Anders is gelijk alles donker.

[Initial G]

bommer schreef op zondag 27 september 2026 @ 18:26:
[Afbeelding]

Dit zegt het schema uit de handleiding. Hoewel aan de load zijde niets gezegd wordt over de fout stroom. Heb ik 300mA gedaan. De load kabel gaat rechtstreeks op mijn omschakelaar in de meterkast. De eindegroepen hebben alle een aardlek 30mA. Op deze manier is de kabel in de grond beveiligd (mocht iemand hem een keer raken. Nee ik heb geen AS kabel. dat hoeft niet meer van de NEN1010:2020) en als er in een eindgroep een fout is, blijft deze er in. Anders is gelijk alles donker.

Je hebt kans dat ie in blijft, maar geen garantie. Want misschien is de foutstroom wel 500mA of meer ineens bij een fout. Voor meer zekerheid zou je een selectieve aardlekschakelaar (tijdvertraagd) moeten nemen (type S). Ik heb dit ook gedaan voor een kabel naar een onderverdeler in het tuinhuis. Zijn wel weer wat duurder, maar van SEP is het te doen. Je hebt ze ook van 100mA.

[jadjong]

rvdgaag schreef op zondag 27 september 2026 @ 13:40:
[...]

Heel weinig tot niets wanneer je geen aparte aardpen hebt (in geval van een kabelbreuk in de grid). Levensgevaarlijk dus. Ik heb hiervoor afgelopen maand een aardpen laten slaan, de omvormer koppelt automatische de nul aan de aarde in geval van een wegvallen van de grid(setting in de interface). Mijn aarde kan dus niet wegvallen en de aardlekschakelaars achter de load uitgang doen het gewoon.

Een aardlekschakelaar heeft geen aardpen nodig. Die meet alleen het verschil tussen fase en nul, wanneer dat meer dan x mA is gaat het ding uit. De reden dat de omvormer nul aan aarde koppelt is om een zwevend net te voorkomen. Bij een zwevend net heb je gewoon 230V verschil tussen nul en fase, maar niets garandeert dat de nul dan ook 0V is. Bij 80V op de nul en 310V op de fase heb je immers ook een verschil van 230V.

Een aardlekschakelaar voor de omvormer (grid-zijde) beveiligt alleen de kabel naar de omvormer wanneer het net actief is, dus daar kan je dan naar hartenlust de betonboor in zetten. De omvormer zelf heeft ten alle tijden een lage aardweerstand nodig om zijn eigen beveiliging te triggeren wanneer er intern een draadje tegen de metalen behuizing waait. Als de aardlek aan de grid-zijde uit gaat door lekstroom dan blijft de omvormer vrolijk verder gaan, daar is het ding namelijk voor gemaakt. Je hebt die aardpen nodig om de metalen behuizing van de omvormer veilig te houden.
Een aardlekschakelaar achter de omvormer (load-zijde) heeft altijd nut, steek je tong in een stopcontact en het ding gaat uit bij minder dan 30mA door je tong. De vraag is of het volgende nuttig is:

net -- aardlekschakelaar1 -- omvormer -- aardlekschakelaar2 -- groepenkast -- standaard groepen/aardlekschakelaars.

Aardlekschakelaar 2 is handig wanneer je van plan bent om tijdens uitval van het net ook nog even door de kabel tussen omvormer en groepenkast te boren. Wanneer je aan een stopcontact in huis gaat likken heb je immers de standaard aardlekschakelaars al die je een darwin award besparen. Mocht je voor aardlekschakelaar 1 en 2 een hogere limiet kiezen, bijvoorbeeld 300mA of 500mA, dan wil het niet zeggen dat de 16A/30mA op standaard gebruiksgroepen in de woning als eerste uit gaat mocht er toch iemand zijn tong ergens in steken.
Voor enige selectiviteit in lekstroom zal je bij aardlekschakelaar 1&2 een type S variant moeten kiezen, die reageert bewust trager op dezelfde lekstroom dan een standaard aardlekschakelaar waardoor je zeker weet dat de 16/30mA op de gebruiksgroep als eerste afschakelt. Als je dan een type S neemt, kies voor een A/S variant want die meet ook DC lekstroom. Wel zo handig bij een apparaat dat misschien ook verboden is met ~1000V aan PV.

[dingo35]

@jadjong Het heeft geen zin dit aan @rvdgaag uit te leggen, het is nu de derde keer in deze thread dat hij deze onjuiste bewering doet; dit was mijn uitleg na de tweede keer: dingo35 in "Het grote Deye inverter (en accu) topic"

...maar het dringt toch niet door?!?

EDIT: en hier Het grote Deye inverter (en accu) topic nóg een keer, in andere bewoordingen, uitgelegd. Blijkbaar heeft hij het idee dat natuurwetten ook maar meningen zijn?

[ Voor 30% gewijzigd door dingo35 op 28-09-2026 10:29 ]

[bommer]

Initial G schreef op zondag 27 september 2026 @ 20:33:
[...]

Je hebt kans dat ie in blijft, maar geen garantie. Want misschien is de foutstroom wel 500mA of meer ineens bij een fout. Voor meer zekerheid zou je een selectieve aardlekschakelaar (tijdvertraagd) moeten nemen (type S). Ik heb dit ook gedaan voor een kabel naar een onderverdeler in het tuinhuis. Zijn wel weer wat duurder, maar van SEP is het te doen. Je hebt ze ook van 100mA.

Het is inderdaad beter een selectieve te nemen, als je het 100% gegarandeerd wil hebben.
Normaal gaat een aardlek er niet uit, althans hier alleen maar als bewuste actie.
Ik neem het risico, die extra €130 is het niet waard.
Ik wil het graag allemaal bij 1 merk houden. (Eaton)

[rvdgaag]

dingo35 schreef op maandag 28 september 2026 @ 06:03:
@jadjong Het heeft geen zin dit aan @rvdgaag uit te leggen, het is nu de derde keer in deze thread dat hij deze onjuiste bewering doet; dit was mijn uitleg na de tweede keer: dingo35 in "Het grote Deye inverter (en accu) topic"

...maar het dringt toch niet door?!?

EDIT: en hier Het grote Deye inverter (en accu) topic nóg een keer, in andere bewoordingen, uitgelegd. Blijkbaar heeft hij het idee dat natuurwetten ook maar meningen zijn?

Zonder de hele discussie opnieuw te willen starten,

NEN 1010 (§551, gebaseerd op IEC 60364-5-55) stelt het volgende. Als een eigen opwekker werkt als alternatief voor een TN-net, mag de beveiliging door automatische afschakeling niet afhankelijk zijn van de aardverbinding van het openbare net. Dat is precies jouw situatie: in eilandbedrijf mag je niet rekenen op de PEN van de netbeheerder.

Wat je mist zonder aardpen

1. Geen referentie ten opzichte van de echte aarde. Als de netkabel fysiek weg is (graafschade, doorgebroken PEN), zweeft je hele PE/N-systeem ten opzichte van de grond buiten. Een fout van L naar de echte aarde loopt niet via de PE en vindt geen retourpad naar de omvormer. Denk aan een defect buitentoestel, een beschadigde tuinkabel of een verwarmingselement met contact naar de aarde. In het eerste moment is dat vaak "onschuldig", zoals bij een IT-stelsel. Maar de aardlek grijpt niet in, en de fout blijft onopgemerkt staan tot er een tweede pad ontstaat. Dat tweede pad kan een persoon zijn, een metalen waterleiding of een andere fout.
2. Potentiaalverschil tussen PE en de omgeving. Zonder aardelektrode is niet gegarandeerd dat de geaarde delen in huis op aardpotentiaal liggen. Bij een foutsituatie kan er aanraakspanning ontstaan tussen een toestelhuis en bijvoorbeeld een natte vloer of de tuin.
3. Een lekkende hoofdvereffening. Vroeger zorgden een metalen waterleiding en gasleiding "gratis" voor een aardverbinding. Bij moderne kunststof leidingen is die er vaak niet meer.

[dingo35]

Het venijn zit m dus in de formulering "Heel weinig tot niets wanneer je geen aparte aardpen hebt (in geval van een kabelbreuk in de grid). "

..als antwoord op de vraag wat je aan een aardlekschakelaar in de GRID leiding hebt als je in eilandmode zit.
Nogal wat mensen missen m.i. de achterliggende gedachte van de vraagsteller (bij een standaard bedrading heb je helemaal niets aan zo'n aardlekschakelaar aangezien in eilandmode de GRID aansluiting afgeschakeld is).

Maar dat even negerend, kun je concluderend stellen dat een aardpen KAN ervoor zorgen dat een aardlekschakelaar afslaat vóórdat iemand een opdonder heeft gekregen (maar dat is niet gegarandeerd), als die aardpen er niet is slaat de aardlekschakelaar af TIJDENS dat iemand een opdonder krijgt. Als het een 30mA exemplaar was leeft die persoon hoogstwaarschijnlijk nog, als het een 300mA exemplaar was is die kans aanzienlijk kleiner.

Dus ook als je geen goede aarde/aardpen hebt zal een 30mA aardlekschakelaar levensreddend zijn.

[ Voor 5% gewijzigd door dingo35 op 28-09-2026 11:58 ]

[DavidZH]

Bij mijn weten is de gridzijde spanningsloos in eilandbedrijf. Want dat MOET volgens EN 50549. Dus in dat opzicht ziet de ALS daar op dat moment uit z’n neus te butteren.

Tijdens ON-GRID bedrijf is de ALS nodig om de kabel tussen de groepenkast en je omvormer te beschermen tegen schade. Als je een spa in de grond steekt dat je niet een dikke vlamboog in je gezicht krijgt.

Hangt de omvormer direct naast je groepenkast kan een normale automaat volstaan.

[HarDus]

rvdgaag schreef op maandag 28 september 2026 @ 11:41:
[...]


Zonder de hele discussie opnieuw te willen starten,

NEN 1010 (§551, gebaseerd op IEC 60364-5-55) stelt het volgende. Als een eigen opwekker werkt als alternatief voor een TN-net, mag de beveiliging door automatische afschakeling niet afhankelijk zijn van de aardverbinding van het openbare net. Dat is precies jouw situatie: in eilandbedrijf mag je niet rekenen op de PEN van de netbeheerder.

Wat je mist zonder aardpen

1. Geen referentie ten opzichte van de echte aarde. Als de netkabel fysiek weg is (graafschade, doorgebroken PEN), zweeft je hele PE/N-systeem ten opzichte van de grond buiten. Een fout van L naar de echte aarde loopt niet via de PE en vindt geen retourpad naar de omvormer. Denk aan een defect buitentoestel, een beschadigde tuinkabel of een verwarmingselement met contact naar de aarde. In het eerste moment is dat vaak "onschuldig", zoals bij een IT-stelsel. Maar de aardlek grijpt niet in, en de fout blijft onopgemerkt staan tot er een tweede pad ontstaat. Dat tweede pad kan een persoon zijn, een metalen waterleiding of een andere fout.
2. Potentiaalverschil tussen PE en de omgeving. Zonder aardelektrode is niet gegarandeerd dat de geaarde delen in huis op aardpotentiaal liggen. Bij een foutsituatie kan er aanraakspanning ontstaan tussen een toestelhuis en bijvoorbeeld een natte vloer of de tuin.
3. Een lekkende hoofdvereffening. Vroeger zorgden een metalen waterleiding en gasleiding "gratis" voor een aardverbinding. Bij moderne kunststof leidingen is die er vaak niet meer.

Zou je op basis van deze post je voorgaande post dan kunnen corrigeren. Ik begrijp nu dat deze ongepast stellig is en nu ook niet (volledig) juist?

[zalkc]

DavidZH schreef op maandag 28 september 2026 @ 12:15:
Bij mijn weten is de gridzijde spanningsloos in eilandbedrijf. Want dat MOET volgens EN 50549. Dus in dat opzicht ziet de ALS daar op dat moment uit z’n neus te butteren.

Tijdens ON-GRID bedrijf is de ALS nodig om de kabel tussen de groepenkast en je omvormer te beschermen tegen schade. Als je een spa in de grond steekt dat je niet een dikke vlamboog in je gezicht krijgt.

Hangt de omvormer direct naast je groepenkast kan een normale automaat volstaan.

Dit lijkt me af te hangen van je omschakelaar/load inrichting. Mijn omschakelaar zit na de hoofdzekering en voor de ALS'en, die ALS'en gaan niet ineens anders werken aangezien ik ook een aardpen heb.

[DavidZH]

zalkc schreef op maandag 28 september 2026 @ 13:45:
[...]

Dit lijkt me af te hangen van je omschakelaar/load inrichting. Mijn omschakelaar zit na de hoofdzekering en voor de ALS'en, die ALS'en gaan niet ineens anders werken aangezien ik ook een aardpen heb.

In mijn post had ik het over de gridzijde van de omvormer. Ongeacht hoe je installatie is ingedeeld, is die ALTIJD spanningsloos bij eilandbedrijf. In jouw geval: als de grid kant van jouw omvormer met een grondkabel verbonden is met de meterkast zijn er maar heeeeeel weinig gevallen mogelijk waar er geen ALS hoeft te worden toegepast op die kabel. Dit is dus geen 30mA, maar een 300mA, liefst selectieve ALS. Dit staal he-le-maal los van welk stelsel er in jouw woning is toegepast.

Aan de loadkant is het bij gebruik van een lange verbindingskabel door de grond net zo goed aanbevolen om een gelijke ALS toe te passen die de hoogste stroom kan verwerken (Deye + grid + eventuele AC PV). Ook deze staan los van je alamats of ALS’en van de eindgroepen.

En beide gevallen staan weer los van de afzekering die bij de kabeldoorsnede past.

[n13l6]

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 zou het mogelijk moeten maken om tijdens zero load to CT je surplus energie in de accu te verkopen naar het net. Dit was voor mij de grootste struikelblok bij deze omvormers en zorgde voor veel gedoe bij de automatisering in Home Assistant. Super blij mee



Wel even dit toevoegen aan je deye_p3.yaml als je de Solarman integratie gebruikt

YAML:

      - name: Program 1 Sell
        platform: switch
        rule: 1
        registers: [0x00AC]
        display:
          mask: 0x04
        icon: mdi:cash-refund

      - name: Program 2 Sell
        platform: switch
        rule: 1
        registers: [0x00AD]
        display:
          mask: 0x04
        icon: mdi:cash-refund

      - name: Program 3 Sell
        platform: switch
        rule: 1
        registers: [0x00AE]
        display:
          mask: 0x04
        icon: mdi:cash-refund

      - name: Program 4 Sell
        platform: switch
        rule: 1
        registers: [0x00AF]
        display:
          mask: 0x04
        icon: mdi:cash-refund

      - name: Program 5 Sell
        platform: switch
        rule: 1
        registers: [0x00B0]
        display:
          mask: 0x04
        icon: mdi:cash-refund

      - name: Program 6 Sell
        platform: switch
        rule: 1
        registers: [0x00B1]
        display:
          mask: 0x04
        icon: mdi:cash-refund

[ Voor 38% gewijzigd door n13l6 op 01-10-2026 10:54 ]

[thomvh]

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 zou het mogelijk moeten maken om tijdens zero load to CT je surplus energie in de accu te verkopen naar het net. Dit was voor mij de grootste struikelblok bij deze omvormers en zorgde voor veel gedoe bij de automatisering in Home Assistant. Super blij mee

[Afbeelding]

Damn... In hoeverre is dit afwijkend van de al bestaande solar sell knop?

[n13l6]

thomvh schreef op donderdag 1 oktober 2026 @ 10:23:
[...]

Damn... In hoeverre is dit afwijkend van de al bestaande solar sell knop?

Na mijn weten is Solar Sell alleen een knopje die je overtollige zonnestroom verkoopt wanneer de accu SoC op 100% zit. In veel landen mag je niet terugvoeden aan het. Anders gaat hij de zonnestroom afknijpen en het verbruik op 0 houden. Maar kan er naast zitten. Deze nieuwe optie verkoop tot de ingestelde SoC zelfs als je zero load to CT doet. Voorheen moest je van modus veranderen.

[Giem]

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 zou het mogelijk moeten maken om tijdens zero load to CT je surplus energie in de accu te verkopen naar het net. Dit was voor mij de grootste struikelblok bij deze omvormers en zorgde voor veel gedoe bij de automatisering in Home Assistant. Super blij mee

[Afbeelding]

Wel even dit toevoegen aan je deye_p3.yaml als je de Solarman integratie gebruikt

YAML:

      - name: Program 1 Sell
        platform: switch
        rule: 1
        registers: [0x00AC]
        display:
          mask: 0x04
        icon: mdi:cash-refund

      - name: Program 2 Sell
        platform: switch
        rule: 1
        registers: [0x00AD]
        display:
          mask: 0x04
        icon: mdi:cash-refund

      - name: Program 3 Sell
        platform: switch
        rule: 1
        registers: [0x00AE]
        display:
          mask: 0x04
        icon: mdi:cash-refund

      - name: Program 4 Sell
        platform: switch
        rule: 1
        registers: [0x00AF]
        display:
          mask: 0x04
        icon: mdi:cash-refund

      - name: Program 5 Sell
        platform: switch
        rule: 1
        registers: [0x00B0]
        display:
          mask: 0x04
        icon: mdi:cash-refund

      - name: Program 6 Sell
        platform: switch
        rule: 1
        registers: [0x00B1]
        display:
          mask: 0x04
        icon: mdi:cash-refund

Waar heb je deze Firmware gevonden, op de GitHub zie ik alleen een versie staan van 3 maanden geleden.

[n13l6]

Giem schreef op donderdag 1 oktober 2026 @ 11:28:
[...]

Waar heb je deze Firmware gevonden, op de GitHub zie ik alleen een versie staan van 3 maanden geleden.

Ff Deye een berichtje sturen, die updaten de firmware via de cloud. Ik denk dat hij gloednieuw is. Had ook even contact met ze gezocht omdat mijn powerloss altijd minimaal 150W lijkt te zijn

[thomvh]

n13l6 schreef op donderdag 1 oktober 2026 @ 10:50:
[...]

Na mijn weten is Solar Sell alleen een knopje die je overtollige zonnestroom verkoopt wanneer de accu SoC op 100% zit. In veel landen mag je niet terugvoeden aan het. Anders gaat hij de zonnestroom afknijpen en het verbruik op 0 houden. Maar kan er naast zitten. Deze nieuwe optie verkoop tot de ingestelde SoC zelfs als je zero load to CT doet. Voorheen moest je van modus veranderen.

Ben wel benieuwd. Want eigenlijk kun je dan op basis van TOU aansturing wisselen tussen verkopen en laden. Wat natuurlijk de scripts veel makkelijker maakt.

[n13l6]

thomvh schreef op donderdag 1 oktober 2026 @ 11:55:
[...]

Ben wel benieuwd. Want eigenlijk kun je dan op basis van TOU aansturing wisselen tussen verkopen en laden. Wat natuurlijk de scripts veel makkelijker maakt.

Ja, heel grof kan je dan zelfs 1x de omvormer instellen om 's nachts en overdag op te laden en dan tijdens de pieken te dumpen.

[thomvh]

n13l6 schreef op donderdag 1 oktober 2026 @ 12:04:
[...]


Ja, heel grof kan je dan zelfs 1x de omvormer instellen om 's nachts en overdag op te laden en dan tijdens de pieken te dumpen.

Ja ik ben benieuwd of mijn trucje nog werkt. Als je alle timeslots op 00:00 zet. Werkt alleen de laatste. Als dat zou werken dan zou het echt een heel stuk makkelijk worden om aan te sturen. Weet je of de power waarde ook mee verander van laden naar ontladen? Want dat is eigenlijk het grootste gemis. Ik moet de max waardes momenteel aanpassen en daar ben ik niet zo'n groot fan van. De TOU slots worden namelijk inactief als de omvormer off grid is wat echt ideaal is.

[n13l6]

Net even wat in elkaar gedraaid, ik kan nu kiezen hoe groot ik de stappen wil. Afhankelijk of EMHASS een negatief of positief vermogen heeft gaat het vakje "Grid" of "Sell" aan. Werkt echt 10x makkelijker dan de vorige truc waarbij het hele huis (- laadpaal) aan de UPS kant hing en er steeds geklooid moest worden tussen Zero Export to CT en Selling First.

[Switek]

thomvh schreef op donderdag 1 oktober 2026 @ 11:55:
[...]

Ben wel benieuwd. Want eigenlijk kun je dan op basis van TOU aansturing wisselen tussen verkopen en laden. Wat natuurlijk de scripts veel makkelijker maakt.

Zo doet Deye-Copilot het ook grotendeels. Ik probeer te leren van Copilot welke registers er worden gebruikt zodat ik dat eventueel later zelf in HA, via bijvoorbeeld DAO, kan gaan doen.
Tot nu toe kom ik het volgende tegen.
ToU Grid/Sell-bits: Disabled / Grid / Sell / Grid+Sell
ToU SOC: Low Batt - 100%
Battery Max Charging Current: 1-160 A
Battery Grid Charging Current: 4-100A
Export Surplus Power: 128–8000 W

Alle tijdsloten worden steeds gelijktijdig met delfde waarden weggeschreven.Verder valt op dat Copilot wel erg veel schrijf acties maakt en als minimale SOC in de ToU de waarde zoals ingesteld bij LowBat hanteert. Hierdoor gaat de beeper aan als er geen PV is geweest en er niet geladen gaat worden van Grid.

[ Voor 4% gewijzigd door Switek op 01-10-2026 14:25 ]

[n13l6]

Switek schreef op donderdag 1 oktober 2026 @ 14:23:
[...]

Zo doet Deye-Copilot het ook grotendeels. Ik probeer te leren van Copilot welke registers er worden gebruikt zodat ik dat eventueel later zelf in HA, via bijvoorbeeld DAO, kan gaan doen.
Tot nu toe kom ik het volgende tegen.
ToU Grid/Sell-bits: Disabled / Grid / Sell / Grid+Sell
ToU SOC: Low Batt - 100%
Battery Max Charging Current: 1-160 A
Battery Grid Charging Current: 4-100A
Export Surplus Power: 128–8000 W

Alle tijdsloten worden steeds gelijktijdig met delfde waarden weggeschreven.Verder valt op dat Copilot wel erg veel schrijf acties maakt en als minimale SOC in de ToU de waarde zoals ingesteld bij LowBat hanteert. Hierdoor gaat de beeper aan als er geen PV is geweest en er niet geladen gaat worden van Grid.

Schrijft Deye Copilot naar RAM of EEPROM? Dat laatste is de reden dat ik maar 4x per dag de ToU tabellen ga updaten.

[Switek]

n13l6 schreef op donderdag 1 oktober 2026 @ 14:29:
[...]


Schrijft Deye Copilot naar RAM of EEPROM? Dat laatste is de reden dat ik maar 4x per dag de ToU tabellen ga updaten.

Nooit over nagedacht eerlijk gezegd, maar het moet dan via Copilot bijna wel RAM zijn.

[Giem]

n13l6 schreef op donderdag 1 oktober 2026 @ 11:40:
[...]


Ff Deye een berichtje sturen, die updaten de firmware via de cloud. Ik denk dat hij gloednieuw is. Had ook even contact met ze gezocht omdat mijn powerloss altijd minimaal 150W lijkt te zijn

Is je probleem met de powerloss hier mee opgelost? Je bedoeld denk ik het eigen verbruik van 100 watt of meer?

[thomvh]

Switek schreef op donderdag 1 oktober 2026 @ 14:47:
[...]

Nooit over nagedacht eerlijk gezegd, maar het moet dan via Copilot bijna wel RAM zijn.

Ik twijfel of de omvormer toch niet al eerder kapot gaat dan de EEPROM. Maar aangezien ze het zelf op dezelfde manier doen gok ik dat Deye er wel een beetje over nadenkt.

[n13l6]

Tot nu toe geen verschillen, heb een uitgebreide analyse naar Deye gestuurd en de update is gisteren gedaan. Dit is de samenvatting:

sensor.sun_8k_power_losses (W)
AVG 160
MIN 53,8
MAX 470,9
STDEV 44,5

Best wel heel hoog, want in veel gevallen zijn de powerlosses hoger dan mijn achtergrondverbruik van het huis. Ik begrijp wel dat power losses een berekening is, maar ben benieuwd hoe hoog deze bij jullie is.

[KVan]

thomvh schreef op donderdag 1 oktober 2026 @ 13:22:
[...]

Ja ik ben benieuwd of mijn trucje nog werkt. Als je alle timeslots op 00:00 zet. Werkt alleen de laatste. Als dat zou werken dan zou het echt een heel stuk makkelijk worden om aan te sturen. Weet je of de power waarde ook mee verander van laden naar ontladen? Want dat is eigenlijk het grootste gemis. Ik moet de max waardes momenteel aanpassen en daar ben ik niet zo'n groot fan van. De TOU slots worden namelijk inactief als de omvormer off grid is wat echt ideaal is.

Dat is precies zoals het hier werkt. Alle slots staan op 1:00 tot 1:00, dan gebruikt hij enkel het laatste. Dus alleen die schrijf ik.

[hannibal2206]

Domba schreef op vrijdag 16 februari 2024 @ 22:02:
@Noordhorn Afhankelijk van je BMS keuze en hoeveelheid kWh opslag.
vanaf >24kwh zou in principe master-BMS max laadvermogen kunnen vrijschakelen, maar zeker vanaf 3x 14-15kwh accu-modules
Dan is ADM420G/B20 te klein deze zal te warm worden de werktemperatuur is 40 graden, vanaf 30 graden neemt de afgezekerde waarde met 0.1A per graad er boven af.

Als je met 12kW accu's kunt laden , dan worden ook gelijktijdig verbruikers vanuit het net voorzien en die komen boven op de 12kW.

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

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 ?

[rvdgaag]

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 ?

Hangt af van je BMS, de master accu zend de data naar de Deye. Ik heb 4 Seplossen eraan hangen en de Seplos Master BMS telt inderdaad de maximaal ingestelde laadstroom van iedere accu op en rapporteert deze gecumuleerd aan de Deye.

Hoe JK's of andere BMS merken dat doen geen idee

[n13l6]

Oke, ik heb extra testen gedaan en ik heb te vroeg gejuicht. Hoewel hij nu inderdaad kan verkopen tijdens zero load to CT, is het vermogen in de ToU tabel nog steeds het totalen vermogen wat door de accu in dat tijdslot geleverd kan worden. Dus als EMHASS bijv. voorschrijft 1000W te verkopen tot een bepaalde SOC en je dit naar de ToU tabel schrijft, dan trekt Deye eerst je huidige zelfverbruik van het vermogen af en stuurt het resterende naar het net. Dit is natuurlijk niet wat je wil. Als je dan een waterkoker aanzet gaat dit over de 1000W grens heen en trekt de Deye stroom van het net. Super stom dat de regeling niet het volgende doet in het voorbeeld:

Ingestelde maximale grens batterij: 10.000 watt
Modus: zero load to CT
ToU tabel: sell enabled, vermogen 1000W, SoC 25%
Huidige verbruik huis: 500W
Totale vermogen uit batterij: 500W zelfconsumptie, 1000W terugleveren.

Bij bijv. laden van een EV:
Huidig verbruik huis: 11.500W
Totaal vermogen uit batterij: 10.000 zelfconsumptie, 0W terugleveren.

Net maar weer even een feature request naar Deye gestuurd...

[scoobs]

En als je export first doet met grid peak shaving off en max sell power als export target? Je SoC target wordt wat losser, maar in mijn ervaring boeit het niet als je een beetje okay load en production forecast hebt icm je EV en warmtepomp als deferrables + eens per 15 minuten een re-plan draaien.

Ik was toevallig vanmorgen bezig om een writer/EMS (EMHASS + wat extra dingen als rebalancing, temperature dependant deratings, en nog wat andere safety features, notifications, en wat ingebouwde hystereses om het aantal registry writes laag te houden.) te pushen naar github. Als GH weer online is kun je daar eens in kijken.

[ Voor 24% gewijzigd door scoobs op 02-10-2026 10:02 ]

[n13l6]

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? Je SoC target wordt wat losser, maar in mijn ervaring boeit het niet als je een beetje okay load en production forecast hebt icm je EV en warmtepomp als deferrables + eens per 15 minuten een re-plan draaien.

Ik was toevallig vanmorgen bezig om een writer/EMS (EMHASS + wat extra dingen als rebalancing, temperature dependant deratings, en nog wat andere safety features, notifications, en wat ingebouwde hystereses om het aantal registry writes laag te houden.) te pushen naar github. Als GH weer online is kun je daar eens in kijken.

Hoe vaak schrijf je het setpoint naar de omvormer? En op deze manier heb je niet je zelfverbruik gecovered denk ik, of heb je je huis aan de UPS kant hangen?

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