Zendure producten in Home Assistant integreren deel 2

[Mimiix]

V-8 schreef op donderdag 3 september 2026 @ 14:47:
[...]

Welke variabele bedoel je dan precies in de Zendure app?

Bij de batterij instellingen van je apparaat, daar kun je de laadlimieten instellen.

Kun je die wel onder de 70% instellen?

[manusjevanalles]

Mimiix schreef op donderdag 3 september 2026 @ 14:57:
[...]

Bij de batterij instellingen van je apparaat, daar kun je de laadlimieten instellen.

Kun je die wel onder de 70% instellen?

In de app van Zendure worden dezelfde limieten qua laad% aangehouden helaas. Ook 50-70%.

[V-8]

Mimiix schreef op donderdag 3 september 2026 @ 14:57:
[...]

Bij de batterij instellingen van je apparaat, daar kun je de laadlimieten instellen.

Kun je die wel onder de 70% instellen?

Ah zo, nee helaas, zoals hierboven vermeld kan die idd ook niet onder de 70. Toch bedankt!

[Mimiix]

manusjevanalles schreef op donderdag 3 september 2026 @ 15:02:
[...]


In de app van Zendure worden dezelfde limieten qua laad% aangehouden helaas. Ook 50-70%.

Dan zit het limiet helaas in de 800.

Ik kan het namelijk wel op de SF2400Pro. Bijzonder dat dit dus ook verschilt tussen de series.

[MrAngry]

Wat hebben jullie aan automatiseringen bovenop Gielz draaien? Ik draai 3*SF800+ naar tevredenheid, maar ik ben wel elke dag even de goedkope en dure uren aan het micromanagen en bij veel goedkope uren ook het maximale laadvermogen zodat hij precies aan het einde van de goedkope periode vol is en eventueel aanwezig PV stroom dan pas het net op gaat. Soms micromanage ik ook het minimal soc percentage om te voorkomen dat ie bij het verkopen in de avond zoveel terugleverd dat ik de nacht niet overbrug met nul op de meter of als de stroom de volgende dag duurder is dan pas ik de strategie aan zodat hij vandaag niet verkoopt in de avond.

Anyway, ik wil er eigenlijk niet teveel naar omkijken, het is een hoop geklooi voor een paar centen, maar ik vind het lastig om het los te laten. Dus eigenlijk wil ik er meer bovenop automatiseren, maar ik weet even niet waar ik moet beginnen met zoeken. Het klinkt eigenlijk als de belofte van zenki AI, maar ik heb HA nodig voor de P1 meter.

[John2B]

xenobia12345 schreef op donderdag 31 juli 2025 @ 18:41:
Inmiddels met behulp van Home Assistant en de config + automation van Gielz de boel draaiend. Wel heb ik een andere P1 meter in mijn setup, de ongetwijfeld bekende "Slimmelezer" van Marcel Zuidwijk. Ook heb ik op elke Zendure een Shelly Plug S Gen3 zitten. Dus op enkele punten wijk ik af van de hardware welke Gielz heeft opgenomen in zijn beschrijving.

Laat maar, inmiddels opgelost ;-)

[ Voor 34% gewijzigd door John2B op 03-09-2026 20:28 ]

[meesje]

Zijn er tweakers die gebruik maken van de officiële Zendure-HA integratie (dus niet gielz)? Deze integratie heb ik namelijk toegepast. Ik zou echter (net als bij gielz) een mooi kant en klaar dashboard willen hebben. Ik kijk nu constant naar de waarden van alle entiteiten.

Is er ook standaard dashboard beschikbaar voor de Zendure-HA integratie?

[Pakhaas]

MrAngry schreef op donderdag 3 september 2026 @ 15:13:
Wat hebben jullie aan automatiseringen bovenop Gielz draaien? Ik draai 3*SF800+ naar tevredenheid, maar ik ben wel elke dag even de goedkope en dure uren aan het micromanagen en bij veel goedkope uren ook het maximale laadvermogen zodat hij precies aan het einde van de goedkope periode vol is en eventueel aanwezig PV stroom dan pas het net op gaat. Soms micromanage ik ook het minimal soc percentage om te voorkomen dat ie bij het verkopen in de avond zoveel terugleverd dat ik de nacht niet overbrug met nul op de meter of als de stroom de volgende dag duurder is dan pas ik de strategie aan zodat hij vandaag niet verkoopt in de avond.

Anyway, ik wil er eigenlijk niet teveel naar omkijken, het is een hoop geklooi voor een paar centen, maar ik vind het lastig om het los te laten. Dus eigenlijk wil ik er meer bovenop automatiseren, maar ik weet even niet waar ik moet beginnen met zoeken. Het klinkt eigenlijk als de belofte van zenki AI, maar ik heb HA nodig voor de P1 meter.

Herkenbaar.

Die laatste 4 maanden overleef ik wel. Ik vind een automatisering voor einde salderen interessanter. Dat je bijvoorbeeld aangeeft dat nachts de auto wel/niet moet laden en daarop gebaseerd wordt of hij bij dure uren moet ontladen tot er bijv nog x.x kwh in de batterij zit voor het huis. Ook bij batterij ontladen in de auto x.x kwh overlaten voor huisverbruik. Ik heb ook solcast die vrij goed inschat hoeveel pv er morgen wordt opgewekt. Dit kan daar ook in mee.

[John2B]

Mkuijper schreef op vrijdag 28 augustus 2026 @ 13:25:
Beste allen,

Ik zit al een tijd door het dit topic heen te bladeren en zie wel een aantal vragen voorbij komen wat enigszins het zelfde is als mijne maar niet echt antwoorden.

Mijn setup is als volgt,

• Zendure solarflow 4000 mix AC+.
• Zonnepanelen met Ephase micro omvormers +- 3kw.
• Ephase metered gateway voor nul op de meter.
• Gielz koppeling zedure sdk op home assistant (om van de trage cloudkoppeling met zendure p1 af te zijn).
• Weinig tot geen ervaring met home assistant verder.

Ik zit met het volgende probleem, panelen staan op nul op de meter omdat de accu vol is. Vermogen wordt gevraagd, panelen schakelen op maar traag, dus accu springt bij. Dit is de "nieuwe" 0w norm. Panelen blijven geknepen maar accu blijft ontladen.

Oplossing volgens AI:

Het Probleem

Als Enphase in nul-op-de-meter (Zero Export) modus staat, knijpt hij zichzelf af. Je kunt aan de Enphase-data dus niet zien hoeveel zonkracht er écht beschikbaar is. Als er een zwaar apparaat aangaat, weet de accu niet of Enphase nog kán opschalen of al aan zijn tax zit.

De Oplossing: Tijdgestuurde Prioritering (Zon Eerst)

We sturen de Zendure-accu aan puur op basis van de P1-meter, maar we gebruiken de reactiesnelheid van Enphase als filter. We dwingen de accu om te wachten, zodat Enphase altijd de eerste kans krijgt om het probleem op te lossen.

1. Bij stroomvraag (Apparaat aan):
   • De P1-meter schiet omhoog.
   • De Zendure-accu krijgt een wachttijd van 15 seconden.
   • Binnen die 15 seconden schaalt Enphase op. Kan Enphase de vraag aan? Dan zakt de P1-meter weer naar 0W en doet de accu niks.
   • Kan Enphase het niet aan? Dan is de P1-meter na 15 seconden nog steeds positief. De accu 'weet' nu dat Enphase maximaal draait en springt direct bij voor het restant.
2. Bij lagere stroomvraag (Apparaat uit, rest blijft aan):
   • Zodra er een apparaat uitschakelt, ontstaat er door de levering van de accu direct een overschot op de P1-meter (stroom zakt direct naar/onder de 0W).
   • De accu reageert nu zonder vertraging (0 seconden) en zet zijn ontlaadvermogen direct op 0W.
   • Enphase ziet dat de accu stopt, ziet de resterende stroomvraag in huis, en blijft onverstoord op zijn maximale capaciteit produceren.

Het Resultaat

Er is geen Enphase-data over de zonsterkte nodig. Door de accu 15 seconden te laten wachten bij inschakelen, en direct te laten stoppen bij uitschakelen, krijgt zonne-energie altijd automatisch voorrang en is de onderlinge strijd volledig opgelost.

Heeft iemand hier al een oplossing voor? of zou dit bij de gielz koppeling in gebouwd kunnen worden? Edit: nul op de meter via enphase zou vanaf 80% acculading weer uit kunnen om weer bij te laden.

Die 15 seconden vertraging zou mooi zijn, echter 's nachts reageert de accu dus te traag. Daar zou je dan iets als zon op en zon onder inbouwen om dat te ondervangen, zo dat 's nachts de 15 seconden naar een lager getal zou kunnen.

[ppaulv]

John2B schreef op donderdag 3 september 2026 @ 16:09:
[...]

Die 15 seconden vertraging zou mooi zijn, echter 's nachts reageert de accu dus te traag. Daar zou je dan iets als zon op en zon onder inbouwen om dat te ondervangen, zo dat 's nachts de 15 seconden naar een lager getal zou kunnen.

Hoe vaak krijg je van Enphase data betreffende de productie van stroom? Kun je daarmee spelen? Een stukje logica maken dat getriggerd wordt door een verandering van 'state' van die Enphase data (als voorbeeld : je krijgt iedere 5 sec data). Als je dan 3 generaties historie (totaal stroom verbruik, Enphase productie, accu productie/verbruik) bijhoudt weet je wat de p1 waarde voor totaal stroomverbruik is 'nu' en 15 sec geleden en als die binnen een acceptabele bandbreedte zitten wel of niet de accu aansturen. Zoiets?
Maar ik heb een vermoeden dat dit simpeler moet kunnen ....

[Keida]

Krisp schreef op maandag 31 augustus 2026 @ 21:21:
[...]

Kun je toelichten/delen hoe je dit gedaan hebt? Ben erg benieuwd.

In de laatste versie kan EVCC ook de 800 Pro automatisch aansturen. Dat het kan lijkt mij een foutje, want de setting past alleen aan dat de batterij in de Flash/RAM modus draait, en als hij snel moet opladen. Oftewel: als de batterij NOM zou moeten draaien werkt het niet. Dat neemt niet weg dat dit nog wat betere uitgangspunten biedt om te optimaliseren.... ware het niet dat de optimizer in EVCC helemaal niet functioneel is, alleen als test.

Ik zoek daarom een manier om het helemaal te automatiseren, want nu pas ik dagelijks die getallen aan en dat vind ik niet echt zinvol.

Het gaat te ver om alle details te noemen, want dat is specifiek voor mijn situatie. En het zijn echt honderden regels code.

Je moet denk ik een aantal voorwaarden opstellen en dan met een AI agent aan de gang gaan.

Bijv:

- hoeveel is je zonnecel productie? kun je dat voorspellen? Ik doe dat met zelfde voorspeller als in EVCC

- hoeveel kwh heeft je EV nodig, en welke dag. Is er een plan actief? in HA kun je dat plan ook querien en gebruiken voor voorspellling

- wil je verdienen/kosten besparen of alleen NOM

En als je zo bezig gaat kom je van alles tegen wat wel en niet werkt

Ik gebruik uiteindelijk Gielz met de proxy - en dus EVCC voor EV laden. Auto gaat meestal voor op batterij. Geen laden van EV uit batterij. Maar als de spread hoog genoeg is dan laadt ik goedkoop accus op en verkoop wanneer duur. Die kwartieren worden dynamisch bepaald door de vraag van het huis en hoeveel er over moet blijven bijvoorbeeld voor de nacht (heeft geen zin om duur te verkopen en duur in te kopen...)

zo maar een voorbeeldje.

[maertenr]

MP3-Junky schreef op woensdag 2 september 2026 @ 21:23:
[...]

Dit probleem heb ik ook met de @gast777 proxy.

Zie mijn bericht een paar posts terug.

Hier hetzelfde probleem
Heb net alles geinstalleerd (Gielz en Nod-red) voor mijn 3x 800 Plus. Hij begon net met 400W ontladen vanuit 1 batterij, maar splitst het nu al een tijdje over 2 batterijen. Iemand een idee misschien?

