Zendure producten in Home Assistant integreren deel 2

[Idr548]

Super Cow schreef op donderdag 24 september 2026 @ 13:13:
[...]

De homewizard P1 polling is standaard 5 sec toch?
Ik kwam dit tegen: https://github.com/taurgis/homeassistant-homewizard-instant

Ik maak zelf gebruik van een homewizard 1 fase din meter(ik nog geen slimme meter ), waar ik dit ook heb moeten veranderen.

Ik had om een reden een restfull sensor zitten
=> sensor.homewizard_p1_vermogen

Deze krijgt zijn data iedere seconde van de homewizard p1 meter.

Ik weet verder niet goed wat ik moet vinden van "omnibattery".
Het ziet er nice uit, maar ik loopt toch soms tegen rare dingen.
De batterij gaat plots in "rust" terwijl er niets te rusten is.
Of de 0 sturing is toch niet zo goed.

Kan ook zijn dat het wat finetunen is natuurlijk.

[ Voor 19% gewijzigd door Idr548 op 25-09-2026 23:59 ]

[raven22]

Idr548 schreef op vrijdag 25 september 2026 @ 23:54:
[...]

Ik had om een reden een restfull sensor zitten
=> sensor.homewizard_p1_vermogen

Deze krijgt zijn data iedere seconde van de homewizard p1 meter.

Ik weet verder niet goed wat ik moet vinden van "omnibattery".
Het ziet er nice uit, maar ik loopt toch soms tegen rare dingen.
De batterij gaat plots in "rust" terwijl er niets te rusten is.
Of de 0 sturing is toch niet zo goed.

Kan ook zijn dat het wat finetunen is natuurlijk.

Als je wat geschiedenis data deelt met AI geeft die vaak wel goede suggesties mbt settings

[Ben(V)]

koboy schreef op vrijdag 25 september 2026 @ 16:08:
[...]

Kijk dan ook even naar waar ik op reageer. De onzin slaat puur op het maar elke 5 seconden een wijziging mogen doen van de accu. In het slechtste geval duurt het een seconde of 5 (of zelfs meer al je van maximaal laden naar maximaal terugleveren gaat) voordat de accu staat te doen wat je hem gevraagd hebt. Een kleine bijstelling van 300W ofzo is in ongeveer een seconde gebeurd. Je zou een feedback algoritme kunnen zetten hierop, maar omdat de data van verschillende devices komt met inherent verschillende timestamps is het makkelijker en geeft het een rustiger regelbeeld om elke 5 seconden een aanpassing te doen omdat de regel toestand van de accu dan meestal stabiel is. Gielz heeft uitgebreid geëxperimenteerd hiermee bij het maken van zijn integratie.

Vergelijk het maar met dat je op een loopband loopt. Kleine variaties in snelheid kun je prima direct oppakken, bij grotere variaties kost het jou even tijd om je aan te passen aan de nieuwe snelheid van de loopband.

Maar nogmaals: als je koeienpoep praat zal ik blijven zeggen dat het onzin is. Als je iets inzichtvols post krijg je een duimpje.

Probeer maar eens twee keer snel achter elkaar een commando naar de Zendure te sturen, dan zit daar echt zo'n 5 seconden reactietijd tussen ook als het tweede commando maar een kleine wijziging is.
Het meest waarschijnlijke is dat Zendure dat gewoon ingebouwd heeft om voor hen moverende redenen, maar dat is speculatie.

En een vergelijking met iets mechanische gaat uiteraard niet op daar speelt de massa-traagheid een factoren en daar heeft een batterij geen last van.

En schelden maakt je argument niet sterker.

[Polvo176]

Polvo176 schreef op vrijdag 25 september 2026 @ 13:58:
[...]

Ik heb dit ook gedaan, maar dan met een ongewijzigde Shelly.
Of het ook echt beter wordt weet ik niet, het blijft een indirecte meting met afwijkingen.

Inmiddels al weer terug op de HW P1.
Bij de Shelly zag ik het zelfde verschijnsel als in Hems, houd NOM niet op nul maar op +25 W, + en - 5 W
Ja, hij is geijkt, maar er lopen zoveel stromen door de meterkast dat het meetveld kennelijk beïnvloed wordt.
De HW houdt het op nul + en - 2 W
In de pieken zoals met de Quooker zie ik weinig verschil, ook al zou de Shelly sneller reageren bij grote veranderingen.
En daar was het toch om te doen.
De Shelly heeft voor mij geen voordeel.

[koboy]

Ben(V) schreef op zaterdag 26 september 2026 @ 09:10:
[...]

Probeer maar eens twee keer snel achter elkaar een commando naar de Zendure te sturen, dan zit daar echt zo'n 5 seconden reactietijd tussen ook als het tweede commando maar een kleine wijziging is.
Het meest waarschijnlijke is dat Zendure dat gewoon ingebouwd heeft om voor hen moverende redenen, maar dat is speculatie.

En een vergelijking met iets mechanische gaat uiteraard niet op daar speelt de massa-traagheid een factoren en daar heeft een batterij geen last van.

En schelden maakt je argument niet sterker.

Ja lekker dan. Je weet net zo goed als ik dat de meesten hiervoor de kennis niet hebben. Ben nu te ziek en heb ook de tijd niet om dit te verifiëren. Geef dan meteen even een screendumpje dat dit laat zien.....
Alleen raar dat Gielz vroeger op 4 seconden updates zat nu 5, en fireson zo te zien nog steeds op 4. Lagere tijden gaven (kansen op) pingpong gedrag. Maar ik ben gek blijkbaar.

Voor zo ver ik weet heb ik je niet uitgescholden, maar corrigeer me als dat wel zo is. Nog beter: rapporteer me!

[Devke]

Devke Zendure Cool Guard – slimme ventilatorkoeling voor je Zendure omvormer(s) in Home Assistant

Hoi allemaal,

Mijn Zendure-omvormers worden in de zomer flink warm. Een ventilator op een slimme stekker helpt prima, maar ik wilde meer dan alleen maar "aan boven X graden". Ik wilde weten hoe lang die ventilatoren draaien, op tijd een seintje krijgen om ze stofvrij te maken, en direct zien als de koeling het ondanks alles niet redt. Zo is Devke Zendure Cool Guard ontstaan. Het draait bij mij inmiddels naar volle tevredenheid, dus ik deel het graag.




Doel

• Omvormer(s) automatisch koel houden met een ventilator op een slimme stekker
• Ventilatoronderhoud (stof!) niet meer vergeten
• Direct zien als er iets mis is, ook als je op een ander dashboard zit
• Alles instelbaar vanaf het dashboard, zonder in de code te duiken

Features

• Ventilator per Zendure los aangestuurd op temperatuur
• Aan- en uit-temperatuur instelbaar
• Draaiurenteller per ventilator
• Onderhoudsmelding na een instelbaar aantal draaiuren
• Resetknop + datum "laatst schoongemaakt"
• Oververhittingsalarm als de omvormer 10 minuten te warm blijft
• Failsafe: sensor weg = ventilator aan
• Zelfherstellend: controleert elke minuut en na een herstart
• Optioneel: rode knipperende alarmstrook bovenin elk dashboard met de alarmtekst

Wat heb je nodig?

• Home Assistant 2024.10 of nieuwer
• De Zendure-integratie van Gielz (Zendure-HA-zenSDK) – Cool Guard gebruikt daaruit de omvormertemperatuur
• Per Zendure een ventilator op een schakelbare stekker
• File editor add-on
• card-mod via HACS (alleen voor de alarmstrook)

Installatie in het kort

1. Packages aanzetten in configuration.yaml
2. Package-bestand in de map packages zetten → herstarten
3. Automatisering plakken in de GUI (Bewerken in YAML)
4. Waarden instellen: aan 35 °C, uit 35 °C, alarm 45 °C, onderhoud 100 uur
5. Drie dashboardkaarten toevoegen
6. Optioneel: alarmblok in je thema (Graphite, ander thema of het standaardthema – alle drie beschreven)

Alle code, de volledige stap-voor-stap uitleg en wat je moet aanpassen bij 1 of 3 Zendures staat op GitHub:
github.com/Devke1972/devke-zendure-cool-guard

Vragen, verbeteringen of je eigen aanpassingen? Laat het hieronder weten. En werkt het bij jou ook?

Disclaimer

Gebruik op eigen risico. Devke Zendure Cool Guard is een hobbyproject en wordt aangeboden zoals het is, zonder enige garantie. De maker is niet aansprakelijk voor schade aan apparatuur, woning of andere gevolgen van het gebruik.

1. Dit is geen officieel product van Zendure en is niet gelieerd aan Zendure of aan de maker van de Zendure-integratie.
2. Controleer zelf of alles bij jou goed werkt, en vertrouw niet blind op de automatisering of de meldingen.
3. Zorg dat ventilatoren en stekkers veilig zijn aangesloten en geschikt zijn voor de plek waar ze staan.

Groet,
Devke

[ Voor 10% gewijzigd door Devke op 26-09-2026 14:41 ]

[gast777]

eamelink schreef op vrijdag 25 september 2026 @ 20:45:
Vanmiddag had ik een probleempje:

1) Ik heb drie SolarFlow 800's, elk met twee PV-panelen eraan, die deden bij elkaar 1400W
3) De SolarFlow batterijen zaten allemaal vol, dus ik vermoed dat ze in 'bypass' zaten
4) Mijn P1 gaf aan ~500W verbruik

Gielz probeerde te 'dischargen' met ~500W (zie derde plaatje), maar de Zendures gebruikten niet de batterij om tot een totaal van 1.9KW te komen.

Mijn vermoeden is dat de Zendures niks deden omdat de bypass output al hoger dan de 500 was. De aansturing had die 500 moeten optellen bij de 1400W PV output van de Zendures, en tegen de Zendures moeten vertellen dat ze 1900W moesten uitsturen.

Iemand die dit herkent?


[Afbeelding]

[Afbeelding]

[Afbeelding]

Wat je even zou kunnen proberen is in de proxy flow, in het blokje "Vul hier de Zendure IP adressen in", even "let bypass_gridpower_compensation_enable = 1" aanpassen naar 0.

Daarna even voor de zekerheid linksboven het "Initialize" blokje de knop links indrukken, zodat die code zeker weer even opnieuw uitgevoerd wordt.

Trouwens, als je live alle gegevens wilt zien die tussen Zendures en proxy en tussen proxy en HA uitgewisseld worden (en eventueel ook alles naar textbestand loggen), kun je de live debug aanzettten op de proxy:

http://192.168.x.x:1880/endpoint/dashboard/zenproxylivedataget
http://192.168.x.x:1880/endpoint/dashboard/zenproxylivedatapost
http://192.168.x.x:1880/endpoint/dashboard/zenproxyinfo

[B-Force]

Knip. Niet meer nodig

[ Voor 98% gewijzigd door B-Force op 28-09-2026 16:49 ]

[R.K]

Ter info: Ik heb al een paar dagen een instabiele verbinding met de Zendure Solarflow, met als gevolg 5 a 600 schakelingen per dag omdat de wifi-verbinding wegvalt en weer terugkomt.

Van alles geprobeerd, opnieuw de wifi ingesteld (via apart 2.4 ghz netwerk) batterij herstart, Gielz geupgrade naar de laatste versie. Modem herstart. Maar probleem blijft bestaan.

Waar het nu naar lijkt is dat het wifikanaal op auto stond ingesteld en een willekeurig kanaal werd gekozen, volgens AI kun je het beste kanaal 1 selecteren, in mijn wifi netwerk bleek dat idd het minst gebruikte kanaal te zijn en heb dat dus handmatig veranderd, tevens werd geadviseerd om de bandbreedte op 20 MHZ te zetten. Dat blijkt een stabieler signaal te geven.

Dus mocht je verbindingsproblemen hebben, kijk dan eerst eens naar je router wifi-omgeving.

[ Voor 3% gewijzigd door R.K op 28-09-2026 11:39 ]

[MP3-Junky]

R.K schreef op maandag 28 september 2026 @ 11:37:
Ter info: Ik heb al een paar dagen een instabiele verbinding met de Zendure Solarflow, met als gevolg 5 a 600 schakelingen per dag omdat de wifi-verbinding wegvalt en weer terugkomt.

Van alles geprobeerd, opnieuw de wifi ingesteld (via apart 2.4 ghz netwerk) batterij herstart, Gielz geupgrade naar de laatste versie. Modem herstart. Maar probleem blijft bestaan.

Waar het nu naar lijkt is dat het wifikanaal op auto stond ingesteld en een willekeurig kanaal werd gekozen, volgens AI kun je het beste kanaal 1 selecteren, in mijn wifi netwerk bleek dat idd het minst gebruikte kanaal te zijn en heb dat dus handmatig veranderd, tevens werd geadviseerd om de bandbreedte op 20 MHZ te zetten. Dat blijkt een stabieler signaal te geven.

Dus mocht je verbindingsproblemen hebben, kijk dan eerst eens naar je router wifi-omgeving.

Ik heb ook last gehad van een instabiele wifi verbinding met een 800plus. Inderdaad het kanaal veranderen van de router hielp. Maar tijdelijk helaas. Omdat ik nog 2 andere 800 plussen had die niet zo instabiele verbinding hadden, vermoedde ik een hardware defect. Aangemeld voor garantie en een nieuwe ontvangen sindien geen problemen meer.

