Eltako FT55 generiert im verschlüsselten Modus kein channelA/channelB-Event

[crispinus]

Hallo,

vor ein paar Tagen sind meine Eltako-Baureihe 14-Komponenten für den RS485-Bus angekommen (ich hatte zunächst FAM14, FTD14, FSG14-USB sowie einige FUD14/400Ws bestellt). Zur Ansteuerung der FUDs sowie einiger Relais hinter einem Arduino habe ich außerdem ein paar Eltako FT55-Taster dazubestellt. Diese wollte ich natürlich gerne aus Sicherheitsgründen im verschlüsselten Modus betreiben. Das Einlernen in FAM14 war nach Betriebsanleitung gar kein Problem, und auch FHEM hat im autocreate-/teach-Modus nach Tastendruck auf den FT55 diesen erkannt und mit der korrekten ID als switch angelegt. Es kommen beim Drücken von Tasten bzw. Loslassen auch pressed / released events und die Readings für buttons und state ändern sich entsprechend. Der einzige Schönheitsfehler ist nun, dass es keine Readings für channelA und channelB gibt, sich somit also die Tastendrücke überhaupt nicht unterscheiden lassen, auch die AI/A0/BI/B0-Events werden nicht generiert.
Ich habe dann versuchsweise die Verschlüsselung der Taster ausgeschaltet, und siehe da, es funktioniert völlig problemlos mit den gleichen defines, die schon zuvor von FHEM angelegt wurden, als der Taster noch verschlüsselt gefunkt hat.
Die Telegramme sehen im Debug-Modus auch in der verschlüsselten Variante korrekt aus (die DATA-Payload ändert sich je nach Tastendruck), und ohnehin ist die Verschlüsselung, wenn ich alles richtig verstanden habe, für FHEM sowieso transparent, da das alles vom FAM14 gemanaged wird.
Ich habe bereits in das EnOcean-Modul hineingesehen, konnte selbst aber keinen Grund für dieses Fehlverhalten finden. Wenn sich jemand, der mehr Erfahrung mit dem Modul hat, dieses Problems annehmen würde, wäre ich natürlich gerne bereit, ggf. für das weitere Debugging benötigte Informationen bereitzustellen.

VG
crispinus

[crispinus]

Kleiner Nachtrag noch: Im Log fiel mir auf, dass ein Druck auf den Taster, der im unverschlüsselten Modus BI-Events generierte,  im verschlüsselten Modus den Eintrag "Keycard inserted" produzierte. Vielleicht sind die Telegramme doch unterschiedlich zwischen unverschlüsseltem und verschlüsseltem Modus. Ich habe noch im Kopf, dass der mit A0 korrespondierende Taster im verschlüsselten Modus das DATA-byte auf 00 stehen hatte, der mit AI korrespondierende Taster auf 20. Ist das so wie auch im unverschlüsselten Modus? Wo finde ich im EnOcean-Modul eigentlich diese Werte wieder?

[klaus.schauer]

Da läuft wohl was beim teach-in für die verschlüsselte Variante schief. Denn so sieht das korrekte Ergebnis aus:

Code Auswählen Erweitern


Internals:
   DEF        FEFF####
   IODev      TCM310_0
   LASTInputDev TCM310_0
   MSGCNT     15
   NAME       EnO_STE_FEFF####
   NOTIFYDEV  global
   NR         42
   STATE      AI B0
   TCM310_0_DestinationID FFFFFFFF
   TCM310_0_MSGCNT 15
   TCM310_0_PacketType 1
   TCM310_0_RSSI -82
   TCM310_0_ReceivingQuality good
   TCM310_0_RepeatingCounter 0
   TCM310_0_SubTelNum 3
   TCM310_0_TIME 2014-09-13 08:15:15
   TYPE       EnOcean
   Readings:
     2014-09-13 08:15:14   channelA        AI
     2014-09-13 08:15:14   channelB        B0
     2014-09-13 08:15:15   energyBow       released
     2014-09-13 08:15:14   state           AI B0
