Warmtepomp aansturen met OTGW en Domotica (Homey Pro of HA)

[Jpiek]

Subject gestart naar aanleiding van verschillende berichten in de Subject "Weheat warmtepompen". Om er daar verder dieper op in te gaan zou het Off-topic maken, bovendien werkt dit (in principe) natuurlijk ook voor andere warmtepompen...

Na aanschaf van een warmtepomp (Weheat Blackbird P80) en de ze op advies van Fabrikant/Leverancier op Opentherm aansturen met een Thermostaat kam ik al snel tot de conclusie dat dit niet bepaald ideaal was qua stroomverbruik.

Ook sloeg de warmtepomp wel erg vaak aan en weer uit. Een tijdje gedraaid op een stooklijn, maar dat had ook zijn nadelen, waaronder het gebrek aan invloed p de binnentemperatuur. De WP stookt op basis van de buitentemperatuur zonder rekening te houden met bv opwarming door zonlicht of wind en windrichting, maar ik miste ook de mogelijkheid om te sturen op gewenste kamertemperatuur.

Ik had al een Homey Pro en kwam een OTGW (OpenTherm GateWay) tegen. Deze plaats je tussen WP en en Thermostaat en kan OT signalen monitoren maar ook beïnvloeden. Zo kun je bv. zelf een 'gevraagde watertemperatuur'/ Doeltemperatuur naar de WP sturen.
https://www.nodo-shop.nl/...herm-gateway-builder.html


Ik ben daarmee aan de slag gegaan en heb een formule bedacht die als het ware een stooklijn simuleerde.

Ik ben begonnen met een Basepoint bij 0 graden Celsius vast te stellen (uit de meeste ideale stooklijn genomen) en heb daar een formule aangehangen. Om bij een hogere of lagere buitentemperatuur een hogere of lagere Doeltemperatuur van het water te berekenen ben ik gaan rekenen met het verschil tussen die Basepoint bij 0C en de werkelijke buitentemperatuur en heb hiervoor een Deelfactor in het leven geroepen.

De formule is geworden : #Doeltemp = #Basepoint - (#Buitentemp/#Deelfactor)
Met echte waardes (voorbeeld) 35 - (12/1,3) = 25,7 bij 12C buitentemp, of bij -5 : 35 - (-5/1,3) = -38,8

Vervolgens ben ik gaan 'spelen' met een correctie op de Doeltemp met een aangemaakte variabele #Doeltempcorrectie:

Als de kamertemperatuur meer dan 0,5C afwijkt van de op de thermostaat ingestelde temperatuur:

#Doeltempcorrectie = (#Ingestelde Temperatuur - #Kamertemperatuur) * 4
Met echte waardes (voorbeeld) (21,5 - 21) * 4 = 2
of als de temperatuur te hoog oploopt : (21,5 - 22) *4 = -2
De Doeltempcorrectie verhoogt of verlaagd dus de gewenste doeltemperatuur.

Bij de OTGW moet je iedere minuut de Doeltemperatuur sturen om oververhitting of 'op hol slaan' te voorkomen, mocht de achterliggen de controller (in mijn geval de Homey Pro) vastlopen of de verbinding verliezen. Die je dat niet dan zal de thermostaat de controle weer overnemen.
Om de Doeltemp niet teveel te laten fluctueren bereken ik de doeltemp ongeveer elke 4 minuten

Ik stuur in Homey rechtstreeks een commando naar de OTGW :

elke 59 seconden :
Neem controle over : CH=1
Stuur doeltemperatuur : CS=xx

Ik bereken de uiteindelijk te sturen doeltemperatuur : #Doeltemp = #Doeltemp + #Doeltempcorrectie

Vervolgens kun je natuurlijk helemaal los gaan en van alles meenemen in die doeltempcorrectie, ik verlaag bv voor elke 1kWh aan opbrengst van mijn zonnepanelen de doeltemp met 1C omdat die hoeveelheid zon via de ramen ook het huis verwarmd.
Met veel ramen op het westen zou je je doeltemp aan kunnen passen bij westenwind.

maar bv ook de doeltemp kunnen verhogen als je stroom teruglevert, vlak voor de zon ondergaat nog even het water op temperatuur brengen als 's middags de WP uitgeschakeld was ivm zon en/of hogere buitentemperatuur.

[Kevin1990]

