Zendure producten in Home Assistant integreren deel 2

[Devke]

koboy schreef op maandag 9 maart 2026 @ 13:58:
[...]


Hmmmm, ik krijg een ideetje..... Uit de post van @alitrix begreep ik dat hij had geupdate bij een lage SOC. Jij ook?

Van de twee nu bekende geslaagde updates: @gielz en @devke, wat was de SOC tijdens updaten bij jullie?

Het zou kunnen dat het updaten misgaat bij lage(re) SOC. In elk geval blijf ik nog even van de knop af....

Ik heb geen update gedaan.

[RobTesla]

Ik heb ondertussen een HA opgezet om m'n Zendure SF 2400 aan te sturen met de @gielz HA-implementatie. Ik zit met een heel specifieke opstelling waarbij ik bepaalde aspecten nog wil kunnen aansturen vanuit eigen scripts. Met name: als ik 'Snel Opladen' kies beginnen de batterijen van de Zendure mooi te laden aan het wattage ingesteld in de parameter 'Maximum Oplaadvermogen'. Als ik dan -terwijl het laden bezig is in de modus 'Snel Opladen'- deze parameter wijzig naar iets anders, dan stuurt die de Zendure niet aan, hij blijft bij het ingestelde vermogen toen ik hem van 'Standby' naar 'Snel Opladen' switchte. Is dat normaal? Ik gebruik Gielz HA script, configuratie "Maart 2026 (20260214)". Ik kan wel ondertussen in de Zendure app het oplaadvermogen manueel aanpassen, dat lukt. Mijn SF zit niet in HEMS.

[Panzer_V]

RobTesla schreef op maandag 9 maart 2026 @ 14:47:
Ik heb ondertussen een HA opgezet om m'n Zendure SF 2400 aan te sturen met de @gielz HA-implementatie. Ik zit met een heel specifieke opstelling waarbij ik bepaalde aspecten nog wil kunnen aansturen vanuit eigen scripts. Met name: als ik 'Snel Opladen' kies beginnen de batterijen van de Zendure mooi te laden aan het wattage ingesteld in de parameter 'Maximum Oplaadvermogen'. Als ik dan -terwijl het laden bezig is in de modus 'Snel Opladen'- deze parameter wijzig naar iets anders, dan stuurt die de Zendure niet aan, hij blijft bij het ingestelde vermogen toen ik hem van 'Standby' naar 'Snel Opladen' switchte. Is dat normaal? Ik gebruik Gielz HA script, configuratie "Maart 2026 (20260214)". Ik kan wel ondertussen in de Zendure app het oplaadvermogen manueel aanpassen, dat lukt. Mijn SF zit niet in HEMS.

Heb je ook de automation toegevoegd en aangezet? Dat is namelijk het hart van de integratie.

[RobTesla]

Panzer_V schreef op maandag 9 maart 2026 @ 14:54:
[...]
Heb je ook de automation toegevoegd en aangezet? Dat is namelijk het hart van de integratie.

Uiteraard. Anders zou die niet beginnen laden als ik die van Standby naar Snel Opladen switch, hé. NOM werkt trouwens ook...

[alitrix]

koboy schreef op maandag 9 maart 2026 @ 13:58:
[...]


Hmmmm, ik krijg een ideetje..... Uit de post van @alitrix begreep ik dat hij had geupdate bij een lage SOC. Jij ook?

Van de twee nu bekende geslaagde updates: @gielz en nog iemand anders @devke, wat was de SOC tijdens updaten bij jullie?

Het zou kunnen dat het updaten misgaat bij lage(re) SOC. In elk geval blijf ik nog even van de knop af....

Ik heb een vermoeden dat er ergens een veiligheids-flag vastzat in de nieuwe versie
Hierdoor bleef die elke keer mijn handmatige input waardes terugzetten op 0.

Alleen HEMS mocht nog de waardes aanpassen (ik heb geen andere P1 apparatuur van Zendure zelf)
Dus heb ik ervoor gekozen om tussen X en Y tijd op te laden door handmatig een vaste waarde te geven
Toen de batterij ergens rond 15% was, heb ik HEMS uitgezet en weer handmatige inputs geprobeerd.

Dat leek te werken, alsof het 'kickstart' gaf, of de veiligheids-flag staat nu wel correct
Wanneer ik vanavond de accu leeg trek, zal ik snel achter komen of de minimale SOC% het probleem was of iets anders

Overigens heb ik ook een eigen automation geschreven (ooit deels overgenomen ergens in het begin van deze threads)
En verder aangepast met Claude naar mijn wens, bv, hij mag de accu niet dischargen om de auto op te laden.

Indien mensen interesse hebben, hier mijn automation

code:

alias: Balance Grid Power with Zendure Hyper 2000 (Dual Battery)
description: >-
  Adjusts two Zendure SolarFlow 2400 batteries to keep P1 meter active power
  near 0W. Distributes load by SoC — batteries with more room charge faster,
  batteries with more stored energy discharge more. Excludes Alfen EV charger
  from discharge calculations to avoid battery→grid→car energy losses. Uses a
  deadband + power buffer to prevent oscillation near zero.
triggers:
  - entity_id:
      - sensor.power_actual
    for:
      hours: 0
      minutes: 0
      seconds: 2
    trigger: state
conditions: []
actions:
  - variables:
      deadband: 50
      power_buffer: 20
      exclude_alfen_ev: true
      min_soc_discharge: 10
  - variables:
      p1_power: "{{ states('sensor.power_actual') | float(0) }}"
      alfen_power: >-
        {{ (states('sensor.alfen_active_power_total_socket_1') | float(0)) *
        1000 }}
      b1_output_now: "{{ states('sensor.solarflow_2400_ac_output_home_power') | float(0) }}"
      b1_input_now: "{{ states('sensor.solarflow_2400_ac_grid_input_power') | float(0) }}"
      b2_output_now: >-
        {{ states('sensor.solarflow_2400_ac_2_battery_output_power') | float(0)
        }}
      b2_input_now: >-
        {{ states('sensor.solarflow_2400_ac_2_battery_input_power') | float(0)
        }}
      b1_soc: "{{ states('sensor.solarflow_2400_ac_electric_level') | float(0) }}"
      b2_soc: "{{ states('sensor.solarflow_2400_ac_2_battery_soc') | float(0) }}"
  - choose:
      - alias: Importing from grid → discharge batteries
        conditions:
          - condition: template
            value_template: "{{ p1_power > deadband }}"
        sequence:
          - variables:
              p1_net: |-
                {% if exclude_alfen_ev %}
                  {{ [p1_power - alfen_power, 0] | max }}
                {% else %}
                  {{ p1_power }}
                {% endif %}
              freed_from_stopping_charge: "{{ b1_input_now + b2_input_now }}"
              total_discharge_needed: >-
                {{ [b1_output_now + b2_output_now + p1_net -
                freed_from_stopping_charge - power_buffer, 0] | max }}
              b1_can_discharge: "{{ b1_soc > min_soc_discharge }}"
              b2_can_discharge: "{{ b2_soc > min_soc_discharge }}"
              b1_effective_soc: "{{ b1_soc if b1_can_discharge else 0 }}"
              b2_effective_soc: "{{ b2_soc if b2_can_discharge else 0 }}"
              total_soc: "{{ [b1_effective_soc + b2_effective_soc, 1] | max }}"
              b1_share: "{{ b1_effective_soc / total_soc }}"
              b2_share: "{{ b2_effective_soc / total_soc }}"
              b1_output_raw: "{{ [total_discharge_needed * b1_share, 800] | min }}"
              b2_output_raw: "{{ [total_discharge_needed * b2_share, 800] | min }}"
              b1_overflow: "{{ [total_discharge_needed * b1_share - 800, 0] | max }}"
              b2_overflow: "{{ [total_discharge_needed * b2_share - 800, 0] | max }}"
              b1_output_final: >-
                {{ [[b1_output_raw + b2_overflow, 800] | min, 0] | max |
                round(0) | int }}
              b2_output_final: >-
                {{ [[b2_output_raw + b1_overflow, 800] | min, 0] | max |
                round(0) | int }}
          - choose:
              - alias: Only EV is importing → stop battery discharge
                conditions:
                  - condition: template
                    value_template: "{{ exclude_alfen_ev and p1_net <= 0 }}"
                sequence:
                  - alias: "B1: AC mode → output (idle)"
                    device_id: 23a5f7897298f4b7f370476ca718bfdd
                    domain: select
                    entity_id: dce7c8ec2f1f0539de4815dd359befcb
                    type: select_option
                    option: output
                  - alias: "B1: Set output to 0"
                    action: number.set_value
                    target:
                      entity_id: number.solarflow_2400_ac_output_limit
                    data:
                      value: "0"
                  - alias: "B1: Set input to 0"
                    action: number.set_value
                    target:
                      entity_id: number.solarflow_2400_ac_input_limit
                    data:
                      value: "0"
                  - alias: "B2: AC mode → output (idle)"
                    device_id: 23f6c98e8b92bb903ea06a9888b5c816
                    domain: select
                    entity_id: select.solarflow_2400_ac_2_ac_operation_mode
                    type: select_option
                    option: output
                  - alias: "B2: Set output to 0"
                    action: number.set_value
                    target:
                      entity_id: number.solarflow_2400_ac_2_output_limit
                    data:
                      value: "0"
                  - alias: "B2: Set input to 0"
                    action: number.set_value
                    target:
                      entity_id: number.solarflow_2400_ac_2_input_limit
                    data:
                      value: "0"
            default:
              - alias: "B1: AC mode → output"
                device_id: 23a5f7897298f4b7f370476ca718bfdd
                domain: select
                entity_id: dce7c8ec2f1f0539de4815dd359befcb
                type: select_option
                option: output
              - alias: "B1: Set output limit"
                action: number.set_value
                target:
                  entity_id: number.solarflow_2400_ac_output_limit
                data:
                  value: "{{ b1_output_final }}"
              - alias: "B1: Set input to 0"
                action: number.set_value
                target:
                  entity_id: number.solarflow_2400_ac_input_limit
                data:
                  value: "0"
              - alias: "B2: AC mode → output"
                device_id: 23f6c98e8b92bb903ea06a9888b5c816
                domain: select
                entity_id: select.solarflow_2400_ac_2_ac_operation_mode
                type: select_option
                option: output
              - alias: "B2: Set output limit"
                action: number.set_value
                target:
                  entity_id: number.solarflow_2400_ac_2_output_limit
                data:
                  value: "{{ b2_output_final }}"
              - alias: "B2: Set input to 0"
                action: number.set_value
                target:
                  entity_id: number.solarflow_2400_ac_2_input_limit
                data:
                  value: "0"
      - alias: Exporting to grid → charge batteries
        conditions:
          - condition: template
            value_template: "{{ p1_power < -deadband }}"
        sequence:
          - variables:
              surplus: "{{ [p1_power | abs - power_buffer, 0] | max }}"
              freed_from_stopping_discharge: "{{ b1_output_now + b2_output_now }}"
              total_charge_needed: >-
                {{ [b1_input_now + b2_input_now + surplus -
                freed_from_stopping_discharge, 0] | max }}
              b1_room: "{{ [100 - b1_soc, 0] | max }}"
              b2_room: "{{ [100 - b2_soc, 0] | max }}"
              total_room: "{{ [b1_room + b2_room, 1] | max }}"
              b1_share: "{{ b1_room / total_room }}"
              b2_share: "{{ b2_room / total_room }}"
              b1_input_raw: "{{ [total_charge_needed * b1_share, 2400] | min }}"
              b2_input_raw: "{{ [total_charge_needed * b2_share, 2400] | min }}"
              b1_overflow: "{{ [total_charge_needed * b1_share - 2400, 0] | max }}"
              b2_overflow: "{{ [total_charge_needed * b2_share - 2400, 0] | max }}"
              b1_input_final: >-
                {{ [[b1_input_raw + b2_overflow, 2400] | min, 0] | max |
                round(0) | int }}
              b2_input_final: >-
                {{ [[b2_input_raw + b1_overflow, 2400] | min, 0] | max |
                round(0) | int }}
          - alias: "B1: AC mode → input"
            device_id: 23a5f7897298f4b7f370476ca718bfdd
            domain: select
            entity_id: dce7c8ec2f1f0539de4815dd359befcb
            type: select_option
            option: input
          - alias: "B1: Set input limit"
            action: number.set_value
            target:
              entity_id: number.solarflow_2400_ac_input_limit
            data:
              value: "{{ b1_input_final }}"
          - alias: "B1: Set output to 0"
            action: number.set_value
            target:
              entity_id: number.solarflow_2400_ac_output_limit
            data:
              value: "0"
          - alias: "B2: AC mode → input"
            device_id: 23f6c98e8b92bb903ea06a9888b5c816
            domain: select
            entity_id: select.solarflow_2400_ac_2_ac_operation_mode
            type: select_option
            option: input
          - alias: "B2: Set input limit"
            action: number.set_value
            target:
              entity_id: number.solarflow_2400_ac_2_input_limit
            data:
              value: "{{ b2_input_final }}"
          - alias: "B2: Set output to 0"
            action: number.set_value
            target:
              entity_id: number.solarflow_2400_ac_2_output_limit
            data:
              value: "0"
mode: restart

[ Voor 95% gewijzigd door alitrix op 09-03-2026 15:34 ]

[gielz]

RobTesla schreef op maandag 9 maart 2026 @ 14:47:
Ik heb ondertussen een HA opgezet om m'n Zendure SF 2400 aan te sturen met de @gielz HA-implementatie. Ik zit met een heel specifieke opstelling waarbij ik bepaalde aspecten nog wil kunnen aansturen vanuit eigen scripts. Met name: als ik 'Snel Opladen' kies beginnen de batterijen van de Zendure mooi te laden aan het wattage ingesteld in de parameter 'Maximum Oplaadvermogen'. Als ik dan -terwijl het laden bezig is in de modus 'Snel Opladen'- deze parameter wijzig naar iets anders, dan stuurt die de Zendure niet aan, hij blijft bij het ingestelde vermogen toen ik hem van 'Standby' naar 'Snel Opladen' switchte. Is dat normaal? Ik gebruik Gielz HA script, configuratie "Maart 2026 (20260214)". Ik kan wel ondertussen in de Zendure app het oplaadvermogen manueel aanpassen, dat lukt. Mijn SF zit niet in HEMS.

Als ik het goed lees zoek je dit? In de april versie is dit opgelost;
https://github.com/Gielz1...elz1986-April-2026-Update

[RobTesla]

gielz schreef op maandag 9 maart 2026 @ 16:06:
[...]
Als ik het goed lees zoek je dit? In de april versie is dit opgelost

Dank! Moet ik enkel de automatisering upgraden of alles?

[gielz]

RobTesla schreef op maandag 9 maart 2026 @ 16:11:
[...]


Dank! Moet ik enkel de automatisering upgraden of alles?

