Wartung am 15.11. – Forum ab 22:00 Uhr nicht erreichbar

[hmanfred]

Danke für deine Antwort.

Natürlich habe ich meinen Thread nochmal durchgelesen.

Die erste Antwort von AlCalzone hat mir "unwahr" und nicht geändert gezeigt.

Alternativ schrieb er: "Ansonsten musst du "wurde geändert" auswählen und dann im Trigger selbst deine Prüfbedingung zusammenbauen."

Und das (erneute) Zusammenbauen der Prüfbedingung hoffte ich mit dem Umsetzen des Screenshots von AlCalzone zu sparen.

Ich hatte mit meinem beschränkten Wissen gehofft, dass ich die zum Triggern verknüpften Datenpunkte ("einer von vielen "false") nicht noch mal auflisten muss.

Kann man da vielleicht was mit Listen machen?

Aber wenns nicht anders geht, mache ich halt meinen "Rattenschwanz".

Gruß

Manfred

[paul53]

@hmanfred:

Kann man da vielleicht was mit Listen machen? `
Ja. Wenn man eine Oder-Verknüpfung der <u>Werte</u> der Datenpunkte möchte, muss man die Werte speichern (z.B. in einer Liste), um sie logisch verknüpfen zu können. Prinzip:

[rantanplan]

@paul53:

Ja. Wenn man eine Oder-Verknüpfung der <u>Werte</u> der Datenpunkte möchte, muss man die Werte speichern (z.B. in einer Liste), um sie logisch verknüpfen zu können. Prinzip: `
Den "Rattenschwanz" hat er damit aber immer noch. Nur an anderer Stelle

[paul53]

Falls alle Datenpunkte Logikwerte sind und die Störung den gleichen Wert hat (im Beispiel: false), kann auch eine Schleife verwendet werden.

[hmanfred]

@paul53:

Falls alle Datenpunkte Logikwerte sind und die Störung den gleichen Wert hat (im Beispiel: false), kann auch eine Schleife verwendet werden. `

Das ist so. Allerdings ist das dann immer noch ein ziemliches Gefrickel.

So sehr die Logik der Homematic-CCU immer verteufelt wird, in einem solchen Fall ist sie genial: bei der Auswahl eines Objektes kann man es in einer Zeile gleichzeitig als Trigger und als Entscheidungswert benutzen.

Vielleicht ist das Aufteilen in zwei Programme hier eine einfachere Lösung. Das ver-ODERn mit dem Wert "false" mit anschließendem unmittelbaren Setzen des Fehler-Indikators ist ja bereits beschrieben. Fürs zweite Programm zum Zurücksetzen müsste ich dann nur eine Lösung finden, mit der ich einfach alle "true" ver-UNDen kann.

:idea: oder ich übertrage alle Objekte als Systemvariable in die CCU und verarbeite sie dann :idea: (nicht ganz ernst gemeint )

[paul53]

Damit die Sammelstörung schon bei Scriptstart verfügbar ist, sollte die Abfrage der Liste mit den Werten in einer Funktion erfolgen.

[paul53]

@hmanfred:

Fürs zweite Programm zum Zurücksetzen müsste ich dann nur eine Lösung finden, mit der ich einfach alle "true" ver-UNDen kann. `
Damit bleibt der Aufwand der gleiche wie mit Triggerung auf Änderung und ODER-Bildung per Schleife.

[rantanplan]

@hmanfred:

Das ist so. Allerdings ist das dann immer noch ein ziemliches Gefrickel. `
Man kann auch alles totquasseln

Einfach mal machen. In der Zeit wo Du hier wegen einer "einfachen" Lösung diskutierst, könnte Dein Programm schon laufen.

Ich habe jetzt mal 3 Minuten "gefrickelt".

Grüße

[paul53]

@rantanplan:

Ich habe jetzt mal 3 Minuten "gefrickelt". `
6 Mal getState() bei jedem Trigger ist zwar die einfachste, aber keine Resourcen schonende Lösung.

Da Störung = false gilt, sollten alle oder durch und ausgetauscht und bei der Ausgabe auf Fehler_kritisch wahr und unwahr getauscht werden. Dann stimmt die Logik.

[rantanplan]

@paul53:

6 Mal getState() bei jedem Trigger ist zwar die einfachste, aber keine Resourcen schonende Lösung. `
????

Wenn man 6 Geräte überwachen will, muss man 6 Geräte triggern. Wo das passiert ist doch egal.

Oder habe ich da etwas verpasst?
@paul53:

Da Störung = false gilt, sollten alle oder durch und ausgetauscht und bei der Ausgabe auf Fehler_kritisch wahr und unwahr getauscht werden. Dann stimmt die Logik. `
Woher hast Du denn die Info?

[paul53]

@rantanplan:

Woher hast Du denn die Info? `
Aus dem ersten Beitrag, und
@hmanfred:

Es geht um einen Summenindikator, der anzeigt, ob eines von vielen Objekten auf "false" steht. `
@rantanplan:

Wenn man 6 Geräte überwachen will, muss man 6 Geräte triggern. `
Das ist klar. Nur die 6 fache Wertabfrage mit "Wert vom Objekt ID" (getState(id).val) ist nicht optimal, da getState(id) eine recht komplexe Funktion ist, die die CPU entsprechend belastet.

[rantanplan]

@paul53:

Das ist klar. Nur die 6 fache Wertabfrage mit "Wert vom Objekt ID" (getState(id).val) ist nicht optimal, da getState(id) eine recht komplexe Funktion ist, die die CPU entsprechend belastet. `
Dein Ansatz die IDs in eine Liste zu packen ist sehr interessant!!!

Habe ich gerade mal ausprobiert. (Auf die Idee bin ich vorher gar nicht gekommen.)

Habe noch nicht alles ausprobiert. Im Trigger kann ich fast alle interessanten Infos zum Auslöser abfragen.

"Objekt ID" liefert nichts. Werde ich mir auf jeden Fall näher anschauen.

[paul53]

@rantanplan:

"Objekt ID" liefert nichts. `
Habe gerade mal mit boolschen Test-Datenpunkten getestet: "Objekt ID" liefert die ID des auslösenden Datenpunktes, das Script funktioniert wie erwartet.