Advanced Flows

Habe eine Frage wegen den AF.
Wenn man einen AF Flow Testet wird ja bildlich dargestellt wie er ablÀuft und ich finde das das Schalten ziemlich langsam verlÀuft.
Wird der Flow genau so langsam auch im Echtmodus ausgefĂŒhrt oder ist das nur wegen der Übersicht?

Da ist nur, damit man das visuell nachvolziehen kann. In echt lÀuft das so flink wie alle Flows sonst auch.

Wie @RonnyW bereits gesagt hat.

Ich hatte mal einen AF erstellt, in dem zuerst ein Soundboard Sound ĂŒber einen Sonos One abgespielt und im Anschluss eine TTS Nachricht ausgegeben werden soll. Im Testmodus hat das wunderbar hintereinander funktioniert. In der RealitĂ€t wurde beides aber nahezu gleichzeitig abgespielt.

Hallo zusammen, auch an @fantross , der an der Diskussion auch beteiligt war.
Die Frage ist schon etwas Àlter, aber vermutlich immer noch aktuell. Dazu wollte ich zumindest eine kleine ErklÀrung liefern, warum sich der Flow ggf. anders verhÀlt als erwartet.

In diesem Fall sind mehrere Aktionen “nacheinander” geschaltet. Das muss aber erstmal nichts heißen. Der Ablauf hĂ€ngt primĂ€r davon aub, wie die Aktionen in der App programmiert sind:

  • asynchroner Aufruf (die Regel): Dabei wird mit AusfĂŒhren der Karte ein asynchroner Aufruf gestartet (z.B. Sound abspielen, Lampe schalten). D.h. die App schickt einfach einen Befehl an das GerĂ€t und damit ist die Aktion beendet. Wann dann die Lampe tatsĂ€chlich schaltet ist nicht gewiss. Der Sound wird dann auch irgendwann abgespielt - und zwar parallel zum weiteren Flow-Ablauf.
  • synchroner Ablauf (bei RĂŒckgabetoken und auf AdvancedFlow angepasste Aktionen): Dabei “wartet” die Aktionsverarbeitung auf das Ergebnis und beendet die Aktionskarte erst dann. Der folgende Aufruf findet also tatsĂ€chlich nach Abarbeitung der vorherigen statt.

Das gleiche betrifft den aufgerufenen Flow. Der Flow wird asynchron gestartet und dessen Aktionen auch. Es kann also sein, dass die Flow-Aktionen vor der Sondausgabe ausgefĂŒhrt werden oder auch nach Aktivieren der Lampe. Die ersten drei Aktionen (incl. der Flow-Aktionen) laufen also alle irgendwie parallel in ungewisser Reihenfolge ab.

Es wird nur wenige Aktionen geben, die bereits auf AdvancedFlow angepasst sind. Das sind u.a. die Homey-eigenene JSON-Konvertierungen. Die laufen synchron. D.h. die Aktionskarte wartet auf die Verarbeitung und ist erst dann beendet, wenn die Konvertierung abgeschlossen ist und man das Ergebnis als Token im nÀchsten Schritt weiter verwenden kann.

Ich musste das z.B. bei Blink oder der SQL-App auch ergÀnzen.
Beispiel: [APP][PRO] MySQL-Client - #42 by RonnyW
Hier wartet die Aktion “SQL-Befehl ausfĂŒhren” auf das Ergebnis der Abfrage und liefert die Daten als Token zurĂŒck. Die nĂ€chste Karte wird erst danach ausgefĂŒhrt.
Zuvor lief das auch asynchron und nach der AusfĂŒhruing wurde ein Ereignis getriggert.

Bei Aktionen ohne definiertes Ergebnis (Token), sollte man also von einer asynchronen/parallelen Verarbeitung ausgehen. Die Reihenfolge der Verarbeitung ist damit nicht sicher.
Beide Varianten wÀren also identisch:

grafik

2 Likes

Continuing the discussion from Advanced Flows:

Genau, die AsynchronitĂ€t muss einem bewusst sein, hier noch ein nettes Beispiel wie die AF-Visualisierung einen in die Irre fĂŒhren kann:

Hier kann die Alexa Sprachausgabe (2. Karte) etwas trĂ€ger sein als die Abarbeitung des gesamten Flows durch Homey. Somit kann die erste Erhöhung der LautstĂ€rke (1. Karte) durch die Erniedrigung (3. Karte) wieder zurĂŒckgenommen werden noch bevor die Sprachausgabe erfolgt.

Hinzu kommt, dass auch auf der Serverseite (hier Alexa) die von Homey getriggerten Aktionen (selbst wenn parallel ausgefĂŒhrt) zusĂ€tzlich asynchron laufen.

Also sollte man hier gewisse Verzögerungen einbauen.

Im Prinzip schon. Nur kann es sein, dass die Aktionen sich dennoch unterscheiden, wenn z.B. der externe Aufruf (Sound
) selbst nochmal die Wiedergabe verzögert.
Schöner wÀre es, wenn die App bei der Aktion das Ende abwartet und dann erst beendet. Das geht aber auch nur bei Aktionen, die man beeinflussen kann. Aufrufe von externen APIs gehen dann ggf. nicht, wenn die wiederum selbst asynchron arbeiten.

Beispiel-Flow: Berechnung der absoluten Luftfeuchtigkeit innen/außen als LĂŒftungsvorschlag:

Durch den Bastenvorschlag einer LĂŒftungstseuerung bei heise.de habe ich mir einen Flow gebastelt, der mir zeigen soll, ob es sinnvoll ist, zu lĂŒften (speziell KellerrĂ€ume), oder ob man damit nur noch mehr Feuchtigkeit in den Innenraum holt. Vielleicht ist das auch fĂŒr euch interessant.

Dazu wird die Temperaturen und Luftfeuchtigkeit innen und außen prĂŒft. Daraus wird mit einer vereinfachten Formel (hatte ich in einem Loxxon-Forum gefunden) die absolute Luftfeuchte (g/mÂł) berechnet. Macht man das fĂŒr innen und außen, kann man einfach prĂŒfen, wo die absolute LF grĂ¶ĂŸer ist.
Ist die Außenfeuchte grĂ¶ĂŸer, dann wird der Alarm im virtuellen Sensor aktiviert. D.h. dann “nicht lĂŒften!”.

Zuerst habe ich mir zwei virtuelle Sensoren angelegt:
grafik
Außen mit LF und Temp. Die Temperatur ist nur informatorisch. Die Luftfeuchte des virt. Sendors wird mit dem Wert der absoluten LF gesetzt.

grafik
Innen mit LF und alarm_contact

Der Flow reagiert jeweis auf Änderung des Sensors. In der Berechnung werden jeweils die globalen Tags des GerĂ€tes verwendet. Wenn sich der Wert eines der virtuellen Sensoren Ă€ndert, werden die Werte vergleichen und de Alarm entweder aktiviert oder deaktiviert.

Hier ist noch die Formel:
{{100000 * 18.016/8314.3 * Luftfeuchtigkeit /100 * 6.1078 * 10^((7.5* Temperatur )/(237.3+ Temperatur ))/( Temperatur + 273.15) }}

Hier noch der Link zur Quelle der Formel (2. Antwort zur Topic):
https://loxwiki.atlassian.net/wiki/spaces/LOX/pages/1518403635/Absolute+Luftfeuchtigkeit+berechnen

1 Like