Zendure producten in Home Assistant integreren deel 2

[ppaulv]

Pakhaas schreef op woensdag 24 juni 2026 @ 15:31:
@raven22 waar ik nog even benieuwd naar ben. Wat gebeurd er als er voldoende stroom van het dak komt om de quooker met 2200w te voeden. Dan wil je dat niet wegfilteren want de pv stroom is snel genoeg voor die korte pieken.

Stel er komt 3000w van PV, Huis 300w en Quooker 2200w. Dan ziet P1 meter -500w. Je levert dus nog steeds 500w terug in werkelijkheid.
Maar als je die quooker gaat wegfilteren dan denkt Zendure dat er -2700w wordt terug geleverd.

Het mooiste is dat je quooker gebruik alleen gaat wegfilteren bij (gedeetelijke) net afname en niet bij teruglevering.

code:

gefilterde_quooker = min(P1, Quooker)
resultaat = P1 - gefilterde_quooker

Dan filter je nooit meer Quooker weg dan daadwerkelijk als netafname zichtbaar is

Zelf heb ik nu een template sensor gemaakt met deze jinja:

code:

{% set p1 = states('sensor.p1_meter_vermogen') | float(0) %}
{% set quooker = states('sensor.quooker_huidig_gebruik') | float(0) %}

{% if quooker < 500 %}
  {% set quooker = 0 %}
{% endif %}

{% if now().hour == 5 and now().minute < 20 %}
  {{ p1 | round(0) }}
{% else %}
  {% set gefilterde_quooker = [p1, quooker] | min %}
  {{ (p1 - gefilterde_quooker) | round(0) }}
{% endif %}

Hiermee geldt:

05:00 t/m 05:19:59 → Quooker wordt niet weggefilterd, batterij mag helpen.
Alle andere tijden → Quooker wordt alleen weggefilterd voor zover die netafname veroorzaakt.
Zonnepanelen mogen de Quooker altijd voeden zonder dat de batterij onnodig gaat reageren.

is dat gelijk aan:
resultaat = max(P1 - Quooker, 0)

?

[Pakhaas]

ppaulv schreef op woensdag 24 juni 2026 @ 15:55:
[...]

is dat gelijk aan:
resultaat = max(P1 - Quooker, 0)

?

Ik begrijp je vraag niet

[ppaulv]

Pakhaas schreef op woensdag 24 juni 2026 @ 16:01:
[...]

Ik begrijp je vraag niet

geeft dit hetzelfde resultaat als :
gefilterde_quooker = min(P1, Quooker)
resultaat = P1 - gefilterde_quooker

?

[Pakhaas]

ppaulv schreef op woensdag 24 juni 2026 @ 16:04:
[...]

geeft dit hetzelfde resultaat als :
gefilterde_quooker = min(P1, Quooker)
resultaat = P1 - gefilterde_quooker

?

Nee, niet helemaal. Bij teruglevering (negatieve P1-waarden) geeft min(P1, Quooker) een verkeerd resultaat. Je moet de filtering begrenzen op minimaal 0 W, bijvoorbeeld met min(0, P1, Quooker) of equivalent, zodat negatieve P1-waarden ongemoeid blijven.

[ppaulv]

Pakhaas schreef op woensdag 24 juni 2026 @ 16:06:
[...]

Nee, niet helemaal. Bij teruglevering (negatieve P1-waarden) geeft min(P1, Quooker) een verkeerd resultaat. Je moet de filtering begrenzen op minimaal 0 W, bijvoorbeeld met min(0, P1, Quooker) of equivalent, zodat negatieve P1-waarden ongemoeid blijven.

Dat is heel smooth natuurlijk. Heb hetzelfde probleem en zoiets als dit ga ik zeker nog een keer maken.
Maar ik denk dat er 2 problemen zijn?
Ten eerste de traagheid van de p1 meter (DSMR 4.2 heb ik ....) en de traagheid van de accu. En persoonlijk zou ik deze logica gebruiken ter voorkoming van onnodig flipperen of veel te laat ergens op reageren terwijl het al historie is, En niet zoeer om die paar seconden dat onnodig aan het net geleverd wordt. Dus voor mij zou het prachtig zijn als de Zendure gewoon pieken zoals die van de quooker negeert. Tot nu toe heb ik echter geen echte oplossing daarvoor gezien die niet (!) de individuele apparaten monitort (dus met een kWh metertje (in een smart switch) aan elk apparaat).
Nu gaat het om een heel beperkt aantal dus het is te overzien.

[Pakhaas]

ppaulv schreef op woensdag 24 juni 2026 @ 16:28:
[...]

Dat is heel smooth natuurlijk. Heb hetzelfde probleem en zoiets als dit ga ik zeker nog een keer maken.
Maar ik denk dat er 2 problemen zijn?
Ten eerste de traagheid van de p1 meter (DSMR 4.2 heb ik ....) en de traagheid van de accu. En persoonlijk zou ik deze logica gebruiken ter voorkoming van onnodig flipperen of veel te laat ergens op reageren terwijl het al historie is, En niet zoeer om die paar seconden dat onnodig aan het net geleverd wordt. Dus voor mij zou het prachtig zijn als de Zendure gewoon pieken zoals die van de quooker negeert. Tot nu toe heb ik echter geen echte oplossing daarvoor gezien die niet (!) de individuele apparaten monitort (dus met een kWh metertje (in een smart switch) aan elk apparaat).
Nu gaat het om een heel beperkt aantal dus het is te overzien.

Hier een snelle meter. Het enige wat ik zie dat als de quooker aanspringt dat het dan 2sec duurt voordat de sensor dit corrigeert, maar ik denk voor Gielz snel genoeg. Dit jaar doe ik nog dynamisch handelen, dus nu nog niet aan de orde maar vanaf volgend jaar wel.

[Mistraller]

Pakhaas schreef op woensdag 24 juni 2026 @ 15:31:
@raven22 waar ik nog even benieuwd naar ben. Wat gebeurd er als er voldoende stroom van het dak komt om de quooker met 2200w te voeden. Dan wil je dat niet wegfilteren want de pv stroom is snel genoeg voor die korte pieken.

PV is wel snel genoeg maar tegen de tijd dat de automation+zendure heeft gereageerd op die verbruikspiek van de quooker (dus even wat minder batterij opladen) dan is de quooker al weer weg en heb je een overshoot teruglevering toch? Het zijn met name die heel korte bijwarm-pieken.

Je kunt een langere quookertijd verwachten als er ook echt water getapt wordt, dan zou je een watermeter moeten gebruiken.
Blijft denk toch een lastige. Je zou nog liever zien dat de Quooker pas bij bijv 85 graden bijwarmt en dan tot 98 gaat. Of instelbaar maken of zo. De warmste bel water stijgt toch op dus de eerste scheut water is écht wel heet... Maar goed, dit is niet het grote quooker topic

[raven22]

Pakhaas schreef op woensdag 24 juni 2026 @ 15:31:
@raven22 waar ik nog even benieuwd naar ben. Wat gebeurd er als er voldoende stroom van het dak komt om de quooker met 2200w te voeden. Dan wil je dat niet wegfilteren want de pv stroom is snel genoeg voor die korte pieken.

Stel er komt 3000w van PV, Huis 300w en Quooker 2200w. Dan ziet P1 meter -500w. Je levert dus nog steeds 500w terug in werkelijkheid.
Maar als je die quooker gaat wegfilteren dan denkt Zendure dat er -2700w wordt terug geleverd.

Het mooiste is dat je quooker gebruik alleen gaat wegfilteren bij (gedeetelijke) net afname en niet bij teruglevering.

code:

gefilterde_quooker = min(P1, Quooker)
resultaat = P1 - gefilterde_quooker

Dan filter je nooit meer Quooker weg dan daadwerkelijk als netafname zichtbaar is

Zelf heb ik nu een template sensor gemaakt met deze jinja:

code:

{% set p1 = states('sensor.p1_meter_vermogen') | float(0) %}
{% set quooker = states('sensor.quooker_huidig_gebruik') | float(0) %}

{% if quooker < 500 %}
  {% set quooker = 0 %}
{% endif %}

{% if now().hour == 5 and now().minute < 20 %}
  {{ p1 | round(0) }}
{% else %}
  {% set gefilterde_quooker = [p1, quooker] | min %}
  {{ (p1 - gefilterde_quooker) | round(0) }}
{% endif %}

Hiermee geldt:

05:00 t/m 05:19:59 → Quooker wordt niet weggefilterd, batterij mag helpen.
Alle andere tijden → Quooker wordt alleen weggefilterd voor zover die netafname veroorzaakt.
Zonnepanelen mogen de Quooker altijd voeden zonder dat de batterij onnodig gaat reageren.

Je hebt gelijk mbt de automatisering. Ik ging ervan uit dat de quooker langer achter elkaar zou verwarmen indien dat nodig is. Maar het blijven kortstondige pieken, alleen wat sneller op elkaar.

Ik heb het nu dus anders aangepakt. Mijn belangrijkste reden om iets aan die pieken te doen is het feit dat de relaisschakelingen de pan uitrijzen door die pieken. De batterij (800+) wordt opgeladen door de pv panelen en ineens vraagt de p1 +2200Watt. De batterij schakelt van opladen naar ontladen en tegen de tijd dat er ontladen wordt is de piek van 2200W verdwenen en hoeft er niet meer ontladen te worden. Dus weer een switch, van ontlasen naar laden.

Ik probeer nu de gielz automatisering stop te zetten zodra de smartplug van de quooker aangeeft dat er een piek aankomt. Dat houdt als het goed is de batterij in dezelfde staat zonder een relais schakeling.
Zodra de piek weg is gedurende 15 seconden wordt Gielz weer 'vrijgegeven' om zijn werk te doen.
Dus ook geen virtuele of gecorrigeerde p1 meer in gebruik.

[Pakhaas]

raven22 schreef op woensdag 24 juni 2026 @ 19:44:
[...]

Je hebt gelijk mbt de automatisering. Ik ging ervan uit dat de quooker langer achter elkaar zou verwarmen indien dat nodig is. Maar het blijven kortstondige pieken, alleen wat sneller op elkaar.

Ik heb het nu dus anders aangepakt. Mijn belangrijkste reden om iets aan die pieken te doen is het feit dat de relaisschakelingen de pan uitrijzen door die pieken. De batterij (800+) wordt opgeladen door de pv panelen en ineens vraagt de p1 +2200Watt. De batterij schakelt van opladen naar ontladen en tegen de tijd dat er ontladen wordt is de piek van 2200W verdwenen en hoeft er niet meer ontladen te worden. Dus weer een switch, van ontlasen naar laden.

Ik probeer nu de gielz automatisering stop te zetten zodra de smartplug van de quooker aangeeft dat er een piek aankomt. Dat houdt als het goed is de batterij in dezelfde staat zonder een relais schakeling.
Zodra de piek weg is gedurende 15 seconden wordt Gielz weer 'vrijgegeven' om zijn werk te doen.
Dus ook geen virtuele of gecorrigeerde p1 meer in gebruik.

