Zendure producten in Home Assistant integreren deel 2

[koboy]

Hippe Lip schreef op dinsdag 5 mei 2026 @ 03:41:
[...]


[...]


[...]


Waarom dat het anders maakt? Dat zal ik je vertellen, @Pakhaas. Het duurde even voordat ik het doorhad.

Je uitleg in de diverse posts hierboven (na de post van gisteren 21:33) klopt niet. En sorry dat ik het moet zeggen, maar je komt nog niet eens in de buurt, ook al klonk het in eerste instantie aardig geloofwaardig.

Eerst even wat feiten.

1. Ik ben netto gebruiker, dus neem in een jaar meer af dan ik teruglever, waardoor ik ook alle belastingen kan verrekenen bij het terugleveren.
2. Als de stroom 20 cent inkoop kost, dan moet die verkoop minimaal 20/0,8 (RTE) + 2,5 (inkoopvergoeding) = 27,5 cent opleveren voor break even. Dat is een spread van 37,5%. Bij een lagere stroomprijs wordt dat nog meer: bij 10 cent zelfs 50% en dan verdien ik dus nog geen cent, dus de spread moet hoger zijn dan dat. En dan heb ik de afschrijving van de batterij nog niet eens meegerekend.

Dan terug naar het nu. Dit is de grafiek van vandaag. En dan heb ik gekozen voor 16 kwartieren inkoop en 12 kwartieren verkoop.

[Afbeelding]

Op een dag als vandaag zou ik dan niets inkopen en niets verkopen als ik jouw advies volg omdat ik die spread van 37,5% lang niet haal.
En omdat je zegt dat ik ook geen NOM moet draaien, doe ik nix met de vulling van mijn batterijen en moet ik alle 24 uren stroom inkopen voor ruim 27 cent x 500W x 24 uur = 3,25 euro volgens jou:


[...]


Intussen vullen mijn panelen zich zelfs op een druilerige dag als gisteren voldoende om nog 2 uren terug te kunnen leveren aan het net, wat me 20-22 cent per kWh opleverde: 4,8 kW x 2 uur x 21 cent = 2 euro en houd ik voldoende over om de nacht door te komen tot de PV weer op gang komt.

Ergo:
Zou ik jouw redenering volg dan kost vandaag me 3,25.
Als ik eigenwijs ben en wel NOM draai en bovendien tijdens de 2 duurste uren teruglever vandaag tegen ruim 30 (piektarief vandaag) - 2,5 (terugleverkosten) = 27,5 cent x 4,8 kW dan kost me dat nix in het verbruik (NOM) en vang ik zelfs ca. 2,65 euro voor het terugleveren van het overschot van de dag.
Dat is een verschil van bijna 6 euro op één dag!
En met jouw advies herhaalt iets soortgelijks zich elke dag dat die spread niet bereikt wordt. Dat gaat me dus een hoop geld kosten.

Daarom ben ik blij met mijn NOM en lever ik vaak 3 tot 4 uur per etmaal terug tegen de dan hoogste prijzen.
Ja, er zullen dagen zijn dat ik wél die spread haal en dan kan ik kijken of in- en verkoop die dag wél rendabel kunnen zijn. Maar dan moet het dus zó rendabel zijn dat het de winst die ik hierboven beschrijf nog eens overstijgt.

Ook @YvonneVP
Als de winkel die dag geen wc papier geleverd kreeg en jij hebt nog een pallet wc papier liggen, wat is dan voordeliger: je pakken voor 10 euro aan de buren die in paniek zijn verkopen en de dagen erna tegen gewone prijs in de winkel een enkel pakje kopen, of dat pallet houden en zelf gebruiken het half jaar erna?
Eerste is handelen, tweede is NOM de accu legen....
Over inkopen op het goedkoopste moment waren we het eens.....

Bij mij doet de accu vandaag helemaal niets omdat de spread te klein is. De laadverliezen zijn dusdanig dat ik fractioneel goedkoper uit ben dan mijn eigen stroom opslaan of handelen. N.B. ook ik ben een netto gebruiker, en volgend jaar verwacht ik dat het aantal handelsdagen zeer beperkt zal zijn.

Maar ook voor mij hier een einde aan de off-topic discussie. Prima als je uit ideologische motieven NOM draait, net als de keuze voor samenom (er van uitgaand dat er geen winstdeling ofzo onder de deelnemers is), maar het is niet financieel de voordeligste.

[Hippe Lip]

@koboy en @Pakhaas
Ja, het begint langzaam door te dringen. Het is een andere manier van denken. En die hoort bij het onderwerp van dit topic overigens
Zonder die gedachte en het besef waar je mee bezig bent zijn de dingen hier niet van veel waarde; veel minder in elk geval.

koboy schreef op dinsdag 5 mei 2026 @ 12:02:
[...]
Prima als je uit ideologische motieven NOM draait, net als de keuze voor samenom (er van uitgaand dat er geen winstdeling ofzo onder de deelnemers is), maar het is niet financieel de voordeligste.

Klopt. Financieel voordeel is niet de bron van elke keuze; ideologie is er ook eentje
Punt erachter.

[ctrl-tab]

Mistraller schreef op dinsdag 5 mei 2026 @ 10:24:
[...]

Goeie tip; ik had inderdaad wel naar de resources gekeken maar ik had inderdaad nog geen goede history. Uit de logs lijken simpelweg de acties te missen.

[...]

Uiteraard ook mijn eerste gedachte. Die laptop waar het geheel op draait is al een oudje inderdaad. Maar met 900 entiteiten, ZHA, influx, grafana, een heleboel kleine integraties, en relatief eenvoudige automations tot nu toe altijd als een zonnetje.
Draait op een SSD. duplicate IP gaat je HA niet van op z'n gat Maar nee, ik heb de zendures een reserved IP in de router gegeven en ik kan ze verder prima zien in de app. En ik heb nooit netwerk issues gehad, zou sterk zijn als dat nu ineens aan het licht komt.

Echter: Resources lijkt wel de basis te zijn van de problemen. Ik zag dat hij enorm heeft staan swappen, tot ongeveer 6u vannacht, toen was ha core volgens mij gecrashed. En toen had ik dus node-red al gestopt en gielz naar 1 zendure laten kijken.
Helaas is ram uitbreiding voor die laptop bizar duur. Ik had 2GB toegewezen aan de VM, omdat de host slechts 4gb heeft. Nu de vm naar 2,5gig gezet en dat lijkt wel te helpen.
Dus ik hou het even in de gaten. Het lijkt wel by far de meest resource intensieve toevoeging op mijn HA instance die ik tot nu toe gezien heb, en dat zag ik niet aankomen; ik meen dat er geen minimale system resources waren opgegeven. Als blijkt dat ik daaronder zit is het misschien slim om in de prerequisites op te nemen. Dan zal ik nog wel eens meer testen, ik heb nog een andere laptop waar nieuwer type geheugen in gaat (en ook al zit). Reden voor laptop? Backup power

Dus ik ga het nog eens met de system monitor integration bekijken.

Tot zover alvast bedankt voor het meedenken!


Edit: Node-RED weet aangezet, en sommige stappen in de flow duren naar mijn idee wel érg lang . Gekke is dat het lijkt dat ie met zendure 3 wil connecten, maar die staat gewoon op "". (Call 3 zendure API; econn reset)
Swap usage in HA loopt weer op. Lijkt wel een memory leak?

[core-ssh ~]$ free -h
total used free shared buff/cache available
Mem: 2.4G 1.5G 36.1M 4.1M 864.6M 989.7M
Swap: 815.1M 348.4M 466.7M

Met alle respect, zou je niet een upgrade doen van je setup? De laptop staat als ik het zo hoor niet in verhouding tot de dure batterij die je ermee tracht aan te sturen. Hij presteert blijkbaar niet, maar zal ook veel meer stroom verbruiken dan een modernere opzet.
Een simpele mini pc met een wat oudere celeron/pentium (bv 5005, 4105) en een streepje geheugen van 16gb kost je niet veel. Zeker niet bij ali. Of je gaat de N100 zelfbouw route met een mini itx bordje, zit je zeker goed.

Ik heb me wel vaak afgevraagd of deze automation niet sneller zou zijn in python, maar ik draai zelf op overkill hardware dus merk er niet zo veel van. Wat ik ervan lees is dat LUA eigenlijk sneller zou moeten zijn. Maar kan me ook voorstellen dat HA niet geoptimaliseerd is voor een automation van 1300+ regels ?

edit ; dacht dat homeassistant automations onder water op lua draaiden, maar lijkt niet zo te zijn

[R1chardTM]

Ja zou je aanraden een kleine investering te doen in wat meer geschikte hardware. Ik draai mijn HA al jaren op een Raspberry Pi 3, kost weinig doet een hoop. Gebruikt ook zeer weinig stroom. Zou nu voor een iets modernere variant kiezen om wat meer toekomst proof te zijn. Of als je tegelijk HA wilt ondersteunen de HA green kopen.

[R.K]

Laatst deze thin cliënt gekocht met voorgeïnstalleerde HA. Draait als een zonnetje.

https://www.marktplaats.n...tm_campaign=socialbuttons

[Mistraller]

ctrl-tab schreef op dinsdag 5 mei 2026 @ 13:20:
[...]


Met alle respect, zou je niet een upgrade doen van je setup? De laptop staat als ik het zo hoor niet in verhouding tot de dure batterij die je ermee tracht aan te sturen. Hij presteert blijkbaar niet, maar zal ook veel meer stroom verbruiken dan een modernere opzet.
Een simpele mini pc met een wat oudere celeron/pentium (bv 5005, 4105) en een streepje geheugen van 16gb kost je niet veel. Zeker niet bij ali. Of je gaat de N100 zelfbouw route met een mini itx bordje, zit je zeker goed.

Ik heb me wel vaak afgevraagd of deze automation niet sneller zou zijn in python, maar ik draai zelf op overkill hardware dus merk er niet zo veel van. Wat ik ervan lees is dat LUA eigenlijk sneller zou moeten zijn. Maar kan me ook voorstellen dat HA niet geoptimaliseerd is voor een automation van 1300+ regels ?

Een mini PC heeft geen ingebakken UPS. Een laptop met een goede accu is gewoon ideaal, en het stroomverbruik is echt heel laag. Stroom eraf? Ding draait nog 2 uur door, stuurt me keurig een sms en als ik terug sms dat ie down moet gaan dan doet ie dat netjes. (Goed, offtopic hier) T'is een oude business laptop.
Tot aan de Zendure presteerde HA echt optimaal, nooit problemen gehad met wat dan ook. Dus dan ga ik niks vervangen, lijkt me logisch. HA draait dus wel binnen een KVM op ubuntu, dus geen baremetal config.

Dat gezegd hebbende, vanwege die peperdure ddr2 4gb bankjes was ik al aan het kijken naar een upgrade, we hebben hier nog een laptop die wel veel nieuwer is maar niet naar win11 kan dus dat wordt de opvolger. Zeker ga ik dat doen, don't worry. Waarom ik de HA vm niet op mijn NAS draai? Die nas staat in de meterkast, terwijl ik op zolder laptop met HA heb vanwege de verbindingen met de PV omvormers (RS485 / BT) en omdat dat een betere plek is voor mijn Zigbee coordinator.

NB: Ik denk dat mijn 6730b laptop wel ruimer in de resources zit dan een RPi 3 dus dat valt me dan wel weer op. Als het op een RPi3 goed draait; zou ik persoonlijk zeggen dat het bij mij ook niet bijzonder slecht zou moeten werken.

Mijn bijdrage is ook meer om aan te stippen dat de automation een behoorlijk zware wissel trekt als je geen heel ruime resources hebt, is ook ter lering voor anderen.
De meesten met HA beginnen klein immers. (Ik ben op een rpi model 1 begonnen )

Ik heb nu node-red op mijn nas draaien, tot nu toe blijft alles werken en ook de states gaan goed zie ik. (Ik doe nu NOM)
Ik zie nog wel gaps maar zolang het blijft werken tot ik de laptop heb vervangen ben ik tevreden.
Gek genoeg uit het zich niet in memory of CPU usage in de system monitor, alleen swap valt me op dat die al op 50% usage zit.
Enfin; blij dat het in elk geval geen domme config fout lijkt te zijn.

[ Voor 9% gewijzigd door Mistraller op 05-05-2026 15:08 ]

[Ben(V)]

De resources gaan voornamelijk op aan Windows en je VM manager en niet aan HA.
En een machine die gaat swappen is niet geschikt voor wat je er mee doet.

