EnOcean ansteuern, aber wie?

[Nobby]

Hallo Miteinander und EnOcean Spezialisten,

ich bin neu in diesem Forum und ebenso in der Thematik Fhem mit
EnOcean.

An meiner Frtiz!Box 7390 haengt ein BSC-Bor jedoch mit eingebautem
TCM300 (nicht 120, nicht 310). Ich habe ihn als TCM 310 deklariert und
kann die EnOcean Telegramme meines
4-Kanal Handsensers (steuert ueber 2-Kanaele meine Markise, 2 Kanaele
sind noch frei) und meines
2-Kanal Schalters (soll meine Bad-Beleuchtung dimmen) erkennen und
sehen.

Ein Senden eines Telegramms ist mir jedoch noch nicht geglueckt weder
per set Befehl und auch nicht ueber die Web-Oberflaeche! Die Befehle
werden zwar geloggt jedoch die Aktoren reagieren nicht.

Kann ich ueberhaupt ueber die angelernten Sender, Schalter mit Fhem
die Aktoren ansprechen oder muss ich ueber den CUL "pseudo" Schalter
definieren, die dann in der Lage sind die Aktoren anzusprechen?

Ich bin fuer jede Hilfe dankbar.

[Rudolf Koenig]

> Kann ich ueberhaupt ueber die angelernten Sender, Schalter mit Fhem
> die Aktoren ansprechen

Nein (bzw. nicht beim EnOcean), da die TCM's weigern sich beliebige Adressen
auszusenden. D.h. man muss einen Switch konfigurieren, dessen Adresse im
erlaubten Bereich ist (id bis id+127, wobei id = get TCM idbase), Beispiel:
define switch1 EnOcean ffc54500
und den Aktor lernt man mit
set switch1 BI
an, auf B0 hoert es mWn automatisch.
Theoretisch kann man mit jedem ID (4*2 * 4*2 = 64) Schalterkombinationen
verwenden (A0/AI, B0/BI, C0/CI, D0/DI und jeweils Zweierkombinationen),
weiss aber nicht, wie Aktoren mit Zweierkombinationen anzulernen sind.

Die andere Moeglichkeit ist statt idbase 00000000 zu verwenden, da wird es mWn
mit _einem_ nicht aenderbaren ID ersetzt. Das ist die von EnOcean empfohlene
Methode. Ich wuerde das nicht verwenden, da es damit nur 64 Schalter zu
schalten sind, und auch beim Austausch des PC-Sticks alles neu anzulernen ist,
aber vielleicht verstehe ich noch was nicht.

Achtung: idbase kann man beim TCM nur 10-mal aendern.

Siehe auch http://fhem.de/commandref.html#EnOceanset:
In order to control devices, you cannot reuse the ID's of other devices (like
remotes), instead you have to create your own, which must be in the allowed
ID-Range of the underlying IO device. For this first query the TCM with the
"get <tcm> idbase" command. You can use up to 128 ID's starting with the base
shown there. If you are using an ID outside of the allowed range, you'll see
an ERR_ID_RANGE message in the fhem log.

[Sebastian]

Hallo zusammen,

ich habe das selbe Problem und bekomme es leider nicht gelöst.
Ich habe meinen physischen Schalter mit autocreate erstellt
Das sieht dann wie folgt aus:

eventMap	BI:off B0:on	deleteattr
fm_fav	999	deleteattr
room	Wohnzimmer	deleteattr
subType	switch	deleteattr

DEF	001A928F
LASTIODev	TCM310_0
MSGCNT	4
NAME	wz_RolloHoch
NR	47
STATE	off
TCM310_0_DestinationID	FFFFFFFF
TCM310_0_MSGCNT	4
TCM310_0_RSSI	68
TCM310_0_SecurityLevel	0
TCM310_0_SubTelNum	1
TCM310_0_TIME	2012-09-05 20:17:17
TYPE	EnOcean

Dann habe ich einen "Software Schalter" definiert:

CFGFN
DEF	FFBC4981
NAME	switch1
NR	128
STATE	off
TYPE	EnOcean

Vorher habe ich über get idbase meine ID ermittelt. Diese lautet FFBC4980. Entsprechend habe ich den Schalter +1 mit FFBC4981 benannt.

Jetzt ist mir aber nicht klar, wie ich meinen physischen Schalter mit meinem manuell erstellten verbinde bzw. angelernt bekommen.
Muss ich wie bei der eigentlichen Schalterprogrammierung die passenden Eltako Aktoren in den Lernmodus versetzen (Schalter auf LRN drehen) oder passiert das alles in der Software. Und wenn wie ?

