Zendure producten in Home Assistant integreren deel 2

[R.K]

Ik krijg met enige regelmaat een AC-error in het logboek van HA, Die error duurt exact een seconde en is dan weer weg.. In de app zie ik er niets van terug. Komt op willekeurige tijden, maar duurt nooit langer dan een seconde.

Iemand een idee?

[ Voor 52% gewijzigd door R.K op 22-06-2026 20:17 ]

[Devke]

R.K schreef op maandag 22 juni 2026 @ 19:55:
Ik krijg met enige regelmaat een AC-error in het logboek van HA, Die error duurt exact een seconde en is dan weer weg.. In de app zie ik er niets van terug. Komt op willekeurige tijden, maar duurt nooit langer dan een seconde.

Iemand een idee?


[Afbeelding]

Ik denk als je bij andere sensoren kijkt dat je hetzelfde ziet. Wifi. Er is even geen connectie tussen HA en je batterijen. Zolang het bij een seconde blijft zou ik er niet zo wakker van liggen.

[R.K]

Devke schreef op maandag 22 juni 2026 @ 20:36:
[...]

Ik denk als je bij andere sensoren kijkt dat je hetzelfde ziet. Wifi. Er is even geen connectie tussen HA en je batterijen. Zolang het bij een seconde blijft zou ik er niet zo wakker van liggen.

Andere sensoren waaronder WiFi hebben het ook rond dezelfde tijd, maar dat kan natuurlijk ook komen omdat er een storing in het apparaat zelf is. Heb onlangs eens het knopje op de omvormer ingedrukt, toen was het bliksenschichtje rood, om gelijk weer naar groen te gaan.

[Devke]

R.K schreef op maandag 22 juni 2026 @ 21:12:
[...]

Andere sensoren waaronder WiFi hebben het ook rond dezelfde tijd, maar dat kan natuurlijk ook komen omdat er een storing in het apparaat zelf is. Heb onlangs eens het knopje op de omvormer ingedrukt, toen was het bliksenschichtje rood, om gelijk weer naar groen te gaan.

Hier zie ik dat ook. Of het bliksemschichtje dan ook even rood is? Zo snel ben ik niet meer 🤣

[koboy]

Pvdbogaard schreef op maandag 22 juni 2026 @ 14:13:
@RemmyB83 Maar hoe verklaard dat de 500W teruglevering midden in de nacht, ongeveer elke minuut? Ik zal de instelling naar 10s zetten.

De aansturing in Gielz staat standaard op 5 seconden om ook de batterij tijd te geven te reageren. Met een update frequentie van 10 seconden vanuit de meter zou ik hem eerder op 20 of 25 seconden zetten om te beginnen, en eventueel daarvanuit langzaamaan experimenterend terug.

[RemmyB83]

koboy schreef op maandag 22 juni 2026 @ 21:19:
[...]

De aansturing in Gielz staat standaard op 5 seconden om ook de batterij tijd te geven te reageren. Met een update frequentie van 10 seconden vanuit de meter zou ik hem eerder op 20 of 25 seconden zetten om te beginnen, en eventueel daarvanuit langzaamaan experimenterend terug.

Inprincipe heeft de batterij genoeg tijd om zich aan te passen. Ik begrijp daarom ook niet, waarom 20sec dan opeens beter zou zijn. Enige probleem kan zijn dat gielz interval valt in seconde 9 van die van de slimmemeter, en hij daardoor grotedeels achter de feiten aanloopt. Al kun je dat ook oplossen door gielz niet per 10sec in te stellen, maar te laten updaten zodra er een update is vanuit de slimmemeter

[ Voor 9% gewijzigd door RemmyB83 op 22-06-2026 22:03 ]

[YvonneVP]

ctrl-tab schreef op zaterdag 20 juni 2026 @ 07:56:
[...]

Dus met wat overcapaciteit die je wilt verhandelen is nextenergie het best. Einde jaar eens kijken !

Er zullen misschien nog wijzigingen gaan komen onder de energieleveranciers. Ik hoop dat ze concurrerender gaan worden net als wanneer je een vast tarief hebt. Het wordt inderdaad even aankijken en in de gaten houden wat de energieleveranciers gaan doen. Waar ik niet op hoop is dat ze ook voor dynamische contracten een terugleververgoeding gaan vragen zoals bij veel vaste tarieven momenteel veelvuldig wel het geval is.

[koboy]

RemmyB83 schreef op maandag 22 juni 2026 @ 21:48:
[...]

Inprincipe heeft de batterij genoeg tijd om zich aan te passen. Ik begrijp daarom ook niet, waarom 20sec dan opeens beter zou zijn. Enige probleem kan zijn dat gielz interval valt in seconde 9 van die van de slimmemeter, en hij daardoor grotedeels achter de feiten aanloopt. Al kun je dat ook oplossen door gielz niet per 10sec in te stellen, maar te laten updaten zodra er een update is vanuit de slimmemeter

