Zendure producten in Home Assistant integreren deel 2

[gielz]

R.K schreef op maandag 5 januari 2026 @ 15:00:
Ik heb een automatisering gemaakt die mijn batterij onder een bepaalde spread op standby zet of niet. Maar het is mij niet geheel duidelijk of ik nu de 'dynamische spread indicatie' daar voor moet aanhouden of de 'dynamische spread indicatie NOM'

Ik zie in mijn dashboard dat er verschillende waardes staan bij de indicaties. Wie kan mij duidelijkheid geven welke ik het best als meetpunt kan gebruiken voor mijn automatisering?

Dynamisch Spread Indicatie is de berekening van je goedkoopste en duurste uren. Pak je de NOM variant dan kijkt hij pas naar het duurste uur na de eerste goedkoopste uur. Hoe ga je de batterij exact laten draaien? Goedkoop laden, Duur NOM en daar tussen Standby?

[R.K]

gielz schreef op maandag 5 januari 2026 @ 15:13:
[...]


Hoe ga je de batterij exact laten draaien? Goedkoop laden, Duur NOM en daar tussen Standby?

Bij mij draait hij met een spread van 22% daaronder standby daarboven Dynamisch NOM. Daartussen niets. Dus wat is dan de beste optie? spread of spread NOM?

[gielz]

R.K schreef op maandag 5 januari 2026 @ 15:43:
[...]


Bij mij draait hij met een spread van 22% daaronder standby daarboven Dynamisch NOM. Daartussen niets. Dus wat is dan de beste optie? spread of spread NOM?

Ik zou dan voor de reguliere spread gaan omdat de ander specifiek bedoelt is om alle uren NOM te draaien en niet alleen op de duurste momenten.

Als het goed is zal er binnenkort ook een modus Dynamisch NOM (Duur) zijn. Die alles gewoon automatisch voor je doet. Op de goedkope momenten laden en laden van overschot en daarna op de duurste uren dit als NOM in zetten.

[R.K]

Bedankt voor je antwoord en uitleg

[gielz]

Gielz Februari test (deel 2)

Op de valreep toch maar even de 2 nieuwe modus opties toegevoegd voor de Februari test.
Dynamisch NOM (Duur) en Dynamisch Handelen

Voor de gene die dit willen testen; https://github.com/Gielz1...1986-Februari-2026-update

Graag alle bugs via DM of via Github. Intern zijn alle modus opties getest.

Releasenotes ruw

2 nieuwe modus opties

Dynamisch NOM (Duur) en Dynamisch Handelen

3 nieuw instelbare entiteiten

Oplaadmarge
Standaard in HEMS word er een marge aangehouden van 50 watt. Hierbij houd de huidige versie 40 watt aan wat dus vanaf nu instelbaar is van 0 tot 50 watt via deze entiteit. Handig in de winter als je alle prik binnen wilt halen.

Ontlaadmarge
Bij iedereen wel verschillend. De ene wilt net wat meer ontladen dan gevraagd word om echt 0 te importeren en de ander juist niet. Nu ook instelbaar van 0 tot 50 watt. In de huidige versie is dit 2 watt.

Standby vertraging
Een doorn in het oog. Ik zie bij andere aansturingen dat de Smartmode op 0 gezet word direct als het vermogen ook op 0 watt staat. Zelf was ik hier geen voorstander van en zie dit bijvoorbeeld ook niet terug bij de Homewizard PIB. Vandaar nu netjes instelbaar van 5-30 minuten. Zodra er dan xx minuten geen activiteit is zal hij smartmode op 0 zetten om de "waakvlam" zoals ik hem zelf noem uit te zetten. Hierna toont een KWH MID meter 0 watt maar uiteraard is er nog wat vermogen nodig intern voor de BMS.

De modus "Standby" wat handmatig was deed dit al correct en altijd direct wat ongewijzigd is. Nu doet de gehele aansturing mee zoals NOM, Slim Opladen etc.

Kleine aanpassingen

SOC bescherming
Gaat nu alleen aan de slag 2 uur na zonsopkomst en 2 uur voor zonsondergang

Handmatig modus
Bij aanpassing van vermogen alleen nog elke 4 seconden via de restapi. Dit was voorheen direct wat bij spammen de api om zeep hielp.

Restcommands
Aanpassing voor nodered doorgevoerd

[Leguan]

gielz schreef op maandag 5 januari 2026 @ 20:42:

Gielz Februari test (deel 2)

Op de valreep toch maar even de 2 nieuwe modus opties toegevoegd voor de Februari test.
Dynamisch NOM (Duur) en Dynamisch Handelen

Voor de gene die dit willen testen; https://github.com/Gielz1...1986-Februari-2026-update

Graag alle bugs via DM of via Github. Intern zijn alle modus opties getest.

Releasenotes ruw

2 nieuwe modus opties

Dynamisch NOM (Duur) en Dynamisch Handelen
[Afbeelding]

3 nieuw instelbare entiteiten

Oplaadmarge
Standaard in HEMS word er een marge aangehouden van 50 watt. Hierbij houd de huidige versie 40 watt aan wat dus vanaf nu instelbaar is van 0 tot 50 watt via deze entiteit. Handig in de winter als je alle prik binnen wilt halen.

Ontlaadmarge
Bij iedereen wel verschillend. De ene wilt net wat meer ontladen dan gevraagd word om echt 0 te importeren en de ander juist niet. Nu ook instelbaar van 0 tot 50 watt. In de huidige versie is dit 2 watt.

Standby vertraging
Een doorn in het oog. Ik zie bij andere aansturingen dat de Smartmode op 0 gezet word direct als het vermogen ook op 0 watt staat. Zelf was ik hier geen voorstander van en zie dit bijvoorbeeld ook niet terug bij de Homewizard PIB. Vandaar nu netjes instelbaar van 5-30 minuten. Zodra er dan xx minuten geen activiteit is zal hij smartmode op 0 zetten om de "waakvlam" zoals ik hem zelf noem uit te zetten. Hierna toont een KWH MID meter 0 watt maar uiteraard is er nog wat vermogen nodig intern voor de BMS.

De modus "Standby" wat handmatig was deed dit al correct en altijd direct wat ongewijzigd is. Nu doet de gehele aansturing mee zoals NOM, Slim Opladen etc.

Kleine aanpassingen

SOC bescherming
Gaat nu alleen aan de slag 2 uur na zonsopkomst en 2 uur voor zonsondergang

Handmatig modus
Bij aanpassing van vermogen alleen nog elke 4 seconden via de restapi. Dit was voorheen direct wat bij spammen de api om zeep hielp.

Restcommands
Aanpassing voor nodered doorgevoerd

Mooie toevoeging die nieuwe modus Dynamisch NOM (duur)! Hopelijk met dezelfde resultaten als de automatisering die ik hier gister heb gedeeld en vandaag (dag met veel spread) het volgende resultaat heeft opgeleverd:

[edjes]

Haha, @gielz , heb ik dat net allemaal bij elkaar zitten programmeren ;-)
Dank! ik ga het testen!!

[edjes]

@gielz Is het een idee om bij elke modus je bedoelde gebruik te benoemen?
Bijv:
- NOM voor de zomer, zonnepanelen vullen, altijd NOM bij geen zon-overschot of handmatig vullen
- Dyn NOM hybride NOM, waar alleen bijladen mogelijk is, verder zelfde als NOM, altijd NOM
- Dyn NOM duur; zomer met weinig panelen, of winter, en bij kleine batterij om het meeste eruit te halen; alleen laden op groene tijden, ontladen op rode tijden

Zoiets?
Ik begin het nu langzaam allemaal te snappen wat je geschreven hebt en ben zelf aan het bijschuren voor mijn eigen situatie, echter word door je ingehaald met dyn NOM duur; mooie toevoeging!

[ Voor 5% gewijzigd door edjes op 05-01-2026 21:41 ]

[gielz]

edjes schreef op maandag 5 januari 2026 @ 21:40:
@gielz Is het een idee om bij elke modus je bedoelde gebruik te benoemen?
Bijv:
- NOM voor de zomer, zonnepanelen vullen, altijd NOM bij geen zon-overschot of handmatig vullen
- Dyn NOM hybride NOM, waar alleen bijladen mogelijk is, verder zelfde als NOM, altijd NOM
- Dyn NOM duur; zomer met weinig panelen, of winter, en bij kleine batterij om het meeste eruit te halen; alleen laden op groene tijden, ontladen op rode tijden

Zoiets?
Ik begin het nu langzaam allemaal te snappen wat je geschreven hebt en ben zelf aan het bijschuren voor mijn eigen situatie, echter word door je ingehaald met dyn NOM duur; mooie toevoeging!

Zeker een goed idee, ik zal dit in de readme opnemen zodra de update op de release github staat.

[DrNickB]

janssuhhh schreef op maandag 5 januari 2026 @ 13:16:
[...]


Ja dat kan ik inderdaad ook op basis van die entiteiten en dat zie ik als een tussenoplossing.
Voor nu kan ik eenvoudig het totale laadvermogen verlagen, maar uiteindelijk wil je dat alleen inleveren wat echt noodzakelijk is en niet meer dan dat.
En juist dat laatste ben ik nog niet achter hoe ik dat op een elegante wijze kan bereiken.

Even een gekke gedachte, en sorry als dit niet kan, maar schiet zo in mijn hoofd.
Het meten van hoeveelheid verbruik op je fase is te doen, als je weel welke Zendure je hierop hebt aangesloten,
zou je via een helper kunnen berekenen hoeveel je Jacuzzi en/of andere verbruikers verbruiken op dat moment. (fase verbruik - zendureX verbruik = rest verbruik)
Misschien als met een automation: als Rest verbruik > xxx W for 30sec; set oplaadlimit zendureX naar xxx Watt
en dan weer terug als verbruik gedaald is.
En oplaad limiet dan een veilige marge lager dan de max van je stoppenkast uiteraard.

Dan kunnen je rest van automatiseringen blijven draaien, je limiteerd alleen die ene zendure via zijn max oplaad snelheid.
Wat weer geen invloed heeft op leveren.

Edit: Ik weet alleen niet 100% zeker of de oplaad limit in te stellen is via een commando

[ Voor 3% gewijzigd door DrNickB op 05-01-2026 23:34 ]

[Jerryvh]

Goede morgen,
Ik heb 3 hypers (cluster, 3x4 AB2000S) die niets anders doen dan surplus van de zonnepanelen stockeren en NOM draaien. Settings 100%-20%. Tot volle tevredenheid; enige interventie die ik doe in deze wintermaanden is op het eind van een zonnige dag (maar net onvoldoende om de 100% te bereiken) wat extra "bijladen" van het net tot 100%, om aldus een calibratie te forceren.
Nu merk ik dat, zelfs mét deze regelmatige calibraties, de ontlaad% tussen de 3 torens snel uiteen lopen - vermoedelijk omdat de ondergrens niet bij elk dezelfde is.
Ik zou dus meer inzicht willen krijgen in de effectieve SoC, om die ondergrens zonder gevaar te benaderen. En daarvoor heb ik dus HA nodig. Echter, ik ben hoegenaamd niet vertrouwd met deze materie, en de handleidingen schrikken me danig af.

Ik zoek dus iemand die me wil helpen HA voor de Zendure SoC Monitoring op te zetten - draaiend op een Synology NAS. Ben bereid een billijke vergoeding te betalen.

[gielz]

