FT55 buttons.*pressed

Begonnen von Spartacus, 31 März 2014, 22:46:50

Vorheriges Thema - Nächstes Thema

Spartacus

Hallo,
habe einen FT55 und möchte das Drücken eines bestimmten Tasters auswerten
Mit
define pressedNotify notify EnO_Sw_01:buttons.*pressed set <device> on
reagiert das Modul auf alle tastendrucke. Ich möchte aber AI,A0,BI,BO unterscheiden. Muss ich das mit einer nachstehenden "if-Anweisung" abfangen, oder gibt es einen direkten Weg   z.B. buttonsA0.pressed/released reagieren.

Spartacus.
Fhem-System: 1 x raspberry PI Typ B, 1 x enOcean PI Typ B | Enocean: PTM210, FMS61NP, FAM14, 2 x FSR14-4x, FTS14-EM | LaCrosse: 2 x TX29D über Jeelink V3 | 1-Wire: 2 x DS18B20 über DS9490R

peter79

#1
Hi,

bin bei diesem Thema auch fast verzweifelt und bin durch zwei Foren Beiträge bei folgendem gelandet (such mal nach "PTM 215", dies ist das Funkmodul...)

Hier mal zwei Beispiele, wie ich meine Sonos-Boxen mit einer FHM8 Fernbedienung steuere (ist das gleiche Funkmodul, wie bei Dir...):

define EnO_switch_FB1_1 EnOcean FFFFFEAA
attr EnO_switch_FB1_1 room EnOcean
attr EnO_switch_FB1_1 subType switch

define EnO_FB1_1_1_Stop_Start notify EnO_switch_FB1_1 { my $rvar=Value("EnO_switch_FB1_1") ;; \
        if ($rvar =~ m/B0/) { fhem "set Sonos_Bad Stop" } \
        elsif ($rvar =~ m/BI/) { fhem "set Sonos_BA on" ;; fhem "set Sonos_Bad Play" } \
        }
define EnO_FB1_1_2 notify EnO_switch_FB1_1:.*channel.*A.* { fhem("set Sonos_Bad ".($EVENT=~m/A0/ ? "VolumeD" : "VolumeU")) }



IMHO irgendwie etwas umständlich, aber es funktioniert (hatte meine ich aber auch hauptsächlich Probleme, da meine Tastendrücke durch eingesetzte Repeater öfters ankamen...).
Falls jemand eine einfachere Lösung hat, so bitte her damit  ::)

Viele Grüße
Peter

Spartacus

Hallo,
danke Peter, das sieht gut aus und werde ich mal testen...

