Zendure producten in Home Assistant integreren deel 2

[Eboman]

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

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

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

[fv]

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

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

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

[pielie8520]

Allen,

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

Gielz integratie werkt perfect met 1 batterij,

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

[Mimiix]

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

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

Gielz integratie werkt perfect met 1 batterij,

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

[Afbeelding] [Afbeelding]

[Afbeelding]

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

[ppaulv]

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

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

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

[pielie8520]

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

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

Excuus vergeten te vermelden

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

[Mscroos]

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

Geen idee of het kan hoor.

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

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

[denneappel]

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

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

Wilde je misschien op een ander bericht reageren?

[Mscroos]

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


Wilde je misschien op een ander bericht reageren?

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

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

[denneappel]

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

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

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

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

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

[fv]

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

Ja, graag .

[ppaulv]

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

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

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

Helpers:

YAML:

input_number:

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

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

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

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

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

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

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

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

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

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

Een template:

YAML:

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

en de automation:

YAML:

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

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

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

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


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

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

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

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


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

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

    action:

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

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

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

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

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

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

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

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

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

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

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

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


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

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

YAML:

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

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

[klmtrf]

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

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

[Afbeelding]

[Afbeelding]

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

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

[koboy]

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

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

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

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

[databeestje]

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

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

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

Voor NOM prima maar voor 'minimum cost' niet.

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

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

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

[klmtrf]

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

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

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

[koboy]

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

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

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

[m-vw]

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

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

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

[Gramser]

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

[Mscroos]

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

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

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

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

[m-vw]

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

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

[ppaulv]

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

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

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

[Mistraller]

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

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

[Gramser]

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

[ppaulv]

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

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

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

[Gramser]

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

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

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

[mitsumark]

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

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

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

[Acidrain]

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

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

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

Helpers:

YAML:

input_number:

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

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

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

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

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

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

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

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

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

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

Een template:

YAML:

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

en de automation:

YAML:

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

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

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

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


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

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

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

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


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

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

    action:

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

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

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

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

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

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

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

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

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

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

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

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


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

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

YAML:

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

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

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

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

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

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

YAML:

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

[databeestje]

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

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

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

[ppaulv]

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

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

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

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

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

YAML:

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

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

[m-vw]

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

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

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

[Acidrain]

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

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

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

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

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

[Mistraller]

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

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

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

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

[ppaulv]

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

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

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

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

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

[Acidrain]

@ppaulv

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

[ppaulv]

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

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

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

[Acidrain]

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

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

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

[marinadus]

Vraagje over de Gielz integratie.

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

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

[m-vw]

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

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

[Acidrain]

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

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

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

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

[Gramser]

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

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

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

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

[Gramser]

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

[Mistraller]

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

Ja tuurlijk, ik kijk er al sinds het begin naar. Ookal heb ik nog vast contract.

[Gramser]

Dank @Mistraller! Ik heb het ook net aangezet (eigenlijk gek dat ik dat niet eerder heb gedaan, maar dacht dat je daarvoor al een dynamisch contract moest hébben), maar weet niet goed wat ik verder moet invullen bij minimal spread, lowest en highest price periods, en en export correction... little help ?

[Mistraller]

Gramser schreef op donderdag 17 september 2026 @ 12:32:
Dank @Mistraller! Ik heb het ook net aangezet (eigenlijk gek dat ik dat niet eerder heb gedaan, maar dacht dat je daarvoor al een dynamisch contract moest hébben), maar weet niet goed wat ik verder moet invullen bij minimal spread, lowest en highest price periods, en en export correction... little help ?

Dat zijn gewoon jouw persoonlijke wensen. Want de spread is het prijsverschil wat jij acceptabel vind om te gaan laden of ontladen, low/high; hoeveel periodes jij wilt aanmerken als laad/ontlaad periode (hangt dus ook van jouw ingestelde vermogens af).
Export correction weet ik niet, ik zit nog op een ouwe Gielz maar ik meen dat je daar energiebelasting correctie in kwijt kan en zo.

Maar goed, ik heb zo het vermoeden dat het op github allemaal prima uitgelegd zal staan

[RemmyB83]

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

Ik zou nog wel even goed nadenken/wachten voor dat je je vastecontract opzegd en overstapt naar dynamisch. Momenteel zijn de dynamischeprijzen ook niet echt laag, en vast bied je nu zekerheid, zeker nu periode er aankomt waarbij je meer gaat verbruiken. Persoonlijk zou ik wachten tot feb/maart.
Helaas loopt mijn vastecontract af per 1okt en ga dynamisch, dus heb verder niets tegen dynamisch. Maar denk er wel even overna in deze roerige tijd.

[Gramser]

Misschien wel goed advies, haast is een slechte raadgever. Ik zou het sowieso pas vanaf januari in laten gaan, maar ik móet uiteindelijk per 1 maart wat kiezen. Vast contract zou in mijn geval zo'n 60 per maand gaan kosten, dynamisch wordt ingeschat op 53,-.

Ik heb wel het idee dat ik met een dynamisch contract minder "moeilijk" hoef te doen tussen auto en batterij. Bij NoM bijten die elkaar als ik de auto op zon wil laden. Bij dynamisch contract kan ik dan makkelijker / is het logischer om beide op te laden als stroom goedkoop is, om maar wat te noemen.

@Mistraller ik vond het op Github niet heel duidelijk nog, maar je helpt me op weg. Dank daarvoor, ik ga me verder inlezen.

[ Voor 10% gewijzigd door Gramser op 17-09-2026 12:56 ]

[Pakhaas]

RemmyB83 schreef op donderdag 17 september 2026 @ 12:48:
[...]

Ik zou nog wel even goed nadenken/wachten voor dat je je vastecontract opzegd en overstapt naar dynamisch. Momenteel zijn de dynamischeprijzen ook niet echt laag, en vast bied je nu zekerheid, zeker nu periode er aankomt waarbij je meer gaat verbruiken. Persoonlijk zou ik wachten tot feb/maart.
Helaas loopt mijn vastecontract af per 1okt en ga dynamisch, dus heb verder niets tegen dynamisch. Maar denk er wel even overna in deze roerige tijd.

Het voordeel van hogere dynamische prijzen overdag is dat je ook meer krijgt voor teruglevering met PV

[RemmyB83]

