Wie erfaehrt FHEM dass ein Aktor manuell geschaltet wurde?

Begonnen von tinyfhem, 04 Februar 2014, 18:25:09

Vorheriges Thema - Nächstes Thema

tinyfhem

Bin noch voellig neu in der Thematik und habe wie folgt begonnen:

1 x Raspberry Pi
1 x EnOcean Pi
1 x Eltako Funktaster FT55
1 x Eltako Funkaktor FSR61

Habe den Funktaster einfach betaetigt und per autodefine konfigurieren lassen:

define switch1 EnOcean FEFF2D58
attr   switch1 room EnOcean
attr   switch1 subType switch

Dann habe ich den Funkaktor definiert und angelernt:

define actuator1 EnOcean FF9AAE81
attr   actuator1 eventMap BI:off B0:on
attr   actuator1 room EnOcean
attr   actuator1 subType switch

Dann die Quittungen des Aktors eingeschaltet und im FHEM definiert:

define actuator1_ack EnOcean 0187970B
attr   actuator1_ack room EnOcean
attr   actuator1_ack subType switch

Damit der Taster nun den Aktor ansteuert habe ich folgendes definiert:

define switch1notify notify switch1 set actuator1 $EVENT

Wenn ich nun den Funktaster in die eine Richtung druecke, geht der Aktor an wie er soll. In die andere Richtung  gedrueckt, geht er aus wie er soll.

Soweit so gut, funktioniert alles wie erwartet. Nun hat aber der Funkaktor auch noch einen weiteren Eingang, ueber den er konventionell durch einen elektrischen Schalter im toggle-Betrieb umgeschaltet werden kann.

Wenn ich das nun mache, kommen auch die entsprechenden "actuator1_ack" datagrams beim FHEM an, allerdings erfolgt in FHEM selbst keine Zustandsaenderung von "actuator1". Wie macht man das, dass FHEM "merkt" (und umsetzt), dass der Aktor "von Hand", also elektrisch getriggert wurde?

Ich habe mal noch folgendes notify gesetzt, die Idee war, dass ich auf das Datagram reagiere, das der Aktor sendet, wenn er von Hand getriggert wurde:

define switch2notify notify actuator1_ack set actuator1 $EVENT

Grundsaetzlich hat das dann auch dazu gefuehrt, dass FHEM das mitbekommen hat, es hat dann natuerlich seinerseits wieder auf den actuator1 ein "ON" geschickt und es kam wieder eine Quittung, d.h. das ganze fing an zu schwingen und hat nur deshalb wieder aufgehoert, weil wahrscheinlich irgendwann mal auf einer der beiden Seiten ein Datagram nicht mehr verarbeitet werden konnte.
FHEM auf Raspberry Pi, EnOcean Pi, HomeMatic LAN Konfigurations Adapter, CUL 868 V3, CUL 433 V3

Wernieman

"set" ist hier nicht richtig. Es gibt ein Ähnlichen Befehl, bitte schaue in die Doku, bei dem eben der Tricker nicht ausgelöst wird!
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Puschel74

Hallo,

setstate sollte passen anstelle von set.
Ich kann mich aber auch täuschen.

Grüße
Zotac BI323 als Server mit DBLog
CUNO für FHT80B, 3 HM-Lan per vCCU, RasPi mit CUL433 für Somfy-Rollo (F2F), RasPi mit I2C(LM75) (F2F), RasPi für Panstamp+Vegetronix +SONOS(F2F)
Ich beantworte keine Supportanfragen per PM! Bitte im Forum suchen oder einen Beitrag erstellen.

tinyfhem

#3
Zitat von: Puschel74 am 04 Februar 2014, 19:26:17
Hallo,

setstate sollte passen anstelle von set.
Ich kann mich aber auch täuschen.

Grüße

die Verwendung von "setstate" hat dazu gefuehrt, dass bei Schaltung im UI, also klick auf "on" / "off" das icon der Lampe zunaechst gezeigt wurde und dann unmittelbar ueberschrieben wurde durch "BI" und "B0". Der Aktor wurde dabei korrekt geschaltet und wenngleich auch das icon im UI nicht mehr da war, so wurde offensichtlich der Zustand "BI/ B0" von FHEM korrekt uebernommen.

Bei Schaltung mit dem Funktaster ("switch1"). Blieb das Lampen-Icon erhalten und signalisierte den korrekten Zustand.

Bei Schaltung ueber den elektrischen Kontakt am Aktor, passierte in FHEM keine Reaktion, ausser dass das ankommende "ACK" im Log erschien.

Update: Es sieht so aus, als ob in dem Fall, in dem ich ueber den elektrischen Kontakt schalte, einfach nur am UI kein screen update durchgefuehrt wird. Druecke ich am Browser "F5" oder "Reload", wird der richtige Zustand angezeigt. Allerdings das Lampen-icon fehlt dann trotzdem noch.
FHEM auf Raspberry Pi, EnOcean Pi, HomeMatic LAN Konfigurations Adapter, CUL 868 V3, CUL 433 V3

klaus.schauer

Zitat von: tinyfhem am 04 Februar 2014, 18:25:09
define actuator1 EnOcean FF9AAE81
attr   actuator1 eventMap BI:off B0:on
attr   actuator1 room EnOcean
attr   actuator1 subType switch

define actuator1_ack EnOcean 0187970B
attr   actuator1_ack room EnOcean
attr   actuator1_ack subType Switch
Das geht für Aktoren, die Quittungstelegramme senden, einfacher:
- Quittungstelegramme am Aktor einschalten und lokalen Taster betätigen.
- fhem richtet dann das Device ein
- attr subDef mit Fhem Sender-ID hinzufügen

Ergebnis:

define actuator1 EnOcean 0187970B
attr actuator1 room EnOcean
attr actuator1 subDef FF9AAE81
attr actuator1 subType switch


Danach Fhem im Aktor anlernen.

tinyfhem

Zitat von: klaus.schauer am 05 Februar 2014, 06:37:18
Das geht für Aktoren, die Quittungstelegramme senden, einfacher:
- Quittungstelegramme am Aktor einschalten und lokalen Taster betätigen.
- fhem richtet dann das Device ein
- attr subDef mit Fhem Sender-ID hinzufügen

Ergebnis:

define actuator1 EnOcean 0187970B
attr actuator1 room EnOcean
attr actuator1 subDef FF9AAE81
attr actuator1 subType switch


Danach Fhem im Aktor anlernen.
fuer exakt welches "define" muss das Attribut "subDef FF9AAE81" gesetzt werden? So wie Du es im code snippet zeigtst, ist es fuer den actuator1 angegeben, der hat aber nicht die ID "0187970B". Die ID "0187970B" gehoert zu definition actuator1_ack. actuator1 hat die FF9AAE81 (= baseid + 1).  Jedenfalls habe ich das Attribut subDef FF9AAE81 nun mal fuer actuator1_ack gesetzt und das Verhalten war in keiner Weise anders als ohne dieses Attribut. (actuator1_ack bezeichnet das Quittungstelegramm, das von actuator1 zurueck geschickt wird).

Was bewirkt das "subDef" denn genau? Wenn ich in der FHEM command reference in der Deutschen Version nach "subDef" suche, wird der Begriff ueberhaupt nicht gefunden. In der Englischen Version wird er zwar gefunden aber eine echte Erklaerung was das subDef bewirkt, finde ich nirgends.

Wie kommt es eigentlich, dass in der Weboberflaeche dem "actuator1" das Lampen-icon zugewiesen wird? Ist das ein default? Und wenn ja, wie kann es dann sein, dass es dann beim schalten des aktors durch direkte elektrische ausloesung, verschwindet und nur noch "BI" bzw "B0" angezeigt wird?
FHEM auf Raspberry Pi, EnOcean Pi, HomeMatic LAN Konfigurations Adapter, CUL 868 V3, CUL 433 V3

klaus.schauer

Zitat von: tinyfhem am 06 Februar 2014, 13:44:20
fuer exakt welches "define" muss das Attribut "subDef FF9AAE81" gesetzt werden? So wie Du es im code snippet zeigtst, ist es fuer den actuator1 angegeben, der hat aber nicht die ID "0187970B". Die ID "0187970B" gehoert zu definition actuator1_ack. actuator1 hat die FF9AAE81 (= baseid + 1).  Jedenfalls habe ich das Attribut subDef FF9AAE81 nun mal fuer actuator1_ack gesetzt und das Verhalten war in keiner Weise anders als ohne dieses Attribut. (actuator1_ack bezeichnet das Quittungstelegramm, das von actuator1 zurueck geschickt wird).
actuator1_ack wird nicht benötigt, falls subDef verwendet wird.
Zitat
Was bewirkt das "subDef" denn genau? Wenn ich in der FHEM command reference in der Deutschen Version nach "subDef" suche, wird der Begriff ueberhaupt nicht gefunden. In der Englischen Version wird er zwar gefunden aber eine echte Erklaerung was das subDef bewirkt, finde ich nirgends.
Mit Hilfe dieses Parameters wird die SenderID festgelegt, die für dieses Device von Fhem gesendet wird.
Zitat
Wie kommt es eigentlich, dass in der Weboberflaeche dem "actuator1" das Lampen-icon zugewiesen wird? Ist das ein default? Und wenn ja, wie kann es dann sein, dass es dann beim schalten des aktors durch direkte elektrische ausloesung, verschwindet und nur noch "BI" bzw "B0" angezeigt wird?
Für on, off und andere Inhalte der Reading gibt es Icons, die automatisch eingeblendet werden. Für z. B. BI aber nicht.

kinne_001

Zitat von: tinyfhem am 06 Februar 2014, 13:44:20

Was bewirkt das "subDef" denn genau? Wenn ich in der FHEM command reference in der Deutschen Version nach "subDef" suche, wird der Begriff ueberhaupt nicht gefunden. In der Englischen Version wird er zwar gefunden aber eine echte Erklaerung was das subDef bewirkt, finde ich nirgends.



Ich versuchs mal mit meinem "Anfängerverständnis" aus eigener Erfahrung:

Nachdem ich FHEM eingerichtet habe, wurde der erste Eltako-Aktor (Dimmer) in FHEM eingelernt... Vorlagen zur cfg, falls man das manuell machen möchte, gibts hier im Forum genug.. SubDef hat sich mir nicht erschlossen, hat ja funktioniert den Dimmer zu steuern.

Dann habe ich weitere Dimmer per copy und paste in der cfg von FHEM angelegt. Jeder schön in der define mit seiner Aktor-ID und ohne SubDef... Einlernen am Aktor hat auch funktioniert.

PROBLEM: jedes mal wenn ich über FHEM einen Dimmer steuerte wurden ALLE angesprochen... bin verzweifelt... da kam SubDef ins Spiel.  Mein USB Stick - also das Teil, was die Sensorinformationen empfängt und an Aktoren Steuerbefehle sendet am FHEM, hat eine eigene Kennung "FF0FF000".  Die Dimmer haben immer diese einzige Kennung angelernt und daher alle auf jeden FHEM Befehl reagiert!

Lösung: Subdef als attr. in dem jeweiligen define Abschnitt für jeden Dimmer der cfg.  Also Dimmer1 SubDef FF0FF001, Dimmer2 SubDef FF0FF002 etc... und siehe da -> jeder Dimmer wird einzeln und exklusiv angesprochen.  Seit dem weiß ich für was SubDef gut ist.

Grüße K.

tinyfhem

Zitat von: klaus.schauer am 06 Februar 2014, 15:55:48
actuator1_ack wird nicht benötigt, falls subDef verwendet wird.Mit Hilfe dieses Parameters wird die SenderID festgelegt, die für dieses Device von Fhem gesendet wird.Für on, off und andere Inhalte der Reading gibt es Icons, die automatisch eingeblendet werden. Für z. B. BI aber nicht.
Also wenn ich die Definition des actuator1_ack komplett entferne, dann wird sofort per autocreate ein neues angelegt. Es heisst dann erstmal nicht actuator1_ack sondern "EnO_switch_0187970B", die definition ist ansonsten identisch zu dem was ich als actuator1_ack hatte, was auch kein Wunder ist, hatte ich es auch zu Anfang schon per autocreate erstellen lassen und nur nach actuator1_ack renamed zur (fuer mich) besseren Lesbarkeit. Wenn ich mir jetzt die Definition von actuator1 anschaue, dann verstehe ich das subDef nach wie vor nicht, denn die Information dahinter erscheint mir redundant:

define actuator1 EnOcean FF9AAE81
attr actuator1 eventMap BI:off B0:on
attr actuator1 room EnOcean
attr actuator1 subDef FF9AAE81
attr actuator1 subType switch


Die BaseID ist  "TCM TCM310 BaseID=FF9AAE80". Das letzte digit habe ich fuer das define von actuator1 von "0" auf "1" hoch gesteppt und wenn da jetzt dieselbe ID (FF9AAE81) im selben define noch mal als attr subDef auftaucht, dann erschliesst sich mir hier der Sinn nicht.

Fuer mich ist das das erste Lernbeispiel und es koennte aus meiner Sicht nicht simpler sein und dennoch funktioniert es nicht, deshalb moechte ich nochmal die Konfiguration beschreiben, was sie tun soll, und was sie wirklich tut:

1 x Raspi / FHEM 5.5
1 x EnOcean Pi
1 x Eltako Funktaster FT55
1 x Eltako Schaltaktor FSR61

#----------------------------
# EnOcean Pi
# TCM TCM310 BaseID=FF9AAE80

define TCM310 TCM 310 /dev/ttyAMA0@57600
attr TCM310 alias EnOcean Pi
attr TCM310 icon cul

#---------------------------------
# Funktaster (per autocreate)
define switch1 EnOcean FEFF2D58
attr switch1 room EnOcean
attr switch1 subType switch

define FileLog_switch1 FileLog ./log/switch1-%Y.log switch1
attr FileLog_switch1 logtype text
attr FileLog_switch1 room EnOcean

#---------------------------------
# Funkaktor (mit subDef, wie von Klaus vorgeschlagen)

define actuator1 EnOcean FF9AAE81
attr actuator1 eventMap BI:off B0:on
attr actuator1 room EnOcean
attr actuator1 subDef FF9AAE81
attr actuator1 subType switch

define FileLog_actuator1 FileLog ./log/actuator1-%Y.log actuator1
attr FileLog_actuator1 logtype text

#---------------------------------

define EnO_switch_0187970B EnOcean 0187970B
attr EnO_switch_0187970B room EnOcean
attr EnO_switch_0187970B subType switch
define FileLog_EnO_switch_0187970B FileLog ./log/EnO_switch_0187970B-%Y.log EnO_switch_0187970B
attr FileLog_EnO_switch_0187970B logtype text
attr FileLog_EnO_switch_0187970B room EnOcean

#---------------------------------
# switch1notify fuehrt dazu, dass der Funktaster den Funkaktor schaltet
# switch2notify soll dazu fuehren, dass eine manuelle Schaltung des Aktors per Quittingstelegramm
# an FHEM uebermittelt wird und dort der Status des Aktors aktualisiert werden kann. Das funktioniert
# jedoch bisher nicht

define switch1notify notify switch1 set actuator1 $EVENT
define switch2notify notify EnO_switch_0187970B setstate actuator1 $EVENT


Und nun, was es tun soll:


  • Aktor soll per click aufs WEB UI geschaltet werden (funktioniert)
  • Aktor soll per click auf den Funktaster geschaltet werden (funktioniert)
  • Aktor soll durch elektrisches Signal direkt am Aktor angelegt geschaltet werden, FHEM soll das mitbekommen und den Zustand uebernehmen und auch signalisieren (Aktor schaltet, FHEM bekommt das zwar ueber das Quittingstelegramm mit, aktualisiert jedoch den Zustand auf dem UI nicht. Ein manueller Browser refresh fuehrt dann dazu, dass zwar der richtige Zustand dann angezeigt wird aber nichtmehr ueber das Lampen-icon sondern selbiges wird durch "BI" und "B0" ersetzt. Bei allen vorherigen Aktionen, wurde das dem Zustand entsprechende Lampen-Icon angezeigt.

Nun habe ich von diesem Zustand aus weiter experimentiert und habe fuer das Quittungstelegramm (EnO_switch_0187970B) auch eine EventMap definiert, genauso wie fuer actuator1 auch. Damit ist das Problem, dass das Lampen-icon durch BI/B0 ersetzt wird verschwunden. Ich kann nun auch auf dem Web UI den Zustand von "EnO_switch_0187970B" als Lampen-Icon dargestellt und korrekt schaltend sehen. Die Situation ist jetzt allerdings nach wie vor so, wenn ich den Aktor elektrisch ausloese, bleibt das Lampenicon im FHEM dunkel, die Lampe darunter, die ueber das Quittungstelegramm geschaltet wird, die wird jedoch hell. FHEM hat die Zustandsaenderung definitiv mitbekommen. Mache ich in dem Zustand ein "refresh" am Browser, geht die Lampe sofort an. Es ist also mit dieser Konfiguration fast alles gut, es fehlt offenbar nur der update am Browser.
FHEM auf Raspberry Pi, EnOcean Pi, HomeMatic LAN Konfigurations Adapter, CUL 868 V3, CUL 433 V3

klaus.schauer

Ich hatte folgende Parameter vorgeschlagen:

define actuator1 EnOcean 0187970B
attr actuator1 room EnOcean
attr actuator1 subDef FF9AAE81
attr actuator1 subType Switch

Die Def und subDef ist unterschiedlich!

tinyfhem

Zitat von: klaus.schauer am 07 Februar 2014, 10:27:57
Ich hatte folgende Parameter vorgeschlagen:

define actuator1 EnOcean 0187970B
attr actuator1 room EnOcean
attr actuator1 subDef FF9AAE81
attr actuator1 subType Switch

Die Def und subDef ist unterschiedlich!
Stimmt. Aber die habe ich fuer einen Fehler gehalten, denn ich war der Meinung, und so habe ich es auch aus einem Wiki, dass ich selbst, an der Stelle wo ich FHEM auf den actuator1 anlerne, die BaseID des EnOcean Pi nehmen muss und selbige hinten um 1 inkrementiere.  Wenn ich das was Du vorschlaegst richtig interpetiere, dann spezifiziere ich mit:

define actuator1 EnOcean 0187970B

den Rueckkanal, denn die 0187970B wird von diesem actuator1 als Quittungstelegramm gesendet und von FHEM empfanfen. Und dann ist das subDef echt das was gesendet wird? Diese Variante habe ich noch nicht versucht, werde ich aber nachholen. Wenns tut, dann tuts eben und alles ist gut, wenntleich mir auch diese Definition alles andere als logisch erscheint. Zumindest jetzt noch in diesem fruehen Stadium meiner FHEM Experimente.

Danke auf jeden Fall fuer die Hilfe.
FHEM auf Raspberry Pi, EnOcean Pi, HomeMatic LAN Konfigurations Adapter, CUL 868 V3, CUL 433 V3

tinyfhem

Funktioniert! Danke Klaus. Es ist mir zwar fuer mich noch nicht "intuitively obvious", warum die Definitionen so aussehen muessen aber das kann ja mit zunehmender Erfahrung auch noch logisch erscheinen. Ist das ein Thema, was evtl. noch im Wiki dokumentiert werden koennte? Ich wuerde mir die Zeit nehmen. Bestimmt gibt es noch weitere Anfaenger, die in genau dieselben Loecher tappen. Ich koennte z.B. den EnOcean Starter Guide (http://www.fhemwiki.de/wiki/EnOcean_Starter_Guide) mit einer Beschreibung genau dieses Szenarios anreichern. Waere das hilfreich?
FHEM auf Raspberry Pi, EnOcean Pi, HomeMatic LAN Konfigurations Adapter, CUL 868 V3, CUL 433 V3

klaus.schauer

Zitat von: tinyfhem am 07 Februar 2014, 16:46:36
Funktioniert! Danke Klaus. Es ist mir zwar fuer mich noch nicht "intuitively obvious", warum die Definitionen so aussehen muessen aber das kann ja mit zunehmender Erfahrung auch noch logisch erscheinen. Ist das ein Thema, was evtl. noch im Wiki dokumentiert werden koennte? Ich wuerde mir die Zeit nehmen. Bestimmt gibt es noch weitere Anfaenger, die in genau dieselben Loecher tappen. Ich koennte z.B. den EnOcean Starter Guide (http://www.fhemwiki.de/wiki/EnOcean_Starter_Guide) mit einer Beschreibung genau dieses Szenarios anreichern. Waere das hilfreich?
Das ist eine sehr gute Idee. Im Wiki wäre dafür genau der richtige Platz. Ich bin auch dankbar für Vorschläge zur Verbesserung der commandref. Hier kann man natürlich keine Schritt für Schritt-Anleitungen unterbringen.

Nach meiner Erfahrung ist das größte Anfängerproblem, die EnOcean Grundprinzipen zu verstehen, z. B. SenderID, Quittungstelegramme, teach-in.

dafex

#13
Servus

Im Wiki steht's genau so. Mann muss sich das allerdings zusammen pfrimmeln. Hab ich auch erst verstanden, als ich das Konfigurationsbeispiel für den FSB61 ganz am Ende gelesen und ausprobiert habe. Das Verständnis kommt eben erst nach vielem probieren.

Du solltest Dir mal die Anleitung für Einsteiger auf der FHEM Hompage mehrmals durchlesen. Ist zwar für FS20/Homematic, aber ist auch für EnOcean anwendbar.

Viel Erfolg weiterhin.

Edit:
Würde Dir auch empfehlen nur über die Weboberfläche Einstellungen vor zunehmen. Siehe auch diesen Beitrag

tinyfhem

Zitat von: dafex am 08 Februar 2014, 10:14:02
Servus

Im Wiki steht's genau so. Mann muss sich das allerdings zusammen pfrimmeln. Hab ich auch erst verstanden, als ich das Konfigurationsbeispiel für den FSB61 ganz am Ende gelesen und ausprobiert habe. Das Verständnis kommt eben erst nach vielem probieren.

Du solltest Dir mal die Anleitung für Einsteiger auf der FHEM Hompage mehrmals durchlesen. Ist zwar für FS20/Homematic, aber ist auch für EnOcean anwendbar.

Viel Erfolg weiterhin.

Edit:
Würde Dir auch empfehlen nur über die Weboberfläche Einstellungen vor zunehmen. Siehe auch diesen Beitrag
Ok, werde mich jetzt nach den ersten Erfahrungen nochmal auf das Dokument und auch auf das Wiki stuerzen. Hatte beides zwar schon vorher gelesen und auch das erste Konfigurationsbeispiel fuer meinen Aktor dort abgeschrieben, aber eben ohne das wirkliche Verstaendnis.

Und wegen den Einstellungen ueber das WebUI: Ja das habe ich nun auch angefangen. Dennoch waers mir recht, wenn die cfg einigermassen lesbar bliebe, z.B. block comments "#-------" nicht eliminiert wuerden. Bisher ist die cfg noch "sauber".
FHEM auf Raspberry Pi, EnOcean Pi, HomeMatic LAN Konfigurations Adapter, CUL 868 V3, CUL 433 V3

tinyfhem

Zitat von: dafex am 08 Februar 2014, 10:14:02
Servus

Im Wiki steht's genau so. Mann muss sich das allerdings zusammen pfrimmeln. Hab ich auch erst verstanden, als ich das Konfigurationsbeispiel für den FSB61 ganz am Ende gelesen und ausprobiert habe. Das Verständnis kommt eben erst nach vielem probieren.

Du solltest Dir mal die Anleitung für Einsteiger auf der FHEM Hompage mehrmals durchlesen. Ist zwar für FS20/Homematic, aber ist auch für EnOcean anwendbar.

Viel Erfolg weiterhin.

Edit:
Würde Dir auch empfehlen nur über die Weboberfläche Einstellungen vor zunehmen. Siehe auch diesen Beitrag
So, inzwischen nochmal einiges gelesen, im besonderen den fhemwiki EnOcean Starter Guide. Dort wird der FSB61 beschrieben, ich habe einen FSR61. habe aus dem Beispiel bei mir noch folgende Aenderungen nachgetragen:

attr actuator1 model FSR61
attr actuator1 subType manufProfile
attr actuator1 manufID 00D

Veraendert hat sich dadurch nichts, war aber ja auch vorher schon gut. (Woher bekomme ich ueberhaupt die Information ob, und wenn ja was fuer ein "subType manufProfile" gesetzt werden muss? Selbe Frage dann auch fuer "manufID 00D").

Allerdings habe ich noch Fehler, ausgeloest beim betaetigen des switches (FT55) mit der Definition:

define switch1 EnOcean FEFF2D58
attr switch1 room EnOcean
attr switch1 subType switch
attr switch1 eventMap BI:off B0:on

auf der "B0" Seite gedrueckt und losgelassen:

2014.02.08 21:04:58 3: switch1notify return value: Unknown argument buttons:, choose one of A0 AI B0 BI C0 CI D0 DI released blink on-for-timer on-till off-for-timer intervals off-till
2014.02.08 21:04:58 3: switch1notify return value: Unknown argument channelB:, choose one of A0 AI B0 BI C0 CI D0 DI released blink on-for-timer on-till off-for-timer intervals off-till
2014.02.08 21:04:58 2: EnOcean set actuator1 B0
2014.02.08 21:04:58 3: switch1notify return value: Unknown argument buttons:, choose one of A0 AI B0 BI C0 CI D0 DI released blink on-for-timer on-till off-for-timer intervals off-till
2014.02.08 21:04:58 3: switch1notify return value: Unknown argument buttons:, choose one of A0 AI B0 BI C0 CI D0 DI released blink on-for-timer on-till off-for-timer intervals off-till

auf der "BI" Seite sieht es analog dazu aus, da spare ich mir jetzt das einfuegen der Logzeilen.

Im EnOcean Starter Guide wird bezug genommen auf einen FSA12. Exakt genauso habe ich meinen FT55 konfiguriert. In der Anleitung fuer Einsteiger habe ich nichts gefunden, was mir in Bezug auf diese Fehlermeldungen weiter hilft.

Der Vollstaendigkeit halber hier nochmal die Definition des Notify:

define switch1notify notify switch1 set actuator1 $EVENT
FHEM auf Raspberry Pi, EnOcean Pi, HomeMatic LAN Konfigurations Adapter, CUL 868 V3, CUL 433 V3

tinyfhem

Zitat von: tinyfhem am 08 Februar 2014, 21:16:47
So, inzwischen nochmal einiges gelesen, im besonderen den fhemwiki EnOcean Starter Guide. Dort wird der FSB61 beschrieben, ich habe einen FSR61. habe aus dem Beispiel bei mir noch folgende Aenderungen nachgetragen:

attr actuator1 model FSR61
attr actuator1 subType manufProfile
attr actuator1 manufID 00D

Veraendert hat sich dadurch nichts, war aber ja auch vorher schon gut. (Woher bekomme ich ueberhaupt die Information ob, und wenn ja was fuer ein "subType manufProfile" gesetzt werden muss? Selbe Frage dann auch fuer "manufID 00D").

Allerdings habe ich noch Fehler, ausgeloest beim betaetigen des switches (FT55) mit der Definition:

define switch1 EnOcean FEFF2D58
attr switch1 room EnOcean
attr switch1 subType switch
attr switch1 eventMap BI:off B0:on

auf der "B0" Seite gedrueckt und losgelassen:

2014.02.08 21:04:58 3: switch1notify return value: Unknown argument buttons:, choose one of A0 AI B0 BI C0 CI D0 DI released blink on-for-timer on-till off-for-timer intervals off-till
2014.02.08 21:04:58 3: switch1notify return value: Unknown argument channelB:, choose one of A0 AI B0 BI C0 CI D0 DI released blink on-for-timer on-till off-for-timer intervals off-till
2014.02.08 21:04:58 2: EnOcean set actuator1 B0
2014.02.08 21:04:58 3: switch1notify return value: Unknown argument buttons:, choose one of A0 AI B0 BI C0 CI D0 DI released blink on-for-timer on-till off-for-timer intervals off-till
2014.02.08 21:04:58 3: switch1notify return value: Unknown argument buttons:, choose one of A0 AI B0 BI C0 CI D0 DI released blink on-for-timer on-till off-for-timer intervals off-till

auf der "BI" Seite sieht es analog dazu aus, da spare ich mir jetzt das einfuegen der Logzeilen.

Im EnOcean Starter Guide wird bezug genommen auf einen FSA12. Exakt genauso habe ich meinen FT55 konfiguriert. In der Anleitung fuer Einsteiger habe ich nichts gefunden, was mir in Bezug auf diese Fehlermeldungen weiter hilft.

Der Vollstaendigkeit halber hier nochmal die Definition des Notify:

define switch1notify notify switch1 set actuator1 $EVENT


In diesem Post sind noch ein paar Fragen bis jetzt offen geblieben. Am meisten bedruecken mich die Fehlermeldungen im Log, wie oben bereits zitiert, also alles das was mit: "switch1notify return value: Unknown argument ...." beginnt. Ich habe bisher nicht rausfinden koennen, was hier schief laeuft.

Koennte es sein, dass bei dem "define switch1notify notify switch1 set actuator1 $EVENT" die $EVENT variable zu irgendwas evaluiert, was diese Fehlermeldungen produziert? Ist die simple Angabe von $EVENT hier fehl am Platz?
FHEM auf Raspberry Pi, EnOcean Pi, HomeMatic LAN Konfigurations Adapter, CUL 868 V3, CUL 433 V3

tinyfhem

Inzwischen habe ich einiges herausgefunden: Der Eltako FT55 ist auf der Basis eines EnOcean PTM215 Moduls aufgebaut. Dieses Modul unterstuetzt zwei Wippen, eine erzeugt A0/AI, die andere B0/BI. beim FT55 wurde nur eine Wippe verbaut und je nachdem, wie man diese Wippe auf das Modul clipsed, wird entweder A0/AI oder B0/BI gesendet, die jeweils andere Funktion ist nicht verfuegbar.

Ich habe weiterhin herausgefunden, dass hier wohl die Konstruktion:

define switch1notify notify switch1 set actuator1 $EVENT

nicht richtig ist, jedenfalls fuehr sie zu den Fehlermeldungen. Bei mir hat folgendes zu den richtigen Ergebnissen gefuehrt und vor allem die Fehlermeldungen bleiben nun aus:

define switch1notify notify switch1 {my $rvar=Value("switch1");; \
if ($rvar =~ m/B0/) {fhem "set actuator1 on"} \
elsif ($rvar =~ m/BI/) {fhem "set actuator1 off"};; \
if ($rvar =~ m/on/) {fhem "set actuator1 on"} \
elsif ($rvar =~ m/off/) {fhem "set actuator1 off"}}

Das B0/BI wird durch druecken des Tasters erzeugt und verarbeitet. Das on/off wird durch druecken des entsprechenden links auf der Web Oberflaeche erzeugt und verarbeitet. Also ich muss echt sagen, dokumentiert habe ich das bis jetzt nirgends gefunden. Auch nicht in diesem EnOcean Starter Guide.
FHEM auf Raspberry Pi, EnOcean Pi, HomeMatic LAN Konfigurations Adapter, CUL 868 V3, CUL 433 V3

dafex

Warum lernst du eigentlich deinen Taster nicht in den Aktor ein? Ich versteh den Sinn des notify Befehls nicht. Was soll der bewirken? Besser ist es du lernst FHEM als Zentralschalter in deinen Aktor ein. Deinen Taster definierst du einfach als EnOcean Sensor. Wenn du nun über den Taster deinen Aktor schaltest bekommt das FHEM mit und zeigt es dir auch an. Genaus so gut kannst du über FHEM den Aktor schalten. Den Taster definierst nur, damit er in FHEM bekannt ist und es weis, was es mit den Telegrammen deines Tasters machen soll. Nämlich nichts. Außer du willst Dinge steuern, die mit dem Taster nicht möglich sind. Zum Beispiel einschalten für zwei Stunden, oder in einer Stunde für zwei Stunden einschalten.

FHEM wird eigentlich nur zur Steuerung von komplexen Szenarien gebraucht, die nicht über EnOcean abgebildet werden können. Und für eine Visualisierung der Komponenten.

tinyfhem

Zitat von: dafex am 22 Februar 2014, 12:04:35
Außer du willst Dinge steuern, die mit dem Taster nicht möglich sind. Zum Beispiel einschalten für zwei Stunden, oder in einer Stunde für zwei Stunden einschalten.
Ganz genau solche Dinge moechte ich machen. Ich moechte auf keinen Fall, dass Sensoren direkt an Aktoren angelernt werden. Alles soll ueber FHEM passieren, FHEM entscheidet, was zu tun ist. Der Aktor ist in einer UP Dose verbaut. Die ganze Anlerngeschichte ist sowas von umstaendlich. In FHEM kann ich das Verhalten meines Systems nach beliebgen definieren und umdefinieren, ohne jemals diesen Aktor wieder ans Tageslicht befoerdern zu muessen. Bei einem Sensor, einem Aktor mag das ja auch noch anders gehen, aber wenn es dann mal eine etwas aufwendigere Anlage sein soll, dann hat das keinen Sinn mehr.

Es funktioniert ja inzwischen auch wie es soll. Ich wundere mich ja nur, dass derartige Szenarien bisher nicht wirklich dokumentiert sind, obgleich es sich um die m.E. einfachsten nur vorstellbaren Szenarien handelt.
FHEM auf Raspberry Pi, EnOcean Pi, HomeMatic LAN Konfigurations Adapter, CUL 868 V3, CUL 433 V3

tinyfhem

Obgleich folgende Frage nicht direkt dem Betreff entspricht, passt es doch vom Kontext her zu diesem Thread am besten. Es geht nach wie vor um die von mir hier beschriebene Konfiguration:
EnOcean
FSR61 Aktor
FT55 Switch

Ich hatte zum Schluss eine funktionierende Konfiguration, mit der mit einem Kanal des FT55 der Aktor eingeschaltet, mit dem anderen Kanal wieder ausgeschaltet werden konnte. Nun wollte ich die Funktionalitaet so erweitern, dass einer der beiden Kanaele des FT55 den Aktor im togglebetrieb ansteuert und somit der andere Kanal frei wird fuer ein x-beliebiges anderes Geraet, in meinem Fall eine Steckdose einer Steckdosenleiste am EGPM Modul.

Ich weiss, dass ich den FSR61 "umlernen" koennte, so dass er Togglebetrieb untersuetzt und genauso wuerde man das ja auch machen, wenn man den sensor direkt an den aktor anlernt aber darin besteht ja genau der Vorteil einer indirekten Steuerung uebe FHEM, dass man genau das nicht braucht sondern flexibel bestimmen kann, dass ein switch heute dieses und morgen jenes schaltet.

Nur leider ist es so, dass ich es bisher nicht hinbekommen habe. Habe das notify fuer den switch wie folgt geaendert. Als erstes liste ich das Original, mit dem ich mit einem Kanal ON mit dem anderen OFF schalten konnte. Als zweites mein Versuch mit dem Toggle Betrieb:


define switch1notify notify switch1 {my $rvar=Value("switch1");; \
if ($rvar =~ m/B0/) {fhem "set actuator1 on"} \
elsif ($rvar =~ m/BI/) {fhem "set actuator1 off"};; \
if ($rvar =~ m/on/) {fhem "set actuator1 on"} \
elsif ($rvar =~ m/off/) {fhem "set actuator1 off"}}



define switch1notify notify switch1 {my $rvar=Value("switch1");; \
if    ($rvar =~ m/B0/ && Value("actuator1") eq "off") {fhem "set actuator1 on"}  \
elsif ($rvar =~ m/B0/ && Value("actuator1") eq "on")  {fhem "set actuator1 off"} \
elsif ($rvar =~ m/BI/) {fhem "set s1 toggle"}}

Das zweite snippet ist das was nicht oder nur teilweise funktioniert. Schalten von "s1" (Stechdose am EGPM) ueber den BI Kanal des FT55 funktioniert im togglebetrieb problemlos. Schalten von "actuator1", mit von Hand implementierter toggle Logik funktioniert auch, allerdings so, dass bei druecken des Tasters die Lampe mehrmals an und aus geht und am Schluss den gewuenschten Zustand einnimmt. Es sieht so aus, als ob ein Schalter prellen wuerde bzw als ob hier durch einmaliges druecken des Tasters mehrere events augeloest und verarbeitet wuerden. Aus dem Log kann ich sehen, dass einmaliges druecken des Tasters folgendes generiert:

2014-03-30_20:09:16 switch1 buttons: pressed
2014-03-30_20:09:16 switch1 channelB: B0
2014-03-30_20:09:16 switch1 B0
2014-03-30_20:09:17 switch1 buttons: released
2014-03-30_20:09:17 switch1 buttons: released

Es erschliesst sich mir nicht, warum hierbei die Lampe bei einmalilgem druecken auf den Taster mehrmals an und aus geht. Hat da jemand eine Idee, wie man das richtig macht?

PS: Warum da in dem log zweimal ein "buttons: released" kommt ist mir auch nicht klar.
FHEM auf Raspberry Pi, EnOcean Pi, HomeMatic LAN Konfigurations Adapter, CUL 868 V3, CUL 433 V3

Spartacus

Hallo  tinyfhem,
ich habe seit heute einen ersten enOcean Switch mit Doppelwippe. Auch ich möchte damit 4 Lämchen schalten /togglen. Ich habe versucht Deinen Code nachzuvollziehen und für mich sieht das völlig OK aus. Ich kann bestätigen, dass beim Drücken des Buttons am Taster, 2 x das "Released" kommt.
2014-03-31 11:24:33 EnOcean Gira_Switch_01 buttons: pressed
2014-03-31 11:24:33 EnOcean Gira_Switch_01 channelB: BI
2014-03-31 11:24:33 EnOcean Gira_Switch_01 BI
2014-03-31 11:24:33 EnOcean Gira_Switch_01 buttons: released
2014-03-31 11:24:33 EnOcean Gira_Switch_01 buttons: released
2014-03-31 11:24:34 EnOcean Gira_Switch_01 buttons: pressed
2014-03-31 11:24:34 EnOcean Gira_Switch_01 channelB: B0
2014-03-31 11:24:34 EnOcean Gira_Switch_01 B0
2014-03-31 11:24:35 EnOcean Gira_Switch_01 buttons: released
2014-03-31 11:24:35 EnOcean Gira_Switch_01 buttons: released

das scheint wohl so zu sein, ich kann mir nicht vorstellen, dass es sich hier um "Tasterprellen" handelt.
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 31 März 2014, 11:27:43
Hallo  tinyfhem,
ich habe seit heute einen ersten enOcean Switch mit Doppelwippe. Auch ich möchte damit 4 Lämchen schalten /togglen. Ich habe versucht Deinen Code nachzuvollziehen und für mich sieht das völlig OK aus. Ich kann bestätigen, dass beim Drücken des Buttons am Taster, 2 x das "Released" kommt.
2014-03-31 11:24:33 EnOcean Gira_Switch_01 buttons: pressed
2014-03-31 11:24:33 EnOcean Gira_Switch_01 channelB: BI
2014-03-31 11:24:33 EnOcean Gira_Switch_01 BI
2014-03-31 11:24:33 EnOcean Gira_Switch_01 buttons: released
2014-03-31 11:24:33 EnOcean Gira_Switch_01 buttons: released
2014-03-31 11:24:34 EnOcean Gira_Switch_01 buttons: pressed
2014-03-31 11:24:34 EnOcean Gira_Switch_01 channelB: B0
2014-03-31 11:24:34 EnOcean Gira_Switch_01 B0
2014-03-31 11:24:35 EnOcean Gira_Switch_01 buttons: released
2014-03-31 11:24:35 EnOcean Gira_Switch_01 buttons: released

das scheint wohl so zu sein, ich kann mir nicht vorstellen, dass es sich hier um "Tasterprellen" handelt.
Spartacus
Also Tasterprellen ist das nicht, das ist mir schon klar. Hier ist das, was der "actuator1" logged:

<Tastendruck 1>
2014-03-30_20:09:12 actuator1 on
2014-03-30_20:09:12 actuator1 off
2014-03-30_20:09:13 actuator1 on
2014-03-30_20:09:13 actuator1 off
2014-03-30_20:09:13 actuator1 on

<Tastendruck 2>
2014-03-30_20:09:16 actuator1 off
2014-03-30_20:09:16 actuator1 on
2014-03-30_20:09:17 actuator1 off
2014-03-30_20:09:17 actuator1 on
2014-03-30_20:09:17 actuator1 off

Es scheinen fuer jeden Tasterdruck 5 Events generiert zu werden, die brav togglen. Ich will aber eigentlich gerne nur einen davon bearbeiten und koennte mir vorstellen, dass das Problem in der PERL expression:

if    ($rvar =~ m/B0/  .....

zu suchen ist. Ich probiere heute abend mal folgendes:

if   ($rvar =~ m/switch1 B0/ ...

Aber selbst wenn das dann taete, ist das der richtige Weg?
FHEM auf Raspberry Pi, EnOcean Pi, HomeMatic LAN Konfigurations Adapter, CUL 868 V3, CUL 433 V3

Spartacus

Hi,
ich habe noch mal im enocean StartarWiki nachgesehen. Hier steht unter Funktaster  FT55 Folgendes zum Protokoll:

2014-01-01_07:00:01 EnO_switch_FFC54500 buttons: pressed
2014-01-01_07:00:01 EnO_switch_FFC54500 channelA: AI
2014-01-01_07:00:01 EnO_switch_FFC54500 AI
2014-01-01_07:00:02 EnO_switch_FFC54500 buttons: released


Warum taucht das letzte "released" 2 x bei uns mehrfach auf?
2014-03-31_21:57:42 EnO_Sw_01 buttons: pressed
2014-03-31_21:57:42 EnO_Sw_01 channelA: A0
2014-03-31_21:57:42 EnO_Sw_01 A0
2014-03-31_21:57:42 EnO_Sw_01 buttons: released
2014-03-31_21:57:42 EnO_Sw_01 buttons: released
2014-03-31_21:57:44 EnO_Sw_01 buttons: pressed
2014-03-31_21:57:44 EnO_Sw_01 channelA: AI
2014-03-31_21:57:44 EnO_Sw_01 AI
2014-03-31_21:57:44 EnO_Sw_01 buttons: released
2014-03-31_21:57:44 EnO_Sw_01 buttons: released
2014-03-31_21:57:45 EnO_Sw_01 buttons: pressed
2014-03-31_21:57:45 EnO_Sw_01 channelB: B0
2014-03-31_21:57:45 EnO_Sw_01 B0
2014-03-31_21:57:46 EnO_Sw_01 buttons: released
2014-03-31_21:57:46 EnO_Sw_01 buttons: released
2014-03-31_21:57:47 EnO_Sw_01 buttons: pressed
2014-03-31_21:57:47 EnO_Sw_01 channelB: BI
2014-03-31_21:57:47 EnO_Sw_01 BI
2014-03-31_21:57:48 EnO_Sw_01 buttons: released
2014-03-31_21:57:48 EnO_Sw_01 buttons: released

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

Spartacus

Hallo,
ich habe noch mal ein bissl an den Einstellungen des FT55 rumgespielt und den Typ FT55 eingestellt. Jertr sieht das Logfile so aus:

Events:
2014-04-01 09:10:51 EnOcean EnO_Sw_01 buttons: pressed
2014-04-01 09:10:51 EnOcean EnO_Sw_01 channelA: A0
2014-04-01 09:10:51 EnOcean EnO_Sw_01 A0
2014-04-01 09:10:52 EnOcean EnO_Sw_01 buttons: released
2014-04-01 09:10:52 EnOcean EnO_Sw_01 released


Ich glaube es nun so zu verstehen:
Das erste "released"bezieht sich auf den Button, das 2. Release auf den State des Kanals, also hier A0
Vielleicht hilft das ja...
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

der Ausdruck:

if   ($rvar =~ m/switch1 B0/ ...

hat nicht funktioniert. Habe deshalb zum debuggen ein print statement eingebaut:

define switch1notify notify switch1 {my $rvar=Value("switch1") ;; print "$rvar\n" ;; \
if    ($rvar =~ m/B0/ && Value("actuator1") eq "off") {fhem "set actuator1 on"}  \
elsif ($rvar =~ m/B0/ && Value("actuator1") eq "on")  {fhem "set actuator1 off"} \
elsif ($rvar =~ m/BI/) {fhem "set s1 toggle"}}

Dann den "B0" Taster gedrueckt, daraufhin tauchte folgendes auf der Console auf:

B0
B0
B0
B0
B0

Danach den "BI" Taster gedrueckt und es kam:

BI
BI
BI
BI
BI

Bei jedem Tastendruck also 5 events. 5 Events die in der Behandlung nicht mehr voneinander unterscheidbar sind. Ich moechte bei Tastendruck entweder nur einen event haben, oder falls mehrere kommen, sie wenigstens voneinander unterscheiden koennen.
FHEM auf Raspberry Pi, EnOcean Pi, HomeMatic LAN Konfigurations Adapter, CUL 868 V3, CUL 433 V3

tinyfhem

Zitat von: Spartacus am 01 April 2014, 09:16:37
Hallo,
ich habe noch mal ein bissl an den Einstellungen des FT55 rumgespielt und den Typ FT55 eingestellt. Jertr sieht das Logfile so aus:
Wie sieht jetzt die Definition im cfg file aus?
FHEM auf Raspberry Pi, EnOcean Pi, HomeMatic LAN Konfigurations Adapter, CUL 868 V3, CUL 433 V3

Spartacus

Hi, hier die config:
# Gira Serientaster FT55
define EnO_Sw_01 EnOcean xxxxxxxx
attr EnO_Sw_01 IODev TCM310_0
attr EnO_Sw_01 group Device
attr EnO_Sw_01 model FT55
attr EnO_Sw_01 room Test
attr EnO_Sw_01 subType switch
define FileLog_EnO_Sw_01 FileLog ./log/EnO_Sw_01-%Y.log EnO_Sw_01
attr FileLog_EnO_Sw_01 logtype text
attr FileLog_EnO_Sw_01 room Test

Gruß,
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

bin nun einen Schritt weiter, habe meine Definition wie folgt geaendert:

attr switch1 model FT55
attr switch1 event-on-change-reading buttons

damit habe ich das gewuenschte, weiter oben beschriebene Verhalten erzielt.
FHEM auf Raspberry Pi, EnOcean Pi, HomeMatic LAN Konfigurations Adapter, CUL 868 V3, CUL 433 V3

Spartacus

#29
Hi,
kannst Du die Lösung noch einmal komplett posten?

Wie kannst Du denn jetzt die eigentliche Taste auswerten, es wird ja nur noch "pressed" und "released" ausgegeben. Die Kanalinformation ist verloren, oder?

Ich verstehe es noch nicht ganz! Ich versuche hier mit einem Taster verschiedene Dinge zu steuern. Der Taster soll z.B. bei einem kurzen klick ein Gerät ein/ausschalten und bei einem längeren Druck ein anderes Gerät ein/ausschalten. So könnte man mit einer Doppelwippe 8 Geräte schalten.

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 01 April 2014, 10:17:23
Hi,
kannst Du die Lösung noch einmal komplett posten?
Spartacus

Klar:

define switch1 EnOcean xxxxxxxx
attr switch1 IODev TCM310
attr switch1 room EnOcean
attr switch1 subType switch
attr switch1 model FT55
attr switch1 event-on-change-reading buttons

define switch1notify notify switch1 {my $rvar=Value("switch1") ;; \
if    ($rvar =~ m/B0/ && Value("actuator1") eq "off") {fhem "set actuator1 on"}  \
elsif ($rvar =~ m/B0/ && Value("actuator1") eq "on")  {fhem "set actuator1 off"} \
elsif ($rvar =~ m/BI/) {fhem "set s1 toggle"}}

Mit dem "B0" channel des switches wird ein toggle auf den actuator1 gemacht. Mit dem "B1" channel wird eine Energenie Steckdose getoggled. Am actuator1 haengt aktuell zum testen eine Lampe und so habe ich auch mitbekommen, dass ohne das "event-on-change-reading", eine Lichtorgel entsteht. Ob das mit dem event-on-change-readings der elegante und sinnvolle Weg ist, da habe ich so meine Zweifel aber es funktioniert. Ich denke eleganter waere, die Definition des notify so anzulegen, dass die events gefiltert werden koennen.
FHEM auf Raspberry Pi, EnOcean Pi, HomeMatic LAN Konfigurations Adapter, CUL 868 V3, CUL 433 V3

Spartacus

#31
Hi,
habe das mal auf meine Bedürfnisse angepasst:
# Eltako Aktor FMS61NP (2xS)
define EnO_Act_01 EnOcean xxxxxx
attr EnO_Act_01 IODev TCM310_0
attr EnO_Act_01 group Device
attr EnO_Act_01 room Test
attr EnO_Act_01 subDef FF94C081
attr EnO_Act_01 subType switch
define FileLog_EnO_Act_01 FileLog ./log/EnO_Act_01-%Y.log EnO_Act_01
attr FileLog_EnO_Act_01 group EnOcean
attr FileLog_EnO_Act_01 logtype text
attr FileLog_EnO_Act_01 room System


# Gira Serientaster
define EnO_Sw_01 EnOcean 008C1D57
attr EnO_Sw_01 IODev TCM310_0
attr EnO_Sw_01 event-on-change-reading buttons
attr EnO_Sw_01 group Device
attr EnO_Sw_01 model FT55
attr EnO_Sw_01 room Test
attr EnO_Sw_01 subType switch
define FileLog_EnO_Sw_01 FileLog ./log/EnO_Sw_01-%Y.log EnO_Sw_01
attr FileLog_EnO_Sw_01 logtype text
attr FileLog_EnO_Sw_01 room Test


EnO_Sw_01 { my $rvar=Value("EnO_Sw_01") ;
  if    ($rvar =~ m/B0/ && ReadingsVal("EnO_Act_01","channelB","") eq "BI") {fhem "set EnO_Act_01 B0"}
  elsif ($rvar =~ m/B0/ && ReadingsVal("EnO_Act_01","channelB","") eq "B0") {fhem "set EnO_Act_01 BI"}
  elsif ($rvar =~ m/BI/ && ReadingsVal("EnO_Act_01","channelA","") eq "AI") {fhem "set EnO_Act_01 A0"}
  elsif ($rvar =~ m/BI/ && ReadingsVal("EnO_Act_01","channelA","") eq "A0") {fhem "set EnO_Act_01 AI"}}


muss aber feststellen, dass fhem nicht jeden Tastendruck umsetzt, vor allem, wenn die Schaltfolge schnell hintereinander erfolgt. Da ist irgendwo noch der Wurm drin....aber woran liegt das? Wenn ich den Taster direkt einlerne, klappt alles zuverlässig!

Edit:
...so macht das irgendwie keinen Sinn! Das ist viel zu langsam...
@tinyfhem:
ist das bei Dir auch so? mach doch bitte mal einen "Doppelklick" auf den Schalter!

Gruß,
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

Spartacus

#32
Hallo,
die Klicks auf den Taster kriegt fhem alle mit, dass kann ich im "Readings"-Fenster verfolgen. Es scheint vielmehr am Aktor zu liegen, der die Rückmeldung nicht schnell genug an fhem übermittelt. Daher vermute ich, dass es bei der ReadingsVal-Anweisung offenbar zu einer falschen Auswertung kommt
Weiß jemand, ob und vor allem wie,  man hier optimieren kann?

Spartacus

Edit:
Es dauert ca. 2-3 sec. bis der Aktor das Statustelegramm gesendet hat. Ist das normal?
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 01 April 2014, 12:36:26
@tinyfhem:
ist das bei Dir auch so? mach doch bitte mal einen "Doppelklick" auf den Schalter!
Also ich kann klicken so schnell es nur geht, die Lampe (actuator1 in meinem Beispiel), folgt brav und bleibt im Tritt. Fhem laeuft bei mir auf einem Raspi.
FHEM auf Raspberry Pi, EnOcean Pi, HomeMatic LAN Konfigurations Adapter, CUL 868 V3, CUL 433 V3

Spartacus

#34
Hi,
das verstehe ich nicht!
Wie hast Du den Aktor angelernt. als Richtungstaster, mit aktiviertem Telegramm? (muss ja, sonst könntest Du den State nicht auslesen)
Bei mir läuft das auch auf einem Pi! und dauert bis zu 2 Sekunden, bis die Quittung im fhem ankommt. Am Aktor kann ich sehen, das die LED jedesmal blinkt..das heisst der Aktor kriegt schon jeden Befehl mit, aber durch den &&ReadiningVal-Befehl wird ja auf die Rückmeldung des Aktors gewartet...und das scheint bei mir sehr lange zu dauern.

Der FMS61NP hat 2 Kanäle, aber daran kann es eigentlich nicht liegen....
der aktor und der Taster liegen neben dem enoacen PI. Verbindung ist prima und ich habe nur einen Aktor an dem Pi.

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

Spartacus

Hallo,
habe gestern noch einmal den Aktor neu eingelernt. Bei aktiviertem Telegramm und als Richtungstaster bleibt der ganze Käse extrem träge. Ich weiss auch nicht mehr, an welcher Schraube ich da drehen soll, denn bei tinyfhem scheint es ja ohne merkliche Verzögerung zu funzen....

Wenn das von der Sache bei mir richtig umgesetzt ist, und niemand sonst noch einen Tipp hat, dann muss ich mein System mal neu aufsetzten. So kann es auf keinen Fall bleiben......

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