Jerryvh schreef op dinsdag 6 januari 2026 @ 06:27:
Goede morgen,
Ik heb 3 hypers (cluster, 3x4 AB2000S) die niets anders doen dan surplus van de zonnepanelen stockeren en NOM draaien. Settings 100%-20%. Tot volle tevredenheid; enige interventie die ik doe in deze wintermaanden is op het eind van een zonnige dag (maar net onvoldoende om de 100% te bereiken) wat extra "bijladen" van het net tot 100%, om aldus een calibratie te forceren.
Nu merk ik dat, zelfs mét deze regelmatige calibraties, de ontlaad% tussen de 3 torens snel uiteen lopen - vermoedelijk omdat de ondergrens niet bij elk dezelfde is.
Ik zou dus meer inzicht willen krijgen in de effectieve SoC, om die ondergrens zonder gevaar te benaderen. En daarvoor heb ik dus HA nodig. Echter, ik ben hoegenaamd niet vertrouwd met deze materie, en de handleidingen schrikken me danig af.

Ik zoek dus iemand die me wil helpen HA voor de Zendure SoC Monitoring op te zetten - draaiend op een Synology NAS. Ben bereid een billijke vergoeding te betalen.

Ik zou je toch adviseren om het zelf te gaan ontdekken. Want stel je laat het netjes allemaal installeren op een Synology en het gaat stuk bij een update dan ben je weer terug bij af. Het enigste wat je nodig hebt is VM op je Synology en een handleiding; https://community.home-as...al-machine-manager/281608

Je kunt er ook voor kiezen om een HA Green te kopen die is volledig panklaar.

[Jerryvh]

HA op de Synology krijg ik draaiend hoor (Docker); maar wat daarna moet gebeuren is mij onbekend.

[koboy]

Jerryvh schreef op dinsdag 6 januari 2026 @ 10:52:
HA op de Synology krijg ik draaiend hoor (Docker); maar wat daarna moet gebeuren is mij onbekend.

Begin met het toevoegen van een P1 meter, komt er een mooi energie dashboard bij en krijg je ondertussen ook een beetje gevoel van hoe het in elkaar zit. Daarna vooral de installatie handelingen van de integraties (plugins) volgen, kan niet veel mee misgaan. Ergste wat er kan gebeuren is dat je de docker container weg moet gooien en opnieuw beginnen.

[janssuhhh]

DrNickB schreef op maandag 5 januari 2026 @ 23:21:
[...]

Even een gekke gedachte, en sorry als dit niet kan, maar schiet zo in mijn hoofd.
Het meten van hoeveelheid verbruik op je fase is te doen, als je weel welke Zendure je hierop hebt aangesloten,
zou je via een helper kunnen berekenen hoeveel je Jacuzzi en/of andere verbruikers verbruiken op dat moment. (fase verbruik - zendureX verbruik = rest verbruik)
Misschien als met een automation: als Rest verbruik > xxx W for 30sec; set oplaadlimit zendureX naar xxx Watt
en dan weer terug als verbruik gedaald is.
En oplaad limiet dan een veilige marge lager dan de max van je stoppenkast uiteraard.

Dan kunnen je rest van automatiseringen blijven draaien, je limiteerd alleen die ene zendure via zijn max oplaad snelheid.
Wat weer geen invloed heeft op leveren.

Edit: Ik weet alleen niet 100% zeker of de oplaad limit in te stellen is via een commando

Helemaal geen gekke gedachte! Mooie duw in de goede richting, thanks!

Uitrekenen hoeveel de Zendure omlaag moet, kan ik inderdaad wel middels helpers (faseX_verbruik+500w-ZendureX_verbruik), dan zit er zelfs een buffertje bij om niet continu volle bak over de fase te gooien.
Dan kan ik de specifieke Zendure wel in een andere fasegroup zetten, maar helaas zijn die maar beperkt tot; 800w, 1200w, 2000w, 2400w en 3600w. En die limiet geldt dan voor alle devices in die groep bij elkaar.

Voor nu kan ik daarmee spelen omdat het maar 1 fase betreft waar ik dit soms zie, maar in de toekomst voorzie ik de andere fasen ook wel te moeten bijsturen.

De parameter "chargeMaxLimit" is read-only, zover ik kan zien. Als ik die nou zou kunnen aanpassen, dan ben ik er volgens mij

[c0mplex1]

janssuhhh schreef op dinsdag 6 januari 2026 @ 14:25:
De parameter "chargeMaxLimit" is read-only, zover ik kan zien. Als ik die nou zou kunnen aanpassen, dan ben ik er volgens mij

De parameter "chargeMaxLimit" is R/W, en dus zelf in te stellen.

[gielz]

Nieuwe update voor de zenSDK https://github.com/Zendure/zenSDK voor wat het waard is;

[Taro]

janssuhhh schreef op zondag 4 januari 2026 @ 16:17:
Ik heb nu ongeveer 2 maanden 4x 2400AC staan en lees al een tijdje mee in dit topic.

Hier gebruik ik de FireSon integratie en ben tot nu toe heel tevreden. Sinds de laatste update werkt ook het excluden van devices met een actieve off-grid poort, perfect. Keurig +/- 0kw!

Zelf probeer ik het een en ander te automatiseren, want het moet ook interessant blijven om met dit spul te werken en de boel steeds slimmer te maken 😉.
Daarvoor laad ik bijvoorbeeld in de goedkope uren met totaal 8400w (3x 2400w en 1x 1200w ivm C-ratings), verdeeld over de 3x25A fasen. Dat gaat allemaal goed, maar op 1 fase zitten 2 grote verbruikers, jacuzzi en vaatwasser, die samen met de 2400AC ruim 6800w trekken. Dat is voor 25A aansluiting een beetje veel van het goede (overschrijding van bijna 20%...).
De jacuzzi gaat verwarmen wanneer hij dat nodig acht en is niet te automatiseren helaas.
De vaatwasser probeer ik zelf goed te timen, maar niet iedereen in het huishouden heeft daar een boodschap aan. Dus soms gaat die aan, terwijl de accu's volle bak laden en dan ook de jacuzzi aanspringt.

Nu is de vraag, hoe ik ervoor kan zorgen dat Home Assistant met de FireSon integratie, samen met de gegevens van de P1-meter (HW), de laadsnelheid omlaag gooit wanneer beide grootverbruikers onverhoopt tegelijk aan gaan.

Zelf kan ik makkelijk een automatisering maken die het totale vermogen van 8400w naar beneden schroeft, maar dan ga ik op alle fasen inleveren.
Wat ik eigenlijk zou willen bereiken is dat ik alleen op de fase met de overschrijding, de laadsnelheid beperk.

Iemand van jullie daar al iets voor geschreven?
Of misschien zie ik gewoon een super simpele oplossing over het hoofd... Iets met; te lang blindstaren op 1 probleem..