[..Christiaan..]

Vanaf welk prijsverschil tussen goedkoop en duur gaan jullie laden. Vandaag is prijsverschil (zonneplan) zo'n 50% en mijn laadgrens is 60% (puur op aanname). Nu gaat de batterij vandaag niet laden; hooguit op een paar zonnestralen. Mijn rte is zo'n 87% (Zendure 2400 ac+)

[meesje]

Na een eerste opgedaan te hebben met de officiële Zendure integratie, ben ik vandaag toch overgegaan naar de gielz/gast777 Zendure integratie, inclusief het dashboard. Voor het gemak maar eerst alle instellingsadviezen overgenomen. Het enige wat ik nog moet doen is de extra attributen vanuit gast777 toevoegen aan de gielz configuration yaml. En natuurlijk een keer aan de slag met automations. Nu heb ik 'm op Nul op de meter ingesteld.

Op dit moment heb ik 1 kleine vraag/opmerking m.b.t. het dashboard, tandwiel tabblad. Bij mij wordt linksboven niet een afbeelding van de Zendure batterij getoond. Ik zie dan onderstaande. Kan ik hierin nog wat aanpassen? Ik maak overigens gebruik van de nabu casa cloud. Ik kan het nu niet test, maar werkt de afbeelding misschien wel als ik HA benader vanaf mijn eigen netwerk?

[ Voor 6% gewijzigd door meesje op 04-09-2026 10:31 ]

[Gramser]

Heb je de automatisering wel aangezet?

[meesje]

Gramser schreef op vrijdag 4 september 2026 @ 10:42:
Heb je de automatisering wel aangezet?

Zucht..... daar kwam ik net ook achter.

Ik zag nu ook dat ie net met 1200w even ging laden, vanwege de SOC bescherming.

[ Voor 17% gewijzigd door meesje op 04-09-2026 10:55 ]

[Bart_Denon]

V-8 schreef op donderdag 3 september 2026 @ 12:22:
Nu een ander probleem: de Zendure staat op Standby, ik wil immers dat de nu opgewekte zonnestroom teruggeleverd ipv opgeslagen wordt (prijzen zijn straks lager dan nu).
Echter laadt hij de batterij op met de opgewekte zonnestroom ipv te bypassen...

Iemand een idee?

Ja ik zie dit gedrag ook bij mij SF800+. Deze gaat pas bij 100% SOC over op backflow.
Ik zat hier over na te denken en je wilt eigenlijk een forced backflow die niet SOC afhankelijk is.
Volgens kun je t wel omzeilen, alleen moet je dan zo aansturen dat alle opwek naar batterij (outputpackpower) direct weer 1:1 als output naar de woning gaat. Dus geforceerd ontladen als er opwek is. Dit moet je dan handmatig automatiseren.
Daarnaast blijft de interne flow altijd nog solar in > batterij laad > batterij ontlaad > ac out.
Het echt bypassen, doet ie alleen op 100% SOC wat ook logisch is want verder doorladen kan natuurlijk niet meer.

[avdwerf]

MrAngry schreef op donderdag 3 september 2026 @ 15:13:
Wat hebben jullie aan automatiseringen bovenop Gielz draaien? Ik draai 3*SF800+ naar tevredenheid, maar ik ben wel elke dag even de goedkope en dure uren aan het micromanagen en bij veel goedkope uren ook het maximale laadvermogen zodat hij precies aan het einde van de goedkope periode vol is en eventueel aanwezig PV stroom dan pas het net op gaat. Soms micromanage ik ook het minimal soc percentage om te voorkomen dat ie bij het verkopen in de avond zoveel terugleverd dat ik de nacht niet overbrug met nul op de meter of als de stroom de volgende dag duurder is dan pas ik de strategie aan zodat hij vandaag niet verkoopt in de avond.

Anyway, ik wil er eigenlijk niet teveel naar omkijken, het is een hoop geklooi voor een paar centen, maar ik vind het lastig om het los te laten. Dus eigenlijk wil ik er meer bovenop automatiseren, maar ik weet even niet waar ik moet beginnen met zoeken. Het klinkt eigenlijk als de belofte van zenki AI, maar ik heb HA nodig voor de P1 meter.

Misschien leuk om eens naar Claude te gaan kijken die via MCP met je Home Assistant communiceert. Heb nu een scheduled task in Claude die elke avond alles checkt voor de dag erop en op basis daarvan goedkope en dure uren vult. Claude weet de stroomprijzen, de huidige staat van de accu, heb een zonopbrengstvoorspelling in HA en claude weet ongeveer mijn dagelijks standaard verbruik. Daar laat ik hem dan elke avond wat van maken, dat komt altijd wel in de buurt met wat ik wil. Als ik het dan een keer vergeet te checken is het niet erg. Ben nog aan het finetunen, wil ook gaan maken nog dat hij rekening houdt met de accustaat van de auto's enzo maar dat moet nog gemaakt gaan worden.

[meesje]

De afgelopen dagen/week best veel gespeeld met Home Assistant i.c.m. Zendure integraties. Dit heeft uiteindlijk geresulteerd in entiteiten met status 'Niet opgegeven'. Enkele entiteiten hebben een Engelse naam, terwijl ik bij mijn laatste Gielz installatie ik gekozen had voor NL. Ik vermoed dat ik bij mijn eerste poging onbewust gekozen heb voor Engels. Dit is nu echt een rommeltje geworden. Repareren gaat me denk ik meer tijd kosten dan een verse installatie.

Al met al de afgelopen periode veel geleerd. Ergens komende week maar de verse installatie doen, waarbij ik voorlopig HA voornamelijk ga inzetten voor energie (HW + Zendure). De rest werkt voorlopig goed genoeg in HomeKit/homebridge. En van sommige smarthome devices vraag ik me af wat de toegevoegde waarde is. Op dat vlak ook even kritisch blijven. Leuk als ik een Ring notificatie nabouw, maar de Ring app doet dat prima. Het voordeel is dat ik dan ook two way audio heb. Ik weet het, het is ook een hobby. En natuurlijk tof als alles in 1 app afgehandeld wordt.

[Gramser]

Home Assistant is voor mij laadpaal en thuisbatterijen, geholpen door wat Homewizardspul. Beetje spelen met automatiseringen en notificaties. Maar meer hoeft het ook niet te worden. Heb vanmorgen met hulp van Claude een automatisering gemaakt die de batterijen op manual zet, waarbij ik dmv een slider op het dashnoard kan aangeven hoeveel de batterij mee mag doen. Als hij meedoet mag dat tot 30%SoC en als de auto weer vol is gaat de Zendure weer terug naar smart matching met minimum van 10%SoC. Met een knop kan ik de auto-voorrang direct uitzetten.

Nu alleen even wachten tot de auto weer terug is, om te testen…

[meesje]

Gramser schreef op vrijdag 4 september 2026 @ 15:41:
Home Assistant is voor mij laadpaal en thuisbatterijen, geholpen door wat Homewizardspul. Beetje spelen met automatiseringen en notificaties. Maar meer hoeft het ook niet te worden. Heb vanmorgen met hulp van Claude een automatisering gemaakt die de batterijen op manual zet, waarbij ik dmv een slider op het dashnoard kan aangeven hoeveel de batterij mee mag doen. Als hij meedoet mag dat tot 30%SoC en als de auto weer vol is gaat de Zendure weer terug naar smart matching met minimum van 10%SoC. Met een knop kan ik de auto-voorrang direct uitzetten.

Nu alleen even wachten tot de auto weer terug is, om te testen…

Een laadpaal hebben we nog niet. Dat maakt het bij ons wat minder complex. Voor nu heb ik gekozen voor modus Nul op de meter. Maar als we voor het einde van het jaar over zijn naar dynamisch moet ik denk ik toch wat meer gaan knutselen. Rekening houden met spread, tarieven, btw, etc. Daarin zie ik ook best verschillende kijken. Het is niet van: je moet het op deze manier inregelen en dan zit je altijd goed. Het liefst zou ik op basis van de gielz/gast777 integratie wel een standaard set met automations willen hebben die ik gewoon blind kan inladen. Voor zover ik weet, bestaat dat niet.

Voordat ik eerdaags een verse installatie doe, wil ik overigens nog twee testen doen met scrypted (om Ring in HomeKit Secure Video te krijgen, maar wel met een acceptabele prebuffer) en homebridge (kan mijn Raspberry Pi ontkoppeld worden).

[Idr548]

Wat zijn jullie settings bij
- opladen starten bij & oplaadmarge
- ontladen starten bij & ontlaadmarge

Wellicht hebben jullie al van alles getest en kunnen jullie ervaringen delen.
Goede mix tussen zo weinig mogelijk export en natuurlijk normaal aantal relais schakelingen.
Om zo optimaal mogelijk te kunnen laden natuurlijk.

[RemmyB83]

Idr548 schreef op vrijdag 4 september 2026 @ 16:11:
Wat zijn jullie settings bij
- opladen starten bij & oplaadmarge
- ontladen starten bij & ontlaadmarge

Wellicht hebben jullie al van alles getest en kunnen jullie ervaringen delen.
Goede mix tussen zo weinig mogelijk export en natuurlijk normaal aantal relais schakelingen.
Om zo optimaal mogelijk te kunnen laden natuurlijk.

Ik heb een vast contract tot en met 30-sept-26, en draai NOM. Hij begint hier momenteel met opladen bij -50W, en hou 15W marge aan.
Ontladen start bij 50W en hou 5W marge aan.

Wat het beste werkt voor jouw thuis, zal afhangen van je contract(vast/dynamisch), grote van je zonnepanelenset, grote van je batterij en van je thuissituatie(kinderen, WP, enz). Kortom wat bij mijn werkt, werkt bij jouw nog iemand anders misschien minder goed.

[Polvo176]

Wie kan me helpen, ben met HA bezig geweest wat met AI de verschillende modes van de manager te sturen, maar de 1600AC+ gehoorzaamt niet, die blijft braaf naar de app luisteren.
De Hypers en de SF800pro2 luisteren wel naar HA.

[peterbier]

Polvo176 schreef op vrijdag 4 september 2026 @ 22:47:
Wie kan me helpen, ben met HA bezig geweest wat met AI de verschillende modes van de manager te sturen, maar de 1600AC+ gehoorzaamt niet, die blijft braaf naar de app luisteren.
De Hypers en de SF800pro2 luisteren wel naar HA.

Hier geen enkel probleem met de 1600+ met aansturing HomeAssistant.
Heb je wel de 1600+ uit HEMS (Zendure app) gehaald.?

[Polvo176]

peterbier schreef op vrijdag 4 september 2026 @ 23:04:
[...]

Hier geen enkel probleem met de 1600+ met aansturing HomeAssistant.
Heb je wel de 1600+ uit HEMS (Zendure app) gehaald.?

Jazeker, mqtt ingesteld en op zensdk in HA

[peterbier]

Polvo176 schreef op vrijdag 4 september 2026 @ 23:07:
[...]

Jazeker, mqtt ingesteld en op zensdk in HA

MQTT gebruik ik niet.
Dat heb ik bij al mijn Zendures uit staan.
Alleen zensdk is voldoende. (Voor de 1600+)
Hyper gebruik ik nog de cloud maar deze gaat weg en komt de 1600+ voor.
Deze heb ik nog in de hal staan.
Probeer eens MQTT uit te zetten op de 1600+.

[Polvo176]

peterbier schreef op vrijdag 4 september 2026 @ 23:11:
[...]

MQTT gebruik ik niet.
Dat heb ik bij al mijn Zendures uit staan.
Alleen zensdk is voldoende. (Voor de 1600+)
Hyper gebruik ik nog de cloud maar deze gaat weg en komt de 1600+ voor.
Deze heb ik nog in de hal staan.
Probeer eens MQTT uit te zetten op de 1600+.

