Zendure producten in Home Assistant integreren deel 2

[Mscroos]

Ben(V) schreef op vrijdag 13 november 2026 @ 09:44:
Alleen als je wifi brak is zou modbus beter werken, maar bij een normale wifi is http minstens zo goed als een seriële verbinding over rs485 met modus protocol.

Sterker nog modus is een "send and forget" protocol zonder handshake en/of retry en wifi heeft dat allemaal wel.

Mijn Wifi is zeker niet brak, dat is echt veel te kort door de bocht, heb Unifi met verschillende AP's met optimaal bereik voor de units (Good - Excellent 98% van de tijd over de drie units). op dit moment staan ze vast op 1 access point welke helemaal is ingericht op de zendure batterijen. Met heel veel tweaken over de tijd om te testen wat wel/geen impact heeft qua instellingen.

Ik heb met een aantal kennissen allemaal dezelfde setup (3 setjes AC2400+) en we zien allemaal dezelfde symptomen (met verschillende netwerk setups).

Natuurlijk werkt het allemaal wel, maar er blijven disconnects zijn (bij mij 2-3 per dag) die we niet kunnen verklaren. Dit gebeurd bij alle andere apparaten in mijn netwerk niet of veel minder.

Daarnaast is het gewoon ook leuk om als tweaker te tweaken toch? En hun eigen powerhub stuurt ook via modbus aan als je die ertussen zet. Dus er zal echt wel een voordeel inzitten ergens, maar dat weet je niet voordat je het geprobeerd hebt ☺️.


Wat betreft het send en forget (heb niet veel ervaring nog met modbus) meldt google mij dit:

Modbus RTU / Serial (applicatielaag):

• Bij een write-commando (zoals Write Single Register of Write Multiple Registers) stuurt de slave bij een geslaagde actie een echo terug (de slave stuurt exact hetzelfde bericht of functiecode terug). Dit fungeert als een bevestiging dat de actie is uitgevoerd.
• Bij een read-commando is het antwoord zelf (de gevraagde registerdata) de bevestiging.

[ Voor 17% gewijzigd door Mscroos op 13-11-2026 10:19 ]

[Ben(V)]

Ik heb helemaal niet beweerd dat jouw wifi brak is, ik zei dat modbus alleen voordelen zou hebben als je wifi brak is, al klink het wel also het niet helemaal ok is, ik heb helemaal nooit disconnects.

En die echo is op applicatie niveau en niet op protocol niveau, ofwel de applicaties aan de HA kant evenals die aan de Zendure kant moeten bij een write dan een retry aanvragen als de echo niet ok terugkomt en dat is bij modbus implementaties zelden het geval.
En bij een read weet je dus nooit of je wel de juiste data binnenkrijgt, er zit geen checksum of zo iets overheen.

Wifi regelt dat op protocol niveau.

[Mscroos]

Ben(V) schreef op vrijdag 13 november 2026 @ 10:35:
Ik heb helemaal niet beweerd dat jouw wifi brak is, ik zei dat modbus alleen voordelen zou hebben als je wifi brak is, al klink het wel also het niet helemaal ok is, ik heb helemaal nooit disconnects.

En die echo is op applicatie niveau en niet op protocol niveau, ofwel de applicaties aan de HA kant evenals die aan de Zendure kant moeten bij een write dan een retry aanvragen als de echo niet ok terugkomt en dat is bij modbus implementaties zelden het geval.
En bij een read weet je dus nooit of je wel de juiste data binnenkrijgt, er zit geen checksum of zo iets overheen.

Wifi regelt dat op protocol niveau.

Was ook echt niet m'n punt naar jou (beetje onhandig geschreven), maar ik zie zag dat zelfs met optimale wifi er problemen zijn in de communicatie. Heb nu weing issues met de communicatie, maar het blijft dat ik in mijn unifi logs kan zien dat de units af en toe de verbinding kwijt zijn en dan weer connecten. Heeft geen impact op de functionaliteit voor zover ik kan zien.....