Ik zou gewoon de package + automatisering + optioneel plug-n-play-dashboard doen. Het enigste wat nog gaat veranderen in de release is dat de configuratie versie aangepast zal gaan worden op releasedatum. Inmiddels hier al een nieuwe release aangemaakt voor Mei 2026.

Net ook even getest voor je met snel ontladen;


Dit zijn trouwens de releasenotes; https://github.com/Gielz1986/Zendure-HA-zenSDK/pull/30

[ Voor 6% gewijzigd door gielz op 09-03-2026 16:15 ]

[gast777]

RobTesla schreef op maandag 9 maart 2026 @ 14:47:
als ik 'Snel Opladen' kies beginnen de batterijen van de Zendure mooi te laden aan het wattage ingesteld in de parameter 'Maximum Oplaadvermogen'. Als ik dan -terwijl het laden bezig is in de modus 'Snel Opladen'- deze parameter wijzig naar iets anders, dan stuurt die de Zendure niet aan, hij blijft bij het ingestelde vermogen toen ik hem van 'Standby' naar 'Snel Opladen' switchte. Is dat normaal?

Als ik het goed begrijp verlaag je het 'Maximum Oplaadvermogen' nadat hij gestart is met 'Snel Opladen'. En dan verandert het vermogen niet naar het nieuwe maximum.

Ik heb dit zojuist even geprobeerd en hier verandert hij wel mee. Dat is met de April versie. Dus wellicht moet je die even installeren en opnieuw proberen.

[DrNickB]

RobTesla schreef op maandag 9 maart 2026 @ 14:47:
Ik heb ondertussen een HA opgezet om m'n Zendure SF 2400 aan te sturen met de @gielz HA-implementatie. Ik zit met een heel specifieke opstelling waarbij ik bepaalde aspecten nog wil kunnen aansturen vanuit eigen scripts. Met name: als ik 'Snel Opladen' kies beginnen de batterijen van de Zendure mooi te laden aan het wattage ingesteld in de parameter 'Maximum Oplaadvermogen'. Als ik dan -terwijl het laden bezig is in de modus 'Snel Opladen'- deze parameter wijzig naar iets anders, dan stuurt die de Zendure niet aan, hij blijft bij het ingestelde vermogen toen ik hem van 'Standby' naar 'Snel Opladen' switchte. Is dat normaal? Ik gebruik Gielz HA script, configuratie "Maart 2026 (20260214)". Ik kan wel ondertussen in de Zendure app het oplaadvermogen manueel aanpassen, dat lukt. Mijn SF zit niet in HEMS.

Waarom gebruik je dan niet de Handmatige optie? die luistert naar elke wijziging.

[YvonneVP]

koboy schreef op maandag 9 maart 2026 @ 13:58:
[...]


Hmmmm, ik krijg een ideetje..... Uit de post van @alitrix begreep ik dat hij had geupdate bij een lage SOC. Jij ook?

Van de twee nu bekende geslaagde updates: @gielz en nog iemand anders @devke, wat was de SOC tijdens updaten bij jullie?

Het zou kunnen dat het updaten misgaat bij lage(re) SOC. In elk geval blijf ik nog even van de knop af....

Ik heb niet specifiek op de SOC gelet. Die had, voor zover ik kan terug kijken, een normale werking en goed was. Vandaag heb ik wel 275 schakelingen staan. Morgen, dus vanaf 00:00 uur vannacht even kijken of dit dan ook minder schakelingen zijn.

[Pakhaas]

Ik heb weer een idee/feature request maar geen idee of het uitvoerbaar is.

Bij Dynamisch Handelen selecteer je aantal goedkope en dure uren/kwartieren. Zodra het goedkoop is gaat hij laden met het ingesteld vermogen en bij dure momenten visa versa.

Bijvoorbeeld vanochtend was het tussen 7:15 en 7:30 (ik werk met kwartierprijzen) 0,378. De omvormers stonden met 4400w terug te leveren. Maar om 8:00-8:15 was het 0.421. Ik heb toen dat eerdere kwartier het vermogen wat lager gedaan oom wat over te houden voor 8:00 uur.

Toen dacht ik, kan dat niet automatisch? We weten voor de komende 24u wat de uur/kwartierprijzen zijn en je hebt aangegeven hoeveel uren/kwartieren hij moet laden/ontladen. Het moet dan mogelijk zijn dat hij dat zo uitspreid dat er op het duurste moment het meeste kan ontladen.

[gast777]

koboy schreef op maandag 9 maart 2026 @ 13:58:
[...]


Hmmmm, ik krijg een ideetje..... Uit de post van @alitrix begreep ik dat hij had geupdate bij een lage SOC. Jij ook?

Van de twee nu bekende geslaagde updates: @gielz en nog iemand anders @devke, wat was de SOC tijdens updaten bij jullie?

Het zou kunnen dat het updaten misgaat bij lage(re) SOC. In elk geval blijf ik nog even van de knop af....

Afgelopen weekend heb ik ook de beide 2400AC's geupdate naar v1.0.19 en heb geen enkel probleem gezien. Dat is met HA Gielz en de Proxy.

Qua SoC was het toen op 12% (10% was ingesteld als minSoc).

[Refl]

Vraagje die misschien allang eerder is beantwoord:

In het overzicht "dynamisch vandaag" is het mogelijk de bar van het huidige tijdstip een andere kleur te geven (bijvoorbeeld blauw of wit)?
Nu staat in het overzicht wel het duurste en goedkoopste uur maar het zou fijn zijn als je met 1 oogopslag kan zien in welk uur/kwartier je momenteel zit.

Wellicht is dit zelf aan te passen maar wilde hem toch eerst hier vragen voor ik het in ChatGPT gooi

[Devke]

Pakhaas schreef op dinsdag 10 maart 2026 @ 08:27:
Ik heb weer een idee/feature request maar geen idee of het uitvoerbaar is.

Bij Dynamisch Handelen selecteer je aantal goedkope en dure uren/kwartieren. Zodra het goedkoop is gaat hij laden met het ingesteld vermogen en bij dure momenten visa versa.

Bijvoorbeeld vanochtend was het tussen 7:15 en 7:30 (ik werk met kwartierprijzen) 0,378. De omvormers stonden met 4400w terug te leveren. Maar om 8:00-8:15 was het 0.421. Ik heb toen dat eerdere kwartier het vermogen wat lager gedaan oom wat over te houden voor 8:00 uur.

Toen dacht ik, kan dat niet automatisch? We weten voor de komende 24u wat de uur/kwartierprijzen zijn en je hebt aangegeven hoeveel uren/kwartieren hij moet laden/ontladen. Het moet dan mogelijk zijn dat hij dat zo uitspreid dat er op het duurste moment het meeste kan ontladen.

Je kunt de duurste kwartieren (periode) instellen. Dan pakt hij vanzelf die kwartieren. Je kunt ook handmatig evt de voor jouw juiste kwartieren pakken. Dan heb je altijd de maximale winst. Wat ik wel kan bedenken is dat je batterij niet voldoende SoC meer heeft om je ingestelde kwartieren ook te kunnen bedienen.

[koboy]

Refl schreef op dinsdag 10 maart 2026 @ 09:00:
Vraagje die misschien allang eerder is beantwoord:

In het overzicht "dynamisch vandaag" is het mogelijk de bar van het huidige tijdstip een andere kleur te geven (bijvoorbeeld blauw of wit)?
Nu staat in het overzicht wel het duurste en goedkoopste uur maar het zou fijn zijn als je met 1 oogopslag kan zien in welk uur/kwartier je momenteel zit.

Wellicht is dit zelf aan te passen maar wilde hem toch eerst hier vragen voor ik het in ChatGPT gooi

In het dashboard zoals het vanaf de april versie van Gielz zit is dit al min of meer aanwezig. Niet met een aparte kleur, maar alle tijdsblokken die al geweest zijn hebben een grijzere kleur. Het eerste heldere blok is dus het huidige prijsblok.

[Refl]

koboy schreef op dinsdag 10 maart 2026 @ 09:22:
[...]


In het dashboard zoals het vanaf de april versie van Gielz zit is dit al min of meer aanwezig. Niet met een aparte kleur, maar alle tijdsblokken die al geweest zijn hebben een grijzere kleur. Het eerste heldere blok is dus het huidige prijsblok.

Ik zie echt geen verschil maar zal de code eens doorspitten of ik kan vinden waar dit geregeld wordt en dan pas ik het aan als het lukt

[Pakhaas]

Devke schreef op dinsdag 10 maart 2026 @ 09:09:
[...]

Je kunt de duurste kwartieren (periode) instellen. Dan pakt hij vanzelf die kwartieren. Je kunt ook handmatig evt de voor jouw juiste kwartieren pakken. Dan heb je altijd de maximale winst. Wat ik wel kan bedenken is dat je batterij niet voldoende SoC meer heeft om je ingestelde kwartieren ook te kunnen bedienen.

Dat begrijp ik, maar volgens mij begrijp jij niet helemaal wat ik bedoel.

Voorbeeld:
Stel je hebt ingesteld om 12 kwartieren (totaal 3 uren) de duurste momenten te pakken.
Je hebt voldoende in je batterij om dit te doen, maar niet voldoende om overal 4800w of 2400w bij 1omvormer te ontladen. Dan haal je die 12 kwartieren niet. Hij zal dan over al die 12 kwartieren met evenveel vermogen de stroom het net op duwen. Maar niet alle kwartieren zijn even duur.

Kwartier 1: 0,36
Kwartier 2: 0,38
Kwartier 3: 0,35
Kwartier 4: 0.42
Kwartier 5: 0.41
Etc

Je wil dan juist dat hij op kwartier 1 tm 3 wat rustiger gaat ontladen zodat die in kwartier 4 en kwartier 5 maximaal kan ontladen. Dus eigenlijk hoe hoger het bedrag, hoe hoger het vermogen.

Waar je kwartieren leest kan je ook uren lezen.

[Devke]

Pakhaas schreef op dinsdag 10 maart 2026 @ 09:49:
[...]

Dat begrijp ik, maar volgens mij begrijp jij niet helemaal wat ik bedoel.

Voorbeeld:
Stel je hebt ingesteld om 12 kwartieren (totaal 3 uren) de duurste momenten te pakken.
Je hebt voldoende in je batterij om dit te doen, maar niet voldoende om overal 4800w of 2400w bij 1omvormer te ontladen. Dan haal je die 12 kwartieren niet. Hij zal dan over al die 12 kwartieren met evenveel vermogen de stroom het net op duwen. Maar niet alle kwartieren zijn even duur.

Kwartier 1: 0,36
Kwartier 2: 0,38
Kwartier 3: 0,35
Kwartier 4: 0.42
Kwartier 5: 0.41
Etc

Je wil dan juist dat hij op kwartier 1 tm 3 wat rustiger gaat ontladen zodat die in kwartier 4 en kwartier 5 maximaal kan ontladen. Dus eigenlijk hoe hoger het bedrag, hoe hoger het vermogen.

Waar je kwartieren leest kan je ook uren lezen.

Ik pak hier de 3 duurste uren bijvoorbeeld. Als de batterij vol is dan dek ik ook bijna precies die 3 uur af met max vermogen ontladen. Klein beetje over (Tussen 10 en 15% SoC). Dan zou het voor mijn gevoel niet moeten uitmaken of je 3 x 4 duurste kwartieren pakt. Of 3 x de duurste uren toch?

[Pakhaas]

Devke schreef op dinsdag 10 maart 2026 @ 10:18:
[...]

Ik pak hier de 3 duurste uren bijvoorbeeld. Als de batterij vol is dan dek ik ook bijna precies die 3 uur af met max vermogen ontladen. Klein beetje over (Tussen 10 en 15% SoC). Dan zou het voor mijn gevoel niet moeten uitmaken of je 3 x 4 duurste kwartieren pakt. Of 3 x de duurste uren toch?

Het is allemaal centen marge natuurlijk, maar als iets technisch kan is het wel leuk natuurlijk (hobby zei je toch? )

3u kan prima op max ontladen, maar soms is het qua spread voordeliger om bijvoorbeeld 4u te laden. Dan is het handig dat je juist extra vermogen inzet op moment dat het het meeste opbrengt.

[Devke]

Pakhaas schreef op dinsdag 10 maart 2026 @ 10:30:
[...]

Het is allemaal centen marge natuurlijk, maar als iets technisch kan is het wel leuk natuurlijk (hobby zei je toch? )

3u kan prima op max ontladen, maar soms is het qua spread voordeliger om bijvoorbeeld 4u te laden. Dan is het handig dat je juist extra vermogen inzet op moment dat het het meeste opbrengt.

Ik denk dat dit effect meer speelt op kwartier basis dan. 4 duurste uren is sws niet haalbaar. Wat ik wel eens doe is doorschuiven naar de volgende ochtend als het tarief daar beter is dan het goedkoopste dure uur. Automatisch opbouwend vermogen zit niet in de integratie iig.

[Pakhaas]

Devke schreef op dinsdag 10 maart 2026 @ 10:37:
[...]
Automatisch opbouwend vermogen zit niet in de integratie iig.

Duh, daarom is het ook een idee/feature request

[Devke]

Pakhaas schreef op dinsdag 10 maart 2026 @ 10:53:
[...]

Duh, daarom is het ook een idee/feature request

, ik moest hem eerst ff begrijpen he ;-P

[gast777]

Pakhaas schreef op dinsdag 10 maart 2026 @ 10:53:
[...]
Duh, daarom is het ook een idee/feature request

Idee:

Als ik het goed begrijp heb je bijvoorbeeld nog maar genoeg kWh in de batterijen zitten om max 8 kwartieren volle bak te ontladen, maar je hebt ingesteld 12 duurste kwartieren ontladen.

Kun je dan geen automation maken die steeds checkt hoeveel kwartieren je met de huidige kWh (Indicatie Beschikbare Energie) op max vermogen zou kunnen laden/ontladen en dan automatisch het aantal "goedkoopste periodes" of "duurste periodes" aanpast naar dat aantal kwartieren?

[TomDZ1979]

Wanneer ik in de app mijn P1 meter en twee hyper 2000's toevoeg aan automodus. Kan ik dan nog steeds enkele parameters aanpassen vanuit de HA integratie (zie foto), die de app overrulen?
Ik zou graag de app blijven gebruiken, maar slaag er niet in om beide hyper 2000's, op twee verschillende groepen, elk aan 800W te laten ontladen voor een totaal van 1600W max samen. In de app kan ik het naar 1600W zetten, maar dan zal zodra de éne leeg is de andere plots meer dan 800W teruggeven, hetgeen niet het gewenste gedrag is. Als ik het op 800W zet in de app, lever ik ook max 800W terug (ofwel 400W per hyper, ofwel 800W op één hyper).
Nu vraag ik mij af of ik via de HA integratie met de juiste instellingen toch dat gedrag kan realiseren, maar wel nog steeds 'automodus' gebruikend in de app.

[Spike2100]