Maakt niet uit de 1600 reageert niet op cmomando's uit HA.
De 800pro was ook moeizaam, maar werkte uiteindelijk wel.
De Hypers waren geen enkel probleem, die reageerden direct.
Kun je ene stukje yaml code laten zien hoe jij dat doet?

[ Voor 5% gewijzigd door Polvo176 op 04-09-2026 23:25 ]

[peterbier]

Polvo176 schreef op vrijdag 4 september 2026 @ 23:25:
[...]

Maakt niet uit de 1600 reageert niet op cmomando's uit HA.
De 800pro was ook moeizaam, maar werkte uiteindelijk wel.
De Hypers waren geen enkel probleem, die reageerden direct.

Vreemd mijn Zendures doen het prima.
Sf800pro,1600+ en 2400AC MQTT uit.
De Hyper via cloud.
Ze reageren direct met Fireson HA.

MQTT gebruik ik alleen voor mijn Climate control voor de airco.
Voor mijn Zendures nooit gebruikt.

En als je kiest handmatig vermogen.
Komt de 1600+ dan niet mee.

[ Voor 29% gewijzigd door peterbier op 04-09-2026 23:35 ]

[peterbier]

@Polvo176
Heb je HA ook al een "echte" reboot gegeven.?

[Polvo176]

peterbier schreef op vrijdag 4 september 2026 @ 23:45:
@Polvo176
Heb je HA ook al een "echte" reboot gegeven.?
[Afbeelding]

Ja, haalt niks uit, de app heeft de controle over de batterij en ook al zet ik het met de hand anders in HA, de app zet het net zo snel weer terug naar de eigen instelling.

[sender]

Polvo176 schreef op zaterdag 5 september 2026 @ 09:37:
[...]

Ja, haalt niks uit, de app heeft de controle over de batterij en ook al zet ik het met de hand anders in HA, de app zet het net zo snel weer terug naar de eigen instelling.

De app "doet niks" als je daar de batterijen uit HEMS haalt.

[Polvo176]

sender schreef op zaterdag 5 september 2026 @ 10:27:
[...]

De app "doet niks" als je daar de batterijen uit HEMS haalt.

De net invoer/uitvoer in de app bepalen wat de batterij doet buiten Hems.

[sender]

Polvo176 schreef op zaterdag 5 september 2026 @ 10:49:
[...]

De net invoer/uitvoer in de app bepalen wat de batterij doet buiten Hems.

Geen idee wat jij daarmee bedoelt. Ik heb mijn accus in de app, uit hems en die doet niets. Nu he. Ik dan ook geen p1 gekoppeld in de app (waarom zou je).

[peterbier]

Polvo176 schreef op zaterdag 5 september 2026 @ 10:49:
[...]

De net invoer/uitvoer in de app bepalen wat de batterij doet buiten Hems.

Vreemd mijn 1600+ draait nu nom via HomeAssistant. Net als de rest van mijn Zendures.
Via zon opladen nu.
Als ik de 1600+ stop stopt deze netjes.

[ Voor 35% gewijzigd door peterbier op 05-09-2026 12:21 ]

[Spike2100]

Dit is de eerste keer dat ik "store solar" zie staan in de fireson integratie. Heeft iemand een idee of dit sneller schakelt dan "smart charge only" op een bewolkte dag?

thanks

[peterbier]

Spike2100 schreef op zaterdag 5 september 2026 @ 13:55:
Dit is de eerste keer dat ik "store solar" zie staan in de fireson integratie. Heeft iemand een idee of dit sneller schakelt dan "smart charge only" op een bewolkte dag?

thanks


[Afbeelding]

Ik heb hier nog geen verschil gezien.
Volgens mij is het hetzelfde als slim opladen.
Maar ik kan het mis hebben.

[Polvo176]

peterbier schreef op zaterdag 5 september 2026 @ 14:38:
[...]

Ik heb hier nog geen verschil gezien.
Volgens mij is het hetzelfde als slim opladen.
Maar ik kan het mis hebben.

Wie kan me uitleggen wat precies de verschillen zijn ook t.o.v. de app?
Met de zoek machines wordt ik niet veel wijzer, die roepen maar wat en spreken elkaar tegen.


De 1600 werkt nu, geen idee wat de oorzaak is geweest, alle instellingen in HA werden direct door de app terug gezet naar de mode en waarden in de app
Ik heb de 1600 opnieuw geïnstalleerd, alles wat met de 1600 te maken had gewist ook in HA en ook alles de nodige keren gereboot.
Op zeker moment nam hij wel de opdrachten uit HA over.
Er is ergens iets in de software blijven hangen wat zich niet zomaar terug liet zetten.

[gast777]

MP3-Junky schreef op dinsdag 1 september 2026 @ 16:01:
[...]

Zie deze grafiek van vandaag.[Afbeelding]

Bij opladen waren beide tegelijk actief (vanwege het hogere gevraagde vermogen).

Het om en om opladen/ontladen is alleen van toepassing als niet beide (of niet allemaal, bij 3 Zendures) actief zijn.

[gast777]

maertenr schreef op vrijdag 4 september 2026 @ 00:52:
[...]

Hier hetzelfde probleem
Heb net alles geinstalleerd (Gielz en Nod-red) voor mijn 3x 800 Plus. Hij begon net met 400W ontladen vanuit 1 batterij, maar splitst het nu al een tijdje over 2 batterijen. Iemand een idee misschien?

Hij gaat standaard terug naar 1 Zendure bij 40% van max vermogen (van 1 Zendure). Dat is dan normaal gesproken 800*0.40=320 Watt. Onder dat gevraagde vermogen zal hij van 2 naar 1 Zendure actief gaan.

Opschakelen naar 2 Zendures gebeurt dan weer bij 100% van max vermogen (van 1 Zendure), dus bij >800W gevraagd vermogen.

Hiermee zit er hysterese in de regeling, zodat hij niet zo snel flippert tussen 1 en 2 Zendures actief.

Een en ander staat hier uitgelegd, maar het voorbeeld is voor 2400W max. Laat maar weten als je een suggestie hebt om het duidelijker uit te leggen.

Deze percentages (40% en 100%) kunnen trouwens aangepast worden in de Node-Red flow in het blokje "Vul hier de Zendure IP adressen in", onder "Optioneel tweakbare variabelen".

Als ik je bericht zo lees, denk ik dat je de 40% hoger wilt zetten, bijvoorbeeld naar 60%. Dan zal hij eerder weer terugzakken naar 1 Zendure actief.

[ Voor 10% gewijzigd door gast777 op 06-09-2026 10:01 ]

[Pakhaas]

gast777 schreef op zondag 6 september 2026 @ 09:40:
[...]

Hij gaat standaard terug naar 1 Zendure bij 40% van max vermogen (van 1 Zendure). Dat is dan normaal gesproken 800*0.40=320 Watt. Onder dat gevraagde vermogen zal hij van 2 naar 1 Zendure actief gaan.

Opschakelen naar 2 Zendures gebeurt dan weer bij 100% van max vermogen (van 1 Zendure), dus bij >800W gevraagd vermogen.

Hiermee zit er hysterese in de regeling, zodat hij niet zo snel flippert tussen 1 en 2 Zendures actief.

Een en ander staat hier uitgelegd, maar het voorbeeld is voor 2400W max. Laat maar weten als je een suggestie hebt om het duidelijker uit te leggen.

Deze percentages (40% en 100%) kunnen trouwens aangepast worden in de Node-Red flow in het blokje "Vul hier de Zendure IP adressen in", onder "Optioneel tweakbare variabelen".

Als ik je bericht zo lees, denk ik dat je de 40% hoger wilt zetten, bijvoorbeeld naar 60%. Dan zal hij eerder weer terugzakken naar 1 Zendure actief.

Zou hoger niet veel efficiënter zijn?

[maartend]

Vraag.


Ik gebruik omnibattery (want heb niet zo heel veel in te stellen, want vast contract en wat zonnepanelen). Nu heb ik omnibattery zo ingesteld dat de batterijen enkel worden geladen vanuit een overschot aan zonnepanelenopwekking. Dus niet van het grid.
Maar hoe zorg ik nu dat de batterijen niet als eerste worden ontladen als ik tijdens zonnige dagen thuis stroom verbruik? Ik heb die batterijen vnl voor in de avond/nacht.
Nu zou ik met timeslots kunnen werken, maar dan staat eea heel hard en de zon gaat natuurlijk in d eloop van het seizoen steeds later op en onder.

[oNo]

Sinds deze week heb ik een SolarFlow 800 Plus, gekocht nadat deze (weer eens) in het aanbiedingen topic stond. Ik heb er 314 euro voor betaald, inclusief bezorging. Als je Home Assistant, een PV installatie en een p1 meter hebt is het bijna een must have. Geen EV hier, en daarom nu ook vrij simpel ingesteld om wat meer energie van de PV zelf te consumeren.

De eerste dag, do 3 sept, heeft het ding via HEMS op NOM gedraaid. Geen idee wat er gebeurde, er zat al wat energie in de batterij. Die avond wat aan het klooien geweest met de HA integratie van Gielz, maar niet aan de praat gekregen. Uiteraard lag dat aan mij, maar de documentatie is voor een newbie als ik nog niet voldoende (niveau, proxmox met verschillende LXC containers waaronder frigate/go2rtc, adguard, haos, zonder AI opgezet ;-) )

Ik heb nu de Zendure HA integratie. De vrijdag te weinig zon om de batterij vol te krijgen. Ik heb 2 simpele automations.
- enable smart charging at 12:00
- enable smart discharging at 19:00 and set minimal SoC to 7%

Gisteren zag ik dat het huishouden voor ruim 3.5 uur op de batterij draait. Te weinig om de ochtend te halen. Het is wel verslavend want eigenlijk wil ik dat. Echter gaan we snel naar een periode dat een eventueel tweede batterij niet vol komt. PV installatie op zuid met 4200 omvormer en 10x505WP panelen.
Dus nu even tijd om te kijken wat ik het voorjaar ga doen.

[meesje]

@oNo Waarom kies je voor een vaste tijden? Deze wil je toch variabel maken?

In ons huishouden zou ik het wel fijn vinden als tijdens de dure tijden de batterijen bijspringen vanwege het hoge verbruik bij het koken. We hebben overigens nog geen dyn.contract. Ik heb nog even om er over na te denken.

[oNo]

meesje schreef op zondag 6 september 2026 @ 13:24:
@oNo Waarom kies je voor een vaste tijden? Deze wil je toch variabel maken?

In ons huishouden zou ik het wel fijn vinden als tijdens de dure tijden de batterijen bijspringen vanwege het hoge verbruik bij het koken. We hebben overigens nog geen dyn.contract. Ik heb nog even om er over na te denken.

Dat klopt, dat is ook de volgende stap. Echter is deze oplossing lekker simpel en dekt al het grootste deel af. Met de beperkte capaciteit van de batterij ga ik zeer weinig winnen om het te optimaliseren. Het is wel een leuk klusje om tijdens een druilerige zondagmiddag te doen.

IMHO is wat ik nu heb al een stuk beter dan de standaard NOM instelling.

[ZuinigeRijder]

Pakhaas schreef op zondag 6 september 2026 @ 11:52:
[...]

Zou hoger niet veel efficiënter zijn?

Ja, voor mijn 3x SF800+ wel. Ik heb 40% naar 80% gezet, zodat maximaal 640 Watt met 1 batterij geladen kan worden, dat is iets van 0.3C

Maar voor 3x een 2400 Watt omvormer zijn andere percentages mogelijk beter. En ligt er ook nog aan hoeveel capaciteit van batterijen eronder zit. Dus eigenlijk zou de waarde iets van 0.4C per omvormer moeten zijn

En dan kan het ook nog zijn dat er verschillende systemen onder de proxy draaien.

[meesje]

oNo schreef op zondag 6 september 2026 @ 14:11:
[...]

Dat klopt, dat is ook de volgende stap. Echter is deze oplossing lekker simpel en dekt al het grootste deel af. Met de beperkte capaciteit van de batterij ga ik zeer weinig winnen om het te optimaliseren. Het is wel een leuk klusje om tijdens een druilerige zondagmiddag te doen.

