Zendure producten in Home Assistant integreren deel 2

[ZuinigeRijder]

@Jan-tweak Dan heb je NIET de Gielz installatie. De Gielz installatie moet niet via HACS geinstalleerd worden, maar handmatig volgens deze stappen:

https://github.com/Gielz1986/Zendure-HA-zenSDK

Ik denk dus dat je de ZenSDK geinstalleerd hebt.
https://github.com/Zendure/Zendure-HA

Daar heb ik geen ervaring mee.

[Jan-tweak]

ZuinigeRijder schreef op donderdag 9 juli 2026 @ 20:44:
@Jan-tweak Dan heb je NIET de Gielz installatie. De Gielz installatie moet niet via HACS geinstalleerd worden, maar handmatig volgens deze stappen:

https://github.com/Gielz1986/Zendure-HA-zenSDK

Ik denk dus dat je de ZenSDK geinstalleerd hebt.
https://github.com/Zendure/Zendure-HA


Daar heb ik geen ervaring mee.

bedankt voor de handleiding, ga ik direct lezen.
kun je die ook samen geinstalleerd hebben of is dat vragen om problemen ?

[ Voor 5% gewijzigd door Jan-tweak op 09-07-2026 20:48 ]

[Gramser]

Inderdaad wat gekkigheden in de app vanavond. Ook nog niet voorbij, maar gelukkig draait het onder Gielz gewoon goed.

[jelleeelco]

Vraagje, wat is nou het verschil tussen draaien met Gielz + Gast777 versus de Fireson integratie?

Ik heb nu drie ongelijke stapels (2 zodra Zendure de 2400AC ophaalt), en die stuur ik aan via Gielz met een aangepaste NodeRed van Gast777 zodat de stapels verschillend kunnen zijn. Wat zou een voordeel zijn om alles binnen Fireson te doen?

[geert1992]

jelleeelco schreef op vrijdag 10 juli 2026 @ 07:53:
Vraagje, wat is nou het verschil tussen draaien met Gielz + Gast777 versus de Fireson integratie?

Ik heb nu drie ongelijke stapels (2 zodra Zendure de 2400AC ophaalt), en die stuur ik aan via Gielz met een aangepaste NodeRed van Gast777 zodat de stapels verschillend kunnen zijn. Wat zou een voordeel zijn om alles binnen Fireson te doen?

Fireson heeft als voordeel dat je de integratie eenvoudig via HACS kunt installeren. Daarnaast biedt het meer sensoren, kun je gemakkelijk clusters maken met meerdere batterijen en is de verdeling van het vermogen over meerdere batterijstapels standaard ingebouwd, rekening houdend met de soc. Bovendien ondersteunt het de volledige Zendure productlijn.

De integratie van Gielz is daarentegen vooral gericht op 1 omvormer, waarvoor hij een uitstekende oplossing heeft ontwikkeld. Waar Gielz echt in uitblinkt, is een overzichtelijk dashboard en een strakkere NOM aansturing, waar je nog een aantal parameters kan aanpassen.

[g00gle]

Ben bezig met een tooltje dat je als tussenlaag kunt gebruiken. De HA-integratie van Gielz praat hiertegenaan, en deze tussenlaag praat vervolgens met meerdere accu's van verschillende capaciteiten. Je kunt er behoorlijk wat in instellen: hij verdeelt het vermogen slim en houdt rekening met diverse aspecten.
Ik had eerst naar de NodeRED-proxy gekeken die hier veel gebruikt wordt, maar daar miste ik toch wat functionaliteit. Even showen hoor:Ik ben er nog mee bezig: ik draai nu diverse simulaties (met Claude) en er moet nog flink getest en gebugfixt worden voordat ik 'm echt in productie ga gebruiken. Maar het begin is er.
Het is simpelweg een Docker-container die je op je eigen thuisserver kunt draaien. Hij ondersteunt de volledige API, en je hoeft letterlijk alleen het "adres" van je omvormer in HA aan te passen naar deze tussenlaag.

[Gramser]

Dat ziet er best sjiek uit zeg! Is in het Nederlands zie ik - zou dit ook werken met de Engelse Gielz? En wat doet dat met de gast777 proxy?

[raven22]

g00gle schreef op vrijdag 10 juli 2026 @ 10:31:
Ben bezig met een tooltje dat je als tussenlaag kunt gebruiken. De HA-integratie van Gielz praat hiertegenaan, en deze tussenlaag praat vervolgens met meerdere accu's van verschillende capaciteiten. Je kunt er behoorlijk wat in instellen: hij verdeelt het vermogen slim en houdt rekening met diverse aspecten.
Ik had eerst naar de NodeRED-proxy gekeken die hier veel gebruikt wordt, maar daar miste ik toch wat functionaliteit. Even showen hoor:

[Afbeelding]

[Afbeelding]

[Afbeelding]

Ik ben er nog mee bezig: ik draai nu diverse simulaties (met Claude) en er moet nog flink getest en gebugfixt worden voordat ik 'm echt in productie ga gebruiken. Maar het begin is er.
Het is simpelweg een Docker-container die je op je eigen thuisserver kunt draaien. Hij ondersteunt de volledige API, en je hoeft letterlijk alleen het "adres" van je omvormer in HA aan te passen naar deze tussenlaag.

fraai hoor, zit nog te wachten op uitbreiding van mijn zendure setup. Daarna heb ik zeker interesse om het te gebruiken

[g00gle]

Gramser schreef op vrijdag 10 juli 2026 @ 11:51:
Dat ziet er best sjiek uit zeg! Is in het Nederlands zie ik - zou dit ook werken met de Engelse Gielz? En wat doet dat met de gast777 proxy?

2 talig, is onafhankelijk van de taal van Gielz, de API calls die Gielz doet veranderen niet door de taal die je gebruikt. (Als dat wel zo is, heb ik nog wat te doen )

Het is een vervanging voor die proxy eigenlijk, was niet echt van plan dit breed te delen, puur omdat ik geen tijd heb om te troubleshooten / support te geven op m'n eigen hobby projectje. M'n git repo staat op private nu, maar die wil ik eventueel wel gaan delen als het goed werkt. We zullen dan wel zien waar het ons brengt vanaf dat moment. Wil overigens niemand hiermee voor het hoofd stoten, het is een beetje uit de hand gelopen hobby projectje waar ik in de vrije uurtjes mee bezig ben geweest. Maar vond het te tof om niet te delen
(Ik snapte maar weinig van de hele NodeRED boom die gebouwd is door @gast777 wat op zichzelf een knap staaltje werk is!)

[Gramser]

Voor mij zijn jullie allemaal sowieso een stelletje tovenaars dus als je het voor jezelf wil houden snap ik dat, maar dit ziet eruit als te mooi om niet te delen 🙂

[RemmyB83]

Gramser schreef op vrijdag 10 juli 2026 @ 12:39:
Voor mij zijn jullie allemaal sowieso een stelletje tovenaars dus als je het voor jezelf wil houden snap ik dat, maar dit ziet eruit als te mooi om niet te delen 🙂

Ik begrijp je enthousiasme, maar zou het zelf niet snel proberen. Voordeel van Gielz en Gast777 is de support en updates. Laatst ook na een update van Zendure, werden de bugs snel op gelost.
Het is niet erg als iemand iets deelt en het niet actief onderhoud, maar dan ben je als gebruiker wel aangewezen op jezelf om het bij problemen zelf op te lossen. En dat is voor mijn, met mijn gebrek aan kennis net een stapje te ver.

[Theetjuh]

@gielz even een vraagje, ik zag net dat het oplaadt vermogen steeds maar verder terugliep en opeens stonden de batterijen van zon 65-70% opeens op 100%
De inverter temperatuur stond op 40 graden, best hoog, normaliter komt deze niet boven de 35 graden.
Nu zie ik bij Calibrations, ik heb de engelse versie, dat deze 33 minuten geleden heeft gedraaid.
Op 1 juli was de laatste calibratie, maar sl ik naar de sensor 'Zendure Calibrating' kijkt, kom ik daar alleen No tegen, geen enkele keer Yes oid. Gaat er ergens iets mis dat je denkt?

edit:
Ik zie de batterijen nog wel op inbalanced staan

[ Voor 5% gewijzigd door Theetjuh op 10-07-2026 13:52 . Reden: inbalanced batterijen ]

[ppaulv]

Ik krijg (voor het eerst) een noodstop te zien :



En nu reageert ie nergens meer op. Is dat normaal gedrag of is er meer mis?

[Gramser]

RemmyB83 schreef op vrijdag 10 juli 2026 @ 13:15:
[...]

Ik begrijp je enthousiasme, maar zou het zelf niet snel proberen. Voordeel van Gielz en Gast777 is de support en updates. Laatst ook na een update van Zendure, werden de bugs snel op gelost.
Het is niet erg als iemand iets deelt en het niet actief onderhoud, maar dan ben je als gebruiker wel aangewezen op jezelf om het bij problemen zelf op te lossen. En dat is voor mijn, met mijn gebrek aan kennis net een stapje te ver.

Heel goed punt hoor - ik bedoelde ook niet zozeer voor mezelf, ik ben erg tevreden met G&G777. Hebben me al meermaals goed geholpen toen ik niet snapte wat ik verkeerd deed...

[Gramser]

Theetjuh schreef op vrijdag 10 juli 2026 @ 13:48:
@gielz even een vraagje, ik zag net dat het oplaadt vermogen steeds maar verder terugliep en opeens stonden de batterijen van zon 65-70% opeens op 100%
De inverter temperatuur stond op 40 graden, best hoog, normaliter komt deze niet boven de 35 graden.
Nu zie ik bij Calibrations, ik heb de engelse versie, dat deze 33 minuten geleden heeft gedraaid.
Op 1 juli was de laatste calibratie, maar sl ik naar de sensor 'Zendure Calibrating' kijkt, kom ik daar alleen No tegen, geen enkele keer Yes oid. Gaat er ergens iets mis dat je denkt?

edit:
Ik zie de batterijen nog wel op inbalanced staan

Die sensor staat alleen op Yes als kalibreren gaande is, meen ik.

[gast777]

ppaulv schreef op vrijdag 10 juli 2026 @ 13:55:
Ik krijg (voor het eerst) een noodstop te zien :

[Afbeelding]

En nu reageert ie nergens meer op. Is dat normaal gedrag of is er meer mis?

