Zendure producten in Home Assistant integreren deel 2

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

Ik twijfel nog een beetje met het kiezen van de juiste modus in ZenSDK. Wie kan/wil daar iets zinvols over zeggen? Ik heb een dynamisch contract bij zonneplan. Nu we nog kunnen salderen lijkt Handelen misschien een betere optie dan NOM of NOM (duur) in de winter.

Ik heb mijn spread op 20% staan met NOM (duur), maar gevoelsmatig is het gunstig om naar modus "Handelen" te gaan als de spread nog veel groter is, zoals vandaag en morgen (40%+) ?

De zonnepanelen leveren bijna niets op in de winter, maar in de zomer natuurlijk wel - en lijkt NOM eerder een gunstige optie te zijn voor de zomer.

[ Voor 53% gewijzigd door stfn345 op 19-01-2026 17:40 ]

[lars1986]

Welke battery card gebruiken jullie om de accu mooi visueel in HA te krijgen?
Zag laatst hier een mooie kaart voorbij komen maar kan hem helaas niet meer terug vinden

[mcurlym]

stfn345 schreef op zondag 18 januari 2026 @ 17:45:

De zonnepanelen leveren bijna niets op in de winter, maar in de zomer natuurlijk wel - en lijkt NOM eerder een gunstige optie te zijn voor de zomer.

Die overweging heb ik ook. Dynamisch handelen lijkt de betere optie in de winter. Maar ik heb wel gemerkt dat hij in die modus niet oplaadt met overtollige (en dus gratis) stroom van de PV. Al bedenk ik met net dat dat vermoedelijk gewoon komt omdat ie al vol zat van opladen tijdens de goedkope uren.

@gielz is het een idee om het mogelijk te maken om een tweede modus te selecteren? Of kan ik aanpassen in dynamisch handelen dat als goedkoop/duur beide = nee, dan niet stand-by maar NOM?

[Rolfie]

lars1986 schreef op maandag 19 januari 2026 @ 19:47:
Welke battery card gebruiken jullie om de accu mooi visueel in HA te krijgen?
Zag laatst hier een mooie kaart voorbij komen maar kan hem helaas niet meer terug vinden

Deze misschien?
Battery State Card

[gielz]

mcurlym schreef op maandag 19 januari 2026 @ 22:06:
[...]


@gielz is het een idee om het mogelijk te maken om een tweede modus te selecteren? Of kan ik aanpassen in dynamisch handelen dat als goedkoop/duur beide = nee, dan niet stand-by maar NOM?

Wat je dus eigenlijk zoekt is Goedkoop opladen, Duur maximaal ontladen en tussen die periodes gewoon NOM (dus zon laden en ontladen indien nodig)? Onderwater zit alles er in dus het is vrij makkelijk om extra modussen beschikbaar te maken.

Voor de toekomstige Maart release staat nu iig dit op het lijstje (kan nog bij). Dit loopt intern al en kan vanaf Februari ook openbaar getest worden; https://github.com/Gielz1986/Zendure-HA-zenSDK/pull/22

[stfn345]

@gielz dat klinkt inderdaad als de gewenste modus (voor mij althans):

1. Goedkoop opladen (periode goedkoopst=true) mits threshold behaald
2. Bij de hoogste prijzen (periode duurst=true) = maximaal ontladen
3. Buiten deze tijden gewoon NOM (dus zon laden indien beschikbaar)

Verder heb ik nog wat ideeen (ik begrijp dat dit zeker niet makkelijk is):

1. Ideaal gezien zou er ook nog een stukje logica toegevoegd worden waardoor het hardcoden van de goedkope en dure uren niet meer nodig is. Dus het bepalen van de hoeveelheid goedkope en dure uren, juist op basis van de threshold ipv andersom.

2. In het verlengde hiervan (in Handel modus): Als het systeem zou kunnen berekenen: mijn SOC/kWh is momentel X, er komen dadelijk Y uren aan waarop ik maximaal ga ontladen. op welke uren kanik dan goedkoop bijladen zodat ik voldoende stroom heb voordat dure uren komen en voldoende stroom heb om maximaal kan ontladen tijdens de Z dure uren. (goedkope uren na de ontlaadperiode zijn dan minder nuttig). Dit is dus vooral: waar zitten mijn goedkope uren t.o.v de dure uren, niet alleen hoeveel.

3. En om het geheel nog wat complexer te maken : Als de automatisering op een manier zou kunnen gokken/inschatten of het de accus vandaag ook via solar geladen gaan worden (en daarmee de vraag kunnen afdekken voor NOM + de dure periode) kun je de hoeveelheid 'goedkope uren' naar beneden schroeven waarbij van het net geladen wordt.

[ Voor 3% gewijzigd door stfn345 op 20-01-2026 11:03 ]

[ppaulv]

gielz schreef op zaterdag 10 januari 2026 @ 16:05:
[...]

[Afbeelding]

Hi @gielz . Twee vragen.
Ten eerste dit plaatje. Met name het onderste deel vind ik erg interessant maar heb geen idee hoe ik dat te zien kan krijgen. Heb de laatste (stabiele) versie in gebruik maar zie die zaken rond vertraging en marge niet. Weet ook niet zeker of mij dat gaat helpen met mijn 'oude' probleem.
In jouw automatisering heb ik al zowat alles wat gewijzigd kan worden gewijzigd (aantallen, parameters, niet de logica zelf) maar zonder effect.
M'n Zendure gaat echt veel te snel calibreren/aanpassen. Bijvoorbeeld vandaag.
M'n panelen produceren zo'n 1kW, ik verbruik nu zelf zo'n 200W dus zo'n 800W gaat terug het net in.
Heb 'slim opladen' aangezet en hij gaat meteen met zo'n 800W opladen. En 2 seconden later het dubbele, en 2 seconden later het drievoudige, etc. En dan na zo'n 10 sec krijgt ie nieuwe data van de P1 meter, ziet dat ik inmiddels 1.5kW uit het net haal en gaat meteen in standby. Om een paar seconden later weer te gaan opladen en herhaalt het spelltje zich.
Ik heb na vele uren zoeken, proberen en opnieuw zoeken niet kunnen ontdekken hoe ik dit flipperen weg kan krijgen.
Als de oplaad-aanpassingen vertraagd worden met 10 seconden zou het goed moeten gaan maar dat gebeurt nu elke seconde, misschien 2, en dat is veel te snel.
Enige suggestie hoe dit te fixen?

[mcurlym]

gielz schreef op maandag 19 januari 2026 @ 22:23:
[...]


Wat je dus eigenlijk zoekt is Goedkoop opladen, Duur maximaal ontladen en tussen die periodes gewoon NOM (dus zon laden en ontladen indien nodig)? Onderwater zit alles er in dus het is vrij makkelijk om extra modussen beschikbaar te maken.

yep, dat klinkt voor mij als de manier om een kleine batterij maximaal te gebruiken. Je zou ook kunnen opteren om tussen die periodes ipv NOM, enkel slim opladen te kunnen kiezen. Want dan zou je kunnen kiezen om slechts 1-2 uur goedkoop opladen te doen en de rest tijdens de dag op te laden als er zon overschot is.

Die keuze zou je dan vervolgens kunnen koppelen aan de dag van de week. bv. werk ik thuis, dan geen NOM overdag, want dan is de batterij vermoedelijk leeg op het moment van de duurste uren. (althans tijdens de donkere wintermaanden).

[martinvdm]

gielz schreef op maandag 19 januari 2026 @ 22:23:
[...]


Wat je dus eigenlijk zoekt is Goedkoop opladen, Duur maximaal ontladen en tussen die periodes gewoon NOM (dus zon laden en ontladen indien nodig)? Onderwater zit alles er in dus het is vrij makkelijk om extra modussen beschikbaar te maken.

Voor de toekomstige Maart release staat nu iig dit op het lijstje (kan nog bij). Dit loopt intern al en kan vanaf Februari ook openbaar getest worden; https://github.com/Gielz1986/Zendure-HA-zenSDK/pull/22

[Afbeelding]

Ik heb ook nog ff bijgewerkt naar de laatste release. Ik had die natuurlijk in grote delen al vanwege het testen, maar zaten toch nog wat aanpassingen in. Top werk.
Voor wat betreft de eerdere vraag snap ik die wel. Nu is Dynamisch Handelen dus goedkoop opladen en duur maximaal ontladen en ertussenin Standby. Op zich logisch zoals al beschreven wordt anders is mogelijk je batterij al leeg voordat je dure uren beginnen. Je zou dan een Dynamisch NOM Handelen moeten hebben om tussentijds ook NOM te doen.

[koboy]

martinvdm schreef op dinsdag 20 januari 2026 @ 16:32:
[...]

Ik heb ook nog ff bijgewerkt naar de laatste release. Ik had die natuurlijk in grote delen al vanwege het testen, maar zaten toch nog wat aanpassingen in. Top werk.
Voor wat betreft de eerdere vraag snap ik die wel. Nu is Dynamisch Handelen dus goedkoop opladen en duur maximaal ontladen en ertussenin Standby. Op zich logisch zoals al beschreven wordt anders is mogelijk je batterij al leeg voordat je dure uren beginnen. Je zou dan een Dynamisch NOM Handelen moeten hebben om tussentijds ook NOM te doen.

