HomeMatic Fenster-Drehgriffkontakt Community-Nachbau: Unterschied zwischen den Versionen

Version vom 30. Dezember 2017, 18:47 Uhr

Der HB-Sec-RHS Funk-Fenster-Drehgriffkontakt ist ein Selbstbau threeStateSensor zur Überwachung eines Fenster-Drehgriffs.

Die Firmware ist identisch mit dem Originalen Sensor von ELV und verhält sich dementsprechend auch gleich.

Übersicht

Die Grundidee zu diesem Sensor wurde durch Kawaci im Forum geliefert. Die Umsetzung besteht aus einer Atmega328p Platine mit CC1101 Funkmodul (868 MHz) sowie einer auf der AskSin++ Portierung des Homematik Protokolls.

Anfangs gab es zwei Ideen wie der Sensor aussehen sollte. Inzwischen hat sich die HomeMatic Variante mit CR2032 Batteriehalterung auf der Platine durchgesetzt. Somit wird hier nicht näher auf andere Versionen (zwei Platinen zur Erfassung der Fensterstellung) eingegangen.

Platine

Schaltplan:

Platine v1.0 (Oberseite mit korrigierter Pinbelegung):

Platine v1.0 (Unterseite, ohne bestücktes Radio):

Bauteilliste

Die Bauteilliste gibt es auf GitHub.

Zusammenlöten der SMD Bauteile

Die Bestückung der Platine ist im diesem Post kurz beschrieben.

Bemerkung: Y1 (32 kHz Quarz), C4 und C5 sind nicht erforderlich. Vor dem Verlöten der Bauteile sollte kontrolliert werden, ob die Platinen in das Gehäuse passen. Falls nicht, sollte entweder das Gehäuse oder die Platine passend gefeilt werden.

Zuerst auf der Unterseite IC1 bestücken: Hierzu einen beliebigen äußeren Pin verzinnen, den Prozessor mit der richtigen Orientierung von Pin 1 (runder Punkt) platzieren und den Pin verlöten. Darauf achten, dass der Prozessor mittig auf den Pads aufliegt, ggf. den Pin wieder erhitzen und den IC drehen oder verschieben. Auf der gegenüberliegenden Seite ebenfalls einen Pin verlöten, damit der IC fixiert ist. Mit einem Flussmittelstift auf allen vier Seiten die Pins bestreichen und auf jeder Seite die Pins einzeln mit einer feinen Lötspitze bzw. feinem Lötzinn verlöten. Kurzschlüsse zwischen einzelnen Pins müssen unbedingt vermieden werden.

Danach auf der Unterseite C1, C2, C3 sowie R1 bestücken. Auf der Oberseite R2, D1 (rot), R3, D2 (gelb), C6 und die beiden Taster bestücken.

Nach dem Flashen der Firmware das Radio (IC2) bzw. den Batteriehalter (BT1) bestücken. Als Antenne (ANT) wird ein Draht mit 86 mm Länge eingelötet.

Firmware

Bootloader

Die Sensorfirmware kann OTA (Over The Air) oder über den Arduino Bootloader geladen werden.

Erstellen des OTA (Over The Air) Bootloaders

Dafür wird, mit Hilfe der makeota.html der Bootloader mit den benötigten Daten gefüllt und anschließend generiert.

Die makeota.html wird dazu in einem belibigen Browser aufgerufen.

Die Felder HM ID und HM-Serial innerhalb der makeota.html können jeweils frei gewählt werden (dabei die Vorgaben beachten, so z.B. HM ID: 6 hexadezimale Zeichen). Das Feld Device Type muss folgende Nummer beinhalten: "0030". Das Feld Config String wird aus den eingegebenen Daten automatisch generiert.

Die zwei o.g. Felder müssen sich von Gerät zu Gerät unterscheiden. Aus diesem Grund ist es sinnvoll, sich die eingegebenen Daten aufzuschreiben oder Screenshots zu erstellen.

Nun muss noch dem Bootloader bekannt gemacht werden, welche Batterien mit dem FDGK verwendet werden. Dies wird über die dropdown Liste "Power Presets" ausgewählt:

Dabei bedeutet:

No StepUp = CR2032 Batterie
StepUp single AA = eine AA Batterie und StepUp
StepUp two AAA = zwei AAA Batterien und StepUp

Die Parameter „Step-Up Present“, „Low-Voltage“ und „Critical Voltage” ergeben sich aus der Wahl in der DropDown Liste, können aber individuell angepasst werden. Für den fehlerfreien Betrieb sollten diese aber unverändert bleiben!

Seit 12/2017 kann optional die aktuelle Firmware mit angegeben werden, so dass die Firmware gleichzeitig mit dem Bootloader geflasht werden kann. In diesem Fall kann der FDGK sofort in Betrieb genommen werden und nur es wird nur eine aktualisierte Firmware per OTA (Over The Air) geflasht.