Ah toch begonnen hiermee! Fijn.

Ik ben nog een groentje in het automatiseren van systemen zoals je weet
Zelf heb ik HA in ons huis draaien. Zou bovenstaande ook kunnen werken met een Tado V3 draadloos met zone regeling?
Je hebt daardoor natuurlijk meerdere temperaturen die in de gaten gehouden moeten worden per kamer.

En om het nog iets lastiger te maken mag 1 thermostaat knop (zone die temperatuur meet en daarop aanstuurt) niet de Tado en dus de WP aansturen maar een klik aan klik uit schakelaar. Dit is voor een elektrische kachel in onze blokhut.

[nairolf]

Je eigen topic, leuk!

Laat ik even beginnen met dat ik geen WP heb, maar ik ben dan ook niet van de impulsaankopen. Wel heb ik me afgelopen anderhalf jaar ongeveer veel ingelezen in warmtepompen, maar ook in warmteverlies algemeen, verwarmingstechniek, etc.

Daarnaast werk ik zelf als software-engineer voor een bedrijf dat (onder andere) precisie-mechanica maakt en de aansturing daarvoor doet. Ik krijg daardoor erg veel mee van collegas over "control theory", het stabiel aansturen van een bepaald stuursignaal (control output) op basis van een ander teruglees-signaal (de feedback). Het kan dus zijn dat ik soms iets te snel/makkelijk over een bepaald onderwerp praat, zeg het dan vooral.

Het idee

Ik denk dat je idee in de basis helemaal goed is! Ik loop eigenlijk zelf ook al een tijd met een heel erg vergelijkbaar idee rond, maar ik heb gewoon te weinig tijd om het (goed) uit te voeren , en ik heb hem ook iets uitgebreider in mn hoofd, wat de uitvoering wat lastiger maakt.

OTGW heb ik ook, dat integreert mooi met HomeAssistant, en dus blijkbaar ook met Homey. Zelf vind ik het super interessant om te zien wat voor data daar allemaal uit rolt, maar de aanstuurmogelijkheden zijn ook heel erg handig! Lijkt me dus een prima keuze voor jouw situatie.

Doeltemp

Je formules zien eruit alsof ze gaan werken, maar ik denk dat je ze wellicht wat omslagtig hanteert. Je zou eens kunnen kijken naar het "graaddagen" model. Dat heeft een formule als volgt:
Benodigde energie per dag (24 uur) = max(0, stookgrens - gemiddelde buitentemperatuur over die 24 uur) * (factor).
De "stookgrens" is een temperatuur waarbij je praktisch niet meer stookt. Dat hangt heel erg af van je huis, maar ook je "leefpatroon", bijv. of er vaak mensen thuis zijn (ieder mens is een 100W kacheltje), maar bijv. of je veel met een oven kookt, etc.
De "max" functie zorgt ervoor dat als de 24-uurs gemiddelde buitentemperatuur boven de stookgrens uitkomt deze formule altijd op 0 uitkomt, en niet negatief wordt.
Als laatste is de "factor" de hoeveelheid extra energie (bijv kWh) die je bij iedere lagere graad buitentemperatuur nodig hebt.

Voorbeeld van mij: Ik heb (gemiddeld over de 365 dagen gemiddeld) een stookgrens van ~15 graden, en een "factor" van 0.24 kuub gas per graad lagere buitentemperatuur. Dat is te zien in onderstaande grafiek. Hierin is de 24-uut-gemiddelde hoeveelheid gas uitgezet tegen de 24-uur-gemiddelde buiten "gevoelstemperatuur" (JAG/TI methode). Hierin zie je dat ik bij -22 buitengevoelstemperatuur (dat is ongeveer -10 graden met 15m/s wind) ongeveer 8.8 kuub gas zou moeten gebruiken. (die blauwe lijn rolt uit mijn eigen algoritme)


Effectief is dit gewoon jouw formule voor #Doeltemp, maar ik heb hem gebaseerd op het idee van het graaddagen model, en ik baseer hem op gevoelstemperatuur, want ik zag dat de grafiek dan veel "rechter" is, en omdat je dan een grote invloed van wind ook indirect meeneemt.

Zelf ben ik van plan om het stookalgoritme op de 24-uurs gemiddelde weersvoorspelling te laten lopen, dus niet op de "instantane" buitentemperatuur of van de afgelopen 24 uur. Ik dacht ergens gelezen te hebben dat jij dat ook had, maar ik zie het hier in je topic even niet terug.