Je kunt het allemaal heel erg ingewikkeld maken, maar ik denk dat je er met de volgende 2 standen al bent voor de situatie 2027+:
- Voor de winter: dynamisch laden en boven de spread grens NOM
- rest van het jaar NOM, en gedurende de duurste uren ontladen tot een bepaalde instelbare ondergrens zodat je nog NOM de nacht doorkomt

Je kunt natuurlijk altijd nog meer precisie willen aanbrengen, maar ik denk dat je hiermee al minimaal 95% van de financiële winst binnen hebt. Bij vakantie pas je dan natuurlijk de dingen wat aan....

[Supermario16]

stfn345 schreef op dinsdag 20 januari 2026 @ 11:03:
@gielz dat klinkt inderdaad als de gewenste modus (voor mij althans):

1. Goedkoop opladen (periode goedkoopst=true) mits threshold behaald
2. Bij de hoogste prijzen (periode duurst=true) = maximaal ontladen
3. Buiten deze tijden gewoon NOM (dus zon laden indien beschikbaar)

Verder heb ik nog wat ideeen (ik begrijp dat dit zeker niet makkelijk is):

1. Ideaal gezien zou er ook nog een stukje logica toegevoegd worden waardoor het hardcoden van de goedkope en dure uren niet meer nodig is. Dus het bepalen van de hoeveelheid goedkope en dure uren, juist op basis van de threshold ipv andersom.

2. In het verlengde hiervan (in Handel modus): Als het systeem zou kunnen berekenen: mijn SOC/kWh is momentel X, er komen dadelijk Y uren aan waarop ik maximaal ga ontladen. op welke uren kanik dan goedkoop bijladen zodat ik voldoende stroom heb voordat dure uren komen en voldoende stroom heb om maximaal kan ontladen tijdens de Z dure uren. (goedkope uren na de ontlaadperiode zijn dan minder nuttig). Dit is dus vooral: waar zitten mijn goedkope uren t.o.v de dure uren, niet alleen hoeveel.

3. En om het geheel nog wat complexer te maken : Als de automatisering op een manier zou kunnen gokken/inschatten of het de accus vandaag ook via solar geladen gaan worden (en daarmee de vraag kunnen afdekken voor NOM + de dure periode) kun je de hoeveelheid 'goedkope uren' naar beneden schroeven waarbij van het net geladen wordt.

Ik heb zelf geen Home Assistant, maar volg het topic wel. Ik heb een eigen ontwikkelde omgeving en maak gebruik van Solcast om de opbrengst van mijn zonnepanelen te voorspellen. Het is niet perfect, maar ik ga wel proberen dit werkend te krijgen. Bedankt voor de "strategische" tips!

[gast777]

ppaulv schreef op dinsdag 20 januari 2026 @ 11:19:
[...]
Heb 'slim opladen' aangezet en hij gaat meteen met zo'n 800W opladen. En 2 seconden later het dubbele, en 2 seconden later het drievoudige, etc. En dan na zo'n 10 sec krijgt ie nieuwe data van de P1 meter, ziet dat ik inmiddels 1.5kW uit het net haal en gaat meteen in standby. Om een paar seconden later weer te gaan opladen en herhaalt het spelltje zich.
Ik heb na vele uren zoeken, proberen en opnieuw zoeken niet kunnen ontdekken hoe ik dit flipperen weg kan krijgen.
Als de oplaad-aanpassingen vertraagd worden met 10 seconden zou het goed moeten gaan maar dat gebeurt nu elke seconde, misschien 2, en dat is veel te snel.
Enige suggestie hoe dit te fixen?

Klinkt alsof je het bekende probleem hebt met de oude P1 meters die slechts om de 10 seconden nieuwe data geven ipv elke seconde. Je kunt het update interval van Gielz aanpassen in de automatisering, die normaliter 4 seconden is. Als je die hoger zet zou het wat beter moeten gaan (nog niet optimaal maar toch).



Maar eigenlijk is het beter om de P1 meter te laten vervangen of een meter met CT klemmen gebruiken die wel elke seconde nieuwe data geeft (Shelly).

[ppaulv]

