Einfache Angabe von Reading-Values in notify Commands

[Markus Bloch]

Na ja, es würde nie bei set ankommen bzw. set bla [<Device>.*:...] würde zu Fehlermeldung führen, weil regexp im Devicenamen bei DOIF, z. Zt. nicht erlaubt ist.

Wenn DOIF das schon vorher umsetzt ist das doch kein Problem.

eine Regexp Unterstützung würde ich hier momentan raus lassen. [device:reading] müssen tatsächlich existierende Bezeichnungen sein (keine regexp).

Gruß
Markus

[justme1968]

die auf set beschränkte variante sollte keine auswirkungen auf doif haben. die sind ja komplett unabhängig voneinander.

das einzige das hier eventuell probleme machen könnte wäre ein set das aus einem doif aufgerufen wird. aber ich denke falls hier ein [] ausdruck vorkommt würde der schon vom doif auf die gleiche weise ersetzt und garnicht erst beim set ankommen. sollte also auch gehen.

das mit der inerpolation bezog sich auf das umschreiben von der fhem version in die perl version. ist aber nicht schlimm bzw. jemand der das tut muss ja sowieso wissen was er tut.

das mit dem {} direkt innerhalb eines fhem kommandos gefällt mir besser als ReadingsVal & co. auf fhem ebene einzuabuen.

wenn man die [device:reading] variante einbaut und zusätzlich das {...} dann hätte man glaube ich das beste aus beiden vorschlägen. zum einen eine wirklich kurze variante wenn es nur um ein reading geht und eine die mehr kann.

@Damian: ich glaube immer noch nicht das es um regex innerhalb von device oder reading namen geht. das .* aus rudis erstem vorschlag war nur 'faulheit' alles auszuschreiben.

[rudolfkoenig]

Ich habe im set [name:reading] eingebaut, und auch {} fuer Eval. Damit kann man Unsinn wie

set heating temperature {[heating:temperature]+1}

schreiben. Da mir das beliebige Auswerten solcher Ausdruecke gewagt vorkam, ist das nur mit

attr global featurelevel 5.7

freigeschaltet, default ist 5.6. Ich haette aber lieber eine bessere Alternative, oder irgendwer kann mir zusichern, dass in set ein {}, was nicht ausgewertet wird, nie sinnvoll ist.

Apropos featurelevel: folgendes ist nur bis featurelevel 5.6 aktiviert:
- das Fuellen der $value Hash beim Perl-Befehlen in AnalyzeCommand
- @/% Ersetzung fuer Notify
- lastinclude

[justme1968]

sehr schön. genau die anwendung das set relativ zu einem bestehenden readings wert zu machen ist ist mir auch noch gekommen.


noch ein paar anmerkungen/vorschläge:

wäre es nicht besser den aufruf von ReplaceSetMagic gleich am anfang von CommandSet vor dem split zu machen statt erst später von DoSet aus? das würde pro device dann ein join und ein split in ReplaceSetMagic sparen.

deine variante erlaubt keine leeren readings. ist es tatsächlich so das es diese nicht gibt?

wenn es das reding nicht gibt verschwinden trotzdem die [] um den ausdruck. sollte man die nicht besser beibehalten?

wäre es für die {..} auswertung nicht besser klammerebenen zu zählen? sonst sollte man dokumentieren das innerhalb des ausdrucks keine geschweiften klammern vor kommen dürfen.

für das eval von {..} wäre im fehlerfall eine meldung im log gut. besonders wenn die klammern nicht gematched werden. für die auswertung von des [] vielleicht auch?

das ganze per default abzuschalten ist zwar sicher, aber auch schade. vor allem da beides abgeschaltet ist.
was das zusichern angeht: mir fällt keine anwendung ein bei der das bis jetzt verwendet worden wäre. aber das heisst nichts

[rudolfkoenig]

Das ist aber sehr hoeflich gewesen.

- ReplaceSetMagic vorne: wuerde mAn zu haeufig fuer "set X ?" aufgerufen. Set sollte sonst nicht soo haeufig aufgerufen werden.
- []/{} wird im "Fehlerfall" jetzt wieder hinzugefuegt.
- wie zaehlt man Klammern?
- habe Logging im Fehlerfall eingebaut.

[justme1968]

ich hab doch keinen grund unhöflich zu sein


zum klammern zählen schaue ich mir für readingsGroup gerade drei varianten an:

- es geht per regex und rekursion und/oder backtracking.
  das wäre am kürzesten zum hinschreiben aber das ist mir zu undurchsichtig

- es geht natürlich ganz altmodisch per schleife über alle zeichen und selber zählen.

- es gibt das Text::Balanced modul das ich mir gerade für readingsGroup anschaue.
  das gibt es ab perl 5.8 und es scheint mir am einfachsten.

[Reinerlein]

Hallo zusammen,

