Zendure producten in Home Assistant integreren deel 2

[gast777]

smetzie schreef op zondag 3 mei 2026 @ 16:11:
Hoi allen,

Ik lees al een tijdje mee op dit forum en na aanschaf van de Zendure pro; toch aan de slag gegaan met de integratie van gielz. Wat er prachtig uitziet; alleen krijg ik het niet werkend (ondanks dit forum doorzoeken en de readme file te doorlezen). Hopelijk kunnen jullie even meekijken.

Tweetal 'problemen'
- Naast het kopje 'aansturen' staat de P1 meter continu op 0 (terwijl deze wel waarde geeft bij de instellingen tab).

Alvast dank voor jullie hulp.

Je hebt "Afwijkende P1 Sensor" niet ingevuld. In plaats daarvan heb je zo te zien dat veld verwijderd van het dashboard en de P1 entiteit daar neergezet.

Dus even Afwijkende P1 Sensor veld terugzetten en invullen met de naam van je P1 sensor (sensor.xxxx).

Deze dus:

[ Voor 16% gewijzigd door gast777 op 03-05-2026 16:20 ]

[R1chardTM]

smetzie schreef op zondag 3 mei 2026 @ 16:11:
Hoi allen,

Ik lees al een tijdje mee op dit forum en na aanschaf van de Zendure pro; toch aan de slag gegaan met de integratie van gielz. Wat er prachtig uitziet; alleen krijg ik het niet werkend (ondanks dit forum doorzoeken en de readme file te doorlezen). Hopelijk kunnen jullie even meekijken.

Tweetal 'problemen'
- Naast het kopje 'aansturen' staat de P1 meter continu op 0 (terwijl deze wel waarde geeft bij de instellingen tab).
- De grafieken van dynamisch vandaag/morgen blijven leeg; ik heb unknow weggehaald en de sensor van Nordpool toegevoegd. Deze geeft ook een waarde bij het instellingen tab.

Onderstaand de screens.


[Afbeelding]

[Afbeelding]

Alvast dank voor jullie hulp.

Wat mij meteen opvalt is dat de modus op standby staat, zie eerste screenshot linksboven. Dan gaat er niets gebeuren, kies daar de gewenste modus. En het lijkt er ook op dat je iets geks gedaan hebt met de afwijkende P1 sensor. Dat veld ziet er bij mij uit als een invul veld. Lijkt er wel op als of je die entiteit heb zitten aanpassen, in plaats van in de UI het veld invullen met de naam van jouw P1 sensor.

Zo zien die twee dingen er bij mij uit.

[ Voor 27% gewijzigd door R1chardTM op 03-05-2026 16:29 ]

[smetzie]

R1chardTM schreef op zondag 3 mei 2026 @ 16:18:
[...]


Wat mij meteen opvalt is dat de modus op standby staat, zie eerste screenshot linksboven. Dan gaat er niets gebeuren, kies daar de gewenste modus. En het lijkt er ook op dat je iets geks gedaan hebt met de afwijkende P1 sensor. Dat veld ziet er bij mij uit als een invul veld. Lijkt er wel op als of je die entiteit heb zitten aanpassen, in plaats van in de UI het veld invullen met de naam van jouw P1 sensor.

Zo zien die twee dingen er bij mij uit.
[Afbeelding]

[Afbeelding]

Thanks; ik had idd dat veld aangepast. De P1 geeft nu een waarde.

Misschien heb ik zoiets soortgelijks gedaan voor de dynamisch vandaag/morgen grafieken.

[gast777]

smetzie schreef op zondag 3 mei 2026 @ 16:33:
[...]


Thanks; ik had idd dat veld aangepast. De P1 geeft nu een waarde.

Misschien heb ik zoiets soortgelijks gedaan voor de dynamisch vandaag/morgen grafieken.

Klopt inderdaad. Dit veld even terugzetten en invullen:

[Devke]

smetzie schreef op zondag 3 mei 2026 @ 16:11:
Hoi allen,

Ik lees al een tijdje mee op dit forum en na aanschaf van de Zendure pro; toch aan de slag gegaan met de integratie van gielz. Wat er prachtig uitziet; alleen krijg ik het niet werkend (ondanks dit forum doorzoeken en de readme file te doorlezen). Hopelijk kunnen jullie even meekijken.

Tweetal 'problemen'
- Naast het kopje 'aansturen' staat de P1 meter continu op 0 (terwijl deze wel waarde geeft bij de instellingen tab).
- De grafieken van dynamisch vandaag/morgen blijven leeg; ik heb unknow weggehaald en de sensor van Nordpool toegevoegd. Deze geeft ook een waarde bij het instellingen tab.

Onderstaand de screens.


[Afbeelding]

[Afbeelding]

Alvast dank voor jullie hulp.

Die 0 is de aansturing. Batterij staat op standby dus aansturing is er niet. Die 0 staat hier ook. Ik zie dat je spread op 25% staat, als je die nu eens naar 0 zet, dan wel actie?

[ctrl-tab]

Heeft iemand de gielz integratie werkend met de builtin nordpool integratie?
Ben al bezig geweest met een translatie template sensor maar kreeg het niet voor elkaar.

[smetzie]

gast777 schreef op zondag 3 mei 2026 @ 16:41:
[...]


Klopt inderdaad. Dit veld even terugzetten en invullen:
[Afbeelding]

Ah top dit, thanks voor de support; het werkt

[oeps]

Hallo allemaal,
Heb/had een issue met de Gielz integratie (of eigenlijk HA zelf). Heb nu een workaround maar snap de oorzaak niet. Sorry, wat langere post.
Ik deel het hier zodat het later door anderen gevonden kan worden en hopelijk weet iemand wat hier echt aan de hand is.


Het uitte zich (door toeval van het moment?) dat de batterij opeens op vol vermogen ging ontladen gedurende ongeveer 2 uur. Daarna normaal, wij waren weg dus het ging vanzelf allemaal! Bij mij is op vol vermogen gelukkig op dit moment nog 800W omdat de Zendure 2400 Pro (zonder panelen nog) nu nog op een stopcontact zit.

Ingezoomed:


Na speuren kwam ik het volgende tegen in de HA logging met eindeloos veel repeats in de logging:

