Autor Thema: Siegenia Fenstersensoren (D2-06-50) nach Batteriewechsel als 1BS auto teachin  (Gelesen 3201 mal)

Offline JooNey

  • New Member
  • *
  • Beiträge: 9
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
« Letzte Änderung: 14 März 2021, 03:21:56 von JooNey »

Offline klaus.schauer

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1211
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.

Offline Flachzange

  • Full Member
  • ***
  • Beiträge: 104
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.

Offline JooNey

  • New Member
  • *
  • Beiträge: 9
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?
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

Viele Grüße
Julian

Offline JooNey

  • New Member
  • *
  • Beiträge: 9
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:

[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

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:
============================================================================================================================================================
[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

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:
[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

Und nach einiger Zeit und einigem Piepen kommen dann wieder die normalen Sender-Telegramme durch, wie es scheint:
[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

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

Offline klaus.schauer

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1211
Danke für die zusätzlichen Informationen. Sobald das Profil im EnOcean-Modul fertig ist, geht es weiter.

Offline JooNey

  • New Member
  • *
  • Beiträge: 9
Hallo klaus,

klingt super. Ich habe mal noch ein wenig gespielt, und dabei das siegenia Gateway benutzt, welches mir auch zum Testen überlassen wurde. Dabei habe ich festgestellt, dass die App insgesamt 6 verschiedene Fenstertypen kennt. Dazu kann man noch etwas einstellen was den Alarm betrifft: "Alarm+Meldung", "Meldung", "Keine", sowie eine "Alarmstärke" zwischen 1 und 7.

Das Gateway sendet dann auch entsprechend der Auswahl ein Teaching-Telegram, da die Methode zum Kalibrieren vom Fenster-Typ abhängt. Im Wechsel sendet das Gateway auch eine Art Kurztelegram, welches aber nicht vom Fenstertyp oder anderen Einstellungen beeinflusst wird.

Hier mal die Meldungen der Station (für DrehKipp mal die Alarm-Einstellungen geändert, um zu sehen, wie das Telegram angepasst wird - die Leerräume habe ich eingefügt, um ähnliche Blöcke untereinander zu haben, in der Hoffnung, dass die zusammen gehören :) ):
Kurztelegram:
- HEX                            |55 00 08 0A 07 C6 00 02 07 FF 8C 39 2D F5                                                                   FF FF FF FF 04 10 DD 96 41 00 8C

DrehKipp
- HEX   Summer+Meldung 1        |55 00 1E 0A 07 19 02 31 07 FF 00 00 02 03 84 00 01 02 00 00 00 02 01 00 00 03 01 00 00 04 01 00 00 05 01 00 FF FF FF FF 04 10 DD 96 41 00 3F
- HEX   Meldung        4        |55 00 1E 0A 07 19 02 31 07 FF 00 00 02 03 84 00 01 02 00 00 00 02 01 00 00 03 01 00 00 04 01 01 00 05 01 03 FF FF FF FF 04 10 DD 96 41 00 AB
- HEX   Keine          7        |55 00 1E 0A 07 19 02 31 07 FF 00 00 02 03 84 00 01 02 00 00 00 02 01 00 00 03 01 00 00 04 01 02 00 05 01 06 FF FF FF FF 04 10 DD 96 43 00 3A

Tilt Before Turn
- HEX                           |55 00 1E 0A 07 19 02 31 07 FF 00 00 02 03 84 00 01 02 00 00 00 02 01 00 00 03 01 01 00 04 01 00 00 05 01 00 FF FF FF FF 04 10 DD 96 41 00 E9


Parallel-Abstell/Vent-Secure
- HEX                           |55 00 1E 0A 07 19 02 31 07 FF 00 00 02 03 84 00 01 02 00 00 00 02 01 00 00 03 01 02 00 04 01 00 00 05 01 00 FF FF FF FF 04 10 DD 96 41 00 94


Dreh/Schwing/Wende/Klapp
- HEX                           |55 00 1E 0A 07 19 02 31 07 FF 00 00 02 03 84 00 01 02 00 00 00 02 01 00 00 03 01 04 00 04 01 00 00 05 01 00 FF FF FF FF 04 10 DD 96 41 00 6E


Kipp
- HEX                           |55 00 1E 0A 07 19 02 31 07 FF 00 00 02 03 84 00 01 02 00 00 00 02 01 00 00 03 01 05 00 04 01 00 00 05 01 00 FF FF FF FF 04 10 DD 96 41 00 B8


Öffnungserkennung
- HEX                           |55 00 1E 0A 07 19 02 31 07 FF 00 00 02 03 84 00 01 02 00 00 00 02 01 00 00 03 01 20 00 04 01 00 00 05 01 00 FF FF FF FF 04 10 DD 96 40 00 AC

Bisher habe ich mal von 2 Varianten die Sensor-Response abgeholt:
Response DrehKipp:
- HEX                          |55 00 08 07 01 3D D2 11 01                   01 A0 15 2A 59 01 FF FF FF FF 47 00 1C
- HEX                          |55 00 08 07 01 3D D2 11 02                   01 A0 15 2A 59 01 FF FF FF FF 47 00 A7
- HEX                          |55 00 08 07 01 3D D2 11 03                   01 A0 15 2A 51 01 FF FF FF FF 47 00 AB
- HEX                          |55 00 08 07 01 3D D2 11 01                   01 A0 15 2A 59 01 FF FF FF FF 47 00 1C
- HEX                          |55 00 08 07 01 3D D2 11 00                   01 A0 15 2A 59 01 FF FF FF FF 47 00 88
- HEX                          |55 00 0E 07 01 40 D2 01 01 00 00 00 0D 5A 82 01 A0 15 2A 00 03 FF FF FF FF 4F 00 20


Response Dreh/Schwing/Wende/Klapp
- HEX                          |55 00 08 07 01 3D D2 11 01                   01 A0 15 2A 51 01 FF FF FF FF 4F 00 2C
- HEX                          |55 00 08 07 01 3D D2 11 02                   01 A0 15 2A 59 01 FF FF FF FF 4C 00 30
- HEX                          |55 00 08 07 01 3D D2 11 01                   01 A0 15 2A 59 01 FF FF FF FF 4D 00 9E
- HEX                          |55 00 08 07 01 3D D2 11 00                   01 A0 15 2A 59 01 FF FF FF FF 4D 00 0A
- HEX                          |55 00 0E 07 01 40 D2 01 1F 00 00 00 00 7F 82 01 A0 15 2A 00 03 FF FF FF FF 4F 00 6B
- HEX                          |55 00 0E 07 01 40 D2 01 1F 00 00 00 00 5A 82 01 A0 15 2A 00 03 FF FF FF FF 4F 00 E7

Ich würde das am Wochenende nochmal etwas ausführlicher machen, und dann hier wieder entsprechend posten. Was ich nicht wirklich provozieren kann, sind die Meldungen, die der Sensor während des Betriebs, oder bei Störung/Alarm sendet, demnach keine Ahnung, was da eventuell alles kommen könnte.

Falls du, Klaus, noch n paar Ideen hast, was ich testen soll, dann gern raus damit.

Viele Grüße und vielen Dank für deinen Einsatz
Julian

Offline klaus.schauer

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1211
Es wird nicht notwendig sein, zu versuchen die Telegramme auf diese Weise auszuwerten. Die Beschreibung des EEP liegt allgemein zugänglich vor, siehe http://tools.enocean-alliance.org/EEPViewer/profiles/D2/06/50/D2-06-50.pdf.

Offline JooNey

  • New Member
  • *
  • Beiträge: 9
Da haben wir uns vermutlich missverstanden. Mir ging es nicht darum hier "reverse-engineering" der Sensor-Telegramme zu machen. Aber wenn ich die EEP Dokumentation nicht vollkommen falsch lese, dann steht da nichts darüber, dass eine "Basis-Station" mit Teach-In-Telegrammen dem Sensor mitteilt, welchen Kalibriermodus er anwenden soll. Je nachdem was man in der App einstellt, werden ja verschiedene Telegramme von der Basis aus an den Sensor geschickt, und der wird dann mit jeweils anderen Bewegungen kalibriert.

Dachte halt, das könnte helfen, aber wenn das doch auch alles so in der Doku steht, dann fehlt mir wohl einfach die Erfahrung.

Offline klaus.schauer

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1211
Im EnOcean-Modul steht das notwendige UTM-Protokoll zum Anlernen bereits zur Verfügung. Über das EEP D2-06-50 wird das Kalibrieren und das Regelbetrieb abgedeckt. U. U. kann es zusätzliche firmenspezifische Erweiterungen geben. Diese wären im EnOcean-Modul nicht immer vollständig abbildbar. Das sehen wir, sobald die Standardfunktionen bereitstehen. Ich muss da aber noch im Geduld bitten.

Offline klaus.schauer

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1211
Mit dem nächsten Update ist jetzt auch das Profil EEP D2-06-50 verfügbar.

Nach dem Anlernen muss der Sensor sofort kalibriert werden. Die Prozedur ist der Gebrauchsanleitung beschrieben. Falls das Kalibrieren erfolgreich war, zeigt das Reading calibrationStep none und statusCalibration ok an.
Bei Statusänderungen der Readings "handle" und "window" kann Fhem Telegramme an Aktoren senden. Damit wird es möglich, auch z. B. Schalt- und Rolloaktoren anzusteuern. Emuliert werden die Profile Kontakt (EEP D5-00-01) und Window Handle (EEP F6-10-00).
Das Profil Kontakt (EEP D5-00-01) leitet die Aktionen von "window" weiter und wird aktiviert über
attr <device> subDefW getNextID
Das Profil Window Handle (EEP F6-10-00) reagiert auf das Reading "handle" und wird aktiviert über
attr <device> subDefH getNextID
Fhem kann danach über die zugehörigen teach-in Kommandos des Profils in die Aktoren eingelernt werden.
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline DrRSatzteil

  • Newbie
  • Beiträge: 2
Da haben wir uns vermutlich missverstanden. Mir ging es nicht darum hier "reverse-engineering" der Sensor-Telegramme zu machen. Aber wenn ich die EEP Dokumentation nicht vollkommen falsch lese, dann steht da nichts darüber, dass eine "Basis-Station" mit Teach-In-Telegrammen dem Sensor mitteilt, welchen Kalibriermodus er anwenden soll. Je nachdem was man in der App einstellt, werden ja verschiedene Telegramme von der Basis aus an den Sensor geschickt, und der wird dann mit jeweils anderen Bewegungen kalibriert.

Dachte halt, das könnte helfen, aber wenn das doch auch alles so in der Doku steht, dann fehlt mir wohl einfach die Erfahrung.

Hallo JooNey,

ich bin selbst kein FHEM User aber habe diesen Thread hier mit großem Interesse gelesen. Ich habe selbst ein paar dieser Sensoren im Einsatz und würde gerne die Alarmintensität verändern da der Alarm häufig schon beim Öffnen des Fensters ertönt. Hast du deine Untersuchungen zu den individuellen Teach In Nachrichten fortgesetzt oder gibt es hier keinen neuen Stand? Ich selbst habe leider kein Siegenia Gateway (sonst müsste ich das ja auch nicht selbst bauen) und kann daher leider auch keine eigenen Untersuchungen anstellen. Im aktuellen FHEM Code scheint ja auf jeden Fall nichts diesbezüglich umgesetzt zu sein.

Viele Grüße an die ganze FHEM Community
Thomas

Offline klaus.schauer

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1211
Das für den Gerätetyp erforderliche EEP ist in Fhem Modul 10_EnOcean implementiert und getestet. Eine Änderung von Geräteeigenschaften wie die Ansprechempfindlichkeit ist über den EEP-Funktionsumfang nicht vorgesehen und möglich.

Offline DrRSatzteil

  • Newbie
  • Beiträge: 2
Das für den Gerätetyp erforderliche EEP ist in Fhem Modul 10_EnOcean implementiert und getestet. Eine Änderung von Geräteeigenschaften wie die Ansprechempfindlichkeit ist über den EEP-Funktionsumfang nicht vorgesehen und möglich.

Hallo Klaus,

vielen Dank für deine Antwort. Den Code hatte ich schon gesehen und dort keine entsprechende Logik gefunden. Grundsätzlich wäre eine Einstellung jedoch möglich (ist im Handbuch beschrieben). Leider ist das genaue Format der Teach In Nachricht nirgendwo beschrieben. Ich hatte schon bei Siegenia nachgefragt aber mache mir da ehrlich gesagt keine Hoffnungen weitere Infos zu bekommen.

VG
Thomas

 

decade-submarginal