Attributes:
   IODev      TCM310_0
   dataEnc    VAES
   eep        D2-03-00
   key        <key>
   macAlgo    3
   manufID    7FF
   rlc        F704
   rlcAlgo    2,++
   rlcTX      false
   room       EnOcean
   subType    switch.00

Das secure teach-in ist in der commandref beschrieben.

[krikan]

Verstehe ich die commandref richtig: Muss nach 128 Tastendrücken ein neues teach-in durchgeführt werden?

[klaus.schauer]

Nein. Es gibt einen Sequenzzähler der im Taster und in Fhem synchron laufen muss. Diese werden bei jedem Telegramm hochgezählt. Sobald der Empfänger (Fhem) mehr als 128 Telegramme des Senders nacheinander nicht empfangen hat, muss neu angelernt werden.

[crispinus]

Hmm. Muss man denn überhaupt ein Secure-Teach-in machen, wenn das nicht über ein USB-Funkmodul an FHEM geht sondern übers FGW14/FAM14? Denn ich lerne ja auch für andere Busmodule wie z.B. FUD14 die Verschlüsselung zunächst ins FAM14 ein und dann die normalen Tasterfunktionen in die anderen Busmodule. Das FAM14 scheint also das Telegramm selbst zu entschlüsseln und dann in entschlüsselter Form auf den Bus zu geben.
FHEM hat mir ja auch ein auf den ersten Blick korrektes Define für den FT55 angelegt, obwohl ich die in der Commandref beschriebenen Vorgänge zum Einlernen verschlüsselter Taster nicht mit FHEM durchgeführt sondern den Taster eben im FAM14 eingelernt hatte. Das Telegramm kann also nicht verschlüsselt bei FHEM angekommen sein, dann wäre ja gar kein Define per autocreate möglich gewesen. Ich werde das ganze nochmal probieren und mir dann mal die übermittelten Telegramme anschauen. Wie müssten denn die Inhalte des DATA-Bytes für die einzelnen Tasten lauten, damit die korrekten A0/I und B0/I-Events generiert werden?

[crispinus]

So, ich habe jetzt noch mal die jeweiligen Telegramme angeschaut. Es ist tatsächlich so, dass durch das FAM14 die Verschlüsselung des Tasters für FHEM transparent wird bzw. keinen Unterschied macht, ob der Taster verschlüsselt sendet oder nicht.
Die Telegramme unterscheiden sich aber tatsächlich etwas: die DATA-Bytes sind zwar gleich (also 10 resp. 30 für die A-Seite und 50 resp. 70 für die B-Seite), dafür ist aber das STATUS-Byte stets 00. Daran hakt dann offensichtlich auch die Generierung der A0/I B0/I-Events, denn für diese ist (so habe ich zumindest aus 10_EnOcean.pm herausgelesen) auch der Inhalt des STATUS-Bytes relevant. Gibt es eventuell eine Möglichkeit, auch ohne das STATUS-Byte auszukommen und so auch das korrekte Auswerten auf Verschlüsselung eingestellter Taster zu ermöglichen?

[klaus.schauer]

Bitte mit subType switch.00 versuchen. switch.00 wird im verschlüsselten Modus verwendet. Vielleicht passt das auch in dieser Konstellation.

Alternativ habe ich ein Empfangsprofil für diesen Spezialfall erstellt: subType switch.7F manufID 00D. Bitte mit anhängender Testdatei probieren.

[crispinus]

Bitte mit subType switch.00 versuchen. switch.00 wird im verschlüsselten Modus verwendet. Vielleicht passt das auch in dieser Konstellation.

Das funktioniert leider nicht...

Alternativ habe ich ein Empfangsprofil für diesen Spezialfall erstellt: subType switch.7F manufID 00D. Bitte mit anhängender Testdatei probieren.

... das dagegen schon. Vielen Dank!

VG
crispinus