@gast777 bedankt voor je reactie. Maar het is de 'slimme' meter die iedere 10 sec nieuwe data levert. De P1 doet het iedere seconde meen ik?
De aanpassing die je hier aangeeft heb ik al uitvoerig getest, op 10 maar ook op 15 sec, zonder effect.
Maar dat was in een vorige versie, misschien is het nu anders geworden. Ik zal het laten weten zodra ik het heb kunnen testen.
@gast777 helaas, ik was zo'n 700W aan het terugleveren, zet 'alleen slim opladen' aan en elke 2 à 3 seconden gaat ie 700W extra opladen. Eerst 700, dan 1400 en daarna 2100. Iedere stap zoals gezegd na zo'n 3 seconden wachttijd. De triggertijd zoals jij die aangaf staat op 11 seconden. Vervolgens zie ie dat er uit het net getrokken wordt en gaat meteen over op standby in enkele stappen van een seconde of 2.
Dus dat werk niet en ik zoek nog steeds naar de plek waar die 3 seconden vandaan komen...
Begin te denken dat HA dit gewoon niet aankan, maar is er een alternatief (zonder 3 klemmen aan te schaffen en/of m'n meterkast te vernielen zodat ie vervangen wordt door een nieuwste versie)?

[ Voor 49% gewijzigd door ppaulv op 21-01-2026 11:33 ]

[JSven]

Ik heb sinds v1.2.X van de fireson integratie het probleem dat in smart modus hij een tijdje niets doet terwijl er genoeg productie van mijn zonnepanelen om te laden. Nadat ik een oude versie had teruggezet was dit veel stabieler. Is dit een bekend probleem?

[ Voor 14% gewijzigd door JSven op 21-01-2026 16:00 ]

[Jerryvh]

Eén van de statistieken die HA afleest uit de AB2000S, is de celtemperatuur.
Ik heb, eveneens via HA, een trigger gezet, die alle lampen in huis (overal Philips Hue) rood laat flikkeren wanneer de celtemp de 50 graden overschrijdt - in de hoop aldus sneller te kunnen ingrijpen bij een mogelijks incident (thermal runaway).

Nu stel ik vast dat de statistiek "hoogste celtemperatuur" zelden boven de 25 graden uitkomt (staat weliswaar in een onverwarmde garage, en het is koud nu). Is dit normaal? Is deze statistiek wel een goede manier om een aankomende thermal runaway vroeger te spotten?

[Bert Luiten]

hallo, ben in het bezit van een 800pro en nu ook van een 800plus, probeer deze via de HA uit te lezen. de 800pro had ik er al in zitten ( werkt prima.. ) maar de 800plus wil zich niet melden... heeft iemand daar nu al ervaring mee ?
ben benieuwd of iemand dat al voor mekaar heeft...
dank voor jullie reactie..

groet Bert

[crbnnw]

Bert Luiten schreef op woensdag 21 januari 2026 @ 18:04:
hallo, ben in het bezit van een 800pro en nu ook van een 800plus, probeer deze via de HA uit te lezen. de 800pro had ik er al in zitten ( werkt prima.. ) maar de 800plus wil zich niet melden... heeft iemand daar nu al ervaring mee ?
ben benieuwd of iemand dat al voor mekaar heeft...
dank voor jullie reactie..

groet Bert

Als het goed is moet je dan even naar Instellingen > Apparaten en Diensten en dan de Zendure integratie herladen in Home Assistant.

[Bert Luiten]

hoi, dank voor je reactie.. deze actie had ik al ondernomen... helaas zonder het gewenste resultaat....

[gast777]

ppaulv schreef op woensdag 21 januari 2026 @ 10:04:
@gast777 bedankt voor je reactie. Maar het is de 'slimme' meter die iedere 10 sec nieuwe data levert.

Klopt, ik bedoel de 'slimme' meter.

De P1 'meter' is geen meter, maar alleen een dongeltje dat de meetwaarden toont/doorgeeft, die de slimme meter uitspuugt op de P1 poort.

Waar die 3 seconden vandaan komt weet ik niet. Heb je wel HA herstart (Quick reload) na de aanpassing in de automation (ik weet niet of dat per se nodig is)?

[gielz]

Bert Luiten schreef op woensdag 21 januari 2026 @ 18:29:
hoi, dank voor je reactie.. deze actie had ik al ondernomen... helaas zonder het gewenste resultaat....

Kun je hem wel pingen en werkt http://<IP>/properties/report ?

[meesje]

Bert Luiten schreef op woensdag 21 januari 2026 @ 18:04:
hallo, ben in het bezit van een 800pro en nu ook van een 800plus, probeer deze via de HA uit te lezen. de 800pro had ik er al in zitten ( werkt prima.. ) maar de 800plus wil zich niet melden... heeft iemand daar nu al ervaring mee ?
ben benieuwd of iemand dat al voor mekaar heeft...
dank voor jullie reactie..

groet Bert

Welke methode gebruik je om dit voor elkaar te krijgen? Ik heb er zelf nog geen ervaring mee. Maar in de topic start van Zendure producten in Home Assistant integreren deel 2 lees ik dat de Gielz methode 1 omvormer ondersteunt of meerdere als je de proxy optie kiest.

[Bert Luiten]

binnen de zendure app werkt hij gewoon mee in hems.. naast de 800pro..

[Bert Luiten]

gielz schreef op woensdag 21 januari 2026 @ 18:44:
[...]


Kun je hem wel pingen en werkt http://<IP>/properties/report ?

ja kan de prop's opvragen....

[Hieke]

Bert Luiten schreef op woensdag 21 januari 2026 @ 19:19:
binnen de zendure app werkt hij gewoon mee in hems.. naast de 800pro..

Herkenbaar.
Een tweede device later toevoegen in bestaande omgeving in HA werkte bij mij ook niet..

Nadat ik complete integratie had verwijderd, HA herstart en nieuwe omgeving had aangemaakt verschenen beide wel. Was weliswaar met 2× SF2400.

[Taro]

Even opnieuw inloggen in de HA integratie lost het doorgaans op, dan wordt de nieuwe devicelist uit de cloud opgehaald.

[Bert Luiten]

ok, ga ik proberen, dank voor je tip.. laat het weten of het lukt..

[Bert Luiten]

mmmhoe log ik opnieuw waarin... ? eerst de hele integratie verwijderen of.. ik zie niet echt een opnieuw inlog optie ..

[ppaulv]

Beide, quick reload en een echte restart.
Dus ik niet snap niet....

[gielz]

ppaulv schreef op woensdag 21 januari 2026 @ 20:09:
Beide, quick reload en een echte restart.
Dus ik niet snap niet....

Zou je hem eens op 20 seconden kunnen zetten en dan mij de logs kunnen van (input_select.zendure_2400_ac_modus_selecteren) sturen via DM.

[Taro]

Bert Luiten schreef op woensdag 21 januari 2026 @ 19:36:
mmmhoe log ik opnieuw waarin... ? eerst de hele integratie verwijderen of.. ik zie niet echt een opnieuw inlog optie ..

En anders de integratie even weggooien en opnieuw toevoegen. Evt. instellingen blijven dan wel bewaard.

[Bert Luiten]

het gekke is dat ik dat al gedaan heb en de instellingen blijven ook bewaard... als ik doe wat jij aangeeft komt bij mij de token vraag niet naar voren, welke optie kies jij daar dan ? en welke versie software heb jij ?
hier draait Versie 1.0.47

[ppaulv]

Zal kijken of ik morgen een geschikte situatie kan creëren dat ie weer gaat flipperen.

[ppaulv]

gielz schreef op woensdag 21 januari 2026 @ 20:35:
[...]


Zou je hem eens op 20 seconden kunnen zetten en dan mij de logs kunnen van (input_select.zendure_2400_ac_modus_selecteren) sturen via DM.

Hoe krijg ik die log als txt te zien? Kan n alleen schermprintjes maken en dat is niet handig.
In het popup scherm zie ik de log bewegingen maar onder 'history' in HA staat helemaal niets.
Heb nu wat gevonden onder 'activity'.
Stuur het je via DM @gielz . Alvast dank.

[ Voor 20% gewijzigd door ppaulv op 22-01-2026 11:43 ]

[Bert Luiten]

Taro schreef op woensdag 21 januari 2026 @ 20:41:
[...]

[Afbeelding]

En anders de integratie even weggooien en opnieuw toevoegen. Evt. instellingen blijven dan wel bewaard.

Hoi, uiteindelijk is het me toch gelukt om zowel de 800pro als de 800plus in de zendure integratie te krijgen op deze manier, heel bedankt voor jullie hulp...

[Bert Luiten]

staat nou mooi te pruttelen en van de zon te genieten....

[hjw-001]

Kijk, mooi bericht hierboven met een goed voorbeeld dat menig tweaker dus ook nadenkt over de koeling van de omvormers, maar die 90 pieken van Zendure niet zo zien zitten voor 2 simpele fans - net zoals ikzelf. Dus ik ben gaan hobby-en.

Ik heb wat tijd geïnvesteerd om zelf een aantal ESP32 Wifi FanControllers te maken voor beheer van de koeling vanuit Home Assistant. Alles zelf in elkaar gesoldeerd, maar moest in 10-voud bestellen, er zijn dus nog wel wat onderdelen beschikbaar.. voor de liefhebber. De voeding zit er niet bij maar specs zijn: DC 12V adapter met minimaal 2 of 3A. Het operereert stand-alone totdat je zelf de automatiseringen in HA toevoegd op basis van de temperatuur sensoren van je zendure-pakket.

Je schakelt vanuit HA de 12V relais aan of uit. Vervolgens kan je het PWM signaal voor alle aangesloten ventilatoren tegelijk instellen. Alles is ook uit te lezen. Geschikt voor 1 tot 8 PWM fans. Het is opgebouwd naar voorbeeld van een andere tweaker. https://github.com/joshua...an-controller/tree/master ik heb zelf alle onderdelen besteld en ben aan de gang gegaan. Dat is toch wel leuk knutselen

Klein maar handige toevoeging al zeg ik het zelf

[ Voor 32% gewijzigd door hjw-001 op 22-01-2026 21:22 ]

[Taro]

hjw-001 schreef op donderdag 22 januari 2026 @ 21:15:
Kijk, mooi bericht hierboven met een goed voorbeeld dat menig tweaker dus ook nadenkt over de koeling van de omvormers, maar die 90 pieken van Zendure niet zo zien zitten voor 2 simpele fans - net zoals ikzelf. Dus ik ben gaan hobby-en.

Ik heb wat tijd geïnvesteerd om zelf een aantal ESP32 Wifi FanControllers te maken voor beheer van de koeling vanuit Home Assistant. Alles zelf in elkaar gesoldeerd, maar moest in 10-voud bestellen, er zijn dus nog wel wat onderdelen beschikbaar.. voor de liefhebber. De voeding zit er niet bij maar specs zijn: DC 12V adapter met minimaal 2 of 3A. Het operereert stand-alone totdat je zelf de automatiseringen in HA toevoegd op basis van de temperatuur sensoren van je zendure-pakket.

Je schakelt vanuit HA de 12V relais aan of uit. Vervolgens kan je het PWM signaal voor alle aangesloten ventilatoren tegelijk instellen. Alles is ook uit te lezen. Geschikt voor 1 tot 8 PWM fans. Het is opgebouwd naar voorbeeld van een andere tweaker. https://github.com/joshua...an-controller/tree/master ik heb zelf alle onderdelen besteld en ben aan de gang gegaan. Dat is toch wel leuk knutselen

Klein maar handige toevoeging al zeg ik het zelf

[Afbeelding]

Altijd leuk om zelf te knutselen natuurlijk, maar dit kan toch veel makkelijker? Er zit een uitgang op de 2400AC/SF800Pro, kabeltje naar 2 fans en dan stuurt de omvormer de ventilatoren direct aan als die >40 graden wordt.

Heb je geen 2400AC/SF800Pro of Zendure stekker, dan kan je via HA gewoon de omvormer temperatuur uitlezen en met een slimme stekker de fans activeren boven temperatuur X, daar is toch geen hele controller voor nodig?

[hjw-001]

Dat kan natuurlijk ook harstikke goed. Maar 3 van die kabeltjes gaan op marktplaats ook voor totaal 75 euro. Ik weet het die zijn zelf ook wel na te bestellen voor veel minder. Maargoed kon het niet gemakkelijk vinden. Daarnaast was destijds de Zendure Fan switch ook nog simpel on/off 12V. Dan ben ik tevreden met 1 unit van minder dan 2 tientjes die 8 fans kan aansturen, met preciezere snelheid instructies Zo heb ik altijd airflow en jaag gewoon het toerental op als het nodig is.

Die 3D print behuizingen zien er wel puik uit, zijn daar de files van beschikbaar?

[ Voor 13% gewijzigd door hjw-001 op 23-01-2026 09:05 ]

[gielz]

hjw-001 schreef op vrijdag 23 januari 2026 @ 09:04:
Dat kan natuurlijk ook harstikke goed. Maar 3 van die kabeltjes gaan op marktplaats ook voor totaal 75 euro. Ik weet het die zijn zelf ook wel na te bestellen voor veel minder. Maargoed kon het niet gemakkelijk vinden. Daarnaast was destijds de Zendure Fan switch ook nog simpel on/off 12V. Dan ben ik tevreden met 1 unit van minder dan 2 tientjes die 8 fans kan aansturen, met preciezere snelheid instructies Zo heb ik altijd airflow en jaag gewoon het toerental op als het nodig is.

Die 3D print behuizingen zien er wel puik uit, zijn daar de files van beschikbaar?

Zullen wij het weer over Home Assistant hebben, thanks! Dit is meer iets voor het reguliere topic. Deze fan is gemaakt door @geert1992 en er is geen openbare file van zo ver ik weet. Wel te koop op marktplaats moet je even op "zendure fan" zoeken; https://www.marktplaats.nl/q/zendure+fan/

[Fremske]

Hallo, ik heb mijn SF800 plus deze week geïnstalleerd en gekoppeld met Home Assistant via de cloud api. Tijdens de installatie moest ik mijn P1 sensor invoeren voor het verbruik maar er werd niet gevraagd om een sensor op te voeren voor de opwek. Hoe kan de SF800 null op de meter draaien via HA als het alleen maar verbruik data ontvangt?

2de vraag, ik heb de SF800 volledig uitgezet via Home Assistant, zie screenshots. Maar tocht loopt mijn SoC iedere dag met 5% terug, hoe kan dit?

[gielz]

Fremske schreef op vrijdag 23 januari 2026 @ 17:57:
Hallo, ik heb mijn SF800 plus deze week geïnstalleerd en gekoppeld met Home Assistant via de cloud api. Tijdens de installatie moest ik mijn P1 sensor invoeren voor het verbruik maar er werd niet gevraagd om een sensor op te voeren voor de opwek. Hoe kan de SF800 null op de meter draaien via HA als het alleen maar verbruik data ontvangt?

2de vraag, ik heb de SF800 volledig uitgezet via Home Assistant, zie screenshots. Maar tocht loopt mijn SoC iedere dag met 5% terug, hoe kan dit?

[Afbeelding]

[Afbeelding]

[Afbeelding]

Er is iig stroom nodig om de batterij werkend te houden. Hier is dat 0,2kwh per dag bij een 2400 AC.

Wanneer hij op off staat en je de SOC ziet dalen waar staat de smartmode dan op is dat 0 of 1? En wat zie je op een externe meting wat betreft wattage (via bijv een slimme stekker)?

[Sander]

Fremske schreef op vrijdag 23 januari 2026 @ 17:57:
Hallo, ik heb mijn SF800 plus deze week geïnstalleerd en gekoppeld met Home Assistant via de cloud api. Tijdens de installatie moest ik mijn P1 sensor invoeren voor het verbruik maar er werd niet gevraagd om een sensor op te voeren voor de opwek. Hoe kan de SF800 null op de meter draaien via HA als het alleen maar verbruik data ontvangt?

2de vraag, ik heb de SF800 volledig uitgezet via Home Assistant, zie screenshots. Maar tocht loopt mijn SoC iedere dag met 5% terug, hoe kan dit?

[Afbeelding]

[Afbeelding]

[Afbeelding]

Je P1 geeft een netto verbruik of teruglevering van je woning, daar springt de SF800 dan voor bij, of laadt juist op als je overschot hebt na eigen verbruik. Opwek is eigenlijk totaal niet relevant bij dit soort dingen want opwek die je zelf verbruikt blijft ‘voor’ de meter en wil je dus ook niet in een batterij gaan opslaan

[ Voor 6% gewijzigd door Sander op 24-01-2026 10:18 ]

[PeaceNlove]

Omdat de HW P1 het bij mij ook laat afweten met 0W in HEMS ook maar eens de sprong in het diepe gedaan met de integratie van Gielz.

Helaas heb ik wel een P1 die maar eens per 10 seconden update. Gelukkig hier al snel gevonden dat je dan de update veel hoger dan 4 seconden moet zetten en ik heb daar 20 van gemaakt. Nu lijkt het wel aardig te draaien, ook met een schakelende oven momenteel aan waarbij ik telkens van terugleveren naar gebruik ga op de P1.
Niet ontevreden met de resultaten tot zo ver, nu ook lekker statistieken en grafieken verzamelen in HA

[koboy]

PeaceNlove schreef op zaterdag 24 januari 2026 @ 12:57:
Omdat de HW P1 het bij mij ook laat afweten met 0W in HEMS ook maar eens de sprong in het diepe gedaan met de integratie van Gielz.

Helaas heb ik wel een P1 die maar eens per 10 seconden update. Gelukkig hier al snel gevonden dat je dan de update veel hoger dan 4 seconden moet zetten en ik heb daar 20 van gemaakt. Nu lijkt het wel aardig te draaien, ook met een schakelende oven momenteel aan waarbij ik telkens van terugleveren naar gebruik ga op de P1.
Niet ontevreden met de resultaten tot zo ver, nu ook lekker statistieken en grafieken verzamelen in HA

Die 10 seconden geldt alleen als je een DSMR4 meter hebt. Met een DSMRt meter spuugt die in elk geval elke seconde de tellerstanden uit,aar is het aan de integratie van de P1 meter in HA om de update frequentie te zetten. Ikzelf heb een seriële kabel lopen waarvan de standaard update frequentie op 30 seconden stond in HA. Ingesteld naar 1 seconde en hoppa!

[ppaulv]

PeaceNlove schreef op zaterdag 24 januari 2026 @ 12:57:
Omdat de HW P1 het bij mij ook laat afweten met 0W in HEMS ook maar eens de sprong in het diepe gedaan met de integratie van Gielz.

Helaas heb ik wel een P1 die maar eens per 10 seconden update. Gelukkig hier al snel gevonden dat je dan de update veel hoger dan 4 seconden moet zetten en ik heb daar 20 van gemaakt. Nu lijkt het wel aardig te draaien, ook met een schakelende oven momenteel aan waarbij ik telkens van terugleveren naar gebruik ga op de P1.
Niet ontevreden met de resultaten tot zo ver, nu ook lekker statistieken en grafieken verzamelen in HA

Tip van een eigenaar van een stotterende slimme meter (dus niet de P1 meter) : als dit nog issues geeft, zet 'm op 35 seconden. Mijn slimme meter wil nogal eens een (of twee) data-pulsjes overslaan zodat de periode niet 10 maar 20 of zelfs 30 seconden is tussen twee data bursts. Het geheel wordt hierdoor wel trager van reactie natuurlijk, maar wel stabieler

[PeaceNlove]

koboy schreef op zaterdag 24 januari 2026 @ 14:04:
[...]


Die 10 seconden geldt alleen als je een DSMR4 meter hebt. Met een DSMRt meter spuugt die in elk geval elke seconde de tellerstanden uit,aar is het aan de integratie van de P1 meter in HA om de update frequentie te zetten. Ikzelf heb een seriële kabel lopen waarvan de standaard update frequentie op 30 seconden stond in HA. Ingesteld naar 1 seconde en hoppa!

Ja, ik heb dus DSMR4, ding is al bijna 10 jaar oud inmiddels en mag al weer vervangen worden omdat die op GPRS werkt. Loopt verder wel stabiel, dus volgens mij zit ik voor nu met de 20 seconden wel goed

[ppaulv]

Heeft iemand ervaringen met de vergelijking van de P1 meters van HW en Zendure? Ik heb ze allebei in de meterkast hangen en vraag me af
1) of de een betere resultaten zou moeten geven dan de ander (en waarom) ?
2) of ik data van bede naast elkaar in 1 dashboard kan zetten, bijv. de netto energie onttrekking/levering? Dit is me (nog) niet gelukt maar misschien kán het wel. Gewoon om te zien of ze altijd hetzelfde doorgeven ....