Gramser schreef op donderdag 17 september 2026 @ 12:52:
Misschien wel goed advies, haast is een slechte raadgever. Ik zou het sowieso pas vanaf januari in laten gaan, maar ik móet uiteindelijk per 1 maart wat kiezen. Vast contract zou in mijn geval zo'n 60 per maand gaan kosten, dynamisch wordt ingeschat op 53,-.

Ik heb wel het idee dat ik met een dynamisch contract minder "moeilijk" hoef te doen tussen auto en batterij. Bij NoM bijten die elkaar als ik de auto op zon wil laden. Bij dynamisch contract kan ik dan makkelijker / is het logischer om beide op te laden als stroom goedkoop is, om maar wat te noemen.

@Mistraller ik vond het op Github niet heel duidelijk nog, maar je helpt me op weg. Dank daarvoor, ik ga me verder inlezen.

Komende maanden wordt het alleen maar donkerder dus vang het zonlicht wat je over hebt op, en dan kun je denk ik weinig verkeerd doen. Opladen op de goedkopere momenten kost je ook tijd en energie, en daar win je denk ik in de winterperiode ook niets mee. Vanaf maart gaan je zonnepanelen waarschijnlijk weer lekker opwekken, en misschien je dagelijkse verbruik grotendeels dekken. En dan zou ik pas overstappen.

[RemmyB83]

Pakhaas schreef op donderdag 17 september 2026 @ 12:59:
[...]

Het voordeel van hogere dynamische prijzen overdag is dat je ook meer krijgt voor teruglevering met PV

Klopt maar er zijn weinig mensen die in de periode van november t/m feb meer opwek hebben dan verbruik....

(Maar na mijn kleine stapje offtoppic, kunnen we deze discussie denk ik beter in een ander topic verder voeren🤗)

[Gramser]

Excuses, het begon met mijn vraag over de dashboardweergave maar we wijden te ver uit. Dank, stof tot nadenken!

[jm29]

Hallo,

Aanstaande dinsdag krijg ik mijn Zendure SolarFlow 4000 Mix Pro binnen. Ik wil deze gaan aansturen middels de integratie van Gielz. Ik heb daarnaast een Alfen Eve Single Pro-line die ik regelmatig gebruik met de ingebouwde solar charge functie. Nu ben ik bang dat de Alfen en de zendure elkaar tegen gaan werken, wanneer ik de solar charge functie van de Alfen gebruik.

Nu heb ik ernaar gekeken om de Alfen ook te integreren in HA, maar ik lees diverse berichten over EEPROM's die snel defect raken door de hoge schrijfactiviteit vanuit HA automatiseringen.

Ik zou graag horen wat jullie inzichten hierover zijn en hoe ik het beste de Alfen lader icm de Zendure kan aansturen. Ik zou hem zo willen aansturen dat de Alfen voorrang krijgt op de zonnestroom en dat de Zendure pas gaat laden wanneer de accu van de auto vol is.

[Mscroos]

jm29 schreef op donderdag 17 september 2026 @ 17:18:
Hallo,

Aanstaande dinsdag krijg ik mijn Zendure SolarFlow 4000 Mix Pro binnen. Ik wil deze gaan aansturen middels de integratie van Gielz. Ik heb daarnaast een Alfen Eve Single Pro-line die ik regelmatig gebruik met de ingebouwde solar charge functie. Nu ben ik bang dat de Alfen en de zendure elkaar tegen gaan werken, wanneer ik de solar charge functie van de Alfen gebruik.

Nu heb ik ernaar gekeken om de Alfen ook te integreren in HA, maar ik lees diverse berichten over EEPROM's die snel defect raken door de hoge schrijfactiviteit vanuit HA automatiseringen.

Ik zou graag horen wat jullie inzichten hierover zijn en hoe ik het beste de Alfen lader icm de Zendure kan aansturen. Ik zou hem zo willen aansturen dat de Alfen voorrang krijgt op de zonnestroom en dat de Zendure pas gaat laden wanneer de accu van de auto vol is.

Dit heb ik gebouwd met een P1 simulator. Ik laat de Alfen op overschot draaien en stuur de P1 waardes zelf aan. Deze simulatie zorgt ervoor dat de auto vanaf 1.4kWh het overschot opneemt. Tot 1.4 kWh laad de accu op. Werkt heel goed, voordeel is dat er niets speciaals naar de Alfen gaat wat afwijkt van normaal gebruik.

[dr.trimble]

Ik heb zopas de update gedaan naar de laatste versie van Gielz. Hierin heb ik mijn Zendure P1 ingesteld als afwijkende p1 meter. Ik krijg echter "NOM" niet op gang. De zendure blijft in standby staan. In het logboek komt er soms "⛔P1 aansturing vermogen offline voor 1 minuut, noodstop —". Ik heb ook mijn homewizard P1-meter geprobeerd en dat was net hetzelfde. Het verbruik is wel te zien van de P1 in de toepassing. Handmatig opladen gaat perfect.

UPDATE:

blijkbaar is "sensor.p1_aansturing_vermogen" niet beschikbaar

Weet iemand een oplossing voor dit probleem?

[ Voor 9% gewijzigd door dr.trimble op 17-09-2026 20:08 ]

[m-vw]

dr.trimble schreef op donderdag 17 september 2026 @ 18:25:
Ik heb zopas de update gedaan naar de laatste versie van Gielz. Hierin heb ik mijn Zendure P1 ingesteld als afwijkende p1 meter. Ik krijg echter "NOM" niet op gang. De zendure blijft in standby staan. In het logboek komt er soms "⛔P1 aansturing vermogen offline voor 1 minuut, noodstop —". Ik heb ook mijn homewizard P1-meter geprobeerd en dat was net hetzelfde. Het verbruik is wel te zien van de P1 in de toepassing. Handmatig opladen gaat perfect.

UPDATE:

blijkbaar is "sensor.p1_aansturing_vermogen" niet beschikbaar

Weet iemand een oplossing voor dit probleem?

Heb je de automatisering gestart?

[dr.trimble]

ja ,hoor. Want handmatig opladen, slim laden en ontladen werkt wel.

Nog een update:

Nu werkt het wel, had een ip-adres ingesteld van de zendure P1-meter in de configuratie en mijn Homewizard ingesteld als afwijkende P1 meter. Dit gaf uiteraard een conflict. Nu werkt alles terug normaal.

[ Voor 63% gewijzigd door dr.trimble op 17-09-2026 20:42 ]

[marinadus]

Gramser schreef op donderdag 17 september 2026 @ 11:52:
[...]

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

