hallo
Ik ben al een tijdje bezig met homey pro 23.
Nu loop ik soms wel is tegen dingen aan dat ik denk volgend mij kunnen flows beter of gestroomlijnder.
Hopelijk kunnen jullie mij helpen of dit nou een beetje een juiste manier is?
Of dat dit soort flows beter kunnen?
Zal er een voorbeeld bij doen en ben dan ook nieuwschierig naar hoe jullie dit zouden doen?
Dank alvast.
Het ziet er goed uit. Als je flow goed werkt, dan niets doen.
Echter, ik heb moeite om het eerste deel van de flow te begrijpen en dat heeft te maken met de 2 variabelen:
Als ik dus de eerste twee flows even oversla, dan kun je:
).Hieronder als voorbeeld een flow die ik recent voor iemand heb gemaakt. De structuur is waar het om gaat: in de centrale logica is de volgorde van de kaarten belangrijk.
Deze variable word op yes gezet nadat s’ochtends de rolluik open gegaan zijn.
Dit is een hele goeie van je. Ik had niet eens gezien dat deze dan nooit gaat werken om 22:00.
Ik heb er de tijd van 11:00 uur aan gehangen. Dit omdat de rolluiken in het weekend bij dochter lief pas helemaal open zijn om 11:00 uur.
Ik ga is kijken hoe ik dingen makkelijker kan samenvoegen.
Ben vrij nieuw en dus ook voornamelijk aan het stoeien met de flows.
Vanuit mijn logica wat vragen/opmerking over jouw flow:
In de And ga je alleen verder met temp < 23 en daarna nog < 25.
Dus de flow start alleen als je bepaalde ‘wisselmomenten’ bereikt. Al deze 4 kaarten zijn denk ik te vervangen door een kaart ‘Als temperatuur verandert’ (?). Gaat alleen de flow vaker af uiteraard maar is dat erg?
En alleen bij >25 is het van belang dat iemand thuis is. Ben benieuwd naar reden van dat verschil 
Iemand kan dus theoretisch thuiskomen als temp = 30 en pas bij thuiskomst wordt 100% gedimd.
Goede punten idd.
Het was een voorbeeld van een structuur meer dan een precieze Flow.
Is meestal niet verstandig: de T moet worden aangepast om een Flip flop te voorkomen, bv van 22.5 en 23 etc. Echter er zijn (apps om) temperatuursensoren periodiek (elke 5 min) te laten rapporteren en dan hoef je hier verder niets te doen.
“Als de temperatuur verandert” is niet efficiënt, dan worden alle tests de hele tijd nodeloos uitgevoerd.
Aanwezigheid had ik toegevoegd zoals OP dat had. Heb ik verder niet over gevraagd.
kan je een naam geven van die app(s) om de temperatuursensoren om de zoveel tijd te controleren.
Elke keer dat Homey een nieuwe temperatuur ontvangt moet deze verwerkt worden, en dus ook getest worden. Door het systeem of in je flow. Het is niet zo dat als de temperatuur de grens niet bereikt er niets gebeurd in Homey.
Ik denk dus dat het niet zoveel kwaad kan om “Als de temperatuur verandert” te gebruiken.
In Advanced Triggers kun je de debounce (ontstuitering) optie gebruiken.
Zie onder met als voorbeeld een debounce van 10 sec.
@Rmb
De temperatuur kan elke paar seconden veranderen, bijvoorbeeld wanneer hij per 0.1C wordt gemeten. Dan is Homey dus bijna constant aan het werk om alle extra condities die in de flow volgen te verifieren.
Wanneer je een aantal flows zo ontwerpt, dan wordt de responsiveness van Homey traag voor andere flows waar het belangrijk is. Bijvoorbeeld een bewegingssensor die een lamp aan moet doen onder bepaalde condities.
Door de juiste grenscondities (zoals in het eerdere voorbeeld aangegeven) in te stellen, minimaliseer je het extra werk voor Homey.
Als je Advanced Triggers met debounce gebruikt is dat iets meer overhead, maar bespaar je nog steeds veel extra werk voor Homey.
Het nadenken over de consequenties en het gebruik van deze logica helpt enorm om de system load van Homey terug te brengen.
Ik heb de 2 volgende situaties in gedachten om te vergelijken:
WANNEER temperatuur verandert
EN temperatuur is groter dan 20 graden
DAN etc..
WANNEER temperatuur groter wordt dan 20 graden
DAN etc..
Dan komen de extra condities die in de rest van de flow volgen in beide flows even vaak aan bod.
Het is natuurlijk mogelijk om alle condities in een advanced flow parallel te zetten. Dan nog hoeven ze niet allemaal uitgevoerd te worden om het benodigde resultaat te bepalen. Zolang er geen hoge CPU belasting is, zou ik me er niet zo druk om maken. En soms heb je ook geen keus omdat de desbetreffende kaart er niet is.
@Rmb In je nu aangepaste voorbeelden heb je gelijk. De extra EN test is minimaal (maar zal nog steeds elke 0.1C kunnen plaatsvinden).
Het idee was om de OP duidelijk te maken waarom zijn flow niet werkte en een voorbeeld te geven van een duidelijk logisch flow ontwerp met een idee waarop te letten om de flow efficient te houden. Voor beginners kan dit het begrip verhogen.
Zoals je boven kunt zien, had ik het over een advanced flow waarin een aantal (niet slechts 1) condities volgen op de trigger Als De Temperatuur verandert. Daar de volgorde van deze condities vaak belangrijk is, zal de gebruiker erop moeten letten en niet nodeloos tests door laten lopen
De discussie die wij tweeen nu in deze thread hebben is overduidelijk en draagt mijns inziens niet echt meer bij aan het inzicht.
Bovendien kan ik weinig met jouw stellingen:
Bovenstaande stelling helpt niet, neemt aan dat iedereen dit wel checkt, neemt aan dat het allemaal wel goed komt.
Geen idee wat je hiermee bedoelt: als de kaart “WANNEER de temperatuur groter wordt dan x graden” er niet is, dan zijn er verschillende manieren om het op te lossen, waarvan een reeds aangegeven: Advanced Trigger.