[ Voor 7% gewijzigd door ppaulv op 24-01-2026 16:20 ]

[edjes]

ik heb die van Zendure ook, maar ik krijg m niet zichtbaar in HA, ondanks updates. Tips?

[Taro]

edjes schreef op zaterdag 24 januari 2026 @ 17:02:
ik heb die van Zendure ook, maar ik krijg m niet zichtbaar in HA, ondanks updates. Tips?

Al gezocht? Taro in "Zendure producten in Home Assistant integreren deel 2"

[Taro]

ppaulv schreef op zaterdag 24 januari 2026 @ 16:20:
Heeft iemand ervaringen met de vergelijking van de P1 meters van HW en Zendure? Ik heb ze allebei in de meterkast hangen en vraag me af
1) of de een betere resultaten zou moeten geven dan de ander (en waarom) ?

Exact hetzelfde. Toen de Zendure P1-meter uitkwam had die een update interval, maar destijds verzocht er 1 seconde van te maken en daardoor hebben ze dezelfde update interval.

2) of ik data van bede naast elkaar in 1 dashboard kan zetten, bijv. de netto energie onttrekking/levering? Dit is me (nog) niet gelukt maar misschien kán het wel. Gewoon om te zien of ze altijd hetzelfde doorgeven ....

Uiteraard. Heb hier al vaker een animated gif gepost met daarin een aantal P1 en CT-meters.

Edit, hierbij, met de opmerking dat de Zendure P1-meter tegenwoordig ook 1x per seconde ipv 1x per 3 seconden update:

[ Voor 15% gewijzigd door Taro op 24-01-2026 18:43 ]

[Pakhaas]

sorry verkeerde topic.

[ Voor 189% gewijzigd door Pakhaas op 24-01-2026 18:55 ]

[edjes]

Taro schreef op zaterdag 24 januari 2026 @ 18:33:
[...]

Al gezocht? Taro in "Zendure producten in Home Assistant integreren deel 2"

HELD!

[edjes]

Mbt de Zendure P1 sensor integreren in HA, rest - platform werkt niet meer.
Onderstaande is de correcte code, mbt chatgpt, getest en werkend!

code:

rest:
  - resource: http://192.168.1.X/properties/report
    scan_interval: 1
    sensor:
      - name: "Zendure P1 Vermogen Fase A"
        value_template: "{{ value_json.a_aprt_power }}"
        unique_id: zendure_p1_vermogen_fase_a
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement

      - name: "Zendure P1 Vermogen Fase B"
        value_template: "{{ value_json.b_aprt_power }}"
        unique_id: zendure_p1_vermogen_fase_b
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement

      - name: "Zendure P1 Vermogen Fase C"
        value_template: "{{ value_json.c_aprt_power }}"
        unique_id: zendure_p1_vermogen_fase_c
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement

      - name: "Zendure P1 Vermogen Totaal"
        value_template: "{{ value_json.total_power }}"
        unique_id: zendure_p1_vermogen_totaal
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement

[klump4u]

@gielz
Bij mij begon de NOM gisteravond pas om 22:50 en doet het nu nog steeds. Ik heb een afwijkende P1 sensor aangegven en de HW P1 ingevuld, ik draai de Versie 20260114, dag ervoor begon wel goed met NOM.
Ik draai deze automatisering erbij zodat hij niet zoveel schakelt rond zonopkomst en zon ondergang

