Zendure producten in Home Assistant integreren deel 2

[Kaaf]

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

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

Dan zit ik hier blijkbaar helemaal fout. Ik gebruik de "Zendure-HA" . Maargoed die doet dus helemaal niets nadat ik de API heb geimporteerd. Geen "p1 meter" en geen batterij. Terwijl ze in de app "gewoon" werken. In HA komt alleen de zendure Manager tevoorschijn. Die geen echte communicatie doet. Ben bang dat ik dit weekend alles reset naar fabrieks waarden en opnieuw ga beginnen met de p1 en batterij. Of heeft hier iemand nog gouden tips

[Krisp]

gielz schreef op vrijdag 13 maart 2026 @ 08:51:
[...]


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

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

Dat heb ik, en dat resulteert hierin. Door het veld ‘handmatige periodes’ leeg te gooien werken de automatiseringen vermoedelijk wel, maar die zijn nog niet zichtbaar.


Voor morgen werkt het overigens wel weer goed, dus wellicht is het een eenmalig issue.

[Devke]

Automatische melding nieuwe release Gielz en Gast777 integratie

Onderstaande automatisering zal een melding sturen als er een update / nieuwe release beschikbaar is van de @gielz en / of @gast777 integratie. In mijn geval zal dat naar mijn mobiele telefoon zijn.

YAML:

alias: Gielz vs Node Red Update Check
description: Controleert Gielz integratie en Node-RED Proxy op nieuwe releases

trigger:
  - platform: state
    entity_id:
      - sensor.zendure_ha_zensdk_github_releasecheck
      - sensor.zendure_proxy_beschikbare_versie
      - sensor.zendure_proxy_versie

action:
  - if:
      - condition: template
        value_template: >
          {{ states('sensor.zendure_ha_zensdk_github_releasecheck') != 'Up-to-date' }}
    then:
      - service: notify.notify
        data:
          title: Update beschikbaar
          message: Er is een nieuwe Gielz integratie update beschikbaar.

  - if:
      - condition: template
        value_template: >
          {{ states('sensor.zendure_proxy_beschikbare_versie') != states('sensor.zendure_proxy_versie') }}
    then:
      - service: notify.notify
        data:
          title: Update beschikbaar
          message: Er is een nieuwe Zendure Node-RED Proxy update beschikbaar.

mode: single

[gielz]

Kaaf schreef op vrijdag 13 maart 2026 @ 13:49:
[...]

Dan zit ik hier blijkbaar helemaal fout. Ik gebruik de "Zendure-HA" . Maargoed die doet dus helemaal niets nadat ik de API heb geimporteerd. Geen "p1 meter" en geen batterij. Terwijl ze in de app "gewoon" werken. In HA komt alleen de zendure Manager tevoorschijn. Die geen echte communicatie doet. Ben bang dat ik dit weekend alles reset naar fabrieks waarden en opnieuw ga beginnen met de p1 en batterij. Of heeft hier iemand nog gouden tips
[Afbeelding]

Zendure HA valt ook onder dit topic (zijn ook tig gebruikers hier die het gebruiken), alleen is de maker Fireson hier niet actief maar wel via https://github.com/Zendure/Zendure-HA/issues

Vaak helpt het om de volledige integratie te verwijderen en opnieuw te installeren.

[ Voor 4% gewijzigd door gielz op 13-03-2026 14:35 ]

[koboy]

Kaaf schreef op vrijdag 13 maart 2026 @ 13:49:
[...]

Dan zit ik hier blijkbaar helemaal fout. Ik gebruik de "Zendure-HA" . Maargoed die doet dus helemaal niets nadat ik de API heb geimporteerd. Geen "p1 meter" en geen batterij. Terwijl ze in de app "gewoon" werken. In HA komt alleen de zendure Manager tevoorschijn. Die geen echte communicatie doet. Ben bang dat ik dit weekend alles reset naar fabrieks waarden en opnieuw ga beginnen met de p1 en batterij. Of heeft hier iemand nog gouden tips
[Afbeelding]

Als je het hebt over een reset naar fabrieksinstellingen van home assistant: dit stappenplan rustig uitvoeren:
1. HACS installeren
2. De nordpool integratie uit HACS installeren
3. Gielz integratie installeren
4. @gielz een kopje koffie sturen

Zie ook de startpost en de installatie handleidingen daar en op de Github van Gielz.
Voordeel van de Gielz integratie is dat die volledig lokaal draait en je niet afhankelijk bent van de cloud verbinding van Zendure.

[gielz]

Ik heb een aantal DMs ontvangen voor het dashboard in combinatie met een witte Home Assistant. Vanaf de mei release is het mogelijk om aan te geven of je een witte of zwarte Home Assistant gebruikt waardoor het dashboard vanzelf aangepast word;

[VicSmurf]

Ik heb net de nieuwste April release er op gezet en nu krijg ik deze melding:

We hebben in het verleden statistieken gegenereerd voor ' Zendure 2400 AC Totale Capaciteit ' (sensor.zendure_2400_ac_totale_capaciteit), maar deze heeft geen statusklasse meer. Daarom kunnen we er geen langetermijnstatistieken meer voor bijhouden.

Statistieken kunnen niet worden gegenereerd totdat deze entiteit een ondersteunde statusklasse heeft.

[gielz]

VicSmurf schreef op vrijdag 13 maart 2026 @ 15:33:
Ik heb net de nieuwste April release er op gezet en nu krijg ik deze melding:


[...]

Dit klopt in de testversie stond deze nog ingesteld dat hij ook in de Long Term Statistics terecht zou komen. Maar gezien je niets aan deze data hebt buiten actueel en een aantal dagen terug is dit niet meegenomen in de definitieve release; https://data.home-assistant.io/docs/statistics/

Je kunt hier voor verwijderen kiezen van de Statistics.

[gast777]

Devke schreef op vrijdag 13 maart 2026 @ 14:15:

Automatische melding nieuwe release Gielz en Gast777 integratie

Onderstaande automatisering zal een melding sturen als er een update / nieuwe release beschikbaar is van de @gielz en / of @gast777 integratie. In mijn geval zal dat naar mijn mobiele telefoon zijn.

Mooie toevoeging. Alleen hebben de gebruikers momenteel nog niet standaard de sensor.zendure_proxy_beschikbare_versie

Ik zal hem hier even inplakken hoe ik (en jij) die momenteel hebben. Ik had die nog niet aan de standaard Proxy sensoren toegevoegd omdat die nog niet zoals het hoort de Github API checkt, maar simpelweg de readme.md downloadt en daar de huidige versie op vindt. Maar voor wie hem wil gebruiken:

code:

## Beschikbare versie check
rest:

  - resource: "https://raw.githubusercontent.com/gast777/Zendure-zenSDK-proxy/main/README.md"
    scan_interval: 43200
    timeout: 30
    headers:
      User-Agent: HomeAssistant
      Accept: text/plain
    sensor:
      - name: "Zendure Proxy Beschikbare Versie"
        unique_id: zendure_proxy_beschikbare_versie
        value_template: >
          {% if 'Huidige versie:' in value %}
            {{ value.split('Huidige versie:')[1].split('\n')[0].strip() }}
          {% else %}
            unknown
          {% endif %}

[Spike2100]

Bij Reconfigure moet je een P1 meter aanduiden. Weet iemand of het mogelijk is om op bepaalde momenten hier een fake meter te kiezen, in deze reconfigure? Ik heb nog niet gevonden dat ik dit in een automatisatie kan aanpassen.

In het grootste deel van Belgïe zit je met het capaciteitstarief. Als je een kwartier lang een hoger verbruik hebt dan 2.5 kW, dan betaal je extra voor die maand. Een dievenland regeling. Met de vaatwasser op een bewolkte dag aan te zetten heb je meestal al prijs.

- Die fake meter zou interessant om smart discharging pas te starten vanaf 2.5 kW....en om de grens van 2.5 kW te bewaken, en niet de 0.
- Of 's nachts als de elektriciteit goedkoper is, je batterij smart chargen tot 2.5 kW. ( zonder rekening te moeten houden met de wasmachine die je vrouw in het midden van de nacht heeft geprogrammeerd )

Een regeling dus enkel voor de dagen met weinig zon. Zodat je de batterij alleen gebruikt om de pieken vanaf 2.5kW op te vangen.

[DeadMetal]

Ik probeer vandaag de zenSDK van Gielz werkend te krijgen, maar het dashboard lukt me niet.
Wie kan me helpen? Ik heb gedaan:

• de nieuwste zendure_ha_zensdk_gielz1986.yaml in de packages map geplaatst en de configuration.yaml aangepast -> HA opnieuw opgestart -> de entiteiten zijn verschenen
• de automation aangemaakt en geactiveerd
• apexcharts-card heb ik al, graphite theme toegevoegd vanuit HACS en HA herstart

So far so good. Tenslotte dan het dashboard, hier heb ik geen ervaring mee.
Ik doe potlood-icoon(dashboards aanpassen) -> plus-icoon (dashboard toevoegen) -> hamburgermenu (3 stipjes) -> bewerken in yaml. Vervolgens plak ik de code zoals getoond op Github -> opslaan

Vervolgens zie ik een leeg dashboard genaamd 'Naamloze weergave'
Wat doe ik fout?

[Devke]

DeadMetal schreef op vrijdag 13 maart 2026 @ 19:30:
Ik probeer vandaag de zenSDK van Gielz werkend te krijgen, maar het dashboard lukt me niet.
Wie kan me helpen? Ik heb gedaan:

• de nieuwste zendure_ha_zensdk_gielz1986.yaml in de packages map geplaatst en de configuration.yaml aangepast -> HA opnieuw opgestart -> de entiteiten zijn verschenen
• de automation aangemaakt en geactiveerd
• apexcharts-card heb ik al, graphite theme toegevoegd vanuit HACS en HA herstart

So far so good. Tenslotte dan het dashboard, hier heb ik geen ervaring mee.
Ik doe potlood-icoon(dashboards aanpassen) -> plus-icoon (dashboard toevoegen) -> hamburgermenu (3 stipjes) -> bewerken in yaml. Vervolgens plak ik de code zoals getoond op Github -> opslaan

Vervolgens zie ik een leeg dashboard genaamd 'Naamloze weergave'
Wat doe ik fout?
[Afbeelding]

Je kunt kiezen voor RAW configuration editor. Daar plak je. Opslaan.

Dashboard openen -> Dashboard bewerken -> 3 puntjes -> Ruwe configuratie editor -> Code plakken -> Opslaan

[ Voor 3% gewijzigd door Devke op 13-03-2026 19:52 ]

[Taro]

Spike2100 schreef op vrijdag 13 maart 2026 @ 19:26:
[Afbeelding]

