Zendure producten in Home Assistant integreren deel 2

[Pakhaas]

hemertje schreef op zaterdag 4 april 2026 @ 18:04:
[...]


Of dat je iedere dag dit handmatig moet aanpassen of dat het systeem dit automatisch voor je overneemt en instelt n.a.v. de goedkope tijden van de dynamische tarieven ?

Opzich kan ik dit vol automatisch instellen, dat hij wat overlaat voor NOM, maar dit jaar is Dynamisch Handelen nog het meest economisch. Heb voor nu een knop op het dashboard, dat als ik daar op druk, gaat die maximaal ontladen tot 1.5kwh. Dat is dus handig, als er nog wat in zit wat ik kwijt wil. Beetje prutsen en uitvinden.

[gast777]

gielz schreef op zaterdag 4 april 2026 @ 18:12:
[...]
Met betrekking tot meer batterijen via node-red kan @gast777 dit beter even beantwoorden.

Wat ik gezien heb tijdens testen is dat de Gielz max 6 accu's ondersteunt. Als ik >6 heb in totaal, dan blijft de batterijen info ("per Batterij") op tab "Gezondheid" leeg.

Echter onder "Totaal" wordt "Aantal Batterijen" en "Totale Capaciteit" wel correct weergegeven.

[gast777]

Snelle test dmv gesimuleerde devices achter de proxy:

[ Voor 12% gewijzigd door gast777 op 04-04-2026 19:04 ]

[metalmarco]

gielz schreef op zaterdag 4 april 2026 @ 18:12:
[...]


Bedankt voor alle info! Zal dit hier ook even gaan testen heb je de offgrid op normal of eco stand? En wat als je de offgrid uit zet zie je dit dan daarna nog?

Met betrekking tot meer batterijen via node-red kan @gast777 dit beter even beantwoorden.

Offgrid staat op "eco" en als ik hem uit zet, dan heb ik het niet gezien. Daarom vermoed ik zelf dat het ergens uit de firmware van Zendure vandaan komt. Want zie in de app ook dat ie dan 'laad" in de grafiek.

Dus zou eventueel een "demper" mooi zijn om de "relais schakelingen" te verlagen. Zoals eerder door Gast777 is aangeven, door alleen te tellen van ontladen naar laden en vs ipv "status" wijziging.

Nu ook met de proxy versie 20160402 met het ontladen van 1 van de 3 sets, zie ik op een andere set "laden" en dan verspringt de "resterende ontlaadtijd" ook regelmatig van "niet aan het ontladen" en "xx:xx" Wat ook denk ik door de "offgrid instelling" komt denk ik.



En hier is hij echt aan het ontladen richting de woning.

[ Voor 16% gewijzigd door metalmarco op 04-04-2026 19:48 ]

[hemertje]

hemertje schreef op vrijdag 3 april 2026 @ 18:55:
heb de ac2400+'s nu een dikke week draaien en getest dmv Zendure Zenki.

wil uiteindelijk 1 kapitein in huis dus wil via home assistant gaan monitoren en sturen
waar kan ik de voor-, en nadelen van Gielz en zenSDK tegen elkaar afwegen?

Iemand nog tips ter overweging?

Thx!

[gast777]

metalmarco schreef op zaterdag 4 april 2026 @ 19:44:
[...]

Nu ook met de proxy versie 20160402 met het ontladen van 1 van de 3 sets, zie ik op een andere set "laden" en dan verspringt de "resterende ontlaadtijd" ook regelmatig van "niet aan het ontladen" en "xx:xx" Wat ook denk ik door de "offgrid instelling" komt denk ik.

De "Modus" (laden/ontladen/standby) wordt door exact 3 items bepaald:
gridInputPower
outputHomePower
acMode

Kun je de grafiek laten zien van gridInputPower en outputHomePower en "Modus" tijdens het probleem?

Voor acMode is er geen sensor in HA van Gielz, maar kunnen we wel maken uiteraard, om die ook te volgen. Als de Zendure App in het donker "Laden" aangeeft voor een device, dan staat acMode misschien zelfs op Laden (1). Dat zou wel raar zijn. Ik ging er vanuit dat acMode alleen door de Gielz REST gezet wordt en er verder niemand aankomt.

In de huidige versie van de proxy wordt de acMode van Zendure1 genomen als acMode van het hele virtuele device (proxy) en aan HA Gielz doorgegeven, omdat ik ervan uitga zat ze alle drie altijd hetzelfde zijn (er is momenteel nog geen slaapmodus voor 3 devices waardoor verschil zou kunnen ontstaan).

Edit: Oh wacht, gridInputPower en outputHomePower hebben we ook niet apart in een HA sensor. Die zal dan ook gemaakt moeten worden om die in een grafiek te kunnen zetten.

Deze hebben we alleen gecombineerd, maar dat zegt niet zoveel in dit geval misschien.

code:

- name: "Zendure 2400 AC Vermogen Aansturing"
        value_template: >
          {% set opladen = value_json['properties']['gridInputPower'] | int %}
          {% set ontladen = - (value_json['properties']['outputHomePower'] | int) %}
          {% if opladen != 0 %}
            {{ opladen }}
          {% else %}
            {{ ontladen }}
          {% endif %}
        unique_id: Zendure_2400_AC_Vermogen_Aansturing
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power

Hier nog de HA Gielz "Modus":

code:

- name: "Zendure 2400 AC Modus"
        value_template: >
          {% set ac_mode = value_json['properties']['acMode'] | int %}
          {% set input_power = value_json['properties']['gridInputPower'] | int %}
          {% set output_power = value_json['properties']['outputHomePower'] | int %}

          {% if ac_mode == 1 and input_power > 0 %}
           Opladen
          {% elif ac_mode == 2 and output_power > 0 %}
           Ontladen
          {% else %}
           Standby
          {% endif %}
        unique_id: Zendure_2400_AC_Modus

Ik zal eens even wat sensors voor je in elkaar knutselen die je in je package kan toevoegen voor monitoring.

[ Voor 39% gewijzigd door gast777 op 04-04-2026 21:07 ]

[gielz]

gast777 schreef op zaterdag 4 april 2026 @ 20:56:
[...]

De "Modus" (laden/ontladen/standby) wordt door exact 3 items bepaald:
gridInputPower
outputHomePower
acMode

Kun je de grafiek laten zien van gridInputPower en outputHomePower en "Modus" tijdens het probleem?

Voor acMode is er geen sensor in HA van Gielz, maar kunnen we wel maken uiteraard, om die ook te volgen. Als de Zendure App in het donker "Laden" aangeeft voor een device, dan staat acMode misschien zelfs op Laden (1). Dat zou wel raar zijn. Ik ging er vanuit dat acMode alleen door de Gielz REST gezet wordt en er verder niemand aankomt.

In de huidige versie van de proxy wordt de acMode van Zendure1 genomen als acMode van het hele virtuele device (proxy) en aan HA Gielz doorgegeven, omdat ik ervan uitga zat ze alle drie altijd hetzelfde zijn (er is momenteel nog geen slaapmodus voor 3 devices waardoor verschil zou kunnen ontstaan).

Edit: Oh wacht, gridInputPower en outputHomePower hebben we ook niet apart in een HA sensor. Die zal dan ook gemaakt moeten worden om die in een grafiek te kunnen zetten.

Deze hebben we alleen opgeteld, maar dat zegt niet zoveel in dit geval misschien.

code:

- name: "Zendure 2400 AC Vermogen Aansturing"
        value_template: >
          {% set opladen = value_json['properties']['gridInputPower'] | int %}
          {% set ontladen = - (value_json['properties']['outputHomePower'] | int) %}
          {% if opladen != 0 %}
            {{ opladen }}
          {% else %}
            {{ ontladen }}
          {% endif %}
        unique_id: Zendure_2400_AC_Vermogen_Aansturing
        unit_of_measurement: "W"
        state_class: measurement
        device_class: power

Ik zal eens even wat sensors voor je in elkaar knutselen die je in je package kan toevoegen voor monitoring.

Mijn vermoeden is dat de Zendure_2400_AC_Vermogen_Aansturing (Zendure_Power) 99 van de 100 keer goed is maar problemen heeft met het Offgridstopcontact. Nu is dit makkelijk op te lossen maar dan ga je weer problemen krijgen met aangesloten zonnepanelen. Zal volgende week eens een Zendure buiten zetten op een zonnepaneel.

Net even de Offgrid getest zonder iets er in en die trekt dus constant 25 watt uit de Zendure in normal mode. Aangezien op een slimme wijze bepaald word of het input of output is zie ik ook al voorbij komen dat hij soms een tijdje op input schiet en denkt dat er 6 watt geladen kan worden.

Loopt gewoon niet lekker in de firmware, bij de 2400 Pro zie ik dat het allemaal goed gaat met de offgrid;

[ Voor 9% gewijzigd door gielz op 04-04-2026 22:07 ]

[Polvo176]

hemertje schreef op vrijdag 3 april 2026 @ 18:55:
heb de ac2400+'s nu een dikke week draaien en getest dmv Zendure Zenki.

Bevalt Zenki niet?
Wat vind je van Zenki?

[Wai_AM]

@gielz onderstaande entiteit wordt nu gemaakt met de data uit de officiele nordpool met de attribute:

code:

tomorrow_valid: true
raw_today:
  - start: "2026-04-04T00:00:00+02:00"
    end: "2026-04-04T00:15:00+02:00"
    value: 0.169
  - start: "2026-04-04T00:15:00+02:00"
    end: "2026-04-04T00:30:00+02:00"
    value: 0.1572
  - start: "2026-04-04T00:30:00+02:00"
    end: "2026-04-04T00:45:00+02:00"
    value: 0.152
  - start: "2026-04-04T00:45:00+02:00"
    end: "2026-04-04T01:00:00+02:00"
    value: 0.1476
  - start: "2026-04-04T01:00:00+02:00"
    end: "2026-04-04T01:15:00+02:00"
    value: 0.1645
  - start: "2026-04-04T01:15:00+02:00"
    end: "2026-04-04T01:30:00+02:00"
    value: 0.1575
  - start: "2026-04-04T01:30:00+02:00"
    end: "2026-04-04T01:45:00+02:00"
    value: 0.156
  - start: "2026-04-04T01:45:00+02:00"
    end: "2026-04-04T02:00:00+02:00"
    value: 0.1518
  - start: "2026-04-04T02:00:00+02:00"
    end: "2026-04-04T02:15:00+02:00"
    value: 0.1574
  - start: "2026-04-04T02:15:00+02:00"
    end: "2026-04-04T02:30:00+02:00"
    value: 0.1598
  - start: "2026-04-04T02:30:00+02:00"
    end: "2026-04-04T02:45:00+02:00"
    value: 0.1596
  - start: "2026-04-04T02:45:00+02:00"
    end: "2026-04-04T03:00:00+02:00"
    value: 0.1567
  - start: "2026-04-04T03:00:00+02:00"
    end: "2026-04-04T03:15:00+02:00"
    value: 0.1688
  - start: "2026-04-04T03:15:00+02:00"
    end: "2026-04-04T03:30:00+02:00"
    value: 0.1928
  - start: "2026-04-04T03:30:00+02:00"
    end: "2026-04-04T03:45:00+02:00"
    value: 0.1963
  - start: "2026-04-04T03:45:00+02:00"
    end: "2026-04-04T04:00:00+02:00"
    value: 0.1997
  - start: "2026-04-04T04:00:00+02:00"
    end: "2026-04-04T04:15:00+02:00"
    value: 0.1885
  - start: "2026-04-04T04:15:00+02:00"
    end: "2026-04-04T04:30:00+02:00"
    value: 0.2081
  - start: "2026-04-04T04:30:00+02:00"
    end: "2026-04-04T04:45:00+02:00"
    value: 0.2101
  - start: "2026-04-04T04:45:00+02:00"
    end: "2026-04-04T05:00:00+02:00"
    value: 0.2221
  - start: "2026-04-04T05:00:00+02:00"
    end: "2026-04-04T05:15:00+02:00"
    value: 0.1929
  - start: "2026-04-04T05:15:00+02:00"
    end: "2026-04-04T05:30:00+02:00"
    value: 0.2165
  - start: "2026-04-04T05:30:00+02:00"
    end: "2026-04-04T05:45:00+02:00"
    value: 0.2263
  - start: "2026-04-04T05:45:00+02:00"
    end: "2026-04-04T06:00:00+02:00"
    value: 0.2991
  - start: "2026-04-04T06:00:00+02:00"
    end: "2026-04-04T06:15:00+02:00"
    value: 0.215
  - start: "2026-04-04T06:15:00+02:00"
    end: "2026-04-04T06:30:00+02:00"
    value: 0.2487
  - start: "2026-04-04T06:30:00+02:00"
    end: "2026-04-04T06:45:00+02:00"
    value: 0.2789
  - start: "2026-04-04T06:45:00+02:00"
    end: "2026-04-04T07:00:00+02:00"
    value: 0.4141
  - start: "2026-04-04T07:00:00+02:00"
    end: "2026-04-04T07:15:00+02:00"
    value: 0.304
  - start: "2026-04-04T07:15:00+02:00"
    end: "2026-04-04T07:30:00+02:00"
    value: 0.3903
  - start: "2026-04-04T07:30:00+02:00"
    end: "2026-04-04T07:45:00+02:00"
    value: 0.4388
  - start: "2026-04-04T07:45:00+02:00"
    end: "2026-04-04T08:00:00+02:00"
    value: 0.45
  - start: "2026-04-04T08:00:00+02:00"
    end: "2026-04-04T08:15:00+02:00"
    value: 0.5001
  - start: "2026-04-04T08:15:00+02:00"
    end: "2026-04-04T08:30:00+02:00"
    value: 0.3258
  - start: "2026-04-04T08:30:00+02:00"
    end: "2026-04-04T08:45:00+02:00"
    value: 0.2915
  - start: "2026-04-04T08:45:00+02:00"
    end: "2026-04-04T09:00:00+02:00"
    value: 0.2533
  - start: "2026-04-04T09:00:00+02:00"
    end: "2026-04-04T09:15:00+02:00"
    value: 0.4527
  - start: "2026-04-04T09:15:00+02:00"
    end: "2026-04-04T09:30:00+02:00"
    value: 0.315
  - start: "2026-04-04T09:30:00+02:00"
    end: "2026-04-04T09:45:00+02:00"
    value: 0.2623
  - start: "2026-04-04T09:45:00+02:00"
    end: "2026-04-04T10:00:00+02:00"
    value: 0.2192
  - start: "2026-04-04T10:00:00+02:00"
    end: "2026-04-04T10:15:00+02:00"
    value: 0.3383
  - start: "2026-04-04T10:15:00+02:00"
    end: "2026-04-04T10:30:00+02:00"
    value: 0.2566
  - start: "2026-04-04T10:30:00+02:00"
    end: "2026-04-04T10:45:00+02:00"
    value: 0.2326
  - start: "2026-04-04T10:45:00+02:00"
    end: "2026-04-04T11:00:00+02:00"
    value: 0.215
  - start: "2026-04-04T11:00:00+02:00"
    end: "2026-04-04T11:15:00+02:00"
    value: 0.2265
  - start: "2026-04-04T11:15:00+02:00"
    end: "2026-04-04T11:30:00+02:00"
    value: 0.2126
  - start: "2026-04-04T11:30:00+02:00"
    end: "2026-04-04T11:45:00+02:00"
    value: 0.1835
  - start: "2026-04-04T11:45:00+02:00"
    end: "2026-04-04T12:00:00+02:00"
    value: 0.1494
  - start: "2026-04-04T12:00:00+02:00"
    end: "2026-04-04T12:15:00+02:00"
    value: 0.1775
  - start: "2026-04-04T12:15:00+02:00"
    end: "2026-04-04T12:30:00+02:00"
    value: 0.1598
  - start: "2026-04-04T12:30:00+02:00"
    end: "2026-04-04T12:45:00+02:00"
    value: 0.1424
  - start: "2026-04-04T12:45:00+02:00"
    end: "2026-04-04T13:00:00+02:00"
    value: 0.1366
  - start: "2026-04-04T13:00:00+02:00"
    end: "2026-04-04T13:15:00+02:00"
    value: 0.1359
  - start: "2026-04-04T13:15:00+02:00"
    end: "2026-04-04T13:30:00+02:00"
    value: 0.1358
  - start: "2026-04-04T13:30:00+02:00"
    end: "2026-04-04T13:45:00+02:00"
    value: 0.1357
  - start: "2026-04-04T13:45:00+02:00"
    end: "2026-04-04T14:00:00+02:00"
    value: 0.1357
  - start: "2026-04-04T14:00:00+02:00"
    end: "2026-04-04T14:15:00+02:00"
    value: 0.1358
  - start: "2026-04-04T14:15:00+02:00"
    end: "2026-04-04T14:30:00+02:00"
    value: 0.1358
  - start: "2026-04-04T14:30:00+02:00"
    end: "2026-04-04T14:45:00+02:00"
    value: 0.1358
  - start: "2026-04-04T14:45:00+02:00"
    end: "2026-04-04T15:00:00+02:00"
    value: 0.1358
  - start: "2026-04-04T15:00:00+02:00"
    end: "2026-04-04T15:15:00+02:00"
    value: 0.1356
  - start: "2026-04-04T15:15:00+02:00"
    end: "2026-04-04T15:30:00+02:00"
    value: 0.1356
  - start: "2026-04-04T15:30:00+02:00"
    end: "2026-04-04T15:45:00+02:00"
    value: 0.1356
  - start: "2026-04-04T15:45:00+02:00"
    end: "2026-04-04T16:00:00+02:00"
    value: 0.1358
  - start: "2026-04-04T16:00:00+02:00"
    end: "2026-04-04T16:15:00+02:00"
    value: 0.1351
  - start: "2026-04-04T16:15:00+02:00"
    end: "2026-04-04T16:30:00+02:00"
    value: 0.1385
  - start: "2026-04-04T16:30:00+02:00"
    end: "2026-04-04T16:45:00+02:00"
    value: 0.1424
  - start: "2026-04-04T16:45:00+02:00"
    end: "2026-04-04T17:00:00+02:00"
    value: 0.176
  - start: "2026-04-04T17:00:00+02:00"
    end: "2026-04-04T17:15:00+02:00"
    value: 0.1497
  - start: "2026-04-04T17:15:00+02:00"
    end: "2026-04-04T17:30:00+02:00"
    value: 0.186
  - start: "2026-04-04T17:30:00+02:00"
    end: "2026-04-04T17:45:00+02:00"
    value: 0.2314
  - start: "2026-04-04T17:45:00+02:00"
    end: "2026-04-04T18:00:00+02:00"
    value: 0.2394
  - start: "2026-04-04T18:00:00+02:00"
    end: "2026-04-04T18:15:00+02:00"
    value: 0.1996
  - start: "2026-04-04T18:15:00+02:00"
    end: "2026-04-04T18:30:00+02:00"
    value: 0.2326
  - start: "2026-04-04T18:30:00+02:00"
    end: "2026-04-04T18:45:00+02:00"
    value: 0.261
  - start: "2026-04-04T18:45:00+02:00"
    end: "2026-04-04T19:00:00+02:00"
    value: 0.3054
  - start: "2026-04-04T19:00:00+02:00"
    end: "2026-04-04T19:15:00+02:00"
    value: 0.2691
  - start: "2026-04-04T19:15:00+02:00"
    end: "2026-04-04T19:30:00+02:00"
    value: 0.281
  - start: "2026-04-04T19:30:00+02:00"
    end: "2026-04-04T19:45:00+02:00"
    value: 0.3137
  - start: "2026-04-04T19:45:00+02:00"
    end: "2026-04-04T20:00:00+02:00"
    value: 0.3171
  - start: "2026-04-04T20:00:00+02:00"
    end: "2026-04-04T20:15:00+02:00"
    value: 0.3243
  - start: "2026-04-04T20:15:00+02:00"
    end: "2026-04-04T20:30:00+02:00"
    value: 0.2838
  - start: "2026-04-04T20:30:00+02:00"
    end: "2026-04-04T20:45:00+02:00"
    value: 0.2758
  - start: "2026-04-04T20:45:00+02:00"
    end: "2026-04-04T21:00:00+02:00"
    value: 0.2531
  - start: "2026-04-04T21:00:00+02:00"
    end: "2026-04-04T21:15:00+02:00"
    value: 0.2831
  - start: "2026-04-04T21:15:00+02:00"
    end: "2026-04-04T21:30:00+02:00"
    value: 0.251
  - start: "2026-04-04T21:30:00+02:00"
    end: "2026-04-04T21:45:00+02:00"
    value: 0.2426
  - start: "2026-04-04T21:45:00+02:00"
    end: "2026-04-04T22:00:00+02:00"
    value: 0.2188
  - start: "2026-04-04T22:00:00+02:00"
    end: "2026-04-04T22:15:00+02:00"
    value: 0.2572
  - start: "2026-04-04T22:15:00+02:00"
    end: "2026-04-04T22:30:00+02:00"
    value: 0.2215
  - start: "2026-04-04T22:30:00+02:00"
    end: "2026-04-04T22:45:00+02:00"
    value: 0.2126
  - start: "2026-04-04T22:45:00+02:00"
    end: "2026-04-04T23:00:00+02:00"
    value: 0.1991
  - start: "2026-04-04T23:00:00+02:00"
    end: "2026-04-04T23:15:00+02:00"
    value: 0.2143
  - start: "2026-04-04T23:15:00+02:00"
    end: "2026-04-04T23:30:00+02:00"
    value: 0.1869
  - start: "2026-04-04T23:30:00+02:00"
    end: "2026-04-04T23:45:00+02:00"
    value: 0.1781
  - start: "2026-04-04T23:45:00+02:00"
    end: "2026-04-05T00:00:00+02:00"
    value: 0.1623
raw_tomorrow:
  - start: "2026-04-05T00:00:00+02:00"
    end: "2026-04-05T00:15:00+02:00"
    value: 0.1364
  - start: "2026-04-05T00:15:00+02:00"
    end: "2026-04-05T00:30:00+02:00"
    value: 0.1371
  - start: "2026-04-05T00:30:00+02:00"
    end: "2026-04-05T00:45:00+02:00"
    value: 0.1347
  - start: "2026-04-05T00:45:00+02:00"
    end: "2026-04-05T01:00:00+02:00"
    value: 0.1356
  - start: "2026-04-05T01:00:00+02:00"
    end: "2026-04-05T01:15:00+02:00"
    value: 0.1358
  - start: "2026-04-05T01:15:00+02:00"
    end: "2026-04-05T01:30:00+02:00"
    value: 0.1356
  - start: "2026-04-05T01:30:00+02:00"
    end: "2026-04-05T01:45:00+02:00"
    value: 0.1356
  - start: "2026-04-05T01:45:00+02:00"
    end: "2026-04-05T02:00:00+02:00"
    value: 0.1353
  - start: "2026-04-05T02:00:00+02:00"
    end: "2026-04-05T02:15:00+02:00"
    value: 0.1339
  - start: "2026-04-05T02:15:00+02:00"
    end: "2026-04-05T02:30:00+02:00"
    value: 0.1347
  - start: "2026-04-05T02:30:00+02:00"
    end: "2026-04-05T02:45:00+02:00"
    value: 0.1352
  - start: "2026-04-05T02:45:00+02:00"
    end: "2026-04-05T03:00:00+02:00"
    value: 0.1344
  - start: "2026-04-05T03:00:00+02:00"
    end: "2026-04-05T03:15:00+02:00"
    value: 0.1348
  - start: "2026-04-05T03:15:00+02:00"
    end: "2026-04-05T03:30:00+02:00"
    value: 0.1342
  - start: "2026-04-05T03:30:00+02:00"
    end: "2026-04-05T03:45:00+02:00"
    value: 0.1336
  - start: "2026-04-05T03:45:00+02:00"
    end: "2026-04-05T04:00:00+02:00"
    value: 0.1332
  - start: "2026-04-05T04:00:00+02:00"
    end: "2026-04-05T04:15:00+02:00"
    value: 0.1344
  - start: "2026-04-05T04:15:00+02:00"
    end: "2026-04-05T04:30:00+02:00"
    value: 0.1332
  - start: "2026-04-05T04:30:00+02:00"
    end: "2026-04-05T04:45:00+02:00"
    value: 0.1339
  - start: "2026-04-05T04:45:00+02:00"
    end: "2026-04-05T05:00:00+02:00"
    value: 0.1333
  - start: "2026-04-05T05:00:00+02:00"
    end: "2026-04-05T05:15:00+02:00"
    value: 0.1333
  - start: "2026-04-05T05:15:00+02:00"
    end: "2026-04-05T05:30:00+02:00"
    value: 0.1333
  - start: "2026-04-05T05:30:00+02:00"
    end: "2026-04-05T05:45:00+02:00"
    value: 0.1332
  - start: "2026-04-05T05:45:00+02:00"
    end: "2026-04-05T06:00:00+02:00"
    value: 0.1332
  - start: "2026-04-05T06:00:00+02:00"
    end: "2026-04-05T06:15:00+02:00"
    value: 0.1332
  - start: "2026-04-05T06:15:00+02:00"
    end: "2026-04-05T06:30:00+02:00"
    value: 0.1332
  - start: "2026-04-05T06:30:00+02:00"
    end: "2026-04-05T06:45:00+02:00"
    value: 0.1332
  - start: "2026-04-05T06:45:00+02:00"
    end: "2026-04-05T07:00:00+02:00"
    value: 0.1333
  - start: "2026-04-05T07:00:00+02:00"
    end: "2026-04-05T07:15:00+02:00"
    value: 0.1355
  - start: "2026-04-05T07:15:00+02:00"
    end: "2026-04-05T07:30:00+02:00"
    value: 0.1347
  - start: "2026-04-05T07:30:00+02:00"
    end: "2026-04-05T07:45:00+02:00"
    value: 0.1351
  - start: "2026-04-05T07:45:00+02:00"
    end: "2026-04-05T08:00:00+02:00"
    value: 0.1338
  - start: "2026-04-05T08:00:00+02:00"
    end: "2026-04-05T08:15:00+02:00"
    value: 0.1357
  - start: "2026-04-05T08:15:00+02:00"
    end: "2026-04-05T08:30:00+02:00"
    value: 0.1347
  - start: "2026-04-05T08:30:00+02:00"
    end: "2026-04-05T08:45:00+02:00"
    value: 0.1344
  - start: "2026-04-05T08:45:00+02:00"
    end: "2026-04-05T09:00:00+02:00"
    value: 0.1338
  - start: "2026-04-05T09:00:00+02:00"
    end: "2026-04-05T09:15:00+02:00"
    value: 0.1355
  - start: "2026-04-05T09:15:00+02:00"
    end: "2026-04-05T09:30:00+02:00"
    value: 0.1339
  - start: "2026-04-05T09:30:00+02:00"
    end: "2026-04-05T09:45:00+02:00"
    value: 0.1332
  - start: "2026-04-05T09:45:00+02:00"
    end: "2026-04-05T10:00:00+02:00"
    value: 0.1332
  - start: "2026-04-05T10:00:00+02:00"
    end: "2026-04-05T10:15:00+02:00"
    value: 0.1331
  - start: "2026-04-05T10:15:00+02:00"
    end: "2026-04-05T10:30:00+02:00"
    value: 0.1326
  - start: "2026-04-05T10:30:00+02:00"
    end: "2026-04-05T10:45:00+02:00"
    value: 0.1311
  - start: "2026-04-05T10:45:00+02:00"
    end: "2026-04-05T11:00:00+02:00"
    value: 0.1263
  - start: "2026-04-05T11:00:00+02:00"
    end: "2026-04-05T11:15:00+02:00"
    value: 0.1314
  - start: "2026-04-05T11:15:00+02:00"
    end: "2026-04-05T11:30:00+02:00"
    value: 0.1261
  - start: "2026-04-05T11:30:00+02:00"
    end: "2026-04-05T11:45:00+02:00"
    value: 0.1237
  - start: "2026-04-05T11:45:00+02:00"
    end: "2026-04-05T12:00:00+02:00"
    value: 0.1227
  - start: "2026-04-05T12:00:00+02:00"
    end: "2026-04-05T12:15:00+02:00"
    value: 0.1214
  - start: "2026-04-05T12:15:00+02:00"
    end: "2026-04-05T12:30:00+02:00"
    value: 0.1214
  - start: "2026-04-05T12:30:00+02:00"
    end: "2026-04-05T12:45:00+02:00"
    value: 0.1211
  - start: "2026-04-05T12:45:00+02:00"
    end: "2026-04-05T13:00:00+02:00"
    value: 0.1086
  - start: "2026-04-05T13:00:00+02:00"
    end: "2026-04-05T13:15:00+02:00"
    value: 0.1173
  - start: "2026-04-05T13:15:00+02:00"
    end: "2026-04-05T13:30:00+02:00"
    value: 0.1078
  - start: "2026-04-05T13:30:00+02:00"
    end: "2026-04-05T13:45:00+02:00"
    value: 0.0992
  - start: "2026-04-05T13:45:00+02:00"
    end: "2026-04-05T14:00:00+02:00"
    value: 0.0866
  - start: "2026-04-05T14:00:00+02:00"
    end: "2026-04-05T14:15:00+02:00"
    value: 0.0788
  - start: "2026-04-05T14:15:00+02:00"
    end: "2026-04-05T14:30:00+02:00"
    value: 0.0739
  - start: "2026-04-05T14:30:00+02:00"
    end: "2026-04-05T14:45:00+02:00"
    value: 0.0727
  - start: "2026-04-05T14:45:00+02:00"
    end: "2026-04-05T15:00:00+02:00"
    value: 0.0731
  - start: "2026-04-05T15:00:00+02:00"
    end: "2026-04-05T15:15:00+02:00"
    value: 0.0713
  - start: "2026-04-05T15:15:00+02:00"
    end: "2026-04-05T15:30:00+02:00"
    value: 0.072
  - start: "2026-04-05T15:30:00+02:00"
    end: "2026-04-05T15:45:00+02:00"
    value: 0.0751
  - start: "2026-04-05T15:45:00+02:00"
    end: "2026-04-05T16:00:00+02:00"
    value: 0.0824
  - start: "2026-04-05T16:00:00+02:00"
    end: "2026-04-05T16:15:00+02:00"
    value: 0.0757
  - start: "2026-04-05T16:15:00+02:00"
    end: "2026-04-05T16:30:00+02:00"
    value: 0.0998
  - start: "2026-04-05T16:30:00+02:00"
    end: "2026-04-05T16:45:00+02:00"
    value: 0.1058
  - start: "2026-04-05T16:45:00+02:00"
    end: "2026-04-05T17:00:00+02:00"
    value: 0.1184
  - start: "2026-04-05T17:00:00+02:00"
    end: "2026-04-05T17:15:00+02:00"
    value: 0.1222
  - start: "2026-04-05T17:15:00+02:00"
    end: "2026-04-05T17:30:00+02:00"
    value: 0.1296
  - start: "2026-04-05T17:30:00+02:00"
    end: "2026-04-05T17:45:00+02:00"
    value: 0.1328
  - start: "2026-04-05T17:45:00+02:00"
    end: "2026-04-05T18:00:00+02:00"
    value: 0.1354
  - start: "2026-04-05T18:00:00+02:00"
    end: "2026-04-05T18:15:00+02:00"
    value: 0.1332
  - start: "2026-04-05T18:15:00+02:00"
    end: "2026-04-05T18:30:00+02:00"
    value: 0.1355
  - start: "2026-04-05T18:30:00+02:00"
    end: "2026-04-05T18:45:00+02:00"
    value: 0.137
  - start: "2026-04-05T18:45:00+02:00"
    end: "2026-04-05T19:00:00+02:00"
    value: 0.1406
  - start: "2026-04-05T19:00:00+02:00"
    end: "2026-04-05T19:15:00+02:00"
    value: 0.1477
  - start: "2026-04-05T19:15:00+02:00"
    end: "2026-04-05T19:30:00+02:00"
    value: 0.2009
  - start: "2026-04-05T19:30:00+02:00"
    end: "2026-04-05T19:45:00+02:00"
    value: 0.2318
  - start: "2026-04-05T19:45:00+02:00"
    end: "2026-04-05T20:00:00+02:00"
    value: 0.2721
  - start: "2026-04-05T20:00:00+02:00"
    end: "2026-04-05T20:15:00+02:00"
    value: 0.2576
  - start: "2026-04-05T20:15:00+02:00"
    end: "2026-04-05T20:30:00+02:00"
    value: 0.2768
  - start: "2026-04-05T20:30:00+02:00"
    end: "2026-04-05T20:45:00+02:00"
    value: 0.2678
  - start: "2026-04-05T20:45:00+02:00"
    end: "2026-04-05T21:00:00+02:00"
    value: 0.2931
  - start: "2026-04-05T21:00:00+02:00"
    end: "2026-04-05T21:15:00+02:00"
    value: 0.311
  - start: "2026-04-05T21:15:00+02:00"
    end: "2026-04-05T21:30:00+02:00"
    value: 0.2926
  - start: "2026-04-05T21:30:00+02:00"
    end: "2026-04-05T21:45:00+02:00"
    value: 0.288
  - start: "2026-04-05T21:45:00+02:00"
    end: "2026-04-05T22:00:00+02:00"
    value: 0.2802
  - start: "2026-04-05T22:00:00+02:00"
    end: "2026-04-05T22:15:00+02:00"
    value: 0.2887
  - start: "2026-04-05T22:15:00+02:00"
    end: "2026-04-05T22:30:00+02:00"
    value: 0.2875
  - start: "2026-04-05T22:30:00+02:00"
    end: "2026-04-05T22:45:00+02:00"
    value: 0.284
  - start: "2026-04-05T22:45:00+02:00"
    end: "2026-04-05T23:00:00+02:00"
    value: 0.2787
  - start: "2026-04-05T23:00:00+02:00"
    end: "2026-04-05T23:15:00+02:00"
    value: 0.2853
  - start: "2026-04-05T23:15:00+02:00"
    end: "2026-04-05T23:30:00+02:00"
    value: 0.273
  - start: "2026-04-05T23:30:00+02:00"
    end: "2026-04-05T23:45:00+02:00"
    value: 0.2748
  - start: "2026-04-05T23:45:00+02:00"
    end: "2026-04-06T00:00:00+02:00"
    value: 0.2593