Kan je wel de voeding van de jacuzzi meten/onderbreken? Als je hem kunt meten en je weet welke 2400AC('s) op diezelfde fase zitten, dan kan je het vermogen van die 1-2x 2400AC verlagen door een ZenSDK commando. Is de jacuzzi klaar, dan verhoog je het vermogen weer. En als je de voeding kunt onderbreken kan je zelf bepalen wanneer die mag opwarmen.

[gielz]

Wellicht wel de moeite waard om te melden hier. Bij het testen van de Gielz automatisering liepen wij er tegen aan dat er blijkbaar verschillende soorten 2400 AC omvormers in omloop zijn waarbij het standby gedrag anders is

Issue is bij de huidige firmware en de vorige firmware.

Meeste omvormers
Smartmode zet je op 0 (0 watt opladen/ontladen) dan stopt meteen de hele omvormer aan de DC en AC kant en gaat het standby vermogen naar 0,2 kwh per dag. (te zien via een externe meting)

Klein aantal omvormers
Smartmode zet je op 0 (0 watt opladen/ontladen) dan gaat hij een tijdje 30 watt verbruiken aan de AC kant waardoor de Smartmode constant naar 1 gaat omdat het nooit 0 watt word. Hierdoor is het standby verbruik aanzienlijk hoger omdat hij nooit echt naar standby gaat. Het standby verbruik gaat hierdoor al snel over de 1,00 kwh per dag.

Screenshot is van @martinvdm

*Geel is DC gemeten, Blauw is AC gemeten via de API.


*Na aanpassing

[martinvdm]

Dank voor je uitgebreide onderzoek en goed dat we er samen uitgekomen zijn.

[arieh]

gielz schreef op donderdag 8 januari 2026 @ 09:45:
Wellicht wel de moeite waard om te melden hier. Bij het testen van de Gielz automatisering liepen wij er tegen aan dat er blijkbaar verschillende soorten 2400 AC omvormers in omloop zijn waarbij het standby gedrag anders is

Issue is bij de huidige firmware en de vorige firmware.

Meeste omvormers
Smartmode zet je op 0 (0 watt opladen/ontladen) dan stopt meteen de hele omvormer aan de DC en AC kant en gaat het standby vermogen naar 0,2 kwh per dag. (te zien via een externe meting)

Klein aantal omvormers
Smartmode zet je op 0 (0 watt opladen/ontladen) dan gaat hij een tijdje 30 watt verbruiken aan de AC kant waardoor de Smartmode constant naar 1 gaat omdat het nooit 0 watt word. Hierdoor is het standby verbruik aanzienlijk hoger omdat hij nooit echt naar standby gaat. Het standby verbruik gaat hierdoor al snel over de 1,00 kwh per dag.

Screenshot is van @martinvdm
[Afbeelding]
*Geel is DC gemeten, Blauw is AC gemeten via de API.

[Afbeelding]
*Na aanpassing

aparte constatering.....is dit gedrag op te lossen middels aanpassing in de HA scripting?

[gielz]

arieh schreef op donderdag 8 januari 2026 @ 10:25:
[...]

aparte constatering.....is dit gedrag op te lossen middels aanpassing in de HA scripting?

Zeker, mocht je het ervaren dan zou je dit kunnen melden op de Zendure HA github wanneer je deze gebruikt. Bij mijn variant is dit opgelost in de aankomende versie. Denk zelf dat het echt maar een klein aantal omvormers zijn.

[Taro]

gielz schreef op donderdag 8 januari 2026 @ 09:45:
Wellicht wel de moeite waard om te melden hier. Bij het testen van de Gielz automatisering liepen wij er tegen aan dat er blijkbaar verschillende soorten 2400 AC omvormers in omloop zijn waarbij het standby gedrag anders is

Ik heb hier thuis inderdaad 2 verschillende versies staan. Te herkennen aan:

1. Vooraan tussen de koelribben wel/niet een rechthoekige rand
2. Uitstulping Wifi is kleiner/groter

Maar ik zie in gedrag volgens mij geen verschil. Zal het eens in de gaten houden.

[janssuhhh]

c0mplex1 schreef op dinsdag 6 januari 2026 @ 14:35:
[...]

De parameter "chargeMaxLimit" is R/W, en dus zelf in te stellen.

Niet via de Zendure-HA (FireSon) integratie toch? Of doe ik iets verkeerd waardoor deze alleen maar bruikbaar is als RO-entiteit?

Taro schreef op woensdag 7 januari 2026 @ 18:03:
[...]

Kan je wel de voeding van de jacuzzi meten/onderbreken? Als je hem kunt meten en je weet welke 2400AC('s) op diezelfde fase zitten, dan kan je het vermogen van die 1-2x 2400AC verlagen door een ZenSDK commando. Is de jacuzzi klaar, dan verhoog je het vermogen weer. En als je de voeding kunt onderbreken kan je zelf bepalen wanneer die mag opwarmen.

Ja die voeding kan ik meten en onderbreken, alleen dat laatste is geen optie. De jacuzzi gaat bij een powerfailure eerst in safe-mode en dan moet ik er fysiek naartoe om hem weer te starten

Die ZenSDK is de restful-api die Zendure-HA ook gebruikt? Overruled de integratie die dan niet als ik het vermogen omlaag gooi? Of doel jij ook op die chargeMaxLimit? Want dan moet ik echt even verdiepen in de ZenSDK en hoe ik die parameter dan kan aanpassen.

[gielz]

janssuhhh schreef op donderdag 8 januari 2026 @ 15:10:
[...]


Niet via de Zendure-HA (FireSon) integratie toch? Of doe ik iets verkeerd waardoor deze alleen maar bruikbaar is als RO-entiteit?

In de Zendure HA gaat het via Fusegroups en je vult zelf de harde limieten in bij het installeren van je batterij via de app. Maar je kunt uiteraard altijd zelf een commando sturen via de API om dit te veranderen;
gielz in "Zendure producten in Home Assistant integreren deel 2"

[KikkerMario]

gielz schreef op donderdag 8 januari 2026 @ 15:36:
[...]


Maar je kunt uiteraard altijd zelf een commando sturen via de API om dit te veranderen;
gielz in "Zendure producten in Home Assistant integreren deel 2"

In mijn ervaring werkte dit geweldig voor de ontlaadlimiet (beter dan de app, want in de app kan je alleen veelvouden van 100 W invoeren), maar werkt het maar tijdelijk eventjes voor de laadlimiet. Die werd al snel weer overschreven door de HA-integratie (Zendure / Fireson).

[Jan-tweak]

gielz schreef op donderdag 8 januari 2026 @ 09:45:
Wellicht wel de moeite waard om te melden hier. Bij het testen van de Gielz automatisering liepen wij er tegen aan dat er blijkbaar verschillende soorten 2400 AC omvormers in omloop zijn waarbij het standby gedrag anders is

Even een mogelijk domme vraag, kun je ook van buiten zien bv via s/n of je een dergelijke speciale omvormer hebt en zou je deze mogelijk bij Zendure kunnen omruilen.

Issue is bij de huidige firmware en de vorige firmware.

Meeste omvormers
Smartmode zet je op 0 (0 watt opladen/ontladen) dan stopt meteen de hele omvormer aan de DC en AC kant en gaat het standby vermogen naar 0,2 kwh per dag. (te zien via een externe meting)

Klein aantal omvormers
Smartmode zet je op 0 (0 watt opladen/ontladen) dan gaat hij een tijdje 30 watt verbruiken aan de AC kant waardoor de Smartmode constant naar 1 gaat omdat het nooit 0 watt word. Hierdoor is het standby verbruik aanzienlijk hoger omdat hij nooit echt naar standby gaat. Het standby verbruik gaat hierdoor al snel over de 1,00 kwh per dag.

Screenshot is van @martinvdm
[Afbeelding]
*Geel is DC gemeten, Blauw is AC gemeten via de API.

[Afbeelding]
*Na aanpassing

[Taro]

Jan-tweak schreef op donderdag 8 januari 2026 @ 18:38:
[...]
Even een mogelijk domme vraag, kun je ook van buiten zien bv via s/n of je een dergelijke speciale omvormer hebt en zou je deze mogelijk bij Zendure kunnen omruilen.

[...]

Ik heb 2 stuks uit de eerste batch:
HOA1NPMCN07XXXX
HOA1NPMCN07XXXX

En 1 uit een latere batch:
HOA1NPN3N20XXXX

Hoe ziet jouw SN er uit minus de laatste 4 digits?

[martinvdm]

Hier dus een 2400 met het genoemde stand-by verbruik. Serial
Serial Number : HOA1NPN4N23XXXX
@gielz om nog wat extra context te scheppen. Begrijp ik het goed dat er dus een serie 2400s zijn die wel naar stand-by 0 watt schakelen en dus een serie die dit niet doet en dus verhoogd stand-by verbruik opeisen? En dit heeft dus te maken met de SmartMode variabele die bij de ene serie wel gezet wordt en bij de andere niet?

[geert1992]

martinvdm schreef op donderdag 8 januari 2026 @ 19:46:
Hier dus een 2400 met het genoemde stand-by verbruik. Serial
Serial Number : HOA1NPN4N23XXXX
@gielz om nog wat extra context te scheppen. Begrijp ik het goed dat er dus een serie 2400s zijn die wel naar stand-by 0 watt schakelen en dus een serie die dit niet doet en dus verhoogd stand-by verbruik opeisen? En dit heeft dus te maken met de SmartMode variabele die bij de ene serie wel gezet wordt en bij de andere niet?

Hier dus ook een HOA1NPN4N23xxxx, kan ik iets testen voor je?

[martinvdm]

geert1992 schreef op donderdag 8 januari 2026 @ 19:49:
[...]

Hier dus ook een HOA1NPN4N23xxxx, kan ik iets testen voor je?

Voor mij niet bijzonder, immers zoals ik eerder schreef werkt de nieuwe versie van Gielz goed omdat deze het stand-by gebruik wel naar 0 zet.
Wellicht kun je bij jezelf nagaan of je in stand-by stand nog steeds verbruik ziet op de sensor.zendure_2400_ac_vermogen_export_dc of je soc dus sneller dan normaal ziet leeglopen.

[geert1992]

martinvdm schreef op donderdag 8 januari 2026 @ 19:56:
[...]

Voor mij niet bijzonder, immers zoals ik eerder schreef werkt de nieuwe versie van Gielz goed omdat deze het stand-by gebruik wel naar 0 zet.
Wellicht kun je bij jezelf nagaan of je in stand-by stand nog steeds verbruik ziet op de sensor.zendure_2400_ac_vermogen_export_dc of je soc dus sneller dan normaal ziet leeglopen.

Dus even een report sturen met smart mode op 1? En kijken wat hij doet? Wel eens opgevallen dat hij met smartmode aan blijft laden, in mijn hoofd was dat alleen bij ontladen.

[gielz]

martinvdm schreef op donderdag 8 januari 2026 @ 19:46:
Hier dus een 2400 met het genoemde stand-by verbruik. Serial
Serial Number : HOA1NPN4N23XXXX
@gielz om nog wat extra context te scheppen. Begrijp ik het goed dat er dus een serie 2400s zijn die wel naar stand-by 0 watt schakelen en dus een serie die dit niet doet en dus verhoogd stand-by verbruik opeisen? En dit heeft dus te maken met de SmartMode variabele die bij de ene serie wel gezet wordt en bij de andere niet?

Klopt mijn omvormer gaat van smartmode 1 naar 0 direct uit zonder enig vermogen. Op zich geen ramp dat dit bij jou en @dennisdew16 anders gaat want wij hebben het nu gewoon netjes opgelost.

[Jan-tweak]

Taro schreef op donderdag 8 januari 2026 @ 18:43:
[...]

Ik heb 2 stuks uit de eerste batch:
HOA1NPMCN07XXXX
HOA1NPMCN07XXXX

En 1 uit een latere batch:
HOA1NPN3N20XXXX

Hoe ziet jouw SN er uit minus de laatste 4 digits?

Mijn SF 2400 AC heeft de volgende s/n:
Model : SolarFlow 2400 AC
Serienummer : HOA1NPN4N23xxxx

[edjes]

Ik krijg in Gielz code value_json errors, omdat ik eea blijkbaar niet via mqtt laat lopen.
Error rendering icon template for sensor.zendure_2400_ac_modus: UndefinedError: 'value_json' is undefined
Wat is een handige oplossing? Hoe laat ik via mqtt lopen?
Het werkt allemaal wel naar tevredenheid ;-) dus geen hoge nood om het aan te passen.

[ Voor 41% gewijzigd door edjes op 10-01-2026 11:41 ]

[gielz]

edjes schreef op zaterdag 10 januari 2026 @ 11:33:
Ik krijg in Gielz code value_json errors, omdat ik eea blijkbaar niet via mqtt laat lopen.
Error rendering icon template for sensor.zendure_2400_ac_modus: UndefinedError: 'value_json' is undefined
Wat is een handige oplossing? Hoe laat ik via mqtt lopen?
Het werkt allemaal wel naar tevredenheid ;-) dus geen hoge nood om het aan te passen.

Deze aansturing draait via RESTful en niet via MQTT. Maar het probleem betreft het renderen van het icoontje wat wel goed gaat aan de voorkant. Ik zal even kijken of ik de onnodige error kan wegwerken.

Gaat iig niets mis in de aansturing.

[martinvdm]

edjes schreef op zaterdag 10 januari 2026 @ 11:33:
Ik krijg in Gielz code value_json errors, omdat ik eea blijkbaar niet via mqtt laat lopen.
Error rendering icon template for sensor.zendure_2400_ac_modus: UndefinedError: 'value_json' is undefined
Wat is een handige oplossing? Hoe laat ik via mqtt lopen?
Het werkt allemaal wel naar tevredenheid ;-) dus geen hoge nood om het aan te passen.

Mqtt is niet relevant voor Gielz ZenSDK. Alles werkt lokaal via REST API. Wellicht heb je een foutje in je yaml gemaakt? Ik vermoed in de rest sensor "Zendure 2400 AC Modus", kun je die code even delen.

[gielz]

edjes schreef op zaterdag 10 januari 2026 @ 11:33:
Ik krijg in Gielz code value_json errors, omdat ik eea blijkbaar niet via mqtt laat lopen.
Error rendering icon template for sensor.zendure_2400_ac_modus: UndefinedError: 'value_json' is undefined
Wat is een handige oplossing? Hoe laat ik via mqtt lopen?
Het werkt allemaal wel naar tevredenheid ;-) dus geen hoge nood om het aan te passen.

Opgelost in de volgende versie (Februari). Zie de error in het logboek niet meer voorbij komen maar zal het nog even in de gaten houden.

Releasenotes Februari
https://github.com/Gielz1986/Zendure-HA-zenSDK/pull/17

Volledige versie ter test
https://github.com/Gielz1...1986-Februari-2026-update

Wijziging icoonfout + andere opstart fout
https://github.com/Gielz1...852bb77638df8c76a1c828b8b

[StarWing]

@gielz, ik kan het direct niet vinden, maar ondersteund je release ook de Zendure P1 meter?

[Stefan1010]

gielz schreef op zaterdag 10 januari 2026 @ 13:59:
[...]


Opgelost in de volgende versie (Februari). Zie de error in het logboek niet meer voorbij komen maar zal het nog even in de gaten houden.

Releasenotes Februari
https://github.com/Gielz1986/Zendure-HA-zenSDK/pull/17

Volledige versie ter test
https://github.com/Gielz1...1986-Februari-2026-update

Wijziging icoonfout + andere opstart fout
https://github.com/Gielz1...852bb77638df8c76a1c828b8b

Hoi,
Complimenten voor al het mooie werk wat je verricht!
Ik heb hier nu 2 sets 2400AC staan die met jouw automatiseting en de node-red proxy draaien. Dat werkt echt top.

Een paar kleine puntjes / vraagjes:

Vanuit de restfull integratie krijg ik deze melding: Error fetching data: http://unknown/api/v1/data failed with Cannot connect to host unknown:80 ssl:default [Domain name not found]
Die wordt denk ik veroorzaakt omdat ik een shelly gebruik en geen homewizzard p1.