Nach drücken der Taste "Create" erscheint eine Schaltfläche "Save Bootloader", mit welcher der angepasste Boorloader gespeichert werden kann. Es wird hierzu kein Netzzugang benötigt. Alles erfolgt per Javascript im Browser.

Flashen des OTA Bootloaders

Anschließend wird per ISP (USBasp oder vergleichbares) der Bootloader geflasht. Zum Laden des Bootloaders, sowie der Software werden die Arduino SDK bzw. avrdude und die von makeota.html generierte Datei benötigt.

Der Bootloader lässt sich nun bei gestecktem ISP Programmer über folgende Befehle flashen:

avrdude -p m328p -P usb -c usbasp -B 3 -U lfuse:w:0xE2:m -U hfuse:w:0xD0:m -U efuse:w:0x06:m -U lock:w:0x2F:m

Setzt die Fuses.

avrdude -p m328p -P usb -c usbasp -V -U flash:w:bootloader.hex

lädt den eigentlichen Bootloader. Dabei ist zu achten, dass "bootloader.hex" die Datei mit dem Bootloader (bzw. der Firmware) ist und dementsprechend auch im Verzeichnis sein muss, wo die Datei zu finden ist.

Wenn jetzt die Platine mit Spannung versorgt wird, sollte die rote LED 7x blinken. Das signalisiert, dass der Bootloader erfolgreich gestartet wurde. Er wartet jetzt darauf, dass die Firmware übertragen wird.

OTA Update

Hierzu wird flash-ota benötigt.

Flash-ota funktioniert aktuell nur mit CUL/COC oder HM-CFG-USB unter Linux (Update mit CUL oder HM-CFG-USB unter Linux), mit dem "HomeMatic Firmware Update Tool" unter Windows (Update mit HM-CFG-USB unter Windows) oder mit einer CCU2.

Für einen HM-CFG-USB oder den HM-UART sieht der Aufruf wie folgt aus:

./flash-ota -f avr_HM_SEC_RHS_201705271601.eq3 -s RHS0000000

Für einen CUL muss noch die USB Schnittstelle oder der Pfad des USB Geräts mit gegeben werden:

./flash-ota -f avr_HM_SEC_RHS_201705271601.eq3 -s RHS0000000 -c /dev/serial/by-path/platform-3f980000.usb-usb-0:1.3:1.0-port0

Falls Fehler während der Übertragung auftreten, muss die Übertragung nochmals wiederholt werden. Wenn die Firmware erfolgreich übertragen werde konnte, kann der Sensor gepairt werden.

Einlöten der Reedkontakte und Anschluss an A0 & A1

...TEXT...

Sensor spezifische Einstellungen

Der Sensor meldet die Position entsprechend welcher Zustand an A0 & A1 an liegt. Derzeit ist folgende Logik implementiert:

A0 & A1 offen - PosA -> OPEN

A0 geschlossen - PosB -> CLOSED

A1 geschlossen - PosC -> TILTED

Die Bedeutung der Positionen kann mittels der entsprechenden Register eingestellt werden.

Ebenfalls kann die CyclicInfoMsg aktiviert werden (zum aktivieren siehe Link am ende des Artikels). Der Sensor meldet sich dann alle 24 Stunden mit dem aktuellen Status.

Register zum ändern der Position von A0 & A1:

set <Device_Name> regSet msgRhsPosA <closed|open|noMsg|tilted>

set <Device_Name> regSet msgRhsPosB <closed|open|noMsg|tilted>

set <Device_Name> regSet msgRhsPosC <closed|open|noMsg|tilted>

Gehäuse

Für das Gehäuse wurde auf eine 3D-Drucklösung gesetzt. Es gibt inzwischen mehrere Versionen (abgerundete obere Kante, eckige Kante uvm.).

Die Standard Version ist hier zu finden.

Wer keinen 3D-Drucker besitzt kann sich im Forum nach einem 3D-Druckservice um schauen. Einige User bieten gegen kleines Geld einen netten und preiswerten Service an.

Links

@@ Zeile 10: / Zeile 10: @@
 einer auf der [https://github.com/pa-pa/AskSinPP AskSin++] Portierung des Homematik Protokolls.
-Anfangs gab es zwei Ideen wie der Sensor aussehen sollte. Inzwischen hat sich die HomeMatic Variante mit CR032 Batteriehalterung auf der Platine durchgesetzt. Somit wird hier nicht näher auf andere Versionen (zwei Platinen zur erfassung der Fensterstellung) eingegangen.
+Anfangs gab es zwei Ideen wie der Sensor aussehen sollte. Inzwischen hat sich die HomeMatic Variante mit CR2032 Batteriehalterung auf der Platine durchgesetzt. Somit wird hier nicht näher auf andere Versionen (zwei Platinen zur Erfassung der Fensterstellung) eingegangen.
 == Platine ==