FHEM - Hausautomations-Systeme > EnOcean

Siegenia Fenstersensoren (D2-06-50) nach Batteriewechsel als 1BS auto teachin

(1/3) > >>

JooNey:
Hallo zusammen,

ich bin neu im Forum und auch recht neu, was FHEM angeht. Zu FHEM gekommen bin ich, da ich ein flexibles EnOcean<>KNX Gateway gesucht habe. Wir haben uns Mitte letzten Jahres ein Haus gekauft, und ich habe angefangen die Elektrik komplett neu zu machen, und dabei gleich Haussteuerung über KNX zu integrieren. Da es sich um eine Bestandsimmobilie aus 1995 handelt, lassen sich gewisse Dinge umsetzen, andere jedoch nicht.

Einer meiner Wünsche war die Integration von Fenster-Sensoren zur Öffnungsüberwachung. Leider ist eine kabelgebundene Lösung über Reed-Kontakte aus diversen Gründen nicht möglich. Aus diesem Grund bin ich auf das System senso secure von Siegenia gestoßen: mit einem Sensor lassen sich alle Öffnungszustände eines (Doppel-)Fensters überwachen. Das klingt erstmal vielversprechend. Da der Hersteller die Kommunikation erstmal nur über seine eigene App inkl. eigenem Gateway anbietet, musste ich die Integration ins KNX System irgendwie hinbekommen - dabei kam mir zu Gute, dass das System auf EnOcean Technologie basiert, und mit dem Protokoll D2-06-50 kommuniziert. Da es jedoch kein KNX Gateway auf dem Markt gibt, welches dieses Protokoll unterstütz, habe ich mich dazu entschlossen einen Raspberry Pi 4 samt EnOcean Modul aufzusetzen und als Gateway zu benutzen, da ich gelesen habe, dass FHEM sehr frei in der Konfiguration ist. Bis hierhin hat auch erstmal alles funktioniert: EnOcean, KNX, alles schick.