[MP3-Junky]

Kan iemand dit gedrag van afgelopen nacht verklaren? Het was een standaard nacht met alleen standby gebruik. Maar blijkbaar piekt de batterij om de zoveel tijd, wat de p1 meter doet uitslaan, waardoor vervolgens de accu in standby gaat. Repeat.

Ik gebruik 3x 800plus met Gielz en de Gast777 proxy.

[ Voor 4% gewijzigd door MP3-Junky op 28-09-2026 15:29 ]

[B-Force]

Ik heb sinds dit weekend Omnibattery draaien, maar het werkt nog niet helemaal zoals gehoopt
Vanmiddag heb ik vol op de zon opgeladen, zodat ik vannacht over zou kunnen komen met NOM. Maar nu is mijn batterij hard aan het ontladen gegaan en staat hij weer op 10%... Was niet helemaal de bedoeling.
Mijn gevoel zegt dat het te maken heeft met vooruitkijken: in de notifications zie iks teeds dat er tot middernacht wordt gerekend. Als er tot dan een overschot is, wordt alles gedumpt?
Nu draait hij nog maar 2 dagen, dus mijn household vraag is nog verre van ok (5 kWh staat hij nu op), dat zou hij nog wel even moeten leren de komende dagen ga ik vanuit. Of doe ik ergens iets verkeerd?
Verder krijg ik nu een nieuwe notificatie dat hij nu hard begint te laden op maximaal vermogen, terwijl het uis ook energie vraagt. Alsof hij alle energie per se uit de batterij wil halen. Maar dat mag ook gewoon vanuit de grid (liver dat zelfs, anders verlies ik de RTE)

[ Voor 16% gewijzigd door B-Force op 28-09-2026 21:18 ]

[gast777]

MP3-Junky schreef op maandag 28 september 2026 @ 15:28:
Kan iemand dit gedrag van afgelopen nacht verklaren? Het was een standaard nacht met alleen standby gebruik. Maar blijkbaar piekt de batterij om de zoveel tijd, wat de p1 meter doet uitslaan, waardoor vervolgens de accu in standby gaat. Repeat.

Ik gebruik 3x 800plus met Gielz en de Gast777 proxy.

[Afbeelding]

Dit lijkt te gebeuren als er een een procent in percentage omlaag gaat. Wisselen ze dan ook van welke actief is? Tijdens een wissel kan het zijn dat'ie even niet strak de nul houdt.

Met 2x Zendure is er een overgangsperiode om de nieuwe eerst rustig wakker te laten worden voor die alle vermogen toe te kennen. Voor 3x Zendure is dat niet geïmplementeerd, dus kan iets een piekje geven. Zou niet echt een probleem moeten zijn.

[gast777]

Als hij elke procent wisselt, dan zou ik aanraden om dat even weer op default 5% of hoger te zetten. Lijkt me een slecht idee om zo vaak te wisselen.

Ik weet niet of dat zo is, is in de grafiek niet te zien.

[MP3-Junky]

gast777 schreef op maandag 28 september 2026 @ 21:05:
Als hij elke procent wisselt, dan zou ik aanraden om dat even weer op default 5% of hoger te zetten. Lijkt me een slecht idee om zo vaak te wisselen.

Ik weet niet of dat zo is, is in de grafiek niet te zien.

Ik heb singleMode_change_device_diff = 20, dus sowieso raar dat hij zo vaak van accu wisselt:

[thijsh02]

Vanaf 1 oktober ga ik over op dynamisch (nu nog vast) en gebruik nu een paar maanden de oplossing van Gielz in HA. Dit werkt tot nu toe allemaal goed alleen loop ik nog te stoeien met de juiste instelling voor onderstaande oplossing:

Ik wil dat de 2400AC+ gaat laden wanneer de stroom het goedkoopst is (ongeveer 5-6 uur laden á 2000w) daarnaast wordt hij ook gevoed met zonnepanelen als die iets opwekken.

Sinds zaterdag heb ik de modus op Dynamisch NOM, maar hij laadt niet op via het net. Welke setting kan ik hiervoor het beste gebruiken? De periodes zijn per 15 minuten en volgens de Zonneplan app zitten we nu in de laagste 24 periodes. (screenshot is van gisteravond)

Moet ik ook een percentage bij de Spread invullen op het settings tabje?

[Pakhaas]

thijsh02 schreef op dinsdag 29 september 2026 @ 11:17:
Vanaf 1 oktober ga ik over op dynamisch (nu nog vast) en gebruik nu een paar maanden de oplossing van Gielz in HA. Dit werkt tot nu toe allemaal goed alleen loop ik nog te stoeien met de juiste instelling voor onderstaande oplossing:

Ik wil dat de 2400AC+ gaat laden wanneer de stroom het goedkoopst is (ongeveer 5-6 uur laden á 2000w) daarnaast wordt hij ook gevoed met zonnepanelen als die iets opwekken.

Sinds zaterdag heb ik de modus op Dynamisch NOM, maar hij laadt niet op via het net. Welke setting kan ik hiervoor het beste gebruiken? De periodes zijn per 15 minuten en volgens de Zonneplan app zitten we nu in de laagste 24 periodes. (screenshot is van gisteravond)

Moet ik ook een percentage bij de Spread invullen op het settings tabje?

[Afbeelding]

Dynamisch NOM duur

[koboy]

thijsh02 schreef op dinsdag 29 september 2026 @ 11:17:
Vanaf 1 oktober ga ik over op dynamisch (nu nog vast) en gebruik nu een paar maanden de oplossing van Gielz in HA. Dit werkt tot nu toe allemaal goed alleen loop ik nog te stoeien met de juiste instelling voor onderstaande oplossing:

Ik wil dat de 2400AC+ gaat laden wanneer de stroom het goedkoopst is (ongeveer 5-6 uur laden á 2000w) daarnaast wordt hij ook gevoed met zonnepanelen als die iets opwekken.

Sinds zaterdag heb ik de modus op Dynamisch NOM, maar hij laadt niet op via het net. Welke setting kan ik hiervoor het beste gebruiken? De periodes zijn per 15 minuten en volgens de Zonneplan app zitten we nu in de laagste 24 periodes. (screenshot is van gisteravond)

Moet ik ook een percentage bij de Spread invullen op het settings tabje?

[Afbeelding]

Percentage invullen inderdaad. Dan zou het moeten werken. Lees de beschrijvingen van de verschillende dynamisch standen even goed door om te kijken wat voor jou de beste is.

[thijsh02]

koboy schreef op dinsdag 29 september 2026 @ 13:36:
[...]

Percentage invullen inderdaad. Dan zou het moeten werken. Lees de beschrijvingen van de verschillende dynamisch standen even goed door om te kijken wat voor jou de beste is.

Ik zal me nog eens goed verdiepen in dat percentage. Snap hem nog niet helemaal, want als je periodes invult dan kan het percentage van de spread toch gewoon leeg blijven?

[koboy]

thijsh02 schreef op dinsdag 29 september 2026 @ 14:06:
[...]

Ik zal me nog eens goed verdiepen in dat percentage. Snap hem nog niet helemaal, want als je periodes invult dan kan het percentage van de spread toch gewoon leeg blijven?

Ja, maar het punt dat je met dynamische tarieven werkt houdt in dat je ook een minimale spread moet instellen om te voorkomen dat de inkoopprijs+laad verliezen boven de gebruiks prijs komt. Als je geen spread invult gebeurt er niets.

Bij een 80% RTE wil je een minimale spread van 25% (((100%/80%)-1)*100%)

[gast777]

MP3-Junky schreef op dinsdag 29 september 2026 @ 08:44:
[...]

Ik heb singleMode_change_device_diff = 20, dus sowieso raar dat hij zo vaak van accu wisselt:

[Afbeelding] [Afbeelding]

In de grafiek staan Zendure 2 en Zendure 3. Wat is er met Zendure 1 aan de hand?

Bij 3 Zendures wordt gekeken naar het verschil in SoC% tussen de hoogste en laagste. Is Zendure 1 misschien bijvoorbeeld 100%, zodat het verschil inderdaad >20% is en hij dus constant kijkt welke hij moet ontladen? Dat zou het verklaren.

[thijsh02]

@koboy Ik heb vanavond een hoop reacties zitten lezen over de spread en de meeste gaan over het juiste spread percentage om te handelen. Voor mij is dit niet van toepassing en wil ik alleen maar mijn accu laden op de goedkoopste uren i.c.m met zonnestroom als die er is en ontladen op de duurste uren.

Ik heb een bronwarmtepomp en in de winterperiode zijn er dagen van 30-50kwh verbruik met vooral in de nacht 2100w per uur. Mijn accu's hebben een capaciteit van 15kwh dus kom niet eens in de buurt, maar wil de duurste uren opvangen.

Welke modus is dan het beste om te kiezen? Mijn gevoel zegt nu Dynamisch NOM (Duur) en dan bijvoorbeeld 30 dure kwartieren en 20 goedkope uren. De spread zet ik dan op 0%.

[Gerry1982]

Even een newbie vraag:

Ik heb 5 Zendure 800 plus batterijen en wil me graag oriënteren voor HA.

Kan ik een goede connectie maken met de Zendure P1 meter naar HA?

Zal mijn oudere Kaifa MA304C (type E0026) slimme meter met DSMR 4.x erg slecht werken als deze niet elke seconden maar elke 10 Seconden data stuurt?

[koboy]

thijsh02 schreef op dinsdag 29 september 2026 @ 22:14:
@koboy Ik heb vanavond een hoop reacties zitten lezen over de spread en de meeste gaan over het juiste spread percentage om te handelen. Voor mij is dit niet van toepassing en wil ik alleen maar mijn accu laden op de goedkoopste uren i.c.m met zonnestroom als die er is en ontladen op de duurste uren.

Ik heb een bronwarmtepomp en in de winterperiode zijn er dagen van 30-50kwh verbruik met vooral in de nacht 2100w per uur. Mijn accu's hebben een capaciteit van 15kwh dus kom niet eens in de buurt, maar wil de duurste uren opvangen.

Welke modus is dan het beste om te kiezen? Mijn gevoel zegt nu Dynamisch NOM (Duur) en dan bijvoorbeeld 30 dure kwartieren en 20 goedkope uren. De spread zet ik dan op 0%.

[Afbeelding]

[Afbeelding]

Bij handelen verzilver je het bedrag van de spread in keiharde cash onafhankelijk van het vermogen dat op dat moment gevraagd wordt. Maar de energie opgeslagen in de accu vertegenwoordigt altijd een waarde, daarom moet je altijd rekening houden met de spread, anders ben je geld door het toilet aan het spoelen.

Voorbeeldje, wat extreem maar maakt het punt wel duidelijk: je hebt de accu opgeladen tegen 20 cent/kWh. Laten we uitgaan van een RTE van 80%, dan is elke kWh die uit die accu komt 25 cent waard. Als de prijs op het dure moment van de dag 21 cent is, dan kun je dus beter de stroom uit het net halen dan uit de accu.

Als je de minimale spread opgeeft, dan weet het regelsysteem (Gielz) of het verschil tussen goedkoop en duur genoeg is om de accu goedkoop te vullen en duur te legen/gebruiken. Zonder de minimale spread weet het systeem dat niet, en zal dus niets doen.
Vul nou maar gewoon die 25% in, de RTE ligt net boven de 80% dus er is wat marge.

Zal er vast zometeen wel iemand komen met dat je ook de afschrijving/slijtage van een cyclus in de spread moet opnemen. Kun je doen, maar dat houdt ook in dat de accu minder gaat doen terwijl hij nog wel "slijt" puur door veroudering. Mijn voorkeur heeft het om de accu zo veel mogelijk puur op prijsverschil renderend in te zetten en het systeem zich te laten terugverdienen. Voor je de accu puur door cycles hebt versleten ben je bijna 20 jaar verder, en kun je beter financieel het maximale in die tijd er uit halen.

[Polvo176]

koboy schreef op dinsdag 29 september 2026 @ 23:44:
[...]

Bij handelen verzilver je het bedrag van de spread in keiharde cash onafhankelijk van het vermogen dat op dat moment gevraagd wordt. Maar de energie opgeslagen in de accu vertegenwoordigt altijd een waarde, daarom moet je altijd rekening houden met de spread, anders ben je geld door het toilet aan het spoelen.

Voorbeeldje, wat extreem maar maakt het punt wel duidelijk: je hebt de accu opgeladen tegen 20 cent/kWh. Laten we uitgaan van een RTE van 80%, dan is elke kWh die uit die accu komt 25 cent waard. Als de prijs op het dure moment van de dag 21 cent is, dan kun je dus beter de stroom uit het net halen dan uit de accu.

Als je de minimale spread opgeeft, dan weet het regelsysteem (Gielz) of het verschil tussen goedkoop en duur genoeg is om de accu goedkoop te vullen en duur te legen/gebruiken. Zonder de minimale spread weet het systeem dat niet, en zal dus niets doen.
Vul nou maar gewoon die 25% in, de RTE ligt net boven de 80% dus er is wat marge.