current_price: 0.2572
unit_of_measurement: EUR/kWh
icon: mdi:cash
friendly_name: nordpool_kwh_nl_eur_5_09_0

echter krijg ik geen raw_today en raw_tormorrow in sensor.dynamisch_nordpool
Status komt er wel in.

zie ik wat over het hoofd?

[hemertje]

Polvo176 schreef op zaterdag 4 april 2026 @ 21:44:
[...]

Bevalt Zenki niet?
Wat vind je van Zenki?

Ik vind de Zendure app nogal gefocust op PV terwijl mijn ac2400+ geen PV-omvormer heeft

Dus die app mogen ze wat mij betreft meer aanpassen aan de hardware die je in gebruik hebt

Het kan aan mij liggen maar ik kan enkel in de app zien dat ik zenki geselecteerd hebt maar het plan wat erachter ligt qua voorspelling niet?

Of ik kijk verkeerd in de Zendure app?

Nadeel van Zendure is dat die geen weet heeft van een eventuele EV, dus als ik die ga laden trekt die ook de zendures leeg….

[Polvo176]

hemertje schreef op zaterdag 4 april 2026 @ 22:26:
[...]


Ik vind de Zendure app nogal gefocust op PV terwijl mijn ac2400+ geen PV-omvormer heeft

Dus die app mogen ze wat mij betreft meer aanpassen aan de hardware die je in gebruik hebt

Het kan aan mij liggen maar ik kan enkel in de app zien dat ik zenki geselecteerd hebt maar het plan wat erachter ligt qua voorspelling niet?

Of ik kijk verkeerd in de Zendure app?

Nadeel van Zendure is dat die geen weet heeft van een eventuele EV, dus als ik die ga laden trekt die ook de zendures leeg….

Ik heb geen EV, maar wel een warmtepomp.
Er zijn diverse andere redenen waarom Zenki voor mij niet werkt.
Maar er komt een versie 2, dus even afwachten wat dit verbeterd.
Met HA is veel mogelijk, maar het duurt dan even voor je een batterij nerd bent i.p.v. satelliet nerd.

[Bart-sss]

Ik ben helemaal nieuw in de home assistant wereld.
Heb in home assistant de code in .yaml geplakt maar volgens gemini moet ik nog ergens de zendure app key en de zendure app secret moeten typen. Waar kan ik deze vinden en waar moet ik deze plaatsen in de code in yaml?

[Wai_AM]

Bart-sss schreef op zondag 5 april 2026 @ 09:11:
Ik ben helemaal nieuw in de home assistant wereld.
Heb in home assistant de code in .yaml geplakt maar volgens gemini moet ik nog ergens de zendure app key en de zendure app secret moeten typen. Waar kan ik deze vinden en waar moet ik deze plaatsen in de code in yaml?

als je helemaal nieuw bent in home assistant, dan kan je beter gielz Zendure-HA-zenSDK gebruiken.
makkelijk te installeren en te gebruiken. Geen app key etc nodig.

[Ben(V)]

Bart-sss schreef op zondag 5 april 2026 @ 09:11:
Ik ben helemaal nieuw in de home assistant wereld.
Heb in home assistant de code in .yaml geplakt maar volgens gemini moet ik nog ergens de zendure app key en de zendure app secret moeten typen. Waar kan ik deze vinden en waar moet ik deze plaatsen in de code in yaml?

Of je neemt de fireson besturing.
Alles staat hier goed beschreven als je hier op installation klikt.
https://github.com/Zendure/Zendure-HA

PS En dump die chatbot met hun halve adviezen.

[ Voor 4% gewijzigd door Ben(V) op 05-04-2026 09:58 ]

[gielz]

Bart-sss schreef op zondag 5 april 2026 @ 09:11:
Ik ben helemaal nieuw in de home assistant wereld.
Heb in home assistant de code in .yaml geplakt maar volgens gemini moet ik nog ergens de zendure app key en de zendure app secret moeten typen. Waar kan ik deze vinden en waar moet ik deze plaatsen in de code in yaml?

Gemini kijkt blijkbaar naar 3 aansturingen. Dit terwijl je kunt gaan voor de Zensdk (zelfbouw), Gielz of Zendure HA (zie TS). Die laatste maakt gebruik van een zendure app key (token). De andere 2 aansturingen maken hier niet gebruik van omdat ze geen verbinding maken met de cloud.

[Bart-sss]

Ik ga er na de paasdagen is goed voor zitten. Dank voor de tips, als ik er niet uit komt laat ik het wel weten.

[Hippe Lip]

Wai_AM schreef op zondag 5 april 2026 @ 09:23:
[...]


als je helemaal nieuw bent in home assistant, dan kan je beter gielz Zendure-HA-zenSDK gebruiken.
makkelijk te installeren en te gebruiken. Geen app key etc nodig.

@Wai_AM Handig als je er meteen een linkje bij zet in je text, zeker als je het hebt tegen iemand die zegt dat die volkomen nieuw is in die omgeving?

[Hippe Lip]

gast777 schreef op zaterdag 4 april 2026 @ 16:23:
==== Beschikbare gesimuleerde devices:
testdevice1 - Solarflow 2400AC
testdevice2 - Solarflow 2400AC
testdevice3 - Solarflow 2400AC
testdevice4 - Solarflow 2400AC+

Ik lees steeds stukjes over iets dat jij hebt gebouwd, lijkt het. Is dat een aanvulling op wat @gielz heeft gemaakt?
Waar vind ik daarvan een beschrijving en vooral ook: waar kan ik het vinden?

Misschien handig als het in de TS vermeld wordt (@gielz?). Of je zet het ergens bij jouw profiel of zo (@gast777?). Want ook daar kon ik het niet vinden. Het is (voor mij) een beetje een puzzelrit zo

[MGZ]

gast777 schreef op zaterdag 4 april 2026 @ 16:11:
Ter aanvulling: deze gesimuleerde devices zijn ook zonder de proxy te gebruiken Je kunt ze vanaf extern rechtstreeks bereiken via:

curl http://<proxy_ip_adres>:1880/endpoint/testdevice1/properties/report
of
curl http://<proxy_ip_adres>:1880/testdevice1/properties/report

Vanaf Gielz:
Verbind met deze gesimuleerde Zendure op "192.168.x.x:1880/testdevice1" of "192.168.x.x:1880/endpoint/testdevice1".

Dus als je Gielz wilt uitproberen maar nog geen Zendure hebt, zou je Node-RED kunnen installeren en de Proxy flow daarin laden en activeren. Daarna kun je de gesimuleerde Zendures benaderen.

Kan iemand in jip en jannekes taal (eventueel via dm) uitleggen hoe iemand die compleet nieuw is in HA dit voor elkaar krijgt? Voor iemand zoals ik die helemaal nieuw is in HA klinkt het alsof je aan een Neanderthaler uitlegt wat internet is. (En ja dat ligt aan mij)
En dan met name het gedeelte om gielz uit te proberen als je nog geen Zendure hebt.

[ Voor 4% gewijzigd door MGZ op 05-04-2026 15:11 ]

[..Christiaan..]

Je kunt claude.ai om hulp vragen? Die is best goed. Dan leer je in de praktijk.

[koos]

Ik loop vast. Is er iemand die kan helpen?
De intergratie van Zendure zelf heb ik aan de gang. Nu wil ik de van Gielz ook draaiende hebben , maar wat ik ook probeer ik krijg alleen maar dit op het scherm:


Entiteiten worden niet gevonden. Waarom niet, wat doe ik fout?

[NiCNCo]

Had vandaag de goedkoopste uren gezet op 4. Volgens de nordpool grafiek sprong dus zoals het hoorde rond 2 uur op status goedkoop met de groene lettertjes boven de grafiek. Gielz automatie op dashboard stond op dynamisch NOM aan. PV leverde op dat moment ~800 watt terug maar ik verwachte dat de Zendure vollebak zouden gaan laden? Maar dat deden ze dus niet? Zie ik iets over het hoofd? Klopt het dat dynamisch NOM de goedkope uren instelling negeert zodra de PV surplus heeft op dat moment?

[ Voor 3% gewijzigd door NiCNCo op 05-04-2026 16:16 ]

[Wai_AM]

koos schreef op zondag 5 april 2026 @ 15:55:
Ik loop vast. Is er iemand die kan helpen?
De intergratie van Zendure zelf heb ik aan de gang. Nu wil ik de van Gielz ook draaiende hebben , maar wat ik ook probeer ik krijg alleen maar dit op het scherm:
[Afbeelding]

Entiteiten worden niet gevonden. Waarom niet, wat doe ik fout?

[Afbeelding]

[Afbeelding]

welke stappen heb je nu allemaal uitgevoerd?
Heb je zendure ip in de scherm met tandwiel ingevoerd ?

[koos]

Ja. Heb ik gedaan.

[Wai_AM]

koos schreef op zondag 5 april 2026 @ 16:41:
Ja. Heb ik gedaan.
[Afbeelding]

zie dat P1 is gevonden : check
zie dat schakelingen 0 is : check
rest van de entiteiten ... onbekend

HA herstart ?
automatisering aangemaakt en gestart ?
alle stappen heb je doorlopen?

[NiCNCo]

Ik weet niet wat ik fout doe of heb gedaan, maar krijg hele rare spread waarden?

Gebuik deze sensor van Nordpool: sensor.nordpool_kwh_nl_eur_3_10_021
Hoort dit? ik zie bij schermafbeeldingen van andere dat jullie % waarden gewoon tussen 0 en 100 vallen, iets zal er wel niet kloppen bij mij?

En laatste vraag waarom zie ik op de Gielz pagina en afbeeldingen op dit forum dit grote zendure icoon met "gekoppelde zendure" aanduiding boven de ip adressen velden?


Ik heb dat niet? ik heb eergister de laatste automatiserings code gebruikt, de laatste Gielz yaml.file en laatste Gielz dashboard yaml code? (dacht ik) Dashboard geeft aan: (April 2026) v20260312

[Wai_AM]

NiCNCo schreef op zondag 5 april 2026 @ 17:34:
Ik weet niet wat ik fout doe of heb gedaan, maar krijg hele rare spread waarden?[Afbeelding]

Gebuik deze sensor van Nordpool: sensor.nordpool_kwh_nl_eur_3_10_021
Hoort dit? ik zie bij schermafbeeldingen van andere dat jullie % waarden gewoon tussen 0 en 100 vallen, iets zal er wel niet kloppen bij mij?

je gebruikt de kale prijs van nordpool. Wat heb je allemaal ingesteld?

En laatste vraag waarom zie ik op de Gielz pagina en afbeeldingen op dit forum dit grote zendure icoon met "gekoppelde zendure" aanduiding boven de ip adressen velden?
[Afbeelding]

Ik heb dat niet? ik heb eergister de laatste automatiserings code gebruikt, de laatste Gielz yaml.file en laatste Gielz dashboard yaml code? (dacht ik) Dashboard geeft aan: (April 2026) v20260312

de afbeeldingen zijn van de Gielz mei beta versie .