[gielz]

Mistraller schreef op dinsdag 5 mei 2026 @ 14:58:
[...]

Mijn bijdrage is ook meer om aan te stippen dat de automation een behoorlijk zware wissel trekt als je geen heel ruime resources hebt, is ook ter lering voor anderen.

De gielz integratie gebruikt een simpele automatisering. Kijk je naar de regels dan zijn het er veel. Maar iedere trigger gaat naar zijn eigen onderdeel met een x aantal voorwaarde.

De impact is dus bijna nul op een Home Assistant installatie. Zelf hier nog een tijd gedraaid op een Synology DS212. Zou dus overal op kunnen draaien als het beter is dan een aardappel.

[c0mplex1]

Voor wat het waard is...
Mijn volledige huis, incl. eigen ontwerp batterij automatisering, heb ik op een RPi5, 8GB mem en 128GB SD-kaart draaien en ik kan zeggen zonder enige haperingen o.i.d.
Voor mijn toepassingen is de RPi5 dus krachtig en snel genoeg.
(en nu niet gelijk de discussie gaan voeren waarom je geen PRi5 met SD-kaart moet gebruiken, want dat weet ik nu wel )

[R1chardTM]

Hier zelfs op een RPi 3 met een whopping 1GB geheugen (en ook op een SD 🙃 wel dagelijkse externe backup) en stuk meer integraties dan alleen Gielz. Ja je laptop blijft waarschijnlijk nog wel even draaien, maar je netwerk ook? Anders heb je er als nog niets aan.

Dus nee de automatisering is echt niet erg zwaar. Waarschijnlijk draaide je HA omgeving al net op het randje en is dit de druppel die de emmer doet overlopen.

[ Voor 35% gewijzigd door R1chardTM op 05-05-2026 17:34 ]

[wheli]

Dan om ook de andere kant te belichten, geen idee of het gerelateerd is, maar ik heb gisteravond na 4 reboots ivm wat tweaken mijn Rpi 4 doorgebrand. Er draaide natuurlijk meer dan alleen dit dashboard maar niet echt veel voor mijn gevoel.
Geen probleem, onderdeel van de hobby maar ik ga wel voor de rpi 5 denk ik.

[peterbier]

wheli schreef op dinsdag 5 mei 2026 @ 18:58:
Dan om ook de andere kant te belichten, geen idee of het gerelateerd is, maar ik heb gisteravond na 4 reboots ivm wat tweaken mijn Rpi 4 doorgebrand. Er draaide natuurlijk meer dan alleen dit dashboard maar niet echt veel voor mijn gevoel.
Geen probleem, onderdeel van de hobby maar ik ga wel voor de rpi 5 denk ik.

Draai al jaren een Raspberry Pi 4 met een samsung pro endurance sd kaart zonder problemen.
Omdat deze wat traag was nu draai ik HomeAssistant op een HP T530 (x86-64).
Die HP trekt ook z,n 3 a 4 watt.
De domotica draaide er al op maar nu ook de Zendure Fireson.
Het werkt perfect en snel.
Ik maak automatisch 1x per week een backup naar mijn Synology ds1520+ nas.
Misschien is z,n pctje wat.

[ctrl-tab]

wheli schreef op dinsdag 5 mei 2026 @ 18:58:
Dan om ook de andere kant te belichten, geen idee of het gerelateerd is, maar ik heb gisteravond na 4 reboots ivm wat tweaken mijn Rpi 4 doorgebrand. Er draaide natuurlijk meer dan alleen dit dashboard maar niet echt veel voor mijn gevoel.
Geen probleem, onderdeel van de hobby maar ik ga wel voor de rpi 5 denk ik.

Zou zelf altijd voor iets X86 gaan , omdat je dan meer performance en flexibiliteit krijgt.
Proxmox draai je bv al op een oude celeron j4105 en je krijgt er zoo veel flexibiliteit voor terug.
Het draaien van je HA in een vm biedt al zoveel voordelen, op gebied van backup/restore bijvoorbeeld.

[Mistraller]

gielz schreef op dinsdag 5 mei 2026 @ 16:04:
[...]


De gielz integratie gebruikt een simpele automatisering. Kijk je naar de regels dan zijn het er veel. Maar iedere trigger gaat naar zijn eigen onderdeel met een x aantal voorwaarde.

De impact is dus bijna nul op een Home Assistant installatie. Zelf hier nog een tijd gedraaid op een Synology DS212. Zou dus overal op kunnen draaien als het beter is dan een aardappel.

Ja dat was dus ook mijn verwachting eigenlijk, en daarom snap ik niet waarom het bij mij specifiek zo slecht werkt. Of er zit ergens heel erg veel vertraging wat de boel opknoopt of een conflict met iets wat ik al draai of zo.... memory leak door een automation vind ik ook onwaarschijnlijk. Nodered zelf zou je ook niet als boosdoener verwachten lijkt me, zoveel mensen die dat gebruiken. Apexcharts misschien die iets geks doet?

Ik heb zojuist in elk geval ff een range extender ertussen gezet, kijken of er toch slecht bereik is of zo, ondanks de melding dat de verbinding goed is. Maar de batterijtjes zijn nu leeg dus eerst wachten op zon tot er weer echt iets actief wordt. Ben benieuwd of HA morgenvroeg wel is blijven leven
Dochterlief heeft de opdracht gekregen om die oude laptop leeg te halen, upgrade is hoe dan ook een goed idee.

Nog wat data van HA:
Cpu usage avg 18%
Mem 61% (van 2,4GB)
Swap 51% (van 800MB)

[Mistraller]

R1chardTM schreef op dinsdag 5 mei 2026 @ 16:55:
Hier zelfs op een RPi 3 met een whopping 1GB geheugen (en ook op een SD 🙃 wel dagelijkse externe backup) en stuk meer integraties dan alleen Gielz. Ja je laptop blijft waarschijnlijk nog wel even draaien, maar je netwerk ook? Anders heb je er als nog niets aan.

Dus nee de automatisering is echt niet erg zwaar. Waarschijnlijk draaide je HA omgeving al net op het randje en is dit de druppel die de emmer doet overlopen.

Ik werk bij een financiële instelling, dus daar zijn we altijd bezig met een plan B
In de meterkast hangen modem, nas, switch, rpi en voordeurcamera, en de hoofdnode van mijn mesh aan een UPS. Die RPI doet de p1 data en diverse bedrade sensors (rook, PIR, watermeter, etc)
De laptop op zolder is met UTP aangesloten en blijft dus verbonden; zelfs de battery powered zigbee nodes blijven in principe draaien maar het halve mesh valt weg bij stroomuitval dus wordt onbetrouwbaar. Verder zit er een GSM modem met sim aan; als de stroom -en internet wegvallen dan krijg ik een SMS. En ik kan ook terug SMSen om commando's te geven. HA heeft uiteraard ook de status van de UPS en van zichzelf (AC of battery powered).
Ook kan ik bij stroomuitval volgens mij de offgrid poort aan zetten met HA. Moet ik nog even maken. Lokale wifi blijft immers draaien. (alleen nu ff niet met die range extender ertussen.)

Goed; zwaar offtopic, maar de Zendures passen wel perfect in mijn plaatje inzake mijn "technisch Noodpakket"

[RobTesla]

Mistraller schreef op dinsdag 5 mei 2026 @ 23:27:
[...]

Ik werk bij een financiële instelling, dus daar zijn we altijd bezig met een plan B
In de meterkast hangen modem, nas, switch, rpi en voordeurcamera, en de hoofdnode van mijn mesh aan een UPS. Die RPI doet de p1 data en diverse bedrade sensors (rook, PIR, watermeter, etc)
De laptop op zolder is met UTP aangesloten en blijft dus verbonden; zelfs de battery powered zigbee nodes blijven in principe draaien maar het halve mesh valt weg bij stroomuitval dus wordt onbetrouwbaar. Verder zit er een GSM modem met sim aan; als de stroom -en internet wegvallen dan krijg ik een SMS. En ik kan ook terug SMSen om commando's te geven. HA heeft uiteraard ook de status van de UPS en van zichzelf (AC of battery powered).
Ook kan ik bij stroomuitval volgens mij de offgrid poort aan zetten met HA. Moet ik nog even maken. Lokale wifi blijft immers draaien. (alleen nu ff niet met die range extender ertussen.)

Goed; zwaar offtopic, maar de Zendures passen wel perfect in mijn plaatje inzake mijn "technisch Noodpakket"

Welk O/S staat er op je laptop? Ik vermoed Windows? Zou je niet eens proberen met een Linux distro? Windows machines zijn zoveel slechter als server...

[MikeyMan]

Ben sinds dit weekend over op de (Standaard/Fireson) integratie. Vooral omdat HEMS zo'n slecht uitgevoerde aansturing van meervoudige accus heeft. De HA integratie gaat hier dan wel weer erg netjes mee om. Kan per accu min/max level aangeven... En bij laag vermogen laadt ie de accus om-en-om.

Draai simpel NOM, dus dat werkt voorlopig goed.
Heb ook nog geen enkele keer een storing van Zendure gezien.

Maar stiekem toch met een schuin oog aan het kijken naar de integratie van @gielz Vooral omdat deze niet afhankelijk is van de cloud. Enige nadeel is dat hier (nog?) geen support voor meerdere inverters is ingebouwd.

Nu kan daar natuurlijk de Node-Red achter gezet worden. Maar dan vraag ik mij af; voegt het toevoegen van extra lagen niet extra vertraging en/of kwetsbaarheid toe? Heb al Node Red draaien, in een aparte docker. En het spul is rock solid. Maar het wordt wel wat complex zo... Maar wellicht is mijn gevoel onjuist.

Eigenlijk ook jammer dat de standaard integratie alleen met de cloud werkt. Niet onbegrijpelijk natuurlijk.

[ Voor 57% gewijzigd door MikeyMan op 06-05-2026 09:05 ]

[wmc]