Zal er vast zometeen wel iemand komen met dat je ook de afschrijving/slijtage van een cyclus in de spread moet opnemen. Kun je doen, maar dat houdt ook in dat de accu minder gaat doen terwijl hij nog wel "slijt" puur door veroudering. Mijn voorkeur heeft het om de accu zo veel mogelijk puur op prijsverschil renderend in te zetten en het systeem zich te laten terugverdienen. Voor je de accu puur door cycles hebt versleten ben je bijna 20 jaar verder, en kun je beter financieel het maximale in die tijd er uit halen.

Ik snap niet dat je hier nog druk over maakt voor nog 3 maanden.
Na 1 januari is dit soort handel voor 90% niet meer bruikbaar.
Het zit al niet eens meer in mijn eigen automatisering.

[B-Force]

Polvo176 schreef op woensdag 30 september 2026 @ 00:32:
[...]

Ik snap niet dat je hier nog druk over maakt voor nog 3 maanden.
Na 1 januari is dit soort handel voor 90% niet meer bruikbaar.
Het zit al niet eens meer in mijn eigen automatisering.

Waarom niet? Wat verandert er dan bij een dynamisch contract van bv Zonneplan? Waarbij je PV vermogen veel lager ligt dan je verbruik?

[MP3-Junky]

gast777 schreef op dinsdag 29 september 2026 @ 20:01:
[...]

In de grafiek staan Zendure 2 en Zendure 3. Wat is er met Zendure 1 aan de hand?

Bij 3 Zendures wordt gekeken naar het verschil in SoC% tussen de hoogste en laagste. Is Zendure 1 misschien bijvoorbeeld 100%, zodat het verschil inderdaad >20% is en hij dus constant kijkt welke hij moet ontladen? Dat zou het verklaren.

Zendure 1 had hier de 10% SoC bereikt. (de blauwe lijn onderin de grafiek)

[ Voor 4% gewijzigd door MP3-Junky op 30-09-2026 07:22 ]

[thijsh02]

koboy schreef op dinsdag 29 september 2026 @ 23:44:
[...]

Bij handelen verzilver je het bedrag van de spread in keiharde cash onafhankelijk van het vermogen dat op dat moment gevraagd wordt. Maar de energie opgeslagen in de accu vertegenwoordigt altijd een waarde, daarom moet je altijd rekening houden met de spread, anders ben je geld door het toilet aan het spoelen.

Thanks voor de uitgebreide uitleg. Deze theorie begrijp, maar zoals aangegeven 'handel' ik niet. Ik wil alleen maar mijn accu volladen op de goedkoopste uren en ontladen op de duurste uren zodat mijn huis de accu optimaal benut. Ik lever vanuit de accu niet aan het net.

Het invullen van de spread heeft dan geen functie toch? Het gat tussen goedkoopste en duurste is vaak meer dan een paar centen. Voor vandaag is het gemiddeld 22 cent laagste 5 uren en 40 cent hoogste 5 uren.

Het gaat mij dus vooral om de juiste modus selecteren i.c.m. het aantal periodes, zodat de accu helemaal ontlaadt op de duurste periodes

[Mai Pensato]

Hier zijn deze week 3 SolarFlow 3000 Mix geinstalleerd. Ik heb zonnepanelen met een 3fase SolarEdge 12,5k omvormer. Elke batterij staat op een aparte fase en eigen stroomgroep. Per 1 october morgen dus gaat mijn Tibber contract in, ik wil alles in Home Assistant gaan regelen lokaal. Heb een homewizard p1 meter en solaredge tcp modbus draaiende in HA.

De batterijen zijn al een keer vol geladen en ontladen. Ik heb HEMS uitgeschakeld.

Gisteravond geprobeerd de officiele Zendure integratie (Fireson) te installeren maar ik krijg ook de foutmelding token accepted but no devices found.

Is daar een workaround voor? Ik moet in ieder geval alle Zendure entiteiten in HA hebben. MQTT broker is geinstalleerd.

Wat is zowiezo de beste route in mijn situatie (zonnepanelen, 3fase omvormer, 3 batterijen en dynamisch stroomcontract bij Tibber) ? Heb me al wat ingelezen ook in Gielz oplossing en dat ik voor 3 batterijen ook de gast777 proxy nodig heb (ik heb nog geen ervaring met nodered).

[koboy]

thijsh02 schreef op woensdag 30 september 2026 @ 07:27:
[...]

Thanks voor de uitgebreide uitleg. Deze theorie begrijp, maar zoals aangegeven 'handel' ik niet. Ik wil alleen maar mijn accu volladen op de goedkoopste uren en ontladen op de duurste uren zodat mijn huis de accu optimaal benut. Ik lever vanuit de accu niet aan het net.

Het invullen van de spread heeft dan geen functie toch? Het gat tussen goedkoopste en duurste is vaak meer dan een paar centen. Voor vandaag is het gemiddeld 22 cent laagste 5 uren en 40 cent hoogste 5 uren.

Het gaat mij dus vooral om de juiste modus selecteren i.c.m. het aantal periodes, zodat de accu helemaal ontlaadt op de duurste periodes

Daar zit hem nu juist de crux: je "handelt" wel. Als de spread te klein is kun je beter de PV opbrengst het net op sturen dan de accu in voor later gebruik. Als je een auto toegestopt krijgt ga je er ook niet mee rijden voordat je weet of er nou benzine, gas, diesel of stroom in moet.
Vul nou die spread in en je zult zien dat het werkt. De spread is gewoon een getalletje om het dynamisch mechanisme te laten werken.

[koboy]

Polvo176 schreef op woensdag 30 september 2026 @ 00:32:
[...]

Ik snap niet dat je hier nog druk over maakt voor nog 3 maanden.
Na 1 januari is dit soort handel voor 90% niet meer bruikbaar.
Het zit al niet eens meer in mijn eigen automatisering.

Als je een eigen automatisering draait moet je je niet iemand de les proberen te lezen die probeert uit te leggen waarom je een bepaald getalletje moet invullen als je de bijbehorende modus wilt draaien in een ANDERE automatisering. Ik help graag anderen, maar dit soort opmerkingen kunnen me echt gestolen worden.

N.B. ook volgend jaar kan op erg grauwe dagen het nuttig zijn om van het net in te kopen richting accu voor gebruik op de dure momenten. Rarara wat heb je daarvoor nodig? De spread!

[Pakhaas]

koboy schreef op woensdag 30 september 2026 @ 09:47:
[...]

Als je een eigen automatisering draait moet je je niet iemand de les proberen te lezen die probeert uit te leggen waarom je een bepaald getalletje moet invullen als je de bijbehorende modus wilt draaien in een ANDERE automatisering. Ik help graag anderen, maar dit soort opmerkingen kunnen me echt gestolen worden.

N.B. ook volgend jaar kan op erg grauwe dagen het nuttig zijn om van het net in te kopen richting accu voor gebruik op de dure momenten. Rarara wat heb je daarvoor nodig? De spread!

Ik ben wel even benieuwd naar jouw visie.

Volgend jaar wil ik voornamelijk de beide EV's laden met stroom uit de batterij. Overdag is er vaak 1 EV thuis en de ander kan dan nachts aan de lader. Als dan overdag stroom goedkoper is dan nachts, wil ik de batterijen overdag ook uit het net laden zodat die avonds in de EV kan ontladen. Hoeveel moet het stroomverschil zijn tussen overdag en nachts om het te rechtvaardigen? Is het verschil te klein, dan kan ik beter overdag niet extra laden en nachts rechtstreek uit het net.

[Acidrain]

Pakhaas schreef op woensdag 30 september 2026 @ 10:04:
[...]

Ik ben wel even benieuwd naar jouw visie.

Volgend jaar wil ik voornamelijk de beide EV's laden met stroom uit de batterij. Overdag is er vaak 1 EV thuis en de ander kan dan nachts aan de lader. Als dan overdag stroom goedkoper is dan nachts, wil ik de batterijen overdag ook uit het net laden zodat die avonds in de EV kan ontladen. Hoeveel moet het stroomverschil zijn tussen overdag en nachts om het te rechtvaardigen? Is het verschil te klein, dan kan ik beter overdag niet extra laden en nachts rechtstreek uit het net.

Het verschil moet tenminste groter zijn dan het verlies wat je hebt in de Zendure als je de Zendure oplaad overdag en het verlies wat je hebt in de Zendure als je snachts de zendure weer ontlaad richting je ev.
Maar dat is volgens mij de zelfde spread als dat je de stroom gewoon zou gebruiken voor je huis, het ev verhaal maakt het niet anders. Wel is het anders voor de ev die overdag thuis staat, je moet voorkomen dat daar eerst nog een Zendure tussen zit. Die moet direct met zonnestroom geladen worden dat scheelt 2 keer verlies op de Zendure.

[Polvo176]

koboy schreef op woensdag 30 september 2026 @ 09:47:
[...]

Als je een eigen automatisering draait moet je je niet iemand de les proberen te lezen die probeert uit te leggen waarom je een bepaald getalletje moet invullen als je de bijbehorende modus wilt draaien in een ANDERE automatisering. Ik help graag anderen, maar dit soort opmerkingen kunnen me echt gestolen worden.

N.B. ook volgend jaar kan op erg grauwe dagen het nuttig zijn om van het net in te kopen richting accu voor gebruik op de dure momenten. Rarara wat heb je daarvoor nodig? De spread!

Ik probeer niemand de les te lezen, alleen met de neus op de feiten te drukken.
Maar je zult er vanzelf wel achter komen dat de spread in de winter te weinig is om te handelen en in de zomer zorgt de zon wel voor volle batterijen.
Overigens verkondigen diverse energie goeroes dit het hele jaar al.
De spread waar jij zo de nadruk op legt was afgelopen winter gemiddeld rond de 7 cent, (25-32 cent) dat is al te weinig om met saldering te handelen, maar zonder saldering zou je bij die verkoop prijs nog 16 cent terug krijgen.
Ja, er zullen nog steeds uitzonderingen op de regel voorkomen, maar dan zeg ik weer, is het de moeite waard om ja daar nog druk over te maken?
Wat jou NB betreft, ik had het over handel, niet over zelf verbruik, dat blijft wel veel vaker interessant.

[koboy]

Pakhaas schreef op woensdag 30 september 2026 @ 10:04:
[...]

Ik ben wel even benieuwd naar jouw visie.

Volgend jaar wil ik voornamelijk de beide EV's laden met stroom uit de batterij. Overdag is er vaak 1 EV thuis en de ander kan dan nachts aan de lader. Als dan overdag stroom goedkoper is dan nachts, wil ik de batterijen overdag ook uit het net laden zodat die avonds in de EV kan ontladen. Hoeveel moet het stroomverschil zijn tussen overdag en nachts om het te rechtvaardigen? Is het verschil te klein, dan kan ik beter overdag niet extra laden en nachts rechtstreek uit het net.

Hangt natuurlijk ook een beetje af van je opslag capaciteit en wat je nog over wilt houden voor het huis.

Gaan we uit van een (vrijwel) nul PV opbrengst die dag, dan wel PV productie valt tijdens de goedkope uren dan kom je op: auto 1 goedkoop laden en de accu vullen als de spread 25% of hoger is qua inkoop. Auto 2 dan in de nacht voor zo ver dat kan uit de accu. (Wat je volgens mij nu ook al doet).
Met die spread van 25% zorg je er voor dat je net goedkoper uit bent wat betreft de stroom die van het net de accu in is gegaan.

[koboy]

Polvo176 schreef op woensdag 30 september 2026 @ 10:47:
[...]

Ik probeer niemand de les te lezen, alleen met de neus op de feiten te drukken.
Maar je zult er vanzelf wel achter komen dat de spread in de winter te weinig is om te handelen en in de zomer zorgt de zon wel voor volle batterijen.
Overigens verkondigen diverse energie goeroes dit het hele jaar al.
De spread waar jij zo de nadruk op legt was afgelopen winter gemiddeld rond de 7 cent, (25-32 cent) dat is al te weinig om met saldering te handelen, maar zonder saldering zou je bij die verkoop prijs nog 16 cent terug krijgen.
Ja, er zullen nog steeds uitzonderingen op de regel voorkomen, maar dan zeg ik weer, is het de moeite waard om ja daar nog druk over te maken?
Wat jou NB betreft, ik had het over handel, niet over zelf verbruik, dat blijft wel veel vaker interessant.

En ik probeerde uit te leggen waarom een getalletje cruciaal is om in te vullen om DE AUTMATISERING DIE JIJ NIET GEBRUIKT werkend te krijgen. Ik zetten schreef niet voor niets "handel" tussen aanhalingstekens wat op het moment dat je dynamische tarieven combineert met een accu ben je altijd bezig met een vorm van "handel", maar dat is iets wat jij blijkbaar weigert te snappen.

Ik krijg echt genoeg van dit soort gedoe! Er is meer dan alleen kale EPEX handel!!!!!

Wijziging: iets netter verwoord.

[ Voor 3% gewijzigd door koboy op 30-09-2026 12:21 ]

[Mistraller]

Gerry1982 schreef op dinsdag 29 september 2026 @ 23:36:
Even een newbie vraag:

Ik heb 5 Zendure 800 plus batterijen en wil me graag oriënteren voor HA.

Kan ik een goede connectie maken met de Zendure P1 meter naar HA?

