Zendure producten in Home Assistant integreren deel 2

[sjnelle]

Ik heb wat uitdagingen.
Ik heb geupgrade naar de april code en krijg onderstaande foutmeldingen in mijn home assistant log.

Daarnaast heb ik wat issues met het verkrijgen van juiste tarieven van Zonneplan. Heeft iemand zijn config online staan waar ik kan spieken?

Tevens als ik de package versie gebruik wordt er niks geladen. In de configuration.yaml werkt het wel

code:

homeassistant:
  packages: !include_dir_named packages

code:

2026-02-25 07:24:30.165 ERROR (MainThread) [homeassistant.helpers.event] Error while processing template: Template<template=({% set uren = state_attr('sensor.dynamisch_goedkoopste_periode', 'duurste_na_eerste_goedkope') %} {% set duur = uren | sort(attribute='value', reverse=true) | list %} [ {% for uur in duur %}
  "{{ (uur.start | as_datetime).strftime('%H:%M') }} - €{{ '%.4f' | format(uur.value) }}"
  {% if not loop.last %}, {% endif %}
{% endfor %} ]) renders=2>
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/template/__init__.py", line 461, in async_render
    render_result = render_with_context(self.template, compiled, **kwargs)
  File "/usr/src/homeassistant/homeassistant/helpers/template/context.py", line 45, in render_with_context
    return template.render(**kwargs)
           ~~~~~~~~~~~~~~~^^^^^^^^^^
  File "/usr/local/lib/python3.13/site-packages/jinja2/environment.py", line 1295, in render
    self.environment.handle_exception()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/usr/local/lib/python3.13/site-packages/jinja2/environment.py", line 942, in handle_exception
    raise rewrite_traceback_stack(source=source)
  File "<template>", line 1, in top-level template code
  File "/usr/local/lib/python3.13/site-packages/jinja2/filters.py", line 438, in do_sort
    return sorted(value, key=key_func, reverse=reverse)
TypeError: 'NoneType' object is not iterable

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/template/__init__.py", line 579, in async_render_to_info
    render_info._result = self.async_render(  # noqa: SLF001
                          ~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^
        variables, strict=strict, log_fn=log_fn, **kwargs
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "/usr/src/homeassistant/homeassistant/helpers/template/__init__.py", line 463, in async_render
    raise TemplateError(err) from err
homeassistant.exceptions.TemplateError: TypeError: 'NoneType' object is not iterable
2026-02-25 07:24:30.170 ERROR (MainThread) [homeassistant.components.template.template_entity] TemplateError('TypeError: 'NoneType' object is not iterable') while processing template 'Template<template=({% set uren = state_attr('sensor.dynamisch_goedkoopste_periode', 'duurste_na_eerste_goedkope') %} {% set duur = uren | sort(attribute='value', reverse=true) | list %} [ {% for uur in duur %}
  "{{ (uur.start | as_datetime).strftime('%H:%M') }} - €{{ '%.4f' | format(uur.value) }}"
  {% if not loop.last %}, {% endif %}
{% endfor %} ]) renders=4>' for attribute 'duurste_periode' in entity 'sensor.dynamisch_spread_indicatie_nom'
2026-02-25 07:24:30.172 ERROR (MainThread) [homeassistant.helpers.event] Error while processing template: Template<template=({% set uren = state_attr('sensor.dynamisch_goedkoopste_periode', 'duurste_na_eerste_goedkope_morgen') %} {% set duur = uren | sort(attribute='value', reverse=true) | list %} [ {% for uur in duur %}
  "{{ (uur.start | as_datetime).strftime('%H:%M') }} - €{{ '%.4f' | format(uur.value) }}"
  {% if not loop.last %}, {% endif %}
{% endfor %} ]) renders=2>
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/template/__init__.py", line 461, in async_render
    render_result = render_with_context(self.template, compiled, **kwargs)
  File "/usr/src/homeassistant/homeassistant/helpers/template/context.py", line 45, in render_with_context
    return template.render(**kwargs)
           ~~~~~~~~~~~~~~~^^^^^^^^^^
  File "/usr/local/lib/python3.13/site-packages/jinja2/environment.py", line 1295, in render
    self.environment.handle_exception()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/usr/local/lib/python3.13/site-packages/jinja2/environment.py", line 942, in handle_exception
    raise rewrite_traceback_stack(source=source)
  File "<template>", line 1, in top-level template code
  File "/usr/local/lib/python3.13/site-packages/jinja2/filters.py", line 438, in do_sort
    return sorted(value, key=key_func, reverse=reverse)
TypeError: 'NoneType' object is not iterable

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/template/__init__.py", line 579, in async_render_to_info
    render_info._result = self.async_render(  # noqa: SLF001
                          ~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^
        variables, strict=strict, log_fn=log_fn, **kwargs
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "/usr/src/homeassistant/homeassistant/helpers/template/__init__.py", line 463, in async_render
    raise TemplateError(err) from err
homeassistant.exceptions.TemplateError: TypeError: 'NoneType' object is not iterable
2026-02-25 07:24:30.174 ERROR (MainThread) [homeassistant.components.template.template_entity] TemplateError('TypeError: 'NoneType' object is not iterable') while processing template 'Template<template=({% set uren = state_attr('sensor.dynamisch_goedkoopste_periode', 'duurste_na_eerste_goedkope_morgen') %} {% set duur = uren | sort(attribute='value', reverse=true) | list %} [ {% for uur in duur %}
  "{{ (uur.start | as_datetime).strftime('%H:%M') }} - €{{ '%.4f' | format(uur.value) }}"
  {% if not loop.last %}, {% endif %}
{% endfor %} ]) renders=4>' for attribute 'duurste_periode' in entity 'sensor.dynamisch_spread_indicatie_nom_morgen'

[YvonneVP]

Taro schreef op woensdag 9 juli 2025 @ 17:41:
Hierbij de YAML om de Zendure P1-meter in Home Assistant te integreren:

YAML:

- resource: http://192.168.1.X/properties/report   # Zendure P1
    scan_interval: 1
    sensor:
      - name: "Zendure P1 Vermogen Fase A"
        value_template: "{{ value_json['a_aprt_power'] }}"
        unique_id: Zendure_P1_Vermogen_Fase_A
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power
      - name: "Zendure P1 Vermogen Fase B"
        value_template: "{{ value_json['b_aprt_power'] }}"
        unique_id: Zendure_P1_Vermogen_Fase_B
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power
      - name: "Zendure P1 Vermogen Fase C"
        value_template: "{{ value_json['c_aprt_power'] }}"
        unique_id: Zendure_P1_Vermogen_Fase_C
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power
      - name: "Zendure P1 Vermogen Totaal"
        value_template: "{{ value_json['total_power'] }}"
        unique_id: Zendure_P1_Vermogen_Totaal
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power

Moet dit in de configuration.yaml opgeslagen worden? Ik heb namelijk ook een Zendure P1 meter, en ook een van Powerbaas, Powerbaas ben ik niet zeker van of die elke seconde uitleest. Aangezien ik een Zendure 2400AC heb lijkt het me misschien handiger om dan ook die P1 meter te integreren in HA zodat ik die in Gielz mooie HA overzicht kan gebruiken.

[YvonneVP]

martinvdm schreef op woensdag 25 februari 2026 @ 07:20:
[...]

Betekent gewoonweg maximaal ont- of opladen tijdens goedkope of dure uren. Naast eventueel nom igv “dynamisch handelen + nom”. Op de GitHub vind je bij de diverse standen in de tabel in de rechterkolom uitleg.

Die uitleg is mij soms ook niet helemaal duidelijk. Vooral voor mensen die wat minder technisch aangelegd zijn is het soms even achter de oren krabben wat iets nu precies inhoud, of betekend, zodat de instellingen ook correct kunnen worden ingevoerd. Waar Gielz een advies geeft neem ik die meestal over, maar sommige begrippen zijn een beetje abacadabra voor me.

[Pakhaas]

YvonneVP schreef op woensdag 25 februari 2026 @ 12:51:
[...]

Moet dit in de configuration.yaml opgeslagen worden? Ik heb namelijk ook een Zendure P1 meter, en ook een van Powerbaas, Powerbaas ben ik niet zeker van of die elke seconde uitleest. Aangezien ik een Zendure 2400AC heb lijkt het me misschien handiger om dan ook die P1 meter te integreren in HA zodat ik die in Gielz mooie HA overzicht kan gebruiken.

Is dat ook nodig als je naast de Zendure P1 meter ook de Homewizard P1 meter hebt?

[gielz]

sjnelle schreef op woensdag 25 februari 2026 @ 09:00:
Ik heb wat uitdagingen.
Ik heb geupgrade naar de april code en krijg onderstaande foutmeldingen in mijn home assistant log.

Daarnaast heb ik wat issues met het verkrijgen van juiste tarieven van Zonneplan. Heeft iemand zijn config online staan waar ik kan spieken?

Tevens als ik de package versie gebruik wordt er niks geladen. In de configuration.yaml werkt het wel

code:

homeassistant:
  packages: !include_dir_named packages

code:

2026-02-25 07:24:30.165 ERROR (MainThread) [homeassistant.helpers.event] Error while processing template: Template<template=({% set uren = state_attr('sensor.dynamisch_goedkoopste_periode', 'duurste_na_eerste_goedkope') %} {% set duur = uren | sort(attribute='value', reverse=true) | list %} [ {% for uur in duur %}
  "{{ (uur.start | as_datetime).strftime('%H:%M') }} - €{{ '%.4f' | format(uur.value) }}"
  {% if not loop.last %}, {% endif %}
{% endfor %} ]) renders=2>
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/template/__init__.py", line 461, in async_render
    render_result = render_with_context(self.template, compiled, **kwargs)
  File "/usr/src/homeassistant/homeassistant/helpers/template/context.py", line 45, in render_with_context
    return template.render(**kwargs)
           ~~~~~~~~~~~~~~~^^^^^^^^^^
  File "/usr/local/lib/python3.13/site-packages/jinja2/environment.py", line 1295, in render
    self.environment.handle_exception()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/usr/local/lib/python3.13/site-packages/jinja2/environment.py", line 942, in handle_exception
    raise rewrite_traceback_stack(source=source)
  File "<template>", line 1, in top-level template code
  File "/usr/local/lib/python3.13/site-packages/jinja2/filters.py", line 438, in do_sort
    return sorted(value, key=key_func, reverse=reverse)
TypeError: 'NoneType' object is not iterable

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/template/__init__.py", line 579, in async_render_to_info
    render_info._result = self.async_render(  # noqa: SLF001
                          ~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^
        variables, strict=strict, log_fn=log_fn, **kwargs
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "/usr/src/homeassistant/homeassistant/helpers/template/__init__.py", line 463, in async_render
    raise TemplateError(err) from err
homeassistant.exceptions.TemplateError: TypeError: 'NoneType' object is not iterable
2026-02-25 07:24:30.170 ERROR (MainThread) [homeassistant.components.template.template_entity] TemplateError('TypeError: 'NoneType' object is not iterable') while processing template 'Template<template=({% set uren = state_attr('sensor.dynamisch_goedkoopste_periode', 'duurste_na_eerste_goedkope') %} {% set duur = uren | sort(attribute='value', reverse=true) | list %} [ {% for uur in duur %}
  "{{ (uur.start | as_datetime).strftime('%H:%M') }} - €{{ '%.4f' | format(uur.value) }}"
  {% if not loop.last %}, {% endif %}
{% endfor %} ]) renders=4>' for attribute 'duurste_periode' in entity 'sensor.dynamisch_spread_indicatie_nom'
2026-02-25 07:24:30.172 ERROR (MainThread) [homeassistant.helpers.event] Error while processing template: Template<template=({% set uren = state_attr('sensor.dynamisch_goedkoopste_periode', 'duurste_na_eerste_goedkope_morgen') %} {% set duur = uren | sort(attribute='value', reverse=true) | list %} [ {% for uur in duur %}
  "{{ (uur.start | as_datetime).strftime('%H:%M') }} - €{{ '%.4f' | format(uur.value) }}"
  {% if not loop.last %}, {% endif %}
{% endfor %} ]) renders=2>
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/template/__init__.py", line 461, in async_render
    render_result = render_with_context(self.template, compiled, **kwargs)
  File "/usr/src/homeassistant/homeassistant/helpers/template/context.py", line 45, in render_with_context
    return template.render(**kwargs)
           ~~~~~~~~~~~~~~~^^^^^^^^^^
  File "/usr/local/lib/python3.13/site-packages/jinja2/environment.py", line 1295, in render
    self.environment.handle_exception()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/usr/local/lib/python3.13/site-packages/jinja2/environment.py", line 942, in handle_exception
    raise rewrite_traceback_stack(source=source)
  File "<template>", line 1, in top-level template code
  File "/usr/local/lib/python3.13/site-packages/jinja2/filters.py", line 438, in do_sort
    return sorted(value, key=key_func, reverse=reverse)
