Zendure producten in Home Assistant integreren deel 2

[Arthur]

Hippe Lip schreef op dinsdag 19 mei 2026 @ 23:05:
[...]
Heb je écht de laatste versie van de Gielz en de proxy van @gast777? Vooral die laatste is belangrijk, want ik had precies zoiets en aan de hand van metingen is er gisteren een nieuwe versie gekomen. Kijk dus even op Github naar de versie van 18-05-2026. Vooral de Node-RED flow is belangrijk om de laatste te hebben.
Laat je weten of het daarna voorbij is?

Bedankt voor je bericht. Ik gebruik de allerlaatste versie van de Gielz. Ik heb de proxy niet, maar ging er eigenlijk van uit dat die alleen zinvol zou zijn voor meerdere omvormers?

DrNickB schreef op dinsdag 19 mei 2026 @ 22:29:
[...]
Niet dat ik je vraag direct kan beantwoorden, maar wat waren je tempratuur waardes van je omvormers en wat was je batterij soc ?
Te warm kan throttle betekenen, hoge soc kan kalibratie zijn voor laatste (soms wel) 20%.

De omvormer was 50 graden, SOC pas zo'n 40%.

[ Voor 21% gewijzigd door Arthur op 20-05-2026 12:19 ]

[Hieke]

Hippe Lip schreef op dinsdag 19 mei 2026 @ 23:14:
En dan heb ik voor @gast777 nog een aardig bericht. Ik heb de afgelopen drie uren tijdens het ontladen je proxycounters laten lopen. In de ene stack 2 GET Reply’s gemist, in de andere maar eentje. En geen enkel serienummer gemist.

Betekent dit dat het nu goed draait? Geen missing packets meer?

Hmm, terwijl ik dit tik bedenk ik me dat ik mijn gehakkel dat ik tot gisteren had (vanwege ‘unknown’ serienummers) alleen voorkwam in de laadfase en dit is tijdens het ontladen, niet tijdens het ontladen vreemd genoeg.
Als ik eraan denk (en dan tijd heb) zal ik morgen tijdens het laden nog eens een waarneming doen.

[Afbeelding]

Zojuist de laatste update van @gast777 gepatched. En daarbij de aanwijzingen in de Readme gevolgd. Maar ik kwam verwijzing naar bovenstaande code daarbij niet tegen.. Heb ik iets over het hoofd gezien of is deze code nog niet publiek?
Waar is deze verkrijgbaar?
Of moet ik zelf aan de slag?

Niet dat IK momenteel zelf problemen ervaar bij het gebruik van de software, maar bij mijn broer gaat het ook mis. Een identieke SF 2400 AC opstelling met 2 omvormers en 3 accu's... Aanleiding om te updaten, mogelijk lost dat het op en anders is diagnostische software meer dan welkom!

[gast777]

Hieke schreef op woensdag 20 mei 2026 @ 14:49:
[...]

Zojuist de laatste update van @gast777 gepatched. En daarbij de aanwijzingen in de Readme gevolgd. Maar ik kwam verwijzing naar bovenstaande code daarbij niet tegen.. Heb ik iets over het hoofd gezien of is deze code nog niet publiek?
Waar is deze verkrijgbaar?
Of moet ik zelf aan de slag?

Welke bovenstaande code bedoel je?

20260518 is momenteel de nieuwste. Dat is het bestand Zendure-proxy-Node-Red-flow_XX.json in de Dutch of Global directory op https://github.com/gast777/Zendure-zenSDK-proxy

Dus als je die genomen hebt zit je al goed.

Debug dashboard zit dan op http://<ip_adres>:1880/endpoint/dashboard/zenproxylivedataget

[ Voor 33% gewijzigd door gast777 op 20-05-2026 18:50 ]

[Hieke]

gast777 schreef op woensdag 20 mei 2026 @ 18:46:
[...]

Welke bovenstaande code bedoel je?

20260518 is momenteel de nieuwste. Dat is het bestand Zendure-proxy-Node-Red-flow_XX.json in de Dutch of Global directory op https://github.com/gast777/Zendure-zenSDK-proxy

Dus als je die genomen hebt zit je al goed.

Debug dashboard zit dan op http://<ip_adres>:1880/endpoint/dashboard/zenproxylivedataget

Ik doelde (middels de afbeelding in de quote) op de proxy-counters.

Heb vanmiddag de JSON-file https://github.com/gast777/Zendure-zenSDK-proxy/tree/main/Dutch_(NL)_Proxy , (last commit date 2 days ago) gedownload en geïmporteerd in een nieuw tabblad van NR.



Maar krijg nu de foutmelding in de browser:

Het extra tabblad met de Zendure Proxy Sensoren werkt wel naar behoren...

Mis even de benodigde kennis, verwachtte eigenlijk een extra, nieuwe pagina/tabblad te moeten toevoegen in de applicatie van Gielz. Net als voor de Proxy Sensoren.

Overigens: ik draai NR op een andere host dan de machine waar HA op draait. Misschien dat url met endpoint daarmee verandert?

Ah, als ik URL aanpas, endpoint weghaal, krijg ik een soort van menupagina.... Maar dit is een ander overzicht dan ik https://gathering.tweakers.net/forum/update_message/85309034 zag..

Dank voor je support en je mooie applicatie!

[ Voor 17% gewijzigd door Hieke op 20-05-2026 19:14 ]

[gast777]

Hieke schreef op woensdag 20 mei 2026 @ 19:03:
[...]

Ik doelde (middels de afbeelding in de quote) op de proxy-counters.

Heb vanmiddag de JSON-file https://github.com/gast777/Zendure-zenSDK-proxy/tree/main/Dutch_(NL)_Proxy , (last commit date 2 days ago) gedownload en geïmporteerd in een nieuw tabblad van NR.

[Afbeelding]

Maar krijg nu de foutmelding in de browser:

[Afbeelding] Het extra tabblad met de Zendure Proxy Sensoren werkt wel naar behoren...

Mis even de benodigde kennis, verwachtte eigenlijk een extra, nieuwe pagina/tabblad te moeten toevoegen in de applicatie van Gielz. Net als voor de Proxy Sensoren.

Overigens: ik draai NR op een andere host dan de machine waar HA op draait. Misschien dat endpoint daarmee verandert?

Dank voor je support en je mooie applicatie!

Ja je kunt die pagina als dashboard in HA toevoegen als die werkt. Probeer eens zonder "/endpoint"?

[Hieke]

gast777 schreef op woensdag 20 mei 2026 @ 19:10:
[...]

Ja je kunt die pagina als dashboard in HA toevoegen als die werkt. Probeer eens zonder "/endpoint"?

We waren even beiden simultaan berichten aan het verzenden. Zonder /endpoint werkt dus. Maar even niet helder hoe ik de data van de Zendures kan tonen als extra kaart in de app van Gielz. Voor de Proxy-sensoren heb je daarvoor een stukje code gepubliceerd. Dat simpel geplakt kan worden.

Daarnaast was ik met name benieuwd naar de diagnostics van de werking van je proxy-software. Die @Hippe Lip dus toonde..

[gast777]

Hieke schreef op woensdag 20 mei 2026 @ 19:26:
[...]

We waren even beiden simultaan berichten aan het verzenden. Zonder /endpoint werkt dus. Maar even niet helder hoe ik de data van de Zendures kan tonen als extra kaart in de app van Gielz. Voor de Proxy-sensoren heb je daarvoor een stukje code gepubliceerd. Dat simpel geplakt kan worden.

Daarnaast was ik met name benieuwd naar de diagnostics van de werking van je proxy-software. Die @Hippe Lip dus toonde..

Ah OK. Het Node-RED dashboard is een website en staat los van Home Assistant. Je kunt wel elke website als dashboard in HA zetten. Maar dat is het. Je kan het niet als kaart op een HA dashboard toevoegen.

En de debug naar file werkt alleen als je Node-RED als App in HA hebt geinstalleerd. (Of je moet zelf het file pad aanpassen in de node-red flow, maar out of the box werkt het dus niet bealve als HA App)

[Hieke]

gast777 schreef op woensdag 20 mei 2026 @ 19:40:
[...]

Ah OK. Het Node-RED dashboard is een website en staat los van Home Assistant. Je kunt wel elke website als dashboard in HA zetten. Maar dat is het. Je kan het niet als kaart op een HA dashboard toevoegen.

En de debug naar file werkt alleen als je Node-RED als App in HA hebt geinstalleerd. (Of je moet zelf het file pad aanpassen in de node-red flow, maar out of the box werkt het dus niet bealve als HA App)

Dank voor je info. Even nog voor mijn beeldvorming:

In welke categorie valt dan de Proxy Info inzake de werking van de Proxy-applicatie?
Want over die code zou ik wel graag willen beschikken.

Bij mijn broer draait zowel HA als NR op dezelfde host. En als er dan een extra "kaart" bij komt met daarin de Proxy Info wordt het allemaal wel simpel voor hem cq mij om het inzicht te krijgen in de problemen die hij meent te hebben..

[smetzie]

Ik heb even gezocht op het forum, maar kon dit probleem niet direct terugvinden. Ik loop tegen het volgende aan met mijn Zendure 2400 Pro.

Zodra de batterij moet gaan ontladen binnen de modus dynamisch handelen, lijkt hij in een soort freeze/storing te schieten. Op dat moment is de batterij niet meer aan te sturen via Home Assistant en ook niet meer via de Zendure app. De enige oplossing lijkt dan te zijn om het apparaat te verwijderen en alles volledig los te koppelen. Daarna werkt alles direct weer normaal en begint hij ook meteen weer met ontladen in dezelfde modus.

Ik weet dat het wifi-signaal bij de batterij momenteel niet optimaal is (daar wordt aan gewerkt), maar het opvallende is dat dit elke avond op exact hetzelfde moment gebeurt: zodra de batterij gaat ontladen. Overdag blijft de batterij gewoon bereikbaar en bestuurbaar. Daarom twijfel ik of het puur een verbindingsprobleem is.

Heeft iemand dit eerder meegemaakt of enig idee waar dit aan kan liggen?

Onderaan heb ik wat screenshots toegevoegd.

[gast777]

@Hieke Je kunt het bijvoorbeeld zo inrichten, zoals ik zelf heb:
- het standaard Gielz dashboard
- de proxy sensoren
- het node-red debug dashboard

[Theetjuh]

Vraagje @gast777, ik zit in de bijna aanschaf mode, dus alvast sorry als ik een vraag stel die mogelijk voor de hand ligt.

Hoe gaat je proxy om met bijvoorbeeld 2400AC+ devices welke je verschillende max input/output wilt geven?
Denk aan de ene omvormer beperken tot 1200W en de andere op 2400W
Is dat iets wat je alsnog in de Zendure app moet instellen?

Ben ook wel benieuwd of het nog uitmaakt of je de 1200W of 2400W als device1 of device2 instelt

[Hieke]

gast777 schreef op woensdag 20 mei 2026 @ 21:35:
@Hieke Je kunt het bijvoorbeeld zo inrichten, zoals ik zelf heb:
- het standaard Gielz dashboard
- de proxy sensoren
- het node-red debug dashboard

[Afbeelding]

Excuses voor het feit dat ik verzuimd heb om ALLE release-info op jouw Github door te nemen. Daarin staat namelijk keurig beschreven hoe ik de debugpagina's kon oproepen. Slordig van mij.

Begrijp nu ook waar dat nieuwe dashboard in NR voor was aangemaakt..

Ik kan nu in elk geval op het systeem waar zowel HA als NR op dezelfde host draaien het dashboard eenvoudig toevoegen. Dank al je mooie werk!

[ Voor 4% gewijzigd door Hieke op 20-05-2026 22:38 ]

[Mistraller]

Theetjuh schreef op woensdag 20 mei 2026 @ 22:01:
Vraagje @gast777, ik zit in de bijna aanschaf mode, dus alvast sorry als ik een vraag stel die mogelijk voor de hand ligt.

Hoe gaat je proxy om met bijvoorbeeld 2400AC+ devices welke je verschillende max input/output wilt geven?
Denk aan de ene omvormer beperken tot 1200W en de andere op 2400W
Is dat iets wat je alsnog in de Zendure app moet instellen?

