Zendure producten in Home Assistant integreren deel 2

[Eduardo M]

Goedemorgen,

Er lijkt wat fout te gaan bij het ontladen met de Gielz automatisering icm de Gast proxy: bij mijn 2e batterij zakt ie door het ingestelde laadpercentage ondergrens van 10%. In de Zendure app zie ik dat de ondergrens dan is gewijzigd naar 5%, ik vermoed dat dat door de Gielz automatisering is aangepast. Iemand die hier ook last van heeft?

[Devke]

gast777 schreef op vrijdag 22 mei 2026 @ 00:40:
[...]

Inderdaad momenteel wordt het max vermogen simpelweg gelijk verdeeld over alle Zendures. Dit is ook de reden dat het mixen van verschillende modellen Zendures niet aan te raden is (behalve als ze hetzelfde vermogen hebben zoals SF2400AC en SF2400AC+).

Ik heb er zeker wel eens over gedacht om dat instelbaar te maken. En ook om rekening te houden met het totaal aantal kWh batterij capaciteit per device (als dat verschillend is) bij het berekenen van het vermogen van ieder device.

(Maar dan zou de gebruiker het best ook evenredig veel batterijcapaciteit eronder zetten, want anders blijven de SoC niet ongeveer gelijk met de verschillende vermogens. Dan heb je nog vrij weinig aan je verschillende vermogens.)

Momenteel heeft dat echter niet echt prioriteit, tenzij er meerdere gebruikers zijn die zo'n asymmetrische setup zouden willen gebruiken met de Gielz aansturing. Dan kan ik er eventueel eens een zaterdag aan besteden.

Het idee is natuurlijk leuk, tweakers willen overal aan kunnen draaien. 😜 Even hardop denkend, zou je de batterijen dit niet gewoon zelf in zoverre willen laten doen als ze de beste RTE combi zoeken? Nu is dat al een klusje denk ik. Ik denk als je voor efficiëntie kiest ipv zelf regelen dat je meer winst hebt. Tis maar een gedachte kronkel. Het zal wel een lastige klus zijn denk ik. NOM is nooit een flatline en wanneer spring je boven 2400 uit? Laden bij 1400 W is best efficient zie ik hier. Beter dan 2400.

[ Voor 5% gewijzigd door Devke op 22-05-2026 08:36 ]

[hremijn]

oeps schreef op donderdag 21 mei 2026 @ 19:51:
[...]

Er is een open issue bij Zendure dat mqtt stopt al HA herstart wordt, bijvoorbeeld door bijwerken HA. Om het te fixen moet mqtt ff in de Zendure app uit/aanzetten.

Dit kreeg ik van Zendure support op 6 mei:

[...]

Dat snap ik niet. De reden van mijn vraag is dat ik gemerkt heb dat als de API niet reageert na korte uitval van de wifi ik wel data van de zendure via mqtt krijg.

[ZuinigeRijder]

gielz schreef op vrijdag 22 mei 2026 @ 07:13:
[...]


Wel even opletten dat je dit niet te laag instelt. Er zijn een aantal zendure type’s (dacht de 2400ac+ en pro) die niet (altijd) ontwaken onder de 60 watt en zelfs vastlopen. Na een reboot met de knop doen ze het weer.

Ik heb wel een nog niet opgelost probleem gemeld bij Zendure. Zie deze post:

ZuinigeRijder in "Het grote Zendure plug-and-play thuisaccu systemen topic"

Ook heeft maar één Solarflow 800 Plus dit probleem

Ik heb aanvullende informatie. Toen ik de tweede accu "2 Solarflow 800 Plus" uit HEMS verwijderde, functioneerde de defecte "1 Solarflow 800 Plus", die continu schakelde tussen "Standby" en "Bezig met ontladen", weer naar behoren. Batterij "1 Solarflow 800 Plus" schakelt dus NIET over naar de stand-bymodus en houdt het nettoverbruik vrijwel nul.

Het lijkt erop dat dit probleem zich alleen voordoet tot rond de 70 Watt (dus 35 Watt per SF 800+).

In de "Basisbelastingmodus" doet zich het probleem niet voor. Alleen in de "Automatische modus" en "Expertmodus -> Slimme metermodus".
Ik heb dit probleem vanavond meerdere keren waargenomen. Het lijkt erop dat "1 Solarflow 800 Plus" alleen overschakelt naar de standbymodus wanneer er stroom teruggeleverd wordt aan het net en er maximaal 35 watt per batterij (70 watt in totaal) hoeft te worden teruggeleverd. Dan schakelt alleen "1 Solarflow 800 Plus" over naar de standbymodus; "2 Solarflow 800 Plus" blijft ongeveer 35 watt terugleveren. Boven de 70 watt leveren beide apparaten stroom terug aan het net.

Ik vermoed echter sterk dat het probleem zich voordoet bij een ontladingsvermogen van maximaal ongeveer 70 watt met twee accu's. Bij hogere ingangsvermogens heb ik het probleem niet waargenomen.

Nu gebruik ik de @gast777 proxy, dus nu gebeurt het ontladen door maar één batterij. Ben me alleen aan het afvragen of het probleem van één van de twee batterijen een relatie heeft tot het probleem wat tot gevolg had van het 80 Watt minimum.

Dit is trouwens het laatste antwoord van Zendure:

Hallo beste klant,

We hebben uw feedback ontvangen. Op basis van de afbeeldingen die u ons stuurde, hebben we een analyse uitgevoerd. Op 4 mei om 17:00 uur was het normale uitgangsvermogen van één apparaat 22 W, terwijl het andere apparaat in de standbymodus stond. Normaal gesproken zouden beide apparaten tegelijkertijd stroom moeten leveren.

Na nader onderzoek van de protocollen ontdekten we dat het apparaat in stand-bymodus een vermogenslimiet van 0 W had. Dit zou te wijten kunnen zijn aan een probleem met het netsignaal, waardoor de twee apparaten verschillende besturingscommando's ontvingen.

Dit is een klein probleem zonder grote functionele beperkingen. Blijf de apparaten in de gaten houden en neem contact met ons op als u verdere problemen ondervindt.

Hartelijke groeten,
Zendure-team

[ Voor 17% gewijzigd door ZuinigeRijder op 22-05-2026 08:51 ]

[Gramser]

In de Zendure-reclames lees je dat de batterijen 6000 cycles of meer mee gaan. Is ergens inzichtelijk hoeveel cycles de batterijen hebben gedaan..?

[gielz]

Eduardo M schreef op vrijdag 22 mei 2026 @ 08:19:
Goedemorgen,

Er lijkt wat fout te gaan bij het ontladen met de Gielz automatisering icm de Gast proxy: bij mijn 2e batterij zakt ie door het ingestelde laadpercentage ondergrens van 10%. In de Zendure app zie ik dat de ondergrens dan is gewijzigd naar 5%, ik vermoed dat dat door de Gielz automatisering is aangepast. Iemand die hier ook last van heeft?

Wellicht de laatste package recentelijk geinstalleerd? Hier zit het nieuwe instelbare laadpercentage in;

Releasenotes;
Stel na de installatie je minimaal en maximaal toegestane laadpercentage in. Deze waarden worden gesynchroniseerd naar: 5% minimaal en 70% maximaal ⚠️

Nieuwe functies

Mogelijkheid om het minimale en maximale laadpercentage in te stellen
Vanaf nu kun je het minimale en maximale laadpercentage in stellen. Hiervoor is de Zendure app niet meer nodig. De instellingen in Home Assistant zijn altijd leidend en worden direct gesynchroniseerd wanneer de batterij een andere waarde heeft.

[TBird484]

@gast777 Bij het upgraden van de proxy heb ik altijd de NR flow opnieuw geimporteerd, de oude weggegooid en de nieuwe daarna gedeployed. Dat gaat en ging probleemloos. Maar ik wil nu een probleem analyseren en gebruik maken van het dashboard. Binnen flowfuse lijkt het erop dat niet alles wordt opgeruimd en krijg ik de volgende foutmelding.

Wat is de juiste upgrade manier om dit issue te voorkomen ?

[wautah91]

thijsh02 schreef op donderdag 21 mei 2026 @ 22:20:
Klopt het dat bijna alle sensoren van de 2400AC+ zijn uitgeschakeld in de Fireson integratie? De temperatuur sensor van de omvormer kan ik bijvoorbeeld niet inschakelen 🤔 melding: Kan status niet wijzigen. Uitgeschakeld door apparaat

Of beter de Gielz integratie gebruiken? Heb alleen ook een Hyper en die staat niet op het ondersteunende lijstje.

ik heb een Hyper2000 proxy gemaakt voor de gielz integratie. Bij mij werkt het, tot nu toe nog geen feedback ontvangen van anderen, dus als je het wilt proberen zou tof zijn!

twoenter/Zendure-zenSDK-Hyper-proxy: Control your Zendure Hyper2000 with zenSDK in Home Assistant

[Theetjuh]

gast777 schreef op vrijdag 22 mei 2026 @ 00:40:
[...]

Inderdaad momenteel wordt het max vermogen simpelweg gelijk verdeeld over alle Zendures. Dit is ook de reden dat het mixen van verschillende modellen Zendures niet aan te raden is (behalve als ze hetzelfde vermogen hebben zoals SF2400AC en SF2400AC+).

Ik heb er zeker wel eens over gedacht om dat instelbaar te maken. En ook om rekening te houden met het totaal aantal kWh batterij capaciteit per device (als dat verschillend is) bij het berekenen van het vermogen van ieder device.

(Maar dan zou de gebruiker het best ook evenredig veel batterijcapaciteit eronder zetten, want anders blijven de SoC niet ongeveer gelijk met de verschillende vermogens. Dan heb je nog vrij weinig aan je verschillende vermogens.)

Momenteel heeft dat echter niet echt prioriteit, tenzij er meerdere gebruikers zijn die zo'n asymmetrische setup zouden willen gebruiken met de Gielz aansturing. Dan kan ik er eventueel eens een zaterdag aan besteden.

Bedankt dat je er iig al even aandacht aangeeft, ik ga binnenkort m'n electricien even vragen hoeveel het gaat kosten om een aparte groep naar de zolder te trekken, dat zou dan iig het probleem voor mij al oplossen. Maar ik kan me voorstellen dat het zeker wel gewaardeerd wordt zo'n optie.

[abaart]

Theetjuh schreef op vrijdag 22 mei 2026 @ 11:35:
[...]

Bedankt dat je er iig al even aandacht aangeeft, ik ga binnenkort m'n electricien even vragen hoeveel het gaat kosten om een aparte groep naar de zolder te trekken, dat zou dan iig het probleem voor mij al oplossen. Maar ik kan me voorstellen dat het zeker wel gewaardeerd wordt zo'n optie.

Heb even snel codex aan het werk gezet met je vraag. Resultaat staat in deze branch op GitHub.

Als je zin hebt kun je het testen met jouw setup! Moet je alleen wel even handmatig deze branch installeren in je AppDaemon setup, want via HACS is het niet mogelijk om test-branches te installeren.

Ondersteunt t/m 10 Zendures met instelbare power-limit per stuk:

code:

devices:
  - ip: "192.168.1.101"
    charge_max_watts: 600
    discharge_max_watts: 700
  - ip: "192.168.1.102"
    charge_max_watts:
    discharge_max_watts: 500

[Eduardo M]

gielz schreef op vrijdag 22 mei 2026 @ 09:10:
[...]


Wellicht de laatste package recentelijk geinstalleerd? Hier zit het nieuwe instelbare laadpercentage in;

Releasenotes;
Stel na de installatie je minimaal en maximaal toegestane laadpercentage in. Deze waarden worden gesynchroniseerd naar: 5% minimaal en 70% maximaal ⚠️

Nieuwe functies

Mogelijkheid om het minimale en maximale laadpercentage in te stellen
Vanaf nu kun je het minimale en maximale laadpercentage in stellen. Hiervoor is de Zendure app niet meer nodig. De instellingen in Home Assistant zijn altijd leidend en worden direct gesynchroniseerd wanneer de batterij een andere waarde heeft.

Ik heb inderdaad het laatste package. Na installatie hiervan het minimale/maximale laadpercentage in HA ingesteld op 10%/100%. Bij ontladen wordt het minimale percentage voor de batterij 1 gerespecteerd en stopt deze met ontladen. Echter voor batterij 2 stopt deze niet op 10% en zie ik in de zendure app dat het minimale laadpercentage gewijzigd is naar 5% het ontladen voor deze batterij loopt dus door naar 5%.

[gielz]

Eduardo M schreef op vrijdag 22 mei 2026 @ 13:51:
[...]

Ik heb inderdaad het laatste package. Na installatie hiervan het minimale/maximale laadpercentage in HA ingesteld op 10%/100%. Bij ontladen wordt het minimale percentage voor de batterij 1 gerespecteerd en stopt deze met ontladen. Echter voor batterij 2 stopt deze niet op 10% en zie ik in de zendure app dat het minimale laadpercentage gewijzigd is naar 5% het ontladen voor deze batterij loopt dus door naar 5%.

Ik zou hiervoor even een issue inschieten bij de proxy github. Want hij synchroniseert constant dus wellicht pakt deze sensor in de proxy de hoogste waarde van de 2 en niet de laagste?

[ppaulv]

ctrl-tab schreef op donderdag 21 mei 2026 @ 23:14:
[...]


Hehe wel ik snap de gedachtengang wel. Maar uiteindelijk is opslag van energie uit je zonnepanelen inkomstenderving. Straks wordt het interessanter, dan gaan de negatieve prijs momenten aanzienlijk toenemen. Dan is het geen inkomstenderving maar een verzekering tegen het betalen van boetes.
En moet je de 'gratis' stroom gaan knijpen (power limit op je panelen knijpen zodat je niks terug levert) Daarom wel fijn als je capaciteit en vermogen van je batterij genoeg is om je panelen voor een uur of 3 volledig (minus basislast) op te slurpen.

ehh .. nee .... als de prijs (voldoende) negatief is, is het beter qua euro's om je panelen volledig uit te schakelen en je accu vol te gooien met stroom uit het net waar je dan ook nog eens voor betaald wordt.
Het is juist inkomstenderving als je in die situatie je panelen gebruikt om je accu te laden.

Alleen in het schemergebiedje waar de kale prijs negatief is maar niet negatief genoeg om de te maken kosten (belastingen en leverancierskosten) goed te maken, dan zou je in het ideale geval wèl je panelen willen gebruiken om je accu te laden maar niets willen terugleveren in het grid. Leveren aan het grid kost dan een beetje en gebruiken uit het grid ook.
Uiteindelijk hebben we het dan over een paar centen per kWh dus of dat nou zoveel moeite waard is... ? En ja, in een recent verleden heb ik daar veel energie in gestoken maar achteraf gezien had ik beter iets anders kunnen gaan doen. Op het leuke leereffect na.

[ Voor 24% gewijzigd door ppaulv op 22-05-2026 14:51 ]

[Mimiix]

ppaulv schreef op vrijdag 22 mei 2026 @ 14:46:
[...]

ehh .. nee .... als de prijs (voldoende) negatief is, is het beter qua euro's om je panelen volledig uit te schakelen en je accu vol te gooien met stroom uit het net waar je dan ook nog eens voor betaald wordt.
Het is juist inkomstenderving als je in die situatie je panelen gebruikt om je accu te laden.

Alleen in het schemergebiedje waar de kale prijs negatief is maar niet negatief genoeg om de te maken kosten (belastingen en leverancierskosten) goed te maken, dan zou je in het ideale geval wèl je panelen willen gebruiken om je accu te laden maar niets willen terugleveren in het grid. Leveren aan het grid kost dan een beetje en gebruiken uit het grid ook.
Uiteindelijk hebben we het dan over een paar centen per kWh dus of dat nou zoveel moeite waard is... ? En ja, in een recent verleden heb ik daar veel energie in gestoken maar achteraf gezien had ik beter iets anders kunnen gaan doen. Op het leuke leereffect na.

En als het om panelen gaat die direct aan de accu zitten? SF2400pro?

Dan heb je namelijk amper verlies

[ppaulv]

Mimiix schreef op vrijdag 22 mei 2026 @ 15:24:
[...]

En als het om panelen gaat die direct aan de accu zitten? SF2400pro?

Dan heb je namelijk amper verlies

Het gaat niet om verlies of geen verlies, dat is een extra factor die ik even niet meegnomen heb in m'n verhaal, het gaat om de prijs die je moet betalen als je iets uit het grid trekt danwel iets in het grid stopt.
Geen idee hoe dat werkt maar ik neem aan (!) dat al die stroom ook direct in het grid gestopt kan worden zonder de accu op te laden?

[Bakkert]

Ik heb de Gielz integratie net een tijdje draaien op mijn 2400 pro. Ben nog lerende in HA, met vallen en opstaan begin ik het een heel klein beetje te begrijpen denk ik, maar een ding waar ik niet achter kom.

Via de configuratie laadpercentage krijg ik de waarden niet aangepast. API blijft op de oude waarden staan die ik ooit in de app ingesteld heb. Configuratie van bijvoorbeeld max. ontladen en max. opladen kan ik wel aanpassen. Iemand een idee waar dit door dan komen?

[gielz]

Bakkert schreef op vrijdag 22 mei 2026 @ 16:11:
Ik heb de Gielz integratie net een tijdje draaien op mijn 2400 pro. Ben nog lerende in HA, met vallen en opstaan begin ik het een heel klein beetje te begrijpen denk ik, maar een ding waar ik niet achter kom.

Via de configuratie laadpercentage krijg ik de waarden niet aangepast. API blijft op de oude waarden staan die ik ooit in de app ingesteld heb. Configuratie van bijvoorbeeld max. ontladen en max. opladen kan ik wel aanpassen. Iemand een idee waar dit door dan komen?

[Afbeelding]

Kun je even je volledige configuratie tabblad posten?

[Gramser]

@Bakkert HEMS staat wel uit toch?

[Bakkert]

gielz schreef op vrijdag 22 mei 2026 @ 16:15:
[...]


Kun je even je volledige configuratie tabblad posten?

Nog vergeten te melden, het is de laatste versie van je integratie.
Echt super mooi werk!
En HEMS staat uit inderdaad.

[ Voor 10% gewijzigd door Bakkert op 22-05-2026 16:24 ]

[gielz]

Bakkert schreef op vrijdag 22 mei 2026 @ 16:21:
[...]


Nog vergeten te melden, het is de laatste versie van je integratie.
Echt super mooi werk!
En HEMS staat uit inderdaad.

[Afbeelding]

Het rode kruis zegt het al. Of je heb geen automatisering actief staan of een oude versie van de automatisering. Ook (kan het mis hebben) heb je bij de dynamisch nordpool sensor na sensor. een spatie staan.

Je leest dus nu eigenlijk alleen uit.

[Bakkert]

gielz schreef op vrijdag 22 mei 2026 @ 16:27:
[...]


Het rode kruis zegt het al. Of je heb geen automatisering actief staan of een oude versie van de automatisering. Ook (kan het mis hebben) heb je bij de dynamisch nordpool sensor na sensor. een spatie staan.

Je leest dus nu eigenlijk alleen uit.

Dank! Sinds de update heb ik inderdaad dat kruis maar de NOM draait wel door. Ga ik kijken wat ik anders had moeten doen, vallen en opstaan
En heel scherp van de nordpool! Was ik vanmiddag mee bezig maar kreeg nog geen data

[oeps]

hremijn schreef op vrijdag 22 mei 2026 @ 08:36:
[...]

Dat snap ik niet. De reden van mijn vraag is dat ik gemerkt heb dat als de API niet reageert na korte uitval van de wifi ik wel data van de zendure via mqtt krijg.

Mijn opmerking is niet echt een antwoord op je vraag. Meer dat mqtt op dit moment ook andere issues heeft. Of het bij iedereen bij elke start een issue geeft, geen idee. Bij mij kon ik het reproduceren en zowel de batterij (2400 Pro) als de Zendure P1 konden hun data niet kwijt.
Is wel heel vreemd, maar mogelijk wil de batterij/P1 de oude sessie blijven gebruiken en heeft niet door dat die weg was. Klinkt als een niet handige Zendure mqtt implementatie.

Fun fact: door de grote broer van mqtt, MQ van IBM gingen vele jaren lang de meeste financiële transacties ter wereld heen (mainframe wereld van vroegah). Ben zeker geen mqtt specialist, dat waren collega’s van me.

[Mimiix]

ppaulv schreef op vrijdag 22 mei 2026 @ 16:01:
[...]

Het gaat niet om verlies of geen verlies, dat is een extra factor die ik even niet meegnomen heb in m'n verhaal, het gaat om de prijs die je moet betalen als je iets uit het grid trekt danwel iets in het grid stopt.
Geen idee hoe dat werkt maar ik neem aan (!) dat al die stroom ook direct in het grid gestopt kan worden zonder de accu op te laden?

Neem, in principe niet. Alleen als ie vol is of leeg is ben ik achter.

[ctrl-tab]

ppaulv schreef op vrijdag 22 mei 2026 @ 14:46:
[...]

ehh .. nee .... als de prijs (voldoende) negatief is, is het beter qua euro's om je panelen volledig uit te schakelen en je accu vol te gooien met stroom uit het net waar je dan ook nog eens voor betaald wordt.
Het is juist inkomstenderving als je in die situatie je panelen gebruikt om je accu te laden.

