Klopt, maar zonder verdere uitleg, excuus dat ik daar verder geen aandacht aan besteed heb.
Overigens ga ik er bij een berekening wel vanuit dat die klaar is zodra de kaart verder gaat…
Ik moest even teruglezen, maar dat klopt @Mike1233 dat had je al eerder aangegeven. Maar het is zó raar, op zijn zachtst gezegd, dat ik niet kon geloven dat “even wachten” de oplossing zou zijn. Er is parallele verwerking opgetreden waar je sequentiële verwerken verwacht. En dan heb je timing problemen waar de app programmeur rekening mee moet houden. Maar misschien kon het in dit geval niet anders?
Als je een computer de volgende opdrachten geeft:
A = 5 +10
Print A
Dan wacht je immers ook niet 5 seconden tussen de 2 opdrachten.
Als je een functie, subroutine, kaartje, subflow aanroept, behoort die functie bij terugkeer naar het hoofdprogramma het resultaat terug te geven. Mocht er een wachttijd nodig zijn, dan behoort dat in die functie te zitten. Of anders goed gedocumenteerd.
Ik heb in de flow met Power aangegeven hoe ik verwacht dat het zou moeten werken.
@Rmb @JohanP Ik bedoel er verder ook niks mee maar ik dat al vaker gehad maar ook niet altijd.
Als ik er dan een kaartje tussen deed van 1 of 2 seconden ging het altijd goed.
En Homey is best snel, maar als hij iets minder snel rekent dan een melding doorstuurt klopt het net niet.
Ik gebruik het voor het berekenen van mijn dagverbruik van de P1 meter. Eindstand - beginstand= dagverbruik. (HP 2019 )Ging eigenlijk altijd goed maar soms niet. Dus ff wachten. 1 of 2 seconden.
Of het voor HP2023 nog nodig is weet ik niet.
Maar misschien dat als je werkt met meerdere kaarten die wijzigen kan het geen kwaad denk ik om even te wachten. Als zou je dat niet verwachten/willen.
1 Like
“Eindstand - beginstand= dagverbruik.”
Ik heb een AVD gemaakt die een veelvoud van dat soort calculatie’s maakt. Van verbruik, teruglevering, opwek panelen en vervolgens het percentage eigen gebruik.
Totaal een stuk of 6 velden in 1 AVD weergeeft.
Die draait al een tijdje, en foutloos, ook op een Early 2019…
De wachttijd kan ik eigenlijk alleen verklaren doordat het data is die opgehaald wordt uit de cloud, een app.
Overigens, als je erbij had gezegd dat het ophalen/bijwerken tijd nodig had, had ik er over nagedacht. Nu heb ik er eigenlijk overheen gelezen…
Ik heb Homey al een tijdje, paar jaar, en heb de flow eigenlijk nooit meer aangepast omdat hef goed werkte. Dus niet meer geprobeerd zonder “wacht” kaart.
Heb ook wel flows mef berekeningen, niet jngewikkeld, waar die extra wachttijd nief in zit. Doen hef ook goed.
Dus ik denk dat flows die afhankelijk zijn van bepaalde tags dat die een kleine wachttijd wel kunnen gebruiken.
Ik zou het toch wel leuk vinden als een Homey expert er eens naar keek.
Want een moeilijke berekening is tot daar aan toe, dat kan wel even duren. Maar de de flow waarmee dit begon was vereenvoudigd:
Wanneer het weeralarm is veranderd noteer dan het weeralarm.
Maw Homey weet dat het weeralarm veranderd is, en toont dan tóch nog het oude weeralarm. Knap hé 
1 Like
Ik heb het hele verhaal niet gelezen, maar klinkt mij als een bug: de flowcard wordt getriggered en pas daarna wordt de waarde in de variabele (tag?) gezet.
1 Like
En onduidelijk dat je de flowtag “New value” moet gebruiken ipv “Huidig weeralarm”.
Nee, de app weet het want die haalt het naar binnen en zet het in de “nieuwe waarde” en naar Homey.
Dit geldt dan ook niet alleen voor het weeralarm.
Vlgs mij is het gewoon de bedoeling dat men de local tag van de triggerkaart gebruikt, zoals ik eerder postte. De local tag kan nl. niet anders dan wél actueel zijn, en moet zonder vertraging via een notificatie te versturen zijn.
Dat klopt. Je moet dan toch na het kaartje “WANNEER het huidige weeralarm veranderd” dan toch een vertraging inlassen, omdat het kaartje “EN het huidige weeralarm is Code rood” test met de tag “huidig weeralarm” en niet met “Nieuwe waarde”.
Dat hoeft een app bouwer niet te doen.
De app gebruiker is zijn eerste doel. Die krijgen het zo snel mogelijk.
Dus via de tag’s uit de trigger kaart.
Gebruikers die een waarde niet gelijk nodig hebben halen deze dan later uit Homey via een tag daar.
De weerdata kan je ook zelf om de 10 minuten ophalen uit een JSON file.
Waarom zou je een waarde ‘niet gelijk nodig hebben’ terwijl het wijzigen van die waarde nu exact de trigger van je flow is ? Oja, er zullen vast voorbeelden te verzinnen zijn maar het is niet het meest voor de hand liggende…
ALS er iets veranderd is wil je weten WAT en WAARIN. En op basis daarvan wil je iets doen. Dat je dan eerst seconden moet wachten is gewoon niet logisch.
IRL is ‘als ik de deur open’ de status ‘deur is open’, en niet pas over een paar sec. want dan stoot ik mijn neus als ik door loop…
1 Like
En dat weet je.
Ik begrijp hier even helemaal niets van.
Misschien kun je script waarmee deze discussie begon in het eerste bericht even nabouwen. Dan praten we over dezelfde script met dezelfde ervaring en hopelijk met wat minder misverstanden.
Alles is met voldoende lezen duidelijk geworden. Ik ga geen herhaling van zetten meer doen.
Feit is dat ‘Huidige weeralarm’ niet meteen het huidige weeralarm aangeeft maar pas na enkele seconden, en als je echt metéén die nieuwe waarde wilt gebruiken je ‘New value’ moet gebruiken.
Alles wat we verder nog zeggen is een herhaling van zetten.
Omdat ik zelf geen alarmen meer uitlees met de KNMI app heb ik alleen op jouw flow gericht.
Daarna even de eerste kaart gekeken hoe dat nu is.
Daar zie ik de twee tag die ik zou gebruiken.
Nu toch even verder gekeken hoe het op mijn manier zou werken.
Helaas kwam het Rode alarm ook niet door de testkaart.
We zien ook hier dat Code rood via de gele lijn de tijdlijn melding geeft.
En als je test op code groen, loopt de flow altijd via de blauwe lijn door. Bij elke waarde die je intypt of eigenlijk 
1 Like
Voor mij is het nu duidelijk waar het fout gaat.
De code wordt niet goed gefilterd.
Ga daarom stoppen met het volgen van dit draadje.
Mijn excuses als ik niet goed ben over gekomen.
Ik denk dat het nu iedereen wel duidelijk is. Fijn dat je de flow even nagebouwd hebt, dat verklaard toch meer dan 1000 woorden. Om met een variant op een bekend spreekwoord te spreken.
1 Like