YAML:

alias: Zendure automatisch laden op zonlicht
description: >-
  Zet Zendure op 'Alleen slim opladen' overdag en 'Nul op de meter' buiten
  daglicht
triggers:
  - minutes: /5
    trigger: time_pattern
actions:
  - choose:
      - conditions:
          - condition: sun
            after: sunrise
            after_offset: "+00:30:00"
            before: sunset
            before_offset: "-00:30:00"
          - condition: template
            value_template: >-
              {{ states('input_select.zendure_2400_ac_modus_selecteren') !=
              'Alleen slim opladen' }}
        sequence:
          - target:
              entity_id: input_select.zendure_2400_ac_modus_selecteren
            data:
              option: Alleen slim opladen
            action: input_select.select_option
      - conditions:
          - condition: or
            conditions:
              - condition: sun
                after: sunset
                after_offset: "-00:30:00"
              - condition: sun
                before: sunrise
                before_offset: "+00:30:00"
          - condition: template
            value_template: >-
              {{ states('input_select.zendure_2400_ac_modus_selecteren') != 'Nul
              op de meter' }}
        sequence:
          - target:
              entity_id: input_select.zendure_2400_ac_modus_selecteren
            data:
              option: Nul op de meter
            action: input_select.select_option
mode: single

[gielz]

klump4u schreef op zondag 25 januari 2026 @ 08:30:
@gielz
Bij mij begon de NOM gisteravond pas om 22:50 en doet het nu nog steeds. Ik heb een afwijkende P1 sensor aangegven en de HW P1 ingevuld, ik draai de Versie 20260114, dag ervoor begon wel goed met NOM.
Ik draai deze automatisering erbij zodat hij niet zoveel schakelt rond zonopkomst en zon ondergang

YAML:

alias: Zendure automatisch laden op zonlicht
description: >-
  Zet Zendure op 'Alleen slim opladen' overdag en 'Nul op de meter' buiten
  daglicht
triggers:
  - minutes: /5
    trigger: time_pattern
actions:
  - choose:
      - conditions:
          - condition: sun
            after: sunrise
            after_offset: "+00:30:00"
            before: sunset
            before_offset: "-00:30:00"
          - condition: template
            value_template: >-
              {{ states('input_select.zendure_2400_ac_modus_selecteren') !=
              'Alleen slim opladen' }}
        sequence:
          - target:
              entity_id: input_select.zendure_2400_ac_modus_selecteren
            data:
              option: Alleen slim opladen
            action: input_select.select_option
      - conditions:
          - condition: or
            conditions:
              - condition: sun
                after: sunset
                after_offset: "-00:30:00"
              - condition: sun
                before: sunrise
                before_offset: "+00:30:00"
          - condition: template
            value_template: >-
              {{ states('input_select.zendure_2400_ac_modus_selecteren') != 'Nul
              op de meter' }}
        sequence:
          - target:
              entity_id: input_select.zendure_2400_ac_modus_selecteren
            data:
              option: Nul op de meter
            action: input_select.select_option
mode: single

Bij iedere modus keuze stopt de batterij en gaat dan pas met de nieuwe modus aan de slag. Kijk even of dit vandaag weer gebeurd. Zo ja dan moeten wij even in de logs kijken op het moment dat jij de nom sturing verwacht.

Mocht je nu al logs hebben dm ze dan even.

[edjes]

Mogelijk stomme vraag, maar ik kom er ff niet uit.
Ik had een slome slimmemeter p1 die ik gebruikte als afw p1 sensor.
Werkte goed, behoudens soms tot 20 sec geen update.
Nu heb ik dankzij eerder beschreven code de zendure p1 meter geinstalleerd. Werkt keurig en update elke seconde. De waardes zijn in kW, de afronding tot 3 achter de komma en laten exact dezelfde getallen zien als de slimmemeter. De naam is sensor.zend_p1_power_tot . Helaas doet de automatisering er niets mee als ik 'm invul bij afwijkende p1. Ik had de naam ook al wat verkort in de hoop dat het in de lengte van de naam zit. Wat doe ik fout?

[gielz]

edjes schreef op zondag 25 januari 2026 @ 10:04:
Mogelijk stomme vraag, maar ik kom er ff niet uit.
Ik had een slome slimmemeter p1 die ik gebruikte als afw p1 sensor.
Werkte goed, behoudens soms tot 20 sec geen update.
Nu heb ik dankzij eerder beschreven code de zendure p1 meter geinstalleerd. Werkt keurig en update elke seconde. De waardes zijn in kW, de afronding tot 3 achter de komma en laten exact dezelfde getallen zien als de slimmemeter. De naam is sensor.zend_p1_power_tot . Helaas doet de automatisering er niets mee als ik 'm invul bij afwijkende p1. Ik had de naam ook al wat verkort in de hoop dat het in de lengte van de naam zit. Wat doe ik fout?

Zou je even een screenshot kunnen posten hoe hij er exact uit ziet. Elke afwijkende P1 zou moeten werken.

[edjes]

De beide meters geven dezelfde waardes aan, ook in juiste plus/min richting en de definitie is ook hetzelfde.
Ik heb de display precision ook op default gehad, ook geen verschil.
Echt heel raar.

Dit is de configyaml:

code:

Rest:
  - resource: http://192.168.1.19/properties/report
    scan_interval: 1
    sensor:
      - name: "Zendure P1 Power Fase A"
        value_template: "{{ (value_json.a_aprt_power | float / 1000) | round(3) }}"
        unique_id: zendure_p1_power_fase_a
        unit_of_measurement: "kW"
        device_class: power
        state_class: measurement

      - name: "Zendure P1 Power Fase B"
        value_template: "{{ (value_json.b_aprt_power | float / 1000) | round(3) }}"
        unique_id: zendure_p1_power_fase_b
        unit_of_measurement: "kW"
        device_class: power
        state_class: measurement

      - name: "Zendure P1 Power Fase C"
        value_template: "{{ (value_json.c_aprt_power | float / 1000) | round(3) }}"
        unique_id: zendure_p1_power_fase_c
        unit_of_measurement: "kW"
        device_class: power
        state_class: measurement

      - name: "Zendure P1 Power Totaal"
        value_template: "{{ (value_json.total_power | float / 1000) | round(3) }}"
        unique_id: zend_p1_power_tot
        unit_of_measurement: "kW"
        device_class: power
        state_class: measurement

[gielz]

edjes schreef op zondag 25 januari 2026 @ 11:19:
[Afbeelding]

[Afbeelding]

De beide meters geven dezelfde waardes aan, ook in juiste plus/min richting en de definitie is ook hetzelfde.
Ik heb de display precision ook op default gehad, ook geen verschil.
Echt heel raar.

Dit is de configyaml:

code:

Rest:
  - resource: http://192.168.1.19/properties/report
    scan_interval: 1
    sensor:
      - name: "Zendure P1 Power Fase A"
        value_template: "{{ (value_json.a_aprt_power | float / 1000) | round(3) }}"
        unique_id: zendure_p1_power_fase_a
        unit_of_measurement: "kW"
        device_class: power
        state_class: measurement

      - name: "Zendure P1 Power Fase B"
        value_template: "{{ (value_json.b_aprt_power | float / 1000) | round(3) }}"
        unique_id: zendure_p1_power_fase_b
        unit_of_measurement: "kW"
        device_class: power
        state_class: measurement

      - name: "Zendure P1 Power Fase C"
        value_template: "{{ (value_json.c_aprt_power | float / 1000) | round(3) }}"
        unique_id: zendure_p1_power_fase_c
        unit_of_measurement: "kW"
        device_class: power
        state_class: measurement

      - name: "Zendure P1 Power Totaal"
        value_template: "{{ (value_json.total_power | float / 1000) | round(3) }}"
        unique_id: zend_p1_power_tot
        unit_of_measurement: "kW"
        device_class: power
        state_class: measurement

De afwijkende sensor moet in watt zijn. Daarna zal hij werken.

[edjes]

Stom, ik dacht dat ik dezelfde definitie had gebruikt als de vorige p1 meter.
Had ik stiekem stukje verderop nog een berekening op gedaan/1000 voor kW.
Dank!!

Hij werkt! Eindelijk 1 sec updates.

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

[gielz]

🎉Gielz Maart test (definitieve release laatste week Februari)

Test configuratie. Bij issues graag via Github (beste weg) of DM.
https://github.com/Gielz1...elz1986-Maart-2026-Update

Deze release staat helemaal in het teken van nog meer verbeteringen én maximale vrijheid. Wat niet verandert? Jij houdt de controle — alles is volledig naar eigen hand te zetten.

Vanaf nu bepaal jij zelf wanneer de batterij gaat laden of ontladen bij gebruik van NOM. Geen zin om al bij -100 watt teruglevering te beginnen met laden? Geen probleem — zet ’m gewoon op bijvoorbeeld -500 watt. Ook het maximale laad- en ontlaadvermogen is nu volledig instelbaar. Superhandig als je batterij op een gedeelde groep zit, of als je met meerdere omvormers werkt in combinatie met Node-RED. Ook handig als je de omvormer wilt knijpen voor een hogere RTE.

Melding van release krijgen

1) Zet een Star bij de Github pagina https://github.com/Gielz1986/Zendure-HA-zenSDK (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

⚠️Brekende wijziging ⚠️

Modus Opladen met 2400 watt en Ontladen met 2400 watt zijn hernoemd naar Snel opladen en Snel ontladen. Dit omdat het maximale vermogen van de omvormer niet altijd 2400 meer is/was. Hiervoor moeten mogelijk eigen automatiseringen die de modus aanpassen aangepast worden. De oude modus bestaat immers niet meer.

Bugfix

Opladen starten en balanceren
Wanneer het laadpercentage (SOC) onder de ingestelde minimale waarde zakt maar de SOC bescherming is nog niet gestart (2 uur na zonsopkomst). Start het opladen niet correct. Dit komt voornamelijk voor als er een dag niet geladen is en buiten het opwekseizoen. Dit is nu opgelost.

Homewizard P1 of eigen P1 sensor niet beschikbaar
Wanneer deze sensoren geen data hebben omdat ze offline zijn blijft de aansturing hangen op de laatst bekende waarde. Dit zal vanaf nu standaard 0 watt worden.

Nieuwe configuratie mogelijkheden

Maximaal Oplaadvermogen / Ontlaadvermogen
Vanaf nu ben je extra in control en bepaal je zelf hoeveel vermogen de batterij überhaupt heeft. Dit word niet alleen in Home Assistant gebruikt maar ook netjes in de batterij hard ingesteld via de API.

Ontladen Starten Bij
Vanaf nu ben je extra in control en bepaal je zelf na hoeveel watt import de batterij gaat ontladen. Dit is instelbaar van 100 tot en met 500 watt. Daarna balanceert de batterij naar 0 + de extra ingestelde ontlaadmarge

Opladen Starten Bij
Vanaf nu ben je extra in control en bepaal je zelf na hoeveel watt teruglevering de batterij gaat laden. Dit is instelbaar van 100 tot en met 1000 watt. Daarna balanceert de batterij naar 0 - de extra ingestelde oplaadmarge

Batterij Volgorde
De batterij volgorde klopt niet altijd van de omvormer (1) tot de grond (6). Vanaf nu kun je de volgorde zelf instellen – bijvoorbeeld 1;5;3;4;2 – hiermee bepaal je zelf de volgorde van de batterijen. De juiste volgorde bepaal je mede aan de hand van sensor.zendure_2400_ac_batterij_serienummers en de sticker op de batterij(en). Op deze manier zullen de batterijtemperaturen en het laadpercentage de juiste volgorde hebben zoals die van de batterij(en) in de stapel.

Nieuw RESTful Command

zendure_instelling
Dit RESTful Command word gebruikt in de configuratie waarbij er instellingen op de batterij aangepast kunnen worden. Wil je deze zelf gaan gebruiken dan kun je hiervoor de onderstaande code gebruiken;

Maximaal oplaadvermogen aanpassen

code:

action: rest_command.zendure_instelling
data:
  sn: "{{ states('sensor.zendure_2400_ac_serienummer') }}"
  instellingitem: chargeMaxLimit
  instellinginhoud: "{{ states('input_number.zendure_2400_ac_max_oplaadvermogen') | int }}"

Minimale SOC naar 20%

code:

action: rest_command.zendure_instelling
data:
  sn: "{{ states('sensor.zendure_2400_ac_serienummer') }}"
  instellingitem: minSoc
  instellinginhoud: 200

Nieuwe sensoren toegevoegd

SOC-limiet Status
Deze sensor kan het volgende aangeven; Normale werking, Laadlimiet bereikt, en Ontlaadlimiet bereikt. Deze word vanaf nu ook gebruikt in de automatisering om zeker te weten dat de batterij bruikbaar is wat bij 1% boven en onder de min/max ingestelde laadpercentage niet altijd het geval was.

Batterij 1-6 Laadpercentage
Vanaf nu kun je per batterij het laadpercentage uitlezen.

Wijzigingen in bestaande onderdelen

sensor.zendure_2400_ac_indicatie_beschikbare_energie
Is aangepast en word nu anders berekend. Bij de indicatie word nu rekening gehouden met de efficiëntie bij export. Dit is dynamisch en zal eerst naar het 24 uur gemiddelde kijken en als deze onder de 70% is naar je RTE indicatie export. Bij het openklikken van deze sensor kun je bij attributen zien hoe de berekening is gelopen.

input_number.zendure_2400_ac_oplaadmarge
Verhoogt van 50 naar 250 watt. Dit om in de zomermaanden als de batterij snel vol is meer terug te leveren om import 100% te voorkomen gedurende de dag.

input_number.zendure_2400_ac_ontlaadmarge
Verhoogt van 50 naar 250 watt. Dit om in de nacht efficiënter te ontladen op een iets hoger vermogen. Of dit het waard is laat ik aan de gebruiker.

sensor.zendure_2400_ac_relais_schakelingen_totaal_vandaag
Na reactie van Zendure support is toch de sensor weer aangepast. Zodra er vermogen/weerstand op de relais komt moet dit geteld worden. Hier worden nu alleen schakelingen geteld wanneer er vermogen op de relais komt. De slijtage is lager dan gebruikelijk omdat het vermogen opbouwend is bij Zendure. 50-100 keer per dag is gebruikelijk bij een relais met direct 100% vermogen.

Standby>Opladen = 1
Standby>Ontladen = 1
Opladen>Ontladen = 1
Ontladen>Opladen = 1
Opladen>Standby = 0
Ontladen>Standby = 0

sensor.p1_aansturing_vermogen
Word vanaf nu ook in de Long-Term Statistics (LTS) opgeslagen.

[gast777]

Voor wie de Proxy in Node-Red gebruikt om twee Zendure devices aan te sturen met Gielz HA: gebruik minimaal de Proxy versie 20260125 (huidige versie) met de Gielz Maart versie. Dan werkt alles, inclusief het max vermogen instellen vanuit de Gielz HA.

[ Voor 4% gewijzigd door gast777 op 26-01-2026 18:26 ]

[jakamp]

Afgelopen weekeinde de Gielz oplossing in HA gezet. Mooie oplossing, maar ik krijg helaas de dynamische component niet aan de praat.
Ik heb de HACS versie van Nordpool geïnstalleerd conform de beschrijving. De BTW, opslag en energiebelasing componenten toegevoegd aan de nordpool_kwh_nl_eur_3_10_0 sensor en het entiteits-ID gerenamed naar sensor.nordpool.
Ik zie alle waarden binnenkomen op de nordpool sensor, maar zie in de APEX-charts, de spread indicaties, goedkope uren geen waarden terugkomen.
Als ik in de code zoek dan wordt de sensor sensor.dynamisch_nordpool gebruikt. Helaas wordt deze niet gevuld.



Iemand een idee waarom deze sensor/template niet gevuld wordt?

[gielz]

jakamp schreef op dinsdag 27 januari 2026 @ 21:26:
Afgelopen weekeinde de Gielz oplossing in HA gezet. Mooie oplossing, maar ik krijg helaas de dynamische component niet aan de praat.
Ik heb de HACS versie van Nordpool geïnstalleerd conform de beschrijving. De BTW, opslag en energiebelasing componenten toegevoegd aan de nordpool_kwh_nl_eur_3_10_0 sensor en het entiteits-ID gerenamed naar sensor.nordpool.
Ik zie alle waarden binnenkomen op de nordpool sensor, maar zie in de APEX-charts, de spread indicaties, goedkope uren geen waarden terugkomen.
Als ik in de code zoek dan wordt de sensor sensor.dynamisch_nordpool gebruikt. Helaas wordt deze niet gevuld.

[Afbeelding]

Iemand een idee waarom deze sensor/template niet gevuld wordt?

Je hoeft je nordpool sensor niet te renamen. Heb je het onderstaande ingevuld zodat de Gielz hem kan gaan gebruiken zoals beschreven staat?

input_text.dynamisch_nordpool_sensor
Optioneel je eigen sensor van Nordpool (HACS) toevoegen. bijv. sensor.nordpool_kwh_nl_eur_3_09_0

[jakamp]

gielz schreef op dinsdag 27 januari 2026 @ 21:38:
[...]


Je hoeft je nordpool sensor niet te renamen. Heb je het onderstaande ingevuld zodat de Gielz hem kan gaan gebruiken zoals beschreven staat?

input_text.dynamisch_nordpool_sensor
Optioneel je eigen sensor van Nordpool (HACS) toevoegen. bijv. sensor.nordpool_kwh_nl_eur_3_09_0

[Afbeelding]

Het entiteits-ID terug gewijzigd naar sensor.nordpool_kwh_nl_eur_3_10_0
Voor het overige staat m.i. alles goed ingesteld.



Helaas werkt het nog niet. Heb je nog andere suggesties ?

[gielz]

jakamp schreef op dinsdag 27 januari 2026 @ 22:17:
[...]


Het entiteits-ID terug gewijzigd naar sensor.nordpool_kwh_nl_eur_3_10_0
Voor het overige staat m.i. alles goed ingesteld.

[Afbeelding]

Helaas werkt het nog niet. Heb je nog andere suggesties ?

Sensor. ontbreekt, zie mijn screenshot

[jakamp]

gielz schreef op dinsdag 27 januari 2026 @ 22:20:
[...]


Sensor. ontbreekt, zie mijn screenshot

Dat was het
Hoe simpel kan het zijn Top, dankjewel !

[Freemann]

Ben gisteravond overgegaan naar de Maart beta en daarbij zowel het dashboard als de Automation "geïnstalleerd".
Nu heb ik het volgende issue;
De handmatige "morgen" invoer laat vreemd gedrag zien.
Zodra ik laden op 10 en ontladen op 34 heb staan, de string uit de spread haal en deze in de handmatige invoer zet, om hier vervolgens 1 G optie uit te halen, dan update de grafiek niet.
Er lijkt een omslagpunt te zitten in de lengte van de string in het input field. Ergens rond de 240 chars lijkt het nog te werken, zodra de string langer is of er meer D/G's in staan stopt hij met updaten. Iemand dit ook opgemerkt?

[gielz]

Freemann schreef op woensdag 28 januari 2026 @ 17:18:
Ben gisteravond overgegaan naar de Maart beta en daarbij zowel het dashboard als de Automation "geïnstalleerd".
Nu heb ik het volgende issue;
De handmatige "morgen" invoer laat vreemd gedrag zien.
Zodra ik laden op 10 en ontladen op 34 heb staan, de string uit de spread haal en deze in de handmatige invoer zet, om hier vervolgens 1 G optie uit te halen, dan update de grafiek niet.
Er lijkt een omslagpunt te zitten in de lengte van de string in het input field. Ergens rond de 240 chars lijkt het nog te werken, zodra de string langer is of er meer D/G's in staan stopt hij met updaten. Iemand dit ook opgemerkt?

Klopt, maar dit ligt niet aan en de Maart test release. De functie komt uit https://github.com/Gielz1986/Dynamisch-HA en werkt al sinds eind Oktober op deze manier.

Je loopt er tegen aan dat dit veld maar 240 karakters lang mag zijn. Wat problemen geeft bij 15 minuten periodes. Het idee is om dit in de toekomst te veranderen zodat je bijvoorbeeld G08:00-10:00 kunt invoeren waardoor het probleem niet meer kan ontstaan of een andere oplossing.

Voor nu is de max dus ongeveer 8 uur handmatig bij 15minuten tarieven. En bij uur tarieven kan wel alles.

[Freemann]

Ah ok, dan zal het er ook mee samen hangen dat ik sinds enkele dagen NOM duur draai met veel ontlaad kwartieren. Wilde daarbij het laden wat meer sturen, waar er soms uitschiets bij zitten voor bijv. 23:30 en 23:45 die ik er dan uit wil halen.

Ga kijken hoe ik er omheen kan werken.

[jakamp]

Sinds maandag draait mijn solarflow 2400 AC met de Gielz oplossing. Gisteren met hulp van Gielz het dynamische deel aan de gang gekregen. Afgelopen nacht was de spread hoog genoeg om te gaan laden. Dat werkt prima, maar het systeem begon met 2400W te laden.
In de Zendure app kun je het ontlaad- en oplaadvermogen instellen op b.v. resp. op b.v. 800 Watt en max. 2400 Watt als je onder HEMS draait. De instelling stond hier ingesteld op 800 Watt ontladen en 1200 Watt laden.
Met de HA Gielz oplossing moet HEMS uitgezet worden. De ontlaad instelling van 800 Watt wordt dan keurig gerespecteerd, maar het oplaadvermogen gaat naar 2400 Watt. Dit is in de Zendure app met HEMS uitgeschakeld ook niet te wijzigen.
In oudere forum entries las ik dat anderen ook tegen dit probleem aanliepen, maar ik heb nergens een oplossing kunnen vinden Iemand een aanwijzing/tip om dit aan te passen?

[gielz]

jakamp schreef op woensdag 28 januari 2026 @ 21:51:
Sinds maandag draait mijn solarflow 2400 AC met de Gielz oplossing. Gisteren met hulp van Gielz het dynamische deel aan de gang gekregen. Afgelopen nacht was de spread hoog genoeg om te gaan laden. Dat werkt prima, maar het systeem begon met 2400W te laden.
In de Zendure app kun je het ontlaad- en oplaadvermogen instellen op b.v. resp. op b.v. 800 Watt en max. 2400 Watt als je onder HEMS draait. De instelling stond hier ingesteld op 800 Watt ontladen en 1200 Watt laden.
Met de HA Gielz oplossing moet HEMS uitgezet worden. De ontlaad instelling van 800 Watt wordt dan keurig gerespecteerd, maar het oplaadvermogen gaat naar 2400 Watt. Dit is in de Zendure app met HEMS uitgeschakeld ook niet te wijzigen.
In oudere forum entries las ik dat anderen ook tegen dit probleem aanliepen, maar ik heb nergens een oplossing kunnen vinden Iemand een aanwijzing/tip om dit aan te passen?

Welke versie van Gielz maak je nu gebruik van?

[jakamp]

gielz schreef op woensdag 28 januari 2026 @ 21:56:
[...]


Welke versie van Gielz maak je nu gebruik van?

In de automation staat Versie 20260114

[gielz]

jakamp schreef op woensdag 28 januari 2026 @ 22:06:
[...]

In de automation staat Versie 20260114

Je kunt 2 dingen doen;

1) Je kunt naar de testversie gaan gielz in "Zendure producten in Home Assistant integreren deel 2" Krijg je veel extra's, je helpt de community en het is instelbaar in HA.
2) Je kunt een post command sturen; gielz in "Zendure producten in Home Assistant integreren deel 2"

[jakamp]

gielz schreef op woensdag 28 januari 2026 @ 22:25:
[...]


Je kunt 2 dingen doen;

1) Je kunt naar de testversie gaan gielz in "Zendure producten in Home Assistant integreren deel 2" Krijg je veel extra's, je helpt de community en het is instelbaar in HA.
2) Je kunt een post command sturen; gielz in "Zendure producten in Home Assistant integreren deel 2"