Gielz stopzetten en weer aan geeft ook relais schakelingen.

[raven22]

Pakhaas schreef op woensdag 24 juni 2026 @ 19:49:
[...]

Gielz stopzetten en weer aan geeft ook relais schakelingen.

ok, dan is dit dus ook niet de oplossing

[Pakhaas]

raven22 schreef op woensdag 24 juni 2026 @ 19:52:
[...]

ok, dan is dit dus ook niet de oplossing

Nee. Je moet eerst zelf goed nadenken wat je wil en waarom voordat je met Claude of ChatGPT aan de slag gaat. Want AI knikt alleen maar ja en werkt alleen als je zelf weet hoe het systeem werkt. AI is weinig kritisch zeg maar...

[raven22]

Pakhaas schreef op woensdag 24 juni 2026 @ 19:56:
[...]

Nee. Je moet eerst zelf goed nadenken wat je wil en waarom voordat je met Claude of ChatGPT aan de slag gaat. Want AI knikt alleen maar ja en werkt alleen als je zelf weet hoe het systeem werkt. AI is weinig kritisch zeg maar...

Het lijkt nu wel goed te gaan trouwens. Zal het eens in de gaten houden. Ik laat gielz trouwens niet iets uitzetten, ik zet alleen de automatisering uit en in onderstaande plaatje was er geen relaisschakeling.

[Mistraller]

raven22 schreef op woensdag 24 juni 2026 @ 19:52:
[...]

ok, dan is dit dus ook niet de oplossing

De oplossing is gewoon de quooker van je P1 signaal aftrekken. Hoe complexer je iets maakt, hoe meer side effects je kunt verwachten. Ook al is tweaken leuk, ik denk dat je hier heel weinig winst kunt behalen, want het enige bestaansrecht van de quooker is kokend water op afroep. En het moment wanneer je thee wilt, valt niet te automatiseren.
Als het om "gewoon" warm water gaat, heb je eigenlijk het verkeerde product, dan ben je met een gewone boiler beter af.

[Moddemeijer]

Hoe krijg ik het aantal relaisschakelingen significant naar beneden (<100/dag) ? Terwijl in de ochtend de batterij vlot oplaadt?

Ik heb dit probleem ook gehad. De Zendure 2400 AC "raakt in de war" als je de internet toegang blokkert. Als gevolg hiervan gaat de Zendure 2400 AC instabiel draaien met veel relaisschakelingen. Ook in alleen laden of alleen ontladen modus blijft het relais schakelen terwijl daar geen enkele grond voor is.

Oplossing: de Zendure 2400 AC (alhoewel functieloos) aan het internet hangen. De Zendure MOET helaas aan het internet.

[Theetjuh]

Moddemeijer schreef op donderdag 25 juni 2026 @ 00:12:
[...]

Ik heb dit probleem ook gehad. De Zendure 2400 AC "raakt in de war" als je de internet toegang blokkert. Als gevolg hiervan gaat de Zendure 2400 AC instabiel draaien met veel relaisschakelingen. Ook in alleen laden of alleen ontladen modus blijft het relais schakelen terwijl daar geen enkele grond voor is.

Oplossing: de Zendure 2400 AC (alhoewel functieloos) aan het internet hangen. De Zendure MOET helaas aan het internet.

Dat is bij de AC2400+ opgelost met firmware 2.0 ik heb internet nu volledig afgesloten, is al door meerdere ervaren

[Moddemeijer]

Theetjuh schreef op donderdag 25 juni 2026 @ 00:23:
[...]

Dat is bij de AC2400+ opgelost met firmware 2.0 ik heb internet nu volledig afgesloten, is al door meerdere ervaren

Volgens de app heb ik de nieuwste versie: Solarflow 2400 AC+ V1.0.3

Ik heb in de router de internet toegang geblokkeerd en een kwartiertje gewacht. Ik heb in 20 min. 2 spookschakelingen en bij de tweede was de modus eventjes unavailable. Dit wijst op het geheel wegvallen van de communicatie.

Hoe kom je aan firmware 2.0?

[Theetjuh]

Moddemeijer schreef op donderdag 25 juni 2026 @ 00:57:
[...]

Volgens de app heb ik de nieuwste versie: Solarflow 2400 AC+ V1.0.3

Ik heb in de router de internet toegang geblokkeerd en een kwartiertje gewacht. Ik heb in 20 min. 2 spookschakelingen en bij de tweede was de modus eventjes unavailable. Dit wijst op het geheel wegvallen van de communicatie.

Hoe kom je aan firmware 2.0?

Deze werd gewoon aangeboden in de app, er even voor zorgen dat je die op de laatste versie hebt draaien.

[Moddemeijer]

Theetjuh schreef op donderdag 25 juni 2026 @ 01:08:
[...]

Deze werd gewoon aangeboden in de app, er even voor zorgen dat je die op de laatste versie hebt draaien.

Kennelijk is versie 2.0 (tijdelijk?) uit de app verwijderd. De app geeft als nieuwste versie Solarflow 2400 AC+ V1.0.3 aan.

[Devke]

Moddemeijer schreef op donderdag 25 juni 2026 @ 01:16:
[...]

Kennelijk is versie 2.0 (tijdelijk?) uit de app verwijderd. De app geeft als nieuwste versie Solarflow 2400 AC+ V1.0.3 aan.

Kan hem hier gewoon updaten naar v2

[ctrl-tab]

Moddemeijer schreef op donderdag 25 juni 2026 @ 00:12:
[...]

Ik heb dit probleem ook gehad. De Zendure 2400 AC "raakt in de war" als je de internet toegang blokkert. Als gevolg hiervan gaat de Zendure 2400 AC instabiel draaien met veel relaisschakelingen. Ook in alleen laden of alleen ontladen modus blijft het relais schakelen terwijl daar geen enkele grond voor is.

Oplossing: de Zendure 2400 AC (alhoewel functieloos) aan het internet hangen. De Zendure MOET helaas aan het internet.

Tenzij je een echte tweaker bent ;)

https://codeberg.org/DaanVervacke/zendure-spoof-european-mqtt-broker/src/branch/main

[DeadMetal]

Gisteravond heb ik de batterij met de hoge prijzen expres wat langer laten ontladen. Vanochtend zag ik dat hij net onder de 10% gezakt was. De gielz stond in de 'Dynamisch handelen + NOM'-modus.
Zojuist wekten mijn panelen zo'n 800w op, de P1 stond rond de 600w teruglevering, maar toch gingen de accu's nog niet laden. Zou dat komen doordat de SoC te laag was?
In onderstaande grafiek zie je het gedrag. Zodra ik de modus aanpaste naar 'Snel laden', begon het opladen wel (nog niet zichtbaar in de grafiek, wel in het cijfertje erboven, dit screenshot was van toen hij nog ging opbouwen richting de 4800w):


Ik zie ook dat de integratie ook echt een vermogensopdracht van 0 gaf de afgelopen tijd:

[raven22]

Mistraller schreef op woensdag 24 juni 2026 @ 22:35:
[...]

De oplossing is gewoon de quooker van je P1 signaal aftrekken. Hoe complexer je iets maakt, hoe meer side effects je kunt verwachten. Ook al is tweaken leuk, ik denk dat je hier heel weinig winst kunt behalen, want het enige bestaansrecht van de quooker is kokend water op afroep. En het moment wanneer je thee wilt, valt niet te automatiseren.
Als het om "gewoon" warm water gaat, heb je eigenlijk het verkeerde product, dan ben je met een gewone boiler beter af.

Dan krijg je nog steeds relaisschakelingen, tot wel 3 per keer dat de quooker een puls van 2200w verbruikt.
Met mijn oplossing is er geen relaisschakeling tijdens de puls. Dat kan zo 100 schakelingen per dag schelen.

Het stroomverbruik komt nu dus meestal uit het net en niet uit de batterij, en dat vind ik prima. Echter de vele relaisschakelingen per dag verminderen drastisch en dat vind ik wel fijn.

[ Voor 10% gewijzigd door raven22 op 25-06-2026 09:11 ]

[Hippe Lip]

raven22 schreef op donderdag 25 juni 2026 @ 09:08:
[...]
Het stroomverbruik komt nu dus meestal uit het net en niet uit de batterij, en dat vind ik prima. Echter de vele relaisschakelingen per dag verminderen drastisch en dat vind ik wel fijn.

Waarom is dat fijn?
Is er iets mis met die relaisschakelingen?

[raven22]

Hippe Lip schreef op donderdag 25 juni 2026 @ 09:30:
[...]

Waarom is dat fijn?
Is er iets mis met die relaisschakelingen?

Nee, maar 3 in een paar seconden en honderden per dag lijkt me minder goed. En als het eenvoudig op te lossen is waarom niet? Maar of je er wat aan wilt doen dat mag ieder voor zich bepalen.

[gielz]

DeadMetal schreef op donderdag 25 juni 2026 @ 08:36:
Gisteravond heb ik de batterij met de hoge prijzen expres wat langer laten ontladen. Vanochtend zag ik dat hij net onder de 10% gezakt was. De gielz stond in de 'Dynamisch handelen + NOM'-modus.
Zojuist wekten mijn panelen zo'n 800w op, de P1 stond rond de 600w teruglevering, maar toch gingen de accu's nog niet laden. Zou dat komen doordat de SoC te laag was?
In onderstaande grafiek zie je het gedrag. Zodra ik de modus aanpaste naar 'Snel laden', begon het opladen wel (nog niet zichtbaar in de grafiek, wel in het cijfertje erboven, dit screenshot was van toen hij nog ging opbouwen richting de 4800w):
[Afbeelding]

Ik zie ook dat de integratie ook echt een vermogensopdracht van 0 gaf de afgelopen tijd:
[Afbeelding]

Heb je wat meer informatie van het logboek? De SOC bescherming zal eerst actief worden 2 uur na zonsopkomst of wanneer er voldoende zon is. Daarna neemt NOM het weer over na enkele minuten.

Je zou gezien het zomer is de SOC bescherming van de integratie kunnen uitzetten en vertrouwen op de BMS om te kijken of het dan iig goed gaat.

[Hippe Lip]

raven22 schreef op donderdag 25 juni 2026 @ 09:34:
[...]
Nee, maar 3 in een paar seconden en honderden per dag lijkt me minder goed.

Waarom is dat minder goed?
Ik ben het met je eens dat ieder het voor zichzelf mag bepalen wat die daarmee doet, maar ik probeer gewoon oprecht te begrijpen wat er mis is met relaisschakelingen (of dat het alleen cosmetisch is).

[Gramser]

Moddemeijer schreef op donderdag 25 juni 2026 @ 01:16:
[...]

