Skip to content
  • Home
  • Aktuell
  • Tags
  • 0 Ungelesen 0
  • Kategorien
  • Unreplied
  • Beliebt
  • GitHub
  • Docu
  • Hilfe
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Standard: (Kein Skin)
  • Kein Skin
Einklappen
ioBroker Logo

Community Forum

donate donate
  1. ioBroker Community Home
  2. Deutsch
  3. Skripten / Logik
  4. Trigger & Performance: Zeit oder Wert / Triggerwerte

NEWS

  • Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨
    BluefoxB
    Bluefox
    17
    1
    3.8k

  • Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄
    BluefoxB
    Bluefox
    13
    1
    1.2k

  • Weihnachtsangebot 2025! 🎄
    BluefoxB
    Bluefox
    25
    1
    2.5k

Trigger & Performance: Zeit oder Wert / Triggerwerte

Geplant Angeheftet Gesperrt Verschoben Skripten / Logik
javascriptblockly
3 Beiträge 2 Kommentatoren 551 Aufrufe 2 Watching
  • Älteste zuerst
  • Neuste zuerst
  • Meiste Stimmen
Antworten
  • In einem neuen Thema antworten
Anmelden zum Antworten
Dieses Thema wurde gelöscht. Nur Nutzer mit entsprechenden Rechten können es sehen.
  • G Offline
    G Offline
    gutgut30
    schrieb am zuletzt editiert von
    #1

    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
    ff33cba4-135e-4e74-9bb2-4dcad2764217-image.png

    1 Antwort Letzte Antwort
    0
    • AsgothianA Offline
      AsgothianA Offline
      Asgothian
      Developer
      schrieb am zuletzt editiert von
      #2

      @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.

      ioBroker auf RPi4 - Hardware soweit wie möglich via Zigbee.
      "Shit don't work" ist keine Fehlermeldung, sondern ein Fluch.

      G 1 Antwort Letzte Antwort
      0
      • AsgothianA Asgothian

        @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.

        G Offline
        G Offline
        gutgut30
        schrieb am zuletzt editiert von
        #3

        @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?

        1 Antwort Letzte Antwort
        0
        Antworten
        • In einem neuen Thema antworten
        Anmelden zum Antworten
        • Älteste zuerst
        • Neuste zuerst
        • Meiste Stimmen


        Support us

        ioBroker
        Community Adapters
        Donate

        596

        Online

        32.7k

        Benutzer

        82.4k

        Themen

        1.3m

        Beiträge
        Community
        Impressum | Datenschutz-Bestimmungen | Nutzungsbedingungen | Einwilligungseinstellungen
        ioBroker Community 2014-2025
        logo
        • Anmelden

        • Du hast noch kein Konto? Registrieren

        • Anmelden oder registrieren, um zu suchen
        • Erster Beitrag
          Letzter Beitrag
        0
        • Home
        • Aktuell
        • Tags
        • Ungelesen 0
        • Kategorien
        • Unreplied
        • Beliebt
        • GitHub
        • Docu
        • Hilfe