Ja maar ik zou niet weten hoe ik daarmee mn doel bereik?

[smeerbartje]

Hey allemaal, ik gebruik al een tijdje de Gielz integratie. In principe werkt deze prima, echter het feit dat het een template is, ik met bestanden moet gaan klooien en het een vrij zware belasting op de home assistant host geeft overwegg ik nu om naar de officiele integratie te gaan.

Nu heb ik eens gegeken naar de openingspost. Hier staat goed uitgelegd wat nu precies de verschillen zijn.

Ik wil eigenlijk alleen maar 0-op-de-meter. Dus zonnestroom over?? --> de batterij in. En bij piekverbruik moet de batterij gaan ontladen. Dat is het enige dat ik wil. Heeft Gielz nu voordelen voor mij? Of kan ik net zo goed de officiele integratie draaien? Deze kan ook gewoon lokaal werken zag ik.

Mis ik iets?

[Whiskey48]

smeerbartje schreef op zaterdag 19 september 2026 @ 09:50:
Hey allemaal, ik gebruik al een tijdje de Gielz integratie. In principe werkt deze prima, echter het feit dat het een template is, ik met bestanden moet gaan klooien en het een vrij zware belasting op de home assistant host geeft overwegg ik nu om naar de officiele integratie te gaan.

Nu heb ik eens gegeken naar de openingspost. Hier staat goed uitgelegd wat nu precies de verschillen zijn.

Ik wil eigenlijk alleen maar 0-op-de-meter. Dus zonnestroom over?? --> de batterij in. En bij piekverbruik moet de batterij gaan ontladen. Dat is het enige dat ik wil. Heeft Gielz nu voordelen voor mij? Of kan ik net zo goed de officiele integratie draaien? Deze kan ook gewoon lokaal werken zag ik.

Mis ik iets?

Of koop een goedkope N100 mini pc.mrt 12gb geheugen oid.

Weet de huidige prijs niet maar tot voor kort waren deze maar net boven de €100.

*Edit: laat maar, je betaalt nu zeker het 3 voudige.

[ Voor 3% gewijzigd door Whiskey48 op 19-09-2026 10:21 ]

[smeerbartje]

Whiskey48 schreef op zaterdag 19 september 2026 @ 10:17:
[...]

Of koop een goedkope N100 mini pc.mrt 12gb geheugen oid.

Weet de huidige prijs niet maar tot voor kort waren deze maar net boven de €100.

*Edit: laat maar, je betaalt nu zeker het 3 voudige.

Dank voor je advies, maar dat was niet de vraag he . Ik vroeg me af of de standaard integratie iets mist t.o.v. de Gielz integratie (puur voor 0-op-de-meter als doel).

[B-Force]

smeerbartje schreef op zaterdag 19 september 2026 @ 09:50:
Hey allemaal, ik gebruik al een tijdje de Gielz integratie. In principe werkt deze prima, echter het feit dat het een template is, ik met bestanden moet gaan klooien en het een vrij zware belasting op de home assistant host geeft overwegg ik nu om naar de officiele integratie te gaan.

Nu heb ik eens gegeken naar de openingspost. Hier staat goed uitgelegd wat nu precies de verschillen zijn.

Ik wil eigenlijk alleen maar 0-op-de-meter. Dus zonnestroom over?? --> de batterij in. En bij piekverbruik moet de batterij gaan ontladen. Dat is het enige dat ik wil. Heeft Gielz nu voordelen voor mij? Of kan ik net zo goed de officiele integratie draaien? Deze kan ook gewoon lokaal werken zag ik.

Mis ik iets?

Kijk eens naar de integratie van energienerds: Zendure Schedule. Heb ik nu ook een tijdje draaien en biedt genoeg opties voor wat je wil. Enige is dan wel dat je iedere dag een schema moet checken, maar dat moet met Gielz ook. (Of je draait hetzelfde als de dag ervoor en je kijkt er niet naar om).

[ Voor 3% gewijzigd door B-Force op 19-09-2026 10:51 ]

[Polvo176]

smeerbartje schreef op zaterdag 19 september 2026 @ 09:50:
Hey allemaal, ik gebruik al een tijdje de Gielz integratie. In principe werkt deze prima, echter het feit dat het een template is, ik met bestanden moet gaan klooien en het een vrij zware belasting op de home assistant host geeft overwegg ik nu om naar de officiele integratie te gaan.

Nu heb ik eens gegeken naar de openingspost. Hier staat goed uitgelegd wat nu precies de verschillen zijn.

Ik wil eigenlijk alleen maar 0-op-de-meter. Dus zonnestroom over?? --> de batterij in. En bij piekverbruik moet de batterij gaan ontladen. Dat is het enige dat ik wil. Heeft Gielz nu voordelen voor mij? Of kan ik net zo goed de officiele integratie draaien? Deze kan ook gewoon lokaal werken zag ik.

Mis ik iets?

Fireson heeft voor mij alleen maar voordelen, werkt zelfs beter dan de app omdat ik tussen verschillende modi kan schakelen wat in Hems niet kan en de vermogens verdeling is beter.
Met 5 batterijen van 3 soorten is Gielz voor mij niet eens bruikbaar.
Voor NOM alleen kunt een hele korte automatisering maken die de manager op slim opladen zet en je bent klaar.
Maar als je alleen NOM wilt draaien kun je de app ook gewoon gebruiken.

[Vaez]

B-Force schreef op zaterdag 19 september 2026 @ 10:50:
[...]

Kijk eens naar de integratie van energienerds: Zendure Schedule. Heb ik nu ook een tijdje draaien en biedt genoeg opties voor wat je wil. Enige is dan wel dat je iedere dag een schema moet checken, maar dat moet met Gielz ook. (Of je draait hetzelfde als de dag ervoor en je kijkt er niet naar om).

Je kan de Gielz redelijk eenvoudig compleet automatiseren naar je eigen wensen, dan hoef je er eigenlijk nooit naar te kijken en wijzigt de modus automatisch. Mijn wens was om me voor te bereiden op 2027 als het salderen weg is. Dus maximaal eigen zonne-energie gebruiken om op te laden, verder op basis van de goedkoopste prijs bij te laden en niet terug te leveren naar het net. En ook niet de accu te ontladen als de prijs op zijn goedkoopste moment zit. Daarmee kwam ik op de volgende scenario's:

• Zon over | accu komt vol uit zon | de zon vult de accu en dekt je huis | Nul op de meter
• Zon over | goedkoopste kwartier | accu komt niet vol | de zon vult de accu en je huis koopt het tekort in | Alleen slim opladen
• Geen zon | goedkoopste kwartier | accu komt niet vol | je huis koopt in en de accu blijft gespaard voor een duurder moment | Alleen slim opladen
• Geen zon | goedkoopste kwartier | dit kwartier laadt bij op net | de accu laadt uit het net en je huis koopt zelf in | Dynamisch NOM
• Geen zon | dure prijs | de accu levert aan je huis | Nul op de meter of Dynamisch NOM

Dit heb ik toen gebouwd in een automation die Gielz aanstuurt en de eerste paar weken gemonitord en verbeterd. Voorbeeldje hiervan: https://github.com/christianvaes/home-assistant/blob/main/automations/accu_dagplan_en_bijplan.yaml

[MazzHead]

smeerbartje schreef op zaterdag 19 september 2026 @ 09:50:
Hey allemaal, ik gebruik al een tijdje de Gielz integratie. In principe werkt deze prima, echter het feit dat het een template is, ik met bestanden moet gaan klooien en het een vrij zware belasting op de home assistant host geeft overwegg ik nu om naar de officiele integratie te gaan.

Nu heb ik eens gegeken naar de openingspost. Hier staat goed uitgelegd wat nu precies de verschillen zijn.

Ik wil eigenlijk alleen maar 0-op-de-meter. Dus zonnestroom over?? --> de batterij in. En bij piekverbruik moet de batterij gaan ontladen. Dat is het enige dat ik wil. Heeft Gielz nu voordelen voor mij? Of kan ik net zo goed de officiele integratie draaien? Deze kan ook gewoon lokaal werken zag ik.

Mis ik iets?

Als je geen nieuwe functionaliteit nodig hebt hoef je niet meer te klooien met bestanden om bij te blijven. Gewoon laten staan en gebruiken. Hetzelfde geldt voor firmware, het werkt toch?

[Holmes]

Ik heb inmiddels de SolarFlow 2400 AC besteld, maar kwam er achteraf pas achter dat er bij sommige gebruikers problemen zijn geweest met connectoren die te warm werden en zelfs zijn gaan smelten.

Nu heb ik nog een ESP32 liggen en een aantal kleine temperatuursensoren. Ik zat daarom te denken om zelf de temperatuur rond de connector(en) te gaan monitoren en die gegevens eventueel in Home Assistant te loggen.

Mijn idee is vooral om vroeg te kunnen zien of er tijdens laden/ontladen een connector duidelijk warmer begint te worden dan de omgeving of dan de andere aansluitpunten.

Is zoiets praktisch uitvoerbaar zonder de connector zelf open te maken? Dus bijvoorbeeld een kleine sensor zo dicht mogelijk tegen de buitenkant van het connectorhuis of de behuizing aan. Of zit de warmte bij zo’n slecht contact juist zo lokaal ín de connector dat je aan de buitenkant pas te laat iets merkt?

Ben vooral benieuwd of iemand dit al eens heeft geprobeerd, en zo ja: waar je de sensor het beste kunt plaatsen en welke temperatuurverschillen nog normaal zijn.

[B-Force]

Vaez schreef op zaterdag 19 september 2026 @ 11:09:
[...]

Je kan de Gielz redelijk eenvoudig compleet automatiseren naar je eigen wensen, dan hoef je er eigenlijk nooit naar te kijken en wijzigt de modus automatisch. Mijn wens was om me voor te bereiden op 2027 als het salderen weg is. Dus maximaal eigen zonne-energie gebruiken om op te laden, verder op basis van de goedkoopste prijs bij te laden en niet terug te leveren naar het net. En ook niet de accu te ontladen als de prijs op zijn goedkoopste moment zit. Daarmee kwam ik op de volgende scenario's:

• Zon over | accu komt vol uit zon | de zon vult de accu en dekt je huis | Nul op de meter
• Zon over | goedkoopste kwartier | accu komt niet vol | de zon vult de accu en je huis koopt het tekort in | Alleen slim opladen
• Geen zon | goedkoopste kwartier | accu komt niet vol | je huis koopt in en de accu blijft gespaard voor een duurder moment | Alleen slim opladen
• Geen zon | goedkoopste kwartier | dit kwartier laadt bij op net | de accu laadt uit het net en je huis koopt zelf in | Dynamisch NOM
• Geen zon | dure prijs | de accu levert aan je huis | Nul op de meter of Dynamisch NOM

Dit heb ik toen gebouwd in een automation die Gielz aanstuurt en de eerste paar weken gemonitord en verbeterd. Voorbeeldje hiervan: https://github.com/christianvaes/home-assistant/blob/main/automations/accu_dagplan_en_bijplan.yaml

Klopt, alleen als er een EV in het spel komt, wordt het wel complexer. Ben er nog niet over uit wat dan het handigst is, ook om de forecasted zonne opbrengst mee te nemen

[Ben(V)]

Holmes schreef op zaterdag 19 september 2026 @ 12:53:
Ik heb inmiddels de SolarFlow 2400 AC besteld, maar kwam er achteraf pas achter dat er bij sommige gebruikers problemen zijn geweest met connectoren die te warm werden en zelfs zijn gaan smelten.

Nu heb ik nog een ESP32 liggen en een aantal kleine temperatuursensoren. Ik zat daarom te denken om zelf de temperatuur rond de connector(en) te gaan monitoren en die gegevens eventueel in Home Assistant te loggen.

Mijn idee is vooral om vroeg te kunnen zien of er tijdens laden/ontladen een connector duidelijk warmer begint te worden dan de omgeving of dan de andere aansluitpunten.

Is zoiets praktisch uitvoerbaar zonder de connector zelf open te maken? Dus bijvoorbeeld een kleine sensor zo dicht mogelijk tegen de buitenkant van het connectorhuis of de behuizing aan. Of zit de warmte bij zo’n slecht contact juist zo lokaal ín de connector dat je aan de buitenkant pas te laat iets merkt?

Ben vooral benieuwd of iemand dit al eens heeft geprobeerd, en zo ja: waar je de sensor het beste kunt plaatsen en welke temperatuurverschillen nog normaal zijn.

Als de temperatuur van een connector op gaat lopen ben je te laat.
Tevens is het bijna onmogelijk daar een temperatuur opnemer te plaatsen.