Leider reagiert mein Rollo weder bisher weder auf meinen physischen (per autocreate erstellten) noch auf meinen manuell erstellten Schalter.
Für Hilfe bin ich sehr dankbar.

[krikan]

Hallo!

versetze Eltako-Aktor in den Lernmodus und lerne den Software-Switch FFBC4981 wie einen physischen Taster an. Dann kannst Du mit dem Software-Switch über FHEM schalten.
Den physichen Taster kannst Du mit FHEM nicht direkt emulieren! Daher zeigt FHEM "nur" den Status des physischen Schalters an.
Viel Erfolg!
Christian

[Sebastian]

Also bringt mir die autocreate Funktion im Prinzip leider nichts ?! Werde mich am We mal damit beschäftigen und berichten.

[Rudolf Koenig]

> Also bringt mir die autocreate Funktion im Prinzip leider nichts ?!

Es erkennt immerhin alle normalen Wand-Schalter.

Wenn man Aktoren ohne Sender automatisch erkennen will, dann hat man ein
prinzipielles Problem. Oder ich habe einen Knoten im Hirn.

[joerg]

Die autocreate Funktion ist bei Schaltern in der Tat nicht sehr hilfreich.

Sinnvoll hingegen ist sie bei dem erstellen der Thermostate. Diese werden vom autocreate zuverlässig gefunden und können so vom ersten Tag ihre logging Funktion übernehmen.

joerg

[krikan]

Am Donnerstag, 13. September 2012 10:15:30 UTC+2 schrieb joerg:

Die autocreate Funktion ist bei Schaltern in der Tat nicht sehr hilfreich.

 

 

Hallo Joerg!

 

Ich verstehe das nicht. Habe ich einen Gedankenfehler?

 

Die Stati der physischen Taster braucht man doch grundsätzlich bei allen Steuerungsvarianten:

Indirekte Variante:
Realer Taster ist nicht und Software-Switch ist am Aktor angelernt.
Wenn der reale Taster gedrückt wird, muss FHEM das doch auswerten können, um per Software-Switch den Aktor schalten zu können. Achtung: Wenn FHEM nicht läuft, dann passiert beim Druck auf den Taster nichts. Nach meiner Meinung nur für Komfortfunktionen nutzen.

 

Direkte Variante:
Realer Taster und Software-Switch sind am Aktor angelernt.
Um hier zu wissen, welchen Zustand der Aktor hat, musst Du den realen Taster auch in FHEM auswerten. Die WEB-Darstellung wäre ohne Berücksichtigung des Status des realen Tasters doch unter Umständen falsch.
Zugegeben, bei den neuen Bidi-Enocean-Aktoren (davon habe ich leider nur 3) könnte man dies (besser?) auch anders lösen :
Rücksignal des Aktors auf Schaltbefehl von FHEM auswerten.

 

Wenn ich die Taster manuell anlegen müsste, würde das wenig Spaß bereiten.

 

Danke,
Christian

 

[joerg]

Hallo Christian,

technisch gesehen betreibst Du zwei Sensornetzwerke parallel.

Einmal das Sensor-Netzwerk mit den "physischen" Schaltern und das "Sensor-Netzwerk" welches aus der FB mit TCM besteht.

Die physischen Schalter (Sensoren) lernst du manuell bei den Aktoren an.

Somit ist der Kommunikationsweg:

"physischer Schalter" -> Aktor -> Verbraucher

Das hast Du wahrscheinlich gemacht

Den "FHEM-Schalter" lernst Du nach korrekter definition auch am Aktor an.

Somit ist der Kommunikationsweg:

Webfrontend->Fhem->FB/TCM->Aktor->Verbraucher

Der physische Schalter hat im zweiten Fall keine Bedeutung.

Du kannst die Veränderung der Schaltzustände die von einem physischen Schalter getätigt wurden nicht so einfach im FHEM Frontend sichtbar machen. (über notify aber wahrscheinlich möglich)

So schlimm ist das manuelle Anlegen der Schalter nicht. Man bekommt Übung darin :-)

Joerg

[krikan]

Hallo Joerg!

Am Donnerstag, 13. September 2012 13:30:33 UTC+2 schrieb joerg:

Hallo Christian,

technisch gesehen betreibst Du zwei Sensornetzwerke parallel.

Einmal das Sensor-Netzwerk mit den "physischen" Schaltern und das "Sensor-Netzwerk" welches aus der FB mit TCM besteht.