Alleen in het schemergebiedje waar de kale prijs negatief is maar niet negatief genoeg om de te maken kosten (belastingen en leverancierskosten) goed te maken, dan zou je in het ideale geval wèl je panelen willen gebruiken om je accu te laden maar niets willen terugleveren in het grid. Leveren aan het grid kost dan een beetje en gebruiken uit het grid ook.
Uiteindelijk hebben we het dan over een paar centen per kWh dus of dat nou zoveel moeite waard is... ? En ja, in een recent verleden heb ik daar veel energie in gestoken maar achteraf gezien had ik beter iets anders kunnen gaan doen. Op het leuke leereffect na.

Dan moet inkoop ook negatief zijn. Ik doel op het feit dat er meer negatieve teruglever momenten komen.

[ppaulv]

ctrl-tab schreef op vrijdag 22 mei 2026 @ 20:03:
[...]


Dan moet inkoop ook negatief zijn. Ik doel op het feit dat er meer negatieve teruglever momenten komen.

Je bedoelt de komende zomermaanden? Ja dat zeker. De komende jaren ..... hang er vanaf. Als het gebruik van accu's enorm gaat toenemen (zou zomaar kunnen in een land waar we nogal 'zunig' zijn), inclusief het gebruik van auto's als nivellerend middel (zie ik helemaal zitten), zouden de grote pieken zomaar wat minder kunnen worden in de toekomst. Maar dat gaan we vanzelf meemaken
En dan zou het best kunnen dat een deel van de huidige automatisering gewoon niet meer nodig is / handel via de accu te weinig gaat opleveren.

[ Voor 10% gewijzigd door ppaulv op 22-05-2026 20:58 ]

[ctrl-tab]

ppaulv schreef op vrijdag 22 mei 2026 @ 20:56:
[...]

Je bedoelt de komende zomermaanden? Ja dat zeker. De komende jaren ..... hang er vanaf. Als het gebruik van accu's enorm gaat toenemen (zou zomaar kunnen in een land waar we nogal 'zunig' zijn), inclusief het gebruik van auto's als nivellerend middel (zie ik helemaal zitten), zouden de grote pieken zomaar wat minder kunnen worden in de toekomst. Maar dat gaan we vanzelf meemaken
En dan zou het best kunnen dat een deel van de huidige automatisering gewoon niet meer nodig is / handel via de accu te weinig gaat opleveren.

Nee ik doel op einde saldering. Waarna je ook met een dynamisch contract enkel marktprijs met eventueel opslag terug krijg,.zonder btw en energiebelasting.
Morgen zou die prijs voor zonneplan naar -0,015 (verkoop) cent duiken om 13:00, terwijl dat nu nog 0,096 cent is (inkoop/verkoop).

[hemertje]

@gast777

Monitor resultaten Node-RED proxy — 16 t/m 22 mei

Ik laat sinds 16 mei een scriptje draaien op mijn MacBook dat elke 30 seconden twee dingen meet: hoe snel de drie Zendures zelf reageren op een ping, én hoe snel de Node-RED proxy antwoordt. In totaal zijn dat bijna 6.900 metingen over zeven dagen.

Wat komt eruit?

Dag	Metingen	OK (<100ms)	Traag (100ms–5s)	Timeout (>5s)
16 mei	588	519 (88%)	56	13
17 mei	1091	970 (89%)	119	2
18 mei ← proxy update	1469	1393 (95%)	76	0
19 mei	799	652 (82%)	142	5
20 mei	769	609 (79%)	153	7
21 mei	829	680 (82%)	143	6
22 mei	1359	1195 (88%)	160	4

De proxy update van 18 mei heeft duidelijk geholpen: dat was de beste dag met 95% snelle responses en voor het eerst nul harde timeouts. Daarna kruipt het aantal trage responses (tussen 100ms en 5 seconden) langzaam weer omhoog naar zo'n 140–160 per dag. De harde timeouts blijven wel laag op 4–7 per dag.

Wat betreft de Zendures zelf: die reageren bij elke meting gewoon netjes op 5 tot 15 milliseconde, ook op het moment dat de proxy vastloopt. Het probleem zit dus echt in de proxy en niet in het netwerk of de apparaten.

Alle harde timeouts duren precies 5,0 seconden — dat is de grens die ik in mijn meetscript heb ingesteld. De proxy geeft dan geen foutmelding, hij reageert gewoon helemaal niet. Geen TCP-fout, de verbinding blijft gewoon open hangen totdat ik hem afbreek.

Mijn vermoeden is dat Node.js af en toe even vastloopt met iets anders — garbage collection of een zware berekening — waardoor binnenkomende verzoeken in de wacht worden gezet. Niet lang genoeg voor een complete crash, maar genoeg om een poll te missen. Ik ga nog kijken of de trage momenten samenvallen met actieve laadcycli, want dan komen er meer commando's tegelijk richting de Zendures.

Monitor draait verder.

[hemertje]

DrNickB schreef op zondag 17 mei 2026 @ 10:09:
[...]

Kan het zijn dat ik in je code, wat daadwerkelijke acties mis naar de zendure toe? of lees ik er zwaar over heen.

Zelf gebruik ik de zelfde structuur, echter in uw code (met gebruikers) kun je de aan/uit waardes zo in stellen dat hij nooit aan gaat of nooit uit gaat

@DrNickB

Goede vragen, even punt voor punt:

Acties naar de Zendure
Die zitten er wel in, maar indirect — de switch.zendure_x_offgrid_socket is de offgrid socket van de Zendure zelf, aangestuurd via de Gielz/gast777 integratie. De ventilator hangt aan die socket, dus switch.turn_on op die entity is de actie naar de Zendure. Er is geen directe API-call nodig, de integratie doet dat onder de motorkap.

Nooit aan / nooit uit door verkeerde thresholds
Hier heb je een punt. Er zit geen validatie in die voorkomt dat je temp_on lager instelt dan temp_off. Als je dat doet — zeg temp_on 30°C en temp_off 35°C — gaat de fan aan zodra de temperatuur boven de 30 komt, maar de UIT-trigger vuurt meteen ook want de temp is al onder de 35. Je krijgt dan een oscillatie of de fan gaat direct weer uit. Omgekeerd, temp_on 40 en temp_off 40, en hij gaat nooit uit want below 40 triggert nooit als hij op 40 staat.

Ik had daar een condition op kunnen zetten die checkt of temp_on daadwerkelijk hoger is dan temp_off voor de automation vuurt, maar dat heb ik weggelaten om de code simpel te houden.

Goede aanvulling — hoe los jij dat in jouw versie op?

[ctrl-tab]

Vreemd fenomeen, available energy dropte gisteren plots ( als gevolg hiervan stopte mijn discharge, ik heb hier een trigger op)

Zeer waarschijnlijk gevolg van gemiste get requests. Kan dit kloppen/is dit gewenst gedrag?
Laatste gielz + proxy, 2x 2400 ac.

[ctrl-tab]

ctrl-tab schreef op vrijdag 22 mei 2026 @ 21:03:
[...]


Nee ik doel op einde saldering. Waarna je ook met een dynamisch contract enkel marktprijs met eventueel opslag terug krijg,.zonder btw en energiebelasting.
Morgen zou die prijs voor zonneplan naar -0,015 (verkoop) cent duiken om 13:00, terwijl dat nu nog 0,096 cent is (inkoop/verkoop).

Ter illustratie .

2026 inkoop/verkoop: 0.096/0.096

2027 inkoop/verkoop: 0.096/-0.015

[gielz]

ctrl-tab schreef op zaterdag 23 mei 2026 @ 05:38:
Vreemd fenomeen, available energy dropte gisteren plots ( als gevolg hiervan stopte mijn discharge, ik heb hier een trigger op)

Zeer waarschijnlijk gevolg van gemiste get requests. Kan dit kloppen/is dit gewenst gedrag?
Laatste gielz + proxy, 2x 2400 ac.[Afbeelding]

[Afbeelding]

Een gemiste get/post is altijd mogelijk en zo te zien zeer minimaal bij jou.

Ik zou iig dat soort automation triggers aanpassen naar “veranderd voor xx seconden”. Dan zal je automation niet direct triggeren.

[ctrl-tab]

gielz schreef op zaterdag 23 mei 2026 @ 06:19:
[...]


Een gemiste get/post is altijd mogelijk en zo te zien zeer minimaal bij jou.

Ik zou iig dat soort automation triggers aanpassen naar “veranderd voor xx seconden”. Dan zal je automation niet direct triggeren.

Thanks, dit heb ik ook gedaan.

Enige dat ik me afvraag is, zou de counter inderdaad naar 0 moeten gaan in zo'n geval? Lijkt me geen correcte afhandeling - if so ?

[Henkoes]

zou de batterij voltage health voor alle batterijen beschikbaar kunnen komen? Ipv alleen voor de 6?

[remcoXP]

ik zie nu dat de spread indicatie heeft historie heeft en op 0 staat. hebben jullie daar ook last van?

sorry

[ Voor 7% gewijzigd door remcoXP op 23-05-2026 10:07 ]

[gast777]

TBird484 schreef op vrijdag 22 mei 2026 @ 11:08:
@gast777 Bij het upgraden van de proxy heb ik altijd de NR flow opnieuw geimporteerd, de oude weggegooid en de nieuwe daarna gedeployed. Dat gaat en ging probleemloos. Maar ik wil nu een probleem analyseren en gebruik maken van het dashboard. Binnen flowfuse lijkt het erop dat niet alles wordt opgeruimd en krijg ik de volgende foutmelding.

[Afbeelding] Wat is de juiste upgrade manier om dit issue te voorkomen ?

Goede vraag. Dit is inderdaad nog even een dingetje, vanwege hoe het Dashboard 2 werkt.

Dit zijn de stappen bij upgraden om dit 100% goed te krijgen:

1) Zet je Gielz op modus Standby.

2) delete de oude proxy flow

3) Ga naar Config Nodes (het tandwieltje). Daar zie je een aantal grijze nodes.




4) Delete al deze grijze nodes. Dubbel-click daarvoor op al deze grijze nodes en kies Delete.



5) Click op 'Deploy'

6) Importeer je nieuwe proxy flow

7) Zet je IP adressen weer in de flow node "Vul hier de Zendure IP adressen in".

8) Click op 'Deploy'

[ Voor 3% gewijzigd door gast777 op 23-05-2026 15:40 ]

[ppaulv]

ctrl-tab schreef op zaterdag 23 mei 2026 @ 05:56:
[...]

Ter illustratie .

2026 inkoop/verkoop: 0.096/0.096

