EnOcean ansteuern, aber wie?

[Guest]

Originally posted by: <email address deleted>

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.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

> 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 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.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

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
<http://www.fritz.box:8083/fhem?cmd.wz_RolloHoch=deleteattr%20wz_RolloHoch%20eventMap&detail=wz_RolloHoch>  
fm_fav
999
 deleteattr
<http://www.fritz.box:8083/fhem?cmd.wz_RolloHoch=deleteattr%20wz_RolloHoch%20fm_fav&detail=wz_RolloHoch>  
room
Wohnzimmer
 deleteattr
<http://www.fritz.box:8083/fhem?cmd.wz_RolloHoch=deleteattr%20wz_RolloHoch%20room&detail=wz_RolloHoch>  
subType
switch
 deleteattr
<http://www.fritz.box:8083/fhem?cmd.wz_RolloHoch=deleteattr%20wz_RolloHoch%20subType&detail=wz_RolloHoch>

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.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

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

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

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

Am Montag, 10. September 2012 22:05:54 UTC+2 schrieb 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
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

> 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.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

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

On Thursday, September 13, 2012 7:50:26 AM UTC+2, Sebastian wrote:
>
> Also bringt mir die autocreate Funktion im Prinzip leider nichts ?! Werde
> mich am We mal damit beschäftigen und berichten.
>
> Am Montag, 10. September 2012 22:05:54 UTC+2 schrieb 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
>>
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

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
 

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

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

On Thursday, September 13, 2012 10:26:05 AM UTC+2, krikan wrote:
>
>
> 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
>  
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

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

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

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

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

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

> 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


--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

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

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

> 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.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

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

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com