Zendure producten in Home Assistant integreren deel 2

[TWKterry]

Ik dacht dat ik er iets over gelezen had en heb het geprobeerd met de zoekfunctie maar kon niets vinden.

Ik heb een HomeWizard PiB en die wil ik samen laten werken met de 2x SF800pro die binnen is maar nog geinstalleerd moet worden. De HW-PiB zit op een groep en laad vanuit een set zonnepanelen op het dak. Er is een HW-P1 meter en een SlimmeLezer beide in HA beschikbaar.

DE 2x SF800pro gaat rechtstreeks op zonnenpanelen van de schuur (in aanbouw) met een eigen groep.

Ik dacht voorlopig de PiB NOM laten regelen (niet via HA) en de SF800pro de tekorten/overschotten met een marge.
Iemand hier al eens mee gewerkt /aanbevelingen ?

[slvans]

Even de check of ik het goed doe om te updaten.
Als ik in de HA UI bij automatiseringen de inhoud van de YAML opnieuw plak en datzelfde bij het dashboard doe. Is de update dan goed uitgevoerd of zie ik nog wat over het hoofd?

[Maarten60]

slvans schreef op vrijdag 8 mei 2026 @ 09:45:
Even de check of ik het goed doe om te updaten.
Als ik in de HA UI bij automatiseringen de inhoud van de YAML opnieuw plak en datzelfde bij het dashboard doe. Is de update dan goed uitgevoerd of zie ik nog wat over het hoofd?

Naast automatisering en dashboard moet je ook de sdk updaten. (Handig om dat als package te doen)

Ten overvloede: let op dat je voor alle versies de zelfde taal gebruikt.

[Henkoes]

Maarten60 schreef op vrijdag 8 mei 2026 @ 10:04:
[...]

Naast automatisering en dashboard moet je ook de sdk updaten. (Handig om dat als package te doen)

Ten overvloede: let op dat je voor alle versies de zelfde taal gebruikt.

Is de SDK de Gielz package?

[koboy]

dit is het zendure HA topic.

[ Voor 97% gewijzigd door teacher op 09-05-2026 08:33 ]

[ctrl-tab]

Henkoes schreef op vrijdag 8 mei 2026 @ 10:16:
[...]

Is de SDK de Gielz package?

Ik neem aan dat dat bedoeld wordt. Heeft niet veel met de SDK te maken, dat terzijde.

[Mimiix]

gielz schreef op donderdag 7 mei 2026 @ 14:32:
[...]

Zie je dan in de grafiek ook dat een deel gewoon naar het huis vloeit? Of heb je aangezet dat PV nooit verder dan de batterij mag? Maar iig heeft een integratie geen invloed op de verdeling zelf en zal je dit ook zien via een HEMS aansturing.

Ben wel benieuwd hoe dat er dan uitziet. In de integratie heb je ook de sensoren;

• Engelse integratie[Afbeelding]

Ik heb bovenstaande tabel zelf even nagemaakt en getest.


Onderstaande screenshot stond hij op NOM, waarbij er 1800 werd geimporteerd (van de solar edge) en de PV 470 deed:



Vervolgens daarna het vermogen aangepast naar 1000 ipv NOM. Toen ging de PV omhoog met ruim 60 watt in dit geval. De Solar edge (links) is ongeveer gelijk.





Ik heb het voor nu even opgelost door max opladen uit net in te stellen op 1000. Dan lijkt het goed te gaan.

[ Voor 3% gewijzigd door Mimiix op 08-05-2026 11:57 ]

[ctrl-tab]

dit is het zendure HA topic.

[ Voor 97% gewijzigd door teacher op 09-05-2026 08:34 ]

[RemmyB83]

Vandaag getroffen door de datacenterbrand, en thuis geen vaste internetverbinding meer. Super blij dat lokaal de batterijen d.m.v. de Gielz intergatie doorwerken.

[Maarten60]

ctrl-tab schreef op vrijdag 8 mei 2026 @ 11:44:
[...]

Ik neem aan dat dat bedoeld wordt. Heeft niet veel met de SDK te maken, dat terzijde.

@slvans @Henkoes

Tenzij ik het verkeerd begrepen heb maar de vraag van @slvans was volgens mij, hoe doe ik een upgrade van de @gielz integratie.

Op github heet de integratie zenSDK Github zenSDK en die bestaat uit drie elementen die je integraal moet updaten
- de definitie file (die ik SDK noem)
- de automatisering
- het dashboard
De definitie file kan je als package in de package directory zetten (aanrader) of in je configuration.yaml opnemen.
Automatisering kopieer je naar automations.yaml (of je maakt er zelf een package van)
Dashboard kopieren naar een dashboard
Voor verder details zie github

[wautah91]

zenSDK Hyper2000 proxy update v20260508

De Hyper2000 proxy heb ik compatibel gemaakt de laatste versie van de gielz package. Houd de controle over jouw Hyper2000 op de gielz manier.

Volledig compatibel en geen aanpassingen nodig aan de gielz package, dashboard en automatisering.



twoenter/Zendure-zenSDK-Hyper-proxy

[koboy]

dit is het zendure HA topic.

[ Voor 96% gewijzigd door teacher op 09-05-2026 08:34 ]

[gast777]

gielz schreef op vrijdag 8 mei 2026 @ 07:48:
[...]


@gast777 had jij deze al in het sensor pakket?

De proxy sensoren hebben al support tot 18 battery packs en de HA sensoren laten temperatuur en batterij % zien. Celbalans is nog niet in de standaard sensoren opgenomen.

Ik kan het zeker toevoegen. Ik had daar nog even mee gewacht omdat er eerst nog wat discussie was over de berekening van de waarden. Tevens vind ik dit niet iets urgents eigenlijk. Zendure toont het ook niet en het kan soms meer vragen oproepen dan beantwoorden. En daarbij is dit voor 18 battery packs een hele lap tekst. Maar ik zal het toevoegen binnenkort.

[Mistraller]

Nav het gekke gedrag bij mij thuis met de Gielz integratie; het lijkt inderdaad niet aan de integratie zelf te liggen.

Ik heb een TPLink Deco Mesh netwerk; hierop zit ook een IoT netwerk (met alleen 2.4Ghz) en daar had ik de zendures aan hangen.

En het werkte pas goed toen ik er een repeater (ook tplink) tussen had gezet.

Wat valt op?

De response op /properties/report geven bij een directe connectie op de Deco (zowel het IoT als het hoofd netwerk trouwens) erg vaak een connection reset. En dan werkt natuurlijk ook de proxy niet. (Daar zag ik ook vaak connection reset/ Connection reset by peer optreden) Bij de repeater (die overigens gewoon wireless is) zie ik dit niet gebeuren.

Het gekke is, dat, ondanks dat de REST API vaak onbereikbaar is, dat de Zendure app zelf prima blijft werken. Ik kan bijvoorbeeld gewoon de led aan/uit zetten of de offgrid poort bedienen.

Het is dus niet zomaar een slechte verbinding, maar ik denk ook de http implementatie op de zendure die ermee te maken heeft. De socket blijft open door 1 mislukte request maar het herstelt zich ook niet meer. En mogelijk lopen daarmee ook het aantal openstaande requests binnen de ZenSDK ofwel de NodeRED proxy op. En dat veroorzaakt een memory leak; en daardoor crashte mijn HA.

Wat mijn Deco in het verhaal doet snap ik nog niet helemaal want de verbinding is wel goed zegt ie. Ik zal eens een mesh node heel dicht in de buurt zetten. Want die repeater is wat mij betreft maar een noodoplossing.

Mocht het voor @gast777 of @gielz interessant zijn als ik wat meer testjes doe, laat maar weten. Wellicht kunnen we de integraties nog iets robuuster krijgen

[NiCNCo]

jordyc schreef op vrijdag 8 mei 2026 @ 06:55:
[...]

Ik snap niet waarom je de 70% capaciteit uit jou bericht niet meeneemt, want je bent er wel bekend mee. Je gaat in jou berekening er met afschrijving nu vanuit dat na die 6000 cycli de batterij helemaal niks meer waard is, wat niet het geval is. Na die 6000 cycli heb je nog steeds ten minste 80% van de originele capaciteit beschikbaar. Stel je wilt dit weer corrigeren dan moet je bij 5 batterijen na 6000 cycli 1 nieuwe batterij kopen a 600 euro. Niet een compleet nieuw systeem wat je nu met je afschrijving simuleert. Een andere optie is om de restwaarde na 6000 cycli te bepalen en die van je investering af te halen. Daarnaast heb je ook te maken van timebound degration. De batterij verliest van nature over tijd ook capaciteit, ongeacht of je de batterij wel of niet gebruikt. Hier zou je dus eigenlijk een correctie op de afschrijving per kWh voor moeten doen. Dat brengt de afschrijving per kWh nog verder naar beneden.

Het hele financiele afschrijving verhaal zoals een bedrijf dat doet is gebaseerd op het idee dat na X periode de batterij in zn totaliteit vervangen moet worden en niks meer waard is. Dat is in dit geval dus absoluut niet waar en al zeker niet als je geen rekening houdt met restwaarde. En naar mijn mening mag je deze methode dus ook niet toepassen op je batterij berekening, omdat je geen rekening houdt met variabelen die een grote impact op de uitkomst hebben.