TypeError: 'NoneType' object is not iterable

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/template/__init__.py", line 579, in async_render_to_info
    render_info._result = self.async_render(  # noqa: SLF001
                          ~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^
        variables, strict=strict, log_fn=log_fn, **kwargs
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "/usr/src/homeassistant/homeassistant/helpers/template/__init__.py", line 463, in async_render
    raise TemplateError(err) from err
homeassistant.exceptions.TemplateError: TypeError: 'NoneType' object is not iterable
2026-02-25 07:24:30.174 ERROR (MainThread) [homeassistant.components.template.template_entity] TemplateError('TypeError: 'NoneType' object is not iterable') while processing template 'Template<template=({% set uren = state_attr('sensor.dynamisch_goedkoopste_periode', 'duurste_na_eerste_goedkope_morgen') %} {% set duur = uren | sort(attribute='value', reverse=true) | list %} [ {% for uur in duur %}
  "{{ (uur.start | as_datetime).strftime('%H:%M') }} - €{{ '%.4f' | format(uur.value) }}"
  {% if not loop.last %}, {% endif %}
{% endfor %} ]) renders=4>' for attribute 'duurste_periode' in entity 'sensor.dynamisch_spread_indicatie_nom_morgen'

Ik heb dit één keer gezien bij een andere gebruiker @Devke . Hier was de oplossing om eerst terug te gaan naar de basis configuration.yaml +package

code:

# Laad standaard set van integraties. Niet verwijderen.
default_config:

# Laad frontend thema's uit de themes-map
frontend:
  themes: !include_dir_merge_named themes

automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml

homeassistant:
  packages: !include_dir_named packages

[YvonneVP]

Pakhaas schreef op woensdag 25 februari 2026 @ 12:58:
[...]

Is dat ook nodig als je naast de Zendure P1 meter ook de Homewizard P1 meter hebt?

De P1 van Zendure heeft, voor zover ik heb kunnen zien, geen eigen entiteit in HA, ook niet via de Zendure-HA integratie. En zonder entiteit kun je die dan dus ook nergens aan koppelen of specifiek uitlezen.

Ik had de REST: code in de configuration.yaml gezet, maar kreeg een foutmelding over 'REST:' toen ik HA wilde herstarten. Ik heb het er dus weer even uit gehaald.

[gielz]

YvonneVP schreef op woensdag 25 februari 2026 @ 13:13:
[...]

De P1 van Zendure heeft, voor zover ik heb kunnen zien, geen eigen entiteit in HA, ook niet via de Zendure-HA integratie. En zonder entiteit kun je die dan dus ook nergens aan koppelen of specifiek uitlezen.

Ik had de REST: code in de configuration.yaml gezet, maar kreeg een foutmelding over 'REST:' toen ik HA wilde herstarten. Ik heb het er dus weer even uit gehaald.

P1 van zendure kun je gewoon uit lezen. Probeer dit eens in een configuration.yaml of eigen package. Let op: REST: mag maar 1x voor komen. En uiteraard het juiste IP;

code:

rest:
  - resource: http://192.168.1.X/properties/report   # Zendure P1
    scan_interval: 1
    sensor:
      - name: "Zendure P1 Vermogen Fase A"
        value_template: "{{ value_json['a_aprt_power'] }}"
        unique_id: Zendure_P1_Vermogen_Fase_A
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power
      - name: "Zendure P1 Vermogen Fase B"
        value_template: "{{ value_json['b_aprt_power'] }}"
        unique_id: Zendure_P1_Vermogen_Fase_B
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power
      - name: "Zendure P1 Vermogen Fase C"
        value_template: "{{ value_json['c_aprt_power'] }}"
        unique_id: Zendure_P1_Vermogen_Fase_C
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power
      - name: "Zendure P1 Vermogen Totaal"
        value_template: "{{ value_json['total_power'] }}"
        unique_id: Zendure_P1_Vermogen_Totaal
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power

[YvonneVP]

@gielz Ik heb de maart configuratie afgelopen avond en nacht vers in HA gezet, maar de Apex chart voor 'Dynamisch Vandaag' bestaat alleen uit rode verticale balkjes, en de Dynamisch Morgen blijft leeg. Ik heb voor beide de door jou meegeleverde yaml code gebruikt zoals ook is aangegeven in de readme.md.

[gielz]

YvonneVP schreef op woensdag 25 februari 2026 @ 13:21:
@gielz Ik heb de maart configuratie afgelopen avond en nacht vers in HA gezet, maar de Apex chart voor 'Dynamisch Vandaag' bestaat alleen uit rode verticale balkjes, en de Dynamisch Morgen blijft leeg. Ik heb voor beide de door jou meegeleverde yaml code gebruikt zoals ook is aangegeven in de readme.md. [Afbeelding]

Wat staat er ingevuld bij input_text.dynamisch_nordpool_sensor en heeft sensor.dynamisch_nordpool daadwerkelijk netjes alle tarieven in de attributen?

[Devke]

sjnelle schreef op woensdag 25 februari 2026 @ 09:00:
Ik heb wat uitdagingen.
Ik heb geupgrade naar de april code en krijg onderstaande foutmeldingen in mijn home assistant log.

Daarnaast heb ik wat issues met het verkrijgen van juiste tarieven van Zonneplan. Heeft iemand zijn config online staan waar ik kan spieken?

Tevens als ik de package versie gebruik wordt er niks geladen. In de configuration.yaml werkt het wel

code:

homeassistant:
  packages: !include_dir_named packages

code:

2026-02-25 07:24:30.165 ERROR (MainThread) [homeassistant.helpers.event] Error while processing template: Template<template=({% set uren = state_attr('sensor.dynamisch_goedkoopste_periode', 'duurste_na_eerste_goedkope') %} {% set duur = uren | sort(attribute='value', reverse=true) | list %} [ {% for uur in duur %}
  "{{ (uur.start | as_datetime).strftime('%H:%M') }} - €{{ '%.4f' | format(uur.value) }}"
  {% if not loop.last %}, {% endif %}
{% endfor %} ]) renders=2>
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/template/__init__.py", line 461, in async_render
    render_result = render_with_context(self.template, compiled, **kwargs)
  File "/usr/src/homeassistant/homeassistant/helpers/template/context.py", line 45, in render_with_context
    return template.render(**kwargs)
           ~~~~~~~~~~~~~~~^^^^^^^^^^
  File "/usr/local/lib/python3.13/site-packages/jinja2/environment.py", line 1295, in render
    self.environment.handle_exception()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/usr/local/lib/python3.13/site-packages/jinja2/environment.py", line 942, in handle_exception
    raise rewrite_traceback_stack(source=source)
  File "<template>", line 1, in top-level template code
  File "/usr/local/lib/python3.13/site-packages/jinja2/filters.py", line 438, in do_sort
    return sorted(value, key=key_func, reverse=reverse)
TypeError: 'NoneType' object is not iterable

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/template/__init__.py", line 579, in async_render_to_info
    render_info._result = self.async_render(  # noqa: SLF001
                          ~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^
        variables, strict=strict, log_fn=log_fn, **kwargs
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "/usr/src/homeassistant/homeassistant/helpers/template/__init__.py", line 463, in async_render
    raise TemplateError(err) from err
homeassistant.exceptions.TemplateError: TypeError: 'NoneType' object is not iterable
2026-02-25 07:24:30.170 ERROR (MainThread) [homeassistant.components.template.template_entity] TemplateError('TypeError: 'NoneType' object is not iterable') while processing template 'Template<template=({% set uren = state_attr('sensor.dynamisch_goedkoopste_periode', 'duurste_na_eerste_goedkope') %} {% set duur = uren | sort(attribute='value', reverse=true) | list %} [ {% for uur in duur %}
  "{{ (uur.start | as_datetime).strftime('%H:%M') }} - €{{ '%.4f' | format(uur.value) }}"
  {% if not loop.last %}, {% endif %}
{% endfor %} ]) renders=4>' for attribute 'duurste_periode' in entity 'sensor.dynamisch_spread_indicatie_nom'
2026-02-25 07:24:30.172 ERROR (MainThread) [homeassistant.helpers.event] Error while processing template: Template<template=({% set uren = state_attr('sensor.dynamisch_goedkoopste_periode', 'duurste_na_eerste_goedkope_morgen') %} {% set duur = uren | sort(attribute='value', reverse=true) | list %} [ {% for uur in duur %}
  "{{ (uur.start | as_datetime).strftime('%H:%M') }} - €{{ '%.4f' | format(uur.value) }}"
  {% if not loop.last %}, {% endif %}
{% endfor %} ]) renders=2>
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/template/__init__.py", line 461, in async_render
    render_result = render_with_context(self.template, compiled, **kwargs)
  File "/usr/src/homeassistant/homeassistant/helpers/template/context.py", line 45, in render_with_context
    return template.render(**kwargs)
           ~~~~~~~~~~~~~~~^^^^^^^^^^
  File "/usr/local/lib/python3.13/site-packages/jinja2/environment.py", line 1295, in render
    self.environment.handle_exception()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/usr/local/lib/python3.13/site-packages/jinja2/environment.py", line 942, in handle_exception
    raise rewrite_traceback_stack(source=source)
  File "<template>", line 1, in top-level template code
  File "/usr/local/lib/python3.13/site-packages/jinja2/filters.py", line 438, in do_sort
    return sorted(value, key=key_func, reverse=reverse)
TypeError: 'NoneType' object is not iterable

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/template/__init__.py", line 579, in async_render_to_info
    render_info._result = self.async_render(  # noqa: SLF001
                          ~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^
        variables, strict=strict, log_fn=log_fn, **kwargs
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "/usr/src/homeassistant/homeassistant/helpers/template/__init__.py", line 463, in async_render
    raise TemplateError(err) from err
homeassistant.exceptions.TemplateError: TypeError: 'NoneType' object is not iterable
2026-02-25 07:24:30.174 ERROR (MainThread) [homeassistant.components.template.template_entity] TemplateError('TypeError: 'NoneType' object is not iterable') while processing template 'Template<template=({% set uren = state_attr('sensor.dynamisch_goedkoopste_periode', 'duurste_na_eerste_goedkope_morgen') %} {% set duur = uren | sort(attribute='value', reverse=true) | list %} [ {% for uur in duur %}
  "{{ (uur.start | as_datetime).strftime('%H:%M') }} - €{{ '%.4f' | format(uur.value) }}"
  {% if not loop.last %}, {% endif %}
{% endfor %} ]) renders=4>' for attribute 'duurste_periode' in entity 'sensor.dynamisch_spread_indicatie_nom_morgen'

Hier gaat het op de april versie ook. Al moet ik zeggen dat er wat meer op handel is ingespeeld dan NOM. Ik had wat issues toen in naar @gielz zijn integratie aan het overstappen was. Wat ik aan het doen ben is al mijn automatiseringen nu rechtstreek in HA aan het zetten zodat ze allemaal in de automations.yaml komen. Ik heb HA in docker op een NAS draaien. Ik had een aparte automatiserings dir en ruim 3000 regels yaml in de config.

Tijd voor meer structuur. Ik heb van alles toen een backup gemaakt. De basis config.yaml gepakt en begonnen met packages. Op die manier behoud je alles bij elkaar. Overzicht!

Het werkt allemaal heerlijk. Zonder issues. De proxy ertussen voor 2 omvormers gaat ook goed. Soms moet je even de bezem pakken al zit je hier wellicht nu niet op te wachten.

Updaten hier is nu wat knip en plak werk heel oneerbiedig gezegd. Backup vooraf.

[sjnelle]

@Devke heb je toevallig je config ergens in git staan?

[YvonneVP]

gielz schreef op woensdag 25 februari 2026 @ 13:47:
[...]


Wat staat er ingevuld bij input_text.dynamisch_nordpool_sensor en heeft sensor.dynamisch_nordpool daadwerkelijk netjes alle tarieven in de attributen?

input_text.dynamisch_nordpool_sensor heeft als invoer bij 'Batterij Configuratie (Essentieel)' sensor.nordpool_kwh_nl_eur_3_10_0

In de attributen van sensor.dynamisch_nordpool staan ook netjes de tarieven.

[YvonneVP]

Pakhaas schreef op woensdag 25 februari 2026 @ 12:58:
[...]

Is dat ook nodig als je naast de Zendure P1 meter ook de Homewizard P1 meter hebt?

@Pakhaas Ik heb (nog) geen HomeWizard P1 meter, maar ik neem dat die wel een entiteit in HA zal krijgen/hebben als je daar een repository voor inleest in HA om verdere gegevens uit te kunnen lezen. Je zou hier anders even naar kunnen kijken. https://www.home-assistant.io/integrations/homewizard/
Er is een samenwerking tussen Homewizard en HA. Hier zou je dus ook even kunnen kijken. https://www.homewizard.co...orks-with-home-assistant/

[Pakhaas]

YvonneVP schreef op woensdag 25 februari 2026 @ 15:46:
[...]


Ik heb geen HomeWizard P1 meter, maar ik neem dat die wel een entiteit in HA zal krijgen/hebben als je daar een repository voor inleest in HA om verdere gegevens uit te kunnen lezen. Je zou hier anders even naar kunnen kijken. https://www.home-assistant.io/integrations/homewizard/
Er is een samenwerking tussen Homewizard en HA. Hier zou je dus ook even kunnen kijken. https://www.homewizard.co...orks-with-home-assistant/

Ja ik heb de HW P1 er al in, maar vroeg mij af of het ook wat toevoegt als ik de Zendure P1 er in heb, want die stuurt tenslotte de omvormer aan.

[Devke]

sjnelle schreef op woensdag 25 februari 2026 @ 14:58:
@Devke heb je toevallig je config ergens in git staan?

Dat is dit. Meer staat er niet in.

YAML:

# Laad standaard set van integraties. Niet verwijderen.
default_config:

# Laad frontend thema's uit de themes-map
frontend:
  themes: !include_dir_merge_named themes

automation: !include automations.yaml