Maar nu..... terwijl ik dit bericht tik en eigenlijk weer in alle logs kijk om aan te geven wat ik dan zie en wat het probleem is (met goede wifi 😉) merk ik het volgende op....

Sinds de firmware update van afgelopen maandag (2.0.5) is het communicatie problem via @gast777 verdwenen..... als dat zo is dan hebben ze toch wel een bugje heel netjes opgelost en zijn er geen timeouts meer.

[Ben(V)]

De Zendures hebben maar een beperkte cpu/netwerk capaciteit en als een applicatie te vaak en/of te snel commandos stuurt gaat het mis.
Ik vermoed dat dit hier het geval was maar is wel speculatie van mijn kant.

Modus zou waarschijnlijk precies hetzelfde effect geven.

[ Voor 12% gewijzigd door Ben(V) op 13-11-2026 11:50 ]

[Gramser]

Hee, ik zie dat @gielz de fix heeft doorgevoerd waarmee we zorgeloos de firmware kunnen updaten. Muchas gracias!

Nu weer ff kijken wát ik dan ook weer moet updaten. Alleen configuration, of ook automation en dashboard…? Telkens een zoektochtje 😆

Edit: idd config en autom, en de proxysensoren van @gast777 weer even toevoegen. Done en de firmware weer probleemloos geupdate!

[ Voor 20% gewijzigd door Gramser op 13-11-2026 14:21 ]

[gielz]

Gramser schreef op vrijdag 13 november 2026 @ 12:32:
Hee, ik zie dat @gielz de fix heeft doorgevoerd waarmee we zorgeloos de firmware kunnen updaten. Muchas gracias!

Nu weer ff kijken wát ik dan ook weer moet updaten. Alleen configuration, of ook automation en dashboard…? Telkens een zoektochtje 😆

Nu maar hopen dat ze niet weer zonder te communiceren de api aanpassen.

Ze passen namelijk ook nooit https://github.com/Zendure/zenSDK aan.

[Mscroos]

gielz schreef op vrijdag 13 november 2026 @ 12:59:
[...]


Nu maar hopen dat ze niet weer zonder te communiceren de api aanpassen.

Ze passen namelijk ook nooit https://github.com/Zendure/zenSDK aan.

Beetje gemiste kans, maar herkenbaar bij veel bedrijven. Met iets meer aan communicatie krijg je zoveel meer tevreden klanten, terwijl ze volgens mij met hun firmware echt wel goed bezig zijn. Ik vind iig dat het steeds stabieler aan het worden is.

@gielz jij weer bedankt voor de nieuwe versie! ben nog steeds helemaal happy met het goede werk! ( en dat van @gast777 natuurlijk). Kan niet wachten op de periode dat we weer wat meer zon gaan krijgen en de Zendures weer wat harder te kunnen laten werken...

[Mscroos]

@gielz het gebrek aan communicatie triggerde mij een beetje... Wat als er nog meer veranderd is?

Dus even oude en nieuwe API vergeleken, er is nog wel meer anders geworden (AC2400+) en het lijkt er ook op dat de reset is ingevoerd?

OOk de avialable power geven zij nu aan, dat was toch iets wat jij ook zelf berekende?

OLD	NEW
"heatState": 0,	heatState: 0
"packInputPower": 0,	packInputPower: 0
"outputPackPower": 0,	outputPackPower: 0
"outputHomePower": 0,	outputHomePower: 0
"remainOutTime": 59940,	remainOutTime: 59940
"packState": 0,	packState: 0
"electricLevel": 93,	electricLevel: 60
"gridInputPower": 0,	gridInputPower: 0
"solarInputPower": 0,	solarInputPower: 0
"solarPower1": 0,	solarPower1: 0
"solarPower2": 0,	solarPower2: 0
"solarPower3": 0,	solarPower3: 0
"solarPower4": 0,	solarPower4: 0
"pass": 0,	pass: 0
"reverseState": 0,	reverseState: 0
"socStatus": 0,	socStatus: 0
"hyperTmp": 3071,	hyperTmp: 3041
"gridOffPower": 0,	gridOffPower: 0
"dcStatus": 0,
"pvStatus": 0,
"acStatus": 0,
"dataReady": 1,	dataReady: 1
"gridState": 1,	gridState: 1
"BatVolt": 4994,	BatVolt: 5003
"socLimit": 0,	socLimit: 0
"faultLevel": 0,	faultLevel: 0
"acCouplingState": 57344,	acCouplingState: 57344
"offGridState": 0,	offGridState: 0
	offGridSurplus: 0
"dryNodeState": 1,	dryNodeState: 1
"writeRsp": 0,
	acReverse: 0
	chargeAvailPower: 0
	dischargeAvailPower: 0
	derateFlag: 0
"acMode": 2,	acMode: 2
"inputLimit": 0,	inputLimit: 255
"outputLimit": 0,	outputLimit: 0
"socSet": 1000,	socSet: 1000
"minSoc": 100,	minSoc: 100
"gridStandard": 4,	gridStandard: 4
"gridReverse": 2,	gridReverse: 1
"inverseMaxPower": 2400,	inverseMaxPower: 2400
"lampSwitch": 1,	lampSwitch: 1
"gridOffMode": 2,	gridOffMode: 2
"IOTState": 2,	IOTState: 2
"Fanmode": 1,	Fanmode: 1
"Fanspeed": 0,	Fanspeed: 0
"bindstate": 0,	bindstate: 1
"factoryModeState": 0,	factoryModeState: 0
"OTAState": 0,	OTAState: 0
"LCNState": 0,
"oldMode": 0,	oldMode: 0
"VoltWakeup": 0,	VoltWakeup: 0
"ts": 1779566220,
"tsZone": 14,	tsZone: 13
"smartMode": 0,	smartMode: 1
"chargeMaxLimit": 2400,	chargeMaxLimit: 2400
"phaseSwitch": 1,	phaseSwitch: 1
"batCalTime": 0,	batCalTime: 60
	socCompSwitch: 0
	reset: 0
"packNum": 3,	packNum: 3
"rssi": -48,	rssi: -46
"is_error": 0	is_error: 0

[gast777]

hemertje schreef op woensdag 11 november 2026 @ 21:10:
@gast777

Bij mij (3× SolarFlow 2400 AC+) werd de totale SoC unavailable zodra één unit zijn webserver niet meer beantwoordde.

In de flow “GET Response handling” in gast777’s proxy wordt packData van alle units samengevoegd; ontbreekt het antwoord van één unit, dan faalt het hele antwoord (packData is not iterable).

Is dat bewust zo?
Een terugval per unit (alleen de bereikbare units samenvoegen) lijkt me beter.
Alles herstelde pas na een herstart van de units.

Ja, dit is "by design".

In de documentatie staat ook bij Requirements: "The Zendures have to be reachable via the network and be operational."

[wesdi83]

Daytona schreef op dinsdag 10 november 2026 @ 12:15:

- de P1 data van mijn DSMR5 update 'slechts' om de 5-10 seconden

Heb je toevallig ook een Landis + Gyr E350 slimme meter?
Verstuurt wel iedere seconde een telegram, maar de waardes worden om de 10 seconden ververst.

[ Voor 104% gewijzigd door wesdi83 op 13-11-2026 17:01 ]

[HansB2]

wesdi83 schreef op vrijdag 13 november 2026 @ 16:01:
[...]

Heb je toevallig ook een Landis + Gyr E350 slimme meter?
Verstuurt wel iedere seconde een telegraam, maar de waardes worden om de 10 seconden ververst.

Dat klopt idd voor de E350. Heb ik ook helaas.

Kan je bij NOM een stuk verbeteren door in de gielz automation /5 te verhogen naar /20 of /21. Gaat dan prima, in iefergeval goed genoeg tot de meter wordt gewisseld.

groet,

Hans

[ Voor 4% gewijzigd door HansB2 op 13-11-2026 16:46 ]