Ben ook wel benieuwd of het nog uitmaakt of je de 1200W of 2400W als device1 of device2 instelt

Ik praat misschien voor mijn beurt maar volgens mij kan dat niet; want dat stel je in de Gielz integratie in. De proxy verdeelt het alleen maar (slim)

[abaart]

smetzie schreef op woensdag 20 mei 2026 @ 21:35:
Ik heb even gezocht op het forum, maar kon dit probleem niet direct terugvinden. Ik loop tegen het volgende aan met mijn Zendure 2400 Pro.

Zodra de batterij moet gaan ontladen binnen de modus dynamisch handelen, lijkt hij in een soort freeze/storing te schieten. Op dat moment is de batterij niet meer aan te sturen via Home Assistant en ook niet meer via de Zendure app. De enige oplossing lijkt dan te zijn om het apparaat te verwijderen en alles volledig los te koppelen. Daarna werkt alles direct weer normaal en begint hij ook meteen weer met ontladen in dezelfde modus.

Dit lijkt heel erg op de problemen die meerdere mensen tegen komen. Er is een kleine hiccup in het netwerk of in de Zendure, waardoor de vele API requests zich opstapelen en de Zendure nieuwe verbindingen gaat weigeren of afbreken. Wanneer de request-storm ophoudt dan herstelt de Zendure zich snel weer. Zie ook dit GitHub issue.

Om deze problemen definitief te verhelpen ben ik begonnen aan het vibecoden van een replica van de NodeRed proxy van @gast777 in Python, gebruik makende van AppDaemon en HACS.

Zie hier de GitHub repo

Ik heb daarin een paar 'slimme' features toegevoegd met als doelen:

• Korte uitval of Zendure hiccups 'graceful' afhandelen. Niet de hele gecombineerde proxy-batterij direct op unavailable in HA, maar tijdelijk doorgaan met de andere (goede) Zendures en de problematische Zendure even rust geven. Wanneer de Zendure zich herstelt nemen we deze weer op in de pool aansturing.
• Voorkomen dat zo'n micro uitval zorgt voor een opstapeling van wachtende API requests, waardoor de Zendure voor langere tijd overbelast blijft.
• Rate-limiten van API requests, door snel opvolgende en/of herhalende/overlappende/langdurende requests vanuit HA slim te combineren en af te handelen. Dit d.m.v. o.a. caching en slim omgaan met queues (zowel inkomend vanuit HA als uitgaand naar de Zendures)
• Makkelijk inzicht in HA in de prestaties/stabiliteit van individuele Zendures. Zodat je een automation met push message kan maken zodra er een Zendure uitvalt. En kan zien welke Zendure langzaam reageert.
• Makkelijker upgraden door gebruik te maken van HACS
• Later: handig opvangen van uitdagende situaties, zoals bij NulOpDeMeter modus 'klapperen' tussen laden en ontladen. Als je meerdere Zendures hebt zou je die kunnen optimaliseren op zo goed mogelijk NOM, door reserve capaciteit in zowel laden als ontladen klaar te hebben staan. Geen idee of dit daadwerkelijk winstgevend is vanwege de overhead, maar vond het wel een grappig idee.
• Later: bijhouden van relais schakelingen op individueel Zendure niveau

Deze oplossingen leken mij kansrijk, maar moeilijk voor mij om te implementeren in NodeRed. Vandaar de switch naar Python. Voordeel is ook dat je met 'gewone code' leesbare git diffs hebt.

Ik ben nu thuis aan het testen, tot nu toe draait het stabiel in NOM modus (de zwaarste in termen van API requests vanwege continue bijsturen). Ik zal het langere tijd blijven testen op stabiliteit.

Om bepaalde reacties voor te zijn: ja, dit is bijna 100% vibe-coded, maar dat doe ik niet voor het eerst, en is wmb ook geen zonde Er zullen dus ongetwijfeld fouten in zitten, verwacht dus geen perfectie.

Ik wil ook graag benadrukken dat dit niet bedoeld is als kritiek op het enorme werk dat @gast777 en @gielz al hebben gedaan aan de HA-integraties en de proxy. Integendeel: zonder hun werk was ik hier niet eens aan begonnen. Ik bouw vooral verder op hun ideeën en aanpak, maar dan in een vorm die voor mij makkelijker te begrijpen, testen en aanpassen is. (in Python)

[ctrl-tab]

abaart schreef op woensdag 20 mei 2026 @ 23:08:
[...]

Dit lijkt heel erg op de problemen die meerdere mensen tegen komen. Er is een kleine hiccup in het netwerk of in de Zendure, waardoor de vele API requests zich opstapelen en de Zendure nieuwe verbindingen gaat weigeren of afbreken. Wanneer de request-storm ophoudt dan herstelt de Zendure zich snel weer. Zie ook dit GitHub issue.

Om deze problemen definitief te verhelpen ben ik begonnen aan het vibecoden van een replica van de NodeRed proxy van @gast777 in Python, gebruik makende van AppDaemon en HACS.

Zie hier de GitHub repo

Ik heb daarin een paar 'slimme' features toegevoegd met als doelen:

• Korte uitval of Zendure hiccups 'graceful' afhandelen. Niet de hele gecombineerde proxy-batterij direct op unavailable in HA, maar tijdelijk doorgaan met de andere (goede) Zendures en de problematische Zendure even rust geven. Wanneer de Zendure zich herstelt nemen we deze weer op in de pool aansturing.
• Voorkomen dat zo'n micro uitval zorgt voor een opstapeling van wachtende API requests, waardoor de Zendure voor langere tijd overbelast blijft.
• Rate-limiten van API requests, door snel opvolgende en/of herhalende/overlappende/langdurende requests vanuit HA slim te combineren en af te handelen. Dit d.m.v. o.a. caching en slim omgaan met queues (zowel inkomend vanuit HA als uitgaand naar de Zendures)
• Makkelijk inzicht in HA in de prestaties/stabiliteit van individuele Zendures. Zodat je een automation met push message kan maken zodra er een Zendure uitvalt. En kan zien welke Zendure langzaam reageert.
• Makkelijker upgraden door gebruik te maken van HACS
• Later: handig opvangen van uitdagende situaties, zoals bij NulOpDeMeter modus 'klapperen' tussen laden en ontladen. Als je meerdere Zendures hebt zou je die kunnen optimaliseren op zo goed mogelijk NOM, door reserve capaciteit in zowel laden als ontladen klaar te hebben staan. Geen idee of dit daadwerkelijk winstgevend is vanwege de overhead, maar vond het wel een grappig idee.
• Later: bijhouden van relais schakelingen op individueel Zendure niveau

Deze oplossingen leken mij kansrijk, maar moeilijk voor mij om te implementeren in NodeRed. Vandaar de switch naar Python. Voordeel is ook dat je met 'gewone code' leesbare git diffs hebt.

Ik ben nu thuis aan het testen, tot nu toe draait het stabiel in NOM modus (de zwaarste in termen van API requests vanwege continue bijsturen). Ik zal het langere tijd blijven testen op stabiliteit.

Om bepaalde reacties voor te zijn: ja, dit is bijna 100% vibe-coded, maar dat doe ik niet voor het eerst, en is wmb ook geen zonde Er zullen dus ongetwijfeld fouten in zitten, verwacht dus geen perfectie.

Ik wil ook graag benadrukken dat dit niet bedoeld is als kritiek op het enorme werk dat @gast777 en @gielz al hebben gedaan aan de HA-integraties en de proxy. Integendeel: zonder hun werk was ik hier niet eens aan begonnen. Ik bouw vooral verder op hun ideeën en aanpak, maar dan in een vorm die voor mij makkelijker te begrijpen, testen en aanpassen is. (in Python)

Klinkt goed. Wanneer je voor mijn use cases feature complete bent (ik gebruik fast charge en discharge, smart discharge) wil ik wel.eens testen.

Heb zelf met claude getracht wat zaken in nodered te doen maar daar is claude niet zo goed in. Ook vind ik zelf python beter te begrijpen dan javascript. Inderdaad niks ten nadele van de huidige oplossingen. Ervaar zelf ook geen issues trouwens.

[hremijn]

abaart schreef op woensdag 20 mei 2026 @ 23:08:
[...]

Ik heb daarin een paar 'slimme' features toegevoegd met als doelen:

• Korte uitval of Zendure hiccups 'graceful' afhandelen. Niet de hele gecombineerde proxy-batterij direct op unavailable in HA, maar tijdelijk doorgaan met de andere (goede) Zendures en de problematische Zendure even rust geven. Wanneer de Zendure zich herstelt nemen we deze weer op in de pool aansturing.
• Voorkomen dat zo'n micro uitval zorgt voor een opstapeling van wachtende API requests, waardoor de Zendure voor langere tijd overbelast blijft.
• Rate-limiten van API requests, door snel opvolgende en/of herhalende/overlappende/langdurende requests vanuit HA slim te combineren en af te handelen. Dit d.m.v. o.a. caching en slim omgaan met queues (zowel inkomend vanuit HA als uitgaand naar de Zendures)

Waarom geen MQTT gebruiken? Dan zijn al die problemen met overloaden van de controller er niet.

[gielz]

Voordat we in een eindeloze discussie belanden over vastlopende Zendure-systemen: dit probleem is letterlijk op één hand te tellen. Tot nu toe bleek in 9 van de 10 gevallen dat de oorzaak lag bij een slecht functionerend thuisnetwerk. Er zijn duizenden (schatting 4-5k) gebruikers die Zendure HA, Gielz of andere sturing gebruiken zonder enig probleem.

Daarnaast zie je dat Zendure dit in de nieuwe “Mix”-serie heeft aangepakt door een netwerkaansluiting toe te voegen.

Nieuwe oplossingen zijn uiteraard welkom in dit topic. Laten we er echter voor waken dat wij het hier straks niet alleen maar over connectie problemen hebben omdat 0,1% van de gebruikers dit probleem heeft.

[dotcom87]

Ik heb gisteren 2 Zendure AB3000X batterijen toegevoegd aan mijn setup. Ik had op dit moment de 2400AC en 1 AB3000X. Ik heb de 2 nieuwe batterijen onderaan de toren toegevoegd, omdat ik de omvormer al met klemmen had vastgemaakt aan de AB3000X die ik al had. Ik zie nu dit op het dashboard van Gielz:




Mijn vraag is of dit er ok uit ziet? Hij heeft de extra capaciteit opgepikt, dus dat is goed. Maar moet ik iets veranderen aan de Battery Order?

[gielz]

dotcom87 schreef op donderdag 21 mei 2026 @ 09:09:
Ik heb gisteren 2 Zendure AB3000X batterijen toegevoegd aan mijn setup. Ik had op dit moment de 2400AC en 1 AB3000X. Ik heb de 2 nieuwe batterijen onderaan de toren toegevoegd, omdat ik de omvormer al met klemmen had vastgemaakt aan de AB3000X die ik al had. Ik zie nu dit op het dashboard van Gielz:

[Afbeelding]

[Afbeelding]
Mijn vraag is of dit er ok uit ziet? Hij heeft de extra capaciteit opgepikt, dus dat is goed. Maar moet ik iets veranderen aan de Battery Order?

De batterij volgorde kan soms foutief zijn. Wat je doet is met pen en papier schrijf je even de volgorde op. Op de batterij zit een sticker met het serienummer.

Vervolgens vergelijk je deze met sensor.zendure_battery_serial_numbers. Stel je wilt dan dat de batterij in de API die op dat moment op plek 3 zit maar eigenlijk de bovenste is veranderen dan is de order 3;1;2. Alle relevante sensoren worden dan aangepast.

Dit is trouwens alleen om het mooier te maken. Je Zendure gaat niet opeens anders werken.

[ppaulv]