Doeltemp correctie

Hier begint het interessante stuk pas . Je hebt nu een vrij simpele correctie: Een "proportionele" actie, dus je correctie hangt alleen af van de huidige temperatuurfout. Je kan eens kijken naar het concept "PID regelaar". Die heeft naar dat proportionele deel "P", ook mogelijkheden tot "I" en "D" acties. De "I" actie is eigenlijk een "historie" actie, dat kan je zo zien: Als je 3 dagen lang steeds 0.5 graden achterloopt dan zegt jouw correctie nogsteeds maar +2 graden. De I-actie is eigenljk een "tellertje", hij houdt de opgetelde fout bij van de volledige historie (de Integraal, vandaar "I"). Dus als je 3 dagen achterloopt dan loopt die I-actie al 3 dagen lang op, waardoor je na 3 dagen bijvoorbeeld niet meer +2 corrigeert, maar +3 of +4 (hangt af van hoe "sterk" je de I-actie maakt, dat kan je gewoon instellen).
De D-actie is denk ik niet zo spannend, dat is de "derivative", die dus kijkt naar de "opwarmsnelheid" van je kamer. Maar omdat je niet "snel" wil corrigeren maar juist langzaam is een PI-regelaar (dus met uitgeschakelde D-actie) vaak al voldoende.

Dag-gemiddelde correctie??

Dan had ik zelf nog een interessant aspect op dit topic: Wat gebeurt er tijdens een SWW run van je WP? Dan ben je ineens een half uur of wel 2 uur aan verwarmingstijd kwijt. Die tijd is niet goed te voorspellen (hangt af van hoeveel je douchet die dat en hoe efficient de WP SWW kan verwarmen, dus langer bij lagere buitentemperatuur). Daarnaast nog defrosts, die wat tijd afsnoepen van je verwarming.

Wat er dus kan gebeuren is dat je de ene dag 18 uur aan het verwarmen bent (5 minuten per uur defrost, 5 minuten het "verlies" van je defrost inhalen, dat 24 keer per dag, en dan nog 2 uur SWW), en de andere dag 23 uur (alleen kort SWW). Je zal dus eigenlijk op die dag dat je 18 uur verwarmt een hogere watertemperatuur moeten aanhouden dan de dag van 23 uur, nog buiten het verschil wat komt uit buitentemperatuur.

Wat mijn idee dus was: Meet terug wat de "gemiddelde aanvoer-watertemperatuur van afgelopen 24 uur" is, en corrigeer je #Doeltemp daarop. Als je dus 2 uur lang SWW hebt gedaan dan is je 24-uurs gemiddelde even iets "ingekakt". Je wil dan mogelijk een paar uur even +2 graden extra hoog stoken om hem weer te corrigeren. En wat gebruik je daarvoor?? PID regelaars YAY . Deze zet je dan waarschijnlijk wat "aggressiever", zodat hij wat sneller optoert in zo'n situatie van 2 uur SWW. Dat "aggressief" hoeft echt niet heel erg te zijn, maar typisch wel veel sneller/aggressiever dan de binnentemperatuur PID.

Dan krijg je wat op de wiki pagina ook wel "Cascaded control" genoemd wordt. Dit is eigenlijk gewoon cascaded control, maar dan op binnentemperatuur waarvoor je maar langzaam corrigeert, en de aanvoertemperatuur waarop je sneller corrigeert.

Zelf ga ik dit heel circus dus uitvoeren op mn gasketel met OTGW, maar de essentie blijft gewoon gelijk.

---

Sorry als ik super onduidelijk ben, ik vind dit gewoon heel interessante materie en spar er graag over met mensen!

[Jpiek]

Hier kun je zien wat wel en niet gesupport word:
https://otgw.tclcode.com/matrix.cgi#thermostats selecteer je thermostaat en daaronder zie je alle beschikbare commando's
In de praktijk gebruik je eigenlijk alleen de Doeltemp qua aansturing.

De Tado zal die verschillende ruimte temperaturen toch moeten vertalen naar 1 Doeltemp richting WP of CV.
Wellicht kun je die individueel uitlezen met HA ?

[Jpiek]

@nairolf

Ik heb deze flow (zo heet dat in Homey) al een tijdje lopen, sinds half januari vorig jaar.
Ik ben IT-Engineer, geen programmeur en al helemaal niet thuis in verwarmingstechniek, maar op alles wat mijn interesse wekt volgt meestal een leaningcurve die veel gelijkenissen heeft met de kliffen van Dover

Mijn Doeltempcorrectie is in werkelijkheid wel heel wat gecompliceerder dan hier weergegeven, zoals ik het hier heb beschreven is meer om de achterliggende redenatie te beschrijven.

De WP hangt in een huis uit 1959, houten vloeren, geen VVW en dus ook niet veel massa waar je warmte in kunt bufferen. Er is wel (door mij) veel gedaan aan isolatie. Maar ik heb al wel gemerkt dat een reactief systeem beter werkt.

Daarnaast zit ik ook wel een beetje met de beperkingen van de manier waarop je flows bouwt in Homey, dat is toch wel heel anders dan een script in HA. Je unts scripts bouwen in/voor Home, maar da's mij nog teveel boven mijn pet. Advanced flows maken voor mij wel heel inzichtelijk wat de flow precies doet.

Ik ben wel nog steeds de flow aan het fine-tunen en zit normaliter meestal strak op een Doeltempcorrectie van 0, wat betekend dan mijn Doeltempberekening aardig spot-on is

SWW gaat niet via de Warmtepomp, ik heb een Electrische Duo boiler hangen (en het zal je niet verbazen) die aangestuurd wordt met Homey en een sussenschakelaar op de nacht/dalstroom aansluiting en alle teruglevering wegsnoept, pas eind van de dag/avond vult hij dat met netstroom aan.

Ik heb overigens ook een 'Defrostdetectie' die bv alle fans op de radiatoren uitzet, en na de Defros idd even de Doeltemp een boost geeft om terug op target te komen.

[Kevin1990]

Jpiek schreef op donderdag 30 oktober 2025 @ 12:21:
Hier kun je zien wat wel en niet gesupport word:
https://otgw.tclcode.com/matrix.cgi#thermostats selecteer je thermostaat en daaronder zie je alle beschikbare commando's
In de praktijk gebruik je eigenlijk alleen de Doeltemp qua aansturing.

De Tado zal die verschillende ruimte temperaturen toch moeten vertalen naar 1 Doeltemp richting WP of CV.
Wellicht kun je die individueel uitlezen met HA ?

Klopt voor het uilezen in HA. Alleen WeHeat ziet maar 1 temperatuur. Degene die het laatste gewijzigd is. Dit is vooral de werkkamer/logeerkamer of hobby kamer.
In de Tado app en in HA zie je ze allemaal afzonderlijk en kunnen uiteraard ook afzonderlijk gestuurd worden. Dit tot irritatie van sommige op het andere topic maar op stooklijn werkt het aardig en brengt rust in het systeem en comfort voor ons.

En ik begreep je verkeerd ik dacht dat je met de temperatuur verhoging de kamer temperatuur bedoelt maar je bedoelt de doeltemperatuur van het water?

[Kevin1990]

nairolf schreef op donderdag 30 oktober 2025 @ 12:10:
Je eigen topic, leuk!

Laat ik even beginnen met dat ik geen WP heb, maar ik ben dan ook niet van de impulsaankopen. Wel heb ik me afgelopen anderhalf jaar ongeveer veel ingelezen in warmtepompen, maar ook in warmteverlies algemeen, verwarmingstechniek, etc.

Daarnaast werk ik zelf als software-engineer voor een bedrijf dat (onder andere) precisie-mechanica maakt en de aansturing daarvoor doet. Ik krijg daardoor erg veel mee van collegas over "control theory", het stabiel aansturen van een bepaald stuursignaal (control output) op basis van een ander teruglees-signaal (de feedback). Het kan dus zijn dat ik soms iets te snel/makkelijk over een bepaald onderwerp praat, zeg het dan vooral.

Het idee

Ik denk dat je idee in de basis helemaal goed is! Ik loop eigenlijk zelf ook al een tijd met een heel erg vergelijkbaar idee rond, maar ik heb gewoon te weinig tijd om het (goed) uit te voeren , en ik heb hem ook iets uitgebreider in mn hoofd, wat de uitvoering wat lastiger maakt.

OTGW heb ik ook, dat integreert mooi met HomeAssistant, en dus blijkbaar ook met Homey. Zelf vind ik het super interessant om te zien wat voor data daar allemaal uit rolt, maar de aanstuurmogelijkheden zijn ook heel erg handig! Lijkt me dus een prima keuze voor jouw situatie.

Doeltemp

Je formules zien eruit alsof ze gaan werken, maar ik denk dat je ze wellicht wat omslagtig hanteert. Je zou eens kunnen kijken naar het "graaddagen" model. Dat heeft een formule als volgt:
Benodigde energie per dag (24 uur) = max(0, stookgrens - gemiddelde buitentemperatuur over die 24 uur) * (factor).
De "stookgrens" is een temperatuur waarbij je praktisch niet meer stookt. Dat hangt heel erg af van je huis, maar ook je "leefpatroon", bijv. of er vaak mensen thuis zijn (ieder mens is een 100W kacheltje), maar bijv. of je veel met een oven kookt, etc.
De "max" functie zorgt ervoor dat als de 24-uurs gemiddelde buitentemperatuur boven de stookgrens uitkomt deze formule altijd op 0 uitkomt, en niet negatief wordt.
Als laatste is de "factor" de hoeveelheid extra energie (bijv kWh) die je bij iedere lagere graad buitentemperatuur nodig hebt.

Voorbeeld van mij: Ik heb (gemiddeld over de 365 dagen gemiddeld) een stookgrens van ~15 graden, en een "factor" van 0.24 kuub gas per graad lagere buitentemperatuur. Dat is te zien in onderstaande grafiek. Hierin is de 24-uut-gemiddelde hoeveelheid gas uitgezet tegen de 24-uur-gemiddelde buiten "gevoelstemperatuur" (JAG/TI methode). Hierin zie je dat ik bij -22 buitengevoelstemperatuur (dat is ongeveer -10 graden met 15m/s wind) ongeveer 8.8 kuub gas zou moeten gebruiken. (die blauwe lijn rolt uit mijn eigen algoritme)
[Afbeelding]

Effectief is dit gewoon jouw formule voor #Doeltemp, maar ik heb hem gebaseerd op het idee van het graaddagen model, en ik baseer hem op gevoelstemperatuur, want ik zag dat de grafiek dan veel "rechter" is, en omdat je dan een grote invloed van wind ook indirect meeneemt.

Zelf ben ik van plan om het stookalgoritme op de 24-uurs gemiddelde weersvoorspelling te laten lopen, dus niet op de "instantane" buitentemperatuur of van de afgelopen 24 uur. Ik dacht ergens gelezen te hebben dat jij dat ook had, maar ik zie het hier in je topic even niet terug.

Doeltemp correctie

Hier begint het interessante stuk pas . Je hebt nu een vrij simpele correctie: Een "proportionele" actie, dus je correctie hangt alleen af van de huidige temperatuurfout. Je kan eens kijken naar het concept "PID regelaar". Die heeft naar dat proportionele deel "P", ook mogelijkheden tot "I" en "D" acties. De "I" actie is eigenlijk een "historie" actie, dat kan je zo zien: Als je 3 dagen lang steeds 0.5 graden achterloopt dan zegt jouw correctie nogsteeds maar +2 graden. De I-actie is eigenljk een "tellertje", hij houdt de opgetelde fout bij van de volledige historie (de Integraal, vandaar "I"). Dus als je 3 dagen achterloopt dan loopt die I-actie al 3 dagen lang op, waardoor je na 3 dagen bijvoorbeeld niet meer +2 corrigeert, maar +3 of +4 (hangt af van hoe "sterk" je de I-actie maakt, dat kan je gewoon instellen).
De D-actie is denk ik niet zo spannend, dat is de "derivative", die dus kijkt naar de "opwarmsnelheid" van je kamer. Maar omdat je niet "snel" wil corrigeren maar juist langzaam is een PI-regelaar (dus met uitgeschakelde D-actie) vaak al voldoende.

Dag-gemiddelde correctie??

Dan had ik zelf nog een interessant aspect op dit topic: Wat gebeurt er tijdens een SWW run van je WP? Dan ben je ineens een half uur of wel 2 uur aan verwarmingstijd kwijt. Die tijd is niet goed te voorspellen (hangt af van hoeveel je douchet die dat en hoe efficient de WP SWW kan verwarmen, dus langer bij lagere buitentemperatuur). Daarnaast nog defrosts, die wat tijd afsnoepen van je verwarming.