Het kost de batterij een paar seconden om op/af te regelen. Hierdoor is bij een 10 seconden update "fout". Door pas een meting later een nieuwe aanpassing zorg je er voor dat de accu zich aanpast aan een situatie die klopt waardoor je een rustiger regelgedrag krijgt doordat je overshoots voorkomt.

Stel je het volgende voor: er gaat een oven aan van 1500W (voor lange tijd). Bij een 10 seconden update krijg je dan:
- accu gaat op regelen naar 1500W
- 10s later geeft de meter nog 150W verbruik aan over de laatste 10s. De accu regelt op naar 1650W (wat veel minder tijd kost)
- 10s later geeft de meter 140W teruglevering aan, de accu regelt terug naar 1510W
Etc
Wanneer de oven uitgaat krijg je een overshoot naar terugleveren, waardoor de accu bij NOM ineens gaat laden en je een bak extra relais schakelingen krijgt.

Met een update frequentie van 20 secondes voorkom je de overshoot ten koste van een vertraagde reactie.

[koboy]

YvonneVP schreef op maandag 22 juni 2026 @ 22:15:
[...]

Er zullen misschien nog wijzigingen gaan komen onder de energieleveranciers. Ik hoop dat ze concurrerender gaan worden net als wanneer je een vast tarief hebt. Het wordt inderdaad even aankijken en in de gaten houden wat de energieleveranciers gaan doen. Waar ik niet op hoop is dat ze ook voor dynamische contracten een terugleververgoeding gaan vragen zoals bij veel vaste tarieven momenteel veelvuldig wel het geval is.

Die terugleverkosten zijn er vaak al in de vorm van inkoopkosten. Nextenergy is 1 van die partijen, dus die 50% is deels een sigaar uit eigen doos. Om deze reden komt Zonneplan er bij lage tarieven als beste uit.

[DrNickB]

Gramser schreef op zondag 14 juni 2026 @ 18:37:
@gast777 Het zou zomaar kunnen, wat je schetst. Dat de 2400AC en 2400AC+ meer verschillen dan we denken wat dit issue betreft.

Hoe dan ook - de zendures zitten nu op een apart SSID op een bedraad AP. Helemaal voor hen alleen. We gaan kijken wat er gebeurt.

Ik kan nu trouwens wel besluiten het AP op een HW Energy Socket te zetten voor een remote herstart

Nee Gramser - afblijven nou!

Zet je wel je HW op diezelfde SSID? Anders verliest die misschien ook z'n verbinding!

Oke, Oke oude uit de sloot, maar niemand had hem gemaakt!

[jelleeelco]

Ik ben behoorlijk bezig geweest met mijn nieuwe beste vriend Claude Code. Ik had de @gielz integratie draaien, dat werkte perfect. Toen ik de nieuwe set (2400AC+) kreeg ben ik gaan experimenteren met de Node Red flow van @gast777 . Werkte ook echt super, vele malen beter dan de logica van HEMS.

Maar ik wilde de 2400AC laden/ontladen op 800watt (veiligheid, maar ook om te testen hoe de pieken worden opgevangen als test voor een eventuele aanschaf van een SolarFlow 800+), en de 2400AC+ op 2400/2400. Dit was met de huidige flow niet mogelijk.

Inmiddels heb ik de Node Red integratie dusdanig aangepast dat je per inverter het IP adres, het laadvermogen, ontlaad-vermogen, en de capaciteit kan instellen op het dashboard. De Node Red flow pikt nieuwe waarden iedere minuut automatisch op.

Daarnaast heb ik een nieuwe automatisering gebouwd die het volgende doet:
1. Rond 13:00 worden de prijzen van Nord Pool ingeladen
2. Dan wordt er een analyse gemaakt op basis van:
a. Verbruik afgelopen dagen
b. Voorspelde opbrengst van de zonnepanelen
c. beste laadschema voor de accu's op basis van de laagste tarieven

Hiermee wordt dan een laadplan gemaakt. Dit laadplan wordt naar mij gemaild. Daarin staat het plan (welke uren er met welk vermogen wordt geladen), hoeveel dat oplevert (gemiddelde prijs per kWh voor de hele dag) en hoeveel het voor de hele dag gaat kosten. Tevens daaronder de gegevens van als je niets doet. Dan staat er twee knoppen: Accept en Reject. Bij Accept gaat het systeem automatisch de Gielz integratie aansturen door op die tijdstippen de laden volgens het plan (in Gielz heb ik dan ook een extra modus moeten toevoegen: "Geoptimeerd laden").

Als je reject, verandert er niets. Je krijgt keurig een email dat je accepted / rejected hebt.

Helaas ben ik absoluut geen code expert zoals @gielz of @gast777 en heb ik bijna alles door Claude laten doen (zelfs toegang gegeven tot HA en de entries, helpers, etc laten aanmaken). Ik zie hier ook gelijk een nadeel in - je bouwt zelf geen kennis op. Maar het werkt wel . Het is nog zeker niet perfect, in de zomer zal het veel minder goed werken dan in de winter. En het 'thuisverbruik' is inclusief het huidige laden van de accu, terwijl Claude denkt dat er 6.xx kWh 'over' is voor de accu. Maar dit zijn schoonheidsfoutjes die (denk ik) het plan niet zullen veranderen (in de winter althans, waarvoor het bedoeld is).

Hieronder wat screenshots... mocht er interesse zijn kan ik wel delen (ik denk via Github of per mail); voor Github moet ik even tijd inruimen (ben veel op reis). Ik heb Claude ook nog gevraagd of het mogelijk was om de totale integratie (Chielz en Gast777) te verwerken in een apart programma / automatisering. Maar ik kreeg het advies dat niet te doen: Claude gaf aan dat de integratie op deze manier eigenlijk al 'perfect' is .

[ Voor 5% gewijzigd door jelleeelco op 23-06-2026 10:55 ]

[Hippe Lip]

Jammer inderdaad dat je zo zelf geen inhoudelijke kennis opbouwt, @jelleeelco

Ik ben bijvoorbeeld wel nieuwsgierig in de module in HA die de mail verzend maar vooral ook naar de constructie in de mail met de knoppen. Wat gebeurt er als je op een knop drukt, hoe komt dat bij HA terecht, hoe is die communicatie? Werkt dat ook als je niet thuis bent als je op die knop in de mail drukt?

[Mimiix]

jelleeelco schreef op dinsdag 23 juni 2026 @ 10:53:
Ik ben behoorlijk bezig geweest met mijn nieuwe beste vriend Claude Code. Ik had de @gielz integratie draaien, dat werkte perfect. Toen ik de nieuwe set (2400AC+) kreeg ben ik gaan experimenteren met de Node Red flow van @gast777 . Werkte ook echt super, vele malen beter dan de logica van HEMS.

Maar ik wilde de 2400AC laden/ontladen op 800watt (veiligheid, maar ook om te testen hoe de pieken worden opgevangen als test voor een eventuele aanschaf van een SolarFlow 800+), en de 2400AC+ op 2400/2400. Dit was met de huidige flow niet mogelijk.

Inmiddels heb ik de Node Red integratie dusdanig aangepast dat je per inverter het IP adres, het laadvermogen, ontlaad-vermogen, en de capaciteit kan instellen op het dashboard. De Node Red flow pikt nieuwe waarden iedere minuut automatisch op.

Daarnaast heb ik een nieuwe automatisering gebouwd die het volgende doet:
1. Rond 13:00 worden de prijzen van Nord Pool ingeladen
2. Dan wordt er een analyse gemaakt op basis van:
a. Verbruik afgelopen dagen
b. Voorspelde opbrengst van de zonnepanelen
c. beste laadschema voor de accu's op basis van de laagste tarieven

Hiermee wordt dan een laadplan gemaakt. Dit laadplan wordt naar mij gemaild. Daarin staat het plan (welke uren er met welk vermogen wordt geladen), hoeveel dat oplevert (gemiddelde prijs per kWh voor de hele dag) en hoeveel het voor de hele dag gaat kosten. Tevens daaronder de gegevens van als je niets doet. Dan staat er twee knoppen: Accept en Reject. Bij Accept gaat het systeem automatisch de Gielz integratie aansturen door op die tijdstippen de laden volgens het plan (in Gielz heb ik dan ook een extra modus moeten toevoegen: "Geoptimeerd laden").

Als je reject, verandert er niets. Je krijgt keurig een email dat je accepted / rejected hebt.

Helaas ben ik absoluut geen code expert zoals @gielz of @gast777 en heb ik bijna alles door Claude laten doen (zelfs toegang gegeven tot HA en de entries, helpers, etc laten aanmaken). Ik zie hier ook gelijk een nadeel in - je bouwt zelf geen kennis op. Maar het werkt wel . Het is nog zeker niet perfect, in de zomer zal het veel minder goed werken dan in de winter. En het 'thuisverbruik' is inclusief het huidige laden van de accu, terwijl Claude denkt dat er 6.xx kWh 'over' is voor de accu. Maar dit zijn schoonheidsfoutjes die (denk ik) het plan niet zullen veranderen (in de winter althans, waarvoor het bedoeld is).

Hieronder wat screenshots... mocht er interesse zijn kan ik wel delen (ik denk via Github of per mail); voor Github moet ik even tijd inruimen (ben veel op reis). Ik heb Claude ook nog gevraagd of het mogelijk was om de totale integratie (Chielz en Gast777) te verwerken in een apart programma / automatisering. Maar ik kreeg het advies dat niet te doen: Claude gaf aan dat de integratie op deze manier eigenlijk al 'perfect' is .

[Afbeelding]


[Afbeelding]

[Afbeelding]

Tof! Zitten deze panelen ook op je accu aangesloten? Of is dit via 220v?

[DeadMetal]

Interessant. Hoewel ik het niet in deze vorm wil implementeren (mailtjes e.d, ik hou alles liever binen HA zelf), merk ik dat ik nog wel eens worstel met de vraag 'of er op de goedkope momenten bijgeladen moet worden uit het net'. Concreet komt dat dus neer op 'welk getal vul ik in bij "goedkoopste periodes vandaag"?', wat weer afhangt van hoe vol de batterij nu is, hoeveel zonopbrengst er te verwachten valt, en hoe vol je de accu uberhaupt wil hebben bij bijv. het begin van de duurdere uren (bijv. begin van de avond).
Bijv. valt er nog wat te handelen in de avond versus een 'vlakke dag' qua prijscurve waarbij wat er overdag door de zonnepanelen de accu ingaat, meer dan genoeg is voor de avond/nacht (NOM).

Ik moet me nog steeds verdiepen in Day Ahead Optimizer, of dat wat voor me is Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO maar ik wacht even af tot mijn nieuwe zonnepanelensysteem er over een week of twee ligt.

[jelleeelco]

Hippe Lip schreef op dinsdag 23 juni 2026 @ 11:11:
Jammer inderdaad dat je zo zelf geen inhoudelijke kennis opbouwt, @jelleeelco

Ik ben bijvoorbeeld wel nieuwsgierig in de module in HA die de mail verzend maar vooral ook naar de constructie in de mail met de knoppen. Wat gebeurt er als je op een knop drukt, hoe komt dat bij HA terecht, hoe is die communicatie? Werkt dat ook als je niet thuis bent als je op die knop in de mail drukt?

Ja, dat is wel het grote nadeel van AI. Kijk ik leer er alsnog wel iets van, maar niet zoveel als dat je het zelf bouwt.

Die knoppen werken idd alleen als ik thuis ben, of als ik via WireGuard met mijn thuisnetwerk verbonden ben. Dat had Claude ook anders kunnen doen en heeft hij ook voorgesteld, maar ik heb daar geen interesse in (geen noodzaak). Het was voor mij ook allemaal een theoretische exercitie OF Claude dit allemaal zou kunnen en hoe...Mijn doel was om meer te leren om met AI te werken dan dat ik HA wilde leren kennen.

Die email werkt met notify.gmail in HA.

[ Voor 7% gewijzigd door jelleeelco op 23-06-2026 12:22 ]

[R.K]

Hoi, Ik gebruik de Gielz aansturing voor mijn SF2400 met 4 batterijen. Ik heb echter het idee dat mijn batterijvolgorde niet klopt. Ik heb het wel juist in de Zendure integratie maar Gielz gebruikt die sensoren niet voor de aansturing.

Hoe kom ik er achter welke batterij waar hoort binnen de Gielz aansturing?

bvd,

[jelleeelco]

R.K schreef op dinsdag 23 juni 2026 @ 13:31:
Hoi, Ik gebruik de Gielz aansturing voor mijn SF2400 met 4 batterijen. Ik heb echter het idee dat mijn batterijvolgorde niet klopt. Ik heb het wel juist in de Zendure integratie maar Gielz gebruikt die sensoren niet voor de aansturing.

Hoe kom ik er achter welke batterij waar hoort binnen de Gielz aansturing?

bvd,

batterij volgorde klopt zelfs in de app van Zendure niet...ik vraag me af of het relevant is

[R.K]

jelleeelco schreef op dinsdag 23 juni 2026 @ 13:39:
[...]

batterij volgorde klopt zelfs in de app van Zendure niet...ik vraag me af of het relevant is

Daar klopte het idd ook niet maar daar kun je de naam veranderen zodat het serienummer klopt met de batterij 1,2,3,of 4.

Relevant is het zeker niet maar wil het graag op volgorde hebben, tweaker

[ctrl-tab]

R.K schreef op dinsdag 23 juni 2026 @ 13:31:
Hoi, Ik gebruik de Gielz aansturing voor mijn SF2400 met 4 batterijen. Ik heb echter het idee dat mijn batterijvolgorde niet klopt. Ik heb het wel juist in de Zendure integratie maar Gielz gebruikt die sensoren niet voor de aansturing.

Hoe kom ik er achter welke batterij waar hoort binnen de Gielz aansturing?

bvd,

serienummers batterij checken en de volgorde aanpassen in de gielz settings.