Gisteren een poging gewaagd om m'n SolarEdge omvormer uit te schakelen als de dynamische stroomprijs onder een bepaald bedrag zakt en weer aan te zetten als ie daar weer boven komt.
Dit gebaseerd op de Nordpool prijzen die ik met de oplossing 'kado' heb gekregen.
Voor mij een lichtelijk academische oefening omdat ik nog tot 1 juli 2027 een vaste prijzen contract heb. Tot die tijd lever ik graag maximaal terug tot 1 januari en daarna maakt het me niets uit tot 1 juli.
Maar goed, tot mijn verbazing werkte het meteen na het oplossen van wat syntax en inspring foutjes. Samen met een eigen stukje om op gezette tijdstippen te switchen naar vooraf bepaalde modi (voorlopig alleen slim opladen vanaf 11.00 uur en slim ontladen om 17.00 uur, dat vind ik voldoende voor nu) is dit 'pretty much' wat ik denk te willen gebruiken. Maar daar komt vast nog wel wat bij de komende maanden.
Voor wie denkt het te kunnen gebruiken, ik heb het in een aparte yaml file in de packages folder gezet, de prijzen waarop gekanteld wordt ga ik nog een keer door een invulveldje vervangen.

[ppaulv]

YAML: switch_and_flip.yaml

  automation:
    - alias: "17 uur alleen slim ontladen"
      description: ""
      trigger:
        - platform: time
          at: "17:00:00"
      condition: []
      action:
        - service: input_select.select_option
          target:
            entity_id: input_select.zendure_2400_ac_modus_selecteren
          data:
            option: "Alleen slim ontladen"
      mode: single

    - alias: "11 uur alleen slim opladen"
      description: ""
      trigger:
        - platform: time
          at: "11:00:00"
      condition: []
      action:
        - service: input_select.select_option
          target:
            entity_id: input_select.zendure_2400_ac_modus_selecteren
          data:
            option: "Alleen slim opladen"
      mode: single

    - alias: Flip SE based on Nordpool price
      description: Turn off advanced power control when price < €0.17
      trigger:
        - platform: state
          entity_id: sensor.dynamisch_nordpool
      condition: []
      action:
        - choose:
            - conditions:
                - condition: numeric_state
                  entity_id: sensor.dynamisch_nordpool
                  below: 0.17
              sequence:
                - service: switch.turn_off
                  target:
                    entity_id: switch.solaredge_i1_advanced_power_control
            - conditions:
                - condition: numeric_state
                  entity_id: sensor.dynamisch_nordpool
                  above: 0.18
              sequence:
                - service: switch.turn_on
                  target:
                    entity_id: switch.solaredge_i1_advanced_power_control
      mode: single

[abaart]

ctrl-tab schreef op donderdag 21 mei 2026 @ 06:29:
Klinkt goed. Wanneer je voor mijn use cases feature complete bent (ik gebruik fast charge en discharge, smart discharge) wil ik wel.eens testen.

In de basis maakt het voor de proxies niet uit welke modus die je in de Gielz HA automation gebruikt. HA geeft commando's -> proxy stuurt (intelligent) door -> Zendures voeren uit. (en rapporteren weer terug in omgekeerde volgorde)

hremijn schreef op donderdag 21 mei 2026 @ 07:13:
Waarom geen MQTT gebruiken? Dan zijn al die problemen met overloaden van de controller er niet.

Ik moet toegeven dat ik zelf MQTT aansturing van de Zendures nog niet geprobeerd heb. Dit omdat er eerder in de Zendure topics hier op GoT werd vermeld dat de MQTT integratie op de Zendures niet goed om zou kunnen gaan met tijdelijk offline zijn van de MQTT server.
Hoe dan ook, bij het combineren van meerdere Zendures zou ook bij het gebruik van MQTT wat slimme aansturing nodig zijn, zoals @gast777 heeft ontwikkeld in Zendure-zenSDK-proxy

gielz schreef op donderdag 21 mei 2026 @ 07:41:
Voordat we in een eindeloze discussie belanden over vastlopende Zendure-systemen: dit probleem is letterlijk op één hand te tellen. Tot nu toe bleek in 9 van de 10 gevallen dat de oorzaak lag bij een slecht functionerend thuisnetwerk. Er zijn duizenden (schatting 4-5k) gebruikers die Zendure HA, Gielz of andere sturing gebruiken zonder enig probleem.

Daarnaast zie je dat Zendure dit in de nieuwe “Mix”-serie heeft aangepakt door een netwerkaansluiting toe te voegen.

Nieuwe oplossingen zijn uiteraard welkom in dit topic. Laten we er echter voor waken dat wij het hier straks niet alleen maar over connectie problemen hebben omdat 0,1% van de gebruikers dit probleem heeft.

Dit is toch het "Zendure producten in Home Assistant integreren" topic ?!?

Het is natuurlijk altijd makkelijk om de ‘oorzaak’ extern te leggen: domme/vervelende gebruikers, te weinig Wifi APs, te weinig cores op je HA server, te weinig gbit internet, te weinig GHz, enz., enz. Echter de gebruikersrealiteit is dat dingen nooit 100% perfect kunnen zijn.
In mijn geval staan de Zendures <1m van een met CAT6A aangesloten TP link Omada AP. Geen enkel ander device in mijn huishouden heeft enig probleem met het netwerk. Dan vind ik het moeilijk te geloven dat de oorzaak van het probleem daarin zou liggen.
En zelfs al zou dat wél het probleem zijn, zie ik geen realistische mogelijkheid om het te verbeteren, buiten de Zendures openschroeven en bij elke een dedicated AP onder de deksel te proppen.

Daarnaast vind ik het eerlijk gezegd ridicuul dat een HA server een high-powered CPU nodig zou hebben, om wat HTTP requests van een paar kB tijdig door te kunnen sturen.

Deze manier van softwareproblemen oplossen lijkt mij tegenstrijdig met de use case van de Zendures: klimaatverandering tegengaan en tegelijkertijd ook geld besparen.

Met dank aan de feedback en hulp van @gast777 heb ik op mijn setup een packet capture gedraaid en geanalyseerd, waaruit bleek dat er inderdaad soms een TCP retransmission plaatsvond (foei!! ), maar dat de daadwerkelijke oorzaak ligt bij de gelimiteerde (reken)capaciteit van de Zendures. Meestal reageren die <100ms, maar soms (met name na moduswissels e.d.) doen ze er eventjes wat langer over. En ze kunnen niet meer dan +-6 gelijktijdige HTTP requests aan.
Ik begrijp uit eerdere berichten dat sommigen het vervelend vinden om AI-gegenereerde teksten te lezen, maar hier staat een uitgebreide probleemanalyse, inclusief code om het probleem te reproduceren.

Dat jij persoonlijk geen last hebt van dit probleem en het daardoor schijnbaar als vervelend ervaart dat gebruikers samen hiervoor een oplossing zoeken, vind ik betreurenswaardig. Maar m.i. rechtvaardigt het niet dat er niet meer over dit probleem gesproken zou mogen worden.

Ik deel hier mijn (weg naar een) oplossing, omdat ik verwacht dat het ook de anderen met dit probleem zou kunnen helpen. Als dat inderdaad zo blijkt, dan zal de discussie hierover ook snel voorbij kunnen zijn, omdat het is opgelost

[gielz]

abaart schreef op donderdag 21 mei 2026 @ 10:38:
[...]

Dat jij persoonlijk geen last hebt van dit probleem en het daardoor schijnbaar als vervelend ervaart dat gebruikers samen hiervoor een oplossing zoeken, vind ik betreurenswaardig. Maar m.i. rechtvaardigt het niet dat er niet meer over dit probleem gesproken zou mogen worden.

Ik deel hier mijn (weg naar een) oplossing, omdat ik verwacht dat het ook de anderen met dit probleem zou kunnen helpen. Als dat inderdaad zo blijkt, dan zal de discussie hierover ook snel voorbij kunnen zijn, omdat het is opgelost

Ik heb letterlijk aangegeven dat nieuwe oplossingen welkom zijn in dit topic. Je reactie vind ik dan een beetje vreemd. Wat ik bedoel aan te geven is dat wij er met ze alle voor moeten waken dat er straks niet 3 pagina's over connectie problemen zijn wat ook prima eerst onderling via DM besproken kan worden.

Wat ik voornamelijk lees op de zenSDK github is dat de gebruikers met een 800 Plus problemen hebben met connecties. In 12 maanden dat ik met de integratie bezig ben geweest hebt ik 3x een connectie probleem via DM/Issue voorbij zien komen deze waren allemaal gelinkt aan een instabiel netwerk maar gebruikte allemaal de 2400AC.

Zie je mogelijkheid om de omvormer open te schroeven om te kijken welke chip ze gebruiken? Hier onder de 2400 Pro.


Zojuist nog even bruteforce commands gestuurd (10 per seconden). Draait gewoon vrolijk door de 2400AC in NOM.

[abaart]

gielz schreef op donderdag 21 mei 2026 @ 10:56:
[...]


Ik heb letterlijk aangegeven dat nieuwe oplossingen welkom zijn in dit topic. Je reactie vind ik dan een beetje vreemd. Wat ik bedoel aan te geven is dat wij er met ze alle voor moeten waken dat er straks niet 3 pagina's over connectie problemen zijn wat ook prima eerst onderling via DM besproken kan worden.

Wat ik voornamelijk lees op de zenSDK github is dat de gebruikers met een 800 Plus problemen hebben met connecties. In 12 maanden dat ik met de integratie bezig ben geweest hebt ik 3x een connectie probleem via DM/Issue voorbij zien komen deze waren allemaal gelinkt aan een instabiel netwerk maar gebruikte allemaal de 2400AC.

Zie je mogelijkheid om de omvormer open te schroeven om te kijken welke chip ze gebruiken? Hier onder de 2400 Pro.
[Afbeelding]

Zojuist nog even bruteforce commands gestuurd (10 per seconden). Draait gewoon vrolijk door de 2400AC in NOM.

Als je mijn analyse leest, zie je dat het spammen van GET requests met 10Hz niet an sich per-se problematisch is. Het is rondom het wisselen van modi en vermogen, dat de Zendure voor enige tijd wat langzaam reageert, soms doet ie er wel eens meer dan 10 seconden over.

Dan is de hele Zendure pool in HA direct 'unavailable', terwijl er in feite niets aan de hand is, behalve dat de rapportage eventjes langzaam reageert.

Als je dan tegelijkertijd door blijft 'spammen' (wat de automation in feite doet op +-1Hz GET + 0,2Hz POST, overigens niets mis mee wmb) stapelen de open connecties zich op, want elke onbeantwoorde request bezet 1 HTTP connectie. Dan is de max van 6 connecties al heel snel gepasseerd. De Zendure kapt de connecties dan af, totdat de (in feite DoS) load weer voldoende afgenomen is.

In de code om het probleem te reproduceren (ongeacht of je Wifi nou goed of slecht is), is te zien dat er helemaal niet zo bizar veel requests nodig zijn om dit probleem te triggeren.

Inmiddels met meer dan 12 uur runtime op NOM heeft mijn proxy-herimplementatie dit probleem in mijn Zendure-pool nog niet getriggered, waar dit met de NodeRed proxy al lang was gebeurd.

Dit doordat mijn proxy de load voor de Zendures binnen de perken houdt, door nooit meer dan 2 gelijktijdige requests open te hebben staan per Zendure. Tegelijkertijd worden wel netjes de HA requests afgehandeld, waardoor zelfs al zou een Zendure alsnog uitvallen, de andere Zendures vrolijk door blijven draaien. (en wanneer mogelijk zelfs eventjes compenseren voor de tijdelijk 'stuurloze' Zendure)

Het zou prima kunnen dat de SoC in de 800 modellen minder krachtig is dan die in de 2400 modellen. Echter verandert dat wmb niets aan de zaak.

De historische issues die je aanhaalt bij 2400AC modellen, zouden met deze proxy –zonder iets aan de schijnbaar suboptimale netwerkverbinding te veranderen– wel eens opgelost kunnen worden. Recent lijkt de melding van @smetzie ook sterk op de bovenstaande situatie. Het zou interessant zijn als @smetzie dit eens zou kunnen testen.

[Theetjuh]

Mistraller schreef op woensdag 20 mei 2026 @ 22:38:
[...]

Ik praat misschien voor mijn beurt maar volgens mij kan dat niet; want dat stel je in de Gielz integratie in. De proxy verdeelt het alleen maar (slim)

Toch bedankt voor je reactie, zou wel balen zijn als het niet per omvormer in te stellen is, aangezien er nu eenmaal een verschil in load op de groep kan zijn.
Juist daarom wil ik die in de schuur op de volle 2400W kunnen laten werken, als compensatie zeg maar.

