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