Bij Reconfigure moet je een P1 meter aanduiden. Weet iemand of het mogelijk is om op bepaalde momenten hier een fake meter te kiezen, in deze reconfigure? Ik heb nog niet gevonden dat ik dit in een automatisatie kan aanpassen.

In het grootste deel van Belgïe zit je met het capaciteitstarief. Als je een kwartier lang een hoger verbruik hebt dan 2.5 kW, dan betaal je extra voor die maand. Een dievenland regeling. Met de vaatwasser op een bewolkte dag aan te zetten heb je meestal al prijs.

- Die fake meter zou interessant om smart discharging pas te starten vanaf 2.5 kW....en om de grens van 2.5 kW te bewaken, en niet de 0.
- Of 's nachts als de elektriciteit goedkoper is, je batterij smart chargen tot 2.5 kW. ( zonder rekening te moeten houden met de wasmachine die je vrouw in het midden van de nacht heeft geprogrammeerd )

Een regeling dus enkel voor de dagen met weinig zon. Zodat je de batterij alleen gebruikt om de pieken vanaf 2.5kW op te vangen.

Ja, daar kan je een fake meter opgeven. En dat is dus voor altijd. En die fake meter moet je beïnvloeden door een mode die je toewijst. Dat kan ook 1 op 1 de P1-meter waarde zijn.

En idd, peakshaving is ideaal voor België.

[Spike2100]

Taro schreef op vrijdag 13 maart 2026 @ 19:55:
[...]

Ja, daar kan je een fake meter opgeven. En dat is dus voor altijd. En die fake meter moet je beïnvloeden door een mode die je toewijst. Dat kan ook 1 op 1 de P1-meter waarde zijn.

En idd, peakshaving is ideaal voor België.

Ik weet dat je daar een meter kan ingeven. Maar op zonnige dagen heb ik die fake meter niet nodig.

Ideaal zou zijn als ik daar via een automatisatie een "fake meter" kan toewijzen en op andere momenten de "1 op 1 p1 meter". Zonder dit manueel moeten te veranderen.

Dit is eigenlijk alles wat ik nodig heb zonder tonnen code en script te moeten schrijven

[Taro]

Spike2100 schreef op vrijdag 13 maart 2026 @ 20:01:
[...]


Ik weet dat je daar een meter kan ingeven. Maar op zonnige dagen heb ik die fake meter niet nodig.

Ideaal zou zijn als ik daar via een automatisatie een "fake meter" kan toewijzen en op andere momenten de "1 op 1 p1 meter". Zonder dit manueel moeten te veranderen.

Dit is eigenlijk alles wat ik nodig heb zonder tonnen code en script te moeten schrijven

Je hoeft geen tonnen code te schrijven.

Wat je kunt doen is een fake meter met 2 opties:

1. 1 op 1 de waarde van een P1-meter
2. Een gemanipuleerde waarde voor peakshaving

Je kunt dan een automatisering maken die afhankelijk van de prijs OF de import van het net 1 van de 2 activeert. Dat is juist het voordeel van die fake meter.

Een andere betere optie: Kies gewoon je echte P1-meter. Toon de Smart Mode van de Zendure integratie op je dashboard. Kies daar uit: Manual Discharging als je wil peakshaven en anders zet je die op Smart NOM. Ben je er ook, maar wel iedere keer handmatig kiezen.

[Spike2100]

Taro schreef op vrijdag 13 maart 2026 @ 20:06:
[...]

Je hoeft geen tonnen code te schrijven.

Wat je kunt doen is een fake meter met 2 opties:

1. 1 op 1 de waarde van een P1-meter
2. Een gemanipuleerde waarde voor peakshaving

Je kunt dan een automatisering maken die afhankelijk van de prijs OF de import van het net 1 van de 2 activeert. Dat is juist het voordeel van die fake meter.

Een andere betere optie: Kies gewoon je echte P1-meter. Toon de Smart Mode van de Zendure integratie op je dashboard. Kies daar uit: Manual Discharging als je wil peakshaven en anders zet je die op Smart NOM. Ben je er ook, maar wel iedere keer handmatig kiezen.

Ik heb héél mijn energiesysteem van het huis afgestemd op de P1 meter en het batterijsysteem. En nu probeer ik dit met het capaciteitstarief.

Ev staan, warmptepomp /airco, zonnepanelen, batterij....zoals velen misschien hier.

Ik wou gewoon zoiets als

Solcast check --> If Winter mode --> Let zendure use P1 -2500 Offset
Solcast check --> If Summer mode --> Let zendure use Normal P1

en was gereed. Zonder gigantisch véél te moeten hersleutelen. Gewoon dat ik telkens in die reconfigure, via automatisatie de normale P1 kon kiezen of een -2500 Offset P1.

Het zal wel allemaal te programmeren zijn. Maar dit is een simpele oplossing die ik mis. Ik wil niets constant manueel herzetten en checken elke dag.

[gielz]

DeadMetal schreef op vrijdag 13 maart 2026 @ 19:30:
Ik probeer vandaag de zenSDK van Gielz werkend te krijgen, maar het dashboard lukt me niet.
Wie kan me helpen? Ik heb gedaan:

• de nieuwste zendure_ha_zensdk_gielz1986.yaml in de packages map geplaatst en de configuration.yaml aangepast -> HA opnieuw opgestart -> de entiteiten zijn verschenen
• de automation aangemaakt en geactiveerd
• apexcharts-card heb ik al, graphite theme toegevoegd vanuit HACS en HA herstart

So far so good. Tenslotte dan het dashboard, hier heb ik geen ervaring mee.
Ik doe potlood-icoon(dashboards aanpassen) -> plus-icoon (dashboard toevoegen) -> hamburgermenu (3 stipjes) -> bewerken in yaml. Vervolgens plak ik de code zoals getoond op Github -> opslaan

Vervolgens zie ik een leeg dashboard genaamd 'Naamloze weergave'
Wat doe ik fout?
[Afbeelding]

Ik zie denk ik wat je fout doet. Je moet eerst een echt nieuw dashboard aanmaken. In de readme is dit nu duidelijker beschreven; https://github.com/Gielz1...eel-plug-n-play-dashboard

[ Voor 5% gewijzigd door gielz op 13-03-2026 20:42 ]

[Keida]

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


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

Quote mezelf even - lag aan nog niet volledig ge-update HA versie. Na updaten werkt iig het tonen van dynamische deel van het tabblad.

[Taro]

Spike2100 schreef op vrijdag 13 maart 2026 @ 20:21:
[...]


Ik heb héél mijn energiesysteem van het huis afgestemd op de P1 meter en het batterijsysteem. En nu probeer ik dit met het capaciteitstarief.

Ev staan, warmptepomp /airco, zonnepanelen, batterij....zoals velen misschien hier.

Ik wou gewoon zoiets als

Solcast check --> If Winter mode --> Let zendure use P1 -2500 Offset
Solcast check --> If Summer mode --> Let zendure use Normal P1

en was gereed. Zonder gigantisch véél te moeten hersleutelen. Gewoon dat ik telkens in die reconfigure, via automatisatie de normale P1 kon kiezen of een -2500 Offset P1.

Het zal wel allemaal te programmeren zijn. Maar dit is een simpele oplossing die ik mis. Ik wil niets constant manueel herzetten en checken elke dag.

Je denkt echt te moeilijk en had het nu al werkend kunnen hebben

Je kunt met bijv. de Season integratie gewoon zeggen in een nieuwe automatisering:

If season = winter of herfst -> Gebruik een Helper: Fake meter = P1-meter - 2500 Watt
Else: Gebruik een Helper: Fake meter = P1-meter

Dan pakt de Zendure integratie dat super netjes op en blijven al je andere spullen gewoon draaien.

Met de zoekfunctie kan je de YAML code hiervoor al terugvinden.

[Spike2100]

Taro schreef op vrijdag 13 maart 2026 @ 20:52:
[...]

Je denkt echt te moeilijk en had het nu al werkend kunnen hebben

Je kunt met bijv. de Season integratie gewoon zeggen in een nieuwe automatisering:

If season = winter of herfst -> Gebruik een Helper: Fake meter = P1-meter - 2500 Watt
Else: Gebruik een Helper: Fake meter = P1-meter

Dan pakt de Zendure integratie dat super netjes op en blijven al je andere spullen gewoon draaien.

Met de zoekfunctie kan je de YAML code hiervoor al terugvinden.

Soms gaat het lichtje pas na een tijdje branden. Van yaml krijg ik spijtig genoeg kortsluiting in mijn hoofd. Alles via hacs of zelf inéén geknutselde scripts/automations/helpers. Ik vind wel iets.

Het klinkt wel logisch wat je zegt 🙂👍

[Pakhaas]

gielz schreef op vrijdag 13 maart 2026 @ 20:31:
[...]


Ik zie denk ik wat je fout doet. Je moet eerst een echt nieuw dashboard aanmaken. In de readme is dit nu duidelijker beschreven; https://github.com/Gielz1...eel-plug-n-play-dashboard

Ah zo makkelijk kan het zijn. Ik zette de raw bestanden in de juiste map in studio code server.

[Taro]

Spike2100 schreef op vrijdag 13 maart 2026 @ 22:10:
[...]


Soms gaat het lichtje pas na een tijdje branden. Van yaml krijg ik spijtig genoeg kortsluiting in mijn hoofd. Alles via hacs of zelf inéén geknutselde scripts/automations/helpers. Ik vind wel iets.

Het klinkt wel logisch wat je zegt 🙂👍

Normaal gesproken zou ik een voorzetje voor je doen, maar ga richting de 70 uur deze week, dus misschien kan iemand anders je even op weg helpen.

Heb je trouwens ChatGPT ofzo? Werkt ook heel goed tegenwoordig. Ach, ben nu toch bezig

Maak 2 helpers aan:

- zendure_peakshaving: {{ states('sensor.JOUW_P1_SENSOR') + 2500 }}
- zendure_normaal: {{ states('sensor.JOUW_P1_SENSOR') }}

Let op: Kan fout gaan door min vs plus waardes, dus even de uitkomst checken.

Maak een Sensor helper (Je fake meter sensor) aan:

- Zendure Smart Meter

{% if is_state('input_select.zendure_smart_mode', 'Smart NOM')%}
{{ states('sensor.zendure_normaal') }}