Dit betekent dat de P1 meter geen waarden meer heeft doorgegeven voor 1 minuut (zoals de melding ook vermeldt).

Aan de Gielz automation code te zien stopt hij dan met alles (noodstop) in het geval van deze modi, die de P1 metingen nodig hebben:

- Dynamisch NOM

- Dynamisch NOM (Duur)

- Dynamisch Handelen + NOM

- Alleen slim opladen

- Alleen slim ontladen

- Nul op de meter

Dus check je P1 meter of de netwerkverbinding daar naartoe.

[Theetjuh]

Gramser schreef op vrijdag 10 juli 2026 @ 14:03:
[...]

Die sensor staat alleen op Yes als kalibreren gaande is, meen ik.

Dat snap ik, maar als ik naar de status kijk van 1 juli tot nu, komt niet 1x Yes in voor, terwijl er dan al wel 2x gekalibreerd is.

[gast777]

Gramser schreef op vrijdag 10 juli 2026 @ 14:03:
[...]

Die sensor staat alleen op Yes als kalibreren gaande is, meen ik.

Ja die sensor geeft aan of geforceerd kalibreren gaande is(waarbij je geen controle over het apparaat meer hebt). In dit geval zal het normaal opladen geweest zijn, waarbij hij dus ook kalibreert bij de 100%, maar niet geforceerd.

[ppaulv]

gast777 schreef op vrijdag 10 juli 2026 @ 14:08:
[...]

Dit betekent dat de P1 meter geen waarden meer heeft doorgegeven voor 1 minuut (zoals de melding ook vermeldt).

Aan de Gielz automation code te zien stopt hij dan met alles (noodstop) in het geval van deze modi, die de P1 metingen nodig hebben:

- Dynamisch NOM

- Dynamisch NOM (Duur)

- Dynamisch Handelen + NOM

- Alleen slim opladen

- Alleen slim ontladen

- Nul op de meter

Dus check je P1 meter of de netwerkverbinding daar naartoe.

Ja sorry, dat is meteen hersteld. Alle p1 meetwaardes komen weer netjes binnen.
Maar de set wil niets meer doen. Heb 'handmatig' , 'slim opladen' en 'snel opladen' geselecteerd en afgewacht, maar hij blijft n op standby staan.
Geduld is een schone zaak ..... en HA helemaal opnieuw opstarten ook ...

[ Voor 6% gewijzigd door ppaulv op 10-07-2026 14:16 ]

[Theetjuh]

gast777 schreef op vrijdag 10 juli 2026 @ 14:10:
[...]

Ja die sensor geeft aan of geforceerd kalibreren gaande is(waarbij je geen controle over het apparaat meer hebt). In dit geval zal het normaal opladen geweest zijn, waarbij hij dus ook kalibreert bij de 100%, maar niet geforceerd.

Aahh dus dan zou ik normaliter nooit die waarde moeten zien, heb nog nooit handmatig gekalibreerd ... zou niet eens weten hoe

[gast777]

Theetjuh schreef op vrijdag 10 juli 2026 @ 14:16:
[...]

Aahh dus dan zou ik normaliter nooit die waarde moeten zien, heb nog nooit handmatig gekalibreerd ... zou niet eens weten hoe

De geforceerde kalibratie (geforceerd opladen naar 100% zonder dat je er iets tegen kunt doen) gebeurt automatisch als hij een maand niet de 100% heeft bereikt. Je kunt het niet zelf starten, maar dat wil je ook niet ;).

[ppaulv]

ppaulv schreef op donderdag 9 juli 2026 @ 20:04:
In het verlengde van de Quooker ..... ik heb een oven aanstaan die, nadat ie op temp is, voortdurend zo om de 30 seconden 1500W stroom pakt en dan weer wegvalt naar nul. M'n SF2400AC+ volgt dat dus niet, mede vanwege m'n DSRM 4.2 meter (om de 10 sec nieuwe waardes, als je geluk hebt, hij slaat er regelmatig eentje over).
De spike bij de Quooker is heel spits (kort) en er was een idee om het op te vangen door de gemeten waardes (Tuya stekker waar de Quooker stekker in zit) af te trekken van de P1 metingen.
Met die oven gaat dat niet echt en is ook niet handig als ie wèl langdurig stroom trekt.
Dus denk ik toch aan het voortschrijdend gemiddelde van zeg 3 meetwaardes van de P1.
Is dat een werkbaar en goed idee volgens jullie?

Ter info.
Ik ben dit gaan bouwen en testen (vandaar m'n vastlopertje vanochtend) en ben heel benieuwd of ik nu het geflipper bij quooker en ovens eruit heb gehaald.
En ja, alles reageert nu heel erg traag want op basis van voortschrijdend gemiddelde van 3 meetwaardes, maar mijn meetpunten zijn nu niet meer afhankelijk van de situatie op een bepaald moment maar op 3 momenten (die vanwege mijn MPRS 4.2 meter ieder 10 seconden uit elkaar liggen).
Het is dus absoluut onmogelijk om hiermee een strakke NOM te maken maar ik heb zo'n hekel aan flipper-gedrag van apparaten dat het me waard is, als het werkt.
Ik zal m'n resultaten melden zodra ik meer weet.
@gielz ik heb dus wel even iets in jouw code moeten wijzigen, namelijk bij het bepalen van de vermogens aansturing heb ik sensor.homewizard_p1_vermogen vervangen door mijn eigen input_number.p1_avg_3
Misschien is het een idee (feature request) om in jouw code ook een eigen input_number.p1_xxx te gebruiken die ergens anders (in het config dashboard) gevuld kan worden met een eigen entiteit (in mijn geval input_number.p1_avg_3) ?

[Do-m-pie]

Wilde toch even mijn ervaringen delen:
1) Zendure SolarFlow 2400 AC+
2) P1 meter Zendure
3) Landis Gyr+ E350 meter met DSMR 4.2 - model ZMF110CCtFs2
4) Gielz integratie in HA core opgezet, maar automatisering getweaked voor bovenstaande meter
- 21 seconden
- factor op 0.25 gezet i.p.v 0.75 (komt 4x voor in het script)
- P1 meter toegevoegd in HA volgens https://github.com/Gielz1986/Zendure-HA-zenSDK/wiki/Global-and-NL-%E2%80%90-P1-CT-meters-(API's)
Daarna onder "Configuration optional" => "Home Energy Meter Sensor
sensor.p1_zendure_api ingevuld
IP adres van P1 meter <<192.168.x.x>> onder Homewizzard P1 IP address ingevuld
5) In zendure_gielz1986_global.yaml de sectie op regel 2301 met resource_template: "http://{{ states('input_text.homewizard_setting_p1_ip_address') }}/api/v1/data" commented met #.
Kreeg anders veel meldingen in logs.

E.e.a. lijkt nu prima te werken.

[Kaaf]

ppaulv schreef op vrijdag 10 juli 2026 @ 14:26:
[...]

Ter info.
Ik ben dit gaan bouwen en testen (vandaar m'n vastlopertje vanochtend) en ben heel benieuwd of ik nu het geflipper bij quooker en ovens eruit heb gehaald.
En ja, alles reageert nu heel erg traag want op basis van voortschrijdend gemiddelde van 3 meetwaardes, maar mijn meetpunten zijn nu niet meer afhankelijk van de situatie op een bepaald moment maar op 3 momenten (die vanwege mijn MPRS 4.2 meter ieder 10 seconden uit elkaar liggen).
Het is dus absoluut onmogelijk om hiermee een strakke NOM te maken maar ik heb zo'n hekel aan flipper-gedrag van apparaten dat het me waard is, als het werkt.
Ik zal m'n resultaten melden zodra ik meer weet.
@gielz ik heb dus wel even iets in jouw code moeten wijzigen, namelijk bij het bepalen van de vermogens aansturing heb ik sensor.homewizard_p1_vermogen vervangen door mijn eigen input_number.p1_avg_3
Misschien is het een idee (feature request) om in jouw code ook een eigen input_number.p1_xxx te gebruiken die ergens anders (in het config dashboard) gevuld kan worden met een eigen entiteit (in mijn geval input_number.p1_avg_3) ?

ppaulv, je bent niet de enige hoor, ik hebeen DSMR 5 meter maar die is niet veel stabieler. De meeste apparaten doen dit eigenlijk (frituur/airfryer/oven/inductiekooplaat op laag vermogen). Ik merk dat ik vaak een handmatige waarde kortstondig instel, en die dan weer vergeet uit te zetten 8)7als ik dit soort dingen aan zet. Anders zijn er zo 100+ schakelingen van het relais. Maar handmatig dingen zetten wil je eigenlijk niet. Ik wacht je bevindingen af. En 100% NOM is toch een utopie

[gielz]

ppaulv schreef op vrijdag 10 juli 2026 @ 14:26:
[...]

