EnOcean Telegramm

Begonnen von TEnOcean, 15 April 2013, 23:16:55

Vorheriges Thema - Nächstes Thema

TEnOcean

Hallo,

ich versuche gerade einen Eltako FRS12 anzusteuern. Ist bei mir auf Universalschalter eingestellt, da wir auch physikalische Tastsschalter haben. Damit kann man nicht mehr einfach über Funk an- oder ausschalten, sondern nur toggle.

Ich versuche gerade einen Fenster-Kontakt FTK zu simulieren, um damit vielleicht aus- und anschalten zu können. Leider funktioniert es über FHEM im Standard-Setup nicht vollumfänglich, da man keine ORG=6 Telegramme senden kann (nur ORG-05 wenn ich es richtig sehe). Und Eltako FTK sende EEP 06-00-01.

Um hier weiterzukommen fehlen mir einige grundsätzliche Informationen. Vielleicht kann mir hier jemand weiterhelfen. Der Aufbau des Datentelegramms ist klar.
Aber was muss vor dem Datentelegramm stehen?

Thorsten

klaus.schauer

Auf die Schnelle habe ich mal eine Ergänzung erstellt:

} elsif ($st eq "contact") {
      # 1BS Telegram
      # Single Input Contact (EEP D5-00-01)
      my $setCmd;      
      if($cmd eq "teach") {
        $setCmd = 0;
      } elsif ($cmd eq "closed") {
        $setCmd = 9;
      } elsif ($cmd eq "open") {
        $setCmd = 8;
      } else {
        return "Unknown argument " . $cmd . ", choose one of open closed teach";
      }    
      IOWrite ($hash, "00070001", sprintf ("D5%02X%s00", $setCmd, $subDef));
      Log $ll2, "EnOcean: set $name $cmd";
   

Befehle lassen sich absenden und werden protokolliert. Ob es allerdings wirklich funktioniert, habe ich in der Kürze der Zeit nicht testen können.

Wer möchte, kann sich den Code in die Routine Sub EnOcean_Set($@) der 10_EnOcean.pm einbauen, am besten vor

} else {
    # Rocker Switch, simulate a PTM200 switch module
      # separate first and second action

 

TEnOcean


Super - danke. Werde ich ausprobieren und dann berichten.

Nun habe ich gleich noch eine Frage: Gibt es eine Möglichkeit mit FHEM die Repeater-Funktionalität des TCM 310 einzuschalten? Habe ich in der Referenz nicht gefunden.

klaus.schauer

Zitat von: TEnOcean schrieb am Di, 16 April 2013 22:05Super - danke. Werde ich ausprobieren und dann berichten.

Nun habe ich gleich noch eine Frage: Gibt es eine Möglichkeit mit FHEM die Repeater-Funktionalität des TCM 310 einzuschalten? Habe ich in der Referenz nicht gefunden.

Eine entsprechende Logik ist mir im Hardware-Programmmodul 10_TCM.pm bisher nicht aufgefallen. Vielleicht muss man "nur" den TCM 310 Chip entsprechend parameterisieren.

TEnOcean

Den obigen Code zum Schalten eins "contact" war bei mir erfolgreich. Ich musste nur noch ein Zeile im Code einfügen:

...
# Single Input Contact (EEP D5-00-01)
my $subDef = AttrVal($name, "subDef", "$hash->{DEF}");
my $setCmd;
if($cmd eq "teach") {
....

Damit konnte ich dann meinen FSR12 definiert anschalten, aber nicht ausschalten. Ich habe das jetzt so gelöst, dass ich zunächst definiert anschalte und dann toggle. Ist nicht ganz schön, weil das Licht beim Ausschalten kurz angeht, wenn es schon aus war. Aber was anderes ist mit jetzt nicht eingefallen. Hier die Zusammenfassung der Lösung:

Ausgangssituation:
  • Aktor: FSR12-12V
  • Physikalische Tastschalter, d.h. oberer Funktionsdrehschalter ist auf ES-UT eingestellt
  • Mittels FHEM soll es möglich sein definiert ein- und auszuschalten

Lösung:
  • FSR12-Einstellungen: oberer Drehschalter auf ES-UT, mittlerer Drehschalter auf AUTO 1, unterer Drehschalter auf AUTO
  • Eingelernt sind die Schalter FSR12_Feld2_27_1 und FTK12_Feld2_27_1
  • Auszug aus dem fhem.cfg (ohne log-Files):

#
# Definition Sender
#
define FSR12_Feld2_27_1 EnOcean FFC75D01
attr FSR12_Feld2_27_1 eventMap B0:on/off
attr FSR12_Feld2_27_1 manufID 00D
attr FSR12_Feld2_27_1 room Thorsten
attr FSR12_Feld2_27_1 subType switch
attr FSR12_Feld2_27_1 webCmd on/off
#
define FTK_Feld2_27_1 EnOcean FFC75D04
attr FTK_Feld2_27_1 room Thorsten
attr FTK_Feld2_27_1 subType contact
attr FTK_Feld2_27_1 webCmd open:closed:teach
#
# Schalter
#
define Thorsten1 dummy
attr Thorsten1 eventMap B0:on/off A0:on AI:off
attr Thorsten1 room Thorsten
attr Thorsten1 webCmd on/off:on:off
#
define Thorsten1_on notify Thorsten1 {if (Value("Thorsten1") eq "on") {fhem("set FTK_Feld2_27_1 closed")}}
define Thorsten1_off notify Thorsten1 {if (Value("Thorsten1") eq "off") {fhem("set FTK_Feld2_27_1 closed;; set FSR12_Feld2_27_1 on/off")}}
define Thorsten1_toggle notify Thorsten1 {if (Value("Thorsten1") eq "on/off") {fhem("set FSR12_Feld2_27_1 on/off")}}

klaus.schauer

Zitat von: TEnOcean schrieb am Sa, 20 April 2013 12:31Den obigen Code zum Schalten eins "contact" war bei mir erfolgreich. Ich musste nur noch ein Zeile im Code einfügen:

...
# Single Input Contact (EEP D5-00-01)
my $subDef = AttrVal($name, "subDef", "$hash->{DEF}");
my $setCmd;
if($cmd eq "teach") {
....

Damit konnte ich dann meinen FSR12 definiert anschalten, aber nicht ausschalten. Ich habe das jetzt so gelöst, dass ich zunächst definiert anschalte und dann toggle. Ist nicht ganz schön, weil das Licht beim Ausschalten kurz angeht, wenn es schon aus war. Aber was anderes ist mit jetzt nicht eingefallen. Hier die Zusammenfassung der Lösung:

Ausgangssituation:
  • Aktor: FSR12-12V
  • Physikalische Tastschalter, d.h. oberer Funktionsdrehschalter ist auf ES-UT eingestellt
  • Mittels FHEM soll es möglich sein definiert ein- und auszuschalten

Lösung:
  • FSR12-Einstellungen: oberer Drehschalter auf ES-UT, mittlerer Drehschalter auf AUTO 1, unterer Drehschalter auf AUTO
  • Eingelernt sind die Schalter FSR12_Feld2_27_1 und FTK12_Feld2_27_1
  • Auszug aus dem fhem.cfg (ohne log-Files):

#
# Definition Sender
#
define FSR12_Feld2_27_1 EnOcean FFC75D01
attr FSR12_Feld2_27_1 eventMap B0:on/off
attr FSR12_Feld2_27_1 manufID 00D
attr FSR12_Feld2_27_1 room Thorsten
attr FSR12_Feld2_27_1 subType switch
attr FSR12_Feld2_27_1 webCmd on/off
#
define FTK_Feld2_27_1 EnOcean FFC75D04
attr FTK_Feld2_27_1 room Thorsten
attr FTK_Feld2_27_1 subType contact
attr FTK_Feld2_27_1 webCmd open:closed:teach
#
# Schalter
#
define Thorsten1 dummy
attr Thorsten1 eventMap B0:on/off A0:on AI:off
attr Thorsten1 room Thorsten
attr Thorsten1 webCmd on/off:on:off
#
define Thorsten1_on notify Thorsten1 {if (Value("Thorsten1") eq "on") {fhem("set FTK_Feld2_27_1 closed")}}
define Thorsten1_off notify Thorsten1 {if (Value("Thorsten1") eq "off") {fhem("set FTK_Feld2_27_1 closed;; set FSR12_Feld2_27_1 on/off")}}
define Thorsten1_toggle notify Thorsten1 {if (Value("Thorsten1") eq "on/off") {fhem("set FSR12_Feld2_27_1 on/off")}}

Ich habe inzwischen mit einem FSR14 getestet. An- und Ausschalten ist uneingeschränkt möglich. Ich habe allerdings nur einen "contact" angelernt. Je nach Einstellung reagiert der FSR14 bei mehreren gleichzeitig angelernten Kontakten unterschiedlich, z. B. "aus" nur wenn alle Kontakte geöffnet.

TEnOcean


Mit dem FRS12 funktioniert bei mir nur das Einschalten, auch wenn ich nur einen "contact" eingelernt habe.

Was mir aber noch gelungen ist, ist es die Repeaterfunktionalität des TCM einzuschalten, indem ich in 00_TCM.pm eine Zeile eingefügt habe.

my %sets310 = (
  "pairForSec"   => { cmd=>"AB18", arg=>"\\d+" },
  "idbase"       => { cmd=>"07", arg=>"FF[8-9A-F][0-9A-F]{5}" },
  "repeater"       => { cmd=>"09", arg=>"0[0-1]0[0-2]" },
# The following 3 does not seem to work / dont get an answer
#  "sleep"        => { cmd=>"01", arg=>"00[0-9A-F]{6}" },
#  "reset"        => { cmd=>"02" },
#  "bist"         => { cmd=>"06", BIST_Result=>"1,1", },
);


"set EUL repeater 0000" schaltet den Repeater aus
"set EUL repeater 0101" schaltet den Repeater ein (1-Level)
"set EUL repeater 0102" schaltet den Repeater ein (2-Level)

Was ich aber noch suche ist ein Möglichkeit, einen FAH60 zu simulieren. Ich kann ihn zwar definieren, aber dann nur die Bits A0,AI,... setzen, nicht einen beliebigen Helligkeitswert oder ein teach-Telegramm.

klaus.schauer

Zitat von: TEnOcean schrieb am So, 21 April 2013 20:03Mit dem FRS12 funktioniert bei mir nur das Einschalten, auch wenn ich nur einen "contact" eingelernt habe.

Was mir aber noch gelungen ist, ist es die Repeaterfunktionalität des TCM einzuschalten, indem ich in 00_TCM.pm eine Zeile eingefügt habe.

my %sets310 = (
  "pairForSec"   => { cmd=>"AB18", arg=>"\\d+" },
  "idbase"       => { cmd=>"07", arg=>"FF[8-9A-F][0-9A-F]{5}" },
  "repeater"       => { cmd=>"09", arg=>"0[0-1]0[0-2]" },
# The following 3 does not seem to work / dont get an answer
#  "sleep"        => { cmd=>"01", arg=>"00[0-9A-F]{6}" },
#  "reset"        => { cmd=>"02" },
#  "bist"         => { cmd=>"06", BIST_Result=>"1,1", },
);


"set EUL repeater 0000" schaltet den Repeater aus
"set EUL repeater 0101" schaltet den Repeater ein (1-Level)
"set EUL repeater 0102" schaltet den Repeater ein (2-Level)

Wird der Befehl fehlerfrei angenommen und kommt eine entsprechende Quittungsmeldung zurück? Ich hatte mich letztlich als erstes mit der Abfrage des Repeaterstatus beschäftigt. Leider bin ich nicht weitergekommen, da als Rückmeldung ein Fehler gemeldet wurde: Timeout reading answer ... Ich wollte deshalb erst einmal klären, ob es bekannte Probleme gibt, die Firmware die Funktionen nur teilweise unterstützt oder vielleicht zu aktualisieren wäre.

klaus.schauer

Zitat von: TEnOcean schrieb am So, 21 April 2013 20:03Was ich aber noch suche ist ein Möglichkeit, einen FAH60 zu simulieren. Ich kann ihn zwar definieren, aber dann nur die Bits A0,AI,... setzen, nicht einen beliebigen Helligkeitswert oder ein teach-Telegramm.
D. h. Fhem soll das Profil Light Sensor (EEP A5-06-01) simulieren und Helligkeitsdaten senden? Woher sollen die Daten für die Helligkeit kommen? Wie sollen die Daten gesendet werden, regelmäßig oder per set-Befehl? Ich kann den Sinn noch nicht erkennen, sieht man mal von Tests ab.

TEnOcean

Ich habe auch ein Timeout bekommen. Die Repeaterfunktionalität wird aber korrekt geschaltet, sowohl Level 1 als auch Level 2 funktioniert.

TEnOcean

Es geht mir immer noch um eine Lösung wie ich meinen FRS12 definiert schalten kann. Ggf. funktioniert es mit einem simulierten FAH. Am liebsten haette ich ja einen generischen Schalter, der ein 4BS Telegramm abschickt bei Vorgabe des Datenpakets.

klaus.schauer

Zitat von: TEnOcean schrieb am So, 21 April 2013 22:44Ich habe auch ein Timeout bekommen. Die Repeaterfunktionalität wird aber korrekt geschaltet, sowohl Level 1 als auch Level 2 funktioniert.
Bevor diese Funktion allgemein verteilt wird, sollte m. E. auch die Quittierung funktionieren. Vielleicht findet sich alsbald eine Lösung.

klaus.schauer

Zitat von: TEnOcean schrieb am So, 21 April 2013 22:55Es geht mir immer noch um eine Lösung wie ich meinen FRS12 definiert schalten kann. Ggf. funktioniert es mit einem simulierten FAH. Am liebsten haette ich ja einen generischen Schalter, der ein 4BS Telegramm abschickt bei Vorgabe des Datenpakets.
Ich verstehe das Problem eigentlich nicht. Lt. Anleitung http://www.eltako.com/fileadmin/downloads/de/_bedienung/FSR12-4x-12_VDC_30400134-1_dt.pdf kann man das Sensorprofil PC anlernen. Das entspricht dem recht neuen Fhem Profil Gateway (EEP A5-38-08), siehe commandref. Bei meinem FSR14 funktioniert das problemlos.

TEnOcean


... ich habe meist FSR12-12V verbaut. Dort kann ich Zentralein/-aus nur für beiden Kanäle gemeinsam einlernen. Beim FSR12-4x könnte ich es einmal probieren, ob es pro Kanal funktioniert - davon habe ich aber nur einen.

P.s.: Zur Repeaterfunktionalität ist es natürlich richtig, dass die Quittung verstanden werden sollte bevor es allgemein eingebaut werden sollte. Ich wollte auch nur sagen, dass es grundsätzlich mit der Hardware funktioniert. Da ich bisher noch nicht mit Perl programmiert habe, geht bei mir alles schleppend - deshalb keine saubere Lösung ....

klaus.schauer

Zitat von: TEnOcean schrieb am Mo, 22 April 2013 09:32... ich habe meist FSR12-12V verbaut. Dort kann ich Zentralein/-aus nur für beiden Kanäle gemeinsam einlernen. Beim FSR12-4x könnte ich es einmal probieren, ob es pro Kanal funktioniert - davon habe ich aber nur einen.
Für Zentral ein/aus würde ich mal das Fhem Profil switch mit dem attr <name> switchType central und den attr subDefI, subDef0 probieren. Damit kann man die Geräte mit einem Fhem-Device ein- und ausschalten.

Die Sensortypauswahl bei den FSR12 ist ja wirklich überschaubar. Ich würde nochmal mit den Profil contact experimentieren und die Funktion Relais (ER) wählen.

TEnOcean


Danke für den Tipp zu zentral ein/aus. Kann ich die EnOcean Sender-IDs für Schalter, subDef0 und subDefI alle gleich setzen?

Die Relaiseinstellung (ER) wird nicht funktionieren, da ich bei Relaisfunktion meine physikalischen Tastschalter dauerhaft gedrückt halten muss, damit das Licht brennt, meine ich mich zu erinnern. Ich hatte früher schon mal ausprobiert, was es mit der Relaisfunktion eigentlich auf sich hat.

Wenn es mit subDef und zentral ein/aus nicht funktioniert, hoffe ich weiterhin mit einem simulierten Helligkeits- oder Bewegungsmelder die definierte Ausschaltng zu erreichen. Einen Bewegungsmelder hatte ich eingelernt und der schaltet das Licht mit dem Telegramm motion=no aus.

klaus.schauer

Zitat von: TEnOcean schrieb am Mo, 22 April 2013 19:40Danke für den Tipp zu zentral ein/aus. Kann ich die EnOcean Sender-IDs für Schalter, subDef0 und subDefI alle gleich setzen?

Die Relaiseinstellung (ER) wird nicht funktionieren, da ich bei Relaisfunktion meine physikalischen Tastschalter dauerhaft gedrückt halten muss, damit das Licht brennt, meine ich mich zu erinnern. Ich hatte früher schon mal ausprobiert, was es mit der Relaisfunktion eigentlich auf sich hat.

Wenn es mit subDef und zentral ein/aus nicht funktioniert, hoffe ich weiterhin mit einem simulierten Helligkeits- oder Bewegungsmelder die definierte Ausschaltng zu erreichen. Einen Bewegungsmelder hatte ich eingelernt und der schaltet das Licht mit dem Telegramm motion=no aus.

DEF, subDef0 und subDefI alle gleich zu setzen ist sinnlos. Für zentral ein/aus werden unterschiedliche SenderIDs benötigt. Für unidirektionale Geräte wäre eine sinnvolle Einstellung z. B. DEF = subDef0 = SenderID, subDefI = SenderID + 1. Für bidirektionale Geräte DEF = GeräteID, subDef0 = SenderID, subDefI = SenderID + 1.

TEnOcean

Das mit dem Zetral Ein/Aus habe ich nicht ausprobiert. Mir war da nicht klar wie das funktionieren soll, da ich kein Zentral-Aus für einen Kanal getrennt einlernen kann.

Ich habe das Problem jetzt wie folgt gelöst:

Generischen 4BS-Schalter eingeführt in 10_EnOcean.pm:
Einen neuen SubType hinzugefügt
my %EnO_subType = (
....
 13          => "generic.4BS");

und folgenden Code eingefügt:
    } elsif ($st eq "generic.4BS") {
     # 4BS Telegram
        my $subDef = AttrVal($name, "subDef", "$hash->{DEF}");
   if ($cmd ne "4BS-Telegram" || $a[1] !~ /^[0-F]{8}$/) {
      return "Unknown argument " . $cmd . ", choose one of 4BS-Telegram";
   }
          my $data = sprintf("A5%s%s00", $a[1], $subDef);
          IOWrite($hash, "000A0001", $data);
     Log $ll2, "EnOcean: set $name $cmd $a[1]";
          shift(@a);

Parametrisierung in fhem.cfg:
#
# generic 4BS
#
define Switch_Feld2_27_1 EnOcean FFC75D07
attr Switch_Feld2_27_1 subType generic.4BS
attr Switch_Feld2_27_1 eventMap ,4BS-Telegram 0000000F:on,4BS-Telegram FFFF000F:off,4BS-Telegram 18080D87:teach,
attr Switch_Feld2_27_1 webCmd on:off
attr Switch_Feld2_27_1 devStateIcon 0000000F:FS20.on FFFF000F:FS20.off


Dann habe ich den Schalter in den FSR12 mit einer mittleren Helligkeitsschwelle eingelernt. Damit simuliere ich einen Sensor der höchste oder niedrigste Helligkeit sendet und damit ein- oder ausschaltet.


klaus.schauer

Zitat von: TEnOcean schrieb am So, 28 April 2013 18:37Das mit dem Zetral Ein/Aus habe ich nicht ausprobiert. Mir war da nicht klar wie das funktionieren soll, da ich kein Zentral-Aus für einen Kanal getrennt einlernen kann.

Ich habe das Problem jetzt wie folgt gelöst:

Generischen 4BS-Schalter eingeführt in 10_EnOcean.pm:
Einen neuen SubType hinzugefügt
my %EnO_subType = (
....
 13          => "generic.4BS");

und folgenden Code eingefügt:
    } elsif ($st eq "generic.4BS") {
     # 4BS Telegram
        my $subDef = AttrVal($name, "subDef", "$hash->{DEF}");
   if ($cmd ne "4BS-Telegram" || $a[1] !~ /^[0-F]{8}$/) {
      return "Unknown argument " . $cmd . ", choose one of 4BS-Telegram";
   }
          my $data = sprintf("A5%s%s00", $a[1], $subDef);
          IOWrite($hash, "000A0001", $data);
     Log $ll2, "EnOcean: set $name $cmd $a[1]";
          shift(@a);

Parametrisierung in fhem.cfg:
#
# generic 4BS
#
define Switch_Feld2_27_1 EnOcean FFC75D07
attr Switch_Feld2_27_1 subType generic.4BS
attr Switch_Feld2_27_1 eventMap ,4BS-Telegram 0000000F:on,4BS-Telegram FFFF000F:off,4BS-Telegram 18080D87:teach,
attr Switch_Feld2_27_1 webCmd on:off
attr Switch_Feld2_27_1 devStateIcon 0000000F:FS20.on FFFF000F:FS20.off


Dann habe ich den Schalter in den FSR12 mit einer mittleren Helligkeitsschwelle eingelernt. Damit simuliere ich einen Sensor der höchste oder niedrigste Helligkeit sendet und damit ein- oder ausschaltet.

Gute Idee, da kann sich jetzt jeder sein individuelles Telegramm basteln. Jetzt fehlt uns nur noch eine eingängige Anleitung in der commandref.

TEnOcean

... wenn die Funktionalität in den offiziellen Code übernommen werden kann, könnte ich in den nächsten Tagen eine Anleitung schreiben.

klaus.schauer

Zitat von: TEnOcean schrieb am Mo, 29 April 2013 19:54... wenn die Funktionalität in den offiziellen Code übernommen werden kann, könnte ich in den nächsten Tagen eine Anleitung schreiben.
Als ich die Programmzeilen in meine Testversion von 10_EnOcean übernommen habe, sind mir weitere Einsatzmöglichkeiten insbesondere für Testzwecke eingefallen. Wir könnten die Funktionalität dafür noch etwas ausbauen:
1. zusätzliche Radio Types 1BS, RPS, später VLD
2. Eingabefeld für Status mit Standardwerten vorbelegt (optional)
3. Eingabefeld für Optional Data (optional)
4. Berechnung der Variablen Data Length und Optional Length im Header in Abhängigkeit von Radio Type und Eingabewerten
Im Fhem Modul für HomeMatic gibt es eine ähnliche Funktionalität, über den subType raw. Wir sollten den neuen subType für EnOcean auch so nennen. Dann ist es einheitlich. Weiterhin würde ich die Befehlsnamen kürzen, das beschleunigt die Eingabe: 1BS, 4BS, RPS ... VLD.
Wäre das ok? Wenn ja, wie teilen wir die Arbeit auf?


TEnOcean

.. ich bin gerne bereit zu helfen. Im Programmieren bin ich vermutlich eher etwas langsam, da ich nicht so viel Zeit habe mir Perl wirklich anzueignen. Dokumentieren/Testen wäre wahrscheinlich bei mir effizienter.

Im Moment muss ich aber gerade noch ein anderes Probleme lösen. Wenn man einen generischen Schalter definiert gibt es ein Problem mit Repeatern. Das Repeatersignal vom ursprünglichen TCM310-Signal wird an den TCM 310 zurückgespielt und vom ursprünglichen generischen Sendeschalter protokolliert, aber nicht als raw signal sondern anders (mit AI, A0,...). Die beste Lösung für mich wäre es eigentlich, wenn der TCM310 Repeatersignale, die eigenen Ursprung haben, ignorieren würde. Kann man das einstellen? Alternativ müsste man wohl die generischen Telegramme auch in der Parse-Funktion einbauen, oder wo sonst?

klaus.schauer

Zitat von: TEnOcean schrieb am Di, 30 April 2013 21:57.. ich bin gerne bereit zu helfen. Im Programmieren bin ich vermutlich eher etwas langsam, da ich nicht so viel Zeit habe mir Perl wirklich anzueignen. Dokumentieren/Testen wäre wahrscheinlich bei mir effizienter.

Im Moment muss ich aber gerade noch ein anderes Probleme lösen. Wenn man einen generischen Schalter definiert gibt es ein Problem mit Repeatern. Das Repeatersignal vom ursprünglichen TCM310-Signal wird an den TCM 310 zurückgespielt und vom ursprünglichen generischen Sendeschalter protokolliert, aber nicht als raw signal sondern anders (mit AI, A0,...). Die beste Lösung für mich wäre es eigentlich, wenn der TCM310 Repeatersignale, die eigenen Ursprung haben, ignorieren würde. Kann man das einstellen? Alternativ müsste man wohl die generischen Telegramme auch in der Parse-Funktion einbauen, oder wo sonst?
Ich habe bisher das Verhalten von fhem in Umgebungen mit Repeatern nicht testen können. Das EnOcean Übertragungsprotokoll müsste das aber schon berücksichtigen. Im Statusfeld des Sendetelegramms werden durch Repeater gesendete Telegramme hochgezählt. Man kann sie also von den Originalpaketen unterscheiden. Deshalb würde ich mal prüfen, was im konkreten Fall im Statusfeld gesendet wird.
Auch kann ich keinen Unterschied zwischen Telegrammen erkennen, die durch die "normalen" Sendeprofile oder das raw-Profil gesendet werden. Ist es definitiv so, dass es sich um Repeater-Telegramme handelt und diese nur beim raw-Profil wieder in fhem ankommen?
Zusätzliche raw-Empfangsprofile insbesondere für 1BS und RPS scheinen mir nicht notwendig. Alle gültigen Befehle werden vollständig ausgewertet und normgerecht umgesetzt, z. B. in B0, BI, released. Die empfangenen Rohdaten kann man sich bei Bedarf im LOG ansehen.

TEnOcean

Im Statusfeld ist das Repeater Bit gesetzt und das Signal wird dann von FHEM (falsch) interpretiert. Da ich bei den meisten Schaltern eigentlich nicht möchte, dass die Signale vom TCM vom Repeater weitergegeben werden, habe ich für mich Folgendes gemacht:

Neues Attribut in 10_EnOcean.pm definiert:
  $hash->{AttrList}  = "IODev do_not_notify:1,0 ignore:0,1 dummy:0,1 " .
                       .....
                       "repeaterLevel:00,01,02,0F ".      
                       $readingFnAttributes;

 und im "Sendeteil" Folgendes angepasst:
    } elsif ($st eq "generic.4BS") {
     # 4BS Telegram
        my $subDef = AttrVal($name, "subDef", "$hash->{DEF}");
   if ($cmd ne "4BS-Telegram" || $a[1] !~ /^[0-F]{8}$/) {
      return "Unknown argument " . $cmd . ", choose one of 4BS-Telegram";
   };
   my $status;
   $status = AttrVal($name, "repeaterLevel", "$hash->{DEF}");
   if ($status !~ /^[0-F]{2}$/) {$status = "00" };

   
        my $data = sprintf("A5%s%s%s", $a[1], $subDef, $status);
        IOWrite($hash, "000A0001", $data);
   Log $ll2, "EnOcean: set $name $cmd $a[1]";
        shift(@a);


Damit kann ich für den Schalter definieren, ob und wie Signale von Repeatern behandelt werden. Ich habe das Attribut auf 0F gesetzt und damit wird es von Repeatern ignoriert.


klaus.schauer

Zitat von: TEnOcean schrieb am So, 05 Mai 2013 15:13Im Statusfeld ist das Repeater Bit gesetzt und das Signal wird dann von FHEM (falsch) interpretiert. Da ich bei den meisten Schaltern eigentlich nicht möchte, dass die Signale vom TCM vom Repeater weitergegeben werden, habe ich für mich Folgendes gemacht:

Neues Attribut in 10_EnOcean.pm definiert:
  $hash->{AttrList}  = "IODev do_not_notify:1,0 ignore:0,1 dummy:0,1 " .
                       .....
                       "repeaterLevel:00,01,02,0F ".      
                       $readingFnAttributes;

 und im "Sendeteil" Folgendes angepasst:
    } elsif ($st eq "generic.4BS") {
     # 4BS Telegram
        my $subDef = AttrVal($name, "subDef", "$hash->{DEF}");
   if ($cmd ne "4BS-Telegram" || $a[1] !~ /^[0-F]{8}$/) {
      return "Unknown argument " . $cmd . ", choose one of 4BS-Telegram";
   };
   my $status;
   $status = AttrVal($name, "repeaterLevel", "$hash->{DEF}");
   if ($status !~ /^[0-F]{2}$/) {$status = "00" };

   
        my $data = sprintf("A5%s%s%s", $a[1], $subDef, $status);
        IOWrite($hash, "000A0001", $data);
   Log $ll2, "EnOcean: set $name $cmd $a[1]";
        shift(@a);


Damit kann ich für den Schalter definieren, ob und wie Signale von Repeatern behandelt werden. Ich habe das Attribut auf 0F gesetzt und damit wird es von Repeatern ignoriert.

Ich habe das eigentliche Problem wohl noch nicht verstanden! Was ist denn fehlerhaft? Welches Problem soll damit gelöst werden, die EnOcean-Repeaterfunktion durch "Zählerüberlauf" auszuschalten?
Bisher habe ich in den EnOcean-Beschreibungen keinen Hinweis gefunden, dass dies vorgesehen ist. Falls die Repeater lt. Designvorgabe entsprechend geplant sind, sollten doch keine Fehler auftreten.

Weiterhin müsste die Funktionalität repeaterLevel dann konsequent auf RORG RPS und 1BS ausgedehnt werden. Hier ist aber zu beachten, dass das Statusbyte bei RORG RPS auch für die Flags T21, NU genutzt wird und entsprechend behandelt werden muss.
Ist es beabsichtigt, dass die DestinationID (DEF) als alternativer Statuswert geschrieben wird, $status = AttrVal($name, "repeaterLevel", "$hash->{DEF}"); ?

TEnOcean

Mein Problem ist, dass das 4BS-Signal vom Repeater neu gesendet wird (mit Statuswert 01) und dann vom TCM empfangen wird mit folgenden Auswirkungen:
1) Meinen Schaltungen per notify werden noch einmal ausgeführt. Macht nichts kaputt, ist nur unschön, immer 2 mal zu schalten.
2) Das Signal vom Repeater wird anders interpretiert. Wenn ich ohne Repeater schalte, erscheint als Statuswert des Schalters einfach das Telegram. Damit lege ich fest welches Icon im Web-Interface angezeigt wird. Das Signal des Repeaters wird aber "zerlegt". Ich erhalte werte für A0,AI,... und der Statuswert ich auch anders. Das macht mir die Icon-Anzeige kaputt.
3) Ich habe überflüssige Funksignale, auf die ich lieber verzichten würde um das Loging und die Verarbeitung zu entlasten.