Zal mijn oudere Kaifa MA304C (type E0026) slimme meter met DSMR 4.x erg slecht werken als deze niet elke seconden maar elke 10 Seconden data stuurt?

Is allemaal geen probleem. Je kan met een REST call gewoon de zendure P1 uitlezen, en op de Kaifa M304 dsmr4 gaat dat prima. Net wat minder snel natuurlijk, dus iets minder strak, maar ik ben zelf erg tevreden.

Ik lees mijn kaifa overigens met een ftdi kabel uit, dus zodra de meter het telegram stuurt is het ook instant aanwezig in HA (push). Doe je een restcall op gezette tijden, dan komt er weer wat vertraging bij want dat is een pull. Dat kan je omzeilen door de REST call vaker uit te voeren; bijv elke seconde. Dan is er dus max 10 seconden geen verandering in de data maar heb je, zodra er verse data is, wel meteen beschikbaar in HA.

Overigens betekent 10 seconden data vs 1 seconden data, NIET dat je altijd 10 seconden te laat bent!

Stel een verbruiker springt aan, en 0,5 seconden later wordt het telegram bericht verzonden, dan heb je even snel response als met een DSMR5.

Je hebt max 10 seconden vertraging, maar meestal korter.

[Gramser]

Zullen we wel op inhoud blijven discussiëren en niet op de man gaan spelen? Er zijn meerdere waarheden hier. Specifieke casus vs bredere verwachting na salderen, om maar wat te noemen. Beide zijn voor mij informatief, als vast-contracter-die-in-2027-naar-dynamisch-gaat, maar dan wil ik het wel leuk vinden om te lezen

[Ben(V)]

@Gramser
Helemaal mee eens, laten we de scheldpartijen maar achterwege laten, daar heeft helemaal niemand wat aan.

[koboy]

Gramser schreef op woensdag 30 september 2026 @ 11:04:
Zullen we wel op inhoud blijven discussiëren en niet op de man gaan spelen? Er zijn meerdere waarheden hier. Specifieke casus vs bredere verwachting na salderen, om maar wat te noemen. Beide zijn voor mij informatief, als vast-contracter-die-in-2027-naar-dynamisch-gaat, maar dan wil ik het wel leuk vinden om te lezen

Ik probeer altijd op de inhoud te blijven. Niemand hier heeft standaard een plus of een minnetje bij mij. Praat je onzin, dan zal ik er tegenin gaan, een mooie complete post met uitleg krijgt van mij een duimpje.

Ik probeerde iemand te helpen het dynamische tarieven deel van zijn automatisering aan de praat te krijgen, en waarom een meestal met epex handel geassocieerde term als spread cruciaal is voor het goed functioneren. Dan helpt het niet als iemand anders die geen kennis heeft van deze automatisering gaat roepen dat ik degene die ik probeer te helpen richting epex handel aan het duwen ben waarvan ik dondersgoed weet dat betreffende dat juist niet wil. En helemaal niet als die deze beschuldiging nog een keer gaat herhalen. In mijn eerste reactie schreef ik nota bene dat hij even goed de beschrijving van de verschillende dynamische standen moest lezen om zeker te weten dat hij de juiste had!

@Ben(V) de biologie verwijzing heb ik verwijderd. Soms schiet ook ik uit mijn slof. Ietwat kleurrijk taalgebruik gebeurt wat vaker.

@Polvo176 : ik weet dondersgoed dat volgend jaar epex handel waarschijnlijk grotendeels nutteloos is, maar we zullen moeten afwachten wat er met de tarieven gebeurt in relatie tot de geo-politieke situatie. Ik heb afgelopen zomer genoeg dagen langs zien komen waarin epex handel voordeliger zou zijn met de regels voor 2027. Hoe de komende winter (en verder) zich gaat ontwikkelen moeten we nog zien; met dynamische tarieven heeft niemand een kristallen bol en kun je eigenlijk alleen maar achteraf de balans opmaken. Hoe dan ook zal ik niemand rücksichtslos adviseren EPEX handel te doen, behalve als het gaat om puur financieel rendement DIT jaar.
Maar zodra je iets opslaat, of dat nou stroom is of vaatwastabletten uit de aanbieding, je bent bezig met een vorm van "handel" alleen verkoop je aan jezelf en heb je het meestal niet over winst maar over besparen. Laat bij dynamische tarieven nou net de spreiding (spread!) tussen de tarieven bepalen of het zin heeft om op te slaan in een accu of niet. Dit is de reden dat het hele dynamische tarieven deel niet werkt als je niet de minimale spread invult in de Gielz automatisering. Hierachter is een stuk logica gebouwd die ook rekening houdt met de situatie voor 2027 en verder, maar de minimale spread in combinatie met een keuze voor een bepaalde dynamische modus bepaalt wat er gebeurt.

Wijziging: bij herlezen zag ik iets wat wat duidelijker mocht. Om die reden 2x spread -> minimale spread om de verwijzing naar de instelling expliciter te maken.

[ Voor 3% gewijzigd door koboy op 30-09-2026 13:49 ]

[Gramser]

koboy schreef op woensdag 30 september 2026 @ 13:05:
[...]

Ik probeer altijd op de inhoud te blijven. Niemand hier heeft standaard een plus of een minnetje bij mij. Praat je onzin, dan zal ik er tegenin gaan, een mooie complete post met uitleg krijgt van mij een duimpje.

Ik probeerde iemand te helpen het dynamische tarieven deel van zijn automatisering aan de praat te krijgen, en waarom een meestal met epex handel geassocieerde term als spread cruciaal is voor het goed functioneren. Dan helpt het niet als iemand anders die geen kennis heeft van deze automatisering gaat roepen dat ik degene die ik probeer te helpen richting epex handel aan het duwen ben waarvan ik dondersgoed weet dat betreffende dat juist niet wil. En helemaal niet als die deze beschuldiging nog een keer gaat herhalen. In mijn eerste reactie schreef ik nota bene dat hij even goed de beschrijving van de verschillende dynamische standen moest lezen om zeker te weten dat hij de juiste had!

@Ben(V) de biologie verwijzing heb ik verwijderd. Soms schiet ook ik uit mijn slof. Ietwat kleurrijk taalgebruik gebeurt wat vaker.

@Polvo176 : ik weet dondersgoed dat volgend jaar epex handel waarschijnlijk grotendeels nutteloos is, maar we zullen moeten afwachten wat er met de tarieven gebeurt in relatie tot de geo-politieke situatie. Ik heb afgelopen zomer genoeg dagen langs zien komen waarin epex handel voordeliger zou zijn met de regels voor 2027. Hoe de komende winter (en verder) zich gaat ontwikkelen moeten we nog zien; met dynamische tarieven heeft niemand een kristallen bol en kun je eigenlijk alleen maar achteraf de balans opmaken. Hoe dan ook zal ik niemand rücksichtslos adviseren EPEX handel te doen, behalve als het gaat om puur financieel rendement DIT jaar.
Maar zodra je iets opslaat, of dat nou stroom is of vaatwastabletten uit de aanbieding, je bent bezig met een vorm van "handel" alleen verkoop je aan jezelf en heb je het meestal niet over winst maar over besparen. Laat bij dynamische tarieven nou net de spreiding (spread!) tussen de tarieven bepalen of het zin heeft om op te slaan in een accu of niet. Dit is de reden dat het hele dynamische tarieven deel niet werkt als je niet de spread invult in de Gielz automatisering. Hierachter is een stuk logica gebouwd die ook rekening houdt met de situatie voor 2027 en verder, maar de spread in combinatie met een keuze voor een bepaalde dynamische modus bepaalt wat er gebeurt.

Je punt was al duidelijk en helder voor mij en anderen, schat ik zo in. Ik been geen moderator hier hoor (gelukkig maar ). Fijn dat je de biologiecomponent hebt verwijderd, dank daarvoor. En soms is het ook okee om ergens gewoon niet meer op te reageren, maar dat is meer mijn persoonlijke stijl als ik mijn punt al heb gemaakt.

Jouw post leerde me zeker iets bij over spread en wat een handig startpercentage is, daar had ik nog geen duidelijk onderbouwd relaas over gelezen. Nu wel

Enfin, weer door...!

[ppaulv]