Ter info.
Ik ben dit gaan bouwen en testen (vandaar m'n vastlopertje vanochtend) en ben heel benieuwd of ik nu het geflipper bij quooker en ovens eruit heb gehaald.
En ja, alles reageert nu heel erg traag want op basis van voortschrijdend gemiddelde van 3 meetwaardes, maar mijn meetpunten zijn nu niet meer afhankelijk van de situatie op een bepaald moment maar op 3 momenten (die vanwege mijn MPRS 4.2 meter ieder 10 seconden uit elkaar liggen).
Het is dus absoluut onmogelijk om hiermee een strakke NOM te maken maar ik heb zo'n hekel aan flipper-gedrag van apparaten dat het me waard is, als het werkt.
Ik zal m'n resultaten melden zodra ik meer weet.
@gielz ik heb dus wel even iets in jouw code moeten wijzigen, namelijk bij het bepalen van de vermogens aansturing heb ik sensor.homewizard_p1_vermogen vervangen door mijn eigen input_number.p1_avg_3
Misschien is het een idee (feature request) om in jouw code ook een eigen input_number.p1_xxx te gebruiken die ergens anders (in het config dashboard) gevuld kan worden met een eigen entiteit (in mijn geval input_number.p1_avg_3) ?

Dit zit er al een tijdje in en kun je vinden op het configuratie tabblad;

[ppaulv]

gielz schreef op vrijdag 10 juli 2026 @ 16:49:
[...]


Dit zit er al een tijdje in en kun je vinden op het configuratie tabblad;
[Afbeelding]

tandjes ...
Het woordje sensor heb ik niet geregistreerd, sorry ! Ga het meteen (morgen) uittesten, laat de boel nu even lopen zoals ie loopt. Heb geen plan vanavond nog een oven te gaan gebruiken maar voor de test zal ik 'm even aanslingeren.

[jelleeelco]

Gramser schreef op vrijdag 10 juli 2026 @ 12:39:
Voor mij zijn jullie allemaal sowieso een stelletje tovenaars dus als je het voor jezelf wil houden snap ik dat, maar dit ziet eruit als te mooi om niet te delen 🙂

Claude Code. Als je het kan bedenken, kan Claude het voor je bouwen

[Gramser]

Dat geloof ik meteen - maar jij hebt een abbootje

[ppaulv]

jelleeelco schreef op vrijdag 10 juli 2026 @ 19:47:
[...]

Claude Code. Als je het kan bedenken, kan Claude het voor je bouwen

Ik kreeg dinsdag een tip van een ex-collega. Zij hebben zeer goede ervaringen met het laten maken van een prototype/poc door chatgpt met als laatste opdracht het maken van een prompt voor Claude om het systeem (onderdeel) echt te bouwen.

Misschien heb je er iets aan

[g00gle]

jelleeelco schreef op vrijdag 10 juli 2026 @ 19:47:
[...]

Claude Code. Als je het kan bedenken, kan Claude het voor je bouwen

Hij kan veel, maar met alleen bedenken ben je er echt nog niet. Gaan toch best wat uurtjes inzitten om iets te bouwen wat echt goed werkt.

Om terug te komen op m'n post van eerder. Als ik tevreden ben en het werkt zoals ik verwacht zal ik de repo openbaar zetten en graag gebruik maken van alle tweakers hier die er interesse in hebben, om er een echt goed product van te maken waar iedereen plezier van kan hebben. Zonde om alleen voor mijzelf te houden! 👌

[gast777]

Even voor de Gielz + Proxy gebruikers met >6 battery packs: zojuist heb ik de Celbalans toegevoegd voor alle max 18 batterijen.

Om die te zien moet je de REST sensoren (HA_REST_proxy_sensors_NL, in de Gielz package toegevoegd) en de dashboard batterij sensors (dashboard_battery_sensors_NL) even opnieuw inplakken. Zowel de Nederlandse als Engelse versie is geupdated.

Voorbeeld:

[jelleeelco]

Gramser schreef op vrijdag 10 juli 2026 @ 21:01:
Dat geloof ik meteen - maar jij hebt een abbootje

2 tientjes in de maand... het geld meer dan waard. Ik zal je een heel simpel voorbeeld geven. Wij hebben thuis zonwering in het glas van Pellini (screenline). Dit is met een app te bedienen. Maar toen het allemaal net aangesloten was bleek dat de app alleen werkt als je op je eigen netwerk zit. Zelfs als je verbinding maakt via VPN doet hij niets. Pellini benaderd, en zeiden dat je thuis een telefoon (iOS) permanent aan moet hebben met de app open. Dan kun je via de webpage van de telefoon op afstand de screen lines bedienen. Complete waanzin qua design natuurlijk, maar er is gewoon geen oplossing beschikbaar.

Claude gevraagd. Die stelde voor een VM met Android en daar de app op laten draaien (als server). Helaas - de webserver is alleen voor de app van iOS ontwikkeld. Dus wat is er nu gebeurd?

1. VM met screenline app
2. Bediening via die app
3. Claude ging via SSH mijn server in en monitorde alle berichten die vanaf de app naar de control module in de meterkast werden gestuurd
4. Volledig LAN protocol reversed engineerd en een kant en klare node red in HA gezet, met dashboard etc.
5. Het kan nu volledig vanuit HA bediend worden zonder tussenkomst van een app.

En alles heeft hij zelf gedaan / voorgesteld. Het voelt als magic....

[Gramser]

Nou inderdaad… ik denk dat ik daar zelf te bescheten voor ben, om zo’n “controle” (die ik -toegegeven- nu ook al niet heb) weg te geven…

[jelleeelco]

ppaulv schreef op vrijdag 10 juli 2026 @ 23:46:
[...]

Ik kreeg dinsdag een tip van een ex-collega. Zij hebben zeer goede ervaringen met het laten maken van een prototype/poc door chatgpt met als laatste opdracht het maken van een prompt voor Claude om het systeem (onderdeel) echt te bouwen.

Misschien heb je er iets aan

Dank, ik ken deze tip. Tot nu toe niet nodig gehad maar ik weet dat prompts handiger kunnen

[Kaaf]

gielz schreef op vrijdag 10 juli 2026 @ 16:49:
[...]


Dit zit er al een tijdje in en kun je vinden op het configuratie tabblad;
[Afbeelding]

Ah, ik dacht dat is de rauwe data moest zijn. Blijkbaar kan het ook met een statistiek (mean). Bedankt voor het melden!

[ppaulv]

ppaulv schreef op vrijdag 10 juli 2026 @ 17:22:
[...]

tandjes ...
Het woordje sensor heb ik niet geregistreerd, sorry ! Ga het meteen (morgen) uittesten, laat de boel nu even lopen zoals ie loopt. Heb geen plan vanavond nog een oven te gaan gebruiken maar voor de test zal ik 'm even aanslingeren.

@gielz ik zit net te testen (zal nog proberen harde cijfers op papier te krijgen) maar ik denk te zien dat, ondanks dat ik nu gebruik maak van die afwijkende sensor, de aanpassingen van het opladen van de accu alleen reageert op de 'echte' P1 metingen en niet reageert op de gemiddelde_van_3 metingen.
Dit is bijvoorbeeld te zien als de laatste 3 metingen van de P1 zeg ongeveer -2500 W zijn (ht gemiddelde dus ook) en dan plotseling een oven (3000W of meer) aan gaat en de meest recente waarde naar 500W springt maar het gemiddelde dus nog op -1500W blijft staan.
Op dat moment (of vrij snel daarna) gaat mijn accu (bijna) in standby terwijl hij gewoon zou moeten blijven laden (want hij zou moeten kijken naar de -1500W).
Is dit uit eerdere testen niet gebleken (of heb je nooit eerder met zo'n gemiddelde getest)?

[gast777]

ppaulv schreef op zaterdag 11 juli 2026 @ 13:33:
[...]

@gielz ik zit net te testen (zal nog proberen harde cijfers op papier te krijgen) maar ik denk te zien dat, ondanks dat ik nu gebruik maak van die afwijkende sensor, de aanpassingen van het opladen van de accu alleen reageert op de 'echte' P1 metingen en niet reageert op de gemiddelde_van_3 metingen.
Dit is bijvoorbeeld te zien als de laatste 3 metingen van de P1 zeg ongeveer -2500 W zijn (ht gemiddelde dus ook) en dan plotseling een oven (3000W of meer) aan gaat en de meest recente waarde naar 500W springt maar het gemiddelde dus nog op -1500W blijft staan.
Op dat moment (of vrij snel daarna) gaat mijn accu (bijna) in standby terwijl hij gewoon zou moeten blijven laden (want hij zou moeten kijken naar de -1500W).
Is dit uit eerdere testen niet gebleken (of heb je nooit eerder met zo'n gemiddelde getest)?

Heb je het HomeWizard P1 IP-adres er nog in staan? Dan zou ik die even weghalen. Dan kan die ook niet meer ongewenst gebruikt worden.

[ppaulv]

gast777 schreef op zaterdag 11 juli 2026 @ 13:41:
[...]

Heb je het HomeWizard P1 IP-adres er nog in staan? Dan zou ik die even weghalen. Dan kan die ook niet meer ongewenst gebruikt worden.

zal ik dadeljk even doen, maar dan gaat er heeeeel veel mis in 'alles'.

[ppaulv]

Ik heb in een grafiek de import van de accu, de P1 power meeting en de avg berekening. Daar zie je dat de import niet wijzigt (rood kruis) als de average (door mij handmatig) van -2200W naar +110W gezet wordt.

[koboy]

ppaulv schreef op zaterdag 11 juli 2026 @ 13:46:
[...]

zal ik dadeljk even doen, maar dan gaat er heeeeel veel mis in 'alles'.

Jouw eigen code heeft dus als input de P1 waardes die Gielz ophaalt? Is er geen integratie voor de HW P1 meter, dan pak je die als basis, en kun je het IP adres van de HW Pq uit Gielz weghalen. Die stuurt nu waarschijnlijk nog de boel in de war.

[ppaulv]

koboy schreef op zaterdag 11 juli 2026 @ 13:53:
[...]

Jouw eigen code heeft dus als input de P1 waardes die Gielz ophaalt? Is er geen integratie voor de HW P1 meter, dan pak je die als basis, en kun je het IP adres van de HW Pq uit Gielz weghalen. Die stuurt nu waarschijnlijk nog de boel in de war.

Nou, ik wil bijna overal de 'echte' P1 waardes gebruiken behalve bij het aansturen van opladen/ontladen. Daar gaat het mis bij a) mijn 4.2 meter en b) spikes (quooker) of heel tijdelijke en vaak repeterende blokken (ovens).
Het leek nu met dat gemiddelde van de laatste drie waardes van de P1 (vermogen) waarde goed te gaan tot ik ontdekte dat ie bij het bijstellen van het laadniveau niet kijkt naar dat gemiddelde maar naar de oorspronkelijke P1 waarde. Ik ben er nog niet echt diep in gedoken maar dat zou imho dus niet kloppen.

[ppaulv]

@gielz ik heb gevonden waardoor dat komt. Jij controleert of de tekst die wordt ingetypt voor die afwijkende sensor wel daadwerkelijk met de tekst 'sensor.' begint. En dat is in mijn geval dus niet zo. Daarom heb ik dat een beetje aangepast en werkt het nu wèl.
De aanpassing : regex_match('^(sensor|input_number)\\..+')
binnen het blok voor P1_Aansturing_Vermogen (2 keer).
Ik test nog even door met verschillende trigger tijden e.d.

[Pimmetje651]

Vandaag een begonnen met prullen om mijn Solarflow 800 Plus in homeassistant te koppel en meteen daarbij de Gielz oplossing in te zetten. Nu heb ik inmiddels de batterij zichtbaar,en kan vanalles intellen daarin.Op dit moment heb ik geen Homewizard P1 dongle, maar maak gebruik van OF ESPhome met DSRM,of eventueel een directe via USB gekoppelde DSRM reader oplossing. Heeft iemand 1 van bovenstaande oplossingen al werkende ? Had nu om te proberen het IP adres van het ESPHome device waar DSRM op draait en werkt, maar dan lijkt er weinig te gebeuren. Overigens nu nog een DSRM 4 meter (komt in aug versie 5 ), en nog geen dynamisch contract (van de Bron).

[Pimmetje651]

Theetjuh schreef op dinsdag 26 mei 2026 @ 15:25:
Vraagje, ik ben op het moment de @gielz integratie aan het inrichten, ik heb het IP al toegevoegd, maar ik zit nu nog even met de P1 meter.
Ik maak hierbij gebruik van een ESPHome en dit product van Zuidwijk: https://www.zuidwijk.com/product/p1-reader-ethernet/

Hierbij heb ik 2 entities, hoe kan ik dat integreren in de enkele entitie 'home_energy_setting_meter_sensor'?:

• sensor.p1_port_power_produced
• sensor.p1_port_power_consumed

Dit kunnen oplossen? Zo ja hoe aangezien ik met een soortgelijke P1 lezer werk

[Theetjuh]

Pimmetje651 schreef op zaterdag 11 juli 2026 @ 16:10:
[...]

Dit kunnen oplossen? Zo ja hoe aangezien ik met een soortgelijke P1 lezer werk

Zeker, zie het antwoord: Theetjuh in "Zendure producten in Home Assistant integreren deel 2"

edit:
stond er direct onder btw

[ Voor 6% gewijzigd door Theetjuh op 11-07-2026 16:49 ]

[ppaulv]

Update. Het gedrag van de accu is al wat rustiger maar nog steedszie ik teveel flippergedrag. Dit zijn denk i kde mometen dat de airco een korte periode veel stroom vraagt en dat moet beter kunnen.
Wordt vervolgd.

[Do-m-pie]

Zojuist de Youless P1 meter met firmware 1.6.4-PO in de Gielz integratie aan de praat gekregen.

Sensor toevoegen aan configuration.yaml van Home Assistant

rest:
 -  resource: http://192.168.1.111/a?f=j
    scan_interval: 1
    sensor:
    - name: "P1 Youless API"
      value_template: "{{ value_json.pwr | float }}"
      unique_id: P1_Youless_API
      unit_of_measurement: "W"
      device_class: power
      state_class: measurement

Werkt ook goed met Zendure SolarFlow 2400 AC+ thuisbatterij, dus ik heb een Zendure P1 meter in de aanbieding :-)