Wat ik doe is door HA het vermogen te laten bereken dat in de connector ontwikkelt wordt.
Dat doe je door spanning van de batterij af te trekken van totale spanning en dat te vermenigvuldigen met de stroom.

Dit is de yaml code voor vier batterijen

      - name: Battery1
        unique_id: ff306e56-0c04-402f-af99-ced16db9a630
        device_class: power
        state_class: measurement 
        unit_of_measurement: "W"
        state: >
          {% set total_voltage =  states('sensor.solarflow_2400_ac_bat_volt') | float %}
          {% set pack_voltage = states('sensor.ab3000_08242_total_vol') | float %}
          {% set pack1_current = states('sensor.ab3000_08242_batcur') | float %}
          {% set pack2_current = states('sensor.ab3000_02822_batcur') | float %}
          {% set pack3_current = states('sensor.ab3000_02866_batcur') | float %}
          {{((total_voltage - pack_voltage) * (pack1_current + pack2_current + pack3_current)) | abs | round(1, default=0)}}

      - name: Battery2
        unique_id: 6a6a8159-442f-4515-b85a-a611896847e2
        device_class: power
        state_class: measurement 
        unit_of_measurement: "W"
        state: >
          {% set total_voltage =  states('sensor.solarflow_2400_ac_bat_volt') | float %}
          {% set pack_voltage = states('sensor.ab3000_02822_total_vol') | float %}
          {% set pack2_current = states('sensor.ab3000_02822_batcur') | float %}
          {% set pack3_current = states('sensor.ab3000_02866_batcur') | float %}
          {{((total_voltage - pack_voltage) * (pack2_current + pack3_current)) | abs | round(1, default=0)}}

      - name: Battery3
        unique_id: bfbacb9e-9204-4de0-a504-c5ca66b3f80a
        device_class: power
        state_class: measurement 
        unit_of_measurement: "W"
        state: >
          {% set total_voltage =  states('sensor.solarflow_2400_ac_bat_volt') | float %}
          {% set pack_voltage = states('sensor.ab3000_02866_total_vol') | float %}
          {% set pack3_current = states('sensor.ab3000_02866_batcur') | float %}
          {{((total_voltage - pack_voltage) * (pack3_current)) | abs | round(1, default=0)}}

      - name: Battery4
        unique_id: 033c931b-c800-47df-8dfc-340dba9e70af
        device_class: power
        state_class: measurement 
        unit_of_measurement: "W"
        state: >
          {% set total_voltage =  states('sensor.solarflow_2400_ac_bat_volt') | float %}
          {% set pack_voltage = states('sensor.ab3000_03030_total_vol') | float %}
          {% set pack4_current  = states('sensor.ab3000_03030_batcur') | float %}
          {{((total_voltage - pack_voltage) * pack4_current) | abs | round(1, default=0)}}

[Maarten60]

smeerbartje schreef op zaterdag 19 september 2026 @ 09:50:
Hey allemaal, ik gebruik al een tijdje de Gielz integratie. In principe werkt deze prima, echter het feit dat het een template is, ik met bestanden moet gaan klooien en het een vrij zware belasting op de home assistant host geeft overwegg ik nu om naar de officiele integratie te gaan.

Ik wil eigenlijk alleen maar 0-op-de-meter. Dus zonnestroom over?? --> de batterij in. En bij piekverbruik moet de batterij gaan ontladen. Dat is het enige dat ik wil. Heeft Gielz nu voordelen voor mij? Of kan ik net zo goed de officiele integratie draaien? Deze kan ook gewoon lokaal werken zag ik.

Mis ik iets?

Iedereen maakt natuurlijk zijn eigen afweging.

Ik gebruik zelf eigenlijk alleen nul-op-de-meter en heb een vast energiecontract. Toch blijf ik voorlopig bij Gielz.

Waarom? Vooral vanwege de vele verschillende laadmodi, de korte lijnen met de ontwikkelaar, die snel reageert en openstaat voor suggesties, en de mogelijkheden om er zelf dingen omheen te bouwen. Zo heb ik extra packages gemaakt voor het afhandelen van EV-laden en voor het aansturen van mijn fans. Ik heb daarnaast twee omvormers en vind de naadloze samenwerking met gast777 een duidelijke pre.

Het “klooien met bestanden” herken ik zelf niet zo. Ik gebruik het SDK-package, heb van de automatisering een package gemaakt (2 regels toevoegen) en ook het dashboard is feitelijk een package. Daardoor kan ik het geheel vrij eenvoudig in één keer installeren.

Ook de zware belasting herken ik niet. Ik heb HA eerst op een RPi5 gedraaid en inmiddels op een aparte NUC. In beide gevallen is het systeem na een restart snel weer beschikbaar en gewoon responsief.

Een ander voordeel vind ik dat ik zelf bepaal wanneer ik update. Dat doe ik misschien twee keer per jaar: als iets goed werkt, hoef ik niet iedere nieuwe versie direct te installeren.

Maar uiteindelijk zou mijn vraag vooral zijn: als je nu tevreden bent over Gielz en eigenlijk alleen NOM wilt, welk probleem probeer je dan met de overstap naar de officiële integratie op te lossen?

[Pakhaas]

Ik vraag mij het volgende af. Stel ik maak een automatisering die op basis van P1 vermogen het oplaadvermogen van de Zendures (via Gielz) steeds aanpast zodat er niet teveel vermogen door de hoofdzekering gaat. Dus een soort loadbalancing. Is dat schadelijk voor de Zendure? Voor mijn idee doet een NOM regeling bij @gielz hetzelfde. Dan zie je ook steeds het in het logboek het vermogen wijzigen. Voor ik iets sloop wil ik wel graag weten of dit kan.

[dr.trimble]

Hoi, ik heb de laatste Gielz draaien. Doordat binnenkort de zonopbrengst zal minderen wil ik al nagaan hoe ik het best mijn batterij kan in zetten. Doordat we in Belgie bij Engie superdaltarief hebben wil ik tijdens deze periode de accu opladen tot een bepaald percentage (afhankelijk van de zonopbrengst van de komende dag). Hoe kan ik dit het best regelen? Voor de overige periodes moet hij gewoon NOM draaien.

[Maarten60]

@Pakhaas
Volgens mij is het continu aanpassen van het laad-/ontlaadvermogen op basis van de P1-meting precies wat de NOM-regeling van Gielz al doet.

Ik begrijp alleen het deel over de hoofdzekering niet helemaal. Welk probleem met de hoofdzekering probeer je precies op te lossen?