Top!. Ik zal morgen de testversie installeren.
Mijn kennis van HA zit nog op redelijk beginners niveau, maar testen is natuurlijk altijd te doen. Dank je voor je snelle reactie! De koffie is onderweg

[gielz]

Freemann schreef op woensdag 28 januari 2026 @ 20:18:
Ah ok, dan zal het er ook mee samen hangen dat ik sinds enkele dagen NOM duur draai met veel ontlaad kwartieren. Wilde daarbij het laden wat meer sturen, waar er soms uitschiets bij zitten voor bijv. 23:30 en 23:45 die ik er dan uit wil halen.

Ga kijken hoe ik er omheen kan werken.

Je kunt ook even wachten. Ik ben bezig met een nieuwe versie waarbij de instelling mogelijk is. Dan kun je gewoon zeggen G00:00-G02:45 en dan gaat hij laden van 00:00 t/m 03:00.

Deze zal eerst op https://github.com/Gielz1986/Dynamisch-HA getest worden en daarna naar de Gielz met de April release mee kunnen.

[Freemann]

gielz schreef op woensdag 28 januari 2026 @ 23:01:
[...]


Je kunt ook even wachten. Ik ben bezig met een nieuwe versie waarbij de instelling mogelijk is. Dan kun je gewoon zeggen G00:00-G02:45 en dan gaat hij laden van 00:00 t/m 03:00.

