Zendure producten in Home Assistant integreren deel 2

[ppaulv]

Theetjuh schreef op woensdag 28 oktober 2026 @ 21:07:
Prima dat je voorzichtig bent met updates, zeker met major releases, maar hou er wel rekening mee dat in 18.4 de eMudhra CA vulnerability is opgelost, das geen kleine CVE.

Overigens, ik meen gelezen te hebben dat de docker versie van HA geen major update heeft gekregen maar dat het daar met een setje security updates is geregeld. Just saying.

[Theetjuh]

ppaulv schreef op woensdag 28 oktober 2026 @ 22:54:
[...]

Overigens, ik meen gelezen te hebben dat de docker versie van HA geen major update heeft gekregen maar dat het daar met een setje security updates is geregeld. Just saying.

In de docker versie zal dit wel anders of makkelijker geregeld kunnen worden

[ Voor 12% gewijzigd door Theetjuh op 28-10-2026 23:27 ]

[Quiqziz]

manusjevanalles schreef op woensdag 28 oktober 2026 @ 07:27:
[...]


Ik heb met Claude een template sensor die het actuele vermogen (laden of ontladen) berekent uit de bron (pv of net), en het omrekent naar euro/uur. Een Riemannsensor houdt de totale opbrengsten bij. Daarop kun je weer een utility sensor (dag/maand/jaar) zetten.
Bij laden uit pv is de waarde -5 (want ik zou 5 cent verdiend hebben aan export), bij laden uit net -29 cent (en een mix kan ook). Bij ontladen is de waarde 29 cent. Ik heb nu nog een vast contract met inkoop 29 cent, verkoop 5 cent. Maar dit werkt identiek met een dynamisch contract.
Ik doe hetzelfde met mijn recent gelegde extra set zonnepanelen.
Desgewenst kan ik hem delen.

Dank je wel, als je hem zou willen delen zou dat top zijn. Ben vooral benieuwd hoe dit te combineren met een dynamisch contract waarbij je elk kwartier met andere getallen werkt ipv steeds een vaste prijs.

[Pakhaas]

Quiqziz schreef op donderdag 29 oktober 2026 @ 06:21:
[...]

Dank je wel, als je hem zou willen delen zou dat top zijn. Ben vooral benieuwd hoe dit te combineren met een dynamisch contract waarbij je elk kwartier met andere getallen werkt ipv steeds een vaste prijs.

Ik heb hier zelf ook een dashboard die precies optelt hoeveel het kost om te laden en ontladen met dynamisch tarieven.

Straks komt er nog het verschil tussen laden en ontladen bij.

Vandaag staat nu in de min, want vannacht geladen en dan straks gaat die weer naar positief na ontladen.

[manusjevanalles]

Quiqziz schreef op donderdag 29 oktober 2026 @ 06:21:
[...]

Dank je wel, als je hem zou willen delen zou dat top zijn. Ben vooral benieuwd hoe dit te combineren met een dynamisch contract waarbij je elk kwartier met andere getallen werkt ipv steeds een vaste prijs.

Ik heb twee sensoren: een voor het inkooptarief (inclusief belastingen) en verkooptarief. In mijn geval dus 29 en 5 cent. Maar het werkt hetzelfde met dynamische prijzen. Ik heb één SF800+.

Dan de volgende sensor:

YAML:

- name: "Opbrengst batterij euro"
    unique_id: 3b5f171b-4b3a-4091-bc0c-9f3a0a9470b3
    unit_of_measurement: "€/h"
    state_class: measurement
    icon: mdi:currency-eur
    state: >
      {% set b       = states('sensor.zendure_2400_ac_vermogen_aansturing') | float(0) %}
      {% set laad    = [b, 0] | max %}
      {% set ontlaad = [-b, 0] | max %}
      {% set n       = states('sensor.netverbruik_totaal') | float(0) %}
      {% set nb      = n - b %}
      {% set p_imp   = states('sensor.kosten_inkoop_kwh') | float(0) %}
      {% set p_exp   = states('sensor.kosten_verkoop_kwh') | float(0) %}
      {% set uit_pv    = [laad, [-nb, 0] | max] | min %}
      {% set vermeden  = [ontlaad, [nb, 0] | max] | min %}
      {{ (( vermeden * p_imp + (ontlaad - vermeden) * p_exp
          - uit_pv * p_exp - (laad - uit_pv) * p_imp ) / 1000) | round(4) }}

Deze sensor laat realtime zien wat er gebeurt financieel. Laden kost in mijn geval meestal 5 cent per kWh (volledig PV), dan zal hij -5 cent aangeven (bij 1000W laden). Ontladen laat dan 29 cent zien.

Om het totaalbedrag bij te houden maak je een Riemann-sensor:

code:

Integral sensor
Trapezoidal
Precision 2
sub-interval 10seconden)

De Riemann-sensor laat dus de totale opbrengsten zien van de batterij. Bij laden loopt hij terug, bij ontladen loopt het bedrag op. Vervolgens kan je utility meters maken met de Riemann-sensor als bron voor de dag/maand/jaarstanden.

Er zijn ongetwijfeld verschillende manieren om de laadkosten vanuit PV te waarderen. In mijn geval krijg ik nog dit jaar voor elke geëxporteerde kWh 5 cent (hopelijk volgend jaar ook nog zolang het contract loopt). Dus wat ik niet teruglever, kost mij wel 5 cent per kWh. In de sensor die de opbrengsten van de zonnepanelen bijhoudt, wordt elke opgeleverde kWh als 5 cent geteld, ook als het direct in de batterij gaat. De batterij loopt dan met 5 cent per kWh terug.

Volledig laden en ontladen levert dus zo'n 29-5*1.5 = 36 cent op, als ik laadverliezen even buiten beschouwing laat.

[ Voor 15% gewijzigd door manusjevanalles op 29-10-2026 09:18 ]

[BestevaerNL]

delete

[ Voor 96% gewijzigd door BestevaerNL op 29-10-2026 14:47 ]

[ppaulv]

Ben(V) schreef op woensdag 28 oktober 2026 @ 09:05:
[...]

Dit lijk mij op een connectie probleem van de wifi als zowel HA als Hems niet werken.

Overigens waarom heb je hem niet gewoon op "Smart Matching" staan in plaats van zelf met de hand proberen de boel bij te regelen?

En wat betreft je vorige post, dat is echt enkel een gevoels kwestie, een batterij slijt echt niet meer door veranderende belasting.
Batterijen verouderen enkel door de absolute hoeveelheid lading en/of ontlading en niet door de snelheid daarvan.

Gisteren weer ongeveer hetzelfde. Op de Zendure app reageren ze dus wèl (niet meteen maar er zit altijd overal vertraging op).
Aansturing via Gielz en NR al enkele dagen volstrekt probleemloos en plotseling reageert niets meer op a) de wisselingen van de P1 en b) mijn handmatige instellingen (naar standby of manual).
De waardes in het NR dashboard voor Power command, Power AC command veranderen niet meer. En dus blijven de accu's doen wat ze aan het begin aan het doen waren, ongeacht wat de P1 waardes zijn.
Herstarten van HA en NR (beide in docker) maakt niets uit.
Het een voor een opnemen van de accu's in HEMS in de Zendure app helpt wel, ze gaan redelijk snel in Standby (na wat gefrut in de te volgen policy).
Daarna weer uit HEMS gehaald en reageren ze weer op HA/NR.
Het lijkt mij dus een communicatieprobleem omdat ze wel zoals verwacht reageren op de Zendure app.
Zou dit kunnen komen door het feit dat HA en NR bij mij in een eigen docker image zitten? Is het mogelijk of beter om NR in de HA docker te installeren?

[ Voor 3% gewijzigd door ppaulv op 30-10-2026 11:07 ]

[SamWjjchen]

zie screenshot.. de connectie status verspringt continue, iemand een idee wat te doen of heeft iemand dit ook als een gehad?
De battery ontlaad niet meer zins vannacht 2.00
alvast dank .

[Polvo176]

SamWjjchen schreef op vrijdag 30 oktober 2026 @ 11:32:
zie screenshot.. de connectie status verspringt continue, iemand een idee wat te doen of heeft iemand dit ook als een gehad?
De battery ontlaad niet meer zins vannacht 2.00
alvast dank .

[Afbeelding]

Is al vaker voorbij gekomen, het is een ip adres conflict.
Er staat in HA Zendure storage dan een ander ip adres dan jou router.
De eerste is niet aan te passen, ik heb daar nog een ticket over lopen.
Ik heb de ip adressen in mij router daarom maar aangepast en vast gezet zodat er door DHCP geen ander ip adres aan de Zendure batterijen gegeven kan worden.

PS, als je ze terug zet op cloud en ha herstart werken ze wel weer.

[ Voor 3% gewijzigd door Polvo176 op 30-10-2026 12:07 ]

[Gramser]

ppaulv schreef op vrijdag 30 oktober 2026 @ 11:06:
[...]

Gisteren weer ongeveer hetzelfde. Op de Zendure app reageren ze dus wèl (niet meteen maar er zit altijd overal vertraging op).
Aansturing via Gielz en NR al enkele dagen volstrekt probleemloos en plotseling reageert niets meer op a) de wisselingen van de P1 en b) mijn handmatige instellingen (naar standby of manual).
De waardes in het NR dashboard voor Power command, Power AC command veranderen niet meer. En dus blijven de accu's doen wat ze aan het begin aan het doen waren, ongeacht wat de P1 waardes zijn.
Herstarten van HA en NR (beide in docker) maakt niets uit.
Het een voor een opnemen van de accu's in HEMS in de Zendure app helpt wel, ze gaan redelijk snel in Standby (na wat gefrut in de te volgen policy).
Daarna weer uit HEMS gehaald en reageren ze weer op HA/NR.
Het lijkt mij dus een communicatieprobleem omdat ze wel zoals verwacht reageren op de Zendure app.
Zou dit kunnen komen door het feit dat HA en NR bij mij in een eigen docker image zitten? Is het mogelijk of beter om NR in de HA docker te installeren?

Ik heb het even niet meer scherp maar heb jij de zendures op een separaat accesspoint zitten?

[ppaulv]

Gramser schreef op vrijdag 30 oktober 2026 @ 12:11:
[...]

Ik heb het even niet meer scherp maar heb jij de zendures op een separaat accesspoint zitten?

nee, staan naast elkaar in hetzelfde wifi netwerk via hetzelfde AP. Dus dat is het niet. En beide hebben lange tijd (maanden) los van elkaar met alleen Gielz prima gefunctioneerd. Pas sinds ik ze allebei aan heb staan en via NR aanstuur gebeurt dit af en toe.

[NWE]

m-vw schreef op donderdag 8 oktober 2026 @ 21:39:
[...]


Gielz heeft deze functie volgens mij niet, van Omnibattery of andere automatiseringen ben ik niet zeker.

Je zou zelf aan de slag kunnen met hetzelfde GET commando dat deze automatiseringen gebruiken om de data binnen te krijgen.

Is er echt geen andere mogelijkheid om de SF3000 in HA "uit te lezen", op dezelfde manier als ik de HW P1 meter uitlees, de de Enphase Envoy "controller" in HomeAssistant ?? Ik heb dan 1 simpel dashboard met alle belangrijke spelers (op mijn PC) . Het managen van de batterij kan ik dan, indien noodzakelijk , nog vanaf mijn friemelscherpje-iPhone doen.

[Fire71]

ppaulv schreef op vrijdag 30 oktober 2026 @ 12:26:
[...]

nee, staan naast elkaar in hetzelfde wifi netwerk via hetzelfde AP. Dus dat is het niet.[Afbeelding] En beide hebben lange tijd (maanden) los van elkaar met alleen Gielz prima gefunctioneerd. Pas sinds ik ze allebei aan heb staan en via NR aanstuur gebeurt dit af en toe.

Wel een opvallend groot verschil in wifi connectie sterkte (-46 vs -73 dbm) voor apparaten die naast elkaar staan. Een sterkte van -73 dbm is echt op het randje van bruikbaar.  Staat de wifi antenne van de 2400+ wel overeind? Zit er geen metaal tussen de AP en de 2400+?

Ter vergelijk, mijn 2 x 2400 pro staan ook naast elkaar, onder mijn AP, en hebben -31 en -34 dbm.

[ppaulv]

Fire71 schreef op vrijdag 30 oktober 2026 @ 12:46:
[...]

Wel een opvallend groot verschil in wifi connectie sterkte (-46 vs -73 dbm) voor apparaten die naast elkaar staan. Een sterkte van -73 dbm is echt op het randje van bruikbaar.  Staat de wifi antenne van de 2400+ wel overeind? Zit er geen metaal tussen de AP en de 2400+?

Ter vergelijk, mijn 2 x 2400 pro staan ook naast elkaar, onder mijn AP, en hebben -31 en -34 dbm.

ja ik vind 'm ook heel apart. Zeker omdat het de AC+ is die het zwakkere signaal laat zien terwijl die een aparte, omhoogstekende antenne heeft.
Hmmm ... ik zie in m'n router dat de AC+ nogal wat TX retries laat zien, variërend tussen de 5 en 25 procent. En de AC blijft daarmee stabiel op 0 procent staan.
Ga dadelijk even kijken.
Maar kan dat verklaren waarom ze allebei af en toe 'bevriezen' ?

Update: er stond een plastic krat met deels metalen spullen mogelijk in het wifi-pad, heb ik weg gehaald en nu zijn de signaalsterktes 50 en 71. Beats me.

[ Voor 8% gewijzigd door ppaulv op 30-10-2026 13:21 ]

[SamWjjchen]

Polvo176 schreef op vrijdag 30 oktober 2026 @ 12:00:
[...]

Is al vaker voorbij gekomen, het is een ip adres conflict.
Er staat in HA Zendure storage dan een ander ip adres dan jou router.
De eerste is niet aan te passen, ik heb daar nog een ticket over lopen.
Ik heb de ip adressen in mij router daarom maar aangepast en vast gezet zodat er door DHCP geen ander ip adres aan de Zendure batterijen gegeven kan worden.

PS, als je ze terug zet op cloud en ha herstart werken ze wel weer.

Dank... Wifi reset in de zendure app een optie?

[Fire71]

ppaulv schreef op vrijdag 30 oktober 2026 @ 13:08:
[...]

ja ik vind 'm ook heel apart. Zeker omdat het de AC+ is die het zwakkere signaal laat zien terwijl die een aparte, omhoogstekende antenne heeft.
Hmmm ... ik zie in m'n router dat de AC+ nogal wat TX retries laat zien, variërend tussen de 5 en 25 procent. En de AC blijft daarmee stabiel op 0 procent staan.
Ga dadelijk even kijken.
Maar kan dat verklaren waarom ze allebei af en toe 'bevriezen' ?

TX retries worden gedaan als er geen bevestiging van connectie komt van de tegenpartij. Een teken van een slechte connectie dus.

Als er geen connectie is kan de2400+ ook niet reageren op vermogensinstructruties. En ook geen connectie maken met een P1 meter.

Zit de antenne goed vastgeschroeft? Heb je in de router aangegeven dat de Zendure alleen mag connecteren met die specifieke AP? En dus nooit met andere AP? Ik heb Asus AI mesh routers en zorg ervoor dat mijn Zendures alleen met het garage AP mogen connecteren.

Waarom de 2400 AC bevriest weet ik niet. Worden ze samen aangestuurd met omnibatterij of Gielz/NR oid?

[Gramser]

ppaulv schreef op vrijdag 30 oktober 2026 @ 12:26:
[...]

nee, staan naast elkaar in hetzelfde wifi netwerk via hetzelfde AP. Dus dat is het niet.[Afbeelding] En beide hebben lange tijd (maanden) los van elkaar met alleen Gielz prima gefunctioneerd. Pas sinds ik ze allebei aan heb staan en via NR aanstuur gebeurt dit af en toe.

Dus beide zendures op een accesspoint, en alleen die zendures zitten daarop? En dat accesspoint is bekabeld op je router aangesloten? Dit lijkt namelijk erg op wat ik eerst ook had: de boel bleef vastlopen voordat ik de zendures op een separaat accesspoint had gezet. Ook heb ik de cached responsetijd in NR naar 2 minuten gezet.

[ppaulv]

Fire71 schreef op vrijdag 30 oktober 2026 @ 13:20:
[...]

TX retries worden gedaan als er geen bevestiging van connectie komt van de tegenpartij. Een teken van een slechte connectie dus.

Als er geen connectie is kan de2400+ ook niet reageren op vermogensinstructruties. En ook geen connectie maken met een P1 meter.

Zit de antenne goed vastgeschroeft? Heb je in de router aangegeven dat de Zendure alleen mag connecteren met die specifieke AP? En dus nooit met andere AP? Ik heb Asus AI mesh routers en zorg ervoor dat mijn Zendures alleen met het garage AP mogen connecteren.

Waarom de 2400 AC bevriest weet ik niet. Worden ze samen aangestuurd met omnibatterij of Gielz/NR oid?

Met antenne is niks mis voor zover ik kan zien, de AC+ staat letterlijk naast de AC en is hoger dus steekt er bovenuit. Ik beide een vast IP adres gegeven maar niet gedwongen aan één AP, die hebben ze zelf gekozen.
Heel vreemd maar ik kan dan niet verklaren waarom de NR van gast777 bevriest. Want daar lijkt het op. Als ik nou zou zien dat de power commando's van Gielz/Gast777 veranderen maar de accu's reageren niet, dan ligt het vrij zeker aan de Zendures.
Maar als ik in Gielz de modus verander in Manual of Stanby, verandert er niets in de commando's die ik van Gast777 zie.
Ik bedoel deze:

[ppaulv]

Gramser schreef op vrijdag 30 oktober 2026 @ 13:26:
[...]

Dus beide zendures op een accesspoint, en alleen die zendures zitten daarop? En dat accesspoint is bekabeld op je router aangesloten? Dit lijkt namelijk erg op wat ik eerst ook had: de boel bleef vastlopen voordat ik de zendures op een separaat accesspoint had gezet. Ook heb ik de cached responsetijd in NR naar 2 minuten gezet.

Nee er zit vanalles op dat AP (8 stuks) en zeker op dat wifi netwerk (32). Maar AP is wel bekabeld.
Ben geen expert maar op een van de pieken van afgelopen etmaal zie ik weinig problemen.


Hoe zet je die cached responsetijd anders? En waarom zou dat helpen?

[ Voor 5% gewijzigd door ppaulv op 30-10-2026 13:35 ]

[Gramser]

Ik weet niet precies hoe die cached responsetijd werkt, maar voor mezelf verklaar ik het als volgt: NR geeft continu opdrachten aan de zendures en vergaloppeert zich soms. Met de cached responsetijd breng je er weer even wat rust in door een aantal seconden/minuten de opdrachten te negeren.

Je vindt het in NR in het scherm waar je ook de ip adressen ingeeft. Beetje naar onderen scrollen en daar vind je wat aanpasbare variabelen. Het heet daar geen cached response uit mn hoofd, maar staat wel op 15 sec. Daar herken je ‘m ook aan.

Maar een puur dedicated AP kan ook helpen.

[Fire71]

ppaulv schreef op vrijdag 30 oktober 2026 @ 13:28:
[...]

Met antenne is niks mis voor zover ik kan zien, de AC+ staat letterlijk naast de AC en is hoger dus steekt er bovenuit. Ik beide een vast IP adres gegeven maar niet gedwongen aan één AP, die hebben ze zelf gekozen.
Heel vreemd maar ik kan dan niet verklaren waarom de NR van gast777 bevriest. Want daar lijkt het op. Als ik nou zou zien dat de power commando's van Gielz/Gast777 veranderen maar de accu's reageren niet, dan ligt het vrij zeker aan de Zendures.
Maar als ik in Gielz de modus verander in Manual of Stanby, verandert er niets in de commando's die ik van Gast777 zie.
Ik bedoel deze:
[Afbeelding]

Dat heb ik ook laatst gehad, dat van dat schijnbaar bevriezen. HA herstart hielp niet. En ook niet wifi herstarten.

Alleen een reboot van de Zendures hielp. Trek de stekker uit stopcontact. Druk minimaal zes seconden op de knop. Lange piep, dan is Zendure uit. Daarna stekker weer in stopcontact en de Zendure start automatisch.

Achteraf had ik het vermoeden dat het gebeurd is na een upgrade van Node Red in HA. Maar dat is maar een vermoeden. Kan heel goed iets anders geweest zijn.

Vraag: Doet de Gast777 flow het automatisch weer na een update van Node Red?

[Polvo176]

SamWjjchen schreef op vrijdag 30 oktober 2026 @ 13:14:
[...]

Dank... Wifi reset in de zendure app een optie?

In de Zendure app zal waarschijnlijk het zelfde adres staan wat ook in de router staat, dus nee, dat gaat niet helpen.

[ppaulv]

Fire71 schreef op vrijdag 30 oktober 2026 @ 13:48:
[...]

Dat heb ik ook laatst gehad, dat van dat schijnbaar bevriezen. HA herstart hielp niet. En ook niet wifi herstarten.

Alleen een reboot van de Zendures hielp. Trek de stekker uit stopcontact. Druk minimaal zes seconden op de knop. Lange piep, dan is Zendure uit. Daarna stekker weer in stopcontact en de Zendure start automatisch.

Achteraf had ik het vermoeden dat het gebeurd is na een upgrade van Node Red in HA. Maar dat is maar een vermoeden. Kan heel goed iets anders geweest zijn.

Vraag: Doet de Gast777 flow het automatisch weer na een update van Node Red?

een reboot van beide Zendures hielp bij mij dus niet.
Het is mijn eerste installatie van NR, heb nog niets ge-update. En HA en NR staan dus los van elkaar, beide in hun eigen Docker container.

[Luuk741]

NWE schreef op vrijdag 30 oktober 2026 @ 12:39:
[...]

Is er echt geen andere mogelijkheid om de SF3000 in HA "uit te lezen", op dezelfde manier als ik de HW P1 meter uitlees, de de Enphase Envoy "controller" in HomeAssistant ?? Ik heb dan 1 simpel dashboard met alle belangrijke spelers (op mijn PC) . Het managen van de batterij kan ik dan, indien noodzakelijk , nog vanaf mijn friemelscherpje-iPhone doen.

En als je gielz gebruikt, maar de automation die de aansturing regelt niet installeert of inschakelt? Ik weet het niet zeker hoor, maar wellicht het proberen waard. Aan de andere kant kun je hem net zo goed aansturen via Gielz ipv de Zendure app, als je dat dan toch al ingesteld heb

[PaulC]

Gramser schreef op vrijdag 30 oktober 2026 @ 13:26:
[...]

Dus beide zendures op een accesspoint, en alleen die zendures zitten daarop? En dat accesspoint is bekabeld op je router aangesloten? Dit lijkt namelijk erg op wat ik eerst ook had: de boel bleef vastlopen voordat ik de zendures op een separaat accesspoint had gezet. Ook heb ik de cached responsetijd in NR naar 2 minuten gezet.

