Problem bei DOIF mit verschiedenen Bedingungen

Begonnen von hermann1514, 21 November 2016, 10:50:31

Vorheriges Thema - Nächstes Thema

l2r

#15
mit dem leeren DOELSE wird aber zum Beispiel jedes mal der set-Befehl ausgeführt, wenn der Bewegungsmeldet motion triggert. Ist dann halt ein bisschen zusätzliche Last. Im Einzelfall zu vernachlässigen, aber Kleinvieh macht bekanntlich ja auch mist. Ein Fall wo es zu unschönem Verhalten führen kann ist, wenn man im Set-Befehl zb. eine Playlist startet. Diese würde dann jedes mal geladen und gestartet werden. Führt dann zu unschönen rucklern... ;)

DOELSE und  attr do always machen in den meisten Fällen das gleiche...
Wissen ist Macht.
Ich weiß nix.
Macht nix.

Damian

Zitat von: l2r am 21 November 2016, 16:46:02
mit dem leeren DOELSE wird aber zum Beispiel jedes mal der set-Befehl ausgeführt, wenn der Bewegungsmeldet motion triggert. Ist dann halt ein bisschen zusätzliche Last. Im Einzelfall zu vernachlässigen, aber Kleinvieh macht bekanntlich ja auch mist. Ein Fall wo es zu unschönem Verhalten führen kann ist, wenn man im Set-Befehl zb. eine Playlist startet. Diese würde dann jedes mal geladen und gestartet werden. Führt dann zu unschönen rucklern... ;)

DOELSE und  attr do always machen in den meisten Fällen das gleiche...

Es ist schon gut sich vorher Gedanken zu machen ob ein leeres DOELSE angegeben wird oder nicht. Denn durch die Angabe des DOELSE wird ein Zustandwechsel provoziert, der manchmal aber nicht immer erwünscht ist.

Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

hermann1514

Oha....ist ja ne ganz schöne Diskussion geworden. :o :o

Nun,

erstmal zu Beta USer:
ZitatDaher wollte ich nur darauf hinweisen, dass es auch andere Möglichkeiten gibt, Dein Problem zu lösen. Aber da Du das offenslichtlich weißt, bitte ich um Verzeihung für den freundlich gemeinten Hinweis.

Danke für den Hinweis....sollte nicht als meckern verstanden werden ;)


Und ja - wenn ich das Radio einschalte wird ja eine Bewegung erzeugt.

Ich werde mal die diversen Vorschläge testen.

Vielen Dank für Eure Hilfe.

Gruß
Hermann





Beta-User

Zitat von: hermann1514 am 22 November 2016, 08:53:36
Danke für den Hinweis....sollte nicht als meckern verstanden werden ;)
Kein Problem ;). Dein Ansatz, die Funktionalität erst mal komplett verstehen zu wollen, ist auf alle Fälle gut!!!

Hier im Forum gibt es nach meinem persönlichen Empfinden zu viele Beiträge von Leuten, die sich unbedacht auf DOIF stürzen und dann völlig erschlagen sind von den vielen Möglichkeiten. Bei meinem Start mit FHEM hab' ich's genauso gemacht und empfinde das heute als Fehler: Die DOIF's haben nach einem kurzen Test funktioniert und ich habe mich dann lange nicht mehr damit beschäfitgt, ob sie wirklich tun, was ich eigentlich möchte. Jezt gehe ich das alles nochmal durch und stelle fest: Das funktioniert meistens, aber leider nicht immer...

Na jedenfalls habe ich gestern abend mal ein paar DOIF's durch einfache norify's ersetzt (in Verbindung mit IF ... ELSE ..., das liest sich einfacher als perl-if-Code) und das ganze dabei noch verdichtet. Also vorher: 2 notify + 4 DOIF für bestimmte Funktionalitäten
Jetzt: 3 notify und ich habe auch noch einen Fehler eleminiert ;D (den will ich aber nicht dem Modul anlasten :D)

Verbleiben noch 18 DOIF... Nochmal 4 dürften einfach sein, dann muß ich mich mal an Stichworte wie defmod und evtl. weekdaytimer ranwagen, um das in den Griff zu kriegen, was mit Wiederholungen zu tun hat oder Zeiträumen, innerhalb derer bestimmte Schaltvorgänge stattfinden sollen. Da ist DOIF wirklich komfortabel!

Gruß,

Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Damian

Zitat von: Beta-User am 22 November 2016, 09:31:53
Kein Problem ;). Dein Ansatz, die Funktionalität erst mal komplett verstehen zu wollen, ist auf alle Fälle gut!!!

Hier im Forum gibt es nach meinem persönlichen Empfinden zu viele Beiträge von Leuten, die sich unbedacht auf DOIF stürzen und dann völlig erschlagen sind von den vielen Möglichkeiten. Bei meinem Start mit FHEM hab' ich's genauso gemacht und empfinde das heute als Fehler: Die DOIF's haben nach einem kurzen Test funktioniert und ich habe mich dann lange nicht mehr damit beschäfitgt, ob sie wirklich tun, was ich eigentlich möchte. Jezt gehe ich das alles nochmal durch und stelle fest: Das funktioniert meistens, aber leider nicht immer...