[gast777]

MGZ schreef op zondag 5 april 2026 @ 15:09:
[...]

Kan iemand in jip en jannekes taal (eventueel via dm) uitleggen hoe iemand die compleet nieuw is in HA dit voor elkaar krijgt? Voor iemand zoals ik die helemaal nieuw is in HA klinkt het alsof je aan een Neanderthaler uitlegt wat internet is. (En ja dat ligt aan mij)
En dan met name het gedeelte om gielz uit te proberen als je nog geen Zendure hebt.

Dit is een nieuwe feature die nu beschikbaar is in de proxy flow in Node-RED.

Wat je kan doen is Node-RED installeren (kan als add-on van HA) en dan het flow bestand Zendure-proxy-Node-Red-flow.json van de Proxy daar importeren en activeren. Zie daar ook de handleiding, of zoek even algemeen over Node-RED op internet. Het is heel gebruiksvriendelijk, maar je moet het even weten.

Je hoeft de Proxy hiervoor niet te gebruiken. Die staat er los van, maar zit toevallig in dezelfde 'flow'.

Vervolgens heb je een aantal virtuele Zendure devices, die je kunt benaderen vanuit HA (of je browser) via REST commands alsof het een echte Zendure is. Je moet wel even een iets aangepaste URL gebruiken.

Het ziet er in Node-RED grafisch zo uit met de 4 testdevices:



In je browser kun je gaan naar http://<node-red_ip_adres>:1880/endpoint/testdevice1/properties/report of http://<node-red_ip_adres>:1880/testdevice1/properties/report afhankelijk van je installatie (probeer gewoon beide en zie welke het is).

Voor HA Gielz uitproberen als je nog geen Zendure hebt, kun je hem toevoegen als "192.168.x.x:1880/testdevice1" of als "192.168.x.x:1880/endpoint/testdevice1" (dus weer afhankelijk van je installatie) in het invulveld "Zendure 2400 AC IP-adres". Dan zou je laden en ontladen kunnen starten en de Gielz denkt dat het echt is.

Zo kun je er een beetje een idee van krijgen hoe het zal werken.

Ik hoor het wel als het niet lukt.

Deze virtuele devices (toestellen is misschien een mooier woord ) gebruik ik zelf om de Gielz Proxy te testen met 3x SF2400AC, omdat ik er zelf maar 2 echte van heb. Het is momenteel wel beperkt wat ze kunnen (bijv de SoC verandert niet etc), maar voor wat basis testen werkt het toch heel aardig.

[ Voor 5% gewijzigd door gast777 op 05-04-2026 18:24 ]

[koos]

@ Wai_AM. Bedankt voor het meedenken.


Heb een her-check gedaan en wat ik zag is dat het IP adres van de Zendure veranderd was. Ook die van de HW p1meter was veranderd. Op het modem maar snel die 2 van DHCP gehaald.
Nu is alles te zien. Joepie..

[NiCNCo]

Wai_AM schreef op zondag 5 april 2026 @ 18:15:
[...]


je gebruikt de kale prijs van nordpool. Wat heb je allemaal ingesteld?


[...]

de afbeeldingen zijn van de Gielz mei beta versie .

Ik heb de kale nordpool prijzen nu opnieuw gedaan. Dit maal rechtstreeks vanuit een sensor.yaml waarbij de UI intergratie entry eerst verwijderd is. Deze wordt nu vervolgens via een template sensor een vergelijking gemaakt met de huidige zonneplan current tarif senser, daar een kalibaratie formule, en smoothing en die wordt uiteindelijk gebruikt door de nordpool sensor additional cost formule gedeelte. Nee ik heb dit niet allemaal zelf bedacht, mede dank aan chatgpt De nordpool waarde in Gielz zit nu nog maar een paar 100ste cent van die van zonneplan vandaan en alle waarden voor next day ahead zijn ook mede gecorrigeerd.

Ik zie nog steeds een spread van boven de 100% namelijk 136% en Spread NOM 189%. Is dit nu wel normaal? Wat hoort de maximale mogelijke spread te zijn in de Gielz dashboard?

[Pakhaas]

NiCNCo schreef op zondag 5 april 2026 @ 20:03:
[...]

Ik heb de kale nordpool prijzen nu opnieuw gedaan. Dit maal rechtstreeks vanuit een sensor.yaml waarbij de UI intergratie entry eerst verwijderd is. Deze wordt nu vervolgens via een template sensor een vergelijking gemaakt met de huidige zonneplan current tarif senser, daar een kalibaratie formule, en smoothing en die wordt uiteindelijk gebruikt door de nordpool sensor additional cost formule gedeelte. Nee ik heb dit niet allemaal zelf bedacht, mede dank aan chatgpt De nordpool waarde in Gielz zit nu nog maar een paar 100ste cent van die van zonneplan vandaan en alle waarden voor next day ahead zijn ook mede gecorrigeerd. [Afbeelding]

Ik zie nog steeds een spread van boven de 100% namelijk 136% en Spread NOM 189%. Is dit nu wel normaal? Wat hoort de maximale mogelijke spread te zijn in de Gielz dashboard?

Morgen wel een mooie dag. Nachts/ochtends eerst de batterij van vandaag ontladen, middags laden en avonds weer alles eruit

[Wai_AM]

NiCNCo schreef op zondag 5 april 2026 @ 20:03:
[...]

Ik heb de kale nordpool prijzen nu opnieuw gedaan. Dit maal rechtstreeks vanuit een sensor.yaml waarbij de UI intergratie entry eerst verwijderd is. Deze wordt nu vervolgens via een template sensor een vergelijking gemaakt met de huidige zonneplan current tarif senser, daar een kalibaratie formule, en smoothing en die wordt uiteindelijk gebruikt door de nordpool sensor additional cost formule gedeelte. Nee ik heb dit niet allemaal zelf bedacht, mede dank aan chatgpt De nordpool waarde in Gielz zit nu nog maar een paar 100ste cent van die van zonneplan vandaan en alle waarden voor next day ahead zijn ook mede gecorrigeerd. [Afbeelding]

Ik zie nog steeds een spread van boven de 100% namelijk 136% en Spread NOM 189%. Is dit nu wel normaal? Wat hoort de maximale mogelijke spread te zijn in de Gielz dashboard?

fijn dat het werk. mocht je makkelijker willen dan kan het ook zo: https://gathering.tweakers.net/forum/view_message/84914288

Weet niet wat je normaal vind, maar dit is zoals ik het hebt , ingesteld Minimale spread: 30%

[gielz]

Op dit moment heb ik een testopstelling gemaakt op de schuur waarbij 2x 390WP via een micro omvormer de offgrid ingang gaan bij een 2400 Pro. Eind volgende week als dit goed gaat met NOM en PV only laden zal ik ze ook via de MC4 kabels gaan aansluiten om dit door te testen.

Nu ben ik op zoek naar een aantal actieve testers met een Zendure en zonnepanelen (offgrid of via de mppt) die een testrelease willen doortesten of het gewoon werkt zoals je verwacht (zodra ik hier de test succesvol heb afgerond). Eigenlijk dus een kwestie van installeren + dashboard draaien en zien dat het goed gaat.

Graag via DM.

[koboy]

NiCNCo schreef op zondag 5 april 2026 @ 20:03:
[...]

Ik heb de kale nordpool prijzen nu opnieuw gedaan. Dit maal rechtstreeks vanuit een sensor.yaml waarbij de UI intergratie entry eerst verwijderd is. Deze wordt nu vervolgens via een template sensor een vergelijking gemaakt met de huidige zonneplan current tarif senser, daar een kalibaratie formule, en smoothing en die wordt uiteindelijk gebruikt door de nordpool sensor additional cost formule gedeelte. Nee ik heb dit niet allemaal zelf bedacht, mede dank aan chatgpt De nordpool waarde in Gielz zit nu nog maar een paar 100ste cent van die van zonneplan vandaan en alle waarden voor next day ahead zijn ook mede gecorrigeerd. [Afbeelding]

Ik zie nog steeds een spread van boven de 100% namelijk 136% en Spread NOM 189%. Is dit nu wel normaal? Wat hoort de maximale mogelijke spread te zijn in de Gielz dashboard?

Ja dit is de spread vandaag. Morgen nog wat mooier met meer dan 200%.
Probeer het ontladen van vanavond nog te stoppen (dure uren naar 0), want morgenochtend levert het nog net wat meer op.

[elektriekert]

Als je met de Proxy van @gast777 werkt en een zogenaamde SF4800AC creëert, wordt er dan bij een lowload alsnog van beiden 2400’s stroom getrokken of is dat zelf in te stellen?
Bijv. >600W = beiden omvormers gebruiken?

[ Voor 3% gewijzigd door elektriekert op 05-04-2026 23:41 ]

[gast777]

elektriekert schreef op zondag 5 april 2026 @ 23:41:
Als je met de Proxy van @gast777 werkt en een zogenaamde SF4800AC creëert, wordt er dan bij een lowload alsnog van beiden 2400’s stroom getrokken of is dat zelf in te stellen?
Bijv. >600W = beiden omvormers gebruiken?

Dat gaat geheel automatisch met de Proxy. Bij lage belasting wordt een van de Zendures eerst in standby en dan na 5 minuten in een slaap modus gezet, ten behoeve van de efficiëntie.

De standaard grenzen zijn 40% en 100% van het als max ingestelde vermogen van 1 device. Dus normaliter is dat 40% en 100% van 2400 Watt (960W en 2400W):

onder 960W - altijd 1 device
boven 2400W - altijd 2 devices
Daar tussenin blijft het zoals het is.

Bij 3 Zendures hetzelfde, maar wat ingewikkelder...

onder 960W - altijd 1 device
boven 4800W - altijd 3 devices
als 1 actief is, boven de 2400W naar 2 devices
als 3 actief zijn, onder de 1920W (40% van 4800W) naar 2 devices

Daarnaast wisselen ze van actief device als het verschil in SoC >= 5% wordt. En als ze tegelijk laden/ontladen, balanceert het vermogen, zodat de SoC dicht bij elkaar blijft.

[elektriekert]

gast777 schreef op maandag 6 april 2026 @ 00:47:
[...]


Dat gaat geheel automatisch met de Proxy. Bij lage belasting wordt een van de Zendures eerst in standby en dan na 5 minuten in een slaap modus gezet, ten behoeve van de efficiëntie.

De standaard grenzen zijn 40% en 100% van het als max ingestelde vermogen van 1 device. Dus normaliter is dat 40% en 100% van 2400 Watt (960W en 2400W):

onder 960W - altijd 1 device
boven 2400W - altijd 2 devices
Daar tussenin blijft het zoals het is.

Bij 3 Zendures hetzelfde, maar wat ingewikkelder...

onder 960W - altijd 1 device
boven 4800W - altijd 3 devices
als 1 actief is, boven de 2400W naar 2 devices
als 3 actief zijn, onder de 1920W (40% van 4800W) naar 2 devices

Daarnaast wisselen ze van actief device als het verschil in SoC >= 5% wordt. En als ze tegelijk laden/ontladen, balanceert het vermogen, zodat de SoC dicht bij elkaar blijft.

Damn!
Hier is dus wel goed over nagedacht, respect!

Ik was nog aan het nadenken dat ik idealiter de fase waar de airco aan hangt sowieso een accu/omvormer op wil zodat ik niet van het net aftrek (intern salderen) maar dus echt eigen stroom gebruik. Maar er valt natuurlijk ook wat over te zeggen om de accu's gelijk te belasten waardoor de slijtage gelijk is bij beiden.

[gast777]

elektriekert schreef op maandag 6 april 2026 @ 09:30:
[...]
Ik was nog aan het nadenken dat ik idealiter de fase waar de airco aan hangt sowieso een accu/omvormer op wil zodat ik niet van het net aftrek (intern salderen) maar dus echt eigen stroom gebruik. Maar er valt natuurlijk ook wat over te zeggen om de accu's gelijk te belasten waardoor de slijtage gelijk is bij beiden.

Voor de belasting/slijtage van de accu's maak het het niet uit wat er nog meer op dezelfde fase zit. Belangrijkste is dat bij vol vermogen laden/ontladen je niet gauw over het max vermogen van een fase zult gaan (normaliter 25A of 5750 Watt). Daarom kun je ze over het algemeen het beste op verschillende fasen zetten.

Hier nog even leuk (vind ik zelf ) de grafiek van vanochtend, waar je de wisselingen van batterij kunt zien, bij lage vermogens, bij 5% verschil in SoC%.



"Opslaan in Flash" staat gelijk aan slaapmodus (smartmode uit). De overgangen van de ene naar het andere device zijn zo ontworpen om soepel te verlopen (nieuwe start langzaam op, oude blijft nog even 95% van het vermogen leveren terwijl de nieuwe opstart en dan wisselen ze langzaam).

NB: Die wijdbeense vorm van de P1 piek bij 9:50 is normaal strakker, maar wordt veroorzaakt door een issue in de nieuwe firmware van de SF2400AC, wat als het goed is nog weer gecorrigeerd wordt.

[elektriekert]

gast777 schreef op maandag 6 april 2026 @ 10:49:
[...]


Voor de belasting/slijtage van de accu's maak het het niet uit wat er nog meer op dezelfde fase zit. Belangrijkste is dat bij vol vermogen laden/ontladen je niet gauw over het max vermogen van een fase zult gaan (normaliter 25A of 5750 Watt). Daarom kun je ze over het algemeen het beste op verschillende fasen zetten.

Hier nog even leuk (vind ik zelf ) de grafiek van vanochtend, waar je de wisselingen van batterij kunt zien, bij lage vermogens, bij 5% verschil in SoC%.

[Afbeelding]

"Opslaan in Flash" staat gelijk aan slaapmodus (smartmode uit). De overgangen van de ene naar het andere device zijn zo ontworpen om soepel te verlopen (nieuwe start langzaam op, oude blijft nog even 95% van het vermogen leveren terwijl de nieuwe opstart en dan wisselen ze langzaam).

NB: Die wijdbeense vorm van de P1 piek bij 9:50 is normaal strakker, maar wordt veroorzaakt door een issue in de nieuwe firmware van de SF2400AC, wat als het goed is nog weer gecorrigeerd wordt.

Wellicht was het niet duidelijk. Maar elk setje komt op zijn eigen fase (zie het grote Zendure topic) voor mijn onderverdeelkast met zeeën van extra ruimte

Maar nogmaals, echt dikke respect voor je werk, Idem voor @gielz uiteraard.

[gast777]

elk setje komt op zijn eigen fase (zie het grote Zendure topic) voor mijn onderverdeelkast met zeeën van extra ruimte

Bij een elektriekert had ik ook niet anders verwacht

Hier op deze zonnige paasochtend nog even ter illustratie een grafiek met Proxy waar ze ook beide tegelijk actief worden vanwege hoger vermogen:



De SoC % van beide Zendures blijft ook netjes dicht bij elkaar

Zo... nu even genoeg reclame

[Pakhaas]

gast777 schreef op maandag 6 april 2026 @ 11:43:
[...]
knip

De proxy werkt echt heel mooi. Ik heb op beide een MID meter en zie ik ook heel mooi dat hij steeds zorgt qua vermogen dat de SOC heel dicht bij elkaar blijft.