Heute kam dann auch endlich ein Test-Sensor vom Hersteller - da ich mit dessen hauseigenen System ja nix anfangen kann. Da ich nicht so ganz sicher war, wie das System funktioniert, habe ich im FHEM einfach mal den Sensor definiert, ManuID und EEP angegeben, und dann die Batterien eingelegt. Der Sensor hat sich im EventMonitor gemeldet, und war im "Lernmodus" um gesagt zu bekommen, wie die verschiedenen Griffstellungen sind. Nachdem ich das (nicht ganz richtig, da der Sensor einfach nur vor mir auf dem Tisch lag, aber zumindest halbwegs ok) ausgeführt hatte, sendete der Sensor entsprechend der Spezifikation D2-06-50 Telegramme (die aber anscheinend aufgrund des nicht ganz korrekten "Anlernens" ein bisschen unverständlich waren.

Also habe ich die Batterien wieder entfernt, in der leisen Hoffnung, dass der Sensor sich eventuell wieder zurücksetzen lässt. (Wäre zwar irgendwie auch doof, weil ich ihn dann jedes Mal neu anlernen müsste, wenn die Batterien mal leer sind, und das wäre ja wirklich abartig, aber für den Moment wäre es hilfreich, da ich den Sensor so schneller wieder einlernen kann.)

Wenn ich nun aber die Batterien wieder in den Sensor lege, piept der lang, und im EventMonitor steht, dass ein erfolgreiches teach-in auf 1BS gemacht wurde. (1BS teach-in accepted EEP D5-00-01 Manufacturer: no ID) Das stimmt ja aber gar nicht. Und egal, was ich tue: TCM auf LearningMode demand, Sensor Attribute (ManufID, EEP, teachMethod) setzen: jedesmall, wenn ich die Batterien rausnehme und wieder einlege, macht das Gerät diesen teach-in.

Da FHEM und der Sensor am Anfang richtig miteinander kommuniziert haben, hoffe ich, dass ich diesen Zustand - mit eurer Hilfe - auch wieder herstellen kann. Meine Vermutung ist, dass der Sensor, da er nun eingelernt ist, nach dem Batteriewechsel ein Telegramm sendet, welches FHEM als Teach-In für 1BS interpretiert, obwohl es evtl. ein auf D2-06-50 basierendes Telegramm a la: "Ich bin wieder da!" darstellt.

EDIT: Habe gerade in der Anleitung gelesen, wie man einen Werksreset macht. Habe selbigen durchgeführt, das Verhalten bleibt das selbe: der Sensor lässt sich nicht mehr so ansprechen, wie beim allerersten Kontakt. Echt seltsam.

Könntet ihr mir Hinweise/Tipps/Diagnose-Ideen geben, damit ich herausfinden kann, woran es liegt, dass der Sensor nun nicht mehr mit der FHEM sprechen mag, oder wie ich die FHEM dazu bekomme das siegenia Telegramm nicht einfach mal so als "teach-in" zu verstehen, und alle device Attribute einfach mal so zu ändern!

Vielen Dank schon jetzt und viele Grüße
Julian

klaus.schauer:
Das EEP D2-06-50 wird derzeit vom Fhem EnOcean-Modul nicht unterstützt. Lt. EEP-Beschreibung wird es automatisch per UTM Teach-In angelernt. Da hilft es nicht, die Attribute wie EEP selbst anzulegen. Das EEP D2-06-50 sollte in das EnOcean-Modul implementiert werden können. Bitte etwas Geduld, wenn es aber noch etwas dauert.

Flachzange:
Machmal wäre weniger Text mehr:

* Wie heißt der Sensor? Link zur Anleitung?
* Device listing zeigen
* Du scheinst den Sensor nicht per autocreate angelegt zu haben, was bei dieser Art von Sensor meistens funktioniert. => Fhem device löschen und per autocreate neuerstellen lassen
* Der Sensor agiert unidirektional. Fhem muss nur auf die Signale des Sensors reagieren. Ein "1BS teach-in accepted EEP D5-00-01 Manufacturer: no ID)" sieht erstmal grundsätzlich nicht falsch aus, deutet aber daraufhin, dass das Device in FHEM nicht korrekt angelegt ist. Grundsätzlich scheint die EEP D2-06-50 aber recht ungewöhnlich zu sein und in der commandref finde ich dazu auch nichts. Auch die EnOcean-Doku ist hier etwas dünn.

Edit: Klaus hat es dann ja bestätigt, dass es noch nicht unterstützt wird.

JooNey:
Hallo Klaus und Flachzange,

danke für eure Antworten. Hier der Link zum Handbuch: https://www.siegenia.com/api/service/downloads/file/185996_de

Ich hatte den Sensor initial nicht in der FHEM angelegt, sondern einfach nur "eingeschaltet" durch Einlegen der Batterien, weil ich wissen wollte, was FEHM erkennt, und wie sich der Sensor meldet.
Leider war das erfolglos. Der Sensor hat zwar gepiept, aber im Eventmonitor wurde keinerlei Kommunikation über EnOcean registriert. Meine Vermutung war: da FHEM offiziell die D2-06-50 nicht unterstützt, muss ich den Sensor wohl selbst anlegen.

Also habe ich das Device definiert, ManufID und EEP eingegeben, und beim nächsten Einschalten kamen die Signale in der FHEM an. Es waren auch die der in der EEP beschriebenen "Calibration Routine". Da ich allerdings nicht die Siegenia App hatte, und den Sensor nicht im Fenster verbaut, war meine Kalibrierung eben nicht so ganz richtig. Aber nachdem der Kalibriervorgang durchgelaufen ist, wurden mir beim bewegen des Sensors die Telegramme angezeigt - nur dass die Interpretation des Inhalt schwer war, da ich eben "falsch" kalibriert hatte.

Das war der Punkt, an dem ich die Batterien aus dem Sensor nahm, und ab da kam jedes mal dieser neue Teach-In Prozess.

Was mich eben so sehr verwundert: es hat beim ersten Mal doch auch geklappt, warum jetzt also nicht mehr!? Der erste Versuch hat ja auch kein 1BS Teach-In ausgelöst. Irritiert mich halt einfach. Deswegen die Frage, ob ich nicht eventuell einfach diesen Teach in Prozess skippen kann!?

@Klaus: ist die Implementation eines neuen EEPs schwierig? Könnte ich das theoretisch umsetzen bzw. irgendwie unterstützen? (Habe ich noch nicht soo tief in die Doku eingelesen, denke aber, dass ich mich da durchaus einarbeiten kann!)

@Flachzange: Ist das hier das device listing, welches du wolltest?

--- Code: ---defmod EnO_SiegeniaTest EnOcean 01A0152A
attr EnO_SiegeniaTest IODev TCM_ESP3_0
attr EnO_SiegeniaTest eep D5-00-01
attr EnO_SiegeniaTest manufID 7FF
attr EnO_SiegeniaTest room EnOcean
attr EnO_SiegeniaTest subType contact

setstate EnO_SiegeniaTest open
setstate EnO_SiegeniaTest 2021-03-14 03:19:18 state open
setstate EnO_SiegeniaTest 2021-03-14 03:19:18 teach 1BS teach-in accepted EEP D5-00-01 Manufacturer: no ID
--- Ende Code ---

Viele Grüße
Julian

JooNey:
Hallo zusammen,

ich habe mir mal die Rohdaten vom Sensor über den RaspPi auslesen lassen. Der Teach-In Modus, wenn der Sensor im Werkszustand ist, ist wie folgt:


--- Code: ---[Summary]
- HEX                          |55 00 0D 07 01 FD D4 00 FF 5D 00 50 06 D2 01 A0 15 2A 00 06 FF FF FF FF 55 00 D4
- Packet Type                  |RADIO_ERP1 (Radio telegram)
- Device Name                  |Unknown
- Device ID                    |000001A0152A
- Manufacturer                 |SIEGENIA_AUBI_KG
- EEP                          |D2-06-50
- RORG                         |VLD Telegram
- FUNC                         |Multisensor Window Handle
- TYPE                         |Unknown
- Data                         |Unknown
- Learn                        |true
- Known                        |false
- RSSI                         |-85 dBm
- CRC                          |invalid

[Telegram]
- Sync. Byte                   |55         |55
- Header                       |00 0D 07 01|
  - Data Length                |00 0D      |13 byte
  - Optional Length            |07         |7 byte
  - Packet Type                |01         |RADIO_ERP1 (Radio telegram)
- CRC8H                        |FD         |valid
- Data                         |D4 00 FF ..|
  - R-ORG                      |D4         |Universal Teach-In EEP based (0xD4)
  - Data_DL                    |00 FF 5D ..|
    - Uni-bi-directional comm..|00         |Unidirectional communication (EEP opeartion)
    - EEP Teach-In-Response m..|00         |EEP Teach-In Response message expected
    - Request accepted         |00         |Request not accepted, general reason
    - Command identifier       |00         |EEP Teach-In Query
    - No. of individual chann..|FF         |Teach-in of all channels supported by the device
    - Manufacturer ID          |005D       |SIEGENIA_AUBI_KG
    - TYPE                     |50         |50
    - FUNC                     |06         |06
    - RORG                     |D2         |D2
  - Originator-ID              |01 A0 15 2A|01 A0 15 2A
  - Status                     |00         |Original sender, 0
- Optional Data                |06 FF FF ..|
  - SubTelNum                  |06         |6
  - Destination ID             |FF FF FF FF|FF FF FF FF
  - dBm                        |55         |-85 dBm
  - SecurityLevel              |00         |0
- CRC8D                        |D4         |valid

--- Ende Code ---

Das Gerät meldet sich offensichtlich mit der richtigen EEP und der richtigen ManufID.

Wenn ich dann den Teach-In durchführe (und diesmal richtig), dann bekomme ich diese Telegramme als Reaktionen auf Veränderungen am (imaginären) Fenster:

--- Code: ---============================================================================================================================================================
[Summary]
- HEX                          |55 00 07 07 01 7A D5 09 01 A0 15 2A 00 03 FF FF FF FF 56 00 1E
- Packet Type                  |RADIO_ERP1 (Radio telegram)
- Device Name                  |Unknown
- Device ID                    |000001A0152A
- Manufacturer                 |Unknown
- EEP                          |Unknown
- RORG                         |Unknown
- FUNC                         |Unknown
- TYPE                         |Unknown
- Data                         |Unknown
- Learn                        |Unknown
- Known                        |false
- RSSI                         |-86 dBm
- CRC                          |invalid
------------------------------------------------------------------------------------------------------------------------------------------------------------
[Telegram]
- Sync. Byte                   |55         |55
- Header                       |00 07 07 01|
  - Data Length                |00 07      |7 byte
  - Optional Length            |07         |7 byte
  - Packet Type                |01         |RADIO_ERP1 (Radio telegram)
- CRC8H                        |7A         |valid
- Data                         |D5 09 01 ..|
  - R-ORG                      |D5         |1BS telegram (0xD5)
  - Data_DL                    |09         |
  - Originator-ID              |01 A0 15 2A|01 A0 15 2A
  - Status                     |00         |Original sender, 0
- Optional Data                |03 FF FF ..|
  - SubTelNum                  |03         |3
  - Destination ID             |FF FF FF FF|FF FF FF FF
  - dBm                        |56         |-86 dBm
  - SecurityLevel              |00         |0
- CRC8D                        |1E         |valid
============================================================================================================================================================
[Summary]
- HEX                          |55 00 07 07 01 7A D5 08 01 A0 15 2A 00 03 FF FF FF FF 55 00 B5
- Packet Type                  |RADIO_ERP1 (Radio telegram)
- Device Name                  |Unknown
- Device ID                    |000001A0152A
- Manufacturer                 |Unknown
- EEP                          |Unknown
- RORG                         |Unknown
- FUNC                         |Unknown
- TYPE                         |Unknown
- Data                         |Unknown
- Learn                        |Unknown
- Known                        |false
- RSSI                         |-85 dBm
- CRC                          |invalid
------------------------------------------------------------------------------------------------------------------------------------------------------------
[Telegram]
- Sync. Byte                   |55         |55
- Header                       |00 07 07 01|
  - Data Length                |00 07      |7 byte
  - Optional Length            |07         |7 byte
  - Packet Type                |01         |RADIO_ERP1 (Radio telegram)
- CRC8H                        |7A         |valid
- Data                         |D5 08 01 ..|
  - R-ORG                      |D5         |1BS telegram (0xD5)
  - Data_DL                    |08         |
  - Originator-ID              |01 A0 15 2A|01 A0 15 2A
  - Status                     |00         |Original sender, 0
- Optional Data                |03 FF FF ..|
  - SubTelNum                  |03         |3
  - Destination ID             |FF FF FF FF|FF FF FF FF
  - dBm                        |55         |-85 dBm
  - SecurityLevel              |00         |0
- CRC8D                        |B5         |valid

--- Ende Code ---

Diesmal wird nichts von all den Teaching Informationen wie EEP oder ManufID übertragen, allerdings steht im R-Org das 1BS telegram, was dann vermutlich dafür sorgt, dass der Sensor jetzt auf einmal neu als 1BS eingeteacht wird.

Nehme ich nun die Batterien raus, und lege sie erneut ein, dann wird mit einem kurzen Piep dieses Telegram abgesetzt:

--- Code: ---[Summary]
- HEX                          |55 00 08 07 01 3D D2 11 0A 01 A0 15 2A 51 01 FF FF FF FF 5C 00 43
- Packet Type                  |RADIO_ERP1 (Radio telegram)
- Device Name                  |Unknown
- Device ID                    |000001A0152A
- Manufacturer                 |Unknown
- EEP                          |Unknown
- RORG                         |Unknown
- FUNC                         |Unknown
- TYPE                         |Unknown
- Data                         |Unknown
- Learn                        |Unknown
- Known                        |false
- RSSI                         |-92 dBm
- CRC                          |invalid

[Telegram]
- Sync. Byte                   |55         |55
- Header                       |00 08 07 01|
  - Data Length                |00 08      |8 byte
  - Optional Length            |07         |7 byte
  - Packet Type                |01         |RADIO_ERP1 (Radio telegram)
- CRC8H                        |3D         |valid
- Data                         |D2 11 0A ..|
  - R-ORG                      |D2         |Variable length data telegram (0xD2)
  - Data_DL                    |11 0A      |
  - Originator-ID              |01 A0 15 2A|01 A0 15 2A
  - Status                     |51         |Subtelegram was repeated 1 time, 1
- Optional Data                |01 FF FF ..|
  - SubTelNum                  |01         |1
  - Destination ID             |FF FF FF FF|FF FF FF FF
  - dBm                        |5C         |-92 dBm
  - SecurityLevel              |00         |0
- CRC8D                        |43         |valid

--- Ende Code ---

Und nach einiger Zeit und einigem Piepen kommen dann wieder die normalen Sender-Telegramme durch, wie es scheint:

--- Code: ---[Summary]
- HEX                          |55 00 07 07 01 7A D5 09 01 A0 15 2A 00 03 FF FF FF FF 47 00 5C
- Packet Type                  |RADIO_ERP1 (Radio telegram)
- Device Name                  |Unknown
- Device ID                    |000001A0152A
- Manufacturer                 |Unknown
- EEP                          |Unknown
- RORG                         |Unknown
- FUNC                         |Unknown
- TYPE                         |Unknown
- Data                         |Unknown
- Learn                        |Unknown
- Known                        |false
- RSSI                         |-71 dBm
- CRC                          |invalid

[Telegram]
- Sync. Byte                   |55         |55
- Header                       |00 07 07 01|
  - Data Length                |00 07      |7 byte
  - Optional Length            |07         |7 byte
  - Packet Type                |01         |RADIO_ERP1 (Radio telegram)
- CRC8H                        |7A         |valid
- Data                         |D5 09 01 ..|
  - R-ORG                      |D5         |1BS telegram (0xD5)
  - Data_DL                    |09         |
  - Originator-ID              |01 A0 15 2A|01 A0 15 2A
  - Status                     |00         |Original sender, 0
- Optional Data                |03 FF FF ..|
  - SubTelNum                  |03         |3
  - Destination ID             |FF FF FF FF|FF FF FF FF
  - dBm                        |47         |-71 dBm
  - SecurityLevel              |00         |0
- CRC8D                        |5C         |valid

--- Ende Code ---

Das alles hilft mir aber eben leider nicht, da FHEM irgendwie das ursprüngliche Teach-In nicht als das interpretiert, was es ist, und danach (obwohl kein Teach-In Telegram vom Sensor abgesetzt wird), die Telegramme direkt als Teach-Ins ansieht, und das device ändert.

Lässt sich mit diesen Informationen jetzt evtl. ein bisschen mehr anfangen?

Viele Grüße
Julian

Navigation

[0] Themen-Index

[#] Nächste Seite

Zur normalen Ansicht wechseln