Medion/MAX! Tür-/Fensterkontakt auf Homematic flashen

[andyboeh]

Hey,

ich habe seit einiger Zeit Medion/MAX! Tür-/Fensterkontakte im Einsatz, die ich mit HomegearRaspberrymatic einsetze und sie nicht für die Heizung verwende. Die Kontakte haben einen STM8L052C6 Mikrocontroller und ein Si4430 Funkmodul, im Gegensatz zum Samsung-Prozessor in den originalen MAX!-Kontakten. Grundsätzlich kann man also entwickeln.

Nach langer Recherche habe ich eine Custom-Firmware für einen HM-CC-RT-DN Thermostaten gefunden, der eine ähnliche Hardware verwendet. Nach etwas Portierarbeit laufen nun die Basics und die Infrastruktur für eine komplette Firmware ist vorhanden. Der TFK gibt sich als HM-Sec-SC-2 aus, er hat aber keinen Sabotagekontakt.

Aktueller Stand:

- Pairing funktioniert
- Statusnachrichten (Offen/geschlossen) funktionieren
- AES Key Exchange funktioniert
- AES Challenge-Response funktioniert
- Batteristatus wird ausgelesen und mit übertragen
- LED feedback
- Periodischer Report, wenn aktiviert
- Power Management: 20uA im Sleep-Mode
- Flashen per Pogopin-Adapter möglich

TODO:
- Peering
- ...?

Zur Installation wird ein ST-Link v2 Programmer benötigt, zum Kompilieren einiges an Linux-Tools - siehe README. Ein 3D-Modell für einen Pogopin-Programmieradapter ist ebenfalls dabei.

Und hier ist der Code: https://github.com/andyboeh/medion-hm-sec-sc

[andyboeh]

Auch wenn das Interesse relativ gering zu sein scheint: Ich komme ganz gut voran. AES läuft jetzt (Key Exchange und Challenge-Response), aber Nachrichten vom Master werden noch nicht überprüft (d.h. es werden keine Signaturanfragen ausgesendet). Das bedeutet, dass man AES auch einfach deaktivieren kann und nicht authentifiziert wird, ob das auch so sein soll.

Parallel dazu werde ich einen Flash-Adapter mittels Pogo-Pins designen (3D-Druck), damit man nicht immer löten muss, um die Kontakte zu flashen (ich habe >10 Kontakte, wenn ich den Stromverbrauch optimiert habe, möchte ich nicht alle einzeln löten müssen).

[Horbi]

Sehr cool, leider habe ich meine Max Komponenten vor geraumer Zeit verschrottet.
Interessant finde ich aber auch ein anderes Funkmodul zu nutzen.
War das aufwändig zu integrieren?
Wie funktioniert das mit der magic word Erkennung zu Beginn der Übertragung?
Funktioniert die 300ms Trägersignalerkennung zum Aufwachen?
Wie sieht es bei dem Funkmodul generell mit dem Stromverbrauch aus?

Fragen über Fragen

[andyboeh]

Interessant finde ich aber auch ein anderes Funkmodul zu nutzen.
War das aufwändig zu integrieren?

Für mich nicht mehr, weil Timo das schon für den HM-CC-RT-DN erledigt hat: https://github.com/timo-schluessler/custom-hm-cc-rt-dn
Ich gehe davon aus, dass eine Integration z.B. in AskSin++ nicht besonders schwierig ist, weil die modulspezifischen Funktionalitäten gut gekapselt sind. Für den STM8 gibt's halt keinen C++ Compiler, deshalb auch kein AskSin++.

Gibt es Homematic-Komponenten, die einen AVR mit einem SiLabs-Modul verwenden? Dann könnte man sich das ggf. ansehen. Ich habe leider kein SiLabs-Modul übrig.

Wie funktioniert das mit der magic word Erkennung zu Beginn der Übertragung?
Funktioniert die 300ms Trägersignalerkennung zum Aufwachen?
Wie sieht es bei dem Funkmodul generell mit dem Stromverbrauch aus?