aber die will/muss ich koppeln...
 

Die physischen Schalter (Sensoren) lernst du manuell bei den Aktoren an.

Somit ist der Kommunikationsweg:

"physischer Schalter" -> Aktor -> Verbraucher

Das hast Du wahrscheinlich gemacht

Habe ich teilweise gemacht. Ist das, was ich als direkte Steuerungsvariante bezeichnet habe.

Den "FHEM-Schalter" lernst Du nach korrekter definition auch am Aktor an.

Somit ist der Kommunikationsweg:

Webfrontend->Fhem->FB/TCM->Aktor->Verbraucher

Einen FHEM-Switch habe ich immer am Aktor angelernt. Nicht nur bei den direkt gesteuerten Aktoren, sondern auch wenn am Aktor kein physischer Schalter angelernt ist (indirekte Variante: Taster->FHEM->Aktor).
 

Der physische Schalter hat im zweiten Fall keine Bedeutung.

Du kannst die Veränderung der Schaltzustände die von einem physischen Schalter getätigt wurden nicht so einfach im FHEM Frontend sichtbar machen. (über notify aber wahrscheinlich möglich)

Doch physischer Schalter hat aus meiner Sicht immer eine Bedeutung. Ich möchte unbedingt die Sichtbarkeit im Frontend. Wenn das nicht gegeben ist, ist WAF weg und ich selbst fände es auch seltsam. Und darum brauche ich auch die physischen Taster im FHEM. Die Abbildung im Frontend habe ich mit folgendem notify erreicht:

define noWoDecke notify pWoDecke:o.* setstate fWoDecke %

wobei
pWoDecke=physischer Schalter
fWoDecke=FHEM-Switch
und jeweils
attr eventMap AI:on A0:off

Das o.* im Pattern nutze ich, damit nur die Stati on und off weitergegen werden; ansonsten schießt mir event:released immer quer.

Das funktioniert anscheinend; bessere Vorschläge sind gerne willkommen ;-)

(Am Rande: Ich bin derzeit noch in der FHEM-Erprobungsphase; das ganze läuft nur im Testbetrieb. Ich scheitere seit ca. 3 Wochen an der Inbetriebnahme des MD15 und der Raffstoresteuerung mit dem FSB61. Bei letzterem bekomme ich enocean.pm nicht so umgebastelt, dass die Laufzeitsteuerung vernünftig funktioniert.)

 

So schlimm ist das manuelle Anlegen der Schalter nicht. Man bekommt Übung darin :-)

Joerg

Darum ist nach meiner Meinung autocreate auch für physische Taster notwendig und ich will keine Übung im manuellen Anlegen haben ;-)
Christian

[Rudolf Koenig]

> Ich scheitere seit ca. 3 Wochen an der Inbetriebnahme des MD15 ...

Daran bin ich auch gescheitert...
Allerdings war meine Motivation auch sehr begrenzt.

[immi]

Doch physischer Schalter hat aus meiner Sicht immer eine Bedeutung. Ich möchte unbedingt die Sichtbarkeit im Frontend. Wenn das nicht gegeben ist, ist WAF weg und ich selbst fände es auch seltsam. Und darum brauche ich auch die physischen Taster im FHEM. Die Abbildung im Frontend habe ich mit folgendem notify erreicht:

define noWoDecke notify pWoDecke:o.* setstate fWoDecke %

wobei
pWoDecke=physischer Schalter
fWoDecke=FHEM-Switch
und jeweils
attr eventMap AI:on A0:off

Hallo Christian
Deine losung funktioniert immer wenn Du eine 1:1:1-verhältnis zwischen  physischer Schalter und FHEM-Switch und aktuatoren.
FHEM-Switch und aktuatoren machen in der regel nuer sinn im  1:1-verhältnis.

Ich habe  aber mehrere n:N:N
z.b Schlafzimmer

• ein einzehl_physischer_Schalter (AI:Light_on A0:Light_off) und
• ein doppel_physischer_Schalter  (BI:Light_on B0:Light_off) und
• ein 4xphysischer_Schalter (BI:Light_on B0:Light_off)