De stand-by vertraging werkt niet met de node-red proxy. Hopelijk kan dat worden meegenomen.

Groetjes, Stefan

[gielz]

StarWing schreef op zaterdag 10 januari 2026 @ 15:53:
@gielz, ik kan het direct niet vinden, maar ondersteund je release ook de Zendure P1 meter?

Niet direct out of the box. Maar je kunt de Zendure P1 uitlezen met de configuratie van @Taro Taro in "Zendure producten in Home Assistant integreren deel 2"

Daarna vul je deze sensor in (bijv sensor.zendure_p1_vermogen_Totaal) bij input_text.afwijkende_p1_sensor

[gielz]

Stefan1010 schreef op zaterdag 10 januari 2026 @ 15:56:
[...]


Hoi,
Complimenten voor al het mooie werk wat je verricht!
Ik heb hier nu 2 sets 2400AC staan die met jouw automatiseting en de node-red proxy draaien. Dat werkt echt top.

Een paar kleine puntjes / vraagjes:

Vanuit de restfull integratie krijg ik deze melding: Error fetching data: http://unknown/api/v1/data failed with Cannot connect to host unknown:80 ssl:default [Domain name not found]
Die wordt denk ik veroorzaakt omdat ik een shelly gebruik en geen homewizzard p1.

De stand-by vertraging werkt niet met de node-red proxy. Hopelijk kan dat worden meegenomen.

Groetjes, Stefan

Klopt wanneer je geen gebruik maakt van de Homewizard P1 krijg je inderdaad die ene melding in je logboek. Zou opgelost kunnen worden maar dat is iets meer werk.

[gast777]

Stefan1010 schreef op zaterdag 10 januari 2026 @ 15:56:
[...]
De stand-by vertraging werkt niet met de node-red proxy. Hopelijk kan dat worden meegenomen.

Wat werkt er precies niet? Ik heb de proxy nog niet getest met Gielz Februari beta versie, dus het zou kunnen. Maar ik zou verwachten dat de proxy hier geen invloed op heeft. Stuur anders even via DM wat er misgaat.

[gast777]

gast777 schreef op zaterdag 10 januari 2026 @ 18:47:
[...]
Stefan1010 schreef op zaterdag 10 januari 2026 @ 15:56:
[...]
De stand-by vertraging werkt niet met de node-red proxy. Hopelijk kan dat worden meegenomen.

Wat werkt er precies niet? Ik heb de proxy nog niet getest met Gielz Februari beta versie, dus het zou kunnen. Maar ik zou verwachten dat de proxy hier geen invloed op heeft. Stuur anders even via DM wat er misgaat.

Ik heb de Februari release beta even getest, met proxy naar 2x Zendure, en de standbyvertraging werkt goed. 5 minuten nadat de minSoc is bereikt, schiet hij van "Opslaan in RAM" naar "Opslaan in Flash" (oftewel, smartMode gaat uit).

Mooie nieuwe feature, als dat standbyverbruik bespaart

[Stefan1010]

gast777 schreef op zaterdag 10 januari 2026 @ 21:02:
[...]


Ik heb de Februari release beta even getest, met proxy naar 2x Zendure, en de standbyvertraging werkt goed. 5 minuten nadat de minSoc is bereikt, schiet hij van "Opslaan in RAM" naar "Opslaan in Flash" (oftewel, smartMode gaat uit).

Mooie nieuwe feature, als dat standbyverbruik bespaart

Dat klinkt goed
Het gaat dus goed als de minSoc bereikt is. Maar wat als bv. de ene unit > 5min in standby staat, de ander ontlaad en het Soc verschil nog geen 2% is?

Ik heb je een DM gestuurd.

[gast777]

Het gaat dus goed als de minSoc bereikt is. Maar wat als bv. de ene unit > 5min in standby staat, de ander ontlaad en het Soc verschil nog geen 2% is?

Gielz stuurt alleen de virtuele grote Zendure direct aan (de proxy). Als die als geheel dus 5 minuten niets doet, gaat de smartMode uit, wat dan door de proxy naar beide Zendures doorgestuurd wordt.

Waar jouw vraag overgaat, bij het om-en-om laden/ontladen (als er slechts 1 Zendure tegelijk laadt/ontlaadt bij lagere vermogens) wordt momenteel dus niet degene die niets doet even op smartMode=0 gezet.

Je ziet vaak dat deze dan nog iets van 20W blijft leveren (dat is bekend onbegrepen gedrag van de Zendure). Op zich zou het mooi zijn om dat uit te zetten, vooral 's nachts bij langzaam ontladen en weinig wisselen van actief ontladende Zendure. Ik hoop echter nog steeds dat Zendure dat een keer zal fixen.

Dat individueel actief op smartMode=0 zetten zit momenteel dus niet in de proxy. Het zou mijns inziens ook meer een soort workaround zijn om normaal Zendure gedrag te optimaliseren/corrigeren.

Ik kan wel een keer kijken of het eventueel toegevoegd kan worden, maar het wordt dan al gauw vrij complex om te implementeren. En dan nog zou het alleen beperkt ingezet moeten worden denk ik, om niet alsnog te veel naar Flash te schrijven. Dus misschien komt het op langere termijn, de feature request blijft staan.

[bilgy_no1]

Mag ik even hartgrondig vloeken op de idioten die Home Assistant hebben ontworpen op deze manier?

Prachtig idee en mooi dat je er zoveel mee kunt, maar wat een gebruiksonvriendelijk gedrocht is het...

OK ik moest even stoom afblazen nadat ik al uren zit te klooien met hulp van Copilot om toch iets heel simpels aan de praat te krijgen:

- batterij opladen tijdens de 5 goedkoopste uren
- batterij ontladen tijdens de 5 duurste uren
- voorwaarde: prijsverschil is minimaal €0,07.
- bron voor de prijzen: Zonneplan HA integratie
- Aansturing batterij: Zendure Home Assistant Integration uit HACS

Ik krijg nog niet eens die Zonneplan prijzen in een werkende sensor die de blokken voor hoogste en laagste prijzen geeft... Krijg waarden 0 of Geen data, ondanks een paar uur klooien met hulp van AI...
De besturing van de batterij ben ik nog niet eens aan toegekomen, maar ik zie wel dat de P1 meter waarden (Zendure P1 lezer, werkt in de app) Niet beschikbaar is... Ik moet eerst zien dat die data betrouwbaar werkt voordat ik de batterij daardoor kan laten aansturen.

Ik weet dat iedereen hier dit aan de praat krijgt, met prachtige grafieken en alles erop en eraan, dus voel me erg incompetent op dit vlak.

En het is niet dat ik dom ben, ik lees op dit moment over de wiskunde achter de relativiteitstheorie. Alleen dat freaking HA zit zo onduidelijk in elkaar, en de bronnen op internet zijn zo onbruikbaar. Ik heb al gezocht naar "Home Assistant voor Dummies" maar zonder resultaat.

Wat niet helpt is dat ik met gezin, werk, hobbies enz ook niet super veel tijd heb om me hierin te verdiepen.

Anyway, zucht... Even de frustratie uiten en iedere tip wordt enorm gewaardeerd.

[Taro]

bilgy_no1 schreef op zondag 11 januari 2026 @ 12:32:
Mag ik even hartgrondig vloeken op de idioten die Home Assistant hebben ontworpen op deze manier?

Prachtig idee en mooi dat je er zoveel mee kunt, maar wat een gebruiksonvriendelijk gedrocht is het...

OK ik moest even stoom afblazen nadat ik al uren zit te klooien met hulp van Copilot om toch iets heel simpels aan de praat te krijgen:

- batterij opladen tijdens de 5 goedkoopste uren
- batterij ontladen tijdens de 5 duurste uren
- voorwaarde: prijsverschil is minimaal €0,07.
- bron voor de prijzen: Zonneplan HA integratie
- Aansturing batterij: Zendure Home Assistant Integration uit HACS

Ik krijg nog niet eens die Zonneplan prijzen in een werkende sensor die de blokken voor hoogste en laagste prijzen geeft... Krijg waarden 0 of Geen data, ondanks een paar uur klooien met hulp van AI...
De besturing van de batterij ben ik nog niet eens aan toegekomen, maar ik zie wel dat de P1 meter waarden (Zendure P1 lezer, werkt in de app) Niet beschikbaar is... Ik moet eerst zien dat die data betrouwbaar werkt voordat ik de batterij daardoor kan laten aansturen.

Ik weet dat iedereen hier dit aan de praat krijgt, met prachtige grafieken en alles erop en eraan, dus voel me erg incompetent op dit vlak.

En het is niet dat ik dom ben, ik lees op dit moment over de wiskunde achter de relativiteitstheorie. Alleen dat freaking HA zit zo onduidelijk in elkaar, en de bronnen op internet zijn zo onbruikbaar. Ik heb al gezocht naar "Home Assistant voor Dummies" maar zonder resultaat.

Wat niet helpt is dat ik met gezin, werk, hobbies enz ook niet super veel tijd heb om me hierin te verdiepen.

Anyway, zucht... Even de frustratie uiten en iedere tip wordt enorm gewaardeerd.

Zendure P1 in HA uitlezen: Taro in "Zendure producten in Home Assistant integreren deel 2"
Prijzen zou ik uit Nord Pool halen ipv Zonneplan, dan werkt het ook als je ooit naar een andere partij overstapt.

En de goedkoopste/duurste uren kan je dmv Cheapest Hours vinden:

5 goedkoopste uren verspreid over de hele dag:

Django/Jinja:

{% from 'cheapest_energy_hours.jinja' import cheapest_energy_hours %}
{{ cheapest_energy_hours('sensor.nordpool_kwh_nl_eur_4_09_021', attr_today='Today', hours=5, split=true, lowest=true, mode='is_now', value_key='price', time_key='time', use_hourly_avg=true) }}

5 duurste uren verspreid over de hele dag:

Django/Jinja:

{% from 'cheapest_energy_hours.jinja' import cheapest_energy_hours %}
{{ cheapest_energy_hours('sensor.nordpool_kwh_nl_eur_4_09_021', attr_today='Today', hours=5, split=true, lowest=false, mode='is_now', value_key='price', time_key='time', use_hourly_avg=true) }}

Bovenstaande Jinja code houdt ook rekening met afronding per uur ipv kwartier voor Zonneplan.

De spread bepalen kan, maar het lastige is dat je soms vandaag wil opladen om morgenavond te ontladen. Daarom doe ik dit persoonlijk met de volgende knoppen:



Kan je verder heel specifiek aangeven waar je per onderdeel tegenaan loopt? Dan kunnen we per stuk gerichte antwoorden geven.

[ Voor 25% gewijzigd door Taro op 11-01-2026 12:47 ]

[koboy]

bilgy_no1 schreef op zondag 11 januari 2026 @ 12:32:
Mag ik even hartgrondig vloeken op de idioten die Home Assistant hebben ontworpen op deze manier?

Prachtig idee en mooi dat je er zoveel mee kunt, maar wat een gebruiksonvriendelijk gedrocht is het...

OK ik moest even stoom afblazen nadat ik al uren zit te klooien met hulp van Copilot om toch iets heel simpels aan de praat te krijgen:

