[gelöst] Device ein- bzw. ausschalten, aber nur, wenn nicht schon aus- bzw. ein

[czcbe]

Hallo zusammen

Ich habe jetzt schon einiges gelesen, probiert und auch angewendet in FHEM.
Nun, nach diversen Steuerungen stelle ich fest, dass bei immer mehr Schaltungen und Bedingungen, auch immer mehr Prüfungen dazukommen. Damit meine ich zum Beispiel:

- Schalte Licht ein wenn jemand nach Hause kommt und wenn es nach Sonnenuntergang ist. Wenn aber noch hell, dann kein Licht einschalten etc. Anschliessend baue ich eine Prüfung nach dem Muster schalte nur ein, wenn nicht schon eingeschaltet:

Code Auswählen Erweitern

set DEVICE:FILTER=state!=on on

--> nach dem Muster ungefähr gehen einige Dinge, wie ihr sicher selber zu Hauf kennt

Nun die Frage: muss ich wirklich manuell zu JEDEM Befehl (z.Bsp. Licht einschalten) eine Prüfung einbauen (z.Bsp. ist Licht schon eingeschaltet). Dies, um Doppelschaltungen zu vermeiden?

Gibt es eine Art Zwischenschicht, die immer schon vor dem Schaltvorgang prüft, wie der derzeitige Zustand ist und dann jeweils nur wenn nötig schaltet? Diese Zustände sind ja bekannt und könnten vorgängig automatisch geprüft werden.

Ist natürlich eine sehr allg. Frage, die ich auch gerne weiter differenzieren kann, wenn nötig.

Danke

[Prof. Dr. Peter Henning]

So etwas sollte man nicht als FHEM-Skript anlegen, sondern als Perl-Unterprogramm. Dann ist die Überprüfung diverser geschachtelter Bedingungen sehr einfach.

LG

pah

[betateilchen]

Auf keinen Fall sollte man sowas für einzelne devices über devspec mit Filter umsetzen

[CoolTux]

Auf keinen Fall sollte man sowas für einzelne devices über devspec mit Filter umsetzen

Warum sollte man

Code Auswählen Erweitern


set DEVICE:FILTER=STATE!=on on

nicht für einzelne Devices machen? Verstehe ich gerade so gar nicht. Dafür ist es doch gemacht worden.

[betateilchen]

Es wäre cool., wenn man ein "set <device> on-if-off" bzw. "off-if-on" hätte.

Zumindest in den SetExtensions sollte sich sowas problemlos integrieren lassen

[Papaloewe]

...oder vielleicht auch "down-if-up", oder "position80-ifnot-position80"?

[betateilchen]

"red-if-green"

[Wuppi68]

dann würde ich aber lieber globalgalaktisch einen Hook in den Setter anbieten

[czcbe]

Klingt hilfreich und nachvollziehbar, danke Euch.

Evtl. kann man sogar die alternierenden Werte selber definieren, on/off, down/up, etc.
Mit einem alternativen off-if-on wäre dann zusätzlich der Vorteil, dass der bestehende set-on-Befehl bestehen bleibt, sodass man weiterhin noch gewünschte Doppelschaltungen machen könnte, falls mal ein Gerät beim 1. Mal nicht geschaltet hat...

[nils_]

sucht ihr das hier?
https://fhem.de/commandref.html#cmdalias

beispiele:
https://wiki.fhem.de/wiki/Cmdalias#setex

[czcbe]

JA, ich denke das ist die Lösung, funktioniert, danke

[Beta-User]

sucht ihr das hier?
https://fhem.de/commandref.html#cmdalias

beispiele:
https://wiki.fhem.de/wiki/Cmdalias#setex

Euch ist aber schon klar, dass das genau das Gegenteil von dieser Aussage ist:

Auf keinen Fall sollte man sowas für einzelne devices über devspec mit Filter umsetzen

Wenn ich das mit meinen bescheidenen Kenntnissen richtig interpretiere, geht es schlicht darum, dass man über den FILTER im Hintergrund einen ziemlichen Overhead erzeugt. Da es aber um ein einzelnes Device geht, sollte das auch über den direkten Weg gehen.

Ungetestet müßte das eher so aussehen:

Code Auswählen Erweitern

{if(Value("$NAME") ne $EVENT) { fhem("set $NAME $EVENT") }}

[czcbe]

Wo würde ich diesen Code dranpacken?

Es handelt sich ja nicht nur um ein Device, vielleicht 15, Tendenz steigend

Ich möchte einerseits wenn möglich verhindern, bei jedem Gerät einzeln einen Prüf-Code packen zu müssen (welcher jetzt auch immer optimaler wäre) und andererseits würde ich natürlich auch gerne eine ressourcenschonende Variante einsetzen.

Also wenn folgendes mit setex als cmdalias nicht gut ist, was dann?:

Code Auswählen Erweitern

Internals:
   ALIAS      setex
   CFGFN     
   DEF        setex .* AS set $EVTPART0:FILTER=STATE!=$EVTPART1 $EVTPART1
   NAME       cmdalias_setex
   NEWCMD     set $EVTPART0:FILTER=STATE!=$EVTPART1 $EVTPART1
   NR         53509
   PARAM      .*
   STATE      defined
   TYPE       cmdalias
Attributes:
   room       System

Anschliessend schalte ich das Licht:

Code Auswählen Erweitern

setex DEVICE $EVENT

[Beta-User]

Die Frage ist berechtigt. Der Code müßte wie das setex definiert werden:
Also in modifizierter Form (als Name ist mir grad nichts besseres eingefallen, aber es sollte auch mit "off" gehen):

Code Auswählen Erweitern

define c_onIfOff cmdalias onIfOff .* AS { fhem("set $EVTPART0 $EVTPART1") if(Value("$EVTPART0") ne $EVTPART1)}