Goedemiddag.
Stel even dat ik 2 Zendure torens heb staan, beide ongeveer 8 kWh.
En ik heb 2 gebruiksdoelen.
1. backup energie voor als de Russen ons grid hacken (of de gemeente trekt een kabel stuk)
2. overdag goedkoop opladen en 's nachts gebruiken terwijl/als de stroom een stuk duurder is
Nu is dus mijn 'twijfel' hoe ik dat zou moeten inrichten. Argumenten daarbij zijn
a) gebruiksgemak (KIS), ook qua software upgrades etc.
b) stabiliteit en betrouwbaarheid van het geheel
c) rendement
Blangrijk gegeven daarbij is natuurlijk hoeveel energie ik minimaal als backup wil behouden en uitsluiten van 'handel' / kostenoptimalisatie.
Met de natte vinger zou ik zeggen 4 kWh (gebaseerd op m'n onderbuik, verder niets).
Is het dan het simpelst om NR oid te gaan installeren (heb nu 1 toren in gebruik met alleen Gielz) en het geheel als één behandelen en SOC op minimaal 30% houden?
Of de 2 torens apart aansturen met bijvoorbeeld de een op een NOM variant en de ander op pure handel?
Midden volgend jaar ga ik denk ik over van vast naar dynamisch.

Heeft iemand daar een helder beeld bij?

[koboy]

ppaulv schreef op woensdag 30 september 2026 @ 17:10:
Goedemiddag.
Stel even dat ik 2 Zendure torens heb staan, beide ongeveer 8 kWh.
En ik heb 2 gebruiksdoelen.
1. backup energie voor als de Russen ons grid hacken (of de gemeente trekt een kabel stuk)
2. overdag goedkoop opladen en 's nachts gebruiken terwijl/als de stroom een stuk duurder is
Nu is dus mijn 'twijfel' hoe ik dat zou moeten inrichten. Argumenten daarbij zijn
a) gebruiksgemak (KIS), ook qua software upgrades etc.
b) stabiliteit en betrouwbaarheid van het geheel
c) rendement
Blangrijk gegeven daarbij is natuurlijk hoeveel energie ik minimaal als backup wil behouden en uitsluiten van 'handel' / kostenoptimalisatie.
Met de natte vinger zou ik zeggen 4 kWh (gebaseerd op m'n onderbuik, verder niets).
Is het dan het simpelst om NR oid te gaan installeren (heb nu 1 toren in gebruik met alleen Gielz) en het geheel als één behandelen en SOC op minimaal 30% houden?
Of de 2 torens apart aansturen met bijvoorbeeld de een op een NOM variant en de ander op pure handel?
Midden volgend jaar ga ik denk ik over van vast naar dynamisch.

Heeft iemand daar een helder beeld bij?

Probleem dat je hebt bij twee parallel lopende strategieën is dat je extra complexiteit introduceert om er voor te zorgen dan deze elkaar niet in de weg zitten.

Mijn klusje voor de winter zoals ik dit nu voor me zie: twee extra automatiseringen maken die Gielz op basis van tijd en SoC laat schakelen. Zal iets in de richting van:

voor de zonnige maanden: 10u Dynamisch NOM, 16u Dynamisch Handel + NOM, bij 40% SOC alleen slim ontladen.
Op deze manier wordt er pas opgeladen als de prijs laag genoeg is, wordt het overschot duur gedumpt en vervolgens alleen maar ontladen wat er ook aan prijsdip in de nacht komt.
Dure/goedkope kwartieren liefst eenmalig zo instellen zodat het dumpen goed loopt en er ook volledig opgeladen wordt.

Voor de donkere maanden altijd basis dynamisch NOM duur: Op de goedkope nacht zaterdag naar zondag de maximale SoC naar 100% en standje snel opladen. Bij 100% SoC naar maximale SoC 50% en terug naar dynamisch NOM duur.
Op deze manier is het zaterdag op zondag goedkoop vullen en de rest van de week de dure pieken er uit NOMmen en als de accu wat leeg raakt dagelijks zo goedkoop mogelijk een klein beetje er bij in. Hier ook het aantal goedkope en dure kwartieren ingesteld.

Kan ongetwijfeld efficiënter, maar dit is wat ik tot nu toe met Gielz bedacht heb. Verder geld natuurlijk ook de 80-20 regel..... Verder wacht ik ook nog even op wat er komen gaat. Misschien bouwt iemand iets briljants.....

[Mai Pensato]

ppaulv schreef op woensdag 30 september 2026 @ 17:10:
Goedemiddag.
Stel even dat ik 2 Zendure torens heb staan, beide ongeveer 8 kWh.
En ik heb 2 gebruiksdoelen.
1. backup energie voor als de Russen ons grid hacken (of de gemeente trekt een kabel stuk)
2. overdag goedkoop opladen en 's nachts gebruiken terwijl/als de stroom een stuk duurder is
Nu is dus mijn 'twijfel' hoe ik dat zou moeten inrichten. Argumenten daarbij zijn
a) gebruiksgemak (KIS), ook qua software upgrades etc.
b) stabiliteit en betrouwbaarheid van het geheel
c) rendement
Blangrijk gegeven daarbij is natuurlijk hoeveel energie ik minimaal als backup wil behouden en uitsluiten van 'handel' / kostenoptimalisatie.
Met de natte vinger zou ik zeggen 4 kWh (gebaseerd op m'n onderbuik, verder niets).
Is het dan het simpelst om NR oid te gaan installeren (heb nu 1 toren in gebruik met alleen Gielz) en het geheel als één behandelen en SOC op minimaal 30% houden?
Of de 2 torens apart aansturen met bijvoorbeeld de een op een NOM variant en de ander op pure handel?
Midden volgend jaar ga ik denk ik over van vast naar dynamisch.

Heeft iemand daar een helder beeld bij?

Welke Solarflows heb je, ik neem aan een Mix 3000 of 4000? Hoe heb je die in Gielz gekregen, heb je daar de Zendure Integration (fireson) niet bij nodig want die krijg ik niet geinstalleerd. En hoe wil je de 2e toren gaan gebruiken in Home Assistant?

[Pakhaas]

koboy schreef op woensdag 30 september 2026 @ 17:58:
[...]

Probleem dat je hebt bij twee parallel lopende strategieën is dat je extra complexiteit introduceert om er voor te zorgen dan deze elkaar niet in de weg zitten.

Mijn klusje voor de winter zoals ik dit nu voor me zie: twee extra automatiseringen maken die Gielz op basis van tijd en SoC laat schakelen. Zal iets in de richting van:

voor de zonnige maanden: 10u Dynamisch NOM, 16u Dynamisch Handel + NOM, bij 40% SOC alleen slim ontladen.
Op deze manier wordt er pas opgeladen als de prijs laag genoeg is, wordt het overschot duur gedumpt en vervolgens alleen maar ontladen wat er ook aan prijsdip in de nacht komt.
Dure/goedkope kwartieren liefst eenmalig zo instellen zodat het dumpen goed loopt en er ook volledig opgeladen wordt.

Voor de donkere maanden altijd basis dynamisch NOM duur: Op de goedkope nacht zaterdag naar zondag de maximale SoC naar 100% en standje snel opladen. Bij 100% SoC naar maximale SoC 50% en terug naar dynamisch NOM duur.
Op deze manier is het zaterdag op zondag goedkoop vullen en de rest van de week de dure pieken er uit NOMmen en als de accu wat leeg raakt dagelijks zo goedkoop mogelijk een klein beetje er bij in. Hier ook het aantal goedkope en dure kwartieren ingesteld.

Kan ongetwijfeld efficiënter, maar dit is wat ik tot nu toe met Gielz bedacht heb. Verder geld natuurlijk ook de 80-20 regel..... Verder wacht ik ook nog even op wat er komen gaat. Misschien bouwt iemand iets briljants.....

Als de batterij nu bijv op soc 5% zit en je zet minimum soc op 10% gaat die eerst bijladen tot minimum soc ongeacht de prijs.

Als hij nu op 100% soc staat en je doet hem naar 50%. Gaat die dan niet ontladen tot 50% ongeacht prijs?

[koboy]

Pakhaas schreef op woensdag 30 september 2026 @ 18:53:
[...]

Als de batterij nu bijv op soc 5% zit en je zet minimum soc op 10% gaat die eerst bijladen tot minimum soc ongeacht de prijs.

Als hij nu op 100% soc staat en je doet hem naar 50%. Gaat die dan niet ontladen tot 50% ongeacht prijs?

Lijkt me onwaarschijnlijk. Het opladen naar 10% is de SoC bescherming in Gielz toch, en die kun je uitzetten. Maar iets om te testen tegen die tijd. Eerst nog even een paar maanden handelen.

Het schema is ook zoals ik het nu voor me zie. Wie weet krijg ik de komende maanden een briljante ingeving

[Pakhaas]

koboy schreef op woensdag 30 september 2026 @ 19:23:
[...]

Lijkt me onwaarschijnlijk. Het opladen naar 10% is de SoC bescherming in Gielz toch, en die kun je uitzetten. Maar iets om te testen tegen die tijd. Eerst nog even een paar maanden handelen.

Het schema is ook zoals ik het nu voor me zie. Wie weet krijg ik de komende maanden een briljante ingeving

Ik heb soc bescherming uit, maar als de batterij onder soc komt, dan neemt de Zendure het over. HEMS staat uit.

[koboy]

Pakhaas schreef op woensdag 30 september 2026 @ 19:30:
[...]

Ik heb soc bescherming uit, maar als de batterij onder soc komt, dan neemt de Zendure het over. HEMS staat uit.

Even testen gewoon tegen die tijd. Anders een extra conditie in de automatisering die het aantal goedkope kwartieren van 1 naar 12 zet samen met een aanpassing van de max SoC ofzo. Het gaat mij om met zo min mogelijk condities een zo groot mogelijk resultaat te bereiken.

[ppaulv]

Mai Pensato schreef op woensdag 30 september 2026 @ 18:45:
[...]

Welke Solarflows heb je, ik neem aan een Mix 3000 of 4000? Hoe heb je die in Gielz gekregen, heb je daar de Zendure Integration (fireson) niet bij nodig want die krijg ik niet geinstalleerd. En hoe wil je de 2e toren gaan gebruiken in Home Assistant?

het gaat om de 2400 serie ('gewoon', plus, pro).
Eén setje werkt al maanden prima met Gielz. En mijn vraag ging inderdaad over hoe ik de 2e toren, als die er komt, het beste kan inzetten.
@Mai Pensato er is een apart topic voor de mix serie, daar vind je dit vast wel. Of anders in het Zendure HA topic.

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

[koboy]

ppaulv schreef op woensdag 30 september 2026 @ 20:48:
[...]

het gaat om de 2400 serie ('gewoon', plus, pro).
Eén setje werkt al maanden prima met Gielz. En mijn vraag ging inderdaad over hoe ik de 2e toren, als die er komt, het beste kan inzetten.

Met de proxy van Gast777 maak je van 2 torens een enkele virtuele die je door Gielz dan weer laat aansturen. Aangezien je al gewend bent aan hoe Gielz werkt waarschijnlijk de makkelijkste methode.

Hoewel ikzelf me altijd aanbevolen houd voor een oplossing die:

• Primair NOM draait
• Overtollig opgeslagen PV via dynamische tarieven zo gunstig mogelijk dumpt
• Indien onvoldoende PV opwek verwacht goedkoop dynamisch oplaadt om op de dure momenten te ontladen

Tot nu toe nog niets ongecompliceerds qua installatie gevonden dat hieraan voldoet.

[ppaulv]

koboy schreef op woensdag 30 september 2026 @ 21:11:
[...]

Met de proxy van Gast777 maak je van 2 torens een enkele virtuele die je door Gielz dan weer laat aansturen. Aangezien je al gewend bent aan hoe Gielz werkt waarschijnlijk de makkelijkste methode.

Hoewel ikzelf me altijd aanbevolen houd voor een oplossing die:

• Primair NOM draait
• Overtollig opgeslagen PV via dynamische tarieven zo gunstig mogelijk dumpt
• Indien onvoldoende PV opwek verwacht goedkoop dynamisch oplaadt om op de dure momenten te ontladen

Tot nu toe nog niets ongecompliceerds qua installatie gevonden dat hieraan voldoet.

Dan is volgens mij de belangrijke vraag : waarom wil je NOM draaien? Is daarvan het doel dat je zo min mogelijk kosten hebt per dag? Want dan zou je gewoon maximaal moeten opladen tijdens goedkope uren en maximaal ontladen tijdens dure uren. En totaal niet kijken naar je eigen gebruik (maar alleen naar de sprad, die moet voldoende zijn om te compenseren voor accu verliezen en slijtage).
Persoonlijk vind ik NOM een aantrekkelijke strategie omdat het er zo mooi uitziet en het mij het gevoel geeft dat ik tot zekere hoogte zelfvoorzienend kan zijn met m'n zonnepanelen en accu. Maar financieel is het bepaald niet de slimste strategie natuurlijk.
Maar ik blijf een mens met emotie en een goed gevoel is voor mij ook veel waard

[thijsh02]

@koboy Nog bedankt voor jouw uitleg. Ik ga nu even draaien op Dynamisch NOM en heb de spread op 20% gezet.

Enige waarmee ik nog aan het stoeien ben is mijn 'oude' Hyper met 3 accu's. Deze kan niet in de integratie van Gielz draaien en had deze tot vandaag op een vast schema staan voor ontladen en alleen laden op de aangesloten pv's.

Heb hem net op Zenki Ai gezet en ga eens kijken of dat werkt. De 2400AC+ draait via @gielz en springt denk ik pas bij als de Hyper leeg is of gestopt is met ontladen. Ze halen beide hun data op via de P1 meter.

[Mai Pensato]

ppaulv schreef op woensdag 30 september 2026 @ 20:48:
[...]

het gaat om de 2400 serie ('gewoon', plus, pro).
Eén setje werkt al maanden prima met Gielz. En mijn vraag ging inderdaad over hoe ik de 2e toren, als die er komt, het beste kan inzetten.
@Mai Pensato er is een apart topic voor de mix serie, daar vind je dit vast wel. Of anders in het Zendure HA topic.

Dit is toch het Zendure HA topic.. 😊 In het Solarflow Mix topic verwijzen ze voor HA vragen ook hierheen. Ik wii graag weten hoe ik in ieder geval 1 van mijn Mix 3000 in HA krijg. Via de officiele integratie (fireson) lukt dat niet vanwege de bug die hier ook meerdere keren genoemd is en die zendure moet oplossen. Lukt dat via Gielz package wel?

Volgende stap is dan alle 3 integreren via de Gast777 proxy (of een andere?). Met nodered heb ik nog geen ervaring. Weet dus niet of dit lastig is.

Ik weet zeker dat hier voldoende ervaring en kennis zit om me op weg te helpen.

[koboy]

ppaulv schreef op woensdag 30 september 2026 @ 21:23:
[...]

Dan is volgens mij de belangrijke vraag : waarom wil je NOM draaien? Is daarvan het doel dat je zo min mogelijk kosten hebt per dag? Want dan zou je gewoon maximaal moeten opladen tijdens goedkope uren en maximaal ontladen tijdens dure uren. En totaal niet kijken naar je eigen gebruik (maar alleen naar de sprad, die moet voldoende zijn om te compenseren voor accu verliezen en slijtage).
Persoonlijk vind ik NOM een aantrekkelijke strategie omdat het er zo mooi uitziet en het mij het gevoel geeft dat ik tot zekere hoogte zelfvoorzienend kan zijn met m'n zonnepanelen en accu. Maar financieel is het bepaald niet de slimste strategie natuurlijk.
Maar ik blijf een mens met emotie en een goed gevoel is voor mij ook veel waard

Gaat om de strategie voor volgend jaar, om die reden is het ook een projectje voor de komende winter. Hangt er natuurlijk ook van of hoe de zaken er in het Midden Oosten bij staan, maar met een enkele 2400W omvormer is het ontlaad vermogen beperkt.

Nu is mijn verwachting (hallo @Polvo176 , ik ben het met je eens!) dat de EPEX handel volgend jaar een groot deel van de dagen niet renderend zal zijn door het wegvallen van de salderingsregeling. Als het kan wil ik dus wel een handelsdag draaien, maar ik moet bovenop de (ont)laad verliezen ook nog de energiebelasting goedmaken in de ruim 4 uur die het duurt om de accu te ontladen. Dat is dus nog een automatisering er bij.....

Nou is mijn accu overgedimensioneerd (hoef ik de PV niet terug te regelen bij negatieve prijzen, en voor als de stroom er afgaat), dus het deel dat ik niet nodig heb voor eigen gebruik moet in de avondpiek tegen zo gunstig mogelijk tarief de deur uit om plek te maken voor de volgende dag. Liever 25-20 cent/kWh vangen voor teruglevering dan hooguit een paar cent.

Maar als ze lekker met bommen blijven gooien in het Midden Oosten kan het best dat pure Epex handel rendabel blijft net als nu, dat moeten we gaan zien.

Ik zit in een iets boven de 100m² rijtjeshuis (koken op gas en gas CV) met 2700Wp op het dak en 11kWh accu. Auto laden houd ik helemaal buiten het energie management systeem. Die gaat 1x per week op het goedkoopste moment aan de lader want met een laadmat en geen eigen oprit is het niet echt praktisch altijd in te pluggen.

Met puur epex handel dit jaar lekker gedraaid: 4020 kWh inkoop tegen 18,1 cent, 2761 kWh tegen 31,8 cent verkoop, bijna 150 euro negatief totaal. Minimale spread op 25%. Kosten voor cycles/slijtage neem ik niet mee in de berekening voor de gewenste spread. Naar mijn mening is dit over de levensduur van de accu minder relevant omdat je ook te maken hebt met degradatie door tijd. Mentaal heb ik de accu op dag 1 volledig afgeschreven, en mag dat ding gewoon zo veel mogelijk rendement binnenhalen.

[koboy]

thijsh02 schreef op woensdag 30 september 2026 @ 22:05:
@koboy Nog bedankt voor jouw uitleg. Ik ga nu even draaien op Dynamisch NOM en heb de spread op 20% gezet.

Enige waarmee ik nog aan het stoeien ben is mijn 'oude' Hyper met 3 accu's. Deze kan niet in de integratie van Gielz draaien en had deze tot vandaag op een vast schema staan voor ontladen en alleen laden op de aangesloten pv's.

Heb hem net op Zenki Ai gezet en ga eens kijken of dat werkt. De 2400AC+ draait via @gielz en springt denk ik pas bij als de Hyper leeg is of gestopt is met ontladen. Ze halen beide hun data op via de P1 meter.

Minimale spread van 20% gaat uit van een 83% RTE. Ga je wel een beetje op het randje van rendabel zitten, maar we praten onder de streep waarschijnlijk over maximaal een paar euro verlies per jaar.

Die Hyper is wel een dingetje, maar je zou kunnen overwegen over te stappen naar de Zendure/fireson integratie want die kan beide aansturen net als Omnibattery dacht ik. Van Zenki zou ik niet te veel verwachten. Mijn test van eind vorig jaar liet vooral veel Artificial Stupidity gedrag zien, maar er zijn wellicht ontwikkelingen geweest. Loskoppelen van de P1 en puur de base load van je huis laten verzorgen (zoals nu?) en de 2400+ via de P1 de rest laten regelen is waarschijnlijk de eenvoudigste renderende oplossing.

[thijsh02]

@koboy ik heb nu een RTE van 85% dus opzich prima denk

De Hyper heb ik een tijdje in Fireson gehad, maar klapt er constant uit met de verbinding. Daarom was ik overgestapt op een tijdschema. Enige nadeel daarvan is weer dat je niet kan laden op de goedkope uren via een tijdschema. Dan moet je alles handmatig bijhouden en ga ik niet doen. Zal de komende periode eens dingen gaan testen. Heb de hyper toch vooral als noodaccu

[Ben(V)]

Pakhaas schreef op woensdag 30 september 2026 @ 19:30:
[...]

Ik heb soc bescherming uit, maar als de batterij onder soc komt, dan neemt de Zendure het over. HEMS staat uit.

Dit doet de BMS van de batterij zelf die zorgt ervoor dat de ingestelde minimum Soc gehandhaafd blijft, dus als die te laag wordt gaat hij zelf bijladen.

[Polvo176]

sender schreef op donderdag 24 september 2026 @ 21:21:
[...]

De officiële HomeWizard-integratie heeft geen instelling voor het interval. Hij pollt zelf, ongeveer elke 5 seconden. Er zijn twee manieren om naar 1 seconde te gaan.

Optie 1: custom integratie met WebSocket (aanrader)

"HomeWizard Instant" is een custom integratie voor P1-meters die data via de WebSocket van de lokale API v2 ontvangt. Updates komen binnen zodra het apparaat nieuwe data meldt, dus zonder polling. Je hebt firmware 6.00 of hoger nodig, en je moet tijdens de setup één keer op de knop van de dongle drukken. Je kunt hem via HACS toevoegen als custom repository (categorie Integration): `hprax/homeassistant-homewizard-instant`. Omdat hij een ander domein gebruikt, kan hij naast de officiële integratie draaien. (https://github.com/hprax/homeassistant-homewizard-instant)

Optie 2: polling uitzetten en zelf 1x per seconde verversen

1. Ga naar Instellingen → Apparaten & diensten → HomeWizard → de drie puntjes bij je apparaat → Systeemopties. Zet "Polling voor wijzigingen inschakelen" uit.

2. Maak een automation:

alias: HomeWizard P1 fast refresh

YAML:

alias: HomeWizard P1 fast refresh
triggers:
  - trigger: time_pattern
    seconds: "/1"
actions:
  - action: homeassistant.update_entity
    target:
      entity_id: sensor.p1_meter_power

Vervang de entity door een sensor van jouw P1-meter. Eén update_entity ververst alle entiteiten van dat apparaat.

Een paar dingen om op te letten:

- Een slimme meter met DSMR 5 of hoger levert elke seconde nieuwe data. Bij DSMR 4 is dat elke 10 seconden, en dan heeft 1 seconde geen zin.

- Vaak pollen belast de dongle en je database. Sluit de vermogenssensoren eventueel uit van de recorder.

Die instant versie werkt perfect, de optie 2 niet, HA schijnt dat zelf tegen te houden en over te gaan op 10 seconden.
blauw is per seconde, geel de standaard 5 sec van de HW P1

[ppaulv]

Mai Pensato schreef op woensdag 30 september 2026 @ 22:24:
[...]

Dit is toch het Zendure HA topic.. 😊 In het Solarflow Mix topic verwijzen ze voor HA vragen ook hierheen. Ik wii graag weten hoe ik in ieder geval 1 van mijn Mix 3000 in HA krijg. Via de officiele integratie (fireson) lukt dat niet vanwege de bug die hier ook meerdere keren genoemd is en die zendure moet oplossen. Lukt dat via Gielz package wel?

Volgende stap is dan alle 3 integreren via de Gast777 proxy (of een andere?). Met nodered heb ik nog geen ervaring. Weet dus niet of dit lastig is.

Ik weet zeker dat hier voldoende ervaring en kennis zit om me op weg te helpen.

excuus, was ervan overtuigd dat het hier om een ander Zendure onderwerp ging. My bad.

[ppaulv]

koboy schreef op woensdag 30 september 2026 @ 22:52:
[...]

Gaat om de strategie voor volgend jaar, om die reden is het ook een projectje voor de komende winter. Hangt er natuurlijk ook van of hoe de zaken er in het Midden Oosten bij staan, maar met een enkele 2400W omvormer is het ontlaad vermogen beperkt.

Nu is mijn verwachting (hallo @Polvo176 , ik ben het met je eens!) dat de EPEX handel volgend jaar een groot deel van de dagen niet renderend zal zijn door het wegvallen van de salderingsregeling. Als het kan wil ik dus wel een handelsdag draaien, maar ik moet bovenop de (ont)laad verliezen ook nog de energiebelasting goedmaken in de ruim 4 uur die het duurt om de accu te ontladen. Dat is dus nog een automatisering er bij.....

Nou is mijn accu overgedimensioneerd (hoef ik de PV niet terug te regelen bij negatieve prijzen, en voor als de stroom er afgaat), dus het deel dat ik niet nodig heb voor eigen gebruik moet in de avondpiek tegen zo gunstig mogelijk tarief de deur uit om plek te maken voor de volgende dag. Liever 25-20 cent/kWh vangen voor teruglevering dan hooguit een paar cent.

Maar als ze lekker met bommen blijven gooien in het Midden Oosten kan het best dat pure Epex handel rendabel blijft net als nu, dat moeten we gaan zien.

Ik zit in een iets boven de 100m² rijtjeshuis (koken op gas en gas CV) met 2700Wp op het dak en 11kWh accu. Auto laden houd ik helemaal buiten het energie management systeem. Die gaat 1x per week op het goedkoopste moment aan de lader want met een laadmat en geen eigen oprit is het niet echt praktisch altijd in te pluggen.

Met puur epex handel dit jaar lekker gedraaid: 4020 kWh inkoop tegen 18,1 cent, 2761 kWh tegen 31,8 cent verkoop, bijna 150 euro negatief totaal. Minimale spread op 25%. Kosten voor cycles/slijtage neem ik niet mee in de berekening voor de gewenste spread. Naar mijn mening is dit over de levensduur van de accu minder relevant omdat je ook te maken hebt met degradatie door tijd. Mentaal heb ik de accu op dag 1 volledig afgeschreven, en mag dat ding gewoon zo veel mogelijk rendement binnenhalen.

Okee ... maar het verhaal blijft denk ik hetzelfde? Alleen heb je dan te maken met gratis zonnestroom die op dat moment niet gebruikt wordt en waarvoor teruglevering nits oplevert of misschien wel geld zal kosten, afhankelijk van je contract.
Dan wordt de rekensom iets anders, namelijk de spread moet dan berekend worden tov een prijs van 0 ipv de echte laagste prijs die dag.
Dan zou je denk ik uit de voeten kunnen met a) Gielz op NOM zetten zolang de PV opbrengst groter is dan het eigen gebruik en b) smart discharge only of beter de handelsinstelling (dynamic trading + smart matching of een van die andere trading opties, ben er niet helemaal in thuis) als dat niet zo is.
Of is dit niet wat je zou willen?