Wat er dus kan gebeuren is dat je de ene dag 18 uur aan het verwarmen bent (5 minuten per uur defrost, 5 minuten het "verlies" van je defrost inhalen, dat 24 keer per dag, en dan nog 2 uur SWW), en de andere dag 23 uur (alleen kort SWW). Je zal dus eigenlijk op die dag dat je 18 uur verwarmt een hogere watertemperatuur moeten aanhouden dan de dag van 23 uur, nog buiten het verschil wat komt uit buitentemperatuur.

Wat mijn idee dus was: Meet terug wat de "gemiddelde aanvoer-watertemperatuur van afgelopen 24 uur" is, en corrigeer je #Doeltemp daarop. Als je dus 2 uur lang SWW hebt gedaan dan is je 24-uurs gemiddelde even iets "ingekakt". Je wil dan mogelijk een paar uur even +2 graden extra hoog stoken om hem weer te corrigeren. En wat gebruik je daarvoor?? PID regelaars YAY . Deze zet je dan waarschijnlijk wat "aggressiever", zodat hij wat sneller optoert in zo'n situatie van 2 uur SWW. Dat "aggressief" hoeft echt niet heel erg te zijn, maar typisch wel veel sneller/aggressiever dan de binnentemperatuur PID.

Dan krijg je wat op de wiki pagina ook wel "Cascaded control" genoemd wordt. Dit is eigenlijk gewoon cascaded control, maar dan op binnentemperatuur waarvoor je maar langzaam corrigeert, en de aanvoertemperatuur waarop je sneller corrigeert.

Zelf ga ik dit heel circus dus uitvoeren op mn gasketel met OTGW, maar de essentie blijft gewoon gelijk.

---

Sorry als ik super onduidelijk ben, ik vind dit gewoon heel interessante materie en spar er graag over met mensen!

Intressant. Ik hoop dat je wat ervaring en eventueel wat uit HA wilt delen als je zover bent. HEt mechanische en elektorinsche aansluiten vind ik minder spannend als dat instellen in HA

[Jpiek]

Kevin1990 schreef op donderdag 30 oktober 2025 @ 14:42:
[...]

En ik begreep je verkeerd ik dacht dat je met de temperatuur verhoging de kamer temperatuur bedoelt maar je bedoelt de doeltemperatuur van het water?

Ja, klopt je past de temperatuur van het water wat door je verwarminsgsysteem loopt aan.

[nairolf]

Kevin1990 schreef op donderdag 30 oktober 2025 @ 14:43:
[...]


Intressant. Ik hoop dat je wat ervaring en eventueel wat uit HA wilt delen als je zover bent. HEt mechanische en elektorinsche aansluiten vind ik minder spannend als dat instellen in HA

Ik deel het graag, maar ik doe alles in slakkenstand en ben eigenlijk nog niet echt ergens..

Maar hier is het te zien:
https://github.com/FlorianOosterhof/HomeAssistantConfig

Ik ben begonnen met alleen maar data analyse uit wat de OTGW en P1 meter me aanleverden.

Eerst wilde ik snappen hoe mijn thermostaat werkt, dus ik ben gaan kijken om te zien of ik er PID-gedrag in kon vinden. Na maanden prutsen een PID-implementatie voor elkaar gekregen in HA templates (maar achteraf niet meer tevreden mee), en gevonden wat de parameters zijn die 99% van de tijd goed weergeven wat de thermostaat doet. Yay nu begreep ik wat de thermostaat dacht!

De combinatie van de P1 meter (DSMR 5, dus iedere 5 minuten gas reading) en OTGW heeft me laten inzien dat ik mijn gasverbruik goed kan splitsen tussen CV en SWW, door te kijken naar de tijd die de "flame on" sensor aan staat, en de verhouding daarbinnen van "ch on" en "dhw on" gedurende het 5-minuten interval tussen 2 gas-readings, en het gasverbruik dan gewoon proportioneel te splitsen. Dat levert me 2 sensoren op die het CV-gasverbruik en SWW-gasverbruik zijn, waardoor data-analyse van CV-verbruik "cleaner" werd. Dit was april 2024 eindelijk af na wederom maanden prutsen met home assistant templates.

Toen dacht ik dat ik die nieuwe sensor naar MinderGas.nl wilde uploaden, maar al snel was me duidelijk dat MinderGas.nl niet het detail aangaf wat ik wilde. Dus ik ben een eigen dashboard gaan maken dat het langetermijn overzicht van gasverbruik vs temperatuur aangeeft. Maar daarvoor moet ik wel de buitentemperatuur weten. Dus ik heb de KNMI API bekeken en in templates gezet. Dit was in Juli 2024 eindelijk een beetje af, inclusief importeren van historisch gescrapete data van KNMI om de HA database te vullen.

Daarna was ik van mening dat de rekemethode van MinderGas.nl (die ik ook in mn dashboard had) niet naar mn wens was, dus ik heb een eigen algoritme ontwikkeld (degene die die blauwe lijn uit mn vorige screenshot fit). Maar dat moest natuurlijk eerst helemaal wiskundig uitgeplozen worden (daar ligt mijn scholing), dus ik heb in een paar maanden een heel noteblok volgekrast tot ik de oplossing vond, en in Januari 2025 was die implementatie eindelijk klaar in het dashboard.

Daarna een hele tijd zitten fine-tunen aan dat dashboard omdat ik toch net niet helemaal het inzicht kreeg wat ik wilde. Uiteindelijk besloten dat de windsnelheid mee moest doen. Maar het algoritme krijg ik maar niet ver-algemeend dat hij 2 inputs kan pakken per punt (temp & wind) (ik krijg het gevoel dat dat niet zomaar kan), dus uiteindelijk besloten dat de JAG/TI methode voor gevoelstemperatuur maar moest volstaan, waardoor het eerdere algoritme gewoon werkt (want weer 1 input: gevoelstemp, die wel bestaat uit die 2 inputs gecombineerd). Dus voor windsnelheid ook een KNMI template sensor gemaakt, en historie geimporteerd. Dit was pas weer September 2025 klaar (na nog een heel noteblok volgekrast te hebben voor dat algoritme, zonder succes deze keer dus).

Daarna gekeken of ik een relatie kon vinden tussen de 24-uur gemiddelde CV-temperatuur en het gasverbruik. Dat was verrassend correlerend: Vrijwel exact lineair: 24-uur gemiddelde CV-temp gemeten bij vloerverwarming verdeler is bjina perfect lineair met het aantal kuub gas in die 24 uur. Samen met graaddagen maakt dat een stooklijn!

Daarna side-project: mechanische ventilatie aanleggen en slim maken. Dit ging verrassend soepel (ESPHome is veel makkelijker dan HA templates!!!!), dus daar was ik met 2 weken klaar mee.

En nu weer terug naar verwarming: Ik heb dus eigenlijk nog niks behalve gas-splitsing, real-time KNMI data en heel veel data analyse.. Het geeft wel een automagisch bijwerkend inzicht in mijn persoonlijke parameters van het graaddagen model, dat is wel fancy. En ik heb ook vastgesteld dat ik het echt wel beter weet dan mn thermostaat.

Maar nu moet ik de regeling nog daadwerkelijk maken. Gezien ik niet tevreden was met de PID implementatie in templates, ben ik nu bezig hem nogmaals te maken in python_script, welke ik dan vanuit templates aanroep. De template is dan alleen voor de trigger(s) & het aanmaken en invullen van de sensoren, alle logica komt in het python_script terecht. Daar ben ik nu een beetje mee bezig, duurt waarschijnlijk nog wel paar maanden voor hij naar mijn zin is

Zodra dat erin zit kan ik vrij snel (lees: binnen een paar weken) de 2 PID regelaars aan elkaar knopen en naar de OTGW sturen. Dan is daarna mn thermostaat een veredelde thermometer, maar wel een belangrijke!

Dus.. ik deel graag met je, maar verwacht er voorlopig niet teveel van.. Al kan je misschien wel al naar al mn template spullen kijken als je wil..

offtopic:
en weer sorry voor mn boekwerk. Ik kan echt wel kort en bondig zijn, zie hieronder

---

Jpiek schreef op donderdag 30 oktober 2025 @ 12:50:
@nairolf

Ik heb deze flow (zo heet dat in Homey) al een tijdje lopen, sinds half januari vorig jaar.
Ik ben IT-Engineer, geen programmeur en al helemaal niet thuis in verwarmingstechniek, maar op alles wat mijn interesse wekt volgt meestal een leaningcurve die veel gelijkenissen heeft met de kliffen van Dover