[ZuinigeRijder]

dr.trimble schreef op zaterdag 19 september 2026 @ 19:37:
Hoi, ik heb de laatste Gielz draaien. Doordat binnenkort de zonopbrengst zal minderen wil ik al nagaan hoe ik het best mijn batterij kan in zetten. Doordat we in Belgie bij Engie superdaltarief hebben wil ik tijdens deze periode de accu opladen tot een bepaald percentage (afhankelijk van de zonopbrengst van de komende dag). Hoe kan ik dit het best regelen? Voor de overige periodes moet hij gewoon NOM draaien.

Je moet een automatisering maken, die het max laadpercentage zet (maar die kun je alleen zetten tussen 70 en 100%) en het min laadpercentage zet (maar die kun je alleen zetten tussen 5 en 50%). Maar je kunt ook een automatisering maken die de SOC% neemt en wanneer die een bepaald percentage bereikt heeft, de modus op Standby zet Met de automatisering heb jij alle vrijheid, tijdstip, dag van de week, etc.

[denneappel]

Maarten60 schreef op zaterdag 19 september 2026 @ 22:22:
@Pakhaas
Volgens mij is het continu aanpassen van het laad-/ontlaadvermogen op basis van de P1-meting precies wat de NOM-regeling van Gielz al doet.

Ik begrijp alleen het deel over de hoofdzekering niet helemaal. Welk probleem met de hoofdzekering probeer je precies op te lossen?

Ik denk dat @Pakhaas graag Xom "X op de meter" wil. Dat kan gewoon door een template P1 te maken die je P1 + of - X doet.

[raven22]

Had al een tijdje Gielz draaien met een SF800plus. Volgende week komen er echter 2x sf2400AC+ bij, dus maar eens rondgekeken naar andere integratie.
Heb nu omnibattery draaien, en ben wel impressed. Zeer eenvoudig te installeren en als het goed is kan het ook overweg met meerdere batterijen van verschillende omvormer en opslag capaciteiten. We gaan het binnenkort zien. Voorlopig is nom voor mij genoeg.

[koboy]

Pakhaas schreef op zaterdag 19 september 2026 @ 17:45:
Ik vraag mij het volgende af. Stel ik maak een automatisering die op basis van P1 vermogen het oplaadvermogen van de Zendures (via Gielz) steeds aanpast zodat er niet teveel vermogen door de hoofdzekering gaat. Dus een soort loadbalancing. Is dat schadelijk voor de Zendure? Voor mijn idee doet een NOM regeling bij @gielz hetzelfde. Dan zie je ook steeds het in het logboek het vermogen wijzigen. Voor ik iets sloop wil ik wel graag weten of dit kan.

Wat je eigenlijk wilt weten is of de op/ontlaad limiet direct naar flash wordt geschreven of dat deze net als het huidige vermogen in RAM wordt opgeslagen.....
Wellicht dat @gielz dit ergens heeft staan....

Als je hier geen duidelijkheid op krijgt zou ik het zekere voor het onzekere nemen en de modulatie in een "fake" P1 meter meenemen zodat je je aansluiting maximaal kan benutten.

[DaanVervacke]

Ik ben op zoek naar enkele Tweakers die hun Solarflow batterij eens willen sturen/testen via BLE, via een ESPHome Bluetooth Proxy.

https://github.com/DaanVervacke/solarflow-ble

[B-Force]

Ik zie her en der mensen met de Omnibattery integratie draaiend. Ik zit zelf nu op Zendure Schedule van Energienerds en dat bevalt prima: lekker overzichtelijk per uur een schema kiezen. Maar wel elke dag opnieuw iets bedenken.

Met Omnibattery wil ik de volgende stap gaan zetten, omdat dat qua logica een stapje verder is. Wellicht op termijn anar de integratie van Gielz, maar volgens mij werk Omnibattery nu eerst even eenvoudiger. Klopt dat? (qua instellen en qua gebruik)

Ik heb de hele support pagina van Omnibattery doorgeplozen, maar ik kan daar niet iets vinden over een visual die per uur (of kwartier) de uit te voeren strategie laat zien. Dit heb ik in eerste instantie denk ik wel nodig om handmatig te kunnen checken of dit (in mijn ogen) inderdaad de beste strategie zou zijn. Weet iemand of dit ook zichtbaar te maken is?

[Holmes]

Net de Zendure 2400AC binnen! 😄 Nog geen gesmolten connectoren 😉 (hehe). Meteen de Gielz-integratie in Home Assistant werkend gemaakt en ook NOM getest. Damn, dat werkt tot nu toe echt goed — supertevreden!

Hoe hebben anderen hier de beveiliging/failsafe in Home Assistant geregeld? Stel dat HA, de integratie of de verbinding ermee uitvalt: blijft de Zendure dan op de laatst ingestelde waarde staan, of kan hij weer terugvallen naar zijn maximale laad-/ontlaadvermogen?

Ik wil natuurlijk voorkomen dat hij bij een storing ineens weer vol vermogen gaat draaien. Hebben jullie daar nog een extra failsafe voor ingebouwd?

[eddyd]

Misschien kunnen jullie mij helpen (als relatief nieuw met HA en Zendure).

Ik heb Gielz geïnstalleerd in HA en alles draait met mijn 2400 AC+. Maar mijn NOM wil niet goed stabiliseren. Als mijn huis relatief stabiel 600 W verbruikt, dan ontlaadt de accu direct naar 1200W. Wat weer terug levering initieerd... en het gaat zo af en aan.

[Maarten60]

eddyd schreef op maandag 21 september 2026 @ 20:57:
Misschien kunnen jullie mij helpen (als relatief nieuw met HA en Zendure).

Ik heb Gielz geïnstalleerd in HA en alles draait met mijn 2400 AC+. Maar mijn NOM wil niet goed stabiliseren. Als mijn huis relatief stabiel 600 W verbruikt, dan ontlaadt de accu direct naar 1200W. Wat weer terug levering initieerd... en het gaat zo af en aan.

Welke meter heb je? 4.2 of 5.

[eddyd]

Maarten60 schreef op maandag 21 september 2026 @ 21:04:
[...]

Welke meter heb je? 4.2 of 5.

de 5.0

[m-vw]

Holmes schreef op maandag 21 september 2026 @ 20:52:
Net de Zendure 2400AC binnen! 😄 Nog geen gesmolten connectoren 😉 (hehe). Meteen de Gielz-integratie in Home Assistant werkend gemaakt en ook NOM getest. Damn, dat werkt tot nu toe echt goed — supertevreden!