2027 inkoop/verkoop: 0.096/-0.015

[Afbeelding]

[Afbeelding]

Ehhh ... dan wellicht even voor de heel erg blonde mensen hier (ikzelf iig, blijkbaar heb ik ergens iets gemist) : als ik nu al een dynamisch contract zou hebben (heb ik niet) is toch nu ook al
de inkoopprijs = marktprijs + belasting + leveranciersvergoeding (dit betaal je)
en verkoopprijs = - marktprijs + belasting + leveranciersvergoeding (dit krijg je)?
Dus belasting en leveranciersvergoeding betaal je altijd, alleen de marktprijs krijg je of betaal je.
Wat heb ik hier verkeerd begrepen ?

[GHorsie]

ctrl-tab schreef op donderdag 21 mei 2026 @ 22:54:
[...]


Gratis bestaat niet. In plaats van terugleveren vang je de stroom nu op (import). Je kiest ervoor om niet voor 13 cent terug te leveren maar om die goedkope stroom op te slaan. Dus die kilowat kost je 13 cent op dat moment.
Daarna compenseer je je verbruik met de batterij tegen 30 cent per kilowat. Dus dat is in feite winst.

Als je een dynamisch contract hebt is dit op dit moment ongeveer 1-op-1.
Straks ligt het anders.

Nu wi ik die integratie ook gebruiken en heb ik dus die "aansturing" sensor ingesteld en een waarde die ik voor een kWh moet betalen. Maar als ik jouw opmerking goed begrijp zou ik niet het bedrag moeten invullen wat ik betaal voor een kWh maar een verschil?

Ik lever niet meer terug dan dat ik gebruik per jaar dus is het wat lastiger voor mij te begrijpen

Wat zou ik in moeten stellen bij de kosten?

[Aardedraadje]

ppaulv schreef op zaterdag 23 mei 2026 @ 12:31:
[...]

Ehhh ... dan wellicht even voor de heel erg blonde mensen hier (ikzelf iig, blijkbaar heb ik ergens iets gemist) : als ik nu al een dynamisch contract zou hebben (heb ik niet) is toch nu ook al
de inkoopprijs = marktprijs + belasting + leveranciersvergoeding (dit betaal je)
en verkoopprijs = - marktprijs + belasting + leveranciersvergoeding (dit krijg je)?
Dus belasting en leveranciersvergoeding betaal je altijd, alleen de marktprijs krijg je of betaal je.
Wat heb ik hier verkeerd begrepen ?

Door salderen krijg je nu energiebelasting nog terug. Straks niet meer.

[ppaulv]

Aardedraadje schreef op zaterdag 23 mei 2026 @ 12:59:
[...]

Door salderen krijg je nu energiebelasting nog terug. Straks niet meer.

aha, dat is het gat in m'n redenering. Dank hiervoor!
Als ik dan uitga van de Nordpool prijzen die ik via Gielz beschikbaar heb, wat zit daar dan wel / niet al in verwerkt? Ik kan wel gaan reverse-engineren op basis van jouw plaatjes (of andere plaatjes) maar dat blijft een gok. Ik vermoed dat het de kale marktprijs is, maar wat zie ik dan in die grafiek? Zijn de zaken als BTW en belasting en vergoeding (die ik ergens anders, weet zogauw niet meer waar) heb ingevuld daar dan in verwerkt?

[jannus66]

Waar staat ’deploy’ voor?

Wat moet ik dan doen?

[koboy]

ppaulv schreef op zaterdag 23 mei 2026 @ 12:31:
[...]

Ehhh ... dan wellicht even voor de heel erg blonde mensen hier (ikzelf iig, blijkbaar heb ik ergens iets gemist) : als ik nu al een dynamisch contract zou hebben (heb ik niet) is toch nu ook al
de inkoopprijs = marktprijs + belasting + leveranciersvergoeding (dit betaal je)
en verkoopprijs = - marktprijs + belasting + leveranciersvergoeding (dit krijg je)?
Dus belasting en leveranciersvergoeding betaal je altijd, alleen de marktprijs krijg je of betaal je.
Wat heb ik hier verkeerd begrepen ?

Dat het bij dynamische leveranciers met zo'n bende aan het worden is als bij vast/variabel.

Bij correct toepassen van het salderen moet namelijk ook de leveranciers vergoeding worden terugbetaald, maar niet alle leveranciers doen dat. Buiten het te salderen deel is er volgens mij nog maar 1 leverancier die ook dan de vergoeding uitbetaald. Zie hiervoor het dynamische tarieven topic.

[ Voor 3% gewijzigd door koboy op 23-05-2026 14:14 ]

[ctrl-tab]

GHorsie schreef op zaterdag 23 mei 2026 @ 12:45:
[...]

Nu wi ik die integratie ook gebruiken en heb ik dus die "aansturing" sensor ingesteld en een waarde die ik voor een kWh moet betalen. Maar als ik jouw opmerking goed begrijp zou ik niet het bedrag moeten invullen wat ik betaal voor een kWh maar een verschil?

Ik lever niet meer terug dan dat ik gebruik per jaar dus is het wat lastiger voor mij te begrijpen

Wat zou ik in moeten stellen bij de kosten?

Je moet een sensor ingeven doe representatief is voor jouw prijs. Dat hangt van aanbieder en type contract af (dynamisch of vast).

Bij zonneplan heb ik 1 kostensensor.. Dat klopt niet 100% want als ik de batterij na zonsondergang leeg krijg ik geen zonnebonus. Maar dat loopt wel los verder qua afwijking.

[gast777]

jannus66 schreef op zaterdag 23 mei 2026 @ 13:56:
Waar staat ’deploy’ voor?

Wat moet ik dan doen?

Dat is op de grote rode 'Deploy' knop drukken, rechtsboven.

[jannus66]

gast777 schreef op zaterdag 23 mei 2026 @ 14:42:
[...]

Dat is op de grote rode 'Deploy' knop drukken, rechtsboven.

Dank.

[TBird484]

gast777 schreef op zaterdag 23 mei 2026 @ 10:45:
[...]

Goede vraag. Dit is inderdaad nog even een dingetje, vanwege hoe het Dashboard 2 werkt.

Dit zijn de stappen bij upgraden om dit 100% goed te krijgen:

Top, Dashboard 2 werkt nu weer

Nog even een andere vraag, binnen Gielz staat automatic SOC Protection enabled. Als het percentage dan onder de ingestelde ondergrens komt, dan komt vanuit Gielz het commando laden met 1200W. Volgens mij heeft de proxy geen inzicht in het doel en behandeld dit als een standaard laadcommando. Ik had dus twee setje die onder de minimale SOC zaten en de proxy maakte daar dus 2 x 600W van. Wat je denk ik eigenlijk zou willen is dat beide setjes met 1200W geladen zouden worden. Klopt mijn aanname ?

[gast777]

TBird484 schreef op zaterdag 23 mei 2026 @ 17:00:
[...]

Top, Dashboard 2 werkt nu weer

Nog even een andere vraag, binnen Gielz staat automatic SOC Protection enabled. Als het percentage dan onder de ingestelde ondergrens komt, dan komt vanuit Gielz het commando laden met 1200W. Volgens mij heeft de proxy geen inzicht in het doel en behandeld dit als een standaard laadcommando. Ik had dus twee setje die onder de minimale SOC zaten en de proxy maakte daar dus 2 x 600W van. Wat je denk ik eigenlijk zou willen is dat beide setjes met 1200W geladen zouden worden. Klopt mijn aanname ?

Klopt, de proxy geeft gewoon de opdrachten van Gielz door aan de Zendures. De Proxy geeft als laadpercentage van de 'virtuele Zendure' het gemiddelde van de Laadpercentages van de twee Zendures door. Als dat onder het minimum ingestelde komt (bijv 10%), dan zal Gielz de laadopdracht geven Laden met 1200 W. Als 1 Zendure onder het minimum is zal die de 1200 W toebedeeld krijgen. Als beide eronder zitten, wordt het verdeeld.

Maakt het vermogen uit voor de SoC protectie? Als hij maar weer een beetje oplaadt tot het minimum is alles wat nodig is, zou ik denken. Misschien mis ik iets?

In ieder geval zal de proxy nooit als Gielz zegt "1200W laden", voor 2400W laden in totaal aan opdracht geven.

[TBird484]

gast777 schreef op zaterdag 23 mei 2026 @ 17:09:
[...]

Maakt het vermogen uit voor de SoC protectie? Als hij maar weer een beetje oplaadt tot het minimum is alles wat nodig is, zou ik denken. Misschien mis ik iets?

Geen idee, dat moeten we aan @gielz vragen waarom hij 1200W heeft ingesteld en of dat belangrijk is.

[specialkdk]

Misschien is het antwoord al gegeven, maar ik raak er met de zoekfunctie niet uit. Ik heb sinds kort een 2400AC+ batterij en ik stuur die aan via Home Assistant, met de Zendure integration (dus via API) voor de communicatie, en Battery SmartFlow AI voor de sturing. Dat werkt, maar eigenlijk hoop ik dat het nog ietsje sneller kan door die API er tussenuit te halen. Belangrijk om weten: mijn HA draait niet lokaal maar in een datacenter; ik heb een VPN tunnel naar dat netwerk zodat ik HA rechtstreeks kan bereiken (via het private IP dat die in het datacenter heeft) maar tenzij ik port forwards instel kan HA niet rechtstreeks aan devices in mijn netwerk. Voor MQTT maakt dat niet uit; als MQTT broker gebruik ik Mosquitto op HA. Maar de SDK gebruiken is dus niet handig want HA kan in principe niet aan de batterij.

Mijn batterij verbindt met de MQTT broker en ik heb de relevante entities gedefinieerd; dat werkt allemaal prima. Maar: als ik bv via MQTT de OutputLimit aanpas, wordt die enkele seconden later door de batterij overschreven ipv dat de batterij die parameter aanpakt. Ik veronderstel dat de batterij conflicterende informatie via de cloud binnenkrijgt, maar ik heb de communicatie richting cloud al eens volledig geblokkeerd en dan nog blijf ik dat probleem hebben. HEMS integratie staat uiteraard al uit. Ik heb ook ergens de suggestie gezien om mqtteu.zen-iot.com op DNS niveau om te leiden naar mijn eigen MQTT server zodat de batterij DENKT dat ze met de cloud verbonden is, maar dat werkt niet want de batterij lust mijn self-signed certificaat niet.

In de Zendure integratie in HA kan je wisselen tussen Connection mode Cloud of ZenSDK, maar dat maakt geen verschil. Dus: kan iemand mij zeggen wat ik waar moet uitzetten zodat de batterij ENKEL nog luistert naar mijn MQTT commando's?

[gielz]