[DaanVervacke]

Wie ging er mij vertellen dat mijn Solarflow AC2400 opeens at random (schijnbaar in een poging tot kalibratie) naar 100 procent zou beginnen opladen? Haal ik dat ding van zn China-owned servers, doet het nog steeds dingen die ik niet vraag...

[JWT]

Daar is het andere zendure topic voor daar is het vaak langs gekomen.

[Gramser]

Gewoon onderdeel van de Zendure-totaalbeleving.

[ppaulv]

Ben benieuwd hoe 'jullie' omgaan met calibratie als je gebruik maakt van Gielz en NR proxy van gast777.
Je kunt dan niet zien hoelang het geleden is dat elke individuele accu is gecalibreerd (naar 100% is getrokken) en worden alle accu's tesamen als één gezien.
En ik wil niet graag overvallen worden door een gezamenlijke calibratie actie (alle accu's tegelijk) op een moment dat het mij echt niet uitkomt. Of dat de Zendure software zelf op eigen houtje iets gaat doen en Gielz/NR genegeerd worden.
Daarom heb ik, samen met mijn nieuwe vriend Claude, een automatisering gemaakt om die calibratie a) handmatig met een knop te kunnen starten per accu apart en b) dat die er daarna geheel zelf voor zorgt dat ze om de beurt, met 2 weken tussenuimte, gecalibreerd worden.
Dat met die knoppen heb ik nu getest en werkt gladjes, dat met die 2 en/of 4 weken moet ik nog afwachten.

[Gramser]

Gielz ziet de percentages als een gemiddelde van alle aangesloten batterijen, als ik me niet vergis? Kalibratie heeft dan alleen plaatsgevonden als de hele toren(s) naar de 100% zijn gegaan.

Ik snap denk ik niet wat je bedoelt.

[Cardinal]

Forecasting 2026.11.6 (gebaseerd op Gielz v20261113)

Nieuw

• Slim vasthouden als eigen schakelaar (standaard aan), plus vasthouden tussen laadslots: de accu levert niet als bijladen later duurder is dan nu inkopen
• Verbruiksprofiel per weekdag, zodat de planner bijvoorbeeld een thuiswerkdag herkent
• Betrouwbaarheid zonvoorspelling per maand, met automatisch meten en invullen voor volgend jaar
• Kalibratieladen: na 14 dagen zonder 100% één keer vol laden in de goedkoopste kwartieren (eerst wachten op zon)
• Planning (was Pad-check): duidelijke tekst over tekort, inkoop, laden en ruimte voor de zon
• Plan Tijdlijn grafiek: netladen in blauw, laadpercentage op een eigen as, tijdlabels per 3 uur en middernachtlijnen

Verder

• Invoervelden worden automatisch opgeschoond
• HomeWizard in een Nederlandstalige Home Assistant wordt automatisch herkend
• Waarschuwingen bij een verkeerde teller of opslag
• De diagnose-export geeft meer informatie.

Upgraden: vervang alle bestanden, herstart Home Assistant en plak het dashboard opnieuw.

Mijn dank aan iedereen die een JSON heeft aangeleverd. Ik kon jullie helpen en jullie hebben mij geholpen met het opsporen van issues.
Mijn dank ook aan de lurkers met lieve berichten in PM

[Quiqziz]

Aangezien ik een Quooker heb waarvan ik niet wil dat mijn Zendure continu op de kortdurende vermogenspieken reageert, heb ik het hiervoor regelmatig gegeven advies opgevolgd om een template sensor te maken die het vermogen van de quooker aftrekt van het totaal vermogen van het huis. Dit laatse is in mijn geval gemeten met een Shelly Pro 3CT63. Met de template sensor wordt dan mijn Zendure aangestuurd via de Gielz integratie.

De template is als volgt geconfigureerd :

{{ states('sensor.shellypro3em63_vermogen') | float(0) - states('sensor.shellyplugmg3_quooker_vermogen') | float(0) }}

De quooker wordt gemeten met een Shelly Plug M gen 3.

Nu zie ik toch dat de template sensor pieken laat zien,eerst postief en vervolgens negatief. Het lijkt dus of de Shelly plug de vermogenspiek later doorgeeft dan de CT meter, waardoor de template sensor alsnog eerst een piek geeft. Vervolgens wordt na het uitschakelen van het verwarmingselement ook het afgenomen vermogen te laat doorgegeven waardoor juist een uitschieter naar beneden ontstaat.

Weet iemand een slimmigheid om dit op te lossen?

[Hippe Lip]

Pakhaas schreef op donderdag 12 november 2026 @ 11:03:
Is Dynamic Smart Matching hetzelfde als Dynamisch NOM?

Ja, behalve de taal

[Hippe Lip]

Do-m-pie schreef op donderdag 12 november 2026 @ 11:22:
Zonoverschot?

Even teruggekeken op mijn iungo en dat zou zomaar kunnen.
Stom van me om daar niet aan te denken.

[Hippe Lip]

Gramser schreef op donderdag 12 november 2026 @ 15:03:
Zonoverschot zou mijn eerste gedachte zijn, maar ik zie dat je ook 82 highest price periods hebt ingevuld. Is dat niet wat veel?

Dat zag ik net ook; het moeten er 80 zijn, want 96 kwartieren in een etmaal.
Dit vind ik zo onhandig bij deze mode en heb @gielz al eens voorgesteld om in de modus ‘Dynamisch NOM’ te zorgen dat je alleen het aantal goedkope periodes (uren/kwartieren) in hoeft te vullen en dat er automatisch aangevuld wordt met de rest voor de dure periodes. Als je minder wil dan gebruik je immers ‘Dynamisch NOM Duur’, toch?

Daarmee beperk je ook de periodes dat het niet laag is (dus het grijze gebied tussen groen en rood). En in die grijze periodes zou hij niks doen (hoewel, dan zou hij dus NOMmen), en als je net in een groene periode beland bent gaat-ie laden.

Dat laatste is toch de modus ‘Dynamisch NOM Duur’?

[Hippe Lip]

Cardinal schreef op donderdag 12 november 2026 @ 17:40:
Ging de auto om 10:04 laden?

Nee. Ten eerste heb ik het hier over laden van de batterij en niet ontladen.
Maar verder wordt het gebruik van mijn laadpaal uitgefilterd uit de P1 voor de Zendures. Voor de laadpaal heb ik een eigen laadregime: de ‘Dynamisch-HA’, ook van Gielz. Zo houd ik die twee gescheiden en zitten ze elkaar niet dwars.

[Pakhaas]

Hippe Lip schreef op vrijdag 13 november 2026 @ 23:43:
[...]

Dat zag ik net ook; het moeten er 80 zijn, want 96 kwartieren in een etmaal.
Dit vind ik zo onhandig bij deze mode en heb @gielz al eens voorgesteld om in de modus ‘Dynamisch NOM’ te zorgen dat je alleen het aantal goedkope periodes (uren/kwartieren) in hoeft te vullen en dat er automatisch aangevuld wordt met de rest voor de dure periodes. Als je minder wil dan gebruik je immers ‘Dynamisch NOM Duur’, toch?

[...]

Dat laatste is toch de modus ‘Dynamisch NOM Duur’?

Zie mijn reactie in andere topic. Je hoeft niet zoveel dure kwartieren te selecteren 😅

Je moet het aantal goedkope selecteren die je wil laden en minstens 1 rode zodat hij een spread kan berekenen. Anders doet die niks tijdens goedkope monent. De rest doet die nom.

[ Voor 12% gewijzigd door Pakhaas op 13-11-2026 23:51 ]

[Hippe Lip]

Quiqziz schreef op vrijdag 13 november 2026 @ 22:55:
Aangezien ik een Quooker heb waarvan ik niet wil dat mijn Zendure continu op de kortdurende vermogenspieken reageert, heb ik het hiervoor regelmatig gegeven advies opgevolgd om een template sensor te maken die het vermogen van de quooker aftrekt van het totaal vermogen van het huis. Dit laatse is in mijn geval gemeten met een Shelly Pro 3CT63. Met de template sensor wordt dan mijn Zendure aangestuurd via de Gielz integratie.

De template is als volgt geconfigureerd :

{{ states('sensor.shellypro3em63_vermogen') | float(0) - states('sensor.shellyplugmg3_quooker_vermogen') | float(0) }}

De quooker wordt gemeten met een Shelly Plug M gen 3.

Nu zie ik toch dat de template sensor pieken laat zien,eerst postief en vervolgens negatief. Het lijkt dus of de Shelly plug de vermogenspiek later doorgeeft dan de CT meter, waardoor de template sensor alsnog eerst een piek geeft. Vervolgens wordt na het uitschakelen van het verwarmingselement ook het afgenomen vermogen te laat doorgegeven waardoor juist een uitschieter naar beneden ontstaat.

Weet iemand een slimmigheid om dit op te lossen?

Dat effect heb ik ook gezien. Ik heb een tijd geleden mijn Quooker ook een tijd op een Shelly-plug gehad en die miste regelmatig de korte bijwarmpiekjes.
Dat blijkt te komen omdat die piekjes te kort zijn. Zo’n tussenstekker meet ook niet écht continu en neemt samples. Het is immers allemaal digitaal. Als nu zo’n piek net tussen twee samples valt, dan mis je die.
Simpel en toch eenvoudig

[Hippe Lip]

Pakhaas schreef op vrijdag 13 november 2026 @ 23:50:
[...]

Zie mijn reactie in andere topic. Je hoeft niet zoveel dure kwartieren te selecteren 😅

Je moet het aantal goedkope selecteren die je wil laden en minstens 1 rode zodat hij een spread kan berekenen. Anders doet die niks tijdens goedkope monent. De rest doet die nom.

Dan mag @gielz zijn wiki wel eens bijwerken, want daar staat het toch echt anders:

Vul als eerste in hoeveel uren je goedkoop zou willen laden per dag via input_number.dynamisch_goedkoopste_x_periode_morgen dit is bijvoorbeeld 3 uur.
Vervolgens vul je de overige duurste uren in via input_number.dynamisch_duurste_x_periode_morgen dit is bijvoorbeeld 21 uur. Wanneer nu sensor.dynamisch_goedkoopste_periode op JA staat zal er opgeladen worden indien sensor.dynamisch_spread_indicatie_nom hoger is dan input_number.dynamisch_minimale_spread. Hij zal na laden constant 0 op de meter behouden (-xx watt bij opladen en -xx watt bij ontladen) en elke dag het dynamisch laden uitvoeren.

Heb jij het no mis, @Pakhaas of @gielz?

[Pakhaas]

Hippe Lip schreef op zaterdag 14 november 2026 @ 00:03:
[...]

Dan mag @gielz zijn wiki wel eens bijwerken, want daar staat het toch echt anders:


[...]


Heb jij het no mis, @Pakhaas of @gielz?

Mij werkt Dynamisch NOM als ik bijv 4 goedkope en 1 Duur kwartier selecteer. Zo lang de spread maar boven minimum spread komt. Gielz zegt daar ook "bijvoorbeeld" dus het is een voorbeeld. Niet dat het verplicht is het zo te doen.

[Hippe Lip]

Pakhaas schreef op vrijdag 13 november 2026 @ 23:50:
Zie mijn reactie in andere topic.

Linkje?

[Hippe Lip]

Pakhaas schreef op zaterdag 14 november 2026 @ 00:05:
Mij werkt Dynamisch NOM als ik bijv 4 goedkope en 1 Duur kwartier selecteer. Zo lang de spread maar boven minimum spread komt. Gielz zegt daar ook "bijvoorbeeld" dus het is een voorbeeld. Niet dat het verplicht is het zo te doen.