volgens mij maakt het niet zoveel uit , tenzij je iets met die volgorde doet. ik zelf bereken connector weerstand en stroomverlies (dus warmte), dan moet het goed staan.

[R.K]

ctrl-tab schreef op dinsdag 23 juni 2026 @ 13:42:
[...]

serienummers batterij checken en de volgorde aanpassen in de gielz settings.

Dat is het hem nou juist, in de Gielz settings zie ik geen info met serienummers, althans ik kan het niet vinden.

[ctrl-tab]

R.K schreef op dinsdag 23 juni 2026 @ 13:51:
[...]

Dat is het hem nou juist, in de Gielz settings zie ik geen info met serienummers, althans ik kan het niet vinden.

De serienummers in gielz staan ook verkeerd . dat is het hele issue (digitaal vs analoog). Er zijn sensoren waar ze in staan.

Sticker buitenkant van de batterij --> beginnen met tellen vanaf boven
In de settings van gielz kan je vervolgens de nummertjes aanpassen

[R.K]

ctrl-tab schreef op dinsdag 23 juni 2026 @ 13:53:
[...]

De serienummers in gielz staan ook verkeerd . dat is het hele issue (digitaal vs analoog). Er zijn sensoren waar ze in staan.

Sticker buitenkant van de batterij --> beginnen met tellen vanaf boven
In de settings van gielz kan je vervolgens de nummertjes aanpassen

Ik zal het wel niet snappen, maar dan weet ik nog steeds niet of batterij 1 in mijn stapel ook batterij 1 is in Gielz

[Kurios]

Weet iemand hoe ik met een automation de Gielz Operation Mode kan zetten:

Ik wil bijv als ik de auto oplaadt (P1>8000watt, of lader=aan) de Zendure even op standby zetten, zodat die niet gaat dischargen.

En als deze klaar is wil ik weer de operatie vervolgen (bijv Smart charge of Smart matching).

[Kurios]

RemmyB83 schreef op maandag 22 juni 2026 @ 14:28:
[...]

Door dat de intervallen niet synchroon lopen krijg je overcompensatie.
Stel je verbruik is 500W, gielz geeft 500W door. Vervolgens controleert gielz opnieuw, maar je slm geeft nog maals 500W, omdat die niet is geupdate. Dus gielz geeft nog eens 500W extra. Kortom 500W te veel. Vervolgens word je slm geupdate en krijgt gielz door er is 500 te veel is. Op deze manier krijg je allemaal correcties, zowel positief als negatief(laden en ontladen)

Ik heb dit ook. Allemaal bergjes in de nacht dat de automation continue zit op en af te schalen wat er wordt discharged (terwijl het stroomverbruik redelijk continue is).

[Gramser]

@Kurios Veel mensen regelen dit volgens mij met de evcc-integratie in Home Assistant. Had je daar al eens naar gekeken?

[wautah91]

R.K schreef op dinsdag 23 juni 2026 @ 14:18:
[...]

Ik zal het wel niet snappen, maar dan weet ik nog steeds niet of batterij 1 in mijn stapel ook batterij 1 is in Gielz

ik snap wat jij niet snapt. ;-)

Als je op het ip-adres van de zendure het properties report opvraagt (via http://ip-adres-zendure/properties/report) zie je in het element packData per batterij het serienummer ("sn"). In Gielz is dat de volgorde van je batterijen hoe het binnenkomt. Als je dan dat vergelijkt met de volgorde in je Zendure app of fysiek op de batterijen kun je de juiste volgorde instellen op het gielz config tabblad.

[wautah91]

Kurios schreef op dinsdag 23 juni 2026 @ 15:11:
Weet iemand hoe ik met een automation de Gielz Operation Mode kan zetten:

Ik wil bijv als ik de auto oplaadt (P1>8000watt, of lader=aan) de Zendure even op standby zetten, zodat die niet gaat dischargen.

En als deze klaar is wil ik weer de operatie vervolgen (bijv Smart charge of Smart matching).

Heel simpel. Gewoon de Modus Selecteren veranderen via een automation:

YAML:

choose:
  - conditions:
      - condition: time
        after: "09:00:00"
        before: "18:00:00"
    sequence:
      - action: input_select.select_option
        metadata: {}
        target:
          entity_id: input_select.zendure_2400_ac_modus_selecteren
        data:
          option: Dynamisch Handelen
default:
  - action: input_select.select_option
    metadata: {}
    target:
      entity_id: input_select.zendure_2400_ac_modus_selecteren
    data:
      option: Dynamisch NOM

[R.K]

wautah91 schreef op dinsdag 23 juni 2026 @ 15:46:
[...]

ik snap wat jij niet snapt. ;-)

