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