[gielz]

Theetjuh schreef op donderdag 21 mei 2026 @ 12:21:
[...]

Toch bedankt voor je reactie, zou wel balen zijn als het niet per omvormer in te stellen is, aangezien er nu eenmaal een verschil in load op de groep kan zijn.
Juist daarom wil ik die in de schuur op de volle 2400W kunnen laten werken, als compensatie zeg maar.

Bij de Zendure HA integratie kan dit wel. Daar werk je met fusegroups per zendure.

[Theetjuh]

gielz schreef op donderdag 21 mei 2026 @ 12:36:
[...]

Bij de Zendure HA integratie kan dit wel. Daar werk je met fusegroups per zendure.

Maar de Zendure HA integratie is weer niet volledig lokaal zover ik begreep en werkt niet samen met m’n eigen esphome P1 meter.

Dus als er een manier is om de Gielz integratie zeg maar 3600W op te geven en de proxy regelt dat daarvan maximaal 1200 naar 1 mag en 2400 naar 2, zijn we er toch?
Maargoed dan denk ik misschien te simpel

[Ben(V)]

Zendure HA is wel volledig lokaal en kan met elke p1 meter die je in HA kunt hangen werken.
Als je enkel Nom gaat gebruiken is dat prima, als je wilt gaan handelen is Gielz de aangewezen integratie.


Overigens lijkt het mij vrij nutteloos om een verschil in te willen stellen.

[RemmyB83]

Theetjuh schreef op donderdag 21 mei 2026 @ 12:53:
[...]

Maar de Zendure HA integratie is weer niet volledig lokaal zover ik begreep en werkt niet samen met m’n eigen esphome P1 meter.

Dus als er een manier is om de Gielz integratie zeg maar 3600W op te geven en de proxy regelt dat daarvan maximaal 1200 naar 1 mag en 2400 naar 2, zijn we er toch?
Maargoed dan denk ik misschien te simpel

Klinkt net zo makkelijk als: even kabeltje trekken, en aansluiten op een eigen groep in de groepenkast

[gielz]

Theetjuh schreef op donderdag 21 mei 2026 @ 12:53:
[...]

Maar de Zendure HA integratie is weer niet volledig lokaal zover ik begreep en werkt niet samen met m’n eigen esphome P1 meter.

Dus als er een manier is om de Gielz integratie zeg maar 3600W op te geven en de proxy regelt dat daarvan maximaal 1200 naar 1 mag en 2400 naar 2, zijn we er toch?
Maargoed dan denk ik misschien te simpel

De Zendure HA integratie kan volledig lokaal. Hiervoor kun je in de integratie een keuze maken dat alles via zenSDK gaat. Bij het installeren of herconfigureren van deze integratie geef je ook je eigen P1 meter op.

De Gielz integratie is primair gebouwd voor 1 device om het eenvoudig en makkelijk voor de gebruiker te houden. De proxy van @gast777 kan hem dan bruikbaar maken voor meerdere devices. Geen idee of @gast777 het ziet zitten om de vermogens verdeling instelbaar te maken wellicht is het een stuk meer werk dan gedacht.

[Theetjuh]

Ben(V) schreef op donderdag 21 mei 2026 @ 12:57:
Overigens lijkt het mij vrij nutteloos om een verschil in te willen stellen.

Kun je aangeven wat daar nutteloos aan is?

RemmyB83 schreef op donderdag 21 mei 2026 @ 12:59:
[...]

Klinkt net zo makkelijk als: even kabeltje trekken, en aansluiten op een eigen groep in de groepenkast

Ik moet zeggen dat ik daar op het moment wel aan zit te denken inderdaad, maar of dat zo simpel is ... kan ik weer niet zelf beoordelen, heb al aardig wat groepen in gebruik.

gielz schreef op donderdag 21 mei 2026 @ 13:17:
[...]

De Zendure HA integratie kan volledig lokaal. Hiervoor kun je in de integratie een keuze maken dat alles via zenSDK gaat. Bij het installeren of herconfigureren van deze integratie geef je ook je eigen P1 meter op.

De Gielz integratie is primair gebouwd voor 1 device om het eenvoudig en makkelijk voor de gebruiker te houden. De proxy van @gast777 kan hem dan bruikbaar maken voor meerdere devices. Geen idee of @gast777 het ziet zitten om de vermogens verdeling instelbaar te maken wellicht is het een stuk meer werk dan gedacht.

Thanks, dan is de Zendure HA integratie toch wel mogelijk, goed om te weten.

Sorry voor al deze vragen btw het is nog vrij nieuw voor me en er staat op zoveel plekken verschillende informatie dat het niet altijd even makkelijk is te bepalen wat op dit moment de waarheid is.

[gielz]

Theetjuh schreef op donderdag 21 mei 2026 @ 13:22:

Thanks, dan is de Zendure HA integratie toch wel mogelijk, goed om te weten.

Sorry voor al deze vragen btw het is nog vrij nieuw voor me en er staat op zoveel plekken verschillende informatie dat het niet altijd even makkelijk is te bepalen wat op dit moment de waarheid is.

Snap ik, afgelopen 12 maanden is er in batterijland een hoop veranderd met betrekking tot aansturen. Mocht je echt even helemaal de weg kwijt willen raken. Buiten de hier besproken integraties zijn er nog veel meer;
https://github.com/search...positories&s=stars&o=desc

[hapklaar]

Even benieuwd: heeft iemand al iets voor in HASS bedacht of gebouwd om te bepalen hoeveel ‘winst’ je Zendure-opstelling heeft opgeleverd vergeleken met een situatie zonder thuisbatterij, per dag, week, maand, jaar of sinds de start, voor de dynamische modi? Om bijv. uiteindelijk ROI of terugverdientijd te kunnen bepalen.

[Mistraller]

hapklaar schreef op donderdag 21 mei 2026 @ 13:50:
Even benieuwd: heeft iemand al iets voor in HASS bedacht of gebouwd om te bepalen hoeveel ‘winst’ je Zendure-opstelling heeft opgeleverd vergeleken met een situatie zonder thuisbatterij, per dag, week, maand, jaar of sinds de start, voor de dynamische modi? Om bijv. uiteindelijk ROI of terugverdientijd te kunnen bepalen.

Ik had het aan ChatGPT gevraagd en die heeft er voor mij een heel eenvoudige rekensom van gemaakt op basis van energieprijs- sensoren en een fixed RTE. (En met fixed contract prijzen) AI tools bakken tegenwoordig best aardige yaml, al moet je soms wel een paar keer proberen voor alles klopt. (Maar dat is GPT eigen)

[ctrl-tab]

hapklaar schreef op donderdag 21 mei 2026 @ 13:50:
Even benieuwd: heeft iemand al iets voor in HASS bedacht of gebouwd om te bepalen hoeveel ‘winst’ je Zendure-opstelling heeft opgeleverd vergeleken met een situatie zonder thuisbatterij, per dag, week, maand, jaar of sinds de start, voor de dynamische modi? Om bijv. uiteindelijk ROI of terugverdientijd te kunnen bepalen.

Ik gebruik hier ' dynamic energy cost' voor.
Deze houdt per dag-week-maand-jaar bij wat de kosten of winst zijn voor een device.
Zie screenshot. Bijna 50 euro gewonnen dus sinds aanschaf om en nabij een maand geleden.

Hij werkt met 1 tarief dus na einde salderingsregeling (ander terugleverbedrag als inkoop bedrag) moet er creatief met bedragen om gegaan worden. Komt iig niet als feature maar zeker doable.
https://github.com/martinarva/dynamic_energy_cost/issues/232

[Mistraller]

Theetjuh schreef op donderdag 21 mei 2026 @ 12:21:
[...]

Toch bedankt voor je reactie, zou wel balen zijn als het niet per omvormer in te stellen is, aangezien er nu eenmaal een verschil in load op de groep kan zijn.
Juist daarom wil ik die in de schuur op de volle 2400W kunnen laten werken, als compensatie zeg maar.

Zolang de meter fase-onbalans saldeert is daar niet zoveel noodzaak toe toch? Je kunt dat beperken door te kijken op welke fase je de apparatuur aansluit.

[Pakhaas]

hapklaar schreef op donderdag 21 mei 2026 @ 13:50:
Even benieuwd: heeft iemand al iets voor in HASS bedacht of gebouwd om te bepalen hoeveel ‘winst’ je Zendure-opstelling heeft opgeleverd vergeleken met een situatie zonder thuisbatterij, per dag, week, maand, jaar of sinds de start, voor de dynamische modi? Om bijv. uiteindelijk ROI of terugverdientijd te kunnen bepalen.

Met mid kwh meters van Homewizard wordt dat automatisch berekent als je de juiste dynamische tarieven hebt ingevoerd.

[gielz]

Wellicht handig om te weten. In de zenSDK API zijn ze nu het volgende aan het ontwikkelen;

https://github.com/Zendure/zenSDK

we are currently developing a remote/device reboot function, and this will be documented in the API documentation once it is available.

[ctrl-tab]

gielz schreef op donderdag 21 mei 2026 @ 14:17:
Wellicht handig om te weten. In de zenSDK API zijn ze nu het volgende aan het ontwikkelen;

https://github.com/Zendure/zenSDK

[...]

remote shutdown zou handiger zijn, voor als je 2400 ac unit raar doet en je op vakantie bent

[Theetjuh]

Mistraller schreef op donderdag 21 mei 2026 @ 14:00:
[...]

Zolang de meter fase-onbalans saldeert is daar niet zoveel noodzaak toe toch? Je kunt dat beperken door te kijken op welke fase je de apparatuur aansluit.

Klopt, maar aangezien ik met batterijpack begin op zolder, waar al erg veel op aangesloten is qua apparatuur, zal die mogelijk niet hoger komen dan 800W aan (dis)charge anders klopt de zekering eruit.
Aangezien later op de avond alleen al een koffiezetapparaat of waterkoker meer vraagt dan die 800W zal hij zeker van het net gaan snoepen.
Daarom ook een andere batterijpack later in het jaar welke op een aparte groep zit, zodat ik wel die volledige 2400W (dis)charge heb, waardoor hij niet meer van het net zou moeten snoepen.

Daarom is het voor mij ook van belang een max_charge/max_discharge te kunnen instellen per omvormer

[Mistraller]

Theetjuh schreef op donderdag 21 mei 2026 @ 14:35:
[...]

Klopt, maar aangezien ik met batterijpack begin op zolder, waar al erg veel op aangesloten is qua apparatuur, zal die mogelijk niet hoger komen dan 800W aan (dis)charge anders klopt de zekering eruit.
Aangezien later op de avond alleen al een koffiezetapparaat of waterkoker meer vraagt dan die 800W zal hij zeker van het net gaan snoepen.
Daarom ook een andere batterijpack later in het jaar welke op een aparte groep zit, zodat ik wel die volledige 2400W (dis)charge heb, waardoor hij niet meer van het net zou moeten snoepen.

Daarom is het voor mij ook van belang een max_charge/max_discharge te kunnen instellen per omvormer

Daar mag ie ook absoluut niet boven de 800W discharge. Waarom op zolder? Want daar is het vaak veel warmer en krijg je eerder dat de omvormer gaat knijpen. Op een reeds zwaar belaste groep zou ik sowieso geen accu aansluiten. (met name de groep die de keuken apparaten voorziet inderdaad)

Kan je beter gewoon in 1x voor goed gaan.

[Theetjuh]

De temperatuur is in de zomer zelfs hoger in de garage dan op zolder, dus dat valt allemaal wel mee, hoogste temperatuur geregistreerd is 28 graden en in de garage 30 graden.

M'n idee was om zo over 3 fases op 3 plekken in het huis wat neer te zetten, zolder, garage en schuur.
Er is maar 1 groep die op zolder komt, vandaar dat ik daar weinig andere keuze had.
Wat daar op zit is de cv, luchtcirculatie en de nodige servertjes/nassen, maar ook de audio/video voor in de woonkamer.

Maar misschien wel een goed idee om een aparte groep hiervoor aan te gaan leggen naar zolder, maakt het ook makkelijker op dan de integratie van Gielz en de proxy van Gast777 te gebruiken