[BestevaerNL]

delete

[ Voor 110% gewijzigd door BestevaerNL op 01-10-2026 15:42 ]

[koboy]

ppaulv schreef op donderdag 1 oktober 2026 @ 14:56:
[...]

Okee ... maar het verhaal blijft denk ik hetzelfde? Alleen heb je dan te maken met gratis zonnestroom die op dat moment niet gebruikt wordt en waarvoor teruglevering nits oplevert of misschien wel geld zal kosten, afhankelijk van je contract.
Dan wordt de rekensom iets anders, namelijk de spread moet dan berekend worden tov een prijs van 0 ipv de echte laagste prijs die dag.
Dan zou je denk ik uit de voeten kunnen met a) Gielz op NOM zetten zolang de PV opbrengst groter is dan het eigen gebruik en b) smart discharge only of beter de handelsinstelling (dynamic trading + smart matching of een van die andere trading opties, ben er niet helemaal in thuis) als dat niet zo is.
Of is dit niet wat je zou willen?

Vooraf: ik zit nog diep in een puzzel hierover, maar je hebt voor het zonnige seizoen te maken met grofweg 3 mogelijkheden. Oplopend in de hoogte van de spread zijn die:

1. Spread kleiner dan (ont)laadverliezen: niets doen alle stroom direct van/naar het net.
2. Ertussenin: overschot duur dumpen via bijvoorbeeld dynamic trading + smart matching, of snel ontladen
3. Spread zo hoog en de avondpiek piek zo hoog en lang genoeg (zomerse airco piek...) dat het loont om alles ipv alleen overschot te dumpen omdat het teruglevertarief hoger is dan het afname tarief later die nacht.

Nou is situatie 1 eenvoudig binnen Gielz af te vangen en zal situatie 3 niet zo heel veel voorkomen. Dus het kan zijn dat ik die situatie 3 in het potje "helaas pindakaas" stop omdat de financiële opbrengst t.o.v. situatie 2 niet opweegt tegen de moeite.
Situatie 2 vraagt dus nog wat werk, o.a. omdat de dynamische standen in Gielz aangestuurd worden in tijdsblokken en het niet mogelijk is om hierbij ook een SoC ondergrens op te geven zodat ik de nacht nog NOM doorkom. Maar dit zou eenvoudig regelbaar moeten kunnen worden met een extra automatisering. In de volle zomer boeit het niet zo veel, dan gaat de accu wel elke dag 100% vol vanuit de zon, maar in het voor en naseizoen zoals nu moet er afhankelijk van de dag een hoeveelheid gedumpt worden. Twee slechte dagen achter elkaar is dan weer voor het potje "helaas pindakaas", of er moet nog iets van een PV voorspeller bij in wat weer een bak meer werk is, terwijl ik het eigenlijk met zo min mogelijk logica een zo groot mogelijk effect wil halen.
Hoe ingewikkelder dingen worden hoe meer tijd het kost te bouwen en hoe meer kans op fouten of problemen bij updates.

N.B. dit hele verhaal boeit natuurlijk alleen bij dynamische contracten. Bij vast draai je gewoon NOM en boeit het niet of de accu "overloopt" en of de stroom er nou dezelfde dag of een week geleden in is gegaan.

[gast777]

MP3-Junky schreef op woensdag 30 september 2026 @ 07:20:
[...]

Zendure 1 had hier de 10% SoC bereikt. (de blauwe lijn onderin de grafiek)

Ohja, bedankt. Die zag ik over het hoofd.

Ik heb nog even in de code gekeken en als er bij ontladen eentje al op minsoc zit (10% in dit geval), dan wordt het Soc percentageverschil waarop wordt gecheckt welke het beste actief kunnen zijn (singleMode_change_device_diff_used) op 1% gezet.

JavaScript:

        // When discharging with one device at minSoc, set the singleMode_change_device_diff_used to 1
        if (socLimit_A == 2 || socLimit_B == 2 || socLimit_C == 2) {
            singleMode_change_device_diff_used = 1;
        } else {
            singleMode_change_device_diff_used = singleMode_change_device_diff;
        }

De reden is dat als bijvoorbeeld het tweede device ook de 10% raakt en stopt met laden, dan wil ik dat de laatste actief wordt en niet de tweede nog actief blijft maar niets doet.

Dat is op deze manier opgelost. Dan krijg je wel dit effect.

Ik kan eens nadenken of dit op een andere manier opgelost kan worden. Maar 'normaliter' zouden ze niet zo ver uit elkaar liggen lijkt me. Het kan wel gemakkelijker gebeuren als er een of twee direct via solar gevoed worden wellicht.

[Polvo176]

peterbier schreef op vrijdag 25 september 2026 @ 13:06:
[...]

Bij mij reageren de Zendures iedere seconde.
Dit kan ik zien aan de 3 fase MID kWh meter wat ik er tussen heb.
Nu dat ik de Shelly (2 seconden) in Fireson heb reageert het nog sneller dan de HW P1 heb ik het idee.

