Problem mit eventMap

[rtv]

Hallo!

Für meine HomeMatic Lampen verwende ich zum Teil eine Syntax wie diese:

Code Auswählen Erweitern

/on-for-timer 000100:Minute/on:An/off:Aus
Das ist praktisch für Dinge wie "webcmd An:Minute:Aus".


Wenn ich das bei TRX-Geräte versuche, erhalte ich mit aktuellem SVN diesen Fehler:

Wrong timespec 01: either HH:MM:SS or {perlcode}

Sinngemäß müsste ich also die Syntax in das hier ändern:

Code Auswählen Erweitern

/on-for-timer 00:01:00:Minute/on:An/off:Aus

Dann bekomme ich beinahe erwartungsgemäß:

Unknown command Minute, choose one of all_off all_on chime off on on-till on-for-timer

Hier müsste entweder der Parser nach dem letzten Doppelpunkt vor einem Slash suchen oder Escapen ermöglichen.


Vermutlich könnte ich auch eine Perl-Funktion ohne Doppelpunkte für das eventMap als workaround nutzen?
Wie ist das empfohlene Vorgehen?
Kann man das on-for-timer Handling geräteübergreifend vereinheitlichen?

[Willi]

Hallo,

mit webcmd-Syntax kann ich Dir nicht helfen. Ich habe webcmd noch nie verwendet.

Ich habe damals on-for-timer gemäß Vorlage des X10-Moduls verwendet, welches schon viel länger als der der Homematic-Code existiert.

Daher steht im commandref dazu:
"on-for-timer requires a relative time in the "at" format (HH:MM:SS, HH:MM) or { <perl code> }, where the perl code returns a time specification)."

Wenn man sich einigen könnte on-for-timer bei allen Modules gleich zu handhaben, wäre ich natürlich dabei.
Eine solche Änderung bedeutet allerdings, dass dann die User umstellen müssten, die on-for-timer bei TRX_LIGHT bereits benutzen.

-- Willi

[rtv]

Hallo Willi!

Ich habe damals on-for-timer gemäß Vorlage des X10-Moduls verwendet

Wenn der gleiche eventMap Parser für alle Module verwendet wird, dann dürfte das bei X10 ja aktuell auch nicht funktionieren.

"on-for-timer requires a relative time in the "at" format (HH:MM:SS, HH:MM) or { <perl code> }, where the perl code returns a time specification)."

Wie müsste eine Funktion aussehen, der ich einen String als Anzahl Sekunden (damit ich keinen Doppelpunkt als Delimiter habe) übergebe und dann diese Spec zurück bekomme?

Wenn man sich einigen könnte on-for-timer bei allen Modules gleich zu handhaben, wäre ich natürlich dabei.
Eine solche Änderung bedeutet allerdings, dass dann die User umstellen müssten, die on-for-timer bei TRX_LIGHT bereits benutzen.

Hm, als Außenstehender würde ich annehmen, dass der Widerstand am geringsten ist, wenn sich die Konvention an den verbreitetsten Modulen (FS20/Homematic) orientiert.
Ein "breaking change" wäre sicherlich ärgerlich, aber das ist hier ja eigentlich nicht der Fall: Die direkte Zeitangabe ist aufgrund des Doppelpunktes derzeit gar nicht möglich. Falls jemand als Workaround { <perl code> } verwendet, dann würde das ja auch in Zukunft noch funktionieren?

Schöne Grüße, Ralf

[Willi]

H
Wenn der gleiche eventMap Parser für alle Module verwendet wird, dann dürfte das bei X10 ja aktuell auch nicht funktionieren.

Wenn Du es auf dieselbe Weise probierst, dann vermutlich.
Allerdings lassen sich Deine Probleme evtl. mit einer Maskierung des Doppelpunktes (z.B. \: oder anderes) lösen. Ich bin nicht der Perl-Freak, um genau zu wissen, welche Maskierung funktioniert.ö Im Zweifel probieren oder den Autor von webcmd fragen.

Hm, als Außenstehender würde ich annehmen, dass der Widerstand am geringsten ist, wenn sich die Konvention an den verbreitetsten Modulen (FS20/Homematic) orientiert.
Ein "breaking change" wäre sicherlich ärgerlich, aber das ist hier ja eigentlich nicht der Fall: Die direkte Zeitangabe ist aufgrund des Doppelpunktes derzeit gar nicht möglich. Falls jemand als Workaround { <perl code> } verwendet, dann würde das ja auch in Zukunft noch funktionieren?

Das stimmt so m.E. leider nicht. Man kann es verwenden und es funktioniert.