[ Voor 0% gewijzigd door Theetjuh op 21-05-2026 16:07 . Reden: typo ]

[Gramser]

Grap777?

🤭🤭🤭

[Theetjuh]

Gramser schreef op donderdag 21 mei 2026 @ 16:05:
Grap777?

🤭🤭🤭

och ik heb zo grapgast in m'n hoofd door een vriend van vroeger, dat ik me constant moet corrigeren, heb het aangepast

[Ben(V)]

Het is veel efficiënter om maar een batterij te hebben op een eigen groep die dan 2400W kan leveren dan drie die elk maar 800W leveren.

Dat laatste wordt een dure grap met geen enkel rendement.

[RemmyB83]

Ben(V) schreef op donderdag 21 mei 2026 @ 17:25:
Het is veel efficiënter om maar een batterij te hebben op een eigen groep die dan 2400W kan leveren dan drie die elk maar 800W leveren.

Dat laatste wordt een dure grap met geen enkel rendement.

Ik weet niet op wie of welk bericht je reageerd, maar dit mag best met iets meer uitleg. Ik heb zelf 3x een 800plus(vandaag 3de in ontvangst genomen😀), en als ik je opmerking zo lees raakt het kant nog wal.

[Gramser]

Kostentechnisch lijkt het me duidelijk toch?

[geert1992]

RemmyB83 schreef op donderdag 21 mei 2026 @ 17:38:
[...]

Ik weet niet op wie of welk bericht je reageerd, maar dit mag best met iets meer uitleg. Ik heb zelf 3x een 800plus(vandaag 3de in ontvangst genomen😀), en als ik je opmerking zo lees raakt het kant nog wal.

Mee eens! Ik had 3 torentjes met hypers, met elk 2 accu's, en haalde een RTE van 83% en hoger. En haal nu met een enkele 2400AC icm 4, en later 5 batterijen een RTE van 84%.

[RemmyB83]

geert1992 schreef op donderdag 21 mei 2026 @ 17:56:
[...]

Mee eens! Ik had 3 torentjes met hypers, met elk 2 accu's, en haalde een RTE van 83% en hoger. En haal nu met een enkele 2400AC icm 4, en later 5 batterijen een RTE van 84%.

Ik heb hier tot vandaag met 2 batterijen en NOM strategie ook een RTE van 85% gehaald(1,5 maand).
Nu met een derde wordt dat misschien iets lastiger.

Daarnaast als het kosten technisch zou zijn, dan heb je met een 2400(type maakt even niet uit), een aparte groep nodig om zijn volle potentie te benutten. Die kosten heb ik nu niet, al wil ik niet zeggen dat ik dat later niet wil als ze naar hun definitieve plek gaan(dan wel 3x🫣).
Ook een 2400 kost atm 950e oftewel 400e per kWh opslag voor de eerste 2.4kWh.

Nu heb ik 3x een batterij gekocht voor minder dan 450e per stuk. En kom op ongeveer 230e per kWh opslag.

Nu is mijn verwachte strategie vooral NOM, en verwacht ik dat de 3 kleine daar beter bij passen dan 1x een 2400. Maar als ik had verwacht om nog veel en lang te kunnen handelen had ik waarschijnlijk ook een 2400 gekocht, omdat ik voor dat doel meer potentie zie in de 2400 zie.

[oeps]

hremijn schreef op donderdag 21 mei 2026 @ 07:13:
[...]

Waarom geen MQTT gebruiken? Dan zijn al die problemen met overloaden van de controller er niet.

Er is een open issue bij Zendure dat mqtt stopt al HA herstart wordt, bijvoorbeeld door bijwerken HA. Om het te fixen moet mqtt ff in de Zendure app uit/aanzetten.

Dit kreeg ik van Zendure support op 6 mei:

Hi ,
Thanks for your follow-up. Our R&D team is aware of this known issue and is working on a solution. We appreciate your patience while we complete the development and optimization.

[Hippe Lip]

Theetjuh schreef op donderdag 21 mei 2026 @ 16:03:
M'n idee was om zo over 3 fases op 3 plekken in het huis wat neer te zetten, zolder, garage en schuur.

Je bedoelt dat je graag je kansen op brand verdeelt over het huis?

[Luuk741]

ctrl-tab schreef op donderdag 21 mei 2026 @ 13:59:
[...]


Ik gebruik hier ' dynamic energy cost' voor.
Deze houdt per dag-week-maand-jaar bij wat de kosten of winst zijn voor een device.
Zie screenshot. Bijna 50 euro gewonnen dus sinds aanschaf om en nabij een maand geleden.

Hij werkt met 1 tarief dus na einde salderingsregeling (ander terugleverbedrag als inkoop bedrag) moet er creatief met bedragen om gegaan worden. Komt iig niet als feature maar zeker doable.
https://github.com/martinarva/dynamic_energy_cost/issues/232


[Afbeelding]

Met welke zendure sensor heb je deze ingesteld? Export vermogen?

[ctrl-tab]

Luuk741 schreef op donderdag 21 mei 2026 @ 20:16:
[...]

Met welke zendure sensor heb je deze ingesteld? Export vermogen?

sensor.zendure_power
dat is de sum (gaat zowel - als + )

komt van gielz trouwens.
Mocht je geen Gielz hebben, dan zou je even een template sensor moeten maken die je export en import combineert, en die gebruiken.

[ Voor 24% gewijzigd door ctrl-tab op 21-05-2026 21:57 ]

[thijsh02]

Klopt het dat bijna alle sensoren van de 2400AC+ zijn uitgeschakeld in de Fireson integratie? De temperatuur sensor van de omvormer kan ik bijvoorbeeld niet inschakelen 🤔 melding: Kan status niet wijzigen. Uitgeschakeld door apparaat

Of beter de Gielz integratie gebruiken? Heb alleen ook een Hyper en die staat niet op het ondersteunende lijstje.

[ZuinigeRijder]

Ik heb vandaag ook de @gielz ZenSDK geïnstalleerd, inclusief de @gast777 proxy voor mijn 2 Zendure 800 Plus batterijen.

Het viel me vanavond op, toen ik deze op NOM mode zetten, dat deze niet ging ontladen. De zonnepanelen leverden nog ietsjes terug, maar er was import van het net van ongeveer 60 Watt.

Volgens mij heeft dat met deze setting te maken:

code:

zendure_2400_ac_ontladen_starten_bij    (Instellingsadvies: 100 watt) 80 t/m 500 watt – hier geef je aan wanneer de batterij exact begint met ontladen. Daarna balanceert de batterij naar 0 - de extra ontlaadmarge.

Ik had deze setting op het minimum van 80 Watt staan. Maar dat betekent volgens mij, dat er pas met ontladen begonnen wordt, als er meer dan 80 Watt van het net geïmporteerd wordt? Klopt dat? Waarom is voor deze setting van 80 Watt als minimum gekozen? Betekent dit dat elke avond pas begonnen wordt met ontladen, wanneer er boven 80 Watt van het net geïmporteerd wordt? Of was dit een ongelukkig moment om NOM te kiezen?

[RemmyB83]

ZuinigeRijder schreef op donderdag 21 mei 2026 @ 22:29:
Ik heb vandaag ook de @gielz ZenSDK geïnstalleerd, inclusief de @gast777 proxy voor mijn 2 Zendure 800 Plus batterijen.

Het viel me vanavond op, toen ik deze op NOM mode zetten, dat deze niet ging ontladen. De zonnepanelen leverden nog ietsjes terug, maar er was import van het net van ongeveer 60 Watt.

Volgens mij heeft dat met deze setting te maken:

code:

zendure_2400_ac_ontladen_starten_bij    (Instellingsadvies: 100 watt) 80 t/m 500 watt – hier geef je aan wanneer de batterij exact begint met ontladen. Daarna balanceert de batterij naar 0 - de extra ontlaadmarge.

Ik had deze setting op het minimum van 80 Watt staan. Maar dat betekent volgens mij, dat er pas met ontladen begonnen wordt, als er meer dan 80 Watt van het net geïmporteerd wordt? Klopt dat? Waarom is voor deze setting van 80 Watt als minimum gekozen? Betekent dit dat elke avond pas begonnen wordt met ontladen, wanneer er boven 80 Watt van het net geïmporteerd wordt? Of was dit een ongelukkig moment om NOM te kiezen?

Klopt.
Maar als je de automation opent, en je zoekt op de woorden opladen en ontladen kun je ze redelijk makkelijk vinden, en waardes ook redelijk makkelijk aanpassen. Ik heb ze namelijk beide aangepast naar 50W en -50W.

[ZuinigeRijder]

@RemmyB83 Dus jij hebt de source code veranderd, bijvoorbeeld min: naar 50?

code:

zendure_2400_ac_ontladen_starten_bij:
    name: Zendure 2400 AC Ontladen Starten Bij
    icon: mdi:battery-minus-variant
    min: 80
    max: 500
    step: 1
    mode: box
    unit_of_measurement: "W"

Is er een reden, waarom 80 als minimum gekozen is? Efficiëntie? Andere reden?

[Luuk741]

ctrl-tab schreef op donderdag 21 mei 2026 @ 21:48:
[...]


sensor.zendure_power
dat is de sum (gaat zowel - als + )

komt van gielz trouwens.
Mocht je geen Gielz hebben, dan zou je even een template sensor moeten maken die je export en import combineert, en die gebruiken.

Ik draai Gielz in het Nederlands, maar denk dat het dan de sensor 'Zendure 2400 AC Vermogen Aansturing' is. Die volgt inderdaad zowel het laden als ontladen. Enige hiaat is dat het laden vrijwel uitsluitend via de zonnepanelen op het dak gebeurd, maar dat als 'kosten' wordt meegenomen in deze berekeningen. Terwijl die energie 'gratis' is

[ctrl-tab]

Luuk741 schreef op donderdag 21 mei 2026 @ 22:43:
[...]

Ik draai Gielz in het Nederlands, maar denk dat het dan de sensor 'Zendure 2400 AC Vermogen Aansturing' is. Die volgt inderdaad zowel het laden als ontladen. Enige hiaat is dat het laden vrijwel uitsluitend via de zonnepanelen op het dak gebeurd, maar dat als 'kosten' wordt meegenomen in deze berekeningen. Terwijl die energie 'gratis' is

Gratis bestaat niet. In plaats van terugleveren vang je de stroom nu op (import). Je kiest ervoor om niet voor 13 cent terug te leveren maar om die goedkope stroom op te slaan. Dus die kilowat kost je 13 cent op dat moment.
Daarna compenseer je je verbruik met de batterij tegen 30 cent per kilowat. Dus dat is in feite winst.

Als je een dynamisch contract hebt is dit op dit moment ongeveer 1-op-1.
Straks ligt het anders.

[Luuk741]

ctrl-tab schreef op donderdag 21 mei 2026 @ 22:54:
[...]


Gratis bestaat niet. In plaats van terugleveren vang je de stroom nu op (import). Je kiest ervoor om niet voor 13 cent terug te leveren maar om die goedkope stroom op te slaan. Dus die kilowat kost je 13 cent op dat moment.
Daarna compenseer je je verbruik met de batterij tegen 30 cent per kilowat. Dus dat is in feite winst.

Als je een dynamisch contract hebt is dit op dit moment ongeveer 1-op-1.
Straks ligt het anders.

Check, dat is ook zo natuurlijk. Had mezelf iets te gemakkelijk iets te rijk gerekend

[ctrl-tab]

Luuk741 schreef op donderdag 21 mei 2026 @ 23:00:
[...]

Check, dat is ook zo natuurlijk. Had mezelf iets te gemakkelijk iets te rijk gerekend

Hehe wel ik snap de gedachtengang wel. Maar uiteindelijk is opslag van energie uit je zonnepanelen inkomstenderving. Straks wordt het interessanter, dan gaan de negatieve prijs momenten aanzienlijk toenemen. Dan is het geen inkomstenderving maar een verzekering tegen het betalen van boetes.
En moet je de 'gratis' stroom gaan knijpen (power limit op je panelen knijpen zodat je niks terug levert) Daarom wel fijn als je capaciteit en vermogen van je batterij genoeg is om je panelen voor een uur of 3 volledig (minus basislast) op te slurpen.

[RemmyB83]