Ik gebruik inmiddels de HW 1 seconde instant intergratie.
Deze ook aan de Zendure manager geknoopt.
De Zendure batterijen reageerden bij mij normaal om de 5 seconden, nu om de 3 seconden, maar zeker niet elke seconde.
Morgen zet ik nog een Shelly Plug M Gen3 socket tussen de Quooker, het weg filteren van die pulsen was mijn hoofd doel.
De Zendure integratie speelt zelf ook een grote rol, het gaat niet altijd om de snelheid van de P1 meter.
Hier nog een voorbeeld zonder de manager op de 1 seconde integratie.
De batterijen werden opgeladen met zonne energie, de Quooker puls is 10 seconden, de Zendure reageert na 5 seconden, maar is pa na ruim een halve minuut weer op NOM.
En ik het tijden gezien van anderhalve minuut.
Dat ligt niet aan de P1 meter, maar aan de Zendure integratie.

[BestevaerNL]

Hoeveel waarde kan ik hangen aan de import en export efficiency binnen Gielz?

Ik heb de afgelopen 24h 85,5% export en 92,75% import.

Is dit gemiddeld tov van andere gebruikers het met een solarflow mix 3000 of 4000?

Ik heb de 4000 mix pro. Mijn pv is direct aangesloten op de zendure.

[gielz]

BestevaerNL schreef op donderdag 1 oktober 2026 @ 23:02:
Hoeveel waarde kan ik hangen aan de import en export efficiency binnen Gielz?

Ik heb de afgelopen 24h 85,5% export en 92,75% import.

Is dit gemiddeld tov van andere gebruikers het met een solarflow mix 3000 of 4000?

Ik heb de 4000 mix pro. Mijn pv is direct aangesloten op de zendure.

Je kunt het beste naar de totale RTE kijken. En dan pas over enkele maanden. Deze geeft een betrouwbaar beeld en wijkt zon 0,5% lager af van een MID meting;



De realtime RTE meting van de afgelopen 24 uur is meer om te bepalen of je niet inefficiënt aan het laden of ontladen bent. Je zet hem dan 5 minuten in een bepaalde stand en kijkt hoe efficiënt dit is.

[m-vw]

Polvo176 schreef op donderdag 1 oktober 2026 @ 21:27:
[...]

Ik gebruik inmiddels de HW 1 seconde instant intergratie.
Deze ook aan de Zendure manager geknoopt.
De Zendure batterijen reageerden bij mij normaal om de 5 seconden, nu om de 3 seconden, maar zeker niet elke seconde.
Morgen zet ik nog een Shelly Plug M Gen3 socket tussen de Quooker, het weg filteren van die pulsen was mijn hoofd doel.
De Zendure integratie speelt zelf ook een grote rol, het gaat niet altijd om de snelheid van de P1 meter.
Hier nog een voorbeeld zonder de manager op de 1 seconde integratie.
De batterijen werden opgeladen met zonne energie, de Quooker puls is 10 seconden, de Zendure reageert na 5 seconden, maar is pa na ruim een halve minuut weer op NOM.
En ik het tijden gezien van anderhalve minuut.
Dat ligt niet aan de P1 meter, maar aan de Zendure integratie.

[Afbeelding]

De spikes die iets achter de feiten aanlopen herken ik wel, maar die anderhalve minuut echt niet.

Verder zie ik continue veel discussie over de scaninterval van de P1 meter en de mogelijkheden om dit te versnellen. Maar als je bij de instellingen het ip-adres van je HW P1 sensor invult is de scaninterval ok gewoon 1sec.

Uit zendure_gielz1986_nl.yaml:

YAML:

  - resource_template: "http://{{ states('input_text.homewizard_p1_ip_adres') }}/api/v1/data"
    scan_interval: 1
    sensor:
      - name: "Homewizard P1 Vermogen"
        value_template: "{{ value_json.active_power_w | float }}"
        unique_id: Homewizard_P1_Vermogen
        unit_of_measurement: "W"
        device_class: power

[MrAngry]

Komt omdat het in een hele keten zit die allemaal scan intervallen hebben:

Van meter naar P1 meter. Dit ligt aan je meter type en dsmr versie.
Van P1 meter naar HA. Voor HomeWizard is dit normaal elke 5 seconden en via de REST API elke seconde
Van de HA sensor naar gielz. Dit staat default op 1 seconde.

De traagste scan interval in de keten bepaald de hele keten. Op dsmr 4 dus 10 seconden, dsmr 5 homewizard default 5 seconden, homewizard instant 1 seconde.

[Polvo176]

m-vw schreef op vrijdag 2 oktober 2026 @ 08:42:
[...]

De spikes die iets achter de feiten aanlopen herken ik wel, maar die anderhalve minuut echt niet.

Verder zie ik continue veel discussie over de scaninterval van de P1 meter en de mogelijkheden om dit te versnellen. Maar als je bij de instellingen het ip-adres van je HW P1 sensor invult is de scaninterval ok gewoon 1sec.

Uit zendure_gielz1986_nl.yaml:

YAML:

  - resource_template: "http://{{ states('input_text.homewizard_p1_ip_adres') }}/api/v1/data"
    scan_interval: 1
    sensor:
      - name: "Homewizard P1 Vermogen"
        value_template: "{{ value_json.active_power_w | float }}"
        unique_id: Homewizard_P1_Vermogen
        unit_of_measurement: "W"
        device_class: power

Dat wist ik niet, maar ik gebruik Gielz ook niet omdat ik een ratjetoe aan verschillende batterijen heb.
Overigens is het voorbeeld van die halve minuut wel in een specifieke sytuatie.
De batterijen laden op via direct aangesloten zonnepanelen maar zorgen tegelijk ook voor NOM.

Als 's avonds alle stroom uit de batterij komt reageert die anders, start 5 sec te laat en stopt 5 sec te laat.
Ik kan nog niet zien of dat met die 1 seconde P1 meting beter is, de huidige socket bij de Quooker geeft het via een omweg ook vertraagd door.
Nog even wachten op de Shelly

[Ben(V)]

De Zendure zelf reageert pas echt na zo'n 5 seconden.
Als de dan bijvoorbeeld een DSMR 4 meter hebt die maar elke 10 seconden nieuwe data geeft dan is de reactietijd iets tussen 6 en 16 seconden.

Een quooker die bijwarmt doet dat maar zo'n 10 tot 15 seconde elke keer.

[MP3-Junky]

gast777 schreef op donderdag 1 oktober 2026 @ 19:05:
[...]

Ohja, bedankt. Die zag ik over het hoofd.

Ik heb nog even in de code gekeken en als er bij ontladen eentje al op minsoc zit (10% in dit geval), dan wordt het Soc percentageverschil waarop wordt gecheckt welke het beste actief kunnen zijn (singleMode_change_device_diff_used) op 1% gezet.

JavaScript:

        // When discharging with one device at minSoc, set the singleMode_change_device_diff_used to 1
        if (socLimit_A == 2 || socLimit_B == 2 || socLimit_C == 2) {
            singleMode_change_device_diff_used = 1;
        } else {
            singleMode_change_device_diff_used = singleMode_change_device_diff;
        }

De reden is dat als bijvoorbeeld het tweede device ook de 10% raakt en stopt met laden, dan wil ik dat de laatste actief wordt en niet de tweede nog actief blijft maar niets doet.

Dat is op deze manier opgelost. Dan krijg je wel dit effect.

Ik kan eens nadenken of dit op een andere manier opgelost kan worden. Maar 'normaliter' zouden ze niet zo ver uit elkaar liggen lijkt me. Het kan wel gemakkelijker gebeuren als er een of twee direct via solar gevoed worden wellicht.

Ik heb op de accu’s geen PV panelen direct aangesloten. Het omschreven gedrag lijkt overigens sporadisch voor te komen.

[koboy]

Ben(V) schreef op vrijdag 2 oktober 2026 @ 13:42:
De Zendure zelf reageert pas echt na zo'n 5 seconden.
Als de dan bijvoorbeeld een DSMR 4 meter hebt die maar elke 10 seconden nieuwe data geeft dan is de reactietijd iets tussen 6 en 16 seconden.

Een quooker die bijwarmt doet dat maar zo'n 10 tot 15 seconde elke keer.

Nuance: het TOTALE SYSTEEM kan met een DSMR 5 meter (of snel uit leesbare CT klemmen) tot wel 5 of meer seconden nodig hebben om de reactie op een wisseling in de huis belasting af te ronden. Meer dan 5 seconden vooral bij heel grote vermogens wisselingen, zeker als er ook nog een wisseling van laden-ontladen bij komt kijken, maar een kleine wisseling van een paar honderd watt is binnen de 1 seconde update frequentie van de uitlezing bij mij klaar (net uitgetest met de handmatige stand van Glielz). Hierom heeft zoals hierboven aangehaald de fireson integratie een vertraging van 3 seconden tussen de opdrachten en de Gielz integratie een vertraging van 5 seconden.

De Zendure kan dus wel meer opdrachten aan, maar het is zinloos deze te sturen voordat je zeker weet dat de vorige opdracht totaal verwerkt is. Als de Zendure maar elke 5 seconden een opdracht zou accepteren was het nutteloos deze vertraging in de integraties te verwerken.

[c0mplex1]

Dus zou je eigenlijk 2 verschillende tijdsintervallen moeten hebben.

's Nachts elke 3 seconde, omdat het nachtverbruik laag is en overdag elke 5 seconden, omdat je dan grotere vermogensverschillen kan hebben.

[BestevaerNL]

Ik heb sinds een paar dagen de 4000 mix pro thuis staan.

De zonnepanelen zijn direct aangesloten op de Zendure.

Nu zie ik dat als de accu snel begint te laden door bv de mode "Dynamic Smart Matching" dat de PV dan offline gaat.

Klopt dit? Zo ja, waarom is dit?

[Ben(V)]

koboy schreef op vrijdag 2 oktober 2026 @ 14:24:
[...]

Nuance: het TOTALE SYSTEEM kan met een DSMR 5 meter (of snel uit leesbare CT klemmen) tot wel 5 of meer seconden nodig hebben om de reactie op een wisseling in de huis belasting af te ronden. Meer dan 5 seconden vooral bij heel grote vermogens wisselingen, zeker als er ook nog een wisseling van laden-ontladen bij komt kijken, maar een kleine wisseling van een paar honderd watt is binnen de 1 seconde update frequentie van de uitlezing bij mij klaar (net uitgetest met de handmatige stand van Glielz). Hierom heeft zoals hierboven aangehaald de fireson integratie een vertraging van 3 seconden tussen de opdrachten en de Gielz integratie een vertraging van 5 seconden.

De Zendure kan dus wel meer opdrachten aan, maar het is zinloos deze te sturen voordat je zeker weet dat de vorige opdracht totaal verwerkt is. Als de Zendure maar elke 5 seconden een opdracht zou accepteren was het nutteloos deze vertraging in de integraties te verwerken.

Het gaat natuurlijk niet om wijzigingen van kleine vermogens, het resultaat daarvan is marginaal.

Waar het om gaat is grote vermogens zoals bijvoorbeeld de 2000W van een Quooker die maar 10 tot 15 seconden elke keer bijwarmt.
Tegen de tijd dat de Zendure dat vermogen begint te leveren stopt de quooker al bijna weer en stuur je dat batterij vermogen voornamelijk het net op, tevens blijft de batterij dan te lang leveren.
De Zendure snelheid kun je niets aan doen maar een trage meter maakt het alleen maar erger en daar kun je wel wat aan doen.

Een quooker waar geen water uit getapt wordt zal dat ongeveer elk half uur bijverwarmen.
Ik heb dat dus opgelost met een powerplug die elke vier uur de quooker laat verwarmen en dan trekt hij veel langer vermogen.
Nadeel is dat als je de spanning van een quooker afhaalt hij geen kokend water kan leveren, maar dat heb ik opgelost door een Zigbee knopje in de keuken waarmee ik hem even kan inschakelen en een automatisering die hem na een paar minuten weer uitschakelt.

[koboy]

Ben(V) schreef op vrijdag 2 oktober 2026 @ 15:54:
[...]

Het gaat natuurlijk niet om wijzigingen van kleine vermogens, het resultaat daarvan is marginaal.

Waar het om gaat is grote vermogens zoals bijvoorbeeld de 2000W van een Quooker die maar 10 tot 15 seconden elke keer bijwarmt.
Tegen de tijd dat de Zendure dat vermogen begint te leveren stopt de quooker al bijna weer en stuur je dat batterij vermogen voornamelijk het net op, tevens blijft de batterij dan te lang leveren.
De Zendure snelheid kun je niets aan doen maar een trage meter maakt het alleen maar erger en daar kun je wel wat aan doen.

Een quooker waar geen water uit getapt wordt zal dat ongeveer elk half uur bijverwarmen.
Ik heb dat dus opgelost met een powerplug die elke vier uur de quooker laat verwarmen en dan trekt hij veel langer vermogen.
Nadeel is dat als je de spanning van een quooker afhaalt hij geen kokend water kan leveren, maar dat heb ik opgelost door een Zigbee knopje in de keuken waarmee ik hem even kan inschakelen en een automatisering die hem na een paar minuten weer uitschakelt.

Jij beweert dat een Zendure zowiezo 5 seconden nodig heeft om te reageren. Dat doe je op een manier die suggereert dat dit in het algemeen is, ipv alleen bij hoge vermogens wisselingen. Net als een dag of wat geleden je beweerde dat een Zendure maar elke 5 seconden een opdracht accepteert (kom ik hopelijk nog wel eens op terug als ik tijd heb).

