Wiederholende Prozeduren auslagern?

[DetlefR]

Aha, noch einer, der von Prototypen überzeugt ist und shift nicht "kann" oder kennt.

oder nicht unbedingt mag 

[alanblack]

Hallo,

als erstes musst Du die Namensgebung für die Geräte überdenken. Dann kannst Du ein Notify anlegen das für alle Bewegungsmelder passt.

Code Auswählen Erweitern

define PIR_all notify Bewegungsmelder.*:motion:.* .

So etwas würde ich mit Hinblick auf z.B. https://forum.fhem.de/index.php/topic,125831.0.html und der im Verlauf verlinkten anderen Threads nur mit großer Vorsicht machen - wenn überhaupt.

Grüße

[DetlefR]

So etwas würde ich mit Hinblick auf z.B. https://forum.fhem.de/index.php/topic,125831.0.html und der im Verlauf verlinkten anderen Threads nur mit großer Vorsicht machen - wenn überhaupt.

Hallo,
der Hauptgrund, warum ich es vorgeschlagen habe, es ist einfacher 45 Notify zu pflegen und zu Warten als wie in dem Thread angegeben 450. Und wenn die Last auf dem Rechner zu groß wird dann würde ich zuerst versuchen, die Ursache abzustellen. Das sind m.M.n die Events. Wo kein Event ist wird auch kein Notify/DOIF abgearbeitet.

Gruß
Detlef

[Beta-User]

So etwas würde ich mit Hinblick auf z.B. https://forum.fhem.de/index.php/topic,125831.0.html und der im Verlauf verlinkten anderen Threads nur mit großer Vorsicht machen - wenn überhaupt.

Ich kann in dem verlinkten Thread kein wirkliches Argument erkennen, aus dem sich ableiten lassen würde, dass es _nicht sinnvoll_ ist, das Namensschema so zu gestalten, dass man per regular expression die auslösenden Devices gruppenweise erfassen könnte. Im Gegenteil: Wenn man es sinnvoll macht (und ggf. auch den trigger weiter hinten entsprechend eingrenzt!), vermindert das die Last erheblich und man hat dafür auch im Rahmen von generalisiertem Code die Option, einfacher Debugging-Optionen vorzusehen...

Hallo,
der Hauptgrund, warum ich es vorgeschlagen habe, es ist einfacher 45 Notify zu pflegen und zu Warten als wie in dem Thread angegeben 450. Und wenn die Last auf dem Rechner zu groß wird dann würde ich zuerst versuchen, die Ursache abzustellen. Das sind m.M.n die Events. Wo kein Event ist wird auch kein Notify/DOIF abgearbeitet.

Das stimmt zwar zum Teil auch, aber nicht immer ist es sinnvoll, Events zu unterdrücken, und zu warten, bis die Last groß ist, ist auch keine optimale Vorgehensweise.

Sinnvoll ist es in jedem Fall, sich über "Strukturen" Gedanken zu machen, also Dinge, die immer gleich laufen sollen (und die Ausnahmen dazu). Genau für solche Sachen macht das Auslagern von Prozeduren dann auch Sinn.
Wenn man es richtig macht
- werden Events nur "von den richtigen Devices" überhaupt erfaßt (NOTIFYDEV);
- werden nur "passende Events" überhaupt zum Anlass genommen, dass der Code aufgerufen wird (bei notify: die ganze regexp paßt);
- werden bricht der Code schnell ab, wenn nichts relevantes passiert ist (Beispiel: Thermostate verstellen, wenn die ganze Heizung aus ist, macht nur beim Ausschalten der Heizung Sinn...)
- ist der Code selbst modular aufgebaut. Beispiel: ggf. wird dann eine "passende" Unterfunktionen aufgerufen, die die "Reaktion" dann auf die jeweilige Hardware anpassen (z.B. kann nicht jeder Heizkörper per virtuellem Peer über eine Fensteröffnung informiert werden; das geht mit CUL_HM, aber für ZigBee muss das anders aussehen, und zwar dann wieder je nachdem, ob HUEDevice oder MQTT2_DEVICE (und dort ggf. wieder nach "model" unterschiedlich!)...

Letztlich muss man sich eigentlich immer erst Gedanken über die "Struktur" machen, und die Eingangsbedingungen, Rahmenbedingungen und möglichen Ergebnis-Aktionen mal auf einen Zettel schreiben, dann ist die konkrete Lösung eigentlich meistens gar nicht soooo sehr das Problem...