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: 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
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
Auf keinen Fall sollte man sowas für einzelne devices über devspec mit Filter umsetzen
Zitat von: betateilchen am 16 Juli 2018, 12:48:12
Auf keinen Fall sollte man sowas für einzelne devices über devspec mit Filter umsetzen
Warum sollte man
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.
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 :)
...oder vielleicht auch "down-if-up", oder "position80-ifnot-position80"?
"red-if-green"
dann würde ich aber lieber globalgalaktisch einen Hook in den Setter anbieten
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...
sucht ihr das hier?
https://fhem.de/commandref.html#cmdalias
beispiele:
https://wiki.fhem.de/wiki/Cmdalias#setex
JA, ich denke das ist die Lösung, funktioniert, danke
Zitat von: nils_ am 17 Juli 2018, 12:32:45
sucht ihr das hier?
https://fhem.de/commandref.html#cmdalias (https://fhem.de/commandref.html#cmdalias)
beispiele:
https://wiki.fhem.de/wiki/Cmdalias#setex (https://wiki.fhem.de/wiki/Cmdalias#setex)
Euch ist aber schon klar, dass das genau das Gegenteil von dieser Aussage ist:
Zitat von: betateilchen am 16 Juli 2018, 12:48:12
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:
{if(Value("$NAME") ne $EVENT) { fhem("set $NAME $EVENT") }}
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?:
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:
setex DEVICE $EVENT
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):
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...
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.
Zitatman ü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.
Hmmm. Scheint mir nicht ganz glaubhaft. Wäre da eher für eine Messung.
LG
pah
ZitatHmmm. Scheint mir nicht ganz glaubhaft. Wäre da eher für eine Messung.
Immer diese Theoretiker :) Na dann:
Vorbereitung/fhem.cfg:
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:
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
Also ein set mit Filter wäre demnach dreimal so schnell wie eines ohne?
da hilft nichtmal popcorn...
Zitatda 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.
Aber dann vergleichst Du doch Äpfel mit Birnen ?
LG
pah
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.
Na, so viele nicht. Nur ein paar Anfänger...
LG
pah
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.
FILTER ist etwas schneller als cmdalias, allerdings sind die Unterschiede nur messbar, aber nicht merkbar.
mich würde einfach mal noch die Messung interessieren, wenn 10.000 Mal mit Filter tatsächlich ein "set on" ausgeführt würde...
fhem "set d:FILTER=STATE!=mirEgal on"
Zitatmich 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.
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.
Danke fürs Testen.
Zitat von: rudolfkoenig am 19 Juli 2018, 18:43:32
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 (http://www.hpmuseum.org/prog/synth41.htm) programmierte, um einzelne Bits und Rechenzeit einzusparen... 8)
Zitat von: betateilchen am 19 Juli 2018, 18:48:31
Danke fürs Testen.
Mag schon stimmen. Aber ich stamme aus einer Zeit, als man Taschenrechner (HP41) noch synthetisch (http://www.hpmuseum.org/prog/synth41.htm) programmierte, um einzelne Bits und Rechenzeit einzusparen... 8)
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*