Het grote Deye inverter (en accu) topic

[bommer]

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

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

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

[genesisfm]

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

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

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

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


Zo zal het vandaag bij mij draaien
[Afbeelding]

[Afbeelding]


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

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

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

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

[timbak02]

Hallo allemaal,

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


Hoi allemaal,

Ik loop tegen een probleem aan met mijn Deye hybride omvormer en ben benieuwd of iemand dit herkent.

Setup

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

Probleem

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



Wat ik al gecontroleerd heb

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

Wat opvalt (zie filmpje)

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

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

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

Mijn vragen

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

Alvast bedankt!

[Domba]

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

[timbak02]

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

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

[desalnietemin]

@dingo35 @Yaldair dank voor jullie reacties!

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

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

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

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

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

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

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

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

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

Een minimaal voorbeeld van je flow zou daarbij erg helpen!

Thanks all