HomeMatic Fenster-Drehgriffkontakt Community-Nachbau: Unterschied zwischen den Versionen
| Zeile 114: | Zeile 114: | ||
Der Sensor meldet die Position entsprechend welcher Zustand an A0 & A1 an liegt. Derzeit ist folgende Logik implementiert: | Der Sensor meldet die Position entsprechend welcher Zustand an A0 & A1 an liegt. Derzeit ist folgende Logik implementiert: | ||
A0 & A1 offen - PosA -> | A0 & A1 offen - PosA -> OPEN | ||
A0 geschlossen - PosB -> | A0 geschlossen - PosB -> CLOSED | ||
A1 geschlossen - PosC -> TILTED | A1 geschlossen - PosC -> TILTED | ||
| Zeile 130: | Zeile 130: | ||
<pre>set <Device_Name> regSet msgRhsPosB <closed|open|noMsg|tilted></pre> | <pre>set <Device_Name> regSet msgRhsPosB <closed|open|noMsg|tilted></pre> | ||
<pre>set <Device_Name> regSet msgRhsPosC <closed|open|noMsg|tilted></pre> | <pre>set <Device_Name> regSet msgRhsPosC <closed|open|noMsg|tilted></pre> | ||
== Gehäuse == | == Gehäuse == | ||
Version vom 22. Dezember 2017, 19:50 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. Das Platinenlayout des Sensors teilt sich auf zwei Platinen auf. Der eigentliche Sender, welcher Arduino-Kompatibel ist, sowie der Sensorplatine zur Erfassung der Fenstergriffstellung.
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 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.
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.