fuer die gleiche lampe.
Der Doppel_physischer_Schalter steuert mir auch die Rollo (AI:Rollo_open A0:Rollo_close) und der 4xphysischer_Schalter ist ein art von fehrnbedinung.
d.h ich muesste flessig fleissig mehrere define-notify mit viele if&else :(

immi

[krikan]

Am Donnerstag, 13. September 2012 22:50:54 UTC+2 schrieb immi:

• ein einzehl_physischer_Schalter (AI:Light_on A0:Light_off) und
• ein doppel_physischer_Schalter  (BI:Light_on B0:Light_off) und
• ein 4xphysischer_Schalter (BI:Light_on B0:Light_off)

fuer die gleiche lampe.
Der Doppel_physischer_Schalter steuert mir auch die Rollo (AI:Rollo_open A0:Rollo_close) und der 4xphysischer_Schalter ist ein art von fehrnbedinung.
d.h ich muesste flessig fleissig mehrere define-notify mit viele if&else :(

immi

 

Hallo Immi!

 

Dann kannst Du in Deinem Fhem-Frontend nicht erkennen, ob die Lampe im Schlafzimmer an ist? Kann doch nicht sein. Das wäre das KO-Kriterium für Fhem.

 

Sorry, bin verwirrt; vielleicht sind meine Ausführung unverständlich. Ich versuch es noch mal:

 

Im Frontend möchte ich den Zustand jedes Verbrauchers erkennen könnnen. Daher muss FHEM immer den Schaltzustand des zugehörigen Aktors wissen. Sofern der Aktor nur über FHEM geschaltet wird, ist der Schaltzustand FHEM immer bekannt (indirekte Steuerung). Wenn der Aktor direkt über einen Taster geschaltet wird (direkte Steuerung), muss FHEM bei undirektionalen Enocean-Aktoren im Funkverkehr die physichen Taster belauschen, um eine korrekte Abbildung im Frontend zu erreichen. Ich brauche daher alle physischen Taster in FHEM (autocreate!).

 

Mein Weg:
Jedem Aktor wird genau ein FHEM-Switch angelernt. (AI = on; A0 = off. Die anderen Schaltzustände des FHEM-Switches (Bx-Dx) nutze ich nicht)
Im Frontend soll dieser FHEM-Switch immer den korrekten Schaltzustand anzeigen.
Dies passiert bei indirekter Steuerung eben automatisch.
Bei der direkten Steuerung muss ich jeden direkt im Aktor angelernten, physischen Taster überwachen. Per genannter notify-Regel wird bei Druck auf den physischen Taster der state des FHEM-Switches fürs Frontend anpassen.
Tatsächlich habe ich bisher immer eine 1:1:1 Verbindung getestet. Aber das sollte doch auch bei einer n:N:N möglich sein. Dem FHEM-Switch für den Deckenlampen-Aktor muss doch nur per notify der letzte physische Tasterdruck als state zugeordnet werden, damit im Frontend der Schaltzustand der Lampe erkennbar ist. Jeder Deiner physischen Schalter/Schaltzustände für die Deckenlampe bekäme dazu die passende notify-Regel für den FHEM-switch. Dafür benötige ich doch keine if&else!? (Ich will nicht den state der physischen Taster in FHEM anpassen!). Den FHEM-Switch für Dein Rollo müsste man bei physischen Tastendruck per notify ebenfalls im state anpassen.
Bei den unidirektionalen Dimmern kann ich die Frontenddarstellung bei direkter Steuerung so leider nicht vernünftig lösen.

 

Gruß, Christian 

[Rudolf Koenig]

> Bei den unidirektionalen Dimmern kann ich die Frontenddarstellung bei

> direkter Steuerung so leider nicht vern�nftig l�sen.

Wieso nicht? Will sagen, ich verstehe das Problem noch nicht.

[immi]

Hallo Rudolf
kein Problem. Nuer mein deutsch wahrscheinlich :(

Hallo Christian

 Dann kannst Du in Deinem Fhem-Frontend nicht erkennen, ob die Lampe im Schlafzimmer an ist? Kann doch nicht sein....

Doch. Ich  kann in Meinem Fhem-Frontend erkennen, ob die Lampe im Schlafzimmer an ist.

 Bei der direkten Steuerung muss ich jeden direkt im Aktor angelernten, physischen Taster überwachen. Per genannter notify-Regel wird bei Druck auf den physischen Taster der state des FHEM-Switches fürs Frontend anpassen.

Genau das gleiche mache ich. Dafuer benutze ich aber bei n:N:N eine/mehrere Bedingte Anweisung in "define-notify"
d.h fleissig unelegante Arbeit. :)

immi

[krikan]

Am Freitag, 14. September 2012 08:47:24 UTC+2 schrieb Rudolf Koenig:

> Bei den unidirektionalen Dimmern kann ich die Frontenddarstellung bei

> direkter Steuerung so leider nicht vern�nftig l�sen.

Wieso nicht? Will sagen, ich verstehe das Problem noch nicht.

 

Hallo Rudi,

 

Die alten unidirektionalen Dimmer reagieren folgendermaßen auf die direkt eingelernten Taster:

kurzer phy. Tastendruck = Dimmer an/aus

langer phy. Tastendruck = Dimmer auf/abdimmen

Was ein langer und kurzer Tastendruck ist und auf wieviel % die Dimmer dann stehen oder gar an oder aus sind, kann ich leider aus den phy. Tastendruck nicht vernünftig ableiten. Ein Rücksignal liefern die unidirektionalen Dimmer leider auch nicht. Ein notify an den FHEM-Switch kann ich daher nicht sinnvoll weitergeben. Nach ein paar phy. Tastenbetätigungen stimmt der state des FHEM-Switches nicht mehr mit der Realität überein. Wen ich dann den state des FHEM-Switches für Komfortfunktionen (bspw. Überwachung) nutzen will, habe ich nur noch Zufallsergebnisse. Einzig mir bekannter Ausweg: Nur indirekte Steuerung der Dimmer über FHEM (Taster->FHEM->Dimmer); aber dann bei FHEM-Ausfall, keine Dimmer-Steuerung möglich.

 

Oder, habe ich mein grundsätzliches Problem noch nicht vernünftig erklärt?

 

Gruß, Christian

 

 

[Rudolf Koenig]

> Oder, habe ich mein grunds�tzliches Problem noch nicht vern�nftig erkl�rt?

Doch, ich meine das jetzt zu verstehen. Loesung habe ich aber keine :(

[krikan]

Am Freitag, 14. September 2012 11:19:20 UTC+2 schrieb Rudolf Koenig:

> Oder, habe ich mein grunds�tzliches Problem noch nicht vern�nftig erkl�rt?

Doch, ich meine das jetzt zu verstehen. Loesung habe ich aber keine

 

Das ist softwareseitig wohl nicht zu lösen. Einzig vernünftige, aber nicht bezahlbare, Lösung ist wohl Austausch gegen Bidi-Dimmaktoren. Bidi-Aktoren würden die Notify-Menge sowieso verschlanken....

[Sebastian]

Hat denn jemand alternativ Erfahrungen mit dem von Eltako angebotenen Produkt FAM-USB ?
Lassen sich damit die Zustände einfacher (physisch/software) ablesen ? Und wie ist insgesamt das Handling ?

[krikan]

Hallo Sebastian

Hat denn jemand alternativ Erfahrungen mit dem von Eltako angebotenen Produkt FAM-USB ?

 

Wozu alternativ? Der FAM-USB ist doch nur das Hardware-Gateway. Welchen Chip (TCMxxx) hat das Ding? Wird es von FHEM erkannt? Wenn ja, ändert das meines Wissens nach derzeit(?) nichts am Handling. Zumindest ist das bei meinen getesteten Gateways so (USB300, Bootup und BOR).

 

Lassen sich damit die Zustände einfacher (physisch/software) ablesen ? Und wie ist insgesamt das Handling ?

 

Im Prinzip ist das Problem doch überall gleich -> man kann bei ENOCEAN keine phy. Taster-Adressen per Software emulieren; wenn man einen Aktor gleichzeitig mit eingelernten Software-Switch und phy. Taster schalten will, muss man den Zustand des Aktors ermitteln. Bei den neuen Bidi-Aktoren relativ einfach. Bei meinen alten unidirektionalen nur schwierig (Sorry, wenn ich Dich mit meinen Ausführung oben im Thread verwirrt habe).

 

Vielleicht sagst Du mal, was Du für Komponenten hast. Wenn Du den FAM schon hast, kannst Du auch FVS nutzen. Nach meinem Kenntnisstand aus 2009, erkennst Du auch dort das grundsätzliche Problem.

 

Gruß, Christian

[Sebastian]

Sorry, ich meinte nicht den FAM-USB sondern die von Dir auch genannte Software FVS - hast du damit bereits Erfahrungen gemacht ?
Mit dieser müsste man nur leider ständig einen Computer im Netzwerk haben, während FHEM auf der Fritzbox läuft.
Ich habe einen BSC Smart Connect EnOcean TCM310 USB Stick.
Es wird sich noch um die alten unidirektionalen Aktoren handeln, da ich das System seit 2 Jahren habe.
Und da ich in dem Thema absolut kein Experte bin, möchte ich es mir so einfach wie möglich machen.

Grüße, Sebastian