Er wordt toch heel duidelijk over ‘overige’ gesproken. En in dat voorbeeld (met uren) tellen die twee netjes op tot 24.

En als dat niet van belang is (behalve nul), waarom moet je er dan überhaupt iets invullen? Dan kan dat toch automatisch gaan?

En nu ik dit schrijf bedenk ik me dat je spread waarschijnlijk niet gaat kloppen als je die twee niet samen tot 24 (uren) of 96 (kwartieren) laat optellen.
De spread tussen 4 duurste en 1 goedkoopste uur is anders dan die tussen 4 duurste en 20 goedkoopste.

[ Voor 6% gewijzigd door Hippe Lip op 14-11-2026 00:11 ]

[Pakhaas]

Hippe Lip schreef op zaterdag 14 november 2026 @ 00:06:
[...]

Linkje?

Staat hierboven al.

[Hippe Lip]

Pakhaas schreef op zaterdag 14 november 2026 @ 00:10:
[...]

Staat hierboven al.

Waarom maak je er zo’n puzzel van, want ik zie die niet.

Hier staat toch echt geen link?!

[ Voor 50% gewijzigd door Hippe Lip op 14-11-2026 00:15 ]

[Pakhaas]

Hippe Lip schreef op zaterdag 14 november 2026 @ 00:10:
[...]

Er wordt toch heel duidelijk over ‘overige’ gesproken. En in dat voorbeeld (met uren) tellen die twee netjes op tot 24.

En als dat niet van belang is (behalve nul), waarom moet je er dan überhaupt iets invullen? Dan kan dat toch automatisch gaan?

En nu ik dit schrijf bedenk ik me dat je spread waarschijnlijk niet gaat kloppen als je die twee niet samen tot 24 (uren) of 96 (kwartieren) laat optellen.

Op dit moment kan NOM sowieso niet uit, dus wat je ook doet. Rendabel is dat niet. Vanaf 2027 is dat anders. Dan zal de spread voor nom ook snel rendabel zijn.

Voor de spread berekening moet je gewoon minimaal 1 goedkoop en 1 duur anders staat er niet bekend ofzo en dan gaat die niet laden.

[Pakhaas]

Hippe Lip schreef op zaterdag 14 november 2026 @ 00:12:
[...]

Waarom maak je er zo’n puzzel van, want ik zie die niet.

Zucht. Ik had mijn quote al naar dit topic verhuist.

[Hippe Lip]

Pakhaas schreef op zaterdag 14 november 2026 @ 00:15:
Op dit moment kan NOM sowieso niet uit, dus wat je ook doet. Rendabel is dat niet. Vanaf 2027 is dat anders. Dan zal de spread voor nom ook snel rendabel zijn.

Dat is een heel ander onderwerp. Laten we het houden bij de vraag.

Voor de spread berekening moet je gewoon minimaal 1 goedkoop en 1 duur anders staat er niet bekend ofzo en dan gaat die niet laden.

Nu zie ik nog steeds niet dat je niet hoeft aan te vullen.
Het zal wel werken, maar de berekening van de spread zal onjuist zijn.

Zie mijn voorbeeld in het andere topic. Het was niet mijn bedoeling om het gesprek over dit punt over twee topics te verdelen. Weet niet hoe dat ontstaan is.

[ Voor 16% gewijzigd door Hippe Lip op 14-11-2026 00:39 ]

[Hippe Lip]

Pakhaas schreef op zaterdag 14 november 2026 @ 00:16:
Zucht. Ik had mijn quote al naar dit topic verhuist.

Dan kom ik weer terug bij mijn vraag:
Linkje naar welke post je bedoelt?

[Pakhaas]

Hippe Lip schreef op zaterdag 14 november 2026 @ 00:19:
[...]

Dan kom ik weer terug bij mijn vraag:
Linkje naar welke post je bedoelt?

Geen idee of dit werkt, maar succes ermee:

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

[Pakhaas]

Hippe Lip schreef op zaterdag 14 november 2026 @ 00:18:
[...]

Dat is een heel ander onderwerp. Laten we het houden bij de vraag.

[...]

Nu zie ik nog steeds niet dat je niet hoeft aan te vullen.
Het zal wel werken, maar de berekening van de spread zal onjuist zijn.

Waarom een ander onderwerp. Waarom moet de spread zo goed kloppen als je toch geen winst er mee maakt. Daarom is nu de spread en spread nom ook altijd gelijk. Volgend jaar zal spread nom veel hoger zijn en daardoor Dynamisch NOM ook veel rendabeler dan dynamisch handelen. Je krijgt immers voor teruglevering straks alleen nog de kale prijs.

Succes en welterusten

[ Voor 8% gewijzigd door Pakhaas op 14-11-2026 00:27 ]

[Hippe Lip]

Pakhaas schreef op zaterdag 14 november 2026 @ 00:22:
[...]

Geen idee of dit werkt, maar succes ermee:

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

Ik zie nu pas dat we dit punt over twee topics zitten te voeren. Das niet echt handig.

[Hippe Lip]

Pakhaas schreef op zaterdag 14 november 2026 @ 00:26:
Waarom een ander onderwerp. Waarom moet de spread zo goed kloppen als je toch geen winst er mee maakt.

We hebben het over het punt of die twee getallen samen op moeten tellen tot 24 dan wel 96.
Dan is het nut van NOM een ander onderwerp.

Welterusten.

[Quiqziz]

@Cardinal ik ben ook aan het experimenteren met jouw planner, met name in voorbereiding naar wegvallen salderingsregeling. Een mooi stukje werk, complimenten! Het viel me op dat ik in de planner grafiek wel de verwachte zonne opbrengst (gele balken) van morgen zie, maar niet van vandaag. Oftewel ze verdwijnen (vermoed ik) als het middernacht is. Klopt dat? Houdt de planner dan wel rekening met de opbrengsten van vandaag? Ik gebruik Solcast.

Ook is het mijn nog niet helemaal duidelijk hoe straks de energiebelasting etc juist ingevuld moet worden vanuit de wiki beschrijving, en hoe dit zich vertaalt naar de all-in price en market price die in het dashboard te zien is. Dit wordt natuurlijk een belangrijke setting als je straks niet meer kunt salderen.

[Cardinal]

@Quiqziz Stuur me via PM de JSON (optionele export module) dan kijk ik even mee.

Ik gebruik nordpool (via marketplace), die creerd sensor.nordpool_kwh_nl_eur_3_10_0. Zodra die geinstalleerd is kan je de nordpool (optionele module) toevoegen en daar de waardes invullen die voor jou van toepassing zijn. Die creerd de correcte sensor.nordpool_kwh_nl_eur_5_09_0 (+ alle overige sensoren) die je bij de dynamische nordpool sensor (gielz) in kan vullen.


Zo ziet het er bij mij uit en is gebasseerd op zonneplan. Je kan de juiste waardes ophalen bij je energieleverancier of jeroen.nl.

[Nachtapotheker]

@Cardinal Wellicht enkel het labeltje, maar bij teruglevering is er geen btw volgend jaar.

[ppaulv]

Gramser schreef op vrijdag 13 november 2026 @ 22:38:
Gielz ziet de percentages als een gemiddelde van alle aangesloten batterijen, als ik me niet vergis? Kalibratie heeft dan alleen plaatsgevonden als de hele toren(s) naar de 100% zijn gegaan.

Ik snap denk ik niet wat je bedoelt.

Klopt helemaal en ik wil ze los van elkaar (laten) calibreren , niet als één grote massa.

[Lempke]

Cardinal schreef op zaterdag 14 november 2026 @ 08:44:
..

Zodra die geinstalleerd is kan je de nordpool (optionele module) toevoegen en daar de waardes invullen die voor jou van toepassing zijn.

..

Hoe heet die optionele module precies, ik kan die zo 1-2-3 niet vinden onder de Nordpool benamingen in de marketplace.