IMHO is wat ik nu heb al een stuk beter dan de standaard NOM instelling.

De afgelopen tijd heb ik van alles uitgeprobeerd met Home Assistant. Vandaag een verse installatie gedaan. Af en toe tussen door even wat inrichten. Eerst de HW apparaten en daarna Gielz/gast777 en deze keer gelijk alles goed.

Verder nog een wens om met reverse proxy (ik heb al een ddns via mijn Synology) om HA van buiten te kunnen benaderen.

[DeadMetal]

@gast777 ik merk dat sporadisch een van mijn 2 Zendures niet 'reageert'. Als de Gielz zegt dat hij moet Snel opladen of Snel ontladen, dan gaat het totaal naar grofweg 2400w in plaats van 4800w. Als ik de gielz dan in Standby zet en daarna weer opnieuw in de gewenste modus, dan pakt hij hem direct wel.

Voorbeeld van Snel ontladen:

code:

Vermogensopdracht = -4800W
Vermogensopdracht Zendure 1 = -2400W
Vermogensopdracht Zendure 2 = -2400W
Zendure 1 Vermogen Aansturing = 0W
Zendure 2 Vermogen Aansturing = -2398 W
Actief Device = Zendure 1 en 2

Is het mogelijk voor jou om in de proxy een controle in te bouwen 'of alle batterijen wel doen wat ik van ze vraag?' I.c.m. een retry-commando geven?
Aandachtspuntje bij Snel opladen is natuurlijk wel dat de batterij op een gegeven moment (als hij redelijk vol begint te raken) steeds langzamer zal opladen en zijn doelsnelheid niet meer kan halen.

[turbojonny]

Is er iemand die al een werkende code heeft rondom twee verschillende Zendure producten met verschillende vermogens? Ik had een 800 plus en heb nu mijn 3000 mix binnen, maar krijg het met geen mogelijkheid naast elkaar werkend. Al geprobeerd met Gast777 om zo het als 1 accu aan te leveren aan gielz, maar dan geeft Gielz aan dat het om twee dezelfde accus gaat (bijv. dus 16kw van 2x 3000 mix). In gielz klopt dan nog meer niet. AI krijgt het ook niet gefixt. Iemand een linkje of leuke code?

Additie van (dis)chargerate en capacity is onvoldoende.

let ipZendure1 = "192.168.xx.xx" (normaal wel ingevuld)
let ipZendure2 = "192.168.xx.xx" (normaal wel ingevuld)
let ipZendure3 = ""

// If you use two Zendures, leave the third as is with an empty string:

// let ipZendure3 = ""

// Tip: to use a simulated Zendure test device, in stead of the IP

// address, enter the name of the simulated device. Run the flow

// Zendure-simulated-devices.json on the same Node-RED host.

// Example:

//let ipZendure1 = "testdevice1"
//let ipZendure2 = "testdevice2"
//let ipZendure3 = "testdevice3"

// Note: When a Zendure inverter gets replaced, and hence the serial numbers
// change, then press the button at "Initialize" to re-learn the serial numbers.

//===============================================================

//== Per-device configuration (charging rate, discharging rate, capacity)
//== Vul hier de specifieke waarden per Zendure omvormer in

//===============================================================

// Charging rate per device (W) - maximum input power per inverter
let chargeRate_1 = 800    // Device 1 max charging rate in W
let chargeRate_2 = 1000   // Device 2 max charging rate in W
let chargeRate_3 = ""    // Device 3 max charging rate in W

// Discharging rate per device (W) - maximum output power per inverter
let dischargeRate_1 = 800   // Device 1 max discharging rate in W
let dischargeRate_2 = 800   // Device 2 max discharging rate in W
let dischargeRate_3 = ""    // Device 3 max discharging rate in W

// Capacity per device (kWh)

let capacity_1 = 8   // Device 1 capacity in kWh
let capacity_2 = 1.92   // Device 2 capacity in kWh
let capacity_3 = ""     // Device 3 capacity in kWh

//===================================================
NB: let niet op wattages. Dit was nog toen ze niet op eigen stopcontact stonden. Is ondertussen wel zo.

[ Voor 66% gewijzigd door turbojonny op 06-09-2026 19:26 ]

[Polvo176]

turbojonny schreef op zondag 6 september 2026 @ 19:22:
Is er iemand die al een werkende code heeft rondom twee verschillende Zendure producten met verschillende vermogens? Ik had een 800 plus en heb nu mijn 3000 mix binnen, maar krijg het met geen mogelijkheid naast elkaar werkend. Al geprobeerd met Gast777 om zo het als 1 accu aan te leveren aan gielz, maar dan geeft Gielz aan dat het om twee dezelfde accus gaat (bijv. dus 16kw van 2x 3000 mix). In gielz klopt dan nog meer niet. AI krijgt het ook niet gefixt. Iemand een linkje of leuke code?

Additie van (dis)chargerate en capacity is onvoldoende.

let ipZendure1 = "192.168.xx.xx" (normaal wel ingevuld)
let ipZendure2 = "192.168.xx.xx" (normaal wel ingevuld)
let ipZendure3 = ""

// If you use two Zendures, leave the third as is with an empty string:

// let ipZendure3 = ""

// Tip: to use a simulated Zendure test device, in stead of the IP

// address, enter the name of the simulated device. Run the flow

// Zendure-simulated-devices.json on the same Node-RED host.

// Example:

//let ipZendure1 = "testdevice1"
//let ipZendure2 = "testdevice2"
//let ipZendure3 = "testdevice3"

// Note: When a Zendure inverter gets replaced, and hence the serial numbers
// change, then press the button at "Initialize" to re-learn the serial numbers.

//===============================================================

//== Per-device configuration (charging rate, discharging rate, capacity)
//== Vul hier de specifieke waarden per Zendure omvormer in

//===============================================================

// Charging rate per device (W) - maximum input power per inverter
let chargeRate_1 = 800    // Device 1 max charging rate in W
let chargeRate_2 = 1000   // Device 2 max charging rate in W
let chargeRate_3 = ""    // Device 3 max charging rate in W

// Discharging rate per device (W) - maximum output power per inverter
let dischargeRate_1 = 800   // Device 1 max discharging rate in W
let dischargeRate_2 = 800   // Device 2 max discharging rate in W
let dischargeRate_3 = ""    // Device 3 max discharging rate in W

// Capacity per device (kWh)

let capacity_1 = 8   // Device 1 capacity in kWh
let capacity_2 = 1.92   // Device 2 capacity in kWh
let capacity_3 = ""     // Device 3 capacity in kWh

//===================================================
NB: let niet op wattages. Dit was nog toen ze niet op eigen stopcontact stonden. Is ondertussen wel zo.

Verschillende batterij typen kan voor zover ik weet alleen met de Fireson integratie, de 3000 mix zit daar helaas nog niet bij.
Nog even geduld doen dus.

[Gramser]

Ik meen dat @jelleeelco dit voor elkaar heeft gekregen met Claude Code

[Vaez]

Ik heb een 2400 AC+ met 11 kWh totaal sinds deze week. Ik wil hiermee zorgen dat mijn kosten zo laag mogelijk zijn. Nu heb ik de Zendure-integratie voor inzicht(deze stuurt niet). Daarnaast draai ik nu ook de Gielz-oplossing. Deze stuurt nu mijn batterij aan(HEMS heb ik uitgezet). Ik heb veel zonsoverschot van mijn zonnepanelen en een dynamisch contract. Daarnaast zou de 11 kWh ongeveer de nacht door moeten kunnen komen met NOM.

Dus in het scenario dat er genoeg zon is en hiermee de accu volgeladen wordt, zou ik gratis de nacht kunnen overbruggen. Echter, in het geval dat er weinig zonopbrengst is, wil ik de accu op het goedkoopste moment volladen zodat dit op de duurdere momenten gebruikt wordt. Voor zover ik heb gezien, kan dit niet direct met de Gielz-integratie. Deze kijkt namelijk niet naar hoeveel zonnepaneelopbrengst er verwacht wordt.

Zou de beste oplossing hiervoor zijn de Solcast-voorspelling(voorspeelt hoeveel zon opbrengst er is de volgende dag) te gebruiken in een automation om te bepalen of er genoeg zonnestroom zal zijn om de accu vol te laten en op basis hiervan elke dag te bepalen of ik "Nul op de meter" of "Dynamisch NOM" wil draaien?

Hoe hebben jullie dit gedaan of wat zou een betere manier zijn?

[ Voor 4% gewijzigd door Vaez op 06-09-2026 23:34 ]

[hemertje]

Hoi @gielz ,

Allereerst bedankt voor het onderhouden van deze integratie — werkt super!

Ik krijg in Home Assistant elke 5 seconden een waarschuwing in de logs van de zenSDK Global automatisering:

code:

ValueError: Template error: float got invalid input 'unavailable'

Wat is het probleem?
De automatisering meet allerlei waarden van de Zendure (batterijlading, vermogen, etc.).
Als een van die sensoren tijdelijk niet bereikbaar is (bijvoorbeeld na een herstart of verbindingsoorzaak), crasht de automatisering en kun je de waarschuwing elke paar seconden terugzien in de logs.

Waarom gebeurt dit?
In de template-code staat op veel plekken | float zonder een veilige standaardwaarde.
Zodra een sensor "unavailable" is (dus geen waarde heeft), geeft dit een foutmelding.

De oplossing is simpel: | float vervangen door | float(0).

Dan krijgt een onbereikbare sensor waarde 0 in plaats van een foutmelding.
Als de sensor weer werkt, verandert er niets.

Welke bestanden moeten aangepast worden?

• Global (EN) Integration/automation_global.yaml
• Dutch (NL) Integration/automation_nl.yaml
• Global (EN) Integration/packages/zendure_gielz1986_global.yaml
• Dutch (NL) Integration/packages/zendure_gielz1986_nl.yaml

Hoe?
Je kunt het zelf doorvoeren met het volgende commando:

code:

bash
perl -pi -e 's/\| float(?!\()/| float(0)/g' automation_global.yaml automation_nl.yaml packages/zendure_gielz1986_global.yaml packages/zendure_gielz1986_nl.yaml

Ik zie dat deze al gemeld is!
Er staat al een issue (#255) en een PR (#257) open:

• Issue #255 — "Template errors in automation_global.yaml when Zendure REST sensors go unavailable (| float without default)"
• PR #257 — "Give float/int filters explicit defaults and guard unavailable entities"

Kan je even checken of die PR al reviewed is of vastloopt?

[DeadMetal]

Vaez schreef op zondag 6 september 2026 @ 23:08:
Ik heb een 2400 AC+ met 11 kWh totaal sinds deze week. Ik wil hiermee zorgen dat mijn kosten zo laag mogelijk zijn. Nu heb ik de Zendure-integratie voor inzicht(deze stuurt niet). Daarnaast draai ik nu ook de Gielz-oplossing. Deze stuurt nu mijn batterij aan(HEMS heb ik uitgezet). Ik heb veel zonsoverschot van mijn zonnepanelen en een dynamisch contract. Daarnaast zou de 11 kWh ongeveer de nacht door moeten kunnen komen met NOM.

Dus in het scenario dat er genoeg zon is en hiermee de accu volgeladen wordt, zou ik gratis de nacht kunnen overbruggen. Echter, in het geval dat er weinig zonopbrengst is, wil ik de accu op het goedkoopste moment volladen zodat dit op de duurdere momenten gebruikt wordt. Voor zover ik heb gezien, kan dit niet direct met de Gielz-integratie. Deze kijkt namelijk niet naar hoeveel zonnepaneelopbrengst er verwacht wordt.

Zou de beste oplossing hiervoor zijn de Solcast-voorspelling(voorspeelt hoeveel zon opbrengst er is de volgende dag) te gebruiken in een automation om te bepalen of er genoeg zonnestroom zal zijn om de accu vol te laten en op basis hiervan elke dag te bepalen of ik "Nul op de meter" of "Dynamisch NOM" wil draaien?

Hoe hebben jullie dit gedaan of wat zou een betere manier zijn?

Ik gebruik zelf de Open-Meteo Solar Forecast integratie. Solcast heeft als beperking dat je maar 1 dakvlak (gratis) kan gebruiken, en ik heb zowel op de voor- als achterkant van mijn huis panelen heb.

Je kan dat inderdaad laten meewegen bij het bepalen in welke modus je de gielz zet.
Zelf gebruik ik helemaal niks van het 'dynamische' gebeuren van gielz. In plaats daarvan laat ik Node-RED (daarin draaien mijn automations, maar HA kan dit evt. zelf ook) de modus van de gielz aanpassen, waarbij hij dan enkel schakelt tussen 'Nul op de meter', 'Alleen slim ontladen', 'Snel ontladen' en 'Snel opladen'. Daarin speelt inderdaad ook de verwachte opbrengst van de dag mee.

Om 6u 's ochtend laat ik een plan voor de dag maken. Hierbij wordt bepaald hoeveel kwartieren we willen laden van het net (dus de modus 'Snel opladen'). Hierbij spelen de energieprijzen een rol en de verwachte opwek en de huidige vulgraad van de batterij. Vervolgens wordt bepaald welke X kwartieren dan de goedkoopste zijn, zodat we op die kwartieren naar 'Snel opladen' kunnen.

Ook wordt bepaald hoeveel kwartieren we willen dat de stroom van de panelen naar de batterijen gaat (hoe meer opwek, hoe minder kwartieren er nodig zijn, en dus hoe meer kwartieren er gewoon teruggeleverd kan worden). Dan blijft hij in de ochtend nog enige tijd op 'Alleen slim ontladen' (opgewekte stroom wordt teruggeleverd, prijs is immers nog redelijk hoog) en gaat op het berekende tijdstip dan naar 'Nul op de meter' (zonopwek gaat de batterij in).

Eind van de middag wordt tenslotte bekeken hoe vol de batterij is geraakt en hoeveel kwartieren we dan kunnen ontladen in de avond (met voldoende sap overlaten voor NOM in de nacht). Dan berekent hij welke kwartieren dat dan moeten zijn, en gaat er op die kwartieren naar 'Snel ontladen'.

En 's avonds laat wordt nog bepaald of er in de nacht evt. nog wat van het net geladen moet worden (stel: morgen amper opwek verwacht, en in de nacht blijken de prijzen lager dan overdag), hoeveel kwartieren en welke kwartieren dat dan zijn.

[oNo]

oNo schreef op zondag 6 september 2026 @ 12:59:
Sinds deze week heb ik een SolarFlow 800 Plus, gekocht nadat deze (weer eens) in het aanbiedingen topic stond. Ik heb er 314 euro voor betaald, inclusief bezorging. Als je Home Assistant, een PV installatie en een p1 meter hebt is het bijna een must have. Geen EV hier, en daarom nu ook vrij simpel ingesteld om wat meer energie van de PV zelf te consumeren.

De eerste dag, do 3 sept, heeft het ding via HEMS op NOM gedraaid. Geen idee wat er gebeurde, er zat al wat energie in de batterij. Die avond wat aan het klooien geweest met de HA integratie van Gielz, maar niet aan de praat gekregen. Uiteraard lag dat aan mij, maar de documentatie is voor een newbie als ik nog niet voldoende (niveau, proxmox met verschillende LXC containers waaronder frigate/go2rtc, adguard, haos, zonder AI opgezet ;-) )

Ik heb nu de Zendure HA integratie. De vrijdag te weinig zon om de batterij vol te krijgen. Ik heb 2 simpele automations.
- enable smart charging at 12:00
- enable smart discharging at 19:00 and set minimal SoC to 7%

Gisteren zag ik dat het huishouden voor ruim 3.5 uur op de batterij draait. Te weinig om de ochtend te halen. Het is wel verslavend want eigenlijk wil ik dat. Echter gaan we snel naar een periode dat een eventueel tweede batterij niet vol komt. PV installatie op zuid met 4200 omvormer en 10x505WP panelen.
Dus nu even tijd om te kijken wat ik het voorjaar ga doen.

Nou vooruit, een volgende poging en ik heb de integratie van Gielz aan de praat. Een nachtje slapen doet het altijd goed. Deze oplossing is ook veel mooier.

Vanaf 10 uur zet ik smart charge only aan. Dan om 14:30 in de middag switch ik naar smart matching. Deze kleine batterij moet dan al redelijk vol zitten. Is dat niet het geval, doe er dan maar wat goedkope stroom in, goedkoper dan prime time 's avonds.

[maertenr]

gast777 schreef op zondag 6 september 2026 @ 09:40:
[...]

Hij gaat standaard terug naar 1 Zendure bij 40% van max vermogen (van 1 Zendure). Dat is dan normaal gesproken 800*0.40=320 Watt. Onder dat gevraagde vermogen zal hij van 2 naar 1 Zendure actief gaan.

Opschakelen naar 2 Zendures gebeurt dan weer bij 100% van max vermogen (van 1 Zendure), dus bij >800W gevraagd vermogen.

Hiermee zit er hysterese in de regeling, zodat hij niet zo snel flippert tussen 1 en 2 Zendures actief.

Een en ander staat hier uitgelegd, maar het voorbeeld is voor 2400W max. Laat maar weten als je een suggestie hebt om het duidelijker uit te leggen.

Deze percentages (40% en 100%) kunnen trouwens aangepast worden in de Node-Red flow in het blokje "Vul hier de Zendure IP adressen in", onder "Optioneel tweakbare variabelen".

Als ik je bericht zo lees, denk ik dat je de 40% hoger wilt zetten, bijvoorbeeld naar 60%. Dan zal hij eerder weer terugzakken naar 1 Zendure actief.

Dank voor je antwoord en dank voor de bijzonder bruikbare uitbreiding voor mijn drie 800 plus'en

De uitleg is prima te volgen. Zou de efficientie niet hoger liggen bij een wat hoger percentage? In mijn eigen geval is het nachtverbruik ongeveer 400W, dat zou goed vanuit 1 batterij te doen zijn.

[ Voor 52% gewijzigd door maertenr op 07-09-2026 12:39 ]

[koboy]

hemertje schreef op maandag 7 september 2026 @ 11:13:
Hoi @gielz ,

Allereerst bedankt voor het onderhouden van deze integratie — werkt super!

Ik krijg in Home Assistant elke 5 seconden een waarschuwing in de logs van de zenSDK Global automatisering:

code:

ValueError: Template error: float got invalid input 'unavailable'

Wat is het probleem?
De automatisering meet allerlei waarden van de Zendure (batterijlading, vermogen, etc.).
Als een van die sensoren tijdelijk niet bereikbaar is (bijvoorbeeld na een herstart of verbindingsoorzaak), crasht de automatisering en kun je de waarschuwing elke paar seconden terugzien in de logs.

Waarom gebeurt dit?
In de template-code staat op veel plekken | float zonder een veilige standaardwaarde.
Zodra een sensor "unavailable" is (dus geen waarde heeft), geeft dit een foutmelding.

De oplossing is simpel: | float vervangen door | float(0).

Dan krijgt een onbereikbare sensor waarde 0 in plaats van een foutmelding.
Als de sensor weer werkt, verandert er niets.

Welke bestanden moeten aangepast worden?

• Global (EN) Integration/automation_global.yaml
• Dutch (NL) Integration/automation_nl.yaml
• Global (EN) Integration/packages/zendure_gielz1986_global.yaml
• Dutch (NL) Integration/packages/zendure_gielz1986_nl.yaml

Hoe?
Je kunt het zelf doorvoeren met het volgende commando:

code:

bash
perl -pi -e 's/\| float(?!\()/| float(0)/g' automation_global.yaml automation_nl.yaml packages/zendure_gielz1986_global.yaml packages/zendure_gielz1986_nl.yaml

Ik zie dat deze al gemeld is!
Er staat al een issue (#255) en een PR (#257) open:

• Issue #255 — "Template errors in automation_global.yaml when Zendure REST sensors go unavailable (| float without default)"
• PR #257 — "Give float/int filters explicit defaults and guard unavailable entities"

Kan je even checken of die PR al reviewed is of vastloopt?

Even de opa stand aan....

Perl gebruiken voor een search+replace obv een regex is hetzelfde als met een Claas 690SL met alle alternatieve invoeren op een aanhanger er achter een kratje bier gaan halen bij de supermarkt, terwijl de fiets gewoon voor de deur staat.....
Zo zien we maar weer dat AI dom is. Perl kun je niet van op aan dat het op elk Unix/Linux systeem staat, sed (stream editor) is dat wel, en pakt zo goed als dezelfde syntax. Geen idee ook waarom er een extra bash shell wordt opgestart als eerste, het is niet zo dat er speciale opties van worden gebruikt....

Zo..... Opa gaat weer met zijn geblokte flanellen sloffen in de leunstoel zitten

[ Voor 3% gewijzigd door koboy op 07-09-2026 17:32 ]

[hemertje]

koboy schreef op maandag 7 september 2026 @ 17:30:
[...]

Even de opa stand aan....

Perl gebruiken voor een search+replace obv een regex is hetzelfde als met een Claas 690SL met alle alternatieve invoeren op een aanhanger er achter een kratje bier gaan halen bij de supermarkt, terwijl de fiets gewoon voor de deur staat.....
Zo zien we maar weer dat AI dom is. Perl kun je niet van op aan dat het op elk Unix/Linux systeem staat, sed (stream editor) is dat wel, en pakt zo goed als dezelfde syntax. Geen idee ook waarom er een extra bash shell wordt opgestart als eerste, het is niet zo dat er speciale opties van worden gebruikt....

Zo..... Opa gaat weer met zijn geblokte flanellen sloffen in de leunstoel zitten

Opa kan weer doorslapen

dank voor de reactie!

[Idr548]

Ik heb dit weekend eens de Gielz sturing zitten uitproberen.
Werkt op zich wel goed volgens de eerste test.
Deze ochtend merke it wel dat de SOC van mijn batterij steeds bleef dalen.
Gestopt aan 10% met ontladen, maar deze daalde verder in stappen tot 6% tot er genoeg vermogen was om terug bij te laden.

Is dit iets die nog mensen ervaren?

[martinvdm]

hemertje schreef op maandag 7 september 2026 @ 11:13:
Hoi @gielz ,

Allereerst bedankt voor het onderhouden van deze integratie — werkt super!

Ik krijg in Home Assistant elke 5 seconden een waarschuwing in de logs van de zenSDK Global automatisering:

code:

ValueError: Template error: float got invalid input 'unavailable'

Wat is het probleem?
De automatisering meet allerlei waarden van de Zendure (batterijlading, vermogen, etc.).
Als een van die sensoren tijdelijk niet bereikbaar is (bijvoorbeeld na een herstart of verbindingsoorzaak), crasht de automatisering en kun je de waarschuwing elke paar seconden terugzien in de logs.

Waarom gebeurt dit?
In de template-code staat op veel plekken | float zonder een veilige standaardwaarde.
Zodra een sensor "unavailable" is (dus geen waarde heeft), geeft dit een foutmelding.

De oplossing is simpel: | float vervangen door | float(0).

Dan krijgt een onbereikbare sensor waarde 0 in plaats van een foutmelding.
Als de sensor weer werkt, verandert er niets.

Welke bestanden moeten aangepast worden?

• Global (EN) Integration/automation_global.yaml
• Dutch (NL) Integration/automation_nl.yaml
• Global (EN) Integration/packages/zendure_gielz1986_global.yaml
• Dutch (NL) Integration/packages/zendure_gielz1986_nl.yaml

Hoe?
Je kunt het zelf doorvoeren met het volgende commando:

code:

bash
perl -pi -e 's/\| float(?!\()/| float(0)/g' automation_global.yaml automation_nl.yaml packages/zendure_gielz1986_global.yaml packages/zendure_gielz1986_nl.yaml

Ik zie dat deze al gemeld is!
Er staat al een issue (#255) en een PR (#257) open:

• Issue #255 — "Template errors in automation_global.yaml when Zendure REST sensors go unavailable (| float without default)"
• PR #257 — "Give float/int filters explicit defaults and guard unavailable entities"

Kan je even checken of die PR al reviewed is of vastloopt?

Het risico is dat float(0) niet neutraal is — je vervangt een offline status door een stille, verkeerde aanname, en welke aanname veilig is verschilt per plek.

Percentage-vergelijkingen (zoals laadpercentage < minimale_laadpercentage): als de laadpercentage-sensor even unavailable is en jij vult daar float(0) in, wordt dat automatisch "0% < jouw minimum" — bijna altijd True. De automation denkt dan dat de batterij leeg is, terwijl er gewoon geen actuele meting was. Dat kan een ongewenste laad- of ontlaadactie triggeren op basis van foute data, in plaats van dat er die ene run niks gebeurt.

Voor sensor.p1_aansturing_vermogen kan dit prima, want dan is je vermogen 0, iets wat ook al zo in de code staat. Let dus op waar je dit zet, het is niet overal een oplossing en kan dus juist foutief werken.

[FredvZ]

Zendure heeft blijkbaar weer zitten rommelen dit weekend: de variabele die kWh met de lading in de batterij is sinds dit weekend het percentage van de lading van de accu geworden. Het gekke is dat de firmware versie op mijn AC2400 nog steeds hetzelfde versienummer (2.0.1) heeft en de update (2.0.2) klaar staat in de app.

[Krisp]

Ik vond de oplossing van @Keida om EVCC en de Zendure met elkaar te verbinden wat ingewikkeld, dus ik heb als voorbereiding op het moment dat EVCC de optimizer daadwerkelijk gaat toepassen alvast een snelle integratie gemaakt waarbij EVCC (via de Gielz-automatiseringen) de batterij aanstuurt.

Dit is een eerste versie: mocht dit goed werken kan m.i. voor EVCC-gebruikers een veel eenvoudiger versie ontwikkeld worden. Tegelijkertijd werkt dit al heel goed.

[The_Haunted]

turbojonny schreef op zondag 6 september 2026 @ 19:22:
Is er iemand die al een werkende code heeft rondom twee verschillende Zendure producten met verschillende vermogens? Ik had een 800 plus en heb nu mijn 3000 mix binnen, maar krijg het met geen mogelijkheid naast elkaar werkend. Al geprobeerd met Gast777 om zo het als 1 accu aan te leveren aan gielz, maar dan geeft Gielz aan dat het om twee dezelfde accus gaat (bijv. dus 16kw van 2x 3000 mix). In gielz klopt dan nog meer niet. AI krijgt het ook niet gefixt. Iemand een linkje of leuke code?

Additie van (dis)chargerate en capacity is onvoldoende.

let ipZendure1 = "192.168.xx.xx" (normaal wel ingevuld)
let ipZendure2 = "192.168.xx.xx" (normaal wel ingevuld)
let ipZendure3 = ""

// If you use two Zendures, leave the third as is with an empty string:

// let ipZendure3 = ""

// Tip: to use a simulated Zendure test device, in stead of the IP

// address, enter the name of the simulated device. Run the flow

// Zendure-simulated-devices.json on the same Node-RED host.

// Example:

//let ipZendure1 = "testdevice1"
//let ipZendure2 = "testdevice2"
//let ipZendure3 = "testdevice3"

// Note: When a Zendure inverter gets replaced, and hence the serial numbers
// change, then press the button at "Initialize" to re-learn the serial numbers.

//===============================================================

//== Per-device configuration (charging rate, discharging rate, capacity)
//== Vul hier de specifieke waarden per Zendure omvormer in

//===============================================================

// Charging rate per device (W) - maximum input power per inverter
let chargeRate_1 = 800    // Device 1 max charging rate in W
let chargeRate_2 = 1000   // Device 2 max charging rate in W
let chargeRate_3 = ""    // Device 3 max charging rate in W

// Discharging rate per device (W) - maximum output power per inverter
let dischargeRate_1 = 800   // Device 1 max discharging rate in W
let dischargeRate_2 = 800   // Device 2 max discharging rate in W
let dischargeRate_3 = ""    // Device 3 max discharging rate in W

// Capacity per device (kWh)

let capacity_1 = 8   // Device 1 capacity in kWh
let capacity_2 = 1.92   // Device 2 capacity in kWh
let capacity_3 = ""     // Device 3 capacity in kWh

//===================================================
NB: let niet op wattages. Dit was nog toen ze niet op eigen stopcontact stonden. Is ondertussen wel zo.

Ik heb dezelfde situatie: een 800 plus en een 3000 mix. Ik heb in Gielz yaml de capaciteit van de mix naar 4.98 gezet. Dan is de gezamenlijke capaciteit gelijk aan de 1,92 en 8 kWh van de beide accu's. Het probleem zit hem in de aansturing van de ontlaadvermogens van 800 en 3000 watt en de verschillen in SOC.

Het is inderdaad een kwestie van geduld tot er een oplossing komt, zelf iets proberen te ontwikkelen, of...investeren en een 2e Mix erbij

[m-vw]

FredvZ schreef op maandag 7 september 2026 @ 21:59:
Zendure heeft blijkbaar weer zitten rommelen dit weekend: de variabele die kWh met de lading in de batterij is sinds dit weekend het percentage van de lading van de accu geworden. Het gekke is dat de firmware versie op mijn AC2400 nog steeds hetzelfde versienummer (2.0.1) heeft en de update (2.0.2) klaar staat in de app.

Ik had een melding in HA over eenheden die ik niet begreep. Denk dat dit het was.

[m-vw]

Polvo176 schreef op zaterdag 5 september 2026 @ 10:49:
[...]

De net invoer/uitvoer in de app bepalen wat de batterij doet buiten Hems.

Als je de batterijen uit HEMS haalt kan je inderdaad handmatig zaken instellen. Maar de app doet dat niet vanzelf. Je ziet misschien wel waarden staan, maar dat zijn de waarden die vanuit HA worden doorgegeven.

[Polvo176]

m-vw schreef op dinsdag 8 september 2026 @ 11:27:
[...]


Als je de batterijen uit HEMS haalt kan je inderdaad handmatig zaken instellen. Maar de app doet dat niet vanzelf. Je ziet misschien wel waarden staan, maar dat zijn de waarden die vanuit HA worden doorgegeven.

Dat was het probleem niet, de batterij was niet aan te sturen vanuit HA, ik heb nu een zelfde probleem met de 800pro.
het heeft te maken met de overschakeling van cloud naar zensdk.
Dan blijft hij schakelen tussen onbekend en zendsdk en is vanuit HA niet meer aan te spreken.

[m-vw]

Polvo176 schreef op dinsdag 8 september 2026 @ 11:36:
[...]

Dat was het probleem niet, de batterij was niet aan te sturen vanuit HA, ik heb nu een zelfde probleem met de 800pro.
het heeft te maken met de overschakeling van cloud naar zensdk.
Dan blijft hij schakelen tussen onbekend en zendsdk en is vanuit HA niet meer aan te spreken.
[Afbeelding]

Slechte Wifi?

Dat zou echter volgens mij enkel betekenen dat niet alles vanuit HA wordt doorgegeven, niet dat de boel weer terugschakelt naar een andere aansturing.

[Polvo176]

m-vw schreef op dinsdag 8 september 2026 @ 11:45:
[...]

Slechte Wifi?

Dat zou echter volgens mij enkel betekenen dat niet alles vanuit HA wordt doorgegeven, niet dat de boel weer terugschakelt naar een andere aansturing.

Wifi is ok, het acces punt staat er nog geen meter vandaan.
Als ik terug schakel naar cloud werkt dat ook niet meer, alleen als ik alles herstart en de batterij opnieuw in de app zet is er weer leven in te krijgen, maar schakelen naar Zensdk lijkt niet te willen.

De 1600 staat nu wel op Zensdk en werkt ook goed, mogelijk is het toch een kwestie van de juiste volgorde van instaleren.

[PASware]

Excuus voor mijn mogelijk dommige vragen.

Ik heb de 2400 AC en in Home Assistant probeer ik de Gielz integration aan de slag te krijgen, ik vraag mij alleen af hoe die weet hoe die verbinding moet maken met mijn 2400AC? Zijn Github is niet duidelijk daarover.
Ik heb de Zendure_gielz1986_global.yaml in de juiste folder geplaatst en het Plug-N-Play dashboard gebruikt en alleen maar foutmeldingen dat de 2400AC niet gevonden kan worden.

Dus hoe maakt die verbinding met mijn 2400AC?

Extra informatie:
Als ik de officiele zendure integration installeer dan komen er een hele hoop entiteiten beschikbaar, die ik weer kan gebruiken in het dashboard, echter is de benaming best wel anders dan die in de Gielz integration staat.

Ik heb bij de officiele zendure integration MQTT uitstaan

Kortom, is de officiele integration nodig om alle entiteiten beschikbaar te hebben?

[ Voor 4% gewijzigd door PASware op 08-09-2026 12:01 ]

[B-Force]

Polvo176 schreef op dinsdag 8 september 2026 @ 11:50:
[...]

Wifi is ok, het acces punt staat er nog geen meter vandaan.
Als ik terug schakel naar cloud werkt dat ook niet meer, alleen als ik alles herstart en de batterij opnieuw in de app zet is er weer leven in te krijgen, maar schakelen naar Zensdk lijkt niet te willen.

De 1600 staat nu wel op Zensdk en werkt ook goed, mogelijk is het toch een kwestie van de juiste volgorde van instaleren.

ik heb hetzelfde euvel. aansutreing houd ik daarom op 'cloud' want ZenSDK blijft timeouten... De accesspoint staat rechtboven de accu met een houten vloer er tussen. En met cloud verbinding heb ik nooit last dat hij niet bereikbaar is.

[Wai_AM]

PASware schreef op dinsdag 8 september 2026 @ 11:56:
Excuus voor mijn mogelijk dommige vragen.

Ik heb de 2400 AC en in Home Assistant probeer ik de Gielz integration aan de slag te krijgen, ik vraag mij alleen af hoe die weet hoe die verbinding moet maken met mijn 2400AC? Zijn Github is niet duidelijk daarover.
Ik heb de Zendure_gielz1986_global.yaml in de juiste folder geplaatst en het Plug-N-Play dashboard gebruikt en alleen maar foutmeldingen dat de 2400AC niet gevonden kan worden.

Dus hoe maakt die verbinding met mijn 2400AC?

Extra informatie:
Als ik de officiele zendure integration installeer dan komen er een hele hoop entiteiten beschikbaar, die ik weer kan gebruiken in het dashboard, echter is de benaming best wel anders dan die in de Gielz integration staat.

Ik heb bij de officiele zendure integration MQTT uitstaan

Kortom, is de officiele integration nodig om alle entiteiten beschikbaar te hebben?

`

Je dient die zelf in te vullen.

[R1chardTM]

PASware schreef op dinsdag 8 september 2026 @ 11:56:
Excuus voor mijn mogelijk dommige vragen.

Ik heb de 2400 AC en in Home Assistant probeer ik de Gielz integration aan de slag te krijgen, ik vraag mij alleen af hoe die weet hoe die verbinding moet maken met mijn 2400AC? Zijn Github is niet duidelijk daarover.
Ik heb de Zendure_gielz1986_global.yaml in de juiste folder geplaatst en het Plug-N-Play dashboard gebruikt en alleen maar foutmeldingen dat de 2400AC niet gevonden kan worden.

Dus hoe maakt die verbinding met mijn 2400AC?

Extra informatie:
Als ik de officiele zendure integration installeer dan komen er een hele hoop entiteiten beschikbaar, die ik weer kan gebruiken in het dashboard, echter is de benaming best wel anders dan die in de Gielz integration staat.

Ik heb bij de officiele zendure integration MQTT uitstaan

Kortom, is de officiele integration nodig om alle entiteiten beschikbaar te hebben?

Nee je moet de Gielz integratie en de officiele Zendure intergratie niet combineren. Om verbinding te maken met de omvormer moet je het IP invullen bij zendure_2400_ac_ip_adres.

[PASware]

@Wai_AM en @R1chardTM Dank!

Ik zie echter de invulvelden niet:


Als ik het blok "Configuration Basic" edit dan krijg ik het edit scherm:


Daar zie ik wel 'input_text.zendure_setting_ip_address', hier kan ik niks invullen, alleen een entiteit kiezen.
Je zou verwachten doordat het een 'input_text' is, dat je dan wel een invulscherm krijgt waar ik dan zelf mijn IP in kan vullen, maar helaas.

[apexia0087]

PASware schreef op dinsdag 8 september 2026 @ 12:32:
@Wai_AM en @R1chardTM Dank!

Ik zie echter de invulvelden niet:
[Afbeelding]

Als ik het blok "Configuration Basic" edit dan krijg ik het edit scherm:
[Afbeelding]

Daar zie ik wel 'input_text.zendure_setting_ip_address', hier kan ik niks invullen, alleen een entiteit kiezen.
Je zou verwachten doordat het een 'input_text' is, dat je dan wel een invulscherm krijgt waar ik dan zelf mijn IP in kan vullen, maar helaas.

Die Configuration basic hoef je niet te editen, dit moet je via het dashboard doen. Ik had iets soortgelijks, bleek dat ik de nl en engelse versie door elkaar had gehaald waardoor de entiteiten niet matchen. Heb toen alles eraf gegooid en opnieuw alles doorlopen. Herstart je HA ook maar is een x bijv.

[Wai_AM]

PASware schreef op dinsdag 8 september 2026 @ 12:32:
@Wai_AM en @R1chardTM Dank!

Enitities not found betekend volgens mij dat de yaml niet goed is ingeladen.

1. Make sure HEMS is disabled in the Zendure app.
2. Place Zendure_gielz1986_global.yaml from the GitHub packages folder into your Home Assistant packages folder. If it does not exist, create it.
3.Create a backup of your configuration.yaml.
4. Then edit your configuration.yaml and add the following:
homeassistant:
packages: !include_dir_named packages
5. Restart Home Assistant.
6. Optionally create the plug-n-play dashboard Go to Plug-N-Play Dashboard. Or fill in the entities below in Home Assistant and restart again.

heb je alle stappen gevolgd of heb je een stap overgeslagen?

[drice]

PASware schreef op dinsdag 8 september 2026 @ 12:32:
@Wai_AM en @R1chardTM Dank!

Ik zie echter de invulvelden niet:
[Afbeelding]

Als ik het blok "Configuration Basic" edit dan krijg ik het edit scherm:
[Afbeelding]

Daar zie ik wel 'input_text.zendure_setting_ip_address', hier kan ik niks invullen, alleen een entiteit kiezen.
Je zou verwachten doordat het een 'input_text' is, dat je dan wel een invulscherm krijgt waar ik dan zelf mijn IP in kan vullen, maar helaas.

Heb je je systeem al een herstart gegeven. Zo te zien mis je een aantal entiteiten

[Mistraller]

The_Haunted schreef op dinsdag 8 september 2026 @ 10:36:
[...]

Ik heb dezelfde situatie: een 800 plus en een 3000 mix. Ik heb in Gielz yaml de capaciteit van de mix naar 4.98 gezet. Dan is de gezamenlijke capaciteit gelijk aan de 1,92 en 8 kWh van de beide accu's. Het probleem zit hem in de aansturing van de ontlaadvermogens van 800 en 3000 watt en de verschillen in SOC.

Het is inderdaad een kwestie van geduld tot er een oplossing komt, zelf iets proberen te ontwikkelen, of...investeren en een 2e Mix erbij

Waarom gebruik je de Fireson integratie niet? Gielz is niet geschikt voor afwijkende vermogens maar bedoeld voor identieke clustertjes of standalone.

[PASware]

Wai_AM schreef op dinsdag 8 september 2026 @ 12:41:
[...]

Enitities not found betekend volgens mij dat de yaml niet goed is ingeladen.

1. Make sure HEMS is disabled in the Zendure app.
2. Place Zendure_gielz1986_global.yaml from the GitHub packages folder into your Home Assistant packages folder. If it does not exist, create it.
3.Create a backup of your configuration.yaml.
4. Then edit your configuration.yaml and add the following:
homeassistant:
packages: !include_dir_named packages
5. Restart Home Assistant.
6. Optionally create the plug-n-play dashboard Go to Plug-N-Play Dashboard. Or fill in the entities below in Home Assistant and restart again.

heb je alle stappen gevolgd of heb je een stap overgeslagen?

Het lijkt te werken. Ik heb echter geen Homewizard P1 meter in gebruik, maar de Zendure P1 meter, daarvan IP adres toegevoegd, maar dat lijkt nog niet te werken.

Ik zie wel bij Configuratie (optioneel):
Afwijkende P1 Sensor

Daar straks maar eens mee spelen

[The_Haunted]

Mistraller schreef op dinsdag 8 september 2026 @ 12:47:
[...]

Waarom gebruik je de Fireson integratie niet? Gielz is niet geschikt voor afwijkende vermogens maar bedoeld voor identieke clustertjes of standalone.

Fireson ondersteunt volgens mij de 3000 nog niet. Ik kreeg elke keer tenminste een token error

[Mscroos]

PASware schreef op dinsdag 8 september 2026 @ 13:24:
[...]

Het lijkt te werken. Ik heb echter geen Homewizard P1 meter in gebruik, maar de Zendure P1 meter, daarvan IP adres toegevoegd, maar dat lijkt nog niet te werken.

Ik zie wel bij Configuratie (optioneel):
Afwijkende P1 Sensor

Daar straks maar eens mee spelen

IP adres toevoegen werkt niet. Zendure moet apart geïnstalleerd worden als afwijkende sensor. Vervolgens de sensor naam daarvan in het Gielz dashboard plaatsen.

Ik gebruik een shelly sensor op deze manier.

[R1chardTM]

PASware schreef op dinsdag 8 september 2026 @ 13:24:
[...]

Het lijkt te werken. Ik heb echter geen Homewizard P1 meter in gebruik, maar de Zendure P1 meter, daarvan IP adres toegevoegd, maar dat lijkt nog niet te werken.

Ik zie wel bij Configuratie (optioneel):
Afwijkende P1 Sensor

Daar straks maar eens mee spelen

https://github.com/Gielz1986/Zendure-HA-zenSDK/wiki/Global-and-NL-%E2%80%90-P1-CT-meters-(API's)

[testmanager]

PASware schreef op dinsdag 8 september 2026 @ 11:56:
Kortom, is de officiele integration nodig om alle entiteiten beschikbaar te hebben?

Nee

[gast777]

DeadMetal schreef op zondag 6 september 2026 @ 18:06:
@gast777 ik merk dat sporadisch een van mijn 2 Zendures niet 'reageert'. Als de Gielz zegt dat hij moet Snel opladen of Snel ontladen, dan gaat het totaal naar grofweg 2400w in plaats van 4800w. Als ik de gielz dan in Standby zet en daarna weer opnieuw in de gewenste modus, dan pakt hij hem direct wel.

Voorbeeld van Snel ontladen:

code:

Vermogensopdracht = -4800W
Vermogensopdracht Zendure 1 = -2400W
Vermogensopdracht Zendure 2 = -2400W
Zendure 1 Vermogen Aansturing = 0W
Zendure 2 Vermogen Aansturing = -2398 W
Actief Device = Zendure 1 en 2

Is het mogelijk voor jou om in de proxy een controle in te bouwen 'of alle batterijen wel doen wat ik van ze vraag?' I.c.m. een retry-commando geven?
Aandachtspuntje bij Snel opladen is natuurlijk wel dat de batterij op een gegeven moment (als hij redelijk vol begint te raken) steeds langzamer zal opladen en zijn doelsnelheid niet meer kan halen.

Je zou tijdens dat probleem even kunnen checken of beide Zendures een inputlimit/outputlimit aangeven die correct is (niet nul). Dat kan via de debug: http://192.168.x.x:1880/endpoint/dashboard/zenproxylivedataget

Als die niet correct is, dan zal Gielz dit ook zien en automatisch een correctie geven (bij modus snel laden/ontladen).

Als die wel correct is, dan betekent dat dat de Zendure de opdracht correct heeft ontvangen, maar om een of andere reden die niet wil uitvoeren. Dat is dan niet een probleem van de proxy of Gielz, maar dat zit in de Zendure zelf. Dan zou je wellicht even de firmware daarvan up-to-date kunnen brengen en als dat niet helpt een Zendure ticket openen. De debug data (kun je ook naar een file laten wegschrijven) zal daarbij zeker helpen om te laten zien wat er gebeurde.

[hemertje]

koboy schreef op maandag 7 september 2026 @ 17:30:
[...]

Even de opa stand aan....

Perl gebruiken voor een search+replace obv een regex is hetzelfde als met een Claas 690SL met alle alternatieve invoeren op een aanhanger er achter een kratje bier gaan halen bij de supermarkt, terwijl de fiets gewoon voor de deur staat.....
Zo zien we maar weer dat AI dom is. Perl kun je niet van op aan dat het op elk Unix/Linux systeem staat, sed (stream editor) is dat wel, en pakt zo goed als dezelfde syntax. Geen idee ook waarom er een extra bash shell wordt opgestart als eerste, het is niet zo dat er speciale opties van worden gebruikt....

Zo..... Opa gaat weer met zijn geblokte flanellen sloffen in de leunstoel zitten

@koboy @martinvdm

Goed nieuws — PR #257 pakt dit al slimmer aan dan mijn voorstel. Twee keuzes:

1. Waar float(0) wél veilig is (input_number helpers, vermogensmetingen):
Standaard 0 als sensor unavailable is — geen probleem.

2. Waar float(0) gevaarlijk is (vergelijkingen, thresholds):
Daar heeft de PR een ⁠ has_value() ⁠ guard toegevoegd. In plaats van een gefabriceerde 0 te vergelijken met een limiet, wordt de hele tak overgeslagen zolang de sensor geen waarde heeft. Dat is precies wat de fout gevende template eerder ook deed — de tak werd overgeslagen door de crash, nu gebeurt dat netjes.

Kortom: jullie zorgen zijn terecht, maar PR #257 heeft ze al meegenomen.
De PR is een draft, maar nog niet reviewed door Gielz.

[NiCNCo]

Voor iedereen die de homeassistant Gielz automatisering samen met meer dan 1 zendure batterij gebruikt dmv Gast777 zendesk proxy in NodeRed.

Ik moest continu me phase bewaken als ik mijn EV wilde laden en tegelijkertijd de batterijen en daarboven op tegelijker tijd de jacuzzi wilde verwarmen in de goedkoopste uurtjes van de dag. Ik heb daarom een Dynamic Load Balancing versie gemaakt van Gast777 proxy om de batterij charge vermogens individueel per fase te downrampen doormiddel van live P1 waarden. (overigens alle credits naar Gielz en Gast777).

Voor wie ook tegen dezelfde problemen aan loopt maak er gebruik van. Alles werkt hetzelfde als de originele Gast777 proxy in NodeRed. Lees de github goed door en doe er je voordeel mee.

Link naar mijn Gitbub pagina:
https://github.com/nicopeet911/Zendure-DLB-proxy

[ Voor 5% gewijzigd door NiCNCo op 09-09-2026 01:52 ]

[Gramser]

Dat ziet er heel mooi uit en het lijkt “simpel” genoeg voor een HA-noob zoals ik. Maar “explain this to me like I’m a six-year-old”: als mijn laadpaal al DLB heeft, waarom moeten mijn batterijen dat dan ook nog hebben?

[sender]

NiCNCo schreef op woensdag 9 september 2026 @ 01:51:
Voor iedereen die de homeassistant Gielz automatisering samen met meer dan 1 zendure batterij gebruikt dmv Gast777 zendesk proxy in NodeRed.

Ik moest continu me phase bewaken als ik mijn EV wilde laden en tegelijkertijd de batterijen en daarboven op tegelijker tijd de jacuzzi wilde verwarmen in de goedkoopste uurtjes van de dag. Ik heb daarom een Dynamic Load Balancing versie gemaakt van Gast777 proxy om de batterij charge vermogens individueel per fase te downrampen doormiddel van live P1 waarden. (overigens alle credits naar Gielz en Gast777).

Voor wie ook tegen dezelfde problemen aan loopt maak er gebruik van. Alles werkt hetzelfde als de originele Gast777 proxy in NodeRed. Lees de github goed door en doe er je voordeel mee.

Link naar mijn Gitbub pagina:
https://github.com/nicopeet911/Zendure-DLB-proxy

[Afbeelding]

[Afbeelding]

Dit ziet er goed uit, mooie beschrijving en mooie (AI) plaatjes.

Ik snap je insteek, maar is dit echt een issue? Als de laadpaal al afgestemd is om de 3 fasen zelf te lezen? Een zendure gebruikt max 2000W per fase (?), bij mij zelfs maar 1000... (3x1000). Dan de normale zaken erbij en de laadpaal die naar 6A bijsteld bij hogere belasting. In dat gevals, wat is dan het voordeel van jouw beredenering?

Lees dit bericht puur als "ik wil het beter begrijpen want wellicht zie ik wat over het hoofd".

[Pakhaas]

NiCNCo schreef op woensdag 9 september 2026 @ 01:51:
Voor iedereen die de homeassistant Gielz automatisering samen met meer dan 1 zendure batterij gebruikt dmv Gast777 zendesk proxy in NodeRed.

Ik moest continu me phase bewaken als ik mijn EV wilde laden en tegelijkertijd de batterijen en daarboven op tegelijker tijd de jacuzzi wilde verwarmen in de goedkoopste uurtjes van de dag. Ik heb daarom een Dynamic Load Balancing versie gemaakt van Gast777 proxy om de batterij charge vermogens individueel per fase te downrampen doormiddel van live P1 waarden. (overigens alle credits naar Gielz en Gast777).

Voor wie ook tegen dezelfde problemen aan loopt maak er gebruik van. Alles werkt hetzelfde als de originele Gast777 proxy in NodeRed. Lees de github goed door en doe er je voordeel mee.

Link naar mijn Gitbub pagina:
https://github.com/nicopeet911/Zendure-DLB-proxy

[Afbeelding]

[Afbeelding]

Een tijd terug heb ik hier begrepen van Gielz etc dat het niet verstandig is om constant het vermogen aan te passen. Heeft te maken met het vele schrijven naar RAM ofzo en dit op termijn niet goed is voor de batterij.

Ik heb het vrij simpel opgelost met een max powercap die bijvoorbeeld op 5100w staat (heb 3 batterijen). Zodra de EV gaat laden, dan zet hij het max vermogen op 5100w, daarna weer terug naar de oude (6000w) waarde. Dit is nu voldoende voor 1x35A. Volgende week gaan wij naar 3x25A en heb de verdeling in de meterkast zo gemaakt dat alles mooi verdeeld is over 3x25A, ik denk het wel te kunnen redden daarmee. Volgend jaar ga ik alleen laden van zon overschot en speelt dit niet meer. Nachts zal er dan wel eens worden geladen met goedkoop stroom, maar dan wordt er in huis ook niet zoveel verbruikt.

[ Voor 17% gewijzigd door Pakhaas op 09-09-2026 08:04 ]

[Gramser]

Mijn automatisering zet de batterijen nu op manual, als ik de auto aan de lader koppel. Ik draai NoM met de Zendures maar wil dat zonoverschot direct de auto in gaat. Mocht ik dat net te langzaam vinden, kan ik met een slider extra Watts uit de accu gebruiken. Maar in principe doen de batterijen niks als de auto laadt. Hoe dat volgend jaar gaat, met waarschijnlijk een dynamisch contract, weet ik mog niet. Dan wil ik misschien met PHEV én batterijen wel volle bak laden… vandaar dat ik hier wel wat meer over wil weten 🙂

[Mscroos]

Gramser schreef op woensdag 9 september 2026 @ 08:16:
Mijn automatisering zet de batterijen nu op manual, als ik de auto aan de lader koppel. Ik draai NoM met de Zendures maar wil dat zonoverschot direct de auto in gaat. Mocht ik dat net te langzaam vinden, kan ik met een slider extra Watts uit de accu gebruiken. Maar in principe doen de batterijen niks als de auto laadt. Hoe dat volgend jaar gaat, met waarschijnlijk een dynamisch contract, weet ik mog niet. Dan wil ik misschien met PHEV én batterijen wel volle bak laden… vandaar dat ik hier wel wat meer over wil weten 🙂

In principe zal dan de auto gaan limiteren op basis van P1 data, althans dat doet mijn Alfen laadpaal. De laadpaal monitored wat de marge to maximale belasting is zodat een kookplaat of een zendure het geheel niet over de grenzen heen laat komen. Zendure gaat dan wel voor op auto in dit geval (zendure op max laden instelling)

Ik heb het zon overschot opgelost door een fake P1 meter op mijn laadpaal te zetten waarvan ik de waardes bepaal. als ik aan het zonneladen ben dan krijgt de laadpaal de P1 - Accu waardes. Het effect is dat als er voldoende stroom opgewekt wordt om de auto te laten starten met laden dat de auto dit overneemt (vanaf 1.4 kWh) als de opwek daaronder zit dan krijgt de accu de stroom.

[Mistraller]

Pakhaas schreef op woensdag 9 september 2026 @ 08:01:
[...]

Een tijd terug heb ik hier begrepen van Gielz etc dat het niet verstandig is om constant het vermogen aan te passen. Heeft te maken met het vele schrijven naar RAM ofzo en dit op termijn niet goed is voor de batterij.

Nom doet natuurlijk niets anders dan dit. Elke 5 seconden wisselt het vermogen en ook vaak wisselen van laden naar ontladen. Is niet anders dan bij een auto waarbij je door te remmen ook ineens gaat laden ipv ontladen.

Punt van aandacht is dat de data die in RAM staat, bij het standby zetten naar flash weggeschreven wordt. En flash is niet oneindig schrijfbaar.

Dit probleem bestaat al lang: Ik heb hier een Sunnyboy PV omvormer. Die kan ik niet sturen op vermogen; ook al zit de hardware er wel in. De ontwikkelaar van de software die ik voor het uitlezen gebruik heeft er ooit functionaliteit ingebouwd waarmee je dynamisch vermogen kon aanpassen. Dat was nu heel leuk geweest gezien afbouw saldering.... ware het niet dat de fabrikant de ontwikkelaar heeft teruggefloten want het flash memory van die omvormer kon zoveel schrijfacties niet aan. (En dat kon niet naar RAM geschreven worden) Toen is het er weer uitgehaald.

[R.K]

in december gaan we verhuizen naar ons nieuwe huis, daar hangt deze slimme meter in de kast, een GPRS versie. Is deze geschikt om met HA (gielz) te werken icm de Solarflow 2400AC

[m-vw]

Mistraller schreef op woensdag 9 september 2026 @ 10:38:
[...]

Nom doet natuurlijk niets anders dan dit. Elke 5 seconden wisselt het vermogen en ook vaak wisselen van laden naar ontladen. Is niet anders dan bij een auto waarbij je door te remmen ook ineens gaat laden ipv ontladen.

Punt van aandacht is dat de data die in RAM staat, bij het standby zetten naar flash weggeschreven wordt. En flash is niet oneindig schrijfbaar.

Dit probleem bestaat al lang: Ik heb hier een Sunnyboy PV omvormer. Die kan ik niet sturen op vermogen; ook al zit de hardware er wel in. De ontwikkelaar van de software die ik voor het uitlezen gebruik heeft er ooit functionaliteit ingebouwd waarmee je dynamisch vermogen kon aanpassen. Dat was nu heel leuk geweest gezien afbouw saldering.... ware het niet dat de fabrikant de ontwikkelaar heeft teruggefloten want het flash memory van die omvormer kon zoveel schrijfacties niet aan. (En dat kon niet naar RAM geschreven worden) Toen is het er weer uitgehaald.

Volgens mij heeft mijn Solpanet omvormer ook een mogelijkheid om het vermogen te beperken, enkel zit dat ergens in het installateursmenu. Dat is voor hier OT, maar wel iets waar ik nog naar wil gaan kijken voor volgend jaar.

[MrAngry]

R.K schreef op woensdag 9 september 2026 @ 10:48:
[Afbeelding]

in december gaan we verhuizen naar ons nieuwe huis, daar hangt deze slimme meter in de kast, een GPRS versie. Is deze geschikt om met HA (gielz) te werken icm de Solarflow 2400AC

Dat is een DSMR 4 meter, daarbij heeft je P1 meter een eigen voeding nodig. Verder werkt het hetzelfde als een DSMR5 meter.

[R.K]

MrAngry schreef op woensdag 9 september 2026 @ 10:51:
[...]

Dat is een DSMR 4 meter, daarbij heeft je P1 meter een eigen voeding nodig. Verder werkt het hetzelfde als een DSMR5 meter.

Een eigen voeding gebruikte ik al dus dat is geen probleem. geeft deze meter met dezelfde intervallen in tijd zijn informatie als de DSMR5 meter?

[Ben(V)]

Nee een DSMR 4 meter geeft elke 10 Seconden data uit via de p1 en een DSMR doet dat elke seconde.

Bij wisselende belasting of wisselde zon werkt dat niet lekker, je kunt dan beter een shelly nemen met CT spoelen.
Die meter wordt overigens wel een keer vervangen, maar omdat de netbeheerder er nog heel veel moet vervangen weet niemand wanneer.

[Erik1]

Mistraller schreef op woensdag 9 september 2026 @ 10:38:
Punt van aandacht is dat de data die in RAM staat, bij het standby zetten naar flash weggeschreven wordt. En flash is niet oneindig schrijfbaar.

Zendure heeft hier ook een instelling voor gemaakt in de accu's: smartMode

smartMode Behavior

• 1: Parameters are not written to flash
• Device restores previous flash values after reboot
• Recommended for frequent configuration changes

[manusjevanalles]

Erik1 schreef op woensdag 9 september 2026 @ 11:30:
[...]

Zendure heeft hier ook een instelling voor gemaakt in de accu's: smartMode

smartMode Behavior

• 1: Parameters are not written to flash
• Device restores previous flash values after reboot
• Recommended for frequent configuration changes

Wanneer is het verstandig deze modus in te stellen?

[winwiz]

MrAngry schreef op woensdag 9 september 2026 @ 10:51:
[...]

Dat is een DSMR 4 meter, daarbij heeft je P1 meter een eigen voeding nodig. Verder werkt het hetzelfde als een DSMR5 meter.

Die wordt binnenkort toch sowieso vervangen?

[maartend]

Edit, ja het is idd sensor.woonkamer_p1_meter_battery_group_target_power

Ik ben wat aan het aanpassen met automations. Maar ik ben op zoek naar een entitie die ik niet kan vinden.


Ik heb een Homewizard p1 meter, die werkt gewoon goed in HA.


Maar de entitie die ik zoek is het equivalent van de volgende ; Gebruik 'Netto Export' in plaats van pure zonneproductie: Het is vaak slimmer om te kijken naar de stroom die je daadwerkelijk over hebt (sensor.power_export of je P1-meter). Als je zonnepanelen 900W leveren, maar je vaatwasser verbruikt 500W, heb je immers maar 400W over voor de batterijen.
sensor.solarpower_production # Vervang door jouw zonnepanelen-sensor (in Watts)

Maar ik krijg hem dus niet gevonden. Heb al op van alles gezocht bij entities in HA.

Ik heb wel deze sensor ; sensor.p1_meter_energy_export_tariff_2 maar daar staat dus tarief in en geen power.

Of deze sensor.woonkamer_p1_meter_battery_group_target_power


Tips?

[ Voor 23% gewijzigd door maartend op 09-09-2026 15:05 ]