Ik beschouw de batterijen na 6000 cycle als end-of -life omdat leeftijd ook een grote rol speelt. Ik laad/ontlaad maximaal 1x per dag. Dan houden ze het 16.4 jaar uit. In de wintermaanden gaan ze niet heel veel doen, dus reken eerder met 20 jaar. Tegen die tijd heb ik ze al weggedaan of ga ik ervan uit dat ze gesneuveld zijn.

Ik heb een heel script draaiende die de ROI bijhoud. Deze temp_sensorsoren rekenen met bewogen power (in of uit) dus vandaar dat ik met 2.8 cent reken per 1 kwh in mijn geval. Charge wordt apart gerekend op de dynamische inkoop prijs (behalve wanneer PV wordt gebruikt. , degratie wordt meegenomen per 1 kwh. en de discharge Profit per kwh. En dit alles samen per dag, maand, jaar indicatie en levensduur. Waarom omdat het kan en ik het leuk vind om met de data te spelen.

[Mimiix]

In navolging van mijn eerdere post Mimiix in "Zendure producten in Home Assistant integreren deel 2"

Zie ik nog iets geks gebeuren met de PV: hij laad tot 100%. Ik heb geen idee hoe en waarom, maar hij gaat boven de 90%. Kalibreren staat al een tijd op Nee.

[Henkoes]

Net gielz en gast777 geüpdatet. Helaas geen cell spanning per batterij nog. Is dit al wel een feature of doe ik iets verkeerd?

[Pakhaas]

Henkoes schreef op vrijdag 8 mei 2026 @ 15:22:
Net gielz en gast777 geüpdatet. Helaas geen cell spanning per batterij nog. Is dit al wel een feature of doe ik iets verkeerd?

Heb je de package, automotion en dashboard? Ik moest volgens mij HA even herstarten voordat ik de nieuwe entiteiten kreeg te zien.

[atimmerman]

Dag,

Hier een tevreden gebruiker van de integratie.Toch afgelopen nacht een probleem met de communicatie naar m'n Solarflow2400+

Afgelopen nacht modus NulOpdeMeter. Om 7.30 neemt verbruik in huis toe en er wordt 1600 Watt gevraagd aan de batterij. Die blijft in StandBy staan en reageert niet meer. De integratie stuurt gewoon z'n setpoint. Ik moest Hems activeren in de app om erachter te komen dat er een foutmelding "DSP-communicatiestoornis foutcode 6" actief was.

Systeem gereset waarna alles gewoon verder loopt. Nu zie ik dat er bij het opvragen van report ook een veld "is_error" terugkomt. Wordt die gebruikt ? Levert die dergelijke foutinfo? Nu leek er vanaf de HASS kant niets aan de hand.

[Henkoes]

Pakhaas schreef op vrijdag 8 mei 2026 @ 15:24:
[...]

Heb je de package, automotion en dashboard? Ik moest volgens mij HA even herstarten voordat ik de nieuwe entiteiten kreeg te zien.

Ik zal de boel wel even helemaal opnieuw doen

[Henkoes]

Pakhaas schreef op vrijdag 8 mei 2026 @ 15:24:
[...]

Heb je de package, automotion en dashboard? Ik moest volgens mij HA even herstarten voordat ik de nieuwe entiteiten kreeg te zien.

[Pakhaas]

Sinds gisteren draait mijn Gielz met @gast777 proxy niet goed. In het logboek zie ik dat hij na 15min inactiviteit naar flash gaat en 5sec later direct weer naar RAM. Gevolg is dat de batterijen steeds niet naar 0w gaan. Anderen die dit ook hebben (gehad?)

Ook wordt bij het laden en ontladen steeds het vermogen gecorrigeerd, terwijl ik niets doe. Logboek staat er vol mee.

Heb de laatste versie van de proxy en van @gielz





De batterijen laden wel gewoon bij goedkoop en ontladen bij duur.

[ Voor 3% gewijzigd door Pakhaas op 08-05-2026 16:08 ]

[metalmarco]

Mistraller schreef op vrijdag 8 mei 2026 @ 14:22:
Nav het gekke gedrag bij mij thuis met de Gielz integratie; het lijkt inderdaad niet aan de integratie zelf te liggen.

Ik heb een TPLink Deco Mesh netwerk; hierop zit ook een IoT netwerk (met alleen 2.4Ghz) en daar had ik de zendures aan hangen.

En het werkte pas goed toen ik er een repeater (ook tplink) tussen had gezet.

Wat valt op?

De response op /properties/report geven bij een directe connectie op de Deco (zowel het IoT als het hoofd netwerk trouwens) erg vaak een connection reset. En dan werkt natuurlijk ook de proxy niet. (Daar zag ik ook vaak connection reset/ Connection reset by peer optreden) Bij de repeater (die overigens gewoon wireless is) zie ik dit niet gebeuren.

Het gekke is, dat, ondanks dat de REST API vaak onbereikbaar is, dat de Zendure app zelf prima blijft werken. Ik kan bijvoorbeeld gewoon de led aan/uit zetten of de offgrid poort bedienen.

Het is dus niet zomaar een slechte verbinding, maar ik denk ook de http implementatie op de zendure die ermee te maken heeft. De socket blijft open door 1 mislukte request maar het herstelt zich ook niet meer. En mogelijk lopen daarmee ook het aantal openstaande requests binnen de ZenSDK ofwel de NodeRED proxy op. En dat veroorzaakt een memory leak; en daardoor crashte mijn HA.

Wat mijn Deco in het verhaal doet snap ik nog niet helemaal want de verbinding is wel goed zegt ie. Ik zal eens een mesh node heel dicht in de buurt zetten. Want die repeater is wat mij betreft maar een noodoplossing.

Het ligt inderdaad aan de aansturing in de Deco/Zendure zelf. Het is bekend dat de Zendures erg doof zijn met WiFi.

Ook geprobeerd met een Repeater er tussen in, maar dat was net zo'n drama. Dus vermoed echt dat het iets is tussen de deco/zendure.

Heb zelf hier ook een Deco Mesh Netwerk (Xe75Pro), en heb ze inderdaad ook op een eigen IoT netwerk en alleen 2.4Ghz. Maar wat bij mij heeft geholpen (nog maar gemiddeld 5 uitval per dag van 5 seconden, omdat er vaak 1 omvormer "geen bereik" heeft) is 1 van de mesh routers iets dichterbij gezet (1 meter) en "snelle roaming" en "beamforming" uitzetten.

En dat bereik is twijfel achtig inderdaad, aangezien de deco app 1 streepje minder heeft soms. En bij mij staat 1 mesh router nog geen 5 meter hemelsbreed van de zendures (3 stuks).

[gast777]

Voor de liefhebbers, met de nieuwe Proxy versie kun je live de ruwe json data zien van alle communicatie tussen HA, Proxy en Zendures. Daarmee kun je exact alles zien wat er gebeurt, wat voor sommige issues (zoals die van @Pakhaas wellicht ) nuttig kan zijn om te troubleshooten. Dit is beschikbaar op het Node-RED dashboard (URL http://<ip-adres>:1880/endpoint/ui/ of http://<ip-adres>:1880/ui/ ). Die kun je evt ook direct in HA zetten (nieuw dashboard toevoegen, web-pagina gebruiken).

Dat ziet er zo uit:



Om de CPU niet continu hiermee te belasten moet de debug aangezet worden middels een knop. En als men het vergeet weer uit te zetten, dan gaat die vanzelf na 3600 GET requests (dus ~ een uur) weer uit.

Heel soms (voor complexe issues) is het ook nodig om de data op te slaan voor latere analyse, met timestamps. Dat is nog niet beschikbaar. Ik heb hier nu wel intern een versie die die mogelijkheid heeft en dat werkt goed (file opslaan in /share/, werkt op HAOS prima). Dit zal evt (default disabled) in een volgende versie terechtkomen.

Misschien zelfs nuttig als je normaal de Gielz zonder proxy gebruikt, dan kun je de proxy er even tussen zetten (werkt nu ook met 1 Zendure) en alle json data zien/opslaan .

Voor de liefhebbers zoals ik al zei Normaliter heb je dit natuurlijk niet nodig.

[YvonneVP]

dit is het zendure HA topic.

[ Voor 96% gewijzigd door teacher op 09-05-2026 08:39 ]

[Hippe Lip]

dit is het zendure HA topic.

[ Voor 95% gewijzigd door teacher op 09-05-2026 08:39 ]

[wautah91]

Mistraller schreef op vrijdag 8 mei 2026 @ 14:22:
Nav het gekke gedrag bij mij thuis met de Gielz integratie; het lijkt inderdaad niet aan de integratie zelf te liggen.

Ik heb een TPLink Deco Mesh netwerk; hierop zit ook een IoT netwerk (met alleen 2.4Ghz) en daar had ik de zendures aan hangen.

En het werkte pas goed toen ik er een repeater (ook tplink) tussen had gezet.

Wat valt op?

De response op /properties/report geven bij een directe connectie op de Deco (zowel het IoT als het hoofd netwerk trouwens) erg vaak een connection reset. En dan werkt natuurlijk ook de proxy niet. (Daar zag ik ook vaak connection reset/ Connection reset by peer optreden) Bij de repeater (die overigens gewoon wireless is) zie ik dit niet gebeuren.

Het gekke is, dat, ondanks dat de REST API vaak onbereikbaar is, dat de Zendure app zelf prima blijft werken. Ik kan bijvoorbeeld gewoon de led aan/uit zetten of de offgrid poort bedienen.

Het is dus niet zomaar een slechte verbinding, maar ik denk ook de http implementatie op de zendure die ermee te maken heeft. De socket blijft open door 1 mislukte request maar het herstelt zich ook niet meer. En mogelijk lopen daarmee ook het aantal openstaande requests binnen de ZenSDK ofwel de NodeRED proxy op. En dat veroorzaakt een memory leak; en daardoor crashte mijn HA.

Wat mijn Deco in het verhaal doet snap ik nog niet helemaal want de verbinding is wel goed zegt ie. Ik zal eens een mesh node heel dicht in de buurt zetten. Want die repeater is wat mij betreft maar een noodoplossing.

Mocht het voor @gast777 of @gielz interessant zijn als ik wat meer testjes doe, laat maar weten. Wellicht kunnen we de integraties nog iets robuuster krijgen

Wat als je de scan interval naar bijvoorbeeld 5 seconden zet in plaats van 1? Bij mij werkt dat een stuk stabieler. Ik dacht zelf dat dat aan mijn mini pc, node red of Hyper2000 lag, maar dat zou dus ook nog aan de deco kunnen liggen...

[Flexiilex]

ctrl-tab schreef op vrijdag 8 mei 2026 @ 07:39:
Hoe lucratief is dat handelen nu eigenlijk met het weer van afgelopen dagen?

Ik gebruik de dynamic energy cost integratie en daar zie je heel mooi het gebruik en kosten vsn je devices, per uur, dag, maand jaar. Zendures hebben me 37 euro opgeleverd in 3 weken. Maar nu ligt het stil, relatief.

Ik gebruikte als test een threshold van 9 cent. Dat is het verschil tussen cheapest hours (mean) en expensive hours (mean), waarvan ik 2 uur met 4kw dump in de avond (dus 8kw uit ex verlies) de rest zelfverbruik (smart discharge). Dat komt aardig uit als er nog een wasje draait in de nacht (nu bijna op 0)

Heb 6 ab3000x dis ~14 kw beschikbaar.

Heb met de charge van gistermiddag welgeteld 50 cent verdiend. Als je dan de afschrijving op laadcycli meeneent draai je eigenlijk gewoon verlies. Ook als je verder gaat dan 6000 cycli.

Heb de threshold nu op 15 cent gezet. Dan pak je de 'mwoah' dagen niet meer mee en zal het meestal veel hoger zijn dan dat.

Volgend jaar andere spelregels natuurlijk.


[Afbeelding]

Goeie tip trouwens, heb dit ook gelijk ingesteld. Iemand enig idee hoe je dan ook je daadwerkelijke winst makkelijk kan berekenen? Inclusief RTE, inkoop prijs en verkoop prijs, maar ook rekening houdend met dat je bijv 7 kWh laad op goedkope kwartier prijs va dat je het had geexporteerd op dat moment enz? Rekening houdend dus met alles zo’n beetje

[ctrl-tab]

Flexiilex schreef op vrijdag 8 mei 2026 @ 20:30:
[...]

Goeie tip trouwens, heb dit ook gelijk ingesteld. Iemand enig idee hoe je dan ook je daadwerkelijke winst makkelijk kan berekenen? Inclusief RTE, inkoop prijs en verkoop prijs, maar ook rekening houdend met dat je bijv 7 kWh laad op goedkope kwartier prijs va dat je het had geexporteerd op dat moment enz? Rekening houdend dus met alles zo’n beetje

Ik gebruik zelf aio energy management voor schedules, dan weet je ook wat de min-max-mean price is van het betreffende window. Dat kan je dan in een input variabele opslaan (bv last charge price) ofwel direct uit die sensor trekken. Dan weet je welke prijs je in je batrerij hebt zitten. Stuur maar pb als je meer info wilt anders wordt het hier ook zon bende.

[jordyc]

Flexiilex schreef op vrijdag 8 mei 2026 @ 20:30:
[...]

Goeie tip trouwens, heb dit ook gelijk ingesteld. Iemand enig idee hoe je dan ook je daadwerkelijke winst makkelijk kan berekenen? Inclusief RTE, inkoop prijs en verkoop prijs, maar ook rekening houdend met dat je bijv 7 kWh laad op goedkope kwartier prijs va dat je het had geexporteerd op dat moment enz? Rekening houdend dus met alles zo’n beetje

Ik gebruik de dynamic enery cost uit HACS. Die berekent per interval aan de hand van het op dat moment geldende tarief en verbruik uit wat iets heeft gekost. Dit kun je dus ook voor terugleveren gebruiken. In de integratie kun je zelf bepalen of je dag, week, jaar of uur staten wilt. Met de manual entity bereken ik dus ook de daadwerkelijke waarde van de stroom die in de batterij zit, om zo te kunnen bepalen of het rendabel is om terug te ontladen.

Ik zal morgen even alle code delen, zowel van de situatie van 2026 als 2027. Dus met onderscheid tussen laden van het net of zonnepanelen en terugleveren.

[wheli]

Morgen zijn de dynamische tarieven precies 0. Ik heb normaal mijn aantal goedkoopste periodes op 16 staan zodat mijn batterijtje helemaal vol is op de goedkoopste uren. Nu wordt de spread niet zichtbaar omdat er gedeeld wordt door 0.

Als ik 24 invul doet hij het wel. Is dit een bekende bug?

Logger: homeassistant.components.template.template_entity
Source: components/template/template_entity.py:101
Integration: Template (documentation, issues)
First occurred: 9:15:42 PM (8 occurrences)
Last logged: 9:24:15 PM

TemplateError('ZeroDivisionError: division by zero') while processing template 'Template<template=({% set uren = state_attr('sensor.dynamisch_goedkoopste_periode', 'raw_tomorrow') or [] %} {% set duurste = state_attr('sensor.dynamisch_goedkoopste_periode', 'duurste_na_eerste_goedkope_morgen') or [] %} {% set goedkope_uren = uren | selectattr('goedkoop','equalto','ja') | list %} {% set dure_uren = duurste | list %} {% if goedkope_uren | count > 0 and dure_uren | count > 0 %} {% set avg_goedkoop = goedkope_uren | map(attribute='value') | sum / goedkope_uren | count %} {% set avg_duur = dure_uren | map(attribute='value') | sum / dure_uren | count %} {{ ((avg_duur - avg_goedkoop) / (avg_goedkoop | abs) * 100) | round(1) }} {% else %} 0 {% endif %}) renders=14>' for attribute '_attr_native_value' in entity 'sensor.dynamisch_spread_indicatie_nom_morgen'

[Pakhaas]

wheli schreef op vrijdag 8 mei 2026 @ 21:30:
Morgen zijn de dynamische tarieven precies 0. Ik heb normaal mijn aantal goedkoopste periodes op 16 staan zodat mijn batterijtje helemaal vol is op de goedkoopste uren. Nu wordt de spread niet zichtbaar omdat er gedeeld wordt door 0.

Als ik 24 invul doet hij het wel. Is dit een bekende bug?

Logger: homeassistant.components.template.template_entity
Source: components/template/template_entity.py:101
Integration: Template (documentation, issues)
First occurred: 9:15:42 PM (8 occurrences)
Last logged: 9:24:15 PM

TemplateError('ZeroDivisionError: division by zero') while processing template 'Template<template=({% set uren = state_attr('sensor.dynamisch_goedkoopste_periode', 'raw_tomorrow') or [] %} {% set duurste = state_attr('sensor.dynamisch_goedkoopste_periode', 'duurste_na_eerste_goedkope_morgen') or [] %} {% set goedkope_uren = uren | selectattr('goedkoop','equalto','ja') | list %} {% set dure_uren = duurste | list %} {% if goedkope_uren | count > 0 and dure_uren | count > 0 %} {% set avg_goedkoop = goedkope_uren | map(attribute='value') | sum / goedkope_uren | count %} {% set avg_duur = dure_uren | map(attribute='value') | sum / dure_uren | count %} {{ ((avg_duur - avg_goedkoop) / (avg_goedkoop | abs) * 100) | round(1) }} {% else %} 0 {% endif %}) renders=14>' for attribute '_attr_native_value' in entity 'sensor.dynamisch_spread_indicatie_nom_morgen'

Ik zou de tarieven weergeven incl btw en eb. Dan is het morgen niet 0. Incl btw en eb geeft een beter beeld van de kosten, ook al kan je nog salderen.

[fabudop]

wheli schreef op vrijdag 8 mei 2026 @ 21:30:
Morgen zijn de dynamische tarieven precies 0. Ik heb normaal mijn aantal goedkoopste periodes op 16 staan zodat mijn batterijtje helemaal vol is op de goedkoopste uren. Nu wordt de spread niet zichtbaar omdat er gedeeld wordt door 0.

Als ik 24 invul doet hij het wel. Is dit een bekende bug?

Dat was te verwachten, als je de code bekijkt:

code:

{{ ((avg_duur - avg_goedkoop) / avg_goedkoop * 100) | round(1) }}

Hij deelt gewoon door de goedkoopste uren, zonder te checken of dat nul is.

Het ging eerder als mis als die prijs negatief werd, maar dat heeft Gielz inmiddels gefixed. Deze fout moet er dus ook nog uit.

Als jij 24 invult dan zal de prijs niet precies meer nul zijn. Het is gewoon toeval dat je hier tegenaan loopt.

[DrNickB]

Mistraller schreef op vrijdag 8 mei 2026 @ 14:22:
Nav het gekke gedrag bij mij thuis met de Gielz integratie; het lijkt inderdaad niet aan de integratie zelf te liggen.

.....

Even gekke vraag:
Waarop draai je deze integratie + NR?
Is dit toevallig een linux gebaseerd systeem?
Zoja welke kernel wordt er mee gewerkt?

Kleine uitleg: enige tijd (paar weekjes) geleden had ik ook veel connection resets, zelf draaide ik HA via Docker compose,
bleek dat er in de linux kernel iets was veranderd / mis was gegaan. Deze bug is pas enige kernel versies later opgelost. Had dus niks met HA te maken, niks met het systeem zelf, maar wel met de combi.

[Mistraller]

metalmarco schreef op vrijdag 8 mei 2026 @ 17:34:
[...]

Het ligt inderdaad aan de aansturing in de Deco/Zendure zelf. Het is bekend dat de Zendures erg doof zijn met WiFi.

Ook geprobeerd met een Repeater er tussen in, maar dat was net zo'n drama. Dus vermoed echt dat het iets is tussen de deco/zendure.

Heb zelf hier ook een Deco Mesh Netwerk (Xe75Pro), en heb ze inderdaad ook op een eigen IoT netwerk en alleen 2.4Ghz. Maar wat bij mij heeft geholpen (nog maar gemiddeld 5 uitval per dag van 5 seconden, omdat er vaak 1 omvormer "geen bereik" heeft) is 1 van de mesh routers iets dichterbij gezet (1 meter) en "snelle roaming" en "beamforming" uitzetten.

En dat bereik is twijfel achtig inderdaad, aangezien de deco app 1 streepje minder heeft soms. En bij mij staat 1 mesh router nog geen 5 meter hemelsbreed van de zendures (3 stuks).

Met repeater is het fors beter bij mij. REST API blijft ook echt hangen in z'n connectie. Want als ik de zendure restart is het ook voor eventjes opgelost. Roaming etc heb ik allemaal al uitgezet, die accu's gaan echt niet door het huis wandelen Ik zal nog eens testen met de node van de 1e etage even naar de garage verhuizen. Als het dan wel goed is dan zet koop ik er nog wel een x50 bij want repeaters vind ik maar niks eigenlijk. Bereik zelf is helemaal prima volgens de Gielz integratie maar ook volgens DECO. En als het werkt, is de response ook gewoon vlotjes.

wautah91 schreef op vrijdag 8 mei 2026 @ 19:47:
[...]

Wat als je de scan interval naar bijvoorbeeld 5 seconden zet in plaats van 1? Bij mij werkt dat een stuk stabieler. Ik dacht zelf dat dat aan mijn mini pc, node red of Hyper2000 lag, maar dat zou dus ook nog aan de deco kunnen liggen...

Waar doe je dat?

DrNickB schreef op zaterdag 9 mei 2026 @ 00:14:
[...]

Even gekke vraag:
Waarop draai je deze integratie + NR?
Is dit toevallig een linux gebaseerd systeem?
Zoja welke kernel wordt er mee gewerkt?

Kleine uitleg: enige tijd (paar weekjes) geleden had ik ook veel connection resets, zelf draaide ik HA via Docker compose,
bleek dat er in de linux kernel iets was veranderd / mis was gegaan. Deze bug is pas enige kernel versies later opgelost. Had dus niks met HA te maken, niks met het systeem zelf, maar wel met de combi.

NR staat nu op mijn Qnap (ts464) om even uit te sluiten, maar gaat tzt wel weer terug naar HA. Maar maakte voor het gedrag niks uit, en ook Gielz direct met 1 zendure gaf zelfde gedrag.

Maar lees mijn post nog eens opnieuw: want dit heeft echt niks met HA zelf te maken. Misschien met de manier waarop het http request naar de REST API gedaan wordt, maar als HA of NR geen respons krijgt, krijgt ook mijn browser of telefoon geen respons op /properties/report. Terwijl de Zendure app zelf dan nog altijd goed werkt. Tot ik de zendure dus herstart, dan is het weer goed. (Want dan is de http server in de zendure immers ook herstart met een verse TCP connectie en zo.

[ctrl-tab]

DrNickB schreef op zaterdag 9 mei 2026 @ 00:14:
[...]

Even gekke vraag:
Waarop draai je deze integratie + NR?
Is dit toevallig een linux gebaseerd systeem?
Zoja welke kernel wordt er mee gewerkt?

Kleine uitleg: enige tijd (paar weekjes) geleden had ik ook veel connection resets, zelf draaide ik HA via Docker compose,
bleek dat er in de linux kernel iets was veranderd / mis was gegaan. Deze bug is pas enige kernel versies later opgelost. Had dus niks met HA te maken, niks met het systeem zelf, maar wel met de combi.

Ook last van gehad. Allerlei vage connection issues. Goodwe integratie ging helemaal stuk. Ubuntu lts. Maar raakte puur UDP als ik me goed herinner.

Heeft me een halve dag gekost, dankjewel auto updates ubuntu.. 🤢

[gielz]

Zelf draai ik de integratie zeer intensief. Hier draait de Global en Nederlandse versie parallel waarbij er maar 1 automatisering actief is.

Zendure is verbonden via een AP zonder mesh in huis. Een goed wifi signaal is eigenlijk het belangrijkste. Had dus wel mooi geweest als ze bekabeld aangesloten konden worden wat bij de MIX serie nu wel het geval is.

[wheli]

#nevermind

[ Voor 106% gewijzigd door wheli op 09-05-2026 08:36 ]

[Pakhaas]

Ik ben even benieuwd wat jullie in het logboek van @gielz zien als jullie het vermogen handmatig wijzigen. Hier komen dan 2 meldingen in het logboek. Trouwens niet altijd, maar meestal wel. Is dat juist?

[ZuinigeRijder]

metalmarco schreef op vrijdag 8 mei 2026 @ 17:34:
[...]

Het ligt inderdaad aan de aansturing in de Deco/Zendure zelf. Het is bekend dat de Zendures erg doof zijn met WiFi.

Ook geprobeerd met een Repeater er tussen in, maar dat was net zo'n drama. Dus vermoed echt dat het iets is tussen de deco/zendure.

Heb zelf hier ook een Deco Mesh Netwerk (Xe75Pro), en heb ze inderdaad ook op een eigen IoT netwerk en alleen 2.4Ghz. Maar wat bij mij heeft geholpen (nog maar gemiddeld 5 uitval per dag van 5 seconden, omdat er vaak 1 omvormer "geen bereik" heeft) is 1 van de mesh routers iets dichterbij gezet (1 meter) en "snelle roaming" en "beamforming" uitzetten.

En dat bereik is twijfel achtig inderdaad, aangezien de deco app 1 streepje minder heeft soms. En bij mij staat 1 mesh router nog geen 5 meter hemelsbreed van de zendures (3 stuks).

Je kunt ook nog per connectie de volgende dingen doen in de Deco App:
- Mesh uitzetten
- Koppelen aan het dichtstbijzijnde AP (dus niet Auto)
- Vastpinnen op 2.4 Ghz

Let op, bij een firmware update, zul je deze settings opnieuw moeten doen.

Naast het al genoemde uitzetten van "snelle roaming" en "beamforming".
Ik heb trouwens geen apart IoT netwerk gemaakt.

Wat ik gemerkt heb, is dat de HomeWizard Energie sockets wel heel dicht bij het Deco AP moet staan, wil deze een goed Wifi signaal hebben. Nu heb ik dus ook een Deco AP in de garage staan, waarbij alleen 2x Zendure 800 Plus, Zendure Bridge en 2x HW Energie socket op zitten

[Floris039]

Kan iemand mij hier mee helpen? Om 11 uur is de auto aan het opladen en vanaf dat moment staat de NOM op 0 import of export op de batterij en geeft de SDK dit weer: Zover ik kan zien is er niks mis met de automatisering. Ik heb HA al geherstart en ook de automatisering uit gezet en weer terug aan.

[Mistraller]

gielz schreef op zaterdag 9 mei 2026 @ 08:22:
Zelf draai ik de integratie zeer intensief. Hier draait de Global en Nederlandse versie parallel waarbij er maar 1 automatisering actief is.

Zendure is verbonden via een AP zonder mesh in huis. Een goed wifi signaal is eigenlijk het belangrijkste. Had dus wel mooi geweest als ze bekabeld aangesloten konden worden wat bij de MIX serie nu wel het geval is.

Ja UTP was wel fijn geweest, heeft altijd mijn voorkeur, ik heb overal extra buis liggen. Maar goed dat wordt helaas vaak weg gelaten; in het geval van de zendure waarschijnlijk vanwege IP65 rating.

ZuinigeRijder schreef op zaterdag 9 mei 2026 @ 09:44:
[...]


Je kunt ook nog per connectie de volgende dingen doen in de Deco App:
- Mesh uitzetten
- Koppelen aan het dichtstbijzijnde AP (dus niet Auto)
- Vastpinnen op 2.4 Ghz

staan, waarbij alleen 2x Zendure 800 Plus, Zendure Bridge en 2x HW Energie socket op zitten

Dat is uiteraard al gedaan, dat heb ik bij alle devices met een vaste opstelling

[Pakhaas]

Iemand enig idee wat dat onbalans precies betekent? Het valt mij op dat hij steeds tijdens het laden/ontladen wat uit balans raakt en daarna weer uitstekend. Nu staat hij sinds dat ze vol zijn op onbalans.

[geert1992]

Pakhaas schreef op zaterdag 9 mei 2026 @ 16:26:
Iemand enig idee wat dat onbalans precies betekent? Het valt mij op dat hij steeds tijdens het laden/ontladen wat uit balans raakt en daarna weer uitstekend. Nu staat hij sinds dat ze vol zijn op onbalans.


[Afbeelding]

Cel onbalans kan kloppen, ze houden een plekje vrij voor Peter en Ali.
In de API call staat de minimale cel voltage, en de hoogste, hier wil je eigenlijk zo minmogelijk verschil in hebben. Gielz heeft nu het zo gemaakt, dat binnen bepaalde marges, hij daar een gradatie aangeeft.
Excellent <= 0,02v
Good <= 0,05v
Slight Imbalance <= 0,08v
else Imbalanced

[ Voor 4% gewijzigd door geert1992 op 09-05-2026 16:49 ]

[Aardedraadje]

Pakhaas schreef op zaterdag 9 mei 2026 @ 16:26:
Iemand enig idee wat dat onbalans precies betekent? Het valt mij op dat hij steeds tijdens het laden/ontladen wat uit balans raakt en daarna weer uitstekend. Nu staat hij sinds dat ze vol zijn op onbalans.


[Afbeelding]

Onbalans zegt alleen iets wanneer de batterijen (een poos) standby zijn. Tijdens ont- en opladen is onbalans te verwachten en mag dan genegeerd worden.

Na het ont- of opladen hebben de cellen nog even wat tijd nodig voordat de openklemspanning herstelt. Daarna zegt het onderlinge spanningsverschil pas iets over de staat van het accupack.

Jij ziet in rust 'uitstekend' en daar gaan het om. Gaat goed dus

[Pakhaas]

Aardedraadje schreef op zaterdag 9 mei 2026 @ 20:35:
[...]

Onbalans zegt alleen iets wanneer de batterijen (een poos) standby zijn. Tijdens ont- en opladen is onbalans te verwachten en mag dan genegeerd worden.

Na het ont- of opladen hebben de cellen nog even wat tijd nodig voordat de openklemspanning herstelt. Daarna zegt het onderlinge spanningsverschil pas iets over de staat van het accupack.

Jij ziet in rust 'uitstekend' en daar gaan het om. Gaat goed dus

Ja poosje later waren ze weer uitstekend. Bedankt.

[gast777]

Pakhaas schreef op zaterdag 9 mei 2026 @ 09:40:
Ik ben even benieuwd wat jullie in het logboek van @gielz zien als jullie het vermogen handmatig wijzigen. Hier komen dan 2 meldingen in het logboek. Trouwens niet altijd, maar meestal wel. Is dat juist?

[Afbeelding]

Update: dit is opgelost in de nieuwe versie van de Proxy (20260509).

Dankzij de nieuwe debug functionaliteit in de Proxy was de oorzaak snel gevonden

[Pakhaas]

Vandaag tijdje met @gast777 aan het debuggen geweest. Werkte perfect met de nieuwe debug functie. Hij wist het daarna snel te verhelpen! Bedankt! 👍

Het probleem was dat mijn logboek vol stond met vermogens correcties.

[ Voor 47% gewijzigd door Pakhaas op 09-05-2026 21:40 ]

[gielz]

Floris039 schreef op zaterdag 9 mei 2026 @ 11:28:
Kan iemand mij hier mee helpen? Om 11 uur is de auto aan het opladen en vanaf dat moment staat de NOM op 0 import of export op de batterij en geeft de SDK dit weer:[Afbeelding] Zover ik kan zien is er niks mis met de automatisering. Ik heb HA al geherstart en ook de automatisering uit gezet en weer terug aan.

Draai je de laatste versie van de automatisering die de hartslag vult? Wat staat er in input_datetime.zendure_gielz_automatisering_laatste_keer_uitgevoerd ?

[Hippe Lip]

Ik heb vandaag eens een hele dag op ‘handel (Dynamic Trading) gedraaid.

Er zouden 23 kwartieren ( of korter als de batterij eerder vol is) achter elkaar strak geladen moeten worden en later op de dag 16 kwartieren ontladen.



Groot was echter mijn verbazing toen ik vanavond keek hoe het was gegaan. Er was helemaal niet strak geladen. Niks strakke laadgrafiek maar een enorme hakkelbende.
Wat kan hier aan de hand geweest zijn?

Bij het ontladen ging het wél netjes strak.

[ Voor 20% gewijzigd door Hippe Lip op 09-05-2026 23:51 ]

[YvonneVP]

koboy schreef op donderdag 7 mei 2026 @ 13:52:
[...]


Dat zeg ik toch letterlijk in de laaste alinea die je ook citeert? Je moet gewoon doen met dat ding waar je zin in hebt. Punt.

Ik geef alleen tegengas tegen het idee dat (een vorm van) NOM financiëel het voordeligste is, want dat is het niet. Net zoals er geen sprake is van gratis opladen van een EV van eigen zonnestroom waar ik ook altijd tegen zal protesteren, zeker zo lang we nog mogen salderen.

En ik geef dus tegengas op het moment dat 'handelen' tot heilige graal wordt verheven. Er zijn namelijk meerder mogelijkheden waarbij het niet iedereen om het geld verdienen gaat maar om het streven van een lagere rekening, en ja dat levert dus ook geld op. Jij begon daar niet over, dus het is ook niet specifiek aan jou gericht.

[Pakhaas]

YvonneVP schreef op zondag 10 mei 2026 @ 03:25:
[...]

Er zijn namelijk meerder mogelijkheden waarbij het niet iedereen om het geld verdienen gaat maar om het streven van een lagere rekening, en ja dat levert dus ook geld op.

Ik geef het op.

[Pakhaas]

@Hippe Lip vreemd. Hier ziet het er zo uit:

[ Voor 21% gewijzigd door Pakhaas op 10-05-2026 07:15 ]

[klump4u]

YvonneVP schreef op zondag 10 mei 2026 @ 03:25:
[...]

En ik geef dus tegengas op het moment dat 'handelen' tot heilige graal wordt verheven. Er zijn namelijk meerder mogelijkheden waarbij het niet iedereen om het geld verdienen gaat maar om het streven van een lagere rekening, en ja dat levert dus ook geld op. Jij begon daar niet over, dus het is ook niet specifiek aan jou gericht.

Precies, ik draai ook alleen NOM en dat vind ik prima, een ieder moet voor zich zelf bepalen waar hij of zij zich goed bij voelt, het leven bestaat uit meer dan alleen maar geld.

[Eduardo M]

Goedemorgen,

Ik zie in HA dat er een nieuwe versie van de Gielz automatisering is. Aangezien dit mijn eerste upgrade gaat worden is mijn vraag: is de installatie identiek aan die van een eerste installatie?

[ Voor 17% gewijzigd door Eduardo M op 10-05-2026 08:09 ]

[gielz]

Eduardo M schreef op zondag 10 mei 2026 @ 07:43:
Goedemorgen,

Ik zie in HA dat er een nieuwe versie van de Gielz automatisering is. Aangezien dit mijn eerste upgrade gaat worden is mijn vraag: is hier een soort van stappenplan voor beschikbaar ?

1. Zet je batterij in modus standby
2. Vervang je package (juiste taal)
3. Vervang je automatisering en dashboard (juiste taal)
4. Herstart HA

Zal dit ook wel even wat netter uitschrijven op GitHub. Eigenlijk zijn het de stappen die je gedaan hebt toen je met de integratie begon.

[gielz]

Hippe Lip schreef op zaterdag 9 mei 2026 @ 23:45:
Ik heb vandaag eens een hele dag op ‘handel (Dynamic Trading) gedraaid.

Er zouden 23 kwartieren ( of korter als de batterij eerder vol is) achter elkaar strak geladen moeten worden en later op de dag 16 kwartieren ontladen.

[Afbeelding]

Groot was echter mijn verbazing toen ik vanavond keek hoe het was gegaan. Er was helemaal niet strak geladen. Niks strakke laadgrafiek maar een enorme hakkelbende.
Wat kan hier aan de hand geweest zijn?

Bij het ontladen ging het wél netjes strak.

[Afbeelding]

Zou je even een stukje log kunnen posten van tijdens het laden?

[Hippe Lip]

gielz schreef op zondag 10 mei 2026 @ 08:11:
[...]

Zou je even een stukje log kunnen posten van tijdens het laden?

Tja, die log is er nu natuurlijk niet meer.

Straks om 09:45 gaat-ie weer een langere tijd achter elkaar volle bak (als het goed is) laden. Ik zal het dan eens in de gaten houden en hier melden.

[Hippe Lip]

YvonneVP schreef op zondag 10 mei 2026 @ 03:25:
[...] waarbij het niet iedereen om het geld verdienen gaat maar om het streven van een lagere rekening, […]

Dat verschil moet je me even uitleggen…

[gielz]

Hippe Lip schreef op zondag 10 mei 2026 @ 08:38:
[...]

Tja, die log is er nu natuurlijk niet meer.

Straks om 09:45 gaat-ie weer een langere tijd achter elkaar volle bak (als het goed is) laden. Ik zal het dan eens in de gaten houden en hier melden.

Log word 10 dagen bewaard, even links naar activiteit/activity gaan.

Daarna als doel/target; input_select.zendure_operation_mode

[Hippe Lip]

gielz schreef op zondag 10 mei 2026 @ 08:45:
[...], even links naar activiteit/activity gaan.

Ik zit me suf te zoeken.
“Links naar activiteit/activity gaan“, waar is dat? Ik heb in HA in de linker balk nix dat daarop lijkt.

Bij Developer tools > Statistics kan ik input_select.zendure_operation_modeook niet vinden.

[gielz]

Hippe Lip schreef op zondag 10 mei 2026 @ 08:54:
[...]

Ik zit me suf te zoeken.
“Links naar activiteit/activity gaan“, waar is dat? Ik heb in HA in de linker balk nix dat daarop lijkt.

Bij Developer tools > Statistics kan ik input_select.zendure_operation_modeook niet vinden.

Je kunt ook more klikken bij het 4 uur logbook. Acitivity staat altijd links tussen je andere dashboards en instellingen etc.

[Hippe Lip]

gielz schreef op zondag 10 mei 2026 @ 09:07:
Acitivity staat altijd links tussen je andere dashboards en instellingen etc.

Dan kijk ik er overheen…
Hierboven staan alleen eigen dashboards.

[klump4u]

Hippe Lip schreef op zondag 10 mei 2026 @ 09:13:
[...]

Dan kijk ik er overheen…
Hierboven staan alleen eigen dashboards.

[Afbeelding]

3e pagina rechtsboven,

[Hippe Lip]

gielz schreef op zondag 10 mei 2026 @ 08:45:
[...]

Log word 10 dagen bewaard, even links naar activiteit/activity gaan.

Daarna als doel/target; input_select.zendure_operation_mode

Is dit wat je zoekt, @gielz?

[Hippe Lip]

En ik draai nu versie 20260501. Hoop er vandaag toe te komen om te upgraden.

[Henkoes]

ctrl-tab schreef op vrijdag 8 mei 2026 @ 20:57:
[...]

Ik gebruik zelf aio energy management voor schedules, dan weet je ook wat de min-max-mean price is van het betreffende window. Dat kan je dan in een input variabele opslaan (bv last charge price) ofwel direct uit die sensor trekken. Dan weet je welke prijs je in je batrerij hebt zitten. Stuur maar pb als je meer info wilt anders wordt het hier ook zon bende.

Is aio energy management betrouwbare software?

[Henkoes]

gielz schreef op zondag 10 mei 2026 @ 08:09:
[...]

1. Zet je batterij in modus standby
2. Vervang je package (juiste taal)
3. Vervang je automatisering en dashboard (juiste taal)
4. Herstart HA

Zal dit ook wel even wat netter uitschrijven op GitHub. Eigenlijk zijn het de stappen die je gedaan hebt toen je met de integratie begon.

Ik doe dit steeds zonder eerste standby in te schakelen. Wist niet dat dat moest. Is het schadelijk zonder standby?

[BizzieBis]

Pakhaas schreef op zaterdag 9 mei 2026 @ 16:26:
Iemand enig idee wat dat onbalans precies betekent? Het valt mij op dat hij steeds tijdens het laden/ontladen wat uit balans raakt en daarna weer uitstekend. Nu staat hij sinds dat ze vol zijn op onbalans.


[Afbeelding]

Ik denk dat de weergave van de cell balans een wat vertekend beeld kan geven. Zo is onderstaande zichtbaar bij mij. De grote piek is op het moment dat de batterij stopt met laden. SOC geeft iets van 78% aan, maar power naar de betreffende batterij is vanaf dit moment alleen nog maar 0. De SOC van de batterij klimt wel langzaam naar 100%. Ik denk dat gedurende dat traject de cellen gebalanceerd worden, en de cell spanning uitlezing onbetrouwbaar is om iets nuttigs te kunnen zeggen over de balans.

Maar zoals al opgemerkt, Bekijk de cell balans wanneer de batterij volledig vol is. Of wanneer je hem voor 50% leeg getrokken hebt. Dan zullen de waardes een beter beeld geven.

[Hippe Lip]

@gielz Nu weer:

[Devke]

Hippe Lip schreef op zondag 10 mei 2026 @ 10:03:
@gielz Nu weer:

[Afbeelding]

[Afbeelding]

[Afbeelding]

Check je Wifi eens. Ik zie gaatjes in je grafieken, dat is een wifi issue.

[Hippe Lip]

Devke schreef op zondag 10 mei 2026 @ 10:15:
[...]

Check je Wifi eens. Ik zie gaatjes in je grafieken, dat is een wifi issue.

Hoe kan ik dat verbeteren als een node van het meshnetwerk (AVM, Fritz) op minder dan 2 meter afstand hangt?

[Devke]

Hippe Lip schreef op zondag 10 mei 2026 @ 10:22:
[...]

Hoe kan ik dat verbeteren als een node van het meshnetwerk (AVM, Fritz) op minder dan 2 meter afstand hangt?

Je kunt proberen even de Zendure opnieuw te koppelen in je app van Zendure. Helpt dat niet dan een x herstart van je modem/app?

[geert1992]

Hippe Lip schreef op zondag 10 mei 2026 @ 10:22:
[...]

Hoe kan ik dat verbeteren als een node van het meshnetwerk (AVM, Fritz) op minder dan 2 meter afstand hangt?

Ik zou eens een WiFi-analyzer op je telefoon installeren en kijken hoe druk de 2,4GHz-band bij jou is. Zeker op 2,4GHz kan het behoorlijk vol zitten met netwerken van buren en andere storingsbronnen.

Persoonlijk zou ik, waar mogelijk, ook afstappen van een volledig draadloos meshnetwerk. In mijn ogen is mesh vooral een noodoplossing voor plekken waar je echt geen kabel kunt krijgen, niet per se de meest duurzame of stabiele oplossing.

Als je de mogelijkheid hebt, zou ik access points liever bekabeld aansluiten. Dat geeft meestal veel meer stabiliteit, lagere latency en minder gedoe dan nodes die onderling draadloos moeten doorverbinden.

[Hippe Lip]

geert1992 schreef op zondag 10 mei 2026 @ 10:42:
[...]

Ik zou eens een WiFi-analyzer op je telefoon installeren en kijken hoe druk de 2,4GHz-band bij jou is. Zeker op 2,4GHz kan het behoorlijk vol zitten met netwerken van buren en andere storingsbronnen.

Ga ik straks doen.

Persoonlijk zou ik, waar mogelijk, ook afstappen van een volledig draadloos meshnetwerk. In mijn ogen is mesh vooral een noodoplossing voor plekken waar je echt geen kabel kunt krijgen, niet per se de meest duurzame of stabiele oplossing.

Als je de mogelijkheid hebt, zou ik access points liever bekabeld aansluiten. Dat geeft meestal veel meer stabiliteit, lagere latency en minder gedoe dan nodes die onderling draadloos moeten doorverbinden.

Je doet nogal een aanname.

AL mijn mesh accesspoints zijn bekabeld aangesloten. Ze hebben allemaal een bekabelde backhaul.

[geert1992]

Hippe Lip schreef op zondag 10 mei 2026 @ 10:49:
[...]

Ga ik straks doen.

[...]

Je doet nogal een aanname.

AL mijn mesh accesspoints zijn bekabeld aangesloten. Ze hebben allemaal een bekabelde backhaul.

Fair point, met bekabelde backhaul is het inderdaad een ander verhaal. Dan noemt AVM/FRITZ het nog steeds “mesh”, maar technisch gezien zijn het vooral bekabelde accesspoints met centrale aansturing.

[TBird484]

Hippe Lip schreef op zondag 10 mei 2026 @ 10:49:
[...]

AL mijn mesh accesspoints zijn bekabeld aangesloten. Ze hebben allemaal een bekabelde backhaul.

Heb je het 2,4GHz kanaaal vast gezet of staat deze nog op auto ? Bij mij was dit uiteindelijk de oplossing in combinatie met het locken van de zendures aan een specifiek accesspoint.

[Hippe Lip]

TBird484 schreef op zondag 10 mei 2026 @ 11:01:
[...]

Heb je het 2,4GHz kanaaal vast gezet of staat deze nog op auto ? Bij mij was dit uiteindelijk de oplossing in combinatie met het locken van de zendures aan een specifiek accesspoint.

@TBird484 Die snap ik niet helemaal. Waar zet ik dat vast, in de Zendure?
En wat zet ik dan precies vast?

[Hippe Lip]

Inmiddels lijkt het erop dat het weer goed gaat.

Wat ik heb gedaan:

1. Accesspoint een minuut van de spanning gehaald.
2. Na opstarten daarvan in de Zendure app elk van de 2 stacks opnieuw met WiFi gekoppeld.
3. Daarna de stacks uitgezet: >6s knop indrukken en nadat display aangeeft dat-ie uit is, de stekker er een minuut uit.
4. Zendures weer aan de spanning, waarna ze opnieuw gingen opstarten.
5. Home Assistant opnieuw opgestart.

Nu krijg ik weer een strakke oplaadgrafiek.

Dank voor alle hulp hier!

[ Voor 3% gewijzigd door Hippe Lip op 10-05-2026 11:43 ]

[Hippe Lip]

geert1992 schreef op zondag 10 mei 2026 @ 10:42:
Ik zou eens een WiFi-analyzer op je telefoon installeren en kijken hoe druk de 2,4GHz-band bij jou is. Zeker op 2,4GHz kan het behoorlijk vol zitten met netwerken van buren en andere storingsbronnen.

Wat is een goed analyser voor de iPhone? Ik heb er een paar geprobeerd, maar daar wordt ik niet wijzer van. Ik zie wel een lijst van andere apparaten op het netwerk, maar dan, wat moet ik daarmee?
Ik heb wel eigen (andere) tools om die te zien, maar dan weet ik toch nog niet of het WiFi-net (kanaal) daarmee overbelast is?

Het werken met zo'n analyser is ook nieuw voor me.

[TBird484]

Hippe Lip schreef op zondag 10 mei 2026 @ 11:39:
[...]

Die snap ik niet helemaal. Waar zet ik dat vast, in de Zendure?
En wat zet ik dan precies vast?

Gaat om settings van de door jou gebruikte WiFi oplossing. Als de kanaalkeuze op auto staat dan wisselt in een drukke omngeving nogal vaak het kanaal. Iedere keer als dit gebeurt wordt de verbinding met je clients verbroken. Dit kan je dus voorkomen door hier een fixed kanaal voor te selecteren. Als je een mesh oplossing gebruikt, dan kunnen de clients gaan roamen binnen de verschillende accesspoints. Dit kan je voorkomen door de betreffende client hard te koppelen aan een specifiek accesspoint

[Ben(V)]

@Hippe Lip
Als je Access Points bekabelt zijn aangesloten is het per definitie geen mesh systeem.
Mesh is niets anders dan een backhaul die over wifi gaat (ofwel repeaters).

En zoals @TBird484 al zei, je Access Points op auto hebben kan Zendure niet goed tegen, als die overschakelen naar een ander kanaal verliest die z'n verbinding en het duurt even voor die weer terug is, dan krijg je dus deze gaten.
Kijk welk kanaal het rustigste is en als je AccessPoint dicht genoeg bij de Zendure staat kun je beter de 5Hz band gebruiken, die heeft veel minder last van storing door buren.

[Devke]

Hippe Lip schreef op zondag 10 mei 2026 @ 11:42:
Inmiddels lijkt het erop dat het weer goed gaat.

Wat ik heb gedaan:

1. Accesspoint een minuut van de spanning gehaald.
2. Na opstarten daarvan in de Zendure app elk van de 2 stacks opnieuw met WiFi gekoppeld.
3. Daarna de stacks uitgezet: >6s knop indrukken en nadat display aangeeft dat-ie uit is, de stekker er een minuut uit.
4. Zendures weer aan de spanning, waarna ze opnieuw gingen opstarten.
5. Home Assistant opnieuw opgestart.

Nu krijg ik weer een strakke oplaadgrafiek.

Dank voor alle hulp hier!

Gaatjes in de grafieken is vaak Wifi. Zelf heb ik een KPN booster ook vervangen door een AP. Bekabeld naar de V12 router van KPN. Helaas valt nu bij het AP soms de verbinding weg. Is ook te testen daar er dan op het AP niet in te loggen valt. Als ik hem even 10 sec spanningsloos maak en weer van prik voorzie dan haken de Zendure's binnen enkele minuten zelf weer aan. Of het AP loopt op zijn eind of het is toch iets i.c.m. het KPN modem. Voor nu heb ik even een Energy Socket gepakt en een automatisering gemaakt. Als de verbining wegvalt dan laat ik de ledring van het Energy Socket knipperen. Visueel dan zichtbaar.

[ Voor 7% gewijzigd door Devke op 10-05-2026 12:59 ]

[Chip2710]

Ik gebruik naar tevredenheid de intergratie van Zendure in HA. Gebruik alleen de „slimme matching“ instelling echter nu wil ik in het weekend de gratis stroom van Budget Energie gebruiken om de accu vol te laden, indien noodzakelijk. Echter welke stand moet ik de Zendure HA app zetten zodat het werkt en moet er nog iets anders omgezet worden?

In de Zendure kan dat eenvoudig en werkt dan ook.

[Henkoes]

Chip2710 schreef op zondag 10 mei 2026 @ 13:58:
Ik gebruik naar tevredenheid de intergratie van Zendure in HA. Gebruik alleen de „slimme matching“ instelling echter nu wil ik in het weekend de gratis stroom van Budget Energie gebruiken om de accu vol te laden, indien noodzakelijk. Echter welke stand moet ik de Zendure HA app zetten zodat het werkt en moet er nog iets anders omgezet worden?

In de Zendure kan dat eenvoudig en werkt dan ook.

[Afbeelding]

Thuisbatterij opladen op de gratis weekend stroom is door budgetenergie verboden in de voorwaarden.

[Chip2710]

Henkoes schreef op zondag 10 mei 2026 @ 14:18:
[...]

Thuisbatterij opladen op de gratis weekend stroom is door budgetenergie verboden in de voorwaarden.

De soep wordt nooit zo heet gegeten als ze wordt opgediend.

[jordyc]

ik had nog beloofd om de sensoren die ik had gebouwd om de ROI van je batterij te meten te delen. Met deze 4 sensoren maak je onderscheidt tussen laden van de zonnepanelen of grid en ontladen voor eigen verbruik of naar de grid.

Je hebt verder de volgende dingen nodig:

- per sensor een extra integral sensor op basis van onderstaande sensoren.

- dynamische uurtarief inclusief belasting, deze koppel je aan laden van grid en ontladen voor eigen verbruik

- dynamische uurtarief exclusief belasting, deze koppel je aan de integral sensor voor laden van de zonnepanelen en ontladen naar grid.

- HACS integration Dynamic Energy Cost. Deze berekent per sensor wat op basis van de uurprijs de daadwerkelijke kosten of besparing is.

- Als je bovenstaande hebt kun je deze in een template sensor bij elkaar voegen om inzicht te krijgen wat je na dit jaar aan kosten gaat besparen.


De code van de 4 sensoren:

YAML: sensoren

    - name: "Batterij laden van zonnepanelen"

      unique_id: battery_charging_from_solar

      unit_of_measurement: "W"

      device_class: power

      state: >

        {% set grid = states('sensor.homewizard_p1_vermogen') | float(0) %}

        {% set battery = states('sensor.zendure_2400_ac_vermogen_aansturing') | float(0) %}


        {% if battery <= 0 %}

          0

        {% elif grid <= 0 %}

          {{ battery }}

        {% else %}

          {{ max(0, battery - grid) }}

        {% endif %}


    - name: "Batterij laden van grid"

      unique_id: battery_charging_from_grid

      unit_of_measurement: "W"

      device_class: power

      state: >

        {% set grid = states('sensor.homewizard_p1_vermogen') | float(0) %}

        {% set battery = states('sensor.zendure_2400_ac_vermogen_aansturing') | float(0) %}


        {% if battery <= 0 %}

          0

        {% elif grid <= 0 %}

          0

        {% else %}

          {{ min(battery, grid) }}

        {% endif %}


    - name: "Batterij output eigen verbruik"

      unique_id: battery_output_own_consumption

      unit_of_measurement: "W"

      device_class: power

      state: >

        {% set grid = states('sensor.homewizard_p1_vermogen') | float(0) %}

        {% set battery = states('sensor.zendure_2400_ac_vermogen_aansturing') | float(0) %}


        {% if battery >= 0 %}

          0

        {% elif grid > 0 %}

          {{ battery | abs }}

        {% else %}

          {{ max(0, battery | abs - grid | abs) }}

        {% endif %}


    - name: "Batterij output naar grid"

      unique_id: battery_output_to_grid

      unit_of_measurement: "W"

      device_class: power

      state: >

        {% set grid = states('sensor.homewizard_p1_vermogen') | float(0) %}

        {% set battery = states('sensor.zendure_2400_ac_vermogen_aansturing') | float(0) %}


        {% if battery >= 0 %}

          0

        {% elif grid > 0 %}

          0

        {% else %}

          {{ min(battery | abs, grid | abs) }}

        {% endif %}

[ Voor 5% gewijzigd door jordyc op 10-05-2026 16:10 ]

[Hippe Lip]

Ben(V) schreef op zondag 10 mei 2026 @ 12:18:
@Hippe Lip
Als je Access Points bekabelt zijn aangesloten is het per definitie geen mesh systeem.
Mesh is niets anders dan een backhaul die over wifi gaat (ofwel repeaters).

Ik zie meerdere access points (AP’s) met dezelfde SSID en hetzelfde wachtwoord en waarbij de handover van AP naar AP centraal geregeld wordt als mesh netwerk.

En zoals @TBird484 al zei, je Access Points op auto hebben kan Zendure niet goed tegen, als die overschakelen naar een ander kanaal verliest die z'n verbinding en het duurt even voor die weer terug is, dan krijg je dus deze gaten.
Kijk welk kanaal het rustigste is en als je AccessPoint dicht genoeg bij de Zendure staat kun je beter de 5Hz band gebruiken, die heeft veel minder last van storing door buren.

Ik zit gelukkig ver genoeg van buren af om er maar twee (twee rustige) te zien. Daar lijkt het dus ook niet aan te liggen.
Het is dus geen drukke omgeving waarbij je veel actieve aanpassingen van kanalen en zo kan verwachten.

Maar kan ik ergens regelen dat de Zendure’s altijd hetzelfde AP gebruiken? Die functie ken ik nog niet binnen de Fritz, maar dat zegt niet zoveel. Pas nog geleerd hoe ik een per DHCP uitgedeeld adres kon wijzigen en er een vast adres van kon maken, zonder dat er in het apparaat zelf iets aangepast werd.

[ Voor 4% gewijzigd door Hippe Lip op 10-05-2026 16:56 ]

[Hippe Lip]

TBird484 schreef op zondag 10 mei 2026 @ 11:59:
[...] Als je een mesh oplossing gebruikt, dan kunnen de clients gaan roamen binnen de verschillende accesspoints. Dit kan je voorkomen door de betreffende client hard te koppelen aan een specifiek accesspoint

@TBird484
Hoe doe ik dat? Die functie ken ik nog niet.

[Mimiix]

Mimiix schreef op vrijdag 8 mei 2026 @ 14:53:
In navolging van mijn eerdere post Mimiix in "Zendure producten in Home Assistant integreren deel 2"

Zie ik nog iets geks gebeuren met de PV: hij laad tot 100%. Ik heb geen idee hoe en waarom, maar hij gaat boven de 90%. Kalibreren staat al een tijd op Nee.

[Afbeelding]

Vandaag weer tot 100%

Ik vermoed dat het komt door het slim opladen dat steeds override en de bms die daar niets mee lijkt te doen.

Iemand anders die dit ook ziet?

[gielz]

Mimiix schreef op zondag 10 mei 2026 @ 16:59:
[...]

Vandaag weer tot 100%

Ik vermoed dat het komt door het slim opladen dat steeds override en de bms die daar niets mee lijkt te doen.

Iemand anders die dit ook ziet?

Weet niet exact wat je bedoelt. Maar ik verwacht dat je denkt dat kalibreren op JA moet komen te staan. Dit doet hij alleen als hij 30 dagen niet tot 100% is opgeladen. Kalibreren komt dan op JA te staan en de batterij word volledig geblokkeerd. De BMS gaat dan zelf tot 100% laden en je kunt niets meer doen met de batterij tot dit is afgerond.

[gielz]

Hippe Lip schreef op zondag 10 mei 2026 @ 10:03:
@gielz Nu weer:

[Afbeelding]

[Afbeelding]

[Afbeelding]

Wat je hier ziet gebeuren is dat hij tijdens de dynamisch cyclus een trigger krijgt dat er gedacht word dat de maximale state of charge is bereikt (door wegvallen WIFI).

Vervolgens gaat hij de cyclus weer herstarten. Prima wanneer de WIFI af en toe wegvalt maar niet om de haverklap wat je hier ziet. Er was een gebruiker op GitHub die dit ook had doordat de Zendure ging zweven in het mesh netwerk.

[Mimiix]

gielz schreef op zondag 10 mei 2026 @ 17:03:
[...]


Weet niet exact wat je bedoelt. Maar ik verwacht dat je denkt dat kalibreren op JA moet komen te staan. Dit doet hij alleen als hij 30 dagen niet tot 100% is opgeladen. Kalibreren komt dan op JA te staan en de batterij word volledig geblokkeerd. De BMS gaat dan zelf tot 100% laden en je kunt niets meer doen met de batterij tot dit is afgerond.

Hij is nu al 3 dagen achter elkaar op 100% geweest als de zon schijnt.

[TBird484]

Hippe Lip schreef op zondag 10 mei 2026 @ 16:52:
[...]

@TBird484
Hoe doe ik dat? Die functie ken ik nog niet.

Ik heb zelf ZenWifi en daar heb ik een optie “Bind device to node”. Als ik het goed lees gebruik jij Fritz. Ik heb hier geen ervaring mee, maar als ik ai mag geloven dan kent dit systeem alleen maar de mogelijkheid om clients uit te sluiten van een AP. Als je dit voor alle AP's zou doen behalve degene waar hij mee verbonden moet blijven, dan zou je hetzelfde resultaat moeten hebben. Maar of dat nu zo'n mooie oplossing is...

[RemmyB83]

Chip2710 schreef op zondag 10 mei 2026 @ 13:58:
Ik gebruik naar tevredenheid de intergratie van Zendure in HA. Gebruik alleen de „slimme matching“ instelling echter nu wil ik in het weekend de gratis stroom van Budget Energie gebruiken om de accu vol te laden, indien noodzakelijk. Echter welke stand moet ik de Zendure HA app zetten zodat het werkt en moet er nog iets anders omgezet worden?

In de Zendure kan dat eenvoudig en werkt dan ook.

[Afbeelding]

Ik zit ook bij budget energie.
En de modus die ik gebruik hangt af van de hoeveelheid zon die ik die dag opwek. Vandaag gewoon nom(smart matching), andere keer slim opladen, en een andere keer handmatig opladen.
Ligt echt aan mijn opwek en verbruik van die dag. Ook wil ik zo min mogelijk salderen, dus ik wil niet opladen om vervolgens weer te salderen. Mijn doel is om op de 1000kWh staffel te blijven hangen en er niet over heen te gaan.

[Gramser]

Ik heb wat mafs, misschien herkennen jullie het? Nu ik terug van vakantie weer eens in HA kijk, zie ik dat een van de twee torentjes op standby staat terwijl hij wel een ontlaadcommando krijgt. Ik heb de automation al even uitgezet, de modus van beiden naar standby gezet en weer terug naar smart matching, en ook even HEMS geactiveerd maar ik krijg torentje 2 niet aan het ontladen.

Kan ik dat op enige manier alsnog op afstand triggeren zonder dat ik meteen de boel weer van de stroom moet halen voor een reset?

edit:
blijkbaar heb ik wel íets getriggerd… want ook device 2 is weer gaan ontladen. Nou mooi. Gekke dingen zijn het af en toe.

[ Voor 33% gewijzigd door Gramser op 10-05-2026 20:13 ]

[RemmyB83]

Gramser schreef op zondag 10 mei 2026 @ 20:04:
Ik heb wat mafs, misschien herkennen jullie het? Nu ik terug van vakantie weer eens in HA kijk, zie ik dat een van de twee torentjes op standby staat terwijl hij wel een ontlaadcommando krijgt. Ik heb de automation al even uitgezet, de modus van beiden naar standby gezet en weer terug naar smart matching, en ook even HEMS geactiveerd maar ik krijg torentje 2 niet aan het ontladen.

Kan ik dat op enige manier alsnog op afstand triggeren zonder dat ik meteen de boel weer van de stroom moet halen voor een reset?

edit:
blijkbaar heb ik wel íets getriggerd… want ook device 2 is weer gaan ontladen. Nou mooi. Gekke dingen zijn het af en toe.

[Afbeelding]

Vandaag was hij hier ook even de weg kwijt.
Accu was leeg maar zodra de hij kon gaan opladen werden de accu's niet actief, en bleef hij alleen de opwek terugleveren van de twee aangesloten panelen. Pas toen ik hem om 11.50 in standby heb gezet en vervolgens op NOM, werd hij wakker en ging hij doen wat hij moest doen.

[Chip2710]

RemmyB83 schreef op zondag 10 mei 2026 @ 19:27:
[...]

Ik zit ook bij budget energie.
En de modus die ik gebruik hangt af van de hoeveelheid zon die ik die dag opwek. Vandaag gewoon nom(smart matching), andere keer slim opladen, en een andere keer handmatig opladen.
Ligt echt aan mijn opwek en verbruik van die dag. Ook wil ik zo min mogelijk salderen, dus ik wil niet opladen om vervolgens weer te salderen. Mijn doel is om op de 1000kWh staffel te blijven hangen en er niet over heen te gaan.

Dat begrijp ik echter hoe werkt dat slim opladen en handmatig opladen?

[RemmyB83]

Chip2710 schreef op zondag 10 mei 2026 @ 23:13:
[...]

Dat begrijp ik echter hoe werkt dat slim opladen en handmatig opladen?

Ik gebruik zelf de Gielz integratie, maar bij de fireson integratie kun je:
1. Bij handmatig opladen zelf instellen met hoeveel Watt je continue wilt laden of ontladen.
2. En bij slim Laden wordt er volgens mijn niet ontladen, en zorgt hij er voor dat al je opwek in de batterij gaat tot hij vol zit.
Geen idee waar die eigenlijk van verschilt met de 'zonne-energie opslaan' mode.

[YvonneVP]

Pakhaas schreef op zondag 10 mei 2026 @ 07:13:
[...]

Ik geef het op.