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.