TBird484 schreef op zaterdag 23 mei 2026 @ 17:26:
[...]

Geen idee, dat moeten we aan @gielz vragen waarom hij 1200W heeft ingesteld en of dat belangrijk is.

Het vermogen 1200 is er alleen maar om ervoor te zorgen dat je niet onnodig veel gaat bijladen. Nu zal dit wel iets efficiënter zijn op 1200 watt dan 2x 600 watt of 3x 400 watt maar dit is verwaarloosbaar.

[Mscroos]

Ik heb weer gehad dat ik een tijdje geen aansturing heb gehad van @gielz via @gast777 proxy. Begrijp niet wat er gebeurd. Vanavond overigens de laatste versie van de proxy geïnstalleerd (draaide tot vanavond op 20260509). Wellicht gevraagd die zich anders...

Wat ik zag was een drop afgelopen nacht naar 0 export van de zendure. Dit is in het eerste snapshot te zien. Het grijze stuk in de grafiek geeft aan dat er wel data binnenkomt van het verbruik.




Ook direct naar de data van de P1 en de netwerk verbinding gekeken. P1 data komt gewoon binnen. en de netwerk kwaliteit is goed of excellent. Tussen ongeveer 2.30 en 3.10 kan je zien dat er wel P1 data is maar dat de accu op 0 blijft staan...




In de logs gezocht naar wat er gebeurd kan zijn.. de discharging is naar 0 gezet door Gielz om 2.26




En daarna pas weer aan om 3.07... ervoor nog een melding van standby dus de automatisering liep wel neem ik aan...



Iemand een idee???

[ Voor 3% gewijzigd door Mscroos op 23-05-2026 23:16 ]

[gast777]

Vreemd. Hoe staat je "Ontladen Starten Bij" / "Start Discharge At" waarde?

[Mscroos]

gast777 schreef op zondag 24 mei 2026 @ 07:36:
Vreemd. Hoe staat je "Ontladen Starten Bij" / "Start Discharge At" waarde?

@gielz die staat op -500, na je vraag ben ik verder gaan inzoomen op het moment dat dit begint om te begrijpen wat het gedrag is.

Hij staat bij het begin moment netjes NoM te draaien, krijgt een piek in verbruik. Tijdens het opschakelen valt de piek weg, Gaat weer naar mijn nacht verbruik van 450 watt, en schakelt nooit meer aan omdat deze onder de 500 zit.

De geleerde les is dat ik mijn discharge moet instellen onder het basis nacht verbruik.

Wat ik wel interessant vind is dat ik dit nog niet eerder heb meegemaakt, waarom schakelt hij midden in de piek eerst naar 0 en daarna gaat hij weer omhoog schakelen, piek is weg en dan weer naar 0. Andere pieken die ik heb gehad schakelen eigenlijk altijd meer op en neer zonder naar 0 te gaan.




Een piek met “normaal” gedrag deze schakelt niet eerst naar 0

[pasmanm]

Venimk1 schreef op dinsdag 19 mei 2026 @ 19:26:
[...]

Mijn batterij blijft gewoon op standby staan ????

Dit script is puur bedoeld om de maximale laadstroom te beperken.

De laadmodus moet je zelf instellen als 'nul op de meter'.

​P.S. ik heb weer wat wijzigingen, een update van dit script volgt binnenkort.

[gast777]

Mscroos schreef op zondag 24 mei 2026 @ 08:42:
[...]

De geleerde les is dat ik mijn discharge moet instellen onder het basis nacht verbruik.

Wat ik wel interessant vind is dat ik dit nog niet eerder heb meegemaakt, waarom schakelt hij midden in de piek eerst naar 0 en daarna gaat hij weer omhoog schakelen, piek is weg en dan weer naar 0. Andere pieken die ik heb gehad schakelen eigenlijk altijd meer op en neer zonder naar 0 te gaan.

Mooi dat dat inderdaad de oorzaak was. Het begon met een hoge piek in verbruik. Dan gaat de Zendure deze compenseren door veel meer te leveren. Toen de piek in vraag plotseling ophield, had het een beetje tijd nodig voor de Zendure om weer omlaag te gaan met het vermogen. Tijdens zo'n verandering kan het berekende gevraagde vermogen wel eens een beetje onnauwkeurig worden en richting nul gaan. En daarna bleef het gevraagde vermogen dus onder het minimum waarop je startte te leveren.

Oplossing is dus simpel, zoals je al door had: zet het "Ontladen Starten Bij" / "Start Discharge At" op een waarde die lager is dan je nachtverbruik. Anders heb je de kans dat als hij even stopt, dat hij niet meer start.

[Korvaag]

Korvaag schreef op dinsdag 19 mei 2026 @ 07:48:
@gielz Ik zie nog wel wat raars gebeuren. Misschien dat jij tips hebt. Ik ben zelf (nog) niet ervaren genoeg om dit te debuggen.

Even een korte schets:
- Ik heb twee merken accu's: Ecoflow en Zendure, beide units 4kWh
- Ecoflow doet NOM en Zendure dynamisch handelen

Wat ik nu zie is het volgende. Ik heb duurst / goedkoopste uren allebei op 4 uur ingesteld (heb een SF800 Pro dus die kan maar met 800W ontladen en 1000W laden wat dus grofweg 4 uur laden en ontladen is).

De grafiek geeft netjes weer dat bv vandaag duurste uren zijn om 6:00 en dan vanmiddag om 19:00 - 21:00. Lijkt prima te kloppen met ook andere apps/sensors zoals de app EnergyPricing of m'n Budget Energie app

Echter als ik dan kijk hoe laat de accu vanochtend is gaan ontladen: van 4:00 - 5:00. Dat is twee uur te vroeg. Het viel me gisteren ook al op met laden maar dat heb ik even genegeerd omdat ik dacht dat alle sensoren/grafieken nog moesten 'settelen' (lees: volledige sets aan waardes hebben voor 24 uur).

Ik heb uiteraard wel een vermoeden wat er mis gaat:
- Er gaat iets mis met timezones?
- Er gaat iets mis in de originele Nordpool sensor met omrekenen (maar waarom geeft de grafiek het dan wel goed weer)

M'n Home Assistant staat netjes op Amsterdam GMT+1. Language staat wel op Engels. Ik zie dit gedrag niet met andere automations. Ik heb bv ook AIO energy management en die schakelt wel op de juiste tijden.

Jij slimme tips?

edit:
iemand anders gevonden in het topic die het ook heeft maar zonder oplossing. Ik heb een clock toegevoegd aan een dashboard en deze staat netjes op 10:01 AM momenteel (ook moment van deze eerste edit). Timezone in settings staat goed, timezone in user staat goed en timezone in docker stack staat goed. Allemaal Europe/Amsterdam enzo.
Ook een testje gedaan met een template sensor met daarin {{ now() }} en dit geeft ook een voor mijn gevoel correcte waarde: 2026-05-20 12:15:00.333648+02:00 (en ik tik dit dus om 12:15).

Omdat ik mijn originele post niet meer mag editten even zo:

De oplossing van iemand anders in dit Topic heeft bij mij ook gewerkt: helaas niet gewerkt
- Backup maken
- Docker container weggooien en volume ook weggooien
- Home Assistant opnieuw deployen
- Bij eerste benadering van de nieuwe install een backup terugzetten.

Raadselachtig, maar het lijkt te werken. Ik weet 90% zeker dat het probleem nu weg is maar ik moet het volgende schakelmoment nog even afwachten om het voor de volle 100% te weten.

edit:
Helaas. Nog niet gerepareerd. De accu stopte net met laden ondanks dat volgens de grafiek de goedkoopste uren nog bezig waren. Wederom 2 uur te vroeg schakelend. Ik heb geen idee meer wat dit kan zijn.

Gefixed volgens mij. @ctrl-tab Mijn issue zat volgens mij in jouw template (niet lullig bedoeld). Jouw sensor berekent de raw_today en raw_tomorrow niet correct qua timezone. Ik heb jouw code deels aangepast:

YAML:

          raw_today: >
            {% set opslag = states('input_number.energy_opslag') | float(0) %}
            {% set vat    = states('input_number.energy_vat')    | float(0) %}
            {% set tax    = states('input_number.energy_tax')    | float(0) %}
            {% set data = namespace(prices=[], group=[], starts=[], ends=[]) %}
            {% if today_price is mapping %}
              {% for state in today_price['NL'] %}
                {% set p = ((state.price / 1000 + tax + opslag) * (1 + vat)) | round(5) %}
                {% set data.group = data.group + [p] %}
                {% if data.group | count == 1 %}
                  {# MODIFIED: Converts UTC string to a local string format #}
                  {% set local_start = (state.start | as_datetime | as_local).isoformat() %}
                  {% set data.starts = data.starts + [local_start] %}
                {% endif %}
                {% if data.group | count == 4 %}
                  {# MODIFIED: Converts end UTC string to local string format #}
                  {% set local_end = (state.end | as_datetime | as_local).isoformat() %}
                  {% set data.prices = data.prices + [{'start': data.starts[-1], 'end': local_end, 'value': (data.group | sum / 4) | round(5)}] %}
                  {% set data.group = [] %}
                {% endif %}
              {% endfor %}
            {% endif %}
            {{ data.prices }}
          raw_tomorrow: >
            {% set opslag = states('input_number.energy_opslag') | float(0) %}
            {% set vat    = states('input_number.energy_vat')    | float(0) %}
            {% set tax    = states('input_number.energy_tax')    | float(0) %}
            {% set data = namespace(prices=[], group=[], starts=[], ends=[]) %}
            {% if tomorrow_price is mapping %}
              {% for state in tomorrow_price['NL'] %}
                {% set p = ((state.price / 1000 + tax + opslag) * (1 + vat)) | round(5) %}
                {% set data.group = data.group + [p] %}
                {% if data.group | count == 1 %}
                  {# MODIFIED: Converts UTC string to a local string format #}
                  {% set local_start = (state.start | as_datetime | as_local).isoformat() %}
                  {% set data.starts = data.starts + [local_start] %}
                {% endif %}
                {% if data.group | count == 4 %}
                  {# MODIFIED: Converts end UTC string to local string format #}
                  {% set local_end = (state.end | as_datetime | as_local).isoformat() %}
                  {% set data.prices = data.prices + [{'start': data.starts[-1], 'end': local_end, 'value': (data.group | sum / 4) | round(5)}] %}
                  {% set data.group = [] %}
                {% endif %}
              {% endfor %}
            {% endif %}
            {{ data.prices }}

[ Voor 40% gewijzigd door Korvaag op 24-05-2026 18:52 ]

[Venimk1]

pasmanm schreef op zondag 24 mei 2026 @ 10:06:
[...]


[...]

heb hier zelf ook beetje aanpassingen gedaan, zodat ze toch sneller is opgeladen..

code:

alias: "Zendure: Agressief Solar Laden"
description: >-
  Agressievere versie van Slim Solar Laden. Laadt de batterij maximaal op met al
  het surplus boven het huisverbruik. Doel: 100% voor 16:00. Minimaal 800W, max
  2400W. Schakel deze UIT en de originele IN om terug te wisselen.
triggers:
  - minutes: /15
    trigger: time_pattern
conditions:
  - above: 100
    condition: numeric_state
    entity_id: sensor.sb3_0_1av_41_674_pv_power
  - condition: not
    conditions:
      - condition: state
        entity_id: automation.zendure_happy_hours_tijdelijk_laadvermogen
        state: "on"
        for:
          minutes: 0
      - condition: time
        after: "11:00:00"
        before: "16:00:00"
actions:
  - variables:
      eind_instelling: >-
        {% set baseload_w = 400 %}

        {% set min_laad_vermogen = 800 %}

        {% set max_laad_vermogen = 1600 %}

        {% set zendure_cap_wh = 5760 %}

        {% set zendure_huidig_perc =
        states('sensor.solarflow_2400_ac_electric_level') | float(0) %}

        {% set zendure_wh_nodig = (([100 - zendure_huidig_perc, 0] | max) / 100)
        * zendure_cap_wh * 1.1 %}

        {% set pv_now = states('sensor.sb3_0_1av_41_674_pv_power') | float(0) %}

        {% set surplus = [pv_now - baseload_w, 0] | max %}

        {% set forecasts =
        state_attr('sensor.solcast_pv_forecast_voorspelling_vandaag',
        'detailedForecast') %}

        {% set ns = namespace(slots=0) %}

        {% if forecasts is not none %}
          {% for slot in forecasts if as_datetime(slot.period_start) >= now() and as_datetime(slot.period_start) <= today_at('20:30') %}
            {% if slot.pv_estimate | float(0) * 2000 > baseload_w %}
              {% set ns.slots = ns.slots + 1 %}
            {% endif %}
          {% endfor %}
        {% endif %}

        {% set uren = [ns.slots * 0.5, 0.5] | max %}

        {% set benodigd = zendure_wh_nodig / uren %}

        {% set plafond = [benodigd, surplus, min_laad_vermogen] | max %}

        {{ [plafond | int, max_laad_vermogen] | min }}
  - action: input_number.set_value
    data:
      value: "{{ eind_instelling }}"
    target:
      entity_id: input_number.zendure_2400_ac_max_oplaadvermogen
mode: restart

[ctrl-tab]

Korvaag schreef op zondag 24 mei 2026 @ 13:41:
[...]

Gefixed volgens mij. @ctrl-tab Mijn issue zat volgens mij in jouw template (niet lullig bedoeld). Jouw sensor berekent de raw_today en raw_tomorrow niet correct qua timezone. Ik heb jouw code deels aangepast:

Vreemd, hier gaat ie wel goed. Klopt de bron wel?

[ctrl-tab]

Iemand bekend.met dit fenomeen? Gielz en lastste gast777 proxy;

Na charge vanmiddag blijft de temperatuur van invertors hangen op.40.graden..in homeassistant althans.

Nu met discharge weer een eerste meeting binnen en zakt nar werkelijke waarde.

Lijkt erop dat buiten de windows geen temperatuur binnen komt?

[Korvaag]

ctrl-tab schreef op zondag 24 mei 2026 @ 19:47:
[...]

Vreemd, hier gaat ie wel goed. Klopt de bron wel?

Ja volgens mij wel. Settings/integrations. Nordpool. Copy EntryID. Of ik moet dat deel verkeerd hebben begrepen natuurlijk.

[DrNickB]

hemertje schreef op vrijdag 22 mei 2026 @ 23:29:
[...]


@DrNickB

Goede vragen, even punt voor punt:

Acties naar de Zendure
Die zitten er wel in, maar indirect — de switch.zendure_x_offgrid_socket is de offgrid socket van de Zendure zelf, aangestuurd via de Gielz/gast777 integratie. De ventilator hangt aan die socket, dus switch.turn_on op die entity is de actie naar de Zendure. Er is geen directe API-call nodig, de integratie doet dat onder de motorkap.

Ohja dat is waar ook, ik gebruik nog een oudere versie en daar heb ik een eigen offgrid aansturing in gemaakt, die bestond toen nog niet.

hemertje schreef op vrijdag 22 mei 2026 @ 23:29:
Nooit aan / nooit uit door verkeerde thresholds
Hier heb je een punt. Er zit geen validatie in die voorkomt dat je temp_on lager instelt dan temp_off. Als je dat doet — zeg temp_on 30°C en temp_off 35°C — gaat de fan aan zodra de temperatuur boven de 30 komt, maar de UIT-trigger vuurt meteen ook want de temp is al onder de 35. Je krijgt dan een oscillatie of de fan gaat direct weer uit. Omgekeerd, temp_on 40 en temp_off 40, en hij gaat nooit uit want below 40 triggert nooit als hij op 40 staat.

Ik had daar een condition op kunnen zetten die checkt of temp_on daadwerkelijk hoger is dan temp_off voor de automation vuurt, maar dat heb ik weggelaten om de code simpel te houden.

Goede aanvulling — hoe los jij dat in jouw versie op?

Ik heb een simpele eigen automatisering met eigen ingestelde waardes, zonder invoer velden
Boven 39 graden aan, onder de 36 graden uit.

[DrNickB]

@Hippe Lip Moest toch even foto'tje doen.
Moet eigenlijk nog wat langere boutjes met moertjes erop,
en eigenlijk de pootjes in het geheel laseren voor de mooi.

[Hippe Lip]

DrNickB schreef op zondag 24 mei 2026 @ 23:13:
@Hippe Lip Moest toch even foto'tje doen.
Moet eigenlijk nog wat langere boutjes met moertjes erop,
en eigenlijk de pootjes in het geheel laseren voor de mooi.

[Afbeelding]

Fraai gemaakt, @DrNickB
Bij een 2400AC is die montage een stuk eenvoudiger dan bij een 2400AC+ zoals bij mij, omdat daar de koelribben aan de achterkant zitten. Dat betekent dat je de boel er niet zomaar op kunt leggen, maar het op moet hangen. Zie mijn plaatjes een paar pagina’s terug.

[ctrl-tab]

ctrl-tab schreef op zondag 24 mei 2026 @ 20:06:
Iemand bekend.met dit fenomeen? Gielz en lastste gast777 proxy;

Na charge vanmiddag blijft de temperatuur van invertors hangen op.40.graden..in homeassistant althans.

Nu met discharge weer een eerste meeting binnen en zakt nar werkelijke waarde.

Lijkt erop dat buiten de windows geen temperatuur binnen komt?

[Afbeelding]

@gast777 enig idee? In proxy debug logs van de zendures, zie ik wel de juiste temperaturen, nu 30 graden. In HA blijft hij op 40 graden hangen.

Het lijkt erop dat alle proxy sensoren niet actief updaten na een charge/discharge(ssmary discharge modus nu)


Als.ik.een fast charge doe,.updaten de sensoren ineens naar de juiste waarde!

[ Voor 5% gewijzigd door ctrl-tab op 25-05-2026 07:27 ]

[gielz]

Gielz TEST release

⚠️⚠️ Dutch (NL) en English (Global) versies ⚠️⚠️

Let op: bij updaten dat je de juiste versie pakt van je bestaande configuratie. Stap je over dan raak je de historie kwijt.

Volg de GitHub ⭐⭐⭐

1) Zet een Star bij de Github pagina (dan volg je hem wat altijd handig is en maakt de aansturing populairder)
2) Klik op Watch en kies waar je exact een melding van wilt krijgen. Bij Custom kun je specifiek alleen releases aanvinken.
3) Bij je profiel onder Notifications kun je aangeven of het via github zelf gaat of naar je mailbox

Release

https://github.com/Gielz1...-zenSDK/tree/Next-release
Problemen graag via DM of GitHub issue.

English (Global)

⚠️ Please make sure to use the correct language update. ⚠️

New features

PV Export Disabled
You can now use a boolean to specify whether to export the PV generation from the connected panels when the battery is full, or to prevent it instead

Mix series

sensor.zendure_total_capacity
Added correct capacity for SolarFlow 3000 Mix AC+, SolarFlow 4000 Mix AC+ and SolarFlow 4000 Mix Pro

Bug fixes

SOC Protection
When SOC protection is disabled and the battery is discharged below the minimum state of charge, Smart Matching will not start. This issue has now been fixed.

Dynamic Charging/Discharging Cycle
When the battery lost connection to the network during dynamic charging or discharging, the cycle would restart immediately. From now on, if the battery reconnects to the network within 15 seconds, the cycle will continue normally.

Dynamic Charging/Discharging Running
Sometimes after a dynamic cycle, the battery won’t switch to Smart Matching when expected. After a dynamic cycle, an extra check will be performed to verify that the cycle is completely finished.

Dynamic Lowest Price Period
When no lowest price periods were selected, this sensor generated an error message in the logbook. This issue has now been resolved.

Dutch (NL)

⚠️ Zorg ervoor dat je de juiste taalupdate gebruikt. ⚠️

Nieuwe functies

PV Export Uitgeschakeld
Je kunt nu met een boolean aangeven of je de PV-opwek van de aangesloten panelen wilt exporteren wanneer de batterij vol is, of deze juist wilt tegenhouden.

Mix series

sensor.zendure_2400_ac_totale_capaciteit
Juiste capaciteit toegevoegd voor SolarFlow 3000 Mix AC+, SolarFlow 4000 Mix AC+ and SolarFlow 4000 Mix Pro

Bug fixes

SOC Bescherming
Wanneer SOC Bescherming is uitgeschakeld en de batterij onder het minimale laadpercentage wordt ontladen, start Nul op de meter niet. Dit probleem is nu opgelost.

Dynamisch Laden/Ontladen Cyclus
Wanneer tijdens het dynamisch laden of ontladen de batterij de verbinding met het netwerk verloor werd de cyclus direct herstart. Wanneer de batterij binnen 15 seconden weer verbinding heeft met het netwerk zal de cyclus vanaf nu gewoon doorlopen.

Dynamisch Laden/Ontladen Loopt
Soms schakelt de batterij na een dynamische cyclus niet naar Nul op de meter wanneer dat verwacht wordt. Na een dynamische cyclus wordt daarom een extra controle uitgevoerd om te verifiëren dat de cyclus volledig is afgerond.

Dynamisch Goedkoopste Periode
Wanneer er geen goedkope periodes waren geselecteerd gaf deze sensor een foutmelding in het logboek. Dit probleem is nu opgelost.

[gast777]

ctrl-tab schreef op maandag 25 mei 2026 @ 07:14:
[...]

@gast777 enig idee? In proxy debug logs van de zendures, zie ik wel de juiste temperaturen, nu 30 graden. In HA blijft hij op 40 graden hangen.

Dus in de debug van de GET Responses zie je de juiste temperaturen staan. Dus ook in de GET response die naar Home Assistent gaat?

Even de debug functie showen natuurlijk






Als Home Assistant dat in jouw geval soms niet juist toont dan ligt dat in ieder geval niet aan de proxy. Die heeft de juiste data aangeleverd.

(in dit geval 3091/10 - 273.1 = 36 graden)

Edit: als je de debug naar file laat schrijven dan voegt hij ook timestamps toe (in UTC tijdzone). Dan kun je ook zien of deze data ook echt tijdens het probleem is langsgekomen.

[ Voor 7% gewijzigd door gast777 op 25-05-2026 11:46 ]

[ctrl-tab]

gast777 schreef op maandag 25 mei 2026 @ 11:35:
[...]

Dus in de debug van de GET Responses zie je de juiste temperaturen staan. Dus ook in de GET response die naar Home Assistent gaat?

Even de debug functie showen natuurlijk

[Afbeelding]

[Afbeelding]


Als Home Assistant dat in jouw geval soms niet juist toont dan ligt dat in ieder geval niet aan de proxy. Die heeft de juiste data aangeleverd.

(in dit geval 3091/10 - 273.1 = 36 graden)

Edit: als je de debug naar file laat schrijven dan voegt hij ook timestamps toe (in UTC tijdzone). Dan kun je ook zien of deze data ook echt tijdens het probleem is langsgekomen.

Dit was de temperatuur op het moment dat de zendure 1 invertor temp 40-41 aan gaf. Het ging dus specifiek om de proxy sensor.

De 'normale' gielz sensor gaf wel 30-ish aan.

hyperTmp: 3021

[remcoXP]

Volgens mij is dynamisch handelen met zonneplan dit jaar nog het meest lucratief.

Stellen jullie dit dan iedere dag handmatig in of hebben jullie er een automation voor gemaakt?

[Pakhaas]

remcoXP schreef op maandag 25 mei 2026 @ 15:43:
Volgens mij is dynamisch handelen met zonneplan dit jaar nog het meest lucratief.

Stellen jullie dit dan iedere dag handmatig in of hebben jullie er een automation voor gemaakt?

Met @gielz integratie kan dat perfect. Alleen even kort de dag ervoor kijken wanneer goedkoop en duur.

[ppaulv]

Pakhaas schreef op maandag 25 mei 2026 @ 15:57:
[...]

Met @gielz integratie kan dat perfect. Alleen even kort de dag ervoor kijken wanneer goedkoop en duur.

Daar hoef je toch niet meer naar om te kijken of vergis ik me nu?

[Pakhaas]

ppaulv schreef op maandag 25 mei 2026 @ 16:52:
[...]

Daar hoef je toch niet meer naar om te kijken of vergis ik me nu?

Je hebt niet elke dag dezelfde aantal goedkope en dure uren. Dus kijk ik per dag over hoeveel kwartieren ik kan laden en ontladen. Daar pas ik het vermogen ook wat op aan.

[ctrl-tab]

gast777 schreef op maandag 25 mei 2026 @ 11:35:
[...]

Dus in de debug van de GET Responses zie je de juiste temperaturen staan. Dus ook in de GET response die naar Home Assistent gaat?

Even de debug functie showen natuurlijk

[Afbeelding]

[Afbeelding]


Als Home Assistant dat in jouw geval soms niet juist toont dan ligt dat in ieder geval niet aan de proxy. Die heeft de juiste data aangeleverd.

(in dit geval 3091/10 - 273.1 = 36 graden)

Edit: als je de debug naar file laat schrijven dan voegt hij ook timestamps toe (in UTC tijdzone). Dan kun je ook zien of deze data ook echt tijdens het probleem is langsgekomen.

Op dit moment, zie ik in de debug modus gewoon updates van de individuele zendures.

hyperTmp: 3021 en 3031

Het ding is dat er geen enkele specifieke sensor meer door komt. Ik denk totdat ik weer daadwerkelijk ga chargen of dischargen .

Power command blijft ook.op 2400 hangen.


Zie screenshots. En last update tijden.

[Devke]

remcoXP schreef op maandag 25 mei 2026 @ 15:43:
Volgens mij is dynamisch handelen met zonneplan dit jaar nog het meest lucratief.

Stellen jullie dit dan iedere dag handmatig in of hebben jullie er een automation voor gemaakt?

1x per dag (vaak als de tarieven weer bekend zijn voor de volgende dag) kijk ik even hoe ik wil dat er geladen en ontladen wordt. Ff instellen in de gielz integratie en rennen maar.

[koboy]

ppaulv schreef op maandag 25 mei 2026 @ 16:52:
[...]

Daar hoef je toch niet meer naar om te kijken of vergis ik me nu?

De integratie kijkt simpelweg naar het aantal ingestelde uren/kwartieren dat het goedkoopste en duurste zijn, doet verder geen planning t.o.v. het laadmoment. Gaat meestal prima, maar theezakjes drogers en opnieuw gebruikers als @Pakhaas en ondergetekende passen dit dagelijks even aan om er voor te zorgen dat er geen cent verloren gaat.
Soms is het bijvoorbeeld voordeliger om een stukje ochtend piek van de dag erna te pakken, of moet er even een extra uurtje toegevoegd worden om er voor te zorgen dat de accu diezelfde dag nog tot op de laaste electronen leeg is.

[Mistraller]

@gielz Iets wat ik mij nog wel afvraag; jij hebt in je instellingen etc geen disclaimer oid als je het vermogen hoger dan 800W zet, zou dat niet verstandig zijn in de vergezochte situatie dat iemand een zondebok zoekt voor een eigengemaakte fout? Zoals in fireson met de fusegroups oid.

[gielz]

Mistraller schreef op dinsdag 26 mei 2026 @ 00:11:
@gielz Iets wat ik mij nog wel afvraag; jij hebt in je instellingen etc geen disclaimer oid als je het vermogen hoger dan 800W zet, zou dat niet verstandig zijn in de vergezochte situatie dat iemand een zondebok zoekt voor een eigengemaakte fout? Zoals in fireson met de fusegroups oid.

Welke disclaimer toont zendure ha exact?

[Mistraller]

gielz schreef op dinsdag 26 mei 2026 @ 07:29:
[...]


Welke disclaimer toont zendure ha exact?

Als je HEMS gebruikt dan moet je zoals bekend zelfs signen. In fireson dwingt het instellen van de fusegroups je al wat meer om na te denken en het staat in de uitleg op github.
https://github.com/Zendure/Zendure-HA/wiki/Fuse-Group

Dus geen verwijt hoor, maar ik verbaasde mij dat het het zomaar kan om boven de 3000W discharge in te stellen, terwijl Zendure in HEMS heel erg hun best doet om de verantwoordelijkheid bij de gebruiker te krijgen. Ik had overigens verwacht dat zoiets in de firmware vastgelegd zou worden.

Is een overweging voor jouzelf vooral om je in te dekken; een klein stukje automation met een warning indien totaal vermogen hoger dan 800 danwel 3000 (net als hems) met een helper waarin je de status van een "gezien-vinkje" bij kunt houden of zo. >800: "Dedicated groep gebruiken" >3000 "verdeel je zendures over meerdere groepen en/of fases"
Vinkje zorgt ervoor dat je het maar 1x krijgt en dan kan je niet zeggen dat je het niet gezien hebt.

[ Voor 24% gewijzigd door Mistraller op 26-05-2026 10:13 ]

[gast777]

Mistraller schreef op dinsdag 26 mei 2026 @ 10:05:
[...]

Is een overweging voor jouzelf vooral om je in te dekken; een klein stukje automation met een warning indien totaal vermogen hoger dan 800 danwel 3000 (net als hems) met een helper waarin je de status van een "gezien-vinkje" bij kunt houden of zo. >800: "Dedicated groep gebruiken" >3000 "verdeel je zendures over meerdere groepen en/of fases"
Vinkje zorgt ervoor dat je het maar 1x krijgt en dan kan je niet zeggen dat je het niet gezien hebt.

Er is al een disclaimer (of bedoel je waarschuwing?):

https://github.com/Gielz1986/Zendure-HA-zenSDK/blob/main/LICENSE

code:

4. No Warranty

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.

IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY CLAIM, DAMAGES OR
OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE
OR OTHER DEALINGS IN THE SOFTWARE.

[Mistraller]

gast777 schreef op dinsdag 26 mei 2026 @ 10:51:
[...]

Er is al een disclaimer (of bedoel je waarschuwing?):

https://github.com/Gielz1986/Zendure-HA-zenSDK/blob/main/LICENSE

code:

4. No Warranty

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.

IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY CLAIM, DAMAGES OR
OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE
OR OTHER DEALINGS IN THE SOFTWARE.

Weet ik. Maar je zou het expliciet kunnen maken. Uiteindelijk zie ik zelfs hier op tweakers mensen twijfelen of het nou echt kwaad kan om meer dan 800W in te voeden op een bestaande groep

Het is slechts een ideetje

[Gramser]

Toch weer een gek dingetje vanochtend. Torentje nummer 2 van mijn AC2400+ reageerde eigenlijk niet meer en bleef maar laden op hetzelfde wattage. Op standby zetten ging niet. Automation uitzetten en HEMS weer aan: zelfde effect. Uiteindelijk ervoor gekozen om de batterijen -beide torens dan maar- spanningloos te maken via de knop en de stekker eruit. Minuutje of wat wachten, weer aanzetten, Gielz enablen en de boel doet het weer.

Toch jammer dat daar een fysieke actie voor nodig was, maar ondertussen heb ik van de gelegenheid gebruik gemaakt om zowel Giels als gast777 even te updaten. Dat was alweer even geleden. Het zou zo jammer zijn als dit in een vakantie gebeurt en je kunt er niks mee. M.n. dat hij niet reageerde op een standby-commando is jammer. Het zou ook zomaar kunnen dat dit bij een calibratie weer goed kwam, weet ik het, maar toch. Aandacht blijft vereist.

[gast777]

ctrl-tab schreef op maandag 25 mei 2026 @ 18:46:
[...]

Op dit moment, zie ik in de debug modus gewoon updates van de individuele zendures.

hyperTmp: 3021 en 3031

Het ding is dat er geen enkele specifieke sensor meer door komt. Ik denk totdat ik weer daadwerkelijk ga chargen of dischargen .

Power command blijft ook.op 2400 hangen.

OK, die algemene en device-specifieke sensoren zitten allemaal in dezelfde GET Response. De algemene worden in de proxy code (blokje "GET Response handling") van de device-specifieke afgeleid (bijv de gemiddelde of hoogste van de waardes van de Zendures wordt genomen).

Dus als de ene wel update en de andere niet, dan is dat heel vreemd. Als de proxy de waarden correct aanlevert aan HA (kun je controleren in de debug), dan zal het toch in HA moeten zitten.

Het chargen of dischargen zou hier in principe ook niets mee te maken moeten hebben, want deze sensoren worden altijd elke seconde opgevraagd door de REST GET request, ongeacht laad/ontlaad acties/status.

Wat misschien wel zou kunnen is dat geen enkele sensor meer update vanuit deze REST GET request (ook de algemene niet). Dan is er een communicatieprobleem en komen de GET Responses niet in HA aan om een of andere reden.

Mocht dit vaker voorkomen, stuur me dan eventueel de debug file en "Geschiedenis" grafiek van HA van tijdens het probleem via DM voor wat meer troubleshooting.

[Mscroos]

gielz schreef op dinsdag 26 mei 2026 @ 07:29:
[...]


Welke disclaimer toont zendure ha exact?

@gielz

[ppaulv]

koboy schreef op maandag 25 mei 2026 @ 20:09:
[...]

De integratie kijkt simpelweg naar het aantal ingestelde uren/kwartieren dat het goedkoopste en duurste zijn, doet verder geen planning t.o.v. het laadmoment. Gaat meestal prima, maar theezakjes drogers en opnieuw gebruikers als @Pakhaas en ondergetekende passen dit dagelijks even aan om er voor te zorgen dat er geen cent verloren gaat.
Soms is het bijvoorbeeld voordeliger om een stukje ochtend piek van de dag erna te pakken, of moet er even een extra uurtje toegevoegd worden om er voor te zorgen dat de accu diezelfde dag nog tot op de laaste electronen leeg is.

ja ok, als je daar tijd in wilt stoppen dan is dat maar zo. Maar ik heb vroeger geleerd dat 'goed' ook meestal 'goed genoeg' is dus daar ga ik niet veel tijd aan spenderen als het eenmaal soepel loopt. En m'n tijd aan andere zaken besteden ....

[Pakhaas]

ppaulv schreef op dinsdag 26 mei 2026 @ 12:12:
[...]

ja ok, als je daar tijd in wilt stoppen dan is dat maar zo. Maar ik heb vroeger geleerd dat 'goed' ook meestal 'goed genoeg' is dus daar ga ik niet veel tijd aan spenderen als het eenmaal soepel loopt. En m'n tijd aan andere zaken besteden ....

Ik moet toch dagelijks kijken wanneer ik 1 van de 2 EV's ga laden. In dat zelfde moment kijk ik ook even snel naar de batterijen. Als het mij 2min kost is het veel.

[R.K]

Ik zie soms een error verschijnen en dan verwijst HA naar de Zendure app, daar kan ik echter niets vinden, iemand een idee wat voor melding dit is en waar in de Zendure app ik dat terug kan vinden?

[Mistraller]

Gramser schreef op dinsdag 26 mei 2026 @ 11:12:
Toch weer een gek dingetje vanochtend. Torentje nummer 2 van mijn AC2400+ reageerde eigenlijk niet meer en bleef maar laden op hetzelfde wattage. Op standby zetten ging niet. Automation uitzetten en HEMS weer aan: zelfde effect. Uiteindelijk ervoor gekozen om de batterijen -beide torens dan maar- spanningloos te maken via de knop en de stekker eruit. Minuutje of wat wachten, weer aanzetten, Gielz enablen en de boel doet het weer.

Toch jammer dat daar een fysieke actie voor nodig was, maar ondertussen heb ik van de gelegenheid gebruik gemaakt om zowel Giels als gast777 even te updaten. Dat was alweer even geleden. Het zou zo jammer zijn als dit in een vakantie gebeurt en je kunt er niks mee. M.n. dat hij niet reageerde op een standby-commando is jammer. Het zou ook zomaar kunnen dat dit bij een calibratie weer goed kwam, weet ik het, maar toch. Aandacht blijft vereist.

Ik denk dat de webserver in de zendure niet altijd helemaal stabiel is. Post requests die niet meer verwerkt worden oid.

[Gramser]

Mistraller schreef op dinsdag 26 mei 2026 @ 13:00:
[...]

Ik denk dat de webserver in de zendure niet altijd helemaal stabiel is. Post requests die niet meer verwerkt worden oid.

Hmmm toch jammer dat je dan thuis moet zijn om dat te verhelpen. Of is er iets waarmee je ‘m weer wakker schudt en normaal laat doen..?

[Pakhaas]

Gramser schreef op dinsdag 26 mei 2026 @ 13:02:
[...]

Hmmm toch jammer dat je dan thuis moet zijn om dat te verhelpen. Of is er iets waarmee je ‘m weer wakker schudt en normaal laat doen..?

Je buren die de planten water geven ook leren hoe ze de batterij kunnen resetten 😅

[Gramser]

Pakhaas schreef op dinsdag 26 mei 2026 @ 13:03:
[...]

Je buren die de planten water geven ook leren hoe ze de batterij kunnen resetten 😅

Mijn buren kennende resetten ze de planten en geven de de batterijen water - ik pas

[Mistraller]

Gramser schreef op dinsdag 26 mei 2026 @ 13:02:
[...]

Hmmm toch jammer dat je dan thuis moet zijn om dat te verhelpen. Of is er iets waarmee je ‘m weer wakker schudt en normaal laat doen..?

misschien met een fingerbot het knopje laten indrukken

Het staat op de wishlist kennelijk. https://forum.zendure.com/d/13961

[Gramser]

Ik wacht de ontwikkelingen wel af 😆

[gast777]

R.K schreef op dinsdag 26 mei 2026 @ 12:50:
Ik zie soms een error verschijnen en dan verwijst HA naar de Zendure app, daar kan ik echter niets vinden, iemand een idee wat voor melding dit is en waar in de Zendure app ik dat terug kan vinden?[Afbeelding]

Dit gaat blijkbaar over de "Zendure 2400 AC Error" (niet te zien in je screenshot)?

YAML:

      - name: "Zendure 2400 AC Error"
        value_template: >
          {% set states = {0: "Geen meldingen", 1: "Zie Zendure APP"} %}
          {% set packState = value_json['properties']['is_error'] | int %}
          {{ states.get(packState, "Onbekend") }}
        unique_id: Zendure_2400_AC_Error
        icon: mdi:battery-alert

Dan geeft je zendure aan dat er een error is. Property "is_error" heeft waarde "1".

Meer weet HA ook niet, dus is de hoop dat de Zendure App meer informatie over de error zal geven.

[ctrl-tab]

Mistraller schreef op dinsdag 26 mei 2026 @ 13:10:
[...]

misschien met een fingerbot het knopje laten indrukken

Het staat op de wishlist kennelijk. https://forum.zendure.com/d/13961

Van de week postte Gielz dat deze feature daadwerkelijk gebouwd gaat worden

[Gramser]

Joh! Die had ik even gemist dus.

[R.K]

gast777 schreef op dinsdag 26 mei 2026 @ 13:23:
[...]

Dit gaat blijkbaar over de "Zendure 2400 AC Error" (niet te zien in je screenshot)?

YAML:

      - name: "Zendure 2400 AC Error"
        value_template: >
          {% set states = {0: "Geen meldingen", 1: "Zie Zendure APP"} %}
          {% set packState = value_json['properties']['is_error'] | int %}
          {{ states.get(packState, "Onbekend") }}
        unique_id: Zendure_2400_AC_Error
        icon: mdi:battery-alert

Dan geeft je zendure aan dat er een error is. Property "is_error" heeft waarde "1".

Meer weet HA ook niet, dus is de hoop dat de Zendure App meer informatie over de error zal geven.

Het is idd de 'Zendure 2400ac error' de app geeft nergens info over een error.

[gielz]

R.K schreef op dinsdag 26 mei 2026 @ 14:03:
[...]

Het is idd de 'Zendure 2400ac error' de app geeft nergens info over een error.

Bij de laatste firmware geeft hij ook een error zodra de batterij op 100% komt. Wellicht ook bij jou?

[koboy]

ppaulv schreef op dinsdag 26 mei 2026 @ 12:12:
[...]

ja ok, als je daar tijd in wilt stoppen dan is dat maar zo. Maar ik heb vroeger geleerd dat 'goed' ook meestal 'goed genoeg' is dus daar ga ik niet veel tijd aan spenderen als het eenmaal soepel loopt. En m'n tijd aan andere zaken besteden ....

Zeker, goed genoeg is goed genoeg als ik op vakantie ben. Nu kijk ik er even naar juist als ik met andere dingen bezig ben. De belastingdienst heeft 15 euro af te dragen BTW per kWh opslag van de BTW teruggave ingehouden, dus ik zit dit jaar even in de maximalisatie stand.

[Theetjuh]

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

[Theetjuh]

Ik denk dat ik al wat heb gevonden, heb even een template sensor aangemaakt:

code:

Name: P1-Port Power
State: {{ ((states('sensor.p1_port_power_consumed') | float(0)) - (states('sensor.p1_port_power_produced') | float(0))) * 1000 }}
Unit of measurement: W (moet blijkbaar in Watt ipv Kilowatt?)
Device class: Power
State class: Measurement
Select a device: P1-Port

[ Voor 2% gewijzigd door Theetjuh op 26-05-2026 17:00 . Reden: correctie, zie volgende post ]

[R.K]

gielz schreef op dinsdag 26 mei 2026 @ 15:14:
[...]


Bij de laatste firmware geeft hij ook een error zodra de batterij op 100% komt. Wellicht ook bij jou?

Dat was het, error en battery 100% was op hetzelfde moment. Niet iets om mij druk om te maken dus. Bedankt voor de info.

[Theetjuh]

Theetjuh schreef op dinsdag 26 mei 2026 @ 15:45:
Ik denk dat ik al wat heb gevonden, heb even een template sensor aangemaakt:

code:

Name: P1-Port Power
State: {{ ((states('sensor.p1_port_power_produced') | float(0)) - (states('sensor.p1_port_power_consumed') | float(0))) * 1000 }}
Unit of measurement: W (moet blijkbaar in Watt ipv Kilowatt?)
Device class: Power
State class: Measurement
Select a device: P1-Port

Blijkbaar moet het een negatieve waarde zijn als je teveel stroom hebt en dus wilt chargen:

code:

{{ ((states('sensor.p1_port_power_consumed') | float(0)) - (states('sensor.p1_port_power_produced') | float(0))) * 1000 }}