NEWS
Trigger & Performance: Zeit oder Wert / Triggerwerte
-
Hi zusammen,
beim Umzug meiner Scripte von der CCU in Richtung iObroker möchte ich natürlich gerne alles "richtig" machen und auch gleich auf die Performance des Systems achten.
Ich stolpere dabei immer wieder über die Trigger und deren Verwendung. Ich möchte oft auf Werte reagieren die sich sehr häufig ändern:
- Temperatur fällt unter / geht über
- LUX ist kleiner als
Dabei baue ich immer Trigger auf Zeit, weil ich glaube dies sei vorteilhafter bezüglich der Performance.
"Prüfe alle 5 Minuten ob der Wert erreicht ist könnte "besser" sein als immer wieder zu prüfen wenn sich der Wert verändert".
Bin ich damit auf dem Holzweg was die Performance angeht und kann ohne Probleme auf Werte als Trigger gehen weil es absolut vernachlässigbar ist?
Die Aktion würde so auch zeitnaher am Ereignis sein...Zudem habe ich "Kontroll-Scripte" die auf den Ausfall wichtiger Aktoren reagieren sollen. Diese reagieren zb auf "alive = false".
Sehe ich es richtig, dass in dem Objekt "Wert, Objekt, Name" die Daten "fest" stehen, die beim Triggervorgang übergeben werden?
Wenn ich also nach x Minuten den Wert erneut prüfe, muss ich diesen erneut auslesen?
Mal als Screenshot wie ich das gebaut habe...- Objekt löst aus
- prüfe dessen Wert
- speichere Objekt ID in einer Variable zur späteren Verwendung
- lade etwas später den Wert des Objektes erneut(!) aus der Variable (letzte Zeile)
Für mein Verständnis kann nur "Wert" an letzter Stelle nicht genommen werden, weil dort der "Triggerstatus" als fester Wert innerhalb des Triggervorgangs drin steht - richtig?
Also muss ich dort "Wert aus Objekt ID "Objekt ID" nehmen anstatt "Wert"?
(Ja, das hätte man auch ohne variable bauen können, ich weiß )Und eine Fragen nebenbei:
Der Wert "Motion-Detected" kommt in iObroker leider sehr verzögert aus der CCU - kann man das beschleunigen?Grüße
-
@gutgut30 sagte in Trigger & Performance: Zeit oder Wert / Triggerwerte:
Zudem habe ich "Kontroll-Scripte" die auf den Ausfall wichtiger Aktoren reagieren sollen. Diese reagieren zb auf "alive = false".
Sehe ich es richtig, dass in dem Objekt "Wert, Objekt, Name" die Daten "fest" stehen, die beim Triggervorgang übergeben werden?
Wenn ich also nach x Minuten den Wert erneut prüfe, muss ich diesen erneut auslesen?
Mal als Screenshot wie ich das gebaut habe...Es gibt hier zwei Möglichkeiten das zu vereinfachen / beschleunigen:
Option a) Du triggerst auf "Wert kleiner als vorher" - dann wird das Skript nur ausgeführt wenn der Sensor von available auf unavailable wechselt. (true > false !!!). Damit kann die Falls-Abfrage weg, aber das zweite Abfragen des Wertes ist notwendig.
Option b) Du gibst dem Falls noch einen "sonst" Zweig mit, in dem du den timeout2 löscht. Dann brauchst du vor der Meldung im Timeout den Wert nicht noch einmal abzufragen, da er sich nicht geaendert haben kann.
Im Bezug auf die Performance sehe ich die Folgende Reihenfolge (geringster Einfluss oben):
- Trigger mit "einfachem" Wenn ausstieg als optimum, auch wenn sie Verhältnismäßig oft auslösen
- Viele Threads die alle n Minuten je einen Sensor abfragen
- Einen Thread der alle n Minuten mehrere Sensoren abfragt
Möglicherweise sehe ich das falsch, aber in meiner Wahrnehmung laufen die Trigger als "Grundlast" statistisch verteilt besser als ein System das alle n Minuten einen (Regelmäßigen) Spike liefert.
A.
-
@Asgothian said in Trigger & Performance: Zeit oder Wert / Triggerwerte:
Möglicherweise sehe ich das falsch, aber in meiner Wahrnehmung laufen die Trigger als "Grundlast" statistisch verteilt besser als ein System das alle n Minuten einen (Regelmäßigen) Spike liefert.
Das ist natürlich in der Tat ein Argument. Ich versuche es mal, so viele Trigger habe ich eigentlich auch nicht. Vielleicht 20-30 am Ende... Das ist ja eigentlich überschaubar.
Kannst du mir evtl. noch kurz hier etwas zu schreiben?
Trigger mit "einfachem" Wenn ausstieg als optimum, auch wenn sie Verhältnismäßig oft auslösen
Meinst du damit Logikblöcke die eine einfach "Falls Prüfung" vornehmen und bei negativem Ergebnis das Script nicht weiter verfolgen?