[gielz]

ppaulv schreef op zaterdag 11 juli 2026 @ 15:42:
@gielz ik heb gevonden waardoor dat komt. Jij controleert of de tekst die wordt ingetypt voor die afwijkende sensor wel daadwerkelijk met de tekst 'sensor.' begint. En dat is in mijn geval dus niet zo. Daarom heb ik dat een beetje aangepast en werkt het nu wèl.
De aanpassing : regex_match('^(sensor|input_number)\\..+')
binnen het blok voor P1_Aansturing_Vermogen (2 keer).
Ik test nog even door met verschillende trigger tijden e.d.

Input_number als P1 gebruiken is niet handig. Je gebruikt hier een template sensor helper of een filter sensor helper voor die het volledig direct zelf berekend.

[ppaulv]

gielz schreef op zondag 12 juli 2026 @ 08:04:
[...]


Input_number als P1 gebruiken is niet handig. Je gebruikt hier een template sensor helper of een filter sensor helper voor die het volledig direct zelf berekend.

Het is ook een helper die automatisch berekend wordt. Is zeker nog niet ideaal nu maar ik ben er mee bezig.

[gielz]

Gielz release V20260712

English (Global)

⚠️ Please make sure to use the correct language update. ⚠️
This release focuses on a number of small dashboard improvements and includes the changes required for the upcoming end of the Dutch net metering scheme ("saldering"). As of 2027, users with a dynamic energy contract will no longer receive a tax refund on electricity exported to the grid, so I've added support for this with the new export correction setting. As always, I've also fixed a number of bugs reported by users.

Dashboard

Energy Graph (Live)
The 'Start Charging' and 'Start Discharging' legend items have been removed, allowing the hover functionality to work correctly again. You can now filter out the home energy meter, so that only the battery data is displayed.

Dynamic Charts
Both charts now take the export correction into account when a period is selected as a discharge/expensive period.

Dynamic and PV Settings
These settings are now hidden when PV and/or Dynamic is disabled, keeping the dashboard cleaner and only showing relevant options.

New Features

Dynamic Export Correction
Dutch users can now set an export correction between €0.000 and €0.200 per kWh. From 2027, you will no longer receive a tax refund for electricity exported to the grid.

Offgrid from Grid
When using the offgrid outlet while the battery is connected to the grid, the outlet would normally draw power from the battery. It will now draw power directly from the grid whenever possible.

Bug Fixes

Dynamic Trading + Smart Matching
When SOC protection was enabled, this mode did not use it, preventing NOM from starting.

Dynamic Cycle (Charging/Discharging)
The cycle did not always end correctly, resulting in unintended additional charging/discharging.

Dynamic Cycle (Charging)
The cycle did not always end correctly when the maximum state of charge was set below 100%.

Dutch (NL)

⚠️ Zorg ervoor dat je de juiste taalupdate gebruikt. ⚠️
Deze release staat in het teken van kleine verbeteringen in het dashboard en bevat de wijzigingen die noodzakelijk zijn zodra de salderingsregeling in Nederland stopt. Vanaf 2027 ontvang je bij een dynamisch energiecontract geen belastingteruggave meer over stroom die je teruglevert aan het net. Hiervoor heb ik de nieuwe exportcorrectie toegevoegd. Uiteraard heb ik ook weer een aantal bugs opgelost die door gebruikers zijn gemeld.

Dashboard

Energiegrafiek (live)
De legenda-items 'Start ontladen' en 'Start opladen' zijn verwijderd, waardoor de mouse-overfunctie weer correct werkt. Vanaf nu kun je de energiemeter uitfilteren, zodat alleen de batterijgegevens worden weergegeven.

Dynamische Grafieken
Beide grafieken houden nu rekening met de exportcorrectie wanneer een periode als ontlaad-/dure periode is geselecteerd.

Dynamische en PV-instellingen
Deze instellingen worden verborgen wanneer PV en/of Dynamisch is uitgeschakeld, zodat het dashboard overzichtelijk blijft en alleen relevante opties worden weergegeven.

Nieuwe functies

Dynamische Exportcorrectie
Nederlandse gebruikers kunnen nu een exportcorrectie instellen tussen €0,000 en €0,200 per kWh. Vanaf 2027 ontvang je geen belastingteruggave meer voor elektriciteit die je teruglevert aan het net.


Offgrid vanaf het Net
Wanneer je het offgrid-stopcontact gebruikt terwijl de batterij is aangesloten op het elektriciteitsnet, werd het stopcontact meestal gevoed vanuit de batterij. Vanaf nu wordt het, wanneer mogelijk, rechtstreeks vanuit het elektriciteitsnet gevoed.

Bugfixes

Dynamisch Handelen + NOM
Wanneer SOC-bescherming was ingeschakeld, werd deze in deze modus niet gebruikt, waardoor NOM niet kon starten.

Dynamische Cyclus (Laden/Ontladen)
De cyclus werd niet altijd correct beëindigd, waardoor onbedoeld extra werd geladen of ontladen.

Dynamische Cyclus (Laden)
De cyclus werd niet altijd correct beëindigd wanneer het maximale laadpercentage onder de 100% was ingesteld.

[Gramser]

Dat ziet eruit als een mooie update @gielz ! Chapeau! Na m’n vakantie maar eens installeren (betekent geloof ik ook weer de proxy van @gast777 opnieuw deployen en instellen).

Oh ja en de offgridstopcontacten opnieuw instellen. Laat ik maar even een goede backup maken want het draait erg prettig nu.

[ Voor 26% gewijzigd door Gramser op 12-07-2026 10:57 ]

[Pimmetje651]

gielz schreef op zondag 12 juli 2026 @ 10:06:

Gielz release V20260712

English (Global)

⚠️ Please make sure to use the correct language update. ⚠️
This release focuses on a number of small dashboard improvements and includes the changes required for the upcoming end of the Dutch net metering scheme ("saldering"). As of 2027, users with a dynamic energy contract will no longer receive a tax refund on electricity exported to the grid, so I've added support for this with the new export correction setting. As always, I've also fixed a number of bugs reported by users.

Dashboard

Energy Graph (Live)
The 'Start Charging' and 'Start Discharging' legend items have been removed, allowing the hover functionality to work correctly again. You can now filter out the home energy meter, so that only the battery data is displayed.

Dynamic Charts
Both charts now take the export correction into account when a period is selected as a discharge/expensive period.

Dynamic and PV Settings
These settings are now hidden when PV and/or Dynamic is disabled, keeping the dashboard cleaner and only showing relevant options.

New Features

Dynamic Export Correction
Dutch users can now set an export correction between €0.000 and €0.200 per kWh. From 2027, you will no longer receive a tax refund for electricity exported to the grid.

Offgrid from Grid
When using the offgrid outlet while the battery is connected to the grid, the outlet would normally draw power from the battery. It will now draw power directly from the grid whenever possible.

Bug Fixes

Dynamic Trading + Smart Matching
When SOC protection was enabled, this mode did not use it, preventing NOM from starting.

Dynamic Cycle (Charging/Discharging)
The cycle did not always end correctly, resulting in unintended additional charging/discharging.

Dynamic Cycle (Charging)
The cycle did not always end correctly when the maximum state of charge was set below 100%.

Dutch (NL)

⚠️ Zorg ervoor dat je de juiste taalupdate gebruikt. ⚠️
Deze release staat in het teken van kleine verbeteringen in het dashboard en bevat de wijzigingen die noodzakelijk zijn zodra de salderingsregeling in Nederland stopt. Vanaf 2027 ontvang je bij een dynamisch energiecontract geen belastingteruggave meer over stroom die je teruglevert aan het net. Hiervoor heb ik de nieuwe exportcorrectie toegevoegd. Uiteraard heb ik ook weer een aantal bugs opgelost die door gebruikers zijn gemeld.

Dashboard

Energiegrafiek (live)
De legenda-items 'Start ontladen' en 'Start opladen' zijn verwijderd, waardoor de mouse-overfunctie weer correct werkt. Vanaf nu kun je de energiemeter uitfilteren, zodat alleen de batterijgegevens worden weergegeven.

