Zendure producten in Home Assistant integreren deel 2

[Mistraller]

m-vw schreef op woensdag 9 september 2026 @ 10:48:
[...]


Volgens mij heeft mijn Solpanet omvormer ook een mogelijkheid om het vermogen te beperken, enkel zit dat ergens in het installateursmenu. Dat is voor hier OT, maar wel iets waar ik nog naar wil gaan kijken voor volgend jaar.

Veel omvormers hebben dat inderdaad, mijn Sunnyboy ook in installateursmenu (omvormer uit 2013) maar die schrijft dus in flash en niet geschikt om dynamisch te wijzigen. Modernere omvormers doen dat inderdaad anders, en dan is dynamisch geen probleem. Feitelijk precies de actie die we met onze thuisaccu ook proberen te bereiken; ongewenste teruglevering minimaliseren.

[Mistraller]

MrAngry schreef op woensdag 9 september 2026 @ 10:51:
[...]

Dat is een DSMR 4 meter, daarbij heeft je P1 meter een eigen voeding nodig. Verder werkt het hetzelfde als een DSMR5 meter.

Dat ligt aan het merk/type meter; de P1 van zendure doet het zonder extra voeding op mijn dsmr4.

[Mistraller]

Erik1 schreef op woensdag 9 september 2026 @ 11:30:
[...]

Zendure heeft hier ook een instelling voor gemaakt in de accu's: smartMode

smartMode Behavior

• 1: Parameters are not written to flash
• Device restores previous flash values after reboot
• Recommended for frequent configuration changes

Zowel Gielz als Fireson maken gebruik van SmartMode. Daar heb je geen omkijken naar verder.

[Mistraller]

winwiz schreef op woensdag 9 september 2026 @ 13:37:
[...]

Die wordt binnenkort toch sowieso vervangen?

Binnen nu en 2030 wel ja....

[MrAngry]

maartend schreef op woensdag 9 september 2026 @ 13:37:
Ik ben wat aan het aanpassen met automations. Maar ik ben op zoek naar een entitie die ik niet kan vinden.


Ik heb een Homewizard p1 meter, die werkt gewoon goed in HA.


Maar de entitie die ik zoek is het equivalent van de volgende ; Gebruik 'Netto Export' in plaats van pure zonneproductie: Het is vaak slimmer om te kijken naar de stroom die je daadwerkelijk over hebt (sensor.power_export of je P1-meter). Als je zonnepanelen 900W leveren, maar je vaatwasser verbruikt 500W, heb je immers maar 400W over voor de batterijen.

Maar ik krijg hem dus niet gevonden. Heb al op van alles gezocht bij entities in HA.


Tips?

Ga naar instellingen (van HA) devices, homewizard, P1 meter, entities en zoek de juiste entity op. Bij het tandwieltje kan je zien hoe die exact heet. Die van mij heet ook een beetje counterintuitief sensor.export_per_year_power

[MrAngry]

Mistraller schreef op woensdag 9 september 2026 @ 13:47:
[...]

Dat ligt aan het merk/type meter; de P1 van zendure doet het zonder extra voeding op mijn dsmr4.

Maar hij heeft een homewizard, dat schrijft ie zelf.

[maartend]

MrAngry schreef op woensdag 9 september 2026 @ 13:54:
[...]

Ga naar instellingen (van HA) devices, homewizard, P1 meter, entities en zoek de juiste entity op. Bij het tandwieltje kan je zien hoe die exact heet. Die van mij heet ook een beetje counterintuitief sensor.export_per_year_power

Ik vind wel deze, maar of dit de goede is? sensor.p1_meter_energy_export_tariff_2 maar daar staat dus tarief in en geen power.


En nu is de zon weg, dus kan het ook niet eens testen


Mogelijk dat dit het is ; sensor.woonkamer_p1_meter_battery_group_target_power

edit ; ja, het is die laatste

[ Voor 15% gewijzigd door maartend op 09-09-2026 15:05 ]

[MrAngry]

Ja maar dat is echt een andere. De friendly name van degene die je wilt zien is bij mij simpelweg Power en die geeft weer wat je op dit moment van het net afneemt of teruggeeft, netto dus.

[ Voor 8% gewijzigd door MrAngry op 09-09-2026 14:00 ]

[Mistraller]

MrAngry schreef op woensdag 9 september 2026 @ 13:55:
[...]

Maar hij heeft een homewizard, dat schrijft ie zelf.

Ja maar dan kan het nog zijn dat een bepaalde meter wel genoeg power levert. Ik heb zelf een FTDI kabel en een Zendure P1 (als "nood", ligt doorgaans in doosje) en daarvoor heb ik geen extra power nodig.
Maar goed, zou idd kunnen dat een homewizard p1 een stroomvreter is, dat weet ik niet

Ik heb een Kaifa MA304, en die is er in DSMR4 en 5 versies. Nu weet ik niet of de meterhardware zelf ook vernieuwd is of dat alleen de GPRS module is + firmware.
Kan mij zomaar voorstellen dat het dit laatste is, wat zou kunnen verklaren dat mijn meter wel wat meer power levert of zo.

[Pakhaas]

Mistraller schreef op woensdag 9 september 2026 @ 10:38:
[...]

Nom doet natuurlijk niets anders dan dit. Elke 5 seconden wisselt het vermogen en ook vaak wisselen van laden naar ontladen. Is niet anders dan bij een auto waarbij je door te remmen ook ineens gaat laden ipv ontladen.

Punt van aandacht is dat de data die in RAM staat, bij het standby zetten naar flash weggeschreven wordt. En flash is niet oneindig schrijfbaar.

Dit probleem bestaat al lang: Ik heb hier een Sunnyboy PV omvormer. Die kan ik niet sturen op vermogen; ook al zit de hardware er wel in. De ontwikkelaar van de software die ik voor het uitlezen gebruik heeft er ooit functionaliteit ingebouwd waarmee je dynamisch vermogen kon aanpassen. Dat was nu heel leuk geweest gezien afbouw saldering.... ware het niet dat de fabrikant de ontwikkelaar heeft teruggefloten want het flash memory van die omvormer kon zoveel schrijfacties niet aan. (En dat kon niet naar RAM geschreven worden) Toen is het er weer uitgehaald.

Wij hebben ook een Sunny Boy 5000TL-21 uit 2016 en daarmee kan ik via modbus het vermogen knijpen naar 1% als de prijs negatief is en zodra ik dan wat meer thuis nodig heb, geeft die wat extra vrij via de automatisering. Soort reverse loadbalancing. Als ik naar 0% ga hoor ik hem juist schakelen, vandaar naar 1%.

[Ben(V)]

Mistraller schreef op woensdag 9 september 2026 @ 14:08:
[...]

Ja maar dan kan het nog zijn dat een bepaalde meter wel genoeg power levert. Ik heb zelf een FTDI kabel en een Zendure P1 (als "nood", ligt doorgaans in doosje) en daarvoor heb ik geen extra power nodig.
Maar goed, zou idd kunnen dat een homewizard p1 een stroomvreter is, dat weet ik niet

Ik heb een Kaifa MA304, en die is er in DSMR4 en 5 versies. Nu weet ik niet of de meterhardware zelf ook vernieuwd is of dat alleen de GPRS module is + firmware.
Kan mij zomaar voorstellen dat het dit laatste is, wat zou kunnen verklaren dat mijn meter wel wat meer power levert of zo.

Als je gprs meter vervangen wordt dan krijg je een compleet nieuwe DSMR 5 meter, modules vervangen doen ze niet(en kan ook niet).

[Mistraller]

Pakhaas schreef op woensdag 9 september 2026 @ 15:03:
[...]

Wij hebben ook een Sunny Boy 5000TL-21 uit 2016 en daarmee kan ik via modbus het vermogen knijpen naar 1% als de prijs negatief is en zodra ik dan wat meer thuis nodig heb, geeft die wat extra vrij via de automatisering. Soort reverse loadbalancing. Als ik naar 0% ga hoor ik hem juist schakelen, vandaar naar 1%.

Ik heb een 2100TL, die had helemaal geen interface, maar ik heb er een BT-piggyback bijgezet.
SBFspot was in staat om het vermogen te regelen. SMA heeft hier toen een statement op gemaakt dat je garantie vervalt als je dit gebruikt. (Toen is het heel snel weer uit SBFspot verdwenen.) Ik kan de specifieke discussie niet meer vinden helaas.
Mogelijk zou ik het met een TCP piggyback met modbus ook kunnen, maar die omvormers van toen hielden er geen rekening mee dat het vermogen dagelijks vaak zou wijzigen en dus het flashmemory vaak beschreven zou worden. Dus ja, het kan, maar met risico's.

Je leest er hier meer over.

https://eliasrm.es/posts/...n-local-inverter-control/

[Mistraller]

Ben(V) schreef op woensdag 9 september 2026 @ 15:17:
[...]

Als je gprs meter vervangen wordt dan krijg je een compleet nieuwe DSMR 5 meter, modules vervangen doen ze niet(en kan ook niet).

Ja, dat had ik ook gehoopt. Zegeltje verwijderen, gprs eruit, 4G erin, firmware flash en klaar...
want verder vind ik die Kaifa prima, het is anders toch maar weer afwachten wat ze erin schroeven. Maar ik denk dat er van de MA304 meerdere subtypes zijn.
En het is voor Enexis ook weer veel te ingewikkeld om precies de juiste module bij het juiste adres te leveren, want overal hangen verschillende.

Duurzaamheidstechnisch gezien echter waanzin, want ook de gasmeter zullen ze wel vervangen. Kijken of ik voor die tijd van het gas af ben.

[Ben(V)]

Je zou helemaal geen gprs swap willen( kan niet want zit gewoon maar een printplaat in), want dan zou je een DSMR 4 houden terwijl je toch echt wel een DSMR 5 wilt als je een batterij hebt.

[Pakhaas]

Mistraller schreef op woensdag 9 september 2026 @ 16:42:
[...]

Ik heb een 2100TL, die had helemaal geen interface, maar ik heb er een BT-piggyback bijgezet.
SBFspot was in staat om het vermogen te regelen. SMA heeft hier toen een statement op gemaakt dat je garantie vervalt als je dit gebruikt. (Toen is het heel snel weer uit SBFspot verdwenen.) Ik kan de specifieke discussie niet meer vinden helaas.
Mogelijk zou ik het met een TCP piggyback met modbus ook kunnen, maar die omvormers van toen hielden er geen rekening mee dat het vermogen dagelijks vaak zou wijzigen en dus het flashmemory vaak beschreven zou worden. Dus ja, het kan, maar met risico's.

Je leest er hier meer over.

https://eliasrm.es/posts/...n-local-inverter-control/

Heb ik dat risico ook?

[Mistraller]

Pakhaas schreef op woensdag 9 september 2026 @ 16:58:
[...]

Heb ik dat risico ook?

Ik denk het wel. Want in die tijd was dynamisch je vermogen aanpassen niet aan de orde. Dus settings belanden gewoon in een EEPROM. Alleen niemand durft te zeggen of dat jarenlang goed gaat.... SMA ook niet.
Maar als je maar 1x daags dat vermogen aanpast dan zal het wel loslopen verwacht ik. Wordt een ander verhaal als je dat per 5 seconden gaat doen zoals we dat op onze thuisaccu's gewoon zijn.

[blahenazo]

Wel bij mijn fireson/ha Zendure 1.4.4 flip flopped smart mode

[Pakhaas]

Mistraller schreef op woensdag 9 september 2026 @ 17:41:
[...]

Ik denk het wel. Want in die tijd was dynamisch je vermogen aanpassen niet aan de orde. Dus settings belanden gewoon in een EEPROM. Alleen niemand durft te zeggen of dat jarenlang goed gaat.... SMA ook niet.
Maar als je maar 1x daags dat vermogen aanpast dan zal het wel loslopen verwacht ik. Wordt een ander verhaal als je dat per 5 seconden gaat doen zoals we dat op onze thuisaccu's gewoon zijn.

Ik heb afgelopen jaar 2 dagen met negatieve prijzen via een automatisering de pv geknepen naar 1% en zodra ik wat meer thuisverbruik had het weer automatisch wat vrij laten geven en terug...dus soort loadbalancing met PV om teruglevering zo laag mogelijk te houden. Dan schuift de balk geregeld heen en weer. Na die 2 dagen is het niet meer negatief geweest.

Ben er even in gedoken. Ik schrijf naar modbus.write_register
address: 40016.
Volgens chatgpt is dat veilig:

Het gebruik van register 40016 via modbus.write_register is de exact juiste methode voor de SMA Sunny Boy 5000TL-21 om dynamisch het vermogen te regelen. Dit specifieke register is door SMA ontworpen om direct in het RAM-geheugen te worden verwerkt. Hierdoor is het absoluut veilig voor cyclisch schrijven, en zal je het Flash-geheugen (EEPROM) er niet mee beschadigen

Zonder die loadbalancing is het vermogen naar 1% zodra negatief en weer op 100% zodra positief. Met de informatie die jij geeft denk ik er nu aan om die regeling wat minder streng te maken. Bovendien zal ik vanaf volgend jaar alle PV in de auto of batterijen laden en is het niet meer nodig om het vermogen te knijpen. Ik verwacht straks helemaal geen negatieve prijzen meer.

[ Voor 16% gewijzigd door Pakhaas op 09-09-2026 19:28 ]

[PeaceNlove]

offtopic:
Ik verwacht nog wel negatieve prijzen, onze energiemarkt is zo sterk verweven met de omliggende landen dat je vaak alle landen tegelijk in de min ziet duiken, dus mijn verwachting is dat we dat de komende jaren zo blijven houden

[Pakhaas]

PeaceNlove schreef op woensdag 9 september 2026 @ 19:22:

offtopic:
Ik verwacht nog wel negatieve prijzen, onze energiemarkt is zo sterk verweven met de omliggende landen dat je vaak alle landen tegelijk in de min ziet duiken, dus mijn verwachting is dat we dat de komende jaren zo blijven houden

Afgelopen jaar maar 2 dagen gehad.

[turbojonny]

In overleg met @jelleeelco kom ik een heel eind om een 800 plus en een 3000 mix AC naast elkaar overal in te voegen (ook bij Gielz). Echter het lijkt alsof de node-red van @gast777 niet weet hoe hij een 3000 mix AC op charging of discharging moet zetten. Hij pas telkens van de 3000 mix wel de output- en inputlimits aan maar hij blijft op standby. @gast777 klopt het dat de 3000 mix voor deze functie niet ondersteunt wordt of zit er gewoon nog een fout ergens?

[maartend]

Vraag.

Ik gebruik de volgende code in HA

alias: 'Batterij laden: Schakel batterij 2 bij boven 700W solar'
description: Laat batterij 2 meehelpen als de zonnepanelen meer dan 800W leveren
triggers:
- entity_id: sensor.woonkamer_p1_meter_battery_group_target_power

trigger: state

conditions: []

actions:

- choose:

- conditions:

- condition: numeric_state

entity_id: sensor.woonkamer_p1_meter_battery_group_target_power

above: 800

sequence:

- action: number.set_value

target:

entity_id: number.accu_schuur_max_charge_power

data:

value: 800

- action: number.set_value

target:

entity_id: number.accu_woonkamer_max_charge_power

data:

value: 800

- conditions:

- condition: numeric_state

entity_id: sensor.woonkamer_p1_meter_battery_group_target_power

below: 800

sequence:

- action: number.set_value

target:

entity_id: number.accu_woonkamer_max_charge_power

data:

value: 0


Echter wordt er maar 1 batterij opgeladen, en pas als deze vol zit lijkt de 2de te gaanwaar zit de fout?

P.s. er gaat iets niet goed met de spacing als ik het hier neerzet, maar die is wel in orde in de automation

[martinvdm]

maartend schreef op donderdag 10 september 2026 @ 18:21:
Vraag.

Ik gebruik de volgende code in HA

alias: 'Batterij laden: Schakel batterij 2 bij boven 700W solar'
description: Laat batterij 2 meehelpen als de zonnepanelen meer dan 800W leveren
triggers:
- entity_id: sensor.woonkamer_p1_meter_battery_group_target_power

trigger: state

conditions: []

actions:

- choose:

- conditions:

- condition: numeric_state

entity_id: sensor.woonkamer_p1_meter_battery_group_target_power

above: 800

sequence:

- action: number.set_value

target:

entity_id: number.accu_schuur_max_charge_power

data:

value: 800

- action: number.set_value

target:

entity_id: number.accu_woonkamer_max_charge_power

data:

value: 800

- conditions:

- condition: numeric_state

entity_id: sensor.woonkamer_p1_meter_battery_group_target_power

below: 800

sequence:

- action: number.set_value

target:

entity_id: number.accu_woonkamer_max_charge_power

data:

value: 0


Echter wordt er maar 1 batterij opgeladen, en pas als deze vol zit lijkt de 2de te gaanwaar zit de fout?

P.s. er gaat iets niet goed met de spacing als ik het hier neerzet, maar die is wel in orde in de automation

Zet je code ff tussen code tags. Los van de vraag omtrent de code. Waarom zou je dit willen?

[gast777]

turbojonny schreef op woensdag 9 september 2026 @ 22:11:
In overleg met @jelleeelco kom ik een heel eind om een 800 plus en een 3000 mix AC naast elkaar overal in te voegen (ook bij Gielz). Echter het lijkt alsof de node-red van @gast777 niet weet hoe hij een 3000 mix AC op charging of discharging moet zetten. Hij pas telkens van de 3000 mix wel de output- en inputlimits aan maar hij blijft op standby. @gast777 klopt het dat de 3000 mix voor deze functie niet ondersteunt wordt of zit er gewoon nog een fout ergens?

Voor zover ik weet hebben de MIX versies gewoon dezelfde relevante ZenSDK items en werkt de Gielz en de proxy gewoon ook op alle MIX modellen. Ik heb een aantal keer ook hier gelezen dat er gebruikers zijn die de proxy met de MIX devices succesvol gebruiken.

Wellicht kun je een debug naar file laten schrijven, zodat duidelijk wordt wat er precies gebeurt.

[maartend]

martinvdm schreef op donderdag 10 september 2026 @ 18:28:
[...]

Zet je code ff tussen code tags. Los van de vraag omtrent de code. Waarom zou je dit willen?

Ik had hem tussen codecrags gezet. Zag je de code tag en gaf dezelfde bende.

En waarom? Omdat nu mijn beide batterijen bij elke laad waarde gelijktijdig worden geladen, maar ik wil dat bij een laadvermogen tot 800w eerst de een wordt geladen en pas bij meer dan 800w beide worden geladen.

[turbojonny]

gast777 schreef op donderdag 10 september 2026 @ 18:42:
[...]

Voor zover ik weet hebben de MIX versies gewoon dezelfde relevante ZenSDK items en werkt de Gielz en de proxy gewoon ook op alle MIX modellen. Ik heb een aantal keer ook hier gelezen dat er gebruikers zijn die de proxy met de MIX devices succesvol gebruiken.

Wellicht kun je een debug naar file laten schrijven, zodat duidelijk wordt wat er precies gebeurt.

Bedankt voor je reactie. Zo wist ik dat de fout bij mij moest liggen. Soms is opnieuw starten een goed idee. Na alle laatste bestanden van je erin gezet te hebben en de code van @jelleeelco erin toegevoegd te hebben, gaan ze allebei aan. Hulde aan jullie + Gielz .

Komende dagen even monitoren hoe ze het samen doen (800+ en 3000 mix).

[jamiev90]

turbojonny schreef op donderdag 10 september 2026 @ 21:28:
[...]

Bedankt voor je reactie. Zo wist ik dat de fout bij mij moest liggen. Soms is opnieuw starten een goed idee. Na alle laatste bestanden van je erin gezet te hebben en de code van @jelleeelco erin toegevoegd te hebben, gaan ze allebei aan. Hulde aan jullie + Gielz .

Komende dagen even monitoren hoe ze het samen doen (800+ en 3000 mix).

Ben benieuwd hoe de combinatie met de gast 777 proxy gaat met je zendures! Ik heb dezelfde zendure combinatie (1 x 800+ en 2 x mix 3000) en heb met de Abaart proxy aardig wat opties en instelling getest om de meest optimale instelling voor mijn situatie en verbruikers te vinden.

Heb het idee dat deze proxy minder bijgehouden wordt dan de gast 777 proxy, maar ben er tevreden mee. De upper limit op 20 en de lower limit op 15 werken bij Abaart voor mij het beste. Is de gast777 proxy geschikt voor devices met verschillende vermogens? Ik was in de veronderstelling dat dit een beperking was.

[jelleeelco]

jamiev90 schreef op donderdag 10 september 2026 @ 21:38:
[...]

Ben benieuwd hoe de combinatie met de gast 777 proxy gaat met je zendures! Ik heb dezelfde zendure combinatie (1 x 800+ en 2 x mix 3000) en heb met de Abaart proxy aardig wat opties en instelling getest om de meest optimale instelling voor mijn situatie en verbruikers te vinden.

Heb het idee dat deze proxy minder bijgehouden wordt dan de gast 777 proxy, maar ben er tevreden mee. De upper limit op 20 en de lower limit op 15 werken bij Abaart voor mij het beste. Is de gast777 proxy geschikt voor devices met verschillende vermogens? Ik was in de veronderstelling dat dit een beperking was.

Ik heb de code van Gast777 schaamteloos aangepast om er 3 omvormers met verschillende capaciteiten en vermogens te kunnen aansturen.

Ik zit eraan te denken het als een soort van 'plugin' te maken om bij Gast777 te kunnen inprikken in plaats van geintegreerd in een wat oudere versie (die ik verder ook niet bijhoud want het werkt bij mij vlekkeloos).

[raven22]

turbojonny schreef op donderdag 10 september 2026 @ 21:28:
[...]

Bedankt voor je reactie. Zo wist ik dat de fout bij mij moest liggen. Soms is opnieuw starten een goed idee. Na alle laatste bestanden van je erin gezet te hebben en de code van @jelleeelco erin toegevoegd te hebben, gaan ze allebei aan. Hulde aan jullKomende dagen even monitoren hoe ze het samen doen (800+ en 3000 mix).

Waar kan ik de code van @jelleeelco vinden? Ik krijg binnenkort nog 2x 2400AC+ naast mijn SF800+.

[m-vw]

jelleeelco schreef op donderdag 10 september 2026 @ 22:38:
[...]

Ik heb de code van Gast777 schaamteloos aangepast om er 3 omvormers met verschillende capaciteiten en vermogens te kunnen aansturen.

Ik zit eraan te denken het als een soort van 'plugin' te maken om bij Gast777 te kunnen inprikken in plaats van geintegreerd in een wat oudere versie (die ik verder ook niet bijhoud want het werkt bij mij vlekkeloos).

Ik heb min of meer hetzelfde gedaan, Gielz+Gast777 als basis. Ook nog even gekeken naar wat jij mij gestuurd hebt, maar uiteindelijk iets gemaakt wat puur werkt voor mijn opstelling.

Echter sinds twee dagen last van crashes (Geheugen probleem) van mijn HA VM die enkel draait voor de batterijen. Dus moet ik eerst uitzoeken wat er de laatste dagen wezenlijk veranderd is voordat ik verder kan met wat nice to haves.

Dus nu alles in weer in HEMS van Zendure. Wilde eigenlijk de Zendure P1 meter al weghalen, maar laat hem dus nog maar even zitten als back-up.

[ Voor 7% gewijzigd door m-vw op 11-09-2026 06:52 ]

[klmtrf]