De legacy devices kunnen gewoon lokaal communiceren (https://github.com/Zendur...cal-Mqtt-(Legacy-Devices) ).

Als ik goed heb is de zenSDK per definitie lokaal, dus heb je helemaal geen cloud meer nodig.

[MikeyMan]

wmc schreef op woensdag 6 mei 2026 @ 09:17:
De legacy devices kunnen gewoon lokaal communiceren (https://github.com/Zendur...cal-Mqtt-(Legacy-Devices) ).

Als ik goed heb is de zenSDK per definitie lokaal, dus heb je helemaal geen cloud meer nodig.

Wacht... Als ik opnieuw de integratie installeer kan het wel lokaal...?

Das interessant... Wel weer een hoop spul hernoemen

De beschrijving is wel wat ambigu:
The configuration of local MQTT is only necessary for the Zendure Legacy devices: Hyper2000, Hub2000, Hub1200 and Ace1500. The newer devices SF800, SF800Pro and SF2400 do not need this, since they can communicate via zenSDK

Ik heb AC2400's. Dus niet necessary... Maar wel ondersteund? Even verder zoeken...

[ Voor 52% gewijzigd door MikeyMan op 06-05-2026 09:22 ]

[Mistraller]

RobTesla schreef op woensdag 6 mei 2026 @ 08:40:
[...]

Welk O/S staat er op je laptop? Ik vermoed Windows? Zou je niet eens proberen met een Linux distro? Windows machines zijn zoveel slechter als server...

Ik draai uiteraard geen Windows maar ubuntu en HA draait in een virtual machine (qemu-kvm).

[Ben(V)]

MikeyMan schreef op woensdag 6 mei 2026 @ 09:01:
Ben sinds dit weekend over op de (Standaard/Fireson) integratie. Vooral omdat HEMS zo'n slecht uitgevoerde aansturing van meervoudige accus heeft. De HA integratie gaat hier dan wel weer erg netjes mee om. Kan per accu min/max level aangeven... En bij laag vermogen laadt ie de accus om-en-om.

Draai simpel NOM, dus dat werkt voorlopig goed.
Heb ook nog geen enkele keer een storing van Zendure gezien.

Maar stiekem toch met een schuin oog aan het kijken naar de integratie van @gielz Vooral omdat deze niet afhankelijk is van de cloud. Enige nadeel is dat hier (nog?) geen support voor meerdere inverters is ingebouwd.

Nu kan daar natuurlijk de Node-Red achter gezet worden. Maar dan vraag ik mij af; voegt het toevoegen van extra lagen niet extra vertraging en/of kwetsbaarheid toe? Heb al Node Red draaien, in een aparte docker. En het spul is rock solid. Maar het wordt wel wat complex zo... Maar wellicht is mijn gevoel onjuist.

Eigenlijk ook jammer dat de standaard integratie alleen met de cloud werkt. Niet onbegrijpelijk natuurlijk.

De firesone integratie werk ook gewoon met ZenSDK.

[MikeyMan]

Ben(V) schreef op woensdag 6 mei 2026 @ 10:07:
[...]


De firesone integratie werk ook gewoon met ZenSDK.

Waar is dat verstopt dan?

ik heb in de (her) configuratie de toggle voor MQTT gevonden. Maar daar zie ik geen Zensdk terug...

Kan het ook niet terugvinden in de installatie stappen:
https://github.com/Zendure/Zendure-HA/wiki/Installation

MQTT is push vanuit de apparaten, ZenSDK is pull vanuit HA volgens mij... Voegt dat nog vertraging toe?

[ Voor 11% gewijzigd door MikeyMan op 06-05-2026 10:22 ]

[Ben(V)]

In het panel van de "Solarflow 2400 AC" in het veld "Control" kun je "Connection Mode " kiezen.
De opties zijn daar "Cloud" of "zenSDK".

[MikeyMan]

Ben(V) schreef op woensdag 6 mei 2026 @ 10:21:
In het panel van de "Solarflow 2400 AC" in het veld "Control" kun je "Connection Mode " kiezen.
De opties zijn daar "Cloud" of "zenSDK".

Jezus... Goed verstopt zeg! Had ook een generieke instelling kunnen zijn.

[Ben(V)]

Hoezo verstopt?
Is gewoon een simpele instelling.
Dat is het belangrijkste panel van de hele integratie, samen met die van de "Zendure Manager".

[ctrl-tab]

Ok ik heb een paar keer een oplossing benoemd voor DSMR4 gebruikers waar je de trigger van de automation wijzigt door deze te laten triggeren op een P1 sensor update.
Dit was lange tijd stabiel , maar ik was op vakantie dus eigenlijk geen grootverbruikers of grote pieken. Bij deze even op terug komen:

Inmiddels ben ik weer thuis van vakantie en heb ik toch meermaals gezien dat er spikes ontstaan waar de zendure constant zichzelf aan het corrigeren is.
Het lijkt erop dat een korstondige piek de initiatie is.

De oplossing met de P1 sensor update klinkt leuk, en zou in theorie goed moeten werken als de meter zich volledig aan de dsmr4 spec zou houden en het telegram altijd de actuele data representeert.
Dit lijkt niet het geval, en las al andere posts in deze thread die dat bevestigen. Bovendien heb ik sporadisch gezien dat er een wijziging in de sensor na 5 seconden plaats vond in plaats van 10 seconden. Dit laatste heeft verder geen directe impact gehad maar je ziet dat het niet super consistent is , althans bij mijn meter.
Zie onderstaande screenshots. Dit kan zo uren door gaan. Soms resolved het uit zichzelf, soms wordt het juist erger.

Een 15-20 seconden interval lijkt voor DSMR4 toch de beste oplossing. Dan baseer je je keuzes niet telkens op een enkel telegram , geef je meer rust voordat er beslissingen genomen worden.

Bedankt @gielz nog voor de support via dm.





Heb zelf een meter vervanging aangevraagd . Wil het gewoon goed zien werken.
Van de andere kant kan je je afvragen of dat beetje aan over- en under-shoots nou zo'n probleem is. Eigenlijk niet maarja je bent techneut of niet

[ Voor 5% gewijzigd door ctrl-tab op 06-05-2026 11:07 ]

[MikeyMan]

Ben(V) schreef op woensdag 6 mei 2026 @ 10:27:
Hoezo verstopt?
Is gewoon een simpele instelling.
Dat is het belangrijkste panel van de hele integratie, samen met die van de "Zendure Manager".

Nouja, zoals ik zei... Ik verwachtte hem op integratie-niveau.

Maar dit is ook wel zinnig, aangezien het per apparaat kan afwijken welke methode er gebruikt wordt.
Eens kijken wat er omvalt als ik de setting wijzig.

[Ben(V)]

ctrl-tab schreef op woensdag 6 mei 2026 @ 11:03:
Ok ik heb een paar keer een oplossing benoemd voor DSMR4 gebruikers waar je de trigger van de automation wijzigt door deze te laten triggeren op een P1 sensor update.
Dit was lange tijd stabiel , maar ik was op vakantie dus eigenlijk geen grootverbruikers of grote pieken. Bij deze even op terug komen:

Inmiddels ben ik weer thuis van vakantie en heb ik toch meermaals gezien dat er spikes ontstaan waar de zendure constant zichzelf aan het corrigeren is.
Het lijkt erop dat een korstondige piek de initiatie is.

De oplossing met de P1 sensor update klinkt leuk, en zou in theorie goed moeten werken als de meter zich volledig aan de dsmr4 spec zou houden en het telegram altijd de actuele data representeert.
Dit lijkt niet het geval, en las al andere posts in deze thread die dat bevestigen. Bovendien heb ik sporadisch gezien dat er een wijziging in de sensor na 5 seconden plaats vond in plaats van 10 seconden. Dit laatste heeft verder geen directe impact gehad maar je ziet dat het niet super consistent is , althans bij mijn meter.
Zie onderstaande screenshots. Dit kan zo uren door gaan. Soms resolved het uit zichzelf, soms wordt het juist erger.

Een 15-20 seconden interval lijkt voor DSMR4 toch de beste oplossing. Dan baseer je je keuzes niet telkens op een enkel telegram , geef je meer rust voordat er beslissingen genomen worden.

Bedankt @gielz nog voor de support via dm.

[Afbeelding]

[Afbeelding]

Heb zelf een meter vervanging aangevraagd . Wil het gewoon goed zien werken.
Van de andere kant kan je je afvragen of dat beetje aan over- en under-shoots nou zo'n probleem is. Eigenlijk niet maarja je bent techneut of niet

Je wilt helemaal niet dat die Zendure gaat reageren op snelle pieken.
Een Zendure heeft zelf een reactietijd van 3 to 5 seconden en gaat dus altijd naijlen en energie leveren als die allang niet meer gevraagd wordt(naijlen).

Ik heb hier een DSMR 5.0 meter en een Quooker, die verwarmt steeds met korte pieken waardoor de Zendure gaat leveren maar altijd te laat en te lang waardoor de energie het net opgaat, daar wordt je ook niet blij van

[RemmyB83]

Ben(V) schreef op woensdag 6 mei 2026 @ 11:45:
[...]


Je wilt helemaal niet dat die Zendure gaat reageren op snelle pieken.
Een Zendure heeft zelf een reactietijd van 3 to 5 seconden en gaat dus altijd naijlen en energie leveren als die allang niet meer gevraagd wordt(naijlen).

Ik heb hier een DSMR 5.0 meter en een Quooker, die verwarmt steeds met korte pieken waardoor de Zendure gaat leveren maar altijd te laat en te lang waardoor de energie het net opgaat, daar wordt je ook niet blij van

Soms moet je gewoon accepteren dat dingen niet perfect zijn. Gisteren ging hier de stoomreiniger door de woonkamer, en deze geeft de hele tijd korte piekjes. Leukste was mijn solar opwek was op dat moment ook nog eens laag, dus bij een piekje ontladen, en bij een dipje opladen. Nou dat werkt dus voor geen meter. Maarja echt belangrijk vind ik dat soort momentjes niet, zolang het in 90%van de tijd wel doet wat ik er van verwacht. 🙂

[ctrl-tab]

RemmyB83 schreef op woensdag 6 mei 2026 @ 12:07:
[...]

Soms moet je gewoon accepteren dat dingen niet perfect zijn. Gisteren ging hier de stoomreiniger door de woonkamer, en deze geeft de hele tijd korte piekjes. Leukste was mijn solar opwek was op dat moment ook nog eens laag, dus bij een piekje ontladen, en bij een dipje opladen. Nou dat werkt dus voor geen meter. Maarja echt belangrijk vind ik dat soort momentjes niet, zolang het in 90%van de tijd wel doet wat ik er van verwacht. 🙂

Als ik me niet vergis heb jij die trigger aangepast naar de sensor update?

Heb je het gedrag dat ik hierboven beschreef niet ervaren?

[Mimiix]

Ik heb getracht wat terug te zoeken, maar nog niet direct een antwoord kunnen vinden. Vergeef me dus als ik het gemist heb.

Ik heb in de Gielz integratie nu Dynamisch Nom ingesteld en de goedkoopste / duurste periodes ingesteld op 8 en 16. Ik zie dat ie op de goedkoopste momenten nu laad en op de duurdere momente ontlaad. Dat snap ik, maar ik begrijp niet goed wat ik hier het beste kan invullen. Waarom zou ik voor 8 kiezen ipv 4 bijvoorbeeld?

[RemmyB83]

ctrl-tab schreef op woensdag 6 mei 2026 @ 13:21:
[...]

Als ik me niet vergis heb jij die trigger aangepast naar de sensor update?

Heb je het gedrag dat ik hierboven beschreef niet ervaren?

Klopt ik heb hem toen idd aangepast. En bij een stabiel verbruik werkte hij goed. Maar zag ook af en toe het gedrag wat jij ziet. Leek wel als of hij ergens door nog steeds op de 5sec zat, of dat de de slimmemeter/batterij niet snel genoeg reageerde.

Ik heb mijn er toen verder niet in verdiept, aangezien mijn slimmemeter vervangen zou worden. En dat is inmiddels ook gebeurt.

[ctrl-tab]

RemmyB83 schreef op woensdag 6 mei 2026 @ 14:24:
[...]

Klopt ik heb hem toen idd aangepast. En bij een stabiel verbruik werkte hij goed. Maar zag ook af en toe het gedrag wat jij ziet. Leek wel als of hij ergens door nog steeds op de 5sec zat, of dat de de slimmemeter/batterij niet snel genoeg reageerde.

Ik heb mijn er toen verder niet in verdiept, aangezien mijn slimmemeter vervangen zou worden. En dat is inmiddels ook gebeurt.

Aah top. Wat merk je zelf aan verbetering sinds je upgrade?

[MikeyMan]

Overzetten van Cloud naar ZenSDK is naadloos verlopen. Merk niet echt verschil natuurlijk. Maar het lijkt te werken. Met dank aan @Ben(V)

Ben nog wel zoekende naar wat de pro's en cons zijn van:
- Cloud
- Zensdk
- MQTT

Push vs Pull. Afhankelijkheid zendure. Snelheid. Betrouwbaarheid. Etc. Maar voorlopig loopt het spulletje. Eerst de dashboards maar eens een beetje opschonen.

[RemmyB83]

ctrl-tab schreef op woensdag 6 mei 2026 @ 14:37:
[...]

Aah top. Wat merk je zelf aan verbetering sinds je upgrade?

Mijn verbruik is hier altijd wel redelijk stabiel, en behalve de kookplaat zag ik geen echte grote schommelingen.
Hier onder kun je zien dat het de eerste 10 dagen met de oude meter, minder vaak op 0 of lager was. Maar een echt groot duidelijk verschil om er een andere meter voor aan te schaffen heb ik niet.
Meterwissel was in mijn geval dan ook toeval, ookal heb ik vervolgens wel een verzwaring aangevraagd ivm de toekomst.


Edit, veel van de hier boven gedeelde staafdiagram hangt ook af van je verbruik, solaropstelling, en bijvoorbeeld het weer.
Je ziet bij mijn dan ook met de nieuwe meter een paar dagen dat dit onderuit gaat.

[ Voor 9% gewijzigd door RemmyB83 op 06-05-2026 15:16 ]

[DeKim]

Ik heb een dsmr 4.2 meter (de veelbesproken e350). Het valt mij op dat op het moment dat er een nieuwe meting van de p1 meter komt, deze al 10 seconde oud is. Alsof hij altijd het voorlaatste telegram doorstuurt. Ook als ik HA elke seconde de API laat uitlezen.

Dat betekent dus dat als een accu zou reageren op een verbruiker, je dat nog niet ziet in de volgende meting maar pas nog een meting later. Heb jij dat ook @ctrl-tab ?

Overigens heb ik nog geen thuisaccu. Ben me aan het inlezen om er straks eentje te kopen.

[ctrl-tab]

DeKim schreef op woensdag 6 mei 2026 @ 16:48:
Ik heb een dsmr 4.2 meter (de veelbesproken e350). Het valt mij op dat op het moment dat er een nieuwe meting van de p1 meter komt, deze al 10 seconde oud is. Alsof hij altijd het voorlaatste telegram doorstuurt. Ook als ik HA elke seconde de API laat uitlezen.

Dat betekent dus dat als een accu zou reageren op een verbruiker, je dat nog niet ziet in de volgende meting maar pas nog een meting later. Heb jij dat ook @ctrl-tab ?

Overigens heb ik nog geen thuisaccu. Ben me aan het inlezen om er straks eentje te kopen.

Ik heb zelf een Kaifa. Ik herken de 10 seconden oude telegrammen niet, volgens specs zou het telegram de laatste actuele status moeten zijn.
Dit lijkt in mijn geval ook niet altijd te kloppen, maar structureel 10 seconden is het zeker niet.

[jannus66]

Hallo, Ik gebruik de Gielz integratie, NOM, naar volle tevredenheid. Zit echter met 1 puntje; kan iemand mij in Jip en Janneke taal uitleggen wat de begrippen:
- opladen starten bij (staat nu op -200)
- oplaadmarge (staat nu op 50)
- ontladen bij (staat nu op 100)
- ontlaadmarge (staat nu op 5) betekenen?

Systeem:
Zendure SolarFlow 2400 AC+ (2.4 kWh) + 1x AB3000L (2.88 kWh)
7 panelen, hele dag zon (ZZW) (Fase 1)
3 fase DSMR 5 meter
eigen groep (Fase 2)
max oplaadvermogen 2000 W
max ontlaadvermogen 1500 W
Vast contract, Geen EV

[gast777]

jannus66 schreef op woensdag 6 mei 2026 @ 17:20:
Hallo, Ik gebruik de Gielz integratie, NOM, naar volle tevredenheid. Zit echter met 1 puntje; kan iemand mij in Jip en Janneke taal uitleggen wat de begrippen:
- opladen starten bij (staat nu op -200)
- oplaadmarge (staat nu op 50)
- ontladen bij (staat nu op 100)
- ontlaadmarge (staat nu op 5) betekenen?

Systeem:
Zendure SolarFlow 2400 AC+ (2.4 kWh) + 1x AB3000L (2.88 kWh)
7 panelen, hele dag zon (ZZW) (Fase 1)
3 fase DSMR 5 meter
eigen groep (Fase 2)
max oplaadvermogen 2000 W
max ontlaadvermogen 1500 W
Vast contract, Geen EV

Je kunt "Help tonen op dashboard" aanzetten. Dan zie je onderstaande uitleg. Laat maar horen als het dan nog niet duidelijk genoeg is.

[Panzer_V]

Wil toch even een compliment maken aan @gielz voor zijn integratie.

De afgelopen dagen heb ik mij suf gedacht om een oplossing te vinden voor de momenten dat in de vroege avonduren, na het koken en eten, de weckketel aangaat. Als die eenmaal op temp is gaat hij pendelen om op temp te blijven. Mijn panelen produceren in de avond nog 700 watt. Dussss, met de NOM modus gaat hij dus continu 'ontladen-standby-laden-standby-ontladen-etc.' doen. Met >50 schakelingen in 30 minuten.

Wat blijkt.....er is gewoon een 'SLIM ONTLADEN' modus. Kwestie van even handmatig de modus veranderen als de weckketel aangaat en nadien terugzetten.

bedankt @gielz !

[Henkoes]

Panzer_V schreef op woensdag 6 mei 2026 @ 19:41:
Wil toch even een compliment maken aan @gielz voor zijn integratie.

De afgelopen dagen heb ik mij suf gedacht om een oplossing te vinden voor de momenten dat in de vroege avonduren, na het koken en eten, de weckketel aangaat. Als die eenmaal op temp is gaat hij pendelen om op temp te blijven. Mijn panelen produceren in de avond nog 700 watt. Dussss, met de NOM modus gaat hij dus continu 'ontladen-standby-laden-standby-ontladen-etc.' doen. Met >50 schakelingen in 30 minuten.

Wat blijkt.....er is gewoon een 'SLIM ONTLADEN' modus. Kwestie van even handmatig de modus veranderen als de weckketel aangaat en nadien terugzetten.

bedankt @gielz !

Hoe verschilt slim ontladen van NOM dan?

[DrNickB]

Henkoes schreef op woensdag 6 mei 2026 @ 22:08:
[...]


Hoe verschilt slim ontladen van NOM dan?

Enkel ontladen, niet opladen.

Dus hij gaat niet wissellen tussen opladen en ontladen, hij blijft wel omhoog en omlaag schalen.

[Pakhaas]

Henkoes schreef op woensdag 6 mei 2026 @ 22:08:
[...]


Hoe verschilt slim ontladen van NOM dan?

Bij NOM wordt er ook geladen als er PV overschot is. Bij Alleen slim ontladen, gaat hij alleen ontladen als er stroom wordt gebruikt.

Eigenlijk best handig als het tarief hoog is en je dus je PV overschot rechtstreeks naar het net wil (want goede prijs) en je niet wil inkopen (want duur)

[ Voor 21% gewijzigd door Pakhaas op 06-05-2026 22:24 ]

[Hippe Lip]

MikeyMan schreef op woensdag 6 mei 2026 @ 14:50:
Overzetten van Cloud naar ZenSDK is naadloos verlopen. Merk niet echt verschil natuurlijk. Maar het lijkt te werken. Met dank aan @Ben(V)

Ben nog wel zoekende naar wat de pro's en cons zijn van:
- Cloud
- Zensdk
- MQTT

Push vs Pull. Afhankelijkheid zendure. Snelheid. Betrouwbaarheid. Etc. Maar voorlopig loopt het spulletje. Eerst de dashboards maar eens een beetje opschonen.

Waarom gebruik je de integratie van @gast777 niet samen met die van @gielz? Dan draait alles lokaal, alles in één en hoef je niet te hannesen met MQTT. Die twee integraties zijn echt letterlijk plug & play.

Of heb ik iets gemist in je wensen?

[YvonneVP]

koboy schreef op dinsdag 5 mei 2026 @ 12:02:
[...]


Ook @YvonneVP
Als de winkel die dag geen wc papier geleverd kreeg en jij hebt nog een pallet wc papier liggen, wat is dan voordeliger: je pakken voor 10 euro aan de buren die in paniek zijn verkopen en de dagen erna tegen gewone prijs in de winkel een enkel pakje kopen, of dat pallet houden en zelf gebruiken het half jaar erna?
Eerste is handelen, tweede is NOM de accu legen....
Over inkopen op het goedkoopste moment waren we het eens.....

Bij mij doet de accu vandaag helemaal niets omdat de spread te klein is. De laadverliezen zijn dusdanig dat ik fractioneel goedkoper uit ben dan mijn eigen stroom opslaan of handelen. N.B. ook ik ben een netto gebruiker, en volgend jaar verwacht ik dat het aantal handelsdagen zeer beperkt zal zijn.

Maar ook voor mij hier een einde aan de off-topic discussie. Prima als je uit ideologische motieven NOM draait, net als de keuze voor samenom (er van uitgaand dat er geen winstdeling ofzo onder de deelnemers is), maar het is niet financieel de voordeligste.

De energie die ik overdag goedkoop inkoop, en verbruik zodra de zonnepanelen niets meer leveren, levert uiteindelijk ook geld op. Ik heb tenslotte dan geen of nauwelijks verbruik. Jij mag handelen als je dat wilt. Ik ga gewoon lekker NOMmen. Ik heb de batterijen niet gekocht om te handelen, maar voor mijn eigen gebruik. Ik heb genoeg zonnestroom, en jaarlijks altijd een overschot. Als de zon de hele dag schijnt laadt ik dus mijn batterij op, maar lever ik ondertussen ook nog aan het net. Of ik pomp in een paar kleine uurtjes de batterij vol, en dan gaat de rest naar het net. Jij kunt dat misschien 'dom' of vreemd vinden. Echter bepaald een ieder zelf waar hij/zij zijn batterij voor wil inzetten. En daar valt niet over te discussiëren. Niets in het leven is zo zwart-wit zoals jij het stelt. Dit dus ook niet, en is voor een ieder anders naar gelang persoonlijke voorkeur. Als ik zou handelen, en ondertussen mijn eigen energierekening naar beneden wil halen, dan heb ik meer capaciteit nodig om het ook nog goed winstgevend te maken. En daar heb ik geen behoefte aan. Ik ben van mening dat ik het met een RTE van 81,5% niet slecht doe.

[YvonneVP]

R.K schreef op dinsdag 5 mei 2026 @ 14:45:
Laatst deze thin cliënt gekocht met voorgeïnstalleerde HA. Draait als een zonnetje.

https://www.marktplaats.n...tm_campaign=socialbuttons

Ik heb van diezelfde aanbieder de HP T730 gekocht, met wat meer RAM en een wat grotere SSD. En dat draait als een tierelier. Voorheen had ik HA op een VM draaien, en daar had ik ook alleen maar problemen mee. Zelfs met meer RAM toewijzing en een grotere HD toewijzing. Entso-e gooide ook elke keer roet in het eten, en uiteindelijk heb ik op die VM HA zo'n 4 keer opnieuw geïnstalleerd, tot ik er echt genoeg van had. Daarna dus de T730 gekocht, en sindsdien ben ik van alle ellende verlost. Mijn laptop laptop heeft een Intel Core i7 met 16 GB RAM en 477 GB HD. HA op een VM is misschien gewoon niet zo'n goede combi op een Windows machine. Zoals gezegd, ik ben blij dat ik die problemen niet meer heb.

[MikeyMan]

Hippe Lip schreef op woensdag 6 mei 2026 @ 23:36:
[...]

Waarom gebruik je de integratie van @gast777 niet samen met die van @gielz? Dan draait alles lokaal, alles in één en hoef je niet te hannesen met MQTT. Die twee integraties zijn echt letterlijk plug & play.

Of heb ik iets gemist in je wensen?

Nouja ik ben niet perse fan van het toevoegen van extra lagen.

Node red is een extra stap in die pijplijn. Had eigenlijk de aanname gedaan dat die ook met mqtt zou werken. Maar deze werkt via de api. En eerlijk gezegd handelt de originele integratie de twee inverters prima af.

Maar als ik AI zou moet geloven is mqtt intrinsiek sneller dan de api. En push ipv pull.

[ Voor 8% gewijzigd door MikeyMan op 07-05-2026 07:32 ]

[Pakhaas]

YvonneVP schreef op donderdag 7 mei 2026 @ 00:40:
[...]

Niets in het leven is zo zwart-wit zoals jij het stelt.

Geldzaken is behoorlijk zwartwit 😄

[ctrl-tab]

YvonneVP schreef op donderdag 7 mei 2026 @ 00:48:
[...]

Ik heb van diezelfde aanbieder de HP T730 gekocht, met wat meer RAM en een wat grotere SSD. En dat draait als een tierelier. Voorheen had ik HA op een VM draaien, en daar had ik ook alleen maar problemen mee. Zelfs met meer RAM toewijzing en een grotere HD toewijzing. Entso-e gooide ook elke keer roet in het eten, en uiteindelijk heb ik op die VM HA zo'n 4 keer opnieuw geïnstalleerd, tot ik er echt genoeg van had. Daarna dus de T730 gekocht, en sindsdien ben ik van alle ellende verlost. Mijn laptop laptop heeft een Intel Core i7 met 16 GB RAM en 477 GB HD. HA op een VM is misschien gewoon niet zo'n goede combi op een Windows machine. Zoals gezegd, ik ben blij dat ik die problemen niet meer heb.

Moet toch gewoon goed draaien in een vm , of dat nou windows als host heeft of linux.. goed, windows als vm host , daar gaan mijn haren van overeind staan om allerlei andere redenen. Wellicht de hdd die bottleneckte?

Draai zelf op proxmox in een vm (dus debian als host), voorheen op k8s, nu gewoon docker compose. Vlekkeloos, een jaar of 10 inmiddels.

[ZuinigeRijder]

Weet niet of deze vraag al gesteld is, maar ik heb het niet gevonden.

Ik heb 2x een Solarflow 800 Plus en ook 2x HW Energy socket ertussen, een HW P1 meter én een Zendure P1 meter. Tot nu toe gebruik ik de Zendure App. Ik weet dat de @gielz integratie maar 1 omvormer aanstuurt en dat je met @gast777 RED node proxy je 2 omvormers kunt koppelen. Ik vroeg me wel af hoe de statistieken voor 2 omvormers getoond worden.

Doet de proxy de statistieken combineren?

Of kun je maar van 1 omvormer de statistieken zien?

Kun je ook de statistieken van de andere omvormer in bijvoorbeeld een ander tabblad laten zien?

Of moet je een combinatie maken van de @gielz integratie (voor voornamelijk de aansturing) en de ZenSDK gebruiken voor de statistieken? Bijten die elkaar?

[Hippe Lip]

YvonneVP schreef op donderdag 7 mei 2026 @ 00:40:
[...]

De energie die ik overdag goedkoop inkoop, en verbruik zodra de zonnepanelen niets meer leveren, levert uiteindelijk ook geld op. Ik heb tenslotte dan geen of nauwelijks verbruik. Jij mag handelen als je dat wilt. Ik ga gewoon lekker NOMmen. Ik heb de batterijen niet gekocht om te handelen, maar voor mijn eigen gebruik. Ik heb genoeg zonnestroom, en jaarlijks altijd een overschot. Als de zon de hele dag schijnt laadt ik dus mijn batterij op, maar lever ik ondertussen ook nog aan het net. Of ik pomp in een paar kleine uurtjes de batterij vol, en dan gaat de rest naar het net. Jij kunt dat misschien 'dom' of vreemd vinden. Echter bepaald een ieder zelf waar hij/zij zijn batterij voor wil inzetten. En daar valt niet over te discussiëren. Niets in het leven is zo zwart-wit zoals jij het stelt. Dit dus ook niet, en is voor een ieder anders naar gelang persoonlijke voorkeur. Als ik zou handelen, en ondertussen mijn eigen energierekening naar beneden wil halen, dan heb ik meer capaciteit nodig om het ook nog goed winstgevend te maken. En daar heb ik geen behoefte aan. Ik ben van mening dat ik het met een RTE van 81,5% niet slecht doe.

Hier ‘moet’ ik toch een kleine nuance aanbrengen. Of je voorkeur nu uitgaat naar NOM of dat je liever handelt is natuurlijk een heel persoonlijke voorkeur. Ik ben ook meer van de NOM dan van de handel en wek in deze tijd van het jaar over het algemeen ook meer op dan dat ik verbruik.

Maar waar @Pakhaas het over had in zijn uitgebreide uitleg in meerdere delen aan mij een paar dagen geleden was wat je het beste doet om maximale financiële winst te behalen. Bij een kleine spread bijvoorbeeld levert direct terugleveren financieel meer op omdat je dan 100% van het overschot verkoopt voor de dan geldende prijs. Sla je het op om het in de nacht te gebruiken, dan heb je maar (ca.) 80% van dat overschot beschikbaar. De prijs van die kWh’s is dan 1/0,8 = 1,25 keer zo hoog als de prijs van het moment van opwek. En dat is bij een kleine spread hoger dan wat je betaalt als je het in de nacht meteen uit het net haalt.

Maar nogmaals: dat is als je het zuiver financieel bekijkt en we weten dat financieel gewin (rendement) niet voor iedereen het eerste doel is. Rustig NOMmen kan ook een rustig gevoel geven.

[Hippe Lip]

ZuinigeRijder schreef op donderdag 7 mei 2026 @ 09:05:
Weet niet of deze vraag al gesteld is, maar ik heb het niet gevonden.

Ik heb 2x een Solarflow 800 Plus en ook 2x HW Energy socket ertussen, een HW P1 meter én een Zendure P1 meter. Tot nu toe gebruik ik de Zendure App. Ik weet dat de @gielz integratie maar 1 omvormer aanstuurt en dat je met @gast777 RED node proxy je 2 omvormers kunt koppelen. Ik vroeg me wel af hoe de statistieken voor 2 omvormers getoond worden.

Doet de proxy de statistieken combineren?

Of kun je maar van 1 omvormer de statistieken zien?

Kun je ook de statistieken van de andere omvormer in bijvoorbeeld een ander tabblad laten zien?

Of moet je een combinatie maken van de @gielz integratie (voor voornamelijk de aansturing) en de ZenSDK gebruiken voor de statistieken? Bijten die elkaar?

De statistieken van de twee Zendures zijn nagenoeg identiek. De proxy van @gast777 zorgt namelijk dat de SoC van de twee of drie stacks vlak bij elkaar in de buurt blijft.

En bij kleinere vermogens bij laden of ontladen wordt er maar eentje tegelijk ingezet om het rendement zo goed mogelijk te houden. Daarbij worden de beschikbare stacks regelmatig gewisseld om de SoC ongeveer gelijk te houden. Heel ingenieus.

[YvonneVP]

Pakhaas schreef op donderdag 7 mei 2026 @ 07:24:
[...]

Geldzaken is behoorlijk zwartwit 😄

Nee hoor, want prioriteiten kunnen daarin shiften. Wat voor jou prioriteit is hoeft niet de prioriteit van een ander te zijn. En dat is dus ook tussen het handelen vs NOM-en. En daarin vond ik je op gegeven moment een beetje drammerig worden. Zoals gezegd, met een capaciteit van 8 kWh hebben die paar centen geen belang omdat je niet echt goed kunt handelen. Als ik daarentegen heel de nacht, of dure periode, geen verbruik heb dan verdien ik ook.

[YvonneVP]

ctrl-tab schreef op donderdag 7 mei 2026 @ 07:25:
[...]

Moet toch gewoon goed draaien in een vm , of dat nou windows als host heeft of linux.. goed, windows als vm host , daar gaan mijn haren van overeind staan om allerlei andere redenen. Wellicht de hdd die bottleneckte?

Draai zelf op proxmox in een vm (dus debian als host), voorheen op k8s, nu gewoon docker compose. Vlekkeloos, een jaar of 10 inmiddels.

Ik gebruikte Oracle Virtualbox om mijn vm in te draaien. Ik kreeg er alleen maar grijs haar van. Heb nu een TC en sindsdien ben ik alleen maar blij. Het draait nu gewoon stabiel, terwijl ik binnen Virtual box echt te maken had met corrupte HA instances, traagheid, en allemaal ander vreemde dingen die er ineens gebeurden. En ik zat in die VM boven de 'recommended' configuratie voor HA als het ging om HDD en RAM etc.

[Pakhaas]

YvonneVP schreef op donderdag 7 mei 2026 @ 11:20:
[...]

Nee hoor, want prioriteiten kunnen daarin shiften. Wat voor jou prioriteit is hoeft niet de prioriteit van een ander te zijn. En dat is dus ook tussen het handelen vs NOM-en. En daarin vond ik je op gegeven moment een beetje drammerig worden. Zoals gezegd, met een capaciteit van 8 kWh hebben die paar centen geen belang omdat je niet echt goed kunt handelen. Als ik daarentegen heel de nacht, of dure periode, geen verbruik heb dan verdien ik ook.

Zeker kunne prioriteiten verschillen dat klopt. Maar wij hadden het puur over wat financieel de beste keuze is en dat is gewoon zwart-wit. Prima wat iedereen voor motivatie er verder bij heeft, maar dat heeft niets te maken met wat financieel de beste keuze is. Dat voor jou de keuze niet alleen geld gedreven is, is helemaal goed, maar staat los van de discussie (die al beëindigd was ivm offtopic).

[wautah91]

Mimiix schreef op woensdag 6 mei 2026 @ 13:44:
Ik heb getracht wat terug te zoeken, maar nog niet direct een antwoord kunnen vinden. Vergeef me dus als ik het gemist heb.

Ik heb in de Gielz integratie nu Dynamisch Nom ingesteld en de goedkoopste / duurste periodes ingesteld op 8 en 16. Ik zie dat ie op de goedkoopste momenten nu laad en op de duurdere momente ontlaad. Dat snap ik, maar ik begrijp niet goed wat ik hier het beste kan invullen. Waarom zou ik voor 8 kiezen ipv 4 bijvoorbeeld?

Dat ligt aan je beschikbare accu capaciteit. Stel je hebt 6 kWh en je laad met 2,4kWh, heb je dus ongeveer 3 uur nodig om de accu vol te laden, dat kun je dan dus het beste doen op de 3 goedkoopste uren wat vaak ook de uren zijn met de meeste PV opwek. Met ontladen precies andersom of draai je nul op de meter

[Mimiix]

wautah91 schreef op donderdag 7 mei 2026 @ 12:12:
[...]

Dat ligt aan je beschikbare accu capaciteit. Stel je hebt 6 kWh en je laad met 2,4kWh, heb je dus ongeveer 3 uur nodig om de accu vol te laden, dat kun je dan dus het beste doen op de 3 goedkoopste uren wat vaak ook de uren zijn met de meeste PV opwek. Met ontladen precies andersom of draai je nul op de meter

dank voor je reactie!

Ik heb 5.28KwH. Echter: Ik heb op het dak 3.6kwh SolarEdge en straks (binnen nu en een week) ook nog eens 1.8kwh aan panelen direct op de SF2400Pro.

Ik vermoed dat met de 1.8kwh het wel oplaad.

De vraag is dus: Wat is wijsheid?

[MikeyMan]

Pakhaas schreef op donderdag 7 mei 2026 @ 11:44:
[...]

Zeker kunne prioriteiten verschillen dat klopt. Maar wij hadden het puur over wat financieel de beste keuze is en dat is gewoon zwart-wit. Prima wat iedereen voor motivatie er verder bij heeft, maar dat heeft niets te maken met wat financieel de beste keuze is. Dat voor jou de keuze niet alleen geld gedreven is, is helemaal goed, maar staat los van de discussie (die al beëindigd was ivm offtopic).

De financiën zijn zwart-wit... Achteraf...

Hoe je dan tot de financieel meest aantrekkelijke instellingen komt heeft echter nogal wat tinten grijs. En eerlijk gezegd krijg ik het niet berekend/beredeneerd wat met enige redelijke zekerheid de goedkoopste oplossing is. Er spelen namelijk nogal veel parameters mee.

[Mimiix]

Ik zie overigens iets anders geks gebeuren met de PV panelen op de SF2400P icm de Gielz integratie: Als ik de functie Slim opladen gebruik, dan pakt ie inderdaad netjes het overtoligge van de solaredge. Echter zorgt dat er ook voor dat de PV van de Zendure omlaag gaat. Klopt dit? Of zijn de waardes gewoon vertraagd?

[RemmyB83]

Mimiix schreef op donderdag 7 mei 2026 @ 12:44:
Ik zie overigens iets anders geks gebeuren met de PV panelen op de SF2400P icm de Gielz integratie: Als ik de functie Slim opladen gebruik, dan pakt ie inderdaad netjes het overtoligge van de solaredge. Echter zorgt dat er ook voor dat de PV van de Zendure omlaag gaat. Klopt dit? Of zijn de waardes gewoon vertraagd?

Even controleren in de zendure app of het volgende op toestaan staat.

[MikeyMan]

Mimiix schreef op donderdag 7 mei 2026 @ 12:44:
Ik zie overigens iets anders geks gebeuren met de PV panelen op de SF2400P icm de Gielz integratie: Als ik de functie Slim opladen gebruik, dan pakt ie inderdaad netjes het overtoligge van de solaredge. Echter zorgt dat er ook voor dat de PV van de Zendure omlaag gaat. Klopt dit? Of zijn de waardes gewoon vertraagd?

Zit ie tegen zn max aan dan?

Kan me voorstellen dat er tot het maximale vermogen wordt geladen.

[ Voor 7% gewijzigd door MikeyMan op 07-05-2026 13:12 ]

[Mimiix]

MikeyMan schreef op donderdag 7 mei 2026 @ 13:11:
[...]

Zit ie tegen zn max aan dan?

Kan me voorstellen dat er tot het maximale vermogen wordt geladen.

Jep. Van de SolarEdge kan hij 2kwh pakken en de panelen doen 600w. Ik zou verwachten dat hij dan 1800 kWh van de SolarEdge pakt. Echter limiteert hij dus op de pv.

Ik vermoed dat dit in de integratie zit, omdat deze gewoon instelt wat hij moet laden. De zendure knijpt dan liever de pv af blijkbaar.

[Mimiix]

RemmyB83 schreef op donderdag 7 mei 2026 @ 13:11:
[...]

Even controleren in de zendure app of het volgende op toestaan staat.
[Afbeelding]

Deze staat aan

[gielz]

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

Jep. Van de SolarEdge kan hij 2kwh pakken en de panelen doen 600w. Ik zou verwachten dat hij dan 1800 kWh van de SolarEdge pakt. Echter limiteert hij dus op de pv.

Ik vermoed dat dit in de integratie zit, omdat deze gewoon instelt wat hij moet laden. De zendure knijpt dan liever de pv af blijkbaar.

Beide integraties bepalen niet wat er met de PV moet gebeuren dat doet de BMS zelf. Stel je zegt laad op met 2400 watt dan zal hij 600 watt van de panelen pakken en dit aanvullen met 1800 watt van het net/huis PV.

Het PV vermogen word per seconden opgehaald bij de Gielz.

[RemmyB83]

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

Deze staat aan

Oke, hij schijnt zijn pv ook wel eens te limiteren als de accu's bijna vol zitten.
Dat heb ik hier ook al eens zien gebeuren.
Zodra die dan 100% is gaat hij pas weer verder met zijn normale productie.

[MikeyMan]

gielz schreef op donderdag 7 mei 2026 @ 13:26:
[...]

Beide integraties bepalen niet wat er met de PV moet gebeuren dat doet de BMS zelf. Stel je zegt laad op met 2400 watt dan zal hij 600 watt van de panelen pakken en dit aanvullen met 1800 watt van het net/huis PV.

Het PV vermogen word per seconden opgehaald bij de Gielz.

@Mimiix geeft aan dat het juist andersom gaat. Eerst 2000 van huis. Dan 400 van PV.

[Jacqui]

Mimiix schreef op donderdag 7 mei 2026 @ 12:15:
[...]

dank voor je reactie!

Ik heb 5.28KwH. Echter: Ik heb op het dak 3.6kwh SolarEdge en straks (binnen nu en een week) ook nog eens 1.8kwh aan panelen direct op de SF2400Pro.

Ik vermoed dat met de 1.8kwh het wel oplaad.

De vraag is dus: Wat is wijsheid?

Ben er de laatste tijd zelf wat mee aan het stoeien geweest om de meest optimale settings te vinden.
Ik ben nu tevreden met onderstaande:
Kwartierprijzen geselecteerd (Tibber dynamisch)
16 goedkoopste periodes laden met 2400W (Dynamisch handelen), waarmee mijn 9 kWh sowieso vol komt
12 duurste periodes ontladen met 1800W (Dynamisch handelen), waarbij ik in de duurste periode dus verkoop, maar de accu dus nog niet helemaal leegtrek
Buiten de duurste en goedkoopste periodes heb ik de modus op 'Alleen slim ontladen', zodat ik de nacht NOM kan draaien, maar nog wel het zonneoverschot van de ochtend en namiddag teruglever.

Overigens stuur ik de modus aan met een eigen automatisering, waarna ik die van Gielz de aansturing van de accu's laat verzorgen.

[Mimiix]

gielz schreef op donderdag 7 mei 2026 @ 13:26:
[...]

Beide integraties bepalen niet wat er met de PV moet gebeuren dat doet de BMS zelf. Stel je zegt laad op met 2400 watt dan zal hij 600 watt van de panelen pakken en dit aanvullen met 1800 watt van het net/huis PV.

Het PV vermogen word per seconden opgehaald bij de Gielz.

Dat lijkt dus in mijn geval niet te gebeuren. Ik zag net duidelijk dat hij 2000w aan het laden was en de panelen rond de 400 bleven. Zodra ik de import handmatig terugzette naar 1000, ging de PV omhoog naar 600~.

[Mimiix]

RemmyB83 schreef op donderdag 7 mei 2026 @ 13:31:
[...]

Oke, hij schijnt zijn pv ook wel eens te limiteren als de accu's bijna vol zitten.
Dat heb ik hier ook al eens zien gebeuren.
Zodra die dan 100% is gaat hij pas weer verder met zijn normale productie.

Accu's zaten bij mij op 30-40%.

[koboy]

YvonneVP schreef op donderdag 7 mei 2026 @ 00:40:
[...]

De energie die ik overdag goedkoop inkoop, en verbruik zodra de zonnepanelen niets meer leveren, levert uiteindelijk ook geld op. Ik heb tenslotte dan geen of nauwelijks verbruik. Jij mag handelen als je dat wilt. Ik ga gewoon lekker NOMmen. Ik heb de batterijen niet gekocht om te handelen, maar voor mijn eigen gebruik. Ik heb genoeg zonnestroom, en jaarlijks altijd een overschot. Als de zon de hele dag schijnt laadt ik dus mijn batterij op, maar lever ik ondertussen ook nog aan het net. Of ik pomp in een paar kleine uurtjes de batterij vol, en dan gaat de rest naar het net. Jij kunt dat misschien 'dom' of vreemd vinden. Echter bepaald een ieder zelf waar hij/zij zijn batterij voor wil inzetten. En daar valt niet over te discussiëren. Niets in het leven is zo zwart-wit zoals jij het stelt. Dit dus ook niet, en is voor een ieder anders naar gelang persoonlijke voorkeur. Als ik zou handelen, en ondertussen mijn eigen energierekening naar beneden wil halen, dan heb ik meer capaciteit nodig om het ook nog goed winstgevend te maken. En daar heb ik geen behoefte aan. Ik ben van mening dat ik het met een RTE van 81,5% niet slecht doe.

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

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

[RemmyB83]

Mimiix schreef op donderdag 7 mei 2026 @ 13:43:
[...]

Accu's zaten bij mij op 30-40%.

Ik heb zelf momenteel export op verboden staan ivm terugleverkosten. Maar vorige maand toen ik mijn batterij en panelen ingebruik nam zag ik ook het volgende. Nu heb ik meer opwek dan opslag en deze panelen krijgen vrij laat pas de volle zon, dus batterijen zitten vaak al vol. Daardoor heb er nooit echt naar gekeken. Maar het werkt idd niet altijd zoals je zou verwachten.

[Mimiix]

Na wat te testen, lijkt het erop dat Gielz sneller is dan de panelen die opkomen. Dus stel dat door de NOM/SLIM opladen de batterij 2kw mag laden, dan vullen de PV panelen aan.

Als ik vervolgens handmatig de batterij naar 1kw zet, vervolgens even wacht tot de PV panelen volledig draaien en vervolgens terug wissel naar NOM/SLIM opladen, dan gaat het wel goed.

[koboy]

MikeyMan schreef op donderdag 7 mei 2026 @ 12:17:
[...]

De financiën zijn zwart-wit... Achteraf...

Hoe je dan tot de financieel meest aantrekkelijke instellingen komt heeft echter nogal wat tinten grijs. En eerlijk gezegd krijg ik het niet berekend/beredeneerd wat met enige redelijke zekerheid de goedkoopste oplossing is. Er spelen namelijk nogal veel parameters mee.

Die tinten grijs en de parameters vallen heel erg mee, zeker als je bij een keurig salderende leverancier zit of een vast contract hebt.

Vast contract: teruglevering beperken, dus NOM.

Dynamisch: als er genoeg verschil zit tussen inkoop en verkoop om de laad- (en handel) verliezen te overbruggen: goedkoop voluit laden, duur dumpen. Om de laadverliezen te overbruggen zit je met verkoop=1,25x inkoop al goed. Dit moet je ophogen als je niet je inkoopkosten (volledig) terugkrijgt, maar daar is ook een mouw aan te passen.
Verschil te klein: niets opslaan maar terugleveren.
Voorbeeldberekeningen zijn de afgelopen dagen al genoeg gemaakt.

Waar het vaak gecompliceerd op wordt gemaakt is als er zaken als slijtage en zo in kosten worden omgezet. Hier loop je echter tegen het probleem aan dat een accu het niet fijn vindt om (bijna) helemaal vol of (bijna) leeg langere tijd door te brengen. Je krijgt dan op dat moment verhoogde zelfdegradatie. Ook is een accu na bijvoorbeeld 6000 cycles niet kapot, maar heeft alleen een (flink) mindere capaciteit. En zeg nou eerlijk: 6000 cycles is voor de meesten van ons 20 jaar als de accu voornamelijk slaapt in de winter. Tegen die tijd heeft hij allang dezelfde functie die nu de oude koelkast in de schuur heeft, of is zelfs helemaal vervangen, omdat hij niet meer paste in het verbruiks patroon.

[gielz]

Mimiix schreef op donderdag 7 mei 2026 @ 14:00:
Na wat te testen, lijkt het erop dat Gielz sneller is dan de panelen die opkomen. Dus stel dat door de NOM/SLIM opladen de batterij 2kw mag laden, dan vullen de PV panelen aan.

Als ik vervolgens handmatig de batterij naar 1kw zet, vervolgens even wacht tot de PV panelen volledig draaien en vervolgens terug wissel naar NOM/SLIM opladen, dan gaat het wel goed.

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

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

• Engelse integratie

[MikeyMan]

koboy schreef op donderdag 7 mei 2026 @ 14:18:
[...]

Die tinten grijs en de parameters vallen heel erg mee, zeker als je bij een keurig salderende leverancier zit of een vast contract hebt.

Vast contract: teruglevering beperken, dus NOM.

Dynamisch: als er genoeg verschil zit tussen inkoop en verkoop om de laad- (en handel) verliezen te overbruggen: goedkoop voluit laden, duur dumpen. Om de laadverliezen te overbruggen zit je met verkoop=1,25x inkoop al goed. Dit moet je ophogen als je niet je inkoopkosten (volledig) terugkrijgt, maar daar is ook een mouw aan te passen.
Verschil te klein: niets opslaan maar terugleveren.
Voorbeeldberekeningen zijn de afgelopen dagen al genoeg gemaakt.

Waar het vaak gecompliceerd op wordt gemaakt is als er zaken als slijtage en zo in kosten worden omgezet. Hier loop je echter tegen het probleem aan dat een accu het niet fijn vindt om (bijna) helemaal vol of (bijna) leeg langere tijd door te brengen. Je krijgt dan op dat moment verhoogde zelfdegradatie. Ook is een accu na bijvoorbeeld 6000 cycles niet kapot, maar heeft alleen een (flink) mindere capaciteit. En zeg nou eerlijk: 6000 cycles is voor de meesten van ons 20 jaar als de accu voornamelijk slaapt in de winter. Tegen die tijd heeft hij allang dezelfde functie die nu de oude koelkast in de schuur heeft, of is zelfs helemaal vervangen, omdat hij niet meer paste in het verbruiks patroon.

Op uur of dagniveau kan ik je volgen... En als je al de keuze hebt gemaakt voor een contract ook. Je zult het dan moeten doen met die keuze.

Over het hele jaar heen wordt het voor mij erg mistig om hier een keuze in te maken... Er komen dan ineens een hoop parameters en onzekerheden om de hoek kijken.

[koboy]

MikeyMan schreef op donderdag 7 mei 2026 @ 15:18:
[...]

Op uur of dagniveau kan ik je volgen... En als je al de keuze hebt gemaakt voor een contract ook. Je zult het dan moeten doen met die keuze.

Over het hele jaar heen wordt het voor mij erg mistig om hier een keuze in te maken... Er komen dan ineens een hoop parameters en onzekerheden om de hoek kijken.

Nee hoor, een accu is voor dagopslag. Die gaat dus in een periode van hooguit een paar dagen helemaal leeg. Dingen als seizoen en zo hoef je dus niet naar te kijken. Laatste beetje (1,5 kWh ofzo) van eergisteren is er vanochtend uit gegaan na 2 dagen pauze. Of dat het allervoordeligste moment is geweest weet ik niet, en ga ik me in het grote geheel ook niet druk over maken.

Volgend jaar is in de winter een heel redelijk scenario om op zondag goedkoop te laden om daarmee de ergste pieken de dagen er na af te dekken, maar dan ga je al redelijk de onzekerheid en speculatie in.

[MikeyMan]

koboy schreef op donderdag 7 mei 2026 @ 15:22:
[...]

Nee hoor, een accu is voor dagopslag. Die gaat dus in een periode van hooguit een paar dagen helemaal leeg. Dingen als seizoen en zo hoef je dus niet naar te kijken. Laatste beetje (1,5 kWh ofzo) van eergisteren is er vanochtend uit gegaan na 2 dagen pauze. Of dat het allervoordeligste moment is geweest weet ik niet, en ga ik me in het grote geheel ook niet druk over maken.

Volgend jaar is in de winter een heel redelijk scenario om op zondag goedkoop te laden om daarmee de ergste pieken de dagen er na af te dekken, maar dan ga je al redelijk de onzekerheid en speculatie in.

Vanuit de accu bezien heb je gelijk. Vanuit de bepaling of je voor een dynamisch of vast contract moet gaan moet je wel degelijk naar de seizoensinvloeden kijken. Maak ik in de zomer het gegarandeerde verlies van de winter goed...

[koboy]

MikeyMan schreef op donderdag 7 mei 2026 @ 15:33:
[...]

Vanuit de accu bezien heb je gelijk. Vanuit de bepaling of je voor een dynamisch of vast contract moet gaan moet je wel degelijk naar de seizoensinvloeden kijken. Maak ik in de zomer het gegarandeerde verlies van de winter goed...

Valt ook wel mee.

Zonder PV: vast
Alleen PV: beetje lood om oud ijzer als je gas stookt
Ga je grotere verbruikers er bij doen die je goed kunt plannen: dynamisch.

Had het eerste jaar situatie 2, PV en gas stoken. Nu EV thuis laden zorgt voor een verdubbeling van het verbruik dat naar de goedkope uren kan worden geschoven. Ik verwacht hier ruim onder de 20 cent te blijven voor het auto laden.

[MikeyMan]

koboy schreef op donderdag 7 mei 2026 @ 15:55:
[...]


Valt ook wel mee.

Zonder PV: vast
Alleen PV: beetje lood om oud ijzer als je gas stookt
Ga je grotere verbruikers er bij doen die je goed kunt plannen: dynamisch.

Had het eerste jaar situatie 2, PV en gas stoken. Nu EV thuis laden zorgt voor een verdubbeling van het verbruik dat naar de goedkope uren kan worden geschoven. Ik verwacht hier ruim onder de 20 cent te blijven voor het auto laden.

Precies mijn punt ook. De oorspronkelijke stelling was dat het allemaal “zwart-wit” zou zijn. Terwijl er inmiddels alweer allerlei extra variabelen bijgehaald worden waardoor de uitkomst verandert.

PV of geen PV, gas of warmtepomp, EV laden of niet, wel/niet mogelijkheid tot load shifting, accucapaciteit, terugleverconstructie, dynamische prijsspreads etc.

Deze hebben enorme invloed op wat financieel het gunstigst is.

Dus ja: achteraf is de rekensom zwart-wit. Maar vooraf is het absoluut geen universele zwart-wit keuze.

[ Voor 31% gewijzigd door MikeyMan op 07-05-2026 16:08 ]

[R1chardTM]

Dit is een topic over het integreren van Zendure in HA, dit soort discussies mogen wat mij betreft ergens anders.

[TBird484]

gast777 schreef op donderdag 30 april 2026 @ 21:40:
[...]

OK ik snap wat je bedoelt, maar dat is niet hoe het is. Als je de batterij data van de proxy (via dashboard_battery_sensors_XX) gebruikt, dan verandert die gewoon mee, precies zoals die van Gielz. Dat komt omdat het gewoon dezelfde Gielz batterij sensoren zijn (ik heb alleen copy-paste gedaan), maar dan verder doorgenummerd.

Zou je dit ook kunnen doen voor de Cell Balance ?

[MikeyMan]

R1chardTM schreef op donderdag 7 mei 2026 @ 16:37:
Dit is een topic over het integreren van Zendure in HA, dit soort discussies mogen wat mij betreft ergens anders.

Lijkt me vrij essentieel voor de keuze van aansturing in deze integratie..

[Mimiix]

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

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

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

• Engelse integratie[Afbeelding]

Ik ga morgen even kijken, gezien de zon nu volledig weg is

[NiCNCo]

Hippe Lip schreef op maandag 4 mei 2026 @ 22:19:
[...]

Dank voor deze uitleg @Pakhaas.
Die had ik even nodig.

Dan nog wel twee andere vragen.

1. Wat voor spreiding kies je dan? Minimaal 20% om je verliezen te compenseren, maar wel hoger omdat je anders nog steeds heen en weer aan het pompen bent met nul winst. Maar hoeveel is dan een geschikte drempel? 30%?
2. En kies je dan voor alleen Dynamic Trading of voor Smart Matching + Smart Matching? Want bij een paar matige dagen haal je die 30% (of hoeveel je ook kiest) nauwelijks en staat de boel te nixen. Is het dan beter wel te NOMmen?

Wat veel mensen vergeten is ook nog de afschrijving van de accu's. Laden/ontladen per 1 cycle kost gewoon geld. Stel je 15.4kW zendures staan met opgegeven 6000 cycle levensduur waar je 5200 euro voor hebt betaald. (na de 6000x cycli zijn de batterijen nog altijd werkzaam met 70% capaciteit "I Know").

Ik wil me niet rijk rekenen dus ik tel die mee in me overweging wanneer wel en niet te laden op de dynamische tarieven, maar per 1 Kwh laden en 1 Kwh ontladen betaal je eigenlijk dus;

5200 euro delen door totaal aantal kw gedurende levenduur (=15.4kw x 2 (in/uit dus 1 cycle) x 6000 = 185.000 kw

is dus per 1 kwh dus 0.028 cent, of het nauw opladen of ontladen is.
(RTE even daargelaten voor het voorbeeld)

Anders gezegd de hele batterij stapel 1x per dagen helemaal vol en weer leeg kost 0.863 cent.

[ctrl-tab]

NiCNCo schreef op donderdag 7 mei 2026 @ 18:56:
[...]

Wat veel mensen vergeten is ook nog de afschrijving van de accu's. Laden/ontladen per 1 cycle kost gewoon geld. Stel je 15.4kW zendures staan met opgegeven 6000 cycle levensduur waar je 5200 euro voor hebt betaald. (na de 6000x cycli zijn de batterijen nog altijd werkzaam met 70% capaciteit "I Know").

Ik wil me niet rijk rekenen dus ik tel die mee in me overweging wanneer wel en niet te laden op de dynamische tarieven, maar per 1 Kwh laden en 1 Kwh ontladen betaal je eigenlijk dus;

5200 euro delen door totaal aantal kw gedurende levenduur (=15.4kw x 2 (in/uit dus 1 cycle) x 6000 = 185.000 kw

is dus per 1 kwh dus 0.028 cent, of het nauw opladen of ontladen is.
(RTE even daargelaten voor het voorbeeld)

Anders gezegd de hele batterij stapel 1x per dagen helemaal vol en weer leeg kost 0.863 cent.

Zou je niet 5200 / 6000 / 15,4 moeten doen? wat erin gaat moet er ook uit.
Dan kom je op 5 cent uit.

Om die reden ga ik pas handelen vanaf 10 cent.

[gast777]

ZuinigeRijder schreef op donderdag 7 mei 2026 @ 09:05:
Weet niet of deze vraag al gesteld is, maar ik heb het niet gevonden.

Ik heb 2x een Solarflow 800 Plus en ook 2x HW Energy socket ertussen, een HW P1 meter én een Zendure P1 meter. Tot nu toe gebruik ik de Zendure App. Ik weet dat de @gielz integratie maar 1 omvormer aanstuurt en dat je met @gast777 RED node proxy je 2 omvormers kunt koppelen. Ik vroeg me wel af hoe de statistieken voor 2 omvormers getoond worden.

Doet de proxy de statistieken combineren?

Of kun je maar van 1 omvormer de statistieken zien?

Kun je ook de statistieken van de andere omvormer in bijvoorbeeld een ander tabblad laten zien?

Of moet je een combinatie maken van de @gielz integratie (voor voornamelijk de aansturing) en de ZenSDK gebruiken voor de statistieken? Bijten die elkaar?

Gielz zelf gaat uit van 1 Zendure, dus de Proxy combineert de data van de 2 of 3 Zendures naar 1 grote Zendure. Dus het standaard Gielz dashboard geeft de relevante data voor al je Zendures samen.

Daarnaast geeft de proxy ook nog extra informatie door aan HA voor de individuele Zendures. Die informatie kan ook op een dashboard gezet worden (bijv op het Gielz dashboard erbij of op een apart dashboard).

Hoe die extra sensoren te installeren staat hier uitgelegd.

Daarnaast ben ik momenteel aan het kijken hoe ik eventueel nog een Node-RED dashboard kan toevoegen voor de Proxy. In eerste instantie vooral voor troubleshooting. Maar dat terzijde.

[RemmyB83]

NiCNCo schreef op donderdag 7 mei 2026 @ 18:56:
[...]

Wat veel mensen vergeten is ook nog de afschrijving van de accu's. Laden/ontladen per 1 cycle kost gewoon geld. Stel je 15.4kW zendures staan met opgegeven 6000 cycle levensduur waar je 5200 euro voor hebt betaald. (na de 6000x cycli zijn de batterijen nog altijd werkzaam met 70% capaciteit "I Know").

Ik wil me niet rijk rekenen dus ik tel die mee in me overweging wanneer wel en niet te laden op de dynamische tarieven, maar per 1 Kwh laden en 1 Kwh ontladen betaal je eigenlijk dus;

5200 euro delen door totaal aantal kw gedurende levenduur (=15.4kw x 2 (in/uit dus 1 cycle) x 6000 = 185.000 kw

is dus per 1 kwh dus 0.028 cent, of het nauw opladen of ontladen is.
(RTE even daargelaten voor het voorbeeld)

Anders gezegd de hele batterij stapel 1x per dagen helemaal vol en weer leeg kost 0.863 cent.

Ik heb nog een vast-contract tot oktober, en ga daarna hoogst waarschijnlijk weer dynamisch. Ik bekijk het straks denk op een andere manier, en dat ding moet gewoon werken voor elke kruimel. Als ik het zo berekend als jouw zal doen, dan denk toch echt dat ouderdom de eigenlijke waarde inhaald. Dus als ik iets meer dan mijn RTE, dek, vindt ik het al snel goed. Ik zie dat ook al met mijn zonnepanelen, toen koste het 1euro per Wattpiek, en nu nog maar de helft. Fabrikant van de omvormer is ookal op de fles, en zijn nu ook geen moer meer waard tov toen.
Over 10 jaar zie ik het wel weer.
Mensen die tegen die tijd een thuisbatterij kopen zullen weer sneller kunnen laden en ontladen, omdat hun afschrijving per cycle lager ligt. Sta ik dan met mijn oude fosiel.

[gielz]

Gielz update v20260507

http://zendure-ha.com/

English (Global)

This update brings a wide range of improvements, new features, bug fixes, and quality-of-life changes designed to make the integration more stable, flexible, and easier to use.

A huge thank you to all users, testers, contributors, and sponsors for the feedback and support. And if this integration made your energy bill slightly less painful, consider giving the repository a star ⭐⭐⭐

⚠️ Please make sure to use the correct language update. After installation, set your minimum and maximum allowed state of charge. These values will sync to: 5% minimum and 70% maximum ⚠️

Bug fixes

Dynamic Spread
Fixed an issue where the dynamic spread calculation was incorrect when energy prices were below zero.

Small changes

Battery Order
Maximum input length changed from 11 to 44.

Maximum Charge/Discharge Power
Now configurable from 400 watts, previously this was 800 watts. Setting it below 800 watts affects your RTE.

Start Charge/Discharge At
Now configurable from -80/80 watts, previously this was -100/100 watts.

New features

Recommended settings are automatically set
When entering or changing the Zendure IP address (input_text.zendure_setting_ip_address), the recommended settings will be automatically applied:

• Standby Delay: 15 minutes
• Start Charging At: -300 watts
• Start Discharging At: 100 watts
• Discharge Buffer: 5 watts
• Charge Buffer: 50 watts
• Minimum SOC: 10%
• Maximum SOC: 100
• Dynamic Manual Period (Tomorrow): empty

sensor.home_energy_meter_power
When the home energy meter goes offline, Smart Matching enters emergency stop mode after one minute. Battery output is forced to 0 watts. When the meter returns online, the process resumes.

Disable SOC protection
It is now possible to disable SOC protection. When the battery drops below the minimum SOC, it will no longer automatically recharge and will wait for the BMS to act.

Min/Max SOC control
You can now set minimum and maximum SOC directly in Home Assistant. These values override the Zendure app and sync immediately.

New entities

Cell balance status sensors (1–6)
sensor.zendure_battery_1_cell_balance_status – sensor.zendure_battery_6_cell_balance_status

Cell balance classification:

• Excellent ≤ 0.02V
• Good ≤ 0.05V
• Slight Imbalance ≤ 0.08V
• Imbalanced > 0.08V

Automation watchdog
input_datetime.zendure_gielz_automation_last_time_executed
Checks every 5 seconds if automation is still running. If not, a red cross appears after 2 minutes in the dashboard config tab.

sensor.zendure_indication_required_energy (#95 by @NextNebula)
Indicates how much energy is required to charge the battery to maximum SOC (including efficiency losses).

sensor.zendure_indication_remaining_charge_time (#95 by @NextNebula)
Estimates remaining time to full charge including efficiency.

Dutch (NL)

Deze update bevat een groot aantal verbeteringen, nieuwe functies, bugfixes en kleine kwaliteitsverbeteringen om de integratie stabieler, flexibeler en gebruiksvriendelijker te maken.

Grote dank aan alle gebruikers, testers, bijdragers en sponsors voor alle feedback en support. En als deze integratie je energierekening iets minder pijnlijk heeft gemaakt, overweeg dan om de repository een ster te geven ⭐⭐⭐

⚠️ Zorg ervoor dat je de juiste taalupdate gebruikt. Stel na de installatie je minimaal en maximaal toegestane laadpercentage in. Deze waarden worden gesynchroniseerd naar: 5% minimaal en 70% maximaal ⚠️

Bug fixes

Dynamische spread
Probleem opgelost waarbij de dynamische spreadberekening onjuist was bij negatieve energieprijzen.

Kleine wijzigingen

Batterij Volgorde
Maximum invullengte aangepast van 11 naar 44.

Maximum Laad/Ontlaadvermogen
Nu instelbaar vanaf 400 watt (was 800 watt). Lager dan 800 watt beïnvloedt RTE.

Start laden/ontladen
Nu instelbaar van -80 tot 80 watt (was -100 tot 100 watt).

Nieuwe functies

Automatisch aanbevolen instellingen
Bij het instellen of wijzigen van het Zendure IP-adres (input_text.zendure_2400_ac_ip_adres) worden automatisch instellingen toegepast:

• Standby vertraging: 15 minuten
• Opladen starten bij: -300 watt
• Ontladen starten bij: 100 watt
• Ontlaadmarge: 5 watt
• Oplaadmarge: 50 watt
• Min SOC: 10%
• Max SOC: 100%
• Dynamische periode (morgen): leeg

sensor.p1_aansturing_vermogen
Bij offline gaan van de energiemeter gaat Smart Matching na 1 minuut in noodstop. Batterij wordt op 0 watt gezet. Bij terugkomst wordt het proces hervat.

SOC bescherming uitschakelen
SOC bescherming kan nu worden uitgeschakeld. De batterij wordt niet automatisch bijgeladen onder minimum SOC; het BMS bepaalt de actie.

Min/max SOC instelbaar
Minimale en maximale SOC zijn nu direct instelbaar in Home Assistant en vervangen de Zendure app.

Nieuwe entiteiten

Celbalans status (1–6)
sensor.zendure_2400_ac_batterij_1_celbalans_status – sensor.zendure_2400_ac_batterij_6_celbalans_status

Status:

• Uitstekend ≤ 0,02V
• Goed ≤ 0,05V
• Lichte onbalans ≤ 0,08V
• Onbalans > 0,08V

Automatisering watchdog
input_datetime.zendure_gielz_automatisering_laatste_keer_uitgevoerd
Controleert elke 5 seconden of de automatisering nog draait. Zo niet, verschijnt na 2 minuten een rood kruis in het dashboard.

sensor.zendure_2400_ac_indicatie_benodigde_energie (#95 door @NextNebula)
Geeft aan hoeveel energie nodig is om de batterij tot max SOC te laden, inclusief efficiëntie.

sensor.zendure_2400_ac_resterende_oplaad_tijd (#95 door @NextNebula)
Geeft de geschatte resterende laadtijd tot max SOC, inclusief efficiëntie.

[Jacqui]

gielz schreef op donderdag 7 mei 2026 @ 19:52:

Gielz update v20260507

http://zendure-ha.com/

Super! Had intussen al geupdate naar v20260504 en kwam van een oude november update... Erg blij met de ontwikkelingen die sindsdien zijn gemaakt. M.n. de verbeteringen in de packages installatie en het standaard dashboard

[fabudop]

NiCNCo schreef op donderdag 7 mei 2026 @ 18:56:
[...]

is dus per 1 kwh dus 0.028 cent, of het nauw opladen of ontladen is.
(RTE even daargelaten voor het voorbeeld)

Anders gezegd de hele batterij stapel 1x per dagen helemaal vol en weer leeg kost 0.863 cent.

Je bedoeld 0.028 euro (oftwel 2.8 cent). (5200 euro/185000 kWh 0 0.028 euro)

[Henkoes]

gielz schreef op donderdag 7 mei 2026 @ 19:52:

Gielz update v20260507

http://zendure-ha.com/

English (Global)

This update brings a wide range of improvements, new features, bug fixes, and quality-of-life changes designed to make the integration more stable, flexible, and easier to use.

A huge thank you to all users, testers, contributors, and sponsors for the feedback and support. And if this integration made your energy bill slightly less painful, consider giving the repository a star ⭐⭐⭐


[...]

Bug fixes

Dynamic Spread
Fixed an issue where the dynamic spread calculation was incorrect when energy prices were below zero.

Small changes

Battery Order
Maximum input length changed from 11 to 44.

Maximum Charge/Discharge Power
Now configurable from 400 watts, previously this was 800 watts. Setting it below 800 watts affects your RTE.

Start Charge/Discharge At
Now configurable from -80/80 watts, previously this was -100/100 watts.

New features

Recommended settings are automatically set
When entering or changing the Zendure IP address (input_text.zendure_setting_ip_address), the recommended settings will be automatically applied:

• Standby Delay: 15 minutes
• Start Charging At: -300 watts
• Start Discharging At: 100 watts
• Discharge Buffer: 5 watts
• Charge Buffer: 50 watts
• Minimum SOC: 10%
• Maximum SOC: 100
• Dynamic Manual Period (Tomorrow): empty

sensor.home_energy_meter_power
When the home energy meter goes offline, Smart Matching enters emergency stop mode after one minute. Battery output is forced to 0 watts. When the meter returns online, the process resumes.

Disable SOC protection
It is now possible to disable SOC protection. When the battery drops below the minimum SOC, it will no longer automatically recharge and will wait for the BMS to act.

Min/Max SOC control
You can now set minimum and maximum SOC directly in Home Assistant. These values override the Zendure app and sync immediately.

New entities

Cell balance status sensors (1–6)
sensor.zendure_battery_1_cell_balance_status – sensor.zendure_battery_6_cell_balance_status

Cell balance classification:

• Excellent ≤ 0.02V
• Good ≤ 0.05V
• Slight Imbalance ≤ 0.08V
• Imbalanced > 0.08V

Automation watchdog
input_datetime.zendure_gielz_automation_last_time_executed
Checks every 5 seconds if automation is still running. If not, a red cross appears after 2 minutes in the dashboard config tab.

sensor.zendure_indication_required_energy (#95 by @NextNebula)
Indicates how much energy is required to charge the battery to maximum SOC (including efficiency losses).

sensor.zendure_indication_remaining_charge_time (#95 by @NextNebula)
Estimates remaining time to full charge including efficiency.

Dutch (NL)

Deze update bevat een groot aantal verbeteringen, nieuwe functies, bugfixes en kleine kwaliteitsverbeteringen om de integratie stabieler, flexibeler en gebruiksvriendelijker te maken.

Grote dank aan alle gebruikers, testers, bijdragers en sponsors voor alle feedback en support. En als deze integratie je energierekening iets minder pijnlijk heeft gemaakt, overweeg dan om de repository een ster te geven ⭐⭐⭐


[...]

Bug fixes

Dynamische spread
Probleem opgelost waarbij de dynamische spreadberekening onjuist was bij negatieve energieprijzen.

Kleine wijzigingen

Batterij Volgorde
Maximum invullengte aangepast van 11 naar 44.

Maximum Laad/Ontlaadvermogen
Nu instelbaar vanaf 400 watt (was 800 watt). Lager dan 800 watt beïnvloedt RTE.

Start laden/ontladen
Nu instelbaar van -80 tot 80 watt (was -100 tot 100 watt).

Nieuwe functies

Automatisch aanbevolen instellingen
Bij het instellen of wijzigen van het Zendure IP-adres (input_text.zendure_2400_ac_ip_adres) worden automatisch instellingen toegepast:

• Standby vertraging: 15 minuten
• Opladen starten bij: -300 watt
• Ontladen starten bij: 100 watt
• Ontlaadmarge: 5 watt
• Oplaadmarge: 50 watt
• Min SOC: 10%
• Max SOC: 100%
• Dynamische periode (morgen): leeg

sensor.p1_aansturing_vermogen
Bij offline gaan van de energiemeter gaat Smart Matching na 1 minuut in noodstop. Batterij wordt op 0 watt gezet. Bij terugkomst wordt het proces hervat.

SOC bescherming uitschakelen
SOC bescherming kan nu worden uitgeschakeld. De batterij wordt niet automatisch bijgeladen onder minimum SOC; het BMS bepaalt de actie.

Min/max SOC instelbaar
Minimale en maximale SOC zijn nu direct instelbaar in Home Assistant en vervangen de Zendure app.

Nieuwe entiteiten

Celbalans status (1–6)
sensor.zendure_2400_ac_batterij_1_celbalans_status – sensor.zendure_2400_ac_batterij_6_celbalans_status

Status:

• Uitstekend ≤ 0,02V
• Goed ≤ 0,05V
• Lichte onbalans ≤ 0,08V
• Onbalans > 0,08V

Automatisering watchdog
input_datetime.zendure_gielz_automatisering_laatste_keer_uitgevoerd
Controleert elke 5 seconden of de automatisering nog draait. Zo niet, verschijnt na 2 minuten een rood kruis in het dashboard.

sensor.zendure_2400_ac_indicatie_benodigde_energie (#95 door @NextNebula)
Geeft aan hoeveel energie nodig is om de batterij tot max SOC te laden, inclusief efficiëntie.

sensor.zendure_2400_ac_resterende_oplaad_tijd (#95 door @NextNebula)
Geeft de geschatte resterende laadtijd tot max SOC, inclusief efficiëntie.

Top! Vraagje, hoe werkt de call balans status als je meerdere stapels/2400 ac hebt met in totaal dus meer dan 6 batterijen?

[jordyc]

dit is het zendure HA topic.

[ Voor 102% gewijzigd door teacher op 09-05-2026 08:36 ]

[ctrl-tab]

Hoe lucratief is dat handelen nu eigenlijk met het weer van afgelopen dagen?

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

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

Heb 6 ab3000x dis ~14 kw beschikbaar.

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

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

Volgend jaar andere spelregels natuurlijk.

[gielz]

Henkoes schreef op donderdag 7 mei 2026 @ 21:55:
[...]


Top! Vraagje, hoe werkt de call balans status als je meerdere stapels/2400 ac hebt met in totaal dus meer dan 6 batterijen?

@gast777 had jij deze al in het sensor pakket?

[..Christiaan..]

YvonneVP schreef op donderdag 7 mei 2026 @ 00:48:
[...]

HA op een VM is misschien gewoon niet zo'n goede combi op een Windows machine.

Ik draai HA op VM op mijn Synology DS218+. Werkt op zich wel lekker maar ik merk wel dat het al snel op de limiet van mijn NAS zit. Ik kan max 2GB geheugen toewijzen en ik heb geen ssd schijven. Ik zit ook te denken om over te stappen.

[gielz]

..Christiaan.. schreef op vrijdag 8 mei 2026 @ 08:06:
[...]

Ik draai HA op VM op mijn Synology DS218+. Werkt op zich wel lekker maar ik merk wel dat het al snel op de limiet van mijn NAS zit. Ik kan max 2GB geheugen toewijzen en ik heb geen ssd schijven. Ik zit ook te denken om over te stappen.

Je zou hier makkelijk HA op kunnen draaien. Zoek even naar een extra ram module en prik die erbij. Aangezien het geen ddr5 is zullen de prijzen nog wel mee vallen.

[MikeyMan]

..Christiaan.. schreef op vrijdag 8 mei 2026 @ 08:06:
[...]

Ik draai HA op VM op mijn Synology DS218+. Werkt op zich wel lekker maar ik merk wel dat het al snel op de limiet van mijn NAS zit. Ik kan max 2GB geheugen toewijzen en ik heb geen ssd schijven. Ik zit ook te denken om over te stappen.

Ik heb 20gb in mn ds1520+ gepropt. Twee ssds erin. Draait als een zonnetje.

Was wel een hel om het spul over te zetten op btrfs.

[Keida]

dit is het zendure HA topic.

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

[ctrl-tab]

dit is het zendure HA topic.

[ Voor 93% gewijzigd door teacher op 09-05-2026 08:37 ]

[Henkoes]

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


@gast777 had jij deze al in het sensor pakket?

Dit zou echt super zijn als ik dit voor alle batterijen zou kunnen zien!