{% elif is_state('input_select.zendure_smart_mode', 'Peakshaving')%}
{{ states('sensor.zendure_peakshaving) }}

{% else %}
0
{% endif %}

Maak een Input select helper, zendure_smart_mode, met 2 opties:
Smart NOM
Peakshaving

Zorg dat bij bovenstaande waardes de entiteiten en namen 100% overeen komen.

En geef sensor.zendure_power_meter als input voor je P1-meter bij de Zendure integratie.

Heb dit niet kunnen testen, maar hopelijk werkt het direct OF helpt het je op weg.

[jordyc]

Spike2100 schreef op vrijdag 13 maart 2026 @ 22:10:
[...]


Soms gaat het lichtje pas na een tijdje branden. Van yaml krijg ik spijtig genoeg kortsluiting in mijn hoofd. Alles via hacs of zelf inéén geknutselde scripts/automations/helpers. Ik vind wel iets.

Het klinkt wel logisch wat je zegt 🙂👍

Gooi je idee met eventuele relevante sensoren in Claude of gpt en vraag of hij voor jou een stappenplan en bijbehorende code kan schrijven. Dit soort zaken zijn ideaal om even door de AI uit te laten werken.

[sunnybeam]

In HomeAssistant kan je de status van HEMS zien ( aan of uit ) maar ik zou HEMS ook in HomeAssistant willen kunnen in of uitschakelen. Is dat opde een of andere manier mogelijk?

Sunnybeam

[Pakhaas]

Ik heb nu de automotion zo aangepast dat hij de modus aanpast afhankelijk van hoe de dag er uit ziet. Eigenlijk zijn er 2 smaken qua tactiek.

1. Dag met grote spread = Dynamisch Handelen.
2. Dag met geen grote spread. Bijvoorbeeld een dag zoals vandaag.


Neutraal
Op deze dag is het in de ochtend rond de 28ct en komt er al zo'n +/- 1500w van PV. Die wil je niet eerst opslaan in de batterij omdat de prijs niet hoog is en ook niet goedkoop. Die wil je rechtstreeks van PV terugleveren aan het net zonder laadverliezen en voor een goede prijs. De modus staat nu automatisch op "Alleen slim ontladen". Mocht er wat in de batterij zitten dan wordt het gebruikt in je huis als zijnde NOM (zonder dat hij oplaad).

Goedkoop
Wanneer sensor.dynamisch_goedkoopste_periode op Ja staat zal hij de modus wijzigen naar "Alleen slim opladen". Want het is een goedkope prijs voor die dag die je in de batterij wil en direct verbruik in huis betaal je een goedkope prijs voor. Overdag komt er toch genoeg PV van het dak die het huisverbruik ook in grote mate afdekt.

Duur
Wanneer sensor.dynamisch_duurste_periode op Ja staat zal de modus wijzigen naar "Dynamisch Handelen" en de batterij leeg gooien in de aangegeven momenten in rood.

Prijsstatus	Modus	Gedrag
goedkoop = Ja	Alleen slim opladen	batterij vullen
duur = Ja	Dynamisch handelen	batterij inzetten voor handel
beide Nee	Alleen slim ontladen	huisverbruik uit batterij, geen opladen

[Jop123]

Kaaf schreef op vrijdag 13 maart 2026 @ 13:49:
[...]

Dan zit ik hier blijkbaar helemaal fout. Ik gebruik de "Zendure-HA" . Maargoed die doet dus helemaal niets nadat ik de API heb geimporteerd. Geen "p1 meter" en geen batterij. Terwijl ze in de app "gewoon" werken. In HA komt alleen de zendure Manager tevoorschijn. Die geen echte communicatie doet. Ben bang dat ik dit weekend alles reset naar fabrieks waarden en opnieuw ga beginnen met de p1 en batterij. Of heeft hier iemand nog gouden tips
[Afbeelding]

Je hebt versie 1-2.5 van de Zendure HA integratie gebruikt.
Om de 2400ac+ te zien moet je in de repo rechts bovenin de 3 puntje kiezen en dan reload.
kies dan voor versie 1.2.7 pre.
met deze nieuwere versie haalt hij wel alles binnen.

[gielz]

sunnybeam schreef op zaterdag 14 maart 2026 @ 10:50:
In HomeAssistant kan je de status van HEMS zien ( aan of uit ) maar ik zou HEMS ook in HomeAssistant willen kunnen in of uitschakelen. Is dat opde een of andere manier mogelijk?

Sunnybeam

Nee is niet mogelijk. Heb je trouwens een hyper? Bij de nieuwere modellen zie ik nergens de HEMS status.

[koboy]

Pakhaas schreef op zaterdag 14 maart 2026 @ 10:58:
Ik heb nu de automotion zo aangepast dat hij de modus aanpast afhankelijk van hoe de dag er uit ziet. Eigenlijk zijn er 2 smaken qua tactiek.

1. Dag met grote spread = Dynamisch Handelen.
2. Dag met geen grote spread. Bijvoorbeeld een dag zoals vandaag.
[Afbeelding]

Neutraal
Op deze dag is het in de ochtend rond de 28ct en komt er al zo'n +/- 1500w van PV. Die wil je niet eerst opslaan in de batterij omdat de prijs niet hoog is en ook niet goedkoop. Die wil je rechtstreeks van PV terugleveren aan het net zonder laadverliezen en voor een goede prijs. De modus staat nu automatisch op "Alleen slim ontladen". Mocht er wat in de batterij zitten dan wordt het gebruikt in je huis als zijnde NOM (zonder dat hij oplaad).

Goedkoop
Wanneer sensor.dynamisch_goedkoopste_periode op Ja staat zal hij de modus wijzigen naar "Alleen slim opladen". Want het is een goedkope prijs voor die dag die je in de batterij wil en direct verbruik in huis betaal je een goedkope prijs voor. Overdag komt er toch genoeg PV van het dak die het huisverbruik ook in grote mate afdekt.

Duur
Wanneer sensor.dynamisch_duurste_periode op Ja staat zal de modus wijzigen naar "Dynamisch Handelen" en de batterij leeg gooien in de aangegeven momenten in rood.

Prijsstatus	Modus	Gedrag
goedkoop = Ja	Alleen slim opladen	batterij vullen
duur = Ja	Dynamisch handelen	batterij inzetten voor handel
beide Nee	Alleen slim ontladen	huisverbruik uit batterij, geen opladen

Leuke vingeroefening!

Volgens mij ben je (voor dit jaar) wel dingen dubbelop aan het doen. Je wilt stroom pas uit de accu gebruiken als dat goedkoper is wanneer je de verliezen meeneemt.

In Gielz zit dit al ingebouwd door de minimale spread op te geven. Staat bij mij op 25% (80% RTE), en vandaag doet hij dus niets.
Heeft wel als consequentie dat als je geen goedkope uren insteld hebt de spread naar 0 gaat en er dus ook niet ontladen wordt. Kwam hier een paar dagen geleden achter toen 23u ineens heel goedkoop was en ik de goedkope uren eind van de middag naar nul had gezet om te voorkomen dat hij om 23u zou gaan laden ipv nog veel goedkoper later. Heeft me een uur duur ontladen gekost.

De instelling naar slim ontladen is wel een goeie om eventuele restjes er uit te halen. Waarschijnlijk zijn die de dag er goedkoop er in gegaan, en een dag als vandaag levert dan toch net wat op. In elk geval is de accu helemaal leeg voor een volgende handelsdag.

[Pakhaas]

koboy schreef op zaterdag 14 maart 2026 @ 11:15:
[...]


Leuke vingeroefening!

Volgens mij ben je (voor dit jaar) wel dingen dubbelop aan het doen. Je wilt stroom pas uit de accu gebruiken als dat goedkoper is wanneer je de verliezen meeneemt.

Klopt ik heb de spread even op 0% gezet omdat ik wil dat hij bij goedkope tarieven wel de batterij vult van PV (en niet uit het net). Die stroom kan ik dan later gebruiken in de avond of alsnog terugleveren. Avonds gaat die namelijk als goedkoop en duur nee is weer naar slim ontladen, dus wordt het huisverbruik uit de batterij gehaald.

Ben nog steeds aan het finetunen wat optimaal is, heb de batterijen ook nog maar een week.

edit: ik heb de minimale spread weer even op 25% gezet. Even kijken of ik dat nog mee moet nemen in de code, zodat daarop ook het juiste gebeurd.

[ Voor 8% gewijzigd door Pakhaas op 14-03-2026 11:21 ]

[RobTesla]

Ik heb nog een vraag over de NOM-stand van de Gielz integratie in HA. Als ik deze activeer en er wordt iets in huis ingeschakeld van 1500 Watt, dan past die de injectie mooi aan. Als die verbruiker wegvalt dan schiet het totale verbruik van het huis eventjes onder nul, wat normaal is. Maar ik zie dat de Zendure dan op Standby geschakeld wordt. En dat is niet de bedoeling uiteraard. Idealiter past die zijn injectie gewoon terug aan, wat -met ons sluimerverbruik- rond de 3 a 400 watt zit.

[koboy]

Pakhaas schreef op zaterdag 14 maart 2026 @ 11:19:
[...]

Klopt ik heb de spread even op 0% gezet omdat ik wil dat hij bij goedkope tarieven wel de batterij vult van PV (en niet uit het net). Die stroom kan ik dan later gebruiken in de avond of alsnog terugleveren. Avonds gaat die namelijk als goedkoop en duur nee is weer naar slim ontladen, dus wordt het huisverbruik uit de batterij gehaald.

Ben nog steeds aan het finetunen wat optimaal is, heb de batterijen ook nog maar een week.

edit: ik heb de minimale spread weer even op 25% gezet. Even kijken of ik dat nog mee moet nemen in de code, zodat daarop ook het juiste gebeurd.

Zelfs als je uitgaat van de RTE die ik realiseer (net geen 85%) heeft het geen zin om te laden bij een spread kleiner dan 18%. Direct terugleveren levert dan gewoon meer op.

Als we even kijken naar de situatie vandaag: laaste restje van de gisteren voor 13 cent ingekochte stroom gebruiken heeft nut. Aan de andere kant levert terugleveren over 1 of meer dagen in een piek waarschijnlijk meer op....

[Pakhaas]

koboy schreef op zaterdag 14 maart 2026 @ 11:37:
[...]


Zelfs als je uitgaat van de RTE die ik realiseer (net geen 85%) heeft het geen zin om te laden bij een spread kleiner dan 18%. Direct terugleveren levert dan gewoon meer op.

Als we even kijken naar de situatie vandaag: laaste restje van de gisteren voor 13 cent ingekochte stroom gebruiken heeft nut. Aan de andere kant levert terugleveren over 1 of meer dagen in een piek waarschijnlijk meer op....

Volgens Gielz dashboard bij bovenste verdeling van momenten is de spread 30%

[koboy]

Pakhaas schreef op zaterdag 14 maart 2026 @ 11:43:
[...]

Volgens Gielz dashboard bij bovenste verdeling van momenten is de spread 30%

Dat kan goed. Maar hij rekent met alle opgegeven uren (5 om 5 bij mij), en dan kom je op een spread van 21%. Waarschijnlijk kun je er wel komen met de goedkoopste 2 en de duurste 2 uur vandaag, maar die hooguit 5 tot 10 cent die het me dan oplevert is het mij niet waard. Beter om vandaag als test van het spread algoritme te gebruiken zodat ik zeker weet dat dat werkt als ik er niet ben.

Als ik straks 2 weken op vakantie ben heb ik ook niet de kans om zaken te optimaliseren, dus het moet in de basis gewoon "goed genoeg" werken.

Opladen tegen 26 cent is gewoon te veel; zou nu ook de auto niet aan de lader hangen tenzij het echt noodzakelijk is.

[gielz]

RobTesla schreef op zaterdag 14 maart 2026 @ 11:36:
Ik heb nog een vraag over de NOM-stand van de Gielz integratie in HA. Als ik deze activeer en er wordt iets in huis ingeschakeld van 1500 Watt, dan past die de injectie mooi aan. Als die verbruiker wegvalt dan schiet het totale verbruik van het huis eventjes onder nul, wat normaal is. Maar ik zie dat de Zendure dan op Standby geschakeld wordt. En dat is niet de bedoeling uiteraard. Idealiter past die zijn injectie gewoon terug aan, wat -met ons sluimerverbruik- rond de 3 a 400 watt zit.

Hij balanceert nu in het ontladen/opladen en dit kan inderdaad opeens 0 worden want hij kan nooit in 1x van ontladen naar opladen of andersom omdat hij balanceert in die stand. Wellicht is een minimum instelbaar verbruik een optie. Maar hier heb je dan weer heel weinig aan als de zon er is.

De vraag is dan wat is handig, voor nu kijk ik zelf gewoon naar de import kwh per uur.

[sunnybeam]

gielz schreef op zaterdag 14 maart 2026 @ 11:09:
[...]


Nee is niet mogelijk. Heb je trouwens een hyper? Bij de nieuwere modellen zie ik nergens de HEMS status.

Bedankt voor je reactie. Ik heb de Zendure SolarFlow 2400.

Sunnybeam

[RobTesla]

gielz schreef op zaterdag 14 maart 2026 @ 13:13:
[...]
Hij balanceert nu in het ontladen/opladen ...

Ja ik zit wel met een heel specifieke situatie. Ik wil enkel teruggave doen in die NOM, niet opladen. Ik heb op mijn grid-connected elektriciteitsnet in huis geen solar panels. Ik heb enkel solar panels op mijn off-grid systeem.

Wat ik doe: Mijn zendures worden bij overschot solar op het offgrid-gedeelte afgeschakeld van mijn on-grid huisnetwerk en gekoppeld met het off-grid systeem en worden opgeladen van de overschot solar.

Nadien omgekeerd: de Zendures worden afgeschakeld van het off-grid systeem, terug gekoppeld op het on-grid systeem en laat die dan NOM draaien. (En wil ik dus enkel teruggave)

De omschakeling tussen off-grid en on-grid systeem is geautomatiseerd met heavy duty relays én ATS.

[sjnelle]

Heeft iemand al wat met uv index gedaan?
Als er veel zon wordt verwacht wil je de dynamische goedkope uren aanpassen dat hij niet van het net gaat laden en verhogen zodra je slechte dag hebt zoals vandaag.
Iemand dat al een voorbeeld van

[jordyc]

Je kunt met de solcast integratie een voorspelling per uur van vandaag en morgen binnen halen voor jouw zonnepanelen. Ik heb em nu bij wijze van test zo ingesteld dat als er minder dan 20kWh wordt opgewekt hij in de goedkope uren volle bak mag bijladen en anders is het alleen slim opladen.

[emielbf]

sjnelle schreef op zaterdag 14 maart 2026 @ 18:00:
Heeft iemand al wat met uv index gedaan?
Als er veel zon wordt verwacht wil je de dynamische goedkope uren aanpassen dat hij niet van het net gaat laden en verhogen zodra je slechte dag hebt zoals vandaag.
Iemand dat al een voorbeeld van

dat doe je et met UV index maar gewoon met de voorspelde zon intensiteit voor jou lokatie. Kun je simpel doen via Solcast, die houdt alleen geen rekening met bomen ed. Dus ik heb zelf een script laten schrijven waarin je ook aan kunt geven hoe de schaduw werking is. En vervolgens vertalen naar kWh's en dat klopt heel aardig. En dan inderdaad kijken of er meer dan X kWh opgewekt gaat worden en dan niet laden/ontladen op goedkope en dure uren

[Brack]

Ik gebruik de Gielz zenSDK automatisering voor mijn Zendure 2400 AC+ in Home Assistant, en wat is dit mooi gemaakt, mijn complimenten. Nu draaiend in de modus 'Dynamisch nul op de meter'. Mijn prioriteit is niet zozeer exact 0 op de meter houden, maar vooral dat de batterij stabiel blijft en niet continu wisselt tussen opladen en ontladen door korte verbruikspieken zoals een koffiemachine (~1500W, 30-60 seconden) of de startfase van een vaatwasser.

Ik heb het interval al van /5 naar /8 gezet. Mijn redenering is dat een groter interval (bijv. /30 of /60 seconden) effectiever is dan de oplaad- en ontlaadmarge voor dit specifieke probleem, omdat de marge bij een piek van 1500W toch al snel overschreden wordt, ongeacht of je die op 100W of 300W instelt.

- Klopt deze redenering, of mis ik iets?
- Wat is een verstandig interval als je korte pieken wilt negeren maar nog wel reageert op structureel hogere afname?

[ppaulv]

Brack schreef op zondag 15 maart 2026 @ 11:45:
...

- Klopt deze redenering, of mis ik iets?
- Wat is een verstandig interval als je korte pieken wilt negeren maar nog wel reageert op structureel hogere afname?

Met een groter interval waarop de automatisering draait verklein je de kans dat ie net die piek meepakt maar wordt ie nooit nul. Je kunt nog steeds de pech hebben dat ie gaat meten tijdens die piek.

[Akki]

Brack schreef op zondag 15 maart 2026 @ 11:45:
Ik gebruik de Gielz zenSDK automatisering voor mijn Zendure 2400 AC+ in Home Assistant, en wat is dit mooi gemaakt, mijn complimenten. Nu draaiend in de modus 'Dynamisch nul op de meter'. Mijn prioriteit is niet zozeer exact 0 op de meter houden, maar vooral dat de batterij stabiel blijft en niet continu wisselt tussen opladen en ontladen door korte verbruikspieken zoals een koffiemachine (~1500W, 30-60 seconden) of de startfase van een vaatwasser.

Ik heb het interval al van /5 naar /8 gezet. Mijn redenering is dat een groter interval (bijv. /30 of /60 seconden) effectiever is dan de oplaad- en ontlaadmarge voor dit specifieke probleem, omdat de marge bij een piek van 1500W toch al snel overschreden wordt, ongeacht of je die op 100W of 300W instelt.

- Klopt deze redenering, of mis ik iets?
- Wat is een verstandig interval als je korte pieken wilt negeren maar nog wel reageert op structureel hogere afname?

Hier interval van /10 sec samen met een low pass filter om de korte pieken te effenen en het springerige gedrag van de inductiekookplaat te vermijden. De batterij reageert op de blauwe gedempte lijn, niet op de originele gele, met een veel rustiger rode lijn als resultaat:


De korte opstartspanning wordt zo mooi vereffend:

[ Voor 15% gewijzigd door Akki op 15-03-2026 21:31 ]

[gielz]

Brack schreef op zondag 15 maart 2026 @ 11:45:
Ik gebruik de Gielz zenSDK automatisering voor mijn Zendure 2400 AC+ in Home Assistant, en wat is dit mooi gemaakt, mijn complimenten. Nu draaiend in de modus 'Dynamisch nul op de meter'. Mijn prioriteit is niet zozeer exact 0 op de meter houden, maar vooral dat de batterij stabiel blijft en niet continu wisselt tussen opladen en ontladen door korte verbruikspieken zoals een koffiemachine (~1500W, 30-60 seconden) of de startfase van een vaatwasser.

Ik heb het interval al van /5 naar /8 gezet. Mijn redenering is dat een groter interval (bijv. /30 of /60 seconden) effectiever is dan de oplaad- en ontlaadmarge voor dit specifieke probleem, omdat de marge bij een piek van 1500W toch al snel overschreden wordt, ongeacht of je die op 100W of 300W instelt.

- Klopt deze redenering, of mis ik iets?
- Wat is een verstandig interval als je korte pieken wilt negeren maar nog wel reageert op structureel hogere afname?

Ik heb hier nog een test liggen met een outlier / uitschieter filter op de P1. Wat hij dan doet is je geeft bijvoorbeeld aan als ik 500 watt buiten de gemiddelde range val kijk dan na x seconden nog eens en ga hem dan pas gebruiken. Alleen hierdoor ga je uiteindelijk wel meer stroom inkopen die toch deels opgevangen hadden kunnen worden door de batterij.

Hierdoor hoef je de interval nooit te veranderen waardoor je de strakke NOM behoud buiten de uitschieters.

[ Voor 4% gewijzigd door gielz op 15-03-2026 16:41 ]

[Fjmk]

Ik heb geminicli en Home Assistant MCP Server https://homeassistant-ai.github.io/ha-mcp/ Home Assistant MCP Server] in gebruik genomen. Ik kon het niet laten om hem te vragen:

analyze automation Zendure zenSDK (Gielz)

Antwoord:

The Zendure zenSDK (Gielz) automation (automation.batterij_zendure) is a complex,
multi-purpose control system for your Zendure battery. It manages charging,
discharging, and operational modes based on real-time power demand, state of
charge (SOC), and dynamic energy prices.

1. Triggers
The automation is highly responsive, triggered by:
* Time Pattern: Every 5 seconds (seconds: "/5") for constant adjustment.
* State Changes: Changes in your selected mode (input_select.zendure_2400_ac_modus_selecteren),
energy price status (cheapest/most expensive periods), and system settings
(max charge/discharge limits).
* Midnight: Resets daily price-related helpers.

2. Core Operational Modes
The automation uses a choose structure to execute different logic based on your selected modus_selecteren:
* Nul op de meter (NOM): Aims for zero grid usage by balancing the house load with battery power.
* Dynamisch NOM: Similar to NOM but with added intelligence for dynamic energy pricing.
* Dynamisch Handelen: Actively charges during cheap periods and discharges during expensive periods.
* Snel opladen/ontladen: Immediate full-power charging or discharging.
* Handmatig: Manual control of charge/discharge power.

3. Smart Balancing Logic (NOM)
This is the most sophisticated part of the automation. When in NOM mode:
* Discharging: If house power (sensor.p1_aansturing_vermogen) exceeds a set threshold,
it starts discharging at 75% of the demand to avoid overshooting. Once discharging,
it fine-tunes to 100% of demand to reach zero grid import.
* Charging: If there is excess power (negative P1 value), it starts charging at 75% of the surplus,
then balances to 100% to capture all excess solar energy.
* Safety Limits: It respects your minimum and maximum SOC settings and oplaad/ontlaad margins.

4. System & Reliability Actions
* RAM vs. Flash Storage: To prevent wearing out the battery's internal flash memory from
frequent updates (every 5 seconds), it automatically switches the storage mode to RAM for
temporary adjustments.
* Standby Management: Automatically puts the system in standby after a period of inactivity
(default 5 minutes).
* Error Correction: Periodically checks and corrects the actual charge/discharge limits
if they drift from your set input_number values.

5. Dynamic Energy Pricing Integration
If you have the Nordpool integration active:
* It automatically transfers "cheapest/most expensive" settings from "tomorrow" to "today" at midnight.
* It triggers high-power charging when sensor.dynamisch_goedkoopste_periode is "Ja".
* It triggers discharging when sensor.dynamisch_duurste_periode is "Ja", provided the "spread"
(price difference) is worth it.

Summary: This automation acts as the "brain" of your energy storage, continuously calculating
the optimal power flow to save money and maximize self-consumption while protecting the
battery hardware.

Daar mag @gielz heel trots op zijn, en ik ben er erg happy mee.

[jordyc]

Akki schreef op zondag 15 maart 2026 @ 16:30:
[...]


Hier interval van /10 sec samen met een low pass filter

Dat is wel interessant. Hoe heb je dat gemaakt?
Ik ben wel benieuwd wat dit onderaan de streep zou schelen als je het alleen op outliers toepast.

[Akki]

jordyc schreef op zondag 15 maart 2026 @ 18:11:
[...]


Dat is wel interessant. Hoe heb je dat gemaakt?
Ik ben wel benieuwd wat dit onderaan de streep zou schelen als je het alleen op outliers toepast.

Ik denk dat mijn methode wel slordig is met de verliezen. Doel was meer een stabiele batterij te krijgen, geen strakke NOM.
Zo is het gedaan:
Maak een nieuwe Helper van Type 'filter' (laagdoorlaat) en baseer die op de echte P1 sensor.
Vul de naam in bij Gielz als 'Afwijkende P1 sensor'.



En dit is het resultaat:

[ Voor 11% gewijzigd door Akki op 15-03-2026 21:36 ]

[Kaaf]

Jop123 schreef op zaterdag 14 maart 2026 @ 11:00:
[...]


Je hebt versie 1-2.5 van de Zendure HA integratie gebruikt.
Om de 2400ac+ te zien moet je in de repo rechts bovenin de 3 puntje kiezen en dan reload.
kies dan voor versie 1.2.7 pre.
met deze nieuwere versie haalt hij wel alles binnen.

Dat was hem, bedankt

[RobTesla]

@gielz Is het ook mogelijk om 2 afzonderlijke Zendure-setups te sturen? Maar niet met die proxy, ik wil steeds elke Zendure toren apart aansturen. Ik speel met het idee om een tweede Zendure toren te plaatsen met ook 5 accu's. Omdat ik met m'n 'speciale' setup zit wil ik dan de Zendures afwisselend laden op het off-grid systeem terwijl de andere toren op het on-grid aan het NOM'en is. De dag nadien wisselt de opstelling. Dus: Dag 1: Zendure 1 opladen van het off-grid systeem (solar), Zendure 2 NOM'en op het on-grid systeem. Dag 2: Zendure 2 NOM'en op het on-grid systeem, Zendure 2 laden op het off-grid systeem.

Ik kan nu al de omschakeling van mijn ene Zendure toren tussen het on-grid en off-grid systeem vanuit mijn HA/OpenHab/eigen scripting doen. Als ik daar nu een tweede bij zet (met ook zijn eigen omschakeling) kan ik volgens mij bij zonnige periodes bijna geheel NOM draaien.

Let wel: ik injecteer maar tot 2000 Watt, alles wat erboven gaat komt natuurlijk van het net, maar die 2kW marge is voor ons al het grootste deel van de koek.

[gast777]

RobTesla schreef op maandag 16 maart 2026 @ 10:47:
@gielz Is het ook mogelijk om 2 afzonderlijke Zendure-setups te sturen? Maar niet met die proxy, ik wil steeds elke Zendure toren apart aansturen.

Makkelijkste lijkt me dan een 2e HA instance gebruiken.

OF als je een 2e Gielz in dezelfde HA wilt hebben, zul je voor de 2e Gielz in zowel de package als de automation, ALLE entiteiten, namen e.d. een andere naam moeten geven, bijvoorbeeld met een prefix ervoor, zodat het 100% gescheiden blijft.

Je hebt wel een heel bijzondere use-case... maar ok, dit is Tweakers

[RobTesla]

gast777 schreef op maandag 16 maart 2026 @ 12:34:
[...]
Je hebt wel een heel bijzondere use-case...

't Is een hobby, hé

[Wai_AM]

Met dit jojo weer zie ik bij NOM sturing de afname (bij wolk voor de zon) per 50W omlaag gaat, dit gaat langzaam als je van 2400W naar 500W of zelfs 0W dient te gaan. Is dit de normale werking van Zendure of kan je die in gielz automatisering aanpassen?

[RobTesla]

Wai_AM schreef op maandag 16 maart 2026 @ 12:54:
Met dit jojo weer zie ik bij NOM sturing de afname (bij wolk voor de zon) per 50W omlaag gaat, dit gaat langzaam als je van 2400W naar 500W of zelfs 0W dient te gaan. Is dit de normale werking van Zendure of kan je die in gielz automatisering aanpassen?

Dit zie ik hier ook. Ik denk dat dit de zendure zelf is die dit doet...

[Stefan1010]

RobTesla schreef op maandag 16 maart 2026 @ 12:55:
[...]

Dit zie ik hier ook. Ik denk dat dit de zendure zelf is die dit doet...

Hier hetzelfde. Ik heb het idee dat hij voorheen sneller reageerde.
Misschien iets in de laatste firmware...

[gielz]

Stefan1010 schreef op maandag 16 maart 2026 @ 17:20:
[...]


Hier hetzelfde. Ik heb het idee dat hij voorheen sneller reageerde.
Misschien iets in de laatste firmware...

Ligt denk ik aan de firmware zie het hier namelijk ook tijdens het opladen. Kleinere stapjes.

[stfn345]

@gielz

Ik denk dat ik een klein bugje heb gevonden: als de Spread indicatie 30,7% is en the Minimale spread = 30 dan doet hij niets (iig niet in Dynamisch Handelen + NOM)
Waarschijnlijk rond hij af en doet hij de berekening: if 30 < 30.
Als ik de minimale spread naar 29 zet ipv 30 werkt het wel.
Edit: ik zie dat er 2 spread indicaties zijn: dynamische_spread_indicatie en dynamische_spread_indicatie_nom.

En voor de rest van de lezers die zensdk-gielz gebruiken icm een dynamisch contract: welke minimale spread gebruiken jullie, (en in welke modus staat hij in 2026?)

[ Voor 45% gewijzigd door stfn345 op 17-03-2026 16:42 ]

[Devke]

stfn345 schreef op dinsdag 17 maart 2026 @ 16:32:
@gielz

Ik denk dat ik een klein bugje heb gevonden: als de Spread indicatie 30,7% is en the Minimale spread = 30 dan doet hij niets (iig niet in Dynamisch Handelen + NOM)
Waarschijnlijk rond hij af en doet hij de berekening: if 30 < 30.
Als ik de minimale spread naar 29 zet ipv 30 werkt het wel.
Edit: ik zie dat er 2 spread indicaties zijn: dynamische_spread_indicatie en dynamische_spread_indicatie_nom.

En voor de rest van de lezers die zensdk-gielz gebruiken icm een dynamisch contract: welke minimale spread gebruiken jullie, (en in welke modus staat hij in 2026?)

Onder de 30% doe ik niet zoveel. Hij staat nu met name in Dynamisch Handelen. Levert het meeste op. NOM gebruik ik soms ook wel. Dan niet voor "winst" maar meer omdat het ook wel gaaf is dat geen stroom van het net hoeft te komen.

[koboy]

stfn345 schreef op dinsdag 17 maart 2026 @ 16:32:
@gielz

Ik denk dat ik een klein bugje heb gevonden: als de Spread indicatie 30,7% is en the Minimale spread = 30 dan doet hij niets (iig niet in Dynamisch Handelen + NOM)
Waarschijnlijk rond hij af en doet hij de berekening: if 30 < 30.
Als ik de minimale spread naar 29 zet ipv 30 werkt het wel.
Edit: ik zie dat er 2 spread indicaties zijn: dynamische_spread_indicatie en dynamische_spread_indicatie_nom.

En voor de rest van de lezers die zensdk-gielz gebruiken icm een dynamisch contract: welke minimale spread gebruiken jullie, (en in welke modus staat hij in 2026?)

Spread op 25%. Boven de 18% levert op gezien de 85% RTE bij mij, maar ik houd wat marge aan.
Stand: dynamisch handelen. Elke dag begin van de middag kijk ik als ik de kans heb even of er wat te optimaliseren valt, maar in de basis is 5 om 5 uur duur/goedkoop best redelijk. Wel opletten dat het aantal laad of ontlaad uren nooit naar 0 gaat, want dan gaat ook de spread naar 0.

Dit met een enkele 2400AC met 4 accu's.

[stfn345]

@koboy gevoelsmatig denk ik dat een minimale spread van 25% al zonde is van je accucycles. De accu heeft geen oneindige levensduur en om deze voor een paar cent helemaal te laten cyclen lijkt me suboptimaal.

Ik zit eraan te denken om een minimale spread van 40-50% aan te houden om cycles te sparen en daarnaast het aantal uren goedkoop op max 3 te zetten, zeker nu de zomer er aan komt en de rest wel bijgeladen wordt met zon. Het blijft een beetje giswerk en ik zou graag willen dat zensdk nog iets slimmer was zodat ik de dure en goedkope uren niet zelf hoef uit te vogelen

Het blijft een lastige som omdat er zoveel variabelen zijn. (wel zon/geen zon, meerdere goedkope periodes op een dag (nacht/middag) of slechts 1?, capaciteit van de accu, laad en ontlaadsnelheid van de accu etc.
Heeft handelen zin?

Voor volgend jaar is het duidelijk dat NOM een vereiste is, vanwege het gebrek aan saldering. Maar in 2026 is het minder duidelijk wat de juiste keuze en settings zijn.

[koboy]

stfn345 schreef op dinsdag 17 maart 2026 @ 17:55:
@koboy gevoelsmatig denk ik dat een minimale spread van 25% al zonde is van je accucycles. De accu heeft geen oneindige levensduur en om deze voor een paar cent helemaal te laten cyclen lijkt me suboptimaal.

Ik zit eraan te denken om een minimale spread van 40-50% aan te houden om cycles te sparen en daarnaast het aantal uren goedkoop op max 3 te zetten, zeker nu de zomer er aan komt en de rest wel bijgeladen wordt met zon. Het blijft een beetje giswerk en ik zou graag willen dat zensdk nog iets slimmer was zodat ik de dure en goedkope uren niet zelf hoef uit te vogelen

Het blijft een lastige som omdat er zoveel variabelen zijn. (wel zon/geen zon, meerdere goedkope periodes op een dag (nacht/middag) of slechts 1?, capaciteit van de accu, laad en ontlaadsnelheid van de accu etc.
Heeft handelen zin?

Voor volgend jaar is het duidelijk dat NOM een vereiste is, vanwege het gebrek aan saldering. Maar in 2026 is het minder duidelijk wat de juiste keuze en settings zijn.

Voor dit jaar (2026) is handel de maximale verdien methode. In dat opzicht is elke cent meegenomen. Als je uitgaat van een levensduur van 6000 cycles / 10 jaar tot 70% restcapaciteit boeien die paar extra cycles dit jaar niet, en de verdiensten helpen wel mee. Op een volle cyclus en een inkooptarief van 25 cent (want lage spread) heb je het over een totale verdienste bij een spread van 25% van ongeveer 20 cent. Begint dan net de moeite te worden.

De accu is voor mij een gebruiksproduct, net als een auto. Ik zorg er goed voor, maar sta niet na elke rit te wassen en poetsen.
Hoe meer dat ding aan het werk is, hoe beter het financiële rendement, en in dat opzicht telt gewoon elk beetje mee. Je laat je geld toch ook niet op de betaalrekening staan omdat de spaarrekening maar 1% ipv 4% rente geeft?

[gielz]

RobTesla schreef op maandag 16 maart 2026 @ 12:55:
[...]

Dit zie ik hier ook. Ik denk dat dit de zendure zelf is die dit doet...

Stefan1010 schreef op maandag 16 maart 2026 @ 17:20:
[...]


Hier hetzelfde. Ik heb het idee dat hij voorheen sneller reageerde.
Misschien iets in de laatste firmware...

Wai_AM schreef op maandag 16 maart 2026 @ 12:54:
Met dit jojo weer zie ik bij NOM sturing de afname (bij wolk voor de zon) per 50W omlaag gaat, dit gaat langzaam als je van 2400W naar 500W of zelfs 0W dient te gaan. Is dit de normale werking van Zendure of kan je die in gielz automatisering aanpassen?

Zouden jullie voor dit afwijkende oplaadgedrag een supportticket kunnen indienen bij Zendure? Ik heb dit ook gedaan en ga nu allerlei data aanleveren. Ook heb ik mijn contactpersoon van Zendure via whatsapp gesproken en aangegeven dat door dit slechte laadgedrag (terug balanceren van 50 watt) je de Zendure thuisbatterij in de lagere segmenten van thuisbatterijen gaat plaatsen.

Hier nu 1 kwh extra import door dit gedrag per dag tijdens het laden op de zon (als er zo nu en dan een wolkje is). Noem het maar hollands weer.

[geert1992]

gielz schreef op woensdag 18 maart 2026 @ 08:37:
[...]


[...]


[...]


Zouden jullie voor dit afwijkende oplaadgedrag een supportticket kunnen indienen bij Zendure? Ik heb dit ook gedaan en ga nu allerlei data aanleveren. Ook heb ik mijn contactpersoon van Zendure via whatsapp gesproken en aangegeven dat door dit slechte laadgedrag (terug balanceren van 50 watt) je de Zendure thuisbatterij in de lagere segmenten van thuisbatterijen gaat plaatsen.

Hier nu 1 kwh extra import door dit gedrag per dag tijdens het laden op de zon (als er zo nu en dan een wolkje is). Noem het maar hollands weer.

[Afbeelding]

Heb je die foto ook geüpload?
Als ik tijd en zin heb, zal ik ook even een support ticket inschieten.

[gielz]

geert1992 schreef op woensdag 18 maart 2026 @ 08:40:
[...]

Heb je die foto ook geüpload?
Als ik tijd en zin heb, zal ik ook even een support ticket inschieten.

Als je de mogelijkheid hebt zou je de test ook kunnen uitvoeren in Zendure HA?

Testcasus: Handmatig modus 2400 watt laden en daarna naar laden op 50 watt.

[Wai_AM]

gielz schreef op woensdag 18 maart 2026 @ 08:49:
[...]


Als je de mogelijkheid hebt zou je de test ook kunnen uitvoeren in Zendure HA?

Testcasus: Handmatig modus 2400 watt laden en daarna naar laden op 50 watt.

zal dit vanmiddag uitvoeren en ook een support ticket indienen.
Is dat via de website of via app in feedback ?

[Devke]

Wai_AM schreef op woensdag 18 maart 2026 @ 08:54:
[...]

zal dit vanmiddag uitvoeren en ook een support ticket indienen.
Is dat via de website of via app in feedback ?

Zie topic warning in algemene topic. https://support.zendure.com/portal/en/home

[mard0]

Ik heb gisteren een zendure 2400 AC+ en AB300L ontvangen en geinstalleerd gebruikmakende van @gielz intergratie. Mijn complimenten hiervoor, het was een eitje om dit te doen. Het enige handwerk wat erbij kwam kijken was even een netto verbruik sensor maken, want die had mijn ESPhome based p1 meter nog niet.

Chapeau. En er komt een koffie je kant op!

[RobTesla]

gielz schreef op woensdag 18 maart 2026 @ 08:37:
Hier nu 1 kwh extra import door dit gedrag per dag tijdens het laden op de zon (als er zo nu en dan een wolkje is).

Dit is voor mijn -speciale use-case- niet zo van belang. Ik heb het ook gezien dat de Zendure dit nu doet, maar voor mij maakt het niet zoveel uit: De Zendure wordt geladen op het off-grid systeem. (Victron met PylonTech batterijen) waarbij die PylonTech op zo'n 'typisch Hollands weertje' als buffer speelt. De aansturing voor het 'slim opladen' van de Zendure vanuit het off-grid systeem doe ik met een python-script dat de Gielz in 'Snel Opladen' schakelt en dan de max oplaadstroom regelt op basis van wat er binnenkomt van Solar op de Victron icm met de SOC en Load van de PylonTechs zodat die ook nog steeds opladen.

[Ben(V)]

gielz schreef op woensdag 18 maart 2026 @ 08:37:
Hier nu 1 kwh extra import door dit gedrag per dag tijdens het laden op de zon (als er zo nu en dan een wolkje is). Noem het maar hollands weer.

Ik vermoed dat ze het ten behoeve van de levensduur van de batterijen gedaan hebben, snel schakelen van max naar nul is niet bevordelijk daarvoor.

Misschien een suggestie aan de hand doen om het instelbaar te maken zodat de gebruiker zelf kan bepalen of ze zoiets willen.
Iets van instelbare terugregel snelheid.

[ Voor 46% gewijzigd door Ben(V) op 18-03-2026 10:11 ]

[gielz]

Ben(V) schreef op woensdag 18 maart 2026 @ 10:07:
[...]


Ik vermoed dat ze het ten behoeve van de levensduur van de batterijen gedaan hebben, snel schakelen van max naar nul is niet bevordelijk daarvoor.
Maar zeker in ons klimaat met relatief kleine wolken die de hele dag voor de zon schuiven is het een hoop verlies.
Iets van instelbare terugregel snelheid.

Misschien een suggestie aan de hand doen om het instelbaar te maken zodat de gebruiker zelf kan bepalen of ze zoiets willen.

Je zou het denken ja maar dat lijkt mij niet. Wanneer je namelijk direct van 2400 naar 0 gaat is het instant. Maar dat is niet wat gebruikelijk is tijdens het opladen via de zon.

Tevens is dit alleen bij opladen bij ontladen kun je alle kanten op en de reactie snelheid is direct.

[Ben(V)]

Ja blijft vreemd

[koboy]

Zou een aanpassing kunnen zijn om beter met snel pulserende belastingen om te kunnen gaan. De kookplaat / Quooker maffia heeft toegeslagen

[ Voor 4% gewijzigd door koboy op 18-03-2026 11:37 ]

[DeadMetal]

gielz schreef op maandag 16 maart 2026 @ 17:46:
[...]
Ligt denk ik aan de firmware zie het hier namelijk ook tijdens het opladen. Kleinere stapjes.

Ik ga mijn 2400+ ergens in de komende dagen installeren. Ik wil de Zendure-app niet (permanent) gaan gebruiken, maar enkel van jouw HA-integratie gebruik gaan maken gielz. Kan ik voorkomen dat de firmware-update geïnstalleerd wordt tijdens het instelproces met de app? Ik heb in mijn router de mogelijkheid om internettoegang voor apparaten te blokkeren.

[koboy]

DeadMetal schreef op woensdag 18 maart 2026 @ 12:09:
[...]


Ik ga mijn 2400+ ergens in de komende dagen installeren. Ik wil de Zendure-app niet (permanent) gaan gebruiken, maar enkel van jouw HA-integratie gebruik gaan maken gielz. Kan ik voorkomen dat de firmware-update geïnstalleerd wordt tijdens het instelproces met de app? Ik heb in mijn router de mogelijkheid om internettoegang voor apparaten te blokkeren.

Firmware upgrade moet je een paar knopjes in de app voor indrukken, kun je volgens mij gewoon niet doen.
Ik heb zelf een paar dagen geleden de upgrade gedaan omdat ik op dat moment geen statistieken vanuit de accu de app meer in zag komen. Dit kan uiteraard ook een andere oorzaak hebben gehad.

Maakt op zich ook niet uit aangezien vol op de dynamische handel dit jaar nog het meest oplevert, en er dus geen NOM gedraaid wordt hier.

[gielz]

DeadMetal schreef op woensdag 18 maart 2026 @ 12:09:
[...]


Ik ga mijn 2400+ ergens in de komende dagen installeren. Ik wil de Zendure-app niet (permanent) gaan gebruiken, maar enkel van jouw HA-integratie gebruik gaan maken gielz. Kan ik voorkomen dat de firmware-update geïnstalleerd wordt tijdens het instelproces met de app? Ik heb in mijn router de mogelijkheid om internettoegang voor apparaten te blokkeren.

Je moet het echt aanklikken. Maar met firmware 1.0.1 van Apri/Mei 2025 krijg ik deze melding groot in het scherm. Bij de HA aansturing zul je de app waarschijnlijk niet zo veel meer gebruiken.

[gielz]

koboy schreef op woensdag 18 maart 2026 @ 11:37:
Zou een aanpassing kunnen zijn om beter met snel pulserende belastingen om te kunnen gaan. De kookplaat / Quooker maffia heeft toegeslagen

Ja maar het is alleen bij laden, bij ontladen is alles direct. Dus de Quooker werkt nog identiek

[paul123]

@gielz is het in jouw setup mogelijk om bij de modi waarbij teruggeleverd wordt een limiet in te stellen tot hoever dit mag gaan? Bijv. vanavond zou ik wel wat terug kunnen leveren maar omdat de prijzen in de nacht en ochtend ook relatief hoog blijven wil ik wel voldoende over houden. Ik kan natuurlijk handmatig het aantal uren "duurste periode" aanpassen of een handmatige periode invoeren, maar het zou handig zijn om een minimum buffer aan te kunnen houden die altijd over blijft voor eigen gebruik. Is waarschijnlijk niet moeilijk toe te voegen dus als er nog niet zoiets is dan zal ik dat eens gaan proberen.

[stfn345]

Heeft iemand ook dit gedrag?
Ik heb een Solarflow 2400AC met 5x AB3000X. (14.4 kWh).

Bij het laden gaat hij in een periode van 3 uur heel geleidelijk van 20% naar 60%.
Echter.. dan zie ik in de grafiek dat hij in een goede 10 minuten van 60 naar 94% gaat. (onmogelijk met 2400w laadsnelheid)

Klinkt alsof er wellicht kalibratie nodig is? Is dat te forceren op een bepaalde manier?.

[Ben(V)]

Misschien een keer kalibreren?
Als je dat automatisch laat doen en hij is om middernacht nog niet vol stopt het kalibreren en komt hij niet tot 100%

[geert1992]

.

[ Voor 158% gewijzigd door geert1992 op 18-03-2026 15:29 ]

[geert1992]

stfn345 schreef op woensdag 18 maart 2026 @ 15:22:
Heeft iemand ook dit gedrag?
Ik heb een Solarflow 2400AC met 5x AB3000X. (14.4 kWh).

Bij het laden gaat hij in een periode van 3 uur heel geleidelijk van 20% naar 60%.
Echter.. dan zie ik in de grafiek dat hij in een goede 10 minuten van 60 naar 94% gaat. (onmogelijk met 2400w laadsnelheid)

Klinkt alsof er wellicht kalibratie nodig is? Is dat te forceren op een bepaalde manier?.

Ik zie hetzelfde gedrag, alleen iets minder heftig; hier gaat hij van 89, naar 100 in een paar minuten.
De batterijen zien meerdere keren per week 100%.
Heb ook het idee dat de nieuwste firmware (.19) dit heeft verergerd.

[Ben(V)]

Hier niets van te merken, maar ik zit nog op de oude firmware.

[stfn345]

Zendure support reageert zo:

The issue of the State of Charge (SOC) jumping from 60% to 94% in your SolarFlow 2400AC system with 5 AB3000X batteries is likely related to SOC estimation accuracy and cell balancing problems within the Battery Management System (BMS). Here are the recommended steps to address this:

Core Issue Analysis:

SOC Estimation Error: The SOC is an estimated value derived from parameters like voltage, current, and temperature. The jump in SOC is a sign of severe estimation inaccuracy, potentially caused by algorithm corrections or data acquisition errors.

Capacity Fade and Balancing Failure: Increased inconsistency among individual cells in the battery pack can lead to reduced usable capacity and interfere with SOC estimation.

System Calibration and Model Updates: The BMS SOC estimation model may need recalibration after prolonged use or changes in the battery setup.

Recommended Actions:
Perform a System Deep Calibration:

- Fully charge the battery to automatic stop using a slow charger.
- Perform a deep discharge (e.g., to 5%-10% SOC).
- Let the battery rest for several hours, then fully charge it again. This helps the BMS recalibrate the relationship between actual capacity and SOC.

Check and Update BMS Firmware:

Ensure the BMS firmware is updated to the latest version. Firmware updates often optimize SOC algorithms and improve balancing strategies. Refer to the manual or contact the equipment supplier for guidance on performing a firmware upgrade.
Conduct Professional Diagnostics:

Cell Voltage Deviation: Check the voltage of all individual cells, especially near the end of charge and discharge. Persistent large voltage differences indicate balancing failure or faulty cells.
Temperature Distribution: Verify uniform temperature across battery modules or cells. Localized temperature abnormalities can affect performance and SOC estimation.
Historical Fault Codes: Read the historical fault logs stored in the BMS for clues like balancing faults or acquisition errors.
Test with a Single Battery:

Disconnect other batteries and test with only one battery connected to verify if the SOC jump is exclusive to the parallel setup.
Provide Feedback:

If the issue persists, provide detailed information to the support team, including:
Specific date and time of SOC jumps.
Screenshots showing the problem.
Device SN and firmware version.
Steps you carried out and their corresponding time and date.
Additional Notes:
SOC jumping is a known phenomenon in multi-battery parallel setups and does not affect system safety. Keeping your device firmware up to date will ensure future optimization updates to address this behavior.

By following these steps, you should be able to resolve or mitigate the SOC estimation issue effectively. Let me know if you need further assistance!

[Wai_AM]

net ticket ingeschoten en krijg meteen een email antwoord terug:

Dear customer,

The issue you described regarding the slow response of the SolarFlow 2400 AC with firmware V1.0.19 to changes in solar input, particularly during cloudy weather, aligns with known concerns about response delays in the system. Here are some insights and suggestions based on the knowledge base:
Observations and Known Behavior:

Response Delay in Adjusting Power:
The system is designed to prioritize stability and avoid frequent fluctuations in power adjustments. This may result in slower reductions in charging power when solar input decreases, as observed in your case.
The gradual decrease in charging power (e.g., from 2400W to 0W taking over 30 seconds) is likely a deliberate design to prevent abrupt changes that could impact system performance.

Firmware Behavior:
Users have reported that earlier firmware versions had faster response times. The current behavior in V1.0.19 may be due to changes in the firmware logic aimed at optimizing other aspects of system performance.

Charging from the Grid:
The system may switch to grid charging if solar input drops below a certain threshold, especially if the battery's charge/discharge thresholds are not optimized.

Suggestions for Improvement:

Optimize Energy Scheduling Settings:
In the Zendure app, review and adjust the energy scheduling settings. Ensure that "PV Only Charging" or "Prioritize Solar" is enabled to minimize grid charging.

Battery Charge/Discharge Thresholds:
Consider optimizing the charge/discharge thresholds. For example, set the battery to discharge to 70% before recharging at 80%, rather than starting to recharge at 79%. This can help reduce unnecessary grid charging.

Firmware Update:
If possible, check for any new firmware updates that may address this issue. Firmware updates can often include optimizations for system behavior.

Restart the System:
Restarting the system can sometimes resolve temporary anomalies in power direction identification or response delays.

Provide Feedback to Zendure:
Your detailed observations and experiment results are valuable. Sharing this information with Zendure's R&D team can help them analyze the issue and potentially release a firmware update to address it.

If the issue persists despite these steps, it may require further analysis by Zendure's R&D team. In such cases, providing a video of the behavior, along with the date and time, can assist in identifying the root cause. Let me know if you need further assistance!

Ben niet blij met dit antwoord, ze zeggen dus vanwege stabiliteit......

[gielz]

Wai_AM schreef op woensdag 18 maart 2026 @ 15:44:
net ticket ingeschoten en krijg meteen een email antwoord terug:

Dear customer,

The issue you described regarding the slow response of the SolarFlow 2400 AC with firmware V1.0.19 to changes in solar input, particularly during cloudy weather, aligns with known concerns about response delays in the system. Here are some insights and suggestions based on the knowledge base:
Observations and Known Behavior:

Response Delay in Adjusting Power:
The system is designed to prioritize stability and avoid frequent fluctuations in power adjustments. This may result in slower reductions in charging power when solar input decreases, as observed in your case.
The gradual decrease in charging power (e.g., from 2400W to 0W taking over 30 seconds) is likely a deliberate design to prevent abrupt changes that could impact system performance.

Firmware Behavior:
Users have reported that earlier firmware versions had faster response times. The current behavior in V1.0.19 may be due to changes in the firmware logic aimed at optimizing other aspects of system performance.

Charging from the Grid:
The system may switch to grid charging if solar input drops below a certain threshold, especially if the battery's charge/discharge thresholds are not optimized.

Suggestions for Improvement:

Optimize Energy Scheduling Settings:
In the Zendure app, review and adjust the energy scheduling settings. Ensure that "PV Only Charging" or "Prioritize Solar" is enabled to minimize grid charging.

Battery Charge/Discharge Thresholds:
Consider optimizing the charge/discharge thresholds. For example, set the battery to discharge to 70% before recharging at 80%, rather than starting to recharge at 79%. This can help reduce unnecessary grid charging.

Firmware Update:
If possible, check for any new firmware updates that may address this issue. Firmware updates can often include optimizations for system behavior.

Restart the System:
Restarting the system can sometimes resolve temporary anomalies in power direction identification or response delays.

Provide Feedback to Zendure:
Your detailed observations and experiment results are valuable. Sharing this information with Zendure's R&D team can help them analyze the issue and potentially release a firmware update to address it.

If the issue persists despite these steps, it may require further analysis by Zendure's R&D team. In such cases, providing a video of the behavior, along with the date and time, can assist in identifying the root cause. Let me know if you need further assistance!

Ben niet blij met dit antwoord, ze zeggen dus vanwege stabiliteit......

Ik zou daar op reageren en doorpakken en je kunt ook verwijzen naar ticket #347582. Zelf heb ik nog contact gehad met mijn contactpersoon en gevraagd of ze streven naar een batterij die leuk is in het laag segment met betrekking tot het laadgedrag of dat ze toch echt de betere willen zijn.

Stabiliteit is natuurlijk onzin want bij het starten van laden, starten van ontladen en het ontladen aanpassen zit deze logica er niet in. Lijkt mij dus gewoon een tikfout in de logica. (charge stapjes van 250 watt om zetten naar 50 watt en tijd voor lunch )

[blahenazo]

Vandaag heb ik het hier toch serieus om zeep geholpen.

Ik draai een 1x ac2400 + 2 x sf800 daarbij nog een 1x sma 3,6 kw.

Ik draai nom ( smart matching), dus zen manager gaat alles sturen.

Hoe laat je de sf800 terug leveren met de ac2400 uit (niet aan het nommen)?

Het idee was: ik ga niet meer nommen , laat de sf800's terug leveren en laat evcc in solar nommen. Maar de sf800 gaven niets meer.

Ik heb vanalles geprobeerd om die sf800 toch maar te laten terug leveren en uiteindelijk de 'ac2400' gedisabled in de interactie. Het hielp niet dus ik enable hem weer en alle entiteiten worden grijs . Weer alles (ha/integratie) herstart geen oplossing.

Ik heb dan maar een backup teruggezet want het liep allemaal een beetje in het honderd. Want de entiteiten gaven niets meer en mijn automatiseringen/dashboards waren om zeep.

[koboy]

geert1992 schreef op woensdag 18 maart 2026 @ 15:28:
[...]

[Afbeelding]
Ik zie hetzelfde gedrag, alleen iets minder heftig; hier gaat hij van 89, naar 100 in een paar minuten.
De batterijen zien meerdere keren per week 100%.
Heb ook het idee dat de nieuwste firmware (.19) dit heeft verergerd.

Bij mij minder heftige sprong bij (bijna) leeg en vol, maar had wel gezien dat die langzaam aan verdwenen was. Waarschijnlijk heeft het BMS zichzelf ingeleerd....
Na de update weer terug naar de oude situatie, dus met sprongetjes. Hoop dat die weer wegtrekken.

Komt er wel het verwachte aantal kWh in en uit de accu?

[jordyc]

Sinds de nieuwste update krijg ik ook regelmatig vanuit de Gielz aansturing een error melding wanneer de batterij bij zijn min/max laadpercentage zit. Dat terwijl ik hiervoor nog nooit een melding had gekregen. Als ik dan in de app kijk zie ik niks aan meldingen.

De batterij is vanmiddag ook in 10 min van nog 1kWh laden naar vol gegaan. Het lijkt er toch op dat deze firmware een paar bugjes heeft.

[peterbier]

Vandaag HomeAssistant met de Zendure als test ingebruik genomen.
Het werkt mooi.
Ook niet meer tegen die grens van maximaal 3000 watt ontladen aan. (Wat ik met HEMS had)
Het dashboard moet ik nog doen met meters enz.
Het begin is er ik blij.😃

[Pakhaas]

jordyc schreef op woensdag 18 maart 2026 @ 19:46:
Sinds de nieuwste update krijg ik ook regelmatig vanuit de Gielz aansturing een error melding wanneer de batterij bij zijn min/max laadpercentage zit. Dat terwijl ik hiervoor nog nooit een melding had gekregen. Als ik dan in de app kijk zie ik niks aan meldingen.

De batterij is vanmiddag ook in 10 min van nog 1kWh laden naar vol gegaan. Het lijkt er toch op dat deze firmware een paar bugjes heeft.

Mijn ene omvormer maakte vandaag ook een sprong van 77 naar bijna 100%. 16 maart heeft deze omvormer en batterijen nog 100% gezien voor ruim 4u.

[geert1992]

peterbier schreef op woensdag 18 maart 2026 @ 20:04:
Vandaag HomeAssistant met de Zendure als test ingebruik genomen.
Het werkt mooi.
Ook niet meer tegen die grens van maximaal 3000 watt ontladen aan. (Wat ik met HEMS had)
Het dashboard moet ik nog doen met meters enz.
Het begin is er ik blij.😃
[Afbeelding]

Welkom bij de club! Sowieso stukken sneller, en slimmer dan HEMS.

[gielz]

Hierbij even een preview over de Mei release waar het dashboard straks met elk (eigen) thema automatisch goed werkt en leesbaar is. Hopelijk in mei ook firmware 1.0.20

*plaatje aanklikken

[GoSolarFlow]

Pakhaas schreef op woensdag 18 maart 2026 @ 20:12:
[...]

Mijn ene omvormer maakte vandaag ook een sprong van 77 naar bijna 100%. 16 maart heeft deze omvormer en batterijen nog 100% gezien voor ruim 4u. [Afbeelding]

Zou de buitentemperatuur met de temp van de cellen kunnen zijn omdat het nu warmer is buiten en laden rond dat tijdstip ook groter is.
Afhankelijk waar de batterijen staan natuurlijk en of de omgevingstemperatuur sterk oploopt uiteraard.

[ Voor 7% gewijzigd door GoSolarFlow op 19-03-2026 10:25 ]

[HiBe]

ik weet dat dit topic expliciet HA in de naam heeft, maar hoop dat ik hier toch een API gerelateerde vraag kan/mag stellen.

Ik ben mijn Zendure 2400AC in mijn Loxone HEMS aan het integreren en loop tegen een eigenaardigheid aan. In mijn HEMS kan ik de batterij sturen naar 2400W (inputLimit of outpuLiimit). Maar de batterij lijkt de export/import op 1200W te limiteren.

Als ik vervolgens in de Zendure app kijk en bij de batterij instellingen (Instelling voor netaansluiting -> netinvoermodus/Netuitvoermodus) naar 1200W gezet te zijn. zodra ik deze aanpas naar 2400W gat het allemaal weer prima.

Ik vraag mij dus af wat de Zendure naar 1200W reset? is dat een specifieke API parameter? kan dit gerelateerd zijn aan de smartMode parameter?

[gielz]

HiBe schreef op donderdag 19 maart 2026 @ 10:46:
ik weet dat dit topic expliciet HA in de naam heeft, maar hoop dat ik hier toch een API gerelateerde vraag kan/mag stellen.

Ik ben mijn Zendure 2400AC in mijn Loxone HEMS aan het integreren en loop tegen een eigenaardigheid aan. In mijn HEMS kan ik de batterij sturen naar 2400W (inputLimit of outpuLiimit). Maar de batterij lijkt de export/import op 1200W te limiteren.

Als ik vervolgens in de Zendure app kijk en bij de batterij instellingen (Instelling voor netaansluiting -> netinvoermodus/Netuitvoermodus) naar 1200W gezet te zijn. zodra ik deze aanpas naar 2400W gat het allemaal weer prima.

Ik vraag mij dus af wat de Zendure naar 1200W reset? is dat een specifieke API parameter? kan dit gerelateerd zijn aan de smartMode parameter?

Dat limiet zou gereset kunnen worden door Zendure HEMS (weet ik niet zeker) of je eigen aansturing. Het betreffen iig de onderstaande API properties. Smartmode staat hier helemaal los van en doet iets anders.

"inverseMaxPower":2400
"chargeMaxLimit":2400

Je zou deze even kunnen opnemen in Loxone HEMS als een sensor om te kijken wanneer ze exact resetten. Zelf niet bekend met Loxone

[HiBe]

gielz schreef op donderdag 19 maart 2026 @ 11:02:
[...]


Dat limiet zou gereset kunnen worden door Zendure HEMS (weet ik niet zeker) of je eigen aansturing. Het betreffen iig de onderstaande API properties. Smartmode staat hier helemaal los van en doet iets anders.

"inverseMaxPower":2400
"chargeMaxLimit":2400

Je zou deze even kunnen opnemen in Loxone HEMS als een sensor om te kijken wanneer ze exact resetten. Zelf niet bekend met Loxone

Bedankt, hier kan ik weer verder mee.

als ik naar de zenSDK documentatie kijk dan lijkt alleen inverseMaxPower schrijfbaar, maar chargeMaxLimit is read-only. toch een beetje onhandig..klopt dit eigenlijk wel?
het liefst zou ik gewoon elke dag op de max zetten, zodat ik er zeker van ben dat dit goed gaat.

[gielz]

HiBe schreef op donderdag 19 maart 2026 @ 11:41:
[...]


Bedankt, hier kan ik weer verder mee.

als ik naar de zenSDK documentatie kijk dan lijkt alleen inverseMaxPower schrijfbaar, maar chargeMaxLimit is read-only. toch een beetje onhandig..klopt dit eigenlijk wel?
het liefst zou ik gewoon elke dag op de max zetten, zodat ik er zeker van ben dat dit goed gaat.

Beide zijn read en write ondanks dat het er niet staat. Ik zou alleen niet elke dag ze standaard op max zetten maar zoeken naar de oorzaak.

[HiBe]

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


Beide zijn read en write ondanks dat het er niet staat. Ik zou alleen niet elke dag ze standaard op max zetten maar zoeken naar de oorzaak.

ga ik zeker ook naar zoeken, maar wil de mogelijkheid hebben voor een workaround totdat ik de oorzaak gevonden heb.

[ralphkeb]

Sinds vandaag ook de eigenaar van een Zendure, krijg de HW p1 meter niet werkende dus dan morgen maar de HA weg in slaan.

Voor nu heb ik 1 800 plus, maar ben voornemens er nog 2 bij te halen, op elke fase een batterij, maar is het ook mogelijk om 3 batterijen te integreren?

Zie wel de mogelijkheid van 2 batterijen met de nodered oplossing, maar wil er straks echt 3.

[Devke]

ralphkeb schreef op donderdag 19 maart 2026 @ 19:50:
Sinds vandaag ook de eigenaar van een Zendure, krijg de HW p1 meter niet werkende dus dan morgen maar de HA weg in slaan.

Voor nu heb ik 1 800 plus, maar ben voornemens er nog 2 bij te halen, op elke fase een batterij, maar is het ook mogelijk om 3 batterijen te integreren?

Zie wel de mogelijkheid van 2 batterijen met de nodered oplossing, maar wil er straks echt 3.

Je zou dit kunnen proberen. Of het lekker werkt? Ik heb zelf 2x 2400 AC. Kan dit niet testen.
https://github.com/Leguanjanin/Zendure-zenSDK-proxy_3

[gielz]

ralphkeb schreef op donderdag 19 maart 2026 @ 19:50:
Sinds vandaag ook de eigenaar van een Zendure, krijg de HW p1 meter niet werkende dus dan morgen maar de HA weg in slaan.

Voor nu heb ik 1 800 plus, maar ben voornemens er nog 2 bij te halen, op elke fase een batterij, maar is het ook mogelijk om 3 batterijen te integreren?

Zie wel de mogelijkheid van 2 batterijen met de nodered oplossing, maar wil er straks echt 3.

Je zou voor de officiële integratie van Zendure zelf kunnen gaan die ondersteund dit; https://github.com/Zendure/Zendure-HA

Besef wel dat je echt veel standby verlies en ontlaad/laad verlies hebt met 3x 800 plus maar dat is meer voor het Zendure topic.

[Refl]

@gielz kleine suggestie die misschien allang is overwogen (en afgeschoten) maar ik heb de y-as van dynamisch vandaag/morgen ingesteld op 0.0 tot 0.50 (euro) en daarboven valt erbuiten. Zodoende makkelijker vergelijken dag op dag voor mij althans.