Aangezien ik ook nogal veel iot apparaten heb en het issue ivm wifi verbindingen hier regelmatig opduikt, zie hier de (met 50% ai hulp ooit samengesteld, i admit) summary die ik in mijn docu staan heb ivm wifi (6) verbindingen (in mijn geval ASUS, maar een groot deel is ook applicable op andere merken zonder meer (alleen kan een setting dan beetje anders noemen of niet aanwezig zijn)

Bij Wi-Fi 6 (802.11ax) routers – en specifiek bij merken zoals ASUS – duikt er af en toe een bekend compatibiliteitsprobleem op dat vooral te maken heeft met oudere clients en slimme huishoudelijke apparaten (IoT).

​Hoewel Wi-Fi 6 volledig achterwaarts compatibel is met oudere standaarden zoals Wi-Fi 5 (802.11ac) en 802.11n, kan de agressieve implementatie van nieuwe Wi-Fi 6-technologieën in de routerfirmware soms voor wrijving zorgen.

​Kuren met Smart Home / IoT-apparaten: Veel slimme stekkers, lampen, oudere IP-camera's of smart home hubs die enkel op 2.4 GHz draaien, raken in de war van moderne Wi-Fi 6-features en vertikken het om te verbinden of verliezen continu hun signaal.

​Welke specifieke instellingen veroorzaken dit?

(​ASUS-)routers hebben een aantal geavanceerde Wi-Fi 6-optimalisaties ingebouwd die dit veroorzaken. Als je merkt dat apparaten verbindingsproblemen hebben, moet je die in de webinterface handmatig uitschakelen of aanpassen:

• ​Target Wake Time (TWT): Een Wi-Fi 6 feature die energie bespaart voor mobiele apparaten door de slaapstand van de Wi-Fi-chip te timen. Oudere of vaste apparaten trekken dit slecht en vallen offline.
• ​Protected Management Frames (PMF): Soms incompatibel met oudere clients.
• ​Wi-Fi Agile Multiband / Roaming-assistenten: Kunnen oudere apparaten "wegduwen" of in een loop van connectie-pogingen laten belanden.
• ​Smart Connect (de bandsteering): Waarbij 2.4 GHz en 5 GHz onder één SSID worden samengevoegd; slimme apparaten weten dan vaak niet op welke frequentie ze moeten vastberaden.

​De oplossingen (in ASUSWRT)

​Mocht je tegen zo'n compatibiliteitsprobleem aanlopen, dan biedt ASUS gelukkig de volledige controle om dit op te lossen (in tegenstelling tot gesloten systemen):

• ​Je kunt per frequentie de 802.11ax / Wi-Fi 6 mode tijdelijk uitschakelen of finetunen voor specifieke netwerken.
• ​Je kunt een apart, geïsoleerd 2.4 GHz gastennetwerk of IoT-netwerk aanmaken waarbij je geavanceerde ax-features uitzet, zodat je oudere apparaten probleemloos verbinding maken, terwijl je hoofdnetwerk vol openstaat voor moderne Wi-Fi 6 apparatuur.

IoT-apparaten locken op een vaste node

​Standaard zijn mesh-systemen heel "agressief": ze proberen apparaten voortdurend te verplaatsen naar de node met het sterkste signaal. Veel statische IoT-apparaten (zoals slimme lampen of thermostaten) raken daar de weg door kwijt.

​In ASUSWRT kun je dit oplossen:

1. ​Via AiMesh Device Control (De officiële manier):
   • ​Log in op je webinterface en ga links naar AiMesh.
   • ​Klik op het tabblad Topology (Topologie) en klik op de node waar je het apparaat op wilt vastzetten.
   • ​Aan de rechterkant verschijnt een paneel met de gekoppelde clients onder die node.
   • ​Klik op het apparaat en zet de optie Binding (of Roaming Block) aan. Hiermee dwing je het apparaat om uitsluitend verbinding te maken met deze specifieke node en niet meer te gaan zwerven naar een andere node.
2. ​Via een apart IoT-netwerk (De robuuste aanpak):
   • ​Als je gebruikmaakt van Guest Network Pro (SDN) op je (ASUS-)router, kun je een apart 2.4 GHz-netwerk aanmaken dat je optioneel op een specifieke node of juist over het hele bereik laat uitzenden, afgeschermd van je hoofdnetwerk

Welk vast kanaal is het beste voor 2.4 GHz IoT?

​Voor de 2.4 GHz-band (waar nagenoeg al het IoT op draait) is automatische kanaalkeuze vaak een ramp, omdat omringende Wi-Fi-netwerken van buren er doorheen storen.

​De gulden regel voor de 2.4 GHz-band is dat je alleen kanaal 1, 6 of 11 mag gebruiken. Dit zijn de enige drie kanalen die elkaar niet overlappen.

• ​Waarom deze? Om te bepalen welke van de twee het rustigste is, kun je op je telefoon een gratis wifi-analyzer app installeren. Kies het kanaal waar de buren het minst op zitten.
• ​Belangrijke instelling (Kanaalbreedte): Zet de kanaalbreedte (Channel Bandwidth) voor de 2.4 GHz-band vast op 20 MHz (en dus niet op 20/40 MHz).
  • ​Waarom? De 2.4 GHz-band is erg smal. Als je 40 MHz kiest, pak je dubbel zoveel bandbreedte van de buren mee, wat zorgt voor gigantisch veel interferentie en wegvallende IoT-verbindingen. 20 MHz is trager, maar rotsvast en storingsvrij voor slimme apparaten.

[raven22]

Fire71 schreef op vrijdag 30 oktober 2026 @ 12:46:
[...]

Wel een opvallend groot verschil in wifi connectie sterkte (-46 vs -73 dbm) voor apparaten die naast elkaar staan. Een sterkte van -73 dbm is echt op het randje van bruikbaar.  Staat de wifi antenne van de 2400+ wel overeind? Zit er geen metaal tussen de AP en de 2400+?

Ter vergelijk, mijn 2 x 2400 pro staan ook naast elkaar, onder mijn AP, en hebben -31 en -34 dbm.

Mijn SF 800 plus staat achter in de tuin onder een overkapping. -84 tot 80db op zijn best.
Slechts een hele enkele keer is de batterij even niet bereikbaar, maar binnen het uur is dat weer hersteld.

[HiBe]

fv schreef op maandag 14 september 2026 @ 17:09:
Ik gebruik de Gielz integratie in HA met twee Zendure 3000 Mix'en ongeveer een maand, maar merk toch wel heel veel overshoot tijdens laden/ontladen waardoor je of teveel ontlaad t.o.v. huidig verbruik of teveel laad uit het net tijdens laden bij zonneovershot. Maar ook s'nacht bij vrij constant verbruik zijn er teveel (hoge) uitschieters (naar boven en beneden). Die zie je trouwens niet in het dashboard van de integratie aangezien deze een smoothing van data laten zien.
Ik gebruik overigens niet de "Dynamische" opties, puur alleen om zonneoverschot op te slaan en s'avond/s'nachts te gebruiken of voor Smart Matching.

Het systeem regelt dus, naar mijn bevinding, te laat. Ik kon dit eerst verklaren doordat de P1 data per 10 sec. verandert (wel DSMR5 meter, dus iedere 1 sec. zenden, maar nieuwe data gaat per 10 sec.:(). Na installatie van een Shelly Pro 3EM wordt de integratie getriggerd door verbruik verandering (tussen 1 a 3 sec.) of iedere 5 sec. automatisch indien geen verbruik verandering. Dit verbeterde de regeling beter, maar kan voor mijn gevoel nog beter. Heb ook wat zitten tunen aan de laad en ontlaad-factor in de laad/ontlaad routine in integratie. Is dit bovenstaande door ander gebruikers ook herkenbaar?

Tevens heb ik de integratie door Claude laten analyseren (niet geschoten altijd mis) of de logica ervan correct is. Hier kwamen wel wat belangrijke punten naar boven en na eigen analyse kan de code ook simpeler/anders op meerdere plekken.
Het beste zou zijn denk ik als de laad/ontlaad logica wordt vervangen door een goed getunde PI(D) regeling. Hier ben ik ook al mee aan het experimenteren...

@fv heb je nog voortgang geboekt met een PID regeling ?

[m-vw]

NWE schreef op vrijdag 30 oktober 2026 @ 12:39:
[...]

Is er echt geen andere mogelijkheid om de SF3000 in HA "uit te lezen", op dezelfde manier als ik de HW P1 meter uitlees, de de Enphase Envoy "controller" in HomeAssistant ?? Ik heb dan 1 simpel dashboard met alle belangrijke spelers (op mijn PC) . Het managen van de batterij kan ik dan, indien noodzakelijk , nog vanaf mijn friemelscherpje-iPhone doen.

Een paar posts onder mijn post is gereageerd dat Gielz ook gewoon de waardes weergeeft als je de automatisering verder niet gebruikt. De entiteiten die door Gielz gecreëerd worden kan je overigens ook op andere dashboarden gebruiken.

[fv]

HiBe schreef op vrijdag 30 oktober 2026 @ 15:12:
[...]

@fv heb je nog voortgang geboekt met een PID regeling ?

Nee, na wat geëxperimenteer het project voorlopig even laten liggen. Kreeg de regeling nog niet stabiel genoeg.

Door de laad/ontlaad factor in de Gielz integratie te kunnen aanpassen via HA ben ik wel tot betere resultaten gekomen en gebruik een Shelly 3-fase stroommeting die veel sneller data genereert dan via de P1 ondanks DSMR5 meter.

We gaan de winter in en dan gaan de accu's ook niet zoveel meer doen icm. zonnecellen (ik doe geen dynamische regeling, heb nog een vast contract tot einde 2027).

[ Voor 12% gewijzigd door fv op 30-10-2026 16:01 . Reden: Aanvulling ]

[ppaulv]

Vandaag doet ie het weer anders. De AC staat volle bak op te laden, de AC+ doet niets en de aansturing zegt 'm dat ie moet terugleveren ....



De vorige keer was het (meen ik) de AC+ die bleef hangen. En daarvoor beide samen.
Ga dadelijk weer eens snuffelen .... Niets te ruiken.

Heb de AC weer in de Zendure HEMS gehangen, policy opnieuw geselecteerd en meteen gaat ie op Standby (dat is de policy). Weer uit HEMS gehaald.

NR van @gast777 blijft zo te zien hangen. De bovenste 3 regels zij al 13 minuten onveranderd (en slaan nergens op overigens)

[ Voor 34% gewijzigd door ppaulv op 30-10-2026 17:21 ]

[Gramser]

Je hebt dus een 2400 en een 2400+ samen in Gielz via gast777? Is dat een use case? Ik meende (maar weet het niet zeker) dat gast777 bedoeld was voor dezelfde modellen?

[RemmyB83]

Gramser schreef op vrijdag 30 oktober 2026 @ 17:15:
Je hebt dus een 2400 en een 2400+ samen in Gielz via gast777? Is dat een use case? Ik meende (maar weet het niet zeker) dat gast777 bedoeld was voor dezelfde modellen?

Nee, gaat erom dat het vermogen gelijk is.
2400 en 2400 gaat goed.
Maar geen 800 en 2400.

[Spikydog]

RemmyB83 schreef op vrijdag 30 oktober 2026 @ 18:14:
[...]

Nee, gaat erom dat het vermogen gelijk is.
2400 en 2400 gaat goed.
Maar geen 800 en 2400.

Gaat wel hoor, hier 2 x 800+ en 1 x 2400AC+, geen enkel probleem

[RemmyB83]

Spikydog schreef op vrijdag 30 oktober 2026 @ 18:59:
[...]

Gaat wel hoor, hier 2 x 800+ en 1 x 2400AC+, geen enkel probleem

Dan heb je denk ik de NR aangepast?

[ppaulv]

En een half uur geleden zat ie weer vast. Bleven ze samen maximaal ontladen. Via Zendure app en HEMS weer op STandby gekregen.
En nu net weer de AC die vol ging ontladen en nergens meer op reageerde. Zelfde 'oplossing'.
Ik heb nu NR gestopt en ga de batterijen nu geheel geïsoleerd met Gielz aansturen. Kijken of een van de twee weer de fout in gaat. Dit werkt zo niet.
Zijn er overiens alternatieven voor de NR proxy? Gielz zelf wil ik niet graag kwijt denk ik maar ik begin open te staan voor opties ....

[Gramser]

Is Omnibattery niks voor jou?

[ppaulv]

Gramser schreef op vrijdag 30 oktober 2026 @ 20:18:
Is Omnibattery niks voor jou?

Misschien wel maar waarom doet de Gast777 proxy het bij mij zo raar? Als dat niks met die proxy te maken heeft verschuift het probleem dan alleen maar.
Als het daar wèl mee te maken heeft, waarom ben ik dan 'de enige' die dit ziet gebeuren?
Ik wordt hier niet blij van.
Heb nu de AC+ op Standby en de AC als enig in Gielz en laat het zo even een dagje draaien.

[Gramser]

Ik weet het ook niet - misschien kun je eea loggen en aan @gast777 voorleggen zodat hij misschien kan zien wat er misgaat?

[ppaulv]

dat is een van de moeilijkheden. Ik heb in NR gezocht naar logging om te kunnen zien of de berichten vanuit Gielz daar wel aankomen en of de berichting van NR wel succesvol naar de batterijen gestuurd worden. Maar kan niet vinden waar dat zou moeten staan en waar ik moet kijken (volgens AI) staat niets.

[Spikydog]

RemmyB83 schreef op vrijdag 30 oktober 2026 @ 19:37:
[...]

Dan heb je denk ik de NR aangepast?

Nee, niets aangepast.

[Nachtapotheker]

Ik ben als software engineer met Claude in de weer gegaan om een eigen laad/ontlaad strategie te bouwen in HA.

Ik heb nu nog een variabel contract vanwege de saldeerruimte, maar ik wil volgend jaar naar dynamisch.

Het algoritme wat ik nu heb baseert zich op de in- en exportprijzen (zoals ze volgend jaar gaan zijn), het ‘normale’ verbruik in huis, de verwachte zonopbrengst en de SOC van de batterij. Het rekent ook over de 0:00 grens heen en herberekent wanneer parameters veranderen.

Na een week finetunen zie ik veelbelovende resultaten. (Ik draai nu nog NOM, dus het ik kan ook mooi zien wat er gebeurt met de planning als je het plan negeert )

Voor de aansturing van de batterij gebruik ik de Gielz integratie. Vervolgens laat de strategie de modus in Gielz kiezen om het plan uit te voeren.

Wellicht is dit een idee voor de tweakers die ontevreden zijn over de wijze waarop Omnibattery het doet. Je kan op deze manier meer finetunen op je eigen situatie.

[Manatwork]

Nachtapotheker schreef op zaterdag 31 oktober 2026 @ 10:16:
Ik ben als software engineer met Claude in de weer gegaan om een eigen laad/ontlaad strategie te bouwen in HA.

Ik heb nu nog een variabel contract vanwege de saldeerruimte, maar ik wil volgend jaar naar dynamisch.

Het algoritme wat ik nu heb baseert zich op de in- en exportprijzen (zoals ze volgend jaar gaan zijn), het ‘normale’ verbruik in huis, de verwachte zonopbrengst en de SOC van de batterij. Het rekent ook over de 0:00 grens heen en herberekent wanneer parameters veranderen.

Na een week finetunen zie ik veelbelovende resultaten. (Ik draai nu nog NOM, dus het ik kan ook mooi zien wat er gebeurt met de planning als je het plan negeert )

Voor de aansturing van de batterij gebruik ik de Gielz integratie. Vervolgens laat de strategie de modus in Gielz kiezen om het plan uit te voeren.

Wellicht is dit een idee voor de tweakers die ontevreden zijn over de wijze waarop Omnibattery het doet. Je kan op deze manier meer finetunen op je eigen situatie.

Het lijkt mij heel interessant maar ik heb werkelijk geen idee hoe ik dit met behulp van Claude voor elkaar zou moeten krijgen. Ik zie wel meer reacties waarin achteloos wordt gemeld dat er een automatisering of een dashboard is geknutseld mbv Claude maar hoe ze dat dan doen wordt er niet bij gezegd. Als iemand een link weet naar een how-to houd ik me aanbevolen.

[mitsumark]

Manatwork schreef op zaterdag 31 oktober 2026 @ 11:24:
[...]

Het lijkt mij heel interessant maar ik heb werkelijk geen idee hoe ik dit met behulp van Claude voor elkaar zou moeten krijgen. Ik zie wel meer reacties waarin achteloos wordt gemeld dat er een automatisering of een dashboard is geknutseld mbv Claude maar hoe ze dat dan doen wordt er niet bij gezegd. Als iemand een link weet naar een how-to houd ik me aanbevolen.

Ik snap je reactie, maar je moet maar gewoon eens beginnen.
Als ik exact jouw quote in claude plak krijg ik vrij duidelijke instructies om mee te beginnen. Ook met ai is er een learning curve (het prompten zelf), je hebt vast een paar uur nodig om het te krijgen zoals je wilt.

[Nachtapotheker]

Manatwork schreef op zaterdag 31 oktober 2026 @ 11:24:
[...]

Het lijkt mij heel interessant maar ik heb werkelijk geen idee hoe ik dit met behulp van Claude voor elkaar zou moeten krijgen. Ik zie wel meer reacties waarin achteloos wordt gemeld dat er een automatisering of een dashboard is geknutseld mbv Claude maar hoe ze dat dan doen wordt er niet bij gezegd. Als iemand een link weet naar een how-to houd ik me aanbevolen.

Dat is ook lastig, je krijgt het ook niet met 1 prompt voor elkaar.

Ik ben een week bezig geweest (een uurtje per dag), elke dag resultaat bekijken en bijsturen, vragen stellen, proberen volledig te doorgronden wat de aanpak is en waarom. Ik gok dat ik straks in de lente/zomer als de verhouding verbruik/opwek totaal anders is weer wat moet bijsturen, maar voor nu werkt het top!

[Gramser]

Ja, ik heb ook een dashboardje gebouwd om mijn thuisbatterijen niet te laten botsen met de laadpaal. Ik wilde dat de zendures op manual gingen wanneer de auto werd ingeplugd. Iemand had dat hier al eens gedaan en de code laten zien. Ik heb die code weer als uitgangspunt genomen en met claude gespard om een en ander aan te passen. Zo heb ik er ook een handmatige planner ingebouwd. Ik heb nog geen dynamische tarieven maar nu kan ik vast oefenen. Mijn auto hoeft echt niet exact goedkope en dure uren te volgen en als hij eenmaal gaat laden mag hij het gewoon afmaken (is max 18kWh, meestal, een PHEV). Maar aan de hand van Gielz zie ik sowieso wanneer de dure en goedkope perioden zijn.

Tot nu toewerkt het feilloos. Maar je moet je wel wat verdiepen in hoe integraties werken, hoe je die installeert, waar je sensoren kunt vinden, bladiebladiebla. Maar: dat kan Claude je prima vertellen! Wees gewoon zo duidelijk mogelijk in je vraagstelling of opdracht. Komt goed, beetje durven! Het kost je wel wat avonduurtjes, ook omdat Claude in de gratis versie maar zoveel tijd per dag beschikbaar geeft...

[ Voor 5% gewijzigd door Gramser op 31-10-2026 14:46 ]

[BestevaerNL]

Gramser schreef op zaterdag 31 oktober 2026 @ 14:39:
Ja, ik heb ook een dashboardje gebouwd om mijn thuisbatterijen niet te laten botsen met de laadpaal. Ik wilde dat de zendures op manual gingen wanneer de auto werd ingeplugd. Iemand had dat hier al eens gedaan en de code laten zien. Ik heb die code weer als uitgangspunt genomen en met claude gespard om een en ander aan te passen. Zo heb ik er ook een handmatige planner ingebouwd. Ik heb nog geen dynamische tarieven maar nu kan ik vast oefenen. Mijn auto hoeft echt niet exact goedkope en dure uren te volgen en als hij eenmaal gaat laden mag hij het gewoon afmaken (is max 18kWh, meestal, een PHEV). Maar aan de hand van Gielz zie ik sowieso wanneer de dure en goedkope perioden zijn.

Tot nu toewerkt het feilloos. Maar je moet je wel wat verdiepen in hoe integraties werken, hoe je die installeert, waar je sensoren kunt vinden, bladiebladiebla. Maar: dat kan Claude je prima vertellen! Wees gewoon zo duidelijk mogelijk in je vraagstelling of opdracht. Komt goed, beetje durven!

Ik heb een combinatie van EVCC en EMHASS. Net zoals jij heb ik ingesteld dat de accu op smart charging springt als ik snel of gepland laad dmv evcc.

Verder regelt EMHASS alles met de accu en warmtepomp. Hij bepaald wanneer te laden, ontladen en verwarmen omdat hij elk kwartier bepaald wat de beste strategie is op basis van prijzen, thermische opslag in het huis. Verder houdt hij ook rekening met hoe snel je huis opwarmd of afkoelt.

Dit heb ik met Claude opgezet en er een dashboard coor gemaakt.

[ Voor 5% gewijzigd door BestevaerNL op 31-10-2026 14:49 ]

[jaroen89]

Manatwork schreef op zaterdag 31 oktober 2026 @ 11:24:
[...]

Het lijkt mij heel interessant maar ik heb werkelijk geen idee hoe ik dit met behulp van Claude voor elkaar zou moeten krijgen. Ik zie wel meer reacties waarin achteloos wordt gemeld dat er een automatisering of een dashboard is geknutseld mbv Claude maar hoe ze dat dan doen wordt er niet bij gezegd. Als iemand een link weet naar een how-to houd ik me aanbevolen.

ik gebruik bijv. de chrome plugin kun je direct dingen laten uitvoeren in je browser.

[Manatwork]

Nachtapotheker schreef op zaterdag 31 oktober 2026 @ 13:21:
[...]

Dat is ook lastig, je krijgt het ook niet met 1 prompt voor elkaar.

Ik ben een week bezig geweest (een uurtje per dag), elke dag resultaat bekijken en bijsturen, vragen stellen, proberen volledig te doorgronden wat de aanpak is en waarom. Ik gok dat ik straks in de lente/zomer als de verhouding verbruik/opwek totaal anders is weer wat moet bijsturen, maar voor nu werkt het top!

Het lijkt me heel leuk om hiermee te experimenteren maar is Claude free hiervoor voldoende om mee te beginnen of moet het per se een betaald abonnement zijn?

[Nachtapotheker]

Manatwork schreef op zaterdag 31 oktober 2026 @ 17:45:
[...]

Het lijkt me heel leuk om hiermee te experimenteren maar is Claude free hiervoor voldoende om mee te beginnen of moet het per se een betaald abonnement zijn?

De eerste paar dagen free gedaan, toen werd ik te enthousiast en wilde ik niet meer steeds 4u wachten tot ik door kon 😅

Met free gaat het functioneel zeker lukken, alleen regelmatig tokens op en wachten…

[ Voor 10% gewijzigd door Nachtapotheker op 31-10-2026 18:05 ]

[BestevaerNL]

Manatwork schreef op zaterdag 31 oktober 2026 @ 17:45:
[...]

Het lijkt me heel leuk om hiermee te experimenteren maar is Claude free hiervoor voldoende om mee te beginnen of moet het per se een betaald abonnement zijn?

Neem het een maandje en je komt een heeeel eind.

[Gramser]

Manatwork schreef op zaterdag 31 oktober 2026 @ 17:45:
[...]

Het lijkt me heel leuk om hiermee te experimenteren maar is Claude free hiervoor voldoende om mee te beginnen of moet het per se een betaald abonnement zijn?

Ik heb het met een gratis account voor mekaar.

[John2B]

Nog iemand geïnteresseerd in een Zendure connector?

Nee geen hele accu, maar ik moest hem ergens aan koppelen 🤣😂

v&a aangeboden: Zendure SolarFlow 3000 Mix AC+

[ Voor 15% gewijzigd door John2B op 31-10-2026 19:09 ]

[denneappel]

Manatwork schreef op zaterdag 31 oktober 2026 @ 17:45:
[...]

Het lijkt me heel leuk om hiermee te experimenteren maar is Claude free hiervoor voldoende om mee te beginnen of moet het per se een betaald abonnement zijn?

Ik betaal zelf voor Mistral. Hun Vibe code CLI heeft een ruimer budget en werkt ook prima. Geen 5 uurs budgetten meer dus je kunt op je zaterdag middag gewoon lekker door.

[ppaulv]

Ben toch te ongeduldig geweest en heb Omnibattery geïnstalleerd. Maar dat gaat 'm zo ook niet worden, zie plaatje van vanavond. Bijna stabiele vraag in huis, geen zon, en een heftig geflipper. Tot de minimale SOC bereikt was.

[oeps]

Heel vreemde situatie met mijn AC2400 Pro in combinatie met Gielz v20261007 (firmware 2.0.4)

Het werkt vrijwel altijd helemaal OK voor mij met 'Dynamic Trading + Smart Matching', maanden lang.

Gisterochtend stond de batterij op minimum SOC (10%) in stand-by. Tijdens de paar cheap kwartieren in de nacht had hij niet geladen.

Geen ramp, de prijzen zijn nu nogal vlak. Nu pas tijd om er even naar te kijken. Het relaas:

• Dynamic Trading + Smart Matching werkt niet (Batterij leeg, 'groene; kwartieren met voldoende spread gemist in de nacht).
• Reload Home Assistant: Geen verschil. Met de hand even wat cheap periods gezet maar start niet met laden.
• Wat ik meestal even doe als er iets geks is: De batterij even toevoegen aan HEMS in de Zendure App en na een paar seconden weer uit. Nu geen enkel effect.
• Modus naar Quick Charge: Gaat direct laden.
• Modus naar Manual en met 250 watt: Gaat direct laden met 250 watt.
• Modus naar Smart Matching (SOC was inmiddels weer boven 10% door Quick charge): Batterij gaat netjes nul op de meter doen.
• Modus weer naar Dynamic Trading + Smart Matching. Reageert niet op dat ik nu in een 'cheap' period zit (even handmatig gedaan met Ghh:mm).
• Modus naar: Dynamic trading: Gaat direct laden en reageert wel op Ghh:mm!!
• Modus weer naar Dynamic Trading + Smart Matching: Het lijkt weer te werken!! Reageert weer op de handmatig ingestelde cheap periode.

Ik zit nu in de schiet mij maar lek modus! Kromme bit? Iemand enig idee?

Omdat Gielz een package is kan ik niet even een reload doen van de integratie. Nu doe ik dan maar een herstart van HA. Is daar een elegantere manier voor?

[DRaakje]

Verse installatie van een Solarflow 2400 AC (8.64 kWh), is het normaal dat de log dit continue laat zien? (V202610007)

[ Voor 3% gewijzigd door DRaakje op 01-11-2026 09:07 ]

[Gyrolion]

ppaulv schreef op zaterdag 31 oktober 2026 @ 23:19:
Ben toch te ongeduldig geweest en heb Omnibattery geïnstalleerd. Maar dat gaat 'm zo ook niet worden, zie plaatje van vanavond. Bijna stabiele vraag in huis, geen zon, en een heftig geflipper. Tot de minimale SOC bereikt was.

[Afbeelding]

Dat is wel heel vreemd, bij mij regelt omnibattery gewoon strak. (AC2400+ met een Homewizard P1 meter via Homewizard Instant HAOS integratie)

Gebruikte je wel een P1 meting welke ieder seconden worden uitgelezen en doorgestuurd wordt naar Omnibattery?

Had je misschien een meter omgedraaid, dat deze een negatieve waarde doorstuurt maar omnibattery eigenlijk een positieve waarde wilt zien?

[ppaulv]

Gyrolion schreef op zondag 1 november 2026 @ 10:43:
[...]

Dat is wel heel vreemd, bij mij regelt omnibattery gewoon strak. (AC2400+ met een Homewizard P1 meter via Homewizard Instant HAOS integratie)

Gebruikte je wel een P1 meting welke ieder seconden worden uitgelezen en doorgestuurd wordt naar Omnibattery?

Had je misschien een meter omgedraaid, dat deze een negatieve waarde doorstuurt maar omnibattery eigenlijk een positieve waarde wilt zien?

nee ik heb een oude 4.2 meter die elke 10 sec data levert. Dat is zo te zien de oorzaak van dit gedrag.
Ik moet dus op zoek naar een manier om OB niet elke seconde maar elke 21 sec te laten werken (die p1 meter skipt er af en toe wel een, vandaar de 20+ timing).

[Gyrolion]

ppaulv schreef op zondag 1 november 2026 @ 10:49:
[...]

nee ik heb een oude 4.2 meter die elke 10 sec data levert. Dat is zo te zien de oorzaak van dit gedrag.
Ik moet dus op zoek naar een manier om OB niet elke seconde maar elke 21 sec te laten werken (die p1 meter skipt er af en toe wel een, vandaar de 20+ timing).

Dan kom je al bijna uit om aan de CT klemmen te gaan als je een stabiele batterij regeling wilt om te NOM'en.

[ppaulv]

ik probeer het eerst met de PD ontroller op 'very smooth' en deadband op 100W (eventueel hoger indien dit niet werkt). Dat is volgens AI de enige mogelijkheid, los van CT klemmen gaan kopen.

[ZuinigeRijder]

oeps schreef op zondag 1 november 2026 @ 07:46:
Heel vreemde situatie met mijn AC2400 Pro in combinatie met Gielz v20261007 (firmware 2.0.4)

Het werkt vrijwel altijd helemaal OK voor mij met 'Dynamic Trading + Smart Matching', maanden lang.

Gisterochtend stond de batterij op minimum SOC (10%) in stand-by. Tijdens de paar cheap kwartieren in de nacht had hij niet geladen.

Geen ramp, de prijzen zijn nu nogal vlak. Nu pas tijd om er even naar te kijken. Het relaas:

• Dynamic Trading + Smart Matching werkt niet (Batterij leeg, 'groene; kwartieren met voldoende spread gemist in de nacht).
• Reload Home Assistant: Geen verschil. Met de hand even wat cheap periods gezet maar start niet met laden.
• Wat ik meestal even doe als er iets geks is: De batterij even toevoegen aan HEMS in de Zendure App en na een paar seconden weer uit. Nu geen enkel effect.
• Modus naar Quick Charge: Gaat direct laden.
• Modus naar Manual en met 250 watt: Gaat direct laden met 250 watt.
• Modus naar Smart Matching (SOC was inmiddels weer boven 10% door Quick charge): Batterij gaat netjes nul op de meter doen.
• Modus weer naar Dynamic Trading + Smart Matching. Reageert niet op dat ik nu in een 'cheap' period zit (even handmatig gedaan met Ghh:mm).
• Modus naar: Dynamic trading: Gaat direct laden en reageert wel op Ghh:mm!!
• Modus weer naar Dynamic Trading + Smart Matching: Het lijkt weer te werken!! Reageert weer op de handmatig ingestelde cheap periode.

Ik zit nu in de schiet mij maar lek modus! Kromme bit? Iemand enig idee?

Omdat Gielz een package is kan ik niet even een reload doen van de integratie. Nu doe ik dan maar een herstart van HA. Is daar een elegantere manier voor?

Ik heb wel gemerkt, dat wanneer je of de duurste periodes op 0 zet of goedkoopste periodes op 0 zet, dat dynamisch handelen niet werkt. Soms wil je mogelijk alleen opladen op goedkoopste periodes, maar niet ontladen op duurste periodes, dat kan dus niet

[PASware]

Ik heb de Zendure Planner nu in Home Assistant, maar ik krijg het niet goed werkende. @Mediacj

Wat werkt wel
• De kaart is zichtbaar in HA
• Epex prijzen zichtbaar
• Ze officiele Zendure HA integration heb ik geinstalleerd

Wat werkt niet
De aansturing reageert nergens op. NOM/Laden, niks. Het leek even gewerkt te hebben met geforceerd laden, maar mijn 2400AC blijft in standby staan (op 20%)

Ik heb 'm NIET in HEMS staan!

Mijn settings van de planner zelf:

Operation select (NOM/off)	select.zendure_manager_operation
AC mode select (input/output)	select.solarflow_2400_ac_ac_mode
Laadvermogen (input_limit)	number.solarflow_2400_ac_input_limit
Ontlaadvermogen (output_limit)	number.solarflow_2400_ac_output_limit
Max SOC bij laden (soc_set)	number.solarflow_2400_ac_soc_set
Min SOC bij ontladen (min_soc)	number.solarflow_2400_ac_min_soc

Zendure HA manager settings:


Als ik de operation mode bijvoorbeeld op Manual power 500w zet, dan springt die even later weer naar Uit.



Als ik AC Input Limit en Output Limit de slider aanpas, naar in dit geval 2000w, blijft de waarde op 0 staan.

Hoe ziet de planner zelf uit?


Ik wil 'm nu forceren om met 1000w te laden, maar dat werkt niet (meer. heeft wel gewerkt). NOM doet ook niks (heeft ook nooit gewerkt)

[ Voor 11% gewijzigd door PASware op 01-11-2026 12:42 ]

[ben]

Ik ben al een paar maanden een tevreden gebruiker van de Gielz-integratie op mijn Home Assistant Green. Het valt me echter op dat deze integratie extreem veel schrijfacties uitvoert naar het logbestand/de database van HA.

Aangezien de HA Green is voorzien van eMMC-geheugen (wat gevoelig is voor slijtage), heeft dit mogelijk een negatieve invloed op de levensduur. Ik heb al geprobeerd om een deel van deze entiteiten uit te sluiten (exclude) van het loggen, maar daardoor werkt het Gielz-dashboard helaas niet meer naar behoren.

Is er een mogelijkheid om het aantal schrijfacties te beperken zonder dat de functionaliteit van het dashboard verloren gaat?

[Polvo176]

PASware schreef op zondag 1 november 2026 @ 12:34:
Ik heb de Zendure Planner nu in Home Assistant, maar ik krijg het niet goed werkende. @Mediacj

Wat werkt wel
• De kaart is zichtbaar in HA
• Epex prijzen zichtbaar
• Ze officiele Zendure HA integration heb ik geinstalleerd

Wat werkt niet
De aansturing reageert nergens op. NOM/Laden, niks. Het leek even gewerkt te hebben met geforceerd laden, maar mijn 2400AC blijft in standby staan (op 20%)

Ik heb 'm NIET in HEMS staan!

Mijn settings van de planner zelf:
[Afbeelding]

Operation select (NOM/off)	select.zendure_manager_operation
AC mode select (input/output)	select.solarflow_2400_ac_ac_mode
Laadvermogen (input_limit)	number.solarflow_2400_ac_input_limit
Ontlaadvermogen (output_limit)	number.solarflow_2400_ac_output_limit
Max SOC bij laden (soc_set)	number.solarflow_2400_ac_soc_set
Min SOC bij ontladen (min_soc)	number.solarflow_2400_ac_min_soc

Zendure HA manager settings:
[Afbeelding]

Als ik de operation mode bijvoorbeeld op Manual power 500w zet, dan springt die even later weer naar Uit.

[Afbeelding]

Als ik AC Input Limit en Output Limit de slider aanpas, naar in dit geval 2000w, blijft de waarde op 0 staan.

Hoe ziet de planner zelf uit?
[Afbeelding]

Ik wil 'm nu forceren om met 1000w te laden, maar dat werkt niet (meer. heeft wel gewerkt). NOM doet ook niks (heeft ook nooit gewerkt)

Ik zie dat je gewisseld hebt tussen cloud en Zensdk, zet hem op cloud en restart HA.
Dan zal het wel weer werken.
Zensdk werkt waarschijnlijk niet omdat je mogelijk een ip adres conflict hebt tussen HA zendure storage en jou router.
Dan blijft hij hangen, ook als je terug schakeld.
Is dan niet meer stuurbaar vanuit HA, wel vanuit de Zendure app in HEMS omdat die het ip adres van jou router gebruikt.

[Fire71]

ben schreef op zondag 1 november 2026 @ 13:22:
Ik ben al een paar maanden een tevreden gebruiker van de Gielz-integratie op mijn Home Assistant Green. Het valt me echter op dat deze integratie extreem veel schrijfacties uitvoert naar het logbestand/de database van HA.

Aangezien de HA Green is voorzien van eMMC-geheugen (wat gevoelig is voor slijtage), heeft dit mogelijk een negatieve invloed op de levensduur. Ik heb al geprobeerd om een deel van deze entiteiten uit te sluiten (exclude) van het loggen, maar daardoor werkt het Gielz-dashboard helaas niet meer naar behoren.

Is er een mogelijkheid om het aantal schrijfacties te beperken zonder dat de functionaliteit van het dashboard verloren gaat?[Afbeelding]

Mijn Home Assistant Green van vijf maanden oud geeft bij schijfstatistieken: levensduur 0% gebruikt.

Ik gebruik Gielz 5 maanden. Kan ik concluderen uit die 0% verbruik dat het wel meevalt met het aantal schrijfacties van Gielz/NR?

[ben]

Fire71 schreef op zondag 1 november 2026 @ 14:23:
[...]

Mijn Home Assistant Green van vijf maanden oud geeft bij schijfstatistieken: levensduur 0% gebruikt.

Ik gebruik Gielz 5 maanden. Kan ik concluderen uit die 0% verbruik dat het wel meevalt met het aantal schrijfacties van Gielz/NR?

De levensduur welke HA aan geeft gaan in stappen van 20 %, die van mij staat (na ruim 2 jaar) al op 60 %, de aangegeven counts in mijn eerder geplaatst overzicht zijn de (top 20) schrijfacties per entiteit van de afgelopen 7 dagen.

[ Voor 7% gewijzigd door ben op 01-11-2026 14:38 ]

[PASware]

Polvo176 schreef op zondag 1 november 2026 @ 13:50:
[...]

Ik zie dat je gewisseld hebt tussen cloud en Zensdk, zet hem op cloud en restart HA.
Dan zal het wel weer werken.
Zensdk werkt waarschijnlijk niet omdat je mogelijk een ip adres conflict hebt tussen HA zendure storage en jou router.
Dan blijft hij hangen, ook als je terug schakeld.
Is dan niet meer stuurbaar vanuit HA, wel vanuit de Zendure app in HEMS omdat die het ip adres van jou router gebruikt.

Dank! Het werkt al iets beter, AC Input en out limit tonen nu inderdaad waardes. Echter werkt NOM nog niet. Het enige wat lijkt te werken is "Laden" en "Ontladen". En daar lijkt die ook op te hangen als ik naar wat anders switch.

Voorbeeld: had op 2000w laden gezet, switch naar Slim-Ontladen en hij blijft met 2000w laden .

[oeps]

ZuinigeRijder schreef op zondag 1 november 2026 @ 11:41:
[...]


Ik heb wel gemerkt, dat wanneer je of de duurste periodes op 0 zet of goedkoopste periodes op 0 zet, dat dynamisch handelen niet werkt. Soms wil je mogelijk alleen opladen op goedkoopste periodes, maar niet ontladen op duurste periodes, dat kan dus niet

Ja klopt, vergeten erbij te zetten. Ik heb altijd minimaal 1 periode duur en goedkoop staan. Hopelijk kan dat in toekomst ook naar nu met de betekenis "Let niet op de spread (ont)laden maar op de geselecteerde tijdstippen)"

[Cardinal]

Ik heb wat vorderingen gemaakt met mijn planner gebasseerd op Gielz. Het meest complexe blijft de planner, daar heb ik al behoorlijk wat bugfixes op losgelaten, maar lijkt nu goed te werken. Hij legt ook zijn gehele plan uit.



De goedkoopste en duurste periodes doet hij niets mee is slechts dat ik beter kan zien wat goedkoop en duur is zodat ik het plan kan checken. Er zitten nog wat quircks in (zie pad-check vs plan morgen), maar dat komt de komende dagen wel.

Ook begonnen met een besparingsplanner, zodat ik wat inzicht kan krijgen in de kosten en terugverdientijd. Nu nog negatief, met dank aan de lage spread de laatste dagen



Mijn github is hier en details over de werking staan op de wiki. Note: installeer card-mod voor betere graphs, anders krijg je default HA graphs.

Volgende stap is op basis van het verbruikprofiel ervoor te zorgen dat de pad-check en planning beter zijn werkt doen en zich gaat basseren op uur en niet op dag. to be continued.

@Nachtapotheker kan je gebruiken als inspiratie, als je weer tokens hebt

[Nachtapotheker]

Cardinal schreef op zondag 1 november 2026 @ 16:37:
Ik heb wat vorderingen gemaakt met mijn planner gebasseerd op Gielz. Het meest complexe blijft de planner, daar heb ik al behoorlijk wat bugfixes op losgelaten, maar lijkt nu goed te werken. Hij legt ook zijn gehele plan uit.

[Afbeelding]

De goedkoopste en duurste periodes doet hij niets mee is slechts dat ik beter kan zien wat goedkoop en duur is zodat ik het plan kan checken. Er zitten nog wat quircks in (zie pad-check vs plan morgen), maar dat komt de komende dagen wel.

Ook begonnen met een besparingsplanner, zodat ik wat inzicht kan krijgen in de kosten en terugverdientijd. Nu nog negatief, met dank aan de lage spread de laatste dagen

[Afbeelding]

Mijn github is hier en details over de werking staan op de wiki. Note: installeer card-mod voor betere graphs, anders krijg je default HA graphs.

Volgende stap is op basis van het verbruikprofiel ervoor te zorgen dat de pad-check en planning beter zijn werkt doen en zich gaat basseren op uur en niet op dag. to be continued.

@Nachtapotheker kan je gebruiken als inspiratie, als je weer tokens hebt

Ga er zeker eens naar kijken. Mijn eigen planning werkt ook goed, misschien moet ik die ook eens in GitHub deelbaar maken.

Je bedoelt denk ik @Manatwork die was degene die zelf wat aan wilde gaan maken

[Mediacj]

PASware schreef op zondag 1 november 2026 @ 12:34:
Ik heb de Zendure Planner nu in Home Assistant, maar ik krijg het niet goed werkende. @Mediacj

Wat werkt wel
• De kaart is zichtbaar in HA
• Epex prijzen zichtbaar
• Ze officiele Zendure HA integration heb ik geinstalleerd

Wat werkt niet
De aansturing reageert nergens op. NOM/Laden, niks. Het leek even gewerkt te hebben met geforceerd laden, maar mijn 2400AC blijft in standby staan (op 20%)

Ik heb 'm NIET in HEMS staan!

Mijn settings van de planner zelf:
[Afbeelding]

Operation select (NOM/off)	select.zendure_manager_operation
AC mode select (input/output)	select.solarflow_2400_ac_ac_mode
Laadvermogen (input_limit)	number.solarflow_2400_ac_input_limit
Ontlaadvermogen (output_limit)	number.solarflow_2400_ac_output_limit
Max SOC bij laden (soc_set)	number.solarflow_2400_ac_soc_set
Min SOC bij ontladen (min_soc)	number.solarflow_2400_ac_min_soc

Zendure HA manager settings:
[Afbeelding]

Als ik de operation mode bijvoorbeeld op Manual power 500w zet, dan springt die even later weer naar Uit.

[Afbeelding]

Als ik AC Input Limit en Output Limit de slider aanpas, naar in dit geval 2000w, blijft de waarde op 0 staan.

Hoe ziet de planner zelf uit?
[Afbeelding]

Ik wil 'm nu forceren om met 1000w te laden, maar dat werkt niet (meer. heeft wel gewerkt). NOM doet ook niks (heeft ook nooit gewerkt)

Het lijkt binnen de Energienerds planner allemaal goed te staan, echter als je in de Zendure HA integratie het vermogen al niet goed kunt instellen gaat het waarschijnlijk binnen die integratie al fout.

Ik zou binnen de Zendure HA integratie de 'connection modus' op Zensdk zetten, die staat nu op Cloud zie ik.

[SamWjjchen]

Mediacj schreef op zondag 1 november 2026 @ 22:54:
[...]

Het lijkt binnen de Energienerds planner allemaal goed te staan, echter als je in de Zendure HA integratie het vermogen al niet goed kunt instellen gaat het waarschijnlijk binnen die integratie al fout.

Ik zou binnen de Zendure HA integratie de 'connection modus' op Zensdk zetten, die staat nu op Cloud zie ik.

Zijn er meer gebruikers die last hebben van de ZENSDK instelling (wegvallende verbindingen) ipv cloud?
Cloud optie werkt niet snel genoeg, vertraging +- 20 sec vertraging, waardoor er toch kleine stukken van het net wordt gebruik.
is dit oplossen met een Zendure ZENSDK update?

[R2D2]

SamWjjchen schreef op maandag 2 november 2026 @ 09:56:
[...]

Zijn er meer gebruikers die last hebben van de ZENSDK instelling (wegvallende verbindingen) ipv cloud?
Cloud optie werkt niet snel genoeg, vertraging +- 20 sec vertraging, waardoor er toch kleine stukken van het net wordt gebruik.
is dit oplossen met een Zendure ZENSDK update?

ZenSDK werkt hier zonder issues, accu pas 2 weken staan dus niet helemaal representatief.

Vertraging ga je hoe dan ook wel iets houden dus strak NOM gaat het nooit zijn maar ik zie de accu eigenlijk altijd vrij snel achter het "verbruik" aan hobbelen. Enige waar hij wat traag mee lijkt te zijn is het omschakelen van ontladen naar laden, helemaal als de accu in "idle" mode is gegaan.

Setup hier is de SolarFlow 4000 mix AC+, officieële Zendure Home Assistant integratie in smart matching mode. P1 meter is van Homewizard.

SMR versie van je slimme meter is overigens ook van belang, mijn oude slimme meter welke op versie 4.x draaide update hoe dan ook maar eens per 10s. Ik had het geluk dat Stedin hier net de week ervoor de meter kwam vervangen voor een nieuwe.

[ppaulv]

Gyrolion schreef op zondag 1 november 2026 @ 11:00:
[...]

Dan kom je al bijna uit om aan de CT klemmen te gaan als je een stabiele batterij regeling wilt om te NOM'en.

Hmmm ... heb nog steeds hoop dat Enexis een dezer dagen (weken,maanden,....) de meter komt vervangen (wat ze sowieso moeten doen vóór 2028 of zoiets?) en vind het wel een uitdaging. Frustrerend en ergerlijk, maar toch een uitdaging.
Wat ik nu vanmorgen heb gedaan is voorlopig geaccepteerd hebben dat Gielz&Gast777 niet willen werken omdat regelmatig de boel op rogue gaat en niet meer luistert en dat OB niet in staat is met een 4.2 meter te werken. Allemaal erg jammer.
Maar daarom heb ik nu (in docker) 2 HA's draaien met Gielz, wat best goed werkt, eentje voor iedere accu en m'n afwijkende P1 meter nog even aangepast met een vermenigvuldiging met 0.5
Dus beide accu's proberen nu de helft van de P1 waardes te compenseren (NoM).
Ben benieuwd of dat dat ergens nog fout zal gaan en zo ja hoe. Maar voor nu ziet het er best ok uit. (dat heb ik al vaker gezegd natuurlijk).

[Gramser]

Als het niet gaat zoals het moet, moet het maar zoals het gaat. Goed bezig @ppaulv

[Fire71]

ppaulv schreef op maandag 2 november 2026 @ 14:13:
[...]

Hmmm ... heb nog steeds hoop dat Enexis een dezer dagen (weken,maanden,....) de meter komt vervangen (wat ze sowieso moeten doen vóór 2028 of zoiets?) en vind het wel een uitdaging. Frustrerend en ergerlijk, maar toch een uitdaging.
Wat ik nu vanmorgen heb gedaan is voorlopig geaccepteerd hebben dat Gielz&Gast777 niet willen werken omdat regelmatig de boel op rogue gaat en niet meer luistert en dat OB niet in staat is met een 4.2 meter te werken. Allemaal erg jammer.
Maar daarom heb ik nu (in docker) 2 HA's draaien met Gielz, wat best goed werkt, eentje voor iedere accu en m'n afwijkende P1 meter nog even aangepast met een vermenigvuldiging met 0.5
Dus beide accu's proberen nu de helft van de P1 waardes te compenseren (NoM).
Ben benieuwd of dat dat ergens nog fout zal gaan en zo ja hoe. Maar voor nu ziet het er best ok uit. (dat heb ik al vaker gezegd natuurlijk).

Heb je in de automation.yaml van Gielz al eens gekeken waar de trigger tijd op staat? Standaard staat die op vijf seconde wat perfect is voor dsm 5 slimme meters, maar voor dsm 4.2 meters zou die op iets van 15 seconde moeten staan, als ik me dat goed herinner. Misschien helpt dat bij jou.

De relevante trigger staat op regel vier van automation.yaml:

alias: Zendure zenSDK (Gielz)

description: Configuratie Versie (v20261007)

triggers:

  - seconds: /5

[ppaulv]

Fire71 schreef op maandag 2 november 2026 @ 16:28:
[...]

Heb je in de automation.yaml van Gielz al eens gekeken waar de trigger tijd op staat? Standaard staat die op vijf seconde wat perfect is voor dsm 5 slimme meters, maar voor dsm 4.2 meters zou die op iets van 15 seconde moeten staan, als ik me dat goed herinner. Misschien helpt dat bij jou.

De relevante trigger staat op regel vier van automation.yaml:

alias: Zendure zenSDK (Gielz)

description: Configuratie Versie (v20261007)

triggers:

  - seconds: /5

absoluut. Dat is het voordeel van Gielz (dat je dat kunt aanpassen).
Maar de combinatie met NR / Gast777 proxy geeft problemen en werkt niet.

[Mistraller]

Fire71 schreef op maandag 2 november 2026 @ 16:28:
[...]

Heb je in de automation.yaml van Gielz al eens gekeken waar de trigger tijd op staat? Standaard staat die op vijf seconde wat perfect is voor dsm 5 slimme meters, maar voor dsm 4.2 meters zou die op iets van 15 seconde moeten staan, als ik me dat goed herinner. Misschien helpt dat bij jou.

De relevante trigger staat op regel vier van automation.yaml:

alias: Zendure zenSDK (Gielz)

description: Configuratie Versie (v20261007)

triggers:

  - seconds: /5

Dit heb ik juist niet gedaan. Stel, je verbruik verandert op moment X; het telegram bericht wordt op X+2 seconden verstuurd. Dan heb je het veranderde verbruiksbeeld slechts 1 seconde later dan een v5. Dan ga je toch niet nog eens 15 seconden wachten op de verwerking?

Het verschil tussen een v4 en v5 is dat het bericht MAX 9 seconden later aankomt (en dat wellicht spikes korter dan 10 seconden niet gezien worden).

Naar mijn idee is het niet erg dat Gielz triggert ook al is de P1 data onveranderd.

Ik heb ook een v4 hangen en ja, er is wel iets afwijking met NOM maar veel minder als ik bang voor was. Ik gebruik een FTDI kabel binnen home assistant waarmee de data binnen miliseconden beschikbaar is nadat de meter ze heeft verstuurd.

[ Voor 10% gewijzigd door Mistraller op 02-11-2026 16:51 ]

[ppaulv]

Mistraller schreef op maandag 2 november 2026 @ 16:46:
[...]

Dit heb ik juist niet gedaan. Stel, je verbruik verandert op moment X; het telegram bericht wordt op X+2 seconden verstuurd. Dan heb je het veranderde verbruiksbeeld slechts 1 seconde later dan een v5. Dan ga je toch niet nog eens 15 seconden wachten op de verwerking?

Het verschil tussen een v4 en v5 is dat het bericht MAX 9 seconden later aankomt (en dat wellicht spikes korter dan 10 seconden niet gezien worden).

Naar mijn idee is het niet erg dat Gielz triggert ook al is de P1 data onveranderd.

Ik heb ook een v4 hangen en ja, er is wel iets afwijking met NOM maar veel minder als ik bang voor was. Ik gebruik een FTDI kabel binnen home assistant waarmee de data binnen miliseconden beschikbaar is nadat de meter ze heeft verstuurd.

en hier heb jij nooit last van gehad?



Dat is alleen weg te krijgen afaik door òf de p1 meter sensor enorm te vertragen en beperken (en zelfs dan nog werkt het niet echt) òf de timing van Gielz op 21 plus zetten

[Mistraller]

ppaulv schreef op maandag 2 november 2026 @ 17:50:
[...]

en hier heb jij nooit last van gehad?

[Afbeelding]

Dat is alleen weg te krijgen afaik door òf de p1 meter sensor enorm te vertragen en beperken (en zelfs dan nog werkt het niet echt) òf de timing van Gielz op 21 plus zetten

Nee. Maar dit doet mij denken aan het Quooker probleem, waar je ook met een v5 niet volledig vanaf komt. (De puls om de quooker bij te warmen is al voorbij voor je accu teruglevert) Maar die puls wordt wel verwerkt dus dan is je verbruiker weg, maar begint je accu te leveren.
En dat zal je met een v4 zeker sterker zien. Oplossing: gebruik een smart plug om die verbruiker te meten, trek die waarde van je P1 af waardoor jouw HEMS blind wordt voor die verbruiker. Dat verbruik zal dus voortaan door het net geleverd worden en nooit door de accu.

Zoek even, dit is al vaker besproken hier.

[ Voor 23% gewijzigd door Mistraller op 02-11-2026 18:27 ]

[Ben(V)]

Dat is geen Quooker.
Een Quooker neem ongeveer elk half uur een vermogen van 2,2kW af gedurende 15 seconden.

Dat is een andere vreemde belasting die staat te pulseren.
Die pieken schieten zelfs boven de 3kW uit, kan dus een oven of een inductieplaat zijn of een combinatie daarvan.

Dit is met geen elke automatisering te compenseren, enkel een snellere p1 meting kan dat een beetje verbeteren, maar nooit helemaal.
Vergeet niet dat een Zendure voor elke verandering mininmaal 5 seconden nodig heeft.

De beste oplossing is wachten op een meter vervanging voor een DSMR 5 meter van je elektriciteit leverancier of een p1 meter met klemmen kopen.

[ Voor 44% gewijzigd door Ben(V) op 02-11-2026 18:40 ]

[mitsumark]

Ben(V) schreef op maandag 2 november 2026 @ 18:35:
Dat is geen Quooker.
Een Quooker neem ongeveer elk half uur een vermogen van 2,2kW af gedurende 15 seconden.

Mijn Itho "quooker" doet elk uur ~400W maar dan wat langer.


Dit lijkt mij ook geen boiler achtig apparaat, maar ik sluit het ook niet uit op basis van dit plaatje.

Dat is een andere vreemde belasting die staat te pulseren.
Die pieken schieten zelfs boven de 3kW uit, kan dus een oven of een inductieplaat zijn of een combinatie daarvan.

Een oven of inductieplaat zou hij toch wel weten?

[Pvdbogaard]

Ik had een probleem met mijn Gielz aansturing en ging over op HEMS. Monitor wel met HA. Ik zie nu een veel rustiger beeld, waarbij de snelle (te extreme) ups en downs zoals @ppaulv ook heeft niet meer aanwezig zijn. Deze pieken had ik ook in de nacht. Toch zag ik constant een sequentie van vullen en ontladen. En dan spontaan een patroon zoals ik nu met HEMS zie, om daarna weer "chaotisch" te worden. Ik ben mijn hele fase verdeling van de apparatuur etc etc in kaart aan het brengen maar vermoed dat het de vertraging van de Zendure aansturing gekoppeld met een SMR5.0 meter. Ik wil zo wie zo een extra groep laten aanleggen voor een (toekomstige) 2de Zendure en overweeg nu toch ook plaatsing van een CT meter om deze traagheid te reduceren.

[Ben(V)]

Je moet ook bedenken dat als je met HEMS werkt dit via de Cloud van Zendure gaat en dat geeft dus extra vertraging.
Een D(S)MR 5 meter is niet het probleem die levert elke seconde data, alleen DSMR 4 meters zijn een probleem die leveren maar elke 10 seconden data.

Sturen via HA in plaats van met HEMS is voor mij de beste weg en sterker nog ik heb de Zendure van het internet afgesloten met m'n firewall en doe alles lokaal, net als alle devices die via wifi werken.

Door de ontwikkelingen van AI wordt hacken steeds simpeler dus vind ik het verstandig alles lokaal te houden en zo min mogelijk wifi iot devices te gebruiken.

[dotcom87]

Ben(V) schreef op maandag 2 november 2026 @ 22:41:
Je moet ook bedenken dat als je met HEMS werkt dit via de Cloud van Zendure gaat en dat geeft dus extra vertraging.
Een D(S)MR 5 meter is niet het probleem die levert elke seconde data, alleen DSMR 4 meters zijn een probleem die leveren maar elke 10 seconden data.

Sturen via HA in plaats van met HEMS is voor mij de beste weg en sterker nog ik heb de Zendure van het internet afgesloten met m'n firewall en doe alles lokaal, net als alle devices die via wifi werken.

Door de ontwikkelingen van AI wordt hacken steeds simpeler dus vind ik het verstandig alles lokaal te houden en zo min mogelijk wifi iot devices te gebruiken.

Hoe handel je je firmware updates af? Want ik zie precies niet meteen een optie om dit lokaal te doen? Of geef je dan even kort internet access?

[testmanager]

dotcom87 schreef op dinsdag 3 november 2026 @ 06:13:
[...]

Hoe handel je je firmware updates af? Want ik zie precies niet meteen een optie om dit lokaal te doen? Of geef je dan even kort internet access?

Je kan periodiek lokaal je smartphone via bluetooth verbinden met je accu”(‘s) en zo een firmware-update doorvoeren (

[oeps]

Cardinal schreef op zondag 1 november 2026 @ 16:37:
Ik heb wat vorderingen gemaakt met mijn planner gebaseerd op Gielz. Het meest complexe blijft de planner, daar heb ik al behoorlijk wat bugfixes op losgelaten, maar lijkt nu goed te werken. Hij legt ook zijn gehele plan uit.

ff dubbelcheck: Als ik jouw planner yaml files installeer maar de extra modus in Gielz er niet bij zet, dan kan ik jouw planner voorlopig er naast draaien (uiteraard kan ik ook de extra modus in Gielz toevoegen maar niet gebruiken).

Zie ik dan wat over het hoofd?
(Ik ben inmiddels toe aan een planner en DAO, Emhass, Omnibattery, en jouw planner staan op mijn lijstje. Ik wil eerst in read-only mode proberen voor het on 'productie' gaat).

Inhoudelijke vraag:

Je gebruikt Solcast als zonnestroom voorspeller. Heeft het zin om Solcast Solar Enhanced vanuit HACS erbij te zetten (uitbreiding voor de Solcast add-on om voorspelling tegen actual aan te houden en er van te leren). Of gaat dat jouw mechanisme juist tegenwerken?

Dank je!

[John2B]

testmanager schreef op dinsdag 3 november 2026 @ 08:57:
[...]

Je kan periodiek lokaal je smartphone via bluetooth verbinden met je accu”(‘s) en zo een firmware-update doorvoeren (

Kan helaas niet via Bluetooth. Verbinden wel, maar updaten niet. Staat waarschuwing bij update.

[Wozmro]

Ben(V) schreef op maandag 2 november 2026 @ 22:41:
Je moet ook bedenken dat als je met HEMS werkt dit via de Cloud van Zendure gaat en dat geeft dus extra vertraging.
Een D(S)MR 5 meter is niet het probleem die levert elke seconde data, alleen DSMR 4 meters zijn een probleem die leveren maar elke 10 seconden data.

Sturen via HA in plaats van met HEMS is voor mij de beste weg en sterker nog ik heb de Zendure van het internet afgesloten met m'n firewall en doe alles lokaal, net als alle devices die via wifi werken.

Door de ontwikkelingen van AI wordt hacken steeds simpeler dus vind ik het verstandig alles lokaal te houden en zo min mogelijk wifi iot devices te gebruiken.

Ik ben net van hetzelfde idee. En heb er mij dit weekend wat mee bezig gehouden. Ik ben geen it'er maar wilde toch al wat meer basiskennis van cyber veiligheid. Google AI heeft het mij mooi uitgelegd 🙂

Van te voren: Zendure batterij, sma omvormer via de standaard internetmodem met standaard instellingen.

Nu alles via HA en extra routertje (tp-link AX55) met meer instelmogelijkheden wordt normaal vandaag geleverd. Alles dicht en lokaal gestuurd.

Risico is misschien niet supergroot (kan ik zelf moeilijk inschatten) maar ik heb geen zin in gedoe als bvb ransomware die mijn batterij, airco of pv blokkeert.

[Ben(V)]

dotcom87 schreef op dinsdag 3 november 2026 @ 06:13:
[...]

Hoe handel je je firmware updates af? Want ik zie precies niet meteen een optie om dit lokaal te doen? Of geef je dan even kort internet access?

Gewoon even de firewall rule uitzetten, updaten en rule weer aanzetten.
Het vervelende is dat Zendure nergens weergeeft of er een firmware update beschikbaar is en zelfs geen release notes publiceert.
Ik moet dus regelmatig even de batterij aan het internet hangen om te kijken of er een update beschikbaar is.

Overigens doe ik dat niet erg vaak.

[ppaulv]

Mistraller schreef op maandag 2 november 2026 @ 18:24:
[...]

Nee. Maar dit doet mij denken aan het Quooker probleem, waar je ook met een v5 niet volledig vanaf komt. (De puls om de quooker bij te warmen is al voorbij voor je accu teruglevert) Maar die puls wordt wel verwerkt dus dan is je verbruiker weg, maar begint je accu te leveren.
En dat zal je met een v4 zeker sterker zien. Oplossing: gebruik een smart plug om die verbruiker te meten, trek die waarde van je P1 af waardoor jouw HEMS blind wordt voor die verbruiker. Dat verbruik zal dus voortaan door het net geleverd worden en nooit door de accu.

Zoek even, dit is al vaker besproken hier.

Dat is bekend en enige tijd geleden geïmplementeerd. Dat is het probleem niet.
Het is puur dat de accu te laat reageert omdat de p1 waardes te laat binnen komen.
Tijdens het maken van het plaatje was er een stabiele vraag in huis, geen pulsvraag.
Dus ja, je hebt gelijk dat de pulsvraag een issue is maar eenvoudig op te lossen. En niet het probleem wat ik heb met OmniBattery.

[ppaulv]

Ben(V) schreef op maandag 2 november 2026 @ 18:35:
Dat is geen Quooker.
Een Quooker neem ongeveer elk half uur een vermogen van 2,2kW af gedurende 15 seconden.

Dat is een andere vreemde belasting die staat te pulseren.
Die pieken schieten zelfs boven de 3kW uit, kan dus een oven of een inductieplaat zijn of een combinatie daarvan.

Dit is met geen elke automatisering te compenseren, enkel een snellere p1 meting kan dat een beetje verbeteren, maar nooit helemaal.
Vergeet niet dat een Zendure voor elke verandering mininmaal 5 seconden nodig heeft.

De beste oplossing is wachten op een meter vervanging voor een DSMR 5 meter van je elektriciteit leverancier of een p1 meter met klemmen kopen.

Nope, helaas. Het is puur het pingelen van trage p1 tegenover accu. Op het moment van de grafiek was er geen stroomvraag va betekenis, en al helemaal geen pulsvraag.
Gielz handelt één accu prima af, na maanden pielen met instellingen en aanpassingen. Maar in combinatie met de proxy van Gast777 ging het fout (zie eerdere berichten). OB is niet 'te vertragen' en reageert veel te snel op de trage P1 meter waardes en levert het getoonde plaatje bij stabiele vraag. Kijk maar naar het einde van de slingerbeweging, dat is het moment dat ik OB op manual zette.
Op dit moment draai ik 2 separate HA's met identieke Gielz en dat werkt tot nu toe goed, even de dag met wat zonneschijn afwachten.
Niet ideaal, zou liever OB of Gielz + gast777 gebruiken maar dat kan dus niet.

[ Voor 25% gewijzigd door ppaulv op 03-11-2026 10:22 ]

[Mistraller]

Ben(V) schreef op dinsdag 3 november 2026 @ 10:09:
[...]

Gewoon even de firewall rule uitzetten, updaten en rule weer aanzetten.
Het vervelende is dat Zendure nergens weergeeft of er een firmware update beschikbaar is en zelfs geen release notes publiceert.
Ik moet dus regelmatig even de batterij aan het internet hangen om te kijken of er een update beschikbaar is.

Overigens doe ik dat niet erg vaak.

Don't fix if it ain't broke.

[Ben(V)]

ppaulv schreef op dinsdag 3 november 2026 @ 10:17:
[...]

Nope, helaas. Het is puur het pingelen van trage p1 tegenover accu. Op het moment van de grafiek was er geen stroomvraag va betekenis, en al helemaal geen pulsvraag.
Gielz handelt één accu prima af, na maanden pielen met instellingen en aanpassingen. Maar in combinatie met de proxy van Gast777 ging het fout (zie eerdere berichten). OB is niet 'te vertragen' en reageert veel te snel op de trage P1 meter waardes en levert het getoonde plaatje bij stabiele vraag. Kijk maar naar het einde van de slingerbeweging, dat is het moment dat ik OB op manual zette.
Op dit moment draai ik 2 separate HA's met identieke Gielz en dat werkt tot nu toe goed, even de dag met wat zonneschijn afwachten.
Niet ideaal, zou liever OB of Gielz + gast777 gebruiken maar dat kan dus niet.

Ik zie toch duidelijk pieken van je p1 meter van boven de 3kW die dan ineens weer wegvallen.

[Mistraller]

ppaulv schreef op dinsdag 3 november 2026 @ 10:17:
[...]

Nope, helaas. Het is puur het pingelen van trage p1 tegenover accu. Op het moment van de grafiek was er geen stroomvraag va betekenis, en al helemaal geen pulsvraag.
Gielz handelt één accu prima af, na maanden pielen met instellingen en aanpassingen. Maar in combinatie met de proxy van Gast777 ging het fout (zie eerdere berichten). OB is niet 'te vertragen' en reageert veel te snel op de trage P1 meter waardes en levert het getoonde plaatje bij stabiele vraag. Kijk maar naar het einde van de slingerbeweging, dat is het moment dat ik OB op manual zette.
Op dit moment draai ik 2 separate HA's met identieke Gielz en dat werkt tot nu toe goed, even de dag met wat zonneschijn afwachten.
Niet ideaal, zou liever OB of Gielz + gast777 gebruiken maar dat kan dus niet.

Zulke overshoots kan normaliter niet. Als er geen vraag is, maar jouw accu krijgt wel de opdracht om er bijv 2kW uit te gooien dan is er iets mis in je metingen. Dat heeft niks met de P1 snelheid te maken eerder met de meting ansich.
Ik draai met mijn Gielz+Gast + v4 meter + 2 zendures en dit geklapper heb ik werkelijk nog nooit gezien. Ik heb geen puls verbruikers in huis.
2x HA is waanzin want dan zet je de klassieke "2 kapiteins op een schip".

Zit het niet een een heel slechte wifi connectie naar je Zendures. Ook al een vrij veel besproken item hier. Als de connectie slecht is of wegvalt, dan gaan je accu's ook veel te traag reageren. Aansturen van de Zendures, zeker met een eigen HEMS begint bij een retestabiele wifi connectie.

[Tortelli]

Ik heb 3x de 2400AC+ met daarbij uitbreiding accu’s met een totale capaciteit van 24,48kWh. Werkt perfect in het Gielz systeem (in combinatie met 15,9kWp aan PV); vanaf het moment dat ik ze had tm september > 90% zelf voorzienend geweest, in oktober zat dit op 72%.

Dat feest is nu natuurlijk voorbij, nu de opwek flink daalt en mijn eigen verbruik (warmtepomp) alleen maar stijgt. Loop met het idee om richting de winter 1 of 2 accu sets uit te schakelen. Wat zou slim zijn: ze laden tot ~50% en vervolgens 1 of 2 ip adressen uit de proxy verwijderen?

Zag overigens dat Vattenfall (en waarschijnlijk meer partijen) TijdPrijs contract aanbieden waarbij de energie snachts een stuk goedkoper is. Dat zou in de winter best interessant kunnen zijn. Wamtepomp loopt voornamelijk in de nacht en de auto kan ik qua laden sturen wanneer ik wil.
Afhankelijk van het tariefverschil is de Zendure setup gebruiken dan nog wel interessant.

[ Voor 25% gewijzigd door Tortelli op 03-11-2026 11:02 ]

[ppaulv]

Mistraller schreef op dinsdag 3 november 2026 @ 10:54:
[...]

Zulke overshoots kan normaliter niet. Als er geen vraag is, maar jouw accu krijgt wel de opdracht om er bijv 2kW uit te gooien dan is er iets mis in je metingen. Dat heeft niks met de P1 snelheid te maken eerder met de meting ansich.
Ik draai met mijn Gielz+Gast + v4 meter + 2 zendures en dit geklapper heb ik werkelijk nog nooit gezien. Ik heb geen puls verbruikers in huis.
2x HA is waanzin want dan zet je de klassieke "2 kapiteins op een schip".

Zit het niet een een heel slechte wifi connectie naar je Zendures. Ook al een vrij veel besproken item hier. Als de connectie slecht is of wegvalt, dan gaan je accu's ook veel te traag reageren. Aansturen van de Zendures, zeker met een eigen HEMS begint bij een retestabiele wifi connectie.

Aan het eind van het geklapper zie je wat de echte vraag van het huis was en is. En dit is niet de eerste keer dat ik dit zag. Lijkt me afdoende bewijs dat het geklapper niet door een pulsvraag komt maar door de slechte samenwerking van trage P1 meter en (trage) accu.
En nee, elke HA/Gielz managed één accu. En ik gebruik een aangepaste P1 meter, namelijk de echte gedeeld door 2. En dat werkt prima zo te zien. Maar ik had niet verwacht deze uitvlucht nodig te hebben.
Dus nee, geen waanzin. Alleen twee separate accu-systemen en dat is jammer.
En nee, wifi geeft nauwelijks errors in de log van de router, zag ook een prima gedrag van Gielz + gast777 proxy, was er heel tevreden over, totdat een van de twee accu's, of allebei tegelijk, bevroren en nergens meer op reageerden. En dat was iedere keer op max ontladen of max opladen. Heel typisch. Gemiddeld gebeurde dat 1x per dag maar onvoorspelbaar.
Zie eerdere berichten daarover als je details wilt weten (en hoe ik dat kon oplossen).

[bigkevx2]

Ben(V) schreef op dinsdag 3 november 2026 @ 10:09:
[...]

Gewoon even de firewall rule uitzetten, updaten en rule weer aanzetten.
Het vervelende is dat Zendure nergens weergeeft of er een firmware update beschikbaar is en zelfs geen release notes publiceert.
Ik moet dus regelmatig even de batterij aan het internet hangen om te kijken of er een update beschikbaar is.

Overigens doe ik dat niet erg vaak.

Dat doet hij wel in de app, klein rood puntje bij je settings menu als je de batterij hebt geselecteerd.

[meesje]

bigkevx2 schreef op dinsdag 3 november 2026 @ 12:00:
[...]

Dat doet hij wel in de app, klein rood puntje bij je settings menu als je de batterij hebt geselecteerd.

Komt dat rode puntje ook tevoorschijn als je de firewall rule nog actief hebt?

[RemmyB83]

meesje schreef op dinsdag 3 november 2026 @ 12:03:
[...]

Komt dat rode puntje ook tevoorschijn als je de firewall rule nog actief hebt?

Ik heb de internettoegang van mijn batterijen ook geblokkeerd in de router.
Ik kan mijn verder ook niet herinneren dat na de eerste update van Zendure die het mogelijk maakte om hem volledig offline te gebruiken zonder andere poespas, dat ik online ben geweest met de batterijen en ik zie ook het rode balletje en de updates in de Zendureapp.