Ich arbeite in div. Flows mit “irgendwelchen” Berechnungen bzw. Variablen und Tag-Zuweisungen. An mehreren Stellen habe ich nun das Phänomen, ich berechne etwas oder weise einer Variablen einen Wert zu, um dann in der nächsten Karte direkt im Anschluss mit den neuen werten “irgendwas” weiter zu machen, aber da scheinen die neuen Werte/Ergebnisse noch nicht angekommen zu sein. Erst wenn ich eine Verzögerung von 3-5 sec zwischen den Karten einfüge klappt es. Bis ich darauf kam habe ich mir einen Wolf gesucht und mal wieder an meinen Programmierungen gezweifelt.
Ist dieses langsame verarbeiten normal (es geschieht sowohl auf der Bridge, als auch auf den Pros)… wäre doch ziemlich doof…
zB:
So funktioniert es, ohne die Verzögerungen nur manchmal, oft, kommt aber Blödsinn bei raus…:
Verwenden Sie den lokalen Parameter der vorherigen Karte, der mit dem Fluss angegeben ist. Dann müssen Sie zuerst die beiden Karten miteinander verbunden haben.
ok, hier war mein Beispiel wahrscheinlich schlecht gewählt, weil alles (hier sichtbar) nur “Ziel-Temperatur” heisst. Es sind aber (natürlich) unterschiedliche Zieltemperaturen (vom Radiator, vom RaumThermostat).
Mit der Übergabe von lokalen Tags werden diese Zeitprobleme (besser) gelöst?
Ich werde damit mal rumexperementieren. Allerdings werden (in diesem Beispiel) auch Werte erzeugt, die wiederum in anderen Flows dann sofort als Trigger dienen. Die müsste ich ja irgendwie übergeben? Muss ich mich mal einarbeiten. Danke für den Tip.
Ja, vorausgesetzt, die Flusskarten sind gut implementiert. Wenn ein Fluss ausgelöst wird, weil sich ein Wert geändert hat, kennt Homey den neuen Wert bereits in der lokalen Variablen der betreffenden Triggerkarte. Dieser Wert muss auch in dem entsprechenden globalen Tag gespeichert werden, und das dauert manchmal eine Weile.
Keine garantie
Welcher Tag ist beim Start des Flows nicht aktuell? Die Temperatur des verwendeten Triggers oder die andere Temperatur?
Normalerweise sind die Trigger so implementiert, dass sie bei Änderung dieses Wertes ausgelöst werden. Im dem Moment sollte das Tag der Flpwkarte identisch sein zum globalen Tag des Gerätes selbst.
Ist das nicht der Fall, dann sollte das an den App-Entwickler gemeldet werden. Dann wird ggf. im der App zuerst der Trigger ausgelöst und dann die Capability geändert.
Der Wert des “anderen” Thermostats ist davon komplett unabhängig.
Solche von Dir hinzugefügten Verzögerungen sind bei solchen simplen Flows definitiv nicht notwendig. Also nein, das ist definitiv nicht normal, zumindest nicht bei Homey Pros!
Auch wenn bereits drüber gesprochen wurde, dennoch hier ein Hinweis zum Aufbau eines Advanced Flows: Die Flowkarten immer zuerst miteinander verbinden und dann die Tags hinzufügen, damit auch die entsprechenden Tags zur Verfügung stehen:
@Thomas_Abel, kann es sein, dass das Problem bei Deinen “externen” Homeys festzustellen ist?
Schau mal bitte in den Homey Einstellungen nach wie die Auslastung des Arbeitsspeichers und der CPU-Nutzung ist. Außerdem mal in Developer Tools → System nachschauen, ob einer dieser Infos auf true steht, was nicht der Fall sein sollte:
Ich war in Grömitz und auf der PRO2023 in Grömitz trat das Problem auf. Gleichzeitig trat das Problem AUCH von dort aus auf der Bridge in Büsum (also wohl extern) auf.
Zuhause (also von dort aus gesehen auch “extern”) hatte ich diese Flows, die manuelle Heizkörperthermostatverstellungen verhindern sollen noch nicht installiert.
was auch immer das ist, diese Positionen stehen auf “false” (zuhause, Grömitz(PRO))
Büsum(Bridge) gibt solche Art Angaben nicht aus.
MIT den Verzögerungen ist der Fehler weg… Ich mache mich aber kfr. dran mal mit “Flowinternen” Variablen zu testen (also nicht globale). Vielleicht klappt das dann. Ich denke das System ist in Verbindung mit batteriebetriebenen WAKE-UP Geräten (hier:devolo Heizkörperthermostaten) schlicht zu langsam (evtl. devolosystem oder Homeysystem) oder aber zu schnell, sodass sich irgendwo irgendwas verschluckt.
Da beim HP23 im Grunde alles lokal abläuft, sollte eine solche Verzögerung definitiv nicht vorkommen. Wenn das aber von extern ausgeführt worden wäre, dann hätte der Flow trotzdem keine Verzögerung haben sollen, aber aufgrund von Internet-Latenzen hätte ich mir vorstellen können, dass die Rückmeldung eine gewisse Zeit lang benötigen.
Wie bereits erwähnt kann ich zu der Bridge nicht viel sagen. Ich weiß z.B. nicht, welche Funktionen lokal, und welche auf externen Servern (Athom Cloud) ausgeführt werden.
Diese Einträge können zum Teil einen Rückschluss zulassen, ob der HP23 z.B. durch Spannungsunterversorgung mit geringerer CPU-Taktfrequenz arbeitet, was aufgrund Deiner Rückmeldung aber ja nicht der Fall ist.
Weil Du jetzt den Begriff WakeUp mit ins Spiel gebracht hast, frage ich mich, ob ich/wir das Problem aufgrund der Beschreibung überhaupt richtig verstanden haben. Weil eigentlich berichtest Du von verzögerten Rechenoperationen.
Beschreib mal bitte ganz genau, was Deine Erwartung von dem Flow ist, und was Du als “Verzögerung” wahrnimmst. Wird die Temperatur Ziel-Temperatur am Thermostat selber verändert, oder wird diese z.B. durch einen anderen Flow verändert?
Beispiel: “Wenn dies passiert ist und diese Bedingungen erfüllt werden, dann stell die Thermostat Ziel-Temperatur auf x °C.”
Zwischen welchen Schritten tritt die “Verzögerung” auf?
Ok, diese “Auslastung” ist definitiv nicht ursächlich für das Problem!
Homey Smartphone App: Mehr → Einstellungen → Allgemein → Speicher bzw. Arbeitsspeicher
Ok: Die Situation (beispielhaft für ein Zimmer, mit 2 Geräten, es gibt aber slbe Situation in mehreren Zimmern, zT mit mehreren Geräten)
Devolo Raumthermostat=Wandthermostat und Heizkörperthermostat=Radiator.
Flow 1:
Wenn jemand am Raumthermostat die ZielTemperatur verändert, dann wird durch einen Flow die Zieltemperatur am Radiator auch auf die neue Zieltemperatur des Wandthermostates gestellt.
“OPTISCH” (offenbar) ist das auch sofort der Fall (wenn ich via Homey testweise (bzw. durch Timeline einen Hinweis ausgebe))
Flow2:
Wenn jetzt jemand MANUELL am Radiator die dortige Zieltemp ändert, …
a) dann wollte ich ursprünglich einfach die Zieltemperatur am Wandthermostat ändern und dachte, dann sind ja immer alle gleich. Ich habe auch versucht die beiden Geräte mittels “HOMEY-Gruppen-App” zusammenzuschalten.
Beides klappte nicht (da kam auch immer irgendwas durcheinander - evtl dasselbe Problem), und lt Diskussion hier im Forum habe ich dann die Raumthermostate als Trigger gelassen, Gruppen aufgelöst und die Radiatorregler dienen quasi nur noch als Reaktoren (die sich einfach nach den Wandthermostaten einstellen). Die Radiatoren sollen also nicht mehr bedient werden.
b) Nun kann es ja aber sein dass ein Feriengast sich nicht daran hält (trotz Hinweisen und Warnschildern unw (RTFM)) und dennoch am Radiator die Zieltemperatur verstellt.
Flow3:
Dieser Flow überprüft:
WENN die Zieltemperatur des Radiators verstellt wurde
UND die Zieltemperaturen des Radiators und des Raumthermostates NICHT gleich sind
DANN soll der Radiator wieder auf die vorherige Zieltemperatur zurückgestellt werden.
Durch den Tastendruck und damit die derartige Verstellung wacht der Radiator ja auf und sendet aktuelle Daten.
(Es gibt leider kein WENN Karte : Wenn beliebige Taste gedrückt wurde)
Bis hierhin funktioniert es auch gut.
Aber nun:
Es gibt natürlich mehrere Flows, die noch was mit der Heizung machen (und die das Raumthermostat ändern (woraufhin sich dann ja das Radiatorthermostat durch o.g. Flow) automatisch anpasst.
zB Nachtabsenkung (Homey App), Balkontüröffnung, Verharzungsschutz (1x wöchentlich voll auf und zudrehen der Ventile), Vorheizen (wenn Urlauber angekündigt sind die Heizkörper hochlaufen lassen) und div. anderes…
Auch diese Funktionen funktionieren allesamt erstmal gut, aber unvermittelt wird die so verstellte Einstellung einige Minuten später (WAKEUP Zeit des Radiators???) automatisch zurückgenommen, oder in einigen Fällen sogar mit ganz fremden Temperaturen neu eingestellt.
Inzwischen glaube ich ja:
Wenn die Zieltemp am Wandthermostat verstellt wird schickt er die an den Radiator. Der schläft aber gerade, d.h. dort wird die Temp. nicht sofort wirklich verstellt, aber für HOMEY gilt sie als verstellt. Wenn dann etwas später der RADIATOR aufwacht (Z-WAVE) werden die neue und alte Zieltemperatur miteinander verglichen und da wird wohl schneller verglichen als real eingestellt. So richtig erklärbar ist es für mich nicht, aber augenscheinlich, denn mit den Verzögerungen (5sec) klappt es bislang zuverlässig (bei PRO). Die Bridge zickt immer noch rum (aber seltener…)
Dieses Heizungsthema (Gruppenbildung) hatte Devolo definitiv besser im Griff, als es Homey hinbekommt (bzw. ich es bei HOMEY hinbekomme).
Ich hoffe das war halbwegs verständlich?
Aber ich habe da jetzt soviel Zeit reingesteckt. Ich lasse es jetzt erstmal so laufen, bevor ich noch irgendwann Homey vor Frust wieder ganz rausschmeisse.
Der Timeline Eintrag stammt dabei aber von dem Flow für das Wandthermostat, korrekt?
Durch diese Kombination von Flow 1 und 2 würdest Du im Grunde zumindest einen kleine Schleife erzeugen:
Ziel-Wert Änderung am Wandthermostat triggert den Flow mit dem Heizkörperthermostat
Ziel-Wert Heizkörperthermostat hat sich nach einigen Minuten geändert (Stichwort WakeUp), was wiederum den Flow für das Wandthermostat triggert
Auch wenn dann durch den Logik-Vergleich Ziel-Wert WT entsprich Ziel-Wert HT die Schleife gestoppt werden würde, wäre es keine gute Programmierung.
Möglicherweise hast Du dieses Problem mit Flow 3 selber erzeugt. Möglicherweise, weil ich Deine Flows für Nachtabsenkung, Balkontüröffnung, Verharzungsschutz, etc. nicht kenne. Wenn diese natürlich alle den Ziel-Wert am HT ändern, dann wird Flow 3 getriggert und setzt den Ziel-Wert wieder zurück. Damit das nicht passiert, müsstest Du all diese Flows so aufbauen, dass der Ziel-Wert des Wandthermostats verändert wird, nicht des Heizungsthermostats.
Aber genau deshalb hattest Du vermutlich die Idee mit dem Trigger “Taste wurde am HT gedrückt”.
Nein, so ist es nicht. Wenn der Ziel-Wert am WT verändert wird, wird dieser Wert immer an Homey gesendet und zwischengespeichert. Selbst dann, wenn das HT genau in diesem Moment wach wäre.
Es kann durchaus sein, dass Homey den neuen Ziel-Wert für das HT direkt in dessen Capabilities schreibt/speichert und dieser neue Wert deshalb auch in der Homey (Web) App direkt sichtbar wird, obwohl sich das HT noch gar nicht verstellt hat. Weil entsprechend neu einstellen kann sich das HT erst dann, wenn es aus dem Tiefschlaf erwacht ist und eine Info an Homey “Ich bin wach” gesendet hat. Liegen Informationen für das HT vor, dann werden diese vom Homey ans HT übermittelt. Das HT stellt den neuen Ziel-Wert ein und geht danach sofort wieder in den Tiefschlaf.
Ob die Werte oder Zustände tatsächlich verglichen werden, und abhängig vom Ergebnis Befehle gesendet werde oder nicht, weiß ich leider bis jetzt nicht.
Was eigentlich dagegen spricht kann mit dem folgenden Versuch getestet werden:
– Rollladen vollständig öffnen
– Position in der App und/oder Developer Tools → Devices überprüfen (App = 100 % / DT = 1)
– Flow erstellen mit Aktions Karte “Setze die Postion auf 100 %” erstellen
– Flow starten
Ergebnis: Obwohl der Rollladen bereits vollständig geöffnet ist, also bei 100 % bzw. 1 steht, hört man das Relais des Rolladen-Aktors klicken. Der Befehl “Setze die Postion auf 100 %” wurde also gesendet, obwohl diese Position schon eingestellt ist.
Deshalb füge ich eigentlich immer entsprechende “Prüf-Bedingungen” ein, z.B. "entspricht nicht 100 %, oder “Ist an/aus”.
Die SmartHome Zentralen der Gerätehersteller haben oft eine bessere Geräteintegration und zum Teil auch mehr Funktionalität als die “offenen” Zentralen. Zum Beispiel ist es mit dem IKEA Trådfri Symfonisk Lautstärke Drehregler nicht annähernd möglich, die Lautstärke so zu regeln, wie es mit einem IKEA Trådfri Hub möglich ist. In Home Assistant funktioniert das schon besser, entspricht aber dennoch nicht der originalen Bedienung. Zumindest war das vor ca. 1,5 Jahren noch so.
Ich fand keine andere Möglichkeit, diese rekursive Schleife zu unterbinden. Ich fand das eigentlich ziemlich elegant gelöst (wenn alles in Echtzeit liefe)
In allen Flows schreibe ich ausschliesslich in die Zieltemperatur des Wandthermostates. Zwei Ausnahmen:
1-eben der Flow, der bemerkt, dass direkt am Radiator dessen Zieltemperatur verändert wurde, da schreibe ich dann auch nur die Radiator Ziel-Temperatur direkt zurück.
2- der Flow, der “nur” stumpf überprüft wenn ZielTempWandthermostat geändert dann gleiche ZielTempRadiator darauf an…
Yepp, dass war der urspr. Gedanke - der leider mangels entsprechender Karte nicht machbar scheint.
Das lese ich mir gleich noch mal durch
OK ich sollte die Flows die den WANDthermostaten bearbeiten also sinngemäß so aufbauen:
WENN
ZielTempWandthermostat verändert wurde
UND
-ZielTempWandthermostat ist NICHT gleich ZielTempRadiator
DANN
-setze/berechne ZielTempRadiator gleich ZielTempWandthermostat
Vielen Dank schon mal für die detaillierte und anschauliche Antwort. ich werde mich noch mal reinarbeiten in die Flows und es ausprobieren.