script: !include scripts.yaml
scene: !include scenes.yaml

homeassistant:
  packages: !include_dir_named packages

De rest staat in een package. Wat lang om hier te droppen. Doe normaal niet zoveel met github. Kun je hier al wat mee? Of?

[ Voor 9% gewijzigd door Devke op 25-02-2026 15:51 ]

[Panzer_V]

NOOB vraag hier. Vandaag de Zendure 2400AC+ binnengekregen. Ik draai HA en heb op HA een mosquito broker draaien.

Wat moet ik precies doen om de Zendure via lokaal MQTT in HA beschikbaar te krijgen middels de officiële Zendure HACS integratie?

Ik zie dat ik in de zendure app bij de batterij onder instellingen iets van MQTT kan instellen. Moet ik daar op het IP van de batterij een nieuwe MQTT server opzetten?

Moet ik dan in HA hiernaar verbinden?

Dat is wat ik probeerde, maar er gebeurd dan niets.

Als ik die MQTT server instel in de Zendure app dan kan ik wel via http://192.168.178.x/properties/report iets inzien.

De batterij is al uit HEMS verwijderd.

Wie kan deze noob een stapje verder helpen?

[YvonneVP]

Pakhaas schreef op woensdag 25 februari 2026 @ 15:47:
[...]

Ja ik heb de HW P1 er al in, maar vroeg mij af of het ook wat toevoegt als ik de Zendure P1 er in heb, want die stuurt tenslotte de omvormer aan.

De HW P1 is compatible met Zendure. Je zou in HA kunnen kijken welke nauwkeuriger meet en dan kun je alsnog kijken welke je aan je batterij koppelt in de Zendure app of GielZ zijn mooie HA aansturing. De Zendure P1 update elke 5-6 seconden, ik weet dus niet of de HW P1 sneller is. De Zonneplan P1 meter is dus trager dan die 5-6 seconden, dus ik gebruik in HA voor die metingen de P1 meter van Powerbaas of wil die van Zendure gaan gebruiken. Ook daar zal ik dan even moeten kijken en vergelijken welke de snelste response doorgeeft.

[gielz]

YvonneVP schreef op woensdag 25 februari 2026 @ 15:20:
[...]

input_text.dynamisch_nordpool_sensor heeft als invoer bij 'Batterij Configuratie (Essentieel)' sensor.nordpool_kwh_nl_eur_3_10_0

In de attributen van sensor.dynamisch_nordpool staan ook netjes de tarieven.

[Afbeelding]

[Afbeelding]

[Afbeelding]

Ik zou je nordpool hacs sensor even goed configureren of direct switchen van energieleverancier met die prijzen.

[YvonneVP]

gielz schreef op woensdag 25 februari 2026 @ 16:00:
[...]


Ik zou je nordpool hacs sensor even goed configureren of direct switchen van energieleverancier met die prijzen.

Ik heb de prijzen ex. btw maar wel met de toeslag van 0,165 die Zonneplan berekend. En dan nog zijn de prijzen van Nordpool lager dan die van Zonneplan, waarschijnlijk omdat het ex. btw is. In de Zonneplan app heb ik de prijzen ook ex btw staan (incl. btw schuifje staat daar dus uit).

Bedoel je met 'Ik zou je nordpool hacs sensor even goed configureren' dat ik de instellingen even opnieuw moet invoeren? Want als ik over de rode verticale balkjes ga, toont ie wel de prijzen. Alleen zou ik verwachten dat bij een lagere prijs dit dus ook korter is, en bij hogere prijzen dus ook langer... en alles wat daar tussenin kan zitten qua prijzen.

[ Voor 5% gewijzigd door YvonneVP op 25-02-2026 16:25 ]

[Ben(V)]

Panzer_V schreef op woensdag 25 februari 2026 @ 15:52:
NOOB vraag hier. Vandaag de Zendure 2400AC+ binnengekregen. Ik draai HA en heb op HA een mosquito broker draaien.

Wat moet ik precies doen om de Zendure via lokaal MQTT in HA beschikbaar te krijgen middels de officiële Zendure HACS integratie?

Ik zie dat ik in de zendure app bij de batterij onder instellingen iets van MQTT kan instellen. Moet ik daar op het IP van de batterij een nieuwe MQTT server opzetten?

Moet ik dan in HA hiernaar verbinden?

Dat is wat ik probeerde, maar er gebeurd dan niets.

Als ik die MQTT server instel in de Zendure app dan kan ik wel via http://192.168.178.x/properties/report iets inzien.

De batterij is al uit HEMS verwijderd.

Wie kan deze noob een stapje verder helpen?

https://iotdomotica.nl/tu...tant-integration-tutorial

[Panzer_V]

Ben(V) schreef op woensdag 25 februari 2026 @ 16:28:
[...]

https://iotdomotica.nl/tu...tant-integration-tutorial

Die had ik dus al gevonden en geprobeerd. Hij voegt wel de manager toe maar dus niet de batterij. Ik krijg nergens dat ding te zien...

[Ben(V)]

Als het goed is krijg je in HA de "Zendure Manager", de "Solarflow 2400 AC+" en een of meer batterijen te zien.

Welke versie heb je geïnstalleerd en welke versie van HA draai je?

[gielz]

YvonneVP schreef op woensdag 25 februari 2026 @ 16:23:
[...]


Ik heb de prijzen ex. btw maar wel met de toeslag van 0,165 die Zonneplan berekend. En dan nog zijn de prijzen van Nordpool lager dan die van Zonneplan, waarschijnlijk omdat het ex. btw is. In de Zonneplan app heb ik de prijzen ook ex btw staan (incl. btw schuifje staat daar dus uit).

Bedoel je met 'Ik zou je nordpool hacs sensor even goed configureren' dat ik de instellingen even opnieuw moet invoeren? Want als ik over de rode verticale balkjes ga, toont ie wel de prijzen. Alleen zou ik verwachten dat bij een lagere prijs dit dus ook korter is, en bij hogere prijzen dus ook langer... en alles wat daar tussenin kan zitten qua prijzen.

De prijzen zouden rond de 0,3 moeten zijn maar niet 8 euro of meer per KWH. Zou even je sensor opnieuw goed instellen via; gielz in "Zendure producten in Home Assistant integreren deel 2"

let op, de post is wel met 2025 btw en toeslag.

[Panzer_V]

Ben(V) schreef op woensdag 25 februari 2026 @ 16:44:
Als het goed is krijg je in HA de "Zendure Manager", de "Solarflow 2400 AC+" en een of meer batterijen te zien.

Welke versie heb je geïnstalleerd en welke versie van HA draai je?

OMG

Ik ben duidelijk nog niet gewend aan de nieuwe indeling binnen HA waarbij in dit geval de batterij dus NIET in de Zendure integratie zichtbaar is, maar in de MQTT integratie zichtbaar wordt.

Sla mij maar lek.........

[hapklaar]

Panzer_V schreef op woensdag 25 februari 2026 @ 17:16:
[...]


OMG

Ik ben duidelijk nog niet gewend aan de nieuwe indeling binnen HA waarbij in dit geval de batterij dus NIET in de Zendure integratie zichtbaar is, maar in de MQTT integratie zichtbaar wordt.

Sla mij maar lek.........

Die horen gewoon in de Zendure integratie te staan

[Panzer_V]

hapklaar schreef op woensdag 25 februari 2026 @ 17:19:
[...]

Die horen gewoon in de Zendure integratie te staan
[Afbeelding]

Daar komen ze dus niet terecht. En ik kan de batterij ook niet bedienen via de manager. Raar is dit....

[Timrob]

Ben nog niet zolang bezig met HA en Zendure accu's. Gebruik nu de Gielz automatisering van April. Zie er goed uit. Wel zie ik bij het schermpje Relais schakelingen soms heel veel schakelingen, bv 22/2 71 schakelingen, 23/2 zit ik op 391 en op 24/2 op 512 schakelingen. Is dat slecht? of heb ik iets niet goed staan?

[HiBe]

is er een mogelijkheid om de Zendure batterij standaard in NOM mode te draaien en af en toe via de zenSDK in te grijpen (bijv. ontladen uitzetten als auto lader aan gaat)?

verder ben ik benieuwd naar de API parameter "gridReverse", wat doet deze?

[Panzer_V]

Goed....ik heb het opgegeven om de 'officiele' integratie te gebruiken.

@gielz , mag ik jou danken?!

Ik heb jouw integratie gebruikt en het werkt heerlijk! Had het binnen een uur up and running. Mega dank en ik ga later deze week jou een koffie kopen. Nu eerst even bijkomen van deze HA-marathon.

[YvonneVP]

gielz schreef op woensdag 25 februari 2026 @ 16:55:
[...]


De prijzen zouden rond de 0,3 moeten zijn maar niet 8 euro of meer per KWH. Zou even je sensor opnieuw goed instellen via; gielz in "Zendure producten in Home Assistant integreren deel 2"

let op, de post is wel met 2025 btw en toeslag.

Ik had 'Prijs in centen' aangevinkt toen ik Nordpool ingesteld heb na installatie. Als je dus €12,569 ziet staan is het dus €0,12569 in plaats van €12,569. Het is wel een beetje verwarrend omdat ie bij Dynamisch Nordpool dus niet laat zien dat het om 'prijs in centen' gaat, maar bij sensor.nordpool_kwh_nl_eur_3_10_0 wel.

Ik heb je instructies in ieder geval even opgevolgd, en de sensor.nordpool_kwh_nl_eur_3_10_0 opnieuw aangemaakt/ingesteld. En toen was het helemaal zoals het zijn moet. Ik heb nu ook de prijzen maar incl btw etc gedaan. In de Zonneplan app zet ik het vinkje voor energiebelasting dan ook wel gewoon aan. Ik moet dan wel weer even aan de prijzen wennen.

[JSven]

HiBe schreef op woensdag 25 februari 2026 @ 18:45:
is er een mogelijkheid om de Zendure batterij standaard in NOM mode te draaien en af en toe via de zenSDK in te grijpen (bijv. ontladen uitzetten als auto lader aan gaat)?

verder ben ik benieuwd naar de API parameter "gridReverse", wat doet deze?

Ja dat is zeker mogelijk. Je kan een aparte automation aanmaken in HA die dan de modus van de manager/batterij aanpast naar standby of alleen slim laden. Voor de Gielz integratie is dat voor volgende entiteit
input_select.zendure_2400_ac_modus_selecteren

Als je stop met de auto te laden kan je de modus terug zetten naar wat je wenst (NOM, dynamisch, ...)

[ben]

Panzer_V schreef op woensdag 25 februari 2026 @ 17:40:
[...]


Daar komen ze dus niet terecht. En ik kan de batterij ook niet bedienen via de manager. Raar is dit....

Ik had hier hetzelfde probleem, maar met de beta versie 1.2.6 werden de batterijen en de AC2400+ wel gevonden ...

[Ben(V)]

Klopt, pas in die versie zijn de nieuwe modellen toegevoegd.

[HiBe]

JSven schreef op woensdag 25 februari 2026 @ 19:33:
[...]


Ja dat is zeker mogelijk. Je kan een aparte automation aanmaken in HA die dan de modus van de manager/batterij aanpast naar standby of alleen slim laden. Voor de Gielz integratie is dat voor volgende entiteit
input_select.zendure_2400_ac_modus_selecteren

Als je stop met de auto te laden kan je de modus terug zetten naar wat je wenst (NOM, dynamisch, ...)

Wat is de modus setting in de ZenSDK API?

[sjnelle]

YvonneVP schreef op woensdag 25 februari 2026 @ 16:23:
[...]


Ik heb de prijzen ex. btw maar wel met de toeslag van 0,165 die Zonneplan berekend. En dan nog zijn de prijzen van Nordpool lager dan die van Zonneplan, waarschijnlijk omdat het ex. btw is. In de Zonneplan app heb ik de prijzen ook ex btw staan (incl. btw schuifje staat daar dus uit).

Hier loop ik ook vast ik heb zoiets maar dit komt ook niet overeen. Heeft denk ik ook te maken met de kwartier prijzen.

code:

- platform: nordpool
    region: "NL"
    currency: "EUR"
    VAT: False
    precision: 3
    low_price_cutoff: 0.9
    price_in_cents: false
    price_type: kWh
    additional_costs: >
      {% set VAT = 0.21 %}
      {% set tax_kWh = 0.1108 %}
      {% set opslag = 0.02200 %}
      {{ (current_price * VAT ) + (tax_kWh + opslag) * (1 + VAT)|float }}

[Bakko]

Onderstaande werkt nu goed voor mij, toevallig ook net mee bezig omdat ik het nog helemaal niet had aangepast voor de bedragen van 2026. Bij Frank staat de opslag in het contract dan weer inclusief BTW, dus de formule iets aangepast. Gielz's code achter "sensor Dynamisch Nordpool" zorgt er dan weer voor dat kwartierprijzen naar uurprijzen worden omgerekend.

code:

- platform: nordpool
    region: "NL"
    currency: "EUR"
    VAT: False
    precision: 3
    low_price_cutoff: 0.9
    price_in_cents: false
    price_type: kWh
    additional_costs: >
      {% set VAT = 0.21 %}
      {% set belasting = states('input_number.energiebelasting') | float(0) %}
      {% set opslag = states('input_number.opslag_energieleverancier') | float(0) %}
      {{ (current_price * VAT) + opslag +  belasting * (1 + VAT) }}

[YvonneVP]

