"Gesunde" Anzahl von registrierten Triggern
-
Bin gerade über die Releasenotes von Javascript 7.9.0 (Gratulation zu den praxisnahen neuen Features!) gestolpert:
https://github.com/ioBroker/ioBroker.javascript/releases/tag/v7.9.0
Raise warning if more than 100 triggers have been registered
Das scheint mir eine nicht besonders praxisferne Anzahl von Triggern zu sein.
-
Was ist an der Überschreitung dieser Anzahl schädlich?
-
Was für Strategien gibt es dieser Schädlichkeit abzuhelfen? Trigger auf verschiedene Javascript-Instanzen verteilen?
-
-
@martinp sagte: Was ist an der Überschreitung dieser Anzahl schädlich?
Sehr viele Trigger entstehen, wenn Trigger innerhalb von Triggern programmiert werden - bis das System irgendwann überlastet ist. Die Warnung weist rechtzeitig darauf hin.
-
@paul53
Weißt du ob das 100 insgesamt ist, was jetzt nicht wirklich viel ist, oder 100 per Skript was schon ne Menge sind.?!:) -
@ticaki sagte: Weißt du ob das 100 insgesamt ist, was jetzt nicht wirklich viel ist
Das weiß nur @haus-automatisierung. Für 100 Trigger in der gesamten JS-Instanz muss man schon eine Menge programmieren. Mit dem $Selector können allerdings leicht viele Trigger erzeugt werden.
-
@paul53 Naja, 100 Datenpunkte in seinem ioBroker Setup zu finden, auf die man einen Trigger setzen könnte, ist ja noch nichts besonders außergewöhnliches ...
-
@ticaki Pro Script natürlich. Sonst wäre die Funktion ja quatsch. Hoffe damit die Trigger in Trigger Leute etwas zu sensibilisieren
-
@paul53 nee, 100 Scripte mit einem Trigger oder 50 Skripte mit 2 Triggern sollte nichts besonders ungewöhnliches sein.
-
@paul53 sagte in "Gesunde" Anzahl von registrierten Triggern:
Mit dem $Selector können allerdings leicht viele Trigger erzeugt werden.
Das ist auch nur ein Trigger.
-
-
@paul53 Achso mit .on auf dem Ergebnis bin ich mir unsicher. Dachte Du übergibst die Datenpunkte als Array (so wie das Blockly macht). Muss ich in Ruhe testen.
Das Limit für die Warnung höher zu setzen wäre ja nicht das Problem.
-
@haus-automatisierung sagte: Dachte Du übergibst die Datenpunkte als Array (so wie das Blockly macht).
Mit Array passiert das gleiche. Lediglich RegExp erzeugt nur einen Trigger.
-
@paul53 Danke fürs testen! Muss mir die interne Logik mal genauer anschauen. Aber wenn man einen Trigger auf 500+ Datenpunkte registriert hat man eventuell auch etwas ungewolltes getan.
Aber 100 ist dann eventuell wirklich zu früh für manche Anwensungsfälle mit Selektor
-
Sorry für das Entern des Thread. Aber es passt thematisch.
So weit ich es entdeckt habe gibt es 2 Arten eine Trigger zu setzten.
Einmal mit on direkt (id / array / Regex) oder per Selector und dann on
on('maxcul.0.KEQ0465505.isOpen', function(obj){on(['maxcul.0.KEQ0465505.isOpen', 'maxcul.0.OEQ0914535.isOpen'], function(obj){on({ id: /^0_userdata\.0\..*\.person$/}, function (obj) {$('state[id=0_userdata.0.*.light_on]').on(function (obj) {
Ich habe bis jetzt immer gedacht, dass dieses Varianten alle gleich sind. Heute ist mir aufgefallen das
es bei der Version mit dem "$(" keine Möglichkeit gibt z.b. "change": "any" zu setzen.
Jetzt lese ich hier das die Regex Version weniger Ressourcen (da nur ein Trigger angelegt wird) verwendet.Persönlich finde ich die Selektor Varianten am einfachsten zu lesen und zu erstellen aber mit diesen Infos macht es wohl Sinn alles auf Regex umzustellen oder ?
-
@ignis-draco sagte in "Gesunde" Anzahl von registrierten Triggern:
Jetzt lese ich hier das die Regex Version weniger Ressourcen (da nur ein Trigger angelegt wird) verwendet.
Gerne mal in Zahlen ausdrücken, was Du da so an Einsparungen beobachtest
Spoiler: Nicht relevant. -
bei mir wären es statt 91 Triggers nur noch 5. Aber ich glaube das es nicht das ist was du meinst. Ja im CPU /Ram Verbrauch wird das wohl untergehen.
Was ich aber gerade noch entdeckt habe, ist das, wenn man einen neuen Datenpunkt angelegt dieser vom
Regex sofort mit erkennt wird. Bei den anderen Varianten muss man erst das skript neu starten.
Das ist auf jeden Fall ein Vorteil. -
@ignis-draco sagte in "Gesunde" Anzahl von registrierten Triggern:
Bei den anderen Varianten muss man erst das skript neu starten.
Logisch, der Selektor wird ja nur einmalig ausgeführt. Man müsste also im Script regelmäßig den Trigger "deabonnieren" (siehe unsubscribe) und neu erstellen, um wirklich alle Datenpunkte abzudecken. Hab ich ja schon rauf und runter erklärt
-
@haus-automatisierung sagte in "Gesunde" Anzahl von registrierten Triggern:
Hab ich ja schon rauf und runter erklärt
Da habe ich mich wohl etwas missverständlich ausgedrückt. Das man es bei der anderen Version machen muss war mir sehr bewusst, aber nicht das beim Regex es nicht nötig ist.
Tja dann werde ich mich wohl die die Regex Version gewöhnen müssen. -
@ignis-draco sagte in "Gesunde" Anzahl von registrierten Triggern:
aber nicht das beim Regex es nicht nötig ist.
Der Regex kann ja auch weniger. Mit dem $-Selektor kannst Du ja weitere Attribute filtern und nicht nur die ID filtern. Das macht es etwas komplexer.
Aber wenn es Dir um Ressourcen geht, wäre das schon ein spannender Vergleich. Immerhin wird dann jede State-Aktualisierung durch jeden Regex-Trigger geprüft.
-
@haus-automatisierung sagte: Der Regex kann ja auch weniger. Mit dem $-Selektor kannst Du ja weitere Attribute filtern
Auch mit RegExp bietet der Trigger weitere Filteroptionen:
on({id: /^0_userdata\.0\..+/, enumName: 'Fenster'}, function(dp) { log(dp.id); }); -
@paul53 Ja, aber nicht alle. Rolle geht z.B. nicht.