Reageer ik er extreem vriendelijk en voorzichtig op met nuance is het nog niet goed. En kom je met een heel verhaal over hoe jij (mooi creatief!) het pulseren van de Quooker hebt opgelost. Een verhaal dat je beter had kunnen voor de post waar ik op reageerde.

Maar verder: Laamaazittuh, toedels!
Volgende keer alleen maar "onzin", en verder verspil ik er geen tijd meer aan om zaken te onderbouwen dan wel toe te lichten.

[Ben(V)]

Zucht..... Lees jij je eigen verhalen wel eens terug?

[ppaulv]

Mannen (@Ben(V) en @koboy ) ik waardeer jullie bijdragen doorgaans enorm en i kzal zeker niet de enige zijn, maar zonder hier de moraalridder te willen uithangen : misschien is het een idee om dit onderling uit te praten?

[koboy]

Laatmaarzitten.

[ Voor 96% gewijzigd door koboy op 02-10-2026 18:50 ]

[peterbier]

Bij mij reageren de Zendures wel sneller als die 5 seconden.
Met de 2 seconden Shelly werkt het na mijn idee iets beter. (NOM)
Ik heb de 1 seconden integratie al in HomeAssistant staan van de HomeWizard P1.
Via HACS.
Deze zal ik binnenkort eens uitproberen in Fireson.

Wat betreft een Quooker deze zal ik uit zetten in de nacht.
Ik heb dan geen Quooker maar een hotfill boiler.
Deze is gewoon uit in de nacht. (Automatisering)

[koboy]

ppaulv schreef op vrijdag 2 oktober 2026 @ 17:35:
Mannen (@Ben(V) en @koboy ) ik waardeer jullie bijdragen doorgaans enorm en i kzal zeker niet de enige zijn, maar zonder hier de moraalridder te willen uithangen : misschien is het een idee om dit onderling uit te praten?

Ik geniet absoluut van discussies (zoals over hoe de aansturing van Gielz te tweaken van gisteren), over hoe zaken aan te pakken, help graag mensen, en vraag incidenteel ook wel eens om hulp.

Maar er valt niets uit te praten als iemand niet kan hebben dat hij aangesproken wordt op onzin. Zoals ik vaker heb gezegd: als iets onzin is reageer ik daarop wie dat dan ook is. Ik stop daar nu totaal mee.

Unsubscribed!

[peterbier]

Super Cow schreef op donderdag 24 september 2026 @ 13:13:
[...]

De homewizard P1 polling is standaard 5 sec toch?
Ik kwam dit tegen: https://github.com/taurgis/homeassistant-homewizard-instant

Ik maak zelf gebruik van een homewizard 1 fase din meter(ik nog geen slimme meter ), waar ik dit ook heb moeten veranderen.

Nog bedankt.
Integratie er net erop gezet.
Het maakt een 2e (Instant) aan naast de HomeWizard.
Nu kan ik de P1 meter per seconde in HomeAssistant uitlezen. (Testen via Fireson moet ik nog)

[meesje]

peterbier schreef op vrijdag 2 oktober 2026 @ 19:53:
[...]

Nog bedankt.
Integratie er net erop gezet.
Het maakt een 2e (Instant) aan naast de HomeWizard.
Nu kan ik de P1 meter per seconde in HomeAssistant uitlezen. (Testen via Fireson moet ik nog)
[Afbeelding]

Waarom Fireson en niet Gielz? Deze laatste doet standaard al per 1 seconde uitlezen.

[peterbier]

meesje schreef op vrijdag 2 oktober 2026 @ 20:19:
[...]

Waarom Fireson en niet Gielz? Deze laatste doet standaard al per 1 seconde uitlezen.

Omdat ik 3 verschillende Zendures heb eigenlijk heb ik de Hyper er ook nog bij.
De Fireson vindt ik heel prettig werken.
Ook omdat ik ook verschillen in opslag per Zendure heb.

[sender]

peterbier schreef op vrijdag 2 oktober 2026 @ 19:53:
[...]

Nog bedankt.
Integratie er net erop gezet.
Het maakt een 2e (Instant) aan naast de HomeWizard.
Nu kan ik de P1 meter per seconde in HomeAssistant uitlezen. (Testen via Fireson moet ik nog)
[Afbeelding]

26 normale homewizard apparaten??? Hoe dan, watermeter, p1 meter en dan nog 24?

[meesje]

sender schreef op vrijdag 2 oktober 2026 @ 20:31:
[...]

26 normale homewizard apparaten??? Hoe dan, watermeter, p1 meter en dan nog 24?

Ik vermoed Energy sockets.

[meesje]

peterbier schreef op vrijdag 2 oktober 2026 @ 20:28:
[...]

Omdat ik 3 verschillende Zendures heb eigenlijk heb ik de Hyper er ook nog bij.
De Fireson vindt ik heel prettig werken.
Ook omdat ik ook verschillen in opslag per Zendure heb.

Drie verschillende (omvormers) werkt inderdaad niet via Gielz/gast777. Verschil in opslag maakt volgens mij niet uit. Ik drie keer 800plus waarvan eentje met een ab2000x. Dat werkt volgens mij prima.

[peterbier]

sender schreef op vrijdag 2 oktober 2026 @ 20:31:
[...]

26 normale homewizard apparaten??? Hoe dan, watermeter, p1 meter en dan nog 24?

Tja HomeWizard sockets en 8 kWh meters. ben de sockets aan het uitfaseren.
Inmiddels al meer dan 50 Shellys.
Daarnaast ook nog veel KNX en Nikobus.
Een beetje een uit de hand gelopen hobby.😅

[Polvo176]

peterbier schreef op vrijdag 2 oktober 2026 @ 20:53:
[...]

Tja HomeWizard sockets en 8 kWh meters. ben de sockets aan het uitfaseren.
Inmiddels al meer dan 50 Shellys.
Daarnaast ook nog veel KNX en Nikobus.
Een beetje een uit de hand gelopen hobby.😅

Grappig, hier idem, heb net een handvol Shelly's binnen gekregen, al kom ik nog lang niet aan 50 toe.
Ik heb wel gezien dat de batterijen sneller reageren met de instant integratie, stapjes van 1 en 2 seconden komen ook voor.

[peterbier]

Polvo176 schreef op vrijdag 2 oktober 2026 @ 21:32:
[...]

Grappig, hier idem, heb net een handvol Shelly's binnen gekregen, al kom ik nog lang niet aan 50 toe.
Ik heb wel gezien dat de batterijen sneller reageren met de instant integratie, stapjes van 1 en 2 seconden komen ook voor.

Oke ga het nog testen blijft leuk.😃

Off topic.
TIP zet alle Shellys op eco mode.
Shelly plugs hebben minder stroomverbruik dan HomeWizard. (Relais ingeschakeld)
Uit meting kom ik bij HomeWizard op 1.2 watt.
Bij Shelly minder dan 0.5 watt.
Als je er een paar gebruikt loopt het wa los.
Als de hoeveelheid toe neemt kan het Standby verbruik wel toenemen. (Met zo,n tussen stekker)

[Polvo176]

peterbier schreef op vrijdag 2 oktober 2026 @ 21:48:
[...]

Oke ga het nog testen blijft leuk.😃

Off topic.
TIP zet alle Shellys op eco mode.
Shelly plugs hebben minder stroomverbruik dan HomeWizard. (Relais ingeschakeld)
Uit meting kom ik bij HomeWizard op 1.2 watt.
Bij Shelly minder dan 0.5 watt.
Als je er een paar gebruikt loopt het wa los.
Als de hoeveelheid toe neemt kan het Standby verbruik wel toenemen. (Met zo,n tussen stekker)

Heb ook even naar het energie verbruik gekeken, als je er 50 hebt tikt elke watt wel aan.
Scheelt bij mij niks tussen Shelly en HW.

Nog even een plaatje met de instant integratie, anders waren de batterij stappen altijd 5 sec, de HW p1 ook.
Nu zie je variatie in de reactie snelheid, of het echt wat uithaalt moet nog blijken.
De Shelly is wel zo razend snel dat ik geen last meer heb van de cloud vertraging.
Ik kan nu de Quooker er uitfilteren.

[Polvo176]

Hier nog even een update, ondanks dat de batterij nu stapjes kan maken van 1, 2 of 3 seconden reageert hij nog altijd 5 seconden na een fikse puls van de Quooker.
Helemaal snap ik dat niet, want hij kán nu wel sneller reageren.

[peterbier]

Hier reageert het direct (rookmachine 700 watt)
Het kan ook nog in het netwerk zitten slecht wifi signaal bij de Zendure.
Of sterk maar de kwaliteit slecht.


Ook al mee gemaakt dat Zendure een accesspoint verder weg pakte en hierdoor traag reageert.
Lock op ap nu ingesteld.

[ Voor 60% gewijzigd door peterbier op 03-10-2026 00:06 ]

[peterbier]

Nu met een project bezig met een Raspberry Pi als cliënt om zo ook de Fireson te bedienen.
Met touchscreen.
Werkt wel mooi om ook de Zendures aan te sturen en de status te bekijken.

[Mimiix]

BestevaerNL schreef op vrijdag 2 oktober 2026 @ 15:35:
Ik heb sinds een paar dagen de 4000 mix pro thuis staan.

De zonnepanelen zijn direct aangesloten op de Zendure.

Nu zie ik dat als de accu snel begint te laden door bv de mode "Dynamic Smart Matching" dat de PV dan offline gaat.

Klopt dit? Zo ja, waarom is dit?

Gaat de pv offline of levert ie aan het huis?

[BestevaerNL]

Mimiix schreef op zaterdag 3 oktober 2026 @ 05:52:
[...]

Gaat de pv offline of levert ie aan het huis?

Nee, hij gaat offline

[Spike2100]

Heeft iemand een definitieve oplossing tegen die onvoorspelbare batterij SOC sinds die V2 update? Bij mij maakt het niet uit of ik die op 5, 10 of 15 zet. Er wordt precies altijd een dipje onder die soc gemaakt zodat het manuele laden automatisch start. Zeer on-interessant met 2 batterijen en capaciteitstarief. Ik gebruik de fireson automatisatie.

Onderstaand vind ik echter vreemd en extreem. Ik had voor te testen mijn soc gisteren op 5 gezet, 2 omvormers heb ik staan. (Dit is een test hé, graag hou ik de batterij op minimum 10 a 15%)

Ik heb een automatisatie die het ontladen stopt wanneer 1 van de batterijen tussen de 10-15% is. Je ziet rond 7h gaat die trigger af. 1 batterij staat op 14%, de andere op 17%. Het ontladen stopt netjes, voor beide batterijen. Echter bleed die van 17% (blauwe lijn) toch nog naar 4% terwijl er niet ontladen wordt....Dat is toch géén normale marge meer.

[B-Force]

Ik gebruik Omnibattery om mijn batterij aan te sturen. Werkt prima, ik krijg alleen regelmatig de melding dat mijn Shelly 3 EM Pro niet snel genoeg update. Daarom heb ik het volgende script draaien op mijn Shelly:

code:

let interval_ms = 2000; // 2 second
Timer.set(interval_ms, true, function () {
    Shelly.getComponentStatus("em", 0, function (res) {
        MQTT.publish("shellypro3em-" + Shelly.getDeviceInfo().id + "/status/em:0", JSON.stringify(res));
    });
}, null);

Maar nog steeds krijg ik deze melding. Doe ik iets verkeerd of kan ik beter iets anders in het script zetten?

[Mimiix]

BestevaerNL schreef op zaterdag 3 oktober 2026 @ 06:57:
[...]

Nee, hij gaat offline

Ik zou een support ticket inschieten. Kijken wat ze zeggen.

[m-vw]

Spike2100 schreef op zaterdag 3 oktober 2026 @ 09:09:
Heeft iemand een definitieve oplossing tegen die onvoorspelbare batterij SOC sinds die V2 update? Bij mij maakt het niet uit of ik die op 5, 10 of 15 zet. Er wordt precies altijd een dipje onder die soc gemaakt zodat het manuele laden automatisch start. Zeer on-interessant met 2 batterijen en capaciteitstarief. Ik gebruik de fireson automatisatie.

Onderstaand vind ik echter vreemd en extreem. Ik had voor te testen mijn soc gisteren op 5 gezet, 2 omvormers heb ik staan. (Dit is een test hé, graag hou ik de batterij op minimum 10 a 15%)

Ik heb een automatisatie die het ontladen stopt wanneer 1 van de batterijen tussen de 10-15% is. Je ziet rond 7h gaat die trigger af. 1 batterij staat op 14%, de andere op 17%. Het ontladen stopt netjes, voor beide batterijen. Echter bleed die van 17% (blauwe lijn) toch nog naar 4% terwijl er niet ontladen wordt....Dat is toch géén normale marge meer.


[Afbeelding]

Uit eigen ervaring, wat staat er als min SoC in de Zendure app?

Ik heb namelijk zelf ook een keer een mismatch gehad tussen HA en de app waarbij de app blijkbaar voorrang kreeg. Of weet je zeker dat de batterij op standby stond?