Die Spezifikation "0F" als Angabe, dass ein Signal nicht vom Repeater weitergegeben werden soll, habe ich aus den "EnOcean Radio Protocol"-Spezifikationen vom 10 Okt 2012.

klaus.schauer

Zitat von: TEnOcean schrieb am Mo, 06 Mai 2013 14:13Mein Problem ist, dass das 4BS-Signal vom Repeater neu gesendet wird (mit Statuswert 01) und dann vom TCM empfangen wird mit folgenden Auswirkungen:
1) Meinen Schaltungen per notify werden noch einmal ausgeführt. Macht nichts kaputt, ist nur unschön, immer 2 mal zu schalten.
2) Das Signal vom Repeater wird anders interpretiert. Wenn ich ohne Repeater schalte, erscheint als Statuswert des Schalters einfach das Telegram. Damit lege ich fest welches Icon im Web-Interface angezeigt wird. Das Signal des Repeaters wird aber "zerlegt". Ich erhalte werte für A0,AI,... und der Statuswert ich auch anders. Das macht mir die Icon-Anzeige kaputt.
3) Ich habe überflüssige Funksignale, auf die ich lieber verzichten würde um das Loging und die Verarbeitung zu entlasten.

Die Spezifikation "0F" als Angabe, dass ein Signal nicht vom Repeater weitergegeben werden soll, habe ich aus den "EnOcean Radio Protocol"-Spezifikationen vom 10 Okt 2012.
zu 1): Falls ein von Fhem gesendetes Telegramm, das vom Repeater zurückkommt, wieder die gleiche Aktion auslöst, wäre das zuerst einmal programmtechnisch in Ordnung. D. h. auch ein Repeater-Telegramm würde richtig ausgewertet... steht im Gegensatz zu 2). Da diese Funktion aber im Normalfall eher nicht sinnvoll ist, wäre mein Ansatz mit einer neuen Option alle empfangenen Telegramme mit SenderIDs von Fhem herauszufiltern und zu unterdrücken. Das sollte grundsätzlich gehen.
Zu 2): Wenn Fhem Originaltelegramme von Fhem oder z. B. eines bidirektionalen Aktors und Telegramme über einen Repeater unterschiedlich anzeigt, könnte das ein Fehler im Programm sein. Das sollten wir untersuchen. Tritt der Fehler nur beim neuen RAW-Profil oder auch bei allen anderen Profilen auf? Welche Datentelegramme (Fhem, bidirektionale Aktoren, Sensoren), die über Repeater gehen, werden richtig/falsch ausgewertet und angezeigt? Welchen Inhalt haben die unterschiedlichen Datentelegramme im LOG?
zu 3): Als Werte für ein neues Attribut würde m. E. eine Schaltfunktion wie repeatingAllow [yes|no] am einfachsten und am verständlichsten sein.