Gisteren heb ik de 2400AC op een eigen groep gezet (met de hulp van een elektricien). In de zendure app alles op maximum gezet en in home assistant "device has its own circuit or phase" aangezet. De omvormer doet wat hij moet doen. 2.4kWh laden en ontladen.

Echter is mijn nachtverbruik nu van 400Wh naar 600Wh gestegen. Is dit normaal? Ook zie ik nu P1 import en export data van telkens 25Wh. Na een 6tal uren was de batterij leeg, dit heeft mij 1200Wh extra gekost. De NOM curve is ook niet smooth.

Hiervoor stond de instelling op 800w/2400w in home assistant. Toen had ik een P1 import/export van 2Wh, en draaide mijn huis snachts netjes rond de 400Wh. De NOM curve was ook heel smooth.

[alitrix]

Sinds de update had ik daar ook last van, bleek dat de Off-grid op “Eco” stond
En dat pakt dan ongeveer 30-35W constant (terwijl er niks op aangesloten was)

Zie hier 2 screenshots waar je dit kunt uitzetten in de Zendure app of in HA

[Spike2100]

Ik heb de laatste update niet gedaan.
Offgrid staat uit. Deze nacht heb ik het probleem echter niet meer gehad. Mijn verbuik was 200 watt per uur meer 😳. En ééns de batterij uitviel, was dit verbruik weg.

Eergisteren rond 18H had ik wel een nieuwe batterij toegevoegd aan mijn stack. Deze stonden echter allemaal rond de 60% (de nieuwe ook). Misschien dat het systeem deze nog moest inregelen....

Ik ga het in het oog houden 🙂

[Bjorker]

alitrix schreef op woensdag 11 maart 2026 @ 05:50:
...
Zie hier 2 screenshots waar je dit kunt uitzetten in de Zendure app of in HA

...

Ik zie dat je connection mode op cloud staat.
Is het met HA aansturing niet sneller om dit op ZenSDK in te stellen?

[alitrix]

Ja, je hebt gelijk
Ik had het recent nog op SDK gezet maar door de update ontstonden gekke problemen (niks met plug-in zelf te maken)

Dus had ik hem op cloud gezet en vergeten terug te draaien
Nu de problemen verholpen zijn, ga ik terug naar SDK 👍

[Maarten60]

@gielz Is het een idee om van de automatisering ook een package te maken?
Er komen dan twee packages (voorbeeld)

code:

packages/zendure_ha_zensdk_gielz1986.yaml
packages/zendure_ha_zenaut_gielz1986.yaml

Als iemand dan meerdere automations heeft zijn die eenvoudiger uit elkaar te houden.

[Pakhaas]

Ik zoek een modus waarbij hij alleen van PV overschot gaat laden, maar dat hij wel gaat terugleveren op dure uren. Ik ben ze even bij langs geweest, maar bij Dynamisch NOM zou hij wel gaan laden van PV overschot, maar ook terugleveren aan het huis. Alleen slim opladen is het ook niet, want dan gaat hij op dure momenten niet terugleveren. Zie ik iets over het hoofd?

[mcurlym]

Dit zou mogelijk moeten zijn met de nieuwe release. Dan neem je Dynamisch Handelen of Dynamisch NOM (duur) en geef je bv. een blok van 3-4 uur aan als duur. Voor de andere uren neemm je dan bv. alleen slim opladen. Heb de release zelf nog niet kunnen installeren, maar dat was in ieder geval het idee om dat mogelijk te maken

[gielz]

Pakhaas schreef op woensdag 11 maart 2026 @ 15:30:
Ik zoek een modus waarbij hij alleen van PV overschot gaat laden, maar dat hij wel gaat terugleveren op dure uren. Ik ben ze even bij langs geweest, maar bij Dynamisch NOM zou hij wel gaan laden van PV overschot, maar ook terugleveren aan het huis. Alleen slim opladen is het ook niet, want dan gaat hij op dure momenten niet terugleveren. Zie ik iets over het hoofd?

Je zoekt iets exotisch
Ik zou Dynamisch NOM (Duur) pakken waarbij je dan alleen dure uren instelt maar geen goedkope en een minimale spread van 0%. Dan gaat hij alle zon oppakken en tijdens de dure uren alleen ontladen tot 0 (+marge)

[Pakhaas]

mcurlym schreef op woensdag 11 maart 2026 @ 16:08:
Dit zou mogelijk moeten zijn met de nieuwe release. Dan neem je Dynamisch Handelen of Dynamisch NOM (duur) en geef je bv. een blok van 3-4 uur aan als duur. Voor de andere uren neemm je dan bv. alleen slim opladen. Heb de release zelf nog niet kunnen installeren, maar dat was in ieder geval het idee om dat mogelijk te maken

Ja ik gebruik de nieuwste en ja dat had ik ook bedacht dat ik dan kan switchen, maar ik wil liever niet moeten switchen, dat vergeet je toch een keer en wil ik ook niet mee bezig zijn. Mooiste zou zijn een modus Alleen Slim Opladen + Terugleveren (duur)

[Pakhaas]

gielz schreef op woensdag 11 maart 2026 @ 16:11:
[...]


Je zoekt iets exotisch
Ik zou Dynamisch NOM (Duur) pakken waarbij je dan alleen dure uren instelt maar geen goedkope en een minimale spread van 0%. Dan gaat hij alle zon oppakken en tijdens de dure uren alleen ontladen tot 0 (+marge)

Ah kijk, dan gaat hij dus niet terugleveren als zijnde NOM? Aangezien die Dynamisch NOM duur heet

[ Voor 5% gewijzigd door Pakhaas op 11-03-2026 16:14 ]

[gielz]

Pakhaas schreef op woensdag 11 maart 2026 @ 16:12:
[...]

Ah kijk, dan gaat hij dus niet terugleveren als zijnde NOM?

Klopt tenzij in de duurste uren, dus het belangrijkste is minimale spread 0% en goedkope uren 0;

Dynamisch NOM (Duur)
Mocht er nog ruimte zijn om meer op te laden zal hij dit bij teruglevering gaan doen. Wanneer sensor.dynamisch_duurste_periode op JA staat zal hij NOM gaan ontladen en de rest van de tijd staat de batterij in standby.

[mcurlym]

Ah I see. In de April release zie ik: "Dynamisch Handelen + NOM modus toegevoegd" --> zou dat ook aangepast kunnen worden naar "Dynamisch Handelen + X" waarbij je X zelf kan kiezen. Je zou dan in principe ook A + X kunnen doen, waarbij A een Dynamische Modus is die gebruikt maakt van je uur blokken en X eender welke andere modus die dan runt in de niet aangeduide uren. Dan heb je maximale flexibiliteit met de uur blokken en een 2de modus.

[gielz]

mcurlym schreef op woensdag 11 maart 2026 @ 16:22:
Ah I see. In de April release zie ik: "Dynamisch Handelen + NOM modus toegevoegd" --> zou dat ook aangepast kunnen worden naar "Dynamisch Handelen + X" waarbij je X zelf kan kiezen. Je zou dan in principe ook A + X kunnen doen, waarbij A een Dynamische Modus is die gebruikt maakt van je uur blokken en X eender welke andere modus die dan runt in de niet aangeduide uren. Dan heb je maximale flexibiliteit met de uur blokken en een 2de modus.

De April release is definitief en zal niet meer aangepast worden tot aan de release. Maar ik snap wat je bedoelt een dual modus optie is gaaf maar geeft ook weer heel veel op te lossen problemen en testwerk. Daarom is 1 modus optie het makkelijkste voor de gebruiker en minder foutgevoelig.

Anders heb je straks een A + X + Y Modus

[Panzer_V]

@gielz , hoe werkt het straks met jouw integratie als ik een extra accu aan de Zendure toevoeg?

Ik dacht zelf aan onderstaand stappenplan:

1. stekker van de Zendure uit het stopcontact
2. Zendure uitzetten (knop 6 seconden ingedrukt houden)
3. nieuwe accupack onder de Zendure plaatsen
4. stekker in het stopcontact (en indien nodig knop indrukken om hem aan te zetten)

Mijn vragen zijn:
Moet ik in de Zendure app nog iets doen? Moet ik in jouw integratie nog iets doen (ik draai de april release)? Zie ik iets over het hoofd?

[geert1992]

Panzer_V schreef op woensdag 11 maart 2026 @ 16:57:
@gielz , hoe werkt het straks met jouw integratie als ik een extra accu aan de Zendure toevoeg?

Ik dacht zelf aan onderstaand stappenplan:

1. stekker van de Zendure uit het stopcontact
2. Zendure uitzetten (knop 6 seconden ingedrukt houden)
3. nieuwe accupack onder de Zendure plaatsen
4. stekker in het stopcontact (en indien nodig knop indrukken om hem aan te zetten)

Mijn vragen zijn:
Moet ik in de Zendure app nog iets doen? Moet ik in jouw integratie nog iets doen (ik draai de april release)? Zie ik iets over het hoofd?

Gielz op standby zetten, en zorg ervoor dat de accu daadwerkelijk in standby staat voor dat je de stekker eruit haalt.

Zorg dat de soc ergens rond de 50 procent ligt wanneer je het doet.

Soc verschil tussen accu's kan voor grote stromen zorgen.
En nieuw komen ze meestal tussen de 40-60procent soc.

[ Voor 9% gewijzigd door geert1992 op 11-03-2026 17:08 ]

[hemertje]

@Pakhaas @gielz

ik heb het idee dat jullie functionaliteit als deze bedoelen:

• Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO

Day Ahead Optimizer: ervaringen met Home Assistant-addon DAO

[Pakhaas]

mcurlym schreef op woensdag 11 maart 2026 @ 16:22:
Ah I see. In de April release zie ik: "Dynamisch Handelen + NOM modus toegevoegd" --> zou dat ook aangepast kunnen worden naar "Dynamisch Handelen + X" waarbij je X zelf kan kiezen. Je zou dan in principe ook A + X kunnen doen, waarbij A een Dynamische Modus is die gebruikt maakt van je uur blokken en X eender welke andere modus die dan runt in de niet aangeduide uren. Dan heb je maximale flexibiliteit met de uur blokken en een 2de modus.

Wat jij wil is eenvoudig met een automatisering te regelen. Ik heb bijvoorbeeld dat als onze EV lader aan gaat zonder load balancing, dan zet hij automatisch de modus op Gielz dashboard naar 'Alleen slim laden'. Hij onthoudt de vorige modus en zodra de EV weer uit gaat zet hij de oude modus terug. Dit kan je ook prima met tijd doen. Bijvoorbeeld tussen 8:00 en 16:00 modus x en tussen 16:00 en 8:00 modus y. Ik heb er ook een override knop dat als ik die indruk doet hij de modus niet naar Alleen slim laden. Kan bijvoorbeeld voorkomen dat het zonnig is en dat er naast auto laden voldoende zon van het dak komt, tarieven heel laag zijn en ik daarom toch extra stroom van het net wil halen voor in de batterijen.

Chatgpt kan dit het beste samenvatten

Wanneer switch.ev aan gaat:
overdag, zonder override:
zet hij de Zendure-modus op Alleen slim opladen
zet hij het max laadvermogen op 4000
als override aan staat of het is nacht:
laat hij de huidige modus met rust
als laden stopt:
zet hij de vorige modus terug

[ Voor 17% gewijzigd door Pakhaas op 11-03-2026 19:54 ]

[Spike2100]

Panzer_V schreef op woensdag 11 maart 2026 @ 16:57:
@gielz , hoe werkt het straks met jouw integratie als ik een extra accu aan de Zendure toevoeg?

Ik dacht zelf aan onderstaand stappenplan:

1. stekker van de Zendure uit het stopcontact
2. Zendure uitzetten (knop 6 seconden ingedrukt houden)
3. nieuwe accupack onder de Zendure plaatsen
4. stekker in het stopcontact (en indien nodig knop indrukken om hem aan te zetten)

Mijn vragen zijn:
Moet ik in de Zendure app nog iets doen? Moet ik in jouw integratie nog iets doen (ik draai de april release)? Zie ik iets over het hoofd?

Betreffende de 2400 AC:

Ik heb eergisteren ééntje toegevoegd op 60%. (mijn vorige 3 werden geleverd rond de 60)

- systeem uitgezet door de knop meer dan 6 seconden in te houden.
- groep uitgezet. (stekker uit kan ook)
- stack herbouwd
- sprong vanzelf terug aan toen ik de omvormer bovenaan plaatste.
- groep aan (of stekker inpluggen).

(Ik heb niets in de zendure app of home assistant gewijzigd.)

Dit duurde maar 5 minuten en alles was terug operationeel.

Good luck

[ Voor 9% gewijzigd door Spike2100 op 12-03-2026 04:51 ]

[sjnelle]

voor degenen die ook problemen hebben met het gelijk krijgen van de nordpool tarieven met zonneplan.
Ik heb deze oplossing gevonden.
In de Hacs integratie van Nordpool moet je de

code:

aio_price.py

file aanpassen
in de file voor

code:

return {
            "start": start_time,
            "end": end_time,
            "updated": updated,
            "currency": currency,
            "areas": area_data,
        }

voeg de volgende code toe

code:

# Aggregate quarterly values into hourly
        if data_type == self.HOURLY:
            for area_key, data_dict in area_data.items():
                vals = sorted(data_dict["values"], key=lambda v: v["start"])
                hourly_vals = []
                for i in range(0, len(vals), 4):
                    chunk = vals[i:i+4]
                    if len(chunk) == 4:
                        hour_start = chunk[0]["start"].replace(minute=0, second=0, microsecond=0)
                        hour_end = chunk[-1]["end"].replace(minute=0, second=0, microsecond=0)
                        avg_val = sum(v["value"] for v in chunk) / 4.0
                        hourly_vals.append(
                            {"start": hour_start, "end": hour_end, "value": avg_val}
                        )
                area_data[area_key]["values"] = hourly_vals

Link naar source van deze aanpassing https://github.com/custom...6#issuecomment-3359867914

en als Nordpool sensor heb ik nu

code:

sensor:
  - platform: nordpool
    region: "NL"
    currency: "EUR"
    VAT: False
    precision: 4
    low_price_cutoff: 0.9
    price_in_cents: false
    price_type: kWh
    additional_costs: >
      {{ (current_price * 0.21) + 0.1108 + 0.02 }}

Hiermee zijn mijn tarieven die in in het @gielz dashboard zie gelijk aan Zonneplan

[sjnelle]

Ik heb een tweede set bijgeplaatst.
Top werk @gielz en @gast777 met de laatste release en de proxy beide mooi werkend.
Proxy is zo ingesteld.

@gast777 heb een vraagje ik zie in de github staan:

Beide Zendures moeten hetzelfde aantal batterijen hebben of ongeveer dezelfde hoeveelheid kWh aan batterijopslag.

nu heb ik 1 2400 ac met 3 accu's en de andere is een 2400 ac met 2 accu's.
Gaat dit nog problemen geven of waar loop ik tegenaan.