- batterij opladen tijdens de 5 goedkoopste uren
- batterij ontladen tijdens de 5 duurste uren
- voorwaarde: prijsverschil is minimaal €0,07.
- bron voor de prijzen: Zonneplan HA integratie
- Aansturing batterij: Zendure Home Assistant Integration uit HACS

Ik krijg nog niet eens die Zonneplan prijzen in een werkende sensor die de blokken voor hoogste en laagste prijzen geeft... Krijg waarden 0 of Geen data, ondanks een paar uur klooien met hulp van AI...
De besturing van de batterij ben ik nog niet eens aan toegekomen, maar ik zie wel dat de P1 meter waarden (Zendure P1 lezer, werkt in de app) Niet beschikbaar is... Ik moet eerst zien dat die data betrouwbaar werkt voordat ik de batterij daardoor kan laten aansturen.

Ik weet dat iedereen hier dit aan de praat krijgt, met prachtige grafieken en alles erop en eraan, dus voel me erg incompetent op dit vlak.

En het is niet dat ik dom ben, ik lees op dit moment over de wiskunde achter de relativiteitstheorie. Alleen dat freaking HA zit zo onduidelijk in elkaar, en de bronnen op internet zijn zo onbruikbaar. Ik heb al gezocht naar "Home Assistant voor Dummies" maar zonder resultaat.

Wat niet helpt is dat ik met gezin, werk, hobbies enz ook niet super veel tijd heb om me hierin te verdiepen.

Anyway, zucht... Even de frustratie uiten en iedere tip wordt enorm gewaardeerd.

Of je doet zoals ik: wachten op de februari release van Gielz integratie. Handel volgens instelbare uren is daarin nieuw opgenomen.
Tot die tijd rommelt Zenki wat aan en stel ik voor een mooie dag wel even een handmatig schema in.

N.B. ik kan het wel zelf oplossen, maar wachten levert me tijd op die ik aan belangrijker zaken kan besteden.

[bilgy_no1]

Taro schreef op zondag 11 januari 2026 @ 12:37:
[...]



Zendure P1 in HA uitlezen: Taro in "Zendure producten in Home Assistant integreren deel 2"
Prijzen zou ik uit Nord Pool halen ipv Zonneplan, dan werkt het ook als je ooit naar een andere partij overstapt.

En de goedkoopste/duurste uren kan je dmv Cheapest Hours vinden:

5 goedkoopste uren verspreid over de hele dag:

Django/Jinja:

{% from 'cheapest_energy_hours.jinja' import cheapest_energy_hours %}
{{ cheapest_energy_hours('sensor.nordpool_kwh_nl_eur_4_09_021', attr_today='Today', hours=5, split=true, lowest=true, mode='is_now', value_key='price', time_key='time', use_hourly_avg=true) }}

5 duurste uren verspreid over de hele dag:

Django/Jinja:

{% from 'cheapest_energy_hours.jinja' import cheapest_energy_hours %}
{{ cheapest_energy_hours('sensor.nordpool_kwh_nl_eur_4_09_021', attr_today='Today', hours=5, split=true, lowest=false, mode='is_now', value_key='price', time_key='time', use_hourly_avg=true) }}

Bovenstaande Jinja code houdt ook rekening met afronding per uur ipv kwartier voor Zonneplan.

De spread bepalen kan, maar het lastige is dat je soms vandaag wil opladen om morgenavond te ontladen. Daarom doe ik dit persoonlijk met de volgende knoppen:

[Afbeelding]

Kan je verder heel specifiek aangeven waar je per onderdeel tegenaan loopt? Dan kunnen we per stuk gerichte antwoorden geven.

Dank voor je hulpaanbod. Ik kom er later op terug, want moet nu de deur uit en ben dan een paar dagen weg zonder toegang tot HA.

Ik denk dat ik het vanaf woensdag of anders volgens weekend weer op kan pakken...

[edjes]

Het klinkt dat HA niet echt geschikt voor je is. Het is juist een enorm toegankelijk systeem met kinderlijke eenvoud maar je kan heel diep gaan. Waar deze aansturing ook wel toe behoort. Misschien moet je stoppen met lezen over wiskunde achter de relativiteit en je verdiepen in HA. ;-)) Maar het kost echt tijd om eea je eigen te maken en dat gaat niet lukken in een paar uutjes. Succes en sterkte!

[amyor]

koboy schreef op zondag 11 januari 2026 @ 13:41:
[...]


Of je doet zoals ik: wachten op de februari release van Gielz integratie. Handel volgens instelbare uren is daarin nieuw opgenomen.
Tot die tijd rommelt Zenki wat aan en stel ik voor een mooie dag wel even een handmatig schema in.

N.B. ik kan het wel zelf oplossen, maar wachten levert me tijd op die ik aan belangrijker zaken kan besteden.

Kijk dit is nieuw voor me, wou net iets posten maar ik wacht maar even af tot februari dan!

Ik ben geen held met Home Assistant en had zo wat ideetjes maar door tijdsgebrek met werk, kinderen en hobby's (en voeg daar dan ook nog eens een griepje aan toe) dan blijkt het spelen met mijn Zendure batterij gewoonweg onmogelijk sinds ik die in huis heb.

Ik mis enorm dat uursschema. Zeker nu ik een tariefplan heb met piek-, dal- en superdaluren.

Dan nog de wagen, de zonnepanelen - die nu in de donkerste dagen weinig tot geen overschot hebben om de batterij al te gaan laden wanneer die zoveelste wasmachine draait- ,....

Het gaat momenteel nog teveel mijn petje te boven ondanks mijn klein ideetje na het ijsberen vandaag.

[Stefan1010]

gast777 schreef op zaterdag 10 januari 2026 @ 23:39:
[...]


Gielz stuurt alleen de virtuele grote Zendure direct aan (de proxy). Als die als geheel dus 5 minuten niets doet, gaat de smartMode uit, wat dan door de proxy naar beide Zendures doorgestuurd wordt.

Waar jouw vraag overgaat, bij het om-en-om laden/ontladen (als er slechts 1 Zendure tegelijk laadt/ontlaadt bij lagere vermogens) wordt momenteel dus niet degene die niets doet even op smartMode=0 gezet.

Je ziet vaak dat deze dan nog iets van 20W blijft leveren (dat is bekend onbegrepen gedrag van de Zendure). Op zich zou het mooi zijn om dat uit te zetten, vooral 's nachts bij langzaam ontladen en weinig wisselen van actief ontladende Zendure. Ik hoop echter nog steeds dat Zendure dat een keer zal fixen.

Dat individueel actief op smartMode=0 zetten zit momenteel dus niet in de proxy. Het zou mijns inziens ook meer een soort workaround zijn om normaal Zendure gedrag te optimaliseren/corrigeren.

Ik kan wel een keer kijken of het eventueel toegevoegd kan worden, maar het wordt dan al gauw vrij complex om te implementeren. En dan nog zou het alleen beperkt ingezet moeten worden denk ik, om niet alsnog te veel naar Flash te schrijven. Dus misschien komt het op langere termijn, de feature request blijft staan.

Idd zou Zendure dat moeten fixen. In ieder geval dank voor het meenemen als feature request.
Het gaat nu trouwens ook al goed in de stand 'alleen slim opladen'. Als beide batterijen x tijd op standby staan vanuit Gielz, dan wordt door de proxy de smartMode=0 overgenomen.

[Stefan1010]

@gielz: ik heb wat in elkaar geknutseld om de restende laadtijd te bepalen. Misschien iets om mee te nemen in jouw automatisering? Jij kunt dat ongetwijfeld veel handiger dan ik

Eerst een template sensor gemaakt (sensor.template_zendure_beschikbare_energie) die de beschikbare energie van alle batterijen berekend:

{{(states('sensor.zendure_1_batterij_1_laadpercentage')|float(0) / 100 * 2.88 - 0.288 |float(0)
+ states('sensor.zendure_1_batterij_2_laadpercentage')|float(0) / 100 * 2.88 - 0.288 |float(0)
+ states('sensor.zendure_1_batterij_3_laadpercentage')|float(0) / 100 * 2.88 - 0.288 |float(0)
+ states('sensor.zendure_1_batterij_4_laadpercentage')|float(0) / 100 * 2.88 - 0.288 |float(0)
+ states('sensor.zendure_2_batterij_5_laadpercentage')|float(0) / 100 * 2.88 - 0.288 |float(0)
+ states('sensor.zendure_2_batterij_6_laadpercentage')|float(0) / 100 * 2.88 - 0.288 |float(0)
+ states('sensor.zendure_2_batterij_7_laadpercentage')|float(0) / 100 * 2.88 - 0.288 |float(0)
+ states('sensor.zendure_2_batterij_8_laadpercentage')|float(0) / 100 * 2.88 - 0.288 |float(0)) | round (2)}}

En dan nog een template die de resterende laadtijd berekend:
(20.74 is mijn geval met 8 batterijen de maximale capaciteit. Dit komt overeen met 90% van de totale capaciteit)

{% if (states('sensor.zendure_2400_ac_vermogen_import') | float(0) > 0 | float) %}
{% set hours = (20.74 - states('sensor.template_zendure_beschikbare_energie')|float)
/ (states('sensor.zendure_2400_ac_vermogen_import')|float(0) / 1000 ) %}
{% set minutes = ((hours % 1) * 60) | int %}
{% set hours = (hours - (hours % 1)) | int %} {{ '%02i:%02i'%(hours, minutes) }}

{% else %}-
{% endif %}

[gielz]

Stefan1010 schreef op zondag 11 januari 2026 @ 21:28:
@gielz: ik heb wat in elkaar geknutseld om de restende laadtijd te bepalen. Misschien iets om mee te nemen in jouw automatisering? Jij kunt dat ongetwijfeld veel handiger dan ik

Eerst een template sensor gemaakt (sensor.template_zendure_beschikbare_energie) die de beschikbare energie van alle batterijen berekend:

{{(states('sensor.zendure_1_batterij_1_laadpercentage')|float(0) / 100 * 2.88 - 0.288 |float(0)
+ states('sensor.zendure_1_batterij_2_laadpercentage')|float(0) / 100 * 2.88 - 0.288 |float(0)
+ states('sensor.zendure_1_batterij_3_laadpercentage')|float(0) / 100 * 2.88 - 0.288 |float(0)
+ states('sensor.zendure_1_batterij_4_laadpercentage')|float(0) / 100 * 2.88 - 0.288 |float(0)
+ states('sensor.zendure_2_batterij_5_laadpercentage')|float(0) / 100 * 2.88 - 0.288 |float(0)
+ states('sensor.zendure_2_batterij_6_laadpercentage')|float(0) / 100 * 2.88 - 0.288 |float(0)
+ states('sensor.zendure_2_batterij_7_laadpercentage')|float(0) / 100 * 2.88 - 0.288 |float(0)
+ states('sensor.zendure_2_batterij_8_laadpercentage')|float(0) / 100 * 2.88 - 0.288 |float(0)) | round (2)}}

En dan nog een template die de resterende laadtijd berekend:
(20.74 is mijn geval met 8 batterijen de maximale capaciteit. Dit komt overeen met 90% van de totale capaciteit)

{% if (states('sensor.zendure_2400_ac_vermogen_import') | float(0) > 0 | float) %}
{% set hours = (20.74 - states('sensor.template_zendure_beschikbare_energie')|float)
/ (states('sensor.zendure_2400_ac_vermogen_import')|float(0) / 1000 ) %}
{% set minutes = ((hours % 1) * 60) | int %}
{% set hours = (hours - (hours % 1)) | int %} {{ '%02i:%02i'%(hours, minutes) }}