ZuinigeRijder schreef op donderdag 21 mei 2026 @ 22:40:
@RemmyB83 Dus jij hebt de source code veranderd, bijvoorbeeld min: naar 50?

code:

zendure_2400_ac_ontladen_starten_bij:
    name: Zendure 2400 AC Ontladen Starten Bij
    icon: mdi:battery-minus-variant
    min: 80
    max: 500
    step: 1
    mode: box
    unit_of_measurement: "W"

Is er een reden, waarom 80 als minimum gekozen is? Efficiëntie? Andere reden?

Ja, van die 80 heb ik 50 gemaakt.
Dit zal gielz idd hebben gedaan vanwege efficentie en overmatig schakkelen van het relais. Nu is dit alleen om het laden of ontladen te starten. Het is niet zo dat hij stopt als het vermogen tussen de 2 waardes komt. Bij een 2400 kan ik mijn daar ook best iets bij voorstellen, maar bij onze kleine 800, hou ik liever een iets kleinere bandbreedte aan. Volgens mijn zit de zendure integratie zelf ook op 50 of 60 Watt.

[gast777]

gielz schreef op donderdag 21 mei 2026 @ 13:17:
[...]


De Zendure HA integratie kan volledig lokaal. Hiervoor kun je in de integratie een keuze maken dat alles via zenSDK gaat. Bij het installeren of herconfigureren van deze integratie geef je ook je eigen P1 meter op.

De Gielz integratie is primair gebouwd voor 1 device om het eenvoudig en makkelijk voor de gebruiker te houden. De proxy van @gast777 kan hem dan bruikbaar maken voor meerdere devices. Geen idee of @gast777 het ziet zitten om de vermogens verdeling instelbaar te maken wellicht is het een stuk meer werk dan gedacht.

Inderdaad momenteel wordt het max vermogen simpelweg gelijk verdeeld over alle Zendures. Dit is ook de reden dat het mixen van verschillende modellen Zendures niet aan te raden is (behalve als ze hetzelfde vermogen hebben zoals SF2400AC en SF2400AC+).

Ik heb er zeker wel eens over gedacht om dat instelbaar te maken. En ook om rekening te houden met het totaal aantal kWh batterij capaciteit per device (als dat verschillend is) bij het berekenen van het vermogen van ieder device.

(Maar dan zou de gebruiker het best ook evenredig veel batterijcapaciteit eronder zetten, want anders blijven de SoC niet ongeveer gelijk met de verschillende vermogens. Dan heb je nog vrij weinig aan je verschillende vermogens.)

Momenteel heeft dat echter niet echt prioriteit, tenzij er meerdere gebruikers zijn die zo'n asymmetrische setup zouden willen gebruiken met de Gielz aansturing. Dan kan ik er eventueel eens een zaterdag aan besteden.

[gielz]

RemmyB83 schreef op donderdag 21 mei 2026 @ 23:19:
[...]

Ja, van die 80 heb ik 50 gemaakt.
Dit zal gielz idd hebben gedaan vanwege efficentie en overmatig schakkelen van het relais. Nu is dit alleen om het laden of ontladen te starten. Het is niet zo dat hij stopt als het vermogen tussen de 2 waardes komt. Bij een 2400 kan ik mijn daar ook best iets bij voorstellen, maar bij onze kleine 800, hou ik liever een iets kleinere bandbreedte aan. Volgens mijn zit de zendure integratie zelf ook op 50 of 60 Watt.

Wel even opletten dat je dit niet te laag instelt. Er zijn een aantal zendure type’s (dacht de 2400ac+ en pro) die niet (altijd) ontwaken onder de 60 watt en zelfs vastlopen. Na een reboot met de knop doen ze het weer.

Zodra ze bezig zijn met laden/ontladen is wel elk vermogen mogelijk. @ZuinigeRijder

Hier een issue met Zendure HA wat geen minimum voorheen had; https://github.com/Zendure/Zendure-HA/pull/1297

[ Voor 5% gewijzigd door gielz op 22-05-2026 07:22 ]

[Eduardo M]

Goedemorgen,

Er lijkt wat fout te gaan bij het ontladen met de Gielz automatisering icm de Gast proxy: bij mijn 2e batterij zakt ie door het ingestelde laadpercentage ondergrens van 10%. In de Zendure app zie ik dat de ondergrens dan is gewijzigd naar 5%, ik vermoed dat dat door de Gielz automatisering is aangepast. Iemand die hier ook last van heeft?

[Devke]

gast777 schreef op vrijdag 22 mei 2026 @ 00:40:
[...]

Inderdaad momenteel wordt het max vermogen simpelweg gelijk verdeeld over alle Zendures. Dit is ook de reden dat het mixen van verschillende modellen Zendures niet aan te raden is (behalve als ze hetzelfde vermogen hebben zoals SF2400AC en SF2400AC+).

Ik heb er zeker wel eens over gedacht om dat instelbaar te maken. En ook om rekening te houden met het totaal aantal kWh batterij capaciteit per device (als dat verschillend is) bij het berekenen van het vermogen van ieder device.

(Maar dan zou de gebruiker het best ook evenredig veel batterijcapaciteit eronder zetten, want anders blijven de SoC niet ongeveer gelijk met de verschillende vermogens. Dan heb je nog vrij weinig aan je verschillende vermogens.)

Momenteel heeft dat echter niet echt prioriteit, tenzij er meerdere gebruikers zijn die zo'n asymmetrische setup zouden willen gebruiken met de Gielz aansturing. Dan kan ik er eventueel eens een zaterdag aan besteden.

Het idee is natuurlijk leuk, tweakers willen overal aan kunnen draaien. 😜 Even hardop denkend, zou je de batterijen dit niet gewoon zelf in zoverre willen laten doen als ze de beste RTE combi zoeken? Nu is dat al een klusje denk ik. Ik denk als je voor efficiëntie kiest ipv zelf regelen dat je meer winst hebt. Tis maar een gedachte kronkel. Het zal wel een lastige klus zijn denk ik. NOM is nooit een flatline en wanneer spring je boven 2400 uit? Laden bij 1400 W is best efficient zie ik hier. Beter dan 2400.

[ Voor 5% gewijzigd door Devke op 22-05-2026 08:36 ]

[hremijn]

oeps schreef op donderdag 21 mei 2026 @ 19:51:
[...]

Er is een open issue bij Zendure dat mqtt stopt al HA herstart wordt, bijvoorbeeld door bijwerken HA. Om het te fixen moet mqtt ff in de Zendure app uit/aanzetten.

Dit kreeg ik van Zendure support op 6 mei:

[...]

Dat snap ik niet. De reden van mijn vraag is dat ik gemerkt heb dat als de API niet reageert na korte uitval van de wifi ik wel data van de zendure via mqtt krijg.

[ZuinigeRijder]

gielz schreef op vrijdag 22 mei 2026 @ 07:13:
[...]


Wel even opletten dat je dit niet te laag instelt. Er zijn een aantal zendure type’s (dacht de 2400ac+ en pro) die niet (altijd) ontwaken onder de 60 watt en zelfs vastlopen. Na een reboot met de knop doen ze het weer.

Ik heb wel een nog niet opgelost probleem gemeld bij Zendure. Zie deze post:

ZuinigeRijder in "Het grote Zendure plug-and-play thuisaccu systemen topic"

Ook heeft maar één Solarflow 800 Plus dit probleem

Ik heb aanvullende informatie. Toen ik de tweede accu "2 Solarflow 800 Plus" uit HEMS verwijderde, functioneerde de defecte "1 Solarflow 800 Plus", die continu schakelde tussen "Standby" en "Bezig met ontladen", weer naar behoren. Batterij "1 Solarflow 800 Plus" schakelt dus NIET over naar de stand-bymodus en houdt het nettoverbruik vrijwel nul.

Het lijkt erop dat dit probleem zich alleen voordoet tot rond de 70 Watt (dus 35 Watt per SF 800+).

In de "Basisbelastingmodus" doet zich het probleem niet voor. Alleen in de "Automatische modus" en "Expertmodus -> Slimme metermodus".
Ik heb dit probleem vanavond meerdere keren waargenomen. Het lijkt erop dat "1 Solarflow 800 Plus" alleen overschakelt naar de standbymodus wanneer er stroom teruggeleverd wordt aan het net en er maximaal 35 watt per batterij (70 watt in totaal) hoeft te worden teruggeleverd. Dan schakelt alleen "1 Solarflow 800 Plus" over naar de standbymodus; "2 Solarflow 800 Plus" blijft ongeveer 35 watt terugleveren. Boven de 70 watt leveren beide apparaten stroom terug aan het net.

Ik vermoed echter sterk dat het probleem zich voordoet bij een ontladingsvermogen van maximaal ongeveer 70 watt met twee accu's. Bij hogere ingangsvermogens heb ik het probleem niet waargenomen.

Nu gebruik ik de @gast777 proxy, dus nu gebeurt het ontladen door maar één batterij. Ben me alleen aan het afvragen of het probleem van één van de twee batterijen een relatie heeft tot het probleem wat tot gevolg had van het 80 Watt minimum.

Dit is trouwens het laatste antwoord van Zendure:

Hallo beste klant,

We hebben uw feedback ontvangen. Op basis van de afbeeldingen die u ons stuurde, hebben we een analyse uitgevoerd. Op 4 mei om 17:00 uur was het normale uitgangsvermogen van één apparaat 22 W, terwijl het andere apparaat in de standbymodus stond. Normaal gesproken zouden beide apparaten tegelijkertijd stroom moeten leveren.

Na nader onderzoek van de protocollen ontdekten we dat het apparaat in stand-bymodus een vermogenslimiet van 0 W had. Dit zou te wijten kunnen zijn aan een probleem met het netsignaal, waardoor de twee apparaten verschillende besturingscommando's ontvingen.

Dit is een klein probleem zonder grote functionele beperkingen. Blijf de apparaten in de gaten houden en neem contact met ons op als u verdere problemen ondervindt.

Hartelijke groeten,
Zendure-team

[ Voor 17% gewijzigd door ZuinigeRijder op 22-05-2026 08:51 ]

[Gramser]

In de Zendure-reclames lees je dat de batterijen 6000 cycles of meer mee gaan. Is ergens inzichtelijk hoeveel cycles de batterijen hebben gedaan..?

[gielz]

Eduardo M schreef op vrijdag 22 mei 2026 @ 08:19:
Goedemorgen,

Er lijkt wat fout te gaan bij het ontladen met de Gielz automatisering icm de Gast proxy: bij mijn 2e batterij zakt ie door het ingestelde laadpercentage ondergrens van 10%. In de Zendure app zie ik dat de ondergrens dan is gewijzigd naar 5%, ik vermoed dat dat door de Gielz automatisering is aangepast. Iemand die hier ook last van heeft?

Wellicht de laatste package recentelijk geinstalleerd? Hier zit het nieuwe instelbare laadpercentage in;

Releasenotes;
Stel na de installatie je minimaal en maximaal toegestane laadpercentage in. Deze waarden worden gesynchroniseerd naar: 5% minimaal en 70% maximaal ⚠️

Nieuwe functies

Mogelijkheid om het minimale en maximale laadpercentage in te stellen
Vanaf nu kun je het minimale en maximale laadpercentage in stellen. Hiervoor is de Zendure app niet meer nodig. De instellingen in Home Assistant zijn altijd leidend en worden direct gesynchroniseerd wanneer de batterij een andere waarde heeft.

[TBird484]

@gast777 Bij het upgraden van de proxy heb ik altijd de NR flow opnieuw geimporteerd, de oude weggegooid en de nieuwe daarna gedeployed. Dat gaat en ging probleemloos. Maar ik wil nu een probleem analyseren en gebruik maken van het dashboard. Binnen flowfuse lijkt het erop dat niet alles wordt opgeruimd en krijg ik de volgende foutmelding.

Wat is de juiste upgrade manier om dit issue te voorkomen ?

[wautah91]

thijsh02 schreef op donderdag 21 mei 2026 @ 22:20:
Klopt het dat bijna alle sensoren van de 2400AC+ zijn uitgeschakeld in de Fireson integratie? De temperatuur sensor van de omvormer kan ik bijvoorbeeld niet inschakelen 🤔 melding: Kan status niet wijzigen. Uitgeschakeld door apparaat

