Neuer ioBroker-Blog online: Monatsrückblick März/April 2026

[mickym]

@newpicsel Die Frage, die sich stellt - warum Du überhaupt mit Timeouts arbeitest? - Nachdem nur geänderte Werte triggern, hast Du doch Datenverlust, wenn Du mit den Timern arbeitest?

[Homoran]

@newpicsel sagte in Mehrfach Triggern verhindern? (Ohne Verlust):

Meinst den "Stop timeout",

nein, ich meine dass ein neuer timeout nur gestartet wird, wenn noch kein timeout läuft.
Erfüllt wahrscheinlich aber auch nicht deine Kriterien.

Ich hab aber immer noch nicht verstanden was genau die Erkennung unterschiedlicher Trigger für den Timeout bedeuten sollen.

Du triggerst auf irgendwelche Netatmo DPs und willst irgend einen state auf wahr setzen, aber nicht wenn der selbe Datenpunkt innerhalb von 3 Sekunden zuschlägt.

Wenn jetzt aber 2 verschiedene Datenpunkte alternierend im Millisekundentakt feuern, soll geschaltet werden

[Newpicsel]

@mickym said in Mehrfach Triggern verhindern? (Ohne Verlust):

@newpicsel Die Frage, die sich stellt - warum Du überhaupt mit Timeouts arbeitest? - Nachdem nur geänderte Werte triggern, hast Du doch Datenverlust, wenn Du mit den Timern arbeitest?

Genau deshalb würde ich ungerne mit den Timern arbeiten!
Mir fällt dazu aber keine Lösung ein…

Mit dem Verlust der gleichen ID des Auslösers kann ich in dem Fall leben, allerdings nicht mit dem Verlust, sollte eine weitere ID den trigger quasi zeitgleich ausgelöst haben, dies soll schön nacheinander abgearbeitet werden.

[mickym]

@newpicsel Nun wenn Du einfach den timer weglässt, dann wird das doch vom System gequeued. Sprich auch wenn gerade ein Trigger in Bearbeitung ist (und getriggert wird ja nur bei Wertänderungen), dann geht Dir doch im Normalfall nichts verloren?

[paul53]

@newpicsel sagte: Funktioniert leider nicht

Du setzt den Trigger-Datenpunkt auf wahr, auch dann, wenn er schon wahr enthält. Ändere den Trigger auf "ist kleiner als letztes".

@newpicsel sagte in Mehrfach Triggern verhindern? (Ohne Verlust):

Ein Timeout

Es bräuchte zu jedem Datenpunkt einen eigenen Timeout. Da aber die Datenpunkte nicht bekannt sind (RegExp), steht es schlecht um die Umsetzung.

[Newpicsel]

@homoran said in Mehrfach Triggern verhindern? (Ohne Verlust):

Du triggerst auf irgendwelche Netatmo DPs und willst irgend einen state auf wahr setzen, aber nicht wenn der selbe Datenpunkt innerhalb von 3 Sekunden zuschlägt.

Wenn jetzt aber 2 verschiedene Datenpunkte alternierend im Millisekundentakt feuern, soll geschaltet werden

Exakt 👍
(Die DPs können von unterschiedlichen Quellen geändert werden, weshalb es durchaus vorkommen kann, dass sich diese Werte nahezu zeitgleich ändern, wobei hier dann tatsächlich nur jeweils die letzte Änderung eines gleichen DPs relevant ist.)

Den steuere Block hab ich nur als Beispiel eingefügt 😅 da folgen einige abfragen wie (falls mache (falls mache () sonst falls () sonst()) sonst()) 🙈

[Homoran]

@newpicsel sagte in Mehrfach Triggern verhindern? (Ohne Verlust):

nur jeweils die letzte Änderung eines gleichen DPs relevant ist

wenn ich es jetzt richtig verstanden habe, könnte dann sogar unter 3 Sekunden der selbe DP noch einmal triggern, wenn zwischendurch ein anderer DP getriggert hatte?

dann würde nicht einmal die Idee von @paul53 helfen für jeden möglichen Datenpunkt ein fixes timeout festzulegen.

Dann brauchst du im Prinzip gar keinen timeout
wenn nie derselbe Datenpunkt zweimal ohne Wechsel auslösen darf

[Newpicsel]

@paul53 said in Mehrfach Triggern verhindern? (Ohne Verlust):

@newpicsel sagte: Funktioniert leider nicht

Du setzt den Trigger-Datenpunkt auf wahr, auch dann, wenn er schon wahr enthält. Ändere den Trigger auf "ist kleiner als letztes".

Der würde dann bei jeder anderen ID auslösen nur nicht bei der gleichen? 🤔
Interessant!
Allerdings wie verhält es sich dann, wenn zwischenzeitlich kein anderer DPs den trigger auslöst? Unwahrscheinlich aber nicht unmöglich muss ich zumindest annehmen 😅

@newpicsel sagte in Mehrfach Triggern verhindern? (Ohne Verlust):

Ein Timeout

Es bräuchte zu jedem Datenpunkt einen eigenen Timeout. Da aber die Datenpunkte nicht bekannt sind (RegExp), steht es schlecht um die Umsetzung.