{% else %}-
{% endif %}

Ik wacht eigenlijk nog steeds op een fix van Zendure al maanden. Dit aangezien het ook niet goed staat in de zendure app zelf.

Voor de Maart release ga ik alle statistiek sensoren nog eens onder de loop nemen. Hier onder een voorbeeld van 1 van de verbeterde sensoren.

- Extra attributen
- Berekening is veel beter

[gielz]

Krijg regelmatig wat DMs met de vraag hoe je een melding kunt krijgen over een nieuwe release/issues/pull requests op github.

Hier onder even de uitleg;

1) Zet een Star bij de Github pagina (dan volg je hem wat altijd handig is)
2) Klik op Watch en kies waar je exact een melding van wilt krijgen. Bij Custom kun je specifiek alleen releases aanvinken.
3) Bij je profiel onder Notifications kun je aangeven of het via github zelf gaat of naar je mailbox

[noo]

@gielz Misschien ook een leuke voor de maart update om de sensoren van de batterijen op de fysieke volgorde te krijgen.

Na het toevoegen van een vierde batterij onder aan de stapel bleek die in packData[1] te verschijnen ipv packData[3] waardoor mijn OCD ging opspelen. Met een kleine aanpassing en een paar input_texts waar je de serienummers invult kun je de sensoren nu in de gewenste volgorde krijgen:

YAML:

#
# Forceer batterijvolgorde van boven naar beneden dmv selecteren op serienummer ipv array indexing:
#
#   value_json.get('packData', [])
#     | selectattr('sn', 'eq', states('input_text.zendure_batterij_1_serienummer') )
#     | map(attribute='maxTemp')
#     | first
#     | default(none)
#
#
      - name: "Zendure 2400 AC Batterij 1 Temperatuur"
        value_template: >
          {% set maxTemp = value_json.get('packData', [])
            | selectattr('sn', 'eq', states('input_text.zendure_batterij_1_serienummer'))
            | map(attribute='maxTemp') | first | default(none) | int %}
          {{ (maxTemp - 2731) / 10.0 }}
        unique_id: Zendure_2400_AC_Batterij_1_Temperatuur
        unit_of_measurement: "°C"
        state_class: measurement
        device_class: temperature
        icon: mdi:thermometer

      - name: "Zendure 2400 AC Batterij 2 Temperatuur"
        value_template: >
          {% set maxTemp = value_json.get('packData', [])
            | selectattr('sn', 'eq', states('input_text.zendure_batterij_2_serienummer'))
            | map(attribute='maxTemp') | first | default(none) | int %}
          {{ (maxTemp - 2731) / 10.0 }}
        unique_id: Zendure_2400_AC_Batterij_2_Temperatuur
        unit_of_measurement: "°C"
        state_class: measurement
        device_class: temperature
        icon: mdi:thermometer
[...]

[mrme12345]

@gielz geweldige integratie, heb hem ook maar eens geinstalleerd voor dynamisch automatiseren. Dank je!

Ik heb ook de grafieken geinstalleerd van dynamisch, en gekozen voor uur (met schakelaar), maar dat heeft geen invloed op de grafieken. Moet ik daar zelf iets voor aanpassen in de grafiek of zie ik iets over het hoofd en is de schakelaar enkel voor de berekeningen en niet voor de grafiek (ik zit bij zonneplan).

[gielz]

mrme12345 schreef op maandag 12 januari 2026 @ 19:24:
@gielz geweldige integratie, heb hem ook maar eens geinstalleerd voor dynamisch automatiseren. Dank je!

Ik heb ook de grafieken geinstalleerd van dynamisch, en gekozen voor uur (met schakelaar), maar dat heeft geen invloed op de grafieken. Moet ik daar zelf iets voor aanpassen in de grafiek of zie ik iets over het hoofd en is de schakelaar enkel voor de berekeningen en niet voor de grafiek (ik zit bij zonneplan).

De schakelaar van 15min naar 1uur zou direct moeten werken in HA 2026.1. Soms kan het ook zo zijn dat je even eenmalig moet F5en. Na het omzetten kun je kijken bij de attributen van sensor.dynamisch_nordpool daar zie je namelijk ook de aanpassing in terug.

DM anders even dan kijken wij waar het fout gaat.

[StarWing]

@gielz, is het een idee/mogelijkheid om je automatisatie via HACS aan te bieden? (wild shot, geen idee hoe HACS werkt).
Dit maakt het updaten wat makkelijker.

[gielz]

StarWing schreef op dinsdag 13 januari 2026 @ 12:06:
@gielz, is het een idee/mogelijkheid om je automatisatie via HACS aan te bieden? (wild shot, geen idee hoe HACS werkt).
Dit maakt het updaten wat makkelijker.

Dan zou die opnieuw geschreven moeten worden in python. Maar ik zal eens kijken of ik hem als package (1:1) beschikbaar kan maken met versiebeheer. Dat laatste heeft ook weinig aanpassingen nodig.

[martinvdm]

gielz schreef op dinsdag 13 januari 2026 @ 12:35:
[...]


Dan zou die opnieuw geschreven moeten worden in python. Maar ik zal eens kijken of ik hem als package (1:1) beschikbaar kan maken met versiebeheer. Dat laatste heeft ook weinig aanpassingen nodig.

Dat valt mee. Met name wat ondersteunde files en de structuur.
https://www.hacs.xyz/docs/publish/integration/

[gielz]

martinvdm schreef op dinsdag 13 januari 2026 @ 18:18:
[...]

Dat valt mee. Met name wat ondersteunde files en de structuur.
https://www.hacs.xyz/docs/publish/integration/

Het punt is dat de huidige code geen python is je kunt hem dus niet zo 123 publiceren. Dan kun je 2 dingen doen of hem volledig herschrijven in python. Of in een package gieten waarbij je 1 regel maar hoeft toe te voegen aan je configuration.yaml. De package zelf loopt dan via HACS inclusief updates.

In Mei 2025 was de insteek om de "Gielz" zo te maken dat iedereen hem zelf zou kunnen aanpassen van sensoren tot de volledige automatisering. En een keer niet in python.

Dat blijft ook de visie; 100% lokaal, 100% zelf in control
Zal na de Februari release eens kijken naar de HACS package.

[edjes]

gielz schreef op dinsdag 13 januari 2026 @ 19:32:
[...]

Dat blijft ook de visie; 100% lokaal, 100% zelf in control
Zal na de Februari release eens kijken naar de HACS package.

Dat laatste ben ik het heel erg mee eens. Ik vind het heerlijk om uit de Gielz code weer dingetjes te pakken en daar mijn eigen scripts en automatiseringen omheen te bouwen!

[ Voor 35% gewijzigd door edjes op 13-01-2026 20:39 ]

[martinvdm]

gielz schreef op dinsdag 13 januari 2026 @ 19:32:
[...]


Het punt is dat de huidige code geen python is je kunt hem dus niet zo 123 publiceren. Dan kun je 2 dingen doen of hem volledig herschrijven in python. Of in een package gieten waarbij je 1 regel maar hoeft toe te voegen aan je configuration.yaml. De package zelf loopt dan via HACS inclusief updates.

In Mei 2025 was de insteek om de "Gielz" zo te maken dat iedereen hem zelf zou kunnen aanpassen van sensoren tot de volledige automatisering. En een keer niet in python.

Dat blijft ook de visie; 100% lokaal, 100% zelf in control
Zal na de Februari release eens kijken naar de HACS package.

Voel je niet verplicht. Ik verwees je alleen naar de basis requirements HACS, nav eerdere suggestie. Wat mij betreft is github zo prima. Versie beheer en fijn platform. Enorm begrip voor je tijd die je steekt in je “hobby project”, die tijd kun je het beste steken in het project zelf.

[StarWing]

Ik ken zelf de voor en nadelen niet van een HACS integratie, het was maar een ideetje.

[Jerryvh]

knip knip, betaalde hulp zoeken hoort niet thuis op het forum.

[ Voor 89% gewijzigd door teacher op 14-01-2026 09:31 ]

[klump4u]

.

[ Voor 99% gewijzigd door teacher op 14-01-2026 09:31 ]

[wautah91]

Ik was een beetje achter met het bijhouden van dit topic sinds de kerst, ben nu weer bij. De laatste pagina's gaan alleen nog maar over de Gielz aansturing. Die ziet er echt heel mooi uit. Ikzelf heb een Hyper. Is er al iemand bezig met het remappen van entities om de Gielz aansturing werkend te krijgen met de Hyper? Ik snap dat de commando's dan fundamenteel anders moeten maar voor mijn gevoel moet dat kunnen?

[R.K]

Ik wil even mijn waardering uitspreken voor het codeerwerk van @gielz
Ik heb de laatste februari update geïnstalleerd en gebruik nu de Dynamisch NOM duur methode, in 5 goedkope uren opladen en de 5 duurste uren ontladen, rekening houdend met de minimale spread.Tussen die uren standby. En het werkt echt fantastisch. Petje af

[gast777]

wautah91 schreef op woensdag 14 januari 2026 @ 12:05:
Ikzelf heb een Hyper. Is er al iemand bezig met het remappen van entities om de Gielz aansturing werkend te krijgen met de Hyper? Ik snap dat de commando's dan fundamenteel anders moeten maar voor mijn gevoel moet dat kunnen?