Habe derzeit noch ein anderes Problem mit meinem Aktor und dem Schalter. Irgendwie kommen die Bestätigungstelegramme des Aktors nur sehr verzögert in fhem an. Das verhindert ein "schnelles" Schalten, da ich den Zustand des Aktors vorher abfrage.. (http://forum.fhem.de/index.php/topic,19763.msg155023.html#new)

Spartacus

Fhem-System: 1 x raspberry PI Typ B, 1 x enOcean PI Typ B | Enocean: PTM210, FMS61NP, FAM14, 2 x FSR14-4x, FTS14-EM | LaCrosse: 2 x TX29D über Jeelink V3 | 1-Wire: 2 x DS18B20 über DS9490R

peter79

mmh - bei EnOcean2EnOcean nutze ich eigentlich auch nur Direktverbindungen und lerne FHEM zusätzlich in den Aktoren an (bei Dimmern hat man so z.B. den Vorteil, dass diese dann auch vernünftig funktionieren und alles funktioniert auch noch ohne FHEM...). Gibt es einen bestimmten Grund, warum Du FHEM dazwischen haben musst? Oder hab ich jetzt was falsch verstanden...

Spartacus

Hi,
neee! Eigentlich nicht! ... aber es ist schon so, wie tinyfhem sagt: Wenn man etwas an der Konfiguration des Aktors ändern muss, so muss man erst die Schalterdose aufmachen um einen neuen Taster o.a. einzulernen. Das ist schon recht aufwändig.

Aber Du hast natürlich recht! Wenn fhem abstürzt, funktioniert nichts mehr!  GGf. werde ich auf eine Kombination der beiden Möglichkeiten setzten (an schlecht zu erreichenden Stellen z.B. eine Schrankbeleuchtung, wo der Aktor hinter dem Schrank sitzt und es unkritisch ist, wenn fhem mal nicht verfügbar ist). Das setzt allerdings voraus, dass es sauber funktioniert.

Es ist aber schon interessant, warum das bei mir nicht richtig klappt. Ist das ein Problem von meiner Installation oder ggf. sogar "normal" dass das Bestätigungstelegram so lange auf sich warten lässt. Ich hätte erwartet, dass es ohne merkliche zeitliche Verzögerung abläuft.

Spartacus
Fhem-System: 1 x raspberry PI Typ B, 1 x enOcean PI Typ B | Enocean: PTM210, FMS61NP, FAM14, 2 x FSR14-4x, FTS14-EM | LaCrosse: 2 x TX29D über Jeelink V3 | 1-Wire: 2 x DS18B20 über DS9490R

tinyfhem

Zitat von: Spartacus am 02 April 2014, 09:50:43
Hi,
neee! Eigentlich nicht! ... aber es ist schon so, wie tinyfhem sagt: Wenn man etwas an der Konfiguration des Aktors ändern muss, so muss man erst die Schalterdose aufmachen um einen neuen Taster o.a. einzulernen. Das ist schon recht aufwändig.

Aber Du hast natürlich recht! Wenn fhem abstürzt, funktioniert nichts mehr!  GGf. werde ich auf eine Kombination der beiden Möglichkeiten setzten (an schlecht zu erreichenden Stellen z.B. eine Schrankbeleuchtung, wo der Aktor hinter dem Schrank sitzt und es unkritisch ist, wenn fhem mal nicht verfügbar ist). Das setzt allerdings voraus, dass es sauber funktioniert.

Es ist aber schon interessant, warum das bei mir nicht richtig klappt. Ist das ein Problem von meiner Installation oder ggf. sogar "normal" dass das Bestätigungstelegram so lange auf sich warten lässt. Ich hätte erwartet, dass es ohne merkliche zeitliche Verzögerung abläuft.

Spartacus
Also ich gehe konsequent den indirekten Weg uber FHEM. Ich will auch mal einen Eltako (EnOcean-) Aktor mit einem billigen FS20 Taster schalten koennen wenn mir danach ist. Ich habe meine Eltako Aktor so aufgesetzt, dass er auch noch ueber konventionelle elektrische Taster geschaltet werden kann, das tut auch dann wenn FHEM nicht laeuft. Ich koennte in dem Fall dann eben komplexere Szenen nicht aufsetzen, z.B. das Licht zeitgesteuert wieder ausschalten oder zusammen mit diesem Licht auch noch andere Verbraucher ein oder aus schalten.
FHEM auf Raspberry Pi, EnOcean Pi, HomeMatic LAN Konfigurations Adapter, CUL 868 V3, CUL 433 V3

klaus.schauer

Zitat von: Spartacus am 02 April 2014, 08:22:05
Habe derzeit noch ein anderes Problem mit meinem Aktor und dem Schalter. Irgendwie kommen die Bestätigungstelegramme des Aktors nur sehr verzögert in fhem an. Das verhindert ein "schnelles" Schalten, da ich den Zustand des Aktors vorher abfrage..
Die Verzögerungen bei den Quittungstelegrammen der Aktoren und beim Senden in Fhem sind gewollt. Die Eltako Aktoren senden die Quittungstelegramme erst nach 200 ms und mehr. Fhem sendet EnOcean-Telegramme auch nur alle 200 ms. Die Verzögerung in Fhem ist notwendig, da die Empfänger bei einer schnelleren Sendefolge häufig nicht reagiert haben. Weiterhin kann das Senden der Funktelegramme durch den Transceiver verzögert werden, falls der Funkkanal belegt ist. In welchem Umfang die interne Abarbeitung der Prozeduren in Fhem den Ablauf noch weiter verzögert, lässt sich schwer sagen. Eine "Echtzeitverarbeitung" in ms darf man von Fhem aber auch nicht erwarten!

Spartacus

Hallo Klaus,
Besten Dank für die Erklärung. Das erklärt die Verzögerung und deutet nicht auf einen Defekt bzw. eine fehlerhafte Konfiguration hin. Das bedeutet aber auch, dass dieser Weg der Ansteuerung nicht optimal ist und die direkte Verbindung zwischen Sender und Aktor für solche Schaltvorgänge die bessere Wahl ist.

Schade!
Spartacus

Fhem-System: 1 x raspberry PI Typ B, 1 x enOcean PI Typ B | Enocean: PTM210, FMS61NP, FAM14, 2 x FSR14-4x, FTS14-EM | LaCrosse: 2 x TX29D über Jeelink V3 | 1-Wire: 2 x DS18B20 über DS9490R