Hoe hebben anderen hier de beveiliging/failsafe in Home Assistant geregeld? Stel dat HA, de integratie of de verbinding ermee uitvalt: blijft de Zendure dan op de laatst ingestelde waarde staan, of kan hij weer terugvallen naar zijn maximale laad-/ontlaadvermogen?

Ik wil natuurlijk voorkomen dat hij bij een storing ineens weer vol vermogen gaat draaien. Hebben jullie daar nog een extra failsafe voor ingebouwd?

[Afbeelding]

De laatst ingestelde waarde blijft actief.
Je moet de integratie zien als iets dat iedere vijf seconde de instelling voor je aanpast. Kijk maar eens in de app. Je kan bij de invoervelden gewoon zien wat er gebeurt.

Ik heb binnen mijn regeling een trigger met push melding voor als de proxy vastloopt en omdat ik HA als vm op een oude laptop draai en wat onverklaarbare uitvallen heb gehad loopt er een script dat controleert of de vm nog actief is. Maar dat is nog een test.

De echte Back-up is de Zendure app.

[ Voor 7% gewijzigd door m-vw op 22-09-2026 06:37 ]

[eddyd]

eddyd schreef op maandag 21 september 2026 @ 21:27:
[...]

de 5.0

En dit gaat ie doen:

[eddyd]

eddyd schreef op maandag 21 september 2026 @ 21:36:
[...]

En dit gaat ie doen: [Afbeelding]

Gevonden, jouw vraag triggerde mij, mijn dsmr integratie stond op 30 seconden, nu op 1 gezet

[manusjevanalles]

eddyd schreef op maandag 21 september 2026 @ 21:43:
[...]

Gevonden, jouw vraag triggerde mij, mijn dsmr integratie stond op 30 seconden, nu op 1 gezet

Volgens mij moet die zelfs op 0 staan zodat elk telegram direct doorkomt.

[eddyd]

manusjevanalles schreef op maandag 21 september 2026 @ 22:07:
[...]


Volgens mij moet die zelfs op 0 staan zodat elk telegram direct doorkomt.

Staat op 0 nu. Dankjewel.

[MP3-Junky]

Holmes schreef op maandag 21 september 2026 @ 20:52:
Net de Zendure 2400AC binnen! 😄 Nog geen gesmolten connectoren 😉 (hehe). Meteen de Gielz-integratie in Home Assistant werkend gemaakt en ook NOM getest. Damn, dat werkt tot nu toe echt goed — supertevreden!

Hoe hebben anderen hier de beveiliging/failsafe in Home Assistant geregeld? Stel dat HA, de integratie of de verbinding ermee uitvalt: blijft de Zendure dan op de laatst ingestelde waarde staan, of kan hij weer terugvallen naar zijn maximale laad-/ontlaadvermogen?

Ik wil natuurlijk voorkomen dat hij bij een storing ineens weer vol vermogen gaat draaien. Hebben jullie daar nog een extra failsafe voor ingebouwd?

[Afbeelding]

Bij storing krijgt de batterij geen nieuw signaal en blijft dus werken op het laatste signaal. Maar volgens mij zit er een failsafe in de batterij ingebouwd dat als hij 10min? geen nieuw signaal ontvangt automatisch naar standby gaat.

[m-vw]

MP3-Junky schreef op dinsdag 22 september 2026 @ 09:45:
[...]
Maar volgens mij zit er een failsafe in de batterij ingebouwd dat als hij 10min? geen nieuw signaal ontvangt automatisch naar standby gaat.

Dit klopt niet, ten minste niet als de batterij op handmatig staat. En de aansturing via HA werkt via hetzelfde principe. Heb al vaak genoeg nachten gehad dat HA gecrasht was en dan blijft de batterij gewoon in zijn laatste opdracht staan.

Ik zou het ook vreemd vinden, want waarom zou een batterij niet de hele dag met 200w mogen (ont)laden?

Hoe het via de Zendure aansturing werkt weet ik niet.

[ Voor 9% gewijzigd door m-vw op 22-09-2026 10:21 ]

[Maarten60]

@eddyd ik weet niet precies welke setting je bedoeld en op 0 hebt gezet. Ik kan die in de Gielz instellingen ook niet vinden.
Ik heb ook een ac2400+ met de standaard Gielz instelling, nom en neem ongeveer 1 kWh per dag af van net. Het log meldt iedere 5 s een opladen balanceren commando. Verder wel eens begrepen dat de zendure ook paar seconden tijd nodig heeft om de instelling te verwerken en dat 5 s heb optimale minimum, voor balanceer commando's, is.
Dit ter info.

[TWKterry]

Klopt het dat de standaard Zendure/Fireson integratie geen veld heeft voor het aantal cycles van de batterijen?
Ik heb een Solarflow 800pro in testopstelling samen met een HomeWizard die wel zo'n veld heeft. Aangezien de levensduur gebaseerd is op cycli zou dat wel een fijne sensor zijn.

[koboy]

Maarten60 schreef op dinsdag 22 september 2026 @ 11:18:
@eddyd ik weet niet precies welke setting je bedoeld en op 0 hebt gezet. Ik kan die in de Gielz instellingen ook niet vinden.
Ik heb ook een ac2400+ met de standaard Gielz instelling, nom en neem ongeveer 1 kWh per dag af van net. Het log meldt iedere 5 s een opladen balanceren commando. Verder wel eens begrepen dat de zendure ook paar seconden tijd nodig heeft om de instelling te verwerken en dat 5 s heb optimale minimum, voor balanceer commando's, is.
Dit ter info.

Als je een P1 kabeltje had gehad dan had je de instelling wel gehad. Default van de integratie hiervoor is elke 30s een update doorlaten naar de HA database wat prima is om de energiestromen in kaart te brengen maar voor aansturing natuurlijk veel te lang. Door deze naar 0s te zetten wordt elke update die de slimme meter via de P1 poort stuurt direct een nieuwe meetwaarde in de HA database waardoor deze ook opgepakt kan worden door de integraties die er van afhankelijk zijn.

[Ben(V)]

TWKterry schreef op dinsdag 22 september 2026 @ 11:20:
Klopt het dat de standaard Zendure/Fireson integratie geen veld heeft voor het aantal cycles van de batterijen?
Ik heb een Solarflow 800pro in testopstelling samen met een HomeWizard die wel zo'n veld heeft. Aangezien de levensduur gebaseerd is op cycli zou dat wel een fijne sensor zijn.

