Flow vereenvoudigen

[JohanP]

Ik wil de flow van een flow vereenvoudigen…

Ik heb een Flow die de doeltemperatuur van mijn warmtepomp bepaald en aanstuurt.

Hiervoor bereken ik een temperatuur adh van de buitentemperatuur en zet die in een variabele, die stuur ik met een commando (verplicht) minimaal eens per minuut naar mijn warmtepomp. In pricipe vrij simpel, echter :

Er zijn een aantal zaken waardoor ik een correctie wil uitvoeren op die doeltemperatuur :

1 Invloed van de zon (op basis van opbrengs panelen)
2 de kamer temperatuur is hoger dan de ingestelde kamertemperatuur
3 de kamer temperatuur is veel hoger dan de ingestelde kamertemperatuur
4 de kamer temperatuur is lager dan de ingestelde kamertemperatuur
5 Als de WP uitslaat vanwege 1 dan wil ik ca 1,5 uur voor zonsondergang de doeltemperatuur tijdelijk verhogen en nog wa profijt hebben van de opbrengt panelen (voorverwarmen dus)

Voor 1 t/m 5 heb ik dus routines geschreven die goed werken.
Alleen moet ik die dus allemaal achter elkaar uitgevoerd worden waar dan uiteindelijk een correctie (plus of min) uitkomt die ik verreken met de berekende doeltemp.
Vervolgens gaat de Flow verder met het sturen van de doeltemp.

Dit wordt echter een gruwelijk lange string van EN kaarten met ALL en ANY, en opsplitsingen, waarbij de Flow op GEEN ENKELE kaart dood mag lopen.
En dan laat ik een error uitkomst eigenlijk nog buien beschouwing (dan springt de verwarming maar terug op de Thermostaat helaas).

Het is ondanks alles een heel ingewikkelde Flow met heel veel lijnen geworden.
Ik heb getracht deze op te splitsen : “Stuur doeltemp elke 59 seconden” en “Bereken doetemp” of
“Bereken correctie” en “Bereken doeltemp met correctie en stuur deze elke 59 seconden”, maar ze lopen toch mis. Doeltemp wordt gestuurd terwijl correctie nog berekend wordt, of correctie loopt ergens vast en de uiteindelijk gestuurde Doeltemp is veel te hoog of te laag.

Hoe kan ik bij voorkeur, alle correcties uit laten voeren in een enkele Flow op een Adv. Flow Canvas en vervolgens de doeltemp berekenen en versturen zonder dat het allemaal één lange string moet worden ?

[OH2TH]

Welkom op het forum

Dit topic is verplaatst naar het Nederlandse deel van het forum, graag je aandacht voor het kiezen van de juiste categorie/taal.

Wanneer je problemen hebt met de Moderatie acties neem dan gerust contact met mij of een andere moderator op via een Prive bericht.

[Theo_de_Koning]

Mijn eerste gedachten bij proberen het te begrijpen.

Die “elke 59 seconden” geeft mij dat je heel precies wilt werken. (Voor een flow maakt het niet uit.)
Dan komt ik bij punt 5 nog extra opbrengst halen waar vergeet te zien of er dan geen bewolking is.
Je temperatuur gaat dan misschien teveel zakken.
Zelf heb ik geen warmtepomp maar dacht wel ergens gelezen te hebben dat je die zo constant mogelijk moet laten draaien. Het verhogen van de temperatuur zou lang duren.
Dan moet je dus ook rekening houden met de buiten temperatuur.

Zelf ben ik soms ook weleens opnieuw moeten gaan kijken omdat een flow te ingewikkeld werd.
Je hebt dan al wel een soort praktijk ervaring.

Lijkt mij wel een leuke klus dit.

[JohanP]

@Theo_de_Koning

Mijn eerste gedachten bij proberen het te begrijpen.

Die “elke 59 seconden” geeft mij dat je heel precies wilt werken. (Voor een flow maakt het niet uit.)

Die 59 seconden komt voor uit een beveiliging in de OTGW firmware, als je niet elke 60 seconden een ‘update’ stuurt wordt de controle weer overgedragen aan de thermostaat.

Alles heel veel korter dan die 59 seconden is eigenlijk een beetje zonde, je wilt geen verwarming die elke 30 seconden een andere doeltemp voor het CV water krijgt, al is het nog zo mimimaal.
Ik heb wel geëxperimenteerd met elke 3 minuten een nieuwe doeltemp berekenen en elke 59 sec updaten, met dus ook genoemde timingsverschillen.

2 flows tegelijkertijd starten ‘Elke 59 seconden’ werkt ook niet, de berekening is langer dan het sturen van 1 commando. dat gaat zelfs op milliseconden blijkbaar nog fout..

Dan komt ik bij punt 5 nog extra opbrengst halen waar vergeet te zien of er dan geen bewolking is.Je temperatuur gaat dan misschien teveel zakken.

Het gaat me niet inhoudelijk om de Flows, dat lukt wel. Ik ben al bezig om te finetunen, dat ‘voorverwamen’ heetf ook een aantal voorwaarden in een EN (Buitenmperatuur, huidige water temperatuur en idd de opbrengst van de PV)

Zelf heb ik geen warmtepomp maar dacht wel ergens gelezen te hebben dat je die zo constant mogelijk moet laten draaien. Het verhogen van de temperatuur zou lang duren.
Dan moet je dus ook rekening houden met de buiten temperatuur.

Gebeurt ook, ik heb overigens een WP met Probaan, die kan veel hoger temperaturen aan. verwarmen kan ook best heel snel, alleen staat hij dan met +2300W te loeien. dat moet je niet willen.

Zelf ben ik soms ook weleens opnieuw moeten gaan kijken omdat een flow te ingewikkeld werd.
Je hebt dan al wel een soort praktijk ervaring.
Lijkt mij wel een leuke klus dit.

Ja, het begin hel simpel, en dan moet/wil je op dit en op dat bijsturen en dan moet je dat toch weer ergens corrigeren. Je wil idd de WP zoveel mogelijk op eenzelfde maar zo lag mogelijk vermogen laten pruttelen, maar het moet ook niet te warm of te koud worden in huis..

Het is geweldig om te doen, idd, maar je komt echt in en lijnenspel uit waar menigeen echt de kriebels van krijgt. Heb zelfs soms zoiets van 'Heb ík dit geschreven (en het werkt ook nog ) ).

Daarom wil ik kijken of ik elke ‘invloed’ een eigen soort van onafhankelijke subroutine kan geven, wat dan na alle berekeinigen samenkomt in 1 uiteindelijke Flow/commando die de WP aanstuurt.

Eigenlijk mis ik dus een “Goto” om overal aan het einde van een Flow te kunnen hangen.

Vroegáh, had je in Dos batchfiles en kn je idd met Labels en “Goto” routines maken..
Mijn Flow werkt, het moet alleen hanteerbaarder worden.

[FKey]

@JohanP

Doeltemp wordt gestuurd terwijl correctie nog berekend wordt,

Ik heb dat opgelost met een “all” functie.
Alleen als alle berekeningen voltooid zijn wordt de doeltemperatuur gestuurd.

Om te voorkomen dat hij vastloopt kan je evt een 2e “all” maken met als ingang de error.

Om een flow te versimpelen begin ik meestal met het opknippen in kleine functionel blokken. (Maar daar was je al mee bezig zo te zien)

[FKey]

@JohanP

Voor 1 t/m 5 heb ik dus routines geschreven die goed werken.
Alleen moet ik die dus allemaal achter elkaar uitgevoerd worden

Als ik het zo lees zou ik deze juist allemaal onafhankelijk van elkaar uitvoeren.
(En samen laten komen in een “all” functie)
En daarna op de uitkomsten logica zetten

[JohanP]

De flow is wat gecompliceerder dan dat, de totale correctie is een som van 1 t/m 4.
Ik zal de flow eens posten… (Als ik die passend krijg, wellicht als geprint naar PDF)…