Als je op het ip-adres van de zendure het properties report opvraagt (via http://ip-adres-zendure/properties/report) zie je in het element packData per batterij het serienummer ("sn"). In Gielz is dat de volgorde van je batterijen hoe het binnenkomt. Als je dan dat vergelijkt met de volgorde in je Zendure app of fysiek op de batterijen kun je de juiste volgorde instellen op het gielz config tabblad.

Thnx, nu snap ik het wel.

[ppaulv]

@wautah91 dit heb ik draaien ...

  automation:
    - alias: "17 uur alleen slim ontladen"
      description: ""
      trigger:
        - platform: time
          at: "17:00:00"
      condition: []
      action:
        - service: input_select.select_option
          target:
            entity_id: input_select.zendure_2400_ac_modus_selecteren
          data:
            option: "Alleen slim ontladen"
      mode: single

En in de automations (settings) ziet dat er zo uit (hetzelfd bestand bevat nog 2 zaakjes, zie beneden):

[ Voor 32% gewijzigd door ppaulv op 23-06-2026 16:35 ]

[Devke]

R.K schreef op dinsdag 23 juni 2026 @ 13:51:
[...]

Dat is het hem nou juist, in de Gielz settings zie ik geen info met serienummers, althans ik kan het niet vinden.

voor de volgorde is dit veld input.text.zendure_2400_ac_batterij_volgorde. De serienummers staan in sensor.zendure_2400_ac_batterij_serienummers

[ZuinigeRijder]

Kurios schreef op dinsdag 23 juni 2026 @ 15:11:
Weet iemand hoe ik met een automation de Gielz Operation Mode kan zetten:

Ik wil bijv als ik de auto oplaadt (P1>8000watt, of lader=aan) de Zendure even op standby zetten, zodat die niet gaat dischargen.

En als deze klaar is wil ik weer de operatie vervolgen (bijv Smart charge of Smart matching).

ZuinigeRijder in "Zendure producten in Home Assistant integreren deel 2"

[gast777]

Vandaag eens de AC groepen van de Zendures (SF2400AC) uitgezet voor het testen van de gridState property. Daarbij kon ik dan meteen controleren of de Zendures dan nog steeds via de offgrid stopcontacten van de zonnepanelen (en micro-omvormers) gaan opladen. Dat zou sinds een eerdere firmware versie namelijk al zijn gefixt volgens de release-notes toen (en nu zit ik op V2.0.0).

En dat gebeurde inderdaad (dat kon ik in de Zendure App zien die via bluetooth verbonden was).

Daarbij ook de wifi uitgezet, voor nog meer realistisch scenario. Mooi om te weten. Zal waarschijnlijk nooit gebruikt worden, maar je weet maar nooit

[ralphkeb]

raven22 schreef op maandag 22 juni 2026 @ 09:15:
[...]

Issue is al opgelost, ik had een stukje code gemaakt om de quooker pieken uit de p1 waarde te filteren, maar daar zat een foutje in.

Wil je de code delen, ik ervaar precies hetzelfde gedrag elk half uur door mijn Quooker?

[raven22]

ralphkeb schreef op woensdag 24 juni 2026 @ 06:34:
[...]

Wil je de code delen, ik ervaar precies hetzelfde gedrag elk half uur door mijn Quooker?

Zie hieronder, ik heb ook een automatisering die de quooker tussen 23 en 5.45 helemaal uitzet. Na 545 is hij dan max een kwartiertje bezig om weer op temp te komen, die periode wil ik wel meenemen uit de batterij omdat het geen pulse verwarmng is. De code staat in een bestand in de packages folder. Gebruik de gecorrigeerde p1 in gielz dashboard.

# 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) %}
          
          {# Bepaal of het nu tussen 05:45 en 06:00 uur is #}
          {% set n = now() %}
          {% set stabiel_opwarmen = (n.hour == 5 and n.minute >= 45) %}
          
          {% if stabiel_opwarmen %}
            {# Tussen 05:45 en 06:00 trekken we niks af: de batterij helpt vol mee #}
            {{ p1 | round(0) }}
          {% else %}
            {# Buiten dit kwartiertje trekken we de Quooker eraf tegen het jojoën #}
            {{ (p1 - quooker) | round(0) }}
          {% endif %}

[Pakhaas]

raven22 schreef op woensdag 24 juni 2026 @ 07:13:
[...]

Zie hieronder, ik heb ook een automatisering die de quooker tussen 23 en 5.45 helemaal uitzet. Na 545 is hij dan max een kwartiertje bezig om weer op temp te komen, die periode wil ik wel meenemen uit de batterij omdat het geen pulse verwarmng is. De code staat in een bestand in de packages folder. Gebruik de gecorrigeerde p1 in gielz dashboard.

# 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) %}
          
          {# Bepaal of het nu tussen 05:45 en 06:00 uur is #}
          {% set n = now() %}
          {% set stabiel_opwarmen = (n.hour == 5 and n.minute >= 45) %}
          
          {% if stabiel_opwarmen %}
            {# Tussen 05:45 en 06:00 trekken we niks af: de batterij helpt vol mee #}
            {{ p1 | round(0) }}
          {% else %}
            {# Buiten dit kwartiertje trekken we de Quooker eraf tegen het jojoën #}
            {{ (p1 - quooker) | round(0) }}
          {% endif %}

Ik zou er een drempel in maken van bijv 500w zodat hij standby verbruik wel uit de batterij haalt, maar de pulsen naar 2200w niet.

[jelleeelco]

Mimiix schreef op dinsdag 23 juni 2026 @ 11:13:
[...]

Tof! Zitten deze panelen ook op je accu aangesloten? Of is dit via 220v?

Nee, is een SolarEdge systeem dus AC zijdig op de Zendure(s).

[Pakhaas]

raven22 schreef op woensdag 24 juni 2026 @ 07:13:
[...]

Zie hieronder, ik heb ook een automatisering die de quooker tussen 23 en 5.45 helemaal uitzet. Na 545 is hij dan max een kwartiertje bezig om weer op temp te komen, die periode wil ik wel meenemen uit de batterij omdat het geen pulse verwarmng is. De code staat in een bestand in de packages folder. Gebruik de gecorrigeerde p1 in gielz dashboard.

# 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) %}
          
          {# Bepaal of het nu tussen 05:45 en 06:00 uur is #}
          {% set n = now() %}
          {% set stabiel_opwarmen = (n.hour == 5 and n.minute >= 45) %}
          
          {% if stabiel_opwarmen %}
            {# Tussen 05:45 en 06:00 trekken we niks af: de batterij helpt vol mee #}
            {{ p1 | round(0) }}
          {% else %}
            {# Buiten dit kwartiertje trekken we de Quooker eraf tegen het jojoën #}
            {{ (p1 - quooker) | round(0) }}
          {% endif %}

Werk jij met @gielz want daar kan je alleen het ip adres van de p1 meter invullen. Met een template sensor heb je geen ip adres met het vermogen minus de quooker.

[raven22]

Pakhaas schreef op woensdag 24 juni 2026 @ 11:02:
[...]

Werk jij met @gielz want daar kan je alleen het ip adres van de p1 meter invullen. Met een template sensor heb je geen ip adres met het vermogen minus de quooker.

ja gielz, ip is alleen voor homewizard p1 dacht ik
zie screenshot waar je de enntiteit invult

[YvonneVP]

raven22 schreef op woensdag 24 juni 2026 @ 11:12:
[...]

ja gielz, ip is alleen voor homewizard p1 dacht ik
zie screenshot waar je de enntiteit invult

[Afbeelding]

Er is ook een mogelijkheid om een afwijkende P1 sensor te gebruiken in plaats van de Homewizard. Dan moet je de sensor naam gebruiken in plaats van een ip adres. Dit zou dan in de code van de quooker ook aangepast moeten worden denk ik omdat je een andere P1 meter hebt ingevuld in de Gielz oplossing..

[Pakhaas]

raven22 schreef op woensdag 24 juni 2026 @ 11:12:
[...]

ja gielz, ip is alleen voor homewizard p1 dacht ik
zie screenshot waar je de enntiteit invult

[Afbeelding]

Ah en die ip van de p1 meter laat je ook staan?

[raven22]

Pakhaas schreef op woensdag 24 juni 2026 @ 11:46:
[...]

Ah en die ip van de p1 meter laat je ook staan?

nee, maar ik heb geen homewizard p1, ik gebruik die van zendure

edit: ik heb trouwens mbv Claude wat nieuwe code.
In de eerste werden verwarmingsmomenten naar gebruik van warmwater overdag ook gefilllterd inderdaad.

Claude kwam hiermee (moet het nog even testen):

# packages/quooker_p1_filter.yaml

input_datetime:
  quooker_laatste_puls:
    name: "Quooker Laatste Puls Einde"
    has_date: true
    has_time: true

template:
  - binary_sensor:
      - name: "Quooker Opwarming Actief"
        unique_id: quooker_opwarming_actief
        device_class: running
        state: >
          {% set quooker = states('sensor.sonoff_1_power') | float(0) %}
          {% set laatste = states('input_datetime.quooker_laatste_puls') %}
          {% if quooker > 500 and laatste not in ['unknown', 'unavailable'] %}
            {% set gap_min = (now() - as_datetime(laatste)).total_seconds() / 60 %}
            {{ gap_min < 15 }}
          {% else %}
            false
          {% endif %}
        delay_off:
          minutes: 20

  - 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) %}
          {% set n = now() %}
          {% set stabiel_opwarmen = (n.hour == 5 and n.minute >= 45) %}
          {% set opwarming = states('binary_sensor.quooker_opwarming_actief') == 'on' %}

          {% if stabiel_opwarmen or opwarming %}
            {{ p1 | round(0) }}
          {% else %}
            {{ (p1 - quooker) | round(0) }}
          {% endif %}

automation:
  - alias: "Quooker: Registreer Einde Puls"
    id: quooker_registreer_einde_puls
    trigger:
      - platform: numeric_state
        entity_id: sensor.sonoff_1_power
        below: 100
    condition:
      - condition: template
        value_template: >
          {{ trigger.from_state is not none and
             trigger.from_state.state | float(0) > 500 }}
    action:
      - service: input_datetime.set_datetime
        target:
          entity_id: input_datetime.quooker_laatste_puls
        data:
          datetime: "{{ now().strftime('%Y-%m-%d %H:%M:%S') }}"

[ Voor 83% gewijzigd door raven22 op 24-06-2026 12:21 ]

[Pakhaas]

raven22 schreef op woensdag 24 juni 2026 @ 12:17:
[...]

nee, maar ik heb geen homewizard p1, ik gebruik die van zendure

edit: ik heb trouwens mbv Claude wat nieuwe code.
In de eerste werden verwarmingsmomenten naar gebruik van warmwater overdag ook gefilllterd inderdaad.

Claude kwam hiermee (moet het nog even testen):

# packages/quooker_p1_filter.yaml

input_datetime:
  quooker_laatste_puls:
    name: "Quooker Laatste Puls Einde"
    has_date: true
    has_time: true

template:
  - binary_sensor:
      - name: "Quooker Opwarming Actief"
        unique_id: quooker_opwarming_actief
        device_class: running
        state: >
          {% set quooker = states('sensor.sonoff_1_power') | float(0) %}
          {% set laatste = states('input_datetime.quooker_laatste_puls') %}
          {% if quooker > 500 and laatste not in ['unknown', 'unavailable'] %}
            {% set gap_min = (now() - as_datetime(laatste)).total_seconds() / 60 %}
            {{ gap_min < 15 }}
          {% else %}
            false
          {% endif %}
        delay_off:
          minutes: 20

  - 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) %}
          {% set n = now() %}
          {% set stabiel_opwarmen = (n.hour == 5 and n.minute >= 45) %}
          {% set opwarming = states('binary_sensor.quooker_opwarming_actief') == 'on' %}

          {% if stabiel_opwarmen or opwarming %}
            {{ p1 | round(0) }}
          {% else %}
            {{ (p1 - quooker) | round(0) }}
          {% endif %}

automation:
  - alias: "Quooker: Registreer Einde Puls"
    id: quooker_registreer_einde_puls
    trigger:
      - platform: numeric_state
        entity_id: sensor.sonoff_1_power
        below: 100
    condition:
      - condition: template
        value_template: >
          {{ trigger.from_state is not none and
             trigger.from_state.state | float(0) > 500 }}
    action:
      - service: input_datetime.set_datetime
        target:
          entity_id: input_datetime.quooker_laatste_puls
        data:
          datetime: "{{ now().strftime('%Y-%m-%d %H:%M:%S') }}"

Wat bedoel je met verwarmingsmomenten? Wij gebruiken de Quooker ook voor warm water (hebben geen warmwater leiding meer naar de keuken) en hij doet dat gewoon met 2200w korte momenten, dus net als met kokend water.

[ppaulv]

Pakhaas schreef op woensdag 24 juni 2026 @ 13:21:
[...]

Wat bedoel je met verwarmingsmomenten? Wij gebruiken de Quooker ook voor warm water (hebben geen warmwater leiding meer naar de keuken) en hij doet dat gewoon met 2200w korte momenten, dus net als met kokend water.

Eh dat is logisch want jouw warme water wordt realtime 'gemaakt' door kokend water en koud water te mengen (dat kun je enigzins regelen met een draaiknop als de temp je niet bevalt).
Dus het enige warme water dat je in de Quooker hebt is kokend.

[Pakhaas]

ppaulv schreef op woensdag 24 juni 2026 @ 13:44:
[...]

Eh dat is logisch want jouw warme water wordt realtime 'gemaakt' door kokend water en koud water te mengen (dat kun je enigzins regelen met een draaiknop als de temp je niet bevalt).
Dus het enige warme water dat je in de Quooker hebt is kokend.

Precies, daarom vroeg ik mij af wat @raven22 bedoelt met verwarmingsmomenten na gebruik van warm water. Ik zie geen verschil tussen het pakken van kokend water en warm water. Beide keren slaat hij aan met 2200w voor korte of iets langere tijd.

[Pakhaas]

@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.

[ Voor 33% gewijzigd door Pakhaas op 24-06-2026 15:41 ]

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