Habe ich mir, ehrlich gesagt, nicht angesehen, weil am Fensterkontakt ein Konfigurieren nur per Tastendruck möglich ist. Der Stromverbrauch bezieht sich auf das gesamte System und Funkmodul im "Idle"-State, da messe ich etwas über 20 uA. Ich kann in den nächsten Tagen gerne einen Screenshot des Stromverbrauchs bei der Übertragung posten.

Ich spiele schon auch mit dem Gedanken, den Heizkörperthermostat anzugehen (ist auch STM8 + Si4430), aber mit der ganzen Regelung und Zeitplanung in der Firmware, Kalibrierfahrt, LCD-Display ... kommt da einiges an zusätzlichem Aufwand hinzu.

[jp112sdl]

Ich gehe davon aus, dass eine Integration z.B. in AskSin++ nicht besonders schwierig ist

Inzwischen ist das Si4431 implementiert.
https://github.com/jp112sdl/AskSinPP/bl ... o-Si4431.h

Leider bin ich erst jetzt hier über dein Projekt gestolpert, sonst wären wir (also hauptsächlich stan23) wohl schneller zum Ziel gekommen.
viewtopic.php?f=76&t=74413&p=722160#p722160

[andyboeh]

Danke, gut zu wissen! Wobei der Teil nicht von mir ist, sondern auf dem oben verlinkten Projekt mit HM-CC-RT-DN basiert.

[borsti_k]

Bin durch Zufall auf dieses Projekt aufmerksam geworden. Danke Dir für die Arbeit an dem Projekt, dies machte die Entsorgung von 10 Fensterkontakten unnötig. Mit einigen Workarounds laufen diese nun in FHEM einwandfrei.
Eine Frage dennoch: Das Aktivieren der periodischen Reports erfolgt wie in einigen Foren beschrieben durch setzen des entsprechenden Registers (cyclicInfoMsg)? Danke!

[andyboeh]

Workarounds auf FHEM-Seite oder im Code? Was musstest du machen?

Ja, an sich sollte das funktionieren, aber ob sie wirklich aufwachen, weiß ich nicht. Ich hab das letzten Monat erst soweit implementiert, dass sie auch mit einer CCU pairen aber ich hatte noch keine Zeit, sie länger als ein paar Minuten laufen zu lassen.

Ich bilde mir ein, dass die Cyclic Info mit Homegear funktioniert hat, zumindest hat sich Homegear nicht mehr beschwert. Mittlerweile bin ich aber von Homegear auf CCU umgestiegen, weil Homegear leider ziemlich tot zu sein scheint.

[borsti_k]

Zuerst beim flashen, was aber sicher an meinen rudimentären Linux-Kenntnissen liegt. Kompilieren mit cmake endete immer mit einer Fehlermeldung, Auslöser war der Aufruf stm8-objcopy. War aber kein Problem, da stm8flash auch .bin files verarbeitet. ./flash funktionierte bei mir nicht, Zugriff verweigert (Linux-noob ).

Die Fensterkontakte konnten problemlos als threeStateSensor angelernt werden, allerdings gab es keine Rückmeldung des Zustandes "open". "closed" funktionierte. In der für die Umsetzung in FHEM zuständige Datei 10_CUL_HM.pm wird als "open" die Meldung "C8" erwartet. Die in dem Master enthaltene Datei "as_send_contact_state.c" meldet aber "02". Geändert und schon funktionierte alles.

Bei mir läuft eine VCCU unter FHEM und eine CCU. Werde mal einen Fensterkontakt versuchsweise an die CCU anlernen, um die Statusmeldung zu testen. Die in FHEM vorgesehene Methode über das Register "cyclicInfoMsg" funktionierte nicht.

[andyboeh]

OK, ich bin gespannt. Momentan ist bei mir recht viel los, aber ich möchte die Kontakte auch wieder länger testen und in Betrieb nehmen. Mit Homegear hatte ich sie ca. 2 Jahre ziemlich problemlos im Betrieb (die Batterie-Leer-Meldung hat nicht richtig geklappt, aber das war mir dann nicht so wichtig), seit der Umstellung auf CCU habe ich sie nicht mehr aktiviert.

Das flash.sh Skript geht bei mir nur mit "sudo", sonst hat es keinen Zugriff auf den Flasher.