Deze zal eerst op https://github.com/Gielz1986/Dynamisch-HA getest worden en daarna naar de Gielz met de April release mee kunnen.

[Afbeelding]

Ziet er goed uit! Zal kijken of ik hem de komende tijd kan testen.

[remcoXP]

@gielz hoe zou ik dit het beste kunnen aanpakken?
ik heb gielz framework om mijn batterij aan te sturen
en evcc voor mijn auto.
nu wil ik eigenlijk dat als de auto laad mijn batterij niet mee doet.

een soort exclude als evcc of auto op charging staat (heb alle entities in home assistant beschikbaar) dan batterij tijdelijk negeren. wiet niet goed hoe ik dit het beste kan aanvliegen en zeker niet met het oog om altijd jou releases tu kunnen copy pasten.

[gielz]

remcoXP schreef op donderdag 29 januari 2026 @ 17:33:
@gielz hoe zou ik dit het beste kunnen aanpakken?
ik heb gielz framework om mijn batterij aan te sturen
en evcc voor mijn auto.
nu wil ik eigenlijk dat als de auto laad mijn batterij niet mee doet.

een soort exclude als evcc of auto op charging staat (heb alle entities in home assistant beschikbaar) dan batterij tijdelijk negeren. wiet niet goed hoe ik dit het beste kan aanvliegen en zeker niet met het oog om altijd jou releases tu kunnen copy pasten.

Wat de meeste doen is een extra automatisering draaien buiten de Gielz om die gewoon de juiste modus zet op het moment van EV opladen. Dan gaat hij bijvoorbeeld naar "Alleen Slim Opladen". is de EV vol dan weer naar de andere gewenste modus.

[gielz]

remcoXP schreef op donderdag 29 januari 2026 @ 17:33:
@gielz hoe zou ik dit het beste kunnen aanpakken?
ik heb gielz framework om mijn batterij aan te sturen
en evcc voor mijn auto.
nu wil ik eigenlijk dat als de auto laad mijn batterij niet mee doet.

een soort exclude als evcc of auto op charging staat (heb alle entities in home assistant beschikbaar) dan batterij tijdelijk negeren. wiet niet goed hoe ik dit het beste kan aanvliegen en zeker niet met het oog om altijd jou releases tu kunnen copy pasten.