Kennelijk is versie 2.0 (tijdelijk?) uit de app verwijderd. De app geeft als nieuwste versie Solarflow 2400 AC+ V1.0.3 aan.

Volgens mij moet je daar wel eerst de nieuwe appversie voor hebben, dus die met HEMS2.0. Dan wordt de firmware meteen gepusht.

[Hippe Lip]

Gramser schreef op donderdag 25 juni 2026 @ 09:45:
[...]
Volgens mij moet je daar wel eerst de nieuwe appversie voor hebben, dus die met HEMS2.0. Dan wordt de firmware meteen gepusht.

Ehh, automatisch gepusht? Hier bij mij (iPhone) niet.

Ik heb wel mijn app ge-update, maar mijn Zendures (gelukkig) nog niet. Die staan nog op de aloude V1.0.3
De upgrade wordt nu wel actief aangeboden.

[gielz]

Hippe Lip schreef op donderdag 25 juni 2026 @ 09:49:
[...]

Ehh, automatisch gepusht? Hier bij mij (iPhone) niet.

Ik heb wel mijn app ge-update, maar mijn Zendures (gelukkig) nog niet. Die staan nog op de aloude V1.0.3
De update wordt nu wel actief aangeboden.

[Afbeelding]

Hij bedoelt zodra de app up-to-date is krijg je het advies om fw 2.0 te installeren. Zie ik hier ook op een 1.0.3 AC+

[Gramser]

Dank u, dat bedoelde ik inderdaad!

[Mistraller]

raven22 schreef op donderdag 25 juni 2026 @ 09:08:
[...]

Dan krijg je nog steeds relaisschakelingen, tot wel 3 per keer dat de quooker een puls van 2200w verbruikt.
Met mijn oplossing is er geen relaisschakeling tijdens de puls. Dat kan zo 100 schakelingen per dag schelen.

Het stroomverbruik komt nu dus meestal uit het net en niet uit de batterij, en dat vind ik prima. Echter de vele relaisschakelingen per dag verminderen drastisch en dat vind ik wel fijn.

Quooker uit. PV uit. 500W verbruik op P1; accu levert 500W
Quooker aan. PV uit. 500W + 2200W P1 ziet 2700W verbruik; HA trekt er 2200 af: accu levert 500W
Quooker uit. PV beetje aan: 1000 teruglevering: accu laadt met 1000W
Quooker aan, PV beetje aan. 1000W teruglevering, 2200W verbruik, dus meter "ziet" 1200W verbruik. HA
trekt er 2200 vanaf: accu laadt met 1000W.
Quooker uit. PV vol aan: 2400 teruglevering: accu laadt met 2400W
Quooker aan, PV vol aan. 2400W teruglevering, 2200W verbruik, dus meter "ziet" 200W teruglevering. HA trekt er 2200 vanaf: accu laadt met 2400W.

Zolang de powerplug en de verbinding maar snel genoeg is, zodat HA de berekening tijdig doet; is de accu helemaal blind voor de quooker

Je quooker verbruik komt volledig op grid hierdoor.

Maar leg me anders even uit waar mijn denkfout zit, misschien zie ik het niet door de hitte

[Moddemeijer]

gielz schreef op donderdag 25 juni 2026 @ 09:51:
[...]


Hij bedoelt zodra de app up-to-date is krijg je het advies om fw 2.0 te installeren. Zie ik hier ook op een 1.0.3 AC+

Het zal toch niet zo zijn dat de te installeren firmware van de Smartphone afhangt:

• Android: V1.0.3
• iPhone: V2.0

[Gramser]

Heb je al wel de app up to date dan @Moddemeijer ? Dan weet je het. Toen ik de app niet had geupdate, kreeg ik ook geen mogelijkheid tot fw 2.0. iPhone hier.

[ Voor 4% gewijzigd door Gramser op 25-06-2026 10:18 ]

[ZuinigeRijder]

De Groene Nerds reviewen de AC2400+ én gaan in op de @gielz integratie (rond 10 minuten).

[DeadMetal]

gielz schreef op donderdag 25 juni 2026 @ 09:41:
[...]
Heb je wat meer informatie van het logboek? De SOC bescherming zal eerst actief worden 2 uur na zonsopkomst of wanneer er voldoende zon is. Daarna neemt NOM het weer over na enkele minuten.

Je zou gezien het zomer is de SOC bescherming van de integratie kunnen uitzetten en vertrouwen op de BMS om te kijken of het dan iig goed gaat.

Helaas is het me niet helemaal duidelijk (ook gekekeken op je Github) wat deze bescherming inhoudt. Maar hij staat sowieso aan. Ik zie in het logbook een melding over een ingeschakelde bescherming van 1200w.

/edit: even gevraagd aan Gemini om mee te denken:

In de Gielz-integratie is de NOM-modus afhankelijk van een stabiele feedback-lus vanuit de Zendure-hub. Wanneer de batterij op 9% staat, gebeurt het volgende:

De Gielz-integratie ziet: "Hé, we leveren 600W terug, we moeten gaan laden!"

De integratie vraagt aan de Zendure-hub (via de lokale API): "Wat is je status, mag ik vermogen sturen?"

De Zendure-hub (die in deep sleep/beveiliging staat vanwege de 9%) antwoordt met een foutcode of een status 0 (laadcapaciteit niet beschikbaar).

De integratie móét die 0 in het logboek zetten, omdat de hardware aangeeft dat er geen stroom naartoe kan.

Zendure heeft hun firmware helaas zo geprogrammeerd dat de hub bij een te lage SOC (onder de 10%) eerst een harde, constante stroomstoot nodig heeft om het BMS te resetten. NOM stuurt een variabel, voorzichtig signaal. Pas toen jij hem op 'Snel laden' zette, stuurde de integratie een geforceerd, maximaal laadcommando. Dit negeert de statuscontrole en 'slaat' de accu als het ware wakker.

De definitieve oplossing voor vannacht

Om te voorkomen dat je dit morgenochtend weer handmatig moet 'kickstarten', moet je zorgen dat de accu vannacht niet onder die kritieke 10%-grens zakt.

Aangezien je een omvormer hebt die 's nachts een klein beetje stroom blijft trekken uit de hub (waardoor hij van je ingestelde minimum naar 9% zakt), kun je het beste de Minimale SOC (output limit) in de Zendure app óf de integratie verhogen naar 13% of 15%.

Als de accu dan 's nachts een procentje wegzwakt, blijft hij op 12% of 14% steken. Dat is ruim boven de hardwarematige 'dead zone' van Zendure, waardoor de integratie morgenochtend bij de eerste 100W of 200W aan zon direct soepel begint te laden in de NOM-modus!

[ Voor 57% gewijzigd door DeadMetal op 25-06-2026 10:39 ]

[gielz]

DeadMetal schreef op donderdag 25 juni 2026 @ 10:31:
[...]


Helaas is het me niet helemaal duidelijk (ook gekekeken op je Github) wat deze bescherming inhoudt. Maar hij staat sowieso aan. Ik zie in het logbook een melding over een ingeschakelde bescherming van 1200w.

Wat de SOC bescherming doet is zodra hij onder de minimale SOC beland zal hij gaan bijladen overdag. Nu is het zo dat de meeste recente firmware versies van Zendure dit inmiddels ook zelf hebben maar die doen dit pas bij 1-2%. Wat prima is want zelf op 0% zit er nog iets van energie in de batterij.

Zelf heb ik hem alleen aanstaan van november t/m februari. De batterij doet dan weinig tot niets hier en blijft op 50% minimale SOC staan.

[raven22]

Mistraller schreef op donderdag 25 juni 2026 @ 10:08:
[...]

Quooker uit. PV uit. 500W verbruik op P1; accu levert 500W
Quooker aan. PV uit. 500W + 2200W P1 ziet 2700W verbruik; HA trekt er 2200 af: accu levert 500W
Quooker uit. PV beetje aan: 1000 teruglevering: accu laadt met 1000W
Quooker aan, PV beetje aan. 1000W teruglevering, 2200W verbruik, dus meter "ziet" 1200W verbruik. HA
trekt er 2200 vanaf: accu laadt met 1000W.
Quooker uit. PV vol aan: 2400 teruglevering: accu laadt met 2400W
Quooker aan, PV vol aan. 2400W teruglevering, 2200W verbruik, dus meter "ziet" 200W teruglevering. HA trekt er 2200 vanaf: accu laadt met 2400W.

Zolang de powerplug en de verbinding maar snel genoeg is, zodat HA de berekening tijdig doet; is de accu helemaal blind voor de quooker

Je quooker verbruik komt volledig op grid hierdoor.

Maar leg me anders even uit waar mijn denkfout zit, misschien zie ik het niet door de hitte

Zou je jouw code willen delen? het klinkt helemaal logisch wat je zegt, maar ik denk door tijdvertraging dat het toch niet zo goed werkte bij mij.

[ppaulv]

raven22 schreef op donderdag 25 juni 2026 @ 10:44:
[...]

Zou je jouw code willen delen? het klinkt helemaal logisch wat je zegt, maar ik denk door tijdvertraging dat het toch niet zo goed werkte bij mij.

eerlijk gezegd denk ik dat de storende pieken van de quooker veel te kort zijn. Zowel voor de accu en de automatisering om te reageren (daar begon dit mee) maar ook te kort voor de smart plug om data te sturen (die is denk ik ook veel te traag?).
Wat mij betreft zou het wellicht een veel beter verhaal worden als we de data van de p1 meter (of die smart plug waar de quooker aan hangt) zouden gaan omvormen naar een voortschrijdend gemiddelde van de afgelopen 2 of 3 metingen. Voor een DSMR 5 meter wat meer dan voor een 4.2 meter.
Is dat wellicht een interessante denkrichting?

[gielz]

Ik lees nu een tijdje mee over de kokendwaterkranen.

Wat je kunt doen is een homewizard plug tussen de kraan te zetten en deze per seconden uit te lezen via de API (is heel eenvoudig). Je hebt vervolgens een vermogen wat gelijk loopt met een DSMR 5.0 meter.

Vervolgens haal je al het vermogen van die energysocket van je P1 vermogen af waarbij je wel het standaard standby vermogen behoud. Dit is dan je gecorrigeerde afwijkende P1 meter die je kunt gebruiken in iedere Zendure integratie.

Je P1 ziet die pieken dan nooit meer en je hoeft geen exotische dingen te bouwen.

[Gramser]

ZuinigeRijder schreef op donderdag 25 juni 2026 @ 10:19:
De Groene Nerds reviewen de AC2400+ én gaan in op de @gielz integratie (rond 10 minuten).

[YouTube: Zelf je batterij aansturen, zonder cloud 🚫☁️ met de Zendure Solarflow 2400 AC+]

Zit wel een foutje in. Aansturen kan NIET via ethernet.

[Gramser]

Overigens zojuist het AP geblokkeerd van internet. Kon gewoon via de KPN-app, hoefde niet eens in m'n modem in te loggen.

Gielz draait netjes door, blij mee.

[Pakhaas]

gielz schreef op donderdag 25 juni 2026 @ 11:03:
Ik lees nu een tijdje mee over de kokendwaterkranen.

Wat je kunt doen is een homewizard plug tussen de kraan te zetten en deze per seconden uit te lezen via de API (is heel eenvoudig). Je hebt vervolgens een vermogen wat gelijk loopt met een DSMR 5.0 meter.

Vervolgens haal je al het vermogen van die energysocket van je P1 vermogen af waarbij je wel het standaard standby vermogen behoud. Dit is dan je gecorrigeerde afwijkende P1 meter die je kunt gebruiken in iedere Zendure integratie.

Je P1 ziet die pieken dan nooit meer en je hoeft geen exotische dingen te bouwen.

Ik had gisteren inderdaad al zo'n sensor gemaakt waarbij het vermogen de P1 minus het vermogen van de slimme stekker van de quooker. Maar wat gebeurd er dan als je aan het terugleveren bent? Dan wil je natuurlijk wel dat de pieken door de PV worden opgevangen.

[Mistraller]

raven22 schreef op donderdag 25 juni 2026 @ 10:44:
[...]

Zou je jouw code willen delen? het klinkt helemaal logisch wat je zegt, maar ik denk door tijdvertraging dat het toch niet zo goed werkte bij mij.

Ik heb geen quooker. Maar mijn Zigbee powerplugs (gewoon van de Ali) zijn wel heel rap met het doorsturen van het vermogen. 1 seconde of zo. En omdat Gielz elke 5 seconden draait normaliter is dat ruim voldoende.
Een helper sensor van je P1 is zo gemaakt, desnoods met hulp van AI. (Ik had een helper nodig omdat mijn P1 data in kW en de teruglevering en verbruik in 2 values bevatte) Maar daar zou ik dus ook direct een toevoeging maken als ik de accu blind zou willen maken voor een bepaald vermogen.

Als jouw powerplug (te) traag data doorstuurt dan is dat het issue, en dan is alles wat je doet een workaround.

Ik heb wel een dsmr4 dus mijn NOM is nog niet superstrak, maar op dagelijkse basis verrassend goed op nul.

Ik heb in een heel ander home assistant projectje ook zoiets gehad ooit, avonden klooien; niet gelukt; ander merk sensor: fixed.

[ Voor 5% gewijzigd door Mistraller op 25-06-2026 11:57 ]

[Mistraller]

Pakhaas schreef op donderdag 25 juni 2026 @ 11:55:
[...]

Ik had gisteren inderdaad al zo'n sensor gemaakt waarbij het vermogen de P1 minus het vermogen van de slimme stekker van de quooker. Maar wat gebeurd er dan als je aan het terugleveren bent? Dan wil je natuurlijk wel dat de pieken door de PV worden opgevangen.

Dat heb ik hierboven geprobeerd uit te leggen. Jouw accu laadt dan gewoon door alsof alle PV beschikbaar is, dus technisch een beetje van de grid. Accu is blind voor de quooker, en alle quooker gebruik haal je uit de grid.
Alle variaties maken het door de vertraging in zowel HA als de accu zelf tot een usecase die je niet met automations écht kunt afdekken.

Dan moet je echt denken aan een sensor die de kraanknop monitort; of exact timen wanneer de quooker aan zal springen en proactief automations laten aftrappen. Dat is echt overengineering. Hier past toch beter KISS denk ik...

Het enige wat je kunt bedenken is dat als er langere tijd quooker verbruik is omdat je hem bijv in de nacht uitzet, dan zou je voor de ochtend-boost een exceptie kunnen maken. Of gecombineerd met een watersensor waardoor je weet dat er een kraan openstaat. Maar als dat je verbruiksmeter is weet je nog steeds niet welke kraan...

[Pakhaas]

Mistraller schreef op donderdag 25 juni 2026 @ 12:05:
[...]

Dat heb ik hierboven geprobeerd uit te leggen. Jouw accu laadt dan gewoon door alsof alle PV beschikbaar is, dus technisch een beetje van de grid. Accu is blind voor de quooker, en alle quooker gebruik haal je uit de grid.
Alle variaties maken het door de vertraging in zowel HA als de accu zelf tot een usecase die je niet met automations écht kunt afdekken.

Dan moet je echt denken aan een sensor die de kraanknop monitort; of exact timen wanneer de quooker aan zal springen en proactief automations laten aftrappen. Dat is echt overengineering. Hier past toch beter KISS denk ik...

Het enige wat je kunt bedenken is dat als er langere tijd quooker verbruik is omdat je hem bijv in de nacht uitzet, dan zou je voor de ochtend-boost een exceptie kunnen maken. Of gecombineerd met een watersensor waardoor je weet dat er een kraan openstaat. Maar als dat je verbruiksmeter is weet je nog steeds niet welke kraan...

Bedankt ik ga volgend jaar na einde salderen eens testen. Nu nog dynamisch handelen en is het niet aan de orde.

Ja ik heb nu in de code dat tussen 5:00 en 5:20 de quooker wel meetelt met de accu, omdat hij dan weer aangaat na een nacht uit.

[ppaulv]

Bijft tricky als de powerplug net eerder of later de quooker load doorgeeft dan de p1 meter vanuit je meterkast. Als die niet op exact hetzelfde moment komen (kans is nihil) gaat het mis. Qua vermogen dat je onterecht uit het grid haalt of er juist in stopt is dat niet interessant. Maar qua schakelingen gaat ie het druk hebben als je net rond die 0 hangt, en het was nou net de bedoeling dat dat minder zou worden ....
Of zien jullie dat anders?
Zou dan echt meer zien in voortschrijdende gemiddelden en/of dat er niet geschakeld mag worden als de p1 waarde een paar seconden geleden hoger was dan de vraag van de quooker (2200W ?) . Makes sense?

[ppaulv]

gielz schreef op donderdag 25 juni 2026 @ 11:03:
Ik lees nu een tijdje mee over de kokendwaterkranen.

Wat je kunt doen is een homewizard plug tussen de kraan te zetten en deze per seconden uit te lezen via de API (is heel eenvoudig). Je hebt vervolgens een vermogen wat gelijk loopt met een DSMR 5.0 meter.

Vervolgens haal je al het vermogen van die energysocket van je P1 vermogen af waarbij je wel het standaard standby vermogen behoud. Dit is dan je gecorrigeerde afwijkende P1 meter die je kunt gebruiken in iedere Zendure integratie.

Je P1 ziet die pieken dan nooit meer en je hoeft geen exotische dingen te bouwen.

Overigens, ik lees de HW energy socket hier uit en krijg elke 5 sec of zoiets data, niet per seconde.
Kan ik dat ergens beïnvloeden?

[raven22]

gielz schreef op donderdag 25 juni 2026 @ 11:03:
Ik lees nu een tijdje mee over de kokendwaterkranen.

Wat je kunt doen is een homewizard plug tussen de kraan te zetten en deze per seconden uit te lezen via de API (is heel eenvoudig). Je hebt vervolgens een vermogen wat gelijk loopt met een DSMR 5.0 meter.

Vervolgens haal je al het vermogen van die energysocket van je P1 vermogen af waarbij je wel het standaard standby vermogen behoud. Dit is dan je gecorrigeerde afwijkende P1 meter die je kunt gebruiken in iedere Zendure integratie.

Je P1 ziet die pieken dan nooit meer en je hoeft geen exotische dingen te bouwen.

Vraagje, als je de homewizard p1 meter gebruikt via het ipadress, hoe grootis dan het reporting interval? 1 sec bij een klasse 5 meter?
Ik gebruik de zendure p1 meter en dan is de polling 5 seconden.

[gielz]

ppaulv schreef op donderdag 25 juni 2026 @ 12:48:
[...]

Overigens, ik lees de HW energy socket hier uit en krijg elke 5 sec of zoiets data, niet per seconde.
Kan ik dat ergens beïnvloeden?

Je kunt hem als REST opnemen; https://github.com/Gielz1...0%90-P1-CT-meters-(API's)

Zou de onderstaande code moeten zijn

code:

rest:
  - resource: http://<IP-ENERGYSOCKET-HOMEWIZARD>/api/v1/data
    scan_interval: 1
    sensor:
      - name: "Homewizard Energysocket API v1"
        value_template: "{{ value_json.active_power_w | float }}"
        unique_id: Homewizard_Energysocket_API_V1
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power

[ppaulv]

@gielz dank je. Het werkt. Maar ik zie dat in de HW app de grafiek veel sneller reageert. Echt in 1 seconde of minder terwijl in HA het zo'n 2 à 3 seconden duurt voor ik iets zie veranderen. Daar zit meer overhead lijkt het.

[Mistraller]

ppaulv schreef op donderdag 25 juni 2026 @ 12:41:
Bijft tricky als de powerplug net eerder of later de quooker load doorgeeft dan de p1 meter vanuit je meterkast. Als die niet op exact hetzelfde moment komen (kans is nihil) gaat het mis. Qua vermogen dat je onterecht uit het grid haalt of er juist in stopt is dat niet interessant. Maar qua schakelingen gaat ie het druk hebben als je net rond die 0 hangt, en het was nou net de bedoeling dat dat minder zou worden ....
Of zien jullie dat anders?
Zou dan echt meer zien in voortschrijdende gemiddelden en/of dat er niet geschakeld mag worden als de p1 waarde een paar seconden geleden hoger was dan de vraag van de quooker (2200W ?) . Makes sense?

Kijk, in de basis is wat wij doen toch behelpen. Want we knutselen al met de P1 data dus defacto ben je altijd te laat. Zelfs met een dsmr5 loop je altijd achter de feiten aan.
Als je dit echt superbelangrijk vind is een PiB simpelweg niet het juiste product, en moet je accu, PV en omvormer compleet anders aanpakken.

ppaulv schreef op donderdag 25 juni 2026 @ 12:48:
[...]

Overigens, ik lees de HW energy socket hier uit en krijg elke 5 sec of zoiets data, niet per seconde.
Kan ik dat ergens beïnvloeden?

Kennelijk is dit een pull. Zigbee plugs doet altijd een push. Dus bij een verandering een bericht en anders niks. Pullen van waardes die mogelijk helemaal niet veranderen is niet optimaal.

[raven22]

Mistraller schreef op donderdag 25 juni 2026 @ 11:56:
[...]

Ik heb geen quooker. Maar mijn Zigbee powerplugs (gewoon van de Ali) zijn wel heel rap met het doorsturen van het vermogen. 1 seconde of zo. En omdat Gielz elke 5 seconden draait normaliter is dat ruim voldoende.
Een helper sensor van je P1 is zo gemaakt, desnoods met hulp van AI. (Ik had een helper nodig omdat mijn P1 data in kW en de teruglevering en verbruik in 2 values bevatte) Maar daar zou ik dus ook direct een toevoeging maken als ik de accu blind zou willen maken voor een bepaald vermogen.

Als jouw powerplug (te) traag data doorstuurt dan is dat het issue, en dan is alles wat je doet een workaround.

Ik heb wel een dsmr4 dus mijn NOM is nog niet superstrak, maar op dagelijkse basis verrassend goed op nul.

Ik heb in een heel ander home assistant projectje ook zoiets gehad ooit, avonden klooien; niet gelukt; ander merk sensor: fixed.

Ik heb de reporting van mijn zigbee smartplug op 1 seconde gezet (stond op 10). Daarnaast haalt Gielz nu elke seconde de p1 waarde op (ipv elke 5 seconden).
Dat gaf al een veel beter beeld.

Als extra heb ik toegevoegd dat bij een negatieve P1 waarde de berekening wordt aangepast zodat de P1 niet positief kan worden. Dus wat beschikbaar is voor teruglevering wordt nu ook gebruikt voor de quooker. Zonder dat hierbij een relaisschakeling plaatsvind omdat de batterij gaat ontladen.

Vannacht/morgenochtend even checken of het ook werkt in een situatie waarbij de batterij al ontlaad.

De aangepaste code:

# packages/quooker_p1_filter.yaml

template:
  - sensor:
      - name: "P1 Netto Exclusief Quooker"
        unique_id: p1_netto_exclusief_quooker
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement
        state: >
          {% set p1 = states('sensor.p1_zendure_api') | float(0) %}
          {% set quooker = states('sensor.sonoff_1_power') | float(0) %}
          {{ ([p1 - quooker, [p1, 0] | min] | max) | round(0) }}

[gielz]

raven22 schreef op donderdag 25 juni 2026 @ 15:14:
[...]

Ik heb de reporting van mijn zigbee smartplug op 1 seconde gezet (stond op 10). Daarnaast haalt Gielz nu elke seconde de p1 waarde op (ipv elke 5 seconden).
Dat gaf al een veel beter beeld.

Als extra heb ik toegevoegd dat bij een negatieve P1 waarde de berekening wordt aangepast zodat de P1 niet positief kan worden. Dus wat beschikbaar is voor teruglevering wordt nu ook gebruikt voor de quooker. Zonder dat hierbij een relaisschakeling plaatsvind omdat de batterij gaat ontladen.

Vannacht/morgenochtend even checken of het ook werkt in een situatie waarbij de batterij al ontlaad.

De aangepaste code:

# packages/quooker_p1_filter.yaml

template:
  - sensor:
      - name: "P1 Netto Exclusief Quooker"
        unique_id: p1_netto_exclusief_quooker
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement
        state: >
          {% set p1 = states('sensor.p1_zendure_api') | float(0) %}
          {% set quooker = states('sensor.sonoff_1_power') | float(0) %}
          {{ ([p1 - quooker, [p1, 0] | min] | max) | round(0) }}

Zou hier wel nog even een unavailable in (laten) bouwen. Wanneer je P1 nu offline gaat om wat voor reden dan ook en hij is aan het NOMen dan blijft hij hangen in zijn laatste vermogen. (iig bij de Gielz)

[raven22]

gielz schreef op donderdag 25 juni 2026 @ 15:30:
[...]


Zou hier wel nog even een unavailable in (laten) bouwen. Wanneer je P1 nu offline gaat om wat voor reden dan ook en hij is aan het NOMen dan blijft hij hangen in zijn laatste vermogen. (iig bij de Gielz)

Zal er naar kijken, maar dat geldt denk ik ook voor het geval dat de wasmachine aanstaat en de P1 niet meer beschikbaar is.

[Moddemeijer]

ppaulv schreef op donderdag 25 juni 2026 @ 14:44:
@gielz dank je. Het werkt. Maar ik zie dat in de HW app de grafiek veel sneller reageert. Echt in 1 seconde of minder terwijl in HA het zo'n 2 à 3 seconden duurt voor ik iets zie veranderen. Daar zit meer overhead lijkt het.

Ik ben vandaag aan het testen met het koppelen van de trigger aan de P1 meter. Het voordeel is dat als de meetwaarde binnenkomt, deze ook direct verwerkt wordt. Verder hoef je geen polling interval te bepalen want polling is overbodig, de P1 meter geeft het ritme aan.

Ik heb de P1 meter van Zendure al heel snel terzijde gelegd. De belangrijkste reden is dat ik geen waarden van de tellers van de elektriciteitsmeter meer binnen kreeg. Twee P1 meters vond ik ook geen elegante oplossing. Ik had al SmartGateways.nl "ESP smart home edition" en deze combineert goed met zenSDK.

[jordyc]

Ik heb vandaag de 2400+ met 2 extra batterijen in gebruik genomen. Vanmiddag op vol vermogen opgeladen en net 2 uur op vol vermogen ontladen. De rest gebruik ik voor NOM in de nacht. Nu zag ik iets geks in de @gielz aansturing. Namelijk dat de batterij zowel import als export op de DC meet tijdens ontladen, dit blijft als ik de batterij handmatig op standby zet. Dit gedrag heb ik niet gezien bij het opladen. Onderstaand is een screenshot van toen de batterij op standby stond.

Hierdoor loopt dus ook de efficiëntie meting uit de pas, iets waar ik wel in geïnteresseerd was om eens te vergelijken met de 2400 die ik eerst had.

Weet iemand wat hier mist gaat en hoe dat te fixen?

[gielz]

jordyc schreef op donderdag 25 juni 2026 @ 22:12:
Ik heb vandaag de 2400+ met 2 extra batterijen in gebruik genomen. Vanmiddag op vol vermogen opgeladen en net 2 uur op vol vermogen ontladen. De rest gebruik ik voor NOM in de nacht. Nu zag ik iets geks in de @gielz aansturing. Namelijk dat de batterij zowel import als export op de DC meet tijdens ontladen, dit blijft als ik de batterij handmatig op standby zet. Dit gedrag heb ik niet gezien bij het opladen. Onderstaand is een screenshot van toen de batterij op standby stond.

Hierdoor loopt dus ook de efficiëntie meting uit de pas, iets waar ik wel in geïnteresseerd was om eens te vergelijken met de 2400 die ik eerst had.

Weet iemand wat hier mist gaat en hoe dat te fixen?

[Afbeelding]

Wat je ziet is het intern balanceren van de batterijen onderling. Dus niet iets geks of waar je iets aan kan doen.

[raven22]

raven22 schreef op donderdag 25 juni 2026 @ 15:14:
[...]

Ik heb de reporting van mijn zigbee smartplug op 1 seconde gezet (stond op 10). Daarnaast haalt Gielz nu elke seconde de p1 waarde op (ipv elke 5 seconden).
Dat gaf al een veel beter beeld.

Als extra heb ik toegevoegd dat bij een negatieve P1 waarde de berekening wordt aangepast zodat de P1 niet positief kan worden. Dus wat beschikbaar is voor teruglevering wordt nu ook gebruikt voor de quooker. Zonder dat hierbij een relaisschakeling plaatsvind omdat de batterij gaat ontladen.

Vannacht/morgenochtend even checken of het ook werkt in een situatie waarbij de batterij al ontlaad.

De aangepaste code:

# packages/quooker_p1_filter.yaml

template:
  - sensor:
      - name: "P1 Netto Exclusief Quooker"
        unique_id: p1_netto_exclusief_quooker
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement
        state: >
          {% set p1 = states('sensor.p1_zendure_api') | float(0) %}
          {% set quooker = states('sensor.sonoff_1_power') | float(0) %}
          {{ ([p1 - quooker, [p1, 0] | min] | max) | round(0) }}

Bovenstaande code lijkt het ook in de nacht en ochtend uitstekend te doen. Tot nu toe vandaag slechts 12 relaisschakelingen tegen minimaal 60 voorheen. En die 12 zijn met een Quooker die de hele nacht aanstaat.

Ook belangrijk is om te zorgen dat je p1 en quooker verbruik sensoren liefst elke seconde verversen.

[jannus66]

raven22 schreef op vrijdag 26 juni 2026 @ 10:44:
[...]

Bovenstaande code lijkt het ook in de nacht en ochtend uitstekend te doen. Tot nu toe vandaag slechts 12 relaisschakelingen tegen minimaal 60 voorheen. En die 12 zijn met een Quooker die de hele nacht aanstaat.

Ook belangrijk is om te zorgen dat je p1 en quooker verbruik sensoren liefst elke seconde verversen.

Hoe implementeer ik dit nu in HA, moet ik sensor.p1_zendure_api vervangen door sensor.p1_netto_exclusief_quooker?
Moet ik deze yaml gewoon in packages zetten (samen met die van Gielz) en dan HA opnieuw opstarten?

[raven22]

jannus66 schreef op vrijdag 26 juni 2026 @ 11:21:
[...]


Hoe implementeer ik dit nu in HA, moet ik sensor.p1_zendure_api vervangen door sensor.p1_netto_exclusief_quooker?
Moet ik deze yaml gewoon in packages zetten (samen met die van Gielz) en dan HA opnieuw opstarten?

klopt inderdaad, in gielz settings vul je sensor.p1_netto_exclusief_quooker in.

in de packages map maak je een nieuw bestand en zet daar de code in. Even herstarten en klaar.

[Pakhaas]

raven22 schreef op vrijdag 26 juni 2026 @ 11:55:
[...]

klopt inderdaad, in gielz settings vul je sensor.p1_netto_exclusief_quooker in.

in de packages map maak je een nieuw bestand en zet daar de code in. Even herstarten en klaar.

Waarom maak je dit in package en niet in GUI? Daar kan je ook gewoon een yaml code plakken en hoef je niet in package dingen aan te maken.

[ Voor 11% gewijzigd door Pakhaas op 26-06-2026 12:06 ]

[raven22]

Pakhaas schreef op vrijdag 26 juni 2026 @ 12:05:
[...]

Waarom maak je dit in package en niet in GUI? Daar kan je ook gewoon een yaml code plakken en hoef je niet in package dingen aan te maken.

Zal best zo zijn, ik ben geen ha expert. Gelukkig zijn er meer wegen die naar Rome leiden, kies degeen die je het prettigst vindt.

[stfn345]

@DeadMetal ik had vanochtend hetzelfde gedrag als jij. Ik gebruik modus "Dynamisch Handelen + NOM"
(2400AC+ fw 2.0.0 / met Gielz 20-06 en gast777 proxy)

Mijn accu's staan ingesteld om tot max 10% te ontladen (zowel in de Zendure app als in Gielz integratie).
Vanmorgen was de SoC naar 9% gezakt.

Ik keek vanmorgen op home assistant, en ik zag dat de accu's in standby stonden, terwijl er wel 800w overschot was. Ik had verwacht dat de gielz integratie in ieder geval overschot ging gebruiken om de accu bij te laden. Nadat ik even kort de accu's handmatig boven de 10% heb gebracht werkte "Dynamisch Handelen + NOM" weer zoals verwacht, maar toen hij (per ongeluk?) onder de 10% zat deed hij niets.

@gielz ps: hoort "Dynamisch Handelen + NOM" niet bij de opties in de automation te staan? Daar staan 10 opties in de automation, maar er zijn 11 opties?

[ppaulv]

Algemene vraag, er zijn inmiddels mensen met praktijk ervaring bij het vervangen van een Zendure stapel met gebruik van Gielz automatisering in HA.
Zijn er 'best practices' tips om dit soepel te laten verlopen?
Ik bedoel, ik heb nu vanalles gebruikt en/of zelf gemaakt op basis van m'n huidige omvormer maar gaat dat optimaal goed als ik die gewoon uit zet en de nieuwe omvormer aan zet (op hetzelfde ip-adres, dat lijkt me dan wel handig, of juist niet?)?

[gielz]

stfn345 schreef op zaterdag 27 juni 2026 @ 12:41:
@DeadMetal ik had vanochtend hetzelfde gedrag als jij. Ik gebruik modus "Dynamisch Handelen + NOM"
(2400AC+ fw 2.0.0 / met Gielz 20-06 en gast777 proxy)

Mijn accu's staan ingesteld om tot max 10% te ontladen (zowel in de Zendure app als in Gielz integratie).
Vanmorgen was de SoC naar 9% gezakt.

Ik keek vanmorgen op home assistant, en ik zag dat de accu's in standby stonden, terwijl er wel 800w overschot was. Ik had verwacht dat de gielz integratie in ieder geval overschot ging gebruiken om de accu bij te laden. Nadat ik even kort de accu's handmatig boven de 10% heb gebracht werkte "Dynamisch Handelen + NOM" weer zoals verwacht, maar toen hij (per ongeluk?) onder de 10% zat deed hij niets.

@gielz ps: hoort "Dynamisch Handelen + NOM" niet bij de opties in de automation te staan? Daar staan 10 opties in de automation, maar er zijn 11 opties?

Zie het probleem inderdaad ook. Dit komt omdat handelen überhaupt is uitgesloten van de soc bescherming. En NOM wacht juist op soc bescherming als deze actief staat.

Je zou voor nu het vinkje bij soc bescherming uitschakelen actief kunnen zetten. Dit weekend zal ik het even fixen voor de aankomende testrelease.

[gielz]

ppaulv schreef op zaterdag 27 juni 2026 @ 13:42:
Algemene vraag, er zijn inmiddels mensen met praktijk ervaring bij het vervangen van een Zendure stapel met gebruik van Gielz automatisering in HA.
Zijn er 'best practices' tips om dit soepel te laten verlopen?
Ik bedoel, ik heb nu vanalles gebruikt en/of zelf gemaakt op basis van m'n huidige omvormer maar gaat dat optimaal goed als ik die gewoon uit zet en de nieuwe omvormer aan zet (op hetzelfde ip-adres, dat lijkt me dan wel handig, of juist niet?)?

Als je gewoon al je historie wilt behouden is het een kwestie van het nieuwe ip adres in te vullen.

Zou daarna HA even herstarten.

[Moddemeijer]

ppaulv schreef op zaterdag 27 juni 2026 @ 13:42:
Algemene vraag, er zijn inmiddels mensen met praktijk ervaring bij het vervangen van een Zendure stapel met gebruik van Gielz automatisering in HA.
Zijn er 'best practices' tips om dit soepel te laten verlopen?
Ik bedoel, ik heb nu vanalles gebruikt en/of zelf gemaakt op basis van m'n huidige omvormer maar gaat dat optimaal goed als ik die gewoon uit zet en de nieuwe omvormer aan zet (op hetzelfde ip-adres, dat lijkt me dan wel handig, of juist niet?)?

Ik ben aan het experimenteren om te bepalen hoe goed NOM (nul op de meter) werkt. Het liefste zou ik een histogram maken van de output van de P1 meter. Op grond van breedte en vorm kan je dan goed beoordelen hoe goed NOM werkt. Helaas heb ik geen "frequentie histogram" tools voor HA kunnen vinden.

Toch wil ik de kwaliteit beoordelen op grond van objectieve meetwaarden. Immer meten is weten. Daarvoor heb ik vier statistische helpers gebouwd. Allen zijn gebaseerd op 5 min. meettijd en 300 samples. Als input gebruik ik het "vermogen" op de P1 meter:

1. het gemiddelde (linear average)
2. het 20% percentiel
3. het 80% percentiel
4. de standaard deviatie

Typische waarden die ik vanochtend bij NOM vond waren:

1. gemiddelde -2 W
2. 20% percentiel -11 W
3. 80% percentiel 9 W
4. standaard deviatie 12 W

Dit is heel goed. Bij NOM is de gemeten waarde 60% van de tijd tussen de -11 en +9 W. Ik was bezig om de "heartbeat" te verlagen en te kijken of ik de waarden nog iets kon verbeteren. Helaas was er te veel zon voor meer NOM metingen. Mijn eerste indruk is dat de heartbeat tot 2s verlaagd kan worden met een geringe verbetering. Bij 1s trad een verslechtering op.

[winwiz]

Moddemeijer schreef op zaterdag 27 juni 2026 @ 14:21:
[...]

Ik ben aan het experimenteren om te bepalen hoe goed NOM (nul op de meter) werkt. Het liefste zou ik een histogram maken van de output van de P1 meter. Op grond van breedte en vorm kan je dan goed beoordelen hoe goed NOM werkt. Helaas heb ik geen "frequentie histogram" tools voor HA kunnen vinden.

Toch wil ik de kwaliteit beoordelen op grond van objectieve meetwaarden. Immer meten is weten. Daarvoor heb ik vier statistische helpers gebouwd. Allen zijn gebaseerd op 5 min. meettijd en 300 samples. Als input gebruik ik het "vermogen" op de P1 meter:

1. het gemiddelde (linear average)
2. het 20% percentiel
3. het 80% percentiel
4. de standaard deviatie

Typische waarden die ik vanochtend bij NOM vond waren:

1. gemiddelde -2 W
2. 20% percentiel -11 W
3. 80% percentiel 9 W
4. standaard deviatie 12 W

Dit is heel goed. Bij NOM is de gemeten waarde 60% van de tijd tussen de -11 en +9 W. Ik was bezig om de "heartbeat" te verlagen en te kijken of ik de waarden nog iets kon verbeteren. Helaas was er te veel zon voor meer NOM metingen. Mijn eerste indruk is dat de heartbeat tot 2s verlaagd kan worden met een geringe verbetering. Bij 1s trad een verslechtering op.

Zit je niet veel moeite te doen voor misschien 200Wh per dag maximaal? Oftewel een 5 €ct. Dit is wat ik zo'n beetje gemiddeld zie als ik NOM draai en ook nog netjes in evenwicht tussen teruglevering en gebruik van het net.

[raven22]

Het was me al eerder opgevallen dat mijn Solarflow 800 plus snachts gaat laden als de SOC 10% bereikt.
Dit gedrag is ontstaan na de update naar 2.0. Voorheen bleef hij gewoon op 10% en ging in de ochtend weer laden van de via mppt aangekoppelde panelen. Dat is ook wat ik wil, alleen laden via PV, niet via AC.
Ik gebruik de @gielz integratie met de smart discharge only setting.
Is er iets veranderd in de automatisering? Kan ik beter een andere modus gebruiken?

[Keida]

ppaulv schreef op zaterdag 27 juni 2026 @ 13:42:
Algemene vraag, er zijn inmiddels mensen met praktijk ervaring bij het vervangen van een Zendure stapel met gebruik van Gielz automatisering in HA.
Zijn er 'best practices' tips om dit soepel te laten verlopen?
Ik bedoel, ik heb nu vanalles gebruikt en/of zelf gemaakt op basis van m'n huidige omvormer maar gaat dat optimaal goed als ik die gewoon uit zet en de nieuwe omvormer aan zet (op hetzelfde ip-adres, dat lijkt me dan wel handig, of juist niet?)?

Ik heb 3 2400AC omvormers ingewisseld voor 3 2400AC+ omvormers, om bekende redenen.

En enige dat ik heb gedaan is IP adres aanpassen in de proxy. Verder draait het perfect.

[gielz]

raven22 schreef op zondag 28 juni 2026 @ 07:29:
Het was me al eerder opgevallen dat mijn Solarflow 800 plus snachts gaat laden als de SOC 10% bereikt.
Dit gedrag is ontstaan na de update naar 2.0. Voorheen bleef hij gewoon op 10% en ging in de ochtend weer laden van de via mppt aangekoppelde panelen. Dat is ook wat ik wil, alleen laden via PV, niet via AC.
Ik gebruik de @gielz integratie met de smart discharge only setting.
Is er iets veranderd in de automatisering? Kan ik beter een andere modus gebruiken?

Je hebt SOC bescherming in de BMS zelf en in de Gielz. Die van de Gielz kun je uitschakelen door het vinkje te zetten. Dan blijft de BMS nog over die niet uit te schakelen is.

Kijk even in je logboek rond de tijd dat hij ging laden dan weet je meteen of het de BMS was of de Gielz.

[gielz]

Moddemeijer schreef op zaterdag 27 juni 2026 @ 14:21:
[...]

Ik ben aan het experimenteren om te bepalen hoe goed NOM (nul op de meter) werkt. Het liefste zou ik een histogram maken van de output van de P1 meter. Op grond van breedte en vorm kan je dan goed beoordelen hoe goed NOM werkt. Helaas heb ik geen "frequentie histogram" tools voor HA kunnen vinden.

Toch wil ik de kwaliteit beoordelen op grond van objectieve meetwaarden. Immer meten is weten. Daarvoor heb ik vier statistische helpers gebouwd. Allen zijn gebaseerd op 5 min. meettijd en 300 samples. Als input gebruik ik het "vermogen" op de P1 meter:

1. het gemiddelde (linear average)
2. het 20% percentiel
3. het 80% percentiel
4. de standaard deviatie

Typische waarden die ik vanochtend bij NOM vond waren:

1. gemiddelde -2 W
2. 20% percentiel -11 W
3. 80% percentiel 9 W
4. standaard deviatie 12 W

Dit is heel goed. Bij NOM is de gemeten waarde 60% van de tijd tussen de -11 en +9 W. Ik was bezig om de "heartbeat" te verlagen en te kijken of ik de waarden nog iets kon verbeteren. Helaas was er te veel zon voor meer NOM metingen. Mijn eerste indruk is dat de heartbeat tot 2s verlaagd kan worden met een geringe verbetering. Bij 1s trad een verslechtering op.

Je kunt ook even de "Helaas pindakaas" gebruiken. Dan is goed te zien waar je import heeft plaatsgevonden.

code:

type: custom:apexcharts-card
cache: true
stacked: true
update_interval: 5sec
span:
  start: day
header:
  show: true
  show_states: true
  title: Helaas pindakaas
graph_span: 1d
series:
  - entity: sensor.p1_meter_energy_import
    name: Helaas pindakaas
    group_by:
      func: diff
      duration: 1h
    type: column
    stroke_width: 0
    opacity: 1
    extend_to: now
    color: "#f1b605"
    float_precision: 5
    yaxis_id: energy
    show:
      in_header: false
  - entity: sensor.p1_meter_energy_import
    yaxis_id: header_only
    name: Vandaag (import)
    float_precision: 3
    statistics:
      period: day
      type: change
      align: start
    show:
      legend_value: true
      in_header: true
      in_chart: false
apex_config:
  toolbar:
    show: true
    tools:
      download: true
      selection: true
      zoom: true
      zoomin: true
      zoomout: true
      pan: true
  tooltip:
    x:
      format: HH:mm:ss
      show: false
  xaxis:
    labels:
      show: false
      style:
        colors: grey
    axisTicks:
      show: false
    axisBorder:
      color: "#616269"
  yaxis:
    - title:
        text: ""
      decimalsInFloat: 3
      labels:
        style:
          colors: "#7b7c83"
  grid:
    strokeDashArray: 0
    borderColor: rgb(52,52,52)
    show: true
  chart:
    height: 200px
  legend:
    show: false
  markers:
    size: 0
    hover:
      size: 0

[DeadMetal]

gielz schreef op zondag 28 juni 2026 @ 08:36:
[...]
Je kunt ook even de "Helaas pindakaas" gebruiken. Dan is goed te zien waar je import heeft plaatsgevonden.

Deze verwijst naar 'sensor.p1_meter_energy_import' welke ik niet heb. Wat voor entiteit moet ik naar verwijzen? Mijn huidig nettoverbruik (waar jouw integratie ook naar kijkt voor het NOMmen, maar die dus ook een negatief getal kan hebben), of een sensor puur voor wat er nu vanaf het net komt (ik heb sensor.electricity_meter_energieverbruik in kW)?

[ppaulv]

Keida schreef op zondag 28 juni 2026 @ 08:15:
[...]

Ik heb 3 2400AC omvormers ingewisseld voor 3 2400AC+ omvormers, om bekende redenen.

En enige dat ik heb gedaan is IP adres aanpassen in de proxy. Verder draait het perfect.

dat is goed om te horen.

[raven22]

gielz schreef op zondag 28 juni 2026 @ 08:34:
[...]


Je hebt SOC bescherming in de BMS zelf en in de Gielz. Die van de Gielz kun je uitschakelen door het vinkje te zetten. Dan blijft de BMS nog over die niet uit te schakelen is.

Kijk even in je logboek rond de tijd dat hij ging laden dan weet je meteen of het de BMS was of de Gielz.

ok, dus als ik in gielz de minimum soc op 11 of 12 % zet dan blijf ik wellicht boven de grens dat het bms het overneemt. zal eens wat testen.

[gielz]

raven22 schreef op zondag 28 juni 2026 @ 13:54:
[...]

ok, dus als ik in gielz de minimum soc op 11 of 12 % zet dan blijf ik wellicht boven de grens dat het bms het overneemt. zal eens wat testen.

Helaas niet want dan denkt de BMS “hey ik zit onder de 12% bijladen die hap”

[raven22]

gielz schreef op zondag 28 juni 2026 @ 14:07:
[...]


Helaas niet want dan denkt de BMS “hey ik zit onder de 12% bijladen die hap”

Je kunt dus nooit meer de batterij ontladen snachts tot de minimum soc en dan de volgende ochtend via pv weer opladen. Vind ik toch beetje vreemd en zeker niet de bedoeling denk ik. Als de batterij nou een week of meer niet op de 100% gezeten heeft voor calibratie dan snap ik het nog, maar als dit dagelijks zo gaat zijn dan heb je er weinig aan.

[gielz]

raven22 schreef op zondag 28 juni 2026 @ 14:32:
[...]

Je kunt dus nooit meer de batterij ontladen snachts tot de minimum soc en dan de volgende ochtend via pv weer opladen. Vind ik toch beetje vreemd en zeker niet de bedoeling denk ik. Als de batterij nou een week of meer niet op de 100% gezeten heeft voor calibratie dan snap ik het nog, maar als dit dagelijks zo gaat zijn dan heb je er weinig aan.

Wat je zou kunnen doen om de BMS te foppen is als volgt;

Zet je minimale soc op 5% en vervolgens met een automatisering laat je hem al op 10% naar een bepaalde modus schieten en terug.

[DeadMetal]

Hippe Lip schreef op dinsdag 19 mei 2026 @ 22:51:
Vanavond heb ik de montage van mijn 200 mm grote ventilatoren afgerond en ik wil het resultaat hier showen. Mogelijk dat anderen er wat aan hebben.

Dank, inmiddels heb ik het ook zo geregeld. De USB-versie. Ventilatoren springen aan als de omvormer boven de 42gr uitkomt, uit onder de 35 graden. Zendures blijven nu op vol vermogen werken, throttlen niet meer.

[ Voor 87% gewijzigd door DeadMetal op 28-06-2026 15:29 ]

[Cardinal]

@DeadMetal welke Mooie 200mm noctuas zijn dat

[ Voor 18% gewijzigd door Cardinal op 28-06-2026 16:21 ]

[klmtrf]

Ik heb drie foutmeldingen in mijn dashboard waarvan ik niet weet hoe ik het oplos. Op de plekken Configuration (basic), Logbook (last 4 hours) en Version staat de melding unknown.

Iemand een idee hoe ik dit oplos?

[Hippe Lip]

DeadMetal schreef op zondag 28 juni 2026 @ 15:27:
Dank, inmiddels heb ik het ook zo geregeld. De USB-versie. Ventilatoren springen aan als de omvormer boven de 42gr uitkomt, uit onder de 35 graden. Zendures blijven nu op vol vermogen werken, throttlen niet meer.

Mooi werk, @DeadMetal Dank voor terugkoppeling

Het fraaie blijf ik de eenvoud hiervan vinden. Minimalistische oplossing die precies doet wat die moet doen: throttling voorkomen en nix meer dan dat.

Edit
Ik zie dat je de roosters met schroefjes vastgezet hebt. Ik had daar van die rubber dingetjes bijgekregen en dan het rooster er achterstevoren op gezet. Dan zit het dichter tegen de fan aan.
Verder totaal onbelangrijk.

[ Voor 20% gewijzigd door Hippe Lip op 28-06-2026 21:59 ]

[gielz]

klmtrf schreef op zondag 28 juni 2026 @ 20:01:
Ik heb drie foutmeldingen in mijn dashboard waarvan ik niet weet hoe ik het oplos. Op de plekken Configuration (basic), Logbook (last 4 hours) en Version staat de melding unknown.

Iemand een idee hoe ik dit oplos?

[Afbeelding]

[Afbeelding]

[Afbeelding]

[Afbeelding]

Welke Home Assistant versie draai je want deze functie is relatief nieuw (2026.2)

https://www.home-assistan...tons-to-your-heading-card

[ Voor 4% gewijzigd door gielz op 29-06-2026 08:03 ]

[Cezus]

ctrl-tab schreef op zondag 3 mei 2026 @ 21:30:
[...]
- let op ik gebruik input values voor vat (.21) , opslag (0.02) , tax (0.091), kan je er ook statisch in zetten (zonneplan)

[...]

Ik probeer de berekening een beetje tot me te nemen. Als ik nu in de geïntegreerde HA NordPool integratie kijk is de hoogste prijs 0,42 euro per kwh. Volgens mijn Zonneplan app is de hoogste prijs 0,556 euro, dit is volgens de app incl. energiebelasting.

Als ik dan vervolgens de bovenstaande berekening er op los laat kom ik op 0,64251 euro per kwh. Mis ik iets of doe ik iets verkeerd?

[Wai_AM]

Cezus schreef op maandag 29 juni 2026 @ 10:49:
[...]

Ik probeer de berekening een beetje tot me te nemen. Als ik nu in de geïntegreerde HA NordPool integratie kijk is de hoogste prijs 0,42 euro per kwh. Volgens mijn Zonneplan app is de hoogste prijs 0,556 euro, dit is volgens de app incl. energiebelasting.

Als ik dan vervolgens de bovenstaande berekening er op los laat kom ik op 0,64251 euro per kwh. Mis ik iets of doe ik iets verkeerd?

Dit is de formule: current_price = price_now + (price_now * vat) + (electricity_tax + purchase_costs) * (1 + vat)
Kijk maar waar jou berekening niet overeenkomt.
0,248776 = 0.0975 + (0.0975 * 0,21) + (0.0916 + 0.0165) * (1 + 0,21)
Komt precies overeen.

Je nordpool is kwartier prijs en die vergelijk je met zonneplan uurprijs

[ Voor 20% gewijzigd door Wai_AM op 29-06-2026 11:29 ]

[Cezus]

Wai_AM schreef op maandag 29 juni 2026 @ 11:19:
[...]

Dit is de formule: current_price = price_now + (price_now * vat) + (electricity_tax + purchase_costs) * (1 + vat)
Kijk maar waar jou berekening niet overeenkomt.[Afbeelding]
0,248776 = 0.0975 + (0.0975 * 0,21) + (0.0916 + 0.0165) * (1 + 0,21)
Komt precies overeen.

Je nordpool is kwartier prijs en die vergelijk je met zonneplan uurprijs

[...]

Bedankt voor de verduidelijking! Nu snap ik hem. In mijn hoofd zou er één kwartier niet zo heel ver boven de kwartier ervoor en kwartier erna uit steken, maar dat is wel het geval dus. De rest vande kwartieren in dat uur trekken het gemiddelde gewoon ver naar beneden

[ppaulv]

Cezus schreef op maandag 29 juni 2026 @ 11:40:
[...]

Bedankt voor de verduidelijking! Nu snap ik hem. In mijn hoofd zou er één kwartier niet zo heel ver boven de kwartier ervoor en kwartier erna uit steken, maar dat is wel het geval dus. De rest vande kwartieren in dat uur trekken het gemiddelde gewoon ver naar beneden

kortere formule is dus :
current_price = (price_now + electricity_tax + purchase_costs) * (1 + vat)

[mussov]

Momenteel gebruik ik de SDK van Zendure zelf (2x Zendure 2400AC+). Echter wil ik met het ingaan van een dynamisch contract per 1 juli zoveel mogelijk eruit halen en overweeg ik de Gielz integratie te gaan gebruiken (met Node-RED proxy).

Wat is dan de beste modus om te gebruiken incl. laadpaal (Peblar; zelf aan te sturen) en zonnepanelen (+- 5,5 kW piek opbrengst). Ik ben het overzicht namelijk een kwijt met de vele opties die er zijn (en de combinatie zonnepanelen).