Als we beide met iets soortgelijks bezig zijn kunnen we elkaar wellicht helpen…

[JohanP]

Ok, bij deze de hele flow.

Variabelen en Tags :

oo_OTGWDoeltemp=Doeltemp water die naar de OTGW gestuurd word

oo_OTGWRekentemp=berekende buitentemp (van 2 sensoren, of 1 als er een uitvalt, of Homey Weathertemp als beide niet werken, De flow wordt uitgeschakeld als die het ook niet doet en verwarming gaat naar Thermostaat) Hier is een aparte Flow voor

oo_OTGWDoeltempCorrectie=berekende correctie op Doeltemp

fo_Defroststatus=tekstvariable met informatie of de WP bezig is met een defrost (Ontdooicyclus, WP gaat uit, warm water in het systeem wordt gebruikt om de WP te ontdooien) Hier is een aparte Flow voor om deze te detecteren, er is geen Tag voor…

#Vermogen=opbrengst PV

#Temperatuur=Kamertemperatuur van eTwist Thermostaat

#Ingestelde temperatuur=Ingestelde temperatuur van eTwist Thermostaat

#Brandermodulatie=Tag van OTGW om te zien of de WP actief is : in percentages

De blauwe lijn rechts gaat verder in de rechtse lijn hieronder:

nb álle lijntjes komen hier rechts (buiten beeld) op 1 ANY uit en gaan hieronder op die ene lijn verder :

Diverse gegevens worden verzameld en komen in een AVD :

en die toont dit:

Opsomming :

-Bereken doel temp

• Corrigeer op opwarming door de zon adh van opbrengst panelen (berekening functioneert en klopt!)

• Booster timer loopt: Tijdelijke verhoging van de watertemp ‘omdat het fris is in huis’ of omdat er net een Defrost heeft plaatsgevonde, dus ff snel water terug op temperatuur brengen (berekening functioneert en klopt!)

• De ingewikkeldste : Als kamertemp hoger dan ingesteld op de thermostaat én de buitentemp is meer dan 12 C zet ik de watertemp op 20 C (corectie is doeltemp-20 = 20C)en de WP gaat uit * Idem als de kamertemp meer dan 24 C wordt. Idem als de kamer temp onder de 24C is en de WP is al uit (voorkomt pendelen).

• Als kamertemp hoger dan ingesteld op de thermostaat én de buitentemp is minder dan 12 C verlaag de doeltemp met tempertuursverschil *1,5

• Als kamertemp lager dan ingesteld op de thermostaat verhoog de doeltemp met tempverschil *2

• ZonOnderOver: Timer loopt vanaf 120 Min voor zonsondergang (kon geen 90 min kiezen). Als deze nog 90 min resttijd heeft zet ik de doeltemp op 25 C als de timer nog 60 minuten heeft op 30 C en als hij nog 30 min heeft stop ik de voorverwarming. Vorwaarde: doeltemp is lager dan 30 C, buitentemp is minder dan 20 C maar hoger dan 13 C (verwarmen is ws niet nodig op een zomeravond en op een koude avond heeft de berekende doeltemp voorrang) en er moet minimaal 800 W opgewekt worden (wat de WP ongeveer gebruikt om 30 C water te maken).

Het totaal van al deze correcties word opgeteld bij de doeltemp (doeltemp plus negatief getal is minus)…
Doeltemp wordt naar de OTGW gestuurd…

[Theo_de_Koning]

Knap stukje werk.
Het is wel lastig om het goed in te voelen.
Met zoveel parameters wordt het gauw een grote flow.

Pendelen voorkomt ik met een timer.
Dat voor beide toestanden.
Jij gebruikt Zandloper dat moet dus wel lukken.

Wat betreft “ZonOnderOver” daar kom ik nu niet boven de 60 Min.
Daarom gebruik ik de Zonnestanden app.
Wel heb ik nu toch even, na een tip, een test gemaakt om een variabele met 90 in een tag te gebruiken.
Zie het resultaat morgen.

[JohanP]

