Zendure producten in Home Assistant integreren deel 2

[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;

[lars1986]

Taro schreef op zondag 6 juli 2025 @ 20:28:
[...]

Ik heb in de configuration.yaml nog het volgende staan om de Nord Pool tarieven gelijk te krijgen aan de Zonneplan tarieven:

YAML:

  - platform: nordpool
    VAT: False
    currency: "EUR"
    price_in_cents: false
    low_price_cutoff: 0.9
    region: "NL"

Dit is voor elke aanbieder van dynamisch contract aan te passen denk ik toch? Wel interessant om eens te bekijken zit nu bij Hegg Energy en gebruik ook nordpool maar wel top als je de prijzen echt gelijk kan krijgen! 
    precision: 3
    price_type: kWh
    additional_costs: >
      {% set VAT = 0.21 %}
      {% set tax_kWh = 0.10154 %}
      {% set opslag = 0.0165 %}
      {{ (current_price * VAT ) + (tax_kWh + opslag) * (1 + VAT)|float }}

Als je Nord Pool tarieven nu al correct zijn, dan moet je gewoon de huidige beschikbare sensor gebruiken.

[Taro]

Ben even op gaan letten op of er export plaatsvindt terwijl de omvormers op 0 staan. En nu lijk ik dat bij alle 3 te constateren via de HW 3-fase kWh meter:


De properties van 1 van de 3:

{"timestamp":1768551241,"messageId":161,"sn":"SN","version":2,"product":"solarFlow2400AC","properties":{"heatState":0,"packInputPower":0,"outputPackPower":0,"outputHomePower":0,"remainOutTime":13100,"packState":2,"electricLevel":70,"gridInputPower":0,"solarInputPower":0,"solarPower1":0,"solarPower2":0,"solarPower3":0,"solarPower4":0,"solarPower5":0,"solarPower6":0,"pass":0,"reverseState":0,"socStatus":0,"hyperTmp":2961,"gridOffPower":0,"dcStatus":1,"pvStatus":0,"acStatus":2,"dataReady":1,"gridState":1,"BatVolt":4999,"socLimit":0,"faultLevel":0,"writeRsp":0,"acMode":1,"inputLimit":0,"outputLimit":0,"socSet":1000,"minSoc":150,"gridStandard":4,"gridReverse":1,"inverseMaxPower":2400,"lampSwitch":0,"gridOffMode":2,"IOTState":2,"fanSwitch":1,"fanSpeed":0,"bindstate":0,"VoltWakeup":0,"OldMode":0,"OTAState":0,"LCNState":0,"factoryModeState":0,"ts":1768551240,"tsZone":13,"smartMode":1,"chargeMaxLimit":2400,"phaseSwitch":1,"packNum":6,"rssi":-82,"is_error":0},"packData":[{"sn":"SN","packType":5,"socLevel":71,"state":2,"power":9,"maxTemp":2931,"totalVol":4990,"batcur":65534,"maxVol":332,"minVol":332,"softVersion":4106,"heatState":0},{"sn":"SN","packType":5,"socLevel":69,"state":2,"power":9,"maxTemp":2861,"totalVol":4980,"batcur":65534,"maxVol":332,"minVol":332,"softVersion":4106,"heatState":0},{"sn":"SN","packType":5,"socLevel":70,"state":2,"power":9,"maxTemp":2891,"totalVol":4990,"batcur":65534,"maxVol":333,"minVol":333,"softVersion":4106,"heatState":0},{"sn":"SN","packType":5,"socLevel":71,"state":2,"power":9,"maxTemp":2861,"totalVol":4990,"batcur":65534,"maxVol":332,"minVol":332,"softVersion":4106,"heatState":0},{"sn":"SN","packType":5,"socLevel":69,"state":2,"power":9,"maxTemp":2871,"totalVol":4990,"batcur":65534,"maxVol":332,"minVol":332,"softVersion":4106,"heatState":0},{"sn":"SN","packType":5,"socLevel":71,"state":2,"power":9,"maxTemp":2871,"totalVol":4990,"batcur":65534,"maxVol":333,"minVol":332,"softVersion":4106,"heatState":0}]}

acMode staat op 1. Nou heb ik de Off mode standaard zo staan:


Waarbij links de "fake meter" is en rechts de aansturing van de Zendure Manager uit de FireSon/Zendure integratie. Zet ik die rechter ook op Off, dan zie ik direct dit gebeuren:

Én de acMode springt dan naar 2, dat is Off.

Die 2x 7 Watt is correct, dat is het standby verbruik van 2x SF800 micro-omvormers op diezelfde aansluiting.

Dus zowel versie 1 als 2 hebben hier last van. In mijn automatisering ga ik dus niet meer alleen de fake meter op Off zetten, maar ook de Zendure integratie, dat scheelt >60 Watt verbruik en het leeglopen van de accu's.

[Taro]

lars1986 schreef op vrijdag 16 januari 2026 @ 09:20:
[...]

Had je hier nog een vraag over? Ik zie nu alleen de quote

[gielz]

Taro schreef op vrijdag 16 januari 2026 @ 09:24:
Ben even op gaan letten op of er export plaatsvindt terwijl de omvormers op 0 staan. En nu lijk ik dat bij alle 3 te constateren via de HW 3-fase kWh meter:
[Afbeelding]

De properties van 1 van de 3:

{"timestamp":1768551241,"messageId":161,"sn":"SN","version":2,"product":"solarFlow2400AC","properties":{"heatState":0,"packInputPower":0,"outputPackPower":0,"outputHomePower":0,"remainOutTime":13100,"packState":2,"electricLevel":70,"gridInputPower":0,"solarInputPower":0,"solarPower1":0,"solarPower2":0,"solarPower3":0,"solarPower4":0,"solarPower5":0,"solarPower6":0,"pass":0,"reverseState":0,"socStatus":0,"hyperTmp":2961,"gridOffPower":0,"dcStatus":1,"pvStatus":0,"acStatus":2,"dataReady":1,"gridState":1,"BatVolt":4999,"socLimit":0,"faultLevel":0,"writeRsp":0,"acMode":1,"inputLimit":0,"outputLimit":0,"socSet":1000,"minSoc":150,"gridStandard":4,"gridReverse":1,"inverseMaxPower":2400,"lampSwitch":0,"gridOffMode":2,"IOTState":2,"fanSwitch":1,"fanSpeed":0,"bindstate":0,"VoltWakeup":0,"OldMode":0,"OTAState":0,"LCNState":0,"factoryModeState":0,"ts":1768551240,"tsZone":13,"smartMode":1,"chargeMaxLimit":2400,"phaseSwitch":1,"packNum":6,"rssi":-82,"is_error":0},"packData":[{"sn":"SN","packType":5,"socLevel":71,"state":2,"power":9,"maxTemp":2931,"totalVol":4990,"batcur":65534,"maxVol":332,"minVol":332,"softVersion":4106,"heatState":0},{"sn":"SN","packType":5,"socLevel":69,"state":2,"power":9,"maxTemp":2861,"totalVol":4980,"batcur":65534,"maxVol":332,"minVol":332,"softVersion":4106,"heatState":0},{"sn":"SN","packType":5,"socLevel":70,"state":2,"power":9,"maxTemp":2891,"totalVol":4990,"batcur":65534,"maxVol":333,"minVol":333,"softVersion":4106,"heatState":0},{"sn":"SN","packType":5,"socLevel":71,"state":2,"power":9,"maxTemp":2861,"totalVol":4990,"batcur":65534,"maxVol":332,"minVol":332,"softVersion":4106,"heatState":0},{"sn":"SN","packType":5,"socLevel":69,"state":2,"power":9,"maxTemp":2871,"totalVol":4990,"batcur":65534,"maxVol":332,"minVol":332,"softVersion":4106,"heatState":0},{"sn":"SN","packType":5,"socLevel":71,"state":2,"power":9,"maxTemp":2871,"totalVol":4990,"batcur":65534,"maxVol":333,"minVol":332,"softVersion":4106,"heatState":0}]}

acMode staat op 1. Nou heb ik de Off mode standaard zo staan:
[Afbeelding]

Waarbij links de "fake meter" is en rechts de aansturing van de Zendure Manager uit de FireSon/Zendure integratie. Zet ik die rechter ook op Off, dan zie ik direct dit gebeuren:
[Afbeelding]
Én de acMode springt dan naar 2, dat is Off.

Die 2x 7 Watt is correct, dat is het standby verbruik van 2x SF800 micro-omvormers op diezelfde aansluiting.

Dus zowel versie 1 als 2 hebben hier last van. In mijn automatisering ga ik dus niet meer alleen de fake meter op Off zetten, maar ook de Zendure integratie, dat scheelt >60 Watt verbruik en het leeglopen van de accu's.

Blijft de smartmode dan op 1 staan bij smart matching in deze integratie als er geen smart matching (Nul op de meter) noodzakelijk is? Als dat zo is zou je dit even moeten melden als issue bij de Github.

[wautah91]

lars1986 schreef op vrijdag 16 januari 2026 @ 09:20:
[...]

Taro schreef op vrijdag 16 januari 2026 @ 09:25:
[...]
Had je hier nog een vraag over? Ik zie nu alleen de quote

Misschien toevallig dezelfde vraag als ik, geen idee


ik ben bezig deze te updaten naar de energiebelasting van 2026. Ik heb ook Zonneplan, wat mij opvalt is dat Nordpool werkt met de kwartierprijzen en Zonneplan met de uur prijzen. Kun je Nordpool laten werken met uurpijzen? De grafieken van het @gielz dashboard zijn ook gebaseerd op uurprijzen. Hoe gaan jullie hiermee om?

Zonneplan All-in prijzen 2026 voor de Nordpool HACS inetgratie
Region NL
Currency EUR
Vink BTW uit
additional_costs template:

code:

      {% set p = current_price | float(0) %}
      {% set opslag = 0.01653 %}
      {% set vat = 1.21 %}
      {% set energiebelasting = 0.1108 %}
      {{ ( ((p + opslag) * vat + energiebelasting) - p ) | float }}

[ Voor 34% gewijzigd door wautah91 op 16-01-2026 11:24 ]

[gielz]

wautah91 schreef op vrijdag 16 januari 2026 @ 10:33:
[...]


[...]

Misschien toevallig dezelfde vraag als ik, geen idee


ik ben bezig deze te updaten naar de energiebelasting van 2026. Ik heb ook Zonneplan, wat mij opvalt is dat Nordpool werkt met de kwartierprijzen en Zonneplan met de uur prijzen. Kun je Nordpool laten werken met uurpijzen? De grafieken van het @gielz dashboard zijn ook gebaseerd op uurprijzen. Hoe gaan jullie hiermee om?

Zonneplan All-in prijzen 2026

code:

{% set VAT = 1.21 %}
{% set tax_kWh = 0.1108 %}
{% set opslag = 0.01653 %}
{{ ((current_price  + opslag ) * VAT) + tax_kWh | float }}

Zonneplan exclusief energiebelasting prijzen 2026

code:

{% set VAT = 1.21 %}
{% set opslag = 0.01653 %}
{{ ((current_price  + opslag ) * VAT)  | float }}

In de gielz berekend hij dit volledig automatisch voor je. Wanneer je hebt uitgevinkt dat je 15minuten prijzen gebruikt zal hij dit automatisch verwerken in de attributen van sensor.dynamisch_nordpool

Deze sensor heeft Raw today en Raw tomorrow identiek aan de Nordpool HACS eigen sensor in de attributen bij het openklikken.

[Taro]

gielz schreef op vrijdag 16 januari 2026 @ 09:36:
[...]


Blijft de smartmode dan op 1 staan bij smart matching in deze integratie als er geen smart matching (Nul op de meter) noodzakelijk is? Als dat zo is zou je dit even moeten melden als issue bij de Github.

Ja/nee, dit komt door mijn specifieke lokale keuze. Ik pas de fake meter aan naar nul en laat de Zendure integratie op Smart Matching staan, wat dan eigenlijk niet de bedoeling is. Als ik de Zendure integratie op Off zet schakelt die netjes alles uit, dus is geen issue in de integratie, maar in mijn eigen implementatie

Ik wilde zowel handmatig laden/ontladen, slim laden/ontladen, NOM als Off allemaal via de fake meter laten verlopen en niet teveel schakelen met de omvormers. Maar in het geval van Off zal ik de Zendure integratie vanaf nu ook op Off zetten, dan is het opgelost.

[mcurlym]

Overpeinzing bij de laatste @gielz update: Schitterend dat Dynamisch NOM (duur) en Dynamisch Handelen zijn geintegreerd! Deze modi sluiten veel meer aan bij mijn idee van een batterij gebruiken; in een woonwijk is off-grid toch niet echt aan de orde. Nu bedacht ik het volgende: Dynamisch NOM (duur) is leuk, maar eigenlijk kan ik gewoon beter Dynamisch Handelen aanzetten. Nu komt het immers voor dat ik de batterij slechts deels gebruik in de dure uren, dan heb ik dus eigenlijk goedkope stroom 'verspild' of althans niet optimaal gebruikt.

Ik heb maar 5 kWh aan batterij, dus met 2-3 uur laden op goedkope uren is ie vol. Idem ontlaad ik de batterij in 2-3 uur tijdens de duurste periode. Wat meestal ook de periode is dat wij het meest intens stroom gebruiken.

Dus opladen als het goedkoop is, volledig ontladen als het duur is, en in tussentijd zorgen dat er minder stroom van de PV het net op gaat. Dat lijkt me het juiste scenario, of zie ik toch iets over het hoofd? Moet ik bv. mijn spread iets hoger zetten (nu op 20%)?

[Jerryvh]

Ik zet dus nog maar mijn eerste stappen in HA.
Tot op heden draaien mijn 3x4 hypers op NOM (niét via HA).
Omdat tijdens de wintermaanden deze regelmatig leeglopen, dacht ik aan een andere toepassing.

In Belgie betalen we een Capaciteitstarief; waarbij elke verbruikspiek van+2500W beboet wordt met een hoger nettarief. Eén enkele piek van 15min hoger dan 2500w is voldoende om je ganse maandtarief te zien stijgen.
Mijn idee is dus (in plaats van de hypers in de winter te gebruiken voor NOM) om de beschikbare capaciteit aan te wenden voor Peak Shaving - dus enkel te assisteren wanneer het verbruik boven de 2,5kW gaat.
Omdat dit niet zo heel veel/lang gebeurt, zou ik op deze manier zelfs met beperkte capaciteit in de akkus meerdere dagen moeten voortkunnen.

Zou dit lukken met een script?

[Jan-tweak]

ondertussen ben ik wat verder met mijn probleem dat binnen Hems de batterij langzaam met circa 20W aan het leeglopen is terwijl deze qua instellingen (basisloadmodus) eigenlijk volledig in standby zou moeten staan, iets wat de app overigens ook prima aangeeft.
binnen de app is dat (kleine) verbruik ook niet te zien met uitzondering dat je ziet dat de batterij met kleine stappen contunue leegloopt.

voorbeeld van het leeglopen. hierbij is dus HEMS ingeschakeld. met basisload 24 uur op standby.
hierbij is de SF 2400AC via een HW energie socket aan het net gekoppeld. (grafiek van HW)

de volgende dag heb ik om 9:00 het HEMS uitgeschakeld, geen andere instellingen verandard en wat blijkt, het ontladen stopt en blijft nu ook geheel op nul.
ik blijf het vreemd vinden dat hij blijkbaar bij HEMS ontlaad met circa 500Wh/Dag, dus bij 2 batterij modules is je batterij in circa 10 dagen volledig leeg getrokken en dat in de standby stand. terwijl als je hem uit de hems stand haalt hij dit gedrag niet heeft. Zeker in tijden dat je eigenlijk totaal geen PV overcapaciteit hebt vind ik dat je juist dan de batterij dus (deels gevuld) prima zou moeten weg zetten. Ik zal dit ook aan Zendure gaan melden.

[gielz]

Jerryvh schreef op vrijdag 16 januari 2026 @ 14:53:
Ik zet dus nog maar mijn eerste stappen in HA.
Tot op heden draaien mijn 3x4 hypers op NOM (niét via HA).
Omdat tijdens de wintermaanden deze regelmatig leeglopen, dacht ik aan een andere toepassing.

In Belgie betalen we een Capaciteitstarief; waarbij elke verbruikspiek van+2500W beboet wordt met een hoger nettarief. Eén enkele piek van 15min hoger dan 2500w is voldoende om je ganse maandtarief te zien stijgen.
Mijn idee is dus (in plaats van de hypers in de winter te gebruiken voor NOM) om de beschikbare capaciteit aan te wenden voor Peak Shaving - dus enkel te assisteren wanneer het verbruik boven de 2,5kW gaat.
Omdat dit niet zo heel veel/lang gebeurt, zou ik op deze manier zelfs met beperkte capaciteit in de akkus meerdere dagen moeten voortkunnen.

Zou dit lukken met een script?

Zeker, een eigen p1 meter maken in Home Assistant. Waarbij hij alleen NOM gaat draaien bij bijvoorbeeld boven de xxxx watt.

Pak bijvoorbeeld je huidige p1 en haal hier standaard 2000 watt van af dan is dus alles boven de 2000 voor de hyper om NOM op te draaien.

Nu de uitwerking nog heb geloof ik geen gebruikers in belgie anders was er vast al een Peak Shaving NOM modus of iets dergelijks.

[Taro]

FireSon/Zendure integratie versie 1.2.4 beschikbaar: https://github.com/Zendure/Zendure-HA/releases/tag/1.2.4, bovenop 1.2.3 die eerder vandaag al beschikbaar kwam.

[xtrme]

Ik heb sinds afgelopen donderdag 2x een sf800 pro zonder extra batterij als spielerij voor overstap naar het echte werk
maar volgens mij heb ik de charged and discharge verkeerd om ondanks dat ze naam technische met hass overeenkomen
Klopt dit (even sanity check)
Ik heb de zendure Hass integratie geïnstalleerd met de manager (die relatief traag reageert)
maar de individuele batterij reageren elke 2-3 sec
P1 meter is een homebuilt waar ik een helper bij gemaakt heb voor combinatie consumptie en productie

[DrNickB]

xtrme schreef op zaterdag 17 januari 2026 @ 12:33:
[Afbeelding]

Ik heb sinds afgelopen donderdag 2x een sf800 pro zonder extra batterij als spielerij voor overstap naar het echte werk
maar volgens mij heb ik de charged and discharge verkeerd om ondanks dat ze naam technische met hass overeenkomen
Klopt dit (even sanity check)
Ik heb de zendure Hass integratie geïnstalleerd met de manager (die relatief traag reageert)
maar de individuele batterij reageren elke 2-3 sec
P1 meter is een homebuilt waar ik een helper bij gemaakt heb voor combinatie consumptie en productie

Bij mijn Sf800Pro, welke ik gebruik via aangesloten zonnenpanelen om te laden:
'Zendure 800 Pro Zon Opwek' -> is mijn solar source
'Zendure 800 Pro Energie Export' en '... Import' -> zijn mijn Batterij instellingen.
Export = Geleverd aan het huis/net; Groen zichtbaar; Positief getal.
Import = Wat de batterij in is gegaan; Rood zichtbaar; Negatief getal. (HA: Energy Comming out of the battery)

is via de Gielz integratie, waarbij:
"Zendure 800 Pro Energie Export" -> sensor.zendure_800_pro_vermogen_export -> value_json['properties']['packInputPower']
Die laatste is het getal wat uit de json report wordt gehaald.

[sjnelle]

Taro schreef op vrijdag 26 september 2025 @ 18:42:
[...]

Je moet het bedrag incl. BTW pakken (want %), daarna maal de RTE. Dan heb je waardes waar je mee kunt rekenen. Dan zit je met een issue, want dan moet je de afschrijving en gewenste marge nog verrekenen, maar eigenlijk moet je die alleen van de hoge uren afhalen, zodat je het verschil tussen laag en hoog kunt zien en kunt bepalen of het de moeite waard is. Maar welke uren bereken je dat dan mee? Misschien in een array gooien, sorteren van laag naar hoog en hoog naar laag, dan eerst voor de 1e, dan voor de 2e controleren, etc. tot het punt dat de spread negatief is en dan stop je. Andere uitdaging: Als de hoge uren voor de lage uren liggen, dan heb je niets om mee te ontladen.

Het lijkt heel simpel, maar ik heb bijv. heel bewust mijn strategie hierop ingericht:

3 duurste uren in de avond ontladen, dan NOM, dan duurste 2 uren in de ochtend ontladen, zodat ze leeg zijn, en onder een bepaald bedrag laden wat soms ook al vroeger is dan de 2 duurste uren in de ochtend, maar dat is dan dus prima aangezien daar al ruimte voor was omdat er al 3 uren + NOM was ontladen. Zo is er altijd capaciteit beschikbaar.

In de lente en zomer is dit overigens nog iets geoptimaliseerd vs herst en winter, dan wordt er minder uren ontladen en tussendoor altijd NOM ipv Smart Discharge en Smart Charge gebruikt om alle zonnestroom op te slaan. Daarnaast heb ik knopjes voor wel/niet goedkoop manueel inkopen en opties om die op 15, 17 of 20 cent in te stellen, of gewoon de goedkoopste 5 uren.

Je wil het simpel houden, begrijp ik, maar het is mogelijk complexer dan je verwacht. Hopelijk lukt het je en ik wil zeker meedenken/meehelpen, maar benieuwd welke obstakels er gaandeweg naar voren komen.

Heb je deze configuratie ergens online staan. Zo zou ik het ook graag bouwen.

[Taro]

sjnelle schreef op zondag 18 januari 2026 @ 09:12:
[...]


Heb je deze configuratie ergens online staan. Zo zou ik het ook graag bouwen.

Je kunt deze hier vinden, echter moet ik hem nog steeds een keer naar een Blueprint ombouwen (nog geen tijd/puf voor gehad), want je zult allemaal foutmeldingen ivm foutieve device ID's krijgen: Taro in "Zendure producten in Home Assistant integreren deel 2"

Je zou hem kunnen copy pasten en daarna de device ID's vervangen door je lokale ID's.

[stfn345]

@gielz enig idee wat ik verkeerd doe?

Als ik de Dynamisch NOM (duur) mode gebruik dan zie ik dat hij met +- 800w aa het opladen is in de goedkope uren. Waarom is dat niet met 2400w? Ik heb 4 goedkope uren gedefinieerd en met 800 watt laadt hij dan maar 3.2kWh, onvoldoende om het pack vol te laden.

Als test heb ik zojuist handmatig "Opladen met 2400w" geselecteerd zie ik dat de inverter wel degelijk met 2400w aan het laden gaat, dus de limiet lijkt niet door de inverter gecapped te worden.

Ik heb momenteel deze settings op de inverter (net op de API gechecked):
"inverseMaxPower": 2400,
"chargeMaxLimit": 2400,

Ik zou verwachten dat hij in de 'goedkope uren' gewoon op 2400w de pack zou volladen ipv 800w.
Throttling vanwege temperatuur is niet het probleem.

Ik heb net de firmware maar geupgrade en kijk hoe het morgen gaat, een snelle blik op jouw code lijkt niet bewust een lagere chargerate in te stellen toch?

[gielz]

stfn345 schreef op zondag 18 januari 2026 @ 17:06:
@gielz enig idee wat ik verkeerd doe?

Als ik de Dynamisch NOM (duur) mode gebruik dan zie ik dat hij met +- 800w aa het opladen is in de goedkope uren. Waarom is dat niet met 2400w? Ik heb 4 goedkope uren gedefinieerd en met 800 watt laadt hij dan maar 3.2kWh, onvoldoende om het pack vol te laden.

Als test heb ik zojuist handmatig "Opladen met 2400w" geselecteerd zie ik dat de inverter wel degelijk met 2400w aan het laden gaat, dus de limiet lijkt niet door de inverter gecapped te worden.

Ik heb momenteel deze settings op de inverter (net op de API gechecked):
"inverseMaxPower": 2400,
"chargeMaxLimit": 2400,

Ik zou verwachten dat hij in de 'goedkope uren' gewoon op 2400w de pack zou volladen ipv 800w.
Throttling vanwege temperatuur is niet het probleem.

Ik heb net de firmware maar geupgrade en kijk hoe het morgen gaat, een snelle blik op jouw code lijkt niet bewust een lagere chargerate in te stellen toch?

De HA aansturing doet "nog" niets met het beperken van het vermogen. Standaard dus wat ingesteld is tijdens de installatie van de batterij.

Laat hem even goedkoop opladen starten en stuur mij dan via DM een printscreen van het log wat beschikbaar is bij input_select.zendure_2400_ac_modus_selecteren en daarbij ook even je properties van dat moment.

Ben benieuwd!

[stfn345]

@gielz Thanks, Ik heb de inverter firmware geupdatet en een reboot gegeven en even volgens jouw advies "goedkoop geladen" (lage spread ingesteld, 23 goedkope uren) en hij lijkt nu wel gewoon 2400w te laden.. vaag... Ik zal het een beetje in de gaten houden.