Einige Module verwenden eine Angabe in Sekunden ohne Struktur. Andere (TRX_LIGHT, X10, ..) machen das über eine Angabe von HH:MM:SS bzw. HH:MM . HH:MM:SS ist keine absolute Zeit, sondern ein Offset in der Form HH:MM:SS. Also wäre 1 Stunde und 2 Minuten als 01:02:00 zu schreiben. Bei FS20 schreibt man das als 3720 (1*60*60 + 2*60).

Dein Homematic-Beispiel mit 000100 gemäß commandref wären demnach 100 Sekunden also 00:01:40 (1 Minute 40 Sekunden).

Jeder kann selbst bestimmen was besser ist. Die Form HH:MM:SS ist zumindest für den Menschen besser lesbar.

Wie dem auch sei, wir müssten erst mal eine Konvention festlegen, die für alle Module gelten soll.

-- Willi

[rtv]

Allerdings lassen sich Deine Probleme evtl. mit einer Maskierung des Doppelpunktes (z.B. \: oder anderes) lösen. Ich bin nicht der Perl-Freak, um genau zu wissen, welche Maskierung funktioniert.ö Im Zweifel probieren oder den Autor von webcmd fragen.

Eine Maskierung mit \ führt zum Tod von fhem.
/ fungiert als Element-Trenner.
Jegliche Form von Hochkomma, Anführungszeichen, etc führt dazu, dass der Ursprungsbefehl on-for-timer seinen Parameter vermisst.

Btw: Du schreibst zum zweiten Mal "webcmd". Das war nur ein Anwendungsbeispiel. Der Bug verhindert aber generell die Nutzung von eventMap und on-for-timer mit TRX (und dann auch X10). Das diese Kombination bei FS20/HM gängiger ist, liegt vor allem daran, dass sie dort häufig für Rolladensteuerungen benötigt wird.

Jeder kann selbst bestimmen was besser ist. Die Form HH:MM:SS ist zumindest für den Menschen besser lesbar.

Wie dem auch sei, wir müssten erst mal eine Konvention festlegen, die für alle Module gelten soll.

Richtig. Darum ist Projekt-Management auch bei Open-Source-Projekten wichtig :)
Ich persönlich finde die at-Syntax ja auch logischer und in diesem Zusammenhang intuitiver nutzbar. Wenn die beiden "großen" Systeme nicht kaputt gemacht werden sollen gäbe es ja noch zwei Alternativen:
1. Die OSS-Variante: Alle implementieren alle Varianten (also Sekunden und at-Spec)-> Aus Wartungsgründen nicht empfehlenswert und würde den Programmierern wohl keinen Spaß machen, wenn sie es selber nicht benötigen.
2. Fixen des Parsers (suche den jeweils letzten Doppelpunkt vor dem Slash statt des ersten), damit auch TRX und X10 die Befehle nutzen können.

[Willi]

Hallo,

ok, ich habe jetzt verstanden, dass Du schon fast alles probiert hast. Danke!

Was mir adhoc-einfällt.

Hast Du mal probiert folgendes anzugeben:

 /on-for-timer 00\x3a01\x3a00:Minute/on:An/off:Aus

Sieht nicht schön aus, ist aber Variante, die bei Problemen mit : bei gplot hilft.

Ich überlege mir mal, ob ich die OSS-Variante (also zusätzlich zur bestehenden Syntax auch ohne : in Sekunden) implementiere. Das ist vermutlich weniger Aufwand als ..........

Ich kann allerdings noch nicht versprechen, wann ich dazu komme.

Grüße

Willi

[rtv]

Hallo!

Danke für den Hinweis, mit dieser Variante überlebt FHEM aber ich bekomme leider wieder:

Wrong timespec 00\x3a01\x3a00: either HH:MM:SS or {perlcode}

Mir fällt gerade auf, dass ich im ersten Beitrag einen Fehler hatte: on-for-timer 000100 sind natürlich 100 Sekunden, auch wenn mein Beispiel von einer Minute spricht. Aber das hattest du so glaub' ich auch verstanden.

Schöne Grüße, Ralf

[juppzupp]

Bin ich auch gerade drüber gestolpert, zumindest bei webCmd funktioniert masquerading über %3A :

Code Auswählen Erweitern

attr flurlicht webCmd     on:off:on-for-timer 00%3A10

[ronny332]

Das Problem ist schon recht alt, dennoch kann man an dieser Stelle FHEM "super" abschiessen:

eine Eventmap mit

/on-for-timer 00\:00\:01:on9000/

schiesst den komplette Perl Prozess mit einem

Trailing \ in regex m/00\/ at fhem.pl line 3390.

ins Nirvana .

Sicherlich ist der Ausdruck vermutlich nicht im Sinne des Erfinders, dennoch finde ich keinen Ansatz wie man einen Timer (hier für TRX_LIGHT) mit einer passenden Dauer in eine Eventmap packt.