EnOcean Telegramm

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

Vorheriges Thema - Nächstes Thema

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!