sjnelle schreef op woensdag 25 februari 2026 @ 21:29:
[...]


Hier loop ik ook vast ik heb zoiets maar dit komt ook niet overeen. Heeft denk ik ook te maken met de kwartier prijzen.

code:

- platform: nordpool
    region: "NL"
    currency: "EUR"
    VAT: False
    precision: 3
    low_price_cutoff: 0.9
    price_in_cents: false
    price_type: kWh
    additional_costs: >
      {% set VAT = 0.21 %}
      {% set tax_kWh = 0.1108 %}
      {% set opslag = 0.02200 %}
      {{ (current_price * VAT ) + (tax_kWh + opslag) * (1 + VAT)|float }}

Zou goed kunnen. In de Zendure app was het ook flink rekenen om de tarieven goed te krijgen, ondanks dat Zonneplan als leverancier wordt ondersteund. In de Zendure app hanteren ze ook 15 minuten prijzen, terwijl Zonneplan het gemiddelde van 4x15 minuten hanteert. De berekening an sich om het gemiddelde van 4x15 minuten te krijgen, incl. de opslag die de energieleverancier berekend, is zo moeilijk niet. Alleen krijg je in de Zendure app dus niet de mogelijkheid om in te stellen of je 15 minuten tarieven wilt gebruiken of uurtarieven. Verder mis ik in de Zendure app nog wel meer mogelijkheden om echt goed controle te hebben over de aansturing van het systeem, en ik was dus als een kind zo blij toen ik de HA oplossing van GielZ tegen kwam bij Github. Nu moet ik alleen nog uitzoeken hoe alles exact werkt, en wat alles betekend. Er staan begrippen tussen waar ik nog nooit van gehoord heb, en dus ook niet weet wat ze doen of inhouden. Maar, ik heb nog tot januari 2027 om dat allemaal uit te vogelen.

[Bakko]

sjnelle schreef op woensdag 25 februari 2026 @ 21:29:
[...]


Hier loop ik ook vast ik heb zoiets maar dit komt ook niet overeen. Heeft denk ik ook te maken met de kwartier prijzen.

code:

additional_costs: >
      {% set VAT = 0.21 %}
      {% set tax_kWh = 0.1108 %}
      {% set opslag = 0.02200 %}
      {{ (current_price * VAT ) + (tax_kWh + opslag) * (1 + VAT)|float }}

Ik zie hier al iets fout gaan, de energiebelasting dit jaar is namelijk 0,09161 euro/kwh ex BTW. Jij hebt hem daar al incl. BTW en dan in de formule gaat er nog een keer BTW overheen. Kijk het is al absurd dat je BTW moet betalen over een belasting, maar gelukkig is het niet zo erg

[YvonneVP]

Bakko schreef op woensdag 25 februari 2026 @ 21:53:
Onderstaande werkt nu goed voor mij, toevallig ook net mee bezig omdat ik het nog helemaal niet had aangepast voor de bedragen van 2026. Bij Frank staat de opslag in het contract dan weer inclusief BTW, dus de formule iets aangepast. Gielz's code achter "sensor Dynamisch Nordpool" zorgt er dan weer voor dat kwartierprijzen naar uurprijzen worden omgerekend.

code:

- platform: nordpool
    region: "NL"
    currency: "EUR"
    VAT: False
    precision: 3
    low_price_cutoff: 0.9
    price_in_cents: false
    price_type: kWh
    additional_costs: >
      {% set VAT = 0.21 %}
      {% set belasting = states('input_number.energiebelasting') | float(0) %}
      {% set opslag = states('input_number.opslag_energieleverancier') | float(0) %}
      {{ (current_price * VAT) + opslag +  belasting * (1 + VAT) }}

Als je een incl. btw bedrag hebt, dan is het nog te doen om het terug te rekenen naar ex. btw.
Heb je de code zelf aangepast, of is dit een stukje wat in de volgende release van GielZ zit?

[wesley2004]

Heb alles voor elkaar gekregen. Ook met de ecotracker.
Alleen nu ik jouw programma heb lopen blijft hij naar -700w ontladen gaan. Ik heb NOM gekozen.
Of moet hij eerst even alles zelf instellen?

gielz schreef op dinsdag 24 februari 2026 @ 19:33:
[...]


Ik heb deze zelf niet maar is dat niet gewoon deze;
https://github.com/Selbst...ain/Ecotracker%20Code.txt

Zou eerst even kijken of je hier reply op krijgt; http://[IP-Everhome]/v1/json en zou scan interval op 1s zetten.

[wmc]

Sinds een paar weken loop ik tegen het probleem aan dat de Hyper 2000 verbinding verliest. In de Zendure app lijkt hij nog aan het laden of ontladen te zijn, maar heb ik geen controle, met de Fireson integratie kan ik niks meer wijzigen. De enige oplossing is batterij fysiek uit het stopcontact halen, even wachten en weer aansluiten. Heeft iemand ervaring met dit probleem en hoe dit op te lossen?

[gielz]

wesley2004 schreef op woensdag 25 februari 2026 @ 22:40:
Heb alles voor elkaar gekregen. Ook met de ecotracker.
Alleen nu ik jouw programma heb lopen blijft hij naar -700w ontladen gaan. Ik heb NOM gekozen.
Of moet hij eerst even alles zelf instellen?


[...]

DM mij anders even je instellingen, versie die je gebruikt en het logboek. Waarschijnlijk is de fout dan zo gevonden.

De aansturing gaat nooit vanzelf -700 watt ontladen.

[gielz]

Timrob schreef op woensdag 25 februari 2026 @ 17:48:
Ben nog niet zolang bezig met HA en Zendure accu's. Gebruik nu de Gielz automatisering van April. Zie er goed uit. Wel zie ik bij het schermpje Relais schakelingen soms heel veel schakelingen, bv 22/2 71 schakelingen, 23/2 zit ik op 391 en op 24/2 op 512 schakelingen. Is dat slecht? of heb ik iets niet goed staan?

Dit zou onder 100 moeten liggen en in uitzonderlijke gevallen iets hoger. Je zou even je gegevens moeten bekijken van 24/2. De meeste schakelingen ontstaan bij zonsopgang en ondergang en wanneer je constant in het minimale bereik zit. Om dat te voorkomen heb ik hier bijvoorbeeld het "opladen starten bij" een stuk lager staan dan -100 watt.

Er zijn ook een aantal gebruikers die laden blokkeren net na zonsopkomst en voor zonderondergang en de rest van de tijd NOM. (uitgesteld laden)

- Hoe ziet je P1 vermogen er uit, is dit alleen maar golven of een strakke lijn met NOM? (screenshot)
- Wat zegt het logboek? (screenshot)
- Wat zijn je exacte instellingen van de sturing? (screenshot)
- Levert je P1 elke seconden data?

[Pakhaas]

Om dat te voorkomen heb ik hier bijvoorbeeld het "opladen starten bij" een stuk lager staan dan -100 watt.

@gielz -100w is genoeg, of nog lager?

[Pakhaas]

Soc calibratie handmatig?
Is het mogelijk om met de Gielz integratie het automatisch calibreren van de soc (batterij gaat naar 100% laden) uit te zetten en handmatig te doen?

Wij gaan pas in april van 1x35A naar 3x25A en ben bang dat als de auto met een domme lader aan het laden is en 2 omvormers gaan laden om op 100% te komen dat we dan over die 35A gaan met nog wat andere gebruikers. De batterijen gaan eerst NOM draaien, zo lang we nog op 1 fase zitten.

Ik wil dit best proberen te regelen met een automation in Chatgpt, maar als het al in Gielz zit is dat niet nodig.

Maximum ontlading batterij instellen bij laden EV
Het 2e wat ik wil inregelen is dat als de EV aan het laden is en de batterijen is door ontlading gezakt naar 4kwh, dat hij dan beide omvormers in standby doet totdat het laden van de EV is gestopt. De EV lader stuur ik aan met een Tapo slimme stekker die ik in HA heb gezet. Dus met HA kan je zien of de auto aan het laden is of niet.

Ook dit wil ik proberen met ChatGPT, bouw je dan een nieuwe automation die de Gielz overrulled ten tijde van EV laden?

Ik ga de @gielz integratie aasturen met de @gast777 proxy

[ Voor 55% gewijzigd door Pakhaas op 26-02-2026 08:33 ]

[gielz]

Pakhaas schreef op donderdag 26 februari 2026 @ 08:13:
[...]


@gielz -100w is genoeg, of nog lager?

Zelf hanteer ik hier -300 maar ik zie ook gebruikers met -1000. Hier zou je echt even moeten kijken voor jezelf wat handig is aangezien het ligt aan het aantal zonnepanelen. Om 08:00 kan ik hier al 1200 watt opwek hebben.

[gielz]

Pakhaas schreef op donderdag 26 februari 2026 @ 08:19:
Soc calibratie handmatig?
Is het mogelijk om met de Gielz integratie het automatisch calibreren van de soc (batterij gaat naar 100% laden) uit te zetten en handmatig te doen?

Wij gaan pas in april van 1x35A naar 3x25A en ben bang dat als de auto met een domme lader aan het laden is en 2 omvormers gaan laden om op 100% te komen dat we dan over die 35A gaan met nog wat andere gebruikers. De batterijen gaan eerst NOM draaien, zo lang we nog op 1 fase zitten.

Ik wil dit best proberen te regelen met een automation in Chatgpt, maar als het al in Gielz zit is dat niet nodig.

Het kalibreren van de batterij wat 1 maand na de laatste keer op 100% start zit in de BMS zelf. Hier is niet een vinkje voor of iets dergelijks. Je zou dit zelf uiteraard kunnen bepalen door 1x in de zoveel tijd gecontroleerd naar 100% te laden. Wat ik hier zie is dat dit kalibreren alleen speelt tussen December en Februari.

[gielz]

Pakhaas schreef op donderdag 26 februari 2026 @ 08:19:
Maximum ontlading batterij instellen bij laden EV
Het 2e wat ik wil inregelen is dat als de EV aan het laden is en de batterijen is door ontlading gezakt naar 4kwh, dat hij dan beide omvormers in standby doet totdat het laden van de EV is gestopt. De EV lader stuur ik aan met een Tapo slimme stekker die ik in HA heb gezet. Dus met HA kan je zien of de auto aan het laden is of niet.

Ook dit wil ik proberen met ChatGPT, bouw je dan een nieuwe automation die de Gielz overrulled ten tijde van EV laden?

Ik ga de @gielz integratie aasturen met de @gast777 proxy

Wat je moet maken is een automatisering die input_select.zendure_2400_ac_modus_selecteren naar de juiste modus zet tijdens het EV laden en dan weer naar een anderen modus wanneer dit klaar is bijvoorbeeld;

NOM > Auto gaat laden > Alleen slim opladen > Auto is klaar > NOM

De gielz kun je dus altijd aan laten staan en deze zal ook nooit zelf de modus aanpassen.

[Pakhaas]

gielz schreef op donderdag 26 februari 2026 @ 09:11:
[...]


Wat je moet maken is een automatisering die input_select.zendure_2400_ac_modus_selecteren naar de juiste modus zet tijdens het EV laden en dan weer naar een anderen modus wanneer dit klaar is bijvoorbeeld;

NOM > Auto gaat laden > Alleen slim opladen > Auto is klaar > NOM

De gielz kun je dus altijd aan laten staan en deze zal ook nooit zelf de modus aanpassen.

Top en die code zet ik dan in dezelfde automations.yaml en dan gewoon onderaan? of maak ik daar een nieuwe file voor aan in Studio Code Server?

Is het dan niet NOM > auto gaat laden > standby > auto is klaar > NOM?

Kan ik daarbij ook instellen dat hij bovenstaande actie alleen doet als de batterijen gezamelijk 4kwh of lager zijn?

[ Voor 13% gewijzigd door Pakhaas op 26-02-2026 09:19 ]

[gielz]

Pakhaas schreef op donderdag 26 februari 2026 @ 09:17:
[...]

Top en die code zet ik dan in dezelfde automations.yaml en dan gewoon onderaan? of maak ik daar een nieuwe file voor aan in Studio Code Server?

Je hebt als het goed is een package of een configuration.yaml van de gielz in gebruik en daarbij een automation via de gui toegevoegd (in HA zelf). Je kunt dus via de gui zelf een automation toevoegen en dus niet een los yaml bestandje (wat GPT je wel aanraad want hij is een beetje dom).

Het aller grootste voordeel is dat als je dit via de gui doet je gewoon wat makkelijker alles kunt testen. Gewoon lekker freubelen en als je geen gewenst resultaat hebt opnieuw beginnen. Zie het als lego.

[gielz]

wmc schreef op donderdag 26 februari 2026 @ 07:42:
Sinds een paar weken loop ik tegen het probleem aan dat de Hyper 2000 verbinding verliest. In de Zendure app lijkt hij nog aan het laden of ontladen te zijn, maar heb ik geen controle, met de Fireson integratie kan ik niks meer wijzigen. De enige oplossing is batterij fysiek uit het stopcontact halen, even wachten en weer aansluiten. Heeft iemand ervaring met dit probleem en hoe dit op te lossen?

Ik zou hiervoor even een issue inschieten bij de github van de zendure HA met uiteraard logs. @Taro had dit in het begin regelmatig maar uiteindelijk werkten dit wel zonder problemen geloof ik.

[Bakko]

YvonneVP schreef op woensdag 25 februari 2026 @ 22:11:
[...]