Eventuell geht das sogar ohne den ausdrücklichen Wechsel in die Perl-Ebene. Könnte man ja testen, wenn es so funktioniert...

[betateilchen]

Im Prinzip könnte man UntoggleDirect() aus der 99_Utils.pm als Vorlage verwenden, um sich eine entsprechende Funktion zu bauen, die das Ganze möglichst flexibel abfackelt.

[rudolfkoenig]

man über den FILTER im Hintergrund einen ziemlichen Overhead erzeugt

Das sollte nicht ueberbewertet werden: FILTER geht ueber die vorher spezifizierte Liste (in diesem Fall mit einem Element), und behaelt nur die Elemente, die dem Filter entsprechen. Das ist mAn in diesem Fall "billiger" als nach Perl zu wechseln. Ich muss aber zugeben, dass ich das nicht nachgemessen habe.

[Prof. Dr. Peter Henning]

Hmmm. Scheint mir nicht ganz glaubhaft. Wäre da eher für eine Messung.

LG

pah

[rudolfkoenig]

Hmmm. Scheint mir nicht ganz glaubhaft. Wäre da eher für eine Messung.

Immer diese Theoretiker Na dann:

Vorbereitung/fhem.cfg:

Code Auswählen Erweitern

attr global modpath .
attr global mseclog 1

define t telnet 7072
define d dummy
define c_onIfOff cmdalias onIfOff .* AS { fhem("set $EVTPART0 $EVTPART1") if(Value("$EVTPART0") ne $EVTPART1)}


Messen/Ergebnisse:

Code Auswählen Erweitern

  18ms { Log 1, "Start";; map { fhem ""                          } (0..9999);; Log 1, "End" } # leere Schleife/perl overhead
2043ms { Log 1, "Start";; map { fhem "set d on"                  } (0..9999);; Log 1, "End" } # Schleife mit set von dummy, ohne Bedingung
655ms { Log 1, "Start";; map { fhem "set d:FILTER=STATE!=on on" } (0..9999);; Log 1, "End" } # Schleife mit FILTER
1098ms { Log 1, "Start";; map { fhem "onIfOff d on"              } (0..9999);; Log 1, "End" } # Schleife mit cmdAlias


[betateilchen]

Also ein set mit Filter wäre demnach dreimal so schnell wie eines ohne?

da hilft nichtmal popcorn...

[rudolfkoenig]

da hilft nichtmal popcorn...

Aber vielleicht ausschlafen
Der set mit FILTER loest gar kein set aus, was Readings-setzen, auf userReadings pruefen, nach evtl. zu benachrichtigende Instanzen zu suchen erspart.

[Prof. Dr. Peter Henning]

Aber dann vergleichst Du doch Äpfel mit Birnen ?

LG

pah

[rudolfkoenig]

Die Aufgabe war die letzten zwei Varianten mit einander zu vergleichen.
Tut mir leid, dass das Einfuegen der "ohne Filter" Version so viele hier verwirrt.

[Prof. Dr. Peter Henning]

Na, so viele nicht. Nur ein paar Anfänger...

LG

pah

[czcbe]

Wie ist nun das Fazit von den grossen Koryphäen?

In der vielzitierten commandref findet man jedenfalls die Filter-Variante, von wo ich sie auch genommen habe.

[rudolfkoenig]

FILTER ist etwas schneller als cmdalias, allerdings sind die Unterschiede nur messbar, aber nicht merkbar.

[betateilchen]

mich würde einfach mal noch die Messung interessieren, wenn 10.000 Mal mit Filter tatsächlich ein "set on" ausgeführt würde...

Code Auswählen Erweitern

fhem "set d:FILTER=STATE!=mirEgal on"

[rudolfkoenig]

mich würde einfach mal noch die Messung interessieren, wenn 10.000 Mal mit Filter tatsächlich ein "set on" ausgeführt würde...

Der erste Test lieferte 1800ms zurueck. Da mir das komisch vorkam, habe ich "set d on" wiederholt, und jetzt habe ich 1300ms bekommen, offensichtlich hatte ich vorhin einen Ausreisser. Ich habe die folgenden Werte aus 3 Durchlaeufen gemittelt, die Abweichungen lagen bei +/- 10ms.

Code Auswählen Erweitern


1290ms { Log 1, "Start";; map { fhem "set d on" } (0..9999);; Log 1, "End" }
1789ms { Log 1, "Start";; map { fhem "set d:FILTER=STATE!=mirEgal on" } (0..9999);; Log 1, "End" }
627ms { Log 1, "Start";; map { fhem "set d:FILTER=STATE!=on on" } (0..9999);; Log 1, "End" }


Aendert aber nichts an der eigentlichen Aussage: FILTER ist in so einem Fall nicht teuer, und ist eigentlich egal, ob man cmdalias oder FILTER verwendet, die zusaetzliche CPU Belastung ist fuer FHEM-typische Szenarien vernachlaessigbar.

[betateilchen]

Danke fürs Testen.

die zusaetzliche CPU Belastung ist fuer FHEM-typische Szenarien vernachlaessigbar.

Mag schon stimmen. Aber ich stamme aus einer Zeit, als man Taschenrechner (HP41) noch synthetisch programmierte, um einzelne Bits und Rechenzeit einzusparen... 

[Wuppi68]

Danke fürs Testen.

Mag schon stimmen. Aber ich stamme aus einer Zeit, als man Taschenrechner (HP41) noch synthetisch programmierte, um einzelne Bits und Rechenzeit einzusparen... 

da ging ja auch darum Speicherplatz um jeden Preis zu sparen

Wie hast Du nachher es geschafft UPN Knoten im Kopf zu lösen?

*duckundweck*