[gast777]

sjnelle schreef op woensdag 11 maart 2026 @ 21:28:
Ik heb een tweede set bijgeplaatst.
Top werk @gielz en @gast777 met de laatste release en de proxy beide mooi werkend.
Proxy is zo ingesteld.

@gast777 heb een vraagje ik zie in de github staan:

[...]


nu heb ik 1 2400 ac met 3 accu's en de andere is een 2400 ac met 2 accu's.
Gaat dit nog problemen geven of waar loop ik tegenaan.

Op zich geen probleem, maar de proxy zal proberen de SoC percentages van beide Zendures bij elkaar in de buurt te houden. Met ongelijk aantal batterijen zal iets lastiger zijn de % ongeveer gelijk te houden. Maar ik voorzie niet echt een probleem.

Mocht het in Dual Mode (beide tegelijk laden/ontladen) teveel uit elkaar gaan lopen, dan kun je nog spelen met "let balancingFactor = 1.15" in het blokje "Vul hier de Zendure IP adressen in". Als je die iets hoger zet, zal het verschil in laadsnelheid iets groter worden, zodat de achterloper wat sneller gaat lopen en de andere wat langzamer. In Single Mode werking is het zowiezo geen probleem.

Laat maar even weten hoe het verloopt, ik ben wel benieuwd.

[sjnelle]

gast777 schreef op woensdag 11 maart 2026 @ 21:52:
[...]

Laat maar even weten hoe het verloopt, ik ben wel benieuwd.

Thx voor je snelle reactie ga ik zeker doen. Ben nog redelijk nieuw in de batterij materie. Nog wel hoop dingen te leren.

[YvonneVP]

Vanmorgen zag ik ineens dat mijn batterij te vroeg begonnen was met opladen. goedkoopste periode was 'nee' en duurste periode was 'ja'. Dit begon rond 8.30 uur, terwijl het laden pas had moeten beginnen om 10.00 uur. Het aantal relaisschakelingen blijft ook nog best hoog. vanaf vannacht 00.00 uur tot nu zijn het er (al) 183.

[gielz]

YvonneVP schreef op donderdag 12 maart 2026 @ 09:59:
Vanmorgen zag ik ineens dat mijn batterij te vroeg begonnen was met opladen. goedkoopste periode was 'nee' en duurste periode was 'ja'. Dit begon rond 8.30 uur, terwijl het laden pas had moeten beginnen om 10.00 uur. Het aantal relaisschakelingen blijft ook nog best hoog. vanaf vannacht 00.00 uur tot nu zijn het er (al) 183.
[Afbeelding]

Dynamisch NOM (Duur) laat op met de zon en met goedkoop is "JA". Wanneer duur op "JA" staat zal hij de energie gaan gebruiken en naar 0 op de P1 gaan bewegen. Fijn dus dat het werk zoals beschreven.
https://github.com/Gielz1...De-verschillende-modussen

Ik zou mij eerder zorgen om je relais schakelingen. Een normaal functionerende batterij ziet er ongeveer zo uit. Kun je jou grafiek eens posten?

[YvonneVP]

Natuurlijk kan ik dat.

[ Voor 20% gewijzigd door YvonneVP op 12-03-2026 10:23 ]

[geert1992]

Panzer_V schreef op woensdag 11 maart 2026 @ 16:57:
@gielz , hoe werkt het straks met jouw integratie als ik een extra accu aan de Zendure toevoeg?

Ik dacht zelf aan onderstaand stappenplan:

1. stekker van de Zendure uit het stopcontact
2. Zendure uitzetten (knop 6 seconden ingedrukt houden)
3. nieuwe accupack onder de Zendure plaatsen
4. stekker in het stopcontact (en indien nodig knop indrukken om hem aan te zetten)

Mijn vragen zijn:
Moet ik in de Zendure app nog iets doen? Moet ik in jouw integratie nog iets doen (ik draai de april release)? Zie ik iets over het hoofd?

Nog een toevoeging, ik zou stap 1 en stap 2 omdraaien.
Dat is gisteren getest.

[Acidrain]

geert1992 schreef op donderdag 12 maart 2026 @ 10:19:
[...]

Nog een toevoeging, ik zou stap 1 en stap 2 omdraaien.
Dat is gisteren getest.

Fout, 1 en 2 staan zoals het hoort. Zie mijn reactie in andere topic, 1 en 2 omdraaien resulteert in een error.

[DJ-Promo]

Misschien een stomme vraag maar wil een Zendure gaan gebruiken en natuurlijk zelf aansturen. Komt in de schuur dus in de winter zou die zich wel moeten verwarmen. Werken zulke dingen als verwarming en SOC calibratie etc. gewoon door wanneer ik de Zendure via HA aanstuur?

[gielz]

YvonneVP schreef op donderdag 12 maart 2026 @ 10:12:
Natuurlijk kan ik dat.
[Afbeelding][Afbeelding]

Alles onder groene lijn is prima daarboven heeft aandacht nodig of kan eenmalig zijn. Is je P1 meter wel een moderne die iedere seconden een update geeft want dat zou ik eerst even goed controleren.

Je ziet ook duidelijk de eerste 5 dagen weinig schakelingen en daarna word het chaos. Is er iets veranderd in je setup? Zou zeker even de logs in duiken en alle data bij elkaar klikken (vermogen batterij, p1 vermogen, modus (standby, opladen en ontladen). Los daarvan een periode bekijken van de logs van input_select.zendure_2400_ac_modus_selecteren. En kijk dan voornamelijk ook naar logs van uren en niet de hele de dag.

Zou hier zeker even goed induiken ondanks dat je 10 jaar garantie hebt.

[geert1992]

Acidrain schreef op donderdag 12 maart 2026 @ 10:33:
[...]

Fout, 1 en 2 staan zoals het hoort. Zie mijn reactie in andere topic, 1 en 2 omdraaien resulteert in een error.

De error gaat toch weg als je de stekker eruit trekt toch? En zo weet je in ieder geval dat hij standby staat.

[ Voor 8% gewijzigd door geert1992 op 12-03-2026 10:55 ]

[Acidrain]

geert1992 schreef op donderdag 12 maart 2026 @ 10:53:
[...]

De error gaat toch weg als je de stekker eruit trekt toch? En zo weet je in ieder geval dat hij standby staat.

Als je eerst de stekker trekt en dan de 6 seconden knop indrukt zoals in de handleiding omschreven is er helemaal geen error.
Handleiding volgen lijkt me dan de juiste?

[YvonneVP]

sjnelle schreef op woensdag 11 maart 2026 @ 21:24:
voor degenen die ook problemen hebben met het gelijk krijgen van de nordpool tarieven met zonneplan.
Ik heb deze oplossing gevonden.
In de Hacs integratie van Nordpool moet je de

code:

aio_price.py

file aanpassen
in de file voor

code:

return {
            "start": start_time,
            "end": end_time,
            "updated": updated,
            "currency": currency,
            "areas": area_data,
        }

voeg de volgende code toe

code:

# Aggregate quarterly values into hourly
        if data_type == self.HOURLY:
            for area_key, data_dict in area_data.items():
                vals = sorted(data_dict["values"], key=lambda v: v["start"])
                hourly_vals = []
                for i in range(0, len(vals), 4):
                    chunk = vals[i:i+4]
                    if len(chunk) == 4:
                        hour_start = chunk[0]["start"].replace(minute=0, second=0, microsecond=0)
                        hour_end = chunk[-1]["end"].replace(minute=0, second=0, microsecond=0)
                        avg_val = sum(v["value"] for v in chunk) / 4.0
                        hourly_vals.append(
                            {"start": hour_start, "end": hour_end, "value": avg_val}
                        )
                area_data[area_key]["values"] = hourly_vals

Link naar source van deze aanpassing https://github.com/custom...6#issuecomment-3359867914

en als Nordpool sensor heb ik nu

code:

sensor:
  - platform: nordpool
    region: "NL"
    currency: "EUR"
    VAT: False
    precision: 4
    low_price_cutoff: 0.9
    price_in_cents: false
    price_type: kWh
    additional_costs: >
      {{ (current_price * 0.21) + 0.1108 + 0.02 }}

Hiermee zijn mijn tarieven die in in het @gielz dashboard zie gelijk aan Zonneplan

De Nordpool sensor heb je verwijdert, en dan opnieuw aangemaakt en ingesteld? Of heb je die code ergens erin gezet via een editor?

[YvonneVP]

gielz schreef op donderdag 12 maart 2026 @ 10:45:
[...]


Alles onder groene lijn is prima daarboven heeft aandacht nodig of kan eenmalig zijn. Is je P1 meter wel een moderne die iedere seconden een update geeft want dat zou ik eerst even goed controleren.

Je ziet ook duidelijk de eerste 5 dagen weinig schakelingen en daarna word het chaos. Is er iets veranderd in je setup? Zou zeker even de logs in duiken en alle data bij elkaar klikken (vermogen batterij, p1 vermogen, modus (standby, opladen en ontladen). Los daarvan een periode bekijken van de logs van input_select.zendure_2400_ac_modus_selecteren. En kijk dan voornamelijk ook naar logs van uren en niet de hele de dag.

Zou hier zeker even goed induiken ondanks dat je 10 jaar garantie hebt.

Ik heb een HW P1 meter, en die recentelijk aangeschaft. Heb die nu, denk ik, een weekje op 2-3. Ik heb ook nog een Powerbaas P1 meter, en die van Zendure zelf. Ter leing en vermaak zou ik die ook eens in kunnen voegen, ipv de HW P1, en dan kijken wat er gebeurt.

[ Voor 8% gewijzigd door YvonneVP op 12-03-2026 11:14 ]

[gielz]

Acidrain schreef op donderdag 12 maart 2026 @ 11:03:
[...]

Als je eerst de stekker trekt en dan de 6 seconden knop indrukt zoals in de handleiding omschreven is er helemaal geen error.
Handleiding volgen lijkt me dan de juiste?

Zou zelf altijd eerst 6 seconden drukken en dan de stekker omdat je anders op hoog vermogen de stekker eruit kan trekken. Maar laten wij vooral hier niet verder op doorgaan in het Zendure HA topic. @geert1992 dus ook niet

Anders moet ik hem straks laten hernoemen naar Zendure producten hoe werkt de aan/uit knop deel 1

[wautah91]

YvonneVP schreef op donderdag 12 maart 2026 @ 11:09:
[...]

De Nordpool sensor heb je verwijdert, en dan opnieuw aangemaakt en ingesteld? Of heb je die code ergens erin gezet via een editor?

@sjnelle 2 maanden geleden had ik deze oplossing daarvoor al gepost. Hoef je geen code aan te passen ;-)

wautah91 schreef op vrijdag 16 januari 2026 @ 10:33:
Zonneplan All-in prijzen 2026 voor de Nordpool HACS integratie
Region NL
Currency EUR
Vink BTW uit
additional_costs template:

code:

{% set p = current_price | float(0) %}
      {% set opslag = 0.01653 %}
      {% set vat = 1.21 %}
      {% set energiebelasting = 0.1108 %}
      {{ ( ((p + opslag) * vat + energiebelasting) - p ) | float }}

[ Voor 20% gewijzigd door wautah91 op 12-03-2026 11:18 ]

[YvonneVP]

wautah91 schreef op donderdag 12 maart 2026 @ 11:17:
[...]

@sjnelle 2 maanden geleden had ik deze oplossing daarvoor al gepost. Hoef je geen code aan te passen ;-)


[...]

en 'Low Price Percentage' moet gewoon op 1 blijven staan, of naar 0.9 worden gezet?

[wautah91]

YvonneVP schreef op donderdag 12 maart 2026 @ 11:27:
[...]

en 'Low Price Percentage' moet gewoon op 1 blijven staan, of naar 0.9 worden gezet?

volgens mij doet dat niets met de prijzen zelf maar is dat meer een indicatie of de prijs goedkoper is dan de rest van de dag.


uit de help van HACS nordpool:

Low price percentage

no

Default: 1 Percentage of average price to set the low price attribute. IF hour_price < average * low_price_cutoff THEN low_price = True ELSE low_price = False

[sjnelle]

YvonneVP schreef op donderdag 12 maart 2026 @ 11:09:
[...]

De Nordpool sensor heb je verwijdert, en dan opnieuw aangemaakt en ingesteld? Of heb je die code ergens erin gezet via een editor?

Nee heb ik niet verwijderd. Mijn home assistant draait in docker. In de docker container heb je die file onder
custum_components/nordpool

Maar de oplossing van @wautah91 lijkt makkelijker wautah91 in "Zendure producten in Home Assistant integreren deel 2"

Heb ik zelf niet getest.

[YvonneVP]

sjnelle schreef op donderdag 12 maart 2026 @ 11:50:
[...]


Nee heb ik niet verwijderd. Mijn home assistant draait in docker. In de docker container heb je die file onder
custum_components/nordpool

Maar de oplossing van @wautah91 lijkt makkelijker wautah91 in "Zendure producten in Home Assistant integreren deel 2"

Heb ik zelf niet getest.

Ik heb de aio_price.py aangepast met de code
# Aggregate quarterly values into hourly
if data_type == self.HOURLY:
for area_key, data_dict in area_data.items():
vals = sorted(data_dict["values"], key=lambda v: v["start"])
hourly_vals = []
for i in range(0, len(vals), 4):
chunk = vals[i:i+4]
if len(chunk) == 4:
hour_start = chunk[0]["start"].replace(minute=0, second=0, microsecond=0)
hour_end = chunk[-1]["end"].replace(minute=0, second=0, microsecond=0)
avg_val = sum(v["value"] for v in chunk) / 4.0
hourly_vals.append(
{"start": hour_start, "end": hour_end, "value": avg_val}
)
area_data[area_key]["values"] = hourly_vals

En deze vóór onderstaande in die file geplaatst.
return {
"start": start_time,
"end": end_time,
"updated": updated,
"currency": currency,
"areas": area_data,
}

Daarna heb ik de Nordpool sensor verwijdert en opnieuw aangemaakt met de volgende waarden:
Region NL
Currency EUR
Vink BTW uit
additional_costs template:
code:
{% set p = current_price | float(0) %}
{% set opslag = 0.01653 %}
{% set vat = 1.21 %}
{% set energiebelasting = 0.1108 %}
{{ ( ((p + opslag) * vat + energiebelasting) - p ) | float }}

En in de grafiek toont ie nu ook netjes de prijzen van Zonneplan, met een heel kleine afwijking in de laatste decimaal omdat de default door Gielz waarschijnlijk op 3 achter de komma zit. En dat is ook helemaal dikke prima.

[koboy]

YvonneVP schreef op donderdag 12 maart 2026 @ 09:59:
Vanmorgen zag ik ineens dat mijn batterij te vroeg begonnen was met opladen. goedkoopste periode was 'nee' en duurste periode was 'ja'. Dit begon rond 8.30 uur, terwijl het laden pas had moeten beginnen om 10.00 uur. Het aantal relaisschakelingen blijft ook nog best hoog. vanaf vannacht 00.00 uur tot nu zijn het er (al) 183.
[Afbeelding]