[Refl]

Osxy schreef op woensdag 1 april 2026 @ 16:47:
[...]


Heb daar een relatief simpele automation voor gemaakt.

4 helper entities:
Zappi laden (true / false obv state van zappi) - is Zappi NU aan het laden
binary.zappi_laden

code:

{{ states('sensor.myenergi_zappi_20133740_plug_status') in [ 'Charging'] }}

Minimum margin for car - number input (hoeveel moet de thuis accu minimaal zijn voordat Zappi voorrang krijgt)
input_number.zendure_minimum_battery_before_car_is_allowed
Zappi enough margin for car - mag duidelijk zijn is huidige accu > dan minimale %
binary_sensor.zendure_battery_enough_margin_for_car

code:

{{ states('sensor.zendure_2400_ac_laadpercentage') > states('input_number.zendure_minimum_battery_before_car_is_allowed')}}

Zappi ready to charge ECO+ - Checked of er minimaal 1450 watt overschot is en er een auto aangesloten is
binary_sensor.zappi_klaar_om_te_laden_op_eco

code:

{{ states('sensor.myenergi_zappi_20133740_plug_status') not in ['unavailable ', 'EV Disconnected'] and (states('sensor.p1_aansturing_vermogen') | float - states('sensor.zendure_2400_ac_vermogen_aansturing') | float) < -1450}}

En dan automation met trigger op Laden, Enough Margin en Ready to charge afhankelijk van situatie wordt dan de Zendure kort op pauze gezet zodat het overschot voor de Zappi zichtbaar wordt en hij zelf ECO+ start (andere optie is Zappi op pauze en op ECO zetten wanneer er voldoende overschot is en dan weer op pauze als overschot minder is dat 1400watt).
Zendure word op charge only gezet zodat mocht er toch nog over zijn hij het pakt maar wel met grotere marge zodat de Zappi over algemeen eerst zal reageren.

Automation

code:

alias: Zendure pauze while charging
description: ""
triggers:
  - trigger: state
    entity_id:
      - binary_sensor.zappi_laden
      - binary_sensor.zendure_battery_enough_margin_for_car
      - binary_sensor.zappi_klaar_om_te_laden_op_eco
conditions: []
actions:
  - choose:
      - conditions:
          - condition: state
            entity_id: binary_sensor.zappi_klaar_om_te_laden_op_eco
            state:
              - "on"
          - condition: state
            entity_id: binary_sensor.zappi_laden
            state:
              - "off"
          - condition: state
            entity_id: binary_sensor.zendure_battery_enough_margin_for_car
            state:
              - "on"
        sequence:
          - action: input_select.select_option
            metadata: {}
            target:
              entity_id: input_select.zendure_2400_ac_modus_selecteren
            data:
              option: Standby
      - conditions:
          - condition: state
            entity_id: binary_sensor.zappi_laden
            state:
              - "on"
        sequence:
          - action: input_select.select_option
            metadata: {}
            target:
              entity_id: input_select.zendure_2400_ac_modus_selecteren
            data:
              option: Alleen slim opladen
          - action: input_number.set_value
            metadata: {}
            target:
              entity_id: input_number.zendure_2400_ac_oplaadmarge
            data:
              value: 100
    default:
      - action: input_select.select_option
        metadata: {}
        target:
          entity_id: input_select.zendure_2400_ac_modus_selecteren
        data:
          option: Nul op de meter
      - action: input_number.set_value
        metadata: {}
        target:
          entity_id: input_number.zendure_2400_ac_oplaadmarge
        data:
          value: 50
mode: single

Dit is top maar het enige wat ik erbij zou willen is dat wanneer je laden start, dat de Gielz dan zijn huidige state "bewaard", de zendure naar bijv. standby of enkel slimladen schakelt, en als de laadpaal klaar is, dat Gielz dan automatisch terugschakelt naar de vorige setting in plaats van een hardcoded setting.

Zal het eens aan Gemini vragen.

[Henkoes]

Beste allen.

Ik probeer erachter te komen of ik met deze integritatie:

Zowel:
N
- NOM kan draaien als prijs boven/onder x is
- kan laden wanneer prijs onder x (bijv 0) is maar alleen hit de zon wanner spread lager is dan x
- kan ontladen als prijs boven x is met marge % voor de nacht.

Is dit mogelijk? Alvast bedankt.
Hiermee wil ik voorkomen dat de batterij in de ochtend laad (wanneer prijs positief) en al vol zit in de middag. En toch handelen. Import overdag en nacht beperken.

[ Voor 5% gewijzigd door Henkoes op 06-04-2026 12:52 ]

[Osxy]

Refl schreef op maandag 6 april 2026 @ 12:10:
[...]


Dit is top maar het enige wat ik erbij zou willen is dat wanneer je laden start, dat de Gielz dan zijn huidige state "bewaard", de zendure naar bijv. standby of enkel slimladen schakelt, en als de laadpaal klaar is, dat Gielz dan automatisch terugschakelt naar de vorige setting in plaats van een hardcoded setting.

Zal het eens aan Gemini vragen.

Dat is niet zo heel lastig, extra helper entity waar je de start setting in opslaat en die toepast bij terug zetten.

[Refl]

Osxy schreef op maandag 6 april 2026 @ 14:08:
[...]


Dat is niet zo heel lastig, extra helper entity waar je de start setting in opslaat en die toepast bij terug zetten.

Yes heb het draaien nu inderdaad Vind het altijd wel spannend met zelf programmeren - hoewel het lijkt te werken qua testen ben je toch altijd bang dat er een 0,1% scenario langs kan komen waardoor alles toch weer in de soep loopt.

[Osxy]

Refl schreef op maandag 6 april 2026 @ 14:16:
[...]


Yes heb het draaien nu inderdaad Vind het altijd wel spannend met zelf programmeren - hoewel het lijkt te werken qua testen ben je toch altijd bang dat er een 0,1% scenario langs kan komen waardoor alles toch weer in de soep loopt.

Ach bij dit soort zaken die alles behalve kritisch zijn denk ik niet super lang na over rare edge cases. Wat basis principes volgen en nette case statements met een default fallback scheelt al driekwart.

[Refl]

Osxy schreef op maandag 6 april 2026 @ 14:52:
[...]


Ach bij dit soort zaken die alles behalve kritisch zijn denk ik niet super lang na over rare edge cases. Wat basis principes volgen en nette case statements met een default fallback scheelt al driekwart.

Ja volgens mij is het enige waar je nu op moet letten dat als hij hem automatisch op een modus zet ivm EV laden, dat je dan niet handmatig de modus nog eens veranderd en denkt dat die modus zal blijven gelden, omdat na het laden hij weer terugschakeld wat de originele modus was voor de EV ging laden... Verder niet spannend.

[elektriekert]

gast777 schreef op maandag 6 april 2026 @ 11:43:
[...]


Bij een elektriekert had ik ook niet anders verwacht

Hier op deze zonnige paasochtend nog even ter illustratie een grafiek met Proxy waar ze ook beide tegelijk actief worden vanwege hoger vermogen:

[Afbeelding]

De SoC % van beide Zendures blijft ook netjes dicht bij elkaar

Zo... nu even genoeg reclame

Mijn username heeft dan weer niets met mij beroep te maken, wellicht 5%

Maar geniet van het weer zou ik zeggen

[MGZ]

gast777 schreef op zondag 5 april 2026 @ 18:17:
[...]


Dit is een nieuwe feature die nu beschikbaar is in de proxy flow in Node-RED.

Wat je kan doen is Node-RED installeren (kan als add-on van HA) en dan het flow bestand Zendure-proxy-Node-Red-flow.json van de Proxy daar importeren en activeren. Zie daar ook de handleiding, of zoek even algemeen over Node-RED op internet. Het is heel gebruiksvriendelijk, maar je moet het even weten.

Je hoeft de Proxy hiervoor niet te gebruiken. Die staat er los van, maar zit toevallig in dezelfde 'flow'.

Vervolgens heb je een aantal virtuele Zendure devices, die je kunt benaderen vanuit HA (of je browser) via REST commands alsof het een echte Zendure is. Je moet wel even een iets aangepaste URL gebruiken.

Het ziet er in Node-RED grafisch zo uit met de 4 testdevices:

[Afbeelding]

In je browser kun je gaan naar http://<node-red_ip_adres>:1880/endpoint/testdevice1/properties/report of http://<node-red_ip_adres>:1880/testdevice1/properties/report afhankelijk van je installatie (probeer gewoon beide en zie welke het is).

Voor HA Gielz uitproberen als je nog geen Zendure hebt, kun je hem toevoegen als "192.168.x.x:1880/testdevice1" of als "192.168.x.x:1880/endpoint/testdevice1" (dus weer afhankelijk van je installatie) in het invulveld "Zendure 2400 AC IP-adres". Dan zou je laden en ontladen kunnen starten en de Gielz denkt dat het echt is.

Zo kun je er een beetje een idee van krijgen hoe het zal werken.

Ik hoor het wel als het niet lukt.

Deze virtuele devices (toestellen is misschien een mooier woord ) gebruik ik zelf om de Gielz Proxy te testen met 3x SF2400AC, omdat ik er zelf maar 2 echte van heb. Het is momenteel wel beperkt wat ze kunnen (bijv de SoC verandert niet etc), maar voor wat basis testen werkt het toch heel aardig.

Dankzij de hulp en geduld van @gast777 heb ik het werkend gekregen.

[Maarten60]

Ik heb een apart package voor de situatie dat de auto laadt gemaakt. Kan ik makkelijk upgraden zonder eigen code aan te passen
Mijn logica

code:

Doel:
Tijdens EV laden mag de batterij niet ontladen naar de auto.
Na laden gaat alles weer terug naar normaal.

Logica:

- Start EV laden (EVSE = CHARGING):
  → sla huidige batterijmodus op
  → zet batterij op "Alleen slim opladen"

- EV laden klaar (CHARGING_FINISHED of AVAILABLE):
  → herstel oorspronkelijke batterijmodus

- Handmatige wijziging:
  → override uitzetten

- Na HA restart:
  → als EV nog laadt → opnieuw "Alleen slim opladen"

Waarom "Alleen slim opladen"?
→ voorkomt ontladen naar auto
→ laat wel laden op zonne-overschot toe

[Pakhaas]

Maarten60 schreef op maandag 6 april 2026 @ 17:31:
Ik heb een apart package voor de situatie dat de auto laadt gemaakt. Kan ik makkelijk upgraden zonder eigen code aan te passen
Mijn logica

code:

Doel:
Tijdens EV laden mag de batterij niet ontladen naar de auto.
Na laden gaat alles weer terug naar normaal.

Logica:

- Start EV laden (EVSE = CHARGING):
  → sla huidige batterijmodus op
  → zet batterij op "Alleen slim opladen"

- EV laden klaar (CHARGING_FINISHED of AVAILABLE):
  → herstel oorspronkelijke batterijmodus

- Handmatige wijziging:
  → override uitzetten

- Na HA restart:
  → als EV nog laadt → opnieuw "Alleen slim opladen"

Waarom "Alleen slim opladen"?
→ voorkomt ontladen naar auto
→ laat wel laden op zonne-overschot toe

Heb ik hier ook werken. Werkt ideaal en hoef er niet meer op te letten.

[wheli]

Willen jullie nog eens meedenken met mij? Ik probeer in het dashboard voor elkaar te krijgen dat de batterij alleen gaat laden op de goedkope momenten. Volgens mij (ik zit de instructie nu voor de 5e keer te lezen) moet dat kunnen met de 'Dynamisch NOM' stand.
Let even niet op vanochend, ik was aan het experimenteren. Maar ik heb hem nu op dynamisch NOM staan, er is 1200 watt zonne-opwek maar de goedkoopste periode (kwartierbasis) is nog op NEE.
Waarom gaat hij nu dan toch volle kracht laden?

[Wai_AM]

wheli schreef op dinsdag 7 april 2026 @ 09:31:
Willen jullie nog eens meedenken met mij? Ik probeer in het dashboard voor elkaar te krijgen dat de batterij alleen gaat laden op de goedkope momenten. Volgens mij (ik zit de instructie nu voor de 5e keer te lezen) moet dat kunnen met de 'Dynamisch NOM' stand.
Let even niet op vanochend, ik was aan het experimenteren. Maar ik heb hem nu op dynamisch NOM staan, er is 1200 watt zonne-opwek maar de goedkoopste periode (kwartierbasis) is nog op NEE.
Waarom gaat hij nu dan toch volle kracht laden?

[Afbeelding]

rechts boven staat duur, automatisering gaat dan nooit laden,
echter het is NOM, dus gaat hij laden met 799 W zo te zien.
Lijkt dus wel te doen zoals je hebt ingesteld.

als je alleen wilt laden op de goedkoopste momenten, dan zou je duurste periode op 0 zetten.

Verder zie ik dat je waarschijnlijk de dynamische inkoopprijs hebt ingesteld, of dat je geen belasting en toeslag hebt ingevuld.

[Aardedraadje]

wheli schreef op dinsdag 7 april 2026 @ 09:31:
Willen jullie nog eens meedenken met mij? Ik probeer in het dashboard voor elkaar te krijgen dat de batterij alleen gaat laden op de goedkope momenten. Volgens mij (ik zit de instructie nu voor de 5e keer te lezen) moet dat kunnen met de 'Dynamisch NOM' stand.
Let even niet op vanochend, ik was aan het experimenteren. Maar ik heb hem nu op dynamisch NOM staan, er is 1200 watt zonne-opwek maar de goedkoopste periode (kwartierbasis) is nog op NEE.
Waarom gaat hij nu dan toch volle kracht laden?

[Afbeelding]

Wat je (denk ik) wilt bereiken, kan niet. Wat het dichtst in de buurt komt bereik je met Dynamisch NOM (duur). Dan gaat hij (volle bak, dus 2400W) laden bij de goedkope uren. En tijdens de dure uren Nul-op-meter (alleen ontladen) .

Een modus waarin hij alleen laadt vanaf je zonnepanelen tijdens goedkoop, en alleen ontlaadt tijdens dure uren, bestaat niet. Die zou je wel eenvoudig zelf kunnen knutselen met een automation:

Wanneer uren goedkoop = Ja -> Modus op alleen slim laden.
Wanneer uren duur = Ja -> Modus op alleen slim ontladen.

[ Voor 3% gewijzigd door Aardedraadje op 07-04-2026 12:34 ]

[wheli]

Oke, thanks. Dan ligt het in ieder geval niet aan mij ;-)
Ik kijk inderdaad altijd naar de prijzen zonder belasting zolang er nog saldering is. Ik wek iets meer op dan in verbruik namelijk op jaarbasis.

Die automatisering is een goed idee, thanks. Ga ik maken

[Hippe Lip]

wheli schreef op dinsdag 7 april 2026 @ 09:31:
Willen jullie nog eens meedenken met mij? Ik probeer in het dashboard voor elkaar te krijgen dat de batterij alleen gaat laden op de goedkope momenten. Volgens mij (ik zit de instructie nu voor de 5e keer te lezen) moet dat kunnen met de 'Dynamisch NOM' stand.
Let even niet op vanochend, ik was aan het experimenteren. Maar ik heb hem nu op dynamisch NOM staan, er is 1200 watt zonne-opwek maar de goedkoopste periode (kwartierbasis) is nog op NEE.
Waarom gaat hij nu dan toch volle kracht laden?