Ik wil soms vroeg in de ochtend (op basis van andere boolean/automation in HA) nog 2-3 kWh in de batterijen overhouden om NOM te blijven behouden. Dit laatste kan wellicht gewoon door de modus vanaf een bepaald tijdstip aan te passen naar NOM en daarna weer naar modus 'x'? Net als bij het laden van de EV mogelijk de modus tijdelijk naar 'Standby' zetten en dan weer naar modus 'x'?

Als ik alles goed heb doorgenomen zou volgens mij Dynamisch Handelen + NOM het beste 'rendement' moeten opleveren? Zijn er nog specifieke dingen waar ik rekening mee moet houden of die ik over het hoofd zie?

[BestevaerNL]

ppaulv schreef op maandag 29 juni 2026 @ 12:57:
[...]

kortere formule is dus :
current_price = (price_now + electricity_tax + purchase_costs) * (1 + vat)

Waar moet je deze formule invullen?

[ppaulv]

BestevaerNL schreef op maandag 29 juni 2026 @ 16:46:
[...]

Waar moet je deze formule invullen?

Nergens denk ik, heb iig geen idee, het ging me alleen om de formule die wat netter opgeschreven kon worden.

[Hippe Lip]

mussov schreef op maandag 29 juni 2026 @ 15:56:
Momenteel gebruik ik de SDK van Zendure zelf (2x Zendure 2400AC+). Echter wil ik met het ingaan van een dynamisch contract per 1 juli zoveel mogelijk eruit halen en overweeg ik de Gielz integratie te gaan gebruiken (met Node-RED proxy).

Wat is dan de beste modus om te gebruiken incl. laadpaal (Peblar; zelf aan te sturen) en zonnepanelen (+- 5,5 kW piek opbrengst). Ik ben het overzicht namelijk een kwijt met de vele opties die er zijn (en de combinatie zonnepanelen).

Ik wil soms vroeg in de ochtend (op basis van andere boolean/automation in HA) nog 2-3 kWh in de batterijen overhouden om NOM te blijven behouden. Dit laatste kan wellicht gewoon door de modus vanaf een bepaald tijdstip aan te passen naar NOM en daarna weer naar modus 'x'? Net als bij het laden van de EV mogelijk de modus tijdelijk naar 'Standby' zetten en dan weer naar modus 'x'?

Als ik alles goed heb doorgenomen zou volgens mij Dynamisch Handelen + NOM het beste 'rendement' moeten opleveren? Zijn er nog specifieke dingen waar ik rekening mee moet houden of die ik over het hoofd zie?

@mussov
Hier nagenoeg dezelfde configuratie. Als het je gaat om maximaal financieel rendement (tot 1 januari), dan kun je het beste uitsluitend dynamisch handelen. Ik heb ook 2x Zendure 2400AC+ met onder elk nog 3 extra batterijen. Samen dus 22 kWh.
Ik heb de Gielz ingesteld op Dynamic Trading en de instelling met 24 goedkoopste periodes en 20 duurste periodes werkt het beste. Vul dat in voor vandaag en morgen, zodat dit automatisch elke dag herhaald wordt.
Het laden duurt net iets korter, maar op deze manier weet je zeker dat je niet nét tijd tekort komt.
Ontladen duurt minder lang vanwege de (ca. 15%) verliezen.
Gebruik van NOMis financieel ongunstig, maar dat zal volgend jaar wel anders zijn. Nu nog niet doen dus.

Voor het laden van de auto gebruik ik een tweede integratie van @gielz: Dynamisch-HA. Die laat ik mijn laadpaal aansturen. Daar stel ik in hoeveel goedkoopste kwartieren ik wil laden. Via een automatisering die kijkt of de sensor.dynamisch_goedkoopste_periode op ‘ja’ staat, wordt de auto dan full-power geladen.
Op die manier kun je je auto altijd op de goedkoopste manier laden. Volledig onafhankelijk van je Zendures.
Voor volgend jaar zal ik een nieuwe configuratie moeten bedenken.

Zorg wel dat je voor je Zendures de Engelse versie van de Gielz (én van de proxy!) installeert. Want alleen dankun je beide integraties van Gielz tegelijk gebruiken en zitten ze elkaar niet in de weg.

Dit verhaal heb ik hier al eens eerder gepost, maar kan het helaas niet meer vinden.

[NiCNCo]

Als iemand interesse heeft voor dynamische load balancing voor wie met 2 of 3 zendures ieder op eigen fase met Node-red Proxy draait van Gast777 met de Gielz automation.

Zie hier de link tot de verdere info,
Github Gast777 Proxy: 3 Fase dynamic Load balancing uitgewerkt en succesful getest, #18

Enkel de Proxy flow hoeft ingeladen te worden, en in Gielz en HA hoeft verder niks gewijzigd te worden. Ik heb Gast777 gevraagd te overwegen deze toevoeging van Dynamic Load Fase Balancing standaard onderdeel te maken van zijn toekomstige Proxy-flows. Wie weet, het werkt hier bij mij super iig. Doe ermee wat je wilt, testen op eigen risico natuurlijk. Maar hier al uitvoerig getest met drie SolarFlow 2400AC+ stapels zonder problemen. De geupgrade flow is te downloaden via de link onderaan het eerste bericht, en is gebaseerd op Gast777 laaste versie 20260618.

(LET OP: dit is enkel voor de gebruikers die alles Nederlandse hebben draaien van Gielz in HA)
(LET OP: dit script gaat ervan dat P1 phase 1 Zendure 1 is. P1 p2=Zendure 2, P1 p3=Zendure 3)
Er zit dus geen phase rotatie settings optie op.

Voorbeelden van Node-red logs wanneer load balancing actief is:


En hier een voorbeeld hoe de extra load balancing settings naar wens aangepast kunnen worden:

[ Voor 52% gewijzigd door NiCNCo op 29-06-2026 18:51 ]

[Moddemeijer]

@Wai_AM De berekening van de Consumentenprijs is mij duidelijk. Ik kan helaas weinig vinden over de "Consumentenprijs" bij teruglevering. De Energiebelasting valt weg. In plaats van een Inkoopvergoeding is er een Terugleververgoeding. Hoe het zit met de BTW is onduidelijk.

[g00gle]

Ik mis een entiteit op m'n dashboard. Ik draaide nog een hele oude Gielz intergratie, ik heb alles opnieuw geïnstalleerd en alles werkt. Maar ik mis deze Entiteit. Weet niet goed welke dit is en waar ik die terug kan vinden / fixen. Iemand een suggestie? Of heeft die gewoon even tijd nodig



Nevermind, schakelen naar "Standby" en weer terug fixt het! Excuus.

Edit 2:
Het komt weer terug, heb nu weer bovenstaande beeld. Geen idee waar ik het moet zoeken.

Ik vermoed dat het "sensor.zendure_2400_ac_resterende_ontlaad_tijd" is. Maar die bestaat wel en is gevuld:

[ Voor 33% gewijzigd door g00gle op 29-06-2026 22:15 ]

[gielz]

g00gle schreef op maandag 29 juni 2026 @ 22:06:
Ik mis een entiteit op m'n dashboard. Ik draaide nog een hele oude Gielz intergratie, ik heb alles opnieuw geïnstalleerd en alles werkt. Maar ik mis deze Entiteit. Weet niet goed welke dit is en waar ik die terug kan vinden / fixen. Iemand een suggestie? Of heeft die gewoon even tijd nodig

[Afbeelding]

Nevermind, schakelen naar "Standby" en weer terug fixt het! Excuus.

Edit 2:
Het komt weer terug, heb nu weer bovenstaande beeld. Geen idee waar ik het moet zoeken.

Ik vermoed dat het "sensor.zendure_2400_ac_resterende_ontlaad_tijd" is. Maar die bestaat wel en is gevuld:
[Afbeelding]

Waarschijnlijk ooit een testversie gedraaid waardoor deze sensor een id heeft met _2. Verwijder je dat dan werkt het weer.

[YvonneVP]

Cezus schreef op maandag 29 juni 2026 @ 10:49:
[...]

Ik probeer de berekening een beetje tot me te nemen. Als ik nu in de geïntegreerde HA NordPool integratie kijk is de hoogste prijs 0,42 euro per kwh. Volgens mijn Zonneplan app is de hoogste prijs 0,556 euro, dit is volgens de app incl. energiebelasting.

Als ik dan vervolgens de bovenstaande berekening er op los laat kom ik op 0,64251 euro per kwh. Mis ik iets of doe ik iets verkeerd?

Voor Zonneplan heb ik de volgende instellingen en template code, en die heeft dan dezelfde bedragen als je in de Zonneplan app ziet staan


Region: NL

Currency: EUR

Vink VAT uit

additional_costs template code:

{% set p = current_price | float(0) %}

{% set opslag = 0.01653 %}

{% set vat = 1.21 %}

{% set energiebelasting = 0.1108 %}

{{ ( ((p + opslag) * vat + energiebelasting) - p ) | float }}

[BestevaerNL]

YvonneVP schreef op dinsdag 30 juni 2026 @ 01:46:
[...]

Voor Zonneplan heb ik de volgende instellingen en template code, en die heeft dan dezelfde bedragen als je in de Zonneplan app ziet staan


Region: NL

Currency: EUR

Vink VAT uit

additional_costs template code:

{% set p = current_price | float(0) %}

{% set opslag = 0.01653 %}

{% set vat = 1.21 %}

{% set energiebelasting = 0.1108 %}

{{ ( ((p + opslag) * vat + energiebelasting) - p ) | float }}

Kan je deze aanpassing van je template delen?

[gielz]

BestevaerNL schreef op dinsdag 30 juni 2026 @ 06:51:
[...]

Kan je deze aanpassing van je template delen?

Yvonne gebruikt dit met haar code;
gielz in "Zendure producten in Home Assistant integreren deel 2"

[YvonneVP]

gielz schreef op dinsdag 30 juni 2026 @ 07:07:
[...]


Yvonne gebruikt dit met haar code;
gielz in "Zendure producten in Home Assistant integreren deel 2"

En die zou in principe voor elke Nederlandse energieleverancier moeten werken, al zal men dan het bedrag van de opslag (ex btw) misschien wel aan moeten passen omdat die per leverancier anders kan zijn bij een dynamisch energiecontract.

[BestevaerNL]

gielz schreef op dinsdag 30 juni 2026 @ 07:07:
[...]


Yvonne gebruikt dit met haar code;
gielz in "Zendure producten in Home Assistant integreren deel 2"

Misschien een aanvulling voor je readme in GitHub? Ik denk dat veel gebruikers hun leveranciergegevens in je dashboard willen kunnen inzien.

De config van Norpool is niet jouw verantwoordelijkheid. Maar het is wel van belang om gericht je accu te kunnen sturen.

[ Voor 13% gewijzigd door BestevaerNL op 30-06-2026 09:20 ]