Zou hem voor dit jaar op dynamisch handelen zetten. Dan heb je zeker geen laad-activiteit buiten de goedkope uren en gegarandeerd het hoogste financiële rendement.

Wbt de relais schakelingen: @gielz heeft na de eerste april-test release een tweede gedaan omdat er een fout in de relais grafiek zat. Heb je die wel geïnstalleerd?

[YvonneVP]

koboy schreef op donderdag 12 maart 2026 @ 12:34:
[...]


Zou hem voor dit jaar op dynamisch handelen zetten. Dan heb je zeker geen laad-activiteit buiten de goedkope uren en gegarandeerd het hoogste financiële rendement.

Wbt de relais schakelingen: @gielz heeft na de eerste april-test release een tweede gedaan omdat er een fout in de relais grafiek zat. Heb je die wel geïnstalleerd?

Bij mij gaat het niet om het handelen/rendement. Ik wil overdag goedkoop laden (en dan hopelijk zoveel mogelijk zonnestroom), en bij duur eigenlijk alleen de stroom uit de batterij halen. Ik heb mijn P1 meter dus 's avonds al met regelmaat 0w verbruik zien hebben, of 9w. Echte pieken zijn er alleen op het moment dat ik mijn koffiemachine of waterkoker even aan zet voor een bakkie. Maar dat is allemaal kortstondig. Het ontladen staat bij mij ingesteld op max 400w, en als ik thuis ben dan verbruik ik veelal minder dan 400w. Misschien het voordeel van alleen wonen. Op die manier haal ik het rendement er uiteindelijk ook uit omdat alle dure uren er nauwelijks verbruik is.

[ Voor 4% gewijzigd door YvonneVP op 12-03-2026 12:45 ]

[Pakhaas]

Ik wil ook alleen slim laden of NOMen en als dure uren op JA staat wil ik dat hij naar modus Dynamisch Handelen gaat, zodat dan alle stroom voor goede prijs naar net wordt gestuurd. Heb daar een automatisering voor geschreven. Zodra dure uren weer NEE wordt gaat die terug naar de modus waar die op stond.

Op die manier kan ik laden met PV en toch de stroom dumpen als de prijs hoog is.

Gielz heeft Rood (duur) en Groen (goedkoop) maar in feite is er ook nog Oranje. Dat zijn geen goedkope en geen dure momenten. Als je dan PV opwek hebt, wil je die niet opslaan (want daarna is het nog goedkoper). Die PV opwek wil je rechtstreeks het net op gooien. Nog even kijken hoe ik dat kan inbouwen in de automatisering.

[YvonneVP]

Pakhaas schreef op donderdag 12 maart 2026 @ 12:45:
Ik wil ook alleen slim laden of NOMen en als dure uren op JA staat wil ik dat hij naar modus Dynamisch Handelen gaat, zodat dan alle stroom voor goede prijs naar net wordt gestuurd. Heb daar een automatisering voor geschreven. Zodra dure uren weer NEE wordt gaat die terug naar de modus waar die op stond.

Op die manier kan ik laden met PV en toch de stroom dumpen als de prijs hoog is.

Gielz heeft Rood (duur) en Groen (goedkoop) maar in feite is er ook nog Oranje. Dat zijn geen goedkope en geen dure momenten. Als je dan PV opwek hebt, wil je die niet opslaan (want daarna is het nog goedkoper). Die PV opwek wil je rechtstreeks het net op gooien. Nog even kijken hoe ik dat kan inbouwen in de automatisering.

[Afbeelding]

Ik begrijp het. Alleen vraag ik me dus af wat dan eigenlijk meer rendement oplevert. Opladen met zonnestroom, en dan die stroom alle dure uren gebruiken? Of in een kortere duurdere periode alles aan het net leveren. Handelen wordt, voor zover ik heb begrepen, toch al lastiger als de saldering stopt. Ik ben dus nu aan het finetunen om mijn totale (betaalde) verbruik zo minimaal mogelijk te krijgen. In de winter ontkom je er niet aan om tegen het goedkoopste tarief op te laden, maar nu staat mijn batterij alleen zonnestroom te laden ondanks dat er toch wat wolken aan de lucht zijn. Ik lees ook met regelmaat mijn slimme meter uit om dus mijn verbruik in de gaten te houden, en dat is nu dus een heel stuk lager geworden sinds ik mijn batterij heb, dan dezelfde periode vorig jaar.

[Pakhaas]

YvonneVP schreef op donderdag 12 maart 2026 @ 12:50:
[...]

Ik begrijp het. Alleen vraag ik me dus af wat dan eigenlijk meer rendement oplevert. Opladen met zonnestroom, en dan die stroom alle dure uren gebruiken? Of in een kortere duurdere periode alles aan het net leveren. Handelen wordt, voor zover ik heb begrepen, toch al lastiger als de saldering stopt. Ik ben dus nu aan het finetunen om mijn totale (betaalde) verbruik zo minimaal mogelijk te krijgen. In de winter ontkom je er niet aan om tegen het goedkoopste tarief op te laden, maar nu staat mijn batterij alleen zonnestroom te laden ondanks dat er toch wat wolken aan de lucht zijn. Ik lees ook met regelmaat mijn slimme meter uit om dus mijn verbruik in de gaten te houden, en dat is nu dus een heel stuk lager geworden sinds ik mijn batterij heb, dan dezelfde periode vorig jaar.

Als salderen stopt wil je juist de zonnestroom opslaan als je daar maar bijv 10ct voor krijgt en later als de stroom 25ct is wil je die juist zoveel mogelijk dumpen. Als daarna bijv de stroom maar 20ct is kan je het beter voor 25ct verkopen en dan weer voor 20ct je huisverbruik dekken.

Of je nou stroom in de middag verkoopt of avonds heeft met wel of niet salderen niets te maken.

[sjnelle]

YvonneVP schreef op donderdag 12 maart 2026 @ 12:28:
[...]

En in de grafiek toont ie nu ook netjes de prijzen van Zonneplan, met een heel kleine afwijking in de laatste decimaal omdat de default door Gielz waarschijnlijk op 3 achter de komma zit. En dat is ook helemaal dikke prima.

Je kunt de decimalen in de gielz grafiek aanpassen.

[gielz]

Pakhaas schreef op donderdag 12 maart 2026 @ 12:55:
[...]

Als salderen stopt wil je juist de zonnestroom opslaan als je daar maar bijv 10ct voor krijgt en later als de stroom 25ct is wil je die juist zoveel mogelijk dumpen. Als daarna bijv de stroom maar 20ct is kan je het beter voor 25ct verkopen en dan weer voor 20ct je huisverbruik dekken.

Of je nou stroom in de middag verkoopt of avonds heeft met wel of niet salderen niets te maken.

Maar zodra het salderen stopt op 01-01-2027 loop je er tegen aan dat je met btw inkoopt en zonder btw gaat terugleveren. Mijn inziens is het in 2027 alleen nog maar Handelen + NOM. Waarbij je dus alle zonnestroom opslaat en gebruikt voor NOM en mocht je wat over hebben wat in de zomer elke dag wel is dump je een uurtje wat KWHs tegen een hoog inkooptarief om een paar stuivers te vangen.

[Pakhaas]

gielz schreef op donderdag 12 maart 2026 @ 12:57:
[...]


Maar zodra het salderen stopt op 01-01-2027 loop je er tegen aan dat je met btw inkoopt en zonder btw gaat terugleveren. Mijn inziens is het in 2027 alleen nog maar Handelen + NOM. Waarbij je dus alle zonnestroom opslaat en gebruikt voor NOM en mocht je wat over hebben wat in de zomer elke dag wel is dump je een uurtje wat KWHs tegen een hoog inkooptarief om een paar stuivers te vangen.

Als jij de batterij vult met PV opwek dan hoef je helemaal niets in te kopen. Je krijgt bij terugleveren idd alleen de kale prijs, maar dit kan nog altijd hoger zijn dan de kale prijs overdag en als je avond/nacht de batterij toch niet volledig leeg maakt kan je beter wat dumpen.

Mijn inziens is het in 2027 alleen nog maar Handelen + NOM.

Probleem met Dynamisch Handelen + NOM is dat hij geen PV overschot opslaat in de batterij.

[ Voor 9% gewijzigd door Pakhaas op 12-03-2026 13:02 ]

[gielz]

Pakhaas schreef op donderdag 12 maart 2026 @ 13:01:
Probleem met Dynamisch Handelen + NOM is dat hij geen PV overschot opslaat in de batterij.

Ja wel hoor. De modus Dynamisch Handelen + NOM;

- Opladen op de zon
- Ontladen als er geen zon is naar nul op de meter
- Vol vermogen laden tijdens goedkoop "JA"
- Vol vermogen ontladen tijdens duur "JA"

De optimale modus voor 2027. Lekker NOMen en dan even op bijvoorbeeld het duurste uurtje 2.4kwh over de schutting gooien tegen duur inkooptarief.

[Kaaf]

Hallo,ik kan niet soortgelijke klachten vinden, in dit topic, noch elders op andere fora.
Ik heb een SF 2400 AC+ met een Zendure P1 meter aangeschaft. Alles werkt in de Zendure App (HEMS enzo). Maar het lukt me niet om de cloud omgeving te koppelen aan Zendure-HA. Als ik de API sleutel invoer in Zendure HA krijg ik alleen de Zendure manager en niet de batterij en P1 meter. En de manager geeft ook helemaal geen data door.

Als ik in de app bij profiel-> "apparaat delen" tik krijg ook lege lijsten. Dus een tweede account lukt ook niet...
Herkennen jullie dit, of is dit alleen bij mij?

[YvonneVP]

sjnelle schreef op donderdag 12 maart 2026 @ 12:56:
[...]


Je kunt de decimalen in de gielz grafiek aanpassen.

Dat verschil is zo minimaal dat ik die moeite niet ga nemen. Verder heb ik de zonneplan stroomprijs die op dat moment geld als entiteit ook aan het dashboard toegevoegd. Met alleen Nordpool was het verschil namelijk groter, voor de grafiek zelf maakt het niets uit maar is het wel handig als ik de Zonneplan tarieven zie.

[Pakhaas]

gielz schreef op donderdag 12 maart 2026 @ 13:08:
[...]


Ja wel hoor. De modus Dynamisch Handelen + NOM;

- Opladen op de zon
- Ontladen als er geen zon is naar nul op de meter
- Vol vermogen laden tijdens goedkoop "JA"
- Vol vermogen ontladen tijdens duur "JA"

De optimale modus voor 2027. Lekker NOMen en dan even op bijvoorbeeld het duurste uurtje 2.4kwh over de schutting gooien tegen duur inkooptarief.

[Afbeelding]

Dan klopt de tekst toch niet?

⚠️ Let op: Alleen te gebruiken met Nordpool sensor. Vul als eerste in hoeveel uren je goedkoop zou willen laden per dag via input_number.dynamisch_goedkoopste_x_periode_morgen dit is bijvoorbeeld 3 uur. Vervolgens vul je de overige duurste uren in via input_number.dynamisch_duurste_x_periode_morgen dit is bijvoorbeeld 3 uur. Wanneer nu sensor.dynamisch_goedkoopste_periode op JA staat zal er opgeladen worden indien sensor.dynamisch_spread_indicatie hoger is dan input_number.dynamisch_minimale_spread. Wanneer sensor.dynamisch_goedkoopste_periode erg lang op JA staat zal hij pas weer gaan laden wanneer de batterij ontladen is tot 90%. Mocht er nog ruimte zijn om meer op te laden zal hij dit bij teruglevering gaan doen. Wanneer sensor.dynamisch_duurste_periode op JA staat zal hij NOM gaan ontladen en de rest van de tijd staat de batterij in standby.

Ook zie ik er ook niet op dat hij gaat laden met pv overschot.

[gielz]

Pakhaas schreef op donderdag 12 maart 2026 @ 13:15:
[...]

Dan klopt de tekst toch niet?


[...]


Ook zie ik er ook niet op dat hij gaat laden met pv overschot.

Wellicht kijk je bij de verkeerde uitleg, maar dit staat er bij de desbetreffende modus;
https://github.com/Gielz1...De-verschillende-modussen

[YvonneVP]

Pakhaas schreef op donderdag 12 maart 2026 @ 13:01:
[...]

Als jij de batterij vult met PV opwek dan hoef je helemaal niets in te kopen. Je krijgt bij terugleveren idd alleen de kale prijs, maar dit kan nog altijd hoger zijn dan de kale prijs overdag en als je avond/nacht de batterij toch niet volledig leeg maakt kan je beter wat dumpen.


[...]

Ik heb een capaciteit van 8,6 kWh. En in een periode als nu kan ik mijn batterij redelijk ver leegtrekken in de tijd dat het donker is, en de tarieven duurder zijn dan de goedkope periode. Vanaf zonsondergang tot zonsopgang draait mijn huis dus eigenlijk alleen op de batterij. In de winter zal ik iets meer verbruik hebben, maar dat heeft gewoon te maken met de kortere dagen. Wel moet ik er even bij vermelden dat ik een nachtmens ben, mijn tv dus ook tot laat aan staat, en als ik niet kan slapen dan gaat ie ook aan...want meestal val ik dan wel in slaap. Na de saldering zal ik mijn batterij dus in de goedkope uren hoger volpompen dan met 800w. Ontladen duurt gelukkig een stuk langer en kan ik dus over de hele donkere uren gebruiken. In de zomer, als er flink wat zon schijnt, zal ik dus overdag de zwaardere apparaten laten draaien zoals wasmachine, vaatwasser, droger, etc. zodat ik de zonnestroom zoveel mogelijk zelf gebruik en niet terug gooi naar het net.

[Pakhaas]

gielz schreef op donderdag 12 maart 2026 @ 13:18:
[...]


Wellicht kijk je bij de verkeerde uitleg, maar dit staat er bij de desbetreffende modus;
https://github.com/Gielz1...De-verschillende-modussen

[Afbeelding]

Ik keek in de OP van dit topic en hier https://github.com/Gielz1986/Zendure-HA-zenSDK

Zag die dynamisch handelen + NOM er niet bij staan. Maar mooi dat die er is!

[Acidrain]

Kaaf schreef op donderdag 12 maart 2026 @ 13:10:
Hallo,ik kan niet soortgelijke klachten vinden, in dit topic, noch elders op andere fora.
Ik heb een SF 2400 AC+ met een Zendure P1 meter aangeschaft. Alles werkt in de Zendure App (HEMS enzo). Maar het lukt me niet om de cloud omgeving te koppelen aan Zendure-HA. Als ik de API sleutel invoer in Zendure HA krijg ik alleen de Zendure manager en niet de batterij en P1 meter. En de manager geeft ook helemaal geen data door.