Nee dat klopt niet.
Het heet "switch count" en zit ook in de FireSon integratie.

En de belangrijkheid hiervan wordt echt overdreven..
Het klopt dat voor elk relais een aantal schakelingen gespecificeerd is, maar dat is alleen gedefinieer onder vollast, schakelen onder nullast veroorzaakt geen slijtage van een relais.

De Zendure batterijen schakelen niet om tussen laden en ontladen onder vollast, maar altijd onder nullast (er wordt eerst terug geregeld).
Het beperken van die schakelingen doet dus niets voor de levensduur van de batterijen.
Die wordt bepaalt door de hoeveelheid vermogen van lading/ontlading en met name bij welke temperatuur en niet door het aantal keren omschakelen.

[Polvo176]

Switch count is iets heel anders dan een cyclus teller en een cyclus count zit er niet bij in HA integratie.
Ik zou er ook niet druk over maken, je zult nooit veel meer dan 250 cycli maken in een jaar als je met zonne energie oplaad, dat zou neerkomen op 24 jaar bij 6000 cycli.
De batterij is dan allang afgeschreven.

[Ben(V)]

@TWKterry

Als je een cyclus count wilt weten kun je dat berekenen door de total charge kWh op te tellen en door de capaciteit van je batterij te delen.

Die gegevens zijn beiden beschikbaar in alle integraties.

[ Voor 4% gewijzigd door Ben(V) op 22-09-2026 13:53 ]

[Mistraller]

TWKterry schreef op dinsdag 22 september 2026 @ 11:20:
Klopt het dat de standaard Zendure/Fireson integratie geen veld heeft voor het aantal cycles van de batterijen?
Ik heb een Solarflow 800pro in testopstelling samen met een HomeWizard die wel zo'n veld heeft. Aangezien de levensduur gebaseerd is op cycli zou dat wel een fijne sensor zijn.

1 Cycle staat voor "helemaal leeg naar helemaal vol".

In mijn geval zie ik dat er bij een serie slappe dagen best wel wat verloop zit in het percentage (Gisteren weer eens een keer 100% aangetikt, maar toen ging ie ergens rond de 84% al trottlen, een teken dat de BMS ziet dat de accu bijna vol zit, en ja, in 1x naar de 100%)
Dat betekent dat een berekende Cycle ook extreem onbetrouwbaar zou zijn. Bovendien, wear is continu. Het is niet zo dat je tot 10.000 cycles niks merkt en daarna ineens kapotte accu's hebt. Is een geleidelijk, chemisch proces. Waarbij ook nog geldt dat snel laden en ontladen, en temperatuur ook best wat invloed hebben.
Een cijfer waar je dus volgens mij heel erg weinig aan hebt in de algemeenheid. En wil je het graag dan is het in HA, desnoods met de hulp van wat AI, zo gemaakt op jouw persoonlijke wensen.

[TWKterry]

Alle antwoorders hierboven hartelijk dank, ik ben weer veel wijzer.
Bij HW wordt een cyclus count gegeven en die is bij mij 292 na anderhalf jaar gebruik op NOM dus bijna 1 in de 2 dagen. Hoe ze die berekenen is verder onbekend en ik maak me ook geen zorgen zoals hierboven ook gezegd.
Maar als met aangeeft zoveel cycli zou ik verwachten dat daar een counter voor is. Ik denk niet dat ik de berekening zelf ga maken, lijkt me te afhankelijk van te veel factoren.
Nogmaals allen dank!

[Idr548]

Willen mensen met Omnibattery eventueel hun settings delen?
Ik heb de homewizard meter / solar meter beide op 1sec polling staan.
Maar ben wat zoek met de instellingen. ik merk redelijk wat import / export van het net.

Thx

[burniej]

B-Force schreef op maandag 21 september 2026 @ 20:01:
Ik zie her en der mensen met de Omnibattery integratie draaiend. Ik zit zelf nu op Zendure Schedule van Energienerds en dat bevalt prima: lekker overzichtelijk per uur een schema kiezen. Maar wel elke dag opnieuw iets bedenken.

Met Omnibattery wil ik de volgende stap gaan zetten, omdat dat qua logica een stapje verder is. Wellicht op termijn anar de integratie van Gielz, maar volgens mij werk Omnibattery nu eerst even eenvoudiger. Klopt dat? (qua instellen en qua gebruik)

Ik heb de hele support pagina van Omnibattery doorgeplozen, maar ik kan daar niet iets vinden over een visual die per uur (of kwartier) de uit te voeren strategie laat zien. Dit heb ik in eerste instantie denk ik wel nodig om handmatig te kunnen checken of dit (in mijn ogen) inderdaad de beste strategie zou zijn. Weet iemand of dit ook zichtbaar te maken is?

Bij omnibattery krijg je in het menu van HA een extra tabblad (dus niet in je dashboard overzicht).

Als je daar heen gaat en op de hoofdpagina naar beneden scrollt zie je de strategie voor de komende 24 uur en wat er daadwerkelijk sinds 12 uur vannacht is gebeurd.

Hierin staat de volgende 'status windows' (gearceerde velden):

Solar window

Solar charge

Grid charge

Battery discharge

Grid charge not needed


En de volgende parameters:

Solar production (kWh/15 min)

Consumption (lWh/15 min)

Total SOC (%)


En als je een laadvertraging hebt aangezet zie je dit als kleine klokjes elk kwartier bovenin de grafiek.

[raven22]

Idr548 schreef op dinsdag 22 september 2026 @ 23:25:
Willen mensen met Omnibattery eventueel hun settings delen?
Ik heb de homewizard meter / solar meter beide op 1sec polling staan.
Maar ben wat zoek met de instellingen. ik merk redelijk wat import / export van het net.

Thx

Ik heb gewoon de default settings en werkt prima volgens mij.
De homewizard p1 entiteit heb ik ingevuld, en ook de 3 fasen bescherming aangevinkt.
Meer niet.

[maartend]

raven22 schreef op woensdag 23 september 2026 @ 07:50:
[...]

Ik heb gewoon de default settings en werkt prima volgens mij.
De homewizard p1 entiteit heb ik ingevuld, en ook de 3 fasen bescherming aangevinkt.
Meer niet.

Ik heb dan nog ingesteld dat de batterijen enkel mogen laden van de panelen en niet mogen ontladen naar het net