Hi, hopelijk kunnen jullie mij helpen. Dynamic trading is plotseling gestopt met werken en ik krijg het niet meer aan de praat. Ik heb de versie van Gielz geüpdatet maar helaas lost dat het probleem niet op. Als ik Quick charge gebruik laadt de batterij wel op.

Een reset van de batterij heeft ook niet geholpen. De spread staat op 50% ingesteld en met de huidige ingestelde laad en ontlaad uren wordt dit behaald. Iemand een idee?

[jelleeelco]

raven22 schreef op donderdag 10 september 2026 @ 22:43:
[...]

Waar kan ik de code van @jelleeelco vinden? Ik krijg binnenkort nog 2x 2400AC+ naast mijn SF800+.

stuur even DM

[marinadus]

Hoi allen,

Weet iemand of dit gedrag normaal is in de Gielz integratie?
Ik gebruik redelijk wat stroom en mijn zonnepanelen wekken nu niet zoveel op en de batterij zit op de minimale limiet van 10% vol. Ik zie veel entries van opladen en daarvoor veel van ontladen.

[Stefan1987]

marinadus schreef op vrijdag 11 september 2026 @ 16:46:
Hoi allen,

Weet iemand of dit gedrag normaal is in de Gielz integratie?
Ik gebruik redelijk wat stroom en mijn zonnepanelen wekken nu niet zoveel op en de batterij zit op de minimale limiet van 10% vol. Ik zie veel entries van opladen en daarvoor veel van ontladen.

[Afbeelding]

Ja dit lijkt mij normaal. Althans, het gebeurt bij mij ook elke 5 sec

[m-vw]

marinadus schreef op vrijdag 11 september 2026 @ 16:46:
Hoi allen,

Weet iemand of dit gedrag normaal is in de Gielz integratie?
Ik gebruik redelijk wat stroom en mijn zonnepanelen wekken nu niet zoveel op en de batterij zit op de minimale limiet van 10% vol. Ik zie veel entries van opladen en daarvoor veel van ontladen.

[Afbeelding]

Volstrekt normaal. Gielz past, indien nodig, iedere 5 seconde het (ont)laadvermogen van je batterij aan. Zo te zien neemt het overschot af. Dat kan zijn door meer verbruik, maar bij een reeks als deze zou het ook zo kunnen zijn dat je panelen aan het eind van de middag de zon kwijt raken. 's Ochtends zal je het omgekeerde zien.

[Fjmk]

Afgelopen week waren er 2 dagen met erg weinig zon, dus de batterij werd niet erg ver opgeladen. De de nacht volgend op die dagen zag ik het batterij percentage zakken van 10% naar 6 of 7%. Dit gebeurd een aantal minuten nadat de batterij de laadlimiet van 10% heeft bereikt en de batterij in standby wordt gezet.

Hebben jullie dit ook al ervaren? Belangrijk genoeg om een github issue in te dienen, of bij Zendure aankaarten?

[ppaulv]

Fjmk schreef op zaterdag 12 september 2026 @ 10:03:
Afgelopen week waren er 2 dagen met erg weinig zon, dus de batterij werd niet erg ver opgeladen. De de nacht volgend op die dagen zag ik het batterij percentage zakken van 10% naar 6 of 7%. Dit gebeurd een aantal minuten nadat de batterij de laadlimiet van 10% heeft bereikt en de batterij in standby wordt gezet.

Hebben jullie dit ook al ervaren? Belangrijk genoeg om een github issue in te dienen, of bij Zendure aankaarten?

Heb je het offgrid stopcontact aan staan?

[Fjmk]

ppaulv schreef op zaterdag 12 september 2026 @ 13:04:
[...]

Heb je het offgrid stopcontact aan staan?

Nee, dat staat uit en er is nietsaangesloten.

De daling vindt plaats in ongeveer 10 minuten na stand-by, en gaat dan in stappen van 1% per minuut. 10 minuten is wel de wachttijd voordat de batterij uit RAM mode gaat.

[DrNickB]

Fjmk schreef op zaterdag 12 september 2026 @ 10:03:
Afgelopen week waren er 2 dagen met erg weinig zon, dus de batterij werd niet erg ver opgeladen. De de nacht volgend op die dagen zag ik het batterij percentage zakken van 10% naar 6 of 7%. Dit gebeurd een aantal minuten nadat de batterij de laadlimiet van 10% heeft bereikt en de batterij in standby wordt gezet.

Hebben jullie dit ook al ervaren? Belangrijk genoeg om een github issue in te dienen, of bij Zendure aankaarten?

Ik ervaar dit sinds de firmware versie update van 2.0.1 en ook op 2.0.2 nu.
Bij mij lijkt het heel erg op dat het voltage op een bepaald moment erg hard zakt.
ik zet dan zelf de automatisering op standby en dan zie je even later het voltage weer oplopen
en inderdaad een minuut of 10-20 later zie je de % verder dalen.
Op de v201 was het nog iets erger als nu.

[Fjmk]

@DrNickB Ik zit ook op versie 2.02........

[Vaez]

In een issue op de Gielz github kwam er een vraag voorbij om het laden van de accu verder te optimaliseren met je eigen opbrengst van de zonnepanelen. Dit is namelijk bijna altijd goedkoper vanaf 2027. Inclusief voorspellingen zodat je niet ’s ochtends hem vollaadt uit het net omdat de stroom goedkoop is en later op de dag zonnestroom krijgt die niet meer in de accu kan omdat die vol is. Ik miste dit zelf ook en had hier een automation voor gemaakt die Solcast gebruikt om voorspellingen van de zon te gebruiken, Nordpool voor prijzen(dit doet Gielz ook al gedeeltelijk) en dan Gielz voor de batterijaansturing en het zetten van de modus. Ik heb de automation heel de week laten testen en verifiëren via Claude en een Home Assistant mcp om zoveel mogelijk scenario's af te dekken. Dit lijkt best wel goed te werken en goede resultaten te geven.

Voor degene die het ook interessant vinden zie https://github.com/christianvaes/home-assistant/blob/main/automations/accu_dagplan_en_bijplan.yaml je hebt hier Gielz, Nordpool integratie en Solcast integratie voor nodig. Ik ben hem zelf nog aan het optimaliseren elke dag als er weer een nieuw scenario komt dat niet optimaal werkt(en er blijken veel meer edge cases te zijn dan ik verwachtte).

[Pakhaas]

Vaez schreef op zondag 13 september 2026 @ 13:38:
In een issue op de Gielz github kwam er een vraag voorbij om het laden van de accu verder te optimaliseren met je eigen opbrengst van de zonnepanelen, dit is namelijk altijd gratis. Inclusief voorspellingen zodat je niet ’s ochtends hem vollaadt omdat de stroom goedkoop is en later op de dag gratis stroom krijgt die niet meer in de accu kan omdat die vol is. Ik miste dit zelf ook en had hier een automation voor gemaakt die Solcast gebruikt om voorspellingen van de zon te gebruiken, Nordpool voor prijzen(dit doet Gielz ook al gedeeltelijk) en dan Gielz voor de batterijaansturing en het zetten van de modus. Ik heb de automation heel de week laten testen en verifiëren via Claude en een Home Assistant mcp om zoveel mogelijk scenario's af te dekken. Dit lijkt best wel goed te werken en goede resultaten te geven.

Voor degene die het ook interessant vinden zie https://github.com/christianvaes/home-assistant/blob/main/automations/accu_dagplan_en_bijplan.yaml je hebt hier Gielz, Nordpool integratie en Solcast integratie voor nodig. Ik ben hem zelf nog aan het optimaliseren elke dag als er weer een nieuw scenario komt dat niet optimaal werkt(en er blijken veel meer edge cases te zijn dan ik verwachtte).

Je eigen pv opwek is niet gratis. Dat is een hardnekkig misverstand. Als je die pv niet opslaat en rechtstreeks teruglevert, krijg je daarvoor geld (dynamisch contract). Dus die waarde lever je dus in bij opslag. Niet gratis.

[Vaez]

Pakhaas schreef op zondag 13 september 2026 @ 13:45:
[...]

Je eigen pv opwek is niet gratis. Dat is een hardnekkig misverstand. Als je die pv niet opslaat en rechtstreeks teruglevert, krijg je daarvoor geld (dynamisch contract). Dus die waarde lever je dus in bij opslag. Niet gratis.

Goed punt, eigenlijk is dit een voorbereiding voor 2027 waar dit niet meer zo werkt als het salderen weg is. Ik heb ook een dynamische contract en dit zorgt ervoor dat je teruglevert op een heel goedkoop moment en eigenlijk wil je dit gebruiken uit je accu op een duur moment. In 2027 is ook nog het terugleveren veel minder interessant, waardoor het zelf gebruiken nog meer loont.

[ Voor 8% gewijzigd door Vaez op 13-09-2026 13:52 ]

[Pakhaas]

Vaez schreef op zondag 13 september 2026 @ 13:51:
[...]

Goed punt, eigenlijk is dit een voorbereiding voor 2027 waar dit niet meer zo werkt als het salderen weg is. Ik heb ook een dynamische contract en dit zorgt ervoor dat je teruglevert op een heel goedkoop moment en eigenlijk wil je dit gebruiken uit je accu op een duur moment. In 2027 is ook nog het terugleveren veel minder interessant, waardoor het zelf gebruiken nog meer loont.

Klopt, maar daar moet je dus de oppertunity costs ook meenemen. Bijv morgen ochtend 52ct incl btw en eb. Zelfs als je die niet meer terug krijgt kan het alsnog lonen om alsnog terug te leveren.

[MrBuzzkill]

Ik loop tegen een issue aan met Gielz werkende te krijgen in HA. Ik ben nog niet super bekend met HA, dus misschien doe ik iet fout. Maar ik heb het dashboard nu werkende, en ben bij de stap om de automation in te voeren. Ik plak daarvoor de automation_global.yaml waarden in een nieuwe automation. Maar bij het opslaan krijg ik error response 500. En ik kan echt niet ontdekken wat er fout is. Heeft iemand dit eerder gehad?

[ppaulv]

MrBuzzkill schreef op zondag 13 september 2026 @ 14:21:
Ik loop tegen een issue aan met Gielz werkende te krijgen in HA. Ik ben nog niet super bekend met HA, dus misschien doe ik iet fout. Maar ik heb het dashboard nu werkende, en ben bij de stap om de automation in te voeren. Ik plak daarvoor de automation_global.yaml waarden in een nieuwe automation. Maar bij het opslaan krijg ik error response 500. En ik kan echt niet ontdekken wat er fout is. Heeft iemand dit eerder gehad?

persoonlijk zou ik de yaml 'gewoon' intact laten en gebruien als 'de' hoofd-automation.
Gebruik dan dit in je configuration.yaml :

automation: !include automation_global.yaml

en hiermee

homeassistant:
packages: !include_dir_named packages
(aan het begin van de packages regel staan twee spaties, die ik hier niet meer zie)

bespaar je je een hoop moeite doordat je hierdoor een 'onbeperkt' eigen automation files en integratie files kunt plaatsen in die packages folder (die je dan dus wel even moet maken) en is het opnieuw laden van de yaml files voldoende om het werkend te krijgen.

[ Voor 3% gewijzigd door ppaulv op 13-09-2026 14:58 ]

[MrBuzzkill]

ppaulv schreef op zondag 13 september 2026 @ 14:57:
[...]

persoonlijk zou ik de yaml 'gewoon' intact laten en gebruien als 'de' hoofd-automation.
Gebruik dan dit in je configuration.yaml :

automation: !include automation_global.yaml

en hiermee

homeassistant:
packages: !include_dir_named packages
(aan het begin van de packages regel staan twee spaties, die ik hier niet meer zie)

bespaar je je een hoop moeite doordat je hierdoor een 'onbeperkt' eigen automation files en integratie files kunt plaatsen in die packages folder (die je dan dus wel even moet maken) en is het opnieuw laden van de yaml files voldoende om het werkend te krijgen.