Als ik in de app bij profiel-> "apparaat delen" tik krijg ook lege lijsten. Dus een tweede account lukt ook niet...
Herkennen jullie dit, of is dit alleen bij mij?

Even voor de zekerheid, heb je in de Zendure app onder het kopje devices/apparatuur op je apparaat geklikt en dan de switch uitgezet voor HEMS?

[YvonneVP]

gielz schreef op donderdag 12 maart 2026 @ 13:08:
[...]


Ja wel hoor. De modus Dynamisch Handelen + NOM;

- Opladen op de zon
- Ontladen als er geen zon is naar nul op de meter
- Vol vermogen laden tijdens goedkoop "JA"
- Vol vermogen ontladen tijdens duur "JA"

De optimale modus voor 2027. Lekker NOMen en dan even op bijvoorbeeld het duurste uurtje 2.4kwh over de schutting gooien tegen duur inkooptarief.

[Afbeelding]

Komende nacht is de stroom weer goedkoop, vandaag heb ik veel zonnestroom en goedkope stroom opgeslagen, dus vanavond voor ik naar bed ga dump ik dan ook eens de stroom op de duurste uren zodat ik hem vannacht weer goedkoop op kan laden. As de stroom morgen pas overdag weer goedkoop zou zijn geweest dan had ik de stroom uit de batterij wel tot morgen gebruikt.

[Kaaf]

Even voor de zekerheid, heb je in de Zendure app onder het kopje devices/apparatuur op je apparaat geklikt en dan de switch uitgezet voor HEMS?

Met HEMS zou je toch op z'n minst de P1 moeten kunnen uitlezen? Maar als ik HEMS uit zet heb ik precies hetzelfde probleem. 5 entities op de Zendure manager die alleen geen data uitlezen. De Zendure-HA zou toch ook gewoon via de cloud moeten werken (met HEMS)?

[koboy]

gielz schreef op donderdag 12 maart 2026 @ 13:18:
[...]


Wellicht kijk je bij de verkeerde uitleg, maar dit staat er bij de desbetreffende modus;
https://github.com/Gielz1...De-verschillende-modussen

[Afbeelding]

Ik denk dat de dynamisch NOM stand de meeste functionaliteit al bevat, maar @Pakhaas net als ik straks wat meer standen moet gebruiken.
Ik zie dan het volgende voor me:
00.00 - xx.yy: alleen slim ontladen
Xx.yy - 23.59: dynamisch handelen NOM
waarbij xx.yy het tijdstip voorstelt dat de accu mag gaan laden nadat dus eerst een periode overschot is teruggeleverd (na de eerste oranje periode in het plaatje van @Pakhaas .

Hier zitten dan nog een paar fine-tune punten in, zoals het omschakel tijdstip xx.yy bepalen adhv verwachte opbrengst, en het omschakelen van terugleveren in de avond van aantal uur naar resterend SOC.

[Krisp]

Vandaag ook een batterij geïnstalleerd en draaiend gekregen. Dank voor al het harde werk tot nu toe.

Waar ik wel verrast over was is de vertraging. Op basis van seconde-metingen zie ik grofweg 10s vertraging tussen de meting (via MQTT) en de reactie van de batterij. Ogenschijnlijk zit het in de ramp rate van de batterij, oftewel de reactiesnelheid. Herkennen anderen dat? Zijn er manieren om die vertraging omlaag te brengen?

[gielz]

Gielz - April 2026 release live

Deze release draait vooral om verfijning. De automatisering is overgestapt van braaf wachten in de rij naar parallel werken. Daardoor reageert de aansturing sneller en kun je instellingen aanpassen terwijl alles gewoon door blijft draaien. De batterij is dus officieel van “even wachten tot ik klaar ben” naar “komt goed, ik regel het tegelijk wel”.

Daarnaast hebben we de batterij 1 seconde extra tijd gegeven om na te denken. Klinkt klein, maar dit voorkomt dat hij zenuwachtig gaat pendelen op de P1-meter. Minder golfbewegingen, rustiger gedrag en stiekem zelfs een iets betere NOM-score. Soms zit vooruitgang dus gewoon in een beetje geduld.

Ook het dashboard heeft een flinke opfrisbeurt gekregen. Het oude dashboard was eigenlijk vooral een enthousiaste testomgeving. Tijd voor iets beters: een nieuw, overzichtelijk dashboard met drie tabbladen waarin je alles vindt wat je over de batterij wilt weten. Minder scrollen, sneller inzicht, en alles blijft volledig aanpasbaar voor wie graag zelf knutselt of eigen dashboards bouwt.

Verder is er een nieuwe dynamische modus toegevoegd die automatisch schakelt tussen handelen en Nul-op-de-Meter.

Kortom: geen revolutie, maar wel een update die de batterij en het dashboard duidelijk soepeler, slimmer en prettiger in gebruik maakt. Precies wat nu noodzakelijk is aangezien het opwekseizoen is begonnen. 🌞🌞🌞

Volg de GitHub ⭐⭐⭐

1) Zet een Star bij de Github pagina (dan volg je hem wat altijd handig is en maakt de aansturing populairder)
2) Klik op Watch en kies waar je exact een melding van wilt krijgen. Bij Custom kun je specifiek alleen releases aanvinken.
3) Bij je profiel onder Notifications kun je aangeven of het via github zelf gaat of naar je mailbox

Release

https://github.com/Gielz1...DK/releases/tag/v20260312

Plug-N-Play Dashboard 2.0 – Alles in één

Overzichtelijk, compleet en verdeeld over 3 tabbladen, zodat je alles over je thuisbatterij in één oogopslag hebt. Gebruik ‘m zoals hij is, of haal er handige onderdelen uit voor je eigen dashboard. Zoals gebruikelijk ook weer 100% zelf aan te passen.

⚠️ Grote aanpassing ⚠️

Automatisering van queued naar parallel
De automatisering draait nu in parallel modus. Hierdoor is het mogelijk om tijdens een lopende modus ook meteen instellingen aan te passen of andere wijzigingen te doen wat de sturing snelheid ten goede komt.
https://www.home-assistant.io/docs/automation/modes/

NOM interval
Uit veel NOM uren data is gebleken dat de batterij regelmatig iets meer dan 4 seconden nodig heeft waardoor je een golfbeweging kreeg op de P1 die minuten aanhield. Hierdoor is de interval nu op 5 seconden gezet. Met deze nieuwe interval kwam er gek genoeg een betere NOM uit.

Dit wil niet zeggen dat wanneer je de waterkoker aanzet de batterij pas na 5 seconden reageert. Het is een 5 seconden interval waardoor de batterij ook binnen 1 seconde kan reageren.

Mocht dit niet wenselijk zijn dan kan dit aangepast worden in de automatisering door /5 naar /4 te zetten:

code:

alias: Zendure zenSDK (Gielz)
description: Configuratie Versie April 2026 (20260216)
triggers:
  - seconds: /5
    id: aansturing_trigger
    trigger: time_pattern

Nieuwe modus optie

Dynamisch Handelen + NOM modus toegevoegd
Deze modus volgt het patroon goedkoopste en duurste uren die ingesteld zijn. Daarbuiten is het altijd Nul op de Meter.

Extra sensoren toegevoegd

⚠️ Zendure-HA-Zensdk Github Releasecheck ⚠️
Er wordt nu verbinding gemaakt met de API van GitHub waardoor deze sensor aangeeft of je up-to-date bent.

Totale Capaciteit
De batterijen worden nu herkend en berekend. Dit betreft de batterij in de omvormers, AB3000X, AB3000L en AB2000X.

Dynamisch Ontladen Loopt en Dynamisch Laden Loopt
Er wordt nu exact bijgehouden wanneer er een dynamisch ontlaad of laadcyclus loopt.

Omvormer Max. Oplaadvermogen en Omvormer Max. Ontlaadvermogen
Vanaf nu kun je zien wat er daadwerkelijk op de omvormer (API) is ingesteld. Dit wordt ook gebruikt om te controleren of deze afwijkend is ten opzichte van je eigen ingestelde maximum oplaad- en ontlaadvermogen.

Help Tonen Op Dashboard
Ten behoeve van het plug-n-play dashboard waardoor het nu mogelijk is om bij de meeste onderdelen direct een helptekst te tonen.

Dynamisch Tonen Op Dashboard
Ten behoeve van het plug-n-play dashboard waardoor je het dynamische gedeelte kunt uitzetten als je hier geen gebruik van wilt maken.

Wijzigingen in bestaande onderdelen

sensor.zendure_2400_ac_modus en sensor.zendure_2400_ac_vermogen_aansturing
Aangepast om de aansturing te kunnen gebruiken met direct aangesloten zonnepanelen op de daarvoor bestemde MC4 connectoren.

sensor.dynamisch_nordpool
Heeft nu 4 extra attributen gekregen:
min_today, max_today, min_tomorrow en max_tomorrow.

sensor.dynamisch_spread_indicatie en sensor.dynamisch_spread_indicatie_nom (inclusief morgen)
Beide hebben nu het attribuut verschil_waarde erbij gekregen. Hierdoor is te zien wat de spread uitgedrukt in geld is.

input_number.zendure_2400_ac_max_oplaadvermogen en input_number.zendure_2400_ac_max_ontlaadvermogen
Wanneer via de Zendure APP of buiten Home Assistant het maximaal ontlaad- of oplaadvermogen werd ingesteld ontstond er een synchronisatiefout. Vanaf nu wordt dit constant gecontroleerd en zo nodig gecorrigeerd. De ingestelde waarde in Home Assistant is altijd leidend.

Bugfix

Indicatie Beschikbare Energie
Wordt nu correct berekend bij de 1600AC+, 2400AC+ en 2400AC Pro.

SOC Kalibratie
Zodra de geforceerde SOC-kalibratie gestart werd door de batterij zelf buiten de aansturing om wilde de batterij in standby gaan wat uiteraard niet kan tot de kalibratie is afgerond. Dit is nu opgelost.

Dynamisch laad en ontlaadgedrag
Tijdens het dynamisch laden en ontladen op hoog vermogen (handelen) was het mogelijk om het vermogen omlaag te zetten via de instellingen maar niet meer omhoog. Dit is nu opgelost.

Snel laad en ontlaadgedrag
Tijdens het snel laden en ontladen was het mogelijk om het vermogen omlaag te zetten via de instellingen maar niet meer omhoog. Dit is nu opgelost.

Spread_Indicatie_NOM en Spread_Indicatie_NOM_Morgen
Beide hadden moeite met handmatig ingevulde periodes. Dit is nu opgelost.

[YvonneVP]

Kaaf schreef op donderdag 12 maart 2026 @ 15:12:
[...]


Met HEMS zou je toch op z'n minst de P1 moeten kunnen uitlezen? Maar als ik HEMS uit zet heb ik precies hetzelfde probleem. 5 entities op de Zendure manager die alleen geen data uitlezen. De Zendure-HA zou toch ook gewoon via de cloud moeten werken (met HEMS)?

De Zendure HA is een andere integratie dan de Zendure-HA-zenSDK waar we het hier over hebben. Als je de integratie Zendure-HA-zenSDK gebruikt dan moet HEMS uit staan. In de Zendure app zou je dan nog wel je Zendure P1 meter moeten zien, en als je daarop klikt zou je een scherm als deze moeten zien, waar je dan weer op door kunt klikken bij 'Vandaag'.
Zie jij je Zendure P1 meter wel in de app als je HEMS uit zet? Of is ie dan niet zichtbaar, en dus niet te benaderen?

[YvonneVP]

gielz schreef op donderdag 12 maart 2026 @ 16:09:

Gielz - April 2026 release live

Deze release draait vooral om verfijning. De automatisering is overgestapt van braaf wachten in de rij naar parallel werken. Daardoor reageert de aansturing sneller en kun je instellingen aanpassen terwijl alles gewoon door blijft draaien. De batterij is dus officieel van “even wachten tot ik klaar ben” naar “komt goed, ik regel het tegelijk wel”.

Daarnaast hebben we de batterij 1 seconde extra tijd gegeven om na te denken. Klinkt klein, maar dit voorkomt dat hij zenuwachtig gaat pendelen op de P1-meter. Minder golfbewegingen, rustiger gedrag en stiekem zelfs een iets betere NOM-score. Soms zit vooruitgang dus gewoon in een beetje geduld.

Ook het dashboard heeft een flinke opfrisbeurt gekregen. Het oude dashboard was eigenlijk vooral een enthousiaste testomgeving. Tijd voor iets beters: een nieuw, overzichtelijk dashboard met drie tabbladen waarin je alles vindt wat je over de batterij wilt weten. Minder scrollen, sneller inzicht, en alles blijft volledig aanpasbaar voor wie graag zelf knutselt of eigen dashboards bouwt.

Verder is er een nieuwe dynamische modus toegevoegd die automatisch schakelt tussen handelen en Nul-op-de-Meter.

Kortom: geen revolutie, maar wel een update die de batterij en het dashboard duidelijk soepeler, slimmer en prettiger in gebruik maakt. Precies wat nu noodzakelijk is aangezien het opwekseizoen is begonnen. 🌞🌞🌞

Volg de GitHub ⭐⭐⭐

1) Zet een Star bij de Github pagina (dan volg je hem wat altijd handig is en maakt de aansturing populairder)
2) Klik op Watch en kies waar je exact een melding van wilt krijgen. Bij Custom kun je specifiek alleen releases aanvinken.
3) Bij je profiel onder Notifications kun je aangeven of het via github zelf gaat of naar je mailbox
[Afbeelding]

Release

https://github.com/Gielz1...DK/releases/tag/v20260312

Plug-N-Play Dashboard 2.0 – Alles in één

Overzichtelijk, compleet en verdeeld over 3 tabbladen, zodat je alles over je thuisbatterij in één oogopslag hebt. Gebruik ‘m zoals hij is, of haal er handige onderdelen uit voor je eigen dashboard. Zoals gebruikelijk ook weer 100% zelf aan te passen.
[Afbeelding]

⚠️ Grote aanpassing ⚠️

Automatisering van queued naar parallel
De automatisering draait nu in parallel modus. Hierdoor is het mogelijk om tijdens een lopende modus ook meteen instellingen aan te passen of andere wijzigingen te doen wat de sturing snelheid ten goede komt.
https://www.home-assistant.io/docs/automation/modes/

NOM interval
Uit veel NOM uren data is gebleken dat de batterij regelmatig iets meer dan 4 seconden nodig heeft waardoor je een golfbeweging kreeg op de P1 die minuten aanhield. Hierdoor is de interval nu op 5 seconden gezet. Met deze nieuwe interval kwam er gek genoeg een betere NOM uit.

Dit wil niet zeggen dat wanneer je de waterkoker aanzet de batterij pas na 5 seconden reageert. Het is een 5 seconden interval waardoor de batterij ook binnen 1 seconde kan reageren.

Mocht dit niet wenselijk zijn dan kan dit aangepast worden in de automatisering door /5 naar /4 te zetten:

code:

alias: Zendure zenSDK (Gielz)
description: Configuratie Versie April 2026 (20260216)
triggers:
  - seconds: /5
    id: aansturing_trigger
    trigger: time_pattern

Nieuwe modus optie

Dynamisch Handelen + NOM modus toegevoegd
Deze modus volgt het patroon goedkoopste en duurste uren die ingesteld zijn. Daarbuiten is het altijd Nul op de Meter.

Extra sensoren toegevoegd

⚠️ Zendure-HA-Zensdk Github Releasecheck ⚠️
Er wordt nu verbinding gemaakt met de API van GitHub waardoor deze sensor aangeeft of je up-to-date bent.

Totale Capaciteit
De batterijen worden nu herkend en berekend. Dit betreft de batterij in de omvormers, AB3000X, AB3000L en AB2000X.

Dynamisch Ontladen Loopt en Dynamisch Laden Loopt
Er wordt nu exact bijgehouden wanneer er een dynamisch ontlaad of laadcyclus loopt.

Omvormer Max. Oplaadvermogen en Omvormer Max. Ontlaadvermogen
Vanaf nu kun je zien wat er daadwerkelijk op de omvormer (API) is ingesteld. Dit wordt ook gebruikt om te controleren of deze afwijkend is ten opzichte van je eigen ingestelde maximum oplaad- en ontlaadvermogen.

Help Tonen Op Dashboard
Ten behoeve van het plug-n-play dashboard waardoor het nu mogelijk is om bij de meeste onderdelen direct een helptekst te tonen.

Dynamisch Tonen Op Dashboard
Ten behoeve van het plug-n-play dashboard waardoor je het dynamische gedeelte kunt uitzetten als je hier geen gebruik van wilt maken.

Wijzigingen in bestaande onderdelen

sensor.zendure_2400_ac_modus en sensor.zendure_2400_ac_vermogen_aansturing
Aangepast om de aansturing te kunnen gebruiken met direct aangesloten zonnepanelen op de daarvoor bestemde MC4 connectoren.

sensor.dynamisch_nordpool
Heeft nu 4 extra attributen gekregen:
min_today, max_today, min_tomorrow en max_tomorrow.

sensor.dynamisch_spread_indicatie en sensor.dynamisch_spread_indicatie_nom (inclusief morgen)
Beide hebben nu het attribuut verschil_waarde erbij gekregen. Hierdoor is te zien wat de spread uitgedrukt in geld is.

input_number.zendure_2400_ac_max_oplaadvermogen en input_number.zendure_2400_ac_max_ontlaadvermogen
Wanneer via de Zendure APP of buiten Home Assistant het maximaal ontlaad- of oplaadvermogen werd ingesteld ontstond er een synchronisatiefout. Vanaf nu wordt dit constant gecontroleerd en zo nodig gecorrigeerd. De ingestelde waarde in Home Assistant is altijd leidend.

Bugfix

Indicatie Beschikbare Energie
Wordt nu correct berekend bij de 1600AC+, 2400AC+ en 2400AC Pro.

SOC Kalibratie
Zodra de geforceerde SOC-kalibratie gestart werd door de batterij zelf buiten de aansturing om wilde de batterij in standby gaan wat uiteraard niet kan tot de kalibratie is afgerond. Dit is nu opgelost.

Dynamisch laad en ontlaadgedrag
Tijdens het dynamisch laden en ontladen op hoog vermogen (handelen) was het mogelijk om het vermogen omlaag te zetten via de instellingen maar niet meer omhoog. Dit is nu opgelost.

Snel laad en ontlaadgedrag
Tijdens het snel laden en ontladen was het mogelijk om het vermogen omlaag te zetten via de instellingen maar niet meer omhoog. Dit is nu opgelost.

Spread_Indicatie_NOM en Spread_Indicatie_NOM_Morgen
Beide hadden moeite met handmatig ingevulde periodes. Dit is nu opgelost.

Kan bij een afwijkende P1 sensor ook het IP adres gebruikt worden van de betreffende P1 meter, als dit dus geen Home Wizard P1 meter is? Of werkt het dan alleen als je de entiteit invoert?

[gielz]

YvonneVP schreef op donderdag 12 maart 2026 @ 18:51:
[...]

Kan bij een afwijkende P1 sensor ook het IP adres gebruikt worden van de betreffende P1 meter, als dit dus geen Home Wizard P1 meter is? Of werkt het dan alleen als je de entiteit invoert?

Hier kun je alleen een sensor naam invoeren. Bij het veld voor het IP van de Homewizard zit hier een stukje code achter die automatisch een REST: sensor voor je aanmaakt.

De meeste P1 zijn makkelijk te integreren via
https://github.com/Gielz1...ende-P1-CT-meters-(API's)

[Keida]

gielz schreef op donderdag 12 maart 2026 @ 16:09:

Gielz - April 2026 release live

Deze release draait vooral om verfijning. De automatisering is overgestapt van braaf wachten in de rij naar parallel werken. Daardoor reageert de aansturing sneller en kun je instellingen aanpassen terwijl alles gewoon door blijft draaien. De batterij is dus officieel van “even wachten tot ik klaar ben” naar “komt goed, ik regel het tegelijk wel”.

Daarnaast hebben we de batterij 1 seconde extra tijd gegeven om na te denken. Klinkt klein, maar dit voorkomt dat hij zenuwachtig gaat pendelen op de P1-meter. Minder golfbewegingen, rustiger gedrag en stiekem zelfs een iets betere NOM-score. Soms zit vooruitgang dus gewoon in een beetje geduld.

Ook het dashboard heeft een flinke opfrisbeurt gekregen. Het oude dashboard was eigenlijk vooral een enthousiaste testomgeving. Tijd voor iets beters: een nieuw, overzichtelijk dashboard met drie tabbladen waarin je alles vindt wat je over de batterij wilt weten. Minder scrollen, sneller inzicht, en alles blijft volledig aanpasbaar voor wie graag zelf knutselt of eigen dashboards bouwt.

Verder is er een nieuwe dynamische modus toegevoegd die automatisch schakelt tussen handelen en Nul-op-de-Meter.

Kortom: geen revolutie, maar wel een update die de batterij en het dashboard duidelijk soepeler, slimmer en prettiger in gebruik maakt. Precies wat nu noodzakelijk is aangezien het opwekseizoen is begonnen. 🌞🌞🌞

Volg de GitHub ⭐⭐⭐

1) Zet een Star bij de Github pagina (dan volg je hem wat altijd handig is en maakt de aansturing populairder)
2) Klik op Watch en kies waar je exact een melding van wilt krijgen. Bij Custom kun je specifiek alleen releases aanvinken.
3) Bij je profiel onder Notifications kun je aangeven of het via github zelf gaat of naar je mailbox
[Afbeelding]

Release

https://github.com/Gielz1...DK/releases/tag/v20260312

Plug-N-Play Dashboard 2.0 – Alles in één

Overzichtelijk, compleet en verdeeld over 3 tabbladen, zodat je alles over je thuisbatterij in één oogopslag hebt. Gebruik ‘m zoals hij is, of haal er handige onderdelen uit voor je eigen dashboard. Zoals gebruikelijk ook weer 100% zelf aan te passen.
[Afbeelding]

⚠️ Grote aanpassing ⚠️

Automatisering van queued naar parallel
De automatisering draait nu in parallel modus. Hierdoor is het mogelijk om tijdens een lopende modus ook meteen instellingen aan te passen of andere wijzigingen te doen wat de sturing snelheid ten goede komt.
https://www.home-assistant.io/docs/automation/modes/

NOM interval
Uit veel NOM uren data is gebleken dat de batterij regelmatig iets meer dan 4 seconden nodig heeft waardoor je een golfbeweging kreeg op de P1 die minuten aanhield. Hierdoor is de interval nu op 5 seconden gezet. Met deze nieuwe interval kwam er gek genoeg een betere NOM uit.

Dit wil niet zeggen dat wanneer je de waterkoker aanzet de batterij pas na 5 seconden reageert. Het is een 5 seconden interval waardoor de batterij ook binnen 1 seconde kan reageren.

Mocht dit niet wenselijk zijn dan kan dit aangepast worden in de automatisering door /5 naar /4 te zetten:

code:

alias: Zendure zenSDK (Gielz)
description: Configuratie Versie April 2026 (20260216)
triggers:
  - seconds: /5
    id: aansturing_trigger
    trigger: time_pattern

Nieuwe modus optie

Dynamisch Handelen + NOM modus toegevoegd
Deze modus volgt het patroon goedkoopste en duurste uren die ingesteld zijn. Daarbuiten is het altijd Nul op de Meter.

Extra sensoren toegevoegd

⚠️ Zendure-HA-Zensdk Github Releasecheck ⚠️
Er wordt nu verbinding gemaakt met de API van GitHub waardoor deze sensor aangeeft of je up-to-date bent.

Totale Capaciteit
De batterijen worden nu herkend en berekend. Dit betreft de batterij in de omvormers, AB3000X, AB3000L en AB2000X.

Dynamisch Ontladen Loopt en Dynamisch Laden Loopt
Er wordt nu exact bijgehouden wanneer er een dynamisch ontlaad of laadcyclus loopt.

Omvormer Max. Oplaadvermogen en Omvormer Max. Ontlaadvermogen
Vanaf nu kun je zien wat er daadwerkelijk op de omvormer (API) is ingesteld. Dit wordt ook gebruikt om te controleren of deze afwijkend is ten opzichte van je eigen ingestelde maximum oplaad- en ontlaadvermogen.

Help Tonen Op Dashboard
Ten behoeve van het plug-n-play dashboard waardoor het nu mogelijk is om bij de meeste onderdelen direct een helptekst te tonen.

Dynamisch Tonen Op Dashboard
Ten behoeve van het plug-n-play dashboard waardoor je het dynamische gedeelte kunt uitzetten als je hier geen gebruik van wilt maken.

Wijzigingen in bestaande onderdelen

sensor.zendure_2400_ac_modus en sensor.zendure_2400_ac_vermogen_aansturing
Aangepast om de aansturing te kunnen gebruiken met direct aangesloten zonnepanelen op de daarvoor bestemde MC4 connectoren.

sensor.dynamisch_nordpool
Heeft nu 4 extra attributen gekregen:
min_today, max_today, min_tomorrow en max_tomorrow.

sensor.dynamisch_spread_indicatie en sensor.dynamisch_spread_indicatie_nom (inclusief morgen)
Beide hebben nu het attribuut verschil_waarde erbij gekregen. Hierdoor is te zien wat de spread uitgedrukt in geld is.

input_number.zendure_2400_ac_max_oplaadvermogen en input_number.zendure_2400_ac_max_ontlaadvermogen
Wanneer via de Zendure APP of buiten Home Assistant het maximaal ontlaad- of oplaadvermogen werd ingesteld ontstond er een synchronisatiefout. Vanaf nu wordt dit constant gecontroleerd en zo nodig gecorrigeerd. De ingestelde waarde in Home Assistant is altijd leidend.

Bugfix

Indicatie Beschikbare Energie
Wordt nu correct berekend bij de 1600AC+, 2400AC+ en 2400AC Pro.

SOC Kalibratie
Zodra de geforceerde SOC-kalibratie gestart werd door de batterij zelf buiten de aansturing om wilde de batterij in standby gaan wat uiteraard niet kan tot de kalibratie is afgerond. Dit is nu opgelost.

Dynamisch laad en ontlaadgedrag
Tijdens het dynamisch laden en ontladen op hoog vermogen (handelen) was het mogelijk om het vermogen omlaag te zetten via de instellingen maar niet meer omhoog. Dit is nu opgelost.

Snel laad en ontlaadgedrag
Tijdens het snel laden en ontladen was het mogelijk om het vermogen omlaag te zetten via de instellingen maar niet meer omhoog. Dit is nu opgelost.

Spread_Indicatie_NOM en Spread_Indicatie_NOM_Morgen
Beide hadden moeite met handmatig ingevulde periodes. Dit is nu opgelost.

@gielz toevallig vandaag Zendure producten binnen gekregen en Plug 'n Play dashboard geinstalleerd
Waar ik tegenaan loop is dat hij niet automatisch het Dynamische deel toont op eerste tabblad (ook met vinkje in configuratie aan)

Als ik dan dashboard edit, naar raw YAML ga, en gelijk weer opsla/eruit ga, dan toont hij ineens wel het dynamische deel (derde kolom aan rechter kant).
Switch ik dan dashboards en weer terug, dan is het weer weg.

klein bugje?

(versie April 2026) v20260312 dus)

Verder moet ik het nog even begrijpen allemaal - leerproces
(en zien hoe te integreren met EVCC)

[gielz]

Keida schreef op donderdag 12 maart 2026 @ 22:00:
[...]


@gielz toevallig vandaag Zendure producten binnen gekregen en Plug 'n Play dashboard geinstalleerd
Waar ik tegenaan loop is dat hij niet automatisch het Dynamische deel toont op eerste tabblad (ook met vinkje in configuratie aan)

Als ik dan dashboard edit, naar raw YAML ga, en gelijk weer opsla/eruit ga, dan toont hij ineens wel het dynamische deel (derde kolom aan rechter kant).
Switch ik dan dashboards en weer terug, dan is het weer weg.

klein bugje?

(versie April 2026) v20260312 dus)

Verder moet ik het nog even begrijpen allemaal - leerproces
(en zien hoe te integreren met EVCC)

Hij zou standaard zichtbaar moeten zijn bij het zetten van het onderstaande vinkje op tabblad 3;


De 3e kolom werkt namelijk met deze code;

code:

visibility:
          - condition: state
            entity: input_boolean.dynamisch_tonen_op_dashboard
            state: 'on'

Ik zou iig even HA herstarten mocht je dat niet gedaan hebben en stuur mij even anders via DM alle 3 de tabbladen als screenshot + de dashboard yaml (dit om 100% zeker er van te zijn dat deze nog 1:1 is)

[Keida]

gielz schreef op donderdag 12 maart 2026 @ 22:15:
[...]


Hij zou standaard zichtbaar moeten zijn bij het zetten van het onderstaande vinkje op tabblad 3;
[Afbeelding]

De 3e kolom werkt namelijk met deze code;

code:

visibility:
          - condition: state
            entity: input_boolean.dynamisch_tonen_op_dashboard
            state: 'on'

Ik zou iig even HA herstarten mocht je dat niet gedaan hebben en stuur mij even anders via DM alle 3 de tabbladen als screenshot + de dashboard yaml (dit om 100% zeker er van te zijn dat deze nog 1:1 is)

Zojuist gedaan. Meerdere restarts later zelfde issue.
Dit is standaard Plug and Play dashboard, niets aan veranderd
wellicht dat meer mensen dit hebben (of iig kunnen checken)

[klump4u]

Keida schreef op donderdag 12 maart 2026 @ 22:51:
[...]