Is het trouwens zo dat je het vermogen per seconden kunt uitlezen tijdens het laden? Ik heb hier namelijk nog op een wensenlijst staan dat je vermogens sensoren kunt uitschakelen van de batterij.

Hoe dat in de praktijk werkt is dat je dan opgeeft; Sensor.heetwaterkraan.vermogen en dat deze dan helemaal niet meer gezien word door de batterij.

[remcoXP]

De aansturen in de paal in evcc gaat met 6 seconde dacht ik.
daaronder krijgen mensen vaak fouten

[koboy]

gielz schreef op vrijdag 30 januari 2026 @ 09:52:
[...]


Is het trouwens zo dat je het vermogen per seconden kunt uitlezen tijdens het laden? Ik heb hier namelijk nog op een wensenlijst staan dat je vermogens sensoren kunt uitschakelen van de batterij.

Hoe dat in de praktijk werkt is dat je dan opgeeft; Sensor.heetwaterkraan.vermogen en dat deze dan helemaal niet meer gezien word door de batterij.

Staat op je wensenlijst ook iets van: als net-afname > x kW, dan niet ontladen? Mijn laadpunt is te dom, maar ik kom qua verbruik alleen boven de 6kW als de auto aan het laden is.....

[Freemann]

koboy schreef op vrijdag 30 januari 2026 @ 10:55:
[...]


Staat op je wensenlijst ook iets van: als net-afname > x kW, dan niet ontladen? Mijn laadpunt is te dom, maar ik kom qua verbruik alleen boven de 6kW als de auto aan het laden is.....

Zelf zit ik ook met een soortgelijk probleem.
De 2 zendure's kunnen met in totaal 4800W laden en wij hebben een 1x35A aansluiting = ~8000W
Als dan ook de vaatwasser, warmtepomp, Quooker, wasmachine aanstaan, dan krijg ik icm met de Zendure's, een melding van de Tibber app dat de Hoofdzekering overbelast is(geweest).
Heb nu een template helper gemaakt met alle vermogens van de hoog vermogende apparaten erin. Het resultaat daarvan trek ik af van 6000W(=26,x*230) en houd ik een marge over.
Max. beschikbaar vermogen = 6000
====================
Warmtepomp = 1100W
Wasmachine = 2200W
===================+
6000W - 3300W = 2700W beschikbaar voor de zendure's
Dit schrijf ik dan weg in "input_number.zendure_2400_ac_max_oplaadvermogen"
Resultaat is dan;


Mogelijk kan iets als dit ingebouwd worden. Bijvoorbeeld een text veld waar je de power sensor in kunt zetten welke opgeteld worden. Dan max. beschikbare A's opgeven en daaruit de boel laten berekenen.

[ Voor 5% gewijzigd door Freemann op 30-01-2026 11:35 ]

[koboy]

Freemann schreef op vrijdag 30 januari 2026 @ 11:33:
[...]

Zelf zit ik ook met een soortgelijk probleem.
De 2 zendure's kunnen met in totaal 4800W laden en wij hebben een 1x35A aansluiting = ~8000W
Als dan ook de vaatwasser, warmtepomp, Quooker, wasmachine aanstaan, dan krijg ik icm met de Zendure's, een melding van de Tibber app dat de Hoofdzekering overbelast is(geweest).
Heb nu een template helper gemaakt met alle vermogens van de hoog vermogende apparaten erin. Het resultaat daarvan trek ik af van 6000W(=26,x*230) en houd ik een marge over.
Max. beschikbaar vermogen = 6000
====================
Warmtepomp = 1100W
Wasmachine = 2200W
===================+
6000W - 3300W = 2700W beschikbaar voor de zendure's
Dit schrijf ik dan weg in "input_number.zendure_2400_ac_max_oplaadvermogen"
Resultaat is dan;
[Afbeelding]

Mogelijk kan iets als dit ingebouwd worden. Bijvoorbeeld een text veld waar je de power sensor in kunt zetten welke opgeteld worden. Dan max. beschikbare A's opgeven en daaruit de boel laten berekenen.

Het ging mij om het niet pompen van energie van de ene naar de andere accu....
Voor jouw situatie zou ik eerder kijken naar een uitbreiding/vervanging van de meterkast naar 3 fasen. Hebben is hebben, en met alle push naar all electric (vervoer) komt er alleen maar meer druk op de beschikbaarheid van 3 fase aansluitingen.

[ppaulv]

koboy schreef op vrijdag 30 januari 2026 @ 12:23:
[...]


Het ging mij om het niet pompen van energie van de ene naar de andere accu....
Voor jouw situatie zou ik eerder kijken naar een uitbreiding/vervanging van de meterkast naar 3 fasen. Hebben is hebben, en met alle push naar all electric (vervoer) komt er alleen maar meer druk op de beschikbaarheid van 3 fase aansluitingen.

Helemaal mee eens, 1 fase is echt te beperkt met al dit soort grootverbruikers.
En vergeet niet dat je rekent met 230V, wat inmiddels ook achterhaald is. In mijn huis fluctueert de spanning doorgaans tussen de 235 en 242 volt. En als de spanning omhoog gaat voor een verwarmingselement in de wasmachine (als voorbeeld) gaat de stroomsterkte net zoveel omhoog (procentueel). En dus het vermogen met ruim 2x die hoeveelheid. Als je op het scherpst van de snede balanceert gaat die zekering vast een keer om

[Freemann]

koboy schreef op vrijdag 30 januari 2026 @ 10:55:
[...]


Staat op je wensenlijst ook iets van: als net-afname > x kW, dan niet ontladen? Mijn laadpunt is te dom, maar ik kom qua verbruik alleen boven de 6kW als de auto aan het laden is.....

Las/lees dat dat je het laden van het domme laadpunt niet kunt sturen, dus dan moet je andere zaken sturen. Ik poog niets tussen accu's heen en weer te pompen.
Dat issue heb ik ook deels en los ik met bovenstaande op. Maar misschien begrijp ik het verkeerd...

Of ik wel/niet overstap naar 3fase is mijn eigen keuze. Wij draaien zo al 10 jaar zonder enige probleem. Enige spannende is, is dat er een oude smelzekering van Stedin in zit. Die wordt binnenkort vervangen voor een 35A automaat.
Maar dit doet allemaal niet ter zake hier.

[Pakhaas]

Kan je niet naar een 40A. Heb je net nog wat marge, alhoewel het niet veel is.

[ppaulv]

Pakhaas schreef op vrijdag 30 januari 2026 @ 13:37:
Kan je niet naar een 40A. Heb je net nog wat marge, alhoewel het niet veel is.

Ik begrijp dat Freemann geen probleem heeft ...

[Freemann]

jeetje ben een tijd niet op GoT geweest... maar dit gaat weer nergens over...
Kan mij niet herinneren dat ik in dit topic om advies heb gevraagd voor een 1/3 fase switch....

Dit is allemaal off-topic en ik ga weer in de lurk modus.

[koboy]

Freemann schreef op vrijdag 30 januari 2026 @ 13:18:
[...]

Las/lees dat dat je het laden van het domme laadpunt niet kunt sturen, dus dan moet je andere zaken sturen. Ik poog niets tussen accu's heen en weer te pompen.
Dat issue heb ik ook deels en los ik met bovenstaande op. Maar misschien begrijp ik het verkeerd...

Of ik wel/niet overstap naar 3fase is mijn eigen keuze. Wij draaien zo al 10 jaar zonder enige probleem. Enige spannende is, is dat er een oude smelzekering van Stedin in zit. Die wordt binnenkort vervangen voor een 35A automaat.
Maar dit doet allemaal niet ter zake hier.

Rustig aan.... En welkom terug.
Ik zie nu ook dat de zaak compleet uit de hand loopt, maar daar heb ik geen invloed op.

Mijn bedoeling was om je even te laten nadenken over een 3 fase overgang meer niet. Het zou het probleem waar je de afgelopen 10 jaar naar toe bent gegroeid structureel oplossen ipv dat je er met automatiseringen omheen werkt. Punt wat ik je vooral wilde meegeven was dat er netbeheerders/gebieden zijn waar je nu al op een wachtlijst komt voor een 3 fase aansluiting en dat dat er alleen maar meer zullen worden. Zit je straks met je mooie glanzende EV via de granny dagenlang te laden omdat je geen 3 fase kunt krijgen.

Die meldingen van Tibber vind ik trouwens irritant als je die niet uit kan zetten en ze direct bij overschrijding gestuurd worden (zelf Zonneplan). Maar ik ga er van uit dat je de uitschakel karakteristiek grafiek van een C klasse automaat al eens hebt gezien

[klump4u]

remcoXP schreef op donderdag 29 januari 2026 @ 17:33:
@gielz hoe zou ik dit het beste kunnen aanpakken?
ik heb gielz framework om mijn batterij aan te sturen
en evcc voor mijn auto.
nu wil ik eigenlijk dat als de auto laad mijn batterij niet mee doet.

een soort exclude als evcc of auto op charging staat (heb alle entities in home assistant beschikbaar) dan batterij tijdelijk negeren. wiet niet goed hoe ik dit het beste kan aanvliegen en zeker niet met het oog om altijd jou releases tu kunnen copy pasten.

Ik heb 3 losse automatiseringen lopen daar voor, bij overdag laden mag de Zendure alleen slim opladen bij voldoende overschot, bij avond/nacht laden mag de Zendure gewoon NOM draaien en de auto meevullen en als de lader naar 0 gaat dan gewoon NOM.