Als je een incl. btw bedrag hebt, dan is het nog te doen om het terug te rekenen naar ex. btw.
Heb je de code zelf aangepast, of is dit een stukje wat in de volgende release van GielZ zit?

Ik heb de configuratie van de nordpool sensor wel gebaseerd op wat Gielz hier deelde maar dat is niet onderdeel van zijn pakket voor de aansturing. Vervolgens input number helper gemaakt voor de verschillende kosten, zodat ik het in de UI kan aanpassen, ook zonder reboot. En dan de formule aangepast omdat ik de opslag inclusief btw invul. In Home Assistant bij Developer->Template kan je dit allemaal plakken en kijken of het werkt (wel even iets invullen voor current_price. AI kan je ook wel helpen met de templates, ik vind de taal die gebruikt wordt (Jinja) best verwarrend om zelf te schrijven, een fout is zo gemaakt.

[paul123]

Gisteren zijn bij mij de 2400 AC+ en de P1 meter bezorgd, de losse batterij was er afgelopen maandag.

Ik heb een oude DSMR 4 slimme meter en had wel verwacht dat dat niet optimaal zou zijn, maar het werkt echt heel slecht. Als de batterij niet vol is staat ie continu te pendelen tussen laden en ontladen waarbij het vermogen in beide richtingen steeds hoger wordt. De batterij reageert op de vertraagde data vanuit de meter en ziet dan z'n eigen consumptie of productie als consumptie/productie van het huis. Dit is zo in ZENKI AI mode, Auto mode en Smart Meter mode.

Ik heb een Enphase "metered" gateway, deze rapporteert wel elke seconde via de locale API, ik ga maar eens kijken of ik die via Home Assistant kan inzetten om de batterij aan te sturen. Anders zal ik een Shelly o.i.d. moeten aanschaffen, wat een beetje jammer is als de slimme meter toch een keer wordt vervangen (de vraag is alleen wanneer). Zijn er anderen die de Enphase gateway hiervoor gebruiken?

Update: ik heb het inmiddels aan de praat met de Gielz setup en deze add-on om de Enphase gateway uit te lezen: https://github.com/vk2him/Enphase-Envoy-mqtt-json (ik had al een mqtt broker draaien voor mijn CV ketel). De "envoy_mqtt_consumption" sensor heb ik nu als "Afwijkende P1 Sensor" geconfigureerd en dat werkt prima. Ik heb alleen het idee dat er een kleine constante afwijking is t.o.v. wat er daadwerkelijk door de meter gaat, dat ga ik nog even proberen te monitoren en kan dan evt. nog een correctie toevoegen.

[ Voor 24% gewijzigd door paul123 op 27-02-2026 13:04 ]

[YvonneVP]

paul123 schreef op donderdag 26 februari 2026 @ 18:38:
Gisteren zijn bij mij de 2400 AC+ en de P1 meter bezorgd, de losse batterij was er afgelopen maandag.

Ik heb een oude DSMR 4 slimme meter en had wel verwacht dat dat niet optimaal zou zijn, maar het werkt echt heel slecht. Als de batterij niet vol is staat ie continu te pendelen tussen laden en ontladen waarbij het vermogen in beide richtingen steeds hoger wordt. De batterij reageert op de vertraagde data vanuit de meter en ziet dan z'n eigen consumptie of productie als consumptie/productie van het huis. Dit is zo in ZENKI AI mode, Auto mode en Smart Meter mode.

Ik heb een Enphase "metered" gateway, deze rapporteert wel elke seconde via de locale API, ik ga maar eens kijken of ik die via Home Assistant kan inzetten om de batterij aan te sturen. Anders zal ik een Shelly o.i.d. moeten aanschaffen, wat een beetje jammer is als de slimme meter toch een keer wordt vervangen (de vraag is alleen wanneer). Zijn er anderen die de Enphase gateway hiervoor gebruiken?

Een Shelly is naar mijn mening an sich sowieso geen slecht idee. Als je een 1-fase aansluiting hebt vallen de kosten nog redelijk mee. Ik heb hier momenteel meerdere P1 meters (4 in totaal), waar ik dus de reactietijd even van in de gaten houdt. 1 kan ik sowieso al schrappen, dat is die van mijn energieleverancier. Die is het traagst van allemaal. De Zendure P1 meter reageert net iets sneller dan de Homewizard P1. Het is maar een paar milliseconden verschil, dus eigenlijk verwaarloosbaar. De Powerbaas reageert een paar kleine seconden trager dan de Zendure P1 en de Homewizard P1. In het dashboard van Gielz heb ik nu de Homewizard P1 meter geïntegreerd, maar kan die makkelijk omzetten naar de Zendure P1 meter.

In de meterkast heb ik ook nog een Shelly 3EM Pro, maar dan aangesloten op een 1-fase systeem in plaats van 3-fasen. Ik had, achteraf gezien, ook voor de goedkopere 1 fase variant kunnen gaan. Mijn batterij heb ik op een aparte groep laten zetten. Met de Shelly Pro 3EM monitor ik het verbruik op de groepen die ik heb. Dit wil ik nog gaan veranderen door de CT klemmen anders in te delen. Dan komt er een CT klem op de aansluiting naar mijn batterij, een naar mijn aansluiting van de zonnepanelen, en 1 op het totaalverbruik, dus op de 1-fase aansluiting. Ik denk/hoop dat het dan beter en inzichtelijker wordt, en dat ik dan de Shelly eventueel kan koppelen aan Gielz zijn Zendure aansturing oplossing. En anders kan ik de Shelly apart monitoren en de data eventueel ook nog in een grafiek zetten en zelf als card toe kunnen voegen aan het dashboard wat ik nu heb met Gielz zijn oplossing. Ik zou, voor zover ik heb begrepen en gelezen, voor de zonnepanelen echter een andere/aparte CT klem moeten aanschaffen, een van 50A ipn 120A. Voor mijn zonnepanelen set-up zou dat voldoende moeten zijn. Die past echter wel op de Shelly Pro 3EM vanwege het stekkertje die Shelly op deze meter gebruikt.

[Pakhaas]

Omdat morgen overdag de prijzen 0 zijn, geeft hij bij de spread een uitroepteken. Is dit een soort van bug, of moet ik wat anders instellen?

[Fremske]

paul123 schreef op donderdag 26 februari 2026 @ 18:38:
Gisteren zijn bij mij de 2400 AC+ en de P1 meter bezorgd, de losse batterij was er afgelopen maandag.

Ik heb een oude DSMR 4 slimme meter en had wel verwacht dat dat niet optimaal zou zijn, maar het werkt echt heel slecht. Als de batterij niet vol is staat ie continu te pendelen tussen laden en ontladen waarbij het vermogen in beide richtingen steeds hoger wordt. De batterij reageert op de vertraagde data vanuit de meter en ziet dan z'n eigen consumptie of productie als consumptie/productie van het huis. Dit is zo in ZENKI AI mode, Auto mode en Smart Meter mode.

Ik heb een Enphase "metered" gateway, deze rapporteert wel elke seconde via de locale API, ik ga maar eens kijken of ik die via Home Assistant kan inzetten om de batterij aan te sturen. Anders zal ik een Shelly o.i.d. moeten aanschaffen, wat een beetje jammer is als de slimme meter toch een keer wordt vervangen (de vraag is alleen wanneer). Zijn er anderen die de Enphase gateway hiervoor gebruiken?

Update: ik heb het inmiddels aan de praat met de Gielz setup en deze add-on om de Enphase gateway uit te lezen: https://github.com/vk2him/Enphase-Envoy-mqtt-json (ik had al een mqtt broker draaien voor mijn CV ketel). De "envoy_mqtt_consumption" sensor heb ik nu als "Afwijkende P1 Sensor" geconfigureerd en dat werkt prima. Ik heb alleen het idee dat er een kleine constante afwijking is t.o.v. wat er daadwerkelijk door de meter gaat, dat ga ik nog even proberen te monitoren en kan dan evt. nog een correctie toevoegen.

Ik heb precies hetzelfde probleem als Paul.
Mijn slimme meter is een DSMR 4 GRPS, dus om 10 seconde wordt de data gepushed naar mijn Home Assistant Green via de DSMR Smart Meter - Home Assistant integratie. Deze alternatieve P1 meter is dan ook opgegeven voor de Gielz integratie.

Mijn 2400AC+ gaat ook alle kanten op, gaat ontladen bij hoge opwerk en opladen als er verbruik is. Nu had ik voor de @gielz integratie die van Fireson (officiële van Zendure) in gebruik en die leek veel constanter te sturen op productie en consumptie en stelde de batterij daar met enige vertraging wel prima op af. Dus ik weet niet zo goed waarom de afwijking zo veel groter is bij @gielz ?

[Ben(V)]

YvonneVP schreef op vrijdag 27 februari 2026 @ 13:17:
[...]


Een Shelly is naar mijn mening an sich sowieso geen slecht idee. Als je een 1-fase aansluiting hebt vallen de kosten nog redelijk mee. Ik heb hier momenteel meerdere P1 meters (4 in totaal), waar ik dus de reactietijd even van in de gaten houdt. 1 kan ik sowieso al schrappen, dat is die van mijn energieleverancier. Die is het traagst van allemaal. De Zendure P1 meter reageert net iets sneller dan de Homewizard P1. Het is maar een paar milliseconden verschil, dus eigenlijk verwaarloosbaar. De Powerbaas reageert een paar kleine seconden trager dan de Zendure P1 en de Homewizard P1. In het dashboard van Gielz heb ik nu de Homewizard P1 meter geïntegreerd, maar kan die makkelijk omzetten naar de Zendure P1 meter.

In de meterkast heb ik ook nog een Shelly 3EM Pro, maar dan aangesloten op een 1-fase systeem in plaats van 3-fasen. Ik had, achteraf gezien, ook voor de goedkopere 1 fase variant kunnen gaan. Mijn batterij heb ik op een aparte groep laten zetten. Met de Shelly Pro 3EM monitor ik het verbruik op de groepen die ik heb. Dit wil ik nog gaan veranderen door de CT klemmen anders in te delen. Dan komt er een CT klem op de aansluiting naar mijn batterij, een naar mijn aansluiting van de zonnepanelen, en 1 op het totaalverbruik, dus op de 1-fase aansluiting. Ik denk/hoop dat het dan beter en inzichtelijker wordt, en dat ik dan de Shelly eventueel kan koppelen aan Gielz zijn Zendure aansturing oplossing. En anders kan ik de Shelly apart monitoren en de data eventueel ook nog in een grafiek zetten en zelf als card toe kunnen voegen aan het dashboard wat ik nu heb met Gielz zijn oplossing. Ik zou, voor zover ik heb begrepen en gelezen, voor de zonnepanelen echter een andere/aparte CT klem moeten aanschaffen, een van 50A ipn 120A. Voor mijn zonnepanelen set-up zou dat voldoende moeten zijn. Die past echter wel op de Shelly Pro 3EM vanwege het stekkertje die Shelly op deze meter gebruikt.

Geen idee hoe je deze conclusie trekt maar de Zendure P1, de homewizard P1 en de powerbaas P1 betrekken hun data allemaal uit de P1 uitgang van je energie meter en zijn dus allemaal maximaal even snel.
Dat wil zeggen als je een DSMR 4 meter hebt is dat 1 meting per 2,5 sec en bij een DSMR 5 meter 1 meting per sec.
Alleen meters zoals een Shelly die zelf met klemmen meten kunnen sneller zijn.

[gielz]

Fremske schreef op vrijdag 27 februari 2026 @ 15:17:
[...]

Ik heb precies hetzelfde probleem als Paul.
Mijn slimme meter is een DSMR 4 GRPS, dus om 10 seconde wordt de data gepushed naar mijn Home Assistant Green via de DSMR Smart Meter - Home Assistant integratie. Deze alternatieve P1 meter is dan ook opgegeven voor de Gielz integratie.

Mijn 2400AC+ gaat ook alle kanten op, gaat ontladen bij hoge opwerk en opladen als er verbruik is. Nu had ik voor de @gielz integratie die van Fireson (officiële van Zendure) in gebruik en die leek veel constanter te sturen op productie en consumptie en stelde de batterij daar met enige vertraging wel prima op af. Dus ik weet niet zo goed waarom de afwijking zo veel groter is bij @gielz ?

De gielz is gemaakt en geoptimaliseerd voor een moderne slimme meter met een 1 seconden interval. De trigger is hier ook niet bij verandering van de P1 maar een vast interval.

Uiteraard is dit interval gewoon aanpasbaar, voor een 1 seconden P1 is dit 5 seconden. De batterij heeft zelf 4,5 seconden nodig om goed te reageren en de meeste gevallen. Denk dat je bij een 10 seconden P1 zomaar op 15 seconden of hoger moet gaan zitten.

[gielz]

Pakhaas schreef op vrijdag 27 februari 2026 @ 15:16:
Omdat morgen overdag de prijzen 0 zijn, geeft hij bij de spread een uitroepteken. Is dit een soort van bug, of moet ik wat anders instellen?
[Afbeelding]

Er worden geen min tarieven verwacht omdat je altijd de BTW hebt. Ik zou je Nordpool HACS sensor even opnieuw configureren dat hij de werkelijke prijs toont en niet alleen de inkoop.

[Pakhaas]

Ik heb de Nordpool configuratie opnieuw gemaakt en de BTW aangevinkt. Ik zie nu wel de spread, maar in de grafiek geeft hij nog wel de 0,00 bedragen aan. Ik mis ook de EB.

[gielz]

Pakhaas schreef op vrijdag 27 februari 2026 @ 16:05:
Ik heb de Nordpool configuratie opnieuw gemaakt en de BTW aangevinkt. Ik zie nu wel de spread, maar in de grafiek geeft hij nog wel de 0,00 bedragen aan. Ik mis ook de EB.

Die vinkjes doen weinig, ik zou deze volgen; https://gathering.tweakers.net/forum/view_message/83698778

Let op: dit is een post uit 2025 met de 2025 tarieven.

[YvonneVP]

Pakhaas schreef op vrijdag 27 februari 2026 @ 15:16:
Omdat morgen overdag de prijzen 0 zijn, geeft hij bij de spread een uitroepteken. Is dit een soort van bug, of moet ik wat anders instellen?
[Afbeelding]

Staat het uitroepteken er ook als je de prijzen niet per 15 minuten ingesteld hebt? Staat er misschien in het logboek iets vermeld? De prijzen heb je ingesteld incl. kosten, btw, belastingen etc? Bij mij staat er geen uitroepteken bij 'spread'. Misschien HA opnieuw starten. Of, en dat wil ook wel eens gebeuren in HA... dat een entiteit er 2 keer in staat. Dat zou je dan even moeten nakijken of dat het geval is, mocht je dat nog niet gedaan hebben.

[Pakhaas]

gielz schreef op vrijdag 27 februari 2026 @ 16:14:
[...]


Die vinkjes doen weinig, ik zou deze volgen; https://gathering.tweakers.net/forum/view_message/83698778

Let op: dit is een post uit 2025 met de 2025 tarieven.

[Pakhaas]

YvonneVP schreef op vrijdag 27 februari 2026 @ 16:19:
[...]


Staat het uitroepteken er ook als je de prijzen niet per 15 minuten ingesteld hebt? Staat er misschien in het logboek iets vermeld? De prijzen heb je ingesteld incl. kosten, btw, belastingen etc? Bij mij staat er geen uitroepteken bij 'spread'. Misschien HA opnieuw starten. Of, en dat wil ook wel eens gebeuren in HA... dat een entiteit er 2 keer in staat. Dat zou je dan even moeten nakijken of dat het geval is, mocht je dat nog niet gedaan hebben.

Nee ik heb de prijzen ex btw en eb. Daar gaat het mis. Ik ga vanavond even prutsen met die link van Gielz. Dank!

[Fremske]

gielz schreef op vrijdag 27 februari 2026 @ 15:56:
[...]


De gielz is gemaakt en geoptimaliseerd voor een moderne slimme meter met een 1 seconden interval. De trigger is hier ook niet bij verandering van de P1 maar een vast interval.

Uiteraard is dit interval gewoon aanpasbaar, voor een 1 seconden P1 is dit 5 seconden. De batterij heeft zelf 4,5 seconden nodig om goed te reageren en de meeste gevallen. Denk dat je bij een 10 seconden P1 zomaar op 15 seconden of hoger moet gaan zitten.

@gielz hoe kan ik de interval dan aanpassen in Home Assistant met jouw integratie naar 15 seconden?

[gielz]

Fremske schreef op vrijdag 27 februari 2026 @ 17:22:
[...]

@gielz hoe kan ik de interval dan aanpassen in Home Assistant met jouw integratie naar 15 seconden?

Je kunt de automatisering open klikken en dan betreft het meteen de eerste regel. Ben benieuwd wat de uitkomst is als je die gaat tweaken.

[gielz]

Voor de gene die de April testversie draaien van de gielz met het nieuwe plug-n-play dashboard is er een update voor het dashboard; https://github.com/Gielz1...ril-2026-Update/Dashboard

- Helpteksten zijn toegevoegd per geselecteerde modus
- Helpteksten verbeterd
- Releasenotes direct in te zien binnen HA via het configuratietabblad onder het kopje versiebeheer.
- Relais schakelingen in het verleden werden foutief weergegeven met veel te hoge aantallen wegens het foutief ophalen uit de statistics (LTS). Ook de eigen grafiek van Home Assistant haalde de data foutief op. De aantallen van vandaag waren wel altijd juist.

Ook is er een kleine update voor de Package / configuration.yaml
- Spread indicaties - Bij het herstarten van Home Assistant gaven de sensoren een tijdelijke foutmelding tijdens de start.

*Ter vergelijking; Boven de nieuwe grafiek, onder de oude foutieve grafiek


Fijn dat er zoveel mensen aan het testen zijn. Zo zie je maar dat dit niet voor niets is.

[mutsaards]

Gielz,
Ik ben ook veroordeelt tot een 4.2 meter met puls per 10 sec.
Maar heb het tot redelijk resultaat gekregen.
Werkt stabiel op NOM, aantal schakelingen 10 tot 18 / dag, nog wel licht instabiel doch komt er telkens zelf uit.
Niet optimaal, zal het ook niet worden omdat trigger en P1 waarde niet gesinchoniseerd zijn.

Hoe: in de versie van 20260114 de volgende parameters aangepast:
Regel 4 tijd van 4 naar 22
regel 363, 381, 547 en 561 factor 0,75 naar 0,25

Basis reden van probleem: voordat P1 waarde ververst wordt loopt algoritme 2 tot 3 maal waardoor telkens aanpassing wordt verhoogd/verlaagd met 75% dus correctie is telkens 150 of zelfs 225 %, kan niet anders dan oscilleren.

Ik heb Zendure via ticket gevraagd probleem op te lossen.
Ze hebben mij een firmware modificatie beloofd, wordt april / mei.

Tegen die tijd is probleem voor mij opgelost. Enexis is gestart met grootschalige vervanging (omgeving Tilburg) scheelt mij 200 eu aan vervangingskosten. (was al gepland)

Schermafdruk nodig van gedrag ? ik hoor het wel.

[gielz]

mutsaards schreef op vrijdag 27 februari 2026 @ 21:47:
Gielz,
Ik ben ook veroordeelt tot een 4.2 meter met puls per 10 sec.
Maar heb het tot redelijk resultaat gekregen.
Werkt stabiel op NOM, aantal schakelingen 10 tot 18 / dag, nog wel licht instabiel doch komt er telkens zelf uit.
Niet optimaal, zal het ook niet worden omdat trigger en P1 waarde niet gesinchoniseerd zijn.

Hoe: in de versie van 20260114 de volgende parameters aangepast:
Regel 4 tijd van 4 naar 22
regel 363, 381, 547 en 561 factor 0,75 naar 0,25

Basis reden van probleem: voordat P1 waarde ververst wordt loopt algoritme 2 tot 3 maal waardoor telkens aanpassing wordt verhoogd/verlaagd met 75% dus correctie is telkens 150 of zelfs 225 %, kan niet anders dan oscilleren.

Ik heb Zendure via ticket gevraagd probleem op te lossen.
Ze hebben mij een firmware modificatie beloofd, wordt april / mei.

Tegen die tijd is probleem voor mij opgelost. Enexis is gestart met grootschalige vervanging (omgeving Tilburg) scheelt mij 200 eu aan vervangingskosten. (was al gepland)

Schermafdruk nodig van gedrag ? ik hoor het wel.

Fijn dat je iig een nieuwe moderne meter krijgt. Dat zal echt een hoop schelen. Mocht dit lang duren kun je ook een KWH MID meter (Homewizard) direct na je hoofdschakelaar plaatsen. Dat is dan je vaste P1 meter.

[YvonneVP]

Ben(V) schreef op vrijdag 27 februari 2026 @ 15:30:
[...]


Geen idee hoe je deze conclusie trekt maar de Zendure P1, de homewizard P1 en de powerbaas P1 betrekken hun data allemaal uit de P1 uitgang van je energie meter en zijn dus allemaal maximaal even snel.
Dat wil zeggen als je een DSMR 4 meter hebt is dat 1 meting per 2,5 sec en bij een DSMR 5 meter 1 meting per sec.
Alleen meters zoals een Shelly die zelf met klemmen meten kunnen sneller zijn.

Ik trek die conclusie door ze allemaal in HA gezet te hebben en dan te kijken wanneer de waarden veranderen. 'Kijk en vergelijk' zeg maar. In de Zendure app heb ik onder apparaatbeheer zowel de Zendure P1 als de Homewizard P1 toegevoegd, en ook daar zie ik de verschillen. Het is dus geen conclusie maar een constatering die ik gedaan heb door de P! meters naast elkaar en gelijktijdig te laten lopen en te monitoren.

Met de P1 meter registreert de Zendure de teruglevering niet als stroom die geleverd wordt van je zonnepanelen, ondanks dat de P1 meter een negatieve waarde toont. Ik heb bij Zendure ook al gevraagd waarom ze voor de 2400AC niet de mogelijkheid inbouwen om een omvormer middels een API toe te kunnen voegen, zoals dit bijvoorbeeld bij de P1 meter van Powerbaas en Homewizard wel kan. De Zendure app heeft wel meer mankementen, en zeker als het gaat om wat getoond wordt met betrekking tot gebruik, en dat de som dus verkeerd is als je terug levert van de batterij naar bijvoorbeeld het huis. Maar dat terzijde omdat ik dergelijke berekeningen best belangrijk vindt, maar de opbouw logica van Zendure me daarin totaal ontgaat. In Shelly kun je ook schema's en automatiseringen aanmaken, en dan is dat makkelijker dan bij een P1 meter omdat die alleen in zijn geheel aan te sturen is. Buiten de rail variant hebben ze ook nog losse Shelly varianten die slechts 1 klem gebruikt, als je daarmee bijvoorbeeld alleen je zonnestroom wilt meten.

[YvonneVP]

Pakhaas schreef op vrijdag 27 februari 2026 @ 16:44:
[...]

Nee ik heb de prijzen ex btw en eb. Daar gaat het mis. Ik ga vanavond even prutsen met die link van Gielz. Dank!

Ik had eerst ook de kale prijzen, en toen kreeg ik geen uitroepteken, de prijs was ook geen 0 op dat moment, maar kreeg ik dus de grafieken niet netjes zoals ze op de schermafdruk van Gielz stonden. Veder had ik het ook ingesteld dat de waarden in centen zou worden weergegeven, en dan leek het dus of 1 kwh €19,- kostte ipv 19 cent. Bij de prijzen voor morgen zag ik ook helemaal geen grafieken. Het had dus goed kunnen zijn dat als de prijzen toen 0 waren geweest ik ook de uitroeptekens had gekregen. Ik heb toen ook de instructies gevolgd uit de link die Gielz je heeft gegeven, en ook de BTW, additionele kosten per kwh van de leverancier, etc. toegepast en sindsdien is het allemaal in orde en opgelost. Hopelijk gaan bij jou die uitroeptekens dus ook weg en werkt het zoals het bedoelt is of hoort te werken.

[YvonneVP]

gielz schreef op vrijdag 27 februari 2026 @ 19:52:
Voor de gene die de April testversie draaien van de gielz met het nieuwe plug-n-play dashboard is er een update voor het dashboard; https://github.com/Gielz1...ril-2026-Update/Dashboard

- Helpteksten zijn toegevoegd per geselecteerde modus
- Helpteksten verbeterd
- Releasenotes direct in te zien binnen HA via het configuratietabblad onder het kopje versiebeheer.
- Relais schakelingen in het verleden werden foutief weergegeven met veel te hoge aantallen wegens het foutief ophalen uit de statistics (LTS). Ook de eigen grafiek van Home Assistant haalde de data foutief op. De aantallen van vandaag waren wel altijd juist.

Ook is er een kleine update voor de Package / configuration.yaml
- Spread indicaties - Bij het herstarten van Home Assistant gaven de sensoren een tijdelijke foutmelding tijdens de start.

*Ter vergelijking; Boven de nieuwe grafiek, onder de oude foutieve grafiek
[Afbeelding]

Fijn dat er zoveel mensen aan het testen zijn. Zo zie je maar dat dit niet voor niets is.

Ook fijn dat jij deze oplossing blijft tweaken en verbeteren. Binnenkort komt er weer een kop koffie jouw kant op.

[Ben(V)]

Blijft gewoon dat ze allemaal als basis de P1 uitgang van de DSMR meter hebben en dat zeker de powerbaas net als de Home Wizard gelijk aan die DSMR snelheid zijn, want die geven die data een op een meteen door. De P1 van Zendure kan dus nooit sneller maar hooguit langzamer zijn.

[gielz]

Ben(V) schreef op zaterdag 28 februari 2026 @ 08:57:
Blijft gewoon dat ze allemaal als basis de P1 uitgang van de DSMR meter hebben en dat zeker de powerbaas net als de Home Wizard gelijk aan die DSMR snelheid zijn, want die geven die data een op een meteen door. De P1 van Zendure kan dus nooit sneller maar hooguit langzamer zijn.

Klopt en ze zijn allemaal net zo snel wanneer je ze op dezelfde manier gaat ophalen in Home Assistant. Wanneer je bijvoorbeeld de standaard integratie van Homewizard gebruikt is dit altijd langzamer (5s).

Alleen de CT klemmen zijn altijd langzamer en minder nauwkeurig ongeacht de verwerking in Home Assistant;

[edjes]

Ik gebruik Tibber en haal de gegevens binnen. Omdat ik niet tevreden was over de vlakke grafiek heb ik een dynamische y-as gemaakt, waardoor de verschillen over de dag meer uitspreken. Dat ziet er zo uit:


Dat is mij nu ook gelukt met de Nordpool grafiek. Ik weet niet hoe hij het houdt bij hele lage prijzen, maar het ziet er wel veel overzichtelijker uit:


Dit is de code voor de apex grafiek, schieten maar!

code:

type: custom:apexcharts-card
stacked: true

header:
  show: true
  title: Vandaag Nordpool

experimental:
  color_threshold: true

graph_span: 24h

span:
  start: day

apex_config:
  chart:
    height: 200px

  plotOptions:
    bar:
      columnWidth: 90%

  grid:
    show: true
    borderColor: "#332f2c"
    strokeDashArray: 0

  tooltip:
    enabledOnSeries:
      - 0
    followCursor: true
    shared: true
    intersect: false
    enabled: true
    x:
      format: HH:mm
      show: false

  xaxis:
    labels:
      show: false
    axisTicks:
      show: false
    axisBorder:
      color: "#616269"

  legend:
    show: false

  yaxis:
    - id: Prijs
      decimalsInFloat: 3
      tickAmount: 6
      forceNiceScale: false
      min: |
        EVAL:function (min) {
          return (window.apexMinNordpool !== undefined)
            ? window.apexMinNordpool
            : min;
        }
      max: |
        EVAL:function (max) {
          return (window.apexMaxNordpool !== undefined)
            ? window.apexMaxNordpool
            : max;
        }
      labels:
        style:
          colors: "#7b7c83"

series:

  ##################################################
  # PRIJS (bepaalt Y-as schaal)
  ##################################################

  - entity: sensor.dynamisch_nordpool
    yaxis_id: Prijs
    type: column
    color: "#ebebeb"
    float_precision: 3
    name: Vandaag

    show:
      in_header: false
      legend_value: false
      extremas: true

    color_threshold:
      - value: 0
        color: "#186ddc"
      - value: 0.155
        color: "#04822e"
      - value: 0.2
        color: "#12A141"
      - value: 0.25
        color: "#79B92C"
      - value: 0.3
        color: "#C4D81D"
      - value: 0.35
        color: "#F3DC0C"
      - value: 0.4
        color: "#EFA51E"
      - value: 0.45
        color: "#E76821"
      - value: 0.5
        color: "#DC182F"

    data_generator: |
      const data = entity.attributes.raw_today || [];
      if (data.length === 0) return [];

      const values = data.map(item => item.value);

      const minVal = Math.min(...values);
      const maxVal = Math.max(...values);
      const range = maxVal - minVal;

      // Dynamische padding (professionele autoscale)
      const topPadding = Math.max(range * 0.15, 0.01);
      const bottomPadding = Math.max(range * 0.20, 0.02);

      let minY = minVal - bottomPadding;
      let maxY = maxVal + topPadding;

      // Nordpool kan negatief worden
      minY = Math.max(minY, -0.10);

      window.apexMinNordpool = minY;
      window.apexMaxNordpool = maxY;

      return data.map(item => [
        new Date(item.start).getTime(),
        item.value
      ]);

  ##################################################
  # GOEDKOOPSTE PERIODE
  ##################################################

  - entity: sensor.dynamisch_goedkoopste_periode
    color: green
    curve: stepline
    opacity: 0.2
    type: column
    name: Goedkoop

    data_generator: |
      const data = entity.attributes.raw_today;
      if (!data) return [];

      return data.map(item => {
        const tijd = new Date(item.start).getTime();
        const waarde = item.goedkoop === "ja" ? 1 : 0;
        return [tijd, waarde];
      });

  ##################################################
  # DUURSTE PERIODE
  ##################################################

  - entity: sensor.dynamisch_goedkoopste_periode
    color: red
    curve: stepline
    opacity: 0.2
    type: column
    name: Duur

    data_generator: |
      const data = entity.attributes.raw_today;
      if (!data) return [];

      return data.map(item => {
        const tijd = new Date(item.start).getTime();
        const waarde = item.duur === "ja" ? 1 : 0;
        return [tijd, waarde];
      });

[gielz]

edjes schreef op zaterdag 28 februari 2026 @ 09:31:
Ik gebruik Tibber en haal de gegevens binnen. Omdat ik niet tevreden was over de vlakke grafiek heb ik een dynamische y-as gemaakt, waardoor de verschillen over de dag meer uitspreken. Dat ziet er zo uit:
[Afbeelding]

Dat is mij nu ook gelukt met de Nordpool grafiek. Ik weet niet hoe hij het houdt bij hele lage prijzen, maar het ziet er wel veel overzichtelijker uit:
[Afbeelding]

Dit is de code voor de apex grafiek, schieten maar!

code:

type: custom:apexcharts-card
stacked: true

header:
  show: true
  title: Vandaag Nordpool

experimental:
  color_threshold: true

graph_span: 24h

span:
  start: day

apex_config:
  chart:
    height: 200px

  plotOptions:
    bar:
      columnWidth: 90%

  grid:
    show: true
    borderColor: "#332f2c"
    strokeDashArray: 0

  tooltip:
    enabledOnSeries:
      - 0
    followCursor: true
    shared: true
    intersect: false
    enabled: true
    x:
      format: HH:mm
      show: false

  xaxis:
    labels:
      show: false
    axisTicks:
      show: false
    axisBorder:
      color: "#616269"

  legend:
    show: false

  yaxis:
    - id: Prijs
      decimalsInFloat: 3
      tickAmount: 6
      forceNiceScale: false
      min: |
        EVAL:function (min) {
          return (window.apexMinNordpool !== undefined)
            ? window.apexMinNordpool
            : min;
        }
      max: |
        EVAL:function (max) {
          return (window.apexMaxNordpool !== undefined)
            ? window.apexMaxNordpool
            : max;
        }
      labels:
        style:
          colors: "#7b7c83"

series:

  ##################################################
  # PRIJS (bepaalt Y-as schaal)
  ##################################################

  - entity: sensor.dynamisch_nordpool
    yaxis_id: Prijs
    type: column
    color: "#ebebeb"
    float_precision: 3
    name: Vandaag

    show:
      in_header: false
      legend_value: false
      extremas: true

    color_threshold:
      - value: 0
        color: "#186ddc"
      - value: 0.155
        color: "#04822e"
      - value: 0.2
        color: "#12A141"
      - value: 0.25
        color: "#79B92C"
      - value: 0.3
        color: "#C4D81D"
      - value: 0.35
        color: "#F3DC0C"
      - value: 0.4
        color: "#EFA51E"
      - value: 0.45
        color: "#E76821"
      - value: 0.5
        color: "#DC182F"

    data_generator: |
      const data = entity.attributes.raw_today || [];
      if (data.length === 0) return [];

      const values = data.map(item => item.value);

      const minVal = Math.min(...values);
      const maxVal = Math.max(...values);
      const range = maxVal - minVal;

      // Dynamische padding (professionele autoscale)
      const topPadding = Math.max(range * 0.15, 0.01);
      const bottomPadding = Math.max(range * 0.20, 0.02);

      let minY = minVal - bottomPadding;
      let maxY = maxVal + topPadding;

      // Nordpool kan negatief worden
      minY = Math.max(minY, -0.10);

      window.apexMinNordpool = minY;
      window.apexMaxNordpool = maxY;

      return data.map(item => [
        new Date(item.start).getTime(),
        item.value
      ]);

  ##################################################
  # GOEDKOOPSTE PERIODE
  ##################################################

  - entity: sensor.dynamisch_goedkoopste_periode
    color: green
    curve: stepline
    opacity: 0.2
    type: column
    name: Goedkoop

    data_generator: |
      const data = entity.attributes.raw_today;
      if (!data) return [];

      return data.map(item => {
        const tijd = new Date(item.start).getTime();
        const waarde = item.goedkoop === "ja" ? 1 : 0;
        return [tijd, waarde];
      });

  ##################################################
  # DUURSTE PERIODE
  ##################################################

  - entity: sensor.dynamisch_goedkoopste_periode
    color: red
    curve: stepline
    opacity: 0.2
    type: column
    name: Duur

    data_generator: |
      const data = entity.attributes.raw_today;
      if (!data) return [];

      return data.map(item => {
        const tijd = new Date(item.start).getTime();
        const waarde = item.duur === "ja" ? 1 : 0;
        return [tijd, waarde];
      });

Gaaf dat je hem naar eigen smaak hebt aangepast en werkend hebt gekregen. In de toekomstige april release gaat dit volledig op de schop om volledig in lijn te komen met de look-n-feel van Zendure.

Daar is de as dan ook dynamisch en de grafiek rustiger gemaakt;

[edjes]

Mooi! Is in je screenshot je y-as nu dynamisch dan?

[gielz]

edjes schreef op zaterdag 28 februari 2026 @ 09:38:
Mooi! Is in je screenshot je y-as nu dynamisch dan?

Ja nu op automatisch van apex, die kapt hem dus iets minder snel af dan bij jou apex. Ik zal jou variant hier even intern aanzetten om te kijken wat deze doet. Zeker een mooie aanvulling, hier ging het iets makkelijker.

code:

type: custom:apexcharts-card
update_interval: 1sec
graph_span: 24h
apex_config:
  markers:
    size: 0
    hover:
      size: 0
  plotOptions:
    bar:
      columnWidth: 90%
  tooltip:
    enabledOnSeries:
      - 0
    followCursor: true
    shared: true
    intersect: false
    enabled: true
    x:
      format: HH:mm
      show: false
    "y":
      formatter: |
        EVAL: (val) => `${val.toFixed(3)} €/kWh`
  grid:
    show: true
    borderColor: "#332f2c"
    strokeDashArray: 0
  chart:
    height: 150px
    stacked: true
    stackOnlyBar: true
  yaxis:
    - title:
        text: ""
      decimalsInFloat: 2
      forceNiceScale: true
      labels:
        style:
          colors: "#7b7c83"
  xaxis:
    labels:
      show: false
    axisTicks:
      show: false
    axisBorder:
      color: "#616269"
  legend:
    show: false
span:
  start: day
series:
  - entity: sensor.dynamisch_goedkoopste_periode
    name: Vandaag
    type: column
    float_precision: 3
    color: "#e0e0e3"
    show:
      in_header: false
      legend_value: false
      extremas: false
    data_generator: |
      const data = entity.attributes.raw_today;
      if (!data) return [];

      return data.map((item, index) => {
        const tijdStart = new Date(item.start).getTime();
        const duration = item.duration
                          ? item.duration * 1000
                          : (data[index + 1]
                              ? new Date(data[index + 1].start).getTime() - tijdStart
                              : 3600000);
        const tijdEind = tijdStart + duration;

        const prijs = item.value;
        const verleden = Date.now() >= tijdEind;  // alleen volledig verlopen blokken

        // Standaardkleur: #e0e0e3
        let kleur = "rgba(224,224,227,1)";

        if (prijs < 0) {
          kleur = verleden ? "rgba(93,173,226,0.25)" : "rgba(93,173,226,1)";
        }
        else if (item.goedkoop === "ja") {
          kleur = verleden ? "rgba(1,161,128,0.25)" : "rgba(1,161,128,1)";
        }
        else if (item.duur === "ja") {
          kleur = verleden ? "rgba(197,59,44,0.25)" : "rgba(197,59,44,1)";
        }
        else {
          kleur = verleden ? "rgba(224,224,227,0.25)" : "rgba(224,224,227,1)";
        }

        return {
          x: tijdStart,
          y: prijs,
          fillColor: kleur
        };
      });

[ Voor 106% gewijzigd door gielz op 28-02-2026 10:08 ]

[Spike2100]

Goeie morgen,

ik heb zendure kunnen koppelen via hun integratie, Zensdk staat open. Als P1 heb ik homewizard.

Echter zie ik in homeassistant een update van deze P1 meter om de 5 seconden.
Hoe kan ik een sensor (helper) maken die elke seconde de data uitleest via de HomeWizard api?

Ik heb de eerste 20 pagina's van deze thread al overlopen. Yaml vind ik nog vrij pittig.
Als iemand een linkje heeft om zo een helper te maken of ergens een guide weet staan mag ook.
Thanks

[ Voor 59% gewijzigd door Spike2100 op 28-02-2026 10:46 ]

[Pakhaas]

Ik zou ook wel de tarieven van Tibber willen.

Tibber tarieven 2026

Bovenop het kale tarief komt:
Inkoop vergoeding: 0.0248 per kwh incl btw
Energiebelasting: 0.1108 per kwh incl btw
Totaal: 0.1356.

Teruglevergoeding:
Bij terugleveren rekent Tibber terugleverkosten gelijk aan de inkoopvergoeding a 0.248 per kwh incl btw.

[paul123]

gielz schreef op zaterdag 28 februari 2026 @ 09:16:
[...]

Alleen de CT klemmen zijn altijd langzamer en minder nauwkeurig ongeacht de verwerking in Home Assistant;

hangt dat ook niet af van de hardware die erachter zit? Als ik naar de output van mijn Enphase gateway kijk dan lijkt dat toch wat preciezer dan de output van jouw Zendure 3CT. Maar ik heb geen direct vergelijkingsmateriaal vanwege mijn oude slimme meter...

[edjes]

Pakhaas schreef op zaterdag 28 februari 2026 @ 10:43:
Ik zou ook wel de tarieven van Tibber willen.

Tibber tarieven 2026

Bovenop het kale tarief komt:
Inkoop vergoeding: 0.0248 per kwh incl btw
Energiebelasting: 0.1108 per kwh incl btw
Totaal: 0.1356.

Teruglevergoeding:
Bij terugleveren rekent Tibber terugleverkosten gelijk aan de inkoopvergoeding a 0.248 per kwh incl btw.

Inmiddels is de opslag bij Tibber 0,148 cent.
Zie https://eerlijkverbruik.nl/energie/tibber
Heb je Tibber? Dan kan je je eigen API gebruiken voor de perfecte prijzen.
Wil je de Nordpool verbouwen?
Dan maak je een nieuwe nordpool sensor en vul je bij addional costs 0,148 in.

[Lange_Slurf]

Pakhaas schreef op zaterdag 28 februari 2026 @ 10:43:
Ik zou ook wel de tarieven van Tibber willen.

Tibber tarieven 2026

Bovenop het kale tarief komt:
Inkoop vergoeding: 0.0248 per kwh incl btw
Energiebelasting: 0.1108 per kwh incl btw
Totaal: 0.1356.

Teruglevergoeding:
Bij terugleveren rekent Tibber terugleverkosten gelijk aan de inkoopvergoeding a 0.248 per kwh incl btw.

Ik heb het op deze manier gedaan, een nieuwe sensor maken in Nordpool met deze waardes onderin volgens:
https://gathering.tweakers.net/forum/view_message/83698778

code:

{% set VAT = 0.21 %}
{% set tax_kWh = 0.1108 %}
{% set opslag = 0.0248 %}
{{ (current_price * VAT ) + (tax_kWh + opslag) * (1 + VAT)|float }}

Wanneer de tarieven wijzigen moet je, denk ik, weer een nieuwe sensor maken. Ik heb nog niet gevonden waar je de getallen eenvoudig aan kan passen.

[ Voor 8% gewijzigd door Lange_Slurf op 28-02-2026 11:27 ]

[koboy]

Pakhaas schreef op zaterdag 28 februari 2026 @ 10:43:
Ik zou ook wel de tarieven van Tibber willen.

Tibber tarieven 2026

Bovenop het kale tarief komt:
Inkoop vergoeding: 0.0248 per kwh incl btw
Energiebelasting: 0.1108 per kwh incl btw
Totaal: 0.1356.

Teruglevergoeding:
Bij terugleveren rekent Tibber terugleverkosten gelijk aan de inkoopvergoeding a 0.248 per kwh incl btw.

Off topic hier, maar omdat ik een hoop namen hier zie die ik niet tegenkom in het dynamische tarieven topic:

Sinds 1 januari betaalt Tibber (effectief) niet meer de inkoop vergoeding terug. Hierdoor krijg je een verschil van 2,48 cent tussen het afname en teruglevertarief.

Voor diegenen met een overschot waren er 2 dynamische leveranciers die er bovenuit sprongen omdat altijd het teruglevertarief hetzelfde was als het afname tarief, ook bij teruglever overschot en zonder additionele voorwaarden: Tibber en Zonneplan. Tibber is daarvan dus afgevallen.

Blijft over Zonneplan, die ook nog een 10% bonus over het kale epex tarief geven bij terugleveren tussen zonsopkomst en zonsondergang: de zonnebonus. En ja, daarbij wordt geen onderscheid gemaakt tussen PV en accu. Op een grijze winterdag heb ik zonnebonus gescoord.

[ben]

Ik heb om mijn Zendure AC2400+ aan te sturen vandaag de Gielz integratie ook geinstalleerd , bijna alles werkt naar behoren alleen krijg ik de onderstaande meldingen, de aangegeven entiteiten kan ik verder ook niet terug vinden ?

[paul123]

ben schreef op zaterdag 28 februari 2026 @ 12:05:
Ik heb om mijn Zendure AC2400+ aan te sturen vandaag de Gielz integratie ook geinstalleerd , bijna alles werkt naar behoren alleen krijg ik de onderstaande meldingen, de aangegeven entiteiten kan ik verder ook niet terug vinden ?

die actie staat bijna aan het eind van de zendure_ha_zensdk_gielz1986.yaml configuratie, dus misschien heb je die niet compleet toegevoegd?

[ben]

paul123 schreef op zaterdag 28 februari 2026 @ 12:21:
[...]


die actie staat bijna aan het eind van de zendure_ha_zensdk_gielz1986.yaml configuratie, dus misschien heb je die niet compleet toegevoegd?

Dank voor je snelle reactie, maar de volledige code staat wel in mijn packages, maar ik zie nu dat er geen enkele "rest_command" entiteit is aangemaakt

[gielz]

ben schreef op zaterdag 28 februari 2026 @ 12:46:
[...]


Dank voor je snelle reactie, maar de volledige code staat wel in mijn packages, maar ik zie nu dat er geen enkele "rest_command" entiteit is aangemaakt

Er is wel eens een bug in ha met rest commands dat ze niet aangemaakt worden. Paar keer herstarten lost het op.

[ben]

gielz schreef op zaterdag 28 februari 2026 @ 12:52:
[...]


Er is wel eens een bug in ha met rest commands dat ze niet aangemaakt worden. Paar keer herstarten lost het op.

Dat heeft inderdaad geholpen !

[gielz]

ben schreef op zaterdag 28 februari 2026 @ 13:47:
[...]


Dat heeft inderdaad geholpen !

Goed om te horen, heb dit nu ook in de wiki opgenomen; https://github.com/Gielz1...eel-gestelde-vragen-(FAQ)

[paul123]

@gielz misschien goed om in de Readme op te nemen dat voor het dashboard de "apexcharts-card" en "Number box" uit HACS nodig zijn, het duurde even voordat ik daar achter was

[gielz]

paul123 schreef op zaterdag 28 februari 2026 @ 14:57:
@gielz misschien goed om in de Readme op te nemen dat voor het dashboard de "apexcharts-card" en "Number box" uit HACS nodig zijn, het duurde even voordat ik daar achter was

Het huidige dashboard was alleen voor het testen en niet iets volwaardigs. Vanaf de april release is er wel een echt kant en klaar dashboard. Deze word ook volledig onderhouden; https://github.com/Gielz1...eel-plug-n-play-dashboard

April release
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.


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.

[Fremske]

mutsaards schreef op vrijdag 27 februari 2026 @ 21:47:
Gielz,
Ik ben ook veroordeelt tot een 4.2 meter met puls per 10 sec.
Maar heb het tot redelijk resultaat gekregen.
Werkt stabiel op NOM, aantal schakelingen 10 tot 18 / dag, nog wel licht instabiel doch komt er telkens zelf uit.
Niet optimaal, zal het ook niet worden omdat trigger en P1 waarde niet gesinchoniseerd zijn.

Hoe: in de versie van 20260114 de volgende parameters aangepast:
Regel 4 tijd van 4 naar 22
regel 363, 381, 547 en 561 factor 0,75 naar 0,25

Basis reden van probleem: voordat P1 waarde ververst wordt loopt algoritme 2 tot 3 maal waardoor telkens aanpassing wordt verhoogd/verlaagd met 75% dus correctie is telkens 150 of zelfs 225 %, kan niet anders dan oscilleren.

Ik heb Zendure via ticket gevraagd probleem op te lossen.
Ze hebben mij een firmware modificatie beloofd, wordt april / mei.

Tegen die tijd is probleem voor mij opgelost. Enexis is gestart met grootschalige vervanging (omgeving Tilburg) scheelt mij 200 eu aan vervangingskosten. (was al gepland)

Schermafdruk nodig van gedrag ? ik hoor het wel.

Hoi @mutsaards ik heb jouw waardes overgenomen om beter NOM te draaien bij mijn DSRM 4.2 gprs meter. Ga het de komende tijd monitoren.

[ Voor 15% gewijzigd door Fremske op 28-02-2026 20:35 ]

[Pakhaas]

Ik zie in het dashboard onder goedkoopste periode en duurste periode handmatige periode staan. Wat voor waardes kan ik daar precies invullen?

In de uitleg bij Dynamisch Handelen + NOM staat Wanneer nu Goedkoopste Periodes op JA staat zal er opgeladen worden indien Spread hoger is dan Minimale Spread

Dat begrijp ik niet helemaal. Moet ik ergens JA aanzetten. Of doet het dashboard automatisch JA als de spread boven de minimale spread komt?

[koboy]

Pakhaas schreef op zaterdag 28 februari 2026 @ 17:53:
Ik zie in het dashboard onder goedkoopste periode en duurste periode handmatige periode staan. Wat voor waardes kan ik daar precies invullen?

In de uitleg bij Dynamisch Handelen + NOM staat Wanneer nu Goedkoopste Periodes op JA staat zal er opgeladen worden indien Spread hoger is dan Minimale Spread

Dat begrijp ik niet helemaal. Moet ik ergens JA aanzetten. Of doet het dashboard automatisch JA als de spread boven de minimale spread komt?

Ik zou hem voor dit jaar nog op dynamisch handelen zetten voor optimaal rendement. Je kunt beter een kWh tegen bijvoorbeeld 26 cent verkopen dan hem uit je accu halen als stroom 24 cent kost.....

De ja gaat over of op dat moment de goedkoopste periode "actief" is.

Qua aantal uren om in te vullen: het aantal uur dat nodig is voor volledig opladen (goedkoopste) en ontladen (duurste).

Let even in deze periode op dat er niet over de datumgrens heen gekeken wordt. Ik heb de afgelopen dagen steeds even gekeken hoe die uren aan te passen om op de juiste strategie te komen. Heeft natuurlijk ook te maken met de tijd van het jaar..... Voor vandaag is het bijvoorbeeld beter om deze avond maar 2 uur te ontladen, en de overige 2,5 uur morgenochtend heel vroeg.

[Pakhaas]

koboy schreef op zaterdag 28 februari 2026 @ 18:41:
[...]


Ik zou hem voor dit jaar nog op dynamisch handelen zetten voor optimaal rendement. Je kunt beter een kWh tegen bijvoorbeeld 26 cent verkopen dan hem uit je accu halen als stroom 24 cent kost.....

De ja gaat over of op dat moment de goedkoopste periode "actief" is.

Qua aantal uren om in te vullen: het aantal uur dat nodig is voor volledig opladen (goedkoopste) en ontladen (duurste).

Let even in deze periode op dat er niet over de datumgrens heen gekeken wordt. Ik heb de afgelopen dagen steeds even gekeken hoe die uren aan te passen om op de juiste strategie te komen. Heeft natuurlijk ook te maken met de tijd van het jaar..... Voor vandaag is het bijvoorbeeld beter om deze avond maar 2 uur te ontladen, en de overige 2,5 uur morgenochtend heel vroeg.

Ja het ging mij even om die JA. Dat staat ook bij Dynamisch handelen.

En wat vul je in bij handmatige periodes? Op wat voor manier kan ik daar iets invullen?

[geert1992]

koboy schreef op zaterdag 28 februari 2026 @ 18:41:
[...]


Ik zou hem voor dit jaar nog op dynamisch handelen zetten voor optimaal rendement. Je kunt beter een kWh tegen bijvoorbeeld 26 cent verkopen dan hem uit je accu halen als stroom 24 cent kost.....

De ja gaat over of op dat moment de goedkoopste periode "actief" is.

Qua aantal uren om in te vullen: het aantal uur dat nodig is voor volledig opladen (goedkoopste) en ontladen (duurste).

Let even in deze periode op dat er niet over de datumgrens heen gekeken wordt. Ik heb de afgelopen dagen steeds even gekeken hoe die uren aan te passen om op de juiste strategie te komen. Heeft natuurlijk ook te maken met de tijd van het jaar..... Voor vandaag is het bijvoorbeeld beter om deze avond maar 2 uur te ontladen, en de overige 2,5 uur morgenochtend heel vroeg.

00:00 is de hoogste prijs, dat is wel heul vroeg.

[koboy]

Pakhaas schreef op zaterdag 28 februari 2026 @ 18:57:
[...]

Ja het ging mij even om die JA. Dat staat ook bij Dynamisch handelen.

En wat vul je in bij handmatige periodes? Op wat voor manier kan ik daar iets invullen?

Daar doe ik niets mee. Staat volgens mij in de installatie handleiding.....

Ik ben visueel ingesteld, dus speel wat met het aantal goedkope en dure uren tot het staat zoals ik wil.

[Devke]

Pakhaas schreef op zaterdag 28 februari 2026 @ 17:53:
Ik zie in het dashboard onder goedkoopste periode en duurste periode handmatige periode staan. Wat voor waardes kan ik daar precies invullen?

In de uitleg bij Dynamisch Handelen + NOM staat Wanneer nu Goedkoopste Periodes op JA staat zal er opgeladen worden indien Spread hoger is dan Minimale Spread

Dat begrijp ik niet helemaal. Moet ik ergens JA aanzetten. Of doet het dashboard automatisch JA als de spread boven de minimale spread komt?

Het kan voorkomen dat bijvoorbeeld de ochtend en avond wat interessante dure uren staan maar de dure uren niet op 1 volgend zijn. Dan kun je in dat veld handmatig toch de boel activeren. Een duur uur om bv 8 uur en om 17 uur kun je invoeren als D08:00;D17:00

De sensor zal vanzelf op Ja springen als er aan de voorwaarde voldaan wordt.

[Pakhaas]

Wanneer je 15min tarieven hebt gekozen dan zijn de getallen achter goedkoopste en duurste periode ook kwartieren. Dus wil je 4u laden dan vul je daar 16 in?

Kan dan beter uur tarieven invullen, ook al is tibber per kwartier.