De Hyper ondersteunt geen REST API, voor zover ik weet. Dus dan zou de communicatie met de Hyper (informatie ontvangen vanuit de Hyper en commando's sturen naar de Hyper) naar MQTT overgezet moeten worden.

Totnutoe heeft niemand gemeld daarmee bezig te zijn AFAIK.

[Ben(V)]

StarWing schreef op dinsdag 13 januari 2026 @ 12:06:
@gielz, is het een idee/mogelijkheid om je automatisatie via HACS aan te bieden? (wild shot, geen idee hoe HACS werkt).
Dit maakt het updaten wat makkelijker.

Als je dat wilt kun je ook gewoon de versie die @FireSon maakt gebruiken.
https://github.com/Zendure/Zendure-HA

[lars1986]

gielz schreef op dinsdag 13 januari 2026 @ 12:35:
[...]


Dan zou die opnieuw geschreven moeten worden in python. Maar ik zal eens kijken of ik hem als package (1:1) beschikbaar kan maken met versiebeheer. Dat laatste heeft ook weinig aanpassingen nodig.

@gielz hoe zit het eigenlijk met updaten? Dit doe je zo te zien eens per maand? En moet je dan je config file nalopen / aanpassen? En automations toevoegen bijvoorbeeld?

[wautah91]

gast777 schreef op woensdag 14 januari 2026 @ 15:24:
[...]


De Hyper ondersteunt geen REST API, voor zover ik weet. Dus dan zou de communicatie met de Hyper (informatie ontvangen vanuit de Hyper en commando's sturen naar de Hyper) naar MQTT overgezet moeten worden.

Totnutoe heeft niemand gemeld daarmee bezig te zijn AFAIK.

Ben jij toevallig de maker van de node-red proxy om twee Zendure's te sturen met de gielz automatisering? Misschien dat het op een soortgelijke manier mogelijk is een vertaling te maken tussen de rest en mqtt commando's.

Mijn doel is om gewoon een beproefd all-in-one automatisering te draaien met mijn hyper. Dat is de gielz automatisering toch? 1x configureren en daarna gaat hij zelf laden en ontladen obv prijzen? Mijn huidige eigen automatisering gaat nog wel eens de mist in...

[gast777]

wautah91 schreef op woensdag 14 januari 2026 @ 21:43:
[...]
Ben jij toevallig de maker van de node-red proxy om twee Zendure's te sturen met de gielz automatisering? Misschien dat het op een soortgelijke manier mogelijk is een vertaling te maken tussen de rest en mqtt commando's.

Klopt dat ben ik Conversie naar MQTT zou wel een heel ander project zijn. Ik denk dat dit beter direct in HA gedaan zou kunnen worden dan middels een proxy. Misschien dat iemand die een Hyper heeft zich ertoe geroepen voelt.

[gielz]

wautah91 schreef op woensdag 14 januari 2026 @ 12:05:
Ik was een beetje achter met het bijhouden van dit topic sinds de kerst, ben nu weer bij. De laatste pagina's gaan alleen nog maar over de Gielz aansturing. Die ziet er echt heel mooi uit. Ikzelf heb een Hyper. Is er al iemand bezig met het remappen van entities om de Gielz aansturing werkend te krijgen met de Hyper? Ik snap dat de commando's dan fundamenteel anders moeten maar voor mijn gevoel moet dat kunnen?

Je kunt dit wellicht redelijk eenvoudig zelf doen; Installeer Zendure HA HACS en vervolgens de Gielz automatisering zonder configuration.yaml. Vervolgens open je deze automatisering en controleer en map je elke Gielz sensor om naar de Zendure HA HACS.

Op mijn github is elke sensor beschreven alleen voor Zendure HA HACS kan ik dit nergens vinden....

[gielz]

lars1986 schreef op woensdag 14 januari 2026 @ 20:34:
[...]

@gielz hoe zit het eigenlijk met updaten? Dit doe je zo te zien eens per maand? En moet je dan je config file nalopen / aanpassen? En automations toevoegen bijvoorbeeld?

Wanneer je zelf niets heb aangepast in de automatisering of configuration.yaml dan is het copy+paste. Bij aanpassing aan bestaande sensoren die opeens een andere state krijgen zal dit goed beschreven worden. Maar hier word iig rekening mee gehouden in releases.

Bij elke release zit een link met de exacte config wijzigingen. Februari release verwacht ik vandaag te kunnen releasen als er geen grote issues meer gevonden worden.

[wautah91]

gast777 schreef op woensdag 14 januari 2026 @ 22:25:
[...]


Klopt dat ben ik Conversie naar MQTT zou wel een heel ander project zijn. Ik denk dat dit beter direct in HA gedaan zou kunnen worden dan middels een proxy. Misschien dat iemand die een Hyper heeft zich ertoe geroepen voelt.

Jouw node-red flow bracht mij op een idee... De gielz entities en automatisering blijft wat het is, de vertaling naar de Hyper gaat via node-red. Ik luister nu op dezelfde manier als jouw flow naar de commando's die HA naar de restAPI stuurt van de 2400ac. Daar ontleed ik het commando naar de waarden die ingesteld moeten worden op de hyper.

WIP:

[gielz]

ZenSDK (Gielz) - Februari release

Deze release is iets groter uitgevallen dan gepland. Uiteindelijk bleek om de batterij 100% in standby te krijgen ook meer werk doordat er in praktijk meerdere omvormer versies in omloop zijn. De ene gaat direct in standby met 0 watt, de andere niet direct maar eerst nog even 30 watt en dan is er nog een andere versie die tijdelijk 85 watt gaat gebruiken.

Er is extreem veel getest door mede-tweakers waarvoor petje af! Maar mocht je iets tegenkomen maak dan even een issue aan. Afhankelijk van het issue worden deze als directe bug release opgelost of in een maandelijkse release en krijgen ze een nette afhandeling.

Melding van release krijgen

1) Zet een Star bij de Github pagina (dan volg je hem wat altijd handig is)
2) Klik op Watch en kies waar je exact een melding van wilt krijgen. Bij Custom kun je specifiek alleen releases aanvinken.
3) Bij je profiel onder Notifications kun je aangeven of het via github zelf gaat of naar je mailbox

Release

https://github.com/Gielz1...DK/releases/tag/v20260115
Wijzigingen: https://github.com/Gielz1...are/v20251215...v20260115

2 Nieuwe modus opties

Dynamisch NOM (Duur) modus toegevoegd
Alle goedkope energie specifiek gebruiken op de duurste uren - In de readme staat beschreven hoe de modus exact werkt.

Dynamisch Handelen modus toegevoegd
Energie inkopen en verkopen - In de readme staat beschreven hoe de modus exact werkt.

Extra sensoren toegevoegd

Oplaadmarge
Standaard in HEMS word er een marge aangehouden van 50 watt. Hierbij houd de huidige versie 40 watt aan wat dus vanaf nu instelbaar is van 0 tot 50 watt via deze entiteit. Handig in de winter als je alle prik binnen wilt halen.

Ontlaadmarge
Bij iedereen wel verschillend. De ene wilt net wat meer ontladen dan gevraagd word om echt 0 te importeren en de ander juist niet. Nu ook instelbaar van 0 tot 50 watt. In de huidige versie is dit 2 watt.

Standby vertraging
Een doorn in het oog. Ik zie bij andere aansturingen dat de Smartmode op 0 gezet word direct als het vermogen ook op 0 watt staat. Zelf was ik hier geen voorstander van en zie dit bijvoorbeeld ook niet terug bij de Homewizard PIB. Vandaar nu netjes instelbaar van 5-30 minuten. Zodra er dan xx minuten geen activiteit is zal hij smartmode op 0 zetten om de "waakvlam" zoals ik hem zelf noem uit te zetten. Hierna toont een KWH MID meter 0 watt maar uiteraard is er nog wat vermogen nodig intern voor de BMS. De modus "Standby" wat handmatig was deed dit al correct en altijd direct wat ongewijzigd is. Nu doet de gehele aansturing mee zoals NOM, Slim Opladen etc.

Relais Stand
Om de relaisschakelingen beter te tellen. Van standby naar dezelfde stand (ontladen/laden) werd als schakeling gezien.

Wijzigingen in bestaande onderdelen

Relais schakeling aantal
De relais schakelingen waren te negatief omdat er ook geteld werd bij Ontladen > Standby > Ontladen wat niet terecht is omdat hij nog in dezelfde stand blijft staan. Voor de tellingen word nu gekeken naar sensor.zendure_2400_ac_relais_stand

Handmatige modus
Bij elke ingevulde waarde ging hij direct naar de API. Dit loopt vanaf nu via het standaard 4 seconden schema om de API niet te veel te belasten.

Minimale SOC bescherming aangepast
Deze zal alleen in werking zijn tussen 2 uur na zonsopkomst en 2 uur voor zonsondergang.

sensor.zendure_2400_ac_modus icoon
Iconen veranderd naar + wanneer er geladen word en - wanneer er ontladen word. Hierdoor beter zichtbaar bij tegels waar alleen iconen gebruikt worden en geen tekst. Code aangepast omdat er json foutmeldingen kwamen bij het renderen.

binary_sensor.p1_nul_import_actief
Bij een herstart van Home Assistant gaf deze een logboek foutmelding. Dit is opgelost

Automatisering opgeschoond
Alle sturing staat nu in aparte categorieën waardoor het makkelijker leesbaar is.

Automatisering wachtrij
Wachtrij verhoogd naar 8 ivm dynamische onderdelen

Node-RED aanpassingen
Voor de gene die meerdere batterijen aansturen via Nodered (https://github.com/gast777/Zendure-zenSDK-proxy) zijn een aantal aanpassingen gedaan in de basis. De restcommands sturen nu een header mee. En het handmatig instelbare vermogen is nu -4800 - 4800 watt. Deze 3 aanpassingen hebben geen invloed op de basis configuratie met 1 batterij.

[wautah91]

gielz schreef op donderdag 15 januari 2026 @ 10:04:

ZenSDK (Gielz) - Februari release

....

Super! Is het mogelijk om jouw yaml van het dashboard dat op de github staat ook te delen?

[gielz]

wautah91 schreef op donderdag 15 januari 2026 @ 11:29:
[...]


Super! Is het mogelijk om jouw yaml van het dashboard dat op de github staat ook te delen?

Die is eigenlijk alleen ter illustratie en hier intern voor het testen. Zelf gebruik ik alleen deze;


Maar hier kun je hem vinden om over te nemen zoals die van Github;
https://gist.github.com/G...a051679c4b8eaa51d48331a05

[wautah91]

gielz schreef op donderdag 15 januari 2026 @ 11:36:
[...]


Die is eigenlijk alleen ter illustratie en hier intern voor het testen. Zelf gebruik ik alleen deze;
[Afbeelding]

Maar hier kun je hem vinden om over te nemen zoals die van Github;
https://gist.github.com/G...a051679c4b8eaa51d48331a05

Geweldig! Bedankt!

[VicSmurf]

@gielz bedankt voor al je moeite, zojuist deze integratie er opgezet! Ik heb ook je dashboard "gejat", geweldig!

[ Voor 21% gewijzigd door VicSmurf op 15-01-2026 14:35 ]

[gielz]

VicSmurf schreef op donderdag 15 januari 2026 @ 14:25:
@gielz bedankt voor al je moeite, zojuist deze integratie er opgezet! Ik heb ook je dashboard "gejat", geweldig!

[Afbeelding]

Bedankt voor de tip, ik heb dit nu toegevoegd aan stap 1. (stond al deels bij de entiteiten uitleg verder op in de readme). Nog een tip van de dag. Mocht je Home Assistant een strak modern uiterlijk willen geven. Gebruik dan deze van HACS; https://github.com/TilmanGriesel/graphite

[VicSmurf]

gielz schreef op donderdag 15 januari 2026 @ 14:40:
[...]


Bedankt voor de tip, ik heb dit nu toegevoegd aan stap 1. (stond al deels bij de entiteiten uitleg verder op in de readme). Nog een tip van de dag. Mocht je Home Assistant een strak modern uiterlijk willen geven. Gebruik dan deze van HACS; https://github.com/TilmanGriesel/graphite

Ik had mijn post alweer aangepast omdat ik het later inderdaad zag bij de entiteiten.
Overigens bedankt voor je andere tip! Ga ik nu installeren :-)

[VicSmurf]

gielz schreef op donderdag 15 januari 2026 @ 11:36:
[...]


Die is eigenlijk alleen ter illustratie en hier intern voor het testen. Zelf gebruik ik alleen deze;
[Afbeelding]

Maar hier kun je hem vinden om over te nemen zoals die van Github;
https://gist.github.com/G...a051679c4b8eaa51d48331a05

Durf het bijna niet te vragen maar zou je die ook willen delen (de gene die je zelf alleen gebruikt) al is het ter inspiratie?

[ZuinigeRijder]

Van de README van Zendure-zenSDK-proxy:

Deze Node-Red flow vormt een proxy server die het mogelijk maakt de Gielz automatisering te gebruiken met twee Zendure devices, zoals 2x Solarflow 2400AC.

@gast777 In hoeverre zou er ook een proxy gemaakt kunnen worden met drie Zendure devices, bijvoorbeeld 3x Zendure 800 Plus? Dan zou je ook 2400 Watt ontlaad vermogen hebben, hetzelfde als 1x Solarflow 2400AC.

3 maal Zendure 800 Plus is goedkoper dan 1x 2400 AC, met ook nog eens 6 mppt aansluitingen én je zou ze zelfs nog over 3 fases kunnen verdelen.