TEnOcean

Den Ansatz alle eingehenden Signale mit TCM-ID nicht auszuwerten finde ich gut. Hatte ich auch dran gedacht. Aber da ich die Stelle nicht gefunden habe, wo es zu machen wäre, und ich außerdem auch nicht möchte, dass der Repeater das Signal überhaupt weitersendet, bin ich den anderen Weg gegangen.

repeatingAllow [yes|no] ist sicherlich besser lesbar. Gut wäre es, wenn man noch die Option level2 hätte. Da mein TCM zentral steht müssten Signal wenn überhaupt nur einmal über einen Repeater gehen, aber nicht zweimal.

Mit dem Repeatersignal hatte ich nur im Raw-Format Probleme. Vermutlich muss man dort wo das Signal interpretiert wird den RAW-Fall mit aufnehmen. Mir ist aber nicht klar, wo das wäre. Folgendes sehe ich:

  • wenn ich ein teach-Telegramm sende, wird der Subtype auf lightSensor.01 gesetzt (meine ich - bin leider diese Tage nicht zu Hause und kann nicht noch einmal testen)
  • bei Empfang des repeater-Signals wird A0,AI usw. gesetzt
  • Datentelegramm vom TCM und Repeater sind gleich, Status ist 00 bzw. 01 (Header kann ich jetzt nicht prüfen)

TEnOcean

.. habe erst jetzt die neuen Funktionalitäten testen können: Raw und repeatingAllowed funktioniert bei mir. Danke für die Implementierung!