Zojuist gedaan. Meerdere restarts later zelfde issue.
Dit is standaard Plug and Play dashboard, niets aan veranderd
wellicht dat meer mensen dit hebben (of iig kunnen checken)

Bij mij werkt het gewoon, staatstandaard uit maar even getest en hij toont dan gewoon de info op de eerste pagina.

[Krisp]

Ik merk dat sinds vannacht Nordpool niet meer werkt. Nu heb ik het geheel sinds gisteren in gebruik, daar kan het zeker aan liggen. Ben wel al van de vorige release naar de huidige release geupgradet. IK kan het ook zien omdat de grafiek niet zichtbaar wordt. Vreemd genoeg gebeurt dit wel als ik de bron in de grafiek vervang door de Nordpool (HACS) sensor, en dat blijft zo als ik de originele sensor terug zet.

Daar hoort deze error bij:

code:

TemplateError('ValueError: Template error: strptime got invalid input '2026-03-13 ' when rendering template '{% set prijzen = state_attr('sensor.dynamisch_nordpool', 'raw_today') %} {% set handmatige = states('input_text.dynamisch_handmatige_periode') %} {% set aantal_goedkoop = states('input_number.dynamisch_goedkoopste_x_periode') | int %} {% set aantal_duur = states('input_number.dynamisch_duurste_x_periode') | int %} {% set kwartier = is_state('input_boolean.dynamisch_15_minuten', 'on') %} {% set default_delta = timedelta(minutes=15) if kwartier else timedelta(hours=1) %} {% if prijzen is iterable %} {% set ns = namespace(goedkope_starttijden=[], dure_starttijden=[]) %} {% if handmatige | length > 0 %} {% for item in handmatige.split(';') %} {% set type = item[0] %} {% set tijden = item[1:] %} {% if '-' in tijden %} {% set start_str = tijden.split('-')[0] %} {% set eind_str = tijden.split('-')[1] %} {% set range_block = True %} {% else %} {% set start_str = tijden %} {% set range_block = False %} {% endif %} {% for uur in prijzen %} {% set dt_start = uur.start | as_datetime %} {% set dt_end = uur.end | as_datetime %} {% set dag = dt_start.strftime('%Y-%m-%d') %} {% set tz = dt_start.tzinfo %} {% set start_dt = strptime(dag ~ ' ' ~ start_str, '%Y-%m-%d %H:%M').replace(tzinfo=tz) %} {% if range_block %} {% set eind_dt = strptime(dag ~ ' ' ~ eind_str, '%Y-%m-%d %H:%M').replace(tzinfo=tz) %} {% if eind_dt <= start_dt %} {% set eind_dt = eind_dt + timedelta(days=1) %} {% endif %} {% set eind_dt = eind_dt + timedelta(seconds=1) %} {% else %} {% set eind_dt = start_dt + default_delta %} {% endif %} {% if dt_start < eind_dt and dt_end > start_dt %} {% if type == 'G' %} {% set ns.goedkope_starttijden = ns.goedkope_starttijden + [uur.start] %} {% elif type == 'D' %} {% set ns.dure_starttijden = ns.dure_starttijden + [uur.start] %} {% endif %} {% endif %} {% endfor %} {% endfor %} {% else %} {% set prijzen_sorted = prijzen | sort(attribute='value') %} {% set ns.goedkope_starttijden = prijzen_sorted[:aantal_goedkoop] | map(attribute='start') | list %} {% if aantal_duur > 0 %} {% set ns.dure_starttijden = prijzen_sorted[-aantal_duur:] | map(attribute='start') | list %} {% else %} {% set ns.dure_starttijden = [] %} {% endif %} {% endif %} [ {% for uur in prijzen %} { "start": "{{ uur.start }}", "end": "{{ uur.end }}", "value": {{ uur.value }}, "goedkoop": "{{ 'ja' if uur.start in ns.goedkope_starttijden else 'nee' }}", "duur": "{{ 'ja' if uur.start in ns.dure_starttijden else 'nee' }}" }{% if not loop.last %},{% endif %} {% endfor %} ] {% else %} [] {% endif %}' but no default was specified') while processing template 'Template<template=({% set prijzen = state_attr('sensor.dynamisch_nordpool', 'raw_today') %} {% set handmatige = states('input_text.dynamisch_handmatige_periode') %} {% set aantal_goedkoop = states('input_number.dynamisch_goedkoopste_x_periode') | int %} {% set aantal_duur = states('input_number.dynamisch_duurste_x_periode') | int %} {% set kwartier = is_state('input_boolean.dynamisch_15_minuten', 'on') %} {% set default_delta = timedelta(minutes=15) if kwartier else timedelta(hours=1) %} {% if prijzen is iterable %} {% set ns = namespace(goedkope_starttijden=[], dure_starttijden=[]) %} {% if handmatige | length > 0 %} {% for item in handmatige.split(';') %} {% set type = item[0] %} {% set tijden = item[1:] %} {% if '-' in tijden %} {% set start_str = tijden.split('-')[0] %} {% set eind_str = tijden.split('-')[1] %} {% set range_block = True %} {% else %} {% set start_str = tijden %} {% set range_block = False %} {% endif %} {% for uur in prijzen %} {% set dt_start = uur.start | as_datetime %} {% set dt_end = uur.end | as_datetime %} {% set dag = dt_start.strftime('%Y-%m-%d') %} {% set tz = dt_start.tzinfo %} {% set start_dt = strptime(dag ~ ' ' ~ start_str, '%Y-%m-%d %H:%M').replace(tzinfo=tz) %} {% if range_block %} {% set eind_dt = strptime(dag ~ ' ' ~ eind_str, '%Y-%m-%d %H:%M').replace(tzinfo=tz) %} {% if eind_dt <= start_dt %} {% set eind_dt = eind_dt + timedelta(days=1) %} {% endif %} {% set eind_dt = eind_dt + timedelta(seconds=1) %} {% else %} {% set eind_dt = start_dt + default_delta %} {% endif %} {% if dt_start < eind_dt and dt_end > start_dt %} {% if type == 'G' %} {% set ns.goedkope_starttijden = ns.goedkope_starttijden + [uur.start] %} {% elif type == 'D' %} {% set ns.dure_starttijden = ns.dure_starttijden + [uur.start] %} {% endif %} {% endif %} {% endfor %} {% endfor %} {% else %} {% set prijzen_sorted = prijzen | sort(attribute='value') %} {% set ns.goedkope_starttijden = prijzen_sorted[:aantal_goedkoop] | map(attribute='start') | list %} {% if aantal_duur > 0 %} {% set ns.dure_starttijden = prijzen_sorted[-aantal_duur:] | map(attribute='start') | list %} {% else %} {% set ns.dure_starttijden = [] %} {% endif %} {% endif %} [ {% for uur in prijzen %} { "start": "{{ uur.start }}", "end": "{{ uur.end }}", "value": {{ uur.value }}, "goedkoop": "{{ 'ja' if uur.start in ns.goedkope_starttijden else 'nee' }}", "duur": "{{ 'ja' if uur.start in ns.dure_starttijden else 'nee' }}" }{% if not loop.last %},{% endif %} {% endfor %} ] {% else %} [] {% endif %}) renders=4>' for attribute 'raw_today' in entity 'sensor.dynamisch_goedkoopste_periode'

[gielz]

Krisp schreef op vrijdag 13 maart 2026 @ 08:36:
Ik merk dat sinds vannacht Nordpool niet meer werkt. Nu heb ik het geheel sinds gisteren in gebruik, daar kan het zeker aan liggen. Ben wel al van de vorige release naar de huidige release geupgradet. IK kan het ook zien omdat de grafiek niet zichtbaar wordt. Vreemd genoeg gebeurt dit wel als ik de bron in de grafiek vervang door de Nordpool (HACS) sensor, en dat blijft zo als ik de originele sensor terug zet.

Daar hoort deze error bij:

code:

TemplateError('ValueError: Template error: strptime got invalid input '2026-03-13 ' when rendering template '{% set prijzen = state_attr('sensor.dynamisch_nordpool', 'raw_today') %} {% set handmatige = states('input_text.dynamisch_handmatige_periode') %} {% set aantal_goedkoop = states('input_number.dynamisch_goedkoopste_x_periode') | int %} {% set aantal_duur = states('input_number.dynamisch_duurste_x_periode') | int %} {% set kwartier = is_state('input_boolean.dynamisch_15_minuten', 'on') %} {% set default_delta = timedelta(minutes=15) if kwartier else timedelta(hours=1) %} {% if prijzen is iterable %} {% set ns = namespace(goedkope_starttijden=[], dure_starttijden=[]) %} {% if handmatige | length > 0 %} {% for item in handmatige.split(';') %} {% set type = item[0] %} {% set tijden = item[1:] %} {% if '-' in tijden %} {% set start_str = tijden.split('-')[0] %} {% set eind_str = tijden.split('-')[1] %} {% set range_block = True %} {% else %} {% set start_str = tijden %} {% set range_block = False %} {% endif %} {% for uur in prijzen %} {% set dt_start = uur.start | as_datetime %} {% set dt_end = uur.end | as_datetime %} {% set dag = dt_start.strftime('%Y-%m-%d') %} {% set tz = dt_start.tzinfo %} {% set start_dt = strptime(dag ~ ' ' ~ start_str, '%Y-%m-%d %H:%M').replace(tzinfo=tz) %} {% if range_block %} {% set eind_dt = strptime(dag ~ ' ' ~ eind_str, '%Y-%m-%d %H:%M').replace(tzinfo=tz) %} {% if eind_dt <= start_dt %} {% set eind_dt = eind_dt + timedelta(days=1) %} {% endif %} {% set eind_dt = eind_dt + timedelta(seconds=1) %} {% else %} {% set eind_dt = start_dt + default_delta %} {% endif %} {% if dt_start < eind_dt and dt_end > start_dt %} {% if type == 'G' %} {% set ns.goedkope_starttijden = ns.goedkope_starttijden + [uur.start] %} {% elif type == 'D' %} {% set ns.dure_starttijden = ns.dure_starttijden + [uur.start] %} {% endif %} {% endif %} {% endfor %} {% endfor %} {% else %} {% set prijzen_sorted = prijzen | sort(attribute='value') %} {% set ns.goedkope_starttijden = prijzen_sorted[:aantal_goedkoop] | map(attribute='start') | list %} {% if aantal_duur > 0 %} {% set ns.dure_starttijden = prijzen_sorted[-aantal_duur:] | map(attribute='start') | list %} {% else %} {% set ns.dure_starttijden = [] %} {% endif %} {% endif %} [ {% for uur in prijzen %} { "start": "{{ uur.start }}", "end": "{{ uur.end }}", "value": {{ uur.value }}, "goedkoop": "{{ 'ja' if uur.start in ns.goedkope_starttijden else 'nee' }}", "duur": "{{ 'ja' if uur.start in ns.dure_starttijden else 'nee' }}" }{% if not loop.last %},{% endif %} {% endfor %} ] {% else %} [] {% endif %}' but no default was specified') while processing template 'Template<template=({% set prijzen = state_attr('sensor.dynamisch_nordpool', 'raw_today') %} {% set handmatige = states('input_text.dynamisch_handmatige_periode') %} {% set aantal_goedkoop = states('input_number.dynamisch_goedkoopste_x_periode') | int %} {% set aantal_duur = states('input_number.dynamisch_duurste_x_periode') | int %} {% set kwartier = is_state('input_boolean.dynamisch_15_minuten', 'on') %} {% set default_delta = timedelta(minutes=15) if kwartier else timedelta(hours=1) %} {% if prijzen is iterable %} {% set ns = namespace(goedkope_starttijden=[], dure_starttijden=[]) %} {% if handmatige | length > 0 %} {% for item in handmatige.split(';') %} {% set type = item[0] %} {% set tijden = item[1:] %} {% if '-' in tijden %} {% set start_str = tijden.split('-')[0] %} {% set eind_str = tijden.split('-')[1] %} {% set range_block = True %} {% else %} {% set start_str = tijden %} {% set range_block = False %} {% endif %} {% for uur in prijzen %} {% set dt_start = uur.start | as_datetime %} {% set dt_end = uur.end | as_datetime %} {% set dag = dt_start.strftime('%Y-%m-%d') %} {% set tz = dt_start.tzinfo %} {% set start_dt = strptime(dag ~ ' ' ~ start_str, '%Y-%m-%d %H:%M').replace(tzinfo=tz) %} {% if range_block %} {% set eind_dt = strptime(dag ~ ' ' ~ eind_str, '%Y-%m-%d %H:%M').replace(tzinfo=tz) %} {% if eind_dt <= start_dt %} {% set eind_dt = eind_dt + timedelta(days=1) %} {% endif %} {% set eind_dt = eind_dt + timedelta(seconds=1) %} {% else %} {% set eind_dt = start_dt + default_delta %} {% endif %} {% if dt_start < eind_dt and dt_end > start_dt %} {% if type == 'G' %} {% set ns.goedkope_starttijden = ns.goedkope_starttijden + [uur.start] %} {% elif type == 'D' %} {% set ns.dure_starttijden = ns.dure_starttijden + [uur.start] %} {% endif %} {% endif %} {% endfor %} {% endfor %} {% else %} {% set prijzen_sorted = prijzen | sort(attribute='value') %} {% set ns.goedkope_starttijden = prijzen_sorted[:aantal_goedkoop] | map(attribute='start') | list %} {% if aantal_duur > 0 %} {% set ns.dure_starttijden = prijzen_sorted[-aantal_duur:] | map(attribute='start') | list %} {% else %} {% set ns.dure_starttijden = [] %} {% endif %} {% endif %} [ {% for uur in prijzen %} { "start": "{{ uur.start }}", "end": "{{ uur.end }}", "value": {{ uur.value }}, "goedkoop": "{{ 'ja' if uur.start in ns.goedkope_starttijden else 'nee' }}", "duur": "{{ 'ja' if uur.start in ns.dure_starttijden else 'nee' }}" }{% if not loop.last %},{% endif %} {% endfor %} ] {% else %} [] {% endif %}) renders=4>' for attribute 'raw_today' in entity 'sensor.dynamisch_goedkoopste_periode'

Zou je even een screenshot kunnen posten wat er ingevuld staat in input_text.dynamisch_nordpool_sensor.

En deze nogmaals doorlezen; https://github.com/Gielz1...-file#-optioneel-nordpool

[Devke]

.
Edit : het toevoegen van afbeeldingen op tweakers is even niet mogelijk. Post verwijderd.

[ Voor 196% gewijzigd door Devke op 13-03-2026 13:23 ]

[ppaulv]

@Devke je wilde even een punt maken ?

[Devke]

ppaulv schreef op vrijdag 13 maart 2026 @ 13:11:
@Devke je wilde even een punt maken ?

Whaha. Nee. Het uploaden van afbeeldingen gaat even niet op tweakers. Dus het zag er erg rommelig uit. Weer verwijderd. Volgt.

[ppaulv]

[ppaulv]

gaat voor mij prima.