Deshalb die Überlegung den timeout über eine Funktion zu erstellen, bei der ich die variable frei setzen kann und hier die ObjektID in den Namen der variable einfließen lassen kann… 🤔
(Nur eine undurchdachte Überlegung)

[Newpicsel]

@homoran

Richtig, fixe timeout für jeden DP fällt auch raus, da diese unbekannt sind 🙈 ist etwas komplexer die Geschichte dahinter…

Aber leider kann es durchaus vorkommen, dass (allerdings nicht relevant unter 3sek) der selbe DP den trigger auslösen könnte.

[Homoran]

@newpicsel sagte in Mehrfach Triggern verhindern? (Ohne Verlust):

Aber leider kann es durchaus vorkommen, dass (allerdings nicht relevant unter 3sek) der selbe DP den trigger auslösen könnte

können kann er!
sollen aber wohl nicht.

aber nach 3 Sekunden ohne anderen triggernden Datenpunkt, darf er wieder?

Das muss dann in der Logik abgefangen werden.
im Trigger ist das nicht möglich

[paul53]

@newpicsel sagte: Trigger werden ab und an mal mehrfach ausgelöst…

Was sind das für Datenpunkte, die sich so verhalten (kurz aufeinander den Wert ändern)?

[Newpicsel]

@paul53 said in Mehrfach Triggern verhindern? (Ohne Verlust):

Was sind das für Datenpunkte, die sich so verhalten (kurz aufeinander den Wert ändern)?

Das sind soll wert DP einer Heizung, diese werden hauptsächlich aus der API aktualisiert, allerdings kann hier jeder seinen Intervall selber einstellen und dann kommen noch manuelle Änderungen aus iobroker hinzu sowie Änderungen von Fenstersensoren.

Ich sag mal so, dass funktioniert schon so, nur ist es halt irgendwie auch nicht schön!
In der Regel erfolgen Änderungen nicht parallel aber ich kann nicht von der Regel ausgehen, es kann durch eine Intervall Aktualisierung durchaus auch vorkommen, dass sich Aktualisierungen überschneiden, auch gerade weil einige Änderungen eine Aktualisierung beinhalten was im Zweifel wenn es mal hart auf hart kommt, 2-3 sehr kurze Aktualisierungen bedeuten könnte! Ich versuche es natürlich zu unterbinden aber ich rechne eher mit der Ausnahme als mit der Regel…

[Blockmove]

@newpicsel

Eine Möglichkeit, die ich bei sowas nutze, ist die zyklische Abfrage von Signalen. Also z.B. Temperaturen oder Energieverbrauch im 30s Takt. Macht gegenseitige Abhängigkeiten, Regler, komplexe Logik usw. einfacher.
Ist in der Prozesstechnik weit verbreitet.

[paul53]

@blockmove sagte: zyklische Abfrage von Signalen.

Wie wendet man dabei den RegExp an?

[Homoran]

@blockmove sagte in Mehrfach Triggern verhindern? (Ohne Verlust):

Ist in der Prozesstechnik weit verbreitet.

da wird auch seltenst eventbasiert mit js gearbeitet.
Eine SPS tickt da anders

[Blockmove]

@homoran said in Mehrfach Triggern verhindern? (Ohne Verlust):

@blockmove sagte in Mehrfach Triggern verhindern? (Ohne Verlust):

Ist in der Prozesstechnik weit verbreitet.

da wird auch seltenst eventbasiert mit js gearbeitet.
Eine SPS tickt da anders

Naja auch eine SPS hat Events (Hardware, Zeit, und im Prinzip auch Flanken).
Das schöne an ioBroker ist ja, dass ich auch im SPS-Stil Aufgaben lösen kann.
Für jede Aufgabe eben das richtige Werkzeug nehmen

[Blockmove]

@paul53 said in Mehrfach Triggern verhindern? (Ohne Verlust):

@blockmove sagte: zyklische Abfrage von Signalen.

Wie wendet man dabei den RegExp an?

Innerhalb des Intervalls verknüpft man ja anhand der Logik die Werte von getStateAsync und schreibt dann mit setStateAync die Ergebnisse. Wenn das ganze mehrfach identisch passieren sool (z.B. mehrere Räume) dann ist es von Vorteil, wenn die entsprechenden Datenpunkte VOR dem Trigger bekannt sind und z.B. in Arrays oder Objekten vorhanden sind. Diese kann man dann innerhalb des Triggers z.B. mit each oder forEach abarbeiten. Das spart Rechenzeit innerhalb des Intervalls.
Die Regular Expressions verwende ich eigentlich nie. Du musst halt schauen, wie du sie auf z.B. GetObject zum Ermitteln der Datenpunkte anwenden kannst.
Natürlich ist das komplexer als ein einfaches:

on({id: new RegExp("0_userdata.0.Devices\.[a-zA-Z0-9]"), change:"ne"}, function (obj) {
 tu irgendwas
});

Vorteil ist, dass ich mehr Kontrolle über den Code-Ablauf habe und Eventkaskaden bei gegenseitiger Beeinflussung von Datenpunkten vermeide. Eben weil die Datenpunkte gar keine Events auslösen.