vandaar: inhoudelijk werkt het allemaal. Ik zou alleen individuele sub-routines er van willen maken. Dat werkelijk elke ‘uitgang’ van een kaart verbonden moet zijn maakt het geheel een stuk ingewikkelder.

OTOH, er is niemand die deze flow aan gaat passen behalve ik zelf

[Theo_de_Koning]

@JohanP

Ik zou alleen individuele sub-routines er van willen maken.

Het enige wat een beetje of sub-routines lijkt zijn deel flows op eigen canvas die je steeds start.
Je mis dan wel het overzicht.

@JohanP

Dat werkelijk elke ‘uitgang’ van een kaart verbonden moet zijn maakt het geheel een stuk ingewikkelder.

Voor mij juist niet want anders zou kaart 3 voor bijna alles 2 x gemaakt moeten worden.

1. Met alle JA uitgangen.
2. Met alle NEE uitgangen.
   Het wordt er niet overzichtenkijker van.

[JohanP]

OP het derde plaatje zou dan alle ‘Nee’ gewoon daar op kunnen houden. En de ‘Ja’ na de laatste 2 kaarten ook.

Alle uitgangen leiden immers naar "Stuur Doeltemperatuur en stel status in’.
En daar kan ik geen aparte flow van maken wat die zal nog steeds pas gestart kunnen worden als alle flows gelopen hebben en op hun einde gekomen zijn.

maar als het niet beter word dan dit is het ook goed, dan weet ik dat ik het op de juiste manier heb gedaan.

Overigens zie ik nu al weer een verbeterpunt : Beginnen met de Boosttimer en die meteen naar "Stuur Doeltemperatuur en stel status in’. Ik verlaag in theorie eerst de doeltemp met correctie op zonlicht, en dat is raar… Dus die twee ga ik omwisselen…

[JohanP]

Nog een aanpassing ivm berekening rekentemp :

Flow berekenRekentemp start ik elke 58 sec, deze Flow ook, maar ik wacht een seconde : Beide flows starten en lopen simultaan, door de WAIT heeft de Flow rekentemp de tijd (zat) om af te ronden voor de uitkomst daarvan gebruikt wordt…

[rwwh]

Ik stuur de setpoints van mijn lucht-lucht warmtepomp (aka airco) ook op een dergelijke alomvattende manier aan, maar daar heb ik een heel andere flow voor die volgens mij veel meer lijkt op wat je “subroutines” noemt.

Ik heb een aantal hulpvariabelen zoals “comfortverhoging” en “energieprijsverlaging”. Elk van die variabelen wordt uitgerekend niet op basis van de verlopen tijd, maar op basis van geschikte triggers: elk uur wordt de nieuwe dynamische energieprijs bekeken, elke 2 uur de nieuwe weersvoorspelling, als een knopje wordt ingedrukt of de laatste persoon verlaat het huis wordt de comfortverhoging opnieuw bepaald etc.

Ook heb ik een variabele voor het setpoint van elke airco-unit. Die setpoint-variabele wordt automatisch opnieuw uitgerekend als een van de onderliggende hulpvariabelen veranderen.

En als laatste stuur ik —asynchroon van al deze processen— de setpoints naar de units toe. In jouw geval zou je dat elke 59 seconden kunnen doen en verder wanneer een setpoint verandert.

Zo zijn het inderdaad allemaal los getriggerde subroutines die de flow ook behoorlijk goed leesbaar houden. Misschien is dit een alternatieve setup die je zou kunnen overwegen.

[rwwh]

Hier zijn twee delen van mijn flow, als potentiele bron van inspiratie. Het zijn het deel waarin de hulpvariabelen worden gezet, en het deel voor het besturen van de airco in mijn kantoor.

[JohanP]

Lijkt idd op wat ik zou willen. En in het begin ook had.

En toen gingen die bereningen en het sturen van de doeltemp async lopen. De doeltemp werd gestuurd terwijl de berekening niet ‘af’ was.

Vandaar nu een variabele ‘doeltempcorrectie’, wellicht eens kijken of ik dan weer subroutines kan gebruiken…