Of beter de Gielz integratie gebruiken? Heb alleen ook een Hyper en die staat niet op het ondersteunende lijstje.

ik heb een Hyper2000 proxy gemaakt voor de gielz integratie. Bij mij werkt het, tot nu toe nog geen feedback ontvangen van anderen, dus als je het wilt proberen zou tof zijn!

twoenter/Zendure-zenSDK-Hyper-proxy: Control your Zendure Hyper2000 with zenSDK in Home Assistant

[Theetjuh]

gast777 schreef op vrijdag 22 mei 2026 @ 00:40:
[...]

Inderdaad momenteel wordt het max vermogen simpelweg gelijk verdeeld over alle Zendures. Dit is ook de reden dat het mixen van verschillende modellen Zendures niet aan te raden is (behalve als ze hetzelfde vermogen hebben zoals SF2400AC en SF2400AC+).

Ik heb er zeker wel eens over gedacht om dat instelbaar te maken. En ook om rekening te houden met het totaal aantal kWh batterij capaciteit per device (als dat verschillend is) bij het berekenen van het vermogen van ieder device.

(Maar dan zou de gebruiker het best ook evenredig veel batterijcapaciteit eronder zetten, want anders blijven de SoC niet ongeveer gelijk met de verschillende vermogens. Dan heb je nog vrij weinig aan je verschillende vermogens.)

Momenteel heeft dat echter niet echt prioriteit, tenzij er meerdere gebruikers zijn die zo'n asymmetrische setup zouden willen gebruiken met de Gielz aansturing. Dan kan ik er eventueel eens een zaterdag aan besteden.

Bedankt dat je er iig al even aandacht aangeeft, ik ga binnenkort m'n electricien even vragen hoeveel het gaat kosten om een aparte groep naar de zolder te trekken, dat zou dan iig het probleem voor mij al oplossen. Maar ik kan me voorstellen dat het zeker wel gewaardeerd wordt zo'n optie.

[abaart]

Theetjuh schreef op vrijdag 22 mei 2026 @ 11:35:
[...]

Bedankt dat je er iig al even aandacht aangeeft, ik ga binnenkort m'n electricien even vragen hoeveel het gaat kosten om een aparte groep naar de zolder te trekken, dat zou dan iig het probleem voor mij al oplossen. Maar ik kan me voorstellen dat het zeker wel gewaardeerd wordt zo'n optie.

Heb even snel codex aan het werk gezet met je vraag. Resultaat staat in deze branch op GitHub.

Als je zin hebt kun je het testen met jouw setup! Moet je alleen wel even handmatig deze branch installeren in je AppDaemon setup, want via HACS is het niet mogelijk om test-branches te installeren.

Ondersteunt t/m 10 Zendures met instelbare power-limit per stuk:

code:

devices:
  - ip: "192.168.1.101"
    charge_max_watts: 600
    discharge_max_watts: 700
  - ip: "192.168.1.102"
    charge_max_watts:
    discharge_max_watts: 500

[Eduardo M]

gielz schreef op vrijdag 22 mei 2026 @ 09:10:
[...]


Wellicht de laatste package recentelijk geinstalleerd? Hier zit het nieuwe instelbare laadpercentage in;

Releasenotes;
Stel na de installatie je minimaal en maximaal toegestane laadpercentage in. Deze waarden worden gesynchroniseerd naar: 5% minimaal en 70% maximaal ⚠️

Nieuwe functies

Mogelijkheid om het minimale en maximale laadpercentage in te stellen
Vanaf nu kun je het minimale en maximale laadpercentage in stellen. Hiervoor is de Zendure app niet meer nodig. De instellingen in Home Assistant zijn altijd leidend en worden direct gesynchroniseerd wanneer de batterij een andere waarde heeft.

Ik heb inderdaad het laatste package. Na installatie hiervan het minimale/maximale laadpercentage in HA ingesteld op 10%/100%. Bij ontladen wordt het minimale percentage voor de batterij 1 gerespecteerd en stopt deze met ontladen. Echter voor batterij 2 stopt deze niet op 10% en zie ik in de zendure app dat het minimale laadpercentage gewijzigd is naar 5% het ontladen voor deze batterij loopt dus door naar 5%.

[gielz]

Eduardo M schreef op vrijdag 22 mei 2026 @ 13:51:
[...]

Ik heb inderdaad het laatste package. Na installatie hiervan het minimale/maximale laadpercentage in HA ingesteld op 10%/100%. Bij ontladen wordt het minimale percentage voor de batterij 1 gerespecteerd en stopt deze met ontladen. Echter voor batterij 2 stopt deze niet op 10% en zie ik in de zendure app dat het minimale laadpercentage gewijzigd is naar 5% het ontladen voor deze batterij loopt dus door naar 5%.

Ik zou hiervoor even een issue inschieten bij de proxy github. Want hij synchroniseert constant dus wellicht pakt deze sensor in de proxy de hoogste waarde van de 2 en niet de laagste?

[ppaulv]

ctrl-tab schreef op donderdag 21 mei 2026 @ 23:14:
[...]


Hehe wel ik snap de gedachtengang wel. Maar uiteindelijk is opslag van energie uit je zonnepanelen inkomstenderving. Straks wordt het interessanter, dan gaan de negatieve prijs momenten aanzienlijk toenemen. Dan is het geen inkomstenderving maar een verzekering tegen het betalen van boetes.
En moet je de 'gratis' stroom gaan knijpen (power limit op je panelen knijpen zodat je niks terug levert) Daarom wel fijn als je capaciteit en vermogen van je batterij genoeg is om je panelen voor een uur of 3 volledig (minus basislast) op te slurpen.

ehh .. nee .... als de prijs (voldoende) negatief is, is het beter qua euro's om je panelen volledig uit te schakelen en je accu vol te gooien met stroom uit het net waar je dan ook nog eens voor betaald wordt.
Het is juist inkomstenderving als je in die situatie je panelen gebruikt om je accu te laden.

Alleen in het schemergebiedje waar de kale prijs negatief is maar niet negatief genoeg om de te maken kosten (belastingen en leverancierskosten) goed te maken, dan zou je in het ideale geval wèl je panelen willen gebruiken om je accu te laden maar niets willen terugleveren in het grid. Leveren aan het grid kost dan een beetje en gebruiken uit het grid ook.
Uiteindelijk hebben we het dan over een paar centen per kWh dus of dat nou zoveel moeite waard is... ? En ja, in een recent verleden heb ik daar veel energie in gestoken maar achteraf gezien had ik beter iets anders kunnen gaan doen. Op het leuke leereffect na.

[ Voor 24% gewijzigd door ppaulv op 22-05-2026 14:51 ]

[Mimiix]

ppaulv schreef op vrijdag 22 mei 2026 @ 14:46:
[...]

ehh .. nee .... als de prijs (voldoende) negatief is, is het beter qua euro's om je panelen volledig uit te schakelen en je accu vol te gooien met stroom uit het net waar je dan ook nog eens voor betaald wordt.
Het is juist inkomstenderving als je in die situatie je panelen gebruikt om je accu te laden.

Alleen in het schemergebiedje waar de kale prijs negatief is maar niet negatief genoeg om de te maken kosten (belastingen en leverancierskosten) goed te maken, dan zou je in het ideale geval wèl je panelen willen gebruiken om je accu te laden maar niets willen terugleveren in het grid. Leveren aan het grid kost dan een beetje en gebruiken uit het grid ook.
Uiteindelijk hebben we het dan over een paar centen per kWh dus of dat nou zoveel moeite waard is... ? En ja, in een recent verleden heb ik daar veel energie in gestoken maar achteraf gezien had ik beter iets anders kunnen gaan doen. Op het leuke leereffect na.

En als het om panelen gaat die direct aan de accu zitten? SF2400pro?

Dan heb je namelijk amper verlies

[ppaulv]

Mimiix schreef op vrijdag 22 mei 2026 @ 15:24:
[...]

En als het om panelen gaat die direct aan de accu zitten? SF2400pro?

Dan heb je namelijk amper verlies

Het gaat niet om verlies of geen verlies, dat is een extra factor die ik even niet meegnomen heb in m'n verhaal, het gaat om de prijs die je moet betalen als je iets uit het grid trekt danwel iets in het grid stopt.
Geen idee hoe dat werkt maar ik neem aan (!) dat al die stroom ook direct in het grid gestopt kan worden zonder de accu op te laden?

[Bakkert]

Ik heb de Gielz integratie net een tijdje draaien op mijn 2400 pro. Ben nog lerende in HA, met vallen en opstaan begin ik het een heel klein beetje te begrijpen denk ik, maar een ding waar ik niet achter kom.

Via de configuratie laadpercentage krijg ik de waarden niet aangepast. API blijft op de oude waarden staan die ik ooit in de app ingesteld heb. Configuratie van bijvoorbeeld max. ontladen en max. opladen kan ik wel aanpassen. Iemand een idee waar dit door dan komen?

[gielz]

Bakkert schreef op vrijdag 22 mei 2026 @ 16:11:
Ik heb de Gielz integratie net een tijdje draaien op mijn 2400 pro. Ben nog lerende in HA, met vallen en opstaan begin ik het een heel klein beetje te begrijpen denk ik, maar een ding waar ik niet achter kom.

Via de configuratie laadpercentage krijg ik de waarden niet aangepast. API blijft op de oude waarden staan die ik ooit in de app ingesteld heb. Configuratie van bijvoorbeeld max. ontladen en max. opladen kan ik wel aanpassen. Iemand een idee waar dit door dan komen?

[Afbeelding]

Kun je even je volledige configuratie tabblad posten?

[Gramser]

@Bakkert HEMS staat wel uit toch?

[Bakkert]

gielz schreef op vrijdag 22 mei 2026 @ 16:15:
[...]


Kun je even je volledige configuratie tabblad posten?

Nog vergeten te melden, het is de laatste versie van je integratie.
Echt super mooi werk!
En HEMS staat uit inderdaad.

[ Voor 10% gewijzigd door Bakkert op 22-05-2026 16:24 ]

[gielz]

Bakkert schreef op vrijdag 22 mei 2026 @ 16:21:
[...]


Nog vergeten te melden, het is de laatste versie van je integratie.
Echt super mooi werk!
En HEMS staat uit inderdaad.

[Afbeelding]

Het rode kruis zegt het al. Of je heb geen automatisering actief staan of een oude versie van de automatisering. Ook (kan het mis hebben) heb je bij de dynamisch nordpool sensor na sensor. een spatie staan.

Je leest dus nu eigenlijk alleen uit.

[Bakkert]

gielz schreef op vrijdag 22 mei 2026 @ 16:27:
[...]


Het rode kruis zegt het al. Of je heb geen automatisering actief staan of een oude versie van de automatisering. Ook (kan het mis hebben) heb je bij de dynamisch nordpool sensor na sensor. een spatie staan.

Je leest dus nu eigenlijk alleen uit.

Dank! Sinds de update heb ik inderdaad dat kruis maar de NOM draait wel door. Ga ik kijken wat ik anders had moeten doen, vallen en opstaan
En heel scherp van de nordpool! Was ik vanmiddag mee bezig maar kreeg nog geen data

[oeps]

hremijn schreef op vrijdag 22 mei 2026 @ 08:36:
[...]

Dat snap ik niet. De reden van mijn vraag is dat ik gemerkt heb dat als de API niet reageert na korte uitval van de wifi ik wel data van de zendure via mqtt krijg.

Mijn opmerking is niet echt een antwoord op je vraag. Meer dat mqtt op dit moment ook andere issues heeft. Of het bij iedereen bij elke start een issue geeft, geen idee. Bij mij kon ik het reproduceren en zowel de batterij (2400 Pro) als de Zendure P1 konden hun data niet kwijt.
Is wel heel vreemd, maar mogelijk wil de batterij/P1 de oude sessie blijven gebruiken en heeft niet door dat die weg was. Klinkt als een niet handige Zendure mqtt implementatie.

Fun fact: door de grote broer van mqtt, MQ van IBM gingen vele jaren lang de meeste financiële transacties ter wereld heen (mainframe wereld van vroegah). Ben zeker geen mqtt specialist, dat waren collega’s van me.