WARNING (MainThread) [homeassistant.components.sensor] Updating rest sensor took longer than the scheduled update interval 0:00:01[0m

Ik heb de batterij pas 3 weken en tot 30 april had ik een eigen +/- P1 Power sensor die elke 5 seconden ververst.
Afgelopen donderdag de rest api versie naar de Zendure P1 meter toegevoegd aan HA en die sensor in Gielz gezet. Werkte prima maar toen niet in de HA log gekeken.
Bij time-out errors is de eerste suggestie natuurlijk: Je hebt bagger Wifi of je hebt een bagger HA server.
De Zendure P1 meter en dongle en bridge hangen beiden in de meterkast naast een paar andere ESPhome sensors waaronder de P1 meter sensor die ik al tijden gebruik zonder problemen.
HA draait in een VM op Proxmox op een i5. De VM heeft 6GB ram en 6 virtuele CPU’s. Een ping naar Zendure P1 geeft gemiddeld 4,6ms roundtrip.
Als workaround gebruik ik nu gewoon weer de +/- Power sensor die ik had.
Om te testen heb ik de Zendure P1 via rest even op 2 seconden gezet. Met 1 seconde was de log zo’n beetje vol met bovenstaande error. Met 2 seconden heb ik een enkele time-out gezien gedurende een uur of 8.

• Ik weet uiteraard niet 100% zeker dat de time-outs de oorzaak zijn het opeens hard ontladen.

Mijn theorie tot nu toe: Af en toe is er door de Quooker even een piek waardoor de batterij op 800W ontladen gaat en net op dat moment gaf iets er de brui aan om zich twee uur later weer te herstellen. Zie ook de screenshots uit de Gielz log.In de HA log zie ik ook de volgende error:

Logger: homeassistant.components.rest.data
Source: components/rest/data.py:181
integration: RESTful (documentation, issues)
First occurred: 08:10:56 (171 occurrences)
Last logged: 16:24:06
Error fetching data: http://unknown/api/v1/data failed with Cannot connect to host unknown:80 ssl:default [DNS server returned answer with no data]
Error fetching data: http://unknown/properties/report failed with Cannot connect to host unknown:80 ssl:default [DNS server returned answer with no data]
Error fetching data: http:///api/v1/data failed with http:///api/v1/data
Error fetching data: http://192.168.178.156/properties/report failed with [Errno 104] Connection reset by peer

Ik snap de error message niet helemaal: http://192.168.178.156/properties/report failed zou kunnen als er even geen connectie is/
Maar http:///api/v1/data failed en http://unknown/api/v1/data failed snap ik niet. Lijkt dan een leeg IP adres veld of de tekst unknown in een IP address veld. In de screenshot met mijn instellingen.

De 192.168.178.156 is de 2400 Pro zelf. De wifi is meestal “Good”, heel soms “weak” (nog onderzoeken) maar in de periode van ontlading was het “Good”, tussen 16:00-18:00. Fritz-box bedrade AP is 2 muren en een verdieping verder. Daar is nog iets te verbeteren. AP dichter bij raam zodat de garage beter in beeld is.

Herkent iemand de problemen met Rest in HA (ik gebruik zelf één rest commando in HA om een ESPhome elke nacht even te herstarten.
Dank!

[DrNickB]

oeps schreef op zondag 3 mei 2026 @ 17:10:
Hallo allemaal,
...

Heb je ook iets meer logging van je Zendure P1 meter? Daar de waardes van? Connectiviteit etc?

Het lijkt er sterk op (ik ben geen expert) als je naar de eerste screenshot kijkt, dat 'iets' is waardoor hij wil gaan ontladen, maar daarna is je gebruik (Wit)/terug levering (groen) gelijk, eigenlijk lijkt de batterij te doen, wat hij hoort te doen.
Daarna lijkt je P1 (wit) iets meer heen en weer te schommelen, en daar lijkt de automatisering weer op te reageren.

[MikeyMan]

Bjorker schreef op woensdag 11 maart 2026 @ 12:06:
[...]

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

Is dit inderdaad sneller? Want dan zet ik hem ook om. Doet de app dan helemaal niks meer?

[TBird484]

ctrl-tab schreef op zondag 3 mei 2026 @ 16:58:
Heeft iemand de gielz integratie werkend met de builtin nordpool integratie?
Ben al bezig geweest met een translatie template sensor maar kreeg het niet voor elkaar.

Ja, die heb ik werkend.
Zie Wai_AM in "Zendure producten in Home Assistant integreren deel 2"
Bovenstaande config is voor de nederlandse versie van Gielz.
Ik heb op basis van de info zelf een template voor de engelse versie gemaakt.
Laat maar weten als je die nodig hebt.
Ik loop nog wel tegen een vreemd ding aan, ik moet perse de 15 min slider in Gielz aan hebben staan, anders wordt er in Gielz geen data verwerkt.

[oeps]

DrNickB schreef op zondag 3 mei 2026 @ 18:24:
[...]

Heb je ook iets meer logging van je Zendure P1 meter? Daar de waardes van? Connectiviteit etc?

Het lijkt er sterk op (ik ben geen expert) als je naar de eerste screenshot kijkt, dat 'iets' is waardoor hij wil gaan ontladen, maar daarna is je gebruik (Wit)/terug levering (groen) gelijk, eigenlijk lijkt de batterij te doen, wat hij hoort te doen.
Daarna lijkt je P1 (wit) iets meer heen en weer te schommelen, en daar lijkt de automatisering weer op te reageren.

Dank je voor je reactie.
Helaas geeft de Zendure P1 geen logging over wifi connectie. Kan dus alleen aan de router/AP kant wat zien wat ook beperkt is.

-66dBm is niet geweldig.
Het lijkt erop dat de Zendure spullen blijven plakken aan de Fritzbox router die veel verder staat. Heel vreemd want Fritzbox zou client steering moeten doen als de router vind dat de client een betere verbinding kan krijgen bij de AP.
Ik ga even dieper in mijn Wifi netwerk duiken.
Dank voor het Wifi zetje

[gast777]

oeps schreef op zondag 3 mei 2026 @ 17:10:
Herkent iemand de problemen met Rest in HA (ik gebruik zelf één rest commando in HA om een ESPhome elke nacht even te herstarten.
Dank!

Kun je de yaml configuratie van de Zendure P1 meter polling laten zien? Lijkt erop dat je daar geen IP adres gebruikt, maar een DNS naam. En dat de DNS lookup dan om een of andere reden even niet goed gaat.

Error fetching data: http://unknown/api/v1/data failed with Cannot connect to host unknown:80 ssl:default [DNS server returned answer with no data]
Error fetching data: http://unknown/properties/report failed with Cannot connect to host unknown:80 ssl:default [DNS server returned answer with no data]

Of is dat misschien de Homewizard P1 entry die probeert te connecten maar 'unknown' heeft als IP adres. In je screenshot staat er (empty value) bij de HomeWizard P1. Ik weet niet of dat normaal is....

[gast777]

Vul bij de HomeWizard P1 eens "unknown" in. Dat lijkt me default als je die niet gebruikt.

[oeps]

gast777 schreef op zondag 3 mei 2026 @ 20:03:
[...]
Kun je de yaml configuratie van de Zendure P1 meter polling laten zien? Lijkt erop dat je daar geen IP adres gebruikt, maar een DNS naam. En dat de DNS lookup dan om een of andere reden even niet goed gaat.

Of is dat misschien de Homewizard P1 entry die probeert te connecten maar 'unknown' heeft als IP adres. In je screenshot staat er (empty value) bij de HomeWizard P1. Ik weet niet of dat normaal is....

Dank voor het meedenken!
De yaml code die ik in mijn sensors.yaml heb staan (included in de configuration.yaml. Intern gebruik ik voor alle domotica spullen vaste ip addressen in HA altijd IP adressen, voor de zekerheid:

YAML:

# REST Sensors
# added 20260430
- platform: rest
  resource: http://192.168.178.162/properties/report
  scan_interval: 2
  name: "P1 Zendure API rest"
  value_template: "{{ value_json.total_power | float }}"
  unique_id: P1_Zendure_API_rest
  unit_of_measurement: "W"
  device_class: power
  state_class: measurement

Staat nu op 2 seconden was 1.
Ik weet dat ik het niet exact doe zoals in de documentatie staat maar ik kreeg allerlei errors bij config check als ik het exact overnam. Na wat knutselen kwam ik tot bovenstaande.

Configuration warnings
Setup of package 'zendure_gielz1986_global' failed: integration 'rest_command' cannot be merged, dict expected in main config
Invalid config for 'rest_command' at configuration.yaml, line 143: expected dictionary for dictionary value 'rest_command', got [{'reboot_moresenswoonkamer_url': {'url': 'http://192.168.178.143/Setup?action=reboot', 'method': 'get', 'timeout': 15}}, {'resource': 'http://192.168.178.162/properties/report', 'scan_interval': 1, 'sensor': [{'name': 'P1 Zendure API', 'value_template': '{{ value_json.total_power | float }}', 'unique_id': 'P1_Zendure_API', 'unit_of_measurement': 'W', 'device_class': 'power', 'state_class': 'measurement'}, {'name': 'P1 Zendure Phase A Power', 'value_template': '{{ value_json.a_aprt_power | fl...

Die error had te maken met dat ik al elders ook een rest commando gebruik reboot_moresenswoonkamer_url die je in de config check hierboven ziet.

Ik heb de HomeWizard entity die uiteraard niet beschikbaar is op disabled gezet sinds vanochtend om te kijken of dat invloed zou hebben op de logging. Ik heb even blabla opgegeven als HW IP adres en dat komt keurig in de log, dus toch een relatie met de HW die ik niet gebruik. Ga die error gewoon maar negeren.

Logger: homeassistant.components.rest.data
Source: components/rest/data.py:181
integration: RESTful (documentation, issues)
First occurred: 08:10:56 (253 occurrences)
Last logged: 20:30:10

Error fetching data: http://unknown/api/v1/data failed with Cannot connect to host unknown:80 ssl:default [DNS server returned answer with no data]
Error fetching data: http://unknown/properties/report failed with Cannot connect to host unknown:80 ssl:default [DNS server returned answer with no data]
Error fetching data: http:///api/v1/data failed with http:///api/v1/data
Error fetching data: http://192.168.178.156/properties/report failed with [Errno 104] Connection reset by peer
Error fetching data: http://blabla/api/v1/data failed with Cannot connect to host blabla:80 ssl:default [Timeout while contacting DNS servers]

Het zijn blijkbaar meerdere rest calls die in één log entry terecht komen. Beetje slordig van HA.

[DrNickB]

oeps schreef op zondag 3 mei 2026 @ 19:42:
[...]

Dank je voor je reactie.
Helaas geeft de Zendure P1 geen logging over wifi connectie. Kan dus alleen aan de router/AP kant wat zien wat ook beperkt is.

Dank voor het Wifi zetje

Was 2 delige vraag, maar zag dat ik het wat minder duidelijk had neer gezet.

Wat waren je historische waardes van de P1 over die periode.
Via meer waardes / Historie graph.

[ctrl-tab]

Mocht iemand interesse hebben om de officiele nordpool integratie werkend te krijgen met gielz;

- aanpassing nodig in gielz package, vanwege gebruik template sensor:

code:

sed -i 's/{{ item\.start\.isoformat() }}/{{ item.start if item.start is string else item.start.isoformat() }}/g' /config/packages/zendure_gielz1986_global.yaml

sed -i 's/{{ item\.end\.isoformat() }}/{{ item.end if item.end is string else item.end.isoformat() }}/g' /config/packages/zendure_gielz1986_global.yaml

- maak template sensor aan die een 'fake' hacs nordpool sensor creeert;
- config entry van officiele nordpoo integratie nog even invoeren;
- let op ik gebruik input values voor vat (.21) , opslag (0.02) , tax (0.091), kan je er ook statisch in zetten (zonneplan)
zonnebonus heb ik er niet in zitten.

code:

  - triggers:
      - trigger: time_pattern
        minutes: /15
      - trigger: homeassistant
        event: start
    actions:
      - delay: "00:00:30"
      - action: nordpool.get_prices_for_date
        data:
          config_entry: < ENTER CONFIG ENTRY ID >
          date: "{{ now().date() }}"
          areas: NL
          currency: EUR
        response_variable: today_price
      - action: nordpool.get_prices_for_date
        data:
          config_entry: < ENTER CONFIG ENTRY ID >
          date: "{{ now().date() + timedelta(days=1) }}"
          areas: NL
          currency: EUR
        response_variable: tomorrow_price 

    sensor:

      # --- CURRENT PRICE (mimics old HACS sensor) ---
      - name: nordpool_kwh_nl_eur_3_095_0
        unique_id: nordpool_kwh_nl_eur_3_095_0
        unit_of_measurement: "EUR/kWh"
        icon: mdi:currency-eur
        state_class: measurement
        state: >
          {% set opslag = states('input_number.energy_opslag') | float(0) %}
          {% set vat    = states('input_number.energy_vat')    | float(0) %}
          {% set tax    = states('input_number.energy_tax')    | float(0) %}
          {% if today_price is mapping and today_price['NL'] | list | count > 0 %}
            {% set now_slot = now().replace(second=0, microsecond=0) %}
            {% set now_slot = now_slot.replace(minute=(now_slot.minute // 15) * 15) %}
            {% set current = namespace(price=none) %}
            {% for state in today_price['NL'] %}
              {% set slot_start = state.start | as_datetime | as_local %}
              {% if slot_start == now_slot %}
                {% set current.price = ((state.price / 1000 + tax + opslag) * (1 + vat)) | round(5) %}
              {% endif %}
            {% endfor %}
            {{ current.price | default('unavailable') }}
          {% else %}
            unavailable
          {% endif %}
        attributes:
          current_price: >
            {% set opslag = states('input_number.energy_opslag') | float(0) %}
            {% set vat    = states('input_number.energy_vat')    | float(0) %}
            {% set tax    = states('input_number.energy_tax')    | float(0) %}
            {% if today_price is mapping and today_price['NL'] | list | count > 0 %}
              {% set now_slot = now().replace(second=0, microsecond=0) %}
              {% set now_slot = now_slot.replace(minute=(now_slot.minute // 15) * 15) %}
              {% set current = namespace(price=none) %}
              {% for state in today_price['NL'] %}
                {% set slot_start = state.start | as_datetime | as_local %}
                {% if slot_start == now_slot %}
                  {% set current.price = ((state.price / 1000 + tax + opslag) * (1 + vat)) | round(5) %}
                {% endif %}
              {% endfor %}
              {{ current.price | default(none) }}
            {% else %}
              {{ none }}
            {% endif %}
          today: >
            {% set opslag = states('input_number.energy_opslag') | float(0) %}
            {% set vat    = states('input_number.energy_vat')    | float(0) %}
            {% set tax    = states('input_number.energy_tax')    | float(0) %}
            {% set data = namespace(prices=[], group=[]) %}
            {% if today_price is mapping %}
              {% for state in today_price['NL'] %}
                {% set p = ((state.price / 1000 + tax + opslag) * (1 + vat)) | round(5) %}
                {% set data.group = data.group + [p] %}
                {% if data.group | count == 4 %}
                  {% set data.prices = data.prices + [(data.group | sum / 4) | round(5)] %}
                  {% set data.group = [] %}
                {% endif %}
              {% endfor %}
            {% endif %}
            {{ data.prices }}
          tomorrow: >
            {% set opslag = states('input_number.energy_opslag') | float(0) %}
            {% set vat    = states('input_number.energy_vat')    | float(0) %}
            {% set tax    = states('input_number.energy_tax')    | float(0) %}
            {% set data = namespace(prices=[], group=[]) %}
            {% if tomorrow_price is mapping %}
              {% for state in tomorrow_price['NL'] %}
                {% set p = ((state.price / 1000 + tax + opslag) * (1 + vat)) | round(5) %}
                {% set data.group = data.group + [p] %}
                {% if data.group | count == 4 %}
                  {% set data.prices = data.prices + [(data.group | sum / 4) | round(5)] %}
                  {% set data.group = [] %}
                {% endif %}
              {% endfor %}
            {% endif %}
            {{ data.prices }}
          tomorrow_valid: >
            {{ tomorrow_price is mapping and tomorrow_price['NL'] | list | count > 0 }}
          average: >
            {% set opslag = states('input_number.energy_opslag') | float(0) %}
            {% set vat    = states('input_number.energy_vat')    | float(0) %}
            {% set tax    = states('input_number.energy_tax')    | float(0) %}
            {% set data = namespace(prices=[], group=[]) %}
            {% if today_price is mapping %}
              {% for state in today_price['NL'] %}
                {% set p = ((state.price / 1000 + tax + opslag) * (1 + vat)) %}
                {% set data.group = data.group + [p] %}
                {% if data.group | count == 4 %}
                  {% set data.prices = data.prices + [(data.group | sum / 4)] %}
                  {% set data.group = [] %}
                {% endif %}
              {% endfor %}
              {{ (data.prices | sum / data.prices | count) | round(5) }}
            {% else %}
              {{ 0 }}
            {% endif %}
          low_price: >
            {% set opslag = states('input_number.energy_opslag') | float(0) %}
            {% set vat    = states('input_number.energy_vat')    | float(0) %}
            {% set tax    = states('input_number.energy_tax')    | float(0) %}
            {% set cutoff = 0.95 %}
            {% set data = namespace(prices=[], group=[]) %}
            {% if today_price is mapping %}
              {% for state in today_price['NL'] %}
                {% set p = ((state.price / 1000 + tax + opslag) * (1 + vat)) %}
                {% set data.group = data.group + [p] %}
                {% if data.group | count == 4 %}
                  {% set data.prices = data.prices + [(data.group | sum / 4)] %}
                  {% set data.group = [] %}
                {% endif %}
              {% endfor %}
              {% set avg = data.prices | sum / data.prices | count %}
              {% set now_slot = now().replace(second=0, microsecond=0) %}
              {% set now_slot = now_slot.replace(minute=(now_slot.minute // 15) * 15) %}
              {% set current = namespace(price=avg) %}
              {% for state in today_price['NL'] %}
                {% set slot_start = state.start | as_datetime | as_local %}
                {% if slot_start == now_slot %}
                  {% set current.price = ((state.price / 1000 + tax + opslag) * (1 + vat)) %}
                {% endif %}
              {% endfor %}
              {{ current.price < avg * cutoff }}
            {% else %}
              {{ false }}
            {% endif %}
          raw_today: >
            {% set opslag = states('input_number.energy_opslag') | float(0) %}
            {% set vat    = states('input_number.energy_vat')    | float(0) %}
            {% set tax    = states('input_number.energy_tax')    | float(0) %}
            {% set data = namespace(prices=[], group=[], starts=[], ends=[]) %}
            {% if today_price is mapping %}
              {% for state in today_price['NL'] %}
                {% set p = ((state.price / 1000 + tax + opslag) * (1 + vat)) | round(5) %}
                {% set data.group = data.group + [p] %}
                {% if data.group | count == 1 %}
                  {% set data.starts = data.starts + [state.start] %}
                {% endif %}
                {% if data.group | count == 4 %}
                  {% set data.prices = data.prices + [{'start': data.starts[-1], 'end': state.end, 'value': (data.group | sum / 4) | round(5)}] %}
                  {% set data.group = [] %}
                {% endif %}
              {% endfor %}
            {% endif %}
            {{ data.prices }}
          raw_tomorrow: >
            {% set opslag = states('input_number.energy_opslag') | float(0) %}
            {% set vat    = states('input_number.energy_vat')    | float(0) %}
            {% set tax    = states('input_number.energy_tax')    | float(0) %}
            {% set data = namespace(prices=[], group=[], starts=[], ends=[]) %}
            {% if tomorrow_price is mapping %}
              {% for state in tomorrow_price['NL'] %}
                {% set p = ((state.price / 1000 + tax + opslag) * (1 + vat)) | round(5) %}
                {% set data.group = data.group + [p] %}
                {% if data.group | count == 1 %}
                  {% set data.starts = data.starts + [state.start] %}
                {% endif %}
                {% if data.group | count == 4 %}
                  {% set data.prices = data.prices + [{'start': data.starts[-1], 'end': state.end, 'value': (data.group | sum / 4) | round(5)}] %}
                  {% set data.group = [] %}
                {% endif %}
              {% endfor %}
            {% endif %}
            {{ data.prices }}

      # --- TOMORROW SENSOR ---
      - name: nordpool_tomorrow
        unique_id: nordpool_tomorrow
        state: >
          {% set opslag = states('input_number.energy_opslag') | float(0) %}
          {% set vat    = states('input_number.energy_vat')    | float(0) %}
          {% set tax    = states('input_number.energy_tax')    | float(0) %}
          {% set data = namespace(prices=[], group=[]) %}
          {% if tomorrow_price is mapping and tomorrow_price['NL'] | list | count > 0 %}
            {% for state in tomorrow_price['NL'] %}
              {% set p = ((state.price / 1000 + tax + opslag) * (1 + vat)) | round(5) %}
              {% set data.group = data.group + [p] %}
              {% if data.group | count == 4 %}
                {% set data.prices = data.prices + [(data.group | sum / 4) | round(5)] %}
                {% set data.group = [] %}
              {% endif %}
            {% endfor %}
            {{ min(data.prices) }}
          {% else %}
            unavailable
          {% endif %}
        attributes:
          data: >
            {% set opslag = states('input_number.energy_opslag') | float(0) %}
            {% set vat    = states('input_number.energy_vat')    | float(0) %}
            {% set tax    = states('input_number.energy_tax')    | float(0) %}
            {% set data = namespace(prices=[], group=[], starts=[]) %}
            {% if tomorrow_price is mapping %}
              {% for state in tomorrow_price['NL'] %}
                {% set p = ((state.price / 1000 + tax + opslag) * (1 + vat)) | round(5) %}
                {% set data.group = data.group + [p] %}
                {% if data.group | count == 1 %}
                  {% set data.starts = data.starts + [state.start] %}
                {% endif %}
                {% if data.group | count == 4 %}
                  {% set data.prices = data.prices + [{'start': data.starts[-1], 'end': state.end, 'price': (data.group | sum / 4) | round(5)}] %}
                  {% set data.group = [] %}
                {% endif %}
              {% endfor %}
            {% endif %}
            {{ data.prices }}

[oeps]

DrNickB schreef op zondag 3 mei 2026 @ 21:07:
[...]

Was 2 delige vraag, maar zag dat ik het wat minder duidelijk had neer gezet.

Wat waren je historische waardes van de P1 over die periode.
Via meer waardes / Historie graph.

Nu snap ik hem
Beide P1 meters toegevoegd, geel de Zendure P1 die in gebruik was voor Gielz tijdens het ontlaad issue van iets voor 16:00 tot bijna 18:00.
De gele en blauwe lijn zijn overal beschikbaar (deze grafiek heeft natuurlijk geen resolutie van 1 seconde). Geel licht soms bovenop, dan weer blauw. Dat is rendering, niet onbeschikbaarheid.


En voor de compleetheid de vullingsgraag van de batterij:


Dank weer!

[hemertje]

Wai_AM schreef op vrijdag 24 april 2026 @ 13:35:
[Afbeelding]

Morgen is een goede test case of je alles goed kan doen

@Wai_AM

hoe ziet jou code voor deze kaarten eruit?

ik zie namelijk:





die van jou ziet er wat rustiger uit

[hemertje]

Wai_AM schreef op donderdag 23 april 2026 @ 08:03:
[...]


netjes.
mogelijke verbetering is dynamisch maken.
- input max temp
- input min temp
- input duration on
- input duration off

zodat het niet vast staat op temp en duur .

deze zijn instelbaar via de Helpers

code:

zendure_offgrid.yaml

[DrNickB]

oeps schreef op zondag 3 mei 2026 @ 21:46:
[...]

Nu snap ik hem
Beide P1 meters toegevoegd, geel de Zendure P1 die in gebruik was voor Gielz tijdens het ontlaad issue van iets voor 16:00 tot bijna 18:00.
De gele en blauwe lijn zijn overal beschikbaar (deze grafiek heeft natuurlijk geen resolutie van 1 seconde). Geel licht soms bovenop, dan weer blauw. Dat is rendering, niet onbeschikbaarheid.
[Afbeelding]

En voor de compleetheid de vullingsgraag van de batterij:
[Afbeelding]

Dank weer!

Ja, nee, sorry je bent me kwijt

p1 lijkt waardes te geven, je zendure lijkt waardes te geven, maar toch deed hij iets wat niet klopt
Maar zie ook niet heel goed terug in als ik je p1 data vergelijk met je screenshot daarvoor,
het lijkt alsof er wat andere waardes in gebruikt worden.
maar nogmaals geen expert en je bent me kwijt

[YvonneVP]

koboy schreef op zaterdag 2 mei 2026 @ 16:04:
[...]


Als je kijkt naar de te maken winst in centen dan maakt kaal of inclusief nu niet zo veel (beetje BTW) uit.
Probleem zit alleen in de RTE van je systeem, die is geen 100% en wordt gerekend in procenten. Daardoor moet je rekenen met de daadwerkelijke totale kosten, zeker dit jaar en volgend jaar ook op de paar momenten dat je gaat laden vanaf het net.

Ik zal in de zomer nagenoeg altijd gebruik maken van mijn zonnestroom om te batterijen te vullen, tenzij net als afgelopen week de goedkope periode negatief is. Dan gaan de zonnepaneeltjes even uit, en prop ik mijn batterij wel vol via het net. Zelf heb ik de prijzen incl. btw en EB. Dan is het namelijk gelijk aan wat ik in de app van Zonneplan zie, en is het voor mij allemaal wat gemakkelijker te vergelijken en zie ik ook gewoon fijn dezelfde prijzen. Scheelt me een hoop hoofdbrekers en gereken.

[YvonneVP]

Hippe Lip schreef op zaterdag 2 mei 2026 @ 23:59:
[...]

Ik ben inmiddels een stuk verder in het begrip en denk dat ik het in de zomer niet nodig heb. Ik heb vooral een flink overschot aan PV, dus loopt mijn accu overdag vol en stel ik de duurste uren in om ‘m weer te legen.
Jammer dat dit (nog) niet kan door simpelweg te zeggen dat ik de 8 duurste kwartieren tussen (bijvoorbeeld) 8 ‘s avonds en 8 in de ochtend wil ontladen. Als je met aantal wil werken, dan lopen die over de hele dag, dus ook de ochtend ervóór. In de winter werkt dat misschien, maar niet in de zomer.

Komend najaar en zeker in de winter dan heb ik die spread wel nodig omdat PV dan niet genoeg oplevert om het etmaal door te komen. Tegen die tijd ga ik me er verder in verdiepen.
Maar dank voor je suggestie, @YvonneVP

Je kunt toch dan handmatig de tijden om te laden en ontladen instellen met Gxx:xx en Dxx:xx. Ik zet gewoon aantal uren goedkoopste in, en aantal uren duurste. En tot nu komen die uren dagelijks goed overeen als zijnde de goedkoopste en duurste uren. Ik kijk er na 13 uur even naar hoe het de andere dag is met de prijzen, en that's it. Mijn provider rekent in uren, dus heb ik de uren ook in Gielz op uren ingesteld. Zou dit op kwartieren worden omgezet dan vermenigvuldig ik de uren van nu, goedkoopste en duurste, gewoon met 4 en dan komt het op hetzelfde neer. Maar zo lang mijn leverancier uren hanteert doe ik dat ook.

[YvonneVP]

Hippe Lip schreef op zondag 3 mei 2026 @ 00:03:
[...]

Je hebt natuurlijk helemaal gelijk, @YvonneVP. Er wordt door @gielz en @gast777 ongelooflijk veel en vooral fraai werk geleverd. En de documentatie díé er is is ook niet verkeerd.

Het was meer de frustratie van de first-time user die eerst alles van die twee in een vloek en een zucht kan installeren, maar als het daarna op aanpassen of updaten aankomt, dan voel je je als in het donker in onbekende omgeving.
Ik kom wel over die frustratie heen hoor en het is zeker geen aanmerking aan de makers, maar soms moet het er even uit.

Ik denk dat je misschien té snel té veel wilde. En daarmee zat je dan naar mijn beleving eerder jezelf in de weg. Vele vragen die je stelde zijn ook al eerder gesteld, en die zijn dan op het forum ook terug te vinden. Enige is dat je dan wel wat meer gebonden bent aan hoe je zoekt om ook het antwoord te kunnen vinden. Ik zou dus zeggen, neem de tijd om het je eigen te maken en probeer niet in 0,5 seconden van 0 naar 100 te willen. Dat levert namelijk frustratie op.

[YvonneVP]

Hippe Lip schreef op zondag 3 mei 2026 @ 00:15:
[...]

Toch begin ik langzaamaan te beseffen (ik ben een trage denker) dat het wel uitmaakt en dat je de totale prijs moet hebben, inclusief EB, BTW en toeslag. Die spread heb je nodig om de verliezen te compenseren en die verliezen zitten ook in de EB, BTW en toeslag. Tenminste als je het hebt over in- en verkoop. Niet als je de batterijen vanuit je PV vult, want das andere koek.

De batterijen vullen uit je PV is altijd de meest winstgevende. Je betaald in NL momenteel geen btw, geen EB, maar wel toeslag. Per kwh is de btw en EB te verwaarlozen, en als je inkoopt terwijl het zonnestroom is, die je later weer verkoopt dan is het ook heel makkelijk om te zien wat de duurste uren zijn om die PV stroom weer te dumpen. Ik denk dus dat je iets te complex aan het denken bent, en dat simpel denken soms juist makkelijker is en beter werkt. Je maakt het jezelf uiteindelijk alleen lastiger, zeker als het gaat om PV stroom. Die levert het meeste op, tenzij de goedkoopste prijzen negatief zijn zoals afgelopen week. Maar dan gaat bij mij de PV uit om van het net te laden. En die stroom dump ik niet om te verkopen, maar gebruik ik dus als mijn PV geen, of niet voldoende, stroom meer levert en draai ik NOM tot de andere dag.

[YvonneVP]

koboy schreef op zondag 3 mei 2026 @ 13:33:
[...]


Ik zou de Nordpool gewoon op kwartieren laten staan. In Gielz zit een schuifje om om te rekenen naar uurtarieven. Scheelt je foutgevoelig het configureren van Nordpool als zonneplan over gaat

Dat is inderdaad ook een goede oplossing om gewoon uurtarieven te hebben.

[YvonneVP]

ppaulv schreef op zondag 3 mei 2026 @ 13:50:
[...]

Zie mijn reactie van 1 mei 14.50 uur. Meen me te herinneren dat daarvoor nodig is dat je beheer rechten hebt op jouw 'site' van solaredge maar dat weet ik niet zeker.
En integratie solaredge modbus multi

Ik zou admin rechten moeten hebben als ik online via mijn browser inlog, en anders vraag ik gewoon even bij het bedrijf die mijn SolarEdge monitort of ze me kunnen helpen.

[Hippe Lip]

YvonneVP schreef op maandag 4 mei 2026 @ 01:18:
[...]
Ik denk dus dat je iets te complex aan het denken bent, en dat simpel denken soms juist makkelijker is en beter werkt. Je maakt het jezelf uiteindelijk alleen lastiger,

Dank voor je reacties, @YvonneVP.
(Te) snel (te) veel willen, daar heb ik vaak last van, net zoals te complex denken. Zo zit mijn hoofd helaas in elkaar, ik weet het.
Ik zal het ermee moeten doen…

Desondanks ( of misschien juist dankzij dat?) is mijn motto: ‘eenvoud is kenmerk van het ware’.

[Pakhaas]

YvonneVP schreef op maandag 4 mei 2026 @ 01:18:
[...]

De batterijen vullen uit je PV is altijd de meest winstgevende. Je betaald in NL momenteel geen btw, geen EB, maar wel toeslag. Per kwh is de btw en EB te verwaarlozen, en als je inkoopt terwijl het zonnestroom is, die je later weer verkoopt dan is het ook heel makkelijk om te zien wat de duurste uren zijn om die PV stroom weer te dumpen. Ik denk dus dat je iets te complex aan het denken bent, en dat simpel denken soms juist makkelijker is en beter werkt. Je maakt het jezelf uiteindelijk alleen lastiger, zeker als het gaat om PV stroom. Die levert het meeste op, tenzij de goedkoopste prijzen negatief zijn zoals afgelopen week. Maar dan gaat bij mij de PV uit om van het net te laden. En die stroom dump ik niet om te verkopen, maar gebruik ik dus als mijn PV geen, of niet voldoende, stroom meer levert en draai ik NOM tot de andere dag.

Momenteel is dit niet het meest winstgevende. Dat is dynamisch handelen.

[Wai_AM]

hemertje schreef op zondag 3 mei 2026 @ 22:03:
[...]


@Wai_AM

hoe ziet jou code voor deze kaarten eruit?

ik zie namelijk:

[Afbeelding]

[Afbeelding]

die van jou ziet er wat rustiger uit

Marktprijs is ook "Line" krijg dan ook kleuren, met ¨column" krijg ik die niet.

[koboy]

YvonneVP schreef op maandag 4 mei 2026 @ 01:18:
[...]

De batterijen vullen uit je PV is altijd de meest winstgevende. Je betaald in NL momenteel geen btw, geen EB, maar wel toeslag. Per kwh is de btw en EB te verwaarlozen, en als je inkoopt terwijl het zonnestroom is, die je later weer verkoopt dan is het ook heel makkelijk om te zien wat de duurste uren zijn om die PV stroom weer te dumpen. Ik denk dus dat je iets te complex aan het denken bent, en dat simpel denken soms juist makkelijker is en beter werkt. Je maakt het jezelf uiteindelijk alleen lastiger, zeker als het gaat om PV stroom. Die levert het meeste op, tenzij de goedkoopste prijzen negatief zijn zoals afgelopen week. Maar dan gaat bij mij de PV uit om van het net te laden. En die stroom dump ik niet om te verkopen, maar gebruik ik dus als mijn PV geen, of niet voldoende, stroom meer levert en draai ik NOM tot de andere dag.

Batterijen uit PV vullen hoeft niet het meest winstgevende te zijn!
Bij teruglevering kleiner dan afname is de waarde van een teruggeleverde kWh gelijk aan die van een afgenomen kWh, dus inclusief BTW en EB en toeslag (in geval van zonneplan).
De 80% RTE is dus OOK van toepassing op de EB component, wat betekent dat je al ongeveer 2 cent winst moet maken op het EPEX deel om alleen de RTE over de EB te compenseren!

Edit: dat van die waarde geldt natuurlijk ook voor de waarde van stroom uit de accu. Ook stroom ingekocht tijdens all-in negatieve uren moet je voor maximale winst dumpen op het duurste moment en niet mee gaan NOMmen.

Heel bot gezegd: met een dynamisch contract is vrijwel elke notie van NOM geld weggooien. Er zijn 2 situaties waarin dit niet zo is:
1. Meer teruglevering dan afname
2. In de smalle prijsband tussen negatieve verkoopprijs en all-in negatieve prijs die je hebt bij leveranciers die de inkoopvergoeding niet teruggeven.
Maar in beide gevallen ga je NOMmen door de PV te regelen niet de accu.

[ Voor 18% gewijzigd door koboy op 04-05-2026 09:36 ]

[smetzie]

Ik ben nog vrij nieuw met Home Assistant en de Gielz-integratie, dus misschien stel ik wat beginnersvragen.
Mijn situatie:

Ik wil binnenkort 4 zonnepanelen aansluiten op een SolarFlow Pro 2400 met 5,2 kWh batterijcapaciteit. Op dit moment staat de ontlading nog op maximaal 800 watt, maar zodra hij op een eigen groep zit wil ik dit verhogen richting 2400 watt. Ik gebruik dynamische tarieven en hanteer ongeveer 12 cent prijsverschil als grens om de batterij tijdens dure uren te ontladen.

Waar ik tegenaan loop:
Tijdens dure uren wordt de batterij ontladen, maar daarna is hij vaak nog niet volledig leeg (vanwege 800w). Ik zou graag willen dat de batterij daarna automatisch het sluipverbruik in de nacht opvangt, in plaats van dat hij op stand-by gaat.

Mijn vragen:

• Kan ik instellen dat bijvoorbeeld 30% van de batterijcapaciteit beschikbaar blijft voor nachtelijk sluipverbruik?
• Moet ik hiervoor de modus van de SolarFlow via een Home Assistant-automatisering aanpassen?
• Welke modus of instellingen gebruiken jullie hiervoor in combinatie met de Gielz-integratie?
• Heeft iemand misschien een simpel voorbeeld van een automatisering, liefst met de gebruikte entiteiten of YAML?

Daarnaast heb ik een hybride auto met een accu van 14,1 kWh. Die laad ik vaak ’s nachts via een normaal 230V-stopcontact. Daar zit een slimme schakelaar tussen, die ik nu via HomeKit automatiseer.

• Hoe voorkomen jullie dat de thuisbatterij onbedoeld leeggetrokken wordt door het laden van de auto, is dat erg of juist niet handig?
• Is het slim om de SolarFlow tijdelijk op stand-by te zetten tijdens het autoladen, of werken jullie liever met een minimale SOC-grens?

Ik ben vooral benieuwd naar hoe anderen dit praktisch hebben ingericht.

[ppaulv]

koboy schreef op maandag 4 mei 2026 @ 09:14:
[...]


Batterijen uit PV vullen hoeft niet het meest winstgevende te zijn!
Bij teruglevering kleiner dan afname is de waarde van een teruggeleverde kWh gelijk aan die van een afgenomen kWh, dus inclusief BTW en EB en toeslag (in geval van zonneplan).
De 80% RTE is dus OOK van toepassing op de EB component, wat betekent dat je al ongeveer 2 cent winst moet maken op het EPEX deel om alleen de RTE over de EB te compenseren!

Edit: dat van die waarde geldt natuurlijk ook voor de waarde van stroom uit de accu. Ook stroom ingekocht tijdens all-in negatieve uren moet je voor maximale winst dumpen op het duurste moment en niet mee gaan NOMmen.

Heel bot gezegd: met een dynamisch contract is vrijwel elke notie van NOM geld weggooien. Er zijn 2 situaties waarin dit niet zo is:
1. Meer teruglevering dan afname
2. In de smalle prijsband tussen negatieve verkoopprijs en all-in negatieve prijs die je hebt bij leveranciers die de inkoopvergoeding niet teruggeven.
Maar in beide gevallen ga je NOMmen door de PV te regelen niet de accu.

Denk dat je laatste opmerking helemaal correct is. Wat daarvoor staat ongetwijfeld ook..

[RemmyB83]

Vorige week heb ik de fireson integratie geupdate, en sinds dien heb ik wat problemen. Deze nogmaals geupdate door een tip hier naar fw 1.3.1.
Maar ik blijf wat rare dingen zien.
Ik heb 2x een sf800 plus.
Hems staat uit.
ZenSDK staat uit.
En Gielz staat aan op NOM.
Accu's waren leeg, ze hebben vandaag wat bij geladen. Vervolgens zijn ze weer leeg, maar nu gaan ze weer niet laden. Lijkt wel of er ergens iets blijft hangen.
Gisteren het zelfde, en toen even zit spelen met hems en fireson. En dan start het uiteindelijk wel. Maar dat is natuurlijk niet de bedoeling.
Extra info: proxy versie 20260430

[Devke]

RemmyB83 schreef op maandag 4 mei 2026 @ 12:41:
Vorige week heb ik de fireson integratie geupdate, en sinds dien heb ik wat problemen. Deze nogmaals geupdate door een tip hier naar fw 1.3.1.
Maar ik blijf wat rare dingen zien.
Ik heb 2x een sf800 plus.
Hems staat uit.
ZenSDK staat uit.
En Gielz staat aan op NOM.
Accu's waren leeg, ze hebben vandaag wat bij geladen. Vervolgens zijn ze weer leeg, maar nu gaan ze weer niet laden. Lijkt wel of er ergens iets blijft hangen.
Gisteren het zelfde, en toen even zit spelen met hems en fireson. En dan start het uiteindelijk wel. Maar dat is natuurlijk niet de bedoeling.
Extra info: proxy versie 20260430

[Afbeelding]

[Afbeelding]

Je gebruikt gielz en Fireson niet gelijktijdig hoop ik? Er kan maar 1 kapitein op het schip actief zijn.

[Maarten60]

smetzie schreef op maandag 4 mei 2026 @ 10:57:
Ik ben nog vrij nieuw met Home Assistant en de Gielz-integratie,

Daarnaast heb ik een hybride auto met een accu van 14,1 kWh. Die laad ik vaak ’s nachts via een normaal 230V-stopcontact. Daar zit een slimme schakelaar tussen, die ik nu via HomeKit automatiseer.

Hoe voorkomen jullie dat de thuisbatterij onbedoeld leeggetrokken wordt door het laden van de auto, is dat erg of juist niet handig?

Auto uit batterij laden is een keuze. Ik laad meestal overdag met zonnestroom, maar als je de batterij met zonnestroom laadt en ‘s morgens vermogen over hebt zou ik de batterij gebruiken (gratis stroom).

• Is het slim om de SolarFlow tijdelijk op stand-by te zetten tijdens het autoladen, of werken jullie liever met een minimale SOC-grens?

Omdat ik overdag via de panelen wil laden, wil ik de batterij (verlies via RTE) niet gebruiken. Ik heb een automatisering die bij laden door auto de batterij in slim opladen zet. Dus niet ontladen maar wel laden als er (pv) stroom over is.

[RemmyB83]

Devke schreef op maandag 4 mei 2026 @ 12:47:
[...]

Je gebruikt gielz en Fireson niet gelijktijdig hoop ik? Er kan maar 1 kapitein op het schip actief zijn.

Nee die staat uit.
Maar gisteren toen ik die even aanzette ging hij weer.... nu doe ik dat even niet om te trouble shoote.

[gast777]

RemmyB83 schreef op maandag 4 mei 2026 @ 12:51:
[...]

[Afbeelding]
Nee die staat uit.
Maar gisteren toen ik die even aanzette ging hij weer.... nu doe ik dat even niet om te trouble shoote.

Onlangs had iemand vage problemen en toen die MQTT uitschakelde op de Zendures was het probleem weg. Fireson gebruikt MQTT dacht ik toch? En tegelijkertijd polt Gielz elke seconde richting de devices via HTTP/REST. Dat beide tegelijk doen zou overbelasting en problemen kunnen veroorzaken.

Ik zou dus zeggen, als test kun je MQTT uitschakelen op je Zendures. En dan kijken of de problemen weg zijn. Sowieso zou ik adviseren niet Gielz en Fireson tegelijk te gebruiken. Ook al is het niet aansturen, ook het alleen informatie pollen en MQTT zenden tegelijk kan wellicht te veel worden voor de Zendures.

[ralphkeb]

RemmyB83 schreef op maandag 4 mei 2026 @ 12:41:
Vorige week heb ik de fireson integratie geupdate, en sinds dien heb ik wat problemen. Deze nogmaals geupdate door een tip hier naar fw 1.3.1.
Maar ik blijf wat rare dingen zien.
Ik heb 2x een sf800 plus.
Hems staat uit.
ZenSDK staat uit.
En Gielz staat aan op NOM.
Accu's waren leeg, ze hebben vandaag wat bij geladen. Vervolgens zijn ze weer leeg, maar nu gaan ze weer niet laden. Lijkt wel of er ergens iets blijft hangen.
Gisteren het zelfde, en toen even zit spelen met hems en fireson. En dan start het uiteindelijk wel. Maar dat is natuurlijk niet de bedoeling.
Extra info: proxy versie 20260430

[Afbeelding]

[Afbeelding]

Ik weet niet wat er ingesteld staat in het configuratie scherm van Gielz? Als er bij het discharging scherm bij start discharge -300 staat en wat ik zie in je schermafbeelding je verbruik -150 W is gaat hij volgens mij niet opladen.

[RemmyB83]

gast777 schreef op maandag 4 mei 2026 @ 13:37:
[...]


Onlangs had iemand vage problemen en toen die MQTT uitschakelde op de Zendures was het probleem weg. Fireson gebruikt MQTT dacht ik toch? En tegelijkertijd polt Gielz elke seconde richting de devices via HTTP/REST. Dat beide tegelijk doen zou overbelasting en problemen kunnen veroorzaken.

Ik zou dus zeggen, als test kun je MQTT uitschakelen op je Zendures. En dan kijken of de problemen weg zijn. Sowieso zou ik adviseren niet Gielz en Fireson tegelijk te gebruiken. Ook al is het niet aansturen, ook het alleen informatie pollen en MQTT zenden tegelijk kan wellicht te veel worden voor de Zendures.

Bedankt voor het meedenken🙂

Logboek in gielz bleef ook op 11.50 hangen, en werd niet elke 5 sec ververst. Na dat ik via gielz de mode op standby had gezet, en weer terug op NOM begon het weer te werken. Gekke was als ik er op het logboek klikte zag ik wel dat hij elke 5 sec werd getriggert.

Ik heb MQTT idd aan staan, en heb ze nu uitgezet. Hopelijk is dat het probleem.
En anders zet ik fireson ook nog wel uit.

In iedergeval alvast bedankt

[RemmyB83]

ralphkeb schreef op maandag 4 mei 2026 @ 13:44:
[...]


Ik weet niet wat er ingesteld staat in het configuratie scherm van Gielz? Als er bij het discharging scherm bij start discharge -300 staat en wat ik zie in je schermafbeelding je verbruik -150 W is gaat hij volgens mij niet opladen.

Bedankt voor je reactie🙂
Maar daar zit het probleem denk ik niet.

[Hippe Lip]

Pakhaas schreef op maandag 4 mei 2026 @ 06:49:
[...]

Momenteel is dit niet het meest winstgevende. Dat is dynamisch handelen.

@Pakhaas
Ook als je PV op een gemiddelde dag meer opwekt dan je in je batterijen kwijt kan en ruim meer is dan je in een etmaal zelf verbruikt?

[ Voor 8% gewijzigd door Hippe Lip op 04-05-2026 21:32 ]

[Pakhaas]

Hippe Lip schreef op maandag 4 mei 2026 @ 21:29:
[...]

@Pakhaas
Ook als je PV op een gemiddelde dag meer opwekt dan je in je batterijen kwijt kan en ruim meer is dan je in een etmaal zelf verbruikt?

Waarom zou dat het anders maken?

[Hippe Lip]

Pakhaas schreef op maandag 4 mei 2026 @ 21:33:
[...]

Waarom zou dat het anders maken?

Ik weet het niet en daarom stel ik jou die vraag.

[Pakhaas]

Hippe Lip schreef op maandag 4 mei 2026 @ 21:46:
[...]

Ik weet het niet en daarom stel ik jou die vraag.

Ik stelde die wedervraag om je even te triggeren.

Bijv morgen. Dan is het overdag 26ct en avonds op duurste 31ct. Als je dan PV overschot gaat opslaan in je batterij met 80% RTE betaal je in werkelijk 31.2ct om de PV opwek op te slaan. Immers als je de PV rechtsteeks had teruggeleverd kreeg je direct 26ct zonder laad- en ontlaadverliezen. Dus dat is de kostprijs bij batterij laden met PV.
Morgen blijven de batterijen in standby en lever ik PV direct terug.

Daarom is nu Dynamisch Handelen economisch het voordeligste. Laden als goedkoop is en ontladen als duur is en de rest op standby.

Dat wordt volgend jaar anders want dan krijg je bij terugleveren alleen kale prijs. Dan is PV opslaan voor later verbruik juist wel aantrekkelijk.

[ Voor 3% gewijzigd door Pakhaas op 04-05-2026 21:56 ]

[Hippe Lip]

Pakhaas schreef op maandag 4 mei 2026 @ 21:55:
[...]

Ik stelde die wedervraag om je even te triggeren.

Bijv morgen. Dan is het overdag 26ct en avonds op duurste 31ct. Als je dan PV overschot gaat opslaan in je batterij met 80% RTE betaal je in werkelijk 31.2ct om de PV opwek op te slaan. Immers als je de PV rechtsteeks had teruggeleverd kreeg je direct 26ct zonder laad- en ontlaadverliezen. Dus dat is de kostprijs bij batterij laden met PV.
Morgen blijven de batterijen in standby en lever ik PV direct terug.

Daarom is nu Dynamisch Handelen economisch het voordeligste. Laden als goedkoop is en ontladen als duur is en de rest op standby.

Dat wordt volgend jaar anders want dan krijg je bij terugleveren alleen kale prijs. Dan is PV opslaan voor later verbruik juist wel aantrekkelijk.

Dank voor deze uitleg @Pakhaas.
Die had ik even nodig.

Dan nog wel twee andere vragen.

1. Wat voor spreiding kies je dan? Minimaal 20% om je verliezen te compenseren, maar wel hoger omdat je anders nog steeds heen en weer aan het pompen bent met nul winst. Maar hoeveel is dan een geschikte drempel? 30%?
2. En kies je dan voor alleen Dynamic Trading of voor Smart Matching + Smart Matching? Want bij een paar matige dagen haal je die 30% (of hoeveel je ook kiest) nauwelijks en staat de boel te nixen. Is het dan beter wel te NOMmen?

[Pakhaas]

Hippe Lip schreef op maandag 4 mei 2026 @ 22:19:
[...]

Dank voor deze uitleg @Pakhaas.
Die had ik even nodig.

Dan nog wel twee andere vragen.

1. Wat voor spreiding kies je dan? Minimaal 20% om je verliezen te compenseren, maar wel hoger omdat je anders nog steeds heen en weer aan het pompen bent met nul winst. Maar hoeveel is dan een geschikte drempel? 30%?
2. En kies je dan voor alleen Dynamic Trading of voor Smart Matching + Smart Matching? Want bij een paar matige dagen haal je die 30% (of hoeveel je ook kiest) nauwelijks en staat de boel te nixen. Is het dan beter wel te NOMmen?

Ik ken de termen die je noemt niet. Ik werk met de NL versie van Gielz.

Minimale spread zeggen ze 25%, maar in praktijk heb ik liever 40-50% want zit bij Tibber en daar betaal je een hogere opslag voor levering dan wat je als bonus bij teruglevering terug krijgt.

Bovendien hou je met RTE nog geen rekening met afschrijving, dus voor een paar centen doe ik niet mee.

NOM moet je nou juist niet doen haha. Bij NOM sla je alsnog PV overschot op, en dat wil je nou juist direct het net op hebben, zoals ik hierboven net heb uitgelegd.

[ Voor 4% gewijzigd door Pakhaas op 04-05-2026 22:27 ]

[koboy]

@Hippe Lip
Een RTE van 80% komt overeen met een spread van 25%. Aangezien de RTE 83% of meer in geval van de 2500ACplus/pro is, maak je dan net een minimale winst als je alle kosten terugkrijgt zoals bij Zonneplan.

Ikzelf pak ook die minimale winst, want alle kleine beetjes helpen en wie het kleine niet eert....

[Hippe Lip]

Pakhaas schreef op maandag 4 mei 2026 @ 22:25:
[...]

Ik ken de termen die je noemt niet. Ik werk met de NL versie van Gielz.

@Pakhaas
Dynamic Trading of voor Smart Matching + Smart Matching
=
Dynamisch handelen of Dynamisch handelen + NOM

Minimale spread zeggen ze 25%, maar in praktijk heb ik liever 40-50% want zit bij Tibber en daar betaal je een hogere opslag voor levering dan wat je als bonus bij teruglevering terug krijgt.

Bovendien hou je met RTE nog geen rekening met afschrijving, dus voor een paar centen doe ik niet mee.

NOM moet je nou juist niet doen haha. Bij NOM sla je alsnog PV overschot op, en dat wil je nou juist direct het net op hebben, zoals ik hierboven net heb uitgelegd.

Ah, die opslag had ik nog niet aan gedacht. Die moet ik nog mee calculeren. Die is hier 2,5 cent, te betalen bij zowel heen als terug. Ik zit bij SamenOM (don’t ask).

En doet het eigen gebruik er nog toe? Ik heb door allerlei apparatuur in huis een basisverbruik van ca. 500W rond de klok. Dat gaat dus altijd door, ook op dagen dat je die spread van laten we zeggen 40% niet haalt. Ik kan me voorstellen dat NOM dan wel zinvol is: overdag enig overschot in de accu (op goedkopere uren) om dat in de avond en nacht tijdens duurdere uren te gebruiken?
Of is dat wishful thinking?

[ Voor 5% gewijzigd door Hippe Lip op 04-05-2026 23:07 ]

[Pakhaas]

Hippe Lip schreef op maandag 4 mei 2026 @ 22:36:
[...]

@Pakhaas
Dynamic Trading of voor Smart Matching + Smart Matching
=
Dynamisch handelen of Dynamisch handelen + NOM

[...]

Ah, die opslag had ik nog niet aan gedacht. Die moet ik nog mee calculeren. Die is hier 2,5 cent, te betalen bij zowel heen als terug. Ik zit bij SamenOM (don’t ask).

En doet het eigen gebruik er nog toe? Ik heb door allerlei apparatuur in huis een basisverbruik van ca. 500W rond de klok. Dat gaat dus altijd door, ook op dagen dat je die spread van laten we zeggen 40% niet haalt. Ik kan me voorstellen dat NOM dan wel zinvol is: overdag enig overschot in de accu (op goedkopere uren) om dat in de avond en nacht tijdens duurdere uren te gebruiken?
Of is dat wishful thinking?

Die opslag van 2.5ct heen en terug hoef je dus niets mee te doen he. Die is immers zelfde heen en terug.

NOM is en blijft nu nee, puur economisch bekeken. Goedkope uren laden, dure uren ontladen. Wellicht kan chatgpt wat vragen voor je voorrekenen, dan kan je het wat visueel maken.

[ Voor 3% gewijzigd door Pakhaas op 04-05-2026 22:54 ]

[Hippe Lip]

Pakhaas schreef op maandag 4 mei 2026 @ 22:48:
Die opslag van 2.5ct heen en terug hoef je dus niets mee te doen he. Die is immers zelfde heen en terug.

@Pakhaas
Helaas. Daarom zei ik al: die 2,5 cent (inclusief BTW) is in beide richtingen te betalen! Die komt er dus bij in geval van afname en wordt in mindering gebracht op de vergoeding bij terugleveren.
Dat maakt de minimale spread die nodig is om überhaupt quitte te spelen waarschijnlijk nog wat hoger.
Maar omdat dit (die 2,5 cent) een absoluut bedrag is en de spread relatief is doe ik er nog even over om dat om te rekenen in benodigde spread.

NOM is en blijft nu nee, puur economisch bekeken. Goedkope uren laden, dure uren ontladen. Maar gezien de vragen die je stelt, heb ik nog niet het idee dat je het begrijpt. Wellicht kan chatgpt wat vragen voor je voorrekenen, dan kan je het wat visueel maken.

Ik zei het al een tijdje geleden: ik ben een trage denker. Ik heb dit soort gesprekken juist nodig om het goed in het hoofd te krijgen. Het is niet een kwestie van het er niet mee eens zijn of eraan twijfelen. Het komt maar langzaam, stapje voor stapje binnen. Het zal mede de leeftijd zijn?

[Mistraller]

Ik voel me ergens heel dom, maar de Gielz integratie, al dan niet met proxy, krijg ik niet soepel werkend en is bij mij bijzonder instabiel.
Ik heb alles volgens de instructies ingericht, de data van beide zendures verschijnt in het dashboard, HEMS is uitgevinkt; en beide hebben een "uitstekende" wifi verbinding.
So far so good....Echter is mijn hele HA daarna een heel stuk meer unresponsive, en ik zie ook steeds de connectie wegschieten, dan is de data op het dashboard tijdelijk op unavailable. (gaps in de graphs).
Ik kan in het Gielz dash "Snel ontladen en snel Opladen" activeren; en dan worden de ingestelde waardes toegepast.
NOM, handmatig doet echter niets. De zendures blijven op standby staan.

Ik had het nachtje eerder ook al getest, en toen was in de ochtend mijn HA gecrashed.

NodeRed heb ik als addon app geinstalleerd binnen ha.
Mijn HA draaide tot nu toe soepel in een KVM up een ubuntu laptop (vraag me af of dit er iets toedoet maar goed)

Om nodeRed even uit te sluiten heb ik de flow gedisabled en in Gielz het IP van 1 zendure ingesteld.
Verbinding lijkt dan iets stabieler, maar ook hier kan ik niet Handmatig een wattage instellen, NOM doen, slechts max ontladen en max laden. En opvragen van de automations pagina in de settings duurt ineens dik 10 seconden.

Ik heb van alle files de NL versie gebruikt. En overal de nieuwste versie.

Ik heb geen idee waar dit nu aan ligt, het lijkt wel een te zware integratie voor mijn HA? Nooit eerder gezien dit gedrag. Maar gekke is dus ook dat ik maar een paar modi werkend kan krijgen. (handmatig had het zeker moeten doen)

De automation heb ik nog omgezet naar trigger op de P1 sensor ipv die 5 seconden trigger om te kijken wat het doet; maar lijkt eerder slechter te werken (dacht dat ik dit begrepen had uit het grote zendure topic; omdat ik nog een dsmr4 heb leek me dit zinvol.

[ Voor 14% gewijzigd door Mistraller op 05-05-2026 02:19 ]

[YvonneVP]

Pakhaas schreef op maandag 4 mei 2026 @ 06:49:
[...]

Momenteel is dit niet het meest winstgevende. Dat is dynamisch handelen.

Tenzij je voor NOM gaat, en dus de stroom van je batterij wilt gebruiken als het zonnetje onder is gegaan.

[YvonneVP]

koboy schreef op maandag 4 mei 2026 @ 09:14:
[...]


Batterijen uit PV vullen hoeft niet het meest winstgevende te zijn!
Bij teruglevering kleiner dan afname is de waarde van een teruggeleverde kWh gelijk aan die van een afgenomen kWh, dus inclusief BTW en EB en toeslag (in geval van zonneplan).
De 80% RTE is dus OOK van toepassing op de EB component, wat betekent dat je al ongeveer 2 cent winst moet maken op het EPEX deel om alleen de RTE over de EB te compenseren!

Edit: dat van die waarde geldt natuurlijk ook voor de waarde van stroom uit de accu. Ook stroom ingekocht tijdens all-in negatieve uren moet je voor maximale winst dumpen op het duurste moment en niet mee gaan NOMmen.

Heel bot gezegd: met een dynamisch contract is vrijwel elke notie van NOM geld weggooien. Er zijn 2 situaties waarin dit niet zo is:
1. Meer teruglevering dan afname
2. In de smalle prijsband tussen negatieve verkoopprijs en all-in negatieve prijs die je hebt bij leveranciers die de inkoopvergoeding niet teruggeven.
Maar in beide gevallen ga je NOMmen door de PV te regelen niet de accu.

Als je met het verhandelen van stroom wilt verdienen dan zal je ook een grotere capaciteit moeten hebben zodat handelen ook echt zin heeft. Met iets van 6,nogwat kwh haal je ook flink wat besparing binnen als je de batterij vol gooit tijdens goedkope, of nog beter negatieve uren, of van je PV. Die stroom kun je tot de andere dag gebruiken, en dan heb je dus nauwelijks verbruik. Voor dat ene jaartje dat handelen nog nut heeft ga ik in ieder geval geen grote investering doen, die ik in die paar maanden die we nog hebben tot de saldering verdwijnt never nooit terug zal verdienen.

[Hippe Lip]

Pakhaas schreef op maandag 4 mei 2026 @ 06:49:
Momenteel is dit (NOM) niet het meest winstgevende. Dat is dynamisch handelen.

Hippe Lip schreef op maandag 4 mei 2026 @ 21:29:
@Pakhaas
Ook als je PV op een gemiddelde dag meer opwekt dan je in je batterijen kwijt kan en ruim meer is dan je in een etmaal zelf verbruikt?

Pakhaas schreef op maandag 4 mei 2026 @ 21:33:
Waarom zou dat het anders maken?

Waarom dat het anders maakt? Dat zal ik je vertellen, @Pakhaas. Het duurde even voordat ik het doorhad.

Je uitleg in de diverse posts hierboven (na de post van gisteren 21:33) lijken niet te kloppen. En sorry dat ik het moet zeggen, maar je komt nog niet eens in de buurt, ook al klonk het in eerste instantie aardig geloofwaardig.

Eerst even wat feiten.

1. Ik ben netto gebruiker, dus neem in een jaar meer af dan ik teruglever, waardoor ik ook alle belastingen kan verrekenen bij het terugleveren.
2. Als de stroom 20 cent inkoop kost, dan moet die verkoop minimaal 20/0,8 (RTE) + 2,5 (inkoopvergoeding) = 27,5 cent opleveren voor break even. Dat is een spread van 37,5%. Bij een lagere stroomprijs wordt dat nog meer: bij 10 cent zelfs 50% en dan verdien ik dus nog geen cent, dus de spread moet hoger zijn dan dat. En dan heb ik de afschrijving van de batterij nog niet eens meegerekend.

Dan terug naar het nu. Dit is de grafiek van vandaag. En dan heb ik gekozen voor 16 kwartieren inkoop en 12 kwartieren verkoop.



Op een dag als vandaag zou ik dan niets inkopen en niets verkopen als ik jouw advies volg omdat ik die spread van 37,5% lang niet haal.
En omdat je zegt dat ik ook geen NOM moet draaien, doe ik nix met de vulling van mijn batterijen en moet ik alle 24 uren stroom inkopen voor ruim 27 cent x 500W x 24 uur = 3,25 euro volgens jou:

Pakhaas schreef op maandag 4 mei 2026 @ 22:48:
NOM is en blijft nu nee, puur economisch bekeken. Goedkope uren laden, dure uren ontladen.

Intussen vullen mijn panelen zich zelfs op een druilerige dag als gisteren voldoende om nog 2 uren terug te kunnen leveren aan het net, wat me 20-22 cent per kWh opleverde: 4,8 kW x 2 uur x 21 cent = 2 euro en houd ik voldoende over om de nacht door te komen tot de PV weer op gang komt.

Ergo:
Zou ik jouw redenering volg dan kost vandaag me 3,25.
Als ik eigenwijs ben en wel NOM draai en bovendien tijdens de 2 duurste uren teruglever vandaag tegen ruim 30 (piektarief vandaag) - 2,5 (terugleverkosten) = 27,5 cent x 4,8 kW dan kost me dat nix in het verbruik (NOM) en vang ik zelfs ca. 2,65 euro voor het terugleveren van het overschot van de dag.
Dat is een verschil van bijna 6 euro op één dag!
En met jouw advies herhaalt iets soortgelijks zich elke dag dat die spread niet bereikt wordt. Dat gaat me dus een hoop geld kosten.

Daarom ben ik blij met mijn NOM en lever ik vaak 3 tot 4 uur per etmaal terug tegen de dan hoogste prijzen.
Ja, er zullen dagen zijn dat ik wél die spread haal en dan kan ik kijken of in- en verkoop die dag wél rendabel kunnen zijn. Maar dan moet het dus zó rendabel zijn dat het de winst die ik hierboven beschrijf nog eens overstijgt.

[gielz]

Mistraller schreef op dinsdag 5 mei 2026 @ 02:02:
Ik voel me ergens heel dom, maar de Gielz integratie, al dan niet met proxy, krijg ik niet soepel werkend en is bij mij bijzonder instabiel.
Ik heb alles volgens de instructies ingericht, de data van beide zendures verschijnt in het dashboard, HEMS is uitgevinkt; en beide hebben een "uitstekende" wifi verbinding.
So far so good....Echter is mijn hele HA daarna een heel stuk meer unresponsive, en ik zie ook steeds de connectie wegschieten, dan is de data op het dashboard tijdelijk op unavailable. (gaps in de graphs).
Ik kan in het Gielz dash "Snel ontladen en snel Opladen" activeren; en dan worden de ingestelde waardes toegepast.
NOM, handmatig doet echter niets. De zendures blijven op standby staan.

Ik had het nachtje eerder ook al getest, en toen was in de ochtend mijn HA gecrashed.

NodeRed heb ik als addon app geinstalleerd binnen ha.
Mijn HA draaide tot nu toe soepel in een KVM up een ubuntu laptop (vraag me af of dit er iets toedoet maar goed)

Om nodeRed even uit te sluiten heb ik de flow gedisabled en in Gielz het IP van 1 zendure ingesteld.
Verbinding lijkt dan iets stabieler, maar ook hier kan ik niet Handmatig een wattage instellen, NOM doen, slechts max ontladen en max laden. En opvragen van de automations pagina in de settings duurt ineens dik 10 seconden.

Ik heb van alle files de NL versie gebruikt. En overal de nieuwste versie.

Ik heb geen idee waar dit nu aan ligt, het lijkt wel een te zware integratie voor mijn HA? Nooit eerder gezien dit gedrag. Maar gekke is dus ook dat ik maar een paar modi werkend kan krijgen. (handmatig had het zeker moeten doen)

De automation heb ik nog omgezet naar trigger op de P1 sensor ipv die 5 seconden trigger om te kijken wat het doet; maar lijkt eerder slechter te werken (dacht dat ik dit begrepen had uit het grote zendure topic; omdat ik nog een dsmr4 heb leek me dit zinvol.

Als je bepaalde sturingen doet moet je dit terug zien in het logbook. Hoe ziet deze er uit?

En installeer even https://www.home-assistant.io/integrations/systemmonitor/

[Pakhaas]

@Hippe Lip je mist in je berekening de opportunity costs die je hebt als je PV overschot opslaat in je batterij voor later verbruik. Overschot van je PV is niet gratis. Die vertegenwoordigd een prijs die je anders had gekregen als je het direct had teruggeleverd zonder RTE verliezen. Verder wil ik het hier bij laten. Dit topic gaat voornamelijk over HA icm Zendure.

[Mimiix]

Mistraller schreef op dinsdag 5 mei 2026 @ 02:02:
Ik voel me ergens heel dom, maar de Gielz integratie, al dan niet met proxy, krijg ik niet soepel werkend en is bij mij bijzonder instabiel.
Ik heb alles volgens de instructies ingericht, de data van beide zendures verschijnt in het dashboard, HEMS is uitgevinkt; en beide hebben een "uitstekende" wifi verbinding.
So far so good....Echter is mijn hele HA daarna een heel stuk meer unresponsive, en ik zie ook steeds de connectie wegschieten, dan is de data op het dashboard tijdelijk op unavailable. (gaps in de graphs).
Ik kan in het Gielz dash "Snel ontladen en snel Opladen" activeren; en dan worden de ingestelde waardes toegepast.
NOM, handmatig doet echter niets. De zendures blijven op standby staan.

Ik had het nachtje eerder ook al getest, en toen was in de ochtend mijn HA gecrashed.

NodeRed heb ik als addon app geinstalleerd binnen ha.
Mijn HA draaide tot nu toe soepel in een KVM up een ubuntu laptop (vraag me af of dit er iets toedoet maar goed)

Om nodeRed even uit te sluiten heb ik de flow gedisabled en in Gielz het IP van 1 zendure ingesteld.
Verbinding lijkt dan iets stabieler, maar ook hier kan ik niet Handmatig een wattage instellen, NOM doen, slechts max ontladen en max laden. En opvragen van de automations pagina in de settings duurt ineens dik 10 seconden.

Ik heb van alle files de NL versie gebruikt. En overal de nieuwste versie.

Ik heb geen idee waar dit nu aan ligt, het lijkt wel een te zware integratie voor mijn HA? Nooit eerder gezien dit gedrag. Maar gekke is dus ook dat ik maar een paar modi werkend kan krijgen. (handmatig had het zeker moeten doen)

De automation heb ik nog omgezet naar trigger op de P1 sensor ipv die 5 seconden trigger om te kijken wat het doet; maar lijkt eerder slechter te werken (dacht dat ik dit begrepen had uit het grote zendure topic; omdat ik nog een dsmr4 heb leek me dit zinvol.

Op wat voor hardware draait HA (SSD/HDD, CPU)? Ik vermoed dat je HA host gewoon te traag is om bij te blijven. Een ander issue kan een defecte ethernet kabel zijn, waardoor de throughput fout gaat. Eventueel zou een DHCP issue kunnen spelen, waarbij je meerdere devices met hetzelfde IP hebt maar dat is wel heel ver gezocht.

[Mistraller]

gielz schreef op dinsdag 5 mei 2026 @ 07:13:
[...]


Als je bepaalde sturingen doet moet je dit terug zien in het logbook. Hoe ziet deze er uit?

En installeer even https://www.home-assistant.io/integrations/systemmonitor/
[Afbeelding]

Goeie tip; ik had inderdaad wel naar de resources gekeken maar ik had inderdaad nog geen goede history. Uit de logs lijken simpelweg de acties te missen.

Mimiix schreef op dinsdag 5 mei 2026 @ 08:14:
[...]


Op wat voor hardware draait HA (SSD/HDD, CPU)? Ik vermoed dat je HA host gewoon te traag is om bij te blijven. Een ander issue kan een defecte ethernet kabel zijn, waardoor de throughput fout gaat. Eventueel zou een DHCP issue kunnen spelen, waarbij je meerdere devices met hetzelfde IP hebt maar dat is wel heel ver gezocht.

Uiteraard ook mijn eerste gedachte. Die laptop waar het geheel op draait is al een oudje inderdaad. Maar met 900 entiteiten, ZHA, influx, grafana, een heleboel kleine integraties, en relatief eenvoudige automations tot nu toe altijd als een zonnetje.
Draait op een SSD. duplicate IP gaat je HA niet van op z'n gat Maar nee, ik heb de zendures een reserved IP in de router gegeven en ik kan ze verder prima zien in de app. En ik heb nooit netwerk issues gehad, zou sterk zijn als dat nu ineens aan het licht komt.

Echter: Resources lijkt wel de basis te zijn van de problemen. Ik zag dat hij enorm heeft staan swappen, tot ongeveer 6u vannacht, toen was ha core volgens mij gecrashed. En toen had ik dus node-red al gestopt en gielz naar 1 zendure laten kijken.
Helaas is ram uitbreiding voor die laptop bizar duur. Ik had 2GB toegewezen aan de VM, omdat de host slechts 4gb heeft. Nu de vm naar 2,5gig gezet en dat lijkt wel te helpen.
Dus ik hou het even in de gaten. Het lijkt wel by far de meest resource intensieve toevoeging op mijn HA instance die ik tot nu toe gezien heb, en dat zag ik niet aankomen; ik meen dat er geen minimale system resources waren opgegeven. Als blijkt dat ik daaronder zit is het misschien slim om in de prerequisites op te nemen. Dan zal ik nog wel eens meer testen, ik heb nog een andere laptop waar nieuwer type geheugen in gaat (en ook al zit). Reden voor laptop? Backup power

Dus ik ga het nog eens met de system monitor integration bekijken.

Tot zover alvast bedankt voor het meedenken!


Edit: Node-RED weet aangezet, en sommige stappen in de flow duren naar mijn idee wel érg lang . Gekke is dat het lijkt dat ie met zendure 3 wil connecten, maar die staat gewoon op "". (Call 3 zendure API; econn reset)
Swap usage in HA loopt weer op. Lijkt wel een memory leak?

[core-ssh ~]$ free -h
total used free shared buff/cache available
Mem: 2.4G 1.5G 36.1M 4.1M 864.6M 989.7M
Swap: 815.1M 348.4M 466.7M

[ Voor 7% gewijzigd door Mistraller op 05-05-2026 10:46 ]

[Hippe Lip]

Pakhaas schreef op dinsdag 5 mei 2026 @ 07:53:
@Hippe Lip je mist in je berekening de opportunity costs die je hebt als je PV overschot opslaat in je batterij voor later verbruik. Overschot van je PV is niet gratis. Die vertegenwoordigd een prijs die je anders had gekregen als je het direct had teruggeleverd zonder RTE verliezen.

Je hebt gelijk, @Pakhaas. Die heb ik gemist.

Verder wil ik het hier bij laten. Dit topic gaat voornamelijk over HA icm Zendure.

[ Voor 11% gewijzigd door Hippe Lip op 05-05-2026 12:11 ]

[koboy]

Hippe Lip schreef op dinsdag 5 mei 2026 @ 03:41:
[...]


[...]


[...]


Waarom dat het anders maakt? Dat zal ik je vertellen, @Pakhaas. Het duurde even voordat ik het doorhad.

Je uitleg in de diverse posts hierboven (na de post van gisteren 21:33) klopt niet. En sorry dat ik het moet zeggen, maar je komt nog niet eens in de buurt, ook al klonk het in eerste instantie aardig geloofwaardig.

Eerst even wat feiten.

1. Ik ben netto gebruiker, dus neem in een jaar meer af dan ik teruglever, waardoor ik ook alle belastingen kan verrekenen bij het terugleveren.
2. Als de stroom 20 cent inkoop kost, dan moet die verkoop minimaal 20/0,8 (RTE) + 2,5 (inkoopvergoeding) = 27,5 cent opleveren voor break even. Dat is een spread van 37,5%. Bij een lagere stroomprijs wordt dat nog meer: bij 10 cent zelfs 50% en dan verdien ik dus nog geen cent, dus de spread moet hoger zijn dan dat. En dan heb ik de afschrijving van de batterij nog niet eens meegerekend.

Dan terug naar het nu. Dit is de grafiek van vandaag. En dan heb ik gekozen voor 16 kwartieren inkoop en 12 kwartieren verkoop.

[Afbeelding]

Op een dag als vandaag zou ik dan niets inkopen en niets verkopen als ik jouw advies volg omdat ik die spread van 37,5% lang niet haal.
En omdat je zegt dat ik ook geen NOM moet draaien, doe ik nix met de vulling van mijn batterijen en moet ik alle 24 uren stroom inkopen voor ruim 27 cent x 500W x 24 uur = 3,25 euro volgens jou:


[...]


Intussen vullen mijn panelen zich zelfs op een druilerige dag als gisteren voldoende om nog 2 uren terug te kunnen leveren aan het net, wat me 20-22 cent per kWh opleverde: 4,8 kW x 2 uur x 21 cent = 2 euro en houd ik voldoende over om de nacht door te komen tot de PV weer op gang komt.

Ergo:
Zou ik jouw redenering volg dan kost vandaag me 3,25.
Als ik eigenwijs ben en wel NOM draai en bovendien tijdens de 2 duurste uren teruglever vandaag tegen ruim 30 (piektarief vandaag) - 2,5 (terugleverkosten) = 27,5 cent x 4,8 kW dan kost me dat nix in het verbruik (NOM) en vang ik zelfs ca. 2,65 euro voor het terugleveren van het overschot van de dag.
Dat is een verschil van bijna 6 euro op één dag!
En met jouw advies herhaalt iets soortgelijks zich elke dag dat die spread niet bereikt wordt. Dat gaat me dus een hoop geld kosten.

Daarom ben ik blij met mijn NOM en lever ik vaak 3 tot 4 uur per etmaal terug tegen de dan hoogste prijzen.
Ja, er zullen dagen zijn dat ik wél die spread haal en dan kan ik kijken of in- en verkoop die dag wél rendabel kunnen zijn. Maar dan moet het dus zó rendabel zijn dat het de winst die ik hierboven beschrijf nog eens overstijgt.

Ook @YvonneVP
Als de winkel die dag geen wc papier geleverd kreeg en jij hebt nog een pallet wc papier liggen, wat is dan voordeliger: je pakken voor 10 euro aan de buren die in paniek zijn verkopen en de dagen erna tegen gewone prijs in de winkel een enkel pakje kopen, of dat pallet houden en zelf gebruiken het half jaar erna?
Eerste is handelen, tweede is NOM de accu legen....
Over inkopen op het goedkoopste moment waren we het eens.....

Bij mij doet de accu vandaag helemaal niets omdat de spread te klein is. De laadverliezen zijn dusdanig dat ik fractioneel goedkoper uit ben dan mijn eigen stroom opslaan of handelen. N.B. ook ik ben een netto gebruiker, en volgend jaar verwacht ik dat het aantal handelsdagen zeer beperkt zal zijn.

Maar ook voor mij hier een einde aan de off-topic discussie. Prima als je uit ideologische motieven NOM draait, net als de keuze voor samenom (er van uitgaand dat er geen winstdeling ofzo onder de deelnemers is), maar het is niet financieel de voordeligste.

[Hippe Lip]

@koboy en @Pakhaas
Ja, het begint langzaam door te dringen. Het is een andere manier van denken. En die hoort bij het onderwerp van dit topic overigens
Zonder die gedachte en het besef waar je mee bezig bent zijn de dingen hier niet van veel waarde; veel minder in elk geval.

koboy schreef op dinsdag 5 mei 2026 @ 12:02:
[...]
Prima als je uit ideologische motieven NOM draait, net als de keuze voor samenom (er van uitgaand dat er geen winstdeling ofzo onder de deelnemers is), maar het is niet financieel de voordeligste.

Klopt. Financieel voordeel is niet de bron van elke keuze; ideologie is er ook eentje
Punt erachter.

[ctrl-tab]

Mistraller schreef op dinsdag 5 mei 2026 @ 10:24:
[...]

Goeie tip; ik had inderdaad wel naar de resources gekeken maar ik had inderdaad nog geen goede history. Uit de logs lijken simpelweg de acties te missen.

[...]

Uiteraard ook mijn eerste gedachte. Die laptop waar het geheel op draait is al een oudje inderdaad. Maar met 900 entiteiten, ZHA, influx, grafana, een heleboel kleine integraties, en relatief eenvoudige automations tot nu toe altijd als een zonnetje.
Draait op een SSD. duplicate IP gaat je HA niet van op z'n gat Maar nee, ik heb de zendures een reserved IP in de router gegeven en ik kan ze verder prima zien in de app. En ik heb nooit netwerk issues gehad, zou sterk zijn als dat nu ineens aan het licht komt.

Echter: Resources lijkt wel de basis te zijn van de problemen. Ik zag dat hij enorm heeft staan swappen, tot ongeveer 6u vannacht, toen was ha core volgens mij gecrashed. En toen had ik dus node-red al gestopt en gielz naar 1 zendure laten kijken.
Helaas is ram uitbreiding voor die laptop bizar duur. Ik had 2GB toegewezen aan de VM, omdat de host slechts 4gb heeft. Nu de vm naar 2,5gig gezet en dat lijkt wel te helpen.
Dus ik hou het even in de gaten. Het lijkt wel by far de meest resource intensieve toevoeging op mijn HA instance die ik tot nu toe gezien heb, en dat zag ik niet aankomen; ik meen dat er geen minimale system resources waren opgegeven. Als blijkt dat ik daaronder zit is het misschien slim om in de prerequisites op te nemen. Dan zal ik nog wel eens meer testen, ik heb nog een andere laptop waar nieuwer type geheugen in gaat (en ook al zit). Reden voor laptop? Backup power

Dus ik ga het nog eens met de system monitor integration bekijken.

Tot zover alvast bedankt voor het meedenken!


Edit: Node-RED weet aangezet, en sommige stappen in de flow duren naar mijn idee wel érg lang . Gekke is dat het lijkt dat ie met zendure 3 wil connecten, maar die staat gewoon op "". (Call 3 zendure API; econn reset)
Swap usage in HA loopt weer op. Lijkt wel een memory leak?

[core-ssh ~]$ free -h
total used free shared buff/cache available
Mem: 2.4G 1.5G 36.1M 4.1M 864.6M 989.7M
Swap: 815.1M 348.4M 466.7M

Met alle respect, zou je niet een upgrade doen van je setup? De laptop staat als ik het zo hoor niet in verhouding tot de dure batterij die je ermee tracht aan te sturen. Hij presteert blijkbaar niet, maar zal ook veel meer stroom verbruiken dan een modernere opzet.
Een simpele mini pc met een wat oudere celeron/pentium (bv 5005, 4105) en een streepje geheugen van 16gb kost je niet veel. Zeker niet bij ali. Of je gaat de N100 zelfbouw route met een mini itx bordje, zit je zeker goed.

Ik heb me wel vaak afgevraagd of deze automation niet sneller zou zijn in python, maar ik draai zelf op overkill hardware dus merk er niet zo veel van. Wat ik ervan lees is dat LUA eigenlijk sneller zou moeten zijn. Maar kan me ook voorstellen dat HA niet geoptimaliseerd is voor een automation van 1300+ regels ?

edit ; dacht dat homeassistant automations onder water op lua draaiden, maar lijkt niet zo te zijn

[R1chardTM]

Ja zou je aanraden een kleine investering te doen in wat meer geschikte hardware. Ik draai mijn HA al jaren op een Raspberry Pi 3, kost weinig doet een hoop. Gebruikt ook zeer weinig stroom. Zou nu voor een iets modernere variant kiezen om wat meer toekomst proof te zijn. Of als je tegelijk HA wilt ondersteunen de HA green kopen.

[R.K]

Laatst deze thin cliënt gekocht met voorgeïnstalleerde HA. Draait als een zonnetje.

https://www.marktplaats.n...tm_campaign=socialbuttons

[Mistraller]

ctrl-tab schreef op dinsdag 5 mei 2026 @ 13:20:
[...]


Met alle respect, zou je niet een upgrade doen van je setup? De laptop staat als ik het zo hoor niet in verhouding tot de dure batterij die je ermee tracht aan te sturen. Hij presteert blijkbaar niet, maar zal ook veel meer stroom verbruiken dan een modernere opzet.
Een simpele mini pc met een wat oudere celeron/pentium (bv 5005, 4105) en een streepje geheugen van 16gb kost je niet veel. Zeker niet bij ali. Of je gaat de N100 zelfbouw route met een mini itx bordje, zit je zeker goed.

Ik heb me wel vaak afgevraagd of deze automation niet sneller zou zijn in python, maar ik draai zelf op overkill hardware dus merk er niet zo veel van. Wat ik ervan lees is dat LUA eigenlijk sneller zou moeten zijn. Maar kan me ook voorstellen dat HA niet geoptimaliseerd is voor een automation van 1300+ regels ?

Een mini PC heeft geen ingebakken UPS. Een laptop met een goede accu is gewoon ideaal, en het stroomverbruik is echt heel laag. Stroom eraf? Ding draait nog 2 uur door, stuurt me keurig een sms en als ik terug sms dat ie down moet gaan dan doet ie dat netjes. (Goed, offtopic hier) T'is een oude business laptop.
Tot aan de Zendure presteerde HA echt optimaal, nooit problemen gehad met wat dan ook. Dus dan ga ik niks vervangen, lijkt me logisch. HA draait dus wel binnen een KVM op ubuntu, dus geen baremetal config.

Dat gezegd hebbende, vanwege die peperdure ddr2 4gb bankjes was ik al aan het kijken naar een upgrade, we hebben hier nog een laptop die wel veel nieuwer is maar niet naar win11 kan dus dat wordt de opvolger. Zeker ga ik dat doen, don't worry. Waarom ik de HA vm niet op mijn NAS draai? Die nas staat in de meterkast, terwijl ik op zolder laptop met HA heb vanwege de verbindingen met de PV omvormers (RS485 / BT) en omdat dat een betere plek is voor mijn Zigbee coordinator.

NB: Ik denk dat mijn 6730b laptop wel ruimer in de resources zit dan een RPi 3 dus dat valt me dan wel weer op. Als het op een RPi3 goed draait; zou ik persoonlijk zeggen dat het bij mij ook niet bijzonder slecht zou moeten werken.

Mijn bijdrage is ook meer om aan te stippen dat de automation een behoorlijk zware wissel trekt als je geen heel ruime resources hebt, is ook ter lering voor anderen.
De meesten met HA beginnen klein immers. (Ik ben op een rpi model 1 begonnen )

Ik heb nu node-red op mijn nas draaien, tot nu toe blijft alles werken en ook de states gaan goed zie ik. (Ik doe nu NOM)
Ik zie nog wel gaps maar zolang het blijft werken tot ik de laptop heb vervangen ben ik tevreden.
Gek genoeg uit het zich niet in memory of CPU usage in de system monitor, alleen swap valt me op dat die al op 50% usage zit.
Enfin; blij dat het in elk geval geen domme config fout lijkt te zijn.

[ Voor 9% gewijzigd door Mistraller op 05-05-2026 15:08 ]

[Ben(V)]

De resources gaan voornamelijk op aan Windows en je VM manager en niet aan HA.
En een machine die gaat swappen is niet geschikt voor wat je er mee doet.

[gielz]

Mistraller schreef op dinsdag 5 mei 2026 @ 14:58:
[...]

Mijn bijdrage is ook meer om aan te stippen dat de automation een behoorlijk zware wissel trekt als je geen heel ruime resources hebt, is ook ter lering voor anderen.

De gielz integratie gebruikt een simpele automatisering. Kijk je naar de regels dan zijn het er veel. Maar iedere trigger gaat naar zijn eigen onderdeel met een x aantal voorwaarde.

De impact is dus bijna nul op een Home Assistant installatie. Zelf hier nog een tijd gedraaid op een Synology DS212. Zou dus overal op kunnen draaien als het beter is dan een aardappel.

[c0mplex1]

Voor wat het waard is...
Mijn volledige huis, incl. eigen ontwerp batterij automatisering, heb ik op een RPi5, 8GB mem en 128GB SD-kaart draaien en ik kan zeggen zonder enige haperingen o.i.d.
Voor mijn toepassingen is de RPi5 dus krachtig en snel genoeg.
(en nu niet gelijk de discussie gaan voeren waarom je geen PRi5 met SD-kaart moet gebruiken, want dat weet ik nu wel )

[R1chardTM]

Hier zelfs op een RPi 3 met een whopping 1GB geheugen (en ook op een SD 🙃 wel dagelijkse externe backup) en stuk meer integraties dan alleen Gielz. Ja je laptop blijft waarschijnlijk nog wel even draaien, maar je netwerk ook? Anders heb je er als nog niets aan.

Dus nee de automatisering is echt niet erg zwaar. Waarschijnlijk draaide je HA omgeving al net op het randje en is dit de druppel die de emmer doet overlopen.

[ Voor 35% gewijzigd door R1chardTM op 05-05-2026 17:34 ]

[wheli]

Dan om ook de andere kant te belichten, geen idee of het gerelateerd is, maar ik heb gisteravond na 4 reboots ivm wat tweaken mijn Rpi 4 doorgebrand. Er draaide natuurlijk meer dan alleen dit dashboard maar niet echt veel voor mijn gevoel.
Geen probleem, onderdeel van de hobby maar ik ga wel voor de rpi 5 denk ik.

[peterbier]

wheli schreef op dinsdag 5 mei 2026 @ 18:58:
Dan om ook de andere kant te belichten, geen idee of het gerelateerd is, maar ik heb gisteravond na 4 reboots ivm wat tweaken mijn Rpi 4 doorgebrand. Er draaide natuurlijk meer dan alleen dit dashboard maar niet echt veel voor mijn gevoel.
Geen probleem, onderdeel van de hobby maar ik ga wel voor de rpi 5 denk ik.

Draai al jaren een Raspberry Pi 4 met een samsung pro endurance sd kaart zonder problemen.
Omdat deze wat traag was nu draai ik HomeAssistant op een HP T530 (x86-64).
Die HP trekt ook z,n 3 a 4 watt.
De domotica draaide er al op maar nu ook de Zendure Fireson.
Het werkt perfect en snel.
Ik maak automatisch 1x per week een backup naar mijn Synology ds1520+ nas.
Misschien is z,n pctje wat.

[ctrl-tab]

wheli schreef op dinsdag 5 mei 2026 @ 18:58:
Dan om ook de andere kant te belichten, geen idee of het gerelateerd is, maar ik heb gisteravond na 4 reboots ivm wat tweaken mijn Rpi 4 doorgebrand. Er draaide natuurlijk meer dan alleen dit dashboard maar niet echt veel voor mijn gevoel.
Geen probleem, onderdeel van de hobby maar ik ga wel voor de rpi 5 denk ik.

Zou zelf altijd voor iets X86 gaan , omdat je dan meer performance en flexibiliteit krijgt.
Proxmox draai je bv al op een oude celeron j4105 en je krijgt er zoo veel flexibiliteit voor terug.
Het draaien van je HA in een vm biedt al zoveel voordelen, op gebied van backup/restore bijvoorbeeld.

[Mistraller]

gielz schreef op dinsdag 5 mei 2026 @ 16:04:
[...]


De gielz integratie gebruikt een simpele automatisering. Kijk je naar de regels dan zijn het er veel. Maar iedere trigger gaat naar zijn eigen onderdeel met een x aantal voorwaarde.

De impact is dus bijna nul op een Home Assistant installatie. Zelf hier nog een tijd gedraaid op een Synology DS212. Zou dus overal op kunnen draaien als het beter is dan een aardappel.

Ja dat was dus ook mijn verwachting eigenlijk, en daarom snap ik niet waarom het bij mij specifiek zo slecht werkt. Of er zit ergens heel erg veel vertraging wat de boel opknoopt of een conflict met iets wat ik al draai of zo.... memory leak door een automation vind ik ook onwaarschijnlijk. Nodered zelf zou je ook niet als boosdoener verwachten lijkt me, zoveel mensen die dat gebruiken. Apexcharts misschien die iets geks doet?

Ik heb zojuist in elk geval ff een range extender ertussen gezet, kijken of er toch slecht bereik is of zo, ondanks de melding dat de verbinding goed is. Maar de batterijtjes zijn nu leeg dus eerst wachten op zon tot er weer echt iets actief wordt. Ben benieuwd of HA morgenvroeg wel is blijven leven
Dochterlief heeft de opdracht gekregen om die oude laptop leeg te halen, upgrade is hoe dan ook een goed idee.

Nog wat data van HA:
Cpu usage avg 18%
Mem 61% (van 2,4GB)
Swap 51% (van 800MB)

[Mistraller]

R1chardTM schreef op dinsdag 5 mei 2026 @ 16:55:
Hier zelfs op een RPi 3 met een whopping 1GB geheugen (en ook op een SD 🙃 wel dagelijkse externe backup) en stuk meer integraties dan alleen Gielz. Ja je laptop blijft waarschijnlijk nog wel even draaien, maar je netwerk ook? Anders heb je er als nog niets aan.

Dus nee de automatisering is echt niet erg zwaar. Waarschijnlijk draaide je HA omgeving al net op het randje en is dit de druppel die de emmer doet overlopen.

Ik werk bij een financiële instelling, dus daar zijn we altijd bezig met een plan B
In de meterkast hangen modem, nas, switch, rpi en voordeurcamera, en de hoofdnode van mijn mesh aan een UPS. Die RPI doet de p1 data en diverse bedrade sensors (rook, PIR, watermeter, etc)
De laptop op zolder is met UTP aangesloten en blijft dus verbonden; zelfs de battery powered zigbee nodes blijven in principe draaien maar het halve mesh valt weg bij stroomuitval dus wordt onbetrouwbaar. Verder zit er een GSM modem met sim aan; als de stroom -en internet wegvallen dan krijg ik een SMS. En ik kan ook terug SMSen om commando's te geven. HA heeft uiteraard ook de status van de UPS en van zichzelf (AC of battery powered).
Ook kan ik bij stroomuitval volgens mij de offgrid poort aan zetten met HA. Moet ik nog even maken. Lokale wifi blijft immers draaien. (alleen nu ff niet met die range extender ertussen.)

Goed; zwaar offtopic, maar de Zendures passen wel perfect in mijn plaatje inzake mijn "technisch Noodpakket"

[RobTesla]

Mistraller schreef op dinsdag 5 mei 2026 @ 23:27:
[...]

Ik werk bij een financiële instelling, dus daar zijn we altijd bezig met een plan B
In de meterkast hangen modem, nas, switch, rpi en voordeurcamera, en de hoofdnode van mijn mesh aan een UPS. Die RPI doet de p1 data en diverse bedrade sensors (rook, PIR, watermeter, etc)
De laptop op zolder is met UTP aangesloten en blijft dus verbonden; zelfs de battery powered zigbee nodes blijven in principe draaien maar het halve mesh valt weg bij stroomuitval dus wordt onbetrouwbaar. Verder zit er een GSM modem met sim aan; als de stroom -en internet wegvallen dan krijg ik een SMS. En ik kan ook terug SMSen om commando's te geven. HA heeft uiteraard ook de status van de UPS en van zichzelf (AC of battery powered).
Ook kan ik bij stroomuitval volgens mij de offgrid poort aan zetten met HA. Moet ik nog even maken. Lokale wifi blijft immers draaien. (alleen nu ff niet met die range extender ertussen.)

Goed; zwaar offtopic, maar de Zendures passen wel perfect in mijn plaatje inzake mijn "technisch Noodpakket"

Welk O/S staat er op je laptop? Ik vermoed Windows? Zou je niet eens proberen met een Linux distro? Windows machines zijn zoveel slechter als server...

[MikeyMan]

Ben sinds dit weekend over op de (Standaard/Fireson) integratie. Vooral omdat HEMS zo'n slecht uitgevoerde aansturing van meervoudige accus heeft. De HA integratie gaat hier dan wel weer erg netjes mee om. Kan per accu min/max level aangeven... En bij laag vermogen laadt ie de accus om-en-om.

Draai simpel NOM, dus dat werkt voorlopig goed.
Heb ook nog geen enkele keer een storing van Zendure gezien.

Maar stiekem toch met een schuin oog aan het kijken naar de integratie van @gielz Vooral omdat deze niet afhankelijk is van de cloud. Enige nadeel is dat hier (nog?) geen support voor meerdere inverters is ingebouwd.

Nu kan daar natuurlijk de Node-Red achter gezet worden. Maar dan vraag ik mij af; voegt het toevoegen van extra lagen niet extra vertraging en/of kwetsbaarheid toe? Heb al Node Red draaien, in een aparte docker. En het spul is rock solid. Maar het wordt wel wat complex zo... Maar wellicht is mijn gevoel onjuist.

Eigenlijk ook jammer dat de standaard integratie alleen met de cloud werkt. Niet onbegrijpelijk natuurlijk.

[ Voor 57% gewijzigd door MikeyMan op 06-05-2026 09:05 ]

[wmc]

De legacy devices kunnen gewoon lokaal communiceren (https://github.com/Zendur...cal-Mqtt-(Legacy-Devices) ).

Als ik goed heb is de zenSDK per definitie lokaal, dus heb je helemaal geen cloud meer nodig.

[MikeyMan]

wmc schreef op woensdag 6 mei 2026 @ 09:17:
De legacy devices kunnen gewoon lokaal communiceren (https://github.com/Zendur...cal-Mqtt-(Legacy-Devices) ).

Als ik goed heb is de zenSDK per definitie lokaal, dus heb je helemaal geen cloud meer nodig.

Wacht... Als ik opnieuw de integratie installeer kan het wel lokaal...?

Das interessant... Wel weer een hoop spul hernoemen

De beschrijving is wel wat ambigu:
The configuration of local MQTT is only necessary for the Zendure Legacy devices: Hyper2000, Hub2000, Hub1200 and Ace1500. The newer devices SF800, SF800Pro and SF2400 do not need this, since they can communicate via zenSDK

Ik heb AC2400's. Dus niet necessary... Maar wel ondersteund? Even verder zoeken...

[ Voor 52% gewijzigd door MikeyMan op 06-05-2026 09:22 ]

[Mistraller]

RobTesla schreef op woensdag 6 mei 2026 @ 08:40:
[...]

Welk O/S staat er op je laptop? Ik vermoed Windows? Zou je niet eens proberen met een Linux distro? Windows machines zijn zoveel slechter als server...

Ik draai uiteraard geen Windows maar ubuntu en HA draait in een virtual machine (qemu-kvm).

[Ben(V)]

MikeyMan schreef op woensdag 6 mei 2026 @ 09:01:
Ben sinds dit weekend over op de (Standaard/Fireson) integratie. Vooral omdat HEMS zo'n slecht uitgevoerde aansturing van meervoudige accus heeft. De HA integratie gaat hier dan wel weer erg netjes mee om. Kan per accu min/max level aangeven... En bij laag vermogen laadt ie de accus om-en-om.

Draai simpel NOM, dus dat werkt voorlopig goed.
Heb ook nog geen enkele keer een storing van Zendure gezien.

Maar stiekem toch met een schuin oog aan het kijken naar de integratie van @gielz Vooral omdat deze niet afhankelijk is van de cloud. Enige nadeel is dat hier (nog?) geen support voor meerdere inverters is ingebouwd.

Nu kan daar natuurlijk de Node-Red achter gezet worden. Maar dan vraag ik mij af; voegt het toevoegen van extra lagen niet extra vertraging en/of kwetsbaarheid toe? Heb al Node Red draaien, in een aparte docker. En het spul is rock solid. Maar het wordt wel wat complex zo... Maar wellicht is mijn gevoel onjuist.

Eigenlijk ook jammer dat de standaard integratie alleen met de cloud werkt. Niet onbegrijpelijk natuurlijk.

De firesone integratie werk ook gewoon met ZenSDK.

[MikeyMan]

Ben(V) schreef op woensdag 6 mei 2026 @ 10:07:
[...]


De firesone integratie werk ook gewoon met ZenSDK.

Waar is dat verstopt dan?

ik heb in de (her) configuratie de toggle voor MQTT gevonden. Maar daar zie ik geen Zensdk terug...

Kan het ook niet terugvinden in de installatie stappen:
https://github.com/Zendure/Zendure-HA/wiki/Installation

MQTT is push vanuit de apparaten, ZenSDK is pull vanuit HA volgens mij... Voegt dat nog vertraging toe?

[ Voor 11% gewijzigd door MikeyMan op 06-05-2026 10:22 ]

[Ben(V)]

In het panel van de "Solarflow 2400 AC" in het veld "Control" kun je "Connection Mode " kiezen.
De opties zijn daar "Cloud" of "zenSDK".

[MikeyMan]

Ben(V) schreef op woensdag 6 mei 2026 @ 10:21:
In het panel van de "Solarflow 2400 AC" in het veld "Control" kun je "Connection Mode " kiezen.
De opties zijn daar "Cloud" of "zenSDK".

Jezus... Goed verstopt zeg! Had ook een generieke instelling kunnen zijn.

[Ben(V)]

Hoezo verstopt?
Is gewoon een simpele instelling.
Dat is het belangrijkste panel van de hele integratie, samen met die van de "Zendure Manager".

[ctrl-tab]

Ok ik heb een paar keer een oplossing benoemd voor DSMR4 gebruikers waar je de trigger van de automation wijzigt door deze te laten triggeren op een P1 sensor update.
Dit was lange tijd stabiel , maar ik was op vakantie dus eigenlijk geen grootverbruikers of grote pieken. Bij deze even op terug komen:

Inmiddels ben ik weer thuis van vakantie en heb ik toch meermaals gezien dat er spikes ontstaan waar de zendure constant zichzelf aan het corrigeren is.
Het lijkt erop dat een korstondige piek de initiatie is.

De oplossing met de P1 sensor update klinkt leuk, en zou in theorie goed moeten werken als de meter zich volledig aan de dsmr4 spec zou houden en het telegram altijd de actuele data representeert.
Dit lijkt niet het geval, en las al andere posts in deze thread die dat bevestigen. Bovendien heb ik sporadisch gezien dat er een wijziging in de sensor na 5 seconden plaats vond in plaats van 10 seconden. Dit laatste heeft verder geen directe impact gehad maar je ziet dat het niet super consistent is , althans bij mijn meter.
Zie onderstaande screenshots. Dit kan zo uren door gaan. Soms resolved het uit zichzelf, soms wordt het juist erger.

Een 15-20 seconden interval lijkt voor DSMR4 toch de beste oplossing. Dan baseer je je keuzes niet telkens op een enkel telegram , geef je meer rust voordat er beslissingen genomen worden.

Bedankt @gielz nog voor de support via dm.





Heb zelf een meter vervanging aangevraagd . Wil het gewoon goed zien werken.
Van de andere kant kan je je afvragen of dat beetje aan over- en under-shoots nou zo'n probleem is. Eigenlijk niet maarja je bent techneut of niet

[ Voor 5% gewijzigd door ctrl-tab op 06-05-2026 11:07 ]

[MikeyMan]

Ben(V) schreef op woensdag 6 mei 2026 @ 10:27:
Hoezo verstopt?
Is gewoon een simpele instelling.
Dat is het belangrijkste panel van de hele integratie, samen met die van de "Zendure Manager".

Nouja, zoals ik zei... Ik verwachtte hem op integratie-niveau.

Maar dit is ook wel zinnig, aangezien het per apparaat kan afwijken welke methode er gebruikt wordt.
Eens kijken wat er omvalt als ik de setting wijzig.

[Ben(V)]

ctrl-tab schreef op woensdag 6 mei 2026 @ 11:03:
Ok ik heb een paar keer een oplossing benoemd voor DSMR4 gebruikers waar je de trigger van de automation wijzigt door deze te laten triggeren op een P1 sensor update.
Dit was lange tijd stabiel , maar ik was op vakantie dus eigenlijk geen grootverbruikers of grote pieken. Bij deze even op terug komen:

Inmiddels ben ik weer thuis van vakantie en heb ik toch meermaals gezien dat er spikes ontstaan waar de zendure constant zichzelf aan het corrigeren is.
Het lijkt erop dat een korstondige piek de initiatie is.

De oplossing met de P1 sensor update klinkt leuk, en zou in theorie goed moeten werken als de meter zich volledig aan de dsmr4 spec zou houden en het telegram altijd de actuele data representeert.
Dit lijkt niet het geval, en las al andere posts in deze thread die dat bevestigen. Bovendien heb ik sporadisch gezien dat er een wijziging in de sensor na 5 seconden plaats vond in plaats van 10 seconden. Dit laatste heeft verder geen directe impact gehad maar je ziet dat het niet super consistent is , althans bij mijn meter.
Zie onderstaande screenshots. Dit kan zo uren door gaan. Soms resolved het uit zichzelf, soms wordt het juist erger.

Een 15-20 seconden interval lijkt voor DSMR4 toch de beste oplossing. Dan baseer je je keuzes niet telkens op een enkel telegram , geef je meer rust voordat er beslissingen genomen worden.

Bedankt @gielz nog voor de support via dm.

[Afbeelding]

[Afbeelding]

Heb zelf een meter vervanging aangevraagd . Wil het gewoon goed zien werken.
Van de andere kant kan je je afvragen of dat beetje aan over- en under-shoots nou zo'n probleem is. Eigenlijk niet maarja je bent techneut of niet

Je wilt helemaal niet dat die Zendure gaat reageren op snelle pieken.
Een Zendure heeft zelf een reactietijd van 3 to 5 seconden en gaat dus altijd naijlen en energie leveren als die allang niet meer gevraagd wordt(naijlen).

Ik heb hier een DSMR 5.0 meter en een Quooker, die verwarmt steeds met korte pieken waardoor de Zendure gaat leveren maar altijd te laat en te lang waardoor de energie het net opgaat, daar wordt je ook niet blij van

[RemmyB83]

Ben(V) schreef op woensdag 6 mei 2026 @ 11:45:
[...]


Je wilt helemaal niet dat die Zendure gaat reageren op snelle pieken.
Een Zendure heeft zelf een reactietijd van 3 to 5 seconden en gaat dus altijd naijlen en energie leveren als die allang niet meer gevraagd wordt(naijlen).

Ik heb hier een DSMR 5.0 meter en een Quooker, die verwarmt steeds met korte pieken waardoor de Zendure gaat leveren maar altijd te laat en te lang waardoor de energie het net opgaat, daar wordt je ook niet blij van

Soms moet je gewoon accepteren dat dingen niet perfect zijn. Gisteren ging hier de stoomreiniger door de woonkamer, en deze geeft de hele tijd korte piekjes. Leukste was mijn solar opwek was op dat moment ook nog eens laag, dus bij een piekje ontladen, en bij een dipje opladen. Nou dat werkt dus voor geen meter. Maarja echt belangrijk vind ik dat soort momentjes niet, zolang het in 90%van de tijd wel doet wat ik er van verwacht. 🙂

[ctrl-tab]

RemmyB83 schreef op woensdag 6 mei 2026 @ 12:07:
[...]

Soms moet je gewoon accepteren dat dingen niet perfect zijn. Gisteren ging hier de stoomreiniger door de woonkamer, en deze geeft de hele tijd korte piekjes. Leukste was mijn solar opwek was op dat moment ook nog eens laag, dus bij een piekje ontladen, en bij een dipje opladen. Nou dat werkt dus voor geen meter. Maarja echt belangrijk vind ik dat soort momentjes niet, zolang het in 90%van de tijd wel doet wat ik er van verwacht. 🙂

Als ik me niet vergis heb jij die trigger aangepast naar de sensor update?

Heb je het gedrag dat ik hierboven beschreef niet ervaren?

[Mimiix]

Ik heb getracht wat terug te zoeken, maar nog niet direct een antwoord kunnen vinden. Vergeef me dus als ik het gemist heb.

Ik heb in de Gielz integratie nu Dynamisch Nom ingesteld en de goedkoopste / duurste periodes ingesteld op 8 en 16. Ik zie dat ie op de goedkoopste momenten nu laad en op de duurdere momente ontlaad. Dat snap ik, maar ik begrijp niet goed wat ik hier het beste kan invullen. Waarom zou ik voor 8 kiezen ipv 4 bijvoorbeeld?

[RemmyB83]

ctrl-tab schreef op woensdag 6 mei 2026 @ 13:21:
[...]

Als ik me niet vergis heb jij die trigger aangepast naar de sensor update?

Heb je het gedrag dat ik hierboven beschreef niet ervaren?

Klopt ik heb hem toen idd aangepast. En bij een stabiel verbruik werkte hij goed. Maar zag ook af en toe het gedrag wat jij ziet. Leek wel als of hij ergens door nog steeds op de 5sec zat, of dat de de slimmemeter/batterij niet snel genoeg reageerde.

Ik heb mijn er toen verder niet in verdiept, aangezien mijn slimmemeter vervangen zou worden. En dat is inmiddels ook gebeurt.

[ctrl-tab]

RemmyB83 schreef op woensdag 6 mei 2026 @ 14:24:
[...]

Klopt ik heb hem toen idd aangepast. En bij een stabiel verbruik werkte hij goed. Maar zag ook af en toe het gedrag wat jij ziet. Leek wel als of hij ergens door nog steeds op de 5sec zat, of dat de de slimmemeter/batterij niet snel genoeg reageerde.

Ik heb mijn er toen verder niet in verdiept, aangezien mijn slimmemeter vervangen zou worden. En dat is inmiddels ook gebeurt.

Aah top. Wat merk je zelf aan verbetering sinds je upgrade?

[MikeyMan]

Overzetten van Cloud naar ZenSDK is naadloos verlopen. Merk niet echt verschil natuurlijk. Maar het lijkt te werken. Met dank aan @Ben(V)

Ben nog wel zoekende naar wat de pro's en cons zijn van:
- Cloud
- Zensdk
- MQTT

Push vs Pull. Afhankelijkheid zendure. Snelheid. Betrouwbaarheid. Etc. Maar voorlopig loopt het spulletje. Eerst de dashboards maar eens een beetje opschonen.

[RemmyB83]

ctrl-tab schreef op woensdag 6 mei 2026 @ 14:37:
[...]

Aah top. Wat merk je zelf aan verbetering sinds je upgrade?

Mijn verbruik is hier altijd wel redelijk stabiel, en behalve de kookplaat zag ik geen echte grote schommelingen.
Hier onder kun je zien dat het de eerste 10 dagen met de oude meter, minder vaak op 0 of lager was. Maar een echt groot duidelijk verschil om er een andere meter voor aan te schaffen heb ik niet.
Meterwissel was in mijn geval dan ook toeval, ookal heb ik vervolgens wel een verzwaring aangevraagd ivm de toekomst.


Edit, veel van de hier boven gedeelde staafdiagram hangt ook af van je verbruik, solaropstelling, en bijvoorbeeld het weer.
Je ziet bij mijn dan ook met de nieuwe meter een paar dagen dat dit onderuit gaat.

[ Voor 9% gewijzigd door RemmyB83 op 06-05-2026 15:16 ]

[DeKim]

Ik heb een dsmr 4.2 meter (de veelbesproken e350). Het valt mij op dat op het moment dat er een nieuwe meting van de p1 meter komt, deze al 10 seconde oud is. Alsof hij altijd het voorlaatste telegram doorstuurt. Ook als ik HA elke seconde de API laat uitlezen.

Dat betekent dus dat als een accu zou reageren op een verbruiker, je dat nog niet ziet in de volgende meting maar pas nog een meting later. Heb jij dat ook @ctrl-tab ?

Overigens heb ik nog geen thuisaccu. Ben me aan het inlezen om er straks eentje te kopen.

[ctrl-tab]

DeKim schreef op woensdag 6 mei 2026 @ 16:48:
Ik heb een dsmr 4.2 meter (de veelbesproken e350). Het valt mij op dat op het moment dat er een nieuwe meting van de p1 meter komt, deze al 10 seconde oud is. Alsof hij altijd het voorlaatste telegram doorstuurt. Ook als ik HA elke seconde de API laat uitlezen.

Dat betekent dus dat als een accu zou reageren op een verbruiker, je dat nog niet ziet in de volgende meting maar pas nog een meting later. Heb jij dat ook @ctrl-tab ?

Overigens heb ik nog geen thuisaccu. Ben me aan het inlezen om er straks eentje te kopen.

Ik heb zelf een Kaifa. Ik herken de 10 seconden oude telegrammen niet, volgens specs zou het telegram de laatste actuele status moeten zijn.
Dit lijkt in mijn geval ook niet altijd te kloppen, maar structureel 10 seconden is het zeker niet.

[jannus66]

Hallo, Ik gebruik de Gielz integratie, NOM, naar volle tevredenheid. Zit echter met 1 puntje; kan iemand mij in Jip en Janneke taal uitleggen wat de begrippen:
- opladen starten bij (staat nu op -200)
- oplaadmarge (staat nu op 50)
- ontladen bij (staat nu op 100)
- ontlaadmarge (staat nu op 5) betekenen?

Systeem:
Zendure SolarFlow 2400 AC+ (2.4 kWh) + 1x AB3000L (2.88 kWh)
7 panelen, hele dag zon (ZZW) (Fase 1)
3 fase DSMR 5 meter
eigen groep (Fase 2)
max oplaadvermogen 2000 W
max ontlaadvermogen 1500 W
Vast contract, Geen EV

[gast777]

jannus66 schreef op woensdag 6 mei 2026 @ 17:20:
Hallo, Ik gebruik de Gielz integratie, NOM, naar volle tevredenheid. Zit echter met 1 puntje; kan iemand mij in Jip en Janneke taal uitleggen wat de begrippen:
- opladen starten bij (staat nu op -200)
- oplaadmarge (staat nu op 50)
- ontladen bij (staat nu op 100)
- ontlaadmarge (staat nu op 5) betekenen?

Systeem:
Zendure SolarFlow 2400 AC+ (2.4 kWh) + 1x AB3000L (2.88 kWh)
7 panelen, hele dag zon (ZZW) (Fase 1)
3 fase DSMR 5 meter
eigen groep (Fase 2)
max oplaadvermogen 2000 W
max ontlaadvermogen 1500 W
Vast contract, Geen EV

Je kunt "Help tonen op dashboard" aanzetten. Dan zie je onderstaande uitleg. Laat maar horen als het dan nog niet duidelijk genoeg is.

[Panzer_V]

Wil toch even een compliment maken aan @gielz voor zijn integratie.

De afgelopen dagen heb ik mij suf gedacht om een oplossing te vinden voor de momenten dat in de vroege avonduren, na het koken en eten, de weckketel aangaat. Als die eenmaal op temp is gaat hij pendelen om op temp te blijven. Mijn panelen produceren in de avond nog 700 watt. Dussss, met de NOM modus gaat hij dus continu 'ontladen-standby-laden-standby-ontladen-etc.' doen. Met >50 schakelingen in 30 minuten.

Wat blijkt.....er is gewoon een 'SLIM ONTLADEN' modus. Kwestie van even handmatig de modus veranderen als de weckketel aangaat en nadien terugzetten.

bedankt @gielz !