jetzt muss ich doch noch mal mitsprechen.
Ich habe im Sonos-Modul einige Set-Anweisungen, die einen textuellen Perl-Hash (also einen String, der zu einem Hash evaluiert werden kann) annehmen, der dann vom Modul interpretiert und verarbeitet wird...

Nun versucht der Set also den {}-Ausdruck zu verarbeiten und gibt was genau weiter?
Wenn es nicht gelingt (ist ein gültiger Perl-Hash ein "nicht-gelingen"?) wird der komplette String an den entsprechenden Setter des Moduls weitergereicht?

Sorry für diese Fragen, ich kann mir das gerade nicht im Quelltext anschauen...
Danke schon mal.

Grüße
Reinerlein

[justme1968]

das wird im feature level 5.7 vermutlich tatsächlich schief gehen.

vorschlag: den wert in ReplaceSetMagic nur dann zuweisen wenn ref auf das eval ergebnis einen leeren string liefert.

[rudolfkoenig]

Ich habe im Sonos-Modul einige Set-Anweisungen, die einen textuellen Perl-Hash (also einen String, der zu einem Hash evaluiert werden kann) annehmen, der dann vom Modul interpretiert und verarbeitet wird...

Kannst du das bitte mit einem Beispiel demonstrieren?

[Reinerlein]

Hallo,

das wäre aber ja blöd
Und wie sähe es aus, wenn das Modul einen Marker setzen könnte, ob diese Auswertung gemacht werden soll oder nicht?
Dann könnte man das zumindest mal im Modul entscheiden.

Oder könnte man eine Erweiterung der bereits jetzt vorhandenen Steuerung für die Fhemweb-Widgets machen, und dort angeben, ob eine Perl-Auswertung vorher zulässig ist, oder nicht?
Dann könnte man es sogar für jede set-Anweisung getrennt festlegen, was überhaupt das beste wäre, da es in meinem Modul ja nur ein paar Anweisungen beträfe. Dann könnte der Anwender für alle anderen Setter dieses neue Feature immer noch nutzen (was sicherlich praktisch wäre)...

Grüße
Reinerlein

[justme1968]

der ref vorschlag sollte das eigentlich alles abdecken ohne so viele manuelle eingriffe

[Reinerlein]

Hi Rudi,

es geht hier eigentlich nur um die Alarmverarbeitung (die anderen von mir gedachten Setter verwenden eckige Klammern) Dort gibt es die Möglichkeit einen Alarm anzulegen oder zu verändern. Dabei werden die möglichen Parameter als Hash mitgegeben (so wie bei der ReadingsGroup sowas als Attribut abgelegt werden kann):

Code Auswählen Erweitern


set Sonos_Wohnzimmer Alarm Update 17 { Shuffle => 1 }

oder

Code Auswählen Erweitern


set Sonos_Wohnzimmer Alarm Update 17 { Shuffle => 1, Enabled => 1, Volume => 10 }


Und das würde mit der Ref-Prüfung klappen? Ich dachte, der würde hier bei eval eine Referenz auf einen Hash zurückgeben, womit ref doch true liefern würde, oder?

Grüße
Reinerlein

[justme1968]

die idee ist das egal ergebnis nur dann in das set einzusetzen wenn es ein string ist. wenn beim eval ein hash raus kommt dann wird das ergebnis verworfen und der klammer inhalt ohne eval unverändert durchgereicht.

[rudolfkoenig]

Mit featurelevel 5.7 hagelt es z.Zt. an Fehler wie

Code Auswählen Erweitern

Useless use of a constant ("Shuffle") in void context

Nach einem Umbau, der den eval immer mit {} ausfuehrt, scheint es mit der ref($x) eq "HASH" Pruefung zu funktionieren.
Wuesste ich gerne, wonach perl entscheidet, ob das Ergebnis ein String (return aus dem Codeblock) oder ein HASH sein soll.
Ich fuehle mich weiterhin sehr unwohl mit {}, und bin nicht sicher, dass es bleibt.

Ein Modul oder set Argument abhaengige Evaluirung finde ich falsch, entweder funktioniert es ueberall, oder nirgends.

[UliM]

$value{x}, % und @ wird nur noch bei aktivierten Attribut (compatibility < 5.6) ersetzt.

Oha. Das sollte eine Ankündigung im Forum wert sein - vielleicht hab ich die verpasst.

Hab mit dem hier Diskutierten nicht getestet, frage mich aber, ob man für notify nicht ohne Klammer auskäme:
device:regexp als Bedingung für notify gibt's schon lang.
device:reading:regexp könnte neu sein, also bei 2x ':' in der Bedingung wird ein reading erwartet. Für set ginge das natürlich nicht, Ber zumindest ich persönlich hab seltenst den Bedarf, mit Reading-Werten zu rechnen.
(Falls diese Idee total off ist, bitte eher ignorieren als mit hämischen Kommentaren versehen

Gruß,
Uli