Aaah kijk, dat lijkt nu wel te werken. Dankjewel!

[ipoffice]

Ik maak inmiddels een paar dagen dankbaar gebruik van de Gielz integratie, maar heb wat vraagtekens mbt de weergave van mijn Goodwe GW3600T-DS aangesloten op de PV-IN AC poort van een 4000 Mix AC+. Vermogen naar de accu / huis worden wel weergegeven, maar Zendure PV Passthrough blijft op PV offline staan en er wordt geen totaal opgewekte energie weergegeven. Dit is wel zichtbaar in de Zendure app.

Daarnaast valt mij op dat bij charging power alleen het vermogen wordt weergegeven dat uit het net wordt gehaald en waarschijnlijk ook hiermee de resterende laadtijd berekent?

Is dit een beperking van de integratie, heb ik iets nog niet goed staan? Inmiddels HA en de accu al herstart, maar nog geen ander gedrag. Graag jullie reactie.

[vati69]

Vandaag de integratie van Gielz in Home Assistant werkend gekregen in combinatie met de node-red flow van gast777. Ik ben erg dankbaar voor al het werk en alle info hier. Ik heb nu 3 Solarflow 800plus werkend in HA, maar ik heb ook nog 2 MIX4000AC+. Ja, een wat aparte combi, de 3 800plus had ik aangeschaft om wat te experimenteren, mede ter vervanging van 2 microomvormers met telkens 2 PV panelen). I.v.m. energieverbruik wist ik al eerder dat ik meer opslag nodig had. En toen kwam de MIX serie uit (Powerhub is nog onderweg).. Lang verhaal kort, op 2 fases elk een MIX4000AC+, op de 3e fase de 3 800plus. Door elektricien meterkast bij geplaatst in garage, daar de 2 4000AC+ vast aangesloten, de 3 800plus elk op een stopcontact. Alles conform handleidingen Zendure.

En dan nu de vraag voor advies: aangezien de flow van gast777 max 3 aparte batterijen aan kan, wat is dan wijsheid: de 2 4000AC+ via HEMS in de Zendure app en/of via de officiele Zendure integratie laten lopen en de 3 800plus via Gielz? of andersom of....? Doel is dit najaar experimenteren om vanaf 1 januari zoveel mogelijk NOM te draaien, bij voorkeur lokaal, bij voorkeur alleen via HA.

Aanvullende informatie: zowel P1monitor gebaseerd op een esp bordje werkend als de officiele zendure p1 meter in gebruik (beide via splitter werkend). DSMR 5.0 meter. Op 2 van de 3 800plus telkens 2 panelen (grofweg 700Wp per 800plus). Panelen vrijwel geheel gericht op zuiden. Daarnaast via 3 aparte "standaard" omvormers nog 39 panelen van 300Wp op vlakken zuid, oost en west). 1 van deze omvormers kan ik nog op 1 4000+ aansluiten op de "pv-ingang". zonder (toekomstige) elektrische auto's hebben we afgelopen jaren grofweg 2000 kwh op jaarbasis "tekort", dus verbruik huishouden is 2000 kwh groter dan opbrengst PV. full electric huis, A++++, L/W warmtepomp, Wpb, WTW en ook zwembad met warmtepomp, enz. Vanaf dit jaar verwacht ik een kleiner verschil i.v.m. geplaatste airco's die ook kunnen verwarmen. Maar als ik RTE van de batterijen incalculeer, kan mijn verwachting wel eens niet uit komen.

[Super Cow]

vati69 schreef op zondag 13 september 2026 @ 23:35:
En dan nu de vraag voor advies: aangezien de flow van gast777 max 3 aparte batterijen aan kan, wat is dan wijsheid: de 2 4000AC+ via HEMS in de Zendure app en/of via de officiele Zendure integratie laten lopen en de 3 800plus via Gielz? of andersom of....? Doel is dit najaar experimenteren om vanaf 1 januari zoveel mogelijk NOM te draaien, bij voorkeur lokaal, bij voorkeur alleen via HA.

Je zou ook eens naar Omnibattery kijken, die ondersteund 10 batterijen
Ik gebruik het zelf ook.

[denneappel]

2 gast777 proxies?
proxy A voor de 3 800plussen.
Proxy B voor de mixen + proxy B.

Geen idee of het kan hoor.

Als je containers draait en dat leuk vindt kan ik je ook mijn Claude proxy eens sturen. Die probeert batterijen voor minimaal 30% vermogen aan te sturen en balanceert op "tijd tot klaar op max vermogen" ipv soc. Zeker met de combi mix en plus ben ik benieuwd wat er gebeurt.

[gielz]

ipoffice schreef op zondag 13 september 2026 @ 18:00:
Ik maak inmiddels een paar dagen dankbaar gebruik van de Gielz integratie, maar heb wat vraagtekens mbt de weergave van mijn Goodwe GW3600T-DS aangesloten op de PV-IN AC poort van een 4000 Mix AC+. Vermogen naar de accu / huis worden wel weergegeven, maar Zendure PV Passthrough blijft op PV offline staan en er wordt geen totaal opgewekte energie weergegeven. Dit is wel zichtbaar in de Zendure app.

Daarnaast valt mij op dat bij charging power alleen het vermogen wordt weergegeven dat uit het net wordt gehaald en waarschijnlijk ook hiermee de resterende laadtijd berekent?

Is dit een beperking van de integratie, heb ik iets nog niet goed staan? Inmiddels HA en de accu al herstart, maar nog geen ander gedrag. Graag jullie reactie.

[Afbeelding]

Zou je de api properties eens kunnen delen zodra de zonnepanelen aan het opwekken zijn overdag? http://<IP>/properties/report

Graag via DM.

[oNo]

Vaez schreef op zondag 13 september 2026 @ 13:38:
In een issue op de Gielz github kwam er een vraag voorbij om het laden van de accu verder te optimaliseren met je eigen opbrengst van de zonnepanelen. Dit is namelijk bijna altijd goedkoper vanaf 2027. Inclusief voorspellingen zodat je niet ’s ochtends hem vollaadt uit het net omdat de stroom goedkoop is en later op de dag zonnestroom krijgt die niet meer in de accu kan omdat die vol is. Ik miste dit zelf ook en had hier een automation voor gemaakt die Solcast gebruikt om voorspellingen van de zon te gebruiken, Nordpool voor prijzen(dit doet Gielz ook al gedeeltelijk) en dan Gielz voor de batterijaansturing en het zetten van de modus. Ik heb de automation heel de week laten testen en verifiëren via Claude en een Home Assistant mcp om zoveel mogelijk scenario's af te dekken. Dit lijkt best wel goed te werken en goede resultaten te geven.

Voor degene die het ook interessant vinden zie https://github.com/christianvaes/home-assistant/blob/main/automations/accu_dagplan_en_bijplan.yaml je hebt hier Gielz, Nordpool integratie en Solcast integratie voor nodig. Ik ben hem zelf nog aan het optimaliseren elke dag als er weer een nieuw scenario komt dat niet optimaal werkt(en er blijken veel meer edge cases te zijn dan ik verwachtte).

Nice, ik ga deze binnenkort eens proberen. Die zal waarschijnlijk wat slimmer zijn dan wat ik nu heb. Al heb ik nu een vrij simpele oplossing die wellicht ook vrij is van edge cases. Het is natuurlijk voor iedere situatie anders. Ik heb 2x een SolarFlow 800 Plus en PV installatie met Growatt 4.2 kW omvormer, alles met de gielz en gast777 oplossing. Sinds gisteren heb ik de ShineLAN voor een WiLAN-X2 module vervangen (vanwege de modbus aansturing en eenvoud)
Wat ik nu doe:
- vanaf 10:00, smart charge only
- tussen 12:00 en 16:00 mag smart matching als SoC > 90%
- tussen 13:00 en 16:00 smart charge only als SoC < 80%
- vanaf 17:00 tot 18:00 quick charge only, daarna standby
- vanaf 19:00, smart matching
Met de beperkte capaciteit komt de SoC altijd op het minimum. Soms in de loop van de nacht/ochtend. Maar soms ook al ruim eerder als ik op zolder zit te indoor fietsen met de airco aan. Dus ik denk dat bovenstaande automatisering wel past.
Al wil ik tussen 16:00 en 18:00 nog wel iets maken waarbij ik smart charge of quick charge selecteer afhankelijk van de verwachte PV opbrengst.

Als ik een bestaande automatisering van iemand ga gebruiken, moet ik wel eerst een plan hebben om de verschillen goed te kunnen zien.

[ Voor 3% gewijzigd door oNo op 16-09-2026 09:23 ]

[Jan-tweak]

Pakhaas schreef op zondag 13 september 2026 @ 13:45:
[...]

Je eigen pv opwek is niet gratis. Dat is een hardnekkig misverstand. Als je die pv niet opslaat en rechtstreeks teruglevert, krijg je daarvoor geld (dynamisch contract). Dus die waarde lever je dus in bij opslag. Niet gratis.

Op zich juist, maar dat is ook maar gedeeltelijk waar bij dynamisch, bij vast is die waarde bij de meeste contracten waar de waarde slechts 0,25ct ( in 2027) bedraagt nagenoeg verwaarloosbaar.
De vraag bij dynamisch, en daar heb je wel gelijk is dat in ver uit de meeste tijd de dynamische waarde veelal op een laag punt zit terwijl de prijs op het moment dat je die stroom weer gaat gebruiken op een veel hoger punt ligt, al helemaal als je het overschot ook nog op de maximale prijs gaat verkopen.
Dus ja, de laadprijs zou je in mindering moeten brengen op de opbrengst prijs incl je laad-ontlaad verliezen.
Maar dat gaat dan wel een heel complex verhaal worden dus snap ik wel dat heel veel mensen de laadkosten gemakshalve gewoon op nul stellen. Maakt het leven en rekenen een stuk eenvoudiger.
Het voordeel ook met HA is dat het geen boekhouding is, je kasboek hoeft dus niet altijd te kloppen.
De andere kant van de medaille is wel dat je ook weet dat in de winter je eigenlijk meer gaat betalen en dan is er nauwelijks zon.

[ Voor 4% gewijzigd door Jan-tweak op 14-09-2026 11:02 ]

[ralphkeb]

Super Cow schreef op maandag 14 september 2026 @ 00:49:
[...]

Je zou ook eens naar Omnibattery kijken, die ondersteund 10 batterijen
Ik gebruik het zelf ook.

Ik heb gisteren ook Omnibattery geinstalleerd, maar kom er nog niet helemaal aan uit hoe dit precies werkt.

Had het enigszins werkend, maar het aantal relaisschakeling was niet normaal zo hoog (600 nog wat ontlaad en 300 laad schakelingen, dit kon ik nog zien in de Gielz integratie).

[Luuk741]

denneappel schreef op vrijdag 21 augustus 2026 @ 15:26:
Ik heb toevallig een weekje Helios forecast draaien. Die combineert het weer met je daadwerkelijke productie gegevens. Ik hoop er over een maandje veel betere voorspellingen mee te halen en kan onbeperkt verschillende PV sets aanmaken omdat er geen API limieten zijn. De berekeningen draaien lokaal.

Mijn doel is om straks automatisch de batterij vol te hebben aan het einde van de dag + evt extra uren te selecteren voor snel ontladen als er meer PV beschikbaar is. Leuk om te zien dat anderen daar ook mee bezig zijn.

Ik merk daarin duidelijk een verschillen tussen de modellen met DC PV en die zonder. Die extra DC PV maakt het wat lastiger om optimaal te sturen. Wel geeft het mijn 800 pro's een mooi hoog laad vermogen als je AC en DC combineert.

Hoe bevalt je deze Helios forecast integratie nu, een klein maandje later? Komen de voorspellingen dicht in de buurt van de praktijk, en zijn ze daarmee bruikbaar genoeg om op te nemen in automations rond het aansturen van de Zendure?

[burniej]

Super Cow schreef op maandag 14 september 2026 @ 00:49:
[...]

Je zou ook eens naar Omnibattery kijken, die ondersteund 10 batterijen
Ik gebruik het zelf ook.

Het is een mooie intgratie, maar wat is je doel en je gebruik je als profiel om aan te sturen?

De standaard profielen zijn nogal beperkt en lijkt er vooral op dat hij gaat laden zodra er overschot is van zonnenergie, hij kijkt niet naar de actuele en toekomstige dynamische prijs om laden uit te stelle tot de 'goedkope' uren. Zonnestroom wil ik op de goedkoopste momenten in de batterij en het extra overschot naast batterij aanvullen wil ik op duurdere momenten het net op.

Voor NOM prima maar voor 'minimum cost' niet.

[Super Cow]

burniej schreef op maandag 14 september 2026 @ 15:10:
[...]

Het is een mooie intgratie, maar wat is je doel en je gebruik je als profiel om aan te sturen?

De standaard profielen zijn nogal beperkt en lijkt er vooral op dat hij gaat laden zodra er overschot is van zonnenergie, hij kijkt niet naar de actuele en toekomstige dynamische prijs om laden uit te stelle tot de 'goedkope' uren. Zonnestroom wil ik op de goedkoopste momenten in de batterij en het extra overschot naast batterij aanvullen wil ik op duurdere momenten het net op.

Voor NOM prima maar voor 'minimum cost' niet.

Ik gebruik het als NOM, in de documentatie staat wel Dynamic Pricing mode en Real-Time Price mode maar dat heb ik zelf niet geprobeerd omdat het nvt is voor mij.

[Eboman]

Luuk741 schreef op maandag 14 september 2026 @ 12:48:
[...]

Hoe bevalt je deze Helios forecast integratie nu, een klein maandje later? Komen de voorspellingen dicht in de buurt van de praktijk, en zijn ze daarmee bruikbaar genoeg om op te nemen in automations rond het aansturen van de Zendure?

Ik heb voorlopig een hele simpele draaien en ik vind hem beter dan de ingebouwde versie. Ik zet nu accu's op smart charging in de nacht als ik niet genoeg zon ga krijgen voor die dag. Vooralsnog werkt dat voor mijn use-case (genoeg reserve) goed genoeg.

[fv]

Ik gebruik de Gielz integratie in HA met twee Zendure 3000 Mix'en ongeveer een maand, maar merk toch wel heel veel overshoot tijdens laden/ontladen waardoor je of teveel ontlaad t.o.v. huidig verbruik of teveel laad uit het net tijdens laden bij zonneovershot. Maar ook s'nacht bij vrij constant verbruik zijn er teveel (hoge) uitschieters (naar boven en beneden). Die zie je trouwens niet in het dashboard van de integratie aangezien deze een smoothing van data laten zien.
Ik gebruik overigens niet de "Dynamische" opties, puur alleen om zonneoverschot op te slaan en s'avond/s'nachts te gebruiken of voor Smart Matching.