Na jedenfalls habe ich gestern abend mal ein paar DOIF's durch einfache norify's ersetzt (in Verbindung mit IF ... ELSE ..., das liest sich einfacher als perl-if-Code) und das ganze dabei noch verdichtet. Also vorher: 2 notify + 4 DOIF für bestimmte Funktionalitäten
Jetzt: 3 notify und ich habe auch noch einen Fehler eleminiert ;D (den will ich aber nicht dem Modul anlasten :D)

Verbleiben noch 18 DOIF... Nochmal 4 dürften einfach sein, dann muß ich mich mal an Stichworte wie defmod und evtl. weekdaytimer ranwagen, um das in den Griff zu kriegen, was mit Wiederholungen zu tun hat oder Zeiträumen, innerhalb derer bestimmte Schaltvorgänge stattfinden sollen. Da ist DOIF wirklich komfortabel!

Gruß,

Beta-User

Ich würde dir an einer Stelle Recht geben, viele wollen komplexe Probleme schnell gelöst haben. Zudem besitzen sie keine Programmiererfahrung und können oft logische zusammenhänge mathematisch nicht richtig erfassen. Zusätzlich kommt noch die Ereignissteuerung hinzu, die dies Sache komplizierter macht. Da kann auch ein DOIF nicht helfen.

Da  jeder notify-Befehl in DOIF-Befehl umgewandelt werden kann, aber nicht umgekehrt, kann man sagen, wenn man ein Problem mit drei notify lösen kann dann kann man es auch mit drei DOIFs lösen, meistens aber kürzer.

Wenn du schon zu den Grundlagen zurück möchtest, dann solltest du vielleicht gleich auf Perl-if setzen, da du auch bei IF an bestimmten Stellen Einschränkungen in Kauf nehmen musst.

Gruß

Damian
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Beta-User

Zitat von: Damian am 22 November 2016, 11:30:10
Wenn du schon zu den Grundlagen zurück möchtest, dann solltest du vielleicht gleich auf Perl-if setzen, da du auch bei IF an bestimmten Stellen Einschränkungen in Kauf nehmen musst.
Das führt jetzt zwar weit weg von der urspünglichen Frage, aber:
- sobald meine C-Programme auf den Arduinos soweit passen, werde ich das mit Perl versuchen zu vertiefen.
- Dass IF auch "bestimmte Einschränkungen" hat, habe ich gelesen, allerdings bislang keine konkrete Vorstellung, worum es sich handeln soll (ok, ich habe zum einen nicht besonders lange gesucht und könnte das Modul zum anderen zum Üben für perl nehmen und versuchen, das durch Analyse des Quellcodes selbst herauszufinden ::)). Bei den "beseitigten" DOIF's ging es "nur" um die Kombination eines (eher seltenen) Ereignisses mit in der Regel einer weiteren Abfrage, also:
--Licht im Bad wird angeschaltet oder ein Taster gedrückt: Umwälzpumpe für Warmwasser anschalten, wenn dort die Wassertemp. unter einem bestimmten Wert ist, oder
--Tür öffnen iVm. einem Höchst-Helligkeitswert=Außenlicht einschalten.
Dafür ist IF nach meinem Eindruck ok und verhindert, dass man sich beim "Klammern" usw. vertippt; diese einfachen Dinge werden dadurch auch nicht viel länger als mit DOIF. Das ist vermutlich bei komplexeren Dingen anders, mal sehen.
- Was mich noch interessieren würde: Hat DOIF eigentlich Vorteile bei der Systemlast, wenn man häufige Events auswerten will (Helligkeitswerte), vor allem, wenn es mit Zeiträumen gekoppelt ist? Werden also bestimmte Abfragen nur durchgeführt, wenn sie Sinn machen, oder wird sowieso immer alles ausgewertet? (Da die Readings aller Elemente in FHEMWEB aktualisiert werden, würde ich auf letzteres tippen).

Ansonsten: An sich hat mir DOIF auch als Anfänger erst mal sehr gut gefallen und sicher manches möglich gemacht, was ich sonst nie oder jedenfalls nicht in der Zeit hinbekommen hätte. Für diesen Ansatz daher auch mal ein ausdrückliches DANKE! Und ich sehe auch, dass DOIF in den guten zwei Jahren, in denen ich es im Einsatz hatte, sehr gewachsen ist und unglaubliche Funktionalitäten ermöglicht, das ist und bleibt eine Riesenleistung und sicher für viele Neulinge auch eine große Hilfe.

Auch die Tutorials, Fehlersuchhilfen usw., die in letzter Zeit dazugekommen sind, sind ein großer Fortschritt!

Thx,

Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

l2r

Wissen ist Macht.
Ich weiß nix.
Macht nix.

Beta-User

Codemirror kenne ich, vermutlich habe ich vor einiger Zeit mal mit einer doofen Frage verursacht, dass dieses Stichwort (und die Funktionalität) plötzlich bei vielen Leuten präsent ist   ;D.

Aber mit perl direkt werden die Kommandos wirklich deutlich länger und damit schlechter zu lesen (und damit für echte Anfänger im Zweifel abschreckend!). Einen echten Nachteil konnte ich bei (einfachen) IF bislang nicht erkennen, lerne da aber gerne dazu...

Gruß,

Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors