FHEM Forum

FHEM - Hausautomations-Systeme => EnOcean => Thema gestartet von: klaus.schauer am 09 März 2014, 08:42:46

Titel: Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: klaus.schauer am 09 März 2014, 08:42:46
Mit Hilfe des Kommandos "readingsProxy" können die Kanäle eines EnOcean Schalters (subType switch) in unabhängige Schalter aufgeteilt werden. Hier die Grundkonfiguration für die Kanäle A und B:

define <device_channelA> readingsProxy <refDevice>:channelA
attr <device_channelA> eventMap A0:on AI:off
attr <device_channelA> setFn ""
attr <device_channelA> setList A0:noArg AI:noArg
attr <device_channelA> valueFn ""
attr <device_channelA> webCmd on:off

define <device_channelB> readingsProxy <refDevice>:channelB
attr <device_channelB> eventMap B0:on BI:off
attr <device_channelB> setFn ""
attr <device_channelB> setList B0:noArg BI:noArg
attr <device_channelB> valueFn ""
attr <device_channelB> webCmd on:off

Titel: Antw:Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: djhans am 10 März 2014, 08:47:41
Hallo Klaus,
das klappt 1a. Habe es mal mit meinem Eltako FMS61NP ausprobiert.

Was mir allerdings auffällt ist, das der Schaltbefehl fast zeitgleich am Aktor ausgeführt wird, wenn man auf on/off drückt, es aber "relativ" lange dauert, bis die Rückmeldung im Webinterface (Lampensymbol) sich ändert (halbe bis 1 sec.) Dieses Verhalten zeigt sich m.E.  nicht, wenn das Device nicht aufgeteilt ist.

Die Frage ist, ob die Verzögerung sich vergrößert wenn mehrere Aktoren zum Einsatz kommen. Bislang ist der o.a. Aktor das einzige Device (außer Sonos) was bei mir im fhem läuft.

Gruß,
djhans.
Titel: Antw:Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: nabbl am 10 März 2014, 12:41:26
Hm.. Jemand ein Beispiel wie genau das aussehen muss?

Habe mal so konfiguriert (Schalter ist Licht + Rollo, beide noch nicht am Aktor eingelernt)


define EnO_switch_Licht_Buero_Daniel readingsProxy EnOcean 008B5BE9:channelA
attr EnO_switch_Licht_Buero_Daniel alias Schalter Büro Daniel
attr EnO_switch_Licht_Buero_Daniel eventMap AI:off A0:on
attr EnO_switch_Licht_Buero_Daniel group Schalter
attr EnO_switch_Licht_Buero_Daniel setFn ""
attr EnO_switch_Licht_Buero_Daniel setList A0:noArg AI:noArg
attr EnO_switch_Licht_Buero_Daniel valueFn ""
attr EnO_switch_Licht_Buero_Daniel webCmd on:off
attr EnO_switch_Licht_Buero_Daniel room OG_Buero_Daniel



define EnO_switch_Rollo_Buero_Daniel readingsProxy EnOcean 008B5BE9:channelB
attr EnO_switch_Rollo_Buero_Daniel alias Schalter Rollo Büro Daniel
attr EnO_switch_Rollo_Buero_Daniel eventMap B0:open BI:close
attr EnO_switch_Rollo_Buero_Daniel group Schalter
attr EnO_switch_Rollo_Buero_Daniel setFn ""
attr EnO_switch_Rollo_Buero_Daniel setList B0:noArg BI:noArg
attr EnO_switch_Rollo_Buero_Daniel valueFn ""
attr EnO_switch_Rollo_Buero_Daniel webCmd on:off
attr EnO_switch_Rollo_Buero_Daniel room OG_Buero_Daniel


Bei mir zeigt er ausserdem nicht den Status an ob Licht aus oder an: Rollladen oben oder unten.
Bin noch völlig neu auf dem Gebiet.

Edit: Denke ich habe jetzt verstanden, dass readingsproxy von einem bestehenden Gerät "erbt" und ich den Sensor vorher noch definen muss.
Daheim kann ich das mal testen.
Titel: Antw:Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: djhans am 10 März 2014, 21:59:50
Hallo,
ich habe den Aktor nun räumlich versetzt und dabei vom Strom getrennt. Das Schalten mit dem aufgeteilten Device funktioniert einwandfrei und ohne Verzögerung, allerdings werden die Schaltzustände des Icons jetzt falsch bzw. gar nicht angezeigt.
Habe fhem nicht neu gestartet, aber ich denke, es müsste auch ohne Neustart funzen, oder? Woran kann das liegen?

djhans
NACHTRAG:
es scheint tatsächlich an der Funkreichweite zu liegen! Was bleibt ist aber die große Verzögerung beim Anzeigen der Stati in der Weboberfläche
Titel: Antw:Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: justme1968 am 23 April 2014, 12:39:17
in welchem raum sind die readingsProxy device die die verzögernd in der anzeige haben?

zumindest für den raum unsorted gibt es aktuell ein problem mit longpoll: http://forum.fhem.de/index.php/topic,22753.msg161726.html#msg161726 (http://forum.fhem.de/index.php/topic,22753.msg161726.html#msg161726).

ansonsten schau dir mal das beispiel in dem thread oben an. da ist die verwendung von setFn und valueFn etwas anders umgesetzt.

gruss
  andre
Titel: Antw:Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: pst am 01 Mai 2014, 13:54:17
Hi Klaus,

ich verstehe das setup so, dass Du einen 4-Kanal Schalter AI / AO / BI / BO so konfigurierst, dass AI und AO einen Schalter simulieren (an/aus) und B0 und BI einen anderen.  Jetzt kann man im toggel modus ja mit enem Kanal ...(also z.B. BI) einen Lampe an und aus machen.
Kann man das mit readingsProxy definieren?

Vielen Dank im Voraus
Stephan 
Titel: Antw:Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: krikan am 01 Mai 2014, 15:19:36
Hallo Klaus,

kann es sein, dass Dein Beispiel nur bei einem physischen Switch als Sensor oder bidi-Aktoren funktioniert? Bei einem FHEM-TCM-Switch habe ich das Reading "channelA" usw. nicht.
Ich muss hier ein readingsProxy mit Bezug auf das Reading "state" anlegen, damit es funktioniert:

define Schalter_channelA_A0 readingsProxy Schalter:state
attr Schalter_channelA_A0 eventMap A0:toggle
attr Schalter_channelA_A0 room EnOcean
attr Schalter_channelA_A0 setFn ""
attr Schalter_channelA_A0 setList A0:noArg
attr Schalter_channelA_A0 valueFn {(ReadingsVal("Schalter_channelA_A0","state",0) eq "off")?"on":"off"}
attr Schalter_channelA_A0 verbose 5
attr Schalter_channelA_A0 webCmd toggle


@Stephan: das obige Toggle-Beispiel ist vermutlich auch das, was Dir helfen könnte (Achtung: ist mein erstes readingsProxy)

Gruß, Christian
Titel: Antw:Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: pst am 01 Mai 2014, 20:10:17
Hallo Christian,

vorab... das erste Bier geht auf mich,.. falls man sich mal treffen sollte.

Definiert habe ich das so,.. wie Du geschrieben hast,.. nur mit B0:

define Schalter_channelB_B0 readingsProxy LichtDeckeStephan:state
attr Schalter_channelB_B0 eventMap B0:toggle
attr Schalter_channelB_B0 room EnOcean
attr Schalter_channelB_B0 setFn ""
attr Schalter_channelB_B0 setList B0:noArg
attr Schalter_channelB_B0 valueFn {(ReadingsVal("Schalter_channelB_B0","state",0) eq "off")?"on":"off"}
attr Schalter_channelB_B0 verbose 5
attr Schalter_channelB_B0 webCmd toggle

zusätzlich noch
define LichtDeckeStephan EnOcean xxxxxx
...

Im log habe ich das:

2014.05.01 19:55:52 4: Schalter_channelB_B0: set hash->{DEVICE} B0
2014.05.01 19:55:52 2: EnOcean set LichtDeckeStephan B0
2014.05.01 19:55:52 4: Schalter_channelB_B0: set hash->{DEVICE} B0
2014.05.01 19:55:52 2: EnOcean set LichtDeckeStephan B0
2014.05.01 19:07:46 4: Schalter_channelB_B0: set hash->{DEVICE} B0

Ich sehe auf FHEMHome (Enocean) unter readingsProxy den Schalter
Schalter_channelB_B0, eine Glühbirne und die Schaltfläche toggle.
Auf toggel gedrückt ändert die Glühbirne ihren Zustand. WAS auch passiert, wenn ich
den physischen Schalter drücke. DAS IST DOCH SCHON WAS :-)
Nun muss ich mir noch einen virtuellen EnOcean(FHEM) schalter machen und ihn
indirekt verbinden.

Dazu dann später mehr...

Euch allen einen schönen Abend,
Stephan
Titel: Antw:Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: pst am 01 Mai 2014, 20:24:31
Hi,

jetzt schnell noch das selbe definiert für BI.
...
Leider funktioniert dies nun nicht mehr wie gewollt.
Zweiter Eintrag bei readingsProxy. OK. Nun habe ich 2 Glühbirnen und zwei Schaltflächen mit toggle.
Soweit so gut.
Wenn ich nun BI oder  B0 schalte (egal ob über Schaltfläche oder pysischen Schalter) verändern sich BEIDE
Glühbirnen.
Beide readingsProxy reagieren auf BI und B0.

Wie muss ich readingsProxy definieren, dass nur auf ein Kanal gehört wird?

Gruss,
Stephan
Titel: Antw:Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: justme1968 am 01 Mai 2014, 20:40:27
du darfst den state nicht aus dem original device lesen (da ist es ja mit beiden tasten verknüpft) sondern musst state aus dem proxy device lesen (da ist es ja getrennt) und auch im proxy device setzen. der setzten teil geht so wie hier: http://forum.fhem.de/index.php/topic,22753.msg161542.html#msg161542 (http://forum.fhem.de/index.php/topic,22753.msg161542.html#msg161542)

gruss
  andre
Titel: Antw:Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: krikan am 01 Mai 2014, 21:28:57
@pst: Sorry Stephan, das es nicht klappt.  :-[

@justme: Andre könntest Du das als Beispiel liefern. Bekomme es trotz Deines Forums-Verweises nicht umgesetzt. Stephans Problem ist, dass ein Kanal 2. Lampen schaltet. Der state "B0" schaltet eine Lampe an und aus genauso wie "BI" eine andere Lampe. Das Originaldevice schickt also immer den gleichen set-Befehl zum an- und auschalten.

Danke, Christian
Titel: Antw:Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: krikan am 01 Mai 2014, 22:13:56
Bastelstunde (Trial-and-error)/ Hiermit habe ich anscheinend Erfolg:

define Schalter_channelA readingsProxy Schalter:state
attr Schalter_channelA eventMap A0:toggle
attr Schalter_channelA room EnOcean
attr Schalter_channelA setFn {readingsSingleUpdate($defs{$name}, "state", (ReadingsVal("Schalter_channelA","state",0) eq "off")?"on":"off", 1);; {"A0"};;}
attr Schalter_channelA setList A0:noArg
attr Schalter_channelA valueFn {undef}
attr Schalter_channelA verbose 5
attr Schalter_channelA webCmd toggle


Stephan und Andre: Kommentare ;)
Titel: Antw:Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: justme1968 am 01 Mai 2014, 23:00:46
sorry kann gerade nicht wirklich schauen aber auf den ersten blick ist das genau die richtung.

den Umweg über die eventmap kannst du dir eigentlich sparen und in der setList direkt toggle angeben.

gruss
  andre
Titel: Antw:Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: pst am 02 Mai 2014, 09:34:45
Hi,

definition für B0 (dementsprechend auch BI) sieht nun so aus:

define Schalter_channelB_B0 readingsProxy LichtDeckeStephan:state
attr Schalter_channelB_B0 room EnOcean
attr Schalter_channelB_B0 setFn {readingsSingleUpdate($defs{$name}, "state", (ReadingsVal("Schalter_channelB_B0","state",0) eq "off")?"on":"off", 1);; {"B0"};;}
attr Schalter_channelB_B0 setList toggle
attr Schalter_channelB_B0 valueFn {undef}
attr Schalter_channelB_B0 verbose 5
attr Schalter_channelB_B0 webCmd toggle

Damit funktioniert das toggeln der Glühbirnen für B0 und BI über das FHEMHome sehr schön.
Über den physischen Schalter passiert ABER nix mehr auf FHEMHome. 
... was vorher einen Einfluss hatte.auf FHEMHome.

Muss da was für valueFn gesetzt werden?

Gruss Stephan

PS.: wie Andre geschrieben hat:
eventMap A0:toggle + setList A0:noArg   <=> setList toggle

Titel: Antw:Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: krikan am 03 Mai 2014, 10:05:03
Hallo,

habe keine Ahnung, wie man den physischen Taster über valueFn im Proxydevice abbilden könnte. Würde das über ein notify, das auf Events vom physischen Taster reagiert und mittels setreading den state des Proxydevices ändert, lösen. Zudem würde ich das Proxydevice sowieso vom Fhem-switch ableiten und nicht vom Device für den physischen Taster.

Mit Klaus´ Beispiel habe ich immer noch Probleme:
Wenn ich das ReadingsProxy-Beispiel auf einen Fhem-Switch anwende, der unidi-Aktoren steuert, wird der state im Proxydevice nicht korrekt auf on/off sondern auf A0/AI aktualisiert. Das Lampensymbol devStateIcon funktioniert dann bei Steuerung über das Proxydevice eben nicht.

Gruß, Christian
Titel: Antw:Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: justme1968 am 03 Mai 2014, 10:11:44
wegen dem on/off a0/a1 problem ist es besser wie oben vorgeschlagen die eventMap weg zu lassen und in setList direkt in und off zu verwenden.

das mit dem schalten am echten device schaue ich mir mal an. ich habe aber keine enocean devices. kann also nicht wirklich testen.

könnt ihr mir mal ein eventog zeigen bei dem am schalter geschaltet wird?

gruss
  andre
Titel: Antw:Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: krikan am 03 Mai 2014, 10:41:47
Eventlog des Schalters sieht so aus

2014-05-03 10:32:50 EnOcean EnO_switch buttons: pressed
2014-05-03 10:32:50 EnOcean EnO_switch channelB: BI
2014-05-03 10:32:50 EnOcean EnO_switch BI
2014-05-03 10:32:50 EnOcean EnO_switch buttons: released
2014-05-03 10:32:50 EnOcean EnO_switch buttons: released
2014-05-03 10:32:50 EnOcean EnO_switch buttons: pressed
2014-05-03 10:32:50 EnOcean EnO_switch channelB: B0
2014-05-03 10:32:50 EnOcean EnO_switch B0
2014-05-03 10:32:51 EnOcean EnO_switch buttons: released
2014-05-03 10:32:51 EnOcean EnO_switch buttons: released
2014-05-03 10:32:51 EnOcean EnO_switch buttons: pressed
2014-05-03 10:32:51 EnOcean EnO_switch channelA: A0
2014-05-03 10:32:51 EnOcean EnO_switch A0
2014-05-03 10:32:51 EnOcean EnO_switch buttons: released
2014-05-03 10:32:51 EnOcean EnO_switch buttons: released
2014-05-03 10:32:52 EnOcean EnO_switch buttons: pressed
2014-05-03 10:32:52 EnOcean EnO_switch channelA: AI
2014-05-03 10:32:52 EnOcean EnO_switch AI
2014-05-03 10:32:52 EnOcean EnO_switch buttons: released
2014-05-03 10:32:52 EnOcean EnO_switch buttons: released


Ich bastel aber noch, habe Dein readingsProxy noch nicht genau verstanden. Darum liegt der Fehler wohl eher hier vor der Tastatur.

Gruß, Christian
Titel: Antw:Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: krikan am 03 Mai 2014, 20:51:32
Meine vorläufigen, schmalen Erkenntnisse und Zusammenfassung zu readingsProxy und mehrkanaligen EnOcean-Switch:

Bei einem physikalichen Schalter, der in FHEM zur Visualiserung genutzt wird (kann keine Aktoren durch FHEM steuern!) gibt es die Readings ChannelA, ChannelB,.. aus den das Proxydevice abgeleitet werden kann. Eventlog hierzu siehe vorheriges Posting.

Die mMn interessanteren FHEM-TCM-Switches zur Steuerung von Aktoren haben bei mir immer nur das Reading state. ReadingsProxy muss vom Reading "state" des Devices abgeleitet werden. Musterkonfiguration für diesen Fall bei der ich bisher keine Fehlfunktionen festgestellt habe:

#FHEM-TCM-Switch zur Aktorsteuerung
define Schalter EnOcean FFAFFF81
attr Schalter subType switch


#Kanal B zur Steuerung mit on und off
define Schalter_channelB readingsProxy Schalter:state
attr Schalter_channelB setFn {readingsSingleUpdate($defs{$name}, "state", $CMD, 1);;($CMD eq "on")?"BI":"B0";;}
attr Schalter_channelB setList on off
attr Schalter_channelB valueFn {undef}
attr Schalter_channelB webCmd on:off


#Kanal C zur Steuerung mit on und off
define Schalter_channelC readingsProxy Schalter:state
attr Schalter_channelC setFn {readingsSingleUpdate($defs{$name}, "state", $CMD, 1);;($CMD eq "on")?"CI":"C0";;}
attr Schalter_channelC setList on off
attr Schalter_channelC valueFn {undef}
attr Schalter_channelC webCmd on:off


Bessere Vorschläge/Gegenmeinungen sind ausdrücklich erwünscht!  ;)

@Justme1968: Wenn ich im Attribut valueFn den Platzhalter $CMD nutze, erhalte ich immer den Fehler valueFn: Global symbol "$CMD" requires explicit package name at (eval 265) line 1. Hast Du einen Hinweis, was ich falsch mache?

Gruß, Christian


Titel: Antw:Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: justme1968 am 05 Mai 2014, 11:22:32
in der valueFn gibt es kein $CMD. die doku war falsch.

valueFn wird zu einem zeitpunkt aufgerufen an dem es nicht unbedingt einen zusammenhang mit der setFn und einem kommando gibt. wenn es das letzte kommando nicht im original device gibt würde ich vorschlagen es in ein reading im proxy device zu stecken.

edit: ich baue das direkt ins modul ein. es gibt dann ein lastCmd reading und du hast in der valueFn zugriff auf $LASTCMD.

edit2: eventuell gibt es für die devices die nur toggeln noch ein problem beim fhem neu start. ich weiss nicht genau ob dann alles konsistent ist. das müsste sich mit lastCmd auch in den griff bekommen lassen.

gruss
  andre
Titel: Antw:Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: justme1968 am 05 Mai 2014, 14:23:38
ps: die valueFn ist dazu da aus dem reading des original device den aktuellen status des proxy device abzuleiten.

wenn du den status nicht aus dem original device nehmen kannst sollte mit der änderung oben möglich sein z.b. {$LASTCMD}als valueFn zu verwenden. du würdest dann direkt das letzte on oder off als status verwenden. d.h. das setReading state könnte entfallen.

gruss
  andre
Titel: Antw:Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: krikan am 05 Mai 2014, 14:25:57
Zitatedit: ich baue das direkt ins modul ein.
Danke!!

Zitatedit2: eventuell gibt es für die devices die nur toggeln noch ein problem beim fhem neu start.
Direkt nach dem Neustart zeigten bei mir sowohl Proxydevices mit toggle als auch mit on/off jeweils nur "initialized" als devstate an. Erst nach dem ersten Schalten war der Zustand korrekt zu sehen. Habe diesem Problem aber bisher keine Beachtung geschenkt. Hatte in der Testumgebung aber auch Fehlermeldungen für fhem.save. Schaue ich mir nach Deinem Umbau noch mal an.

Gruß, Christian
Titel: Antw:Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: pst am 10 Mai 2014, 10:49:12
Hallo Andre, hi Christian,

habe mir den Kommentar zu Herzen genommen:
Die readingsProxy gehen nun auf den Fhem Schalter. Mit notify auf den physischen Schalter wird der state der readingsProxy gesetzt.
So sieht es aus:
Def. physischer und Fhem Schalter


define EnOSwitch_Stephan EnOcean xxxxxxx
attr EnOSwitch_Stephan IODev TCM310_0
attr EnOSwitch_Stephan room EnOcean
attr EnOSwitch_Stephan subType switch
# ------------------------------------------------------------
define FhemSwitch_Stephan EnOcean xxxxxx
attr FhemSwitch_Stephan IODev TCM310_0
attr FhemSwitch_Stephan room EnOcean
attr FhemSwitch_Stephan subType switch


Def.s readingsProxy

define rPA_StephanDecke readingsProxy FhemSwitch_Stephan:state
attr rPA_StephanDecke setFn {readingsSingleUpdate($defs{$name}, "state", $CMD, 1);;($CMD eq "on")?"AI":"A0";;}
attr rPA_StephanDecke setList on off
attr rPA_StephanDecke valueFn {$LASTCMD}
attr rPA_StephanDecke webCmd on:off

define rPB_StephanWand readingsProxy FhemSwitch_Stephan:state
attr rPB_StephanWand setFn {readingsSingleUpdate($defs{$name}, "state", $CMD, 1);;($CMD eq "on")?"BI":"B0";;}
attr rPB_StephanWand setList on off
attr rPB_StephanWand valueFn {$LASTCMD}
attr rPB_StephanWand webCmd on:off


Notify auf den physischen Switch

define act_on_EnOSwitch_Stephan notify EnOSwitch_Stephan {\
if ($EVENT eq "B0") {\
    {Log 3, ('****** EnOSwitch_Stephan B0='.$EVENT)}\
    if (Value("rPA_StephanDecke") ne "on") {\
      fhem("setstate rPA_StephanDecke on")\
    }\
    else {\
      fhem("setstate rPA_StephanDecke off")\
    }\
}\
elsif ($EVENT eq "BI") {\
    {Log 3, ('****** EnOSwitch_Stephan BI='.$EVENT)}\
    if (Value("rPB_StephanWand") ne "on") {\
      fhem("setstate rPB_StephanWand on")\
    }\
    else {\
      fhem("setstate rPB_StephanWand off")\
    }\
}\
}


Anlernen muss man hierbei A0 und AI vom Fhem Schalter auf einen Kanal (!).
(Im EnOcean Starter Guide wird bei dem FSA12 Beispiel nur B0 angelernt, das scheint mir falsch zu sein!)

Wenn es dann mal funktioniert, fragt man sich, wo war da jetzt eigentlich das Problem.
Was bleibt, ist das refresh Problem, wenn man den phyisischen Schalter drückt (nach refresh Browser stimmt die Anzeige) und die Möglichkeit, dass die Anzeige
nicht stimmt. Das mit der Anzeige ist klar, da .... (keine Rückmeldung vom Aktor/Fhem nicht online - Schalter gedrückt/Signal verpasst/ usw.).

Im EnOcean Starter Guide gibt es keinen Hinweis auf readingsProxy. War readingsProxy jetzt eigentlich nötig?
Die readingsProxy senden ja jetzt A0/AI und B0/BI jeweils auf einen Kanal. Hat man davon einen Vorteil.
Man könnte es doch auch so machen, dass ein readingsProxy A0, ein anderes Ai usw. benutzt.
Was hättet Ihr anders/schöner gemacht?

Habt Ihr dazu noch Kommentare?

Was bleibt noch,...
meinen Dank an euch Beiden(!);
super Projekt,.. dieses Fhem(!),...;
super Support (!);

Euch ein schönes Wo-Ende.
Gruss Stephan








Titel: Antw:Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: krikan am 10 Mai 2014, 20:52:29
Hallo Stephan,

freut mich das es läuft.

ZitatWas bleibt, ist das refresh Problem, wenn man den phyisischen Schalter drückt
Nutze mal im notify statt setstate das FHEM-Kommando setreading für "state". Oder füge alternativ nach setstate noch ein trigger hinzu. Sollte das Beheben.

ZitatIm EnOcean Starter Guide gibt es keinen Hinweis auf readingsProxy. War readingsProxy jetzt eigentlich nötig?
readingsProxy ist noch relativ jung und das Wiki braucht Pflege. Ob readingsProxy notwendig war? Du kommst sicherlich auch ohne zum Ziel. Bei mir geht es alles ohne, aber nur weil es readingsProxy bei meinem Einstieg in FHEM noch nicht gab und ich noch keine Zeit zum Anpassen/Überdenken hatte.

ZitatsetFn {readingsSingleUpdate($defs{$name}, "state", $CMD, 1);;($CMD eq "on")?"AI":"A0";;}
Wenn ich {LASTCMD} richtig verstanden habe, könntest Du das Gestrichene löschen. Sollte durch {LASTCMD} erledigt werden.

Gruß, Christian


edit: Trigger-Variante wird vermutlich nicht funktionieren.
Titel: Antw:Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: justme1968 am 10 Mai 2014, 21:56:44
brauchen tut man es natürlich nicht. man kann alles auch zu fuss mit notifys, dummys und 99_myUtils machen. aber spätestens wenn es ausser on und off noch toggle oder on-for-timer, on-till oder änliches sein soll ist ein 'fertiges' device einfacher.

das ist wie mit allen anderen hilfs devices auch. brauchen tut man weder structure noch LightScene oder watchdog oder THRESHOLD oder average oder devpoint ...

Zitat von: krikan am 10 Mai 2014, 20:52:29
Wenn ich {LASTCMD} richtig verstanden habe, könntest Du das Gestrichene löschen. Sollte durch {LASTCMD} erledigt werden.

fast. das gestrichene kann weg und {$LASTCMD} als valueFn verwenden. dann sollte auch nach dem start von fhem das proxy device den rictigen status haben.

gruss
  andre
Titel: Antw:Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: krikan am 11 Mai 2014, 10:58:01
Zitatfast. das gestrichene kann weg und {$LASTCMD} als valueFn verwenden. dann sollte auch nach dem start von fhem das proxy device den rictigen status haben.
Genau das meinte ich; valueFn hat Stephan ja bereits korrekt angelegt. ;)

Nach Fhem-Neustart ist (dev-?)state nun nach Verwendung von {$LASTCMD} korrekt.

Zur Threadvervollständigung: Meine Enocean-Musterkonfiguration für readingsProxy nach Einführung von {$LASTCMD} sieht nun so aus:

#FHEM-TCM-Switch zur Aktorsteuerung
define Schalter EnOcean FFAFFF81
attr Schalter subType switch


#Kanal B zur Steuerung mit on und off
define Schalter_channelB readingsProxy Schalter:state
attr Schalter_channelB setFn {($CMD eq "on")?"BI":"B0";;}
attr Schalter_channelB setList on off
attr Schalter_channelB valueFn {$LASTCMD}
attr Schalter_channelB webCmd on:off


#Kanal C zur Steuerung mit on und off
define Schalter_channelC readingsProxy Schalter:state
attr Schalter_channelC setFn {($CMD eq "on")?"CI":"C0";;}
attr Schalter_channelC setList on off
attr Schalter_channelC valueFn {$LASTCMD}
attr Schalter_channelC webCmd on:off
Titel: Antw:Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: pst am 13 Mai 2014, 19:26:35
Hallo Christian,

wegen refresh: ... setreading für "state" ... hat funktioniert. Sehr schön!

Könntest Du mal in den thread:
Fhem Schalter als Taster für ZentralAus 
reinschauen.

Wegen dem EnOcean Starter Guide:
Ich würde wohl meine scenarien dokumentieren, fühle mich aber 'noch' nicht in der Lage, die ganzen
parameter/attribute/Funktionen -, und wie sie zusammenspielen, zu beschreiben.

Werde nun alle meine Schalter definieren und mich dem Web-Frontend zuwenden.

Das ist jetzt nicht mein thread. Ist dieser thread gelöst und wer setzt ihn um?

Gruss Stephan
Titel: Antw:Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: 50watt am 21 Juni 2014, 21:56:23
Ich habe mal den EnOcean_Starter_Guide  (http://www.fhemwiki.de/wiki/EnOcean_Starter_Guide#Taster_-_physisch_und_in_Fhem) diesbezüglich aktualisiert - passt das so?
Titel: Antw:Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: krikan am 21 Juni 2014, 22:08:44
Danke! Passt nach meiner Meinung.
Entspricht auch justme1968´s Erläuterungen: http://www.fhemwiki.de/wiki/ReadingsProxy
Titel: Antw:Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: doba am 20 Oktober 2014, 22:45:01
Hallo allerseits,

ich habe mittlerweile meinen FMS61NP auch angelernt bekommen, habe jetzt aber noch ein problem was das Ansteuern der beiden Kanäle betrifft.
Anbei die Definitionen.
Das Problem:
Wenn ich den Befehl A0 sende schaltet das Relais, kurz darauf wird aber der Status B0 gemeldet.
Analog: Wenn ich B0 sende schaltet das Relais, kurz darauf wird aber der Status A0 gemeldet.
Das gleiche beim Aussschalten.
Das hat zur Folge, dass das Lampensymbol immer am anderen Kanal AN oder AUS ist als ich eigentlich schalte.
Hat jemand eine Idee womit das zusammen hängen kann?

define Eltako_Kueche EnOcean 018Cxxxx
attr Eltako_Kueche IODev TCM310_ESP3
attr Eltako_Kueche group FMS61-NP
attr Eltako_Kueche subDef FF9Fxxxx
attr Eltako_Kueche subType switch

define Eltako_Kueche_A readingsProxy Eltako_Kueche:channelA
attr Eltako_Kueche_A group FMS61-NP
attr Eltako_Kueche_A setFn {($CMD eq "on")?"A0":"AI";;;;}
attr Eltako_Kueche_A setList on off
attr Eltako_Kueche_A valueFn {($VALUE eq "A0")?"on":"off"}
attr Eltako_Kueche_A webCmd on:off

define Eltako_Kueche_B readingsProxy Eltako_Kueche:channelB
attr Eltako_Kueche_B group FMS61-NP
attr Eltako_Kueche_B setFn {($CMD eq "on")?"B0":"BI";;;;}
attr Eltako_Kueche_B setList on off
attr Eltako_Kueche_B valueFn {($VALUE eq "B0")?"on":"off"}
attr Eltako_Kueche_B webCmd on:off

Danke schonmal
Gruß
DoBa
Titel: Antw:Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: krikan am 20 Oktober 2014, 23:43:10
Du hast vermutlich nicht entsprechend http://www.fhemwiki.de/wiki/EnOcean-FMS61NP-2-Kanal-Multifunktions-Stromsto%C3%9Fschalter#Definition.2FAnlernvorgang angelernt, sondern Kanal 1 mit set Eltako_Kueche A0 und Kanal 2 mit set Eltako_Kueche B0. Da Kanal 1 immer mit channelB Statustelegramme verschickt und Kanal 2 mit channelA, ist es jetzt bei Dir verdreht.

edit: tausche mal die setFn der readingsProxy-Devices oder die saubere Lösung von Norbert
Titel: Antw:Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: Norberto am 20 Oktober 2014, 23:44:24
Ups, da war mir krikan zuvorgekommen.....

Guten Abend,

Kanal 1 entspricht B0/BI, Kanal 2 entspricht A0/AI.

Wenn Du die Kanäle so herum anlernst klappt es. Funktioniert bei mir. Dazu gibts hier auch irgendwo einen Thread.

Gruß, Norbert
Titel: Antw:Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: doba am 21 Oktober 2014, 20:13:46
Hallo,
vielen Dank euch beiden. Das war in der Tat der Fehler. Ich habe den Abschnitt auch gelesen, aber irgednwo anders stand es anders herum mit A und B.

Habt ihr Erfahrung mit der Reichweite des EnOcean USB Gateways?
Bei mir ist die Reichweite aktuell sehr schlecht. Wenn der Raspberry, auf dem Fhem läuft, noch keine 10 Meter (ohne Wände) von dem Eltako-Aktor entfernt ist kommen die Signale nicht mehr richtig an. Die FS20 Geräte funktionieren einwandfrei.
Kann man bzgl Signalstärke etwas einstellen? Ich habe bisher nichts dazu gefunden.

Gruß
Doba
Titel: Antw:Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: bert am 04 Januar 2015, 00:44:22
@krikan @doba
seid ihr sicher, dass das subDef in den sog. Master kommt. Bin der Auffassung, da es ja 2 subDef´s gibt, für jeden Kanal eine, und dass diese in die beiden readingsProxy gehören. Komme erst zum Wochende auf meine Baustelle. Dort werde ich das mal testen. Das Wiki hat mich doch ganz schön verwirrt.

Gutes Neues Jahr
Bert
Titel: Antw:Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: krikan am 04 Januar 2015, 00:49:41
Verstehe Dein Problem leider nicht, könntest Du das bitte an einem Beispiel erläutern?
Willst Du subDef in das readingsProxy-Device aufnehmen?
Titel: Antw:Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: bert am 04 Januar 2015, 01:12:57
Guten Morgen
ich muss doch beide Kanäle getrennt anlernen und habe dadurch ja auch 2 unterschiedliche Sender Id´s.

Bert
Titel: Antw:Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: krikan am 04 Januar 2015, 01:25:43
Guten Morgen zurück ;)

Nein, du hast nur ein Aktordevice mit einer Sender-ID des Gateways (subDef), das mit AI/A0 und BI/B0 die Kanäle ansteuert/anlernt. Das ist notwendig, da die Bestätigungstelegramme für beide Kanäle die gleiche AbsenderID haben, die in der Definition des Aktordevices enthalten ist.

Bei Deiner Vorstellung hättest Du 2 getrennte Aktordevices und bräuchtest readingsProxy nicht. Bei unidi-Aktoren ist Dein Gedankengang problemlos umsetzbar; bei bidi-Devices ohne Auswertung der Bestätigungstelegramme wäre es auch möglich, aber wohl nicht sinnvoll.

Gruß, Christian
Titel: Antw:Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: bert am 04 Januar 2015, 09:56:14
Beide subDef kommen in den Master. Wobei ich nicht weiß ob die überhaupt benötigt werde. Schalten kann ich jeden Kanal per Fhem auch ohne Diese. Lediglich die Rückmeldung vom KanalA0 konnte ich nicht durch ein Icon darstellen. 

hier der Auszug aus der .cfg

#Lampe Master
define Terrasse EnOcean 018992A0
attr Terrasse IODev TCM_ESP2_1
attr Terrasse group Licht
attr Terrasse manufID 00D
attr Terrasse model other
attr Terrasse room EnOcean
attr Terrasse subDef FFE53809
attr Terrasse subDef0 FFE53808
attr Terrasse subType switch
#attr Terrasse eventMap A0:an AI:aus
define FileLog_Terrasse FileLog ./log/Terrassee-%Y.log Terrasse
attr FileLog_Terrasse logtype text
attr FileLog_Terrasse room Log

######
#Lampe
define Terrasse_Lampe_vorne readingsProxy Terrasse_Lampe_vorne:channelA
attr Terrasse_Lampe_vorne group Licht
attr Terrasse_Lampe_vorne room Terrasse
attr Terrasse_Lampe_vorne setFn {($CMD eq "on")?"A0":"AI";;;;}
attr Terrasse_Lampe_vorne setList on off
attr Terrasse_Lampe_vorne valueFn {($VALUE eq "A0")?"on":"off"}
attr Terrasse_Lampe_vorne webCmd on:off

######
#Lampe
define Terrasse_Lampe_hinten readingsProxy Terrasse_Lampe_hinten:channelB
attr Terrasse_Lampe_hinten group Licht
attr Terrasse_Lampe_hinten room Terrasse
attr Terrasse_Lampe_hinten setFn {($CMD eq "on")?"B0":"BI";;;;}
attr Terrasse_Lampe_hinten setList on off
attr Terrasse_Lampe_hinten valueFn {($VALUE eq "B0")?"on":"off"}
attr Terrasse_Lampe_hinten webCmd on:off


Bert
Titel: Antw:Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: krikan am 04 Januar 2015, 10:09:26
Wenn Du mir nicht glauben magst, dann mach es so. ;) Ist aber mMn nicht sinnvoll. Du verschwendest eine SenderID unnötig. Von den Seiteneffekten, die Du mit Deinem Vorgehen auslösen kannst (einen siehst Du schon), ganz zu schweigen. Wenn es für Dich so läuft, dann lass es bitte so.

Alle anderen nehmen besser die Variante aus dem Wiki: http://www.fhemwiki.de/wiki/EnOcean-FMS61NP-2-Kanal-Multifunktions-Stromsto%C3%9Fschalter. Was stört Dich eigentlich an der Wiki-Vorgehensweise?

PS: Das ist hier eigentlich verdammt Off-Topic, da es um den Anlernvorgang des Aktors geht und nicht readingsProxy.

edit: Dir ist bekannt, dass eine SenderID 4-Kanäle hat, die unabhängig von einander sind. Siehe bspw. http://www.fhemwiki.de/wiki/EnOcean_Starter_Guide#Teach-In_als_Tasteremulation.
Titel: Antw:Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: bert am 04 Januar 2015, 12:07:15
Wenn ich beim FMS61 beide Kanäle getrennt schalten will brauch ich auch 2 Sender ID. Also verschwende ich keine. Anstatt meinen Beitrag als Off-Topic einzustufen hättest Du besser mal gelesen, denn es ging niemals um das Anlernen des Aktor´s, sondern um eine erforderliche Ergänzung im Wiki.  Entgegen Deiner Behauptung "es gibt  nur eine Sender-Id" hat EnOcean für diverse Aktoren mehrere subDef´s vorgesehen (siehe Commandref). 
Wenn Du es schaffst, könntest Du mir ja sagen wie ich die beiden Kanäle separat  mit 1er Sender-Id schalten kann, "damit ich keine verschwende". Ansonsten könnte ich vermuten dass Du noch keinen FMS61 angelernt hast.

Optimal wäre gewesen, wenn Du mir mitgeteilt hättest wofür die subDef´s gut sind. Bei mir "in der realen Welt" funktioniert nämlich das Schalten dieser Aktoren aus Fhem auch ohne subDef´s problemlos. Lediglich die Anzeige des Icon´s für KanalA0 hat mir gefehlt (was ja durch Wiki gelöst wurde)

Was verstehst Du unter Seiteneffekten, die ich auslöse ? Was ich sehe ist, dass das Wiki an dieser Stelle überarbeitet werden sollte. Entweder, das mit der subDef raus, oder die subDef0 bzw. subDefI mit dazu.

Ansonsten stört mich nichts an der Wiki-Vorgehensweise, ausser Deiner Behauptung.

Bert
Titel: Antw:Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: krikan am 04 Januar 2015, 12:52:02
War die Nacht zu lang?  :o

Du solltest bitte einmal mein Geschriebenes noch einmal durchlesen und auch das Wiki noch einmal anschauen. Ich sehe keine Fehler.

Zitat von: bert am 04 Januar 2015, 12:07:15
Wenn ich beim FMS61 beide Kanäle getrennt schalten will brauch ich auch 2 Sender ID.
Das ist falsch und hatte ich versucht zu erläutern. Wenn Du es nicht verstehst, entschuldige ich mich vielmals für meine pädagische Unfähigkeit.. :-[ Bitte lese das Enocean Starter Guide

Zitat
Entgegen Deiner Behauptung "es gibt  nur eine Sender-Id" hat EnOcean für diverse Aktoren
Das habe ich nicht behauptet, schau es Dir bitte noch einmal an, was ich geschrieben habe

ZitatWas ich sehe ist, dass das Wiki an dieser Stelle überarbeitet werden sollte. Entweder, das mit der subDef raus, oder die subDef0 bzw. subDefI mit dazu.
Da ist alles korrekt. Gehe doch bitte einfach schrittweise den Anlernvorgang noch einmal durch. Vielleicht fällt Dir dann etwas auf.

Und Du bist nmM Off-Topic, da Dein Problem nicht bei readingsProxy liegt, sondern beim grundlegenden Verständnis. Sorry, das ist nicht böse gemeint.

Was natürlich sein könnte, dass Du einen seltenen Modus beim Aktor nutzt, bei dem alles anders ist als sonst oder Du nutzt gar nicht den FMS.....

Gruß, Christian 8)
Titel: Antw:Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: bert am 04 Januar 2015, 13:40:04
Ich habe Deine Erläuterung leider nicht gefunden, könntest Du mir die bitte nochmal zukommen lassen. Bin gerne bereit von Dir zu lernen.

Was ist mit meiner Frage zu subDef ?

Ich hab auch keine Fehler bemängelt.

Gruß, Bert


P.S.
ich hab ne ganze Hütte voll Eltako´s (ca. 30 Aktoren FUD,FMS,FSR,FSG,MS+Kleinzeug) und alles funktioniert. Geh davon aus, dass ich anlernen kann. Hab halt alles nach Eltako-Vorgaben, Forum-lesen, Wiki-lesen und Try+Error gemacht, jetzt fehlt mir nur noch der Geistesblitz aus Deiner Erläuterung um keine Sender-Id´s zu verschwenden.
Titel: Antw:Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: krikan am 04 Januar 2015, 13:58:40
Du brauchst nur eine SenderID(subDef), da diese mehrere Kanäle A-D hat. Kanal A der SenderID wird an einem Aktorkanal und Kanal B der SenderID an dem anderen Aktorkanal angelernt. Wie Du das genau machen musst, steht detailliert und schrittweise im Wiki http://www.fhemwiki.de/wiki/EnOcean-FMS61NP-2-Kanal-Multifunktions-Stromsto%C3%9Fschalter#Definition.2FAnlernvorgang.

Im Fazit schaltest Du den einen Aktor-Kanal mit "set <Aktordevice> BO/BI" und den anderen mit "set <Aktordevice> AO/AI". Dahinter steckt aber immer die gleiche SenderID, die im subDef steht.

Keine Ahnung, was ich mehr dazu schreiben soll. Oder ich verstehe Dich nicht, dann sollte wer anderes übernehmen/eingreifen oder Du musst es noch einmal anders erklären. :-[

Zitatich hab ne ganze Hütte voll Eltako´s (ca. 30 Aktoren FUD,FMS,FSR,FSG,MS+Kleinzeug)
So wenig....  ;)  :P
Titel: Antw:Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: krikan am 04 Januar 2015, 14:13:12
ZitatBei mir "in der realen Welt" funktioniert nämlich das Schalten dieser Aktoren aus Fhem auch ohne subDef´s problemlos
Sorry, das realisiere ich erst jetzt und kann ich überhaupt nicht deuten. In den subDef steht bei bidi-Aktoren immer eine SenderID des TCMs. Ohne subDef dürftest Du nicht über Fhem schalten können. Wie schaffst Du das? Lernst Du als unidi-Taster-Emulation ein? Hast Du keine bidi-Aktoren?
Titel: Antw:Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: krikan am 04 Januar 2015, 17:25:36
Hallo Bert!

Bist Du jetzt klargekommen?
ZitatWas ich sehe ist, dass das Wiki an dieser Stelle überarbeitet werden sollte. Entweder, das mit der subDef raus, oder die subDef0 bzw. subDefI mit dazu.
Siehst Du noch einen Grund das Wiki in irgendeiner Form anzupassen, damit nicht andere über evtl. nicht durchgeführten Bearbeitungsbedarf stolpern?

Danke für Deine Antwort.
Gruß, Christian
Titel: Antw:Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: bert am 04 Januar 2015, 17:56:44
Deine Erläuterung und das mehrfache Nachlesen im Wiki haben mir den erwünschten Geistesblitz gebracht. Du hast Recht. Wiki ist ok. Eine ID reicht.

DAS ist Off-Topic
Meine Vorgehensweise bei den Aktoren ist:
1. Bestätigungtelegramm einschalten.
2. Realen Taster am Aktor einlernen als Universaltaster. Fast alle Taster sind mehrfach mit Aktoren belegt und sollte ich doch eine Wippe frei haben ist diese "Reserve".
3. Der Aktor wird durch den Einlernvorgang des Tasters im Fhem erkannt und angelegt, natürlich mit der Sender-ID für´s TCM.
4. Rename des Aktors in ein (für mich) erkennbares Device in Fhem.
5. Den Softschalter im Fhem definieren mit einer freien Sender-ID des TCM.
6. Den Softschalter am Aktor einlernen als Universaltaster.
7. Im Fhem die benötigten Attribute für den Aktor setzen. Bis hierhin funktioniert alles auch ohne subDef problemlos.
wenn kein Bestätgungstelegramm käme hätte ich wohl alte "unidi" Aktoren. Darüber musste ich mir nie Gedanken machen. Was sind "bidi" Aktoren.

Ich kann jedenfalls mit dem Handy(Webviewcontrol) durch´s Haus laufen und die Lampen schalten(ohne subDef).
Nun hätte ich gerne gewusst wie ich das anders/besser machen kann.
Und die Antwort auf "wofür ist subDef gut" steht noch aus.

Gruß, bert

Titel: Antw:Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: krikan am 04 Januar 2015, 19:18:51
Jetzt wird mir klarer, warum wir solche Verständigungsprobleme haben:

Du hast bidi-Aktoren (wg. Bestätigungstelegrammen) und nutzt im Prinzip die für unidi-Aktoren vorgesehenen Teach-Ins. Funktioniert sicherlich irgendwie, aber ist so nicht so vorgesehen und macht es (vorsichtig formuliert) komplizierter. Du hast für alle Aktoren 2 Fhem-Devices, wo Du nur eines benötigst.

Bei bidi-Aktoren ist der grundlegende Aufbau für das EINZIGE Fhem-Device:

define <name> EnOcean <die SenderID des Aktors>
attr <name> subDef <eine freie SenderID des TCM>

Mir ist jetzt auch klar, was Deine Frage nach "subDef" auslöst. Bei unidi-Aktoren steckt die SenderID des TCM im define des Softschalters. Bei den bidi-Aktoren immer im subDef, damit Steuerung und Anzeige der Bestätigungstelegramme über ein Fhem-Device laufen. Findest Du auch so in der commandref und in http://www.fhemwiki.de/wiki/EnOcean_Starter_Guide. Dort werden auch andere Dinge beantwortet (bidi versus unidi,..). Ich hoffe für mich, dass Du das EnOcean Starter Guide nie gelesen hast, ansonsten bitte ich um Info, wodurch die Mißverständnisse hervorgerufen wurden, damit ich evtl. Anpassungen vornehmen kann.

Fazit aus meiner Sicht: Bitte unbedingt EnOcean Starter Guide durchlesen, Du machst Dir sonst das Fhem-Leben unnötig schwer....
Titel: Antw:Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: bert am 04 Januar 2015, 21:26:16
Bin jetzt an meinem Testsystem genau nach Anleitung für einen FSR61 vorgegangen. Funktioniert hab nur 1 Device welches ich auch schalten kann. Leider gibt es im Reading nur Status, und der wird gefüllt mit "released". Der Zustand on/off ist nicht mehr erkenntlich.

Gruß
Bert 
Titel: Antw:Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: krikan am 04 Januar 2015, 21:33:39
Hast Du die Bestätigungstelegramme eingeschaltet? Eigentlich dürfte "released" nur stehen bleiben, wenn kein Bestätigungstelegramm kommt. Der Zustand on/off wird aus dem Bestätigungstelegramm gespeist. Ansonsten mach mal einen neuen Thread auf. Keine Ahnung, ob 50watt, der den Aktor hat, hier mitliest.
Titel: Antw:Aufteilung der Kanäle des subType switch in unabhängige Devices (readingsProxy)
Beitrag von: bert am 04 Januar 2015, 21:59:52
Das wars auch, nachdem ich das nochmal alles neu gemacht hatte hat´s geklappt. Dafür sind die Icon´s für webCmd weg.

Danke
Bert