[Mimiix]

ppaulv schreef op vrijdag 22 mei 2026 @ 16:01:
[...]

Het gaat niet om verlies of geen verlies, dat is een extra factor die ik even niet meegnomen heb in m'n verhaal, het gaat om de prijs die je moet betalen als je iets uit het grid trekt danwel iets in het grid stopt.
Geen idee hoe dat werkt maar ik neem aan (!) dat al die stroom ook direct in het grid gestopt kan worden zonder de accu op te laden?

Neem, in principe niet. Alleen als ie vol is of leeg is ben ik achter.

[ctrl-tab]

ppaulv schreef op vrijdag 22 mei 2026 @ 14:46:
[...]

ehh .. nee .... als de prijs (voldoende) negatief is, is het beter qua euro's om je panelen volledig uit te schakelen en je accu vol te gooien met stroom uit het net waar je dan ook nog eens voor betaald wordt.
Het is juist inkomstenderving als je in die situatie je panelen gebruikt om je accu te laden.

Alleen in het schemergebiedje waar de kale prijs negatief is maar niet negatief genoeg om de te maken kosten (belastingen en leverancierskosten) goed te maken, dan zou je in het ideale geval wèl je panelen willen gebruiken om je accu te laden maar niets willen terugleveren in het grid. Leveren aan het grid kost dan een beetje en gebruiken uit het grid ook.
Uiteindelijk hebben we het dan over een paar centen per kWh dus of dat nou zoveel moeite waard is... ? En ja, in een recent verleden heb ik daar veel energie in gestoken maar achteraf gezien had ik beter iets anders kunnen gaan doen. Op het leuke leereffect na.

Dan moet inkoop ook negatief zijn. Ik doel op het feit dat er meer negatieve teruglever momenten komen.

[ppaulv]

ctrl-tab schreef op vrijdag 22 mei 2026 @ 20:03:
[...]


Dan moet inkoop ook negatief zijn. Ik doel op het feit dat er meer negatieve teruglever momenten komen.

Je bedoelt de komende zomermaanden? Ja dat zeker. De komende jaren ..... hang er vanaf. Als het gebruik van accu's enorm gaat toenemen (zou zomaar kunnen in een land waar we nogal 'zunig' zijn), inclusief het gebruik van auto's als nivellerend middel (zie ik helemaal zitten), zouden de grote pieken zomaar wat minder kunnen worden in de toekomst. Maar dat gaan we vanzelf meemaken
En dan zou het best kunnen dat een deel van de huidige automatisering gewoon niet meer nodig is / handel via de accu te weinig gaat opleveren.

[ Voor 10% gewijzigd door ppaulv op 22-05-2026 20:58 ]

[ctrl-tab]

ppaulv schreef op vrijdag 22 mei 2026 @ 20:56:
[...]

Je bedoelt de komende zomermaanden? Ja dat zeker. De komende jaren ..... hang er vanaf. Als het gebruik van accu's enorm gaat toenemen (zou zomaar kunnen in een land waar we nogal 'zunig' zijn), inclusief het gebruik van auto's als nivellerend middel (zie ik helemaal zitten), zouden de grote pieken zomaar wat minder kunnen worden in de toekomst. Maar dat gaan we vanzelf meemaken
En dan zou het best kunnen dat een deel van de huidige automatisering gewoon niet meer nodig is / handel via de accu te weinig gaat opleveren.

Nee ik doel op einde saldering. Waarna je ook met een dynamisch contract enkel marktprijs met eventueel opslag terug krijg,.zonder btw en energiebelasting.
Morgen zou die prijs voor zonneplan naar -0,015 (verkoop) cent duiken om 13:00, terwijl dat nu nog 0,096 cent is (inkoop/verkoop).

[hemertje]

@gast777

Monitor resultaten Node-RED proxy — 16 t/m 22 mei

Ik laat sinds 16 mei een scriptje draaien op mijn MacBook dat elke 30 seconden twee dingen meet: hoe snel de drie Zendures zelf reageren op een ping, én hoe snel de Node-RED proxy antwoordt. In totaal zijn dat bijna 6.900 metingen over zeven dagen.

Wat komt eruit?

Dag	Metingen	OK (<100ms)	Traag (100ms–5s)	Timeout (>5s)
16 mei	588	519 (88%)	56	13
17 mei	1091	970 (89%)	119	2
18 mei ← proxy update	1469	1393 (95%)	76	0
19 mei	799	652 (82%)	142	5
20 mei	769	609 (79%)	153	7
21 mei	829	680 (82%)	143	6
22 mei	1359	1195 (88%)	160	4

De proxy update van 18 mei heeft duidelijk geholpen: dat was de beste dag met 95% snelle responses en voor het eerst nul harde timeouts. Daarna kruipt het aantal trage responses (tussen 100ms en 5 seconden) langzaam weer omhoog naar zo'n 140–160 per dag. De harde timeouts blijven wel laag op 4–7 per dag.

Wat betreft de Zendures zelf: die reageren bij elke meting gewoon netjes op 5 tot 15 milliseconde, ook op het moment dat de proxy vastloopt. Het probleem zit dus echt in de proxy en niet in het netwerk of de apparaten.

Alle harde timeouts duren precies 5,0 seconden — dat is de grens die ik in mijn meetscript heb ingesteld. De proxy geeft dan geen foutmelding, hij reageert gewoon helemaal niet. Geen TCP-fout, de verbinding blijft gewoon open hangen totdat ik hem afbreek.

Mijn vermoeden is dat Node.js af en toe even vastloopt met iets anders — garbage collection of een zware berekening — waardoor binnenkomende verzoeken in de wacht worden gezet. Niet lang genoeg voor een complete crash, maar genoeg om een poll te missen. Ik ga nog kijken of de trage momenten samenvallen met actieve laadcycli, want dan komen er meer commando's tegelijk richting de Zendures.

Monitor draait verder.

[hemertje]

DrNickB schreef op zondag 17 mei 2026 @ 10:09:
[...]

Kan het zijn dat ik in je code, wat daadwerkelijke acties mis naar de zendure toe? of lees ik er zwaar over heen.

Zelf gebruik ik de zelfde structuur, echter in uw code (met gebruikers) kun je de aan/uit waardes zo in stellen dat hij nooit aan gaat of nooit uit gaat

@DrNickB

Goede vragen, even punt voor punt:

Acties naar de Zendure
Die zitten er wel in, maar indirect — de switch.zendure_x_offgrid_socket is de offgrid socket van de Zendure zelf, aangestuurd via de Gielz/gast777 integratie. De ventilator hangt aan die socket, dus switch.turn_on op die entity is de actie naar de Zendure. Er is geen directe API-call nodig, de integratie doet dat onder de motorkap.

Nooit aan / nooit uit door verkeerde thresholds
Hier heb je een punt. Er zit geen validatie in die voorkomt dat je temp_on lager instelt dan temp_off. Als je dat doet — zeg temp_on 30°C en temp_off 35°C — gaat de fan aan zodra de temperatuur boven de 30 komt, maar de UIT-trigger vuurt meteen ook want de temp is al onder de 35. Je krijgt dan een oscillatie of de fan gaat direct weer uit. Omgekeerd, temp_on 40 en temp_off 40, en hij gaat nooit uit want below 40 triggert nooit als hij op 40 staat.

Ik had daar een condition op kunnen zetten die checkt of temp_on daadwerkelijk hoger is dan temp_off voor de automation vuurt, maar dat heb ik weggelaten om de code simpel te houden.

Goede aanvulling — hoe los jij dat in jouw versie op?

[ctrl-tab]

Vreemd fenomeen, available energy dropte gisteren plots ( als gevolg hiervan stopte mijn discharge, ik heb hier een trigger op)

Zeer waarschijnlijk gevolg van gemiste get requests. Kan dit kloppen/is dit gewenst gedrag?
Laatste gielz + proxy, 2x 2400 ac.

[ctrl-tab]

ctrl-tab schreef op vrijdag 22 mei 2026 @ 21:03:
[...]


Nee ik doel op einde saldering. Waarna je ook met een dynamisch contract enkel marktprijs met eventueel opslag terug krijg,.zonder btw en energiebelasting.
Morgen zou die prijs voor zonneplan naar -0,015 (verkoop) cent duiken om 13:00, terwijl dat nu nog 0,096 cent is (inkoop/verkoop).

Ter illustratie .

2026 inkoop/verkoop: 0.096/0.096

2027 inkoop/verkoop: 0.096/-0.015

[gielz]

ctrl-tab schreef op zaterdag 23 mei 2026 @ 05:38:
Vreemd fenomeen, available energy dropte gisteren plots ( als gevolg hiervan stopte mijn discharge, ik heb hier een trigger op)

Zeer waarschijnlijk gevolg van gemiste get requests. Kan dit kloppen/is dit gewenst gedrag?
Laatste gielz + proxy, 2x 2400 ac.[Afbeelding]

[Afbeelding]

Een gemiste get/post is altijd mogelijk en zo te zien zeer minimaal bij jou.

Ik zou iig dat soort automation triggers aanpassen naar “veranderd voor xx seconden”. Dan zal je automation niet direct triggeren.

[ctrl-tab]

gielz schreef op zaterdag 23 mei 2026 @ 06:19:
[...]


Een gemiste get/post is altijd mogelijk en zo te zien zeer minimaal bij jou.

Ik zou iig dat soort automation triggers aanpassen naar “veranderd voor xx seconden”. Dan zal je automation niet direct triggeren.

Thanks, dit heb ik ook gedaan.

Enige dat ik me afvraag is, zou de counter inderdaad naar 0 moeten gaan in zo'n geval? Lijkt me geen correcte afhandeling - if so ?

[Henkoes]

zou de batterij voltage health voor alle batterijen beschikbaar kunnen komen? Ipv alleen voor de 6?

[remcoXP]

ik zie nu dat de spread indicatie heeft historie heeft en op 0 staat. hebben jullie daar ook last van?

sorry

[ Voor 7% gewijzigd door remcoXP op 23-05-2026 10:07 ]

[gast777]

TBird484 schreef op vrijdag 22 mei 2026 @ 11:08:
@gast777 Bij het upgraden van de proxy heb ik altijd de NR flow opnieuw geimporteerd, de oude weggegooid en de nieuwe daarna gedeployed. Dat gaat en ging probleemloos. Maar ik wil nu een probleem analyseren en gebruik maken van het dashboard. Binnen flowfuse lijkt het erop dat niet alles wordt opgeruimd en krijg ik de volgende foutmelding.

[Afbeelding] Wat is de juiste upgrade manier om dit issue te voorkomen ?

Goede vraag. Dit is inderdaad nog even een dingetje, vanwege hoe het Dashboard 2 werkt.

Dit zijn de stappen bij upgraden om dit 100% goed te krijgen:

1) Zet je Gielz op modus Standby.

2) delete de oude proxy flow

3) Ga naar Config Nodes (het tandwieltje). Daar zie je een aantal grijze nodes.




4) Delete al deze grijze nodes. Dubbel-click daarvoor op al deze grijze nodes en kies Delete.



5) Click op 'Deploy'

6) Importeer je nieuwe proxy flow

7) Zet je IP adressen weer in de flow node "Vul hier de Zendure IP adressen in".

8) Click op 'Deploy'

[ Voor 3% gewijzigd door gast777 op 23-05-2026 15:40 ]

[ppaulv]

ctrl-tab schreef op zaterdag 23 mei 2026 @ 05:56:
[...]

Ter illustratie .

2026 inkoop/verkoop: 0.096/0.096

2027 inkoop/verkoop: 0.096/-0.015

[Afbeelding]

[Afbeelding]

Ehhh ... dan wellicht even voor de heel erg blonde mensen hier (ikzelf iig, blijkbaar heb ik ergens iets gemist) : als ik nu al een dynamisch contract zou hebben (heb ik niet) is toch nu ook al
de inkoopprijs = marktprijs + belasting + leveranciersvergoeding (dit betaal je)
en verkoopprijs = - marktprijs + belasting + leveranciersvergoeding (dit krijg je)?
Dus belasting en leveranciersvergoeding betaal je altijd, alleen de marktprijs krijg je of betaal je.
Wat heb ik hier verkeerd begrepen ?