Dynamische Grafieken
Beide grafieken houden nu rekening met de exportcorrectie wanneer een periode als ontlaad-/dure periode is geselecteerd.

Dynamische en PV-instellingen
Deze instellingen worden verborgen wanneer PV en/of Dynamisch is uitgeschakeld, zodat het dashboard overzichtelijk blijft en alleen relevante opties worden weergegeven.

Nieuwe functies

Dynamische Exportcorrectie
Nederlandse gebruikers kunnen nu een exportcorrectie instellen tussen €0,000 en €0,200 per kWh. Vanaf 2027 ontvang je geen belastingteruggave meer voor elektriciteit die je teruglevert aan het net.
[Afbeelding]

Offgrid vanaf het Net
Wanneer je het offgrid-stopcontact gebruikt terwijl de batterij is aangesloten op het elektriciteitsnet, werd het stopcontact meestal gevoed vanuit de batterij. Vanaf nu wordt het, wanneer mogelijk, rechtstreeks vanuit het elektriciteitsnet gevoed.

Bugfixes

Dynamisch Handelen + NOM
Wanneer SOC-bescherming was ingeschakeld, werd deze in deze modus niet gebruikt, waardoor NOM niet kon starten.

Dynamische Cyclus (Laden/Ontladen)
De cyclus werd niet altijd correct beëindigd, waardoor onbedoeld extra werd geladen of ontladen.

Dynamische Cyclus (Laden)
De cyclus werd niet altijd correct beëindigd wanneer het maximale laadpercentage onder de 100% was ingesteld.

Ben ik gek, zoek mezelf suf maar is er een update knop of dergelijke?

[ppaulv]

Update. Het lijkt erop datde quooker spikes netjes genegeerd worden. Ik zie regelmatige spikes en weet redelijk zeker dat die van de quooker zijn.
Heb nu de Gielz timer 'uit' gezet (op 50 seconden) maar een trigger voor verandering in waarde (state) van mijn gemiddelde over 3 waardes toegevoegd. En die wordt getriggerd door veranderingen in waarde van sensor.homewizard_p1_vermogen omdat die elke 10 sec wordt doorgegeven maar ook regematig een 'zending' overslaat.
Dus pas als ik een nieuwe P1 vermogens waarde binnen krijg wordt het gemiddelde opnieuw berekend en daardoor wordt de Gielz getriggerd.
Please comment ...

[Pakhaas]

Gramser schreef op zondag 12 juli 2026 @ 10:50:
Dat ziet eruit als een mooie update @gielz ! Chapeau! Na m’n vakantie maar eens installeren (betekent geloof ik ook weer de proxy van @gast777 opnieuw deployen en instellen).

Dat hoeft niet. Enkel het proxy adres weer opnieuw in het dashboard zetten.

[Gramser]

Bedoel je de ip-adressen in de proxy (nog steeds beginner hier he)? En de sensoren van gast777…? Daar ook weer iets mee doen?

Ik heb altijd het idee dat ik een hele nieuwe installatie aan het doen ben…

[Pakhaas]

Gramser schreef op zondag 12 juli 2026 @ 11:41:
Bedoel je de ip-adressen in de proxy (nog steeds beginner hier he)? En de sensoren van gast777…? Daar ook weer iets mee doen?

Ik heb altijd het idee dat ik een hele nieuwe installatie aan het doen ben…

Nee in de proxy doe je niks. Het adres naar de proxy moet weer in Gielz. De proxy sensors moet je wel even opnieuw in Gielz zetten.

[Gramser]

En eeeehhh… waar vind ik het adres naar de proxy..? #durftevragen 😬

[Pakhaas]

Gramser schreef op zondag 12 juli 2026 @ 12:53:
En eeeehhh… waar vind ik het adres naar de proxy..? #durftevragen 😬

Als goed is staat die nu al ingevuld. Even opslaan en later terugplaatsen.

[Gramser]

Oh die!! Thanks. Dat helpt!

[Maarten60]

Gramser schreef op zondag 12 juli 2026 @ 12:53:
En eeeehhh… waar vind ik het adres naar de proxy..? #durftevragen 😬

Er is geen update knop. Je moet feitelijk de installatie procedure opnieuw volgen. Behalve dat je instellingen behouden blijven.
Let op, als je de gast777 proxy gebruikt moet je opnieuw de sensoren bij Gielz toevoegen. (Conform gast777 procedure)
De proxy instelling staat op de gielz instellingen tab (tandwiel) onder Configuratie basis en dan veld zendure 2400 ip adres. Je huidige waarde wordt automatisch overgenomen. Voorbeeld ip adres 192.168.x.y of localhost:1880/endpoint bij gebruik proxy
Dus
1) zensdk downloaden (voorkeur package), en evt gast777 sensoren toevoegen
2) automatisering downloaden en installeren
3) dashboard downloaden en installeren
4) ha restart.
Ten overvloede, let op de correcte taal

[Gramser]

Ah eigenlijk is dat ook wel wat ik tot nu toe steeds deed - ik eist dat er geen updateknop was maar goed dat ik dan niet de hele proxy ook weer moet installeren. Wel de offgridswitches dus.

Komt vast goed 👌🏻

[gast777]

Gramser schreef op zondag 12 juli 2026 @ 13:24:
Ah eigenlijk is dat ook wel wat ik tot nu toe steeds deed - ik eist dat er geen updateknop was maar goed dat ik dan niet de hele proxy ook weer moet installeren. Wel de offgridswitches dus.

Komt vast goed 👌🏻

Als je de offgrid switches van de proxy gebruikt, staan die als het goed is in een apart package. Die blijven gewoon staan en hoef je niets aan te veranderen als je Gielz of de Proxy update.

Edit: wel het dashboard uiteraard als je ze op het Gielz dashboard erbij hebt gezet. Zelf heb ik alle proxy specifieke sensoren/schakelaars op een apart dashboard. Dan is de Gielz update even 5 minuten en klaar.

[ Voor 14% gewijzigd door gast777 op 12-07-2026 14:46 ]

[Gramser]

gast777 schreef op zondag 12 juli 2026 @ 14:42:
[...]

Als je de offgrid switches van de proxy gebruikt, staan die als het goed is in een apart package. Die blijven gewoon staan en hoef je niets aan te veranderen als je Gielz of de Proxy update.

Gekke is dat ik ze niet meer terug zie in het dashboard, waar ik ze wel zichtbaar had, met een knop om ze aan en uit te kunnen zetten. Ik heb werkelijk waar geen idee meer hoe ik die weer zichtbaar en werkend krijg, dus daar ben ik nu mee aan het pielen. De rest van het updaten is alvast weer gelukt gelukkig.

[gast777]

Gramser schreef op zondag 12 juli 2026 @ 14:46:
[...]

Gekke is dat ik ze niet meer terug zie in het dashboard, waar ik ze wel zichtbaar had, met een knop om ze aan en uit te kunnen zetten. Ik heb werkelijk waar geen idee meer hoe ik die weer zichtbaar en werkend krijg, dus daar ben ik nu mee aan het pielen. De rest van het updaten is alvast weer gelukt gelukkig.

Als je ze op het Gielz dashboard had staan die je vervangen hebt, dan moet je inderdaad weer "de schakelaars switch.zendure_X_offgrid_socket op je dashboard plaatsen en eventueel de algemene offgrid schakelaar switch.zendure_offgrid_socket, die alle schakelaars tegelijk schakelt."

[Gramser]

gast777 schreef op zondag 12 juli 2026 @ 14:47:
[...]

Als je ze op het Gielz dashboard had staan die je vervangen hebt, dan moet je inderdaad "de schakelaars switch.zendure_X_offgrid_socket op je dashboard plaatsen en eventueel de algemene offgrid schakelaar switch.zendure_offgrid_socket, die alle schakelaars tegelijk schakelt."

Sorry ik was weer eens te snel he. Ik zat de uitleg over de package te zoeken in je engelse readme, en die staat alleen in de nederlandse readme . Toen ik die eenmaal had was het weer snel gebeurd - we zijn weer up-to-date! Thanks weer!

[gast777]

Gramser schreef op zondag 12 juli 2026 @ 14:52:
[...]

Sorry ik was weer eens te snel he. Ik zat de uitleg over de package te zoeken in je engelse readme, en die staat alleen in de nederlandse readme . Toen ik die eenmaal had was het weer snel gebeurd - we zijn weer up-to-date! Thanks weer!

Ah ja, klopt. De Engelstalige github readme pagina heeft momenteel nog niet alles wat de Nederlandse pagina heeft. Een aantal optionele dingen ontbreken nog.

Mooi dat het je weer gelukt is

[ Voor 5% gewijzigd door gast777 op 12-07-2026 15:13 ]

[ppaulv]

@Kaaf , @gielz en wie het nog meer interesseert.
Ik ben voorlopig best tevreden nu.
Quooker spikes worden genegeerd.
En ik realiseer me dat ik nog lang niet alle scenario's gezien heb, maar dat komt vanzelf de komende tijd.
Bijvoorbeeld een oven aan hebben zonder dat de export gaat stuiteren is vanmiddag gezien.
Voorlopig laat ik het hierbij ;-)


BTW @gielz , ik heb inmiddels een sensor van die average gemaakt dus ik hoef jouw code niet meer daarop aan te passen.

[ Voor 8% gewijzigd door ppaulv op 12-07-2026 18:30 ]

[oeps]

gielz schreef op zondag 12 juli 2026 @ 10:06:

Gielz release V20260712

Een heel klein dingetje.
Na de upgrade had ik entity not found voor input_number.dynamic_export_correction. Ik zie in de readme dat dit nieuw is. Logisch dat je die helper moet aanmaken maar expliciet in de readme en instructies opnemen met de settings kan vragen voorkomen.
Aanvulling/oplossing:Ik had HA moeten rebooten na de upgrade uiteraard anders leest hij de nieuwe config niet opnieuw in!
Zo opgelost door de number helper aan te maken uiteraard:

[ Voor 8% gewijzigd door oeps op 13-07-2026 12:39 ]

[gielz]

oeps schreef op maandag 13 juli 2026 @ 10:00:
[...]

