mit dem angehängten patch wird das set commando um eine optionale bedingung erweitert. damit lassen sich in einem einzigen set dann z.b. nur die lampen hoch dimmen die tatsächlich auch an sind oder nur die runter dimmen die heller als 50% sind. die vorgeschlagene syntax sieht so aus:set [bedingung] <device> <params>...die eckigen klammern müssen tatsächlich hin geschrieben werden. bedinung selber hat die form reading:regex oder ein perl ausruck in {}. wenn das erste zeichen nach der öffnenden eckigen klammer ein ! ist wird die bedingung negiert. beispiele sehen dann so aus:set [!state:off] TYPE=HUEDevice dimUp
set [state:off] meienLampe on-for-timer 10
set [{(ReadingsVal($DEVICE,"pct",0)>80)}] TYPE=HUEDevice dimDown
der zeite patch erweitert structure so das falls das erste argument des set eine bedinung nach obigem format ist diese bedingung an das CommandSet weitergereicht wird und so für jedes device ausgewertet wird. beispiel:define s structure s TYPE=HUEDevice
set s [!state:off] dimUp
set s [{(ReadingsVal($DEVICE,"pct",0)>90)}] dimDown
die gleiche erweiterung würde ich auch noch in die lightScene einbauen.
gruss
andre
Nette Idee und kleiner Patch, ich finde sowas gehoert aber nach devspec2array, als optionaler Filter. Ich bin nur beim Syntax unsicher:
TYPE=HUEDevice[!state:off]
TYPE=HUEDevice:[!state:off]
TYPE=HUEDevice,FILTER=!state:off
Finde z.Zt. die dritte Variante am besten. Andere Vorschlaege?
die varianten mit eindeutigem zeichen am anfang und ende haben den den vorteil das sie sich sicherer parsen/erkennen lassen, auch z.b. robust gegen leerzeichen im perl ausdruck und erlauben auch die syntax zu erweitern.
wie wäre FILTER=[<bedingung>] wobei besingung reading:regex oder ein {} ausdruck mit jeweils optionalem ! davor sein kann.
das könnte mann dann später auf mehrere solcher ausdrücke die mit & | und klammern verknüpft sind erweitern.
diese syntax mit KEYWORD=[] könnte man vielleicht auch für die attribut im define angeben idee aus dem anderen thread verwenden
Habe kein Problem mit dem vorgeschlagenen Syntax.
Mit der define / attr Geschichte habe ich aber immer noch meine Probleme, da versuchst du ein Attribut zu setzen bevor noch das Geraet definiert ist, das kann AttrFn & Co gehoerig durcheinanderbringen.
ich baue den patch mal auf devspec2array mit der vorgeschlagenen syntax um. mal sehen ob das mit dem parsen immer noch so gut hin haut wenn es nach dem device namen/devspec kommt.
eventuell wäre es einfacher das umzudrehen. alsoset FILTER=[...] devspec ...
bevor in CommandDefine die DefFn aufgerufen wird ist das gerät zumindest rudimentär da. sollte das nicht reichen? zumindest die fälle die ich im sinn habe wie z.b. verbose zu setzen damit schon im define passend geloggt werden kann sollte doch funktionieren.
Hab devspec umgebaut/erweitert.
Die schlechte Nachricht: range (Lampe1-Lampe3) wurde entfernt. Bitte mit Regexp loesen.
Die Guten:
- Der NAME=WERT Ausdruck ist jetzt allgemeiner, und sucht NAME erst als "internal", dann als reading und zum Schluss als Attribut
- Man kann auch NAME!=WERT spezifizieren
- man kann beliebig viele :FILTER=NAME=WERT dranhaengen, um die zuvor gefundene Liste zu filtern
- der Code ist etwas verstaendlicher und kuerzer geworden.
Beispiele:
set room=kitchen:FILTER=STATE=on off
list room=kitchen:FILTER=STATE!=off STATE
Habs dokumentiert und eingecheckt
schön das du dir idee so schnell aufgegriffen hast. ich habe aber mit der aktuellen version ein paar probleme:
- die syntax erlaubt ein paar dinge und mögliche erweiterungen leider nicht mehr die im ersten vorschlag möglich gewesen sind und ich glaube sie ist anfällig für probleme beim parsen.
- es ist nicht möglich für die filter zwischen und und oder verküpfung zu wählen
- es ist nicht möglich etwas anderes als regex zu verwenden. z.b dim > 75.
-> es geht also z.b. nicht: alle lampen die an oder heller als 75% sind.
- die möglichkeit des perl ausdrucks fehlt leider auch mit der man das hätte nachrüsten können
gruss
andre
Immer diese Haar-in-der-Suppe Sucher (die aber leider auch nette Ideen haben, die ich nicht immer sofort erkenne :)
- "und" ist implizit, "oder" kann man haeufig per regexp | loesen. Ich weiss, es ist nicht allgemeingueltig.
- dim>75 == FILTER=STATE=(7[6789]|8x|9x|100). Ok, elegant ist anders.
- perl Ausdruck: wieso ist folgendes
set Lampe:FILTER={ReadingsValue("Lampe","state","") eq "off"} on
besser bzw. verstaendlicher als
{ if(ReadingsValue("Lampe","state","") eq "off") fhem("set Lampe on") }
ich gebe zu ich habe in meinem posting am anfang noch nicht alles preisgegeben. manche vielleicht noch verworrenen gedanken lassen sich auch schwer in worte fassen...
- dein beispiel für und und oder bezieht sich auf eine regex bzw. werte in einem einzigen reading. ich kann aber nicht zwei unterschiedliche redings mit oder verknüpfen. ganz zu schweigen von klammer ebenen. also z.b. alle devices die entwerde state=on haben oder pct >75. oder die readinsg dim,pct und bri.
- ja. elegant ist anders :) und funktioniert so auch nur bei werten bei denen die obergrenze bekannt ist
- wenn der filter auf fhem ebene angegeben wird kann ich ihn auch per strucutre oder lightScene an die beteiligten devices durch reichen (siehe letztes beispiel aus dem ersten post). das geht nicht wenn ich mich auf der perl ebene bewege. gleiches gilt z.b. auch für einem readingsProxy den ich vor ein device schalte eine priorisierung mehrerer möglicher eingangs kanäle zu einem ergebniss zusammen zu schalten.
set Lampe:Filter={meinSehrKomplexerFilter()} on
es geht also weniger um das aussehen als den wechsel zwischen fhem und perl ebene die beide varianten unterscheidet.
Ich sehe immer noch nicht die richtigen Beispiele, habe aber eval dazugepackt.
Geraetename wird als $NAME (oder %NAME) an die Funktion weitergegeben, und der Rueckgabewert des Ausdrucks wird ausgewertet. Beispiel (nicht wirklich sinnvoll):
list TYPE=FS20:FILTER={Log(1,$NAME);;1}
Passt dir das so?
ist es haare in der suppe suchen wenn ich $DEVICE statt $NAME vorschlagen würde?
dann ist es mit readingsGroup und readingsProxy & co konsistent. $NAME bzw $name ist dort das parent device (also z.b. die readingsGroup selber) und $DEVICE das device um das es gerade geht.
ansonsten danke!
Ja, aber ich habe es eingebaut.
Und ein "Bug" gefixed: FHEMWEB setzt "room=all" ab, und ist ueberrascht, wenn room=all zurueckkommt, weil die alte Version fuer Anfragen mit "=" ein Leerstring zurueckgeliefert hat.
dann noch mal danke.
zu room=all fällt mir ein das es dabei noch das problem mit longpoll gab. ich erinnere mich aber gerade nicht mehr an den stand. mir ist aber gestern erst aufgefallen das es im raum everyting nicht gegangen ist.
schau mal hier: http://forum.fhem.de/index.php/topic,19092.msg127745.html#msg127745 (http://forum.fhem.de/index.php/topic,19092.msg127745.html#msg127745). da wird scheinbar für den | fall zu viel zurück geliefert.
gruss
andre
Hat weniger mit "|" als mit dem "." im Namen zu tun.
devspec2array prueft nach \b<Argument>\b, damit der longpoll-Filter fuer room=X bei Mehrfachraeumen (room=X,Y,Z) greift.
Was ist deine Meinung?
auf die schnelle fällt mir nur ein
\b(?!\.)<Argument>\b(?!\.) statt \b<Argument>\b zu verwenden. das funktioniert zumindest für die fälle bei denen der punkt nicht am ende der regex steht.
richtig sauber ist es aber auch nicht. und ich weiss auch nicht ob das mit allen relevanten perl versionen geht.
[^\B.] wäre vielleicht noch eine weitere unvollständige alternative aber die geht bei mir gar nicht.
oder den room sonderfall explizit machen und im nicht room fall auf ^<Argument>$ prüfen.
Zitatoder den room sonderfall explizit machen und im nicht room fall auf ^<Argument>$ prüfen.
Das erscheint mir am sichersten, habs eingecheckt.
mit dem angehängten patch kann man im set einer structure den filter für devspec mit übergeben und dieser wird dann bei allen set für die einzelnen devices der structure mit angehängt.
man kann so z.b. mitset <structure> [FILTER=STATE=on] offnur genau die devices aus schalten die noch an sind und für alle anderen die funk last vermeiden.
gruss
andre
Eingecheckt.