Voor- en nadelen?

[gielz]

VicSmurf schreef op donderdag 15 januari 2026 @ 15:33:
[...]


Durf het bijna niet te vragen maar zou je die ook willen delen (de gene die je zelf alleen gebruikt) al is het ter inspiratie?

Niet helemaal hetzelfde. Bij deze zitten niet de zonsopkomst en zonsondergang;
https://gathering.tweakers.net/forum/view_message/84165010

Het onderste gedeelte moet je zelf ook tweaken;

code:

type: custom:apexcharts-card
experimental:
  brush: true
cache: true
stacked: true
update_interval: 5sec
header:
  show: true
  show_states: true
  title: ""
graph_span: 60min
brush:
  selection_span: 15min
  apex_config:
    grid:
      strokeDashArray: 0
      borderColor: rgb(52,52,52)
      show: true
    yaxis:
      show: false
    xaxis:
      labels:
        show: false
      axisTicks:
        show: false
    chart:
      height: 80
series:
  - entity: sensor.zendure_2400_ac_vermogen_aansturing
    name: Batterij
    group_by:
      func: avg
      duration: 5sec
    type: area
    transform: return -x;
    stroke_width: 0
    opacity: 1
    extend_to: now
    color: "#f1b605"
    float_precision: 0
    yaxis_id: energy
    show:
      in_header: false
      in_brush: true
  - entity: sensor.p1_vermogen_met_batterij
    name: P1 met batterij
    group_by:
      func: avg
      duration: 5sec
    type: area
    stroke_width: 0
    opacity: 1
    extend_to: now
    color: "#46474c"
    float_precision: 0
    yaxis_id: energy
    show:
      in_header: false
      in_brush: true
  - entity: sensor.p1_meter_energy_export
    yaxis_id: header_only
    name: 60min (export)
    float_precision: 2
    group_by:
      func: diff
      duration: 60min
    show:
      legend_value: true
      in_header: true
      in_chart: false
  - entity: sensor.p1_meter_energy_import
    yaxis_id: header_only
    name: 60min (import)
    float_precision: 2
    group_by:
      func: diff
      duration: 60min
    show:
      legend_value: true
      in_header: true
      in_chart: false
  - entity: sensor.p1_meter_energy_import
    yaxis_id: header_only
    name: Vandaag (import)
    float_precision: 2
    statistics:
      period: day
      type: change
      align: start
    show:
      legend_value: true
      in_header: true
      in_chart: false
apex_config:
  toolbar:
    show: true
    tools:
      download: true
      selection: true
      zoom: true
      zoomin: true
      zoomout: true
      pan: true
  tooltip:
    x:
      format: HH:mm:ss
      show: false
  xaxis:
    labels:
      show: false
      style:
        colors: grey
    axisTicks:
      show: false
    axisBorder:
      color: "#616269"
  yaxis:
    - title:
        text: ""
      decimalsInFloat: 0
      labels:
        style:
          colors: "#7b7c83"
  grid:
    strokeDashArray: 0
    borderColor: rgb(52,52,52)
    show: true
  chart:
    height: 155px
  legend:
    show: false
  markers:
    size: 0
    hover:
      size: 0
visibility:
  - condition: state
    entity: input_boolean.toon_zendure_batterij_grafiek
    state: "on"

[Leguan]

ZuinigeRijder schreef op donderdag 15 januari 2026 @ 15:39:
Van de README van Zendure-zenSDK-proxy:


[...]


@gast777 In hoeverre zou er ook een proxy gemaakt kunnen worden met drie Zendure devices, bijvoorbeeld 3x Zendure 800 Plus? Dan zou je ook 2400 Watt ontlaad vermogen hebben, hetzelfde als 1x Solarflow 2400AC.

3 maal Zendure 800 Plus is goedkoper dan 1x 2400 AC, met ook nog eens 6 mppt aansluitingen én je zou ze zelfs nog over 3 fases kunnen verdelen.

Voor- en nadelen?

Ik heb de proxy aangepast naar 3 SolarFlow 2400 AC's. Misschien heb je er wat aan: https://github.com/Leguanjanin/Zendure-zenSDK-proxy_3

[lars1986]

Volgens mij doe ik iets heel simpels fout... Ik zie in de nordpool integratie wel de dagprijs voorbij komen maar krijg dit niet werkend... waar gaat het fout?

[denneappel]

Ik hoop dat iemand mij kan uitleggen waarom er 2 verschillende rest commands worden gebruikt voor laden en laden balanceren.
Is er een reden waarom er na het starten niet opnieuw iedere keer acmode meegegeven mag worden? Dat zou de 2e rest command overbodig maken namelijk.

YAML:

  zendure_x_laden:
    url: http://{{ states('input_text.zendure_2400_ac_ip_adres') }}/properties/write
    method: POST
    headers:
      Content-Type: application/json
      Content-Encoding: identity
    payload: '{"sn": "{{sn}}","properties": {"acMode": 1, "inputLimit": {{inputLimit}} }}'

  zendure_x_laden_balanceren:
    url: http://{{ states('input_text.zendure_2400_ac_ip_adres') }}/properties/write
    method: POST
    headers:
      Content-Type: application/json
      Content-Encoding: identity
    payload: '{"sn":"{{sn}}","properties":{"inputLimit": {{inputLimit}} }}'

[gast777]

Leguan schreef op donderdag 15 januari 2026 @ 16:55:
[...]


Ik heb de proxy aangepast naar 3 SolarFlow 2400 AC's. Misschien heb je er wat aan: https://github.com/Leguanjanin/Zendure-zenSDK-proxy_3

De proxy zou out-of-the-box moeten werken met met 2x SF800Plus (niet getest). Alleen even dit omzetten in de box "Vul hier de Zendure IP adressen en serienummers in":

code:

let maxPower = 2400 // for SF2400AC devices
//let maxPower = 800 // for SF800Pro devices

En inderdaad kun je het proberen met die 3-device aangepaste versie van @Leguan.

Combinatie met zonnepanelen direct aangesloten heeft wellicht nog wat meer haken en ogen.

[gielz]

lars1986 schreef op donderdag 15 januari 2026 @ 18:33:
Volgens mij doe ik iets heel simpels fout... Ik zie in de nordpool integratie wel de dagprijs voorbij komen maar krijg dit niet werkend... waar gaat het fout? [Afbeelding]

Dit is denk ik geen Nordpool HACS;

gielz in "Zendure producten in Home Assistant integreren deel 2" *tarieven 2025

[ Voor 10% gewijzigd door gielz op 15-01-2026 19:08 ]

[gielz]

denneappel schreef op donderdag 15 januari 2026 @ 18:39:
Ik hoop dat iemand mij kan uitleggen waarom er 2 verschillende rest commands worden gebruikt voor laden en laden balanceren.
Is er een reden waarom er na het starten niet opnieuw iedere keer acmode meegegeven mag worden? Dat zou de 2e rest command overbodig maken namelijk.

YAML:

  zendure_x_laden:
    url: http://{{ states('input_text.zendure_2400_ac_ip_adres') }}/properties/write
    method: POST
    headers:
      Content-Type: application/json
      Content-Encoding: identity
    payload: '{"sn": "{{sn}}","properties": {"acMode": 1, "inputLimit": {{inputLimit}} }}'

  zendure_x_laden_balanceren:
    url: http://{{ states('input_text.zendure_2400_ac_ip_adres') }}/properties/write
    method: POST
    headers:
      Content-Type: application/json
      Content-Encoding: identity
    payload: '{"sn":"{{sn}}","properties":{"inputLimit": {{inputLimit}} }}'

Zo min mogelijk properties elke keer sturen is het doel. Anders zou je ook gewoon bij elke wijziging smartmode kunnen meesturen.

[lars1986]

thanks @gielz dat was hem denk ik inderdaad! Kan ik verder met het inrichten

kijken of ik je dashboard na kan maken met alle info erop!

[gielz]

lars1986 schreef op donderdag 15 januari 2026 @ 19:10:
thanks @gielz dat was hem denk ik inderdaad! Kan ik verder met het inrichten

kijken of ik je dashboard na kan maken met alle info erop!

Toevallig vandaag gepost, iemand wou de illustratie/testboard van github;
https://gist.github.com/G...a051679c4b8eaa51d48331a05

[lars1986]

Top ik heb hem erop staan is kijken wat ik verder allemaal nog in moet stellen
Instellingen zoals maximale hoeveelheid vermogen moet je daar eerst in de zendure app nog toestemming voor geven of hoeft dat niet...

[gielz]

lars1986 schreef op donderdag 15 januari 2026 @ 19:38:
Top ik heb hem erop staan is kijken wat ik verder allemaal nog in moet stellen
Instellingen zoals maximale hoeveelheid vermogen moet je daar eerst in de zendure app nog toestemming voor geven of hoeft dat niet...

Tijdens de eenmalige installatie via de zendure app heb je dit gekozen.

Maar stel nou dat je denk van goh wat heb ik gekozen;
gielz in "Zendure producten in Home Assistant integreren deel 2"

[lars1986]

waardes staan hierop nu

"inverseMaxPower":800
"chargeMaxLimit":2400

Alleen mag ik nog niet met 2400 laden omdat hij op een gedeelde groep zit...
Volgende week wordt de accu aangesloten zodat hij beide op 2400 kan staan.

[gielz]

noo schreef op maandag 12 januari 2026 @ 09:31:
@gielz Misschien ook een leuke voor de maart update om de sensoren van de batterijen op de fysieke volgorde te krijgen.

Na het toevoegen van een vierde batterij onder aan de stapel bleek die in packData[1] te verschijnen ipv packData[3] waardoor mijn OCD ging opspelen. Met een kleine aanpassing en een paar input_texts waar je de serienummers invult kun je de sensoren nu in de gewenste volgorde krijgen:

YAML:

#
# Forceer batterijvolgorde van boven naar beneden dmv selecteren op serienummer ipv array indexing:
#
#   value_json.get('packData', [])
#     | selectattr('sn', 'eq', states('input_text.zendure_batterij_1_serienummer') )
#     | map(attribute='maxTemp')
#     | first
#     | default(none)
#
#
      - name: "Zendure 2400 AC Batterij 1 Temperatuur"
        value_template: >
          {% set maxTemp = value_json.get('packData', [])
            | selectattr('sn', 'eq', states('input_text.zendure_batterij_1_serienummer'))
            | map(attribute='maxTemp') | first | default(none) | int %}
          {{ (maxTemp - 2731) / 10.0 }}
        unique_id: Zendure_2400_AC_Batterij_1_Temperatuur
        unit_of_measurement: "°C"
        state_class: measurement
        device_class: temperature
        icon: mdi:thermometer

      - name: "Zendure 2400 AC Batterij 2 Temperatuur"
        value_template: >
          {% set maxTemp = value_json.get('packData', [])
            | selectattr('sn', 'eq', states('input_text.zendure_batterij_2_serienummer'))
            | map(attribute='maxTemp') | first | default(none) | int %}
          {{ (maxTemp - 2731) / 10.0 }}
        unique_id: Zendure_2400_AC_Batterij_2_Temperatuur
        unit_of_measurement: "°C"
        state_class: measurement
        device_class: temperature
        icon: mdi:thermometer
[...]

Dit komt er zeker aan maar de vraag was nog even hoe dit zo makkelijk mogelijk kan en dat het goed uit te breiden is met meer batterijgegevens;