[Afbeelding]

P1 staat op -278W en je PV levert veel op.
Je hebt dynamisch NOM ingesteld. Betekent dat niet dat de batterij zoveel mogelijk je PV opvangt (NOM)? Dat lijkt die te doen, want je levert zelfs iets terug (marge).
Dat lijkt me precies wat deze modus zou moeten doen toch? Of wil je niet laden en je PV-overschot het net op gooien? Dat doet dynamisch NOM wel voor je, maar dan op het duurste moment, zodat je er zoveel mogelijk aan overhoudt.

[wheli]

Hippe Lip schreef op dinsdag 7 april 2026 @ 14:14:
[...]

P1 staat op -278W en je PV levert veel op.
Je hebt dynamisch NOM ingesteld. Betekent dat niet dat de batterij zoveel mogelijk je PV opvangt (NOM)? Dat lijkt die te doen, want je levert zelfs iets terug (marge).
Dat lijkt me precies wat deze modus zou moeten doen toch? Of wil je niet laden en je PV-overschot het net op gooien? Dat doet dynamisch NOM wel voor je, maar dan op het duurste moment, zodat je er zoveel mogelijk aan overhoudt.

Ja dat laatste wil ik. Ik heb zonnepanelen op NO. Dus vanochtend toen de stroom 49 cent was wekte ik 1000 watt op. Die gaat nu regelrecht de batterij in met 15% verlies. Ik wacht dan liever op de goedkoopste momenten om hem vol te laden, dus alleen de goedkoper momenten.
Ik heb nu 3 automatiseringen gemaakt nav @Aardedraadje . De twee die gesuggereerd werden + als de batterij vol is (100%) dan gaat hij naar dynamische NOM. Als het goed is gaat hij bij de dure uren straks terug naar slim ontladen

[Refl]

wheli schreef op dinsdag 7 april 2026 @ 14:18:
[...]


Ja dat laatste wil ik. Ik heb zonnepanelen op NO. Dus vanochtend toen de stroom 49 cent was wekte ik 1000 watt op. Die gaat nu regelrecht de batterij in met 15% verlies. Ik wacht dan liever op de goedkoopste momenten om hem vol te laden, dus alleen de goedkoper momenten.
Ik heb nu 3 automatiseringen gemaakt nav @Aardedraadje . De twee die gesuggereerd werden + als de batterij vol is (100%) dan gaat hij naar dynamische NOM. Als het goed is gaat hij bij de dure uren straks terug naar slim ontladen

Dynamisch Handelen pakken en goedkope uurtjes selecteren (zo voorkom je dat bij PV opbrengt bij een duurder kwartier/uur je die 85% verlies neemt). Misschien kun je marge op 0 zetten, of anders 1 uurtje/kwartiertje als duur aanmerken.

Dan heb je wel geen NOM meer... Je kunt die nieuwe modus Dynamisch Handelen + NOM proberen (nieuw sinds de maart update). Maar ik zie het nut van NOM nog niet in 2026 met salderingsregeling. Leuk dat je kunt voorkomen dat je snachts stroom inkoopt voor zeg 25 cent, maar met salderen kun je die stroom beter ontladen het net op voor 30+ cent en weer klaar zijn voor de volgende dag zon/goedkope stroom. Puur financieel gezien dan natuurlijk.

[ Voor 20% gewijzigd door Refl op 07-04-2026 14:32 ]

[Hippe Lip]

wheli schreef op dinsdag 7 april 2026 @ 14:18:
Ja dat laatste wil ik.

Dan moet je geen (al dan niet dynamisch) NOM kiezen, want die doet wat de naam zegt: Nul Op de Meter houden in plaats van terugleveren.

Gebruik dan de stand ‘handel’ (of hoe die ook heet) van @gielz. Die koopt in op de goedkoopste (door jou instelbaar aantal) uren en levert terug op de duurste uren.
Is dat niet precies wat je zoekt?

[DeadMetal]

Als ik de Node-Red flow van @gast777 zou willen gebruiken, moeten er dan 2 exact identieke systemen staan? Of kan een 2400 AC+ ook met een 2400 Pro gecombineerd worden?

[NiCNCo]

Devke schreef op zondag 29 maart 2026 @ 15:39:
[...]

Ik zie dat @Wai_AM je verder helpt. Ik denk dat je verkeerd geknipt en geplakt hebt. Goede hulp kan ChatGPT zijn. Zeker met code.

Ik heb om deze reden even de titelveld aangepast als geheugensteuntje hoe de value in getypt dient te worden.

[NiCNCo]

DeadMetal schreef op dinsdag 7 april 2026 @ 20:01:
Als ik de Node-Red flow van @gast777 zou willen gebruiken, moeten er dan 2 exact identieke systemen staan? Of kan een 2400 AC+ ook met een 2400 Pro gecombineerd worden?

Ja dat is geen probleem, zolang ze maar even veel vermogen aankunnen (in/uit) en er dezelfde hoeveel capaciteit hebben, geen solarflow 800 gaan mengen met een 2400AC bijvoorbeeld. Mits je de max inuit op 1600watt houd zodat de solarflow 800 niet overvraagt raakt. Maar beste is gewoon twee dezelfde, 2400AC, AC+ of PRO mengen dus prima zonder verdere zorgen. Staat netjes op de Github beschreven trouwens van gast777 proxy https://github.com/gast77...#nieuw-in-versie-20260404

Vereisten: https://github.com/gast77...=readme-ov-file#vereisten

• 2x of 3x Zendure SolarFlow 2400 AC (of SolarFlow 2400 AC+/Pro, SolarFlow 1600 AC+ of Zendure SolarFlow 800 Plus/Pro). In principe zal een combinatie van twee verschillende modellen ook werken. Wel is het aan te bevelen dat beide devices ongeveer dezelfde hoeveelheid kWh aan batterijopslag en hetzelfde max vermogen hebben (bijvoorbeeld een SolarFlow 2400AC en een SolarFlow 2400AC+).
• Zorg dat op beide Zendures hetzelfde maximale en minimale laadpercentage (SoC percentages) ingesteld staan. Dit kan via de Zendure App.
• Beide Zendures moeten hetzelfde aantal batterijen hebben of ongeveer dezelfde hoeveelheid kWh aan batterijopslag.
• De beide Zendures en de Node-RED server moeten een vast IP adres hebben.
• Wifi ontvangst moet uitstekend zijn.
• Beide Zendures moeten beschikbaar zijn via het netwerk en werken.

[ Voor 49% gewijzigd door NiCNCo op 07-04-2026 20:41 ]

[DeadMetal]

NiCNCo schreef op dinsdag 7 april 2026 @ 20:35:
[...]


Ja dat is geen probleem, zolang ze maar even veel vermogen aankunnen (in/uit) en er dezelfde hoeveel capaciteit hebben, geen solarflow 800 gaan mengen met een 2400AC bijvoorbeeld. Mits je de max inuit op 1600watt houd zodat de solarflow 800 niet overvraagt raakt. Maar beste is gewoon twee dezelfde, 2400AC, AC+ of PRO mengen dus prima zonder verdere zorgen. Staat netjes op de Github beschreven trouwens van gast777 proxy https://github.com/gast77...#nieuw-in-versie-20260404

Vereisten: https://github.com/gast77...=readme-ov-file#vereisten

• 2x of 3x Zendure SolarFlow 2400 AC (of SolarFlow 2400 AC+/Pro, SolarFlow 1600 AC+ of Zendure SolarFlow 800 Plus/Pro). In principe zal een combinatie van twee verschillende modellen ook werken. Wel is het aan te bevelen dat beide devices ongeveer dezelfde hoeveelheid kWh aan batterijopslag en hetzelfde max vermogen hebben (bijvoorbeeld een SolarFlow 2400AC en een SolarFlow 2400AC+).
• Zorg dat op beide Zendures hetzelfde maximale en minimale laadpercentage (SoC percentages) ingesteld staan. Dit kan via de Zendure App.
• Beide Zendures moeten hetzelfde aantal batterijen hebben of ongeveer dezelfde hoeveelheid kWh aan batterijopslag.
• De beide Zendures en de Node-RED server moeten een vast IP adres hebben.
• Wifi ontvangst moet uitstekend zijn.
• Beide Zendures moeten beschikbaar zijn via het netwerk en werken.

Ah top, dank je. Ik twijfelde door de tekst op de Github van gielz waar staat 'Of twee dezelfde omvormers in combinatie met de Node-RED proxy van Gast777'

[Yell0]

pasmanm schreef op donderdag 26 maart 2026 @ 20:38:
Ik heb de Gielz-integratie in Home Assistant inmiddels draaiend, maar ik loop tegen onverwacht gedrag aan bij de Standby-modus.

Mijn verwachting is dat de batterij in Standby-modus volledig stopt met laden en ontladen (0W verbruik/levering).

In de praktijk gebeurt echter het volgende:
*) De batterij staat in NOM en ontlaadt netjes met 800W.
*) Ik schakel handmatig over naar Standby.
*) Er volgt een korte pauze waarbij de levering naar 0W zakt.
*) Na deze korte pauze springt de batterij echter vanzelf weer terug naar ontladen met 800W, ondanks dat de status nog op 'Standby' staat.

Zou Standby de batterij niet simpelweg moeten bevriezen? Zie ik iets over het hoofd in de configuratie of wordt dit commando door het systeem overschreven?[Afbeelding]

[Afbeelding]

Heb jij dit nog opgelost? Ik loop tegen hetzelfde aan namelijk en ben de hele middag aan het klooien.....

[wheli]

Hippe Lip schreef op dinsdag 7 april 2026 @ 14:50:
[...]

Dan moet je geen (al dan niet dynamisch) NOM kiezen, want die doet wat de naam zegt: Nul Op de Meter houden in plaats van terugleveren.

Gebruik dan de stand ‘handel’ (of hoe die ook heet) van @gielz. Die koopt in op de goedkoopste (door jou instelbaar aantal) uren en levert terug op de duurste uren.
Is dat niet precies wat je zoekt?

Misschien was ik niet helemaal duidelijk; ik wil graag dat de batterij gaat laden op de goedkoopste uren die ik instel (meestal 4-6 uur per dag). Daarna moet hij NOM nastreven. Bij de dynamische handelsstand ging hij heel vaak aan en uit vorige week toen de prijzen door de dag heen schommelden. Dat was ook niet de bedoeling haha.
Ik zal eerst deze automatisering eens testen. Tot nu toe werkt het goed.

[koboy]

wheli schreef op dinsdag 7 april 2026 @ 21:17:
[...]


Misschien was ik niet helemaal duidelijk; ik wil graag dat de batterij gaat laden op de goedkoopste uren die ik instel (meestal 4-6 uur per dag). Daarna moet hij NOM nastreven. Bij de dynamische handelsstand ging hij heel vaak aan en uit vorige week toen de prijzen door de dag heen schommelden. Dat was ook niet de bedoeling haha.
Ik zal eerst deze automatisering eens testen. Tot nu toe werkt het goed.

De HEMS dynamische tarieven mode is inderdaad een beetje rommelig omdat die met vaste tarief-grenzen werkt en in elk geval met Zonneplan vast bleef houden aan kwartier- ipv uur-prijzen.

Met de Gielz integratie icm met uurprijzen (Zonneplan) pakt hij bij mij keurig 1 of 2 aaneengesloten blokken per dag obv wat de goedkoopste uren zijn. Of dat met kwartierprijzen ook lukt weet ik niet die zijn nog rafelig in op en afbouw van de ochtend en avondpiek.

[pasmanm]

Yell0 schreef op dinsdag 7 april 2026 @ 21:07:
[...]


Heb jij dit nog opgelost? Ik loop tegen hetzelfde aan namelijk en ben de hele middag aan het klooien.....

Hoewel de standaard Zendure-integratie prima draait, blijft de Gielz-variant een probleemgeval. Ik heb van alles geprobeerd: de SF2400 gereset, gewisseld tussen integraties in HA en alle forumtips en instellingen gecheckt.
Niets hielp. Ik heb het voor nu opgegeven en ben terug bij de standaard integratie.
Mocht jij de oplossing vinden, dan hoor ik het graag.

[Lange_Slurf]

Zojuist de nieuwste YAML geupdate en ook meteen over gestapt op de "package" variant.

Gaat zeer makkelijk, echter lijkt 1 attribuut niet echt te laden.

"Available Energy", en daarmee dus ook remaining discharge time hebben nog een waarde van 0.
Is dit iets wat met de loop van de tijd vanzelf komt?
Total capacity is wel iets dat wordt weergegeven (17,28 kWh) en het laadpercentage is bekend, dat zou toch eigenlijk al een goede waarde moeten geven?

[gielz]

Yell0 schreef op dinsdag 7 april 2026 @ 21:07:
[...]


Heb jij dit nog opgelost? Ik loop tegen hetzelfde aan namelijk en ben de hele middag aan het klooien.....

Waar loop je exact tegen aan? Is het de standaard 800 watt ontlaad actie?

Ik zou dan het volgende checken, tabblad 4 van het dashboard toont exact aan wat de batterij doet van uit Home Assistant. Staat hier niets dan doet hij ook niets en komt een vermogensaansturing ergens anders vandaan.

99/100x is dit een foutieve installatie van de Zendure in de verwarrende app. Wanneer je namelijk een Zendure gaat toevoegen geeft hij aan hoeveel vermogen je max wil en wat de baseload is. Deze moet uiteraard op 0 want je wilt geen baseload naar huis. En HEMS uiteraard uit maar dat spreekt voor zich.

[gielz]

Lange_Slurf schreef op dinsdag 7 april 2026 @ 22:39:
Zojuist de nieuwste YAML geupdate en ook meteen over gestapt op de "package" variant.

Gaat zeer makkelijk, echter lijkt 1 attribuut niet echt te laden.

"Available Energy", en daarmee dus ook remaining discharge time hebben nog een waarde van 0.
Is dit iets wat met de loop van de tijd vanzelf komt?
Total capacity is wel iets dat wordt weergegeven (17,28 kWh) en het laadpercentage is bekend, dat zou toch eigenlijk al een goede waarde moeten geven?

Zo te lezen werk je met de engelse test variant. De berekening heeft wat tijd nodig want hij kijkt naar de berekende efficientie (zichtbaar als je hem aanklikt en bij de attributen kijkt). Ik heb zojuist ook een nieuwe testversie er op gezet omdat in de engelse variant hier een tikfout in zat.

Deze versie is trouwens wel bijna stable, alleen aangesloten PV is nog niet volledig getest.

[Lange_Slurf]

Tnx, Engels of Nederlands maakt mij niet zoveel uit, ik had eigenlijk niet door of er ook een NL versie is. *edit* NL versie geïnstalleerd en "alle" stats zijn terug. Ik denk dat er nog NL stats in HASS geschreven stonden.

Overigens, in de screenshot die jij laat zien vanuit de Zendure app. Waar jij "nul" hebt staan bij output to home, zie je bij mij een waarde fluctuerend gelijk aan de de daadwerkelijke ontlading (op dit moment dan).

*"zendure_2400_ac_soc_status" staat op Unavailable, komt dit ook door de taalkeuze?

*Welke card heeft deze pijltjes? Ik kan alleen maar numeriek invoeren.

[ Voor 80% gewijzigd door Lange_Slurf op 07-04-2026 23:20 ]

[raven22]

@gielz Is het mogelijk om ook een negatieve waarde toe te staan bij de ontlaad marge?
Nu is de p1 waarde vaak net negatief, ik heb hem liever net een beetje meer positief.

[Yell0]

gielz schreef op dinsdag 7 april 2026 @ 22:39:
[...]


Waar loop je exact tegen aan? Is het de standaard 800 watt ontlaad actie?

Ik zou dan het volgende checken, tabblad 4 van het dashboard toont exact aan wat de batterij doet van uit Home Assistant. Staat hier niets dan doet hij ook niets en komt een vermogensaansturing ergens anders vandaan.

99/100x is dit een foutieve installatie van de Zendure in de verwarrende app. Wanneer je namelijk een Zendure gaat toevoegen geeft hij aan hoeveel vermogen je max wil en wat de baseload is. Deze moet uiteraard op 0 want je wilt geen baseload naar huis. En HEMS uiteraard uit maar dat spreekt voor zich.

[Afbeelding]

Ik heb een 2400Pro en wat ik ook ingeef in de Zendure app, de app blijft in de lead en ik krijg wel de waardes door in HA in Gielz, maar kan vanuit HA niet de lead nemen. Ik heb zo'n beetje alle opties geprobeerd in de app (eerst alles zonder HEMS, daarna zelfs met.....), maar niets lijkt te werken. Ik ben zeer benieuwd of iemand met een 2400Pro, het wel werkend heeft gekregen en dan met welke settings.

[Lange_Slurf]

Yell0 schreef op dinsdag 7 april 2026 @ 23:09:
[...]


Ik heb een 2400Pro en wat ik ook ingeef in de Zendure app, de app blijft in de lead en ik krijg wel de waardes door in HA in Gielz, maar kan vanuit HA niet de lead nemen. Ik heb zo'n beetje alle opties geprobeerd in de app (eerst alles zonder HEMS, daarna zelfs met.....), maar niets lijkt te werken. Ik ben zeer benieuwd of iemand met een 2400Pro, het wel werkend heeft gekregen en dan met welke settings.

Eigenlijk hoef je niets meer met de Zendure app te doen, af en toe een update van je devices draaien, meer niet.

Staat het schuifje bij "add to HEMS" uit? (naar links?)
En wat zegt tab 4 bij het logboek in home assistant?

[Yell0]

Lange_Slurf schreef op dinsdag 7 april 2026 @ 23:29:
[...]


Eigenlijk hoef je niets meer met de Zendure app te doen, af en toe een update van je devices draaien, meer niet.

Staat het schuifje bij "add to HEMS" uit? (naar links?)
En wat zegt tab 4 bij het logboek in home assistant?

Het HEMS schuifje staat zeker uit en het logbook laat alleen de acties zien die ik in HA probeer, maar dus geen effect hebben. Ik krijg alleen maar actie als ik direct in de app iets opgeef. De nacht heeft deze nu vast staan ontladen met 300w, om het sluipverbruik af te dekken, maar zou er graag meer meedoen.....

[gielz]

Yell0 schreef op woensdag 8 april 2026 @ 06:28:
[...]


Het HEMS schuifje staat zeker uit en het logbook laat alleen de acties zien die ik in HA probeer, maar dus geen effect hebben. Ik krijg alleen maar actie als ik direct in de app iets opgeef. De nacht heeft deze nu vast staan ontladen met 300w, om het sluipverbruik af te dekken, maar zou er graag meer meedoen.....

Ik ben zelf hier intensief aan het testen met een 2400 pro. Zou het volgende proberen;

Eerst even een herstart testen door de knop 6 sec (hoort dan piepjes) in te drukken en de stekker er uit en in te doen. Is dit niet de oplossing dan opnieuw toevoegen in de app en tijdens de configuratie alles waar een vraag over watt komt deze op 0 watt zetten.

Je ziet trouwens dus wel alle data in HA?

[zeegerd]

Hi, even checken: zijn hier mensen die hun Hyper(s) zonder problemen lokaal aansturen met BlueTooth + Zendure-integratie (Fireson) in Home Assistant? Ik maak helaas iets te vaak mee dat er een Hyper bevriest, met alle vervelende gevolgen van dien, zoals: de een blijft laden, de andere gaat ontladen. Krijg de indruk dat dit door Zendure ook niet gefixt kan worden.

Ook handig aan lokaal: geen afhankelijkheid van (Chinese) internetdienst.

Mijn HA Green microcomputer heeft zelf geen BT, maar dit zou met een ESP32-bordje vrij eenvoudig moeten kunnen.

[hremijn]

Yell0 schreef op woensdag 8 april 2026 @ 06:28:
[...]


Het HEMS schuifje staat zeker uit en het logbook laat alleen de acties zien die ik in HA probeer, maar dus geen effect hebben. Ik krijg alleen maar actie als ik direct in de app iets opgeef. De nacht heeft deze nu vast staan ontladen met 300w, om het sluipverbruik af te dekken, maar zou er graag meer meedoen.....

Ik heb een 2400pro en ik kan niets doen met de batterij vanuit de app.
Dus ook geen opdrachten geven om te ontladen.
Bij alle acties die ik doe vanuit Home in de app krijg ik de melding "Please add energy storage device".
Ik kan wel bij de devices de status zien en firmware upgrade.
Het lijkt erop dat er bij jou nog een energieopslagsysteem actief is in de app.

[Refl]

Als je op 1 dag een laad en ontlaad cyclus hebt (van rond de 10% naar 100% en terug, pakhembeet) en de spread staat die dag op bijvoorbeeld 19 cent in Gielz:

Klopt het dan dat je die dag je accu in kWh (bijvoorbeeld 10) * 0,9 (10-100 laden) * 0,85 (RTE) * 0,19 euro verdient oplevert op die dag? Natte vinger bierviltje?

EDIT: Verdienen is relatief natuurlijk omdat je kijkt naar tarieven maar PV stroom wat je opslaat en verkoopt is de marge groter dan die 19 cent

[ Voor 20% gewijzigd door Refl op 08-04-2026 10:41 ]

[koboy]

Refl schreef op woensdag 8 april 2026 @ 10:38:
Als je op 1 dag een laad en ontlaad cyclus hebt (van rond de 10% naar 100% en terug, pakhembeet) en de spread staat die dag op bijvoorbeeld 19 cent in Gielz:

Klopt het dan dat je die dag je accu in kWh (bijvoorbeeld 10) * 0,9 (10-100 laden) * 0,85 (RTE) * 0,19 euro verdient oplevert op die dag? Natte vinger bierviltje?

EDIT: Verdienen is relatief natuurlijk omdat je kijkt naar tarieven maar PV stroom wat je opslaat en verkoopt is de marge groter dan die 19 cent

Klopt precies. Dit jaar trouwens ook voor PV stroom. Volgend jaar moet je onderscheid gaan maken tussen PV en ingekochte stroom.

[Hippe Lip]

wheli schreef op dinsdag 7 april 2026 @ 21:17:
Misschien was ik niet helemaal duidelijk; ik wil graag dat de batterij gaat laden op de goedkoopste uren die ik instel (meestal 4-6 uur per dag). Daarna moet hij NOM nastreven. Bij de dynamische handelsstand ging hij heel vaak aan en uit vorige week toen de prijzen door de dag heen schommelden. Dat was ook niet de bedoeling haha.
Ik zal eerst deze automatisering eens testen. Tot nu toe werkt het goed.

@wheli Dan is je doel nog niet duidelijk. Wat streef je na?

1. Laagste kosten (eventueel zelfs winst) of
2. Maximaliseren eigen gebruik van PV?

[ppaulv]

Hippe Lip schreef op zaterdag 4 april 2026 @ 09:17:
[...]

Dank je @gielz
Alleen werk dat, als ik je goed begrijp, met een vaste dumpperiode. Als er dan eens minder in de accu zit dan haal je opeens de rest van de nacht niet meer met NOM. Voor een zorgeloze werking zal er toch een berekening (educated guess, zoals dat zo mooi heet) gemaakt moeten worden van wat er nog nodig is tot de volgende zonbijdrage. Als dat er is dan is de modus Dynamisch Handelen + NOM écht compleet!

Even voor de beeldvorming.
Stel je hebt een vaste dumpperiode (verkoop) en aan het begin of halverwege (maakt niet uit) heb je nog x% accu. En normaliter verbruik je dat zelf in huis totdat er weer opgeladen gaat worden.
Dan zou je graag de beschikbare accu-energie legen / gebruiken tegen de hoogste prijs, rekening houdend met zo'n 15% systeemverlies. En niet midden in de nacht dumpen tegen lage prijs om een paar uur later de hoofdprijs te betalen voor m'n verbruik.
Dus 2 scenario's gedurende de nacht :
1) voorkeur voor eigen gebruik uit accu: telkens rekening houden met te verwachten eigen verbruik en eventueel overschot dumpen tijdens de duurdere uren in de ochtendspits (als die er zijn)
2) voorkeur voor dumpen tijdens duurste uren : afhankelijk van aanwezige accu lading bepalen hoeveel uur daarmee gedumpt kan worden en dat doen tijdens de duurste overeenkomende periode in de komende 12 uur / totdat de zon gaat schijnen.
Is dit zinnige praat of klets ik nu maar wat (hoop het eerste)?

[Floris039]

ppaulv schreef op woensdag 8 april 2026 @ 13:48:
[...]

Even voor de beeldvorming.
Stel je hebt een vaste dumpperiode (verkoop) en aan het begin of halverwege (maakt niet uit) heb je nog x% accu. En normaliter verbruik je dat zelf in huis totdat er weer opgeladen gaat worden.
Dan zou je graag de beschikbare accu-energie legen / gebruiken tegen de hoogste prijs, rekening houdend met zo'n 15% systeemverlies. En niet midden in de nacht dumpen tegen lage prijs om een paar uur later de hoofdprijs te betalen voor m'n verbruik.
Dus 2 scenario's gedurende de nacht :
1) voorkeur voor eigen gebruik uit accu: telkens rekening houden met te verwachten eigen verbruik en eventueel overschot dumpen tijdens de duurdere uren in de ochtendspits (als die er zijn)
2) voorkeur voor dumpen tijdens duurste uren : afhankelijk van aanwezige accu lading bepalen hoeveel uur daarmee gedumpt kan worden en dat doen tijdens de duurste overeenkomende periode in de komende 12 uur / totdat de zon gaat schijnen.
Is dit zinnige praat of klets ik nu maar wat (hoop het eerste)?

Klinkt logisch. Ik denk dat de dump het beste net kan plaatsvinden voordat de zonnepanelen gaan werken (als iedereen wakker wordt en de prijzen hoog genoeg zijn) want dat is normaal gesproken het moment dat de prijzen naast rond het avondeten het duurste zijn. Maar dan moet het verschil wel groot genoeg zijn tussen de duurste en goedkope momenten. En dan vooral na 1-1-27....

[ppaulv]

@Floris039 want ..... volgens jou kun je dit jaar nog tot 1 jan beter salderen met vaste prijzen dan gebruik maken van dynamische prijzen?
Ik moet per 1 juli aan een nieuw contract ....

[ Voor 14% gewijzigd door ppaulv op 08-04-2026 15:19 ]

[Floris039]

ppaulv schreef op woensdag 8 april 2026 @ 15:19:
@Floris039 want ..... volgens jou kun je dit jaar nog tot 1 jan beter salderen met vaste prijzen dan gebruik maken van dynamische prijzen?
Ik moet per 1 juli aan een nieuw contract ....

Eh nee, ik ging er vanuit dat je dat doet met dynamische prijzen. Ik zei toch ook dat het verschil tussen hoog en laag tarief aanwezig moet zijn anders is terugleveren totaal niet interessant... En in dat geval boeit het niet wanneer je het teruglevert want er is dan geen geld te verdienen door de piek te verschuiven.

Wat ik bedoelde met vanaf 1-1-27 is dat vanaf dan het verschil tussen hoog en laag tarief (dynamisch) NOG hoger moet zijn omdat je ook de energiebelasting dan moet terug verdienen als je terug levert.

Ik heb thuis een dynamisch energietarief maar dat is voor iedereen natuurlijk eigen afweging. Ik ben dr in ieder geval heel blij mee.

[ppaulv]

ok, dan begrijpen we elkaar.
En om geld te verdienen na 1 jan moet je een nog grotere spread hebben? Ik begrijp dat ik me nog meer moet inlezen, die had ik nog niet zo begrepen.
Maar ook al verdien ik er niets aan maar beperk ik het verlies maximaal met m'n accu, dan nog is het de moeite waard om te doen. Toch?

[Sander]

ppaulv schreef op woensdag 8 april 2026 @ 18:31:
ok, dan begrijpen we elkaar.
En om geld te verdienen na 1 jan moet je een nog grotere spread hebben? Ik begrijp dat ik me nog meer moet inlezen, die had ik nog niet zo begrepen.
Maar ook al verdien ik er niets aan maar beperk ik het verlies maximaal met m'n accu, dan nog is het de moeite waard om te doen. Toch?

Nu kun je goedkoop inkopen en duur verkopen (en je zonnepanelen eigenlijk negeren als je per saldo meer verbruikt dan teruglevert). vanaf 1-1 zou je nog steeds goedkoop inkopen maar zal duur verkopen minder interessant zijn door het salderen. Dus dan wordt de volgorde: eigen zonnestroom (en die zoveel mogelijk gelijk verbruiken), evt tekort kun je goedkoop inkopen en dan rest van de tijd NOM draaien om niet duur in te hoeven kopen.

[Yell0]

gielz schreef op woensdag 8 april 2026 @ 06:34:
[...]


Ik ben zelf hier intensief aan het testen met een 2400 pro. Zou het volgende proberen;

Eerst even een herstart testen door de knop 6 sec (hoort dan piepjes) in te drukken en de stekker er uit en in te doen. Is dit niet de oplossing dan opnieuw toevoegen in de app en tijdens de configuratie alles waar een vraag over watt komt deze op 0 watt zetten.

Je ziet trouwens dus wel alle data in HA?

Ja, ik zie alle data in HA. En nu ik er verder induik zie ik ook dat het aantal batterijen over de tijd wisselt tussen 3 en 4. De capaciteit maakt tegelijkertijd ook rare sprongen. De serienummers bekeken, is het de Pro zelf die verdwijnt........maar hij functioneert nog wel. Kan/zal waarschijnlijk een technisch issue zijn en een Ticket gelogged dus.........

[Hippe Lip]

ppaulv schreef op woensdag 8 april 2026 @ 18:31:
ok, dan begrijpen we elkaar.
En om geld te verdienen na 1 jan moet je een nog grotere spread hebben? Ik begrijp dat ik me nog meer moet inlezen, die had ik nog niet zo begrepen.
Maar ook al verdien ik er niets aan maar beperk ik het verlies maximaal met m'n accu, dan nog is het de moeite waard om te doen. Toch?

Voor jouw begrip en omdat je mij hierboven quootte: ik zit in de situatie dat ik in de zomermaanden veel meer opwek dan ik verbruik. Dat betekent dat ik sowieso ga terugleveren (of curltailen, maar dat ben ik niet echt van plan). In die situatie is er voor mij geen sprake van inkopen, omdat ik in die maanden volledig op eigen opwek kan draaien.
Tenminste: zolang ik het niet verpest door ergens in de nacht de héle inhoud van mijn accu aan het net te leveren, want dan moet ik om de rest van de nacht door te komen tóch nog wat van het net halen. Dat is hoe dan ook duurder, omdat alles dat in mijn accu zit immers gratis is!

Dat was de basis voor mijn vraag aan @gielz. Ik zal dus een automatisering moeten maken die dat terugleveren tegen de hoogste prijs zal afbreken bij een bepaalde minimumlading van mijn accu. Dus stel dat ik 4 kWh in een nacht nodig heb, dan moet het terugleveren (verkopen) stoppen bij 14% (10% minimum accuwaarde + mijn 4% voor de nacht).
En dat geldt met name vanaf 2027.

[gielz]

Hippe Lip schreef op woensdag 8 april 2026 @ 21:39:
[...]

Voor jouw begrip en omdat je mij hierboven quootte: ik zit in de situatie dat ik in de zomermaanden veel meer opwek dan ik verbruik. Dat betekent dat ik sowieso ga terugleveren (of curltailen, maar dat ben ik niet echt van plan). In die situatie is er voor mij geen sprake van inkopen, omdat ik in die maanden volledig op eigen opwek kan draaien.
Tenminste: zolang ik het niet verpest door ergens in de nacht de héle inhoud van mijn accu aan het net te leveren, want dan moet ik om de rest van de nacht door te komen tóch nog wat van het net halen. Dat is hoe dan ook duurder, omdat alles dat in mijn accu zit immers gratis is!

Dat was de basis voor mijn vraag aan @gielz. Ik zal dus een automatisering moeten maken die dat terugleveren tegen de hoogste prijs zal afbreken bij een bepaalde minimumlading van mijn accu. Dus stel dat ik 4 kWh in een nacht nodig heb, dan moet het terugleveren (verkopen) stoppen bij 14% (10% minimum accuwaarde + mijn 4% voor de nacht).
En dat geldt met name vanaf 2027.

Zit wel iets ingewikkelder in elkaar helaas. Je zou hem inderdaad kunnen stoppen bij xx% maar wat als er daarna een SOC drop is dan koop je heel de nacht alles in en heb je nog niets.

Wat ook nog belangrijk is om mee te nemen; Er zijn zat dagen dat de dag gewoon slecht begint maar dat er bijvoorbeeld wel gewassen moet worden of dat je de stroom gewoon nodig hebt. Dat moet je dan ook inkopen omdat je met een zeer lage SOC de nacht in gaat. Dit is eigenlijk de hoofdreden dat het er niet standaard in zit. Zoveel mogelijkheden en uitkomsten.

Zelf zal ik eerder gewoon tijdens het koken maximaal terugleveren om alle kook/oven golfjes mooi op te vangen in de opwekmaanden.

[Wai_AM]

Heb eindelijk officiele nordpool integratie werkend:

Voor als je die wilt gebruiken met Gielz Zendure-HA-zenSDK

- Zorg dat je HACS nordpool verwijdert (echt verwijderen)
- maak in packages map een bestand genaamd nordpool_officical.yaml (of een naam naar keuze)
plak onderstaande erin

code:

input_number:
  energiebelasting:
    name: energiebelasting
    icon: mdi:numeric
    min: 0
    max: 10
    step: 0.1
    mode: box

  opslag_energieleverancier:
    name: opslag_energieleverancier
    icon: mdi:numeric
    min: 0
    max: 10
    step: 0.1
    mode: box

  btw_percentage:
    name: btw_percentage
    icon: mdi:numeric
    min: 0
    max: 10
    step: 0.1
    mode: box

template:
  - triggers:
    - trigger: time_pattern
      minutes: /1
    - trigger: homeassistant
      event: start
    action:
      - variables:
          area: NL
          currency: EUR
          config_entry: [b]<config entry ID>[/b]
          price_now: sensor.nord_pool_nl_huidige_prijs
          price_low: sensor.nord_pool_nl_laagste_prijs
          price_high: sensor.nord_pool_nl_hoogste_prijs
      - action: nordpool.get_price_indices_for_date
        data:
          config_entry: "{{ config_entry }}"
          date: "{{ now().date() }}"
          areas: "{{ area }}"
          currency: "{{ currency }}"
          resolution: "15"
        response_variable: today_price
      - action: nordpool.get_price_indices_for_date
        data:
          config_entry: "{{ config_entry }}"
          date: "{{ now().date() + timedelta(days=1) }}"
          areas: "{{ area }}"
          currency: "{{ currency }}"
          resolution: "15"
        response_variable: tomorrow_price
    sensor:
      - name: nordpool_kwh_nl_eur_5_09_0
        unique_id: nordpool_kwh_nl_eur_5_09_0
        unit_of_measurement: "€/kWh"
        icon: mdi:cash
        device_class: energy
        state: > # returns the current price
          {% set electricity_tax = states('input_number.energiebelasting') | float(0) %}
          {% set purchase_costs = states('input_number.opslag_energieleverancier') | float(0) %}
          {% set vat = states('input_number.btw_percentage') | float(0) %}
          {% set current_price = ((states(price_now) | float(0) + ((states(price_now) | float(0) * vat) + (electricity_tax + purchase_costs) * (1 + vat))) | round(4) ) %}
          {{ current_price }}
        attributes:
          tomorrow_valid: >
            {{ tomorrow_price["NL"] | count > 0 }}
          raw_today: >
            {% if (today_price is mapping) %}
              {% set data = namespace(prices=[]) %}
              {% set electricity_tax = states('input_number.energiebelasting') | float(0) %}
              {% set purchase_costs = states('input_number.opslag_energieleverancier') | float(0) %}
              {% set vat = states('input_number.btw_percentage') | float(0) %}
              {% if today_price["NL"] | count > 0 %}
                {% for state in today_price["NL"] %}
                  {% set corrected_start = as_datetime(state.start).astimezone().isoformat() %}
                  {% set corrected_end = as_datetime(state.end).astimezone().isoformat() %}
                  {% set data.prices = data.prices + [{'start':corrected_start, 'end':corrected_end, 'value': ((state.price/1000) + (((state.price/1000) * vat) + (electricity_tax + purchase_costs) * (1 + vat))) | float(0)| round(4)}] %}
                {% endfor %}
              {% endif %}
              {{data.prices}}
            {% else %}
              []
            {% endif %}
          raw_tomorrow: >
            {% if (tomorrow_price is mapping) %}
              {% set data = namespace(prices=[]) %}
              {% set electricity_tax = states('input_number.energiebelasting') | float(0) %}
              {% set purchase_costs = states('input_number.opslag_energieleverancier') | float(0) %}
              {% set vat = states('input_number.btw_percentage') | float(0) %}
              {% if tomorrow_price["NL"] | count > 0 %}
                {% for state in tomorrow_price["NL"] %}
                  {% set corrected_start = as_datetime(state.start).astimezone().isoformat() %}
                  {% set corrected_end = as_datetime(state.end).astimezone().isoformat() %}
                  {% set data.prices = data.prices + [{'start':corrected_start, 'end':corrected_end, 'value': ((state.price/1000) + (((state.price/1000) * vat) + (electricity_tax + purchase_costs) * (1 + vat))) | float(0)| round(4)}] %}
                {% endfor %}
              {% endif %}
              {{data.prices}}
            {% else %}
              []
            {% endif %}
          current_price: >
            {% set electricity_tax = states('input_number.energiebelasting') | float(0) %}
            {% set purchase_costs = states('input_number.opslag_energieleverancier') | float(0) %}
            {% set vat = states('input_number.btw_percentage') | float(0) %}
            {% set current_price = ((states(price_now) | float(0) + ((states(price_now) | float(0) * vat) + (electricity_tax + purchase_costs) * (1 + vat))) | round(4) ) %}
            {{ current_price }}

-ga naar instellingen--> Ontwikkelaarshulpmiddelen --> Acties

zoek naar prijzen.


kies nordpool


Vul als je wilt de rest in en klik op Actie uitvoeren, en je ziet prijzen eronder verschijnen


Ga naar YAML-modus en kopieer je config entry ID (een stuk ervan heb ik even verwijderd)

Plak die config entry ID in regel 36 van nordpool_official.yaml

input nummer (entiteiten) dienen in decimalen te worden ingevuld.
BTW 21% = 0,21
energiebelasting (2026) = 0,0916
opslag_energieleverancier (Tibber 2026) = 0,0205

check config of er niks verkeerd is en herstart dan pas HA.

Dan zou je een entiteit hebben genaamd nordpool_kwh_nl_eur_5_09_0.
Vul die in voor Gielz: Dynamische nordpool sensor

Je dient nu aanpassingen in Gielz yaml bestand te maken bij:

attributes:
raw_today: >-
en
raw_tomorrow: >-

de .isoformat() weg te halen (zoals hieronder ter illustraties doorgehaald).

{
"start": "{{ item.start.isoformat() }}",
"end": "{{ item.end.isoformat() }}",
"value": {{ item.value }}

{
"start": "{{ hour_start.isoformat() }}",
"end": "{{ hour_end.isoformat() }}",

Yaml checken en Yaml configuraties herladen.


Apex chart:

code:

type: custom:apexcharts-card
experimental:
  color_threshold: true
header:
  show: true
  title: Electricity prices Inc. (today)
  show_states: false
  colorize_states: true
apex_config:
  stroke:
    show: true
    width: 2
  chart:
    height: 300px
    stacked: false
    stackOnlyBar: true
    toolbar:
      autoSelected: pan
      show: true
      tools:
        download: false
        zoom: true
        zoomin: false
        zoomout: false
        pan: true
    zoom:
      enabled: true
      allowMouseWheelZoom: true
      autoScaleYaxis: true
graph_span: 24h
span:
  end: day
now:
  show: true
  label: Now
series:
  - entity: sensor.nordpool_kwh_nl_eur_5_09_0
    name: prijs incl. belasting en extra kosten
    type: line
    show:
      legend_value: false
      extremas: true
      in_header: before_now
    float_precision: 4
    data_generator: |
      return entity.attributes.raw_today.map((record, index) => {
        return [record.start, record.value];
      });
    color_threshold:
      - value: -0.1
        color: "#000fff"
      - value: 0
        color: "#00ffd5"
      - value: 0.1
        color: "#ff8000"
      - value: 0.2
        color: "#0080ff"
      - value: 0.3
        color: "#ff2a00"
      - value: 1
        color: "#ff00d4"

[Idr548]

Welke temperaturen zien jullie bij de omvormer via HA met zo een zonnige lente dagen tijdens het laden?
En vanaf wanneer is het nuttig of gewenst om een ventilator te plaatsen bovenop de Solarflow?

[hemertje]

wat doe ik niet goed?
volgens de handleiding
https://github.com/Gielz1...eel-plug-n-play-dashboard

deze code kopieren
https://github.com/Gielz1...enSDK/blob/main/Dashboard

[hemertje]

Ah, er komt wat info binnen druppelen

[Hippe Lip]

gielz schreef op woensdag 8 april 2026 @ 22:22:
Zit wel iets ingewikkelder in elkaar helaas. Je zou hem inderdaad kunnen stoppen bij xx% maar wat als er daarna een SOC drop is dan koop je heel de nacht alles in en heb je nog niets.

Ehhh, wacht ff, @gielz. Nu lees ik iets nieuws: een SOC-drop? Wasda?
Kan die SOC zomaar in elkaar donderen? Is dat de kwaliteit van de accu of zo? Niet dat ik dat verwacht, maar wat dan wel?

Wat ook nog belangrijk is om mee te nemen; Er zijn zat dagen dat de dag gewoon slecht begint maar dat er bijvoorbeeld wel gewassen moet worden of dat je de stroom gewoon nodig hebt. Dat moet je dan ook inkopen omdat je met een zeer lage SOC de nacht in gaat. Dit is eigenlijk de hoofdreden dat het er niet standaard in zit. Zoveel mogelijkheden en uitkomsten.

Zelf zal ik eerder gewoon tijdens het koken maximaal terugleveren om alle kook/oven golfjes mooi op te vangen in de opwekmaanden.

Ja, dat zal zeker ook gebeuren. We kennen (gelukkig?) niet alleen maar dagen met overvloedige zon in de zomer…
Mijn uitleg ging over de dagen met (veel) overschot.

[Henkoes]

Een modus waarbij:

Binnen x goedkoopste uren het laden start maar max vermogen beperkt is tot of zonnepaneel opbrengst (slimladen) of hard limit. Met huidige profielen lijkt het erop als we ook perongeluk gaan importeren.

Is dit mogelijk met deze oplossing?

[ Voor 16% gewijzigd door Henkoes op 09-04-2026 07:37 ]

[Henkoes]

Vervolgvraag: is de modus ook aan te passen vanuit een andere automatisering?

[hemertje]

Graag even jullie hulp
Ik zie namelijk veel 'Unavailable'

Wat heb ik gemist bij het invullen?

[Wai_AM]

hemertje schreef op donderdag 9 april 2026 @ 08:28:
Graag even jullie hulp
Ik zie namelijk veel 'Unavailable'

Wat heb ik gemist bij het invullen?

[Afbeelding]

[Afbeelding]

[Afbeelding]

P1: geef gevens , check.
Batterij: IP adres is dynamisch en is weer veranderd ? of heb je vast gezet en heeft nog even tijd om gegevens zichtbaar te worden ?
Dynamische sensor heb je niet ingevuld..

[Devke]

Wai_AM schreef op woensdag 8 april 2026 @ 22:23:
Heb eindelijk officiele nordpool integratie werkend:

Voor als je die wilt gebruiken met Gielz Zendure-HA-zenSDK

- Zorg dat je HACS nordpool verwijdert (echt verwijderen)
- maak in packages map een bestand genaamd nordpool_officical.yaml (of een naam naar keuze)
plak onderstaande erin

[...]


-ga naar instellingen--> Ontwikkelaarshulpmiddelen --> Acties


[...]


Plak die config entry ID in regel 36 van nordpool_official.yaml


input entiteiten die je kan vullen:
energiebelasting
opslag_energieleverancier
btw_percentage

check config of er niks verkeerd is en herstart dan pas HA.

Dan zou je een entiteit hebben genaamd nordpool_kwh_nl_eur_5_09_0.
Vul die in voor Gielz: Dynamische nordpool sensor

Je dient nu aanpassingen in Gielz yaml bestand te maken bij:

attributes:
raw_today: >-
en
raw_tomorrow: >-

de .isoformat() weg te halen (zoals hieronder ter illustraties doorgehaald).


[...]


Yaml checken en Yaml configuraties herladen.


Apex chart:

[...]

Moet input_number btw_percentage niet qua max hoger dan 10 ingesteld worden? Nu kun je vlgs mij aangeven in de GUI dat BTW percentage max 10% kan zijn ipv 21.