Het systeem regelt dus, naar mijn bevinding, te laat. Ik kon dit eerst verklaren doordat de P1 data per 10 sec. verandert (wel DSMR5 meter, dus iedere 1 sec. zenden, maar nieuwe data gaat per 10 sec.:(). Na installatie van een Shelly Pro 3EM wordt de integratie getriggerd door verbruik verandering (tussen 1 a 3 sec.) of iedere 5 sec. automatisch indien geen verbruik verandering. Dit verbeterde de regeling beter, maar kan voor mijn gevoel nog beter. Heb ook wat zitten tunen aan de laad en ontlaad-factor in de laad/ontlaad routine in integratie. Is dit bovenstaande door ander gebruikers ook herkenbaar?

Tevens heb ik de integratie door Claude laten analyseren (niet geschoten altijd mis) of de logica ervan correct is. Hier kwamen wel wat belangrijke punten naar boven en na eigen analyse kan de code ook simpeler/anders op meerdere plekken.
Het beste zou zijn denk ik als de laad/ontlaad logica wordt vervangen door een goed getunde PI(D) regeling. Hier ben ik ook al mee aan het experimenteren...

[pielie8520]

Allen,

Wie heeft de oplossing, helaas kan ik niet vinden wat er nu misgaat,

Gielz integratie werkt perfect met 1 batterij,

gast777/Proxy node-red haalt wel gegevens op van de Zendure Solarflow's
Maar geeft op de debug pagina dat er geen verbinding is met HA.
Zie afbeelding (let op de debug pagina staat in NL, alles staat momenteel in EN, maar zelfde error)

[Mimiix]

pielie8520 schreef op dinsdag 15 september 2026 @ 11:30:
Allen,

Wie heeft de oplossing, helaas kan ik niet vinden wat er nu misgaat,

Gielz integratie werkt perfect met 1 batterij,

gast777/Proxy node-red haalt wel gegevens op van de Zendure Solarflow's
Maar geeft op de debug pagina dat er geen verbinding is met HA.
Zie afbeelding (let op de debug pagina staat in NL, alles staat momenteel in EN, maar zelfde error)

[Afbeelding] [Afbeelding]

[Afbeelding]

Gooi eens het lokale IP er in ? (ofwel 127.0 ofwel het ip van je machine).

[ppaulv]

FYI. M'n yaml code waarmee ik effectief spikes in de p1 meetwaardes (totale stroom af/opname) onderdruk werkt naar behoren en stabiel. Speciaal gemaakt voor de oudere 4.2 meters die niet elke seconde maar slechts iedere 10 secondes een meetwaarde sturen.
As een fors hogere / lagere meetwaarde 2x achter elkaar gezien wordt ,is het geen spike, als ie slechts 1x voorkomt wèl.
Als er interesse is wil ik de code (en handleiding) delen.
Zie plaatje van het gedrag.

De groene lijn is de alternatieve p1 sensor, de blauwe lijn m'n panelen opbrengst, de rode lijn de 'echte' p1 waarde en de gele lijn wat de accu doet.

[ Voor 36% gewijzigd door ppaulv op 15-09-2026 11:39 ]

[pielie8520]

Mimiix schreef op dinsdag 15 september 2026 @ 11:34:
[...]

Gooi eens het lokale IP er in ? (ofwel 127.0 ofwel het ip van je machine).

Excuus vergeten te vermelden

127.0.0.1 en ipadres van de HA zelf ook geprobeerd.
Resultaat hetzelfde

[Mscroos]

denneappel schreef op maandag 14 september 2026 @ 03:06:
2 gast777 proxies?
proxy A voor de 3 800plussen.
Proxy B voor de mixen + proxy B.

Geen idee of het kan hoor.

Als je containers draait en dat leuk vindt kan ik je ook mijn Claude proxy eens sturen. Die probeert batterijen voor minimaal 30% vermogen aan te sturen en balanceert op "tijd tot klaar op max vermogen" ipv soc. Zeker met de combi mix en plus ben ik benieuwd wat er gebeurt.

Ja kan, je kan de NL en EN versie naast elkaar draaien. Geef beide een aangepast P1 en je hebt volledige controle.

[denneappel]

Mscroos schreef op dinsdag 15 september 2026 @ 12:34:
[...]

Ja kan, je kan de NL en EN versie naast elkaar draaien. Geef beide een aangepast P1 en je hebt volledige controle.

Wilde je misschien op een ander bericht reageren?

[Mscroos]

denneappel schreef op dinsdag 15 september 2026 @ 12:40:
[...]


Wilde je misschien op een ander bericht reageren?

als je die 2 talen gebruikt kan je volgens mij twee proxies draaien. En ook 2x Gielz

[ Voor 4% gewijzigd door Mscroos op 15-09-2026 12:44 ]

[denneappel]

Mscroos schreef op dinsdag 15 september 2026 @ 12:43:
[...]

als je die 2 talen gebruikt kan je volgens mij twee proxies draaien. En ook 2x Gielz

Ik was niet heel duidelijk en maakt een typo zie ik nu.

proxy A voor de 3 800plussen.
Proxy B voor de mixen + proxy A

Met andere woorden.
1 Gielz integratie stuurt proxy B dus aan. Proxy B verdeelt dat onder de 2x Mix en proxy A. Proxy A verdeelt weer onder de 3x 800plus.

[fv]

ppaulv schreef op dinsdag 15 september 2026 @ 11:34:
<knip>
Als er interesse is wil ik de code (en handleiding) delen.
<knip>

Ja, graag .

[ppaulv]

OK.
Allereerst de handmatige (eenmalige) handelingen en uitleg.
Aanpassingen op de originele Gielz international automatisering:

1. De Gielz triggert elke 21 seconde, hoger mag, lager niet.
2. Alle factoren in de Gielz heb ik op 75% gezet. Wellicht zijn die niet allemaal nodig maar dat heb ik verder niet uitgezocht.
3. De hoogte van een spike heb ik gezet op 1000W, daarmee kun je spelen.
4. De alternatieve p1 meter sensor (p1_sp_el_sensor) die ik gebruik wordt beperkt in z'n maximale veranderingen. Ik heb dat nu op 500W staan.
5. Er is een template sensor (ik heb een aparte yaml file met templates)
6. Ook een rijtje helpers, waarvan de meeste gebruikt kunnen worden voor debugging, te herkennen aan 'dbg' in de naam.
7. En natuurlijk de automation zelf.

Al deze extra files heb ik in de 'packages' folder staan.

Helpers:

YAML:

input_number:

  p1_last_1:
    name: P1 last reading 1 #1
    min: -9000
    max: 9000
    step: 1
    mode: box
  p1_last_2:
    name: P1 last reading 2 #2
    min: -9000
    max: 9000
    step: 1
    mode: box

  p1_last_3:
    name: P1 last reading 3 #3
    min: -9000
    max: 9000
    step: 1
    mode: box

  p1_sp_el:
    name: P1 spike eliminated
    min: -9000
    max: 9000
    step: 1
    mode: box

  p1_dbg_new_val:
    name: P1 debug new_val
    min: -9000
    max: 9000
    step: 1
    mode: box

  p1_dbg_close_to_l1:
    name: P1 debug close_to_l1 (0/1)
    min: -9000
    max: 9000
    step: 1
    mode: box

  p1_dbg_close_to_l2:
    name: P1 debug close_to_l2 (0/1)
    min: -9000
    max: 9000
    step: 1
    mode: box

  p1_dbg_l1_eff:
    name: P1 debug l1_eff (after spike rule)
    min: -9000
    max: 9000
    step: 1
    mode: box

  p1_dbg_sp_el_unclamped:
    name: P1 debug sp_el_unclamped
    min: -9000
    max: 9000
    step: 1
    mode: box

  p1_dbg_sp_el:
    name: P1 debug sp_el (clamped)
    min: -9000
    max: 9000
    step: 1
    mode: box

  p1_dbg_spike_detected:
    name: P1 debug spike detected
    min: 0
    max: 2
    step: 1
    mode: box

Een template:

YAML:

template:
  - sensor:
      - name: p1_sp_el_sensor
        state: "{{ states('input_number.p1_sp_el') | float(0) | round(0) }}"
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement

en de automation:

YAML:

automation:
  - alias: "P1 spike elimination v8.0"
    mode: single

    trigger:
      - platform: state
        entity_id: sensor.homewizard_p1_power
        id: p1_power_trigger

      - platform: state
        entity_id: sensor.zendure_charging_mode
        id: modus_trigger

    variables:
      new_val: "{{ states('sensor.homewizard_p1_power') | float(0) }}"
      last_1: "{{ states('input_number.p1_last_1') | float(0) }}"
      last_2: "{{ states('input_number.p1_last_2') | float(0) }}"
      last_3: "{{ states('input_number.p1_last_3') | float(0) }}"
      sp_el_old: "{{ states('input_number.p1_sp_el') | float(0) }}"
      spike_range: 1000
      max_delta: 500


      nv_close_to_l1: >-
        {{ ((new_val - last_1) | abs) }}

      nv_close_to_l2: >-
        {{ ((new_val - last_2) | abs ) }}

      spike_detected: >-
        {{
          1
          if (
            ((nv_close_to_l2 | float(0)) * 2)
            < (spike_range | float(0))
            and
            (nv_close_to_l1 | float(0))
            > (spike_range | float(0))
          )
          else 0
        }}

      l1_eff: >-
        {% if spike_detected | int(0) == 1 %}
          {{ new_val | float(0) }}
        {% else %}
          {{ last_1 | float(0) }}
        {% endif %}


      sp_el_unclamped: >-
        {% if nv_close_to_l1 > spike_range %}
          {% set nv = last_1 %} 
        {% else %}
          {% set nv = new_val %}
        {% endif %}
        {% if spike_detected | int(0) == 1 %}
          {{ sp_el_old | float(0) }}
        {% else %}
          {% set solar = states('sensor.solaredge_i1_ac_power') | float(0) %}
          {{
            (
              nv 
              - solar * 0.3
            ) | round(0)
          }}
        {% endif %}

      sp_el: >-
        {% set delta = sp_el_unclamped - sp_el_old %}
        {% if delta > max_delta %}
          {{ sp_el_old + max_delta }}
        {% elif delta < -max_delta %}
          {{ sp_el_old - max_delta }}
        {% else %}
          {{ sp_el_unclamped }}
        {% endif %}

    action:

      - service: input_number.set_value
        target:
          entity_id: input_number.p1_dbg_sp_el_unclamped
        data:
          value: "{{ (sp_el_unclamped | float(0)) }}"

      - service: input_number.set_value
        target:
          entity_id: input_number.p1_dbg_sp_el
        data:
          value: "{{ (sp_el | float(0)) }}"

      - service: input_number.set_value
        target:
          entity_id: input_number.p1_dbg_new_val
        data:
          value: "{{ new_val }}"

      - service: input_number.set_value
        target:
          entity_id: input_number.p1_dbg_close_to_l2
        data:
          value: "{{ nv_close_to_l2 }}"

      - service: input_number.set_value
        target:
          entity_id: input_number.p1_dbg_close_to_l1
        data:
          value: "{{ nv_close_to_l1 }}"

      - service: input_number.set_value
        target:
          entity_id: input_number.p1_dbg_spike_detected
        data:
          value: "{{ spike_detected | int(0) }}"

      - service: input_number.set_value
        target:
          entity_id: input_number.p1_dbg_last_1
        data:
          value: "{{ last_1 }}"

      - service: input_number.set_value
        target:
          entity_id: input_number.p1_dbg_last_2
        data:
          value: "{{ last_2 }}"

      - service: input_number.set_value
        target:
          entity_id: input_number.p1_dbg_l1_eff
        data:
          value: "{{ l1_eff }}"

      - service: input_number.set_value
        target:
          entity_id: input_number.p1_last_3
        data:
          value: "{{ last_2 }}"

      - service: input_number.set_value
        target:
          entity_id: input_number.p1_last_2
        data:
          value: "{{ last_1 }}"

      - service: input_number.set_value
        target:
          entity_id: input_number.p1_last_1
        data:
          value: "{{ new_val }}"


      - service: input_number.set_value
        target:
          entity_id: input_number.p1_sp_el
        data:
          value: "{{ sp_el }}"

en nogmaals, alles waar 'dbg' in de naam staat is voor de werking niet relevant, alleen voor debugging.
Daarvoor heb ik dit in een dashboard gezet:

YAML:

type: entities
entities:
  - entity: sensor.homewizard_p1_power
  - entity: input_number.p1_last_1
  - entity: input_number.p1_last_2
  - entity: input_number.p1_last_3
  - entity: sensor.p1_sp_el_sensor
  - entity: input_number.p1_dbg_spike_detected
  - entity: input_number.p1_dbg_close_to_l1
    name: nv_close_l1
  - entity: input_number.p1_dbg_close_to_l2
    name: nv_close_l2

Succes! En ik hoor graag of het bij anderen ook netjes werkt.

[klmtrf]

klmtrf schreef op vrijdag 11 september 2026 @ 12:59:
Hi, hopelijk kunnen jullie mij helpen. Dynamic trading is plotseling gestopt met werken en ik krijg het niet meer aan de praat. Ik heb de versie van Gielz geüpdatet maar helaas lost dat het probleem niet op. Als ik Quick charge gebruik laadt de batterij wel op.

Een reset van de batterij heeft ook niet geholpen. De spread staat op 50% ingesteld en met de huidige ingestelde laad en ontlaad uren wordt dit behaald. Iemand een idee?

[Afbeelding]

[Afbeelding]

Hi, ik ben er inmiddels achter. Het was niet gestopt maar er was achter de schermen een afwijking van 2 uur.
Met behulp van Claude heb ik het (zoals het er naar uit ziet) kunnen oplossen door de zendure_gielz1986_global.yaml aan te passen.

{% set nu = now().astimezone() %}
aangepast naar
{% set nu = now() %}

[koboy]

klmtrf schreef op dinsdag 15 september 2026 @ 17:23:
[...]

Hi, ik ben er inmiddels achter. Het was niet gestopt maar er was achter de schermen een afwijking van 2 uur.
Met behulp van Claude heb ik het (zoals het er naar uit ziet) kunnen oplossen door de zendure_gielz1986_global.yaml aan te passen.

{% set nu = now().astimezone() %}
aangepast naar
{% set nu = now() %}

Is het niet een beter idee om de tijdzone in home Assistant goed te zetten? Instellingen - Systeem - Woninginformatie......

[databeestje]

burniej schreef op maandag 14 september 2026 @ 15:10:
[...]

Het is een mooie intgratie, maar wat is je doel en je gebruik je als profiel om aan te sturen?

De standaard profielen zijn nogal beperkt en lijkt er vooral op dat hij gaat laden zodra er overschot is van zonnenergie, hij kijkt niet naar de actuele en toekomstige dynamische prijs om laden uit te stelle tot de 'goedkope' uren. Zonnestroom wil ik op de goedkoopste momenten in de batterij en het extra overschot naast batterij aanvullen wil ik op duurdere momenten het net op.

Voor NOM prima maar voor 'minimum cost' niet.

Dit kan wel, hier wacht deze tot bijvoorbeeld ~11.00 om te laden als er genoeg voorspelde opwek is ten opzichte van gemiddeld huisverbruik (7d).

Dit is "Laadvertraging inschakelen". Daarnaast gebruik ik "voorspellend laden" zodat deze op goedkope uren gaat laden. Ik heb daar de "max prijs laden" en "min prijs ontladen" op 0,12 staan met een arbitrage van 0,05. Dat zijn overigens de epex prijzen van Nordpool zonder belastingen.

[ Voor 13% gewijzigd door databeestje op 15-09-2026 19:12 ]

[klmtrf]

koboy schreef op dinsdag 15 september 2026 @ 17:50:
[...]

Is het niet een beter idee om de tijdzone in home Assistant goed te zetten? Instellingen - Systeem - Woninginformatie......

Hier dacht ik ook aan maar de locatie en tijdzone staan goed.

[koboy]

klmtrf schreef op dinsdag 15 september 2026 @ 19:11:
[...]

Hier dacht ik ook aan maar de locatie en tijdzone staan goed.

Dan staat de systeem klok in het BIOS waarschijnlijk niet goed, of die van het OS. Zou daar even goed induiken, anders kun je bij elke update van Gielz opnieuw de "fix" invoeren.

[m-vw]

De oplossing van @ppaulv zal goed werken voor de 'Quookerpiek', maar waar ik tegenaan loop is de schommelingen veroorzaakt door mijn inductieplaat. Als die eenmaal op temperatuur is is er geen constante stroomvraag, maar werkt de plaat pulserend.

Als je meerdere pannen op de plaat hebt staan dan levelen die elkaar wel wat uit, maar bij één pan zie je de P1 meter continue heen en weer gaan tussen + en -.

Handmatig een basis ontlading instellen lijkt een dempend effect te hebben, maar een meer geautomatiseerde regeling heeft natuurlijk de voorkeur.

[Gramser]

Hoe lang kook je op een dag, en hoeveel “kost” je dit daadwerkelijk? Voor mij persoonlijk valt dit een beetje onder “gerommel in de marge”. Maar, als Tweaker snap ik je vraag wel weer. Hoe snel pulseert die plaat?

[Mscroos]

m-vw schreef op woensdag 16 september 2026 @ 08:24:
De oplossing van @ppaulv zal goed werken voor de 'Quookerpiek', maar waar ik tegenaan loop is de schommelingen veroorzaakt door mijn inductieplaat. Als die eenmaal op temperatuur is is er geen constante stroomvraag, maar werkt de plaat pulserend.

Als je meerdere pannen op de plaat hebt staan dan levelen die elkaar wel wat uit, maar bij één pan zie je de P1 meter continue heen en weer gaan tussen + en -.

Handmatig een basis ontlading instellen lijkt een dempend effect te hebben, maar een meer geautomatiseerde regeling heeft natuurlijk de voorkeur.

`Heb getest met m'n quooker, koffie apparaat (die is erger), vaatwasser, kookplaat en wasmachine pieken. Mijn conclusie is vooralsnog dat je heel erg moet gaan dempen om alles eruit te halen. Die pieken maken me niet zoveel uit, op en afschakelen van de accu is niet erg en gaat, als hij al aan het leveren is vrij snel. Ik ben nu vooral aan het kijken dat hij niet na een piek door de 0 valt en dent dat er teruggeleverd wordt. Daar zitten de relais clicks en de grotere vertragingen in die eigenlijk alleen maar gedempt moeten worden. Eigenlijk is de basale regel dat bij geen zonne levering en NoM bij mij thuis de terug levering nooit onder 400 Watt kan vallen.

[m-vw]

@Gramser en @Mscroos Het is natuurlijk gerommel in de marge en ik ben heel tevreden over hoe mijn regeling nu werkt.

Het valt voor mij ook een beetje onder spielerij en iets waarmee ik HA en het programmeren binnen HA meer onder de knie zou kunnen krijgen.

[ppaulv]

Mscroos schreef op woensdag 16 september 2026 @ 09:54:
[...]

`Heb getest met m'n quooker, koffie apparaat (die is erger), vaatwasser, kookplaat en wasmachine pieken. Mijn conclusie is vooralsnog dat je heel erg moet gaan dempen om alles eruit te halen. Die pieken maken me niet zoveel uit, op en afschakelen van de accu is niet erg en gaat, als hij al aan het leveren is vrij snel. Ik ben nu vooral aan het kijken dat hij niet na een piek door de 0 valt en dent dat er teruggeleverd wordt. Daar zitten de relais clicks en de grotere vertragingen in die eigenlijk alleen maar gedempt moeten worden. Eigenlijk is de basale regel dat bij geen zonne levering en NoM bij mij thuis de terug levering nooit onder 400 Watt kan vallen.

Inderdaad, pieken die langer dan eenmalig zijn worden niet als piek gezien en daar gaat het systeem op reageren met mijn code. Zie plaatje, ik was toen aan het koken (inductie dus, 1 plaat in gebruik). In het plaatje zie je geen activiteit van de accu omdat ie toen al vol was en ik geen NOM had ingesteld. Anders zou ie constant aan-uit-aan-uit gaan leveren. En dat wil ik niet dus zet ik 'm om 17.00 uur op standby en pas om 19.00 op 'smart discharge only'. En in de ochtend als de zon net begint op te komen idem dito.

[Mistraller]

Gramser schreef op woensdag 16 september 2026 @ 08:49:
Hoe lang kook je op een dag, en hoeveel “kost” je dit daadwerkelijk? Voor mij persoonlijk valt dit een beetje onder “gerommel in de marge”. Maar, als Tweaker snap ik je vraag wel weer. Hoe snel pulseert die plaat?

Dat pulseren zie ik met onze plaat niet hoor. Ik heb zelf het idee dat je met al dat gefilter het hele bestaansrecht van je accu wegneemt.
Verbruik in de keuken is in de zomer een fors deel van mijn stroomverbruik in elk geval.

[Gramser]

Ik meet onze kookplaat niet apart (maar kan ‘m wel horen “aanslaan” als ik aan het koken ben. M’n zendures reageren daar best netjes op. En niet alle pitten pulseren gelijk dus als je er meer dan een aan hebt -ik meestal twee of drie- zie je op het grote geheel gewoon dat de zendure vrij constant zijn vermogen levert. Voor mij dus niet de moeite om daar lang bij stil te staan.

[ppaulv]

Mistraller schreef op woensdag 16 september 2026 @ 11:50:
[...]

Dat pulseren zie ik met onze plaat niet hoor. Ik heb zelf het idee dat je met al dat gefilter het hele bestaansrecht van je accu wegneemt.
Verbruik in de keuken is in de zomer een fors deel van mijn stroomverbruik in elk geval.

Dat is niet voor iedereen zo denk ik, voor mij iig niet. Het hangt helemaal af van de reden/het doel waarom je 'm hebt. Als dat 'NOM' is, minimaal stroomverbruik uit het grid, dan heb je volledig gelijk, maar kun je dat alleen realiseren met een DSMR 5 meter lijkt me.
Mijn reden / doel voor m'n accu is zo'n 80% daarvan, wat met relatief weinig kunstgrepen te realiseren is (ik heb zo'n 4.2 meter). En als ik nu het ding standby zet tijdens de chaotische tijden in de ochtend en avond (koken e.d. want daarvan gaat ie in de stress) dan heb ik net genoeg capaciteit om de nacht door te komen. Om ook de kook-periode te kunnen opvangen zou ik dan een uitbreiding moeten aanschaffen en zolang ik geen versie 5 meter heb is dat zinloos. Of ik moet weer gaan werken met CT klemmen maar dat ga ik niet doen.

[Gramser]

m-vw schreef op woensdag 16 september 2026 @ 10:17:
@Gramser en @Mscroos Het is natuurlijk gerommel in de marge en ik ben heel tevreden over hoe mijn regeling nu werkt.

Het valt voor mij ook een beetje onder spielerij en iets waarmee ik HA en het programmeren binnen HA meer onder de knie zou kunnen krijgen.

Ik snap dat helemaal. Zo ben ik zelf bezig om mijn Peblar laadpaal en zendures samen te laten werken zonder dat ze elkaar bijten - en zonder iets als evcc. Dat begint al ergens op te lijken, en dat is voor mij ook oefenen in HA (en Chat en Claude 😉)

[mitsumark]

Gramser schreef op woensdag 16 september 2026 @ 13:32:
[...]

Ik snap dat helemaal. Zo ben ik zelf bezig om mijn Peblar laadpaal en zendures samen te laten werken zonder dat ze elkaar bijten - en zonder iets als evcc. Dat begint al ergens op te lijken, en dat is voor mij ook oefenen in HA (en Chat en Claude 😉)

Ik heb dat zelf ook op de planning staan komende maand(en), hou ons op de hoogte.

[Acidrain]

ppaulv schreef op dinsdag 15 september 2026 @ 15:07:
OK.
Allereerst de handmatige (eenmalige) handelingen en uitleg.
Aanpassingen op de originele Gielz international automatisering:

1. De Gielz triggert elke 21 seconde, hoger mag, lager niet.
2. Alle factoren in de Gielz heb ik op 75% gezet. Wellicht zijn die niet allemaal nodig maar dat heb ik verder niet uitgezocht.
3. De hoogte van een spike heb ik gezet op 1000W, daarmee kun je spelen.
4. De alternatieve p1 meter sensor (p1_sp_el_sensor) die ik gebruik wordt beperkt in z'n maximale veranderingen. Ik heb dat nu op 500W staan.
5. Er is een template sensor (ik heb een aparte yaml file met templates)
6. Ook een rijtje helpers, waarvan de meeste gebruikt kunnen worden voor debugging, te herkennen aan 'dbg' in de naam.
7. En natuurlijk de automation zelf.

Al deze extra files heb ik in de 'packages' folder staan.

Helpers:

YAML:

input_number:

  p1_last_1:
    name: P1 last reading 1 #1
    min: -9000
    max: 9000
    step: 1
    mode: box
  p1_last_2:
    name: P1 last reading 2 #2
    min: -9000
    max: 9000
    step: 1
    mode: box

  p1_last_3:
    name: P1 last reading 3 #3
    min: -9000
    max: 9000
    step: 1
    mode: box

  p1_sp_el:
    name: P1 spike eliminated
    min: -9000
    max: 9000
    step: 1
    mode: box

  p1_dbg_new_val:
    name: P1 debug new_val
    min: -9000
    max: 9000
    step: 1
    mode: box

  p1_dbg_close_to_l1:
    name: P1 debug close_to_l1 (0/1)
    min: -9000
    max: 9000
    step: 1
    mode: box

  p1_dbg_close_to_l2:
    name: P1 debug close_to_l2 (0/1)
    min: -9000
    max: 9000
    step: 1
    mode: box

  p1_dbg_l1_eff:
    name: P1 debug l1_eff (after spike rule)
    min: -9000
    max: 9000
    step: 1
    mode: box

  p1_dbg_sp_el_unclamped:
    name: P1 debug sp_el_unclamped
    min: -9000
    max: 9000
    step: 1
    mode: box

  p1_dbg_sp_el:
    name: P1 debug sp_el (clamped)
    min: -9000
    max: 9000
    step: 1
    mode: box

  p1_dbg_spike_detected:
    name: P1 debug spike detected
    min: 0
    max: 2
    step: 1
    mode: box

Een template:

YAML:

template:
  - sensor:
      - name: p1_sp_el_sensor
        state: "{{ states('input_number.p1_sp_el') | float(0) | round(0) }}"
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement

en de automation:

YAML:

automation:
  - alias: "P1 spike elimination v8.0"
    mode: single

    trigger:
      - platform: state
        entity_id: sensor.homewizard_p1_power
        id: p1_power_trigger

      - platform: state
        entity_id: sensor.zendure_charging_mode
        id: modus_trigger

    variables:
      new_val: "{{ states('sensor.homewizard_p1_power') | float(0) }}"
      last_1: "{{ states('input_number.p1_last_1') | float(0) }}"
      last_2: "{{ states('input_number.p1_last_2') | float(0) }}"
      last_3: "{{ states('input_number.p1_last_3') | float(0) }}"
      sp_el_old: "{{ states('input_number.p1_sp_el') | float(0) }}"
      spike_range: 1000
      max_delta: 500


      nv_close_to_l1: >-
        {{ ((new_val - last_1) | abs) }}

      nv_close_to_l2: >-
        {{ ((new_val - last_2) | abs ) }}

      spike_detected: >-
        {{
          1
          if (
            ((nv_close_to_l2 | float(0)) * 2)
            < (spike_range | float(0))
            and
            (nv_close_to_l1 | float(0))
            > (spike_range | float(0))
          )
          else 0
        }}

      l1_eff: >-
        {% if spike_detected | int(0) == 1 %}
          {{ new_val | float(0) }}
        {% else %}
          {{ last_1 | float(0) }}
        {% endif %}


      sp_el_unclamped: >-
        {% if nv_close_to_l1 > spike_range %}
          {% set nv = last_1 %} 
        {% else %}
          {% set nv = new_val %}
        {% endif %}
        {% if spike_detected | int(0) == 1 %}
          {{ sp_el_old | float(0) }}
        {% else %}
          {% set solar = states('sensor.solaredge_i1_ac_power') | float(0) %}
          {{
            (
              nv 
              - solar * 0.3
            ) | round(0)
          }}
        {% endif %}

      sp_el: >-
        {% set delta = sp_el_unclamped - sp_el_old %}
        {% if delta > max_delta %}
          {{ sp_el_old + max_delta }}
        {% elif delta < -max_delta %}
          {{ sp_el_old - max_delta }}
        {% else %}
          {{ sp_el_unclamped }}
        {% endif %}

    action:

      - service: input_number.set_value
        target:
          entity_id: input_number.p1_dbg_sp_el_unclamped
        data:
          value: "{{ (sp_el_unclamped | float(0)) }}"

      - service: input_number.set_value
        target:
          entity_id: input_number.p1_dbg_sp_el
        data:
          value: "{{ (sp_el | float(0)) }}"

      - service: input_number.set_value
        target:
          entity_id: input_number.p1_dbg_new_val
        data:
          value: "{{ new_val }}"

      - service: input_number.set_value
        target:
          entity_id: input_number.p1_dbg_close_to_l2
        data:
          value: "{{ nv_close_to_l2 }}"

      - service: input_number.set_value
        target:
          entity_id: input_number.p1_dbg_close_to_l1
        data:
          value: "{{ nv_close_to_l1 }}"

      - service: input_number.set_value
        target:
          entity_id: input_number.p1_dbg_spike_detected
        data:
          value: "{{ spike_detected | int(0) }}"

      - service: input_number.set_value
        target:
          entity_id: input_number.p1_dbg_last_1
        data:
          value: "{{ last_1 }}"

      - service: input_number.set_value
        target:
          entity_id: input_number.p1_dbg_last_2
        data:
          value: "{{ last_2 }}"

      - service: input_number.set_value
        target:
          entity_id: input_number.p1_dbg_l1_eff
        data:
          value: "{{ l1_eff }}"

      - service: input_number.set_value
        target:
          entity_id: input_number.p1_last_3
        data:
          value: "{{ last_2 }}"

      - service: input_number.set_value
        target:
          entity_id: input_number.p1_last_2
        data:
          value: "{{ last_1 }}"

      - service: input_number.set_value
        target:
          entity_id: input_number.p1_last_1
        data:
          value: "{{ new_val }}"


      - service: input_number.set_value
        target:
          entity_id: input_number.p1_sp_el
        data:
          value: "{{ sp_el }}"

en nogmaals, alles waar 'dbg' in de naam staat is voor de werking niet relevant, alleen voor debugging.
Daarvoor heb ik dit in een dashboard gezet:

YAML:

type: entities
entities:
  - entity: sensor.homewizard_p1_power
  - entity: input_number.p1_last_1
  - entity: input_number.p1_last_2
  - entity: input_number.p1_last_3
  - entity: sensor.p1_sp_el_sensor
  - entity: input_number.p1_dbg_spike_detected
  - entity: input_number.p1_dbg_close_to_l1
    name: nv_close_l1
  - entity: input_number.p1_dbg_close_to_l2
    name: nv_close_l2

Succes! En ik hoor graag of het bij anderen ook netjes werkt.

Ik heb het simpeler opgelost met het zelfde resultaat. (Veel simpeler )

Ik heb een helper aangemaakt die de quooker weg filtert.
Onder helpers:
Helper aanmaken en kies Filter
Naam: P1 Meter Power Filtered
Entiteit: P1 Power
Filter: Uitschieter
*Verzenden klikken*
Venstergrootte: 4
Straal: 1200
Precisie: 0
*Verzenden klikken*
Klaar

Deze sensor stel je dan in als p1 meter in je zendure configuratie en klaar.

yaml van bovenstaande mocht je het in je configuration.yaml willen zetten:

YAML:

sensor:
  - platform: filter
    name: "P1 Meter Power Filtered"
    unique_id: p1_meter_power_filtered_outlier
    entity_id: sensor.p1_meter_power
    filters:
      - filter: outlier
        window_size: 4
        radius: 1200

[databeestje]

Gramser schreef op woensdag 16 september 2026 @ 13:32:
[...]

Ik snap dat helemaal. Zo ben ik zelf bezig om mijn Peblar laadpaal en zendures samen te laten werken zonder dat ze elkaar bijten - en zonder iets als evcc. Dat begint al ergens op te lijken, en dat is voor mij ook oefenen in HA (en Chat en Claude 😉)

Ik gebruik OmniBattery en heb daar onder "excluded devices" de Peblar staan, je kan dan configureren wat deze aan de hand van de Power Sensor moet doen. Ik zet de batterij op pauze, maar je kan ook het vermogen negeren en huis verbruik laten dekken. Ik gebruik deze overdag in Puur Solar, en in de nacht op normaal of tijdens goedkope uren met een normale HA automation + Cheapest Energy Windows

[ppaulv]

Acidrain schreef op woensdag 16 september 2026 @ 14:38:
[...]

Ik heb het simpeler opgelost met het zelfde resultaat. (Veel simpeler )

Ik heb een helper aangemaakt die de quooker weg filtert.
Onder helpers:
Helper aanmaken en kies Filter
Naam: P1 Meter Power Filtered
Entiteit: P1 Power
Filter: Uitschieter
*Verzenden klikken*
Venstergrootte: 4
Straal: 1200
Precisie: 0
*Verzenden klikken*
Klaar

Deze sensor stel je dan in als p1 meter in je zendure configuratie en klaar.

yaml van bovenstaande mocht je het in je configuration.yaml willen zetten:

YAML:

sensor:
  - platform: filter
    name: "P1 Meter Power Filtered"
    unique_id: p1_meter_power_filtered_outlier
    entity_id: sensor.p1_meter_power
    filters:
      - filter: outlier
        window_size: 4
        radius: 1200

een wereld, wat zeg ik, een universum van onbegrip gaat voor me open .....
Nu ben ik hier al maanden mee bezig en dankzij AI werd het steeds ingewikkelder. Nu heb ik er zelf al de meeste ballast uit gehaald maar zo afgrijselijk simpel als dit had ik 'm niet verwacht.
Nu weet ik niet of ie effectief precies hetzelfde doet maar het lijkt er wel op.
I stand corrected .....

[m-vw]

Gramser schreef op woensdag 16 september 2026 @ 13:32:
[...]

Ik snap dat helemaal. Zo ben ik zelf bezig om mijn Peblar laadpaal en zendures samen te laten werken zonder dat ze elkaar bijten - en zonder iets als evcc. Dat begint al ergens op te lijken, en dat is voor mij ook oefenen in HA (en Chat en Claude 😉)

Dat ken ik. Ik heb een Alfenpaal en die heeft als beperking dat het of HA of de app/cloud is. Dat maakt het proberen heel vervelend omdat ik bij ieder switch de paal moet resetten.

[Acidrain]

ppaulv schreef op woensdag 16 september 2026 @ 15:47:
[...]

een wereld, wat zeg ik, een universum van onbegrip gaat voor me open .....
Nu ben ik hier al maanden mee bezig en dankzij AI werd het steeds ingewikkelder. Nu heb ik er zelf al de meeste ballast uit gehaald maar zo afgrijselijk simpel als dit had ik 'm niet verwacht.
Nu weet ik niet of ie effectief precies hetzelfde doet maar het lijkt er wel op.
I stand corrected .....

Ik speelde al heel lang met de gedachte om pieken weg te filteren, daarnaast heb ik een Eddi van MyEnergy die een boiler verwarmt met behulp van een Harvi en CT klemmen en die zat de Zendure ook behoorlijk in de weg.

Die Eddi heb ik opgelost door als die op laden springt (Status in HA) tegen Zendure te zeggen ga maar handmatig ontladen met een vaste waarde van 200W (ongeveer mijn huis last).
Dat zorgde er voor dat die niet bij elk wolkje heel erg gingen pingelen met elkaar en de Zendure ook niet rond de 0 bleef schakelen.

De Quooker moet ik heel eerlijk toegeven dat ik daar vanmorgen Claude op los gelaten heb en die kwam eigenlijk meteen met deze oplossing
Alle korte pieken hoger dan 1200 watt worden hiermee genegeerd of op zn minst afgeschaafd en langere loads boven de 1200 watt worden wel opgevangen maar dan met iets vertraging.

[Mistraller]

ppaulv schreef op woensdag 16 september 2026 @ 12:29:
[...]

Dat is niet voor iedereen zo denk ik, voor mij iig niet. Het hangt helemaal af van de reden/het doel waarom je 'm hebt. Als dat 'NOM' is, minimaal stroomverbruik uit het grid, dan heb je volledig gelijk, maar kun je dat alleen realiseren met een DSMR 5 meter lijkt me.
Mijn reden / doel voor m'n accu is zo'n 80% daarvan, wat met relatief weinig kunstgrepen te realiseren is (ik heb zo'n 4.2 meter). En als ik nu het ding standby zet tijdens de chaotische tijden in de ochtend en avond (koken e.d. want daarvan gaat ie in de stress) dan heb ik net genoeg capaciteit om de nacht door te komen. Om ook de kook-periode te kunnen opvangen zou ik dan een uitbreiding moeten aanschaffen en zolang ik geen versie 5 meter heb is dat zinloos. Of ik moet weer gaan werken met CT klemmen maar dat ga ik niet doen.

Ik draai NOM op een DSMR4. Dat gaat best goed. Natuurlijk kan het strakker, ben ik met je eens, maar als er genoeg PV aanbod is, dan is het netto altijd minder dan 1kWh. Maar ook de bruto cijfers vond ik verrassend goed. Het is met een 10 seconden window natuurlijk ook niet zo dat je altijd 10 seconden achterloopt, dat is de maximale waarde. Dus soms is de accu laat met bijspringen of afschalen, maar dat kan ook soms net zo snel als met een dsmr5 zijn.
Ik heb nu voldoende capaciteit om, indien vol, de hele dag te kunnen afdekken, ook qua vermogen. Alleen moet er nog wat PV bij
Ik probeer juist zo min mogelijk in de accu sturing te doen, want alle custom code moet ook beheerd worden, en ik heb het idee dat het centenwerk is in wat ik nog zou kunnen doen.

Maar inderdaad, geen huishouden hetzelfde, alleen maar mooi toch dat je het zo per persoon kunt inrichten hoe je precies wilt

[ppaulv]

Acidrain schreef op woensdag 16 september 2026 @ 16:10:
[...]

Ik speelde al heel lang met de gedachte om pieken weg te filteren, daarnaast heb ik een Eddi van MyEnergy die een boiler verwarmt met behulp van een Harvi en CT klemmen en die zat de Zendure ook behoorlijk in de weg.

Die Eddi heb ik opgelost door als die op laden springt (Status in HA) tegen Zendure te zeggen ga maar handmatig ontladen met een vaste waarde van 200W (ongeveer mijn huis last).
Dat zorgde er voor dat die niet bij elk wolkje heel erg gingen pingelen met elkaar en de Zendure ook niet rond de 0 bleef schakelen.

De Quooker moet ik heel eerlijk toegeven dat ik daar vanmorgen Claude op los gelaten heb en die kwam eigenlijk meteen met deze oplossing
Alle korte pieken hoger dan 1200 watt worden hiermee genegeerd of op zn minst afgeschaafd en langere loads boven de 1200 watt worden wel opgevangen maar dan met iets vertraging.

ik realiseer me dat ik na jaren als IT-er tegen opdrachtgevers/superusers zeggen : 'je moet geen functionaliteit in termen van oplossingen benoemen maar zeggen wat je in de basis nodig hebt', ik steeds letterlijk aan AI gevraagd heb hoe een bepaalde oplossing syntactisch correct geschreven moest worden. Fout - fout - fout ....

[Acidrain]

@ppaulv

Hij doet wat hij moet doen, hier een voorbeeld, P1 tegen P1 filtered
15:44 de Quooker spike

[ppaulv]

Acidrain schreef op woensdag 16 september 2026 @ 16:21:
@ppaulv

[Afbeelding]Hij doet wat hij moet doen, hier een voorbeeld, P1 tegen P1 filtered
15:44 de Quooker spike

ik zag het bij mezelf al gebeuren ja. Netjes.
Heb jij nog iets aangepast bij de Gielz factoren? Dat heb ik wel gedaan op zeker moment omdat het heel zenuwachtig gedrag veroorzaakte, maar dat was in combinatie met mijn (andere) p1 filtering.

[Acidrain]

ppaulv schreef op woensdag 16 september 2026 @ 16:49:
[...]

ik zag het bij mezelf al gebeuren ja. Netjes.
Heb jij nog iets aangepast bij de Gielz factoren? Dat heb ik wel gedaan op zeker moment omdat het heel zenuwachtig gedrag veroorzaakte, maar dat was in combinatie met mijn (andere) p1 filtering.

Ik zit nog op de Fireson integratie en voor zover ik weet kan ik daar niets aan aanpassen

[marinadus]

Vraagje over de Gielz integratie.

Momenteel gebruik ik de modus nul op de meter wat in de basis prima werkt.
Echter wil ik dat de batterij snel gaat opladen als de huidige stroomprijs 0,00 is.
En dat hij stroom uit de batterij pas gaat gebruiken als de huidige stroomprijs hoger is dan x bijv. €0,30.

Kunnen jullie eens meedenken hoe dit optimaal in te richten? Wellicht is dit al een andere modus?
Ik wil dus iets meer controle. Mijn zonnepanelen wekken te weinig op om nul op de meter te halen dus wil ik het optimaal inzetten en dus extra laden als de stroom goedkoop is en pas ontladen als het huis het nodig heeft als de huidige stroomprijs boven de x ligt.

[m-vw]

@Acidrain super handige helper.
Één vraag: ik heb meerdere p1 vermogenssensoren waaronder die jij gebruikt.

Ik zie die andere sneller reageren dan p1_meter_vermogen. Nog een speciale reden om voor de te kiezen?

[Acidrain]

m-vw schreef op woensdag 16 september 2026 @ 22:05:
@Acidrain super handige helper.
Één vraag: ik heb meerdere p1 vermogenssensoren waaronder die jij gebruikt.

Ik zie die andere sneller reageren dan p1_meter_vermogen. Nog een speciale reden om voor de te kiezen?

Ik gebruik hem sinds gister morgen en ben nog niet in andere opties gedoken.

Deze heeft 4 ijkpunten en werkt met een mediaan.
Zou hij sneller reageren dan pakt hij de Quooker spike weer mee.

[Gramser]

marinadus schreef op woensdag 16 september 2026 @ 21:53:
Vraagje over de Gielz integratie.

Momenteel gebruik ik de modus nul op de meter wat in de basis prima werkt.
Echter wil ik dat de batterij snel gaat opladen als de huidige stroomprijs 0,00 is.
En dat hij stroom uit de batterij pas gaat gebruiken als de huidige stroomprijs hoger is dan x bijv. €0,30.

Kunnen jullie eens meedenken hoe dit optimaal in te richten? Wellicht is dit al een andere modus?
Ik wil dus iets meer controle. Mijn zonnepanelen wekken te weinig op om nul op de meter te halen dus wil ik het optimaal inzetten en dus extra laden als de stroom goedkoop is en pas ontladen als het huis het nodig heeft als de huidige stroomprijs boven de x ligt.

Ik neem aan dat je dynamische tarieven hebt - maak je al gebruik van de het dynamische blokje met de Nordpoolsensor in de automatisering en het dashboard? Die is speciaal gemaakt voor dynamische tarieven, en dan kun je ook gebruik maken van de verschillende strategieën die Gielz biedt.

[Gramser]

Overigens, iets anders: ik heb nu nog een vast contract maar wil eigenlijk al overstappen naar dynamisch. Opzegboete is twee tientjes, kan ik mee leven. Zou vanaf januari ingaan dan. Is er eigenlijk een mogelijkheid om die Nordpoolsensor al "aan te zetten" om gewoon te kunnen zien wat dure en goedkope uren zijn? Dan gaat het een beetje voor me leven, en kan ik gaan nadenken over wanneer auto te laden en zo.