Doorzetten! Op die manier kennis opdoen is het leukste!!

Mijn Doeltempcorrectie is in werkelijkheid wel heel wat gecompliceerder dan hier weergegeven, zoals ik het hier heb beschreven is meer om de achterliggende redenatie te beschrijven.

Ah oke. Care to elaborate?? Ben benieuwd!!

De WP hangt in een huis uit 1959, houten vloeren, geen VVW en dus ook niet veel massa waar je warmte in kunt bufferen. Er is wel (door mij) veel gedaan aan isolatie. Maar ik heb al wel gemerkt dat een reactief systeem beter werkt.

Ohja, wederom al gelezen.. Maar in dat geval zal je kamertemperatuur ook veel directer de watertemperatuur "volgen", waardoor die 2e PID mogelijk helemaal niet nodig is voor het stukje "off-time compensatie" (zoals SWW).

Daarnaast zit ik ook wel een beetje met de beperkingen van de manier waarop je flows bouwt in Homey, dat is toch wel heel anders dan een script in HA. Je unts scripts bouwen in/voor Home, maar da's mij nog teveel boven mijn pet. Advanced flows maken voor mij wel heel inzichtelijk wat de flow precies doet.

Ik ben wel nog steeds de flow aan het fine-tunen en zit normaliter meestal strak op een Doeltempcorrectie van 0, wat betekend dan mijn Doeltempberekening aardig spot-on is

Netjes, dat is natuurlijk het doel! Een goede feedforward ("voorspellend" stoken, dus op huidige of komende temperatuur) maakt (bij verwarming in ieder geval) feedback (reageren op kamertemperatuur) bijna overbodig! Maar ik vind het zelf wel een fijn idee om dat er toch wel in te hebben..

SWW gaat niet via de Warmtepomp, ik heb een Electrische Duo boiler hangen (en het zal je niet verbazen) die aangestuurd wordt met Homey en een sussenschakelaar op de nacht/dalstroom aansluiting en alle teruglevering wegsnoept, pas eind van de dag/avond vult hij dat met netstroom aan.

Ah dat maakt het ook een stukje simpeler ja!

offtopic:
wat is die Duo boiler waar je het over hebt?

Ik heb overigens ook een 'Defrostdetectie' die bv alle fans op de radiatoren uitzet, en na de Defros idd even de Doeltemp een boost geeft om terug op target te komen.

Klinkt leuk! Heb je HeatMeisters daarvoor? Of van die "fabriek-af" dingen?

[Jpiek]

nairolf schreef op donderdag 30 oktober 2025 @ 21:31:
[...]
Doorzetten! Op die manier kennis opdoen is het leukste!!

Absoluut, ik ben nogal autodidact met dergelijke dingen. En meestal knal ik van Novice/N0ob naar Ervaren of zelfs Specialist in hele korte tijd.

't leuk, handig, maar soms best wel belastend... Beetje combi ADHD en Autisme...

Ah oke. Care to elaborate?? Ben benieuwd!!

Dan moet ik dat als screenshot delen, een Advance flow kan je helaals niet zo goed tekstueel delen.
Ik weet niet of je de Flows van Homey kun lezen ? (lukt vast wel )


Ik heb als boiler een Itho-Daalderop Duo 80 liter hangen. Ben express niet voor de 'Green' versie gegaan, die doet hetzelfde maar dan met een eigen kastje, maar gaat dan de rest van mijn Homey flows in de weg zitten...
Als fans heb ik 4 Heatfans (te koop bij elke DHZ) per twee op 2 radiatoren (Logeerkamer/rommehok BG) en in de Woonkamer, verder 2 'CLIMATEBOOSTER Convector Pro Canal set 2' van de Hornbach op/in de convectorput achter in de woonkamer/serre.

We hebben aan de achterzijde van het huis een 5*2 meter serre met schuifpui en glazen dak. Dat was best een uitdaging, heb eerst getest met een paar enorme ali-fans met regelbaar toerental :



De CLIMATEBOOSTER 's hebben echter 2 temp sensoren en regelen toerental zelf...

[Jpiek]

Dit is een deel van de flow, alleen de Doeltempcorrectie obv gemeten ruimtetemperatuur..