Een heel klein dingetje.
Na de upgrade had ik entity not found voor input_number.dynamic_export_correction. Ik zie in de readme dat dit nieuw is. Logisch dat je die helper moet aanmaken maar expliciet in de readme en instructies opnemen met de settings kan vragen voorkomen.
Zo opgelost door de number helper aan te maken uiteraard:
[Afbeelding]

Als je de laatste versie van de package hebt zit deze er in, wellicht is het daar niet goed gegaan bij je upgrade;

[ppaulv]

@gielz (en alle anderen). Ondanks dat ik al best tevreden was/ben over mijn toevoeging van het gemiddelde over 3 metingen van de P1, zie ik toch nog iets anders (dat er ook al was toen ik gewoon de P1 metingen gebruikte). Het lijkt er sterk op dat het herbalanceren van import of export van de accu teveel bijstuurt. Een dosis overstuur dus.
Zie plaatje. Daarin zie je telkens blokjes meer en minder ontladen, dat na eenkwartier of zo wel uitdempt maar dat imho gewoon niet zou moeten optreden.
Ik heb zelf al in die hoek wat uitgeprobeerd om die balanceer acties te dempen maar dat liep op niets uit. Begrijp ook niet helemaal hoe dat op dit moment werkt of zou moeten werken.
Misschien heeft iemand, als het niet Michiel zelf is, een idee hoe dit te dempen?

[oeps]

gielz schreef op maandag 13 juli 2026 @ 10:27:
[...]


Als je de laatste versie van de package hebt zit deze er in, wellicht is het daar niet goed gegaan bij je upgrade;
[Afbeelding]

Ik was de reboot van HA vergeten! Excuus!

[JSven]

oeps schreef op maandag 13 juli 2026 @ 12:40:
[...]

Ik was de reboot van HA vergeten! Excuus!

Je bent niet de eerste en niet de laatste die dat al eens vergeten is (inclusief mezelf)

[peterpijpelink]

hoi, misschien hoort deze vraag hier niet, maar aansturing van een thuisbatterij via Home Assistant is voor mijn prioriteit 1. Ik twijfel nog tussen de Zendure sonarflow mix en de Anker solex solarban Max AC.


Iemand bekend met beide units en of er wezenlijke verschillen zijn? (ja van beide specs gelezen, maar zegt weinig tot niets over HA entities etc...) ik zoek dus vooral echte gebruikerservaring.

Ik wil een thuisbatterij aanschaffen om ervaring op te doen en vooral slim aansturen, mijn auto laad ik op overschot PV zon. En dan mag de accu niets doen of overschot opslaan. Goed aansturen is dan essentieel.

[Gramser]

Volgens mij is dat laatste exact waar EVCC voor bedoeld is - ook beschikbaar als HA-integratie. De Zendure is in ieder geval prima te vinden door EVCC, daar zit geen beperking. Ik kan het zelf nog niet toepassen wegens gebrek aan laadpaal, de grannycharger is hier niet bepaald geschikt voor.

[ Voor 17% gewijzigd door Gramser op 13-07-2026 13:05 ]

[Maarten60]

peterpijpelink schreef op maandag 13 juli 2026 @ 12:42:
hoi, misschien hoort deze vraag hier niet, maar aansturing van een thuisbatterij via Home Assistant is voor mijn prioriteit 1. Ik twijfel nog tussen de Zendure sonarflow mix en de Anker solex solarban Max AC.


Iemand bekend met beide units en of er wezenlijke verschillen zijn? (ja van beide specs gelezen, maar zegt weinig tot niets over HA entities etc...) ik zoek dus vooral echte gebruikerservaring.

Ik wil een thuisbatterij aanschaffen om ervaring op te doen en vooral slim aansturen, mijn auto laad ik op overschot PV zon. En dan mag de accu niets doen of overschot opslaan. Goed aansturen is dan essentieel.

Als het specifiek over de HA-aansturing van de Zendure gaat zit je hier op de juiste plek. Er is een specifiek topic over de Zendure functionele kant.
Mijn ervaring met de HA-aansturing van de Zendure AC2400+.
Ik gebruik zelf de Gielz en proxy 777 modules. De GIelz is voor de aansturing van 1 batterij. Met de proxy kan je meerdere batterijen aansturen als 1 virtuele unit
1) Gielz en Gast777 zijn zeer actieve maintainers die ook openstaan voor bug fixing en nieuwe features. Hoewel ze ieder hun eigen module ontwikkelen is de samenwerking naadloos
2) Deze aansturing is volledig lokaal, je bent dus niet afhankelijk van een cloud
3) Er is een actieve community die elkaar helpt
4) Ik heb 2 thuisbatterijen die ik probleemloos aanstuur voor NoM. Ik lees positieve ervaring over dynamisch handelen maar daar het ik zelf geen ervaring mee.
5) De oplossingen zijn open en je kan dus zelfs aanvullingen maken. Ik heb zelf een aanvullende oplossing gemaakt voor het laden van mijn auto en het aansturen van de fans.
Kortom, ik ben een tevreden gebruiker.
Tip, lees de afgelopen 15 pagina's eens door dan krijg je een gevoel voor wat er speelt.

[MP3-Junky]

Kan iemand mij geruststellen mbt het aantal relais schakelingen?

De Gielz integratie zegt "tot 100 per dag is normaal". Maar dan is het relais toch met een paar jaar kapot? Of kunnen ze meer hebben?

[ZuinigeRijder]

@gielz Wanneer ik het aantal goedkope periodes kleiner maak (in dit geval 9 periodes van 1 kwartier vandaag, naar 8 periodes van 1 kwartier vandaag) wordt de Spread én Spread NOM "Unavailable" bij Dynamisch Vandaag. Gisteren had ik dat alleen bij Dynamisch morgen (maar die is nu nog niet beschikbaar). Komt dit door de negatieve prijzen/0 prijzen vandaag? Het lijkt alleen te maken te hebben met de goedkope periodes.



Lijkt een delen door nul probleem?

code:

Logger: homeassistant.components.template.template_entity
Source: components/template/template_entity.py:99
Integration: Template (documentation, issues)
First occurred: July 13, 2026 at 10:47:34 (11 occurrences)
Last logged: 10:40:01

TemplateError('ZeroDivisionError: division by zero') while processing template 'Template<template=({% set uren = state_attr('sensor.dynamisch_goedkoopste_periode', 'raw_today') or [] %} {% set goedkoop = uren | selectattr('goedkoop','equalto','ja') | list %} {% set duur = uren | selectattr('duur','equalto','ja') | list %} {% if goedkoop | count > 0 and duur | count > 0 %} {% set avg_goedkoop = goedkoop | map(attribute='value') | sum / goedkoop | count %} {% set avg_duur = duur | map(attribute='value') | sum / duur | count %} {{ ((avg_duur - avg_goedkoop) / (avg_goedkoop | abs) * 100) | round(1) }} {% else %} 0 {% endif %}) renders=132>' for attribute '_attr_native_value' in entity 'sensor.dynamisch_spread_indicatie'
TemplateError('ZeroDivisionError: division by zero') while processing template 'Template<template=({% set uren = state_attr('sensor.dynamisch_goedkoopste_periode', 'raw_today') or [] %} {% set duurste = state_attr('sensor.dynamisch_goedkoopste_periode', 'duurste_na_eerste_goedkope') 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=132>' for attribute '_attr_native_value' in entity 'sensor.dynamisch_spread_indicatie_nom'
...

P.S. ik zie ook deze waarschuwing in de logging, blijkbaar na een timeout. Maar staat los van het bovenstaande probleem.

code:

Logger: homeassistant.components.automation.zendure_zensdk_gielz
Source: helpers/script.py:2197
Integration: Automation (documentation, issues)
First occurred: July 13, 2026 at 10:47:35 (101 occurrences)
Last logged: 09:05:18

Zendure zenSDK (Gielz): Error in 'choose[1]' evaluation: In 'template' condition: ValueError: Template error: float got invalid input 'unknown' when rendering template '{{ states('sensor.zendure_2400_ac_ingesteld_ontlaadvermogen') | float != states('input_number.zendure_2400_ac_max_ontlaadvermogen') | float }}' but no default was specified
Zendure zenSDK (Gielz): Systeem: PV export aanpassen: Error executing script. Error for call_service at pos 1: Timeout when calling resource "http://localhost:1880/endpoint/properties/write"
Zendure zenSDK (Gielz): Error executing script. Error for choose at pos 2: Timeout when calling resource "http://localhost:1880/endpoint/properties/write"
Zendure zenSDK (Gielz): NOM Aansturing: Tijdens ontladen balanceren naar -xxx watt (100% van de vraag): Error executing script. Error for call_service at pos 1: Timeout when calling resource "http://localhost:1880/endpoint/properties/write"
Zendure zenSDK (Gielz): Error executing script. Error for choose at pos 3: Timeout when calling resource "http://localhost:1880/endpoint/properties/write"

En deze foutmelding (998 occurrences):

code:

Logger: homeassistant.helpers.template
Source: helpers/template/__init__.py:648
First occurred: July 13, 2026 at 09:00:53 (998 occurrences)
Last logged: 10:56:23

Template variable warning: 'dict object' has no attribute 'packData' when rendering '{% set volgorde_raw = states('input_text.zendure_2400_ac_batterij_volgorde') %} {% set packdata = value_json['packData'] %} {% if not packdata %} unknown {% elif volgorde_raw in ['unknown','unavailable',''] %} {% set p = packdata[5] %} {% set d = p['maxVol'] - p['minVol'] %} {{ 'Uitstekend' if d <= 2 else 'Goed' if d <= 5 else 'Lichte onbalans' if d <= 8 else 'Onbalans' }} {% else %} {% set idx = (volgorde_raw.split(';')[5] | int) - 1 %} {% if idx < packdata | length %} {% set p = packdata~[idx] %} {% set d = p['maxVol'] - p['minVol'] %} {{ 'Uitstekend' if d <= 2 else 'Goed' if d <= 5 else 'Lichte onbalans' if d <= 8 else 'Onbalans' }} {% else %} unknown {% endif %} {% endif %}'
Template variable warning: 'dict object' has no attribute 'product' when rendering '{{ value_json.product }}'
Template variable warning: 'dict object' has no attribute 'packData' when rendering '{% set product = value_json.product %} {% if product in ["solarFlow4000AC+", "solarFlow4000Pro", "solarFlow3000AC+"] %} {% set mapping = { 70: 8.00 } %} {% else %} {% set mapping = { 5: 2.88, 70: 1.92, 300: 1.92, 350: 2.88, 500: 2.40 } %} {% endif %} {% set packs = value_json.packData %} {% if packs %} {% set ns = namespace(total=0) %} {% for pack in packs %} {% set type = pack.packType | int %} {% if type in mapping %} {% set ns.total = ns.total + mapping~[type] %} {% endif %} {% endfor %} {{ ns.total | round(2) }} {% else %} 0 {% endif %}'

[ Voor 101% gewijzigd door ZuinigeRijder op 14-07-2026 10:59 ]

[Tiesert]

Het opvangen van het plotselinge verbruik van de Qooker is hier besproken, maar ik heb eigenlijk meer "last" van de opstart van de zonnepanelen. Aan het begin van de dag kan ik de fluctuerende productie niet goed compenseren naar 0, de automatisering is altijd te laat of heeft een overshoot. Resultaat is opname van het grid en teruglevering. Ik gebruik de RESTful verbinding met de HW-p1 op basis van 2 seconden interval. Zou hier nog wat te verbeteren zijn?

[Mistraller]

MP3-Junky schreef op dinsdag 14 juli 2026 @ 08:40:
Kan iemand mij geruststellen mbt het aantal relais schakelingen?

De Gielz integratie zegt "tot 100 per dag is normaal". Maar dan is het relais toch met een paar jaar kapot? Of kunnen ze meer hebben?

Ik heb hier al een jaar of 10 PIR's hangen met relais. Die dingen schakelen dagelijks ontelbare keren. Een relais kan makkelijk 100.000 tot 1 miljoen schakelingen doen. Afhankelijk van de stroom die er loopt bij het schakelmoment. Maar omdat de Zendure volgens mij eerst vermogen naar nul brengt, dan schakelt van laden naar ontladen of omgekeerd, is de hoeveelheid stroom dus laag.

Tot slot: ik heb 2 zendures dus daarmee het dubbele aantal schakelingen. Zelfs nog meer dan je zou verwachten omdat de proxy regelt dat de Zendures om en om actief zijn bij lage vermogens.

Ik denk zelf dat het aantal schakelmomenten totaal niet relevant is. (Overigens maakt Gielz een aanname wat een schakeling is; toen ik slechte wifi had zat ik ver boven de 2000 per dag, maar dat was echt niet zo, want dan had ik het geklik wel gehoord.)

[Mistraller]

Tiesert schreef op dinsdag 14 juli 2026 @ 10:53:
Het opvangen van het plotselinge verbruik van de Qooker is hier besproken, maar ik heb eigenlijk meer "last" van de opstart van de zonnepanelen. Aan het begin van de dag kan ik de fluctuerende productie niet goed compenseren naar 0, de automatisering is altijd te laat of heeft een overshoot. Resultaat is opname van het grid en teruglevering. Ik gebruik de RESTful verbinding met de HW-p1 op basis van 2 seconden interval. Zou hier nog wat te verbeteren zijn?

Dat is toch maar een kleine afwijking zou ik zeggen? Ik heb dat met een DSMR4 altijd wel een beetje, maar uiteindelijk zie ik over de hele dag dan geen waardes in de meterstanden die er echt toe doen.

[Polvo176]

Mistraller schreef op dinsdag 14 juli 2026 @ 10:58:
[...]

Ik heb hier al een jaar of 10 PIR's hangen met relais. Die dingen schakelen dagelijks ontelbare keren. Een relais kan makkelijk 100.000 tot 1 miljoen schakelingen doen. Afhankelijk van de stroom die er loopt bij het schakelmoment. Maar omdat de Zendure volgens mij eerst vermogen naar nul brengt, dan schakelt van laden naar ontladen of omgekeerd, is de hoeveelheid stroom dus laag.

Tot slot: ik heb 2 zendures dus daarmee het dubbele aantal schakelingen. Zelfs nog meer dan je zou verwachten omdat de proxy regelt dat de Zendures om en om actief zijn bij lage vermogens.

Ik denk zelf dat het aantal schakelmomenten totaal niet relevant is. (Overigens maakt Gielz een aanname wat een schakeling is; toen ik slechte wifi had zat ik ver boven de 2000 per dag, maar dat was echt niet zo, want dan had ik het geklik wel gehoord.)

Mag wel hopen dat het meer dan 100.000 zijn, met 100 per dag ben je na 1000 dagen = 2 jaar en 8 maanden op het einde.

Het is wel afhankelijk hoe je de batterijen gebruikt.
Ben je alleen bezig met NOM, zal het vaker zijn dan met lange perioden van leveren en terug leveren.
Ik heb overcapaciteit en ben eigenlijk 24 uur per dag aan het terug leveren op wat bijzondere verbruikspieken na.
Batterij laat op met zonne energie en ontlaad met een vast vermogen dat boven het gebruik ligt en schakelt dus nauwelijks.

Het is dus ook afhankelijk of je er zonnepanelen op hebt aangesloten.
De batterijen met zonnepanelen zitten bij mij op 9, 21 en 28 per dag.
De batterij zonder zonnepanelen op 40 tot 50 per dag.

[Pimmetje651]

Okay alvast aan het voorbereiden op de 2de batterij die onderweg is, wilde ik de @gast777 nodered proxy gaan opzetten. Nu moet je daarvoor de flowfuse node-red-dashboard module Installer. Maar dit lukt me dus niet.

Gebruik de standaard HomeAssistant app met versie 22.0.0 maar deze is dus te nieuw voor de module. (Node v24.16.0 in gebruik, maar 18 / 20 / 22 ondersteund). Hoe hebben jullie dit opgelost?

[Mistraller]

Polvo176 schreef op dinsdag 14 juli 2026 @ 13:58:
[...]

Mag wel hopen dat het meer dan 100.000 zijn, met 100 per dag ben je na 1000 dagen = 2 jaar en 8 maanden op het einde.

Het is wel afhankelijk hoe je de batterijen gebruikt.
Ben je alleen bezig met NOM, zal het vaker zijn dan met lange perioden van leveren en terug leveren.
Ik heb overcapaciteit en ben eigenlijk 24 uur per dag aan het terug leveren op wat bijzondere verbruikspieken na.
Batterij laat op met zonne energie en ontlaad met een vast vermogen dat boven het gebruik ligt en schakelt dus nauwelijks.

Het is dus ook afhankelijk of je er zonnepanelen op hebt aangesloten.
De batterijen met zonnepanelen zitten bij mij op 9, 21 en 28 per dag.
De batterij zonder zonnepanelen op 40 tot 50 per dag.

Hoop is uitgestelde teleurstelling.

De nadruk ligt op "makkelijk". Een fatsoenlijk relais haalt dat, belast, met gemak.
Een relais dat een vermogen schakelt, slijt op de contacten. Maar jouw zendure schakelt niet op vol vermogen. Dus een miljoen of flink meer ligt meer in de verwachting.

Met Nom rond etenstijd als de PV opbrengst terug aan het lopen is, geeft hier vaak wat geklapper. Want oven heeft bijv een aan-uit cyclus en de hele tijd schakelen de zendures mee. De relais lijken me een van de minst interessante zaken om je zorgen over te maken qua levensduur in elk geval.

[ErikLooren]

Hoi allemaal,

Ik heb de Gielz integratie draaien op Home-Assistant icm Zendure 2400 AC+ en AB3000L batterij.

Wat ik mij afvroeg is waarom de 2de grafiek continu hoog-laag pendelt. Is dit wel goed?

Ook vroeg ik mij af of de HACS Zendure Manager Integratie aan moet staan en in welke modus deze gezet zou moeten worden.

Ook twijfel ik aan het aantal relais-schakelingen, is 1000 per dag niet een beetje aan de hoge kant

Zou iemand mij van iets extra informatie willen voorzien?

Alvast bedankt! 😊

[ Voor 10% gewijzigd door ErikLooren op 14-07-2026 22:31 ]

[ppaulv]

Update.
Ik was eigenlijk al tevreden met mijn constructie van voortschrijdend gemiddelde P1 vermogen meting over 3 meetpunten. EN heb dat zelfs ook met 5 uitgetest.
Maar daar zat een denkfout in. Of het verkeerd lezen van de grafieken.
Het grootste probleem met het 'stuiteren' zat 'm erin dat de accu veel te laat/traag reageerde op wijzigingen in de P1 waardes. En door dat gebruikte gmiddelde werd dat nog trager en dus erger. Door met de triggering en de factoren (van 100% naar 75% en zelfs 50%) in de Gielz automatisering te spelen leek het nog wat te worden. Het gestuiter kwam nog steeds elke keer voor maar dempte redelijk snel uit. Maar dat was niet de oplossing.
Toen kwam ik op het idee om dat gemiddelde te beperken tot 70% van de 'nieuwe' meting en 30% van de vorige. Daarmee worden veranderingen wèl heel snel gezien en verwerkt maar worden spikes afgezwakt.
Dit werkt nu al de hele avond best heel goed. Zit nog wat te spelen met die factoren (heb 'm ze nu op 80% staan, allemaal (nog) hetzelfde). Accu ontlading (600 - 700 W) wordt nu zo geregeld dat er continu zo'n 125 - 150 W verbruik overblijft. En bij plotseling groot verbruik dempt de reactie uit na 1 of 2 slingerbewegingen. Dat vind ik niet verkeerd aangezien ik een 4.2 meter heb (dus elke 10 sec een update van de meetwaardes). Zal morgen verder kijken hoe het gaat.

[ppaulv]

ErikLooren schreef op dinsdag 14 juli 2026 @ 22:25:
Hoi allemaal,

Ik heb de Gielz integratie draaien op Home-Assistant icm Zendure 2400 AC+ en AB3000L batterij.

Wat ik mij afvroeg is waarom de 2de grafiek continu hoog-laag pendelt. Is dit wel goed?

Ook vroeg ik mij af of de HACS Zendure Manager Integratie aan moet staan en in welke modus deze gezet zou moeten worden.

Ook twijfel ik aan het aantal relais-schakelingen, is 1000 per dag niet een beetje aan de hoge kant

Zou iemand mij van iets extra informatie willen voorzien?

Alvast bedankt! 😊

[Afbeelding]

[Afbeelding] [Afbeelding]

[Afbeelding]

Dat is inderdaad veel teveel. Wellicht moet je eens proberen het voortdurende geflipper tussen opladen en ontladen to voorkomen.
Daarbij kun je botweg (automatisch) tijdgestuurd wisselen tussen 'alleen opladen', 'alleen ontladen' en 'standby'. Daarmee beperk je dit gedrag met harde hand.
Ook zou je kunnen kijken naar een manier van dempen van de slingerbewegingen.
Heb je een DSMR 4.2 meter ? Die slecht elke 10 sec data levert? Daar heb ik de afgelopen dagen een 'oplossing' (meer een pleister) voor gezocht en denk nu wat te hebben dat werkt.

[Tiesert]

Mistraller schreef op dinsdag 14 juli 2026 @ 11:01:
[...]

Dat is toch maar een kleine afwijking zou ik zeggen? Ik heb dat met een DSMR4 altijd wel een beetje, maar uiteindelijk zie ik over de hele dag dan geen waardes in de meterstanden die er echt toe doen.

Ja, dat is ook zo. Maar ja, het blijft natuurlijk een uitdaging om te blijven verbeteren ;-) Want vele beetjes maken ook een serieus verlies.

[meesje]

Als je kiest voor de HA integratie van Zendure zelf, volstaat dan ook dat je alleen gebruik maakt van een HW P1 meter? Of moet je dan ook de P1 meter van Zendure gebruiken?

[ErikLooren]

ppaulv schreef op dinsdag 14 juli 2026 @ 22:40:
[...]

Dat is inderdaad veel teveel. Wellicht moet je eens proberen het voortdurende geflipper tussen opladen en ontladen to voorkomen.
Daarbij kun je botweg (automatisch) tijdgestuurd wisselen tussen 'alleen opladen', 'alleen ontladen' en 'standby'. Daarmee beperk je dit gedrag met harde hand.
Ook zou je kunnen kijken naar een manier van dempen van de slingerbewegingen.
Heb je een DSMR 4.2 meter ? Die slecht elke 10 sec data levert? Daar heb ik de afgelopen dagen een 'oplossing' (meer een pleister) voor gezocht en denk nu wat te hebben dat werkt.

Ik heb een Landis+Gyr SMR 5.0 slimme meter en een HomeWizard P1 direct hierop aangesloten.

[Devke]

ErikLooren schreef op dinsdag 14 juli 2026 @ 22:25:
Hoi allemaal,

Ik heb de Gielz integratie draaien op Home-Assistant icm Zendure 2400 AC+ en AB3000L batterij.

Wat ik mij afvroeg is waarom de 2de grafiek continu hoog-laag pendelt. Is dit wel goed?

Ook vroeg ik mij af of de HACS Zendure Manager Integratie aan moet staan en in welke modus deze gezet zou moeten worden.

Ook twijfel ik aan het aantal relais-schakelingen, is 1000 per dag niet een beetje aan de hoge kant

Zou iemand mij van iets extra informatie willen voorzien?

Alvast bedankt! 😊

[Afbeelding]

[Afbeelding] [Afbeelding]

[Afbeelding]

Misschien lees ik het verkeerd maar heb je zowel gielz als de Zendure integratie draaien? Dat kan niet. Dan heb je 2 kapiteins op 1 schip. Het is of de 1 of de ander.

[ppaulv]

ErikLooren schreef op dinsdag 14 juli 2026 @ 22:53:
[...]

Ik heb een Landis+Gyr SMR 5.0 slimme meter en een HomeWizard P1 direct hierop aangesloten.

Hmm .. dan moet het iets anders zijn.
Die tweede screenshot van jou, waaruit (applicatie) heb je die gemaakt?

[ErikLooren]

ppaulv schreef op woensdag 15 juli 2026 @ 07:57:
[...]

Hmm .. dan moet het iets anders zijn.
Die tweede screenshot van jou, waaruit (applicatie) heb je die gemaakt?

Hi,

het screenshot was van de omvormer zelf, deze reageert ook als de in en uitvoerwaarde veranderen in Gielz.

In de manager staat aangegeven dat deze Uit staat/inactief is.

Heb de waardes bij oplaadlimiet en marges aaangepast, denk dat dit wel wat zal schelen qua relaisschakelingen.

[Do-m-pie]

ppaulv schreef op dinsdag 14 juli 2026 @ 22:34:
Update.
Ik was eigenlijk al tevreden met mijn constructie van voortschrijdend gemiddelde P1 vermogen meting over 3 meetpunten. EN heb dat zelfs ook met 5 uitgetest.
Maar daar zat een denkfout in. Of het verkeerd lezen van de grafieken.
Het grootste probleem met het 'stuiteren' zat 'm erin dat de accu veel te laat/traag reageerde op wijzigingen in de P1 waardes. En door dat gebruikte gmiddelde werd dat nog trager en dus erger. Door met de triggering en de factoren (van 100% naar 75% en zelfs 50%) in de Gielz automatisering te spelen leek het nog wat te worden. Het gestuiter kwam nog steeds elke keer voor maar dempte redelijk snel uit. Maar dat was niet de oplossing.
Toen kwam ik op het idee om dat gemiddelde te beperken tot 70% van de 'nieuwe' meting en 30% van de vorige. Daarmee worden veranderingen wèl heel snel gezien en verwerkt maar worden spikes afgezwakt.
Dit werkt nu al de hele avond best heel goed. Zit nog wat te spelen met die factoren (heb 'm ze nu op 80% staan, allemaal (nog) hetzelfde). Accu ontlading (600 - 700 W) wordt nu zo geregeld dat er continu zo'n 125 - 150 W verbruik overblijft. En bij plotseling groot verbruik dempt de reactie uit na 1 of 2 slingerbewegingen. Dat vind ik niet verkeerd aangezien ik een 4.2 meter heb (dus elke 10 sec een update van de meetwaardes). Zal morgen verder kijken hoe het gaat.

Ik heb hier met een DSMR 4.2 meter de factoren in de automatisering van Gielz naar 0.25 gezet en de trigger naar 21 seconden. Werkt redelijk goed om het geslinger op te vangen.

Opladen bij -350 W en marge van 50
Ontladen bij 100 W en marge van 5

[Do-m-pie]

mutsaards schreef op vrijdag 27 februari 2026 @ 21:47:
Gielz,
Ik ben ook veroordeelt tot een 4.2 meter met puls per 10 sec.
Maar heb het tot redelijk resultaat gekregen.
Werkt stabiel op NOM, aantal schakelingen 10 tot 18 / dag, nog wel licht instabiel doch komt er telkens zelf uit.
Niet optimaal, zal het ook niet worden omdat trigger en P1 waarde niet gesinchoniseerd zijn.

Hoe: in de versie van 20260114 de volgende parameters aangepast:
Regel 4 tijd van 4 naar 22
regel 363, 381, 547 en 561 factor 0,75 naar 0,25

Basis reden van probleem: voordat P1 waarde ververst wordt loopt algoritme 2 tot 3 maal waardoor telkens aanpassing wordt verhoogd/verlaagd met 75% dus correctie is telkens 150 of zelfs 225 %, kan niet anders dan oscilleren.

Ik heb Zendure via ticket gevraagd probleem op te lossen.
Ze hebben mij een firmware modificatie beloofd, wordt april / mei.

Tegen die tijd is probleem voor mij opgelost. Enexis is gestart met grootschalige vervanging (omgeving Tilburg) scheelt mij 200 eu aan vervangingskosten. (was al gepland)

Schermafdruk nodig van gedrag ? ik hoor het wel.

Deze tip gevolgd

[jelleeelco]

ErikLooren schreef op woensdag 15 juli 2026 @ 08:08:
[...]

Hi,

het screenshot was van de omvormer zelf, deze reageert ook als de in en uitvoerwaarde veranderen in Gielz.

In de manager staat aangegeven dat deze Uit staat/inactief is.

Heb de waardes bij oplaadlimiet en marges aaangepast, denk dat dit wel wat zal schelen qua relaisschakelingen.

[Afbeelding]

[Afbeelding]

[Afbeelding]

lijkt idd alsof je met 2 integraties aanstuurt. Staat de automatisering van Gielz ook aan? Je moet een van de twee uitschakelen - Gielz of Fireson.

[bluebit]

ErikLooren schreef op woensdag 15 juli 2026 @ 08:08:
[...]

Hi,

het screenshot was van de omvormer zelf, deze reageert ook als de in en uitvoerwaarde veranderen in Gielz.

In de manager staat aangegeven dat deze Uit staat/inactief is.

Heb de waardes bij oplaadlimiet en marges aaangepast, denk dat dit wel wat zal schelen qua relaisschakelingen.

[Afbeelding]

[Afbeelding]

[Afbeelding]

Nee, zo had ik hem ook staan, maar je moet de officiele zendure integratie volledig uitschakelen! (drie puntjes klikken, en uitschakelen). Ik heb deze week 6 uur lang zitten te troubleshooten omdat de ene integratie de batterij telkens in save to flash zette en op standby terwijl Gielz integratie deze naar RAM zette en weer ging laden/ontladen.

leverde maar 2500 relaisschakelingen op...ik realiseerde me het toen ik in de log zag dat Gielz integratie de batterij telkens naar FLASH zette, maar er nergens een melding kwam dat ie naar RAM gezet werd, terwijl ik het wel zag gebeuren op de entiteit. Overigens wordt dit ook door iedereen aanbevolen, maar ja, ik ben wat langzamer.

[Gramser]

We hebben het hier over uitschakeling van de betreffende automatisering van de Zendure integratie, toch? Voor de duidelijkheid? Je hoeft niet die hele integratie zelf uit te schakelen?

[R.K]

Vraagje: Kunnen meerdere Solarflow's communiceren in HA met één P1 meter?

[ Voor 4% gewijzigd door R.K op 15-07-2026 12:45 ]

[Mscroos]

R.K schreef op woensdag 15 juli 2026 @ 12:44:
Vraagje: Kunnen meerdere Solarflow's communiceren in HA met één P1 meter?

Begrijp de vraag niet helemaal, maar als je de nodered van Gast777 gebruikt dan worden meerdere units gecombineerd en die gebruiken samen de P1(data) via Gielz.

[R.K]

Mscroos schreef op woensdag 15 juli 2026 @ 12:50:
[...]

Begrijp de vraag niet helemaal, maar als je de nodered van Gast777 gebruikt dan worden meerdere units gecombineerd en die gebruiken samen de P1(data) via Gielz.

Ah oke', dat was idd het antwoord wat ik zocht, Thnx.