Advanced Flows

Es führt dazu, nicht “kann”.

Ich bin mir noch nicht sicher, ob ich das auch gut fände. Muss ich mir noch mal Gedanken drüber machen… :thinking:
Auf der anderen Seite haben wir vermutlich eh wenig Einfluss darauf.

Wenn Flow deaktiviert gab’s noch nie. Und mit Wenn Flow aktiviert meinst Du vermutlich die Karte Dieser Flow wurde gestartet, oder:

Diese Karte wurde bei den AF durch den Start-Button ersetzt:
image

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 @DirkG , 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

2 Likes

Ich wollte 6 einzelne Standardflows zu einem AF zusammenfügen. Dabei musste ich festgestellt, dass der AF nicht funktioniert, obwohl ich die 6 einzelnen Flows 1:1 übertragen habe (bis tlw. auf die Benennung der Timer).

Standardflows

Offen

Gekippt

Zu

Advanced Flow

Als Gerät kommt ein Homematic Fenstergriffsensor HmIP-SRH zum Einsatz, der die Stellung des Türgriffes Offen, Gekippt und Geschlossen abfragt und diesen an eine Variable weitergeben soll. Die 2 Sekunden Verzögerung sorgen dafür, dass die Variable OGK_Terassentür_Offen erst dann gesetzt wird, wenn der Griff auch wirklich in der Endposition angekommen ist.

Wie bereits gesagt, der AF funktioniert nicht! @RonnyW, Du als App Entwickler, hast Du eventuell eine Idee woran das liegen könnte? Müsste die Homematic App ggfs. für AFs angepasst werden?

Übrigens, wenn ich nur die zwei zugehörigen Flows in einen AF übertrage, dann funktioniert der AF.

Beispiel

Hi,
sieht alles soweit gut aus. Es ist egal, wieviele Trigger enthalten sind. Der Trigger startet immer seinen “Zweig” innerhalb der Canvas.
Ist denn die Prüfung der Kondition ok? Es wird ja je nach Variale immer nur ein Trigger auch zum Ende ausgeführt.

Ja, die Bedingungen 0, 1 und 2 sind korrekt und auch den richtigen Triggern zugeordnet.
Aber mit der App kann das nicht zusammenhängen?

Du könntest den Timer etwas länger einstellen und in der App prüfen, ob er auch läuft.

Mit den Standardflows läuft der Timer, bei dem AF wird der Timer erst gar nicht gestartet. Hätte ich vielleicht vorher schon erwähnen sollen, sorry.
Deshalb ja meine Vermutung, dass es etwas mit der Homematic App zutun haben könnte, da die Flows überhaupt nicht gestartet werden.

Das wäre merkwürdig. Die Trigger sind ja die selben, egal ob Standard oder Advanced Flow.
Ich würde auch keinen Unterschied erwarzen, ob 1 oder 3 Trigger im Flow vorhanden sind. Jeder Trigger läuft als separater Prozess.
Funktioniert eine Timelineausgabe nach dem Trigger?

Ich habe auch eine Reihe von Flows mit der Chronograph-App mit Advanced Flows erstellt, und auch diese werden nicht immer ausgelöst.
Die Stoppuhr funktioniert.
Ich und noch eine weitere Person, die ebenfalls im Chronograph topic darüber berichtete.
https://community.homey.app/t/app-pro-chronograph-adds-precise-timer-stopwatch-and-transition-functionality-to-homey/18214/204

@RonnyW, @Mike1233, ich habe andere AFs mit 10 oder mehr Triggern inklusive der Chronograph App und die laufen alle ohne Probleme. Deshalb suche ich die Ursache die ganze Zeit bei der Homematic App.

Aber ich werde das mal ausprobieren und die Chronograph App weglassen. Wenn das auch nicht funktioniert, werde ich mich mal an Athom wenden.

@RonnyW, @Mike1233, es liegt nicht an der Chronograph App.

Ich habe testweise folgende Flows erstellt:

Ich erhalte keine Benachrichtigungen in der Timeline, wenn ich den Türgriff öffnen, schließe oder auf Kipp stelle. Im Gerät selber wird der Status aber korrekt geändert bzw. angezeigt:
image

Lösche ich 2 Trigger, erhalte ich bei entsprechender Türgriffposition eine Timeline-Benachrichtigung… :man_shrugging:t3:

Das klingt nach einem Problem von Athom bzw. den Advanced Flows - oder in der App für den Trigger.

Deine Trigger besitzen einen Parameter. Technisch gesehen werden alle 3 Trigger aufgerufen bei einer Änderung am Gerät und die App filtert dann über den angegebenen Parameter, ob der Trigger ausgeführt werden soll oder nicht.
Es könnte also sein, dass Homey nur einen der Trigger aufruft (eher unwahrscheinlich) oder evtl. den “falschen” Parameter dem Trigger übergibt (evtl. immer den gleichen). Evtl. nimmt Athom alle Trigger in innerhalb des Canvas in eine Liste auf und wegen dem dreifachen Trigger wird dieser nur 1x aufgenommen. Dann dürfte der Flow IMMER bei einem Parameter ausgelöst werden. #
Das könntest du mal testen, ob immer eine Variante funktioniert und die anderen beiden nicht.

Das wäre dann eine Supportmeldung an Athom wert.