FHEMWiki - Benutzerbeiträge [de]

LaCrosseGateway V1.x

2022-01-26T08:58:56Z

PeMue: Baudrate hinzugefügt

Diese Wiki-Seite beschreibt ausschließlich das LaCrosseGateway V1.x, das auf dem ESP8266 basiert.<br/>
Für das LaCrosseGateway32 [https://forum.fhem.de/index.php?topic=70338.0] das auf dem ESP32 basiert, wird es eine eigene Seite geben.{{Randnotiz|RNText=Dokumentationsstand Version 1.27}}

Das LaCrosseGateway (hier und im Forum auch mit LGW abgekürzt) erfüllt den gleichen Zweck wie ein [[JeeLink|JeeLink USB-Stick]] und zwar das Empfangen, Abfragen und Steuern von funkbasierten LaCrosse Sensoren und Aktoren, die im 868 MHz FSK Sendeverfahren arbeiten (OOK-Sendeverfahren (433 MHz) wird nicht unterstützt). Die Verarbeitung der Daten und Steuerung der Aktoren erfolgt mithilfe von FHEM, das als zentrale Steuereinheit dient.
Der signifikante Unterschied zu einem JeeLink USB-Stick ist der Betrieb über Wireless LAN ([https://de.wikipedia.org/wiki/Wi-Fi WiFi]).
Das Herzstück des LaCrosse-Gateways besteht aus einem ESP8266-12E/F. Das LaCrosseGateway ist aufgrund des hohen Stromverbrauchs nicht für den Akkubetrieb geeignet.

Der Einsatz eines WiFi-LaCrosse-Gateways bietet folgende Vorteile:
*Kann an eine Stelle platziert werden, an der alle Sensoren optimal empfangen werden, dafür ist nur Strom (5V/1A USB Netzteil) und [https://de.wikipedia.org/wiki/Wi-Fi WiFi] Access Point erforderlich
*Im Minimalausbau nur zwei Bauteile NodeMCU DEVKIT 1.0 + RFM69 (siehe Bauteile) nötig
*Alternativ am USB-Port wie ein JeeLink verwendbar
*Einsatz von on board Sensoren / Aktoren (siehe [[#Unterstützte Sensoren und Aktoren | Unterstützte Sensoren und Aktoren]]) möglich

Hinweis: Die Anbindung in FHEM kann zwar noch mit dem JeeLink-Modul erfolgen, aber es ist sinnvoll, auf das LaCrosseGateway-Modul (36_LaCrosseGateway.pm) umzustellen, da dieses eine bessere Unterstützung für die Funktionen des LGW bietet.

=Hardware=
==Bauteile==
Für das WiFi-LaCrosse-Gateway werden folgende Bauteile verwendet:
*[Option 1] [http://www.esp8266.com/wiki/doku.php?id=esp8266-module-family#esp-12-e_q ESP8266 ESP-12E Modul].<br />Diese Variante eignet sich für Projekte für die eine kleine Bauform benötigt wird.<br />Für die Inbetriebnahme, insbesondere für das Aufbringen der Firmware, muss das Modul an einen [[Medium:Lgw USB2Serial Adapter.jpg|USB2Serial-Adapter]] angeschlossen werden. Für diese Variante sind Lötkenntnisse erforderlich.
*[Option 2] [https://raw.githubusercontent.com/nodemcu/nodemcu-devkit-v1.0/master/Documents/NodeMCU_DEVKIT_1.0.jpg NodeMCU DEVKIT 1.0 (oder 2.0)]ist die Inbetriebnahme einfacher, da alles für das Aufbringen der Firmware bereits vorhanden ist und kein Löten nötig ist.<br />{{Link2Forum|Topic=45594|Message=430183|LinkText=Hinweis:}} Folgende Devkits werden nicht "offiziell" unterstützt, da ungetestet, können aber durchaus in bestimmten Fällen verwendet werden:
** V0.9 (da ungetestet, bekommt man aber kaum noch zu kaufen)
** V3.0 - passt nicht auf die Platine von PeMue, ist größer als das 2.0. Auf der Rückseite steht "Lolin".
** Devkits mit einem CH340 USB converter (da ungetestet und teils falsche Bauform und von der USB-Anbindung her teils problematisch)
*[Option 3] Alternativ zu einem DEVKIT 1.0 kann auch ein [http://www.wemos.cc/Products/d1_mini.html "WeMOS D1 mini"] eingesetzt werden. Vorteil bei diesem Kit ist die kleine Bauform bei gleichem Funktionsumfang wie das DEVKIT 1.0.
*[Option 4] ESP8266-07 auf einem DEVKIT 1.0. für den Betrieb mit einer externen Wifi Antenne.
**''Hinweis:'' Der ESP-07 hat einen 25Q80 1M flash Chip. Dieser ist für den Betrieb mit der LaCrosseGateway Firmware geeignet, für ein OTA-Update ist es jedoch zu wenig. Aus diesem Grund muss/kann dieser auf 4M flash umgebaut werden. Weitere Informationen und Details zum Umbau sind im {{Link2Forum|Topic=45594|Message=448307|LinkText=Forenthread (Gehäuse-Variante)}} beschrieben.
*[Optional] RFM69CW - Für das Senden und Empfangen funkbasierter LaCrosse Aktoren und Sensoren
*[Optional] On board Sensoren (siehe [[#Unterstützte Sensoren und Aktoren | Unterstützte Sensoren und Aktoren]])
*[Optional] SC16IS750 Zur Bereitstellung der seriellen Schnittstelle, da die GPIOs (GPIO1 / GPIO3) DEVKIT's V1.0 von FTDI verwendet werden und damit nicht genutzt werden können.
*[Optional] OLED-Display SSD1306 I2C zur Darstellung von Daten (Bootvorgang, on board Sensoren, Inhalte aus FHEM)
*[Optional] [[#MCP23008|MCP23008]] zur Bereitstellung (konfigurierbar) von digitalen 8 Ein- Ausgängen oder Sonderfunktion (OLED)
*[Optional] Nextion Touch Display zur Darstellung von verschiedenen Informationen oder zum Schalten von Aktoren.
*Steckbrett (inkl. Kabel/Widerstände)/Lochrasterplatine (Lötkolben, Lötzinn, Widerstände etc.) / [[#Platine|PeMue Platine]]

==Schaltung==
===Variante: DEVKIT 1.0 Minimum===
[[Datei:lgw_Schaltplan_Devkit_minimum.png|400px|thumb|left|Variante: DEVKIT 1.0]]
<div style="clear:both;"></div>
===Variante: DEVKIT 1.0 Maximalausbau===
[[Datei:lgw_Schaltplan_Devkit_full.png|400px|thumb|left|Variante: FTDI]]
<div style="clear:both;"></div>
===Variante: Platine (PeMue)===
siehe hier: {{Link2Forum|Topic=45594|LinkText=Thread}}
<div style="clear:both;"></div>
Siehe [[#Erweiterungsmöglichkeiten | Erweiterungsmöglichkeiten]].

===MCP23008===
I2C Adresse 0x27 -> A0,A1,A2 = 3.3V
<syntaxhighlight lang="php">
|-------\/-------|
LGW D1 |1 SCL VDD 18| LGW 3.3V
LGW D2 |2 SDA GP7 17| PB7 --/ --- GND or Output
LGW 3.3V |3 A2 GP6 16| PB6 --/ --- GND or Output
LGW 3.3V |4 A1 GP5 15| PB5 --/ --- GND or Output
LGW 3.3V |5 A0 GP4 14| PB4 --/ --- GND or Output
LGW 3.3V |6 RES GP3 13| PB3 --/ --- GND or Output
|7 NC GP2 12| PB2 --/ --- GND or Output
|8 INT GP1 11| PB1 --/ --- GND or Output
LGW GND |9 VSS GP0 10| PB0 --/ --- GND or Output
|----------------|</syntaxhighlight>

===Nextion Display===
Angeschlossen wird das Display wie folgt:
GPIO0: TXD -> Nextion RXD
GPIO2: RXD -> Nextion TXD

Das Display benötigt eine 5V Spannungsversorgung, diese kann vom VIN des DEVKIT's abgegriffen werden. Vom Betrieb mit 3.3V wird abgeraten.
Ein level shifter für RXD/TXD ist nicht nötig.

==Aufbau auf einem Steckbrett==
[[Datei:lgw_Steckbrett.png|600px|thumb|left|LaCrosseGateway Aufbau auf einem Steckbrett]]
<div style="clear:both;"></div>
'''''Hinweis:''' Der Sender und Empfänger RFM12, der auf dem Steckbrett zu sehen ist, wird nicht mehr unterstützt.''

==Platine==
PeMue (vielen Dank) hat {{Link2Forum|Topic=45594|LinkText=hier}} eine Platine (7,1cm x 5,0cm) für das LaCrosseGateway entworfen (Stand 05.2016).

===Oberseite===
[[Datei:lgw_Platine_Oberseite.jpg|400px|thumb|left|LaCrosseGateway Platine Oberseite]]
<div style="clear:both;"></div>

===Unterseite===
[[Datei:lgw_Platine_Unterseite.jpg|400px|thumb|left|LaCrosseGateway Platine Unterseite]]
<div style="clear:both;"></div>

===DEVKIT 1.0 bestückt Oberseite===
[[Datei:Lgw_Platine_Devkit_oberseite.png|400px|thumb|left|LaCrosseGateway Platine Oberseite]]
<div style="clear:both;"></div>

===DEVKIT 1.0 bestückt Unterseite===
[[Datei:lgw_Platine_Devkit_unterseite.png|400px|thumb|left|LaCrosseGateway Platine Unterseite]]
<div style="clear:both;"></div>

===ESP8266-12E bestückt Oberseite===
{| class="galleryTable noFloat"
|-
| [[Datei:lgw_Platine_ESP-12E_oberseite.png|400px|thumb|left|(1) LaCrosseGateway Platine Oberseite mit 2 x RFM69CW, BME280 und DHT22]]
| [[Datei:lgw_Platine_ESP-12E_oberseite_2.jpg|490px|thumb|left|(2) LaCrosseGateway Platine Oberseite mit 2 x RFM69CW, BME280]]
| [[Datei:lgw_Platine_ESP-12E_oberseite_2_inkl_GE.jpg.jpg|325px|thumb|left|(2) LaCrosseGateway Platine Oberseite mit 2 x RFM69CW, BME280 inkl. Gehäuse]]
|}
'''''Hinweis:''' Die Platine (Bild (1)) ist mit einem LM75 Sensor bestückt. Diese Bestückung macht zusammen mit einem BME280 keinen Sinn, es handelt sich hierbei um eine Entwicklungsplatine.''

===ESP8266-12E bestückt Unterseite===
{| class="galleryTable noFloat"
|-
| [[Datei:lgw_Platine_ESP-12E_unterseite.png|400px|thumb|left|(1) LaCrosseGateway Platine Unterseite]]
| [[Datei:lgw_Platine_ESP-12E_unterseite_2.jpg|415px|thumb|left|(2) LaCrosseGateway Platine Unterseite mit 2 x RFM69CW, BME280]]
|}

===Platine bestücken (Hinweise und Tipps)===
*Auf der Platine (Version 1.0) ist für das RFM69CW-Modul eine Markierung (zwei Quadrate) aufgedruckt, die den Chip und den Quarz symbolisieren. Wenn man den RFM69CW so drauflötet, wie abgebildet, ist er falsch rum drauf.<br />Es muss darauf geachtet werden, wo auf dem RFM69CW die "Ant" Beschriftung steht, dieser Lötpunkt muss auf die Platine an den Punkt "1" ausgerichtet werden. Zur Sicherheit bitte den [[#Variante: Platine (PeMue)|Schaltplan]] konsultieren und die genaue Position ermitteln.<br>'''Für die Platine V1.1 wurde das korrigiert.'''
*Die Antennenlänge für das RFM69CW beträgt 82 mm. Dafür möglichst eindrahtigen Leiter (aus Kupfer) verwenden.

==Erweiterungsmöglichkeiten==
Das LaCrosseGateway kann optional mit verschiedenen Komponenten erweitert werden.

Folgende Erweiterungen sind möglich:
*es kann ein eigener Prozessor (mit eigener Firmware) angeschlossen werden, der Daten empfängt und diese dem LGW übergibt.
*es kann z.B. ein NanoCUL angeschlossen werden, dessen serielle Schnittstelle transparent auf einem Port im Web bereitgestellt wird.
*es kann ein vierter und fünfter RFM69CW angeschlossen werden, diese können alles, was die bisherigen drei auch können.
*es kann ein aktiver Piezo Summer (Piezo Buzzer) angeschlossen (an GPIO7 des SC16IS750) werden, um von FHEM aus das LaCrosseGateway einen Alarm ausgeben zu lassen. Hinweis: Falls der Strom von 10mA, den die Ausgänge liefern, nicht reicht, ist noch eine Transistor-Schaltstufe vorzusehen.

Alle diese Daten stellt das LaCrosseGateway per WiFi an FHEM zu, dort wird es von den entsprechenden Modulen (LaCrosseGateway, LaCrosse, PCA301, ...) weiterverarbeitet.

Alle Komponenten werden automatisch erkannt, sofern angeschlossen.
Für die Realisierung der o.g. Möglichkeiten wird ein [http://www.aliexpress.com/item/1x-Breakout-Board-for-SC16IS750-I2C-SPI-to-UART-IC/1327351219.html?spm=2114.30010308.3.38.HxdznQ&ws_ab_test=searchweb201556_9,searchweb201602_2_10034_507_10020_10001_10002_10017_10010_10005_10011_10006_10021_10003_10004_10022_10009_10008_10018_10019,searchweb201603_6&btsid=97b30f2b-e937-426b-8202-de585dd7ee97 SC16IS750] verwendet.

Der SC16IS750 wird per I2C an das LaCrosseGateway angeschlossen und bietet eine serielle Schnittstelle und 8 Digital I/Os

'''Auf dieser Basis sind momentan folgende Erweiterungen möglich:'''

===SubProzessor===
Der SubProzessor dient dazu, dass mit einem eigenen Sketch Daten erfasst werden können, ohne sich um die ganze Nummer, die das LGW macht (WiFi, Kommunikation mit FHEM, Frontend, OTA, ...), kümmern zu müssen.
Ferner ermöglicht es die Implementierung von eigenen Projekten, dabei werden die zeitkritischen Abläufe des LGWs nicht beeinträchtig.

An die serielle Schnittstelle des SC16IS750 kann optional ein Arduino angeschlossen werden (z.B. ein Pro Mini)
Entweder ein 3.3V / 8MHz oder ein 5V / 16MHz, der aber dann auch mit 3.3V betrieben wird.

'''''Wichtig:''' Alle LaCrosseGateway Komponenten laufen ausschließlich mit '''3.3V''', aus diesem Grund dürfen keine '''5V''' Komponenten angeschlossen werden.''

'''Firmware flashen'''

Die Firmware kann über das LGW auf den SubProzessor (Voraussetzung: Arduino hat einen bootloader) geflasht werden.

Dazu wird sie auf das LGW hochgeladen (<nowiki>http://<LGW-IP>/ota/addon.hex</nowiki>).

Das LGW nimmt den Upload entgegen, wandelt das Intel-Hex in binary um und schickt es per STK500-Protokoll an den Arduino.

Falls ein OLED angeschlossen ist, wird sogar ein progress angezeigt.

'''Vorgehen Firmware flashen'''

Die Firmware kann z.B. mithilfe von "curl" mit dem nachfolgenden Befehl hochgeladen werden:
<syntaxhighlight lang="php">curl --http1.0 -H "Content_Type:multipart/form-data" -F "file=@/myFolder/LGW-Addon.ino.hex; filename=addon.hex" http://192.168.31.211/ota/addon.hex</syntaxhighlight>

'''''Hinweis:''' filename=addon.hex im Beispiel darf nicht verändert werden, nur /myFolder/LGW-Addon.ino.hex und die IP-Adresse wird entsprechend angepasst.''

Der Upload dauert etwas, danach sollte bei Erfolg vom LGW ein Protokoll zurückgeschickt kommen, das wie folgt aussieht:
<syntaxhighlight lang="php">Start receiving 'addon.hex'
File: /addon.hex Size: 21417
Starting flash
Sending sync
Enter program mode
Binary size is:7608
Leave Program Mode
Flash finished</syntaxhighlight>

Mit dem SubProzessor können die entsprechenden Daten auf zwei mögliche Arten am LGW übermittelt werden:

'''KeyValueProtokoll (KVP):'''
Format:<syntaxhighlight lang="php">KV <Type> <Address> <Key>=<Value>,<Key>=<Value>,<Key>=<Value>, ...</syntaxhighlight>
Beispiel:<syntaxhighlight lang="php">KV DHT 01 Temperature=21.5,Humidity=62</syntaxhighlight>

Das LGW übermittelt die Daten als KVP an FHEM und dort entsteht ein KVP Device, das die Daten darstellt.

'''LaCrosse:'''

Format:<syntaxhighlight lang="php">LC <Address> T=<Temperature>,H=<Humidity></syntaxhighlight>
Beispiel:
<syntaxhighlight lang="php">LC 9F T=21.5,H=62</syntaxhighlight>
<syntaxhighlight lang="php">LC 9F T=21.5</syntaxhighlight>
Das LGW setzt die Werte in das LaCrosse Protokoll um (wie z.B. ein TX29DTH) und schickt sie an FHEM.
In FHEM entsteht ein LaCrosse Device (autocreate, LaCrossePairForSec ...), als ob es ein LaCrosse Sensor wäre.

Das [https://forum.fhem.de/index.php?action=dlattach;topic=43672.0;attach=48914 LGW-Addon.ino] ist ein einfaches Beispiel, das diese Technik veranschaulicht.
Es bindet den geliebten DHT22 an und sendet ihn als LaCrosse-Sensor (über das LGW) an FHEM und es misst die Spannung und sendet sie zusammen mit der UpTime des SubProzessors als KVP

Der umrandete Bereich [[#Addon Schaltung |Schaltung - "Example"]] "Example" ist das zu [https://forum.fhem.de/index.php?action=dlattach;topic=43672.0;attach=48914 LGW-Addon.ino] passende Beispiel.

==Unterstützte Sensoren und Aktoren==
Alle Sensoren und Aktoren, die auch vom "LaCrosse Arduino" Sketch unterstützt werden.<br />
(siehe [[JeeLink#Unterst.C3.BCtzte_Sensoren_und_Aktoren_incl._Wetterstation_WS_1600JeeLink|vom JeeLink unterstützte LaCrosse Sensoren und Aktoren]])

Zusätzlich zu LaCrosse werden auch die folgenden Geräte unterstützt:
{| class="wikitable"
!Bezeichnung !! Datenrate !! Sonstiges !! Funktion !! Hinweise
|-
| PCA301 ||868950 kHz (868,970 und 868,990 ) 6.631 kbps || extern || Energiemess-Steckdose (Unterstützt werden bis zu 50 Dosen) ||
|-
| EC3000 ||868.300 kHz mit 20.000 kbps|| extern || Energiemess-Steckdose ||
|-
| RFM69CW || || on board || Zum Empfangen und Senden von Sensor/Aktor Daten || Hinweise DHT22 beachten.
|-
| BME280 || || on board || Temperatur, Feuchte und Druck || Falls das verwendete Breakout bereits PullUp-Widerstände für SDA und SCL enthält, sind diese nicht mehr zusätzlich nötig.
|-
| BMP180 || || on board || Temperatur und Druck || Falls das verwendete Breakout bereits PullUp-Widerstände für SDA und SCL enthält, sind diese nicht mehr zusätzlich nötig.
|-
| LM75 || || on board|| Temperatur ||
|-
| DHT22 || ||on board|| Temperatur und Feuchte || Kann anstatt RFM69 Radio#3 eingesetzt werden.
|-
| SC16IS750 || I2C Adresse: 0x90 ||on board || OI Erweiterung ||
|-
| OLED SSD1306|| I2C Adresse: 0x3C || on board || OLED Display||
|-
| MCP23008|| I2C Adresse: 0x27 || on board || Input/Output Port Expander||
|-
| Piezo Summer |||| on board ||Piezo Buzzer||
|-
| Nextion Display ||(Max.) 57600 baud || on board ||Touch Display||

|}

Alle direkt am LGW anschließbaren Sensoren werden automatisch erkannt, wenn sie vorhanden sind.

<u>Sie werden in folgender Reihenfolge verwendet:</u>

Wenn ein BME280 vorhanden ist, wird dieser verwendet und sonst nichts, da man dann bereits Temperatur, Feuchte und Druck hat.

Ist kein BME280 vorhanden, wird geschaut, ob ein BMP180 vorhanden ist. Falls ja, haben wir Druck und Temperatur.

Dann wird geschaut, ob ein DHT22 vorhanden ist. Wenn ja, wird er zusätzlich verwendet, aber vom BMP180 dann nur noch der Druck.

Temperatur und Feuchte vom DHT22, dass dieses Wertepaar von einem Sensor stammt.

Wenn kein BMP180 und kein BME180 da ist, sondern nur ein DHT22, dann hat man Temperatur und Feuchte.

Wenn nichts vorhanden ist (also keiner der bisher genannten Sensoren), wird, falls vorhanden, der LM75 verwendet.

=Software=

== Release Notes ==
*[https://forum.fhem.de/index.php/topic,43672.0.html LaCrosseGateway Release Notes im Forum]

==Funktionsumfang==
*Access Point für die Konfiguration
*Konfiguration über WEB-Frontend (Erreichbar per ''<nowiki>http://IP-Adresse oder Hostname/setup</nowiki>'' auf Port 80 )
**SSID und Password (Die Konfiguration wird im EEPROM gespeichert und bei zukünftigen Neustarts verwendet.)
**Statische IP-Adresse anstatt DHCP
**Hostname
*Vom LaCrosseGateway FHEM-Modul über IP-Adresse:Port oder Hostname:Port ansprechbar. Der Port ist konfigurierbar.
*Unterstützt bis zu 5 x RFM69CW (Keine Unterstützung für RFM12)
*On board und externe Sensoren und Aktoren ([[#Unterstützte Sensoren und Aktoren |Unterstützte Sensoren und Aktoren]])
*Betrieb nur per USB möglich, als ob es ein JeeLink wäre
*FHEM Anbindung
*Log im Web-Frontend
*Firmware OTA-Update (Firmware-Over-the-Air-Update per FHEM)
*Erweiterungsmöglichkeiten per SC16IS750 (Für Buzzer und für weitere zwei RFM69)
*SubProzessor (An die serielle Schnittstelle des SC16IS750 kann optional ein Arduino angeschlossen werden (z.B. ein Pro Mini))
*Serial bridge (Optional kann die serielle Schnittstelle des SC16IS750 transparent auf einem TCP Port bereitgestellt werden)
*Software Serial Bridge - Stellt die Soft Serial Schnittstelle transparent auf einem TCP Port bereit.

==Sourcecode==
Der Quellcode des LaCrosse Gateways befindet sich [https://svn.fhem.de/trac/export/HEAD/trunk/fhem/contrib/arduino/36_LaCrosseGateway.zip im FHEM SVN Repository (contrib)].

==Firmware Download==
Die [https://svn.fhem.de/trac/export/HEAD/trunk/fhem/FHEM/firmware/JeeLink_LaCrosseGateway.bin Firmware] befindet sich im [https://svn.fhem.de/trac/browser/trunk/fhem FHEM SVN Repository] und wird per FHEM Update verteilt. Neue Version der [https://svn.fhem.de/trac/export/HEAD/trunk/fhem/FHEM/firmware/JeeLink_LaCrosseGateway.bin Firmware] wird im {{Link2Forum|Topic=43672|LinkText=FHEM Forum "LaCrosse Gateway"}} angekündigt und der Funktionsumfang bzw. die Änderungen beschrieben.

Nach einem FHEM-Update alternativ auch: ''<FHEM-Installations-Verzeichnis>/FHEM/firmware/JeeLink_LaCrosseGateway.bin''

==Firmware aufspielen==
Wie bei einem JeeLink muss auch für das LaCrosseGateway die Firmware aufgespielt werden.

Das [https://raw.githubusercontent.com/nodemcu/nodemcu-devkit-v1.0/master/Documents/NodeMCU_DEVKIT_1.0.jpg NodeMCU DEVKIT 1.0] hat eine CP2102 UART Bridge implementiert, dafür muss ein CP2102 Treiber installiert sein.

Bei einem ESP8266-12E Modul kann die Firmware mithilfe eines Seriell-USB-Konverters aufgespielt werden.

===Windows/Mac/Linux per "esptool"===
Verifiziert und getestet wurde dieses Vorgehen auf Windows (Windows 10), Mac (El Capitan):

1) Das [https://github.com/igrr/esptool-ck/releases esptool 0.4.6] für die entsprechende Plattform herunterladen.

2) Zum Aufspielen der Firmware muss ein Befehl mit der folgenden Syntax ausgeführt werden:
<syntaxhighlight lang="php">
esptool -vv -cp [Port] -cb 921600 -ca 0x00000 -cd nodemcu -cf [Pfad zur Firmware (bin-File)]</syntaxhighlight>
'''[Port]''' und '''[Pfad zur Firmware (bin-File)]''' müssen angepasst werden.

''Beispiel (Mac/Linux):''

<syntaxhighlight lang="php">esptool -vv -cp /dev/tty.SLAB_USBtoUART -cb 921600 -ca 0x00000 -cd nodemcu -cf JeeLink_LaCrosseGateway.bin</syntaxhighlight>

'''''Hinweis:''' Das esptool ist nicht sonderlich stabil. Es kommt vor, dass es manchmal den Upload nicht startet oder nicht durchbekommt. In diesem Fall hilft es den Vorgang, auch mehrmals, zu wiederholen.''

=== Linux/Debian/Ubuntu "esptool v2.1"===

Installieren:
<syntaxhighlight lang="bash">
sudo apt-get esptool
</syntaxhighlight>

''Beispiel mit neuer Syntax bei esptool v2.1:''
<syntaxhighlight lang="bash"> sudo esptool --port /dev/ttyUSB0 write_flash 0x00000 JeeLink_LaCrosseGateway.bin</syntaxhighlight>

===Windows per "nodemcu-flasher"===

1) [https://github.com/nodemcu/nodemcu-flasher/raw/master/Win32/Release/ESP8266Flasher.exe Espressif Flashtool] downloaden und entpacken:

2) [https://svn.fhem.de/trac/export/HEAD/trunk/fhem/FHEM/firmware/JeeLink_LaCrosseGateway.bin Firmware] downloaden

3) FlashTool starten und wie folgt einstellen:

{| class="galleryTable noFloat"
|-
| [[Datei:nodemcu-flasher_1.png|450px|thumb|left|Firmware auswählen]]
| [[Datei:nodemcu-flasher_2.png|450px|thumb|left|Flash Parameter (Advanced Tab) wie abgebildet einstellen]]
|}

4) COM-Port auswählen und den Flashvorgang starten (Button: '''Flash(F)''') ...
[[Datei:nodemcu-flasher_3.png|450px|thumb|left|COM Port auswählen und das "Flashen" initiieren]]
<div style="clear:both;"></div>

Nach dem Flashen sollte über die serielle Ausgabe (57600 Baud) des ESP der Start und das Öffnen des AccessPoints zu sehen sein.

'''''Hinweis:''' Die Geschwindigkeit von 921600 baud ist nicht auf jedem Rechner (besonders auf virtualisierten Systemen) machbar. In diesem Fall die Baudrate auf 57600 reduzieren.''

==Funktionsweise==
Während des Startvorgangs versucht sich das LaCrosseGateway in einem WLAN anzumelden. Dazu muss es eine SSID und das entsprechende Passwort kennen.

Beim ersten Start (nach dem initialen Aufspielen der Firmware) sind diese Informationen noch unbekannt. Aus diesem Grund wird folgende Strategie verfolgt:

Wenn es sich in keinem WLAN anmelden kann, dann öffnet es einen Access Point mit der SSID "LaCrosseGateway_'''xxxxxx'''", wobei '''xxxxxx''' die eindeutige Chip-ID des ESP8266 ist.

Der Access Point wird aus Sicherheitsgründen nach 15 Minuten wieder geschlossen.
Innerhalb dieser 15 Minuten kann man sich mit dem Access Point verbinden. Der Access Point vergibt (per DHCP) IP-Adressen aus dem Netzwerk 192.168.222.0. Anschließend kann über die LaCrosseGateway Konfigurationsseite [http://192.168.222.1/setup http://192.168.222.1/setup] die initiale Konfiguration vorgenommen werden.
Die Konfiguration wird im EEPROM gespeichert und bei zukünftigen Neustarts verwendet.
Die Konfigurationsseite ist auch im "Normalbetrieb" (ohne Access Point) über die Adresse http://''seine aktuelle IP-Adresse''/setup erreichbar.

Wenn sich das LaCrosseGateway an dem konfigurierten WLAN anmelden konnte (es wartet max. 30 Sekunden auf einen connect) und von diesem per DHCP eine IP-Adresse erhalten hat, dann stellt es auf dieser Adresse den Port 81 zur Verfügung, über den in FHEM das LaCrosseGateway Modul senden und empfangen kann.

'''Optische Darstellung der Initialisierung'''

Beim Start und der Initialisierung wird mit der Board-eigenen LED signalisiert, was gerade passiert:
*5 schnelle Blinks direkt nach dem Start, als Zeichen, dass ein Reset stattgefunden hat
*Blinken im Sekundentakt, während versucht wird, sich mit einem WLAN zu verbinden
*LED aus, wenn der Connect zu einem WLAN geklappt hat und dann vereinzeltes Blinken, wenn Daten an FHEM übermittelt werden

== LaCrosseGateway einrichten ==
Für die Ersteinrichtung des LaCrosseGateways werden die SSID und das Passwort des WLAN-Routers benötigt. Ferner wird empfohlen auf dem WLAN-Router bzw. dem DHCP-Server eine IP-Adresse für das LaCrosseGateway zu reservieren. Für die Reservierung wird die MAC-Adresse des LaCrosseGateways benötigt, diese kann über die "Home"-Page des LaCrosseGateways ermittelt, alternativ von dem [[#Windows per "nodemcu-flasher" |NODEMCU Firmware Programmer]] (''Reiter "Operation -> "STA MAC"'') entnommen werden.

Sofern diese Vorbereitungen getroffen wurden und alle Informationen vorliegen, kann das LaCrosseGateway eingerichtet werden.

'''''<u>Für die Konfiguration sind folgende Schritte nötig:</u>'''''
*Mit dem LaCrosseGateway Access Point "LaCrosseGateway_xxxxxx" verbinden (siehe [[#Funktionsweise |Beschreibung Funktionsweise]])
*Mithilfe eines Browsers die [http://192.168.222.1/setup LaCrosseGateway "Setup"-Page] öffnen
*SSID und das Password eintragen. Man kann zwei SSID/Passwort-Kombinationen mit jeweils einem Timeout konfigurieren. 120 bedeutet z.B. dass das LGW 120 Sekunden lang versucht, die SSID zu erreichen. Falls die erste SSID nach "Timeout" Sekunden nicht erreicht wurde, wird Timeout Sekunden lang versucht, die zweite SSID zu connecten.
*''[Empfohlen]'' Das Frontend Passwort festlegen
*''[Optional]'' Falls kein DHCP-Server zur Verfügung steht bzw. keine Reservierung erwünscht ist, dann muss die IP-Adresse / Netmask (Optional auch Gateway) eingetragen werden
*''[Empfohlen]'' Hostnamen festlegen bzw. anpassen
*Alle Angaben mit dem Button "save and restart" bestätigen. Dabei werden die vorgenommenen Einstellungen im EEPROM gespeichert und ein Neustart des LaCrosseGateways initiiert.

Nach dem Neustart verbindet sich das LaCrosseGateway mit dem WLAN-Router.

Anschließend kann mit der [[#Hinweise zum Betrieb mit FHEM |Inbetriebnahme in FHEM]] fortgefahren werden.

==Firmware aktualisieren==

Nachfolgend werden, neben der unter dem Punkt [[#Firmware aufspielen |Firmware aufspielen]] beschriebenen Möglichkeiten, weitere Möglichkeiten zur Aktualisierung der LaCrosseGateway [[LaCrosseGateway#Firmware Download|Firmware]] aufgezeigt.

Hinweis: Die Einstellungen des LaCrosseGateway werden dabei nicht gelöscht.

=== Per FHEM (OTA-Update)===
Voraussetzungen:

*Das LGW muss auf der IP-Adresse, die im LaCrosseGateway Modul definiert ist, erreichbar sein
*Es wird kein avrdude benötigt
*Das Attribut "flashCommand" spielt keine Rolle

Die LaCrosseGateway Firmware kann vom LaCrosseGateway Device (LaCrosseGateway Modul) aus mit
<syntaxhighlight lang="php">set myLaCrosseGateway flash</syntaxhighlight> aktualisiert werden.
'''''myLaCrosseGateway''' muss bei Bedarf auf den Gerätenamen in FHEM angepasst werden.''

'''''Hinweis:''' Das Update dauert ca. 30 Sekunden.''

=== Per FHEM (USB)===
Voraussetzungen:
Auf dem FHEM-Server muss Python und pyserial installiert sein. Die Installation kann z.B. so erfolgen:
*apt-get install python
*wget https://bootstrap.pypa.io/get-pip.py
*python get-pip.py
*pip install pyserial

Das Attribut "mode" muss auf USB gesetzt sein: attr myLaCrosseGateway mode USB

Der flash-Vorgang wird gestartet mit: set myLaCrosseGateway flash

=== Per CURL ===
Voraussetzungen:
*[https://curl.haxx.se/download.html curl-Tool] installiert

'''''Beispiel:'''''
<syntaxhighlight lang="php">curl --http1.0 -# -o ~output.txt -H "Content_Type:multipart/form-data" -F "file=@.\JeeLink_LaCrosseGateway.bin; filename=firmware.bin" http://192.168.31.211/ota/firmware.bin</syntaxhighlight>

'''Firmwaredateiname (file=)''' und die '''IP-Adresse''' muss entsprechend angepasst werden.

=== Per WEB OTA-Update (deprecated)===

'''''deprecated'''''

==LaCrosseGateway Web-Frontend==
===Status-Wert RSSI===
Die WiFi Signalstärke (dBm) (-36 ist besser als -60)

===Status-Wert FramesPerMinute===
Dieser gibt an, wie viele frames von Sensoren in der letzten Minute erfolgreich empfangen, dekodiert und verarbeitet wurden.
Es eignet sich zur Überwachung, wenn weniger als ein Grenzwert empfangen wurde, dann kann ein Alarm (Benachrichtigung, Restart etc.) ausgelöst werden.

===Status-Wert ReceivedFrames===
Dieser Wert gibt an, wie viele seit dem Start des LGW empfangen wurden.

===WiFi "Startup-delay"===

Mit diesem Konfigurationsparameter kann eine Verzögerung (in Sekunden) definiert werden, bis das LGW nach einem Neustart einen ersten Verbindungsversuch zum WiFi Access Point (Router: Fritzbox etc.) startet.

Eine Anpassung kann für den folgenden Fall sinnvoll sein:

Nach einem Stromausfall benötigt ein WiFi Access Point (Router: Fritzbox etc.) in den meisten Fällen länger zum Starten als das LGW. In der default Einstellung führt das dazu, dass der LGW nach dem Starten versucht 30 Sekunden lang eine Verbindung zum AP herzustellen. Wenn keine Verbindung innerhalb dieser Zeit zustande kommt, dann gibt das LGW auf und macht seinen eigenen AP auf. Mit einer entsprechenden Verzögerung (Dauer bis der Router gestartet ist und der WiFi-AP zur Verfügung steht) kann sichergestellt werden, dass der AP gestartet ist und sich das LGW mit dem AP verbinden kann.

===Internal Sensors "Sensor-ID"===
Bei Einsatz von mehr als einem LaCrosseGateway, muss die LaCrosse-ID, mit der die internen Sensoren des Gateways übermittelt werden, angepasst werden.
Hierbei ist darauf zu achten, dass die LaCrosse-ID nur einmal auf einer FHEM Instanz vorkommen darf. Die ID kann entweder Dezimal (211) oder Hex (0xD3) angegeben werden.

'''''Detailinformationen:''''' Wenn ein LGW interne Sensoren hat (BME280, BMP180, DHT22, ...) dann sendet es die Daten des Sensors so, als ob es eine Wetterstation wäre (WS 1600 Format) an das LGW. Bisher hat es dafür die Sensor-ID 0 verwendet. Wenn man mehrere LGWs an einem FHEM angebunden hat, dann mischen sich deren Sensor-Daten auf dem LaCrosse device mit der ID 0. Um das zu vermeiden, kann man nun konfigurieren, mit welcher Sensor-ID die internen Sensoren gesendet werden sollen und die beiden LGWs unterschiedlich konfigurieren.

Die Anpassung der LaCrosse-ID hat keinerlei Einfluss auf die Daten, die von den Radios empfangen werden.

===Internal Sensors "Altitude"===
Mit diesen Parameter kann die Höhe über NN konfiguriert werden.

===Internal Sensors "Temperature-/Humidity-correction"===
Für Temperatur und Feuchte kann ein Korrekturwert angegeben werden.

Der Wert kann entweder ein Offset oder prozentual sein.

'''Beispiele:'''

{| class="wikitable" style="margin-left: auto; margin-left: 0px;"
! Korrekturwert !! Gemessen !! Ergebnis
|-
| -5
| 20°C
| 15°C
|-
| +3
| 20°C
| 23°C
|-
| -10%
| 20°C
| 18°C
|-
| +20%
| 20°C
| 24°C
|}

===SC16IS750-Clone===
Wenn aktiviert, wird die I2C clock auf 100 kHz runtergenommen und
es wird an einigen Stellen etwas auf die Bremse getreten, dass ein SC16IS70-Clone, der langsamer
als echte Hardware ist, mitkommt.
Sollte man ohne zwingenden Grund nicht aktivieren.

===Use MDNS===
Legt fest, ob das LGW seine IP-Adresse per MDNS bekannt gibt. Dies ist nötig, wenn man einen Mac hat oder bei Windows einen Bonjour-Service laufen hat.
Dies ist beim Entwickeln sinnvoll, kann üblicherweise ausgeschaltet bleiben.

===MCP23008===
Konfigurationsmöglichkeit für die 8 IO Pins (siehe auch [[#Inbetriebnahme_von_MCP23008|Inbetriebnahme von MCP23008]]).

===Serial bridge port und bridge baud===
Das LGW kann nun optional die serielle Schnittstelle des SC16IS750 transparent auf einem TCP Port bereitstellen.
Dazu gibt es die "Serial bridge port" und "Serial bridge baud" auf der "config"-Page des LGWs.
Das LGW überträgt transparent die Daten der seriellen Schnittstelle an FHEM und umgekehrt.

===Soft Serial Bridge===
Das LGW kann optional eine Soft serial bridge (zuverlässig nur mit bis zu 57600 Baud) transparent auf einem TCP Port bereitstellen.
Folgende Parameter können auf der LGW Setup-Page angepasst/konfiguriert werden:

{| class="wikitable" style="margin-left: auto; margin-left: 0px;"
! Parameter !! Beschreibung
|-
| Port
| Der Port, auf dem es angesprochen werden kann
|-
| Baud
| Die Baudrate für die Kommunikation
|-
| Nextion display
| Für den Betrieb eines Nextion Display muss diese Option aktiviert sein.
|-
| Add units
| Fügt an die Werte (Temp,Hum,Pres), die das LGW an das Display schickt, Einheiten an.
|}

Mithilfe des Soft serial bridge können verschiedene Geräte (nanoCUL, Nextion Display, etc.), welche per serieller Schnittstelle kommunizieren können, in Betrieb genommen werden.

===Statuswerte abrufen===
Mit http://<IP-des-LGW>/state können die Statuswerte, die das LGW-Frontend anzeigt, als XML zur Weiterverarbeitung abgerufen werden.

Beispiel:
<syntaxhighlight lang="php"><LGW>
<Info Key="UpTimeSeconds" Value="107086"/>
<Info Key="UpTimeText" Value="1Tg. 5Std. 44Min. 46Sek. "/>
<Info Key="WIFI" Value="NeverTellThem"/>
<Info Key="MacAddress" Value="18:FE:34:9A:6D:48"/>
<Info Key="ChipID" Value="10120520"/>
<Info Key="ReceivedFrames" Value="93593"/>
<Info Key="FramesPerMinute" Value="52"/>
</LGW></syntaxhighlight>

===Funktionsweise Log===
Das Log ist als Hilfsmittel bei der Fehlersuche gedacht z.B. um bei PCA301 zu verfolgen, wann wer was wie fragt und antwortet oder um zu schauen, ob irgendwelche Sensoren überhaupt empfangen werden und die Daten an FHEM geliefert werden.

[[Datei:lgw_LogPage.png|600px|thumb|left|LaCrosseGateway Log ebfrontend]]
<div style="clear:both;"></div>
Mit "Command" kann man Befehle an das LGW senden. Sie entsprechen dem, was man mit "set myLaCrosseGateway raw ..." aus FHEM schicken kann.
Die obere Liste enthält die Daten, die an FHEM übermittelt werden (bzw. würden, wenn sich ein FHEM auf das LGW verbunden hat)
Die untere Liste enthält debug-Informationen u.a. wird hier der letzte Systemstart aufgezeichnet.
Die verwendete SDK-Version und der letzte Reset-Grund werden ebenfalls ausgegeben

Das Log kann per HTTP abgerufen werden:
<syntaxhighlight lang="php">http://<LGW-IP>/getLogData</syntaxhighlight>

'''''Beispiel:'''''
<syntaxhighlight lang="php">http://192.168.31.211/getLogData</syntaxhighlight>

das Ergebnis sieht wie folgt aus:
<syntaxhighlight lang="php">DATA:OK 22 117 196 0 58 226 102 0 58 191 86 0 0 40 172 0 105 1 101 3 0 [75 C4 E2 66 00 00 BF 56 00 00 00 02 3B FC DC 00 69 01 65 4A A4 C4 F9 F2 4F 11 A4 F6 7C 03 A0 00 00 00 00 03 A0 38 09 21 27]
DATA:OK 9 11 130 4 173 125 [92 D5 97 7D 75]
DATA:OK EMT7110 84 81 8 207 0 36 0 1 1 199 1 [25 6A 54 51 40 02 00 24 C3 41 C7 9B]
SYS: AddOn: KV ADDON 01 Voltage=3.33,UpTime=4921
DATA:OK VALUES ADDON 01 Voltage=3.33,UpTime=4921
DATA:OK 9 38 1 4 67 65 [99 84 91 41 07]
DATA:OK 22 126 67 0 65 236 34 0 65 231 116 0 0 32 103 0 48 0 134 1 0 [7E 43 EC 22 00 00 E7 74 00 00 00 01 C7 AC D7 00 30 00 86 00 57 E4 69 1E 46 8E D4 68 C7 04 10 00 00 00 00 04 10 18 0A DC F7]
DATA:OK 9 36 1 4 128 61 [99 05 52 3D 96]
DATA:OK WS 0 4 4 185 255 255 255 255 255 255 255 255 255 0 3 252</syntaxhighlight>

'''''DATA:''''' für die obere Liste

'''''SYS: ''''' für die untere Liste

Bei jedem Aufruf werden die seit dem letzten Abruf neu aufgelaufenen Logeinträge geliefert.
Intern werden maximal 40 Einträge gepuffert (aber kein Ringpuffer, weil die ersten 40 mit dem Bootlog erhalten bleiben müssen)

'''''Hinweis:''''' Aus Performance- und Stabilitätsgründen sollten die Daten nicht zu häufig und nicht von zwei Instanzen gleichzeitig abgerufen werden.

=Hinweise zum Betrieb mit FHEM=

==Voraussetzungen==
Es wird ein [[#LaCrosseGateway einrichten |vorkonfiguriertes]] LaCrosseGateway vorausgesetzt.

Perl Modul: ''LWP::UserAgent'' - Dieses wird für das Firmware Update per FHEM LaCrosseGateway Modul benötigt.
Auf einem Raspberry Pi kann die Installation wie folgt durchgeführt werden:
<syntaxhighlight lang="php">sudo apt-get install libwww-perl</syntaxhighlight>
alternativ auch mit
<syntaxhighlight lang="php">sudo cpan LWP::UserAgent</syntaxhighlight>

'''FHEM Module'''

'''Hinweis:''' Ursprünglich wurde für das LaCrosseGateway das FHEM-Modul 36_JeeLink.pm verwendet. Da es aber inzwischen erhebliche Unterschiede zwischen dem JeeLink-LaCrosse-Sketch und dem LaCrosseGateway gibt, existiert seit Mitte November 2016 ein für das LaCrosseGateway spezialisiertes und optimiertes FHEM-Modul, das 36_LaCrosseGateway.pm.<br>
Dieses sollte anstatt dem 36_JeeLink.pm vorzugsweise verwendet werden.

''36_LaCrosseGateway.pm'' (wird per FHEM Update verteilt)

''36_KeyValueProtocol.pm'' (wird per FHEM Update verteilt)

''36_LaCrosse.pm'' (wird per FHEM Update verteilt)

''36_PCA301.pm'' (wird per FHEM Update verteilt)

''36_EC3000.pm'' (wird per FHEM Update verteilt)

''36_EMT7110.pm'' (wird per FHEM Update verteilt)

''36_Level.pm'' (wird per FHEM Update verteilt)

''42_Nextion.pm'' (wird per FHEM Update verteilt)

==Device Definition==
===WLAN===
Die Definition sieht dann wie folgt aus:

<code>define <myLaCrosseGateway> LaCrosseGateway <IP-Adresse>:81</code>

''<myLaCrosseGateway>'' kann bei Bedarf angepasst werden.

''<IP-Adresse>'' muss entsprechend angepasst werden. Anstatt der IP-Adresse kann auch der Hostname vom LaCrosseGateway verwendet werden.

'''Beispiel:'''
<syntaxhighlight lang="php">define myLaCrosseGateway LaCrosseGateway 192.168.22.33:81</syntaxhighlight>
<u>IP-Adresse ermitteln:</u> Das LaCrosseGateway heist per default Einstellung "''LaCrosseGateway''", per ping auf den Hostnamen ''LaCrosseGateway'' kann die <IP-Adresse> ermittelt werden.

===USB===
Wenn man das LGW über USB betreiben will, dann möchte man üblicherweise kein WiFi.
Um das WiFi zu deaktivieren gibt es zwei Möglichkeiten:<br>
1.) Man kann mit einem 10k pullup auf 3.3V an MOSI == GPIO13 == D7 "jumpern", dass man kein WiFi will. Wenn vorhanden, wird WiFi sofort beim Start deaktiviert.<br>
2.) Man kann WiFi auf der Setup-Page des LGW deaktivieren.<br>

Für den Betrieb via USB sieht die Definition wie folgt aus:

<code>define <myLaCrosseGateway> LaCrosseGateway <USB-Port>@57600</code>

''<myLaCrosseGateway>'' kann bei Bedarf angepasst werden.

''<USB-Port>'' muss entsprechend angepasst werden.

Beispiel: <code>define myLaCrosseGateway LaCrosseGateway /dev/ttyUSB0@57600</code>
''/dev/ttyUSB0'' Falls bereits mehrere USB Geräte angeschlossen sind muss der USB Port angepasst werden.

'''Hinweis:''' Sind mehrere USB Devices am FHEM Server (z.B. RPI, Cubietruck etc.) in Betrieb, dann ist die Zuordnung über den USB-Port nicht zuverlässig. Die Ports werden u.a. in der Reihenfolge vergeben, in der die Geräte angeschlossen werden. Zuverlässiger und eindeutiger ist die Zuordnung über die Serial-ID.

Dieser Befehl zeigt die Serial-ID der angeschlossenen USB-Devices an:
<code>ls -l /dev/serial/by-id</code>

Beispiel für die Ausgabe:
<syntaxhighlight lang="text">lrwxrwxrwx 1 root root 13 Mai 14 10:37 usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0 -> ../../ttyUSB1
lrwxrwxrwx 1 root root 13 Mai 30 11:27 usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0 -> ../../ttyUSB2
lrwxrwxrwx 1 root root 13 Apr 16 14:52 usb-Silicon_Labs_ELV_USB-Modul_UM2102_EVFSRFF8COEXIKOT-if00-port0 -> ../../ttyUSB0</syntaxhighlight>
In diesem Fall ist u.a. ein DEVKIT 1.0 mit der Serial-ID ''usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0 -> ../../ttyUSB2'' angeschlossen.

Auf Basis dieser Informationen lässt sich folgende Definition erstellen:

<code>define myLaCrosseGateway LaCrosseGateway /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0@57600</code><br>
Wichtig ist es, die Übertragungsrate von 57600 bit/s anzugeben.<br><br>

Wenn man das LGW ohne WiFi betreibt, dann muss man natürlich auf die Annehmlichkeiten des Web-Frontends verzichten.<br>
In diesem Fall kann man die Konfiguration, die man über das Web-Frontend machen würde, über die serielle Schnittstelle machen.<br>

<code>set myLaCrosseGateway raw "SETUP ..."</code><br>
Das ... sind die gewünschten Einstellungen. Es müssen nicht alle Einstellungen gesendet werden sondern nur die, die man setzen will.<br>
Es werden nur die Einstellungen gesetzt und im EEPROM gespeichert, es wird aber kein Reboot ausgelöst<br>
Einen Reboot kann man mit "set myLaCrosseGateway raw 8377e" auslösen.<br>
Mehrere Einstellungen können durch Semikolon getrennt angegeben werden.<br>
Beispiel:
<code>set myJeeLink213 raw "SETUP UseWiFi false; IO0 OLED mode=thp; IO1 OLED Off; CorrT -2.5; ISID 213"</code>

Man kann auf der seriellen Schnittstelle die aktuellen Einstellungen abrufen.
Das command ist 1g<br>
<code>set myLaCrosseGateway raw 1g</code><br>
Man bekommt dann so etwas zurück:
<syntaxhighlight lang="text">SETUP ctSSID esesidee; ctPASS PasstWort; staticIP 192.168.31.211; staticMask 255.255.255.0; staticGW 192.168.31.1;
HostName LGW211; StartupDelay 1; ISID 0xD3; Altitude 220; CorrT 0; CorrH 0; DataPort1 81; DataPort2 82; SerialBridgePort 85;
SerialBridgeBaud 38400; UseMDNS true; IO0 OLED mode=s; IO1 OLED mode=thp; IO2 OLED On; IO3 OLED Off; oledStart 120; KVInterval 10;
KVIdentity 211; PCA301Plugs 036180=3,03A094=1,035FF1=6;</syntaxhighlight>

==Reconnect==
Falls das LaCrosseGateway nicht erreichbar ist (Kein Strom/Stromausfall, WLAN Verbindung unterbrochen etc.), bricht das LaCrosseGateway Device die Kommunikation ab. Über das entsprechende ''timeout'' Attribut kann das LaCrosseGateway device so konfigurert werden, dass es in regelmässigen Abständen erneut versucht eine Verbindung mit dem LaCrosseGateway herzustellen.

Konfigurationsempfehlung für ''timeout'' = 120 Sekunden und ''checkInterval'' = 30 Sekunden:

Der Wert kann in FHEM wie folgt gesetzt werden:
<syntaxhighlight lang="php">attr myLaCrosseGateway timeout 120,30</syntaxhighlight>
'''''myLaCrosseGateway''' muss auf den Gerätenamen in FHEM angepasst werden.''

Während das LaCrosseGateway eine WiFi-Verbindung aufbaut, benötigt das LaCrosseGateway-Modul je nach Konfiguration einige Zeit bis es einen neuen Connect auf den Datenport des LaCrosseGateway versucht. Das Finden der optimalen Werte erfordert etwas Geduld, es kann auch schon mal ein, zwei Minuten dauern, bis die ersten Daten in FHEM übertragen werden.

'''''Erklärung der Timeout Werte:'''''
120,30 prüft alle 30 Sekunden, ob seit mindestens 120 Sekunden keine Daten mehr übermittelt wurden und falls dem so ist, macht es einen Reset auf der Schnittstelle, was die Verbindung zum LaCrosseGateway neu aufbaut. Das bedeutet, in so einem Fall ist die Verbindung nach spätestens 150 Sekunden wieder hergestellt.

'''''Hinweis:''' Mit diesem Attribut wird lediglich eine neue Verbindung aufgebaut, dabei wird das LaCrosseGateway nicht resetet.''

==Liste aller initCommands==
Eine aktuelle Liste der initCommands, die man von FHEM, Terminalprogramm oder Web-Frontend aus senden kann, sind auf dem Web-Frontend "Help"-Page des LaCrosseGateways (ab V1.17) aufgeführt.

[http://IP-Adresse/setup http://IP-Adresse oder Hostname/help]

<syntaxhighlight lang="php">
<n>a set to 0 if the blue LED bothers
<n>c use one of the possible data rates (for transmit on RFM #1)
<n>d set to 1 to see debug messages
<8266>e Clear EEPROM
<n>f initial frequency in kHz (5 kHz steps, 860480 ... 879515)
<n>g get information (1g: get current settings)
<n>h Altitude
<n,f,i>i Init PCA for Radio #<n> to <m>MHz and <i>s Interval
<n>m bits 1: 17.241 kbps, 2 : 9.579 kbps, 4 : 8.842 kbps, 8 : 20.000 kbps (for RFM #1)
<n>M bits 1: 17.241 kbps, 2 : 9.579 kbps, 4 : 8.842 kbps, 8 : 20.000 kbps (for RFM #2)
<n>#<x>m bits 1: 17.241 kbps, 2 : 9.579 kbps, 4 : 8.842 kbps, 8 : 20.000 kbps (for RFM #x)
<n>o set HF-parameter e.g. 1,4o for RFM69
<n>p payload on the serial port (1: all, 2: only undecoded data)
<n>r use one of the possible data rates (for RFM #1)
<n>R use one of the possible data rates (for RFM #2)
<n>#<x>r use one of the possible data rates (for RFM #x)
<x,x,...>s Send to PCA301 (must be 10 byte)
<x,x,...>S Send to CustomSensor
<n>t 0=no toggle, else interval in seconds (for RFM #1)
<n>T 0=no toggle, else interval in seconds (for RFM #2)
<n>#<x>t 0=no toggle, else interval in seconds (for RFM #x)
v show version
<n>w 0=no wifi
<n>z set to 1 to display analyzed frame data instead of the normal data
</syntaxhighlight>

==LaCrosseGateway zurücksetzen==
Das LaCrosseGateway kann auf die "Werkseinstellungen" zurückgesetzt werden.<br>
Dadurch werden alle auf der Setup-Page gemachten und im EEPROM gespeicherten Einstellungen verworfen.
Der Befehl dazu lautet: <syntaxhighlight lang="php">8266e</syntaxhighlight>
Er kann mit einem Terminalprogramm, von FHEM aus mit <syntaxhighlight lang="php">set <myLaCrosseGateway> raw 8266e</syntaxhighlight> oder von der Log-Page des LGW gesendet werden.

Danach startet das LGW wieder als Access Point [[#LaCrosseGateway einrichten|initiale Konfiguration]] und die Konfiguration kann über die "Setup-Page" neu vorgenommen werden kann.

==Sensoren/Aktoren anlegen==

Voraussetzung: die [http://fhem.de/commandref.html#autocreate FHEM autocreate Funktion] ist aktiv.

Die erkannten Sensoren und Aktoren werden automatisch erkannt und in FHEM angelegt, sobald Daten empfangen werden.

Empfangene Sensoren werden nur hinzugefügt werden, wenn LaCrossePairForSec auf 120 Sekunden gesetzt wird.
<syntaxhighlight lang="php">set myLaCrosseGateway LaCrossePairForSec 120 ignore_battery</syntaxhighlight>

==Inbetriebnahme von BMP180 / BME280==
Damit die Daten der o.g. Sensoren in FHEM zur Verfügung stehen, muss zunächst das FHEM-Device angelegt werden.

Das Anlegen kann automatisch erfolgen, dafür muss der folgende FHEM Befehl ausgeführt werden:
<syntaxhighlight lang="php">set myLaCrosseGateway LaCrossePairForSec 120 ignore_battery</syntaxhighlight>

Dann sollte von [http://fhem.de/commandref.html#autocreate FHEM autocreate Funktion] ein LaCrosse Device mit der [[#Sensor-ID | Sensor-ID]] (Default Wert: 0) angelegt werden.

Alternativ kann das FHEM Device manuell angelegt werden:
Die '''''ID''''', mit der das LGW die internen Sensoren sendet, entspricht der konfigurierten [[#Sensor-ID | Sensor-ID]] (Default Wert: 0)
Es verhält sich so, als ob es eine Wetterstation (wie z.B. WS 1600) wäre.
<syntaxhighlight lang="php">define <name> LaCrosse 00</syntaxhighlight>
Anchließend muss eine Höhenkorrektur (Grund: der Luftdruck wird immer bezogen auf NN angegeben, der Sensor liefert aber den Absolutdruck) mit dem command '''''h''''' in den initCommands vorgenommen werden, dies erfolgt mit dem FHEM Befehl:

Beispiel: 220h legt 220m über NN fest.''
<syntaxhighlight lang="php">attr myLaCrosseGateway initCommands 220h</syntaxhighlight>

'''Besser:''' Alternativ kann die Höhe über NN auch auf der Setup-Page des LGW gesetzt werden.<br>
Das hat den Vorteil, dass sofort vom Start an der normalisierte Luftdruck an FHEM gesendet wird und nicht erst, wenn die initCommands von FHEM geschickt wurden.

==Inbetriebnahme Piezo Summer==

Der Piezo Summer wird in FHEM über das LaCrosseGateway Modul angesteuert.

'''Beispiele:'''
<syntaxhighlight lang="php">
set myLaCrosseGateway raw 1,60b -> beep ... beep ... beep 60 Sekunden lang
set myLaCrosseGateway raw 2,300b -> beep beep ... beep beep ... beep beep 300 Sekunden lang
set myLaCrosseGateway raw 3,120b -> beep beep beep ... beep beep beep ... 120 Sekunden lang
set myLaCrosseGateway raw 0b -> beep stoppen
</syntaxhighlight>

==Inbetriebnahme von RFM69CW==
Mit dem LaCrosseGateway ist es möglich mehrere RFM69CW einzusetzen. Nachfolgend wird die Konfiguration des Senders/Empfängers erläutert.

Die "Default Werte" (wenn keine Angaben definiert werden) für die data rate sind wie folgt definiert:
<syntaxhighlight lang="php">
#1 (Erste) => 17241
#2 (Zweite) => 9579
#3 (Dritte) => 8842
#4 (Vierte) => 20000
#5 (Fünfte) => 17241
</syntaxhighlight>

'''''Hinweis:''' Detailinformationen sind auch auf der LaCrosseGateway "Help"-Page zu finden.''

{| class="wikitable" style="margin-left: auto; margin-left: 0px;"
|-
|colspan="2" style="text-align:center"|'''<Datenrate>#<Radio-Nummer><command>'''
|-
| <code>m t:</code> || ''Toggle-Steuerung''
|-
| <code>r:</code> || ''DataRate''
|-
| <code>f:</code> || ''Frequenz''
|}

'''''Beispiele:'''''

''
{| class="wikitable" style="margin-left: auto; margin-left: 0px;"
!Definition !! Erläuterungen
|-
| <syntaxhighlight lang="php">attr myLaCrosseGateway initCommands 0#1r v</syntaxhighlight>
| DataRate des ersten RFM setzen
|-
| <syntaxhighlight lang="php">attr myLaCrosseGateway initCommands 8842#3r v </syntaxhighlight>
| DataRate des dritten RFM setzen
|-
| <syntaxhighlight lang="php">attr myLaCrosseGateway initCommands 868300#2f v</syntaxhighlight>
| Frequenz des zweiten RFM setzten
|-
| <syntaxhighlight lang="php">attr myLaCrosseGateway initCommands 868295#3f v</syntaxhighlight>
| Frequenz des dritten RFM setzten
|-
| <syntaxhighlight lang="php">attr myLaCrosseGateway initCommands 17241#1r 8842#2r v</syntaxhighlight>
| Zwei RFM69CW mit DataRate 17241 und 8842
|-
| <syntaxhighlight lang="php">attr myLaCrosseGateway initCommands 3#1m 20#1t 8842#2r v</syntaxhighlight>
| Zwei RFM69CW mit 20 Sekunden DataRate 17241 toggle 9579 plus 8842 permanent
|-
| <syntaxhighlight lang="php">attr myLaCrosseGateway initCommands 220h 868295#1f 868310#2f v</syntaxhighlight>
| Zwei RFMs Frequenz 868295 und 868310 sowie Höhe über NN
|-
| <syntaxhighlight lang="php">attr myLaCrosseGateway initCommands 868295#1f 3#1m 20#1t 2,868950,60i 8842#3r 220h 0a v</syntaxhighlight>
| Drei RFMs Frequenz 868295 / PCA301 / WS1600 sowie Höhe über NN <br>Radio 1 auf 868295 MHz und Toggle 9K/17K mit 20 Sekunden<br>Radio 2 für PCA301 initialisiert<br>Radio 3 macht 8842 kbps für die WS 1600<br>Höhe 220m über NN<br>Activity LED aus<br>v am Ende ruft die neu gesetzten Daten vom LaCrosseGateway ab, damit sie in FHEM LaCrosseGateway Modul aktualisiert werden.
|}

'''''Hinweis:''' Es ist wichtig ein "v" an das Ende eines initCommands anzuhängen. Damit wird veranlasst, dass das LaCrosseGateway seine neuen Einstellungen an FHEM zurückmeldet.
==Inbetriebnahme von PCA301==
PCA301 im LGW funktioniert ähnlich dem PCA301 Sketch, allerdings mit einigen systembedingten Abweichungen.

Per default ist PCA301 nicht aktiviert, es muss in den initCommands aktiviert werden. Dazu gibt es das command "'''''i'''''".

'''<RadioNr>,<Frequenz>,<Poll-Intervall>i'''

Die Initialisierung kann auch erneut geschickt werden, um z.B. das Poll-Intervall zu ändern.

'''''Wichtig:''''' Es darf nur '''"ein"''' Radio für PCA301 initialisiert sein, nicht mehrere. Das PCA301 initialisierte Radio ist dediziert für PCA301 zuständig, es kann nicht zwischen anderen Protokollen (z.B. LaCrosse) toggeln.''

Das ''Poll-Interval'' sollte nicht extrem heruntergesetzt (nicht unter eine Minute) werden, da PCA301 sonst LaCrosse verdrängt. PCA301 hat höhere Priorität, da es bei der Kommunikation
mit den Dosen keine Antworten überhören darf.

Unter Umständen muss die Frequenz etwas angepasst werden, wenn das Radio und/oder die Dosen nicht genau auf 868950 liegen.
Das ist daran zu erkennen, dass entweder gar keine Antwort von den Dosen oder verzögerte Antwort ankommt.
Werte von 868960 oder 960970 haben in manchen Fällen Abhilfe gebracht.

'''''Beispiele:'''''

{| class="wikitable" style="margin-left: auto; margin-left: 0px;"
! Definition !! Erläuterungen
|-
| style="width:40%" | <code>attr myLaCrosseGateway initCommands 2,868950,120i v</code>
| Initialisiert den zweiten RFM auf 868950 MHz und setzt das Poll-Intervall auf 120 Sekunden
|-
| <code>attr myLaCrosseGateway initCommands 1,868950,120i 3#2m 20#2t 220h 0a v</code>
| Initialisierung eines LaCrosseGateways mit zwei Radios für TX29, TX35, PCA301 und BMP180/BME280.<br>Das erste Radio macht PCA301 und das zweite toggelt 17241/9579 im 20 Sekunden Takt um TX29 und TX35 zu empfangen<br>der BMP180/BME280 liefert den Druck für 220m Meereshöhe<br>die LED ist deaktiviert
|}

'''Ablauf:'''

Nachdem PCA301 initialisiert ist, lauscht das LaCrosseGateway auf der entsprechenden Frequenz.
Sobald eine Dose empfangen wurde, wird sie in der Konfiguration (EEPROM) dauerhaft registriert und ab sofort gepollt.

Das ''Polling'' funktioniert so, dass für jede Dose geschaut wird, wann sie zuletzt empfangen wurde und wenn das länger als das konfigurierte Interval zurück liegt,
dann wird sie abgefragt. Wenn sonst etwas (Basisstation, anderes FHEM) die Dose abgefragt hat und das LaCrosseGateway die Antwort gehört hat, dann gilt das auch als
empfangen und es wird kein eigener Poll für die Dose ausgelöst. ''Das Zusammenspiel mit einer echten Basisstation konnte bisher nur grob simuliert werden.''

Das ''Pairing'' (also die Vergabe eines Kanals) funktioniert wie im PCA301-Sketch, button an der Dose ''"3 Sekunden"'' drücken, dann vergibt das LaCrosseGateway den nächsten freien Kanal.
Dosen, die bereits einen Kanal haben, können durch ein Schalten vor Ort, an das LaCrosseGateway angelernt werden. Das LaCrosseGateway erkennt sie und nimmt sie in die
Konfiguration auf. Falls die Dose bereits mit einem anderen Kanal bekannt war, wird der Kanal im LaCrosseGateway aktualisisert.

Auf der Setup-Page im Web-Frontend (http://IP-Adresse oder Hostname/setup) des LaCrosseGateway kann die Liste der bekannten Dosen (ID=Kanal) eingesehen werden. Hinweis: Es sollten keine Änderungen in diesem Bereich vorgenommen werden.

Wenn ein Kommando (Schalten, Daten abfragen, ...) an eine Dose gesendet wurde und keine Antwort kam, wird bereits im Sketch drei mal versucht, eine Antwort zu bekommen.

Das PCA301 Modul in FHEM funktioniert komplett wie bisher.

Weiterführende Themen zum PCA301 sind im Wiki [[PCA301 Funkschaltsteckdose mit Energieverbrauchsmessung]] und PCA301 FHEM Thread {{Link2Forum|Topic=11648|LinkText=JeeLink / PCA301 Thread}} beschrieben.

Die Befehle, die der PCA301-Sketch kennt, gibt es im LaCrosseGateway nur teilweise:
{| class="wikitable" style="margin-left: auto; margin-left: 0px;"
! Befehl (Beschreibung)!! Erläuterungen
|-
| <code>a "turn activity LED on or off</code>
| wie bisher
|-
| <code>l "list known devices"</code>
| entfallen, kann man nun im Web-Frontend sehen
|-
| <code>q "turn quiet mode on or off"</code>
| wie bisher
|-
| <code>r "list recordings"</code>
| entfallen
|-
| <code>s "send to plug"</code>
| wie bisher
|-
| <code>v "report version and configuration parameters"</code>
| wie bisher
|-
| <code>d, e, p "poll / turn a device on / off"</code>
| entfallen
|-
| <code>h, +, -, # "modify and display RF12 Frequency register"</code>
| entfallen, ersetzt durch das "i" command bzw. das bereits vorhandene "f" command
|}

==Inbetriebnahme von Energy Count 3000 (EC3000)==
Die EC3000 sendet auf 868.300 kHz mit 20.000 kbps. Dafür wurde eine neue data rate hinzugefügt.
Sie kann mit 3r oder 20000r gesetzt werden. Wenn diese data rate gesetzt wird, wird auch automatisch der RFM69 auf den Empfang von EC3000 uminitialisiert.

EC3000 kann auch in einen data rate toggle mit einbezogen werden. Dazu gibt es nun das bit mit dem Wert 8 für 20.000 kbps

Um EC3000 dediziert mit einem der drei RFMs zu empfangen muss man einfach die data rate des gewünschten RFM setzen. Beispiel initCommand:
20000#2r

Um EC3000 in einen data rate toggle mit einzubeziehen muss im m command das 8-wertige bit gesetzt werden.
Wenn man z.B. mit dem zweiten Radio 17k Sensoren (TX29...) und EC3000 empfangen soll (20 Sekunden toggle), wäre das initCommand:

'''Beispiel:'''
<syntaxhighlight lang="php">attr myLaCrosseGateway initCommands 9#2m 20#2t v</syntaxhighlight>

==Inbetriebnahme von MCP23008==
Auf der LaCrosseGateway "config"-page kann für jeden der 8 IO Pins konfiguriert werden, ob es ein Input oder Output Pin ist.

'''Input''': Eingang, wird per KVP an FHEM übermittelt. Einsatzzweck: z.B. Anschluss von Pushbuttons.

'''Output''': Kann von FHEM aus gesetzt werden. Einsatzzweck: z.B. Anschluss von LEDs.

Beispiel: ''Input => Eingang, wird per KVP an FHEM übermittelt''
<syntaxhighlight lang="php">OK VALUES LGPB 211 GP2=0,GP3=1,GP4=0,GP5=0,GP6=0,GP7=0</syntaxhighlight>

Beispiel: ''Output => Kann von FHEM aus gesetzt werden.''
<syntaxhighlight lang="php">set myLaCrosseGateway raw "MCP GP0=1,GP1=0"</syntaxhighlight>

==Inbetriebnahme Analogport==
Der Analogport A0 des ESP8266 wird als Reading im LaCrosseGatewayModul aufgeführt.
Um das zu aktivieren, muss man auf der Setup-Page des LGW die Option "Send analog values" ankreuzen.
Der Eingangsspannungsbereich von A0 ist 0V ... 1.0V, was zu einem Reading von 0 ... 1023 führt.

==Inbetriebnahme von OLED-Display==
Es wird das 128x64 pixel 0.96" I2C Display mit dem SSD1306 controller und das 128x64 pixel 1.3" mit dem SH1106 controller unterstützt.

Für die korrekte Darstellung auf dem 1.3" Display, muss die Checkbox 1.3" auf der Setup-Page aktiviert werden

Hinweis: das 0.96" Display bekommt man auch in einer Variante, die SPI unterstützt. Diese Variante kann nur nach einem Umbau verwendet werden.

Der nachfolgende Funktionsumfang ist implementiert:

*OLED ein- und ausschalten sowie das Senden von individuellen Texten über FHEM mithilfe des LaCrosseGateway-Moduls
*OLED Startverhalten konfigurierbar
*Übermittlung des Display Status im KVP
*Anzeige von Statusinformationen in der obersten Zeile mithilfe von Symbolen (siehe Abbildung - von links nach rechts)
**WiFi connect erfolgreich
**Ein FHEM hat sich auf einen DataPort connected
**Ein FHEM hat sich auf den Prozessor an der [[#Serial_transparent_bridge|UART bridge]] connected
**WiFi Signalstärke (dBm). Hinweis: -36 ist besser als -60
[[Datei:lgw_oled_statuszeile.png|400px|thumb|left|OLED Anzeige von Statusinformationen]]
<div style="clear:both;"></div>
*Darstellung von bis zu drei Texten und optional eines Symbols
*Definition des Zeitintervalls für das Umschalten zur nächsten Seite
*Zuweisung der Modes an die Ports des MCP23008 (Die Konfiguration erfolgt auf der "Setup"-Page)
*Fortschrittsanzeige beim Flashen eines an die serielle Schnittstelle des SC16IS750 angeschlossenen Arduinos (siehe SubProzessor und Serial transparent bridge)

===OLED Start Modus===
Einstellungsmöglichkeit über die "Config"-Page wie sich das OLED nach einem Start verhalten soll.
Mögliche Optionen: on / off / Anzahl Sekunden, nach denen es ausgeht.
Zusätzlich kann der initiale Mode festgelegt werden (z.B. thp)

===Modes===
{| class="wikitable" style="margin-left: auto; margin-left: 0px;"
! Prefix !! Parameter !! Erläuterung
|-
| OLED mode=
| t
| Temperatur des internen Sensors
|-
| OLED mode=
| h
| Feuchte des internen Sensors
|-
| OLED mode=
| p
| Druck des internen Sensors
|-
| OLED mode=
| s
| Statuswerte des LGW
|-
| OLED mode=
| f
| von FHEM gesetzter Text
|}

===Mögliche Symbole===
{| class="wikitable" style="margin-left: auto; margin-left: 0px;"
! Parameter !! Erläuterung !! OLED Darstellung
|-
| t
| Temperature
| [[Datei:lgw_sym_t.jpg|150px|thumb|left|]]
<div style="clear:both;"></div>
|-
| h
| Humidity
|[[Datei:lgw_sym_h.jpg|150px|thumb|left|]]
<div style="clear:both;"></div>
|-
| p
| Pressure
|[[Datei:lgw_sym_p.jpg|150px|thumb|left|]]
<div style="clear:both;"></div>
|-
| s
| System
|[[Datei:lgw_sym_s.jpg|150px|thumb|left|]]
<div style="clear:both;"></div>
|-
| i
| Info
|[[Datei:lgw_sym_i.jpg|150px|thumb|left|]]
<div style="clear:both;"></div>
|-
| w
| Warning
|[[Datei:lgw_sym_w.jpg|150px|thumb|left|]]
<div style="clear:both;"></div>
|-
| e
| Error
|[[Datei:lgw_sym_e.jpg|150px|thumb|left|]]
<div style="clear:both;"></div>
|}

===Beispiele===

{| class="wikitable" style="margin-left: auto; margin-left: 0px;"
! Definition !! Erläuterung
|-
| style="width:30%" | <syntaxhighlight lang="php">set myLaCrosseGateway raw "OLED On"</syntaxhighlight>
| Schaltet ein angeschlossenes Display ein
|-
| <syntaxhighlight lang="php">set myLaCrosseGateway raw "OLED Off"</syntaxhighlight>
| Schaltet ein angeschlossenes Display aus
|-
| <syntaxhighlight lang="php">set myLaCrosseGateway raw "OLED interval=20"</syntaxhighlight>
| Legt fest, dass (je nach mode) alle 20 Sekunden die nächste Seite angezeigt wird.
|-
| <syntaxhighlight lang="php">set myLaCrosseGateway raw "OLED mode=ths"</syntaxhighlight>
| Zeigt nacheinander Temperatur, Feuchte und Systemdaten an
|-
| <syntaxhighlight lang="php">set myLaCrosseGateway raw "OLED mode=thp"</syntaxhighlight>
| Zeigt nacheinander Temperatur, Feuchte und Luftdruck an
|-
| <syntaxhighlight lang="php">set myLaCrosseGateway raw "OLED mode=thps"</syntaxhighlight>
| Zeigt nacheinander Temperatur, Feuchte, Luftdruck und Systemdaten an
|-
| <syntaxhighlight lang="php">set myLaCrosseGateway raw "OLED mode=f"</syntaxhighlight>
| Zeigt ausschließlich den von FHEM festgelegten Text an
|-
| <syntaxhighlight lang="php">set myLaCrosseGateway raw "OLED mode=s"</syntaxhighlight>
| Zeigt ausschließlich die Systemdaten an
|-
| <syntaxhighlight lang="php">set myLaCrosseGateway raw "OLED show=Soll: 20.5,Ist: 19.2,,t"</syntaxhighlight>
| Zeigt die übergebenen Texte an und links das Symbol für Temperatur
|-
| <syntaxhighlight lang="php">set myLaCrosseGateway raw "OLED show=55%,,,h"</syntaxhighlight>
| Zeigt nur den Text "55%" und das Symbol für Feuchte an. Da es nur ein Text ist, wird er größer dargestellt
|-
| <syntaxhighlight lang="php">set myLaCrosseGateway raw "OLED show=Line 1,Line 2,Line 3"</syntaxhighlight>
| Zeigt drei Texte aber kein Symbol an.
|-
| <syntaxhighlight lang="php">attr myLaCrosseGateway initCommands "OLED mode=thps"</syntaxhighlight>
| Zeigt nacheinander Temperatur, Feuchte, Luftdruck und Systemdaten an. Der Mode wird immer geschickt, wenn FHEM sich neu auf das LGW connected.
|}

==Inbetriebnahme eines Nextion Displays==

Mithilfe der Seriellen Schnittstelle [[#Soft_serial_bridge|(Soft serial bridge]]), kann ein Nextion Display in Betrieb genommen werden. Das Besondere dabei ist, dass das LGW zusätzlich seine Status Informationen (AP-Verbindungsstatus, RSSI, IP, Version, FHEM Verbindungsstatus, etc.) an das Display schickt.
Die Anbindung an FHEM erfolgt mithilfe des Nextion Moduls (42_Nextion.pm), welches per FHEM Update verteilt wird.

Ein Diskussionsthread zum Thema „LaCrosseGateway mit Nextion Display“ findet man {{Link2Forum|Topic=63443|LinkText=hier}}.

===Voraussetzungen===
Vor der Inbetriebnahme in FHEM, müssen folgende Voraussetzungen erfüllt sein:
*Das Display ist wie [[#Nextion_Display|hier]] beschrieben an das LGW angeschlossen.
*Die [[#Soft_serial_bridge|Soft serial bridge]] auf der LGW Setup-page ist konfiguriert.
*Das LaCrosse Gateway Device ist wie [[#Device_Definition|hier]] beschrieben angelegt.

===Funktionsumfang===

Der nachfolgende Funktionsumfang ist implementiert:

*OTA Firmware (.tft File) Übertragung an das Display
*Automatische Anpassung der Baudrate auf dem Nextion
*Das LGW schickt (periodisch) Werte an folgende Controls:
{| class="wikitable" style="margin-left: auto; margin-left: 0px;"
! Control!! Beschreibung/Anmerkung
|-
| LGW#temp.txt
| Nur wenn ein entsprechender on board sensor vorhanden ist.
|-
| LGW#hum.txt
| Nur wenn ein entsprechender on board sensor vorhanden ist.
|-
| LGW#pres.txt
| Nur wenn ein entsprechender on board sensor vorhanden ist.
|-
| LGW#rssi.txt
| WLAN RSSI Signalstärke
|-
| LGW#ip.txt
| IP-Adresse des LGW's
|-
| LGW#fpm.txt
| Frames Per Minute
|-
| LGW#heap.txt
| Free Heap
|-
| LGW#up.txt
| Uptime
|-
| LGW#ver.txt
| Version
|-
| LGW#wifi (vis)
| Setzt die visibility
|-
| LGW#fhem
| Setzt die visibility
|-
| LGW#cpu1
| Setzt die visibility
|-
| LGW#cpu2
| Setzt die visibility
|-
| LGW#main
| Sendet, nachdem es sich initialisiert hat, ein "page LGW#main" an das Nextion.
|-
| LGW#info
| Sendet die Info an die LGW#prog page
|-
| LGW#ptext
| Sendet die Info an die LGW#prog page
|-
| LGW#pbar
| Sendet die Info an die LGW#prog page
|}

*Fortschrittsanzeige beim flashen der Nextion Firmware

===Device Definition Nextion Modul===

Die Definition für die Nextion Bridge sieht dann wie folgt aus:

<code>define <nextion> Nextion <IP-Adresse>:<Port></code>

''<nextion>'' kann bei Bedarf angepasst werden.

''<IP-Adresse>'' muss entsprechend angepasst werden. Anstatt der IP-Adresse kann auch der Hostname vom LaCrosseGateway verwendet werden.

''<Port>'' Ist der auf der Setup-page definierte Port

'''Beispiel:'''
<syntaxhighlight lang="php">define nextion Nextion 192.168.22.33:86</syntaxhighlight> IP-Adresse ermitteln: Das LaCrosseGateway heisst per default Einstellung "LaCrosseGateway", per ping auf den Hostnamen LaCrosseGateway kann die <IP-Adresse> ermittelt werden.

===Firmware erstellen und flashen ===
Ein UI für das Nextion Display wird mit dem Nextion Editor erstellt. Mithilfe des Editors kann die entsprechende Firmware (tft Datei – siehe „File -> Open build folder“) kompiliert (Button: Compile) werden.

Das LGW kann die Firmware (.tft Datei) zum Display übertragen. Dazu gibt es zwei Varianten:

'''curl'''

Syntax lautet:

<code>curl --http1.0 -# -o ~output.txt -H "Content_Type:multipart/form-data" -F "file=@<tftFileName>; filename=nextion.tft" http://<LGW-IP>/ota/nextion</code>

Beispiel:

<code>curl --http1.0 -# -o ~output.txt -H "Content_Type:multipart/form-data" -F "file=@D:\MyNextionFiles\lgw.tft; filename=nextion.tft" http://192.168.31.213/ota/nextion</code>

'''Das LaCrosseGateway Modul in FHEM'''

Syntax lautet:

<syntaxhighlight lang="php">set <myLaCrosseGateway> nextionUpload</syntaxhighlight>

Wenn das Attribut "tftFile" gesetzt ist, wird die darin angegebene Datei hochgeladen, ansonsten wird versucht, das File „FHEM/firmware/nextion.tft“ hochzuladen.

===Anwendungsbeispiel===
In {{Link2Forum|Topic=63443|LinkText=diesem FHEM Forum Thread}} wurde ein LGW Nextion UI erarbeitet (Stand 01.08.2017 {{Link2Forum|Topic=63443|Message=582453|LinkText=Version 0.7}}), um die Funktionsweise zu demonstrieren.
Das Nextion UI besteht aus folgenden Pages:
{| class="wikitable"
!ID !! Name !! Page !! Beispiel !! Hinweise/Funktion/Bechreibung !! Nextion Debug commands
|-
| 0 ||Boot || Boot || [[Datei:lgw_nextion_boot.png|200px|thumb|left|]]<div style="clear:both;"></div> || Das ist die Startseite nach Einschalten des Nextion Displays. ||
|-
| 1 ||Progress||LGW#prog ||[[Datei:lgw_nextion_prog.png|200px|thumb|left|]]<div style="clear:both;"></div>|| Auf dieser Seite wird der WiFi Verbindungsfortschritt angezeigt. Alle Werte werden vom LGW befüllt. ||page LGW#prog
vis LGW#pbar,1

vis LGW#ptext,1

LGW#pbar.val=50

LGW#ptext.txt="Connect WiFi (1)"
|-
| 2 ||Main|| LGW#main || [[Datei:lgw_nextion_main.png|200px|thumb|left|]]<div style="clear:both;"></div> ||Dies ist die Hauptseite, welche vom LGW aufgerufen wird, sobald der Bootvorgang abgeschlossen ist.<br>Hinweise zur Funktionsweise findet man {{Link2Forum|Topic=63443|Message=546896|LinkText=hier}}|| page LGW#main
vis LGW#wifi,1

vis LGW#fhem,1

vis LGW#cpu1,1

vis LGW#cpu2,1

LGW#rssi.txt="-68"

tTime.txt="23:45"

tDate.txt="01.08.2017"

vis iTemp,1

LGW#temp.txt="25.7"

vis iHum,1

LGW#hum.txt="68%"

vis iPres,1

LGW#pres.txt="1024hPa"

vis iWind,1

tout_ws.txt="23km/h"

vis iOutT,1

tout_t.txt="28°C"
|-
| 3 ||Info Page|| Info || [[Datei:lgw_nextion_info.png|200px|thumb|left|]]<div style="clear:both;"></div> || Alle Informationen auf dieser Seite werden von LGW automatisch befüllt. || page Info
vis LGW#ip,1

LGW#ip.txt="192.168.222.1"

vis LGW#fpm,1

LGW#fpm.txt="5"

vis LGW#heap,1

LGW#heap.txt="16280"

vis LGW#ver,1

LGW#ver.txt="1.30"

vis LGW#up,1

LGW#up.txt="1Tg.4Std.34Min."
|-
| 4 || Info Page 2 || Info2 || [[Datei:lgw_nextion_info2.png|200px|thumb|left|]]<div style="clear:both;"></div> || tInfo50 und tInfo51 sind für Nextion UI Version reserviert. tInfo60 bis tInfo91 sind nicht belegt und können verwendet werden, um z.B. die FHEM Verison anzuzeigen. || page Info2
tInfo60.txt="tInfo60:"

tInfo61.txt="tInfo61"

tInfo70.txt="tInfo70:"

tInfo71.txt="tInfo71"

tInfo80.txt="tInfo80:"

tInfo81.txt="tInfo81"

tInfo90.txt="tInfo90:"

tInfo91.txt="tInfo91"
|-
| 5 || Settings || Settings || [[Datei:Lgw_nextion_Settings.png|200px|thumb|left|]]<div style="clear:both;"></div> || Einstellungsmöglichkeit von Helligkeit (Wertebereich von 10% bis 100%) des Displays und des PowerOff Timeouts (Wertebereich: off und 1-120 Sek.)||page Settings
h1.val=25

h0.val=60
|-
| 6 || Control Center||CoCe||[[Datei:lgw_nextion_CoCe.png|200px|thumb|left|]]<div style="clear:both;"></div> ||Zum Schalten von Aktoren und Status Anzeige.<br>Weitere Hinweise zur Funktionsweise sind {{Link2Forum|Topic=63443|Message=576902|LinkText=hier}} zu finden. || page CoCe
lblT1.txt="lbT1"

lblS1.txt="aus"

lblT2.txt="lbT2"

lblS2.txt="an"

lblT3.txt="lbT4"

lblS3.txt="zu"

lblT4.txt="lbT3"

lblS4.txt="auf"

lblT5.txt="lbT5"

lblS5.txt="n.a."
|-
| 7 || Weather ||Weather||[[Datei:lgw_nextion_Weather.png|200px|thumb|left|]]<div style="clear:both;"></div>||Zur Anzeige einer Wettervorhersage. Diese Seite wird durch ein touch auf den "Temp-Wert" in der Main#Page aufgerufen. <br>Implementierungshinweise sind {{Link2Forum|Topic=63443|Message=582453|LinkText=hier}} zu finden. ||page Weather
p0.pic=12

t0.txt="Mo 01 Aug 2017\rmin:15 max:18"

p1.pic=16

t1.txt="Di 02 Aug 2017\rmin:15 max:18"

p2.pic=17

t2.txt="Mi 03 Aug 2017\rmin:15 max:18"

p3.pic=12

t3.txt="Do 04 Aug 2017\rmin:25 max:28"

p4.pic=15

t4.txt="Fr 05 Aug 2017\rmin:28 max:32"
|}

Hinweis: Alle Controls die mit dem Namen "LGW#" beginnen sind für das LGW reserviert und werden entsprechend vom Gateway befüllt.

===Nextion Tipps & Tricks===
====Nextion Commandreferenz====
Sehr hilfreich ist die Nextion instruction Page, welche hier: https://www.itead.cc/wiki/Nextion_Instruction_Set zu finden ist.

==Serial Transparent Bridge==
Das LGW kann optional die serielle Schnittstelle des SC16IS750 transparent auf einem TCP Port bereitstellen.
Dazu gibt es die settings ''"Serial bridge port"'' und ''"Serial bridge baud"'' auf der "Setup"-Page" (Web-Frontend) des LaCrosseGateways.
Das LaCrosseGateway überträgt transparent die Daten der seriellen Schnittstelle an FHEM und umgekehrt.
Damit kann z.B. ein NanoCUL an das LaCrosseGateway angeschlossen werden und in FHEM verwendet werden.

'''''Vorgehensweise:'''''
*Einen NanoCUL bauen, z.B. auf Basis eines Arduino Pro Mini, flashen und testweise in Betrieb nehmen.
*Den NanoCUL an die serielle Schnittstelle des SC16IS70 anschließen
*Port und baud rate auf der "Setup"-Page des LaCrosseGateways festlegen, z.B. Port 85 und 38400 baud
*CUL in FHEM definieren (Beispiel):
<syntaxhighlight lang="php">define CULXYZ CUL <IP-Adresse>:85 0000</syntaxhighlight>
'''''<CULXYZ>''''' Muss nach eigenen Bedürfnissen angepasst werden.

'''''<IP-Adresse>''''' Muss entsprechend angepasst werden.

Sollte das CUL-Device nicht erreichbar sein (Restart, Austausch im Falle eines Defekts etc.), empfiehlt es sich einen reconnect Mechanismus in FHEM zu implementieren.

Dieser kann wie folgt aussehen:

<syntaxhighlight lang="php">define CULXYZ-Reconnector at +*00:00:30 {\
my $deviceName = "<CULXYZ>";;\
my $version = CommandGet("", $deviceName . " version");;\
my $gotAnswer = index($version, 'No answer') == -1;;\
\
if(!$gotAnswer) {\
fhem("set " . $deviceName . " reopen");;\
}\
\
} </syntaxhighlight>
'''''<CULXYZ>''''' Muss nach eigenen Bedürfnissen angepasst werden.

'''''Vorgehen Firmware flashen mit LGW'''''

Ein bereits in Betrieb genommener NanoCUL kann nach dem gleichen Vorgehen (siehe [[#SubProzessor|"SubProzessor - Vorgehen Firmware flashen"]]) wie ein SubProzessor geflasht werden.

==Zugriff mit mehreren FHEM Instanzen==

Bis zu drei FHEM Instanzen können auf das LaCrosseGateway gleichzeitig zugreifen.
Auf der "Setup"-Page des LaCrosseGateways können bis zu drei Ports (Data ports), pro Port eine FHEM Instanz, definiert werden (Reboot erforderlich).
Aus Performancegründen empfiehlt sich nur die benötigten Ports zu definieren.

'''''Hinweise:''''' Die Portnummer 8266 wird für OTA Update verwendet, und 80 für die "Config"-page. Aus diesem Grund ist die Verwendung dieser ports nicht erlaubt.

Wenn sich mehrere FHEM Instanzen ein LaCrosseGateway teilen, dann ist darauf zu achten, dass die eine gemeinsame/gleiche initCommand Konfiguration haben. Sollten die FHEM Instanzen unterschiedliche initCommands senden, gewinnt das (zufällig) letzte und legt es für alle anderen fest.

=Nano LaCrosse Gateway=
Das nano LaCrosse Gateway verwendet die gleiche [https://svn.fhem.de/trac/export/HEAD/trunk/fhem/FHEM/firmware/JeeLink_LaCrosseGateway.bin Firmware] wie das WiFi LaCrosse Gateway, der signifikante Unterschied ist die kompakte (portable) Bauform. Aufgrund der Bauform können jedoch nicht alle Bauteile verwendet werden.
Das Gateway eignet sich sehr gut als Entwicklungsstick (dies ist der Entstehungsgrund) oder zum Empfangen und Steuern von LaCrosse basierten Sensoren/Aktoren an einem FHEM Server (RPI, Cubietruck, etc.).

Der Betrieb über WiFi, entsprechende Stromversorgung (per USB) vorausgesetzt, ist ebenfalls möglich.

Weiterführende Informationen zum nano LaCrosse Gateway und Ideensammlung für eine Platine sind im {{Link2Forum|Topic=51329|LinkText=FHEM Forum}} zu finden.

==Bauteile==
Folgende Bauteile werden benötigt:
*Gehäuse [http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=36507 schwarz] oder [http://www.voelkner.de/products/164819/USB-Gehaeuse-USB-1kl-Transparent.html transparent]
*ESP-12E
*Auto-Flash-Reset-Schaltung
*[http://www.aliexpress.com/item/6Pin-USB-2-0-to-TTL-UART-Module-Serial-Converter-CP2102-STC-Replace-Ft232/32364013343.html?spm=2114.13010208.99999999.261.mWmpl5 CP2102 FTDI]
*RFM69CW
*Status-LED

==Schaltung==
[[Datei:lgw_nano_Schaltplan.png|600px|thumb|left|Schaltplan NanoLGW]]
<div style="clear:both;"></div>

==Selbstbau==
{| class="galleryTable noFloat"
|-
| [[Datei:lgw_nano_Selbstbau1.png|320px|thumb|left|Selbstbau nano LaCrosse Gateway 1]]
| [[Datei:lgw_nano_Selbstbau2.png|300px|thumb|left|Selbstbau nano LaCrosse Gateway 2]]
| [[Datei:lgw_nano_Selbstbau3.png|475px|thumb|left|Selbstbau nano LaCrosse Gateway 3]]
|}
==Platine==
===nano LaCrosse Gateway===
{| class="galleryTable noFloat"
|-
|[[Datei:Nanolgw_bestueckt_oberseite.jpg|400px|thumb|left|nano LaCrosse Gateway Platine Oberseite]]
|[[Datei:Nanolgw_bestueckt_unterseite.jpg|400px|thumb|left|nano LaCrosse Gateway Platine Unterseite]]
|}
===USB2TTL===
{| class="galleryTable noFloat"
|-
|[[Datei:Nanolgw_USB2TTL_1.jpg|400px|thumb|left|USB2TTL Platine Oberseite]]
|[[Datei:Nanolgw_USB2TTL_2.jpg|400px|thumb|left|USB2TTL Platine Unterseite]]
|}
===nano LaCrosse Gateway inkl. USB2TTL===
{| class="galleryTable noFloat"
|-
|[[Datei:Nanolgw_oberseite_USB2TTL_1.jpg|400px|thumb|left|nano LaCrosse Gateway inkl. USB2TTL Oberseite]]
|[[Datei:Nanolgw_oberseite_USB2TTL_2.jpg|400px|thumb|left|nano LaCrosse Gateway inkl. USB2TTL Oberseite]]
|}
{| class="galleryTable noFloat"
|-
|[[Datei:Nanolgw_unterseite_USB2TTL.jpg|400px|thumb|left|nano LaCrosse Gateway inkl. USB2TTL Unterseite]]
|[[Datei:Nanolgw_seitenansicht_USB2TTL.jpg|400px|thumb|left|nano LaCrosse Gateway inkl. USB2TTL Seitenansicht]]
|}
===nano LaCrosse Gateway fertig bestückt inkl. Gehäuse===
{| class="galleryTable noFloat"
|-
|[[Datei:Nanolgw_USB2TTL_fertig_oberseite.jpg|400px|thumb|left|nano LGW fertig bestückt inkl. Gehäuse Oberseite]]
|[[Datei:nanolgw_USB2TTL_fertig_unterseite.jpg|400px|thumb|left|nano LGW fertig bestückt inkl. Gehäuse Unterseite]]
|}
===Platine bestücken (Hinweise und Tipps)===
*Die Beschriftung SJ4 und SJ3 ist auf dem USB2TTL Wandler vertauscht, dies beeinträchtigt aber die Funktion nicht.
*Beim nanoLGW hängt C1 etwas über dem FTDI232RL vom USB2TTL Wandler, daher braucht diese Platine noch eine "Schönheitskorrektur".

= Tipps & Tricks =

==Löschen des kompletten Flash des ESP8266 mit dem esptool==
Aufgrund eines aktuell im espressif SDK vorhandenen Bugs, kann es passieren, dass das LaCrosseGateway nach dem Aufspielen der Firmware, mit einer Exception den Bootvorgang (nach "Start WIFI_STA") abbricht und nicht mehr ordnungsgemäß starten kann. In diesem Fall hilft nur noch das Löschen des kompletten Speichers des ESP8266 und das erneute Aufspielen der Firmware.

Mit dem nachfolgenden Befehl kann der Speicher des ESP8266 komplett gelöscht werden.

'''''Achtung:''' Dabei werden alle Einstellungen unwiderruflich gelöscht''
<syntaxhighlight lang="php">./esptool -vv -cp /dev/tty.SLAB_USBtoUART -cb 115200 -ca 0x00000 -cd nodemcu -ce</syntaxhighlight>

'''''</dev/tty.SLAB_USBtoUART>''' Muss entsprechend angepasst werden.''

=Weiterführende Links=
Diskussionsthread aus dem Forum:

{{Link2Forum|Topic=43672|LinkText=LaCrosseGateway - LaCrosse, PCA301 und EC3000 über wifi mit ESP8266 ohne Arduino}}

{{Link2Forum|Topic=45594|LinkText=Platine für LaCrosseGateway: Platinenbestellung}}

{{Link2Forum|Topic=51329|LinkText=Platine für nanoLGW (LaCrosse Gateway): Layout}}

{{Link2Forum|Topic=52921|LinkText=Display für LaCrosseGateway}}

{{Link2Forum|Topic=63443|LinkText=LaCrosseGateway mit Nextion Display}}

[[Kategorie:Interfaces]]
[[Kategorie:IP Components]]
[[Kategorie:Other Components]]
[[Kategorie:Temperatursensoren]]
[[Kategorie:Feuchtesensoren]]
[[Kategorie:Wetterstationen]]
[[Kategorie:868MHz]]

MapleCUN

2021-01-29T15:18:01Z

PeMue: typo corrected

{{Infobox Hardware|
|Bild=MapleCULx4.jpg
|Bildbeschreibung=MAPLE CUL (ohne LAN)
|HWProtocol=diverse
|HWType=Transceiver
|HWCategory=CUL
|HWComm=Funk 433MHz oder 868MHz
|HWChannels=N/A
|HWVoltage=3,3V nach Spannungsregler
|HWPowerConsumption=
|HWPoweredBy=USB
|HWSize=
|HWDeviceFHEM=CUL
|HWManufacturer=Eigenbau
}}

== Einleitung ==
Der MapleCUN ist neuartiges CUN oder CUL Interface zum Selbstbau, entwickelt von Telekatz.
Durch den STM32 Mikrocontroller ist die Basis sehr leistungsfähig. Der Controller ist deutlich schneller als ATMega und verfügt über mehr Flash und RAM sowie integriertes USB.
Es können 1-4 Transceiver verbaut werden.

Alle 4 Transceiver werden über ein einziges serielles Device (alternativ LAN) angesprochen als "stackable" Modul ...

Der MAPLE-Mini stellt jedoch über zwei UARTs noch zwei Serielle-Interfaces bereit, die anderweitig genutzt werden können.Diese konkrete Nutzung z.B. [[MapleCUX-Platinen|bei Ranseyers-Platinen oder anderen Umsetzunge]]n hat jedoch keinen Zusammenhang mit dem MAPLE-CUL, wird daher separat beschrieben und sollte bei Fragen auch separat diskutiert werden.

<gallery>
File:MapleCUN.jpg|Schaltplan|alt=alt language
File:MapleCULx4.jpg|Prototypen-Aufbau mit Steck-Transceivern|alt=alt language
File:4-fach-1.3-1280.jpg|4-Fach CUL V1.3|alt=alt language
File:4-fach-1.3-LAN.jpg|4-Fach CUN mit LAN-Modul V1.3|alt=alt language
File:4-fach-produktiv.jpg|4-Fach CUL im offenen Gehäuse|alt=alt language
</gallery>

== Aufbau ==
Benötigt werden dazu folgende Teile:

* [https://de.aliexpress.com/item/leaflabs-Leaf-maple-mini-ARM-STM32-compatibility/1400667476.html Maple Mini Board]
* [https://de.aliexpress.com/item/CC1101-Wireless-Module-Long-Distance-Transmission-Antenna-868MHZ-M115/32635393463.html CC1101 Funkmodul]
* [https://de.aliexpress.com/item/Free-shipping-W5100-Ethernet-module-Ethernet-network-module-for-arduino/32341522510.html W5100] oder [https://de.aliexpress.com/item/Free-shipping-W5500-Ethernet-network-module-hardware-TCP-IP-51-STM32-microcontroller-program-over-W5100/32750316619.html W5500] Ethernet Modul (Optional)
Der Aufbau kann auf Lochraster erfolgen, fertige Platinen (siehe Foto) sparen jedoch Zeit, reduzieren Fehlerquellen und erhöhen die Zuverlässigkeit.

Die Module werden gemäß Schaltplan miteinander verbunden. Da alle Module mit 3,3V laufen, sind keine Bauteile für eine Pegelanpassung notwendig.

== Bestückung der Module / Protokolle ==
Stand 07/2017: Es sind noch nicht alle Protokolle an den zusätzlichen Transceivern verfügbar.
Nach einem Reset der Konfiguration ist die Frequenz von CC0 auf 868MHz und CC1 auf 433MHz voreingestellt, lässt sich dann aber auch umkonfigurieren.

Ende Juni 2017 wurde die automatische Erkennung der Module überarbeitet. Jetzt ist es auch möglich, einen Slot unbestückt zu lassen und die nachfolgenden Slots trotzdem verwenden zu können. Wenn alle 4 Slots belegt sind, funktioniert SlowRF an Slot0, Slot1 und Slot2. Ist irgend ein beliebiger Slot unbelegt, funktioniert es an den übrigen 3 Slots. Allerdings funktioniert das Senden von SlowRF nicht am letzten Slot, da dort kein Output Pin angeschlossen ist.

Neben [[SlowRF]] nutzt der MapleCUN Intertechno und [[SOMFY|Somfy]] 433MHz.

Wegen der fehlenden "Out"-Leitung am vierten Steckplatz kann man dort diese Protokolle aber auch nicht verwenden. Nutzbar am vierten Steckplatz sind [[HomeMatic]], [[MAX]], RWE, [[LaCrosse]] und FastRF (alles 868MHz). Durch die Wahl des Protokolls wird die Frequenz automatisch eingestellt '''und kann auch nicht geändert werden!'''

Weitere Infos zu [http://culfw.de/culfw.html SlowRF]

== Bootloader flashen ==
Zum Flashen kann entweder von ST der "STM32 Flash Loader Demonstrator" oder das Tool stm32flash benutzt werden. Flashen über den originalen MAPLE Bootloader per USB funktioniert nicht.

Pin Belegung zum Bootloader flashen:
* FTDI-GND an MapleMini-GND
* FTDI-VCC an MapleMini-VCC
* FTDI-TX an MapleMini-rx1
* FTDI-RX an MapleMini-tx1
* MapleMini-boot1 an MapleMini-GND

MapleMini in den Flash-Modus versetzen:
* Taster [But32] und Taster [Reset] drücken
* Taster [Reset] los lassen
* Nach ca. 1 sec. den Taster [But32] los lassen
* Der MapleMini befindet sich jetzt im Flash-Modus und kann über rx1 und tx1 geflasht werden.

<gallery>
File:Flash1.png|Flash Bootloader 1|alt=alt language
File:Flash2.png|Flash Bootloader 2|alt=alt language
File:Flash3.png|Flash Bootloader 3|alt=alt language
File:Flash4.png|Flash Bootloader 4|alt=alt language
File:Flash5.png|Flash Bootloader 5|alt=alt language
</gallery>

== Bootloader flashen ohne TTL-Adapter ==
[[Datei:MapleCUN Bootloader serial monitor.png|mini|200px|rechts|Bootloader, serieller Monitor]]
Der Bootloader kann mittlerweile auch komplett ohne TTL-Adapter über den USB-Port des MapleMini geflasht werden. Grundbedingung dürfte wohl nur sein, dass bereits ein Bootloader geflasht ist (beim Anschließen leuchtet/blinkt die blaue LED). Dazu müssen erst in der Arduino IDE die nötigen Treiber installiert werden. Die Anleitung für die gängigen Betriebssysteme findet sich [https://github.com/rogerclarkmelbourne/Arduino_STM32/wiki/Installation hier].

Wichtig: Hierbei sollten auch wirklich die Treiber von dort verwendet werden und keine vorher evtl. von anderen Quellen installierten Treiber. Nach der Installation muss die IDE neu gestartet werden. Im Anschluss kann der Sketch von [https://github.com/rogerclarkmelbourne/Arduino_STM32/wiki/Bootloader#update-using-the-updater-sketch hier] installiert werden.

Es kann sein, dass nach der Installation in der Konsole steht, dass der Reset am Board nicht geklappt hat. In dem Fall muss der Maple noch händisch per reset-Button resettet werden.
Nachdem das Board wieder erkannt wurde (Port: COMx), muss der Serielle Monitor in der Arduino IDE aufgerufen werden. Dort sollte dann der obere Teil des Screenshots zu sehen sein. Nun muss noch in der Textbox oben "Y" eingeben und das ganze mit ''Senden'' freigegeben werden.
Wenn das wie auf dem Screenshot gezeigt durchgelaufen ist, kann jetzt direkt a-culfw geflasht werden.

== Alternative Bootloader ==
Alternativ zum V2 bootloader kann auch der MSC Bootloader verwendet werden (anzupassen: der Maple hat die LED an PB1).

Der MSC Bootloader stellt ein USB Laufwerk bereit, auf welches z.B. mit dem Dateimanager einfach die Firmware kopiert wird.

Zweimal innerhalb einer Sekunde "Reset" betätigen startet den Bootloader. Dieser funktioniert aber wegen der unterschiedlichen USB Reset Schaltung auch nicht mit dem Blue Pill (siehe {{Link2Forum|Topic=101610|LinkText=diesen Forentitel}}).

== Firmware / Flashen ==
{{Randnotiz|RNTyp=g|RNText=Sofern auf dem Maple bereits der spezielle und zur Firmware passende Bootloader installiert ist, kann über den USB-Port geflasht werden, ansonsten wird noch ein USB/TTL Wandler benötigt. Da der UART1 Anschluss des Controllers 5V-tolerant ist kann auch ein Wandler mit 5V Ausgang verwendet werden. Angeschlossen wird der Wandler an den Debug-Port (DBG).

Achtung: Der Bootloader sollte ohne zwingenden Grund niemals getauscht werden. Bei Firmwareupdates reicht es normalerweise immer aus, nur die a-culfw zu tauschen.}}

Die Sourcen sind auf [https://github.com/heliflieger/a-culfw github] zu finden, der Link auf die aktuellen binaries sowie auf die aktuelle Flash-Anleitung findet sich {{Link2Forum|Topic=60458|msg=518449|LinkText=hier (im ersten Post)}}.

Die Firmware ist in der a-culfw enthalten. Für den MapleCUN gibt es jetzt nur noch zwei verschiedene Firmware-Dateien, je nach verwendetem Wizchip:
* MapleCUNx4_W5100.bin
* MapleCUNx4_W5500.bin
In diesen Versionen sind alle Protokolle enthalten. Für einen MapleCUL (also ohne LAN Modul) kann man beide Versionen verwenden.

Falls kein Netzwerkmodul angeschlossen ist, wird dies automatisch erkannt. Auch die Anzahl der Transceivermodule wird automatisch erkannt.

Anmerkungen zur Firmware:
*Die Umschaltung zwischen den RF Protokollen wurde angepasst. Dies funktioniert mit Ausnahme von KOPP_FC mit allen Protokollen.
*Folgende Einschränkungen gibt es für den Betrieb mit mehreren Transceivern:
*SlowRF funktioniert nur an CC0 und CC1.
*MBUS funktioniert an jedem Transceiver, aber insgesamt nicht an mehr als einem Transceiver gleichzeitig.
*KOPP_FC funktioniert nur an CC0.
*Die restlichen Protokolle funktionieren an allen Transceivern und auch mehrfach gleichzeitig.
*LaCrosse geht seit Firmware (a-culfw) 1.26.03. Empfangen funktioniert ohne Zusatzhardware mit einem freien 868Mhz Modul, auf das ein
::<code>set raw Nr1</code>
:bzw.
::<code>set raw Nr2</code>
:gesetzt wird.

===Firmware flashen: ===
* Zuerst den Bootloader tauschen (einmalig)
* per USB das Firmware Binary flashen
Bitte jeweils die aktuelle README der Firmware beachten.

Probleme beim Flashen:

sudo ./stm32flash -w maple_mini_boot20.bin -v /dev/ttyUSB1
stm32flash 0.5

http://stm32flash.sourceforge.net/

Using Parser : Raw BINARY
Interface serial_posix: 57600 8E1
Version : 0x22
Option 1 : 0x00
Option 2 : 0x00
Device ID : 0x0410 (STM32F10xxx Medium-density)
- RAM : 20KiB (512b reserved by bootloader)
- Flash : 128KiB (size first sector: 4x1024)
- Option RAM : 16b
- System RAM : 2KiB
Write to memory
Erasing memory
Got NACK from device on command 0x43
Can't initiate chip mass erase!
Failed to erase memory

Lösung:
sudo ./stm32flash -k /dev/ttyUSB1
...
Read-UnProtecting flash

=== Trick zum USB-Flashen (Code Schnipsel für kleines Skript) ===
<syntaxhighlight lang="bash">
#! /bin/sh
while (true); do
sudo dfu-util --verbose --device 1eaf:0003 --cfg 1 --alt 2 --download MapleCUNx4_W5500_BL.bin
#sudo dfu-util --verbose --device 1eaf:0003 --cfg 1 --alt 2 --download MapleCUNx4_W5100_BL.bin
if [ $? -eq 0 ]
then break
fi
sleep 1
done
exit
</syntaxhighlight>

== Firmware flashen unter Windows 7 - 64bit ==
Folgende Sourcen werden genutzt:
* https://github.com/rogerclarkmelbourne/Arduino_STM32
* https://zadig.akeo.ie/

Die einzelnen Schritte:
* Reset des Maple durch drücken des Reset Buttons
* Drücken des "but=32" Buttons direkt nach dem Reset und gedrückt halten
* Der Maple sollte jetzt im 4 Hz Takt blinken und im DFU Modus sein
* "but=32" loslassen
<syntaxhighlight lang="doscon">
C:\tmp\Arduino_STM32-master\Arduino_STM32-master\tools\win>dfu-util --list
dfu-util - (C) 2007-2008 by OpenMoko Inc.
This program is Free Software and has ABSOLUTELY NO WARRANTY
Found DFU: [0x1eaf:0x0003] devnum=1, cfg=0, intf=0, alt=0, name=""
Found DFU: [0x1eaf:0x0003] devnum=1, cfg=0, intf=0, alt=1, name="STM32duino bootloader v1.0 Upload to Flash 0x8005000"
Found DFU: [0x1eaf:0x0003] devnum=1, cfg=0, intf=0, alt=2, name="STM32duino bootloader v1.0 Upload to Flash 0x8002000"
</syntaxhighlight>
* Treiber für den Maple mit Zadig setzen:
:<code>libusbk (v3.0.7.0)</code>
* Firmware flashen:
<syntaxhighlight lang="doscon">
C:\tmp\Arduino_STM32-master\Arduino_STM32-master\tools\win\dfu-util-0.9-win64>dfu-util --verbose --device 1eaf:0003 --cfg 1 --alt 2 --download MapleCUNx4_W5500_BL.bin
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 1eaf:0003
Run-time device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Setting #2 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0110
Device returned transfer size 1024
Copying data from PC to DFU device
Download [=========================] 100% 66288 bytes
Download done.
Sent a total of 66288 bytes
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Done!
</syntaxhighlight>
* Tipp: Bei mir funktioniert das flashen nur direkt am PC. Ist ein USB Hub dazwischen erkennt dfu-util den Maple nicht.

== Einrichtung in FHEM (alt) ==
Per USB oder LAN:
## USB
define MAPLECUL1_868 CUL /dev/serial/by-id/usb-STM32_MAPLECUL_USB__6bfbb14f-if0@38400 4444
## LAN
## define MAPLECUL1_868 CUL IP:Port=2323 FHTIDattr MAPLECUL_USB_868 group Gateways
#define MAPLECUL1_868 CUL 192.168.1.65:2323 1234
attr MAPLECUL1_868 icon cul_868
attr MAPLECUL1_868 model CUN
attr MAPLECUL1_868 hmId 308393
attr MAPLECUL1_868 rfmode HomeMatic
attr MAPLECUL1_868 room TRX
attr MAPLECUL1_868 group Gateways

1234 oder 4444 muss oder besser kann durch eine eigene "FHTID" ersetzt werden.

Die zusätzlichen Transceiver werden als STACKABLE_CC angelegt.

define MAPLECUL2_433 STACKABLE_CC MAPLECUL1_868
attr MAPLECUL2_433 group Gateways
attr MAPLECUL2_433 icon cul_cul
attr MAPLECUL2_433 model CUN
attr MAPLECUL2_433 room TRX
attr MAPLECUL2_433 rfmode SlowRF

define MAPLECUL3 STACKABLE_CC MAPLECUL2_433
attr MAPLECUL3 group Gateways
attr MAPLECUL3 icon cul_868
attr MAPLECUL3 rfmode SlowRF
attr MAPLECUL3 room 8.00_Zentral,TRX

define MAPLECUL4 STACKABLE_CC MAPLECUL3
attr MAPLECUL4 group Gateways
attr MAPLECUL4 hmId 308393
attr MAPLECUL4 icon cul_868
attr MAPLECUL4 rfmode HomeMatic
attr MAPLECUL4 room 8.00_Zentral,TRX

== Einrichtung in FHEM (neu) ==
{{Randnotiz|RNTyp=Fehl|RNText=Läuft aktuell nicht stabil. Siehe Forenthema {{Link2Forum|Topic=99751|LinkText=MAPLECUN verabschiedet sich seit einigen Tagen jede Stunde}}.}}
Beispiel: Bis zu 4fach:
define MAPLECUL1_868 CUL /dev/serial/by-id/usb-STM32_MAPLECUL_USB__6bfbb14f-if0@38400 4444
#define MAPLECUL1_868 CUL 192.168.1.65:2323 1234
#define MAPLECUL1_868 CUL IP:Port=2323 FHTIDattr MAPLECUL_USB_868 group Gateways
attr MAPLECUL1_868 icon cul_868
attr MAPLECUL1_868 model CUN
attr MAPLECUL1_868 hmId 308393
attr MAPLECUL1_868 rfmode HomeMatic
attr MAPLECUL1_868 room TRX
attr MAPLECUL1_868 group Gateways

define MAPLECUL1Stack STACKABLE MAPLECUL1_868
attr MAPLECUL1Stack room TRX
define MAPLECUL2_433 CUL FHEM:DEVIO:MAPLECUL1Stack:9600 0000
attr MAPLECUL2_433 group Gateways
attr MAPLECUL2_433 icon cul_cul
attr MAPLECUL2_433 model CUN
attr MAPLECUL2_433 room TRX
attr MAPLECUL2_433 rfmode SlowRF

define MAPLECUL2Stack STACKABLE MAPLECUL2_433
attr MAPLECUL2Stack room TRX
define MAPLECUL3 CUL FHEM:DEVIO:MAPLECUL2Stack:9600 0000
attr MAPLECUL3 group Gateways
attr MAPLECUL3 icon cul_868
attr MAPLECUL3 rfmode SlowRF
attr MAPLECUL3 room 8.00_Zentral,TRX

define MAPLECUL4Stack STACKABLE MAPLECUL3
attr MAPLECUL4Stack room TRX
define MAPLECUL4 CUL FHEM:DEVIO:MAPLECUL4Stack:9600 0000
attr MAPLECUL4 group Gateways
attr MAPLECUL4 hmId 308393
attr MAPLECUL4 icon cul_868
attr MAPLECUL4 rfmode HomeMatic
attr MAPLECUL4 room 8.00_Zentral,TRX

#nach shutdown restart
set MAPLECUL2_433 freq 433.920
set MAPLECUL2_433 bWidth 464
set MAPLECUL2_433 rAmpl 42
set MAPLECUL2_433 sens 4
# 115200 Baud für HM-Mod-UART und z.B. CC2530
set MAPLECUL1_868 raw pb0@115200
set MAPLECUL1_868 raw pb1@115200
set MAPLECUL1_868 raw ps

Beispiel 4* ZWAVE Seriell:
define mCUL ZWCUL /dev/serial/by-id/usb-STM32_MapleCUL_71a7e023-if00 00000000 01
attr mCUL dataRate 100k

define SCC1 STACKABLE mCUL
define z100k ZWCUL FHEM:DEVIO:SCC1:9600 00000000 01
attr z100k dataRate 100k

define SCC2 STACKABLE z100k
define z40k ZWCUL FHEM:DEVIO:SCC2:9600 00000000 01
attr z40k dataRate 40k

define SCC3 STACKABLE z40k
define z9k6 ZWCUL FHEM:DEVIO:SCC3:9600 00000000 01
attr z9k6 dataRate 9600

Beispiel 2 fach:
define CULMGrau868 CUL /dev/serial/by-id/usb-STM32_MapleCUL_6bfbb14f-if00@38400 1432
attr CULMGrau868 group Gateways
attr CULMGrau868 icon cul_868
attr CULMGrau868 model CUN
attr CULMGrau868 rfmode SlowRF

define CULMGrau868Stack STACKABLE CULMGrau868

define CULMGrau433 CUL FHEM:DEVIO:CULMGrau868Stack:9600 0000
attr CULMGrau433 group Gateways
attr CULMGrau433 icon cul_cul
attr CULMGrau433 model CUN
attr CULMGrau433 rfmode SlowRF

== Zusätzliche Serielle Schnittstellen ==
Die UARTs werden als "virtuelle" Schnittstellen per USB und LAN bereitgestellt:
* Über USB werden zwei weitere Schnittstellen angelegt (typischerweise neben /dev/ttyACM0 eben /dev/ttyACM1 und /dev/ttyACM2 unter Linux und unter Windows einfach zwei weitere COM Ports).

Beispiel HM-UART an der zweite Seriellen-Schnittstelle auf einer Ranseyer Platine gelötet und local „by-id“ angesprechen:
:<code>define mapleCUL CUL /dev/serial/by-id/usb-STM32_MapleCUL_71a7e023-if00@38400 4444 ### </code>
Der MAPLE-Cul selbst
:<code>define myRemoteHmUART HMUARTLGW /dev/serial/by-id/usb-STM32_MapleCUL_71a7e023-if02 ### </code>

Die zweite Serielle
* Der Netzwerkzugriff erfolgt über die Ports 2324 und 2325.

Zur Einstellung der Baudrate über Netzwerk gibt es folgende Befehle:
* UART0 Baudrate einstellen: pb0@38400
* UART1 Baudrate einstellen: pb1@9600
* Baudrate im EEPROM speichern: ps
* Baudrate anzeigen: pi

set MapleCUL raw pb0@38400
set MapleCUL raw pb1@9600
set MapleCUL raw ps
get MapleCUL raw pi

Ein am UART0 angeschlossener [[HM-MOD-RPI-PCB HomeMatic Funkmodul für Raspberry Pi#Platine 2 -UART-Modul|HM-MOD-UART]] kann z.B. mit folgender Definition in FHEM eingebunden werden:
:<code>define myRemoteHmUART HMUARTLGW uart://192.168.42.23:2324</code>

Weiteres:
:<code>UART0= 8+9 = PA3+2 </code>
:<code>UART1= 0+1 = PB11+10 </code>

Für die Anbindung des MapleCUL ist die Baudrate egal, da kann man nichts falsch einstellen. Sie wird nicht benötigt, da der MapleCUL nicht über RS232 angebunden ist. Anders verhält es sich mit den beiden zusätzlichen UART0 und UART1 Ports. Dort ist die Baudrate relevant, da die serielle Schnittstelle dort auch physikalisch existiert.

== Debugging / weiteres ==
* Das Gerät startet ständig neu: Netzteil tauschen!
* Ich habe das Netzteil schon getauscht. Nochmals tauschen! Grund: Ein 500mA Netzteil liefert meist 500mA ohne, dass das vorher auf den Datenleitungen ausgehandelt wurde. Kein 2A Netzteil. Diese liefern meist nur 100mA, wenn das Gerät nicht mehr anfordert. 100mA sind nur leider zu wenig, wenn ein CC1101 sendet. Das führt dann dazu, dass die Spannung kurz einbricht und der MapleCUN resetet. Das könnte möglicherweise in Zukunft per Software gefixt werden: https://github.com/heliflieger/a-culfw/pull/25
* Stromverbrauch der Transceiver: Typischerweise 17 mA für RX und 34 mA für TX pro Modul (bei Inaktivität: 4 Transceiver, LAN-Modul, MAPLE ca 100mA).
* Debug-Port bzw WLAN-Anbindung über den Debug-Port: Der Maple erkennt, ob am USB-Port Kommunikation stattfindet. Konkret: ist ein Rechner am USB Port des Maple angeschlossen, dann funktioniert USB oder LAN Betrieb des MapleCUN. Ist nur ein Steckernetzteil am USB (oder ein Kabel ohne Datenleitungen - wie z.B. von einer Powerbank), dann funktioniert der LAN und WLAN Betrieb. Das liegt daran, dass seit Firmware Version 1.26.02 alle Daten durch die a-culfw auf den Debugport kopiert werden.
* Auf die OUT-Leitung kann bei den meisten FastRF Protokollen verzichtet werden. MAX und HM funktionieren z.B. ohne OUT Leitung
* Beim ersten Transceiver ist der Status nicht "Initialized": Möglicherweise ist die Verdrahtung fehlerhaft
* Der MAPLE-CUN startet ständig neu (z.B. unter Linux zu sehen bei <code>tail -f /var/log/syslog</code>, hier taucht das selbe USB Gerät ständig neu auf): Eventuell wurde eine veraltete Firmware für das LAN-Modul aufgespielt, aber kein LAN-Modul erkannt
* Devices auf einem Linux Rechner:
pi@raspberrypi:/dev/serial/by-id $ ls -la
total 0
drwxr-xr-x 2 root root 100 Jul 27 18:52 .
drwxr-xr-x 4 root root 80 Jul 27 18:52 ..
lrwxrwxrwx 1 root root 13 Jul 27 18:52 usb-STM32_MapleCUL_2788282f-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 Jul 27 18:52 usb-STM32_MapleCUL_2788282f-if02 -> ../../ttyACM1
lrwxrwxrwx 1 root root 13 Jul 27 18:52 usb-STM32_MapleCUL_2788282f-if04 -> ../../ttyACM2

* Wenn gar nicht mehr klar ist, wie der MAPLE-CUL eingestellt ist, ggf mal zurücksetzen (statt CUL1 das erste Gerät angeben):
:<code>set CUL1 raw e </code>
* Wenn keiner der Transceiver erkannt, wird an einem beliebigen Modul von Pin8 rückwärts Kurschlüsse suchen bis Pin1. Also messen zwischen 8+7, 7+6, 6+5,... Anschliessend einen Pin auslassen und noch messen 8+6, 7+5, 6+4, ...)
* Debug Port (115.200; Ausgaben nur, wenn USB Kommunikation erfolgt; letzte vorkompilierte Firmware: 1.26.01. Bei neueren Firmwares ist statt Debug die WLAN Anbindung vorgesehen)
Beispiel für Meldungen am Debug-Port mit 4 Transceivern und LAN-Modul:

-I- Getting new Started Project --
-I- MapleCUNx4
-I- Compiled: Mar 18 2017 15:46:32 --
-I- init Flash
-I- init Timer
-I- init EEprom
-I- init Ethernet
WIZCHIP Initialized success.
-I- Detected CC0: PN 0x00 VER 0x14
-I- Detected CC1: PN 0x00 VER 0x18
-I- Detected CC2: PN 0x00 VER 0x14
-I- Detected CC3: PN 0x00 VER 0x14
-I- Detected ethernet
-I- init USB
-I- init Complete

== Links ==
* {{Link2Forum|Topic=https://forum.fhem.de/index.php/topic,60458.0.html |LinkText=Diskussion im Forum}}
* [https://github.com/heliflieger/a-culfw/branches a-culfw Sourcecode]
* [[MapleCUX-Platinen|Fertige Platinen mit Erweiterungen wie mySensors, ESP8266, ...]]
* [[MapleCUx und 1-wire|MapleCUx und 1-wire]]

[[Kategorie:Interfaces]]
[[Kategorie:CUL]]
[[Kategorie:433MHz]]

JeeLink

2021-01-09T12:24:19Z

PeMue: Formatierung Relay Betrieb

'''JeeLink''' ist ein RF-Gerät im Formfaktor eines USB-Sticks mit externer Antenne.
{{Infobox Hardware
|Bild=JeeLink.jpg
|Bildbeschreibung=JeeLink mit Drahtantenne
|HWProtocol=PCA301, EC3000, RoomNode oder LaCrosse und EMT7110
|HWType=[[Interface]]
|HWCategory=
|HWComm=433/868/913 MHz
|HWChannels=?
|HWVoltage=5 V
|HWPowerConsumption=ca. 90 mA
|HWPoweredBy=USB
|HWSize=23*67*9mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#JeeLink 36_JeeLink.pm]
|ModOwner={{Link2FU|430|Andre / justme1968}}
|HWManufacturer=JeeLabs
}}

== Beschreibung ==
Vergleichbar mit dem [[CUL]] von Busware, ist der JeeLink ein USB-Stick, mit dem Funk-Hausautomations-Komponenten angebunden werden können. CUL und JeeLink unterscheiden sich im Funkmodul (CUL -> CC1101; JeeLink -> RF12B), die nicht miteinander kompatibel sind. Daher kann man auch keinen CUL als JeeLink-Ersatz nutzen!

Den JeeLink gibt es in einer
* 433 MHz Version
* 868 MHz Version (Standard)
* 915 MHz Version (Betrieb in Europa nicht zugelassen)

== Vorbereitung JeeLink ==
Um mit dem JeeLink die jeweils gewünschten Signale empfangen zu können, ist er zunächst mit der passenden Firmware zu versorgen. Dies kann auf zwei Arten geschehen. Entweder durch das selber kompilieren der Software und das Flashen aus der Arduino IDE oder aus FHEM heraus mit einem aktuellen Firmwareimage das per update mit ausgeliefert wird.

=== Selber Kompilieren ===
[[Datei:JeeLink_flashen_1.jpg|mini|100px|rechts|Vorbereitung: Arduino einrichten]]
Um den JeeLink mit FHEM benutzen zu können, muss (mit der Arduino Software / Entwicklungsumgebung (IDE)) eine spezifische "Firmware" (ein Sketch) auf dem JeeLink installiert werden. Die generelle Vorbereitung für diese Aktion ist unabhängig vom benötigten Sketch und besteht aus den folgenden Schritten:
* Für Windows oder Mac OS X den passenden [http://www.ftdichip.com/Drivers/VCP.htm FTDI Treiber] installieren, unter Linux ist dieser meist schon vorhanden
* Installation der [http://arduino.cc/de/Guide/HomePage Arduino Software] für die benutzte Plattform (verfügbar sind Windows, Mac OS X und Linux)
* Je nach Sketch einbinden der [https://github.com/jcw/jeelib/archive/master.zip Jeelabs Library] in die Arduino IDE
* Herunterladen des benötigten Sketches (aus [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino FHEM/contrib])
* Anschließen des JeeLink an einen USB-Anschluss des Rechners mit der Arduino IDE
* Start der Arduino Software und JeeLink flashen

=== JeeLink aus Arduino flashen ===
[[Datei:JeeLink_flashen_2.jpg|mini|100px|rechts|JeeLink Flashen]]
* Anschließen des JeeLink an einen USB-Anschluss des Rechners mit der Arduino IDE
* Start der Arduino Software
* Seriellen Port des JeeLink auswählen
* Einstellungen: in den Tools als Board "Arduino Uno" auswählen
* Sketch mit "Datei öffnen" auswählen
* Upload klicken

=== JeeLink aus FHEM flashen ===
* Auf dem FHEM System muss "avrdude" installiert sein. Das kann z.B. über die "normale" Linux Paketverwaltung geschehen.
** Auf dem Paspberry (Raspbian Linux) funktioniert die Installation von "avrdude" mit <code>sudo apt-get update</code> und dannach <code>sudo apt-get install avrdude</code>
* mit <code>set <JeeLinkDevice> flash [firmware]</code> wird das Flashen angestossen<br><code>firmware</code> kann LaCrosse, PCA301 oder EC3000 sein. Wenn <code>firmware</code> nicht angegeben wird versucht FHEM den Namen der zu flashenden Firmware aus der zur Zeit installierten Firmware abzuleiten.
* im FHEM Log kann der Ausgang des Flashvorgangs kontrolliert werden
* über das <code>flashCommand</code> Attribut lässt sich das Kommando zum Flashen an besondere Anforderungen anpassen

'''Vorsicht bei Jeelink Clones!'''

Jeelink Clones basierend auf dem Arduino Nano haben normalerweise keinen Optibootloader drauf im Gegensatz zum Original JeeLink und JeeNode.

Konsequenz:

Beim "Nano Clone" und ähnliches muß man zum flashen in FHEM die Baudrate setzen mit "-b 57600"

Original JeeLink, original JeeNode, und alle Arduinos, die einen Optibootloader drauf haben flashen in FHEM ohne "-b 57600"

== Hinweise zum Betrieb mit FHEM ==
Um den JeeLink (erstmalig) mit FHEM benutzen zu können, muss dieser erfolgreich geflasht worden sein.
* JeeLink an den FHEM-Rechner anschließen
* Auf Linux Systemen kann es notwendig sein, mit <code>mknod /dev/ttyUSB0 c 188 0</code> das Device anzulegen (bitte erst überprüfen, ob der Stick nicht automatisch erkannt wird)

=== Definition in fhem.cfg ===
Erforderliche Definitionen in FHEM:
:<code>define myJeeLink JeeLink /dev/ttyUSBx@57600</code>
*'''USBx''' ist anzupassen an die aktuell benutzte Schnittstelle, 0 wenn sonst nichts am USB-Port hängt
*x=0,1,2, usw.

Die [http://fhem.de/commandref.html#autocreate autocreate-Funktion] sollte aktiv sein. Alle erkannten Devices (PCA301, LaCrosse Sensoren incl. IT+ Wetterstation WS1600, EMT7110, EC3000, und RoomNodes) werden dann automatisch angelegt, sobald die jeweiligen Daten empfangen werden.

Pro Geräte-Art/Protokoll muss ein eigener JeeLink mit dem passenden Sketch zum Empfang dieser Daten vorhanden sein (es kann jeweils nur ein Sketch im JeeLink aktiv sein und es gibt (zumindest derzeit (04/2014)) keinen Sketch, der mehr als eines der Protokolle abdeckt).

'''Anmerkung:''' Der LaCrosse Sketch deckt sowohl die LaCrosse Temperatursensoren, die IT+ Wetterstation WS1600 als auch den Energieverbrauchssensor EMT7110 ab.

=== PCA301 Sketch ===
Der Sketch für die Unterstützung der ''PCA301 Funkschaltsteckdose mit Energieverbrauchsmessung'' (PCA301-pcaSerial.zip) kann aus dem [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino/ FHEM-Repository] heruntergeladen werden. Details zur Benutzung finden sich im Artikel zur [[PCA301 Funkschaltsteckdose mit Energieverbrauchsmessung|PCA301]].

Unter Umständen werden die Signale der PCA301 nicht empfangen. Insbesondere mit selbst erstellten "JeeLinks" durch wahrscheinlich hohe Bauteiltoleranzen der RF12B Sendeeinheiten. Mit dem im Sketch voreingestellten rf12_center_freq = 0xA6FE (868,9500 MHz) bekommt man in diesem Fall keine Steckdose angelernt.

==== Frequenzanpassung über modifizierten Sketch ====
Durch Tests mittels ''set <myJeeLink> raw +'' bzw ''set <myJeeLink> raw -'' kann man dann ermitteln, ob die Funksignale z.B. ab A703 bis A715 empfangen werden. Das entspricht einem Frequenzbereich zwischen 868,9750 MHz und 869,0550 MHz.
Die Mitte ist die Lösung, die man dann im Sketch ändern muss:
:<code>static uint16_t rf12_center_freq = 0xA70C;</code>
Anschließend auf den JeeLink neu flashen.

==== Frequenzanpassung über Attribut initCommands ====
Über das <code>initCommands</code> lässt sich die gefundene Frequenz einstellen, ohne dass die Firmware verändert werden muss.
:<code>attr <JeeLinkDevice> initCommands <hhhh>h</code>

=== LaCrosse Sketch ===
Der Sketch für die Unterstützung der LaCrosse Temperatursensoren, der IT+ Wetterstation WS1600 und des Energieverbrauchssensors EMT7110 so wie auch TechnoLine Sensoren (Temperatur, Luftfeuchte,...).<br>

* Er kann aus dem [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino FHEM-Repository] heruntergeladen werden.
* Alternative ist den Sketch direkt über FHEM zu flashen <code>set <JeeLinkDevice> flash LaCrosse</code> z.B.: <code>set myJeeLink flash LaCrosse</code> zuvor sollte aber ein FHEM update mit <code>update</code> durchgeführt werden.
<br>

'''Sensoren anlernen:
Mit folgenden Befehl hat man die Möglichkeit 60 Sekunden ein Gerät anzulernen. Das Gerät erscheint dann unter der Rubrik LaCrosse. <code>set <JeeLinkDevice> LaCrossePairForSec 60</code> zum Beispiel: <code>set myJeeLink LaCrossePairForSec 60</code>.

'''In der neuesten Version unterstützt er auch den SuperJee''' (siehe auch diesen {{Link2Forum|Topic=14786|Message=316924|LinkText=Forenbeitrag}}) mit folgenden Optionen:

* Option 1 (Dual RFM):
:Es kann ein zweiter RFM12B oder RFM69CW angeschlossen werden. Somit können zwei data rates (z.B. 17241 für TX29DTH und 8842 für WS 1600) gleichzeitig empfangen werden. Das geht natürlich auch mit dem toggle mode, nur ist es bei der Wetterstation ärgerlich, wenn man 30 Sekunden lang nichts empfängt und dadurch die alles entscheidende Windböe verpasst.
* Option 2 (BMP180):
:Da der Luftdruck in den Basisstationen gemessen wird, steht er für FHEM nicht zur Verfügung.
Deshalb kann nun optional ein BMP180 oder BMP085 angeschlossen werden. Auch hier wird automatisch erkannt, ob er vorhanden ist.
:Der BMP180 wird mit 3,3V versorgt und SDA mit PC4 und SCL mit PC5 verbunden (siehe die in diesem {{Link2Forum|Topic=14786|Message=316924|LinkText=Forenbeitrag}} angehängte SuperJee-CL.png)

==== Übersicht Kommandos ====
<n>a set to 0 if the blue LED bothers
<n>f initial frequency in kHz (5 kHz steps, 860480 ... 879515) (for RFM #1)
<n>F initial frequency in kHz (5 kHz steps, 860480 ... 879515) (for RFM #2)
<n>h altituide above sea level
<n>m bits 1: 17.241 kbps, 2 : 9.579 kbps, 4 : 8.842 kbps (for RFM #1)
<n>M bits 1: 17.241 kbps, 2 : 9.579 kbps, 4 : 8.842 kbps (for RFM #2)
<n>r use one of the possible data rates (for RFM #1)
<n>R use one of the possible data rates (for RFM #2)
<n>t 0=no toggle, else interval in seconds (for RFM #1)
<n>T 0=no toggle, else interval in seconds (for RFM #2)
v show version
<n>y if 1 all received packets will be retransmitted (Relay mode)

==== Relay-Betrieb ====
Der LaCrosse Sketch ermöglicht auch den Relay-Betrieb zur Reichweitenverbesserung. Er funktioniert damit ähnlich wie z. B. ein WLAN Range Extender. Wenn der Sketch für den Relay-Betrieb konfiguriert ist, wird jedes empfangene IT+ Datenpaket, das eine gültige Prüfsumme hat, direkt nach dem Empfang wieder gesendet.

Das Prinzip ist generell recht einfach:
# JeeLink im Sketch als Relais konfigurieren und flashen: Um den Relay Betrieb einzuschalten, muss im Sketch der Parameter <code>bool RELAY = 1;</code> auf den Wert 1 gesetzt werden. Falls die LED stört, kann diese im Sketch durch Setzen des Parameters <code>#define ENABLE_ACTIVITY_LED 0</code> auf 0 gesetzt werden.
# Auf "halber Strecke" (d.h. irgendwo zwischen dem primären Sender und dem entfernten Empfänger) auf ein USB-Steckernetzteil stecken. Der JeeLink arbeitet in diesem Modus "autonom", er benötigt also lediglich einen Spannungsversorgung.

Der JeeLink empfängt und decodiert alle Protokolle, die er auch für FHEM unterstützt. Wenn er ein Paket empfangen hat (egal von welchem Sensor) und CRC OK war, dann sendet er es wieder aus. Der JeeLink am FHEM merkt keinen Unterschied. Falls ein Paket es doch bis zum FHEM direkt geschafft hat, kommt es dort zweimal an. Diese Situation muss in FHEM behandelt werden.

Details zu diesem Betriebsmodus sind in diesen Forenbeiträgen ({{Link2Forum|Topic=14786|Message=165153|LinkText=LaCrosse}} bzw. {{Link2Forum|Topic=26494|Message=196648|LinkText=EMT7110}}) zu finden.

==== Frequenzanpassung ====
Ab Version LaCrosseITPlusReader.10.1e wurde der Sketch so erweitert, dass man von FHEM aus die Frequenz setzen kann. Dazu versteht der Sketch das neue Kommando "f":
:<code>set myJeeLink raw 868295f</code>
setzt die Frequenz auf 868295 kHz.

Die Frequenz kann im Bereich von 860480 kHz bis 879515 kHz in 5kHz -Schritten eingestellt werden.
Details dazu in diesem {{Link2Forum|Topic=14786|Message=222541}} im Forum. Die Frequenzanpassung ist insbesondere beim 30.3155.WD häufig erforderlich, weshalb er als kritisch einzustufen und nicht zu empfehlen ist (siehe {{Link2Forum|Topic=14786|Message=352550|LinkText=Forenbeitrag}}).

==== Toggle und Datenrate ====
Toggle
t: toggle time
20t = alle 20 Sekunden die Datenrate wechseln

Datenrate
m: toggle mode
bits: 1= 17.241 kbps, 2= 9.579 kbps, 4= 8.842 kbps
3m ist 17.241 kbps (TX29) und 9.579 kbps (TX35)

Beispiel initCommands
6m 30t v
Zwischen 8.842 kbps und 9.579 kbps wechseln (4+2=6), alle 30 Sekunden

==== Unterstützte Sensoren und Aktoren incl. Wetterstation WS 1600 ====
{{Randnotiz|RNTyp=y|RNText=Die Ausführungen in diesem Abschnitt gelten ab der Version 10.1q auch für die Wetterstation WS1080.

'''Wichtig WS1800''': die WS1080 gibt es (unter gleichem Namen) in einer "OOK"- und in einer "FSK"-Version.
* Der LaCrosse Sketch und das LaCrosseGateway können nur die FSK-Version empfangen, die OOK-Version wird nicht unterstützt.
* Die FSK-Version ist zu erkennen an einem runden grünen Aufkleber im Batteriefach der Station mit dem Aufdruck "PASS 7". Details dazu in {{Link2Forum|Topic=14786|Message=363766|LinkText=diesem Forenbeitrag}}
}}

Die in der folgenden Liste (Quelle: {{Link2Forum|Topic=14786|Message=164801|LinkText=FHEM Forum}}) aufgeführten Sensoren wurden bisher erfolgreich getestet:

{| class="wikitable"
!Bezeichnung !! Datenrate !! Link / Hinweise
|-
| TX21IT || 17.241 kbps ||
|-
| TX25-IT || 17.241 kbps ||
|-
| TX27-IT || 17.241 kbps ||
|-
| TX29-IT || 17.241 kbps ||
|-
| TX29DTH-IT || 17.241 kbps ||
|-
| TX37 || 17.241 kbps ||
|-
| TX35TH-IT || 9.579 kbps ||
|-
| TX35DTH-IT || 9.579 kbps ||
|-
| 30.3143.IT || 17.241 kbps ||
|-
| 30.3144.IT || 17.241 kbps || ({{Link2Forum|Topic=17662|LinkText=Forenthread}})
|-
| 30.3147.IT || 17.241 kbps ||
|-
| 30.3155WD || 9.579 kbps || kritisch; nicht zu empfehlen; siehe {{Link2Forum|Topic=14786|Message=352550|LinkText=Forenbeitrag}}
|-
| 30.3156WD || 9.579 kbps || Batterie-kritisch. Funktioniert schlecht mit Akkus!
|-
| 30.3187.IT || 17.241 kbps || haben alle die gleiche ID, daher nur einzeln verwendbar ({{Link2Forum|Topic=64636|LinkText=Forenthread}})
|-
| WT440XH || 17.241 kbps ||
|-
| WS 1600 (TX22) || 8.842 kbps || ({{Link2Forum|Topic=14786|Message=297293|LinkText=Forenbeitrag}})
|-
| WS 1080 || 17.241 kbps || Bitte Hinweise beachten! ({{Link2Forum|Topic=14786|Message=363766|LinkText=Forenbeitrag}})
|-
| [[EMT7110]] || 9.579 kbps || ({{Link2Forum|Topic=26494|LinkText=Forenthread}})
|-
| LevelSender || 17.241 kbps || ({{Link2Forum|Topic=23217|LinkText=Forenthread}})

|}

Werden Sensoren mit unterschiedlichen Datenraten gleichzeitig betrieben, ist der Toggle Modus einzustellen, z.B. mit dem Befehl
:<code>initCommands 6m 30t v </code>
wobei ''30t'' für "Toggle Modus, alle 30 Sekunden" steht.

=== Energy Count 3000 Sketch ===
Der Sketch für die Unterstützung der Energy Count 3000 Zwischenstecker kann aus dem [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino/ FHEM-Repository] heruntergeladen werden.

Das FHEM Modul dazu (36_EC3000.pm) ist genau wie die Module für JeeLink (36_JeeLink.pm) und PCA301 (36_PCA301.pm) mittlerweile im aktuellen FHEM enthalten.

=== JeeLabs RoomNode ===
Eine Beschreibung zum Empfang der JeeLabs RoomNodes ist in {{Link2Forum|Topic=11648|Message=92037|LinkText=diesem Forenbeitrag}} enthalten.

=== JeeLink LED deaktivieren ===
Ein "dauerhaftes" Deaktivieren der LED des JeeLink ist möglich mit
:<code>define not.global notify global:INITIALIZED set myJeeLink led off</code>
damit wird, sobald FHEM komplett gestartet ist, von FHEM der Befehl zum Ausschalten der LED gesendet. Alternativ kann mit
:<code>attr myJeeLink initCommands 0a v</code>
dem Sketch die Anweisung gegeben werden, bei der Initialisierung die LED zu deaktivieren.
''Quelle: dieser {{Link2Forum|Topic=27161|LinkText=Forenthread}}''

=== Weitergehende Informationen ===
Hinweise zum Betrieb eines JeeLink mit FHEM finden sich aktuell in größerer Anzahl in verschiedenen Diskussionen im Forum:
* {{Link2Forum|Topic=11648|LinkText=JeeLink / PCA301}} - Analyse des Funkprotokolls; Anfänge der Entstehung der PCA301 Unterstützung in FHEM.
* {{Link2Forum|Topic=14786|LinkText=JeeLink / LaCrosse}} - JeeLink Modul zur Einbindung von La Crosse
* {{Link2Forum|Topic=11648|Message=92019|LinkText=JeeLink / EC3000}} - Anfänge der Entstehung der EC3000 Unterstützung in FHEM.
* Hinweise zu {{Link2Forum|Topic=11648|Message=92037|LinkText=JeeLabs RoomNode}} und anderen JeeLab Nodes
* {{Link2Forum|Topic=25399|Message=183910|LinkText=JeeLink mit FHEM2FHEM nutzen}}

== Bekannte Probleme ==
* Beim Betrieb an einer [[AVM Fritz!Box|FritzBox]] wird der JeeLink unter Umständen als ''Für die Nutzung mit dem USB-Fernanschluss reserviert'' angezeigt. In diesem Fall muss die Reservierung deaktiviert/aufgehoben werden (Details dazu in diesem {{Link2Forum|Topic=16579|LinkText=Forenthread}}).
* Die Version ''v3c'' des JeeLink funktioniert (Stand 06/2015) nur mit dem LaCrosse Sketch. PCA301 und EC3000 Sketch sind auf den JeeLink Classic beschränkt (siehe unter anderem Diskussion im Forum, startend {{Link2Forum|Topic=11648|Message=308267|LinkText=hier}}).

== Weblinks ==
* [http://jeelabs.com/products/jeelink JeeLabs], JeeLink Hersteller
* [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino/ PCA301 Sketch] im SVN
* [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino/ LaCrosse Sketch] im SVN
* [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino/ EC3000 Sketch] im SVN
* [http://blog.moneybag.de/hausautomation-fhem-mit-funksteckdose-energiemessung-elv-pca-301/ Blog] zum Thema JeeLink zur Anbindung von PCA301 und von LaCrosse Temperatursensoren an FHEM
* {{Link2Forum|Topic=23217|LinkText=LevelSender}} Tankfüllstand mit JeeLink empfangen

[[Kategorie:Interfaces]]
[[Kategorie:Other Components]]
[[Kategorie:868MHz]]
[[Kategorie:433MHz]]

JeeLink

2021-01-09T12:18:38Z

PeMue: Erklärung Relay Betrieb eingefügt

'''JeeLink''' ist ein RF-Gerät im Formfaktor eines USB-Sticks mit externer Antenne.
{{Infobox Hardware
|Bild=JeeLink.jpg
|Bildbeschreibung=JeeLink mit Drahtantenne
|HWProtocol=PCA301, EC3000, RoomNode oder LaCrosse und EMT7110
|HWType=[[Interface]]
|HWCategory=
|HWComm=433/868/913 MHz
|HWChannels=?
|HWVoltage=5 V
|HWPowerConsumption=ca. 90 mA
|HWPoweredBy=USB
|HWSize=23*67*9mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#JeeLink 36_JeeLink.pm]
|ModOwner={{Link2FU|430|Andre / justme1968}}
|HWManufacturer=JeeLabs
}}

== Beschreibung ==
Vergleichbar mit dem [[CUL]] von Busware, ist der JeeLink ein USB-Stick, mit dem Funk-Hausautomations-Komponenten angebunden werden können. CUL und JeeLink unterscheiden sich im Funkmodul (CUL -> CC1101; JeeLink -> RF12B), die nicht miteinander kompatibel sind. Daher kann man auch keinen CUL als JeeLink-Ersatz nutzen!

Den JeeLink gibt es in einer
* 433 MHz Version
* 868 MHz Version (Standard)
* 915 MHz Version (Betrieb in Europa nicht zugelassen)

== Vorbereitung JeeLink ==
Um mit dem JeeLink die jeweils gewünschten Signale empfangen zu können, ist er zunächst mit der passenden Firmware zu versorgen. Dies kann auf zwei Arten geschehen. Entweder durch das selber kompilieren der Software und das Flashen aus der Arduino IDE oder aus FHEM heraus mit einem aktuellen Firmwareimage das per update mit ausgeliefert wird.

=== Selber Kompilieren ===
[[Datei:JeeLink_flashen_1.jpg|mini|100px|rechts|Vorbereitung: Arduino einrichten]]
Um den JeeLink mit FHEM benutzen zu können, muss (mit der Arduino Software / Entwicklungsumgebung (IDE)) eine spezifische "Firmware" (ein Sketch) auf dem JeeLink installiert werden. Die generelle Vorbereitung für diese Aktion ist unabhängig vom benötigten Sketch und besteht aus den folgenden Schritten:
* Für Windows oder Mac OS X den passenden [http://www.ftdichip.com/Drivers/VCP.htm FTDI Treiber] installieren, unter Linux ist dieser meist schon vorhanden
* Installation der [http://arduino.cc/de/Guide/HomePage Arduino Software] für die benutzte Plattform (verfügbar sind Windows, Mac OS X und Linux)
* Je nach Sketch einbinden der [https://github.com/jcw/jeelib/archive/master.zip Jeelabs Library] in die Arduino IDE
* Herunterladen des benötigten Sketches (aus [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino FHEM/contrib])
* Anschließen des JeeLink an einen USB-Anschluss des Rechners mit der Arduino IDE
* Start der Arduino Software und JeeLink flashen

=== JeeLink aus Arduino flashen ===
[[Datei:JeeLink_flashen_2.jpg|mini|100px|rechts|JeeLink Flashen]]
* Anschließen des JeeLink an einen USB-Anschluss des Rechners mit der Arduino IDE
* Start der Arduino Software
* Seriellen Port des JeeLink auswählen
* Einstellungen: in den Tools als Board "Arduino Uno" auswählen
* Sketch mit "Datei öffnen" auswählen
* Upload klicken

=== JeeLink aus FHEM flashen ===
* Auf dem FHEM System muss "avrdude" installiert sein. Das kann z.B. über die "normale" Linux Paketverwaltung geschehen.
** Auf dem Paspberry (Raspbian Linux) funktioniert die Installation von "avrdude" mit <code>sudo apt-get update</code> und dannach <code>sudo apt-get install avrdude</code>
* mit <code>set <JeeLinkDevice> flash [firmware]</code> wird das Flashen angestossen<br><code>firmware</code> kann LaCrosse, PCA301 oder EC3000 sein. Wenn <code>firmware</code> nicht angegeben wird versucht FHEM den Namen der zu flashenden Firmware aus der zur Zeit installierten Firmware abzuleiten.
* im FHEM Log kann der Ausgang des Flashvorgangs kontrolliert werden
* über das <code>flashCommand</code> Attribut lässt sich das Kommando zum Flashen an besondere Anforderungen anpassen

'''Vorsicht bei Jeelink Clones!'''

Jeelink Clones basierend auf dem Arduino Nano haben normalerweise keinen Optibootloader drauf im Gegensatz zum Original JeeLink und JeeNode.

Konsequenz:

Beim "Nano Clone" und ähnliches muß man zum flashen in FHEM die Baudrate setzen mit "-b 57600"

Original JeeLink, original JeeNode, und alle Arduinos, die einen Optibootloader drauf haben flashen in FHEM ohne "-b 57600"

== Hinweise zum Betrieb mit FHEM ==
Um den JeeLink (erstmalig) mit FHEM benutzen zu können, muss dieser erfolgreich geflasht worden sein.
* JeeLink an den FHEM-Rechner anschließen
* Auf Linux Systemen kann es notwendig sein, mit <code>mknod /dev/ttyUSB0 c 188 0</code> das Device anzulegen (bitte erst überprüfen, ob der Stick nicht automatisch erkannt wird)

=== Definition in fhem.cfg ===
Erforderliche Definitionen in FHEM:
:<code>define myJeeLink JeeLink /dev/ttyUSBx@57600</code>
*'''USBx''' ist anzupassen an die aktuell benutzte Schnittstelle, 0 wenn sonst nichts am USB-Port hängt
*x=0,1,2, usw.

Die [http://fhem.de/commandref.html#autocreate autocreate-Funktion] sollte aktiv sein. Alle erkannten Devices (PCA301, LaCrosse Sensoren incl. IT+ Wetterstation WS1600, EMT7110, EC3000, und RoomNodes) werden dann automatisch angelegt, sobald die jeweiligen Daten empfangen werden.

Pro Geräte-Art/Protokoll muss ein eigener JeeLink mit dem passenden Sketch zum Empfang dieser Daten vorhanden sein (es kann jeweils nur ein Sketch im JeeLink aktiv sein und es gibt (zumindest derzeit (04/2014)) keinen Sketch, der mehr als eines der Protokolle abdeckt).

'''Anmerkung:''' Der LaCrosse Sketch deckt sowohl die LaCrosse Temperatursensoren, die IT+ Wetterstation WS1600 als auch den Energieverbrauchssensor EMT7110 ab.

=== PCA301 Sketch ===
Der Sketch für die Unterstützung der ''PCA301 Funkschaltsteckdose mit Energieverbrauchsmessung'' (PCA301-pcaSerial.zip) kann aus dem [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino/ FHEM-Repository] heruntergeladen werden. Details zur Benutzung finden sich im Artikel zur [[PCA301 Funkschaltsteckdose mit Energieverbrauchsmessung|PCA301]].

Unter Umständen werden die Signale der PCA301 nicht empfangen. Insbesondere mit selbst erstellten "JeeLinks" durch wahrscheinlich hohe Bauteiltoleranzen der RF12B Sendeeinheiten. Mit dem im Sketch voreingestellten rf12_center_freq = 0xA6FE (868,9500 MHz) bekommt man in diesem Fall keine Steckdose angelernt.

==== Frequenzanpassung über modifizierten Sketch ====
Durch Tests mittels ''set <myJeeLink> raw +'' bzw ''set <myJeeLink> raw -'' kann man dann ermitteln, ob die Funksignale z.B. ab A703 bis A715 empfangen werden. Das entspricht einem Frequenzbereich zwischen 868,9750 MHz und 869,0550 MHz.
Die Mitte ist die Lösung, die man dann im Sketch ändern muss:
:<code>static uint16_t rf12_center_freq = 0xA70C;</code>
Anschließend auf den JeeLink neu flashen.

==== Frequenzanpassung über Attribut initCommands ====
Über das <code>initCommands</code> lässt sich die gefundene Frequenz einstellen, ohne dass die Firmware verändert werden muss.
:<code>attr <JeeLinkDevice> initCommands <hhhh>h</code>

=== LaCrosse Sketch ===
Der Sketch für die Unterstützung der LaCrosse Temperatursensoren, der IT+ Wetterstation WS1600 und des Energieverbrauchssensors EMT7110 so wie auch TechnoLine Sensoren (Temperatur, Luftfeuchte,...).<br>

* Er kann aus dem [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino FHEM-Repository] heruntergeladen werden.
* Alternative ist den Sketch direkt über FHEM zu flashen <code>set <JeeLinkDevice> flash LaCrosse</code> z.B.: <code>set myJeeLink flash LaCrosse</code> zuvor sollte aber ein FHEM update mit <code>update</code> durchgeführt werden.
<br>

'''Sensoren anlernen:
Mit folgenden Befehl hat man die Möglichkeit 60 Sekunden ein Gerät anzulernen. Das Gerät erscheint dann unter der Rubrik LaCrosse. <code>set <JeeLinkDevice> LaCrossePairForSec 60</code> zum Beispiel: <code>set myJeeLink LaCrossePairForSec 60</code>.

'''In der neuesten Version unterstützt er auch den SuperJee''' (siehe auch diesen {{Link2Forum|Topic=14786|Message=316924|LinkText=Forenbeitrag}}) mit folgenden Optionen:

* Option 1 (Dual RFM):
:Es kann ein zweiter RFM12B oder RFM69CW angeschlossen werden. Somit können zwei data rates (z.B. 17241 für TX29DTH und 8842 für WS 1600) gleichzeitig empfangen werden. Das geht natürlich auch mit dem toggle mode, nur ist es bei der Wetterstation ärgerlich, wenn man 30 Sekunden lang nichts empfängt und dadurch die alles entscheidende Windböe verpasst.
* Option 2 (BMP180):
:Da der Luftdruck in den Basisstationen gemessen wird, steht er für FHEM nicht zur Verfügung.
Deshalb kann nun optional ein BMP180 oder BMP085 angeschlossen werden. Auch hier wird automatisch erkannt, ob er vorhanden ist.
:Der BMP180 wird mit 3,3V versorgt und SDA mit PC4 und SCL mit PC5 verbunden (siehe die in diesem {{Link2Forum|Topic=14786|Message=316924|LinkText=Forenbeitrag}} angehängte SuperJee-CL.png)

==== Übersicht Kommandos ====
<n>a set to 0 if the blue LED bothers
<n>f initial frequency in kHz (5 kHz steps, 860480 ... 879515) (for RFM #1)
<n>F initial frequency in kHz (5 kHz steps, 860480 ... 879515) (for RFM #2)
<n>h altituide above sea level
<n>m bits 1: 17.241 kbps, 2 : 9.579 kbps, 4 : 8.842 kbps (for RFM #1)
<n>M bits 1: 17.241 kbps, 2 : 9.579 kbps, 4 : 8.842 kbps (for RFM #2)
<n>r use one of the possible data rates (for RFM #1)
<n>R use one of the possible data rates (for RFM #2)
<n>t 0=no toggle, else interval in seconds (for RFM #1)
<n>T 0=no toggle, else interval in seconds (for RFM #2)
v show version
<n>y if 1 all received packets will be retransmitted (Relay mode)

==== Relay-Betrieb ====
Der LaCrosse Sketch ermöglicht auch den Relay-Betrieb zur Reichweitenverbesserung. Er funktioniert damit ähnlich wie z. B. ein WLAN Range Extender. Wenn der Sketch für den Relay-Betrieb konfiguriert ist, wird jedes empfangene IT+ Datenpaket, das eine gültige Prüfsumme hat, direkt nach dem Empfang wieder gesendet.

Das Prinzip ist generell recht einfach:
# JeeLink im Sketch als Relais konfigurieren und flashen: Um den Relay Betrieb einzuschalten, muss im Sketch der Parameter
:<code>bool RELAY = 1;</code> auf den Wert 1 gesetzt werden. Falls die LED stört, kann diese im Sketch durch Setzen des Parameters
:<code>#define ENABLE_ACTIVITY_LED 0</code> auf 0 gesetzt werden.
# Auf "halber Strecke" (d.h. irgendwo zwischen dem primären Sender und dem entfernten Empfänger) auf ein USB-Steckernetzteil stecken. Der JeeLink arbeitet in diesem Modus "autonom", er benötigt also lediglich einen Spannungsversorgung.

Der JeeLink empfängt und decodiert alle Protokolle, die er auch für FHEM unterstützt. Wenn er ein Paket empfangen hat (egal von welchem Sensor) und CRC OK war, dann sendet er es wieder aus. Der JeeLink am FHEM merkt keinen Unterschied. Falls ein Paket es doch bis zum FHEM direkt geschafft hat, kommt es dort zweimal an. Diese Situation muss in FHEM behandelt werden.

Details zu diesem Betriebsmodus sind in diesen Forenbeiträgen ({{Link2Forum|Topic=14786|Message=165153|LinkText=LaCrosse}} bzw. {{Link2Forum|Topic=26494|Message=196648|LinkText=EMT7110}}) zu finden.

==== Frequenzanpassung ====
Ab Version LaCrosseITPlusReader.10.1e wurde der Sketch so erweitert, dass man von FHEM aus die Frequenz setzen kann. Dazu versteht der Sketch das neue Kommando "f":
:<code>set myJeeLink raw 868295f</code>
setzt die Frequenz auf 868295 kHz.

Die Frequenz kann im Bereich von 860480 kHz bis 879515 kHz in 5kHz -Schritten eingestellt werden.
Details dazu in diesem {{Link2Forum|Topic=14786|Message=222541}} im Forum. Die Frequenzanpassung ist insbesondere beim 30.3155.WD häufig erforderlich, weshalb er als kritisch einzustufen und nicht zu empfehlen ist (siehe {{Link2Forum|Topic=14786|Message=352550|LinkText=Forenbeitrag}}).

==== Toggle und Datenrate ====
Toggle
t: toggle time
20t = alle 20 Sekunden die Datenrate wechseln

Datenrate
m: toggle mode
bits: 1= 17.241 kbps, 2= 9.579 kbps, 4= 8.842 kbps
3m ist 17.241 kbps (TX29) und 9.579 kbps (TX35)

Beispiel initCommands
6m 30t v
Zwischen 8.842 kbps und 9.579 kbps wechseln (4+2=6), alle 30 Sekunden

==== Unterstützte Sensoren und Aktoren incl. Wetterstation WS 1600 ====
{{Randnotiz|RNTyp=y|RNText=Die Ausführungen in diesem Abschnitt gelten ab der Version 10.1q auch für die Wetterstation WS1080.

'''Wichtig WS1800''': die WS1080 gibt es (unter gleichem Namen) in einer "OOK"- und in einer "FSK"-Version.
* Der LaCrosse Sketch und das LaCrosseGateway können nur die FSK-Version empfangen, die OOK-Version wird nicht unterstützt.
* Die FSK-Version ist zu erkennen an einem runden grünen Aufkleber im Batteriefach der Station mit dem Aufdruck "PASS 7". Details dazu in {{Link2Forum|Topic=14786|Message=363766|LinkText=diesem Forenbeitrag}}
}}

Die in der folgenden Liste (Quelle: {{Link2Forum|Topic=14786|Message=164801|LinkText=FHEM Forum}}) aufgeführten Sensoren wurden bisher erfolgreich getestet:

{| class="wikitable"
!Bezeichnung !! Datenrate !! Link / Hinweise
|-
| TX21IT || 17.241 kbps ||
|-
| TX25-IT || 17.241 kbps ||
|-
| TX27-IT || 17.241 kbps ||
|-
| TX29-IT || 17.241 kbps ||
|-
| TX29DTH-IT || 17.241 kbps ||
|-
| TX37 || 17.241 kbps ||
|-
| TX35TH-IT || 9.579 kbps ||
|-
| TX35DTH-IT || 9.579 kbps ||
|-
| 30.3143.IT || 17.241 kbps ||
|-
| 30.3144.IT || 17.241 kbps || ({{Link2Forum|Topic=17662|LinkText=Forenthread}})
|-
| 30.3147.IT || 17.241 kbps ||
|-
| 30.3155WD || 9.579 kbps || kritisch; nicht zu empfehlen; siehe {{Link2Forum|Topic=14786|Message=352550|LinkText=Forenbeitrag}}
|-
| 30.3156WD || 9.579 kbps || Batterie-kritisch. Funktioniert schlecht mit Akkus!
|-
| 30.3187.IT || 17.241 kbps || haben alle die gleiche ID, daher nur einzeln verwendbar ({{Link2Forum|Topic=64636|LinkText=Forenthread}})
|-
| WT440XH || 17.241 kbps ||
|-
| WS 1600 (TX22) || 8.842 kbps || ({{Link2Forum|Topic=14786|Message=297293|LinkText=Forenbeitrag}})
|-
| WS 1080 || 17.241 kbps || Bitte Hinweise beachten! ({{Link2Forum|Topic=14786|Message=363766|LinkText=Forenbeitrag}})
|-
| [[EMT7110]] || 9.579 kbps || ({{Link2Forum|Topic=26494|LinkText=Forenthread}})
|-
| LevelSender || 17.241 kbps || ({{Link2Forum|Topic=23217|LinkText=Forenthread}})

|}

Werden Sensoren mit unterschiedlichen Datenraten gleichzeitig betrieben, ist der Toggle Modus einzustellen, z.B. mit dem Befehl
:<code>initCommands 6m 30t v </code>
wobei ''30t'' für "Toggle Modus, alle 30 Sekunden" steht.

=== Energy Count 3000 Sketch ===
Der Sketch für die Unterstützung der Energy Count 3000 Zwischenstecker kann aus dem [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino/ FHEM-Repository] heruntergeladen werden.

Das FHEM Modul dazu (36_EC3000.pm) ist genau wie die Module für JeeLink (36_JeeLink.pm) und PCA301 (36_PCA301.pm) mittlerweile im aktuellen FHEM enthalten.

=== JeeLabs RoomNode ===
Eine Beschreibung zum Empfang der JeeLabs RoomNodes ist in {{Link2Forum|Topic=11648|Message=92037|LinkText=diesem Forenbeitrag}} enthalten.

=== JeeLink LED deaktivieren ===
Ein "dauerhaftes" Deaktivieren der LED des JeeLink ist möglich mit
:<code>define not.global notify global:INITIALIZED set myJeeLink led off</code>
damit wird, sobald FHEM komplett gestartet ist, von FHEM der Befehl zum Ausschalten der LED gesendet. Alternativ kann mit
:<code>attr myJeeLink initCommands 0a v</code>
dem Sketch die Anweisung gegeben werden, bei der Initialisierung die LED zu deaktivieren.
''Quelle: dieser {{Link2Forum|Topic=27161|LinkText=Forenthread}}''

=== Weitergehende Informationen ===
Hinweise zum Betrieb eines JeeLink mit FHEM finden sich aktuell in größerer Anzahl in verschiedenen Diskussionen im Forum:
* {{Link2Forum|Topic=11648|LinkText=JeeLink / PCA301}} - Analyse des Funkprotokolls; Anfänge der Entstehung der PCA301 Unterstützung in FHEM.
* {{Link2Forum|Topic=14786|LinkText=JeeLink / LaCrosse}} - JeeLink Modul zur Einbindung von La Crosse
* {{Link2Forum|Topic=11648|Message=92019|LinkText=JeeLink / EC3000}} - Anfänge der Entstehung der EC3000 Unterstützung in FHEM.
* Hinweise zu {{Link2Forum|Topic=11648|Message=92037|LinkText=JeeLabs RoomNode}} und anderen JeeLab Nodes
* {{Link2Forum|Topic=25399|Message=183910|LinkText=JeeLink mit FHEM2FHEM nutzen}}

== Bekannte Probleme ==
* Beim Betrieb an einer [[AVM Fritz!Box|FritzBox]] wird der JeeLink unter Umständen als ''Für die Nutzung mit dem USB-Fernanschluss reserviert'' angezeigt. In diesem Fall muss die Reservierung deaktiviert/aufgehoben werden (Details dazu in diesem {{Link2Forum|Topic=16579|LinkText=Forenthread}}).
* Die Version ''v3c'' des JeeLink funktioniert (Stand 06/2015) nur mit dem LaCrosse Sketch. PCA301 und EC3000 Sketch sind auf den JeeLink Classic beschränkt (siehe unter anderem Diskussion im Forum, startend {{Link2Forum|Topic=11648|Message=308267|LinkText=hier}}).

== Weblinks ==
* [http://jeelabs.com/products/jeelink JeeLabs], JeeLink Hersteller
* [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino/ PCA301 Sketch] im SVN
* [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino/ LaCrosse Sketch] im SVN
* [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino/ EC3000 Sketch] im SVN
* [http://blog.moneybag.de/hausautomation-fhem-mit-funksteckdose-energiemessung-elv-pca-301/ Blog] zum Thema JeeLink zur Anbindung von PCA301 und von LaCrosse Temperatursensoren an FHEM
* {{Link2Forum|Topic=23217|LinkText=LevelSender}} Tankfüllstand mit JeeLink empfangen

[[Kategorie:Interfaces]]
[[Kategorie:Other Components]]
[[Kategorie:868MHz]]
[[Kategorie:433MHz]]

JeeLink

2021-01-09T12:13:44Z

PeMue: Erklärung für Relay Betrieb eingefügt

'''JeeLink''' ist ein RF-Gerät im Formfaktor eines USB-Sticks mit externer Antenne.
{{Infobox Hardware
|Bild=JeeLink.jpg
|Bildbeschreibung=JeeLink mit Drahtantenne
|HWProtocol=PCA301, EC3000, RoomNode oder LaCrosse und EMT7110
|HWType=[[Interface]]
|HWCategory=
|HWComm=433/868/913 MHz
|HWChannels=?
|HWVoltage=5 V
|HWPowerConsumption=ca. 90 mA
|HWPoweredBy=USB
|HWSize=23*67*9mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#JeeLink 36_JeeLink.pm]
|ModOwner={{Link2FU|430|Andre / justme1968}}
|HWManufacturer=JeeLabs
}}

== Beschreibung ==
Vergleichbar mit dem [[CUL]] von Busware, ist der JeeLink ein USB-Stick, mit dem Funk-Hausautomations-Komponenten angebunden werden können. CUL und JeeLink unterscheiden sich im Funkmodul (CUL -> CC1101; JeeLink -> RF12B), die nicht miteinander kompatibel sind. Daher kann man auch keinen CUL als JeeLink-Ersatz nutzen!

Den JeeLink gibt es in einer
* 433 MHz Version
* 868 MHz Version (Standard)
* 915 MHz Version (Betrieb in Europa nicht zugelassen)

== Vorbereitung JeeLink ==
Um mit dem JeeLink die jeweils gewünschten Signale empfangen zu können, ist er zunächst mit der passenden Firmware zu versorgen. Dies kann auf zwei Arten geschehen. Entweder durch das selber kompilieren der Software und das Flashen aus der Arduino IDE oder aus FHEM heraus mit einem aktuellen Firmwareimage das per update mit ausgeliefert wird.

=== Selber Kompilieren ===
[[Datei:JeeLink_flashen_1.jpg|mini|100px|rechts|Vorbereitung: Arduino einrichten]]
Um den JeeLink mit FHEM benutzen zu können, muss (mit der Arduino Software / Entwicklungsumgebung (IDE)) eine spezifische "Firmware" (ein Sketch) auf dem JeeLink installiert werden. Die generelle Vorbereitung für diese Aktion ist unabhängig vom benötigten Sketch und besteht aus den folgenden Schritten:
* Für Windows oder Mac OS X den passenden [http://www.ftdichip.com/Drivers/VCP.htm FTDI Treiber] installieren, unter Linux ist dieser meist schon vorhanden
* Installation der [http://arduino.cc/de/Guide/HomePage Arduino Software] für die benutzte Plattform (verfügbar sind Windows, Mac OS X und Linux)
* Je nach Sketch einbinden der [https://github.com/jcw/jeelib/archive/master.zip Jeelabs Library] in die Arduino IDE
* Herunterladen des benötigten Sketches (aus [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino FHEM/contrib])
* Anschließen des JeeLink an einen USB-Anschluss des Rechners mit der Arduino IDE
* Start der Arduino Software und JeeLink flashen

=== JeeLink aus Arduino flashen ===
[[Datei:JeeLink_flashen_2.jpg|mini|100px|rechts|JeeLink Flashen]]
* Anschließen des JeeLink an einen USB-Anschluss des Rechners mit der Arduino IDE
* Start der Arduino Software
* Seriellen Port des JeeLink auswählen
* Einstellungen: in den Tools als Board "Arduino Uno" auswählen
* Sketch mit "Datei öffnen" auswählen
* Upload klicken

=== JeeLink aus FHEM flashen ===
* Auf dem FHEM System muss "avrdude" installiert sein. Das kann z.B. über die "normale" Linux Paketverwaltung geschehen.
** Auf dem Paspberry (Raspbian Linux) funktioniert die Installation von "avrdude" mit <code>sudo apt-get update</code> und dannach <code>sudo apt-get install avrdude</code>
* mit <code>set <JeeLinkDevice> flash [firmware]</code> wird das Flashen angestossen<br><code>firmware</code> kann LaCrosse, PCA301 oder EC3000 sein. Wenn <code>firmware</code> nicht angegeben wird versucht FHEM den Namen der zu flashenden Firmware aus der zur Zeit installierten Firmware abzuleiten.
* im FHEM Log kann der Ausgang des Flashvorgangs kontrolliert werden
* über das <code>flashCommand</code> Attribut lässt sich das Kommando zum Flashen an besondere Anforderungen anpassen

'''Vorsicht bei Jeelink Clones!'''

Jeelink Clones basierend auf dem Arduino Nano haben normalerweise keinen Optibootloader drauf im Gegensatz zum Original JeeLink und JeeNode.

Konsequenz:

Beim "Nano Clone" und ähnliches muß man zum flashen in FHEM die Baudrate setzen mit "-b 57600"

Original JeeLink, original JeeNode, und alle Arduinos, die einen Optibootloader drauf haben flashen in FHEM ohne "-b 57600"

== Hinweise zum Betrieb mit FHEM ==
Um den JeeLink (erstmalig) mit FHEM benutzen zu können, muss dieser erfolgreich geflasht worden sein.
* JeeLink an den FHEM-Rechner anschließen
* Auf Linux Systemen kann es notwendig sein, mit <code>mknod /dev/ttyUSB0 c 188 0</code> das Device anzulegen (bitte erst überprüfen, ob der Stick nicht automatisch erkannt wird)

=== Definition in fhem.cfg ===
Erforderliche Definitionen in FHEM:
:<code>define myJeeLink JeeLink /dev/ttyUSBx@57600</code>
*'''USBx''' ist anzupassen an die aktuell benutzte Schnittstelle, 0 wenn sonst nichts am USB-Port hängt
*x=0,1,2, usw.

Die [http://fhem.de/commandref.html#autocreate autocreate-Funktion] sollte aktiv sein. Alle erkannten Devices (PCA301, LaCrosse Sensoren incl. IT+ Wetterstation WS1600, EMT7110, EC3000, und RoomNodes) werden dann automatisch angelegt, sobald die jeweiligen Daten empfangen werden.

Pro Geräte-Art/Protokoll muss ein eigener JeeLink mit dem passenden Sketch zum Empfang dieser Daten vorhanden sein (es kann jeweils nur ein Sketch im JeeLink aktiv sein und es gibt (zumindest derzeit (04/2014)) keinen Sketch, der mehr als eines der Protokolle abdeckt).

'''Anmerkung:''' Der LaCrosse Sketch deckt sowohl die LaCrosse Temperatursensoren, die IT+ Wetterstation WS1600 als auch den Energieverbrauchssensor EMT7110 ab.

=== PCA301 Sketch ===
Der Sketch für die Unterstützung der ''PCA301 Funkschaltsteckdose mit Energieverbrauchsmessung'' (PCA301-pcaSerial.zip) kann aus dem [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino/ FHEM-Repository] heruntergeladen werden. Details zur Benutzung finden sich im Artikel zur [[PCA301 Funkschaltsteckdose mit Energieverbrauchsmessung|PCA301]].

Unter Umständen werden die Signale der PCA301 nicht empfangen. Insbesondere mit selbst erstellten "JeeLinks" durch wahrscheinlich hohe Bauteiltoleranzen der RF12B Sendeeinheiten. Mit dem im Sketch voreingestellten rf12_center_freq = 0xA6FE (868,9500 MHz) bekommt man in diesem Fall keine Steckdose angelernt.

==== Frequenzanpassung über modifizierten Sketch ====
Durch Tests mittels ''set <myJeeLink> raw +'' bzw ''set <myJeeLink> raw -'' kann man dann ermitteln, ob die Funksignale z.B. ab A703 bis A715 empfangen werden. Das entspricht einem Frequenzbereich zwischen 868,9750 MHz und 869,0550 MHz.
Die Mitte ist die Lösung, die man dann im Sketch ändern muss:
:<code>static uint16_t rf12_center_freq = 0xA70C;</code>
Anschließend auf den JeeLink neu flashen.

==== Frequenzanpassung über Attribut initCommands ====
Über das <code>initCommands</code> lässt sich die gefundene Frequenz einstellen, ohne dass die Firmware verändert werden muss.
:<code>attr <JeeLinkDevice> initCommands <hhhh>h</code>

=== LaCrosse Sketch ===
Der Sketch für die Unterstützung der LaCrosse Temperatursensoren, der IT+ Wetterstation WS1600 und des Energieverbrauchssensors EMT7110 so wie auch TechnoLine Sensoren (Temperatur, Luftfeuchte,...).<br>

* Er kann aus dem [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino FHEM-Repository] heruntergeladen werden.
* Alternative ist den Sketch direkt über FHEM zu flashen <code>set <JeeLinkDevice> flash LaCrosse</code> z.B.: <code>set myJeeLink flash LaCrosse</code> zuvor sollte aber ein FHEM update mit <code>update</code> durchgeführt werden.
<br>

'''Sensoren anlernen:
Mit folgenden Befehl hat man die Möglichkeit 60 Sekunden ein Gerät anzulernen. Das Gerät erscheint dann unter der Rubrik LaCrosse. <code>set <JeeLinkDevice> LaCrossePairForSec 60</code> zum Beispiel: <code>set myJeeLink LaCrossePairForSec 60</code>.

'''In der neuesten Version unterstützt er auch den SuperJee''' (siehe auch diesen {{Link2Forum|Topic=14786|Message=316924|LinkText=Forenbeitrag}}) mit folgenden Optionen:

* Option 1 (Dual RFM):
:Es kann ein zweiter RFM12B oder RFM69CW angeschlossen werden. Somit können zwei data rates (z.B. 17241 für TX29DTH und 8842 für WS 1600) gleichzeitig empfangen werden. Das geht natürlich auch mit dem toggle mode, nur ist es bei der Wetterstation ärgerlich, wenn man 30 Sekunden lang nichts empfängt und dadurch die alles entscheidende Windböe verpasst.
* Option 2 (BMP180):
:Da der Luftdruck in den Basisstationen gemessen wird, steht er für FHEM nicht zur Verfügung.
Deshalb kann nun optional ein BMP180 oder BMP085 angeschlossen werden. Auch hier wird automatisch erkannt, ob er vorhanden ist.
:Der BMP180 wird mit 3,3V versorgt und SDA mit PC4 und SCL mit PC5 verbunden (siehe die in diesem {{Link2Forum|Topic=14786|Message=316924|LinkText=Forenbeitrag}} angehängte SuperJee-CL.png)

==== Übersicht Kommandos ====
<n>a set to 0 if the blue LED bothers
<n>f initial frequency in kHz (5 kHz steps, 860480 ... 879515) (for RFM #1)
<n>F initial frequency in kHz (5 kHz steps, 860480 ... 879515) (for RFM #2)
<n>h altituide above sea level
<n>m bits 1: 17.241 kbps, 2 : 9.579 kbps, 4 : 8.842 kbps (for RFM #1)
<n>M bits 1: 17.241 kbps, 2 : 9.579 kbps, 4 : 8.842 kbps (for RFM #2)
<n>r use one of the possible data rates (for RFM #1)
<n>R use one of the possible data rates (for RFM #2)
<n>t 0=no toggle, else interval in seconds (for RFM #1)
<n>T 0=no toggle, else interval in seconds (for RFM #2)
v show version
<n>y if 1 all received packets will be retransmitted (Relay mode)

==== Relay-Betrieb ====
Der LaCrosse Sketch ermöglicht auch den Relay-Betrieb zur Reichweitenverbesserung. Er funktioniert damit ähnlich wie z. B. ein WLAN Range Extender. Wenn der Sketch für den Relay-Betrieb konfiguriert ist, wird jedes empfangene IT+ Datenpaket, das eine gültige Prüfsumme hat, direkt nach dem Empfang wieder gesendet.

Das Prinzip ist generell recht einfach:
# JeeLink im Sketch als Relais konfigurieren und flashen.
# Auf "halber Strecke" (d.h. irgendwo zwischen dem primären Sender und dem entfernten Empfänger) auf ein USB-Steckernetzteil stecken. Der JeeLink arbeitet in diesem Modus "autonom", er benötigt also lediglich einen Spannungsversorgung.
Um den Relay Betrieb einzuschalten, muss im Sketch der Parameter
:<code>bool RELAY = 1;</code>
auf den Wert 1 gesetzt werden. Falls die

Der JeeLink empfängt und decodiert alle Protokolle, die er auch für FHEM unterstützt. Wenn er ein Paket empfangen hat (egal von welchem Sensor) und CRC OK war, dann sendet er es wieder aus. Der JeeLink am FHEM merkt keinen Unterschied. Falls ein Paket es doch bis zum FHEM direkt geschafft hat, kommt es dort zweimal an. Diese Situation muss in FHEM behandelt werden.

Details zu diesem Betriebsmodus sind in diesen Forenbeiträgen ({{Link2Forum|Topic=14786|Message=165153|LinkText=LaCrosse}} bzw. {{Link2Forum|Topic=26494|Message=196648|LinkText=EMT7110}}) zu finden.

==== Frequenzanpassung ====
Ab Version LaCrosseITPlusReader.10.1e wurde der Sketch so erweitert, dass man von FHEM aus die Frequenz setzen kann. Dazu versteht der Sketch das neue Kommando "f":
:<code>set myJeeLink raw 868295f</code>
setzt die Frequenz auf 868295 kHz.

Die Frequenz kann im Bereich von 860480 kHz bis 879515 kHz in 5kHz -Schritten eingestellt werden.
Details dazu in diesem {{Link2Forum|Topic=14786|Message=222541}} im Forum. Die Frequenzanpassung ist insbesondere beim 30.3155.WD häufig erforderlich, weshalb er als kritisch einzustufen und nicht zu empfehlen ist (siehe {{Link2Forum|Topic=14786|Message=352550|LinkText=Forenbeitrag}}).

==== Toggle und Datenrate ====
Toggle
t: toggle time
20t = alle 20 Sekunden die Datenrate wechseln

Datenrate
m: toggle mode
bits: 1= 17.241 kbps, 2= 9.579 kbps, 4= 8.842 kbps
3m ist 17.241 kbps (TX29) und 9.579 kbps (TX35)

Beispiel initCommands
6m 30t v
Zwischen 8.842 kbps und 9.579 kbps wechseln (4+2=6), alle 30 Sekunden

==== Unterstützte Sensoren und Aktoren incl. Wetterstation WS 1600 ====
{{Randnotiz|RNTyp=y|RNText=Die Ausführungen in diesem Abschnitt gelten ab der Version 10.1q auch für die Wetterstation WS1080.

'''Wichtig WS1800''': die WS1080 gibt es (unter gleichem Namen) in einer "OOK"- und in einer "FSK"-Version.
* Der LaCrosse Sketch und das LaCrosseGateway können nur die FSK-Version empfangen, die OOK-Version wird nicht unterstützt.
* Die FSK-Version ist zu erkennen an einem runden grünen Aufkleber im Batteriefach der Station mit dem Aufdruck "PASS 7". Details dazu in {{Link2Forum|Topic=14786|Message=363766|LinkText=diesem Forenbeitrag}}
}}

Die in der folgenden Liste (Quelle: {{Link2Forum|Topic=14786|Message=164801|LinkText=FHEM Forum}}) aufgeführten Sensoren wurden bisher erfolgreich getestet:

{| class="wikitable"
!Bezeichnung !! Datenrate !! Link / Hinweise
|-
| TX21IT || 17.241 kbps ||
|-
| TX25-IT || 17.241 kbps ||
|-
| TX27-IT || 17.241 kbps ||
|-
| TX29-IT || 17.241 kbps ||
|-
| TX29DTH-IT || 17.241 kbps ||
|-
| TX37 || 17.241 kbps ||
|-
| TX35TH-IT || 9.579 kbps ||
|-
| TX35DTH-IT || 9.579 kbps ||
|-
| 30.3143.IT || 17.241 kbps ||
|-
| 30.3144.IT || 17.241 kbps || ({{Link2Forum|Topic=17662|LinkText=Forenthread}})
|-
| 30.3147.IT || 17.241 kbps ||
|-
| 30.3155WD || 9.579 kbps || kritisch; nicht zu empfehlen; siehe {{Link2Forum|Topic=14786|Message=352550|LinkText=Forenbeitrag}}
|-
| 30.3156WD || 9.579 kbps || Batterie-kritisch. Funktioniert schlecht mit Akkus!
|-
| 30.3187.IT || 17.241 kbps || haben alle die gleiche ID, daher nur einzeln verwendbar ({{Link2Forum|Topic=64636|LinkText=Forenthread}})
|-
| WT440XH || 17.241 kbps ||
|-
| WS 1600 (TX22) || 8.842 kbps || ({{Link2Forum|Topic=14786|Message=297293|LinkText=Forenbeitrag}})
|-
| WS 1080 || 17.241 kbps || Bitte Hinweise beachten! ({{Link2Forum|Topic=14786|Message=363766|LinkText=Forenbeitrag}})
|-
| [[EMT7110]] || 9.579 kbps || ({{Link2Forum|Topic=26494|LinkText=Forenthread}})
|-
| LevelSender || 17.241 kbps || ({{Link2Forum|Topic=23217|LinkText=Forenthread}})

|}

Werden Sensoren mit unterschiedlichen Datenraten gleichzeitig betrieben, ist der Toggle Modus einzustellen, z.B. mit dem Befehl
:<code>initCommands 6m 30t v </code>
wobei ''30t'' für "Toggle Modus, alle 30 Sekunden" steht.

=== Energy Count 3000 Sketch ===
Der Sketch für die Unterstützung der Energy Count 3000 Zwischenstecker kann aus dem [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino/ FHEM-Repository] heruntergeladen werden.

Das FHEM Modul dazu (36_EC3000.pm) ist genau wie die Module für JeeLink (36_JeeLink.pm) und PCA301 (36_PCA301.pm) mittlerweile im aktuellen FHEM enthalten.

=== JeeLabs RoomNode ===
Eine Beschreibung zum Empfang der JeeLabs RoomNodes ist in {{Link2Forum|Topic=11648|Message=92037|LinkText=diesem Forenbeitrag}} enthalten.

=== JeeLink LED deaktivieren ===
Ein "dauerhaftes" Deaktivieren der LED des JeeLink ist möglich mit
:<code>define not.global notify global:INITIALIZED set myJeeLink led off</code>
damit wird, sobald FHEM komplett gestartet ist, von FHEM der Befehl zum Ausschalten der LED gesendet. Alternativ kann mit
:<code>attr myJeeLink initCommands 0a v</code>
dem Sketch die Anweisung gegeben werden, bei der Initialisierung die LED zu deaktivieren.
''Quelle: dieser {{Link2Forum|Topic=27161|LinkText=Forenthread}}''

=== Weitergehende Informationen ===
Hinweise zum Betrieb eines JeeLink mit FHEM finden sich aktuell in größerer Anzahl in verschiedenen Diskussionen im Forum:
* {{Link2Forum|Topic=11648|LinkText=JeeLink / PCA301}} - Analyse des Funkprotokolls; Anfänge der Entstehung der PCA301 Unterstützung in FHEM.
* {{Link2Forum|Topic=14786|LinkText=JeeLink / LaCrosse}} - JeeLink Modul zur Einbindung von La Crosse
* {{Link2Forum|Topic=11648|Message=92019|LinkText=JeeLink / EC3000}} - Anfänge der Entstehung der EC3000 Unterstützung in FHEM.
* Hinweise zu {{Link2Forum|Topic=11648|Message=92037|LinkText=JeeLabs RoomNode}} und anderen JeeLab Nodes
* {{Link2Forum|Topic=25399|Message=183910|LinkText=JeeLink mit FHEM2FHEM nutzen}}

== Bekannte Probleme ==
* Beim Betrieb an einer [[AVM Fritz!Box|FritzBox]] wird der JeeLink unter Umständen als ''Für die Nutzung mit dem USB-Fernanschluss reserviert'' angezeigt. In diesem Fall muss die Reservierung deaktiviert/aufgehoben werden (Details dazu in diesem {{Link2Forum|Topic=16579|LinkText=Forenthread}}).
* Die Version ''v3c'' des JeeLink funktioniert (Stand 06/2015) nur mit dem LaCrosse Sketch. PCA301 und EC3000 Sketch sind auf den JeeLink Classic beschränkt (siehe unter anderem Diskussion im Forum, startend {{Link2Forum|Topic=11648|Message=308267|LinkText=hier}}).

== Weblinks ==
* [http://jeelabs.com/products/jeelink JeeLabs], JeeLink Hersteller
* [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino/ PCA301 Sketch] im SVN
* [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino/ LaCrosse Sketch] im SVN
* [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino/ EC3000 Sketch] im SVN
* [http://blog.moneybag.de/hausautomation-fhem-mit-funksteckdose-energiemessung-elv-pca-301/ Blog] zum Thema JeeLink zur Anbindung von PCA301 und von LaCrosse Temperatursensoren an FHEM
* {{Link2Forum|Topic=23217|LinkText=LevelSender}} Tankfüllstand mit JeeLink empfangen

[[Kategorie:Interfaces]]
[[Kategorie:Other Components]]
[[Kategorie:868MHz]]
[[Kategorie:433MHz]]

Raspberry Pi

2020-07-19T15:12:08Z

PeMue:

Beim '''Raspberry Pi''' handelt es sich um einen postkartengroßen Einplatinen-Computer, der von der Raspberry Pi Foundation entwickelt wird. Die Hardware basiert auf dem BCM 283x SoC (System-on-Chip) von Broadcom, einem ARM-Prozessor. Zu Hardwaredetails und den verschiedenen Modellen sowie Produktentwicklungen siehe [http://de.wikipedia.org/wiki/Raspberry_Pi#Hardware Wikipedia].
Dank der kleinen Abmessungen, dem recht geringen Energieverbrauch (bis ca. 4 Watt) sowie der günstigen Anschaffungskosten (ca. 30€) ist der Raspberry Pi eine attraktive Hardware für die Heimautomatisierung mit FHEM. Er ist dank dem Linux-Betriebssystem vollständig kompatibel zur aktuell vorhandenen und von FHEM unterstützen Hardware. Das derzeit empfohlene Standard-Image zum Betrieb des Raspberry Pi ist die auf Debian basierende Raspberry Pi OS Distribution (ab Mitte 2019 ''Buster'').

== Installation / Setup ==
=== Betriebssystem ===
====Vorbemerkung====
Raspberry Pi OS ist direkt bei raspberrybi.org unter https://www.raspberrypi.org/downloads/raspberry-pi-os/ herunterladbar. Die folgende Anleitung gilt für die lite-Version ohne grafischen Desktop und für die Modelle für B, B+, B2, B3, B3+, Zero W. (Stand Juni 2018)

Alle in diesem Abschnitt verwendeten Code Blöcke benötigen root Rechte. Deshalb bitte immer am Besten im Kontext <code>sudo su</code> ausführen. Man kann auch einzelne Befehle mit sudo davor ausführen, allerdings wird die Berechtigung bei Pipe Befehlen nicht durchgereicht.

Alle Dateien müssen im Linux-Format (nur LF als Zeilenende) erzeugt/editiert werden! Unbedingt einen geeigneten Editor verwenden und auf das Format beim Speichern achten!

====SD-Karte vorbereiten====
Die heruntergeladene Datei muss entpackt und auf die Speicherkarte geschrieben werden. Es gibt dazu verschiedene Tools je nach Betriebssystem. Für Windows ist windisk32imager zu empfehlen, Projektseite [https://sourceforge.net/projects/win32diskimager/]. Für Mac OS gibt es den Pi Filler.

Detaillierte Anleitungen zur Vorgehensweise finden sich für die Betriebssysteme Linux, Mac OS und Windows unter [https://www.raspberrypi.org/documentation/installation/installing-images/README.md Writing an image to the SD card]

Die SD Card enthält nun zwei Partitionen/Laufwerke, wobei das erste Laufwerk unter alle Betriebssystemen lesbar ist. In diesem Laufwerk (/boot) müssen jetzt noch zwei Dateien erzeugt werden:
* eine leere Datei mit dem Namen ssh, um den (headless) Zugriff per ssh zu ermöglichen (Pi Filler macht dies automatisch). Hinweis: Eine spätere Aktivierung von SSH ist mit <code>sudo raspi-config</code> (Punkt 5 "Interfacing Options", dann Punkt 2 SSH) möglich, erfordert dann aber Tastatur und Monitor am RPi.
* eine Textdatei im Linux Format mit Namen wpa_supplicant.conf und folgendem Inhalt, wenn der Pi sofort mit WLAN starten soll.

<pre>country=DE
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
network={
ssid="FRITZ!Box 7490"
psk="12345678901234567890"
}
</pre>
* SD Karte auswerfen.
* SD Karte in Raspberry Pi stecken und booten.

Alternativ kann auch Monitor und Tastatur verwendet werden.

====Anmeldung und Grundkonfiguration====
Default raspberrypi-os: Host raspberrypi, User pi, Passwort raspberry

Default ubuntu: Host ubuntu, User ubuntu, Passwort ubuntu

Anmeldung entweder lokal oder mit dem Befehl: ssh <user>@<hostname>

Das Passwort sollte geändert werden, dazu dem Sicherheitshinweis folgen und <code>passwd</code> eingeben.

Alle unten genannten Befehle müssen mit erhöhten Rechten ausgeführt werden (z. B. sudo)!

Als Erstes sollte: Zeitzone, Sprache und Hostname angepasst werden.
Entweder Menügeführt mit <code>sudo raspi-config</code>
oder per Script / Shell Befehle:

<source lang="bash"># Zeitzone einstellen & Zeitsynchronisierung über das Internet aktivieren
timedatectl set-timezone Europe/Berlin
timedatectl set-ntp true

# Konfigurieren lokale Sprache deutsch
sed -i -e 's/# de_DE.UTF-8 UTF-8/de_DE.UTF-8 UTF-8/' /etc/locale.gen
locale-gen
localectl set-locale LANG=de_DE.UTF-8 LANGUAGE=de_DE

# Hostname
hostnamectl set-hostname mymachine

# System aktualisieren
apt-get update
apt-get upgrade

#Neustart
reboot</source>

Am Anfang sollte man Befehle nicht verketten, sondern immer auf die Ausgabe warten (es sei denn, man hat Erfahrung): also kein <code>apt-get update && apt-get upgrade </code>. Ebenso sollte man nicht mit automatischen Bestätigungen arbeiten, also kein upgrade mit "-y". Nach einer Installation ist ein aufräumen immer gut, also:
<source lang="bash">
apt-get autoremove
apt-get clean
apt-get purge $(dpkg --get-selections | grep deinstall | cut -f1 | xargs)
</source>

====Verwendung UART für Zusatzmodule====
Einige Aufsteckmodule (z.B. HM-MOD-RPI-PCB) für den GPIO Port verwenden die serielle Schnittstelle UART. Der Zugriff auf diese serielle Schnittstelle erfordert eine modellabhängige Konfiguration.

Bei allen Modellen muss die Verwendung der seriellen Linux console an ttyAMA0 deaktiviert werden:
<source lang="bash"># seriell-getty Dienst für ttyAMA0 dauerhaft deaktivieren
systemctl stop serial-getty@ttyAMA0.service
systemctl disable serial-getty@ttyAMA0.service
systemctl mask serial-getty@ttyAMA0.service
</source>
Bei den Modellen mit Bluetooth muss die UART aktiviert und umkonfiguriert werden:
<source lang="bash"># serielle Schnittstelle aktivieren und mit BT Schnittstelle tauschen
# für Raspberry Pi OS
config="/boot/config.txt"
# für Ubuntu
#config="/boot/firmware/usercfg.txt"

bash -c "cat <<EOF >> $config
enable_uart=1
dtoverlay=miniuart-bt
core_freq=250
EOF"
</source>
Die config Datei von ubuntu verwendet den Befehl include usercfg.txt. Mit Erscheinen des Pi 4 wurden die overlay Dateien umbenannt (Start mit Pi3- entfernt) die alten Namen funktionieren aber noch.

Um die Konfiguration abzuschließen ist ein Neustart erforderlich
<source lang="bash">#Neustart erforderlich
reboot</source>

====Troubleshooting====
'''Kontrolle der seriellen Schnittstelle'''

Der Befehl <code>ls -l /dev/ttyAMA0</code> muss folgende Ausgabe liefern.
crw-rw---- 1 root dialout 204, 64 Jun 7 22:56 /dev/ttyAMA0
Sollte dies nicht der Fall sein, muss der Dienst serial-getty@ttyAMA0.service deaktiviert werden!

Kontrolle der Verlinkung von /dev/serial*

Der Befehl <code>ls -l /dev/serial*</code> muss folgende Ausgabe liefern.
* Bei Modellen mit BT und richtiger Konfiguration (funktioniert nur unter Raspberry Pi OS)
lrwxrwxrwx 1 root root 7 Jun 7 22:55 /dev/serial0 -> ttyAMA0
lrwxrwxrwx 1 root root 5 Jun 7 22:55 /dev/serial1 -> ttyS0
* Bei den Modellen ohne BT und richtiger Konfiguration
lrwxrwxrwx 1 root root 7 Jun 8 18:30 /dev/serial0 -> ttyAMA0
Sollte das nicht der Fall sein, sind die Einträge in der /boot/config.txt fehlerhaft.

'''Kontrolle Bluetooth'''

Die Funktion von Bluetooth kann mit dem hcitool überprüft werden. Mit <code>hcitool dev</code> wird das interne BT Gerät mit MAC Adresse angezeigt. Mit <code>hcitool scan</code> bzw. <code>hcitool lescan</code> kann nach sichtbaren Geräten gesucht werden.

Weitergehende Informationen zur Anpassung der Konfiguration von Raspberry Pi OS sind nachzulesen auf https://www.raspberrypi.org/documentation/configuration/.

Sollte die Bluetooth Schnittstelle nach der Installation von FHEM nicht funktionieren, hilft es den Dienst abhängig zu starten, siehe diesen Wiki Artikel [[Fhem.service (systemd unit file)]]

=== FHEM ===
Die Installation von FHEM kann nach der Raspberry Pi OS Installation sehr einfach über das Debian-Repository [http://debian.fhem.de] erfolgen.
* Es wird unbedingt empfohlen zur Grundinstallation zunächst keine Module, USB Sticks oder ähnliche Zusatzbaugruppen an den IO Ports des Raspberry gesteckt zu haben.
* Dieser Abschnitt beschreibt nur die Grundinstallation von FHEM auf einem Raspberry Pi mit Raspberry Pi OS!
* Weitere Installationsschritte sind je nach verwendeten FHEM-Modulen notwendig.
** Informationen hierzu liefert üblicherweise die {{Link2CmdRef}} zum jeweiligen Modul.
** Den weiteren Einstieg in FHEM findet man im Artikel [[Quick-Start]]

==== Der einfache Weg zum aktuellen System ====
Der folgende Befehlsblock ist die praktische Umsetzung der Beschreibung auf http://debian.fhem.de. Bitte unbedingt vor Installation rückversichern, ob es dort (insbesondere unter ''The easy way: use apt-get'') Aktualisierungen gab.
* Dieser Befehlsblock erfordert erhöhte Rechte, also bitte als Erstes <code>sudo su</code> ausführen!
* Beim Kopieren aufpassen! Jede Zeile muss einzeln ausgeführt werden!
<source lang="bash"># von debian.fhem.de installieren - siehe aktuelle Anleitung dort https://debian.fhem.de/
wget -qO - http://debian.fhem.de/archive.key | apt-key add -
echo "deb http://debian.fhem.de/nightly/ /" >> /etc/apt/sources.list
apt-get update
apt-get install fhem
</source>

==== Das offizielle Release ====
Man kann FHEM mit dem Debian-Paket von [https://fhem.de/#Installation fhem.de] installieren. Dieser Weg führt zu einem offiziellen Release, welches aber unter Umständen erheblich vom aktuellen Versions- und Diskussionsstand im Forum abweicht.

Alternativ kann man auch den manuellen Weg von https://debian.fhem.de/ wählen.

==== Empfohlener Patch ====
Da gerade auf dem Raspberry die automatische Erkennung der USB Schnittstellen zu 100% CPU Last führt (FHEM träge und reagiert nicht), wird empfohlen sofort nach der Installation noch diesen "Patch" auszuführen: FHEM starten, wenn alle USB-Geräte ausgesteckt sind. Dann <code>attr initialUsbCheck disable 1</code> in der Kommandozeile in FHEMWEB eingeben, <code>save</code> ausführen und FHEM anschließen wieder mit eingesteckten USB-Geräten neu starten.

==== Deinstallation ====
Man kann FHEM auch wieder spurlos vom System entfernen und ganz von vorn beginnen. Allerdings sollte man sich im Klaren sein, damit ensteht kein jungfräuliches System!
<source lang="bash">sudo apt-get purge fhem
sudo apt-get autoremove
</source>

=== Zusatzpakete bei FHEM-Erst- und Zweitinstallation ===
Nachdem der RPi eingerichtet ist, können weitere Pakete installiert werden. Keines davon ist zwingend erforderlich, um das Grundgerüst von FHEM betreiben zu können. Einige Pakete erhöhen aber den Bedienungskomfort, andere sind zur Nutzung bestimmter weiterer FHEM-Module (siehe {{Link2CmdRef}}) erforderlich.

Hierzu wurden in letzter Zeit mehrere Hilfsmodule entwickelt, die insbesondere bei Wiederinstallation (etwa nach Absturz) wichtig sein können. So zeigt das Modul Installer die installierten Perl-Module an, siehe dazu [https://forum.fhem.de/index.php?topic=98381.15 diesen Thread]

Wenn man eine frühere Installation auf einer anderen SD-Karte installieren möchte und nicht mehr weiß, welche Zusatzpakete man auf der alten Karte installiert hatte, hilft (diese und nachfolgende Hinweise sind aus dem Blog [https://heinz-otto.blogspot.com/2019/07/infos-zur-installation-von-modulen-und.html])
zcat $(ls -tr /var/log/apt/history.log.*.gz)|grep -A1 Start-Date
weiter. Hier werden frühere Eingaben der Kommandozeile wiedergegeben. Es gibt einen analogen Befehl, um die mit CPAN installierten Pakete anzuzeigen. Dazu muss man das debian Paket perl-doc installiert haben und gibt dann ein
for M in `perldoc -t perllocal|grep Module |sed -e 's/^.*" //'`; do V=`perldoc -t perllocal|awk "/$M/{y=1;next}y" |grep VERSION |head -n 1`; printf "%30s %s\n" "$M" "$V"; done |sort
Ebenso kann man herausfinden, ob und durch welches debian-Paket das Perl-Paket installiert wurde. Die zweite Version sucht nur in Paketen die -perl im Namen tragen und läuft damit wesentlich schneller:
s='Device::SerialPort' ## zu diesem Paket wird gesucht
perl -M$s -e '' 2>/dev/null &&echo "Modul $s ist vorhanden"''
for i in $(dpkg -l |grep ^ii| awk '{ print $2 }'|tr -d "\r"|tr "\n" " ");do if dpkg -L $i|grep $s &> /dev/null;then echo $i enthält $s;fi;done
for i in $(dpkg -l |grep ^ii|grep '\-perl'| awk '{ print $2 }'|tr -d "\r"|tr "\n" " ");do if dpkg -L $i|grep $s &> /dev/null;then echo $i enthält $s;fi;done

Es gibt gute Gründe die Installation von Perl Modulen über debian-Pakete der Installation über cpan zu bevorzugen. Dazu zählt die Updatefähigkeit und die Geschwindigkeit. Man kann im Internet nach den Paketen suchen, man kann aber auch einfach die Verfügbarkeit für das lokale System testen. Dazu braucht man das Tool apt-file, welches man zuerst installieren muss. Der letzte Befehl lädt den Infocache lokal und dauert etwas:
sudo apt-get update
sudo apt-get install apt-file
sudo apt-file update
Die folgende Suche nutzt den Umstand, dass in der im Paket enthaltenen Liste der Dateien auch die Doku in der Form "/usr/share/man/man3/IO::File.3perl.gz" enthalten ist. Der search Befehl unten akzeptiert mehrere Modulnamen durch Zeilenumbruch getrennt. In dem Beispiel sind die Modulnamen in einem String durch Leerzeichen getrennt, die Trennung wird in Zeilenumbruch geändert, jede Zeile ergänzt und über stdin an den search Befehl von apt-file übergeben. Die Option -l bewirkt das nur die gefunden Pakete gelistet werden, werden mehrere der abgefragten Modulnamen in einem Paket gefunden, wird es nur einmal gelistet:
s="IO::File Digest::MD5" ##Such-String
echo $s|tr " " "\n"|sed 's/$/./;s/^/\//'|apt-file search -l -f -

Zuletzt eine Übersicht diverser Zusatzpakete.
{| class="wikitable"
! style="width:10%" | Beschreibung
! style="width:10%" | Paketname
! style="width:50%" | Kontext
! style="width:30%" | Installieren
|-
|Zeitserver
|ntpdate
|Setzt die Systemzeit bei Start des RPi. Wird für FHEM benötigt, da es sonst nicht startet.
|<code>sudo apt-get install ntpdate
sudo ntpdate -u de.pool.ntp.org</code>
|-
|Perl JSON
|JSON
|Wird von einigen Modulen benötigt, z.B. harmony, iTunes
|<code>sudo apt-get install libjson-perl</code>
|-
|Samba-Server
|samba
|Mittels Samba kann man z.B. den Ordner /opt/fhem als Share freigeben. Dieser Share kann z.B. im Windows-Explorer als Laufwerk verbunden werden, so dass die Bearbeitung von config- und Programmdateien bequem möglich ist. Hier eine hilfreiche [https://www.elektronik-kompendium.de/sites/raspberry-pi/2007071.htm Kurzanleitung] aus der (wenn man auf einen speziellen user verzichtet) nur die Einträge für smb.conf gesetzt werden müssen.
|<code>sudo apt-get install samba cifs-utils</code>
Danach muss der share definiert werden mittels

<code>sudo nano /etc/samba/smb.conf</code>
|-
|Mailversand
|sendemail (alt: sendEmail)
|Wird benötigt, um Mails versenden zu können, bspw. für Alarm-Benachrichtigungen.
Nach Installation des Paketes benötigt man noch eine Routine in FHEM gemäß [[E-Mail senden#Raspberry Pi]]
|<code>sudo apt-get install sendemail</code> bzw. <code>sudo apt-get install sendEmail</code>
|-
|Wake-on-LAN
|etherwake
|Wird z.B. für das Modul WOL benötigt.
|<code>sudo apt-get install etherwake</code>
|-
|Perl Telnet
|telnet
|Wurde vor Fritz!OS 6.2x z.B. für das Modul [[FRITZBOX]] benötigt, da es eine im Netzwerk vorhandene Fritzbox über deren Telnet-Port ansprach. Mittlerweile wird TR-64 und SOAP verwendet.
|<code>sudo apt-get install libnet-telnet-perl</code>
|-
|Socat
|socat
|Kann verwendet werden, um auf anderen Rechnern im Netzwerk Linux-Befehle oder Skripts auszuführen. Auch können auf Slave-FHEM-Installationen Befehl ausgeführt werden, z.B. mit

<code><nowiki>system("echo 'set lampe on' | /usr/bin/socat - TCP:1.2.3.4:7072");</nowiki></code>

1.2.3.4 muss natürlich durch die IP-Adresse des Zielrechners ersetzt werden.
|<code>sudo apt-get install socat</code>
|-
|Libcrypt
|Libcrypt
|Perl libcrypt, erforderlich falls Homematic-devices mit AES verwendet werden sollen.
|<code>sudo apt-get install libcrypt-rijndael-perl</code>
|-
|libdatetime
|libdatetime
|Perl libdatetime, erforderlich für das Weather-Modul.
|<code>sudo apt-get install libdatetime-format-strptime-perl</code>
|-
|EnOcean XML functions
|libxml simple
|Perl XML::SIMPLE, erforderlich für die XML Funktionen des ENOCEAN Moduls.
|<code>sudo apt-get install libxml-simple-perl</code>
|-
|EnOcean Cryptographic functions
|libcrypt-random-source-perl
|Perl Crypt::Random, erforderlich für die Cryptographic Funktionen des ENOCEAN Moduls.
|<code>sudo /usr/bin/perl -MCPAN -e 'install Crypt::Random'</code>
|}

== Bekannte Probleme ==
=== Netzteil ===
Der RPi verwendet ein USB Netzteil als Spannungsversorgung. Gemessen kann der RPi allein bereits um die 900mA Strom fordern. Das bringt kleine Netzteile, besonders wenn noch CULs oder WLAN Sticks an USB hängen schnell an die Grenze. Die Fehler die daraus resultieren sind Abstürze, Netzwerkprobleme uvm. Daher bitte ein ausreichend starkes Netzteil mit mind. 2000mA oder einen aktiven USB-HUB für die Periperie verwenden.

=== Echtzeituhr ===
Der RPi hat keine [http://de.wikipedia.org/wiki/Echtzeituhr Real-Time-Clock] (RTC), das heißt, dass er nach einem Neustart keine gültige (im Sinne von aktuell) Systemzeit hat, sondern ein Datum in der Vergangenheit. Dieses Problem wird sinnvollerweise mit einer [http://de.wikipedia.org/wiki/Network_Time_Protocol NTP-Konfiguration] oder durch [[Raspberry Pi: RTC Hat|Installation einer Echtzeituhr]] umgangen.

Dabei muss Sorge getragen werden, dass der [http://wiki.debian.org/NTP ntpd] schon einen Datums-/Zeitabgleich gemacht hat, bevor FHEM gestartet wird. Geschieht der Abgleich nicht vorher, sondern erst nachdem FHEM schon läuft, stellt FHEM die Logs zwar auf das nun aktuelle Datum um (die "alten" Logs mit dem eigentlich ungültigen Datum werden natürlich behalten), aber irgendetwas scheint FHEM dabei so zu belasten, dass es eine Last von über 0.8 bis 0.9 erzeugt. Diese Last besteht auf Dauer und verschwindet erst, wenn man das Ganze sauber durchkonfiguriert und FHEM neu gestartet hat. Die hohe Systemauslastung zeigt sich auch in einem sehr trägen Laden der FHEM-Webseiten in einem beliebigen Browser. (siehe {{Link2Forum|Topic=70741}})

=== Last durch Backup (während update) ===
Bei einen [[Update]] von FHEM durch den Befehl <code>update</code> kann durch Setzen des Attributs "<code>attr global backup_before_update 1</code>" automatisch vorab ein [[Backup]] durchgeführt werden. Die (ggf. großen) Log-Dateien werden dabei ebenfalls archiviert. Während der Archivierung ist FHEM blockiert. Durch die beschränkte Leistungsfähigkeit des Raspberry Pi kann das Backup zudem lange dauern. Durch ein "<code>attr global updateInBackground 1</code>" wird ein Backup im Hintergrund ausgeführt (Quelle: {{Link2Forum|Topic=15729}}).

Alternative Möglichkeiten:
* Backup ausschalten und manuell durchführen
* Backup-Befehl anpassen und so große Dateien bzw. Verzeichnisse (log/) nicht archivieren

== Watchdog einrichten ==
Man kann den RPi regelmäßig prüfen lassen, ob FHEM noch läuft und gegebenenfalls einen Neustart durchführen lassen. Eine mögliche Vorgehensweise ist in diesem {{Link2Forum|Topic=20553|LinkText=Forumsthema}} beschrieben.
{{Hinweis|Statt des Einsatzes derartiger Methoden ist zu empfehlen, nach der eigentliche Fehlerursache zu forschen und diese abzustellen. Haben Sie dennoch einen solchen Watchdog eingerichtet, sollten Sie bei Fragen zu Ihnen seltsam erscheinenden Phänomänen im Forum darauf hinweisen, auch wenn die Symptome scheinbar nichts mit dem Watchdog zu tun haben sollten.}}

== Interne Links ==
* [[CUL am Raspberry Pi flashen]]
* [[Raspberry Pi und 1-Wire]]

== Externe Links ==
* {{Link2Forum|Topic=33460|Message=264679}} zum Umzug von Raspberry B auf Raspberry Pi 2
* [http://www.raspberrypi.org/ Offizielle Webseite der Raspberry Pi Foundation]
* [http://www.raspberrypi.org/downloads Offizielle Downloads der Raspberry Pi Foundation]

[[Kategorie:Raspberry Pi]]
[[Kategorie:HOWTOS]]

Raspberry Pi

2020-07-19T15:03:32Z

PeMue: raspbian -> Raspberry Pi OS

Beim '''Raspberry Pi''' handelt es sich um einen postkartengroßen Einplatinen-Computer, der von der Raspberry Pi Foundation entwickelt wird. Die Hardware basiert auf dem BCM 283x SoC (System-on-Chip) von Broadcom, einem ARM-Prozessor. Zu Hardwaredetails und den verschiedenen Modellen sowie Produktentwicklungen siehe [http://de.wikipedia.org/wiki/Raspberry_Pi#Hardware Wikipedia].
Dank der kleinen Abmessungen, dem recht geringen Energieverbrauch (bis ca. 4 Watt) sowie der günstigen Anschaffungskosten (ca. 30€) ist der Raspberry Pi eine attraktive Hardware für die Heimautomatisierung mit FHEM. Er ist dank dem Linux-Betriebssystem vollständig kompatibel zur aktuell vorhandenen und von FHEM unterstützen Hardware. Das derzeit empfohlene Standard-Image zum Betrieb des Raspberry Pi ist die auf Debian basierende Raspberry Pi OS Distribution.

== Installation / Setup ==
=== Betriebssystem ===
====Vorbemerkung====
Raspberry Pi OS ist direkt bei raspberrybi.org unter https://www.raspberrypi.org/downloads/raspberry-pi-os/ herunterladbar. Die folgende Anleitung gilt für die lite-Version ohne grafischen Desktop und für die Modelle für B, B+, B2, B3, B3+, Zero W. (Stand Juni 2018)

Alle in diesem Abschnitt verwendeten Code Blöcke benötigen root Rechte. Deshalb bitte immer am Besten im Kontext <code>sudo su</code> ausführen. Man kann auch einzelne Befehle mit sudo davor ausführen, allerdings wird die Berechtigung bei Pipe Befehlen nicht durchgereicht.

Alle Dateien müssen im Linux-Format (nur LF als Zeilenende) erzeugt/editiert werden! Unbedingt einen geeigneten Editor verwenden und auf das Format beim Speichern achten!

====SD-Karte vorbereiten====
Die heruntergeladene Datei muss entpackt und auf die Speicherkarte geschrieben werden. Es gibt dazu verschiedene Tools je nach Betriebssystem. Für Windows ist windisk32imager zu empfehlen, Projektseite [https://sourceforge.net/projects/win32diskimager/]. Für Mac OS gibt es den Pi Filler.

Detaillierte Anleitungen zur Vorgehensweise finden sich für die Betriebssysteme Linux, Mac OS und Windows unter [https://www.raspberrypi.org/documentation/installation/installing-images/README.md Writing an image to the SD card]

Die SD Card enthält nun zwei Partitionen/Laufwerke, wobei das erste Laufwerk unter alle Betriebssystemen lesbar ist. In diesem Laufwerk (/boot) müssen jetzt noch zwei Dateien erzeugt werden:
* eine leere Datei mit dem Namen ssh, um den (headless) Zugriff per ssh zu ermöglichen (Pi Filler macht dies automatisch). Hinweis: Eine spätere Aktivierung von SSH ist mit <code>sudo raspi-config</code> (Punkt 5 "Interfacing Options", dann Punkt 2 SSH) möglich, erfordert dann aber Tastatur und Monitor am RPi.
* eine Textdatei im Linux Format mit Namen wpa_supplicant.conf und folgendem Inhalt, wenn der Pi sofort mit WLAN starten soll.

<pre>country=DE
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
network={
ssid="FRITZ!Box 7490"
psk="12345678901234567890"
}
</pre>
* SD Karte auswerfen.
* SD Karte in Raspberry Pi stecken und booten.

Alternativ kann auch Monitor und Tastatur verwendet werden.

====Anmeldung und Grundkonfiguration====
Default raspberrypi-os: Host raspberrypi, User pi, Passwort raspberry

Default ubuntu: Host ubuntu, User ubuntu, Passwort ubuntu

Anmeldung entweder lokal oder mit dem Befehl: ssh <user>@<hostname>

Das Passwort sollte geändert werden, dazu dem Sicherheitshinweis folgen und <code>passwd</code> eingeben.

Alle unten genannten Befehle müssen mit erhöhten Rechten ausgeführt werden (z. B. sudo)!

Als Erstes sollte: Zeitzone, Sprache und Hostname angepasst werden.
Entweder Menügeführt mit <code>sudo raspi-config</code>
oder per Script / Shell Befehle:

<source lang="bash"># Zeitzone einstellen & Zeitsynchronisierung über das Internet aktivieren
timedatectl set-timezone Europe/Berlin
timedatectl set-ntp true

# Konfigurieren lokale Sprache deutsch
sed -i -e 's/# de_DE.UTF-8 UTF-8/de_DE.UTF-8 UTF-8/' /etc/locale.gen
locale-gen
localectl set-locale LANG=de_DE.UTF-8 LANGUAGE=de_DE

# Hostname
hostnamectl set-hostname mymachine

# System aktualisieren
apt-get update
apt-get upgrade

#Neustart
reboot</source>

Am Anfang sollte man Befehle nicht verketten, sondern immer auf die Ausgabe warten (es sei denn, man hat Erfahrung): also kein <code>apt-get update && apt-get upgrade </code>. Ebenso sollte man nicht mit automatischen Bestätigungen arbeiten, also kein upgrade mit "-y". Nach einer Installation ist ein aufräumen immer gut, also:
<source lang="bash">
apt-get autoremove
apt-get clean
apt-get purge $(dpkg --get-selections | grep deinstall | cut -f1 | xargs)
</source>

====Verwendung UART für Zusatzmodule====
Einige Aufsteckmodule (z.B. HM-MOD-RPI-PCB) für den GPIO Port verwenden die serielle Schnittstelle UART. Der Zugriff auf diese serielle Schnittstelle erfordert eine modellabhängige Konfiguration.

Bei allen Modellen muss die Verwendung der seriellen Linux console an ttyAMA0 deaktiviert werden:
<source lang="bash"># seriell-getty Dienst für ttyAMA0 dauerhaft deaktivieren
systemctl stop serial-getty@ttyAMA0.service
systemctl disable serial-getty@ttyAMA0.service
systemctl mask serial-getty@ttyAMA0.service
</source>
Bei den Modellen mit Bluetooth muss die UART aktiviert und umkonfiguriert werden:
<source lang="bash"># serielle Schnittstelle aktivieren und mit BT Schnittstelle tauschen
# für Raspberry Pi OS
config="/boot/config.txt"
# für Ubuntu
#config="/boot/firmware/usercfg.txt"

bash -c "cat <<EOF >> $config
enable_uart=1
dtoverlay=miniuart-bt
core_freq=250
EOF"
</source>
Die config Datei von ubuntu verwendet den Befehl include usercfg.txt. Mit Erscheinen des Pi 4 wurden die overlay Dateien umbenannt (Start mit Pi3- entfernt) die alten Namen funktionieren aber noch.

Um die Konfiguration abzuschließen ist ein Neustart erforderlich
<source lang="bash">#Neustart erforderlich
reboot</source>

====Troubleshooting====
'''Kontrolle der seriellen Schnittstelle'''

Der Befehl <code>ls -l /dev/ttyAMA0</code> muss folgende Ausgabe liefern.
crw-rw---- 1 root dialout 204, 64 Jun 7 22:56 /dev/ttyAMA0
Sollte dies nicht der Fall sein, muss der Dienst serial-getty@ttyAMA0.service deaktiviert werden!

Kontrolle der Verlinkung von /dev/serial*

Der Befehl <code>ls -l /dev/serial*</code> muss folgende Ausgabe liefern.
* Bei Modellen mit BT und richtiger Konfiguration (funktioniert nur unter Raspberry Pi OS)
lrwxrwxrwx 1 root root 7 Jun 7 22:55 /dev/serial0 -> ttyAMA0
lrwxrwxrwx 1 root root 5 Jun 7 22:55 /dev/serial1 -> ttyS0
* Bei den Modellen ohne BT und richtiger Konfiguration
lrwxrwxrwx 1 root root 7 Jun 8 18:30 /dev/serial0 -> ttyAMA0
Sollte das nicht der Fall sein, sind die Einträge in der /boot/config.txt fehlerhaft.

'''Kontrolle Bluetooth'''

Die Funktion von Bluetooth kann mit dem hcitool überprüft werden. Mit <code>hcitool dev</code> wird das interne BT Gerät mit MAC Adresse angezeigt. Mit <code>hcitool scan</code> bzw. <code>hcitool lescan</code> kann nach sichtbaren Geräten gesucht werden.

Weitergehende Informationen zur Anpassung der Konfiguration von Raspberry Pi OS sind nachzulesen auf https://www.raspberrypi.org/documentation/configuration/.

Sollte die Bluetooth Schnittstelle nach der Installation von FHEM nicht funktionieren, hilft es den Dienst abhängig zu starten, siehe diesen Wiki Artikel [[Fhem.service (systemd unit file)]]

=== FHEM ===
Die Installation von FHEM kann nach der Raspberry Pi OS Installation sehr einfach über das Debian-Repository [http://debian.fhem.de] erfolgen.
* Es wird unbedingt empfohlen zur Grundinstallation zunächst keine Module, USB Sticks oder ähnliche Zusatzbaugruppen an den IO Ports des Raspberry gesteckt zu haben.
* Dieser Abschnitt beschreibt nur die Grundinstallation von FHEM auf einem Raspberry Pi mit Raspberry Pi OS!
* Weitere Installationsschritte sind je nach verwendeten FHEM-Modulen notwendig.
** Informationen hierzu liefert üblicherweise die {{Link2CmdRef}} zum jeweiligen Modul.
** Den weiteren Einstieg in FHEM findet man im Artikel [[Quick-Start]]

==== Der einfache Weg zum aktuellen System ====
Der folgende Befehlsblock ist die praktische Umsetzung der Beschreibung auf http://debian.fhem.de. Bitte unbedingt vor Installation rückversichern, ob es dort (insbesondere unter ''The easy way: use apt-get'') Aktualisierungen gab.
* Dieser Befehlsblock erfordert erhöhte Rechte, also bitte als Erstes <code>sudo su</code> ausführen!
* Beim Kopieren aufpassen! Jede Zeile muss einzeln ausgeführt werden!
<source lang="bash"># von debian.fhem.de installieren - siehe aktuelle Anleitung dort https://debian.fhem.de/
wget -qO - http://debian.fhem.de/archive.key | apt-key add -
echo "deb http://debian.fhem.de/nightly/ /" >> /etc/apt/sources.list
apt-get update
apt-get install fhem
</source>

==== Das offizielle Release ====
Man kann FHEM mit dem Debian-Paket von [https://fhem.de/#Installation fhem.de] installieren. Dieser Weg führt zu einem offiziellen Release, welches aber unter Umständen erheblich vom aktuellen Versions- und Diskussionsstand im Forum abweicht.

Alternativ kann man auch den manuellen Weg von https://debian.fhem.de/ wählen.

==== Empfohlener Patch ====
Da gerade auf dem Raspberry die automatische Erkennung der USB Schnittstellen zu 100% CPU Last führt (FHEM träge und reagiert nicht), wird empfohlen sofort nach der Installation noch diesen "Patch" auszuführen: FHEM starten, wenn alle USB-Geräte ausgesteckt sind. Dann <code>attr initialUsbCheck disable 1</code> in der Kommandozeile in FHEMWEB eingeben, <code>save</code> ausführen und FHEM anschließen wieder mit eingesteckten USB-Geräten neu starten.

==== Deinstallation ====
Man kann FHEM auch wieder spurlos vom System entfernen und ganz von vorn beginnen. Allerdings sollte man sich im Klaren sein, damit ensteht kein jungfräuliches System!
<source lang="bash">sudo apt-get purge fhem
sudo apt-get autoremove
</source>

=== Zusatzpakete bei FHEM-Erst- und Zweitinstallation ===
Nachdem der RPi eingerichtet ist, können weitere Pakete installiert werden. Keines davon ist zwingend erforderlich, um das Grundgerüst von FHEM betreiben zu können. Einige Pakete erhöhen aber den Bedienungskomfort, andere sind zur Nutzung bestimmter weiterer FHEM-Module (siehe {{Link2CmdRef}}) erforderlich.

Hierzu wurden in letzter Zeit mehrere Hilfsmodule entwickelt, die insbesondere bei Wiederinstallation (etwa nach Absturz) wichtig sein können. So zeigt das Modul Installer die installierten Perl-Module an, siehe dazu [https://forum.fhem.de/index.php?topic=98381.15 diesen Thread]

Wenn man eine frühere Installation auf einer anderen SD-Karte installieren möchte und nicht mehr weiß, welche Zusatzpakete man auf der alten Karte installiert hatte, hilft (diese und nachfolgende Hinweise sind aus dem Blog [https://heinz-otto.blogspot.com/2019/07/infos-zur-installation-von-modulen-und.html])
zcat $(ls -tr /var/log/apt/history.log.*.gz)|grep -A1 Start-Date
weiter. Hier werden frühere Eingaben der Kommandozeile wiedergegeben. Es gibt einen analogen Befehl, um die mit CPAN installierten Pakete anzuzeigen. Dazu muss man das debian Paket perl-doc installiert haben und gibt dann ein
for M in `perldoc -t perllocal|grep Module |sed -e 's/^.*" //'`; do V=`perldoc -t perllocal|awk "/$M/{y=1;next}y" |grep VERSION |head -n 1`; printf "%30s %s\n" "$M" "$V"; done |sort
Ebenso kann man herausfinden, ob und durch welches debian-Paket das Perl-Paket installiert wurde. Die zweite Version sucht nur in Paketen die -perl im Namen tragen und läuft damit wesentlich schneller:
s='Device::SerialPort' ## zu diesem Paket wird gesucht
perl -M$s -e '' 2>/dev/null &&echo "Modul $s ist vorhanden"''
for i in $(dpkg -l |grep ^ii| awk '{ print $2 }'|tr -d "\r"|tr "\n" " ");do if dpkg -L $i|grep $s &> /dev/null;then echo $i enthält $s;fi;done
for i in $(dpkg -l |grep ^ii|grep '\-perl'| awk '{ print $2 }'|tr -d "\r"|tr "\n" " ");do if dpkg -L $i|grep $s &> /dev/null;then echo $i enthält $s;fi;done

Es gibt gute Gründe die Installation von Perl Modulen über debian-Pakete der Installation über cpan zu bevorzugen. Dazu zählt die Updatefähigkeit und die Geschwindigkeit. Man kann im Internet nach den Paketen suchen, man kann aber auch einfach die Verfügbarkeit für das lokale System testen. Dazu braucht man das Tool apt-file, welches man zuerst installieren muss. Der letzte Befehl lädt den Infocache lokal und dauert etwas:
sudo apt-get update
sudo apt-get install apt-file
sudo apt-file update
Die folgende Suche nutzt den Umstand, dass in der im Paket enthaltenen Liste der Dateien auch die Doku in der Form "/usr/share/man/man3/IO::File.3perl.gz" enthalten ist. Der search Befehl unten akzeptiert mehrere Modulnamen durch Zeilenumbruch getrennt. In dem Beispiel sind die Modulnamen in einem String durch Leerzeichen getrennt, die Trennung wird in Zeilenumbruch geändert, jede Zeile ergänzt und über stdin an den search Befehl von apt-file übergeben. Die Option -l bewirkt das nur die gefunden Pakete gelistet werden, werden mehrere der abgefragten Modulnamen in einem Paket gefunden, wird es nur einmal gelistet:
s="IO::File Digest::MD5" ##Such-String
echo $s|tr " " "\n"|sed 's/$/./;s/^/\//'|apt-file search -l -f -

Zuletzt eine Übersicht diverser Zusatzpakete.
{| class="wikitable"
! style="width:10%" | Beschreibung
! style="width:10%" | Paketname
! style="width:50%" | Kontext
! style="width:30%" | Installieren
|-
|Zeitserver
|ntpdate
|Setzt die Systemzeit bei Start des RPi. Wird für FHEM benötigt, da es sonst nicht startet.
|<code>sudo apt-get install ntpdate
sudo ntpdate -u de.pool.ntp.org</code>
|-
|Perl JSON
|JSON
|Wird von einigen Modulen benötigt, z.B. harmony, iTunes
|<code>sudo apt-get install libjson-perl</code>
|-
|Samba-Server
|samba
|Mittels Samba kann man z.B. den Ordner /opt/fhem als Share freigeben. Dieser Share kann z.B. im Windows-Explorer als Laufwerk verbunden werden, so dass die Bearbeitung von config- und Programmdateien bequem möglich ist. Hier eine hilfreiche [https://www.elektronik-kompendium.de/sites/raspberry-pi/2007071.htm Kurzanleitung] aus der (wenn man auf einen speziellen user verzichtet) nur die Einträge für smb.conf gesetzt werden müssen.
|<code>sudo apt-get install samba cifs-utils</code>
Danach muss der share definiert werden mittels

<code>sudo nano /etc/samba/smb.conf</code>
|-
|Mailversand
|sendemail (alt: sendEmail)
|Wird benötigt, um Mails versenden zu können, bspw. für Alarm-Benachrichtigungen.
Nach Installation des Paketes benötigt man noch eine Routine in FHEM gemäß [[E-Mail senden#Raspberry Pi]]
|<code>sudo apt-get install sendemail</code> bzw. <code>sudo apt-get install sendEmail</code>
|-
|Wake-on-LAN
|etherwake
|Wird z.B. für das Modul WOL benötigt.
|<code>sudo apt-get install etherwake</code>
|-
|Perl Telnet
|telnet
|Wurde vor Fritz!OS 6.2x z.B. für das Modul [[FRITZBOX]] benötigt, da es eine im Netzwerk vorhandene Fritzbox über deren Telnet-Port ansprach. Mittlerweile wird TR-64 und SOAP verwendet.
|<code>sudo apt-get install libnet-telnet-perl</code>
|-
|Socat
|socat
|Kann verwendet werden, um auf anderen Rechnern im Netzwerk Linux-Befehle oder Skripts auszuführen. Auch können auf Slave-FHEM-Installationen Befehl ausgeführt werden, z.B. mit

<code><nowiki>system("echo 'set lampe on' | /usr/bin/socat - TCP:1.2.3.4:7072");</nowiki></code>

1.2.3.4 muss natürlich durch die IP-Adresse des Zielrechners ersetzt werden.
|<code>sudo apt-get install socat</code>
|-
|Libcrypt
|Libcrypt
|Perl libcrypt, erforderlich falls Homematic-devices mit AES verwendet werden sollen.
|<code>sudo apt-get install libcrypt-rijndael-perl</code>
|-
|libdatetime
|libdatetime
|Perl libdatetime, erforderlich für das Weather-Modul.
|<code>sudo apt-get install libdatetime-format-strptime-perl</code>
|-
|EnOcean XML functions
|libxml simple
|Perl XML::SIMPLE, erforderlich für die XML Funktionen des ENOCEAN Moduls.
|<code>sudo apt-get install libxml-simple-perl</code>
|-
|EnOcean Cryptographic functions
|libcrypt-random-source-perl
|Perl Crypt::Random, erforderlich für die Cryptographic Funktionen des ENOCEAN Moduls.
|<code>sudo /usr/bin/perl -MCPAN -e 'install Crypt::Random'</code>
|}

== Bekannte Probleme ==
=== Netzteil ===
Der RPi verwendet ein USB Netzteil als Spannungsversorgung. Gemessen kann der RPi allein bereits um die 900mA Strom fordern. Das bringt kleine Netzteile, besonders wenn noch CULs oder WLAN Sticks an USB hängen schnell an die Grenze. Die Fehler die daraus resultieren sind Abstürze, Netzwerkprobleme uvm. Daher bitte ein ausreichend starkes Netzteil mit mind. 2000mA oder einen aktiven USB-HUB für die Periperie verwenden.

=== Echtzeituhr ===
Der RPi hat keine [http://de.wikipedia.org/wiki/Echtzeituhr Real-Time-Clock] (RTC), das heißt, dass er nach einem Neustart keine gültige (im Sinne von aktuell) Systemzeit hat, sondern ein Datum in der Vergangenheit. Dieses Problem wird sinnvollerweise mit einer [http://de.wikipedia.org/wiki/Network_Time_Protocol NTP-Konfiguration] oder durch [[Raspberry Pi: RTC Hat|Installation einer Echtzeituhr]] umgangen.

Dabei muss Sorge getragen werden, dass der [http://wiki.debian.org/NTP ntpd] schon einen Datums-/Zeitabgleich gemacht hat, bevor FHEM gestartet wird. Geschieht der Abgleich nicht vorher, sondern erst nachdem FHEM schon läuft, stellt FHEM die Logs zwar auf das nun aktuelle Datum um (die "alten" Logs mit dem eigentlich ungültigen Datum werden natürlich behalten), aber irgendetwas scheint FHEM dabei so zu belasten, dass es eine Last von über 0.8 bis 0.9 erzeugt. Diese Last besteht auf Dauer und verschwindet erst, wenn man das Ganze sauber durchkonfiguriert und FHEM neu gestartet hat. Die hohe Systemauslastung zeigt sich auch in einem sehr trägen Laden der FHEM-Webseiten in einem beliebigen Browser. (siehe {{Link2Forum|Topic=70741}})

=== Last durch Backup (während update) ===
Bei einen [[Update]] von FHEM durch den Befehl <code>update</code> kann durch Setzen des Attributs "<code>attr global backup_before_update 1</code>" automatisch vorab ein [[Backup]] durchgeführt werden. Die (ggf. großen) Log-Dateien werden dabei ebenfalls archiviert. Während der Archivierung ist FHEM blockiert. Durch die beschränkte Leistungsfähigkeit des Raspberry Pi kann das Backup zudem lange dauern. Durch ein "<code>attr global updateInBackground 1</code>" wird ein Backup im Hintergrund ausgeführt (Quelle: {{Link2Forum|Topic=15729}}).

Alternative Möglichkeiten:
* Backup ausschalten und manuell durchführen
* Backup-Befehl anpassen und so große Dateien bzw. Verzeichnisse (log/) nicht archivieren

== Watchdog einrichten ==
Man kann den RPi regelmäßig prüfen lassen, ob FHEM noch läuft und gegebenenfalls einen Neustart durchführen lassen. Eine mögliche Vorgehensweise ist in diesem {{Link2Forum|Topic=20553|LinkText=Forumsthema}} beschrieben.
{{Hinweis|Statt des Einsatzes derartiger Methoden ist zu empfehlen, nach der eigentliche Fehlerursache zu forschen und diese abzustellen. Haben Sie dennoch einen solchen Watchdog eingerichtet, sollten Sie bei Fragen zu Ihnen seltsam erscheinenden Phänomänen im Forum darauf hinweisen, auch wenn die Symptome scheinbar nichts mit dem Watchdog zu tun haben sollten.}}

== Interne Links ==
* [[CUL am Raspberry Pi flashen]]
* [[Raspberry Pi und 1-Wire]]

== Externe Links ==
* {{Link2Forum|Topic=33460|Message=264679}} zum Umzug von Raspberry B auf Raspberry Pi 2
* [http://www.raspberrypi.org/ Offizielle Webseite der Raspberry Pi Foundation]
* [http://www.raspberrypi.org/downloads Offizielle Downloads der Raspberry Pi Foundation]

[[Kategorie:Raspberry Pi]]
[[Kategorie:HOWTOS]]

MQTT2-Module - Praxisbeispiele

2020-06-08T06:06:41Z

PeMue: Hinweis auf Passwort in den Geräten bei Absicherung mit allowed.

== Einführung: MQTT bzw. MQTT2 in FHEM ==
{{Randnotiz|RNTyp=y|RNText=Sollten Sie MQTT2_CLIENT verwenden, beachten Sie bitte, dass der MQTT2_CLIENT die ursprüngliche Herkunft der über MQTT verteilten Informationen nicht kennt. Daher ergeben sich in der Anwendung kleinere Unterschiede, zu deren Verständnis die diesbezüglichen [[MQTT2_CLIENT#Anwendung|Hinweise zu MQTT2_CLIENT]] bekannt sein sollten.}}Zur Einbindung von Geräten, welche zur Nutzung des MQTT-Protokols konfiguriert werden können und darüber mit einem MQTT-Server (früher: Broker) kommunizieren, stehen unter FHEM verschiedene Optionen zur Verfügung, wobei nicht alle Module beliebig miteinander verwendet werden können. Details hierzu sind dieser [[MQTT|Übersicht]] zu entnehmen.

Im Rahmen dieses Artikels wird für die eigentlichen Geräte [[MQTT2 DEVICE|MQTT2_DEVICE]] verwendet, damit wird als IO-Device entweder {{Link2CmdRef|Anker=MQTT2_SERVER|Lang=en|Label=MQTT2_SERVER}} oder [[MQTT2 CLIENT|MQTT2_CLIENT]] oder benötigt, mit einem IO-Device des Typs [[MQTT (Modul)|MQTT]] funktioniert die nachfolgende Darstellung dagegen nicht<ref>Allerdings können die Konfigurationen in der Regel recht einfach auf die bisherige MQTT-Implementierung übertragen werden</ref>. MQTT2_DEVICE unterstützt u.a. auch die ''setExtensions'' direkt, also z.B. ''on-for-timer<ref>Beachten Sie bei mehrkanaligen Geräten, dass jeweils nur ein Hauptkanal mittels setExtensions verwaltet werden kann! U.a. aus diesen Grund ist es meist sinnvoller, die ''split''-Varianten der attrTemplate-Einrichtung zu verwenden.</ref>'' sowie ''[[MQTT2-Module - Praxisbeispiele#attrTemplate_2|attrTemplate]]''<ref>Auch MQTT_DEVICE unterstützt SetExtensions, allerdings muß dies dort per Attribut eingeschaltet werden</ref>.

=== Allgemeine Einstellungen und Hinweise ===
{{Randnotiz|RNTyp=r|RNText=Beachten Sie, dass für autocreate in Verbindung mit MQTT2_SERVER '''zwingend''' jeder über MQTT kommunizierende Client eine ClientID angeben muß. Passen Sie daher ggf. die Einstellungen Ihres Geräts an. Manche Geräte verwenden auch "Wegwerf"-ClientID's. Für diese empfiehlt es sich, ggf. dann die durch autocreate erstellten Geräte nachzubearbeiten und die ClientID-Angabe v.a. aus den Inhalten des readingList-Attributs zu entfernen.}}Die nachfolgenden Beispiele gelingen am einfachsten mit '''MQTT2_SERVER als Server ("Broker")''', für diesen sollte dabei ''autocreate'' nicht deaktiviert sein, damit die erforderlichen MQTT2_DEVICES soweit möglich automatisiert erstellt werden<ref>Dabei wird vorausgesetzt, dass ein allgemeines {{Link2CmdRef|Anker=autocreate|Lang=en|Label=autocreate}}-Device (''TYPE=autocreate'') ebenfalls aktiv ist.</ref> .

Beispiel<ref>MQTT2_SERVER verwendet als default-Einstellung für ''autocreate'' ''simple'', ohne dass ein entsprechendes Attribut gesetzt werden müßte. Die Einstellung ''complex'' empfiehlt sich in der Regel nicht; diese ist jedoch dann zu empfehlen, wenn das Device entweder verschachtelte JSON-Array-Strukturen liefert oder bestimmte Readings nicht gefüllt werden sollen.</ref>:
define MQTT2_FHEM_Server MQTT2_SERVER 1883 global

Falls der MQTT Broker mit Hilfe von [[allowed]] abgesichert wurde, muss in den Geräten ebenfalls User bzw. Passwort eingetragen werden, damit eine MQTT Kommunikation möglich ist.

{{Hinweis|Die Code-Darstellung in diesem Beitrag entspricht jeweils dem RAW-Format zum [[Import von Code Snippets]]. Wer die Attribute direkt und einzeln bearbeitet, muß ggf. die "\" entfernen!}}

=== MQTT-Einstellungen in den Geräten ===
Die Beispiele gehen davon aus, dass die einzubindenden Geräte '''''mit den default-Einstellungen''''' für MQTT betrieben werden, wenn man von den Angaben zum Server und ggf. der Gerätekennung absieht. Es sollten also insbesondere '''keine Veränderungen der topic-Pfade''' vorgenommen werden.

{{Hinweis|Einige der hier beschriebenen Einstellungen haben Änderungen der sich durch die jeweiligen Automatismen eigentlich jeweils ergebenden Standard-Werte zur Folge, insbesondere, was Reading-Namen und von den Geräten gesendete Werte angeht. Sie sollten daher zunächst die Konfiguration des jeweiligen MQTT2-DEVICE-Geräts abschließen, und erst anschließend die weitere Integration mit Event-Handlern, logging usw. vornehmen. }}

== zigbee2mqtt ==
[[Bild:MQTT2_zigbee2mqtt_Bulbs.png|400px|thumb|Darstellung in FHEMWEB]]
[https://github.com/Koenkk/zigbee2mqtt zigbee2mqtt] ist ein open-source Projekt, mit dem zigbee-Geräte über MQTT direkt angesprochen werden können, ohne dass hierfür eine Bridge eines Herstellers benötigt wird.
=== Installation von zigbee2mqtt ===
Die Installation des zigbee2mqtt-Diensts ist auf der Homepage des Projekts beschrieben. Ergänzend muß in der configuration.yaml eine ''client_id'' unter ''mqtt'' (z.B. zigbee_pi) vergeben werden<ref>Die Anführungszeichen sowie genau zwei Leerzeichen sind hier erforderlich!</ref>.
mqtt:
client_id: 'zigbee_pi'
Da der Dienst auch später in den Anlernmodus versetzt werden kann, kann man auch gleich <code>permit_join: false</code> setzen, um das versehentliche Einbinden neuer oder fremder Geräte zu unterbinden.
{{Hinweis|Wird ein CC2531 auf demselben Linux-Computer verwendet, auf dem auch FHEM installiert ist, kann es vorkommen, dass FHEM diesen mit einem CUL verwechselt und durch ''initialUsbCheck'' in FHEM einbindet, wodurch er für den zigbee2mqtt-Dienst nicht mehr verfügbar ist. Dann sollte ''initialUsbCheck'' deaktiviert und das automatisch angelegte CUL-Device wieder gelöscht werden. Weiter sollte der CC2531 auch in FHEM '''und''' zigbee2mqtt ''[[Mehrere USB-Geräte einbinden|by-id]]'' eingebunden werden, um Probleme beim gleichzeitigen Einsatz anderer Geräte, die ''/dev/ttyACMx'' belegen können, zu vermeiden (betrifft z.B. CUL/MapleCUL ).}}

=== Define eines MQTT2-Devices als "Bridge" ===
Dann kann eine Art "Grund-Device" angelegt werden, das für die Ansteuerung des eigentlichen Server-Dienstes genutzt wird, der bereits unmittelbar nach der erfolgreichen Konfiguration von zigbee2mqtt zur Verfügung steht. In der Regel sollte dieses automatisch erstellt werden, wenn der zigbee2mqtt-Dienst (oder der betreffende Rechner) neu gestartet wird (oder FHEM oder dort ein Sensor einen Messwert sendet). Beispiel<ref>Hier waren bereits zwei Zigbee-Geräte angelernt</ref>:

defmod MQTT2_zigbee_pi MQTT2_DEVICE zigbee_pi
attr MQTT2_zigbee_pi IODev MQTT2_FHEM_Server
attr MQTT2_zigbee_pi readingList zigbee_pi:zigbee2mqtt/bridge/state:.* state\
zigbee_pi:zigbee2mqtt/0x90fd9ffffe65db16:.* { json2nameValue($EVENT, '') }\''
zigbee_pi:zigbee2mqtt/0x90fd9ffffe0bcd51:.* { json2nameValue($EVENT, '') }\''
zigbee_pi:zigbee2mqtt/bridge/log:.* { json2nameValue($EVENT, 'log_') }
attr MQTT2_zigbee_pi room MQTT2_DEVICE

Für die Funktion einer zigbee2mqtt-Bridge steht ein {{Link2CmdRef|Anker=set|Lang=en|Label=template}} bereit, das direkt die passenden Attribute vergibt, um dem zigbee2mqtt-Dienst passende Anweisungen geben zu können und weitere Geräte für die eigentlichen Aktoren und Sensoren anzulegen:

set MQTT2_zigbee_pi attrTemplate zigbee2mqtt_bridge

Ist dieses angelegt, kann zigbee2mqtt mit <code>set MQTT2_zigbee_pi permit_join true</code> in den Anlernmodus versetzt werden, anzulernende Geräte müssen anschließend jeweils nach Bedienungsanleitung in den Anlernmodus gebracht werden.

=== Vereinzeln der eigentlichen Geräte ===

Über das mit dem template vergebene bridgeRegexp-Attribut
attr MQTT2_zigbee_pi bridgeRegexp zigbee2mqtt/([A-Za-z0-9]*)[/]?.*:.* "zigbee_$1"
werden anschließend neue MQTT2_DEVICE-Geräte automatisch angelegt, sobald ein bisher unbekanntes Zigbee-Gerät einen neuen Status (z.B. einen Meßwert) meldet. Um zu erfragen, welche Geräte dem zigbee-Deinst bekannt sind, kann via <code>get MQTT2_zigbee_pi devicelist true</code> eine Liste abgefragt werden, die weitere Informationen zu den bereits angelernten Geräten enthält.
Geräte, die nicht automatisch etwas senden, kann man mit Hilfe des MQTT2_SERVER-Geräts einmalig schalten, damit diese ihren Status bzw. das erfolgreiche Schalten zurückmelden, Beispiel<ref>Die mit 0x... beginnende Angabe entspricht dabei dem ''friendly_name''.</ref>:
set MQTT2_FHEM_Server publish zigbee2mqtt/0x90fd9ffffe0bcd51/set {"state":"ON","brightness":60}

Für Gerätetypen, für die bereits templates vorhanden sind, ist es am einfachsten, diese einmalig auf die Geräte anzuwenden. Das Vorgehen entspricht dabei dem oben für die Bridge beschriebenen. Dafür wird immer vorausgesetzt, dass ein neues Device mit autocreate (ggf. über die bridgeRegexp) angelegt wurde<ref>Dieses befindet sich dann im Raum MQTT2_DEVICE. Um diesen sichtbar zu machen, muß ggf. die Browser-Seite neu geladen werden.</ref>

Beispiele:
==== IKEA-Tradfri-Birne ====
{{Randnotiz|RNTyp=g|RNText=Wie wähle ich nun das richtige Template für mein Leuchtmittel aus?
-> Es wird nicht zwischen einer Birne/Bulb/Lampe und einem LED-Controller unterschieden sondern anhand der möglichen Lichtdarstellung des Gerätes:

light_dimmer:
Das anzusteuernde Geräte besitzt ausschließlich eine feste Lichtfarbe welche gedimmt werden kann.

light_cct:
Das anzusteuernde Gerät besitzt eine warmweiße sowie kaltweiße Lichtfarbe welche verändert sowie gedimmt werden kann.

light_rgb_xxx:
Das anzusteuernde Gerät besitzt die Möglichlichkeit einer farbigen Lichtdarstellung (Rot, Grün, Blau) und kann gedimmt werden.

light_rgbw_xxx:
Das anzusteuernde Gerät besitzt die Möglichlichkeit einer farbigen Lichtdarstellung (Rot, Grün, Blau) und besitzt eine warmweiße ODER kaltweiße Lichtfarbe welche eingestellt sowie gedimmt werden kann.

light_rgbcct_xxx:
Das anzusteuernde Gerät besitzt die Möglichlichkeit einer farbigen Lichtdarstellung (Rot, Grün, Blau) und besitzt eine warmweiße UND kaltweiße Lichtfarbe welche verändert sowie gedimmt werden kann.

xxx:
hex: Farbänderung mit hex
rgb: Farbänderung mit r g b
xy: Farbänderung mit x sowie y
hue: Farbänderung mit hue und saturation

Warum diese Einteilung in "hex", "rgb", "xy" sowie "hue"?
-> Zigbee2MQTT unterstützt das Übermitteln aller dieser Werte, allerdings unterscheiden sich hier die Geräte. Manche "verstehen" nur z.B. Hex-Farbänderungen, andere halt nur eine Farbänderung mit rgb-Werten.
-> Aus diesem Grund muss an dieser Stelle probiert werden mit welchem der 4 Templates sich die Farbveränderung des Gerätes steuern lässt!

HINWEIS: Templates für Farbänderungen mithilfe von XY- sowie HUE-Werten wurden bis heute nicht angelegt!
}}
Beispiel eines dimmbaren Tradfri-Leuchtmittels
defmod IKEA_Bulb2 MQTT2_DEVICE
attr IKEA_Bulb2 IODev MQTT2_FHEM_Server
attr IKEA_Bulb2 icon light_control
attr IKEA_Bulb2 devStateIcon {zigbee2mqtt_devStateIcon255($name)}
attr IKEA_Bulb2 readingList zigbee_pi:zigbee2mqtt/0x90fd9ffffe0bcd51:.* { json2nameValue($EVENT) }
attr IKEA_Bulb2 setList on:noArg zigbee2mqtt/0x90fd9ffffe0bcd51/set {"state":"ON"}\
off:noArg zigbee2mqtt/0x90fd9ffffe0bcd51/set {"state":"OFF"}\
brightness:colorpicker,BRI,0,15,255 zigbee2mqtt/0x90fd9ffffe0bcd51/set {"state":"on","$EVTPART0":"$EVTPART1"}
attr IKEA_Bulb2 webCmd toggle:on:off:brightness
attr IKEA_Bulb2 model L_02a_zigbee2mqtt_bulb

Kann man auch die Farbtemperatur einstellen, wird die setList wie folgt erweitert oder das entsprechende template<ref>Durch die ''model''-Angabe kann nachvollzogen werden, welches template angewendet wurde.</ref> anwendet:
...
color_temp:colorpicker,CT,250,1,454 zigbee2mqtt/0x90fd9ffffe0bcd51/set {"$EVTPART0":"$EVTPART1"}

Die templates sind dabei in der Regel so gestaltet, dass eventuell mehr Optionen in FHEMWEB erscheinen, als tatsächlich vorhanden oder erwünscht sind.
Da sich obige einfarbige dimmbare Lampe durch Klicken auf das devStateIcon schalten läßt, ist für die vollständige Ansteuerung bereits dieses webCmd hinreichend:
attr IKEA_Bulb2 webCmd brightness

==== Temp/Hum. Sensor ====
tbd

==== Motion Sensor ====
Als MQTT-Server wird hier ''mosquitto'' verwendet, als IO-Device wird daher ein {{Link2CmdRef|Anker=MQTT2_CLIENT|Lang=en|Label=MQTT2_CLIENT}}-Gerät definiert:

defmod mqtt2_client MQTT2_CLIENT 192.168.2.4:1883
attr mqtt2_client autocreate 1
attr mqtt2_client rawEvents zigbee2mqtt/GB_Bewegungsmelder:.*
attr mqtt2_client room test
attr mqtt2_client subscriptions #

Das eigentliche Device sieht dann so aus:
defmod GB_Bewegungsmelder_MQTT2 MQTT2_DEVICE zigbee_158d0001f9d030
attr GB_Bewegungsmelder_MQTT2 IODev mqtt2_client
attr GB_Bewegungsmelder_MQTT2 devStateIcon motion:motion_detector@red off:motion_detector@green no_motion:motion_detector@green
attr GB_Bewegungsmelder_MQTT2 icon motion_detector@blue
attr GB_Bewegungsmelder_MQTT2 readingList mqtt2client:zigbee2mqtt/GB_Bewegungsmelder:.* { json2nameValue($EVENT) }
attr GB_Bewegungsmelder_MQTT2 room MQTT2_DEVICE
attr GB_Bewegungsmelder_MQTT2 stateFormat {\
if(ReadingsVal("$name","occupancy",0) eq "true") {\
sprintf("motion");;\
} else {\
sprintf("no_motion");; \
}\
}
==== Anlegen von Zigbee2MQTT-Gruppen in FHEM ====
{{Hinweis|Die nachfolgende Darstellung ist vorläufig!}}
{{Hinweis|Bevor man eine Gruppe mithilfe von Zigbee2MQTT anlegen kann, sollte man sicherstellen, dass man über die aktuelleste Version von Zigbee2MQTT verfügt (min. vom 15. Februar 2019). Außerdem sollte auch der Koordinator (zumeist CC2531) die aktuellste Firmware besitzen (min. vom 15. Februar 2019). Falls ein flashen des Koordinators mit der neusten Firmware erfolgen soll, ist darauf zu achten, dass nach einem flashen alle Geräte neu angelernt werden müssen! (Hinweise zum flashen ohne erneutem anlernen sind hier zu finden: https://www.zigbee2mqtt.io/information/flashing_without_re-pairing.html)}}

=====Erstellen einer Zigbee2MQTT-Gruppe=====
Bevor das Ganze in FHEM funktioniert, muss eine Gruppe in der "configuration.yaml" angelegt werden, dieser Vorgang ist auf folgender Seite beschrieben: https://www.zigbee2mqtt.io/information/groups.html
Wenn die Geräte anschließend über den FHEM MQTT2-Server der Gruppe hinzugefügen werden sollen, kann dies mit folgendem Befehl erfolgen:
set <MQTT2-Server> publish zigbee2mqtt/bridge/group/<Zigbee2MQTT Friendly-Gruppenname>/add <Zigbee2MQTT Friendly-Gerätename>

Beispiel:
set MQTT2_FHEM_Server publish zigbee2mqtt/bridge/group/Wohnzimmer/add Stehlampe

Dieser Befehl kann so oft verwendet werden, wie man Geräte zu einer Gruppe hinzufügen möchte.

Zum Entfernen eines Gerätes aus einer Gruppe kann folgender Befehl verwendet werden:
set <MQTT2-Server> publish zigbee2mqtt/bridge/group/<Zigbee2MQTT Friendly-Gruppenname>/remove <Zigbee2MQTT Friendly-Gerätename>
Beispiel:
set MQTT2_FHEM_Server publish zigbee2mqtt/bridge/group/Wohnzimmer/remove Kuechenlampe

=====Anlegen der Gruppe in FHEM=====
Da Gruppen in Zigbee2MQTT aktuell keine Rückmeldung über ihren Status geben, wird auch beim einmaligen Schalten kein Gerät automatisch in FHEM angelegt. Aus diesem Grund muss dies mit folgendem Befehl noch manuell erfolgen:
defmod <FHEM NAME> MQTT2_DEVICE
Beispiel
defmod lichtWohnzimmer MQTT2_DEVICE
Anschließend wird auch für dieses Gerät wieder ein passendes template ausgewählt, wie als wäre es ein normales Zigbee2MQTT-Gerät.
Im anschließenden Dialog-Fenster welches sich nach dem Setzen des templates öffnet, müssen die folgenden Werte durch passendes ersetzt werden:
BASE_TOPIC -> zigbee2mqtt
DEV_ID -> <Zigbee2MQTT Friendly-Gruppenname>

Danach sollte sich die Gruppe wie ein normales Zigbee2MQTT Gerät steuern lassen.

== Tasmota ==
{{Randnotiz|RNTyp=r|RNText=Bitte beachten Sie, dass versicherungsrechtliche Probleme entstehen können, wenn die herstellereigene Firmware ersetzt wird!}}[https://github.com/arendst/Sonoff-Tasmota Tasmota] ('''T'''heo '''A'''rends '''S'''onoff '''M'''QTT '''O'''ver '''T'''he '''A'''ir - einer offenen Firmware von [https://github.com/arendst arendst]) ist eine open-source Software für ESP8266-Geräte, die z.B. statt der originalen Firmware für Sonoff-Geräte und andere ESP8266-basierte WLAN-Steckdosen usw. verwendet werden kann.
{{Hinweis|[[Datei:Tasmota mqtt config.png|120px|thumb|right]]Vor allem, aber nicht nur bei Verwendung des MQTT2_CLIENT als IO, ist es empfehlenswert, in der MQTT-Konfiguration der tasmota-Geräte für den Parameter ''<nowiki>topic = %topic% (tasmota)</nowiki>'' ebenfalls die dynamisch aus der Chip-ID erzeugte Kennung ''DVES_%06X'' zu verwenden. (Kopieren Sie einfach diese Zeichenkette aus dem Eingabefeld für ''"client ..."'', siehe nebenstehende Abbildung). Die eigentliche Umbenennung zu einem "sprechenden Namen" kann dann innerhalb von FHEM - mittels ''rename'' oder ggf. mit einem ''alias'' - erfolgen.}}
=== MQTT2_DEVICE ===
Dieses sollte bei aktiviertem ''autocreate'' am MQTT2_SERVER-Device automatisch angelegt werden, sobald das betreffende Gerät eingesteckt oder neu gestartet oder an einem evtl. vorhandenen Taster geschalten wird. Bislang wurden Tasmota version(en) ab 6.1.1 bis min. 8.1.0 getestet, dies auf verschiedener Hardware, zunächst mit Sonoff Touch und S20, zwischenzeitlich mit einer Vielzahl von Geräten, die per USB-Adapter oder mit der Methode aus dem [https://www.heise.de/ct/artikel/Tuya-Convert-IoT-Geraete-ohne-Loeten-vom-Cloud-Zwang-befreien-4283623.html Tuya-Convert]-Projekt des heise-Verlags auf Tasmota umgeflasht wurden.

=== Manuelle Anpassungen ===
Die RAW-Definition kann dann beispielsweise wie folgt ergänzt werden:
defmod MQTT2_DVES_9B01BD MQTT2_DEVICE DVES_9B01BD
attr MQTT2_DVES_9B01BD IODev m2server
attr MQTT2_DVES_9B01BD readingList DVES_9B01BD:tele/DVES_9B01BD/STATE:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/DVES_9B01BD/LWT:.* LWT\
DVES_9B01BD:cmnd/DVES_9B01BD/POWER:.* POWER\
DVES_9B01BD:tele/DVES_9B01BD/UPTIME:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/DVES_9B01BD/SENSOR:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/DVES_9B01BD/INFO1:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/DVES_9B01BD/INFO2:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/DVES_9B01BD/INFO3:.* { json2nameValue($EVENT) }\
DVES_9B01BD:stat/DVES_9B01BD/RESULT:.* { json2nameValue($EVENT) }\
DVES_9B01BD:stat/DVES_9B01BD/STATE:.* { json2nameValue($EVENT) }
attr MQTT2_DVES_9B01BD room MQTT2_DEVICE
attr MQTT2_DVES_9B01BD setList on cmnd/DVES_9B01BD/POWER on\
off cmnd/DVES_9B01BD/POWER off\
reboot cmnd/DVES_9B01BD/Restart 1
attr MQTT2_DVES_9B01BD webCmd on:off:reboot

=== attrTemplate ===

===== Allgemeines =====
Für gängige Tasmota-Geräte stehen ''templates'' bereit, mit denen sich diese schnell konfigurieren lassen.
Beachten Sie dazu den Abschnitt ''attrTemplate'' in [[MQTT2 DEVICE#attrTemplate|MQTT2_DEVICE]]. Bei Anwendung eines template mit "split" im Namen werden dabei weitere Geräte angelegt und konfiguriert.{{Hinweis|Bitte attrTemplates nicht verwechseln mit templates, die auf den Tasmota- bzw. Blackadder-Seiten angeboten werden, welche zur Konfiguration der firmware genutzt werden können! Es sollte zunächst die firmware korrekt eingerichtet werden, so dass das Gerät selbst direkt auf dessen Web-Interface korrekt bedient werden kann.}}

===== Kein passendes attrTemplate vorhanden? =====
Exisitert (noch) kein passendes attrTemplate, ist zu empfehlen, zunächst das "''tasmota_basic''" anzuwenden. Dieses führt einige Basiskonfigurationen durch, die für FHEM hilfreich sind, z.B. wird die firmware so eingestellt, dass Schaltzustände in Kleinschreibung übermittelt werden, statt der defaults "ON" bzw. "OFF".

Allerdings stellt dieses das ''autocreate'' an dem MQTT2_DEVICE auf 0, was dann nicht optimal ist, wenn man weitere Readings aus dem Gerät erwartet, etwa, weil zusätzliche Sensoren vorhanden sind. In diesem Fall empfiehlt es sich, das ''autocreate''-Attribut an dem MQTT2_DEVICE zu löschen, damit alle weiteren Informationen verarbeitet werden und ggf. im ''jsonMap''-Attribut nur die Angabe "''POWER1:state''" zu belassen.

=== on-for-timer ===
Um z.B. ein Relais nur für einen Zeitraum anzuschalten, kann man bei Tasmota-Geräten zwischen mehrere Varianten wählen. Ohne speziellen ''setter'' in der ''setList'' werden die '''SetExtensions''' verwendet. Timer laufen damit innerhalb FHEM. Da diese intern als temporäres [[at]] ausgeführt werden, sind diese auch noch nach einem FHEM-Neustart vorhanden, sofern FHEM ordnungsgemäß beendet und neu gestartet wird.

Die Tasmota-firmware bietet ergänzend dazu zwei Möglichkeiten an, bei denen der Timer direkt auf dem ESP-Microcontroller verwaltet wird:

==== delay ====
Zeile zur Erweiterung der ''setList'' (Attributeingabe via FHEMWEB!):
on-for-timer {my $duration = $EVTPART1*10; 'cmnd/DVES_575127/Backlog POWER1 1; delay '.$duration.'; POWER1 0'}

Ohne Auswirkungen auf alles, was danach kommt, hat aber den Nachteil, dass die möglichen Zeitspannen auf 3600 1/10 Sekunden begrenzt sind (siehe https://github.com/arendst/Tasmota/wiki/Commands#delay), also eine Stunde.

====pulseTime ====
Zeile zur Erweiterung der ''setList'' (s.o.):
on-for-timer {my $duration = $EVTPART1 < 11.2 ? $EVTPART1*10 : $EVTPART1+100; 'CMNDTOPIC/Backlog pulseTime1 '.$duration.'; POWER1 1'}
Auch hier sind die möglichen längsten Einschaltdauern begrenzt, allerdings ist diese mit 18h deutlich länger als mit ''delay''. Diese Implementierung hat den Nachteil, dass der ESP-Microcontroller die jeweils letzte pulseTime auch für alle weiteren "normalen" Einschaltvorgänge berücksichtigt, das Relais also ebenfalls nach Ablauf der übermittelten pulseTime abgeschaltet wird; dies gilt allerdings ohne explizites ''save'' nur bis zum nächsten reboot des Microcontrollers.

== ESPurna ==
ESPurna ist eine weitere alternative firmware für ESP8266-basierte Geräte, Details sind der [https://github.com/xoseperez/espurna/wiki Projektseite] zu entnehmen.

Das Format, in dem ESPurna Daten sendet, unterscheidet sich v.a. darin, dass bool'sche Werte als 0 oder 1 gesendet werden, und nicht wie sonst üblich als "on" oder "off" oä.. Es stehen einige Mustertemplates zur Verfügung, um diese Art der Payload in FHEM-konforme Werte zu überführen.

== Shelly ==
=== Vorbemerkung ===
Auch für Shelly-Geräte steht eine Auswahl an [[MQTT2-Module - Praxisbeispiele#attrTemplate_2|templates]] bereit.
Beachten Sie auch hier, dass uU. bei Anwendung eines template mit "split" im Namen weitere Geräte angelegt und konfiguriert werden.

=== Shelly1 ===

=== Shellybulb ===
Zunächst muss man einen Statusupdate des Shellybulb erzwingen (Aus- und Einschalten, physikalisch oder per Web-UI), damit das Gerät bei eingeschaltetem autocreate angelegt wird. Dies sieht zunächst so aus:
Internals:
CFGFN
CID shellybulb_3CC533
DEF shellybulb_3CC533
DEVICETOPIC MQTT2_shellybulb_3CC533
IODev MQTT2_FHEM_Server
NAME MQTT2_shellybulb_3CC533
NR 246
STATE ???
TYPE MQTT2_DEVICE
READINGS:
2018-12-12 19:28:08 status_blue 0
2018-12-12 19:28:08 status_brightness 61
2018-12-12 19:28:08 status_effect 0
2018-12-12 19:28:08 status_gain 26
2018-12-12 19:28:08 status_green 0
2018-12-12 19:28:08 status_ison true
2018-12-12 19:28:08 status_mode color
2018-12-12 19:28:08 status_red 255
2018-12-12 19:28:08 status_temp 3250
2018-12-12 19:28:08 status_white 0
Attributes:
IODev MQTT2_FHEM_Server
readingList shellybulb_3CC533:shellies/shellybulb-3CC533/color/0/status:.* { json2nameValue($EVENT, 'status_') }
room MQTT2_DEVICE
[[Bild:MQTT2 Shellybulb.png|400px|thumb|Darstellung in FHEMWEB nach Anwendung des template]]Dann bei den set-Anweisungen das attrTemplate "shellybulb" auswählen und setzen. Es erscheint eine Abfrage, ob die vorhandenen Readings gelöscht werden sollen. Diese bitte bestätigen und die Seite neu laden. Danach einmal An- und Ausschalten, damit die Readings auch durch einen neuen Status initialisiert werden und die Seite im Browser neu laden.

=== Shelly Plug S ===
Über die Leistungsmessung des Shelly Plug S lässt sich sehr einfach auch eine Erkennung des Betriebszustandes des angeschlossenen Gerätes realisieren. Dazu stellt man zuerst fest, wieviel Leistung das Gerät in jedem Betriebszustand verbraucht und kann dann z.B. für einen angeschlossenen Fernseher, der im Standby 1 Watt und im Betrieb > 100 Watt verbraucht, den Zustand erkennen und als on/off Status anzeigen. Dazu wird das state Reading wie folgt definiert:
attr readingList shellies/shellyplug-s-123456/relay/0/power:.* { { state => $EVTPART0<100?"off":"on" } }
Der Status des MQTT2 Devices zeigt dann bei <100W "off" und sonst "on" an.

=== HTTP-Commands ===
In diesem {{Link2Forum|Topic=102369|LinkText=Forumsbeitrag}} wird eine Lösung vorgestellt, um über [[99 myUtils anlegen|myUtils-Code]] weitere Kommandos bereitzustellen, die sonst nur direkt über das Web-Interface zu erreichen sind.

== 8-Port-Ethernet Board ==
<gallery>
datei:8-relais-ethernetboard closed.jpg|mit Gehäuse
datei:8-Port-MQTT-Relais-Board.jpg|ohne Gehäuse
</gallery>
In diesem [https://forum.fhem.de/index.php/topic,107536.msg1016379.html#msg1016379 Forenbeitrag] bzw. dem betreffenden Thread wurde ein Relais-Board vorgestellt, mit dem 8 Relais über Ethernetkabel verbunden werden, die Kommunikation erfolgt dann über MQTT. Über die verwendete Software ist wenig bekannt, es könnte jedoch sein, dass diese Art der Einbindung auch bei weiteren Boards funktioniert, die einen bestimmten Ethernet-Chipset von TI (DP83848) und eine Cortex M3 MCU verwenden.

== Milight-Bridge ==
=== Vorbemerkung ===
Der [https://github.com/sidoh/esp8266_milight_hub esp8266_milight_hub] ist ein open source- Projekt, mit dem auf Basis von ''openmili'' eine Vielzahl von MiLight-Geräten gesteuert werden können. Der MiLight-Hub erstetzt dabei eine beliebige Zahl von Milight-Bridges und ist auch zu verschiedenen Versionen des MiLight-Protokols kompatibel.
Neben MQTT kann dieser auch mit HTTPMOD oder Wifilight (bzw. den MiLight-Modulen) gesteuert werden. Die Hardware entspricht dabei im Wesentlichen einem MySensors-Wifi-Gateway<ref>Es wird lediglich ein anderer CS-PIN genutzt. Dies kann einfach in der Web-Oberfläche der Firmware umgestellt werden.</ref>.
Hier wird vorausgesetzt, dass eine funktionierende Bridge vorhanden ist.
Der Vorteil der MQTT-Lösung liegt darin, dass man bei kompatiblen Fernbedienungen auch direkt Informationen über Schaltvorgänge erhält, die mit der Fernbedienung ausgelöst werden.

=== Einstellungen am MiLight-Hub ===
Die zum FHEM-Server bzw. dem MQTT2_SERVER passenden Vorgaben sind im Web-Interface des Hub einzustellen. Gegebenenfalls passen Sie die vom Hub zurückzugebenden Elemente im Web-Interface des Hub an.
Die Einstellungen für ''MQTT topic pattern'' usw. können auf den default-Werten<ref>Diese sind: <br>''milight/:device_id/:device_type/:group_id'' für "topic pattern"<br>''milight/updates/:hex_device_id/:device_type/:group_id'' für "update topic pattern"<br>''milight/states/:hex_device_id/:device_type/:group_id'' für "state topic pattern". Der Autor hat derzeit folgende Infotypen zum Senden markiert: "status, brightness, hue, color, mode, color_temp, bulb_mode, computed_color, hex_color" (enthält eventuell zu viele Angaben. Bei einem Eventhandler muß man uU. darauf achten, dass kurz hintereinander zweimal dasselbe Event kommen kann (für ON/OFF)).</ref> belassen werden, für die seit Mitte 2019 vorhandene Option, eine LWT-Message zu senden (''MQTT Client Status Topic''), tragen Sie ''milight/LWT'' ein und aktivieren ''Detailed''.

=== FHEM-Devices ===
[[Bild:MQTT2 MiLight.png|400px|thumb|Milight: Darstellung in FHEMWEB]]
==== Bridge ====
Wird nun über den Hub oder eine von diesem erkannte Fernbedienung ein vorhandenes Leuchtmittel geschaltet, wird bei eingeschaltetem autocreate ein erstes Device erstellt, die zunächst erstellte Definition sieht typischerweise etwa so aus:
defmod MQTT2_milight_hub_1370325 MQTT2_DEVICE milight_hub_1370325
attr MQTT2_milight_hub_1370325 IODev MQTT2_FHEM_Server
attr MQTT2_milight_hub_1370325 readingList milight_hub_1370325:milight/updates/0xBE59/rgbw/1:.* { json2nameValue($EVENT, '1_', $JSONMAP) }
attr MQTT2_milight_hub_1370325 room MQTT2_DEVICE

Auf dieses Device wird nun das ''template'' '''esp_milight_hub_bridge''' angewandt.

==== Einzelne Leuchtmittel ====

Wird nun nochmals das oben verwendete Leuchtmittel geschaltet, erstellt autocreate ein weiteres Device:
defmod MQTT2_milight_0xBE59_1 MQTT2_DEVICE milight_0xBE59_1
attr MQTT2_milight_0xBE59_1 IODev MQTT2_FHEM_Server
attr MQTT2_milight_0xBE59_1 readingList milight/states/0xBE59/rgbw/1:.* { json2nameValue($EVENT, '1_', $JSONMAP) }
attr MQTT2_milight_0xBE59_1 room MQTT2_DEVICE

Auf dieses wird nun eines der Bulb-templates angewendet. Wählt man das template X_01_esp_milight_hub_rgbw_bulb, wird eine einfache Variante erstellt, die neben einem toggelnden Icon nur Regler für Helligkeit, die Farbe und zwei Schaltflächen für den Weiß- und Nachtmodus enthält. Wer mehr oder andere Steuerelemente erhalten möchte, verwendet ein anderes template. Nicht benötigte Elemente kann man dabei einfach aus der Definition löschen.

Alle weiteren Devices werden genauso erstellt.

Um ein Device zu erhalten, mit dem sich alle Kanäle gleichzeitig steuern lassen, kann das template ''X_01a_esp_milight_hub_make_rgbw_group'' verwendet werden. Dieses verändert nicht das aktuelle Device, sondern erstellt '''eine Kopie''', die dann modifiziert wird. Diese Kopie ist unter dem Namen ''milight_<RemoteID>_0'' im selben Raum zu finden wie das Ausgangsgerät und kann ebenfalls an die eigenen Wünsche angepaßt werden.

Weitere Beispiele:
Beispiel für ein RGB-CCT-Device:
defmod Licht_Wz_all MQTT2_DEVICE
attr Licht_Wz_all IODev MQTT2_Broker
attr Licht_Wz_all eventMap /set_white:Weiss/night_mode:Nacht/white_mode:white/on:on/off:off/ON:on/OFF:off/next_mode:Mode/mode_speed_up:Up/mode_speed_down:Down/
attr Licht_Wz_all group Licht
attr Licht_Wz_all icon light_control
attr Licht_Wz_all readingList milight/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\
milight/updates/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\
milight/states/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\

attr Licht_Wz_all room Wohnzimmer
attr Licht_Wz_all setList on milight/0x5D02/rgb_cct/0 {"status":"ON"}\
off milight/0x5D02/rgb_cct/0 {"status":"OFF"}\
level milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
hue:colorpicker,HUE,0,1,359 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
command:uzsuSelectRadio,Weiss,Nacht,Mode,Up,Down milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
brightness:colorpicker,BRI,0,1,255 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
next_mode milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
mode_speed_up milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
mode_speed_down milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
saturation:colorpicker,BRI,0,1,100 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
color_temp:colorpicker,CT,153,1,370 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
device_id milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
effect milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
mode milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
commands milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}
attr Licht_Wz_all sortby 1
attr Licht_Wz_all webCmd command:brightness:saturation:color_temp:hue
attr Licht_Wz_all webCmdLabel command\
:brightness:saturation\
:color_temp:hue
==== Ein Leuchtmittel, mehrere Fernbedienungen ====
Pairt man mehrere Fernbedienungen mit einem Leuchtmittel, sollten auch alle entsprechenden Fernbedienungscodes in das readingList-Attribut übernommen werden. Dazu übernimmt man am einfachsten die Einträge aus den zusätzlichen MQTT2_DEVICEs. Benötigt man das zusätzliche Device nicht separat, um z.B. eine getrennte Gruppenschaltung zu realisieren, kann man dieses löschen. Beispiel-readingList für ein Device, das auf zwei Fernbedienungscodes und zwei Gruppen "hört":

attr Licht_Wz_all readingList milight/states/0x1234/rgbw/2:.* {json2nameValue($EVENT) }\
milight/updates/0x1234/rgbw/2:.* { json2nameValue($EVENT) }\
milight/states/0x1234/rgbw/0:.* { json2nameValue($EVENT) }\
milight/updates/0x1234/rgbw/0:.* { json2nameValue($EVENT) }\
milight/states/0xABCD/rgbw/0:.* { json2nameValue($EVENT) }\
milight/updates/0xABCD/rgbw/0:.* { json2nameValue($EVENT) }\
milight/states/0xABCD/rgbw/4:.* { json2nameValue($EVENT) }\
milight/updates/0xABCD/rgbw/4:.* { json2nameValue($EVENT) }

==== Fernbedienung als Input-Device nutzen ====
In diesem {{Link2Forum|Topic=103493|LinkText=Thread}} ist dargestellt, wie man eine Fernbedingung des Typs FUT089 dazu verwenden kann, einen [[MPD]] oder Rollladenaktoren zu steuern, oder diese Fernbedienung für [[Hue#HUE-Device|HUEDevice]]-Leuchtmittel zu nutzen.
Um hier nur Differenz-Meldungen zu erhalten und doppelte Events zu verhindern, sollte hier die readingList so angepaßt werden, dass nur Messages aus dem "updates"-Zweig ausgewertet werden:
defmod MiLight_RC1_0 MQTT2_DEVICE milight_0xABCD_0
attr MiLight_RC1_0 readingList milight/updates/0xABCD/fut089/0:.* { json2nameValue($EVENT) }\
milight/states/0xABCD/fut089/0:.* {}

== eBus ==
An dieser Stelle sollen lediglich die Grundzüge erläutert werden, eine ausführliche Anleitung über die Konfiguration des [[EBUS-MQTT2|eBus mit MQTT2 gibt es hier]].

=== Vorbereitung und Definition am eBus ===
Vorausgesetzt wird ein laufender eBus-Dämon. Dessen Einrichtung wird im Artikel [[EBUS#Software|EBUS]] beschrieben.
In der Konfiguration des Dämons ( /etc/default/ebusd ) ist die Kommunikation über MQTT zu aktivieren und die Topic-Struktur festzulegen, z.B. ''ebusd/%circuit/%name''.
--accesslevel=* --mqttport=1883 --mqttjson --mqtthost=IpAdresseMQTTSERVER --mqtttopic=ebusd/%circuit/%name
{{Hinweis|Nachfolgend wird davon ausgegangen, dass als Vorgabe für mqtttopic ''ebusd'' verwendet wurde. Dies kann geändert werden, es wird aber dringend empfohlen, das mqtttopic in jedem Fall mit ''ebus...'' zu beginnen!}}

=== Vorbereitung und Definition in FHEM ===
Unabhängig von dem konkret genutzten IO-Modul (MQTT2_SERVER oder MQTT2_CLIENT) sollte an diesem '''''vor''''' den nachfolgenden Schritten zunächst das autocreate ausgeschaltet werden. Weiter sollte geprüft werden, ob es bereits MQTT2_DEVICE-Geräte gibt, die Einträge in der ''readingList'' enthalten, die vom ebus stammen. Da wir die ''readingList'' anschließend mit erweiterten JSON-Optionen erstellen wollen, müssen zumindest sämtliche ''readingList''-Attribute entsprechend bereinigt oder gelöscht werden; in der Regel ist es einfacher, diese Geräte nach dem Deaktivieren des autocreate am IO zu löschen.
{{Randnotiz|RNTyp=y|RNText=Sollten Sie MQTT2_CLIENT als IO nutzen, sollte für das weitere Vorgehen eine Kopie des MQTT2-"Sammeldevices" genutzt werden, und dessen ''CID'' auf ''ebusd'' geändert werden. Nach Anwendung des ebusd-splitter-templates müssen dann alle den ebus betreffenden Einträge aus der ''readingList'' des "Sammeldevices" gelöscht werden oder diese ganz gelöscht.}}Ist der ebus-Dämon lauffähig und für MQTT konfiguriert, sendet dieser regelmäßige Messages.

Sind die Vorbereitungen abgeschlossen, aktivieren wir ''autocreate'' wieder, allerdings wählen wir als autocreate-Methode ''complex'' aus, da der eBus-Dämon teilweise<ref>Dies betrifft vorrangig die Statusmeldungen</ref> eine weiter verschachtelte JSON-Struktur zum Versenden der Informationen verwendet als üblich. Danach wird wie bei den anderen o.g. Geräten automatisch ein neues MQTT2_DEVICE angelegt<ref>Bei Verwendung des MQTT2_CLIENT wird dann die ''readingList'' am bereits definierten MQTT2_DEVICE aus der Kopie des "Sammeldevice" automatisch wieder erstellt bzw. gefüllt.</ref>

==== "ebus-Bridge" ====
Auf das von ''autocreate'' erstellte MQTT2_DEVICE wird nunmehr das template ''eBus_daemon_splitter'' angewendet. Nach einiger Zeit sollte sowohl die readingList an diesem Device erweitert worden sein, wie auch ein oder mehrere neue MQTT2_DEVICE-Geräte angelegt.
Dieses Device liefert zukünftig Readings zum Dämon selbst, wie dessen ''uptime'', alle weiteren am eBus angeschlossenen Teilnehmer werden dagegen zweckmäßigerweise durch ein oder mehrere weitere MQTT2_DEVICE-Geräte dargestellt.

Das ''attrTemplate'' läd eine weitere ''attrTemplate''-file und [[99 myUtils anlegen|99_myUtils-Code]] vom FHEM-Server nach. Beides steht dann auch unmittelbar zur Nutzung zur Verfügung.
==== "ebusd_bai" und weitere Geräte ====
{{Hinweis|Der eBus-Dämon sendet nicht alle Informationen zu allen am eBus angeschlossenen Geräte automatisch. Diese müssen teilweise erst aktiv angefragt werden. Wie das im einzelnen erfolgen kann, ist dem o.g. Detailartikel zu entnehmen.}}
Funktioniert die Kommunikation zwischen dem eBus-Dämon und FHEM, sollte nach einigen Minuten zumindest ein weiteres Gerät namens ''MQTT2_ebus_bai'' angelegt worden sein.

== Allgemeine Hinweise ==
=== MQTT2_SERVER und MQTT2_CLIENT für Debugging nutzen ===
Nutzt man das rawEvents-Attribut am MQTT2-IO<ref>z.B. <code>attr MQTT2_FHEM_Server rawEvents .*</code>, der regex-Filter kann wie üblich angepaßt werden</ref>, kann man den Datenverkehr des Servers am Event-Monitor mitschneiden. Dies ist insbesondere für unbekannte Geräte nützlich, deren Topic- und Payload-Struktur noch nicht bekannt ist.
Um den kompletten MQTT Datenaustausch mitzuschneiden, kann man mit <code>attr mqtt2_server verbose 5</code> auch alles ins FHEM-Log schreiben lassen.

=== attrTemplate ===
Zur Konfiguration von MQTT2_DEVICE-Geräten kann die Funktion ''[[AttrTemplate|attrTemplate]]'' genutzt werden.
Die Anwendung für MQTT2_DEVICE ist [[MQTT2 DEVICE#attrTemplate|hier]] beschrieben.

{{Hinweis|In einigen Fällen kann es vorkommen, dass die template-Bezeichnung zwischenzeitlich geändert wurde. Seit 21.09.2019 erfolgt die Sortierung der auswählbaren templates nicht mehr nur nach den Namen, so dass die entsprechenden Namensbestandteile entfallen sind, die einer besseren Sortierung dienten.}}

=== attrTemplate: Es werden nicht alle templates angezeigt ===
Siehe Beitrag [[AttrTemplate#Warum finde ich das Template xyz nicht.3F|AttrTemplate: Warum finde ich das Template xyz nicht.]]

=== attrTemplate und Sprachsteuerung ===
Konfiguriert man MQTT2_DEVICE-Geräte mit attrTemplate, werden in der Regel auch direkt die für die Sprachsteuerung der Geräte erforderlichen Attribute mit gesetzt. Weiterführende Hinweise sind auch zu diesem Teilaspekt von ''[[AttrTemplate|attrTemplate]]'' dem betreffenden Hauptartikel zu entnehmen.

=== bridgeRegexp ===
[[Datei:Mqtt2 server.png|300px|thumb|left|Logische Verortung der bridgeRegexp-Angaben]]{{Randnotiz|RNTyp=y|RNText=Beachten Sie, dass aufgrund des geschilderten Prinzips eine Änderung einer bridgeRegexp bei einem Gerät auch dazu führt, dass alle Readings eines Geräts und alle readingList-Einträge gelöscht werden.}}Üblicherweise werden alle Informationen, die aus einer Quelle stammen auch '''''einem''''' ''MQTT2_DEVICE'' zugeordnet, wobei im Falle des dort nicht aktivierten autocreate-Attributs entsprechende readingList-Einträge erzeugt werden. Das '''Attribut''' ''bridgeRegexp'' kann dazu genutzt werden, um neue, bisher unbekannte Topic-Strukturen im Rahmen des autocreate-Vorgangs anders zu strukturieren. Diese werden dabei im Ergebnis einem '''anderen Device''' (das ggf. erst erstellt wird) zugeschlagen, sollte eine zu der topic-Struktur passende regex in diesem Attribut gesetzt sein. Für dessen CID und die Bildung des Names wird die im 2. Teil jedes Eintrags als ''newClientId'' hinterlegte Angabe verwendet.
Dementsprechend sind in den hier aufgeführten Beispielen ''bridgeRegexp''-Attribute immer dort zu finden, wo ein Gerät oder Dienst dazu dient, mit weiteren, ggf. auf andere Weise kommunizierende Geräte oder Baugruppen zu kommunizieren. Ein Sonderfall hierbei ist das template ''MQTT2_CLIENT_general_bridge'' zur Verwendung mit dem [[MQTT2_CLIENT#Anwendung|MQTT2_CLIENT]], denn aus dessen Sicht stammen alle Informationen aus derselben Quelle, nämlich z.B. dem ''mosquitto''-Server und würden sonst alle einem einem MQTT2_DEVICE zugewiesen.

=== Ständig neue Devices? ===
MQTT2_SERVER kann zwischen verschiedenen Geräten auch anhand der ClientID unterscheiden. Für jedes neu erkannte Gerät wird auch ein eigenes MQTT2_DEVICE angelegt. Abhilfemaßnahmen:
==== Vergabe einer ClientID ====
Die meisten MQTT-fähigen Geräte enthalten Optionen zur Vergabe einer eindeutigen ClientID (siehe das Beispiel des zigbee2mqtt-Dienstes oben).
Wird keine ClientID vergeben, verwenden manche Clients für jede Verbindung wieder neue ID's. Es wird empfohlen, möglichst von diesen Einstelloptionen Gebrauch zu machen.

==== Löschen der ClientID aus der readingList usw. ====
Ist dies nicht möglich oder erwünscht, kann man auch die ClientID aus den readingList-, setList- und getList-Attributen entfernen. Dies ist jedenfalls solange unschädlich als nicht mehrere Geräte identische Topic-Pfade verwenden (daher die Empfehlung, insbesondere bei Tasmota-Geräten den ''default'' "sonoff" zu ändern).
Beispielsweise wäre <code>attr Milight_Bridge readingList milight_hub_1370325:milight/LWT:.* {json2nameValue($EVENT) }</code> zu ändern in <code>attr Milight_Bridge readingList milight/LWT:.* {json2nameValue($EVENT) }</code>
Die über ''attrTemplate'' verfügbaren Konfigurationen verwenden in der Regel keine ClientID's bzw. entfernen diese.

=== Wildcards in readingList und setList ===
Auch in readingList und in setList sollten sich sog. wildcards verwenden lassen. Die Vorgehensweise ist jedoch unterschiedlich:

In ''readingList'' werden normale regex-Ausdrücke verwendet. Ein Punkt steht daher z.B. für ein beliebiges Zeichen, alles zwischen zwei Topic-Tree-Elementen (getrennt typischerweise durch einen "/") kann man so schreiben: "[^/]+" (entspricht: "Mindestens ein Zeichen, das kein Schrägstrich ist"). Ergänzender Hinweis: Will man z.B. Informationen aus einem beliebigen Teil des Topic-trees extrahieren und als Reading-Namen verwenden, kann dies im Rahmen eines Perl-Aufrufs geschehen. Beispiele aus der mqtt2.template-file: OpenMQTTGateway_BT_scanner und OpenMQTTGateway_BT_gtag (letzteres überführt die Information, über welches Gateway bestimmte Informationen eingegangen ist jeweils in eigene Readings pro Gateway).

In ''setList'' gelten dagegen die wildcard-Konventionen aus der MQTT-Welt. Dort steht "+" für einen austauschbaren Teil des Topic-Trees (zwischen zwei Schrägstrichen). Anmerkung: Bitte vorher prüfen, ob es wirklich sinnvoll ist, derart unspezifische Publishes vorzunehmen. Meist gibt es "Gruppen-Topics", auf die mehrere Geräte eines bestimmten Typs hören bzw. man kann dies dort (in der firmware bzw. auf den Konfigurationsseiten der Geräte) einstellen.

=== Weiterführende Themen ===
==== Verbinden mehrerer FHEM-Instanzen über MQTT ====
Wie im Hauptartikel zu [[MQTT#Kommunikation zu sonstigen FHEM-Geräten über MQTT|MQTT]] erläutert, gibt es mehrere Varianten, wie man mit Hilfe von FHEM aus Events an beliebigen Geräten MQTT-Messages erzeugen kann. So kann man z.B. Messdaten eines Systems über ein ''notify'' iVm. einer einfachen ''publish''-Anweisung an ein zweites FHEM schicken, das diese Daten dann z.B. mit Hilfe der MQTT2-Module auswerten kann.
Damit dabei Nachrichten unterschiedlicher Quellen auch als getrennte Readings bzw. ggf. auch gesonderten MQTT2_DEVICE-Instanzen zugeordnet werden, sollte man entsprechende Topic-Strukturen wählen, die dann auch mit Hilfe einer geeigneten ''bridgeRegexp'' automatisiert ausgewertet werden kann, siehe z.B. dieser {{Link2Forum|Topic=107145|LinkText=Forumsthread}}:
attr MQTT2_myMqttServer bridgeRegexp \
SmartHome/MqttGenericBridge2/([A-Za-z0-9]*)/.*:.* "mgb2_$1"
Dabei werden die betreffenden Informationen der entfernten FHEM-Instanz alle nach dem Schema ''SmartHome/MqttGenericBridge2/<Device-Name>/<Reading-Name>'' versendet.

==== Umstellung von MQTT_DEVICE (und Derivaten wie XiaomiMQTTDevice) zu MQTT2_DEVICE ====
Wer beabsichtigt, von der Implementierung MQTT+MQTT_DEVICE zu MQTT2-IO und MQTT2_DEVICE zu wechseln, sollte einige Punkte beachten. Viele diesbezügliche Fragen sind vor allem in {{Link2Forum|Topic=103762|LinkText=diesem Foren-Thread}}

näher erläutert.

== Links ==
* {{Link2Forum|Topic=91394|LinkText=Thread, aus dem diese Anleitung ursprünglich entstanden ist}}
* {{Link2Forum|Topic=91807|LinkText=Thread zum Tasmota-Device}}
* {{Link2Forum|Topic=97989|LinkText=Thread, aus dem diese Anleitung für den eBus ursprünglich entstanden ist}}
* {{Link2Forum|Topic=94495|LinkText=Neue templates einreichen}}
* {{Link2Forum|Topic=94494|LinkText=Fragen, Wünsche und Kritik zu mqtt2.template}}

== Hinweise ==
<references />
[[Kategorie:HOWTOS]]
[[Kategorie:MQTT]]
[[Kategorie:ZigBee]]
[[Kategorie:IP Components|IP Komponenten]]
[[Kategorie:Other Components]]
[[Kategorie:Interfaces]]

MQTT

2020-06-08T06:00:30Z

PeMue: Hinweis auf Eintragen User/Passwort in Geräten bei Absicherung mit allowed

MQTT ist ein Protokoll ("Message Queue Telemetry Transport"), mit dem Daten und Befehle zwischen verschiedenen Geräten ausgetauscht werden. Die Kommunikation erfolgt dabei über einen zentralen MQTT-Server, in alter Nomenklatur auch ''Broker'' genannt.

MQTT wurde entwickelt, um möglichst effizient, sicher und mit wenig Datenlast zu kommunizieren. MQTT ist nachrichtenorientiert, daher muss ein Client nicht beständig beim Server anfragen, ob neue Daten vorliegen. Heute findet sich MQTT vor allem im Bereich des ''Internet of Things'' (IoT). MQTT kann leicht mit FHEM verbunden werden, ohne dass dabei größerer CPU- oder Datenverbrauch entsteht.

== Eine sehr kurze Einführung in MQTT ==
Die folgende Einführung kann eine vollwertige Einleitung wie beispielsweise [https://github.com/mqtt/mqtt.github.io/wiki diese Wikieinträge] nicht ersetzen.

Bei MQTT findet die nachrichtenbasierte Kommunikation zwischen einzelnen Teilnehmern<ref>Teilnehmer in diesem Sinne kann ein Stück Hardware mit einer MQTT-fähigen firmware sein, ein auf einem Computer laufendes Script (einschließlich eines MQTT-Server-Dienstes wie ''mosquitto'' oder ''MQTT2_SERVER'', kurz: alles mögliche sein. Dadurch kann auch ein einzelner Computer unter mehreren ClientID's am MQTT-Datenaustausch beteiligt sein.</ref> in der Regel nicht direkt statt. Stattdessen werden alle Nachrichten von einem Teilnehmer an einen Serverdienst, den MQTT-Server (früher ''Broker'' genannt) übergeben, der dann dafür sorgt, dass die Nachricht an alle (berechtigten) anderen Teilnehmer verteilt wird, die sich für derartige Nachrichten "interessieren". Wenn also ein Teilnehmer ohne Server-Funktion (Client) Daten von einem bestimmten anderen Teilnehmer (anderer Client) empfangen will, muss es vorher dem MQTT-Server (Broker) mitteilen, dass er die Nachrichten dieses anderen Teilnehmers abonniert (deshalb wird dieser Vorgang als ''subscribe'' bezeichnet). Im IoT ist besonders interessant, dass Sender und Empfänger von Nachrichten durch den MQTT-Server vollständig entkoppelt werden können - jemand, der Daten bereit stellt, muss sich also nicht darum kümmern, wer diese Daten empfängt<ref>Aufgrund dieser Funktionsweise sollte allerdings darauf geachtet werden, die Möglichkeiten des jeweiligen Servers zur Sicherung der Daten gegen unberechtigten Zugriff zu nutzen, insbesondere wenn die Art der Daten oder die sich hierdurch ergebenden Möglichkeiten, z.B. Schaltvorgänge in der realen Welt auszulösen, dies notwendig macht!</ref>.

Eine Nachricht besteht im Wesentlichen aus den folgenden Elementen:
*ClientID - das ist die Kennung des Senders einer Nachricht<ref>Diese kann sich bei der Weitergabe der Nachricht ändern: Zunächst sendet ein Client eine Nachricht unter seiner ClientID, der MQTT-Server wird diese dann in der Regel durch seine Kennung ersetzten, wenn er die Nachricht an einen Abonnenten - der auch ein weiterer MQTT-Server sein kann - weitergibt.</ref>
*Topic - das ist die Adresse, an die eine Nachricht gesendet wird, bzw. von wo sie abgeholt werden kann (so ähnlich wie ein Postfach in der realen Welt). Topics sind einfache Strings, die mit Schrägstrichen getrennt werden (keine Leerzeichen und nur sehr wenige Sonderzeichen erlaubt). Ein Topic könnte beispielhaft so lauten: <code>zuHause/1OG/Kueche/Licht/state</code>. Diese Topics beinhalten also eine Hierarchie der Objekte - hier im Beispiel sind sie zuerst danach sortiert, ob sie sich zu Haus befinden, dann wird nach Stockwerken sortiert und im ersten Stock schaut man auf die Küche sowie das dort vorhandene Licht.
*Payload - das ist der Inhalt der Nachricht, oft handelt es sich um Befehle oder Daten.
*Quality of Service - soll geprüft werden, ob die Nachricht zugestellt wurde und wenn ja, mit welcher "Tiefe"?
*Retained Message.
Details bitte in der oben genannten Einführung nachlesen.

MQTT kommuniziert üblicherweise über Port 1883, es können aber unter derselben Netzwerkadresse an unterschiedlichen Ports auch mehrere Serverdienste bereitstehen.

== Installation in FHEM ==
Um MQTT in FHEM zu nutzen, benötigt man (mindestens) einen MQTT-Server. Es gibt zwei Möglichkeiten: Man kann FHEM-externe Server-Software (oder auch einen oder mehrere im Internet bereitstehende MQTT-Server) verwenden oder man kann die MQTT-Serverkomponente aktivieren, die mit {{Link2CmdRef|Anker=MQTT2_SERVER|Lang=en|Label=MQTT2_SERVER}} in FHEM direkt bereitsteht. Hier werden kurz beide Installationswege erläutert, zwingend ist nur einer, da eben mindestens ein MQTT-Serverdienst aktiv sein muß.

Die nachfolgenden Schaubilder zeigen schematisch die in FHEM zur Verfügung stehenden Wege der Einbindung von Hard- und/oder Softwarekomponenten, die über das MQTT-Protokoll Daten austauschen.
<gallery>
Datei:Mqtt2 server.png|Datenaustausch mit MQTT-Geräten, wenn MQTT2_SERVER als internem MQTT-Serverdienst verwendet wird
Datei:Mqtt2 client v extern server.png|Datenaustausch mit MQTT-Geräten, wenn MQTT2_CLIENT iVm. mosquitto als externem MQTT-Serverdienst verwendet wird
Datei:00 mqtt pm.png|Datenaustausch mit MQTT-Geräten, wenn das Modul ''MQTT'' (00_MQTT.pm) iVm. mosquitto als externem MQTT-Serverdienst verwendet wird
</gallery>
=== FHEM als MQTT-Server ===
Die mit dem Modul {{Link2CmdRef|Anker=MQTT2_SERVER|Lang=en|Label=MQTT2_SERVER}} bereitstehende Serverkomponente kann z.B. wie folgt aktiviert werden:
defmod myBroker MQTT2_SERVER 1883 global
Dieses [[Gerät]] übernimmt dann die Kommunikation mit den externen Clients (und wird von diesen behandelt, wie jeder andere MQTT-Server auch<ref>Bitte beachten Sie, dass (Stand: Juni 2019) MQTT2_SERVER nicht alle features des MQTT-Protokolls unterstützt.</ref>) und verteilt die eingehenden Nachrichten als IO-Device<ref>im Sinne des [[DevelopmentModuleIntro#Zweistufiges Modell für Module|2-stufigen Modulkonzepts]]</ref> für die Client-Module [[MQTT2_DEVICE]]<ref>Die Zahl 2 in den Modulnamen verweist nur darauf, dass es sich um eine neuere Modulfamilie handelt; die Kommunikation mit den externen Komponenten unterscheidet sich nicht zu den älteren Modulen, die vor dem Jahr 2018 genutzt werden konnten.</ref> und {{Link2CmdRef|Anker=MQTT_GENERIC_BRIDGE|Lang=de|Label=MQTT_GENERIC_BRIDGE}}.
Ein weiterer Vorteil dieser Lösung besteht darin, dass man ein MQTT2_SERVER-Device mit Hilfe von [[allowed]] absichern kann, was auch SSL-verschlüsselte Kommunikation ermöglicht. '''Hinweis:''' In diesem Fall muss User bzw. Passwort auch in den entsprechenden Geräten eingetragen werden.

{{Hinweis|Wenn Sie beabsichtigen, diese Variante zu verwenden, sollten Sie als nächstes die [[MQTT2-Module - Praxisbeispiele|Praxisbeispiele zu den MQTT2-Modulen]] lesen, und ggf. später wieder hierher zurückkehren. Dort findet sich auch ein Abschnitt zu dem auf den Grafiken zu den MQTT2-IO-Modulen enthaltenen [[MQTT2-Module_-_Praxisbeispiele#bridgeRegexp|bridgeRegexp]]-Attribut.}}

=== FHEM-externer Broker ===
==== Beispiel: mosquitto ====
Eine gern verwendete MQTT-Server-Software ist [http://mosquitto.org Mosquitto]. Sie kann ohne weiteres auf dem Raspberry Pi, der bereits eine FHEM-Installation besitzt, installiert werden und wird keine größere CPU- oder Netzwerklast verursachen.

Eine Anleitung zur Installation findet sich beispielsweise in diesem [http://blog.wenzlaff.de/?p=6487 Blogeintrag]. Im wesentlichen beschränkt sich die Installation eines MQTT Servers aber auf wenige Arbeitsschritte. Bei ''stretch'' ist ''Mosquitto'' bereits in der Distribution enthalten und kann - zusammen mit dem client Befehl ''mosquito_sub'', der weiter unten benötigt wird, wie folgt installiert und getestet werden<ref>Die für den Betrieb mit FHEM erforderlichen Perl-Module sind teilweise (noch) nicht in den Paketquellen verfügbar. Sie können dennoch statt mit cpan auch als Debian-Paket mit Hilfe von ''dh-make-perl'' installiert werden, wobei vorab das in den Paketquellen bereits vorhandene ''libmodule-pluggable-perl'' installiert werden sollte:<br>
<code>sudo apt-get install dh-make-perl<br>
dh-make-perl --install --cpan Net::MQTT::simple<br>
dh-make-perl --install --cpan Net::MQTT::Constants<br>
sudo dpkg -i libnet-mqtt-simple-perl*.deb<br>
sudo dpkg -i libnet-mqtt-perl*.deb</code></ref>:
{{Randnotiz|RNTyp=g|RNText=Für ältere Distributionen (hier am Beispiel von ''jessie'') muß ggf. aus einer zusätzlichen Paketquelle installiert werden:
wget http://repo.mosquitto.org/debian/mosquitto-repo.gpg.key
sudo apt-key add mosquitto-repo.gpg.key
cd /etc/apt/sources.list.d/
sudo wget http://repo.mosquitto.org/debian/mosquitto-jessie.list
sudo apt-get update
Danach kann die eigentliche Installation durchgeführt werden wie links für ''stretch'' beschrieben.}}<source lang="bash">
sudo apt-get install mosquitto mosquitto-clients

# MQTT Server Test
sudo service mosquitto status

# Start / Stop des Servers
sudo service mosquitto stop
sudo service mosquitto start
</source>
Danach ist der RPi mit <nowiki>shutdown restart</nowiki> neu zu starten.

==== IO-Module für externe MQTT-Server ====
Damit FHEM mit dem MQTT-Server kommuniziert, muss noch ein IO-Device angelegt werden. Dabei stehen zwei Varianten zur Wahl, das Modul [[MQTT (Modul)|MQTT]] oder seit Ende 2018 [[MQTT2_CLIENT]].

Beide Module können auch dazu genutzt werden, um Daten zwischen zwei FHEM-Installationen auszutauschen, insbesondere kann auch 00_MQTT.pm als Client für einen MQTT2_SERVER eingesetzt werden, der '''auf der anderen Installation''' als MQTT-Serverdienst eingerichtet ist. Darüber hinaus bestehen eine Vielzahl von Kombinationsmöglichkeiten der diversen IO-Module, wenn die Installation auf mehrere Server verteilt ist.
Auf einer FHEM-Installation wird jedoch in der Regel nur eines der IO-Module benötigt.

===== MQTT2_CLIENT =====
Ein MQTT2_CLIENT-IO-Device wird z.B. angelegt mit
define myBroker MQTT2_CLIENT 10.0.0.5:1883 ## bitte EIGENE IP-Adresse eintragen

{{Hinweis|Wenn Sie beabsichtigen, MQTT2_CLIENT zu verwenden, sollten Sie zuerst die [[MQTT2-Module - Praxisbeispiele|Praxisbeispiele zu den MQTT2-Modulen]] lesen, und dabei die Hinweise im Artikel [[MQTT2_CLIENT]] beachten.}}

Ein MQTT2_CLIENT-Device kann ebenfals mit Hilfe von [[allowed]] abgesichert werden, um z.B. SSL-verschlüsselte Kommunikation zu ermöglichem. Client-Module zu diesem IO-Typ sind wiederum [[MQTT2_DEVICE]] und {{Link2CmdRef|Anker=MQTT_GENERIC_BRIDGE|Lang=de|Label=MQTT_GENERIC_BRIDGE}}.

===== MQTT (Modul) =====
Vorab werden für diese Variante weitere Perl-Pakete benötigt:
<source lang="bash">
# Perl Version ausgeben
perl -v
# Perl MQTT Module nachinstallieren (läuft ein paar Minuten)
sudo cpan install Net::MQTT:Simple
sudo cpan install Net::MQTT:Constants
</source>

Ein IO-Device des Typs MQTT wird z.B. angelegt mit
{{Randnotiz|RNTyp=g|RNText=Sofern der Broker mit FHEM über localhost kommuniziert, kann als IP 127.0.0.1 verwendet werden.}}
define myBroker MQTT 10.0.0.5:1883 ## bitte EIGENE IP-Adresse eintragen
{{Randnotiz|RNTyp=g|RNText=Außerhalb der offiziellen Quellen sind auch einige ältere Varianten des Moduls MQTT_DEVICE verfügbar, die jeweils spezielle Anforderungen (z.B. für Zigbee2mqtt) separat abbilden. Diese werden hier nicht gesondert behandelt, da solche Sonderfälle heute generischer und einfacher durch den Einsatz von MQTT2_DEVICE abzubilden sind.}}Client-Device-Module zum Modul [[MQTT (Modul)|MQTT]] sind [[MQTT_DEVICE]], {{Link2CmdRef|Anker=MQTT_BRIDGE|Lang=de|Label=MQTT_BRIDGE}} (veraltet) und {{Link2CmdRef|Anker=MQTT_GENERIC_BRIDGE|Lang=de|Label=MQTT_GENERIC_BRIDGE}}. Da ''MQTT_DEVICE'' payload im JSON-Format (im Unterschied zu MQTT2_DEVICE) nicht selbst verarbeiten kann wird hier zusätzlich das Modul {{Link2CmdRef|Anker=expandJSON|Lang=de|Label=expandJSON}} benötigt, um den {{Link2Forum|Topic=66761|LinkText=JSON String auszuwerten}}.

=== Performancefragen... ===
...oder was sollte man als Lösung wählen, wenn man in die MQTT-Welt einsteigt<ref>vgl. hierzu diesen {{Link2Forum|Topic=94768|Message=875714|LinkText=Beitrag}} von Rudolf König</ref>?
Grundsätzlich sollte man davon ausgehen, dass innerhalb von FHEM die Verarbeitung derselben Daten näherungsweise denselben Aufwand bedeuten, unabhängig davon, welche der Implementierungen (''MQTT2_CLIENT'', ''MQTT'' oder ''MQTT2_SERVER'') man konkret wählt.
Ein externer Broker hat daher vor allem dann Vorteile, wenn die MQTT Daten überwiegend für was anderes (nicht FHEM) verwendet werden, oder MQTT zweckentfremdet wird (wie z.Bsp. für Musikübertragung). Nutzt man das MQTT-Protokoll dagegen vorwiegend innerhalb von FHEM, ist eher der Einsatz von MQTT2_SERVER in Betracht zu ziehen. Dieser soll Anfängern die Anbindung von MQTT Geräten in FHEM einfacher machen. Wer später merkt, dass er doch einen externen Broker benötigt, kann dann immer noch auf MQTT2_CLIENT in Verbindung mit einem anderen Broker wechseln.
Dagegen ist der Weg von MQTT_DEVICE zu MQTT2_DEVICE mit erheblich mehr Aufwand verbunden.

=== Kommunikation zu sonstigen FHEM-Geräten über MQTT ===

Möchte man Daten von einem [[Gerät]] (im FHEM-Sinn), das '''nicht''' vom Typ ''MQTT2_DEVICE'' oder ''MQTT_DEVICE'' (je nach IO-Modul) ist, per MQTT-Protokoll versenden (z.B. für eine andere Visualisierungslösung als FHEMWEB, oder als FHEM2FHEM-Ersatzlösung), oder diese sonstigen Geräte über MQTT-Anweisungen von außen steuern können, hat man mehrere Möglichkeiten:

==== MQTT_GENERIC_BRIDGE ====
Das Modul {{Link2CmdRef|Anker=MQTT_GENERIC_BRIDGE|Lang=en|Label=MQTT_GENERIC_BRIDGE}} ermöglicht es, sein jeweiliges IO-Modul-Gerät zu nutzen, um diesen Kommunikationsweg für beliebig viele andere FHEM-Geräte bereitzustellen. Dabei erfolgt am MQTT_GENERIC_BRIDGE-Gerät selbst nur eine Basiskonfiguration, im Übrigen durch Attribute an dem jeweiligen Gerät selbst. So kann z.B. ein Aktor des Typs [[CUL_HM]] an- oder ausgeschaltet werden oder auch einfach nur seinen aktuellen Schaltzustand per MQTT-Protokoll publizieren.

Dieses Modul kann seit November 2018 mit allen drei IO-Modul-Varianten zusammen eingesetzt werden, also sowohl mit ''MQTT2_SERVER'' bzw. ''MQTT2_CLIENT'' oder ''MQTT'' (00_MQTT.pm).

Dabei sollte man jedoch beachten, dass zur Verwendung mit den MQTT2-IO's unbedingt die autocreate-Funktion des betreffenden IOs ausgeschaltet wird und dies auch bleibt<ref>siehe dazu diesen {{Link2Forum|Topic=95341|LinkText=Thread}} zu den technischen Hintergründen</ref>! Weiter wird das Perl-Modul ''libmodule-pluggable-perl'' benötigt<ref>Dieses kann über <code>apt-get install libmodule-pluggable-perl</code> installiert werden</ref>, damit im Hintergrund auch das Modul [[MQTT (Modul)|MQTT]] geladen werden kann. Damit gelten auch für diesen Modul die Installationsvoraussetzungen für [[MQTT#MQTT_.28Modul.29|MQTT]]!

Anwendungsfälle und -beispiele für das Modul sind diesem {{Link2Forum|Topic=91642|LinkText=Thread}} zu entnehmen.

==== MQTT_BRIDGE ====
Dieses Modul kann nur zusammen mit einem IO-Gerät des Typs [[MQTT (Modul)|MQTT]] verwendet werden. Dabei wird pro weiterzuleitendem anderen FHEM-Gerät eine eigene Instanz dieses Moduls verwendet. Auf den Einsatz dieser Option sollte in neuen Installationen zugunsten von ''MQTT_GENERIC_BRIDGE'' verzichtet werden.

==== Per publish-Befehl am IO-Gerät ====
Alle drei IO-Module kennen direkte ''publish''-Anweisungen, mit deren Hilfe beliebige ''payloads'' an beliebige ''topics'' gesendet werden können. Dies kann man z.B. in einem [[notify]] oder [[at]] nutzen, um einzelne Events zu publishen oder Werteanfragen abzusetzen.

Hier eine regelmäßige Werteabfrage auf einen [[EBUS-MQTT2|ebus]]:
defmod get_ebus_updates at +*00:15:00 set ebusMQTT publish ebusd/430/Hc1HeatCurve/get;
set ebusMQTT publish ebusd/430/HwcTempDesired/get;
...

==== RAW-Events am IO-Gerät (MQTT2.*) ====
Bei beiden MQTT2-IO-Modulen (MQTT2_SERVER und MQTT2_CLIENT) kann per [[Regulärer Ausdruck|regulärem Ausdruck]] festgelegt werden, welche Nachrichten ein Event erzeugen sollen, auf das dann wieder z.B. mit einem [[notify]] reagiert werden kann, z.B. um beliebige Schaltaktionen auszulösen.

== MQTT-Clients (Beispiele) ==

===Arduino-library===
Zur Kommunikation mit dem Broker von Seiten eines [[Arduino|Arduinos]] mit selbst erstellten Sketches böte sich der PubSubClient an.

===PC-Software===
Um die Funktionalität des Brokers zu testen kann z.B. ein Analyse-Tool wie MQTT.fx verwendet werden, oder die im Paket ''mosquitto-clients'' enthaltenen Linux-Kommandozeilen-Programme ''mosquitto_sub'' und ''mosquitto_pub''. Letzterer könnte z.E. auch aus beliebigen ''shell-scripten'' heraus aufgerufen werden. Als Perl-Bibliothek steht alternativ z.B. [https://metacpan.org/pod/distribution/AnyEvent-MQTT/bin/anyevent-mqtt-pub anyevent-mqtt-pub] zur Verfügung.

=== Tasmota ===
Eine derzeit oft genutzte Möglichkeit für MQTT bilden die [[Sonoff]]-Geräte und weitere [[ESP8266]]-basierte Hardware, die unter vielen Handelsnamen erhältlich sind. Werden diese mit Tasmota ('''T'''heo '''A'''rends '''S'''onoff '''M'''QTT '''O'''ver '''T'''he '''A'''ir - einer offenen Firmware von [https://github.com/arendst arendst]) geflasht, so kommunizieren sie über MQTT. Um diese Geräte einzubinden, ist wie folgt vorzugehen. Zuerst ist ein Serverdienst (Broker) bereitzustellen, wie oben beschrieben.

Unter Sonoff sind einige Topics voreingestellt. arendst stellt insbesondere drei Topic-Präfixe bereit, die seiner Meinung jedes Topic einleiten sollen (in den Eingabemasken als "%prefix%" notiert). Das sind einmal Kommandos (abgekürzt als cmnd), die dazu dienen, Befehle auszuführen. Daten werden mit tele und stat übertragen. Ein Topic besteht dann zuerst aus diesem Präfix und danach dem eigentlichen Topic. Wer also beispielsweise einem Sonoff_Switch einen Befehl senden will, sollte als Topic cmnd/Sonoff_Switch wählen. Wenn der Switch ein- und ausgeschaltet werden kann, muss der Topic noch das Wort POWER enthalten (in MQTT werden viele Kennworte komplett groß geschrieben). Der Topic lautet damit vollständig "cmnd/Sonoff_Switch/POWER/set"

{{Randnotiz|RNTyp=g|RNText=Dabei ist darauf zu achten, dass für den Parameter ''topic = %topic% (sonoff)'' statt ''sonoff'' ein gerätespezifischer eigener Name eingetragen wird. Hierzu kann man z.B. auch die dynamisch aus der Chip-ID erzeugte Kennung ''DVES_%06X'' verwenden, indem man die unter ''client (DVES_8BABA9)'' zu findende Angabe kopiert. Die eigentliche Umbenennung zu einem "sprechenden Namen" kann dann innerhalb von FHEM - mittels ''rename'' oder ggf. mit einem ''alias'' - erfolgen.}}

Link zum Forum: {{Link2Forum|Topic=27532|LinkText=MQTT FHEM Einrichtung}} (hier als ''MQTT_DEVICE''!):

### FHEM Device mit MQTT verbinden ###
define Sonoff_Switch MQTT_DEVICE
attr Sonoff_Switch IODev myBroker
attr Sonoff_Switch devStateIcon ON:rc_GREEN:OFF OFF:rc_RED:ON
attr Sonoff_Switch icon hue_filled_br30
attr Sonoff_Switch publishSet ON OFF cmnd/TestSwitch/POWER
attr Sonoff_Switch room MQTT
attr Sonoff_Switch subscribeReading_Licht stat/Sonoff_Switch/POWER
attr Sonoff_Switch subscribeReading_Sensor tele/Sonoff_Switch/SENSOR
attr Sonoff_Switch subscribeReading_Status stat/Sonoff_Switch/STATUS
attr Sonoff_Switch webCmd ON:OFF

Der hier dargestellte Beispielcode realisiert die Kommunikation zwischen FHEM und dem sonoff Modul via MQTT Broker. Zu beachten ist hier, dass '''subscribeReading_Licht''' und '''subscribeReading_Status''' unterschiedliche Syntax des Topic Strings haben!

== Sicherheit ==
Prinzipiell ist MQTT ebenso sicher wie eine Postkarte. Solange man es nicht extra absichert, kann jeder der, im eigenen LAN ist (und die Adresse vom Broker kennt) alle Topics mitlesen.
:<code>meinHaus/Flur/Haustuer:open / close</code>
bietet unter diesen Umständen reichlich Raum für Verbesserungen!

Abhilfe:
=== Username / Passwort ===
Zunächst kann man erst mal einen Username / Passwort vergeben, was alle IO-Device-Module unterstützen. Da ist zwar auch noch lange nicht sicher, aber zumindest steigert es den Aufwand schon mal. Jetzt muss man zumindest schon mal Pakete sniffen und verstehen, um unbefugt zu lesen oder gar zu publishen.

=== TLS ===
Um wirklich sicher zu werden, führt kein Weg an TLS vorbei.

Der MQTT-Client in [[#Tasmota|Tasmota]] (für ESP8266) kann mit TLS betrieben werden, vgl. [https://github.com/arendst/Tasmota/wiki/TLS Beschreibung im Tasmota-Wiki].

Leider kann z.B. ein Arduino das schlicht nicht mehr, da die einfacheren Modelle nicht über ausreichend Speicher und die Rechenleistung verfügen.

'''(Hier fehlt eine Anleitung für allowed usw.)'''

== Probleme ==
=== Anweisung und Ergebnis weichen voneinander ab ===
In der Regel melden MQTT-fähige Geräte entweder den Erhalt einer Nachricht zurück oder den Status nach Durchführung der in der ''payload'' enthaltenen Anweisung. Dabei findet aber in der Regel beim Empfänger eine Verarbeitung der Nachricht statt, ggf. wird diese auch weitergesendet und nochmals verarbeitet, bevor dann ggf. eine Rückmeldung des neuen Status an den MQTT-Server erfolgt. Handelt es sich um einfache on/off-Befehle, bleibt Anweisung und Ergebnis in der Regel identisch. Bei anderen, namentlich bei Dimmer-Werten, kann es zu Rundungsdifferenzen bei nummerischen Werten kommen. So kann z.B. ein Dimm-Wert von 70% gesetzt werden, zürückgemeldet wird dann aber 72% (oder 67%).
Dies ist technisch bedingt, vermeiden kann das jedoch in aller Regel nur der Autor der jeweiligen software/firmware auf dem "rechnenden" Gerät.

=== Unbeabsichtigte Schleifen ===
Durch Fehler in der topic-Struktur können unbeabsichtigte Schleifen entstehen, die FHEM komplett blockieren können. Es ist unbedingt darauf zu achten, dass die jeweiligen Sende- und Empfangs-topics andere sind!

== Links ==
* [http://mqtt.org Offizielle Homepage von MQTT, englisch]
* [http://www.hivemq.com/blog/mqtt-essentials-part-1-introducing-mqtt Sehr gute Einführung, englisch, sind 5 lesenswerte Teile]
* [https://www.heise.de/developer/artikel/MQTT-Protokoll-fuer-das-Internet-der-Dinge-2168152.html Ein Exkurs von Heise mit Beispielen, deutsch, sehr lesenswert]
* [http://www.mqttfx.org/ MQTT FX - ein sehr praktisches Analysetool]
* {{Link2Forum|Topic=69230|LinkText=Diskussionsthread im Forum}}
* {{Link2Forum|Topic=92888|LinkText=Thread, zur Entstehungsgeschichte von MQTT2_CLIENT}}
* {{Link2Forum|Topic=93255|LinkText=Ankündigungsthread zur MQTT2-Erweiterung der MQTT_GENERIC_BRIDGE}}
* [[MQTT_Einf%C3%BChrung_Teil_2|Teil 2 der MQTT Einführung]]: Detailaspekte (vorrangig zur Modulfamilie MQTT/MQTT_DEVICE)
* [[MQTT Einführung Teil 3|Teil 3 der MQTT Einführung]]: Arduino-Client selbst programmieren

== Hinweise ==
<references />

[[Kategorie:Glossary]]
[[Kategorie:HOWTOS]]
[[Kategorie:MQTT|Einführung]]
[[Kategorie:MQTT| ]]

MQTT

2020-01-17T14:15:17Z

PeMue: typo

MQTT ist ein Protokoll ("Message Queue Telemetry Transport"), mit dem Daten und Befehle zwischen verschiedenen Geräten ausgetauscht werden. Die Kommunikation erfolgt dabei über einen zentralen MQTT-Server, in alter Nomenklatur auch ''Broker'' genannt.

MQTT wurde entwickelt, um möglichst effizient, sicher und mit wenig Datenlast zu kommunizieren. MQTT ist nachrichtenorientiert, daher muss ein Client nicht beständig beim Server anfragen, ob neue Daten vorliegen. Heute findet sich MQTT vor allem im Bereich des ''Internet of Things'' (IoT). MQTT kann leicht mit FHEM verbunden werden, ohne dass dabei größerer CPU- oder Datenverbrauch entsteht.

== Eine sehr kurze Einführung in MQTT ==
Die folgende Einführung kann eine vollwertige Einleitung wie beispielsweise [https://github.com/mqtt/mqtt.github.io/wiki diese Wikieinträge] nicht ersetzen.

Bei MQTT findet die nachrichtenbasierte Kommunikation zwischen einzelnen Teilnehmern<ref>Teilnehmer in diesem Sinne kann ein Stück Hardware mit einer MQTT-fähigen firmware sein, ein auf einem Computer laufendes Script (einschließlich eines MQTT-Server-Dienstes wie ''mosquitto'' oder ''MQTT2_SERVER'', kurz: alles mögliche sein. Dadurch kann auch ein einzelner Computer unter mehreren ClientID's am MQTT-Datenaustausch beteiligt sein.</ref> in der Regel nicht direkt statt. Stattdessen werden alle Nachrichten von einem Teilnehmer an einen Serverdienst, den MQTT-Server (früher ''Broker'' genannt) übergeben, der dann dafür sorgt, dass die Nachricht an alle (berechtigten) anderen Teilnehmer verteilt wird, die sich für derartige Nachrichten "interessieren". Wenn also ein Teilnehmer ohne Server-Funktion (Client) Daten von einem bestimmten anderen Teilnehmer (anderer Client) empfangen will, muss es vorher dem MQTT-Server (Broker) mitteilen, dass er die Nachrichten dieses anderen Teilnehmers abonniert (deshalb wird dieser Vorgang als ''subscribe'' bezeichnet). Im IoT ist besonders interessant, dass Sender und Empfänger von Nachrichten durch den MQTT-Server vollständig entkoppelt werden können - jemand, der Daten bereit stellt, muss sich also nicht darum kümmern, wer diese Daten empfängt<ref>Aufgrund dieser Funktionsweise sollte allerdings darauf geachtet werden, die Möglichkeiten des jeweiligen Servers zur Sicherung der Daten gegen unberechtigten Zugriff zu nutzen, insbesondere wenn die Art der Daten oder die sich hierdurch ergebenden Möglichkeiten, z.B. Schaltvorgänge in der realen Welt auszulösen, dies notwendig macht!</ref>.

Eine Nachricht besteht im Wesentlichen aus den folgenden Elementen:
*ClientID - das ist die Kennung des Senders einer Nachricht<ref>Diese kann sich bei der Weitergabe der Nachricht ändern: Zunächst sendet ein Client eine Nachricht unter seiner ClientID, der MQTT-Server wird diese dann in der Regel durch seine Kennung ersetzten, wenn er die Nachricht an einen Abonnenten - der auch ein weiterer MQTT-Server sein kann - weitergibt.</ref>
*Topic - das ist die Adresse, an die eine Nachricht gesendet wird, bzw. von wo sie abgeholt werden kann (so ähnlich wie ein Postfach in der realen Welt). Topics sind einfache Strings, die mit Schrägstrichen getrennt werden (keine Leerzeichen und nur sehr wenige Sonderzeichen erlaubt). Ein Topic könnte beispielhaft so lauten: <code>zuHause/1OG/Kueche/Licht/state</code>. Diese Topics beinhalten also eine Hierarchie der Objekte - hier im Beispiel sind sie zuerst danach sortiert, ob sie sich zu Haus befinden, dann wird nach Stockwerken sortiert und im ersten Stock schaut man auf die Küche sowie das dort vorhandene Licht.
*Payload - das ist der Inhalt der Nachricht, oft handelt es sich um Befehle oder Daten.
*Quality of Service - soll geprüft werden, ob die Nachricht zugestellt wurde und wenn ja, mit welcher "Tiefe"?
*Retained Message.
Details bitte in der oben genannten Einführung nachlesen.

MQTT kommuniziert üblicherweise über Port 1883, es können aber unter derselben Netzwerkadresse an unterschiedlichen Ports auch mehrere Serverdienste bereitstehen.

== Installation in FHEM ==
Um MQTT in FHEM zu nutzen, benötigt man (mindestens) einen MQTT-Server. Es gibt zwei Möglichkeiten: Man kann FHEM-externe Server-Software (oder auch einen oder mehrere im Internet bereitstehende MQTT-Server) verwenden oder man kann die MQTT-Serverkomponente aktivieren, die mit {{Link2CmdRef|Anker=MQTT2_SERVER|Lang=en|Label=MQTT2_SERVER}} in FHEM direkt bereitsteht. Hier werden kurz beide Installationswege erläutert, zwingend ist nur einer, da eben mindestens ein MQTT-Serverdienst aktiv sein muß.

Die nachfolgenden Schaubilder zeigen schematisch die in FHEM zur Verfügung stehenden Wege der Einbindung von Hard- und/oder Softwarekomponenten, die über das MQTT-Protokoll Daten austauschen.
<gallery>
Datei:Mqtt2 server.png|Datenaustausch mit MQTT-Geräten, wenn MQTT2_SERVER als internem MQTT-Serverdienst verwendet wird
Datei:Mqtt2 client v extern server.png|Datenaustausch mit MQTT-Geräten, wenn MQTT2_CLIENT iVm. mosquitto als externem MQTT-Serverdienst verwendet wird
Datei:00 mqtt pm.png|Datenaustausch mit MQTT-Geräten, wenn das Modul ''MQTT'' (00_MQTT.pm) iVm. mosquitto als externem MQTT-Serverdienst verwendet wird
</gallery>
=== FHEM als MQTT-Server ===
Die mit dem Modul {{Link2CmdRef|Anker=MQTT2_SERVER|Lang=en|Label=MQTT2_SERVER}} bereitstehende Serverkomponente kann z.B. wie folgt aktiviert werden:
defmod myBroker MQTT2_SERVER 1883 global
Dieses [[Gerät]] übernimmt dann die Kommunikation mit den externen Clients (und wird von diesen behandelt, wie jeder andere MQTT-Server auch<ref>Bitte beachten Sie, dass (Stand: Juni 2019) MQTT2_SERVER nicht alle features des MQTT-Protokolls unterstützt.</ref>) und verteilt die eingehenden Nachrichten als IO-Device<ref>im Sinne des [[DevelopmentModuleIntro#Zweistufiges Modell für Module|2-stufigen Modulkonzepts]]</ref> für die Client-Module [[MQTT2_DEVICE]]<ref>Die Zahl 2 in den Modulnamen verweist nur darauf, dass es sich um eine neuere Modulfamilie handelt; die Kommunikation mit den externen Komponenten unterscheidet sich nicht zu den älteren Modulen, die vor dem Jahr 2018 genutzt werden konnten.</ref> und {{Link2CmdRef|Anker=MQTT_GENERIC_BRIDGE|Lang=de|Label=MQTT_GENERIC_BRIDGE}}.
Ein weiterer Vorteil dieser Lösung besteht darin, dass man ein MQTT2_SERVER-Device mit Hilfe von [[allowed]] absichern kann, was auch SSL-verschlüsselte Kommunikation ermöglicht.

{{Hinweis|Wenn Sie beabsichtigen, diese Variante zu verwenden, sollten Sie als nächstes die [[MQTT2-Module - Praxisbeispiele|Praxisbeispiele zu den MQTT2-Modulen]] lesen, und ggf. später wieder hierher zurückkehren. Dort findet sich auch ein Abschnitt zu dem auf den Grafiken zu den MQTT2-IO-Modulen enthaltenen [[MQTT2-Module_-_Praxisbeispiele#bridgeRegexp|bridgeRegexp]]-Attribut.}}

=== FHEM-externer Broker ===
==== Beispiel: mosquitto ====
Eine gern verwendete MQTT-Server-Software ist [http://mosquitto.org Mosquitto]. Sie kann ohne weiteres auf dem Raspberry Pi, der bereits eine FHEM-Installation besitzt, installiert werden und wird keine größere CPU- oder Netzwerklast verursachen.

Eine Anleitung zur Installation findet sich beispielsweise in diesem [http://blog.wenzlaff.de/?p=6487 Blogeintrag]. Im wesentlichen beschränkt sich die Installation eines MQTT Servers aber auf wenige Arbeitsschritte. Bei ''stretch'' ist ''Mosquitto'' bereits in der Distribution enthalten und kann - zusammen mit dem client Befehl ''mosquito_sub'', der weiter unten benötigt wird, wie folgt installiert und getestet werden<ref>Die für den Betrieb mit FHEM erforderlichen Perl-Module sind teilweise (noch) nicht in den Paketquellen verfügbar. Sie können dennoch statt mit cpan auch als Debian-Paket mit Hilfe von ''dh-make-perl'' installiert werden, wobei vorab das in den Paketquellen bereits vorhandene ''libmodule-pluggable-perl'' installiert werden sollte:<br>
<code>sudo apt-get install dh-make-perl<br>
dh-make-perl --install --cpan Net::MQTT::simple<br>
dh-make-perl --install --cpan Net::MQTT::Constants<br>
sudo dpkg -i libnet-mqtt-simple-perl*.deb<br>
sudo dpkg -i libnet-mqtt-perl*.deb</code></ref>:
{{Randnotiz|RNTyp=g|RNText=Für ältere Distributionen (hier am Beispiel von ''jessie'') muß ggf. aus einer zusätzlichen Paketquelle installiert werden:
wget http://repo.mosquitto.org/debian/mosquitto-repo.gpg.key
sudo apt-key add mosquitto-repo.gpg.key
cd /etc/apt/sources.list.d/
sudo wget http://repo.mosquitto.org/debian/mosquitto-jessie.list
sudo apt-get update
Danach kann die eigentliche Installation durchgeführt werden wie links für ''stretch'' beschrieben.}}<source lang="bash">
sudo apt-get install mosquitto mosquitto-clients

# MQTT Server Test
sudo service mosquitto status

# Start / Stop des Servers
sudo service mosquitto stop
sudo service mosquitto start
</source>
Danach ist der RPi mit <nowiki>shutdown restart</nowiki> neu zu starten.

==== IO-Module für externe MQTT-Server ====
Damit FHEM mit dem MQTT-Server kommuniziert, muss noch ein IO-Device angelegt werden. Dabei stehen zwei Varianten zur Wahl, das Modul [[MQTT (Modul)|MQTT]] oder seit Ende 2018 [[MQTT2_CLIENT]].

Beide Module können auch dazu genutzt werden, um Daten zwischen zwei FHEM-Installationen auszutauschen, insbesondere kann auch 00_MQTT.pm als Client für einen MQTT2_SERVER eingesetzt werden, der '''auf der anderen Installation''' als MQTT-Serverdienst eingerichtet ist. Darüber hinaus bestehen eine Vielzahl von Kombinationsmöglichkeiten der diversen IO-Module, wenn die Installation auf mehrere Server verteilt ist.
Auf einer FHEM-Installation wird jedoch in der Regel nur eines der IO-Module benötigt.

===== MQTT2_CLIENT =====
Ein MQTT2_CLIENT-IO-Device wird z.B. angelegt mit
define myBroker MQTT2_CLIENT 10.0.0.5:1883 ## bitte EIGENE IP-Adresse eintragen

{{Hinweis|Wenn Sie beabsichtigen, MQTT2_CLIENT zu verwenden, sollten Sie zuerst die [[MQTT2-Module - Praxisbeispiele|Praxisbeispiele zu den MQTT2-Modulen]] lesen, und dabei die Hinweise im Artikel [[MQTT2_CLIENT]] beachten.}}

Ein MQTT2_CLIENT-Device kann ebenfals mit Hilfe von [[allowed]] abgesichert werden, um z.B. SSL-verschlüsselte Kommunikation zu ermöglichem. Client-Module zu diesem IO-Typ sind wiederum [[MQTT2_DEVICE]] und {{Link2CmdRef|Anker=MQTT_GENERIC_BRIDGE|Lang=de|Label=MQTT_GENERIC_BRIDGE}}.

===== MQTT (Modul) =====
Vorab werden für diese Variante weitere Perl-Pakete benötigt:
<source lang="bash">
# Perl Version ausgeben
perl -v
# Perl MQTT Module nachinstallieren (läuft ein paar Minuten)
sudo cpan install Net::MQTT:Simple
sudo cpan install Net::MQTT:Constants
</source>

Ein IO-Device des Typs MQTT wird z.B. angelegt mit
{{Randnotiz|RNTyp=g|RNText=Sofern der Broker mit FHEM über localhost kommuniziert, kann als IP 127.0.0.1 verwendet werden.}}
define myBroker MQTT 10.0.0.5:1883 ## bitte EIGENE IP-Adresse eintragen
{{Randnotiz|RNTyp=g|RNText=Außerhalb der offiziellen Quellen sind auch einige ältere Varianten des Moduls MQTT_DEVICE verfügbar, die jeweils spezielle Anforderungen (z.B. für Zigbee2mqtt) separat abbilden. Diese werden hier nicht gesondert behandelt, da solche Sonderfälle heute generischer und einfacher durch den Einsatz von MQTT2_DEVICE abzubilden sind.}}Client-Device-Module zum Modul [[MQTT (Modul)|MQTT]] sind [[MQTT_DEVICE]], {{Link2CmdRef|Anker=MQTT_BRIDGE|Lang=de|Label=MQTT_BRIDGE}} (veraltet) und {{Link2CmdRef|Anker=MQTT_GENERIC_BRIDGE|Lang=de|Label=MQTT_GENERIC_BRIDGE}}. Da ''MQTT_DEVICE'' payload im JSON-Format (im Unterschied zu MQTT2_DEVICE) nicht selbst verarbeiten kann wird hier zusätzlich das Modul {{Link2CmdRef|Anker=expandJSON|Lang=de|Label=expandJSON}} benötigt, um den {{Link2Forum|Topic=66761|LinkText=JSON String auszuwerten}}.

=== Performancefragen... ===
...oder was sollte man als Lösung wählen, wenn man in die MQTT-Welt einsteigt<ref>vgl. hierzu diesen {{Link2Forum|Topic=94768|Message=875714|LinkText=Beitrag}} von Rudolf König</ref>?
Grundsätzlich sollte man davon ausgehen, dass innerhalb von FHEM die Verarbeitung derselben Daten näherungsweise denselben Aufwand bedeuten, unabhängig davon, welche der Implementierungen (''MQTT2_CLIENT'', ''MQTT'' oder ''MQTT2_SERVER'') man konkret wählt.
Ein externer Broker hat daher vor allem dann Vorteile, wenn die MQTT Daten überwiegend für was anderes (nicht FHEM) verwendet werden, oder MQTT zweckentfremdet wird (wie z.Bsp. für Musikübertragung). Nutzt man das MQTT-Protokoll dagegen vorwiegend innerhalb von FHEM, ist eher der Einsatz von MQTT2_SERVER in Betracht zu ziehen. Dieser soll Anfängern die Anbindung von MQTT Geräten in FHEM einfacher machen. Wer später merkt, dass er doch einen externen Broker benötigt, kann dann immer noch auf MQTT2_CLIENT in Verbindung mit einem anderen Broker wechseln.
Dagegen ist der Weg von MQTT_DEVICE zu MQTT2_DEVICE mit erheblich mehr Aufwand verbunden.

=== Kommunikation zu sonstigen FHEM-Geräten über MQTT ===

Möchte man Daten von einem [[Gerät]] (im FHEM-Sinn), das '''nicht''' vom Typ ''MQTT2_DEVICE'' oder ''MQTT_DEVICE'' (je nach IO-Modul) ist, per MQTT-Protokoll versenden (z.B. für eine andere Visualisierungslösung als FHEMWEB, oder als FHEM2FHEM-Ersatzlösung), oder diese sonstigen Geräte über MQTT-Anweisungen von außen steuern können, hat man mehrere Möglichkeiten:

==== MQTT_GENERIC_BRIDGE ====
Das Modul {{Link2CmdRef|Anker=MQTT_GENERIC_BRIDGE|Lang=en|Label=MQTT_GENERIC_BRIDGE}} ermöglicht es, sein jeweiliges IO-Modul-Gerät zu nutzen, um diesen Kommunikationsweg für beliebig viele andere FHEM-Geräte bereitzustellen. Dabei erfolgt am MQTT_GENERIC_BRIDGE-Gerät selbst nur eine Basiskonfiguration, im Übrigen durch Attribute an dem jeweiligen Gerät selbst. So kann z.B. ein Aktor des Typs [[CUL_HM]] an- oder ausgeschaltet werden oder auch einfach nur seinen aktuellen Schaltzustand per MQTT-Protokoll publizieren.

Dieses Modul kann seit November 2018 mit allen drei IO-Modul-Varianten zusammen eingesetzt werden, also sowohl mit ''MQTT2_SERVER'' bzw. ''MQTT2_CLIENT'' oder ''MQTT'' (00_MQTT.pm).

Dabei sollte man jedoch beachten, dass zur Verwendung mit den MQTT2-IO's unbedingt die autocreate-Funktion des betreffenden IOs ausgeschaltet wird und dies auch bleibt<ref>siehe dazu diesen {{Link2Forum|Topic=95341|LinkText=Thread}} zu den technischen Hintergründen</ref>! Weiter wird das Perl-Modul ''libmodule-pluggable-perl'' benötigt<ref>Dieses kann über <code>apt-get install libmodule-pluggable-perl</code> installiert werden</ref>, damit im Hintergrund auch das Modul [[MQTT (Modul)|MQTT]] geladen werden kann. Damit gelten auch für diesen Modul die Installationsvoraussetzungen für [[MQTT#MQTT_.28Modul.29|MQTT]]!

Anwendungsfälle und -beispiele für das Modul sind diesem {{Link2Forum|Topic=91642|LinkText=Thread}} zu entnehmen.

==== MQTT_BRIDGE ====
Dieses Modul kann nur zusammen mit einem IO-Gerät des Typs [[MQTT (Modul)|MQTT]] verwendet werden. Dabei wird pro weiterzuleitendem anderen FHEM-Gerät eine eigene Instanz dieses Moduls verwendet. Auf den Einsatz dieser Option sollte in neuen Installationen zugunsten von ''MQTT_GENERIC_BRIDGE'' verzichtet werden.

==== Per publish-Befehl am IO-Gerät ====
Alle drei IO-Module kennen direkte ''publish''-Anweisungen, mit deren Hilfe beliebige ''payloads'' an beliebige ''topics'' gesendet werden können. Dies kann man z.B. in einem [[notify]] oder [[at]] nutzen, um einzelne Events zu publishen oder Werteanfragen abzusetzen.

Hier eine regelmäßige Werteabfrage auf einen [[EBUS-MQTT2|ebus]]:
defmod get_ebus_updates at +*00:15:00 set ebusMQTT publish ebusd/430/Hc1HeatCurve/get;
set ebusMQTT publish ebusd/430/HwcTempDesired/get;
...

==== RAW-Events am IO-Gerät (MQTT2.*) ====
Bei beiden MQTT2-IO-Modulen (MQTT2_SERVER und MQTT2_CLIENT) kann per [[Regulärer Ausdruck|regulärem Ausdruck]] festgelegt werden, welche Nachrichten ein Event erzeugen sollen, auf das dann wieder z.B. mit einem [[notify]] reagiert werden kann, z.B. um beliebige Schaltaktionen auszulösen.

== MQTT-Clients (Beispiele) ==

===Arduino-library===
Zur Kommunikation mit dem Broker von Seiten eines [[Arduino|Arduinos]] mit selbst erstellten Sketches böte sich der PubSubClient an.

===PC-Software===
Um die Funktionalität des Brokers zu testen kann z.B. ein Analyse-Tool wie MQTT.fx verwendet werden, oder die im Paket ''mosquitto-clients'' enthaltenen Linux-Kommandozeilen-Programme ''mosquitto_sub'' und ''mosquitto_pub''. Letzterer könnte z.E. auch aus beliebigen ''shell-scripten'' heraus aufgerufen werden. Als Perl-Bibliothek steht alternativ z.B. [https://metacpan.org/pod/distribution/AnyEvent-MQTT/bin/anyevent-mqtt-pub anyevent-mqtt-pub] zur Verfügung.

=== Tasmota ===
Eine derzeit oft genutzte Möglichkeit für MQTT bilden die [[Sonoff]]-Geräte und weitere [[ESP8266]]-basierte Hardware, die unter vielen Handelsnamen erhältlich sind. Werden diese mit Tasmota ('''T'''heo '''A'''rends '''S'''onoff '''M'''QTT '''O'''ver '''T'''he '''A'''ir - einer offenen Firmware von [https://github.com/arendst arendst]) geflasht, so kommunizieren sie über MQTT. Um diese Geräte einzubinden, ist wie folgt vorzugehen. Zuerst ist ein Serverdienst (Broker) bereitzustellen, wie oben beschrieben.

Unter Sonoff sind einige Topics voreingestellt. arendst stellt insbesondere drei Topic-Präfixe bereit, die seiner Meinung jedes Topic einleiten sollen (in den Eingabemasken als "%prefix%" notiert). Das sind einmal Kommandos (abgekürzt als cmnd), die dazu dienen, Befehle auszuführen. Daten werden mit tele und stat übertragen. Ein Topic besteht dann zuerst aus diesem Präfix und danach dem eigentlichen Topic. Wer also beispielsweise einem Sonoff_Switch einen Befehl senden will, sollte als Topic cmnd/Sonoff_Switch wählen. Wenn der Switch ein- und ausgeschaltet werden kann, muss der Topic noch das Wort POWER enthalten (in MQTT werden viele Kennworte komplett groß geschrieben). Der Topic lautet damit vollständig "cmnd/Sonoff_Switch/POWER/set"

{{Randnotiz|RNTyp=g|RNText=Dabei ist darauf zu achten, dass für den Parameter ''topic = %topic% (sonoff)'' statt ''sonoff'' ein gerätespezifischer eigener Name eingetragen wird. Hierzu kann man z.B. auch die dynamisch aus der Chip-ID erzeugte Kennung ''DVES_%06X'' verwenden, indem man die unter ''client (DVES_8BABA9)'' zu findende Angabe kopiert. Die eigentliche Umbenennung zu einem "sprechenden Namen" kann dann innerhalb von FHEM - mittels ''rename'' oder ggf. mit einem ''alias'' - erfolgen.}}

Link zum Forum: {{Link2Forum|Topic=27532|LinkText=MQTT FHEM Einrichtung}} (hier als ''MQTT_DEVICE''!):

### FHEM Device mit MQTT verbinden ###
define Sonoff_Switch MQTT_DEVICE
attr Sonoff_Switch IODev myBroker
attr Sonoff_Switch devStateIcon ON:rc_GREEN:OFF OFF:rc_RED:ON
attr Sonoff_Switch icon hue_filled_br30
attr Sonoff_Switch publishSet ON OFF cmnd/TestSwitch/POWER
attr Sonoff_Switch room MQTT
attr Sonoff_Switch subscribeReading_Licht stat/Sonoff_Switch/POWER
attr Sonoff_Switch subscribeReading_Sensor tele/Sonoff_Switch/SENSOR
attr Sonoff_Switch subscribeReading_Status stat/Sonoff_Switch/STATUS
attr Sonoff_Switch webCmd ON:OFF

Der hier dargestellte Beispielcode realisiert die Kommunikation zwischen FHEM und dem sonoff Modul via MQTT Broker. Zu beachten ist hier, dass '''subscribeReading_Licht''' und '''subscribeReading_Status''' unterschiedliche Syntax des Topic Strings haben!

== Sicherheit ==
Prinzipiell ist MQTT ebenso sicher wie eine Postkarte. Solange man es nicht extra absichert, kann jeder der, im eigenen LAN ist (und die Adresse vom Broker kennt) alle Topics mitlesen.
:<code>meinHaus/Flur/Haustuer:open / close</code>
bietet unter diesen Umständen reichlich Raum für Verbesserungen!

Abhilfe:
=== Username / Passwort ===
Zunächst kann man erst mal einen Username / Passwort vergeben, was alle IO-Device-Module unterstützen. Da ist zwar auch noch lange nicht sicher, aber zumindest steigert es den Aufwand schon mal. Jetzt muss man zumindest schon mal Pakete sniffen und verstehen, um unbefugt zu lesen oder gar zu publishen.

=== TLS ===
Um wirklich sicher zu werden, führt kein Weg an TLS vorbei.

Der MQTT-Client in [[#Tasmota|Tasmota]] (für ESP8266) kann mit TLS betrieben werden, vgl. [https://github.com/arendst/Tasmota/wiki/TLS Beschreibung im Tasmota-Wiki].

Leider kann z.B. ein Arduino das schlicht nicht mehr, da die einfacheren Modelle nicht über ausreichend Speicher und die Rechenleistung verfügen.

'''(Hier fehlt eine Anleitung für allowed usw.)'''

== Probleme ==
=== Anweisung und Ergebnis weichen voneinander ab ===
In der Regel melden MQTT-fähige Geräte entweder den Erhalt einer Nachricht zurück oder den Status nach Durchführung der in der ''payload'' enthaltenen Anweisung. Dabei findet aber in der Regel beim Empfänger eine Verarbeitung der Nachricht statt, ggf. wird diese auch weitergesendet und nochmals verarbeitet, bevor dann ggf. eine Rückmeldung des neuen Status an den MQTT-Server erfolgt. Handelt es sich um einfache on/off-Befehle, bleibt Anweisung und Ergebnis in der Regel identisch. Bei anderen, namentlich bei Dimmer-Werten, kann es zu Rundungsdifferenzen bei nummerischen Werten kommen. So kann z.B. ein Dimm-Wert von 70% gesetzt werden, zürückgemeldet wird dann aber 72% (oder 67%).
Dies ist technisch bedingt, vermeiden kann das jedoch in aller Regel nur der Autor der jeweiligen software/firmware auf dem "rechnenden" Gerät.

=== Unbeabsichtigte Schleifen ===
Durch Fehler in der topic-Struktur können unbeabsichtigte Schleifen entstehen, die FHEM komplett blockieren können. Es ist unbedingt darauf zu achten, dass die jeweiligen Sende- und Empfangs-topics andere sind!

== Links ==
* [http://mqtt.org Offizielle Homepage von MQTT, englisch]
* [http://www.hivemq.com/blog/mqtt-essentials-part-1-introducing-mqtt Sehr gute Einführung, englisch, sind 5 lesenswerte Teile]
* [https://www.heise.de/developer/artikel/MQTT-Protokoll-fuer-das-Internet-der-Dinge-2168152.html Ein Exkurs von Heise mit Beispielen, deutsch, sehr lesenswert]
* [http://www.mqttfx.org/ MQTT FX - ein sehr praktisches Analysetool]
* {{Link2Forum|Topic=69230|LinkText=Diskussionsthread im Forum}}
* {{Link2Forum|Topic=92888|LinkText=Thread, zur Entstehungsgeschichte von MQTT2_CLIENT}}
* {{Link2Forum|Topic=93255|LinkText=Ankündigungsthread zur MQTT2-Erweiterung der MQTT_GENERIC_BRIDGE}}
* [[MQTT_Einf%C3%BChrung_Teil_2|Teil 2 der MQTT Einführung]]: Detailaspekte (vorrangig zur Modulfamilie MQTT/MQTT_DEVICE)
* [[MQTT Einführung Teil 3|Teil 3 der MQTT Einführung]]: Arduino-Client selbst programmieren

== Hinweise ==
<references />

[[Kategorie:Glossary]]
[[Kategorie:HOWTOS]]
[[Kategorie:MQTT|Einführung]]
[[Kategorie:MQTT| ]]

Universalsensor

2019-12-02T09:21:11Z

PeMue: link 2018 Hardware angepasst

[[Datei:Universalsensor-CC1101-Innen.jpg|200px|thumb|right|Universalsensor im Innengehäuse]]
[[Datei:Universalsensor-CC1101-Aussen.jpg|200px|thumb|right|Universalsensor im Außengehäuse]]

== Übersicht ==
Die [[Universalsensor]]-Platine ist eine Hardwareplattform, um verschiedene Sensorwerte auch über unterschiedliche Übertragungsverfahren z.B. für die eigene Homeautomatisierung verfügbar zu machen.

Hier werden die unterschiedliche Platinenlayouts, welche z.B. für einen Innensensor und einen Außensensor verwendet werden können, vorgestellt.

Als Übertragungsmedien sind ein Funkmodul (CC1101) oder ein RS485 Transceiver (LT1785 oder kompatibel) vorgesehen.

Mit dem Funkmodul ist eine Anbindung an Funksysteme im 868 MHz oder auch 433 MHz-Band möglich. Hiermit kann der Sensor z.B. in ein HomeMatic Funksystem integriert werden, aber auch andere Funksysteme sind über eine entsprechende Firmware realisierbar. Mit dem RS485 Transceiver ist z.B. auch eine Integration in das HomeMatic-Wired System möglich.

Das Platinenlayout der Sensoren enthält zwei Pinleisten, welche Arduino-Kompatibel sind. Als Mikrocontroller ist ein Atmega 328p bestückt. Über diese Erweiterungsports können zusätzlich eigene Sensoren oder auch Aktoren angeschlossen werden, diese müssen dann aber über eine Erweiterung der bestehenden Firmware oder mit einer eigenen Firmware angesprochen werden.

Die Spannungsversorgung erfolgt über zwei AA bzw. AAA Batterien. Damit eine möglichst gute Ausnutzung der Batteriekapazität erzielt wird und auch Sensoren mit 3,3 V Spannungsversorgung benutzt werden können, kann ein MAX1724 Step-Up-Converter bestückt werden. Dieser stellt eine stabile Spannungsversorgung von 3,3 V zur Verfügung. Als Mindest-Eingangsspannung sind hier dann lediglich 1,2 V notwendig. Somit ist eine Versorgung auch aus nur einer Batteriezelle denkbar.

Alternativ kann eine Spannungsversorgung über einen Schaltregler erfolgen. Diese Versorgung kommt bei der Bestückungsversion mit RS485-Transceiver zum Einsatz, aber auch bei Benutzung mit dem Funkmodul kann diese Spannungsversorgung eingesetzt werden.

Der Schaltregler erlaubt einen recht breiten Eingangsspannungsbreich von 7 V bis 24 V. Außerdem steht damit intern zusätzlich zu den 3,3 V eine Spannung von 5 V zur Verfügung.

== Innensensor ==
[[Datei:Universalsensor-CC1101-Innen platine.jpg|200px|thumb|right|Universalsensor-Platine für das Innengehäuse. Hier noch ohne Bestückungsoption für RS485 und ohne bestückten SHT10 (Temperatur / Luftfeuchte)]]

Das Layout des Innensensors unterstützt standardmäßig folgende Sensorbestückung:
* Temperatur / Feuchte (SHT10)
* Temperatur / Luftdruck (BMP180)
* Helligkeit (TSL2561)
Zusätzlich können über die zwei Pinleisten eigene Sensoren z.B. über eine Erweiterungsplatine angeschlossen werden. Als Beispiel ist hier eine Firmwareversion genannt, bei der mehrere 1-Wire Sensoren an den Sensor angeschlossen und abgefragt werden können. Zusätzlich zu den unterschiedlichen bestückbaren Sensoren kann der Innensensor alternativ zum Funkmodul mit einem RS485 Transceiver bestückt werden. Als Spannungsversorgung steht eine Batterieversorgung (1,2-3 V) oder eine Spannungsversorgung über einen Schaltregler (7-24 V) zur Verfügung.

== Außensensor ==
[[Datei:Universalsensor-CC1101-Aussen_platine.jpg|200px|thumb|right|Universalsensor-Platine für das Außengehäuse mit Beschreibung der I2C-Anschlussbelegung.]]

Die Platine des Außensensors ist deutlich kompakter als die des Innensensors, daher ist in dieser Version derzeit nur das Funkmodul bestückbar. Andere Übertragungsverfahren wie z.B. RS485 müssten hier extern realisiert werden. Das Layout des Außensensors unterstützt standardmäßig folgende Sensorbestückung:
* Temperatur / Luftdruck (BMP180)
* Helligkeit (TSL2561)
Weitere Sensoren, z.B. ein SHT10 für Temperatur/Luftfeuchte, können über den nach außen geführten I2C-Bus angeschlossen werden. Natürlich existiert auch beim Außensensor die Möglichkeit, weitere Sensoren oder auch Aktoren über die beiden Pinleisten anzuschließen.

{{Link2Forum|Topic=20620|Message=182690|LinkText=Dieser Forenbeitrag}} beschreibt, wie der SHT10 auch innerhalb eines Gehäuses benutzt werden kann.

Um die Platine im Gehäuse zu fixieren, wird auf einer Seite des Batteriehalters ein kleiner Schaumstoffblock aufgeklebt (siehe nebenstehendes Foto)

== Helligkeitssensor ==
[[Datei:SHT10_breakout.jpg|200px|thumb|right|SHT10 Breakout-Board für den Außensensor.]]
[[Datei:CC1101-Sensor-Außen_mit_Filterfolie.JPG|200px|thumb|right|Das Außengehäuse mit Filterfolie.]]
[[Datei:Innensensor_Loch_für_Acrylstab_Maße.jpg|200px|thumb|right|Bohrvorlage für den Acrylstab im Innengehäuse.]]
Der Helligkeitssensor braucht zum sinnvollen Einsatz natürlich die Möglichkeit, vom Umgebungslicht beleuchtet zu werden. Da der Sensor im Innengehäuse in der Nähe der Lüftungsschlitze sitzt, wird er dadurch bereits beleuchtet, allerdings fällt hier nur wenig Licht auf den Sensor. Daher ist bei dieser Messmethode die erreichbare Auflösung sehr gering.

Die bessere Lösung ist es, in die Abdeckung des Sensorgehäuses ein 5 mm großes Loch zu bohren. In das Loch wird ein kurzer Stift aus Acrylglas eingesetzt (siehe Bild mit der Bohrvorlage). Achtung, das Loch ist in horizontaler Ausrichtung nicht genau mittig. Der Acrylstab hat nicht genau 5 mm Durchmesser. Es sind 5,2 mm. Man kann dennoch ein 5 mm Loch bohren. Das Einschieben des Stabes in das Loch geht dann allerdings ziemlich schwer. Vor dem Einschieben kann man den Acrylstab an der Innenseite noch leicht anfasen. Dann lässt er sich leichter in das Loch schieben. Die Länge des Acrylstabes Beträgt 17 mm.

Im Außensensor ist die ausreichende Beleuchtung bereits durch die transparente Gehäuseoberseite gewährleistet. Allerdings wird der Sensor in direkter Sonneneinstrahlung übersteuern. Daher kann hier zwischen Sensor und Deckel eine Filterfolie eingelegt werden. Die getestete Filterfolie lässt dann nur noch etwa 25% des Lichtes durch. Dadurch ist eine Lage ausreichend, damit der Sensor auch im Sommer bei voller Sonneneinstrahlung nicht mehr übersteuert. Durch den bekannten Filterwert der Folie lässt sich so auch gut ein Umrechnungsfaktor für die Heligkeitsmessung in Lux z.B. in FHEM hinterlegen.

Eine Testreihe mit der Folie im Vergleich mit einem kommerziellen Luxmeter hat den Faktor 0,265 ergeben. Mit Folie bekommt man mit einer Division durch 0,265 auf den aktuellen Lux-Wert:
:<code>$lux = $lum/0.265</code>

Um den Wert mit Folie unterhalb des Devices angezeigt zu bekommen, muss man hierfür ein userreading erstellen.
Die erfolgt mit folgendem Befehl:
:<code>attr Outdoor.Helligkeit userReadings luminosity2 { ReadingsVal("Outdoor.Helligkeit","luminosity",0)/0.265;; }</code>

Der Devicename (hier im Beispiel ''Outdoor.Helligkeit'') muss gegen den eigenen Devicenamen ausgetauscht werden.

Werden zwei Folien benutzt muss der Wert von 0.265 angepasst werden.

Nun ist es möglich, den richtigen Wert unter dem Reading ''luminosity2'' abzufragen.

== Firmware ==
[[Datei:CC1101-Sensor_Firmwareupdate_mit_dem_Raspberry_Pi.jpg|200px|thumb|right|Firmwareupdate mit dem Raspberry Pi.]]

Aktuell existieren für den Sensor drei verschiedene Firmwareversionen:
* [[HB-UW-Sen-THPL]] HB-UW-Sen-THPL-I, HB-UW-Sen-THPL-O (Version 0.15)
: HomeMatic-kompatibler Temperatur / Feuchte / Luftdruck / Helligkeitssensor für das Innengehäuse oder Außengehäuse
* [https://github.com/TomMajor/SmartHome/tree/master/HB-UNI-Sensor1 HB-UNI-Sensor1]
: Neuauflage des Universalsensors in 2018 für Temperatur, Luftdruck, Luftfeuchte, Helligkeit mit neuer AskSinPP Bibliothek
* HWB-ONEWIRE (Experimentel)
: HomeMatic-Wired Kompatibles 1-Wire-Temperatursensor-interface

HB-UW-Sen-THPL-I und HB-UW-Sen-THPL-O unterscheiden sich nur durch die Geräte-ID (F101 für HB-UW-Sen-THPL-I, F102 für HB-UW-Sen-THPL-O). Dadurch ist es möglich, dass die Sensoren z.B. in der CCU über ein eigenes Icon verfügen.

'''Configtaster'''

Drückt man den Configtaster auf der Platine im Betrieb 1x, so startet man das [[HomeMatic_Devices_pairen|Pairing]]. Die LED fängt langsam an zu blinken. Drückt man den Taster nun nochmal, aber deutlich länger, blinkt die LED sehr schnell (jetzt loslassen). Jetzt kann der Sensor resettet werden. Dazu drückt man den Taster erneut, bis die LED ausgeht. Der Sensor hat sich nun zurückgesetzt.

'''Firmwarekonfiguration'''

Auf einige Einstellungen des Sensors lässt sich über die Kommandozeile Einfluss nehmen. Dazu
:<code>set <sensorname> regSet <register> <wert></code>
eingeben. Die folgenden Register stehen dabei zur Verfügung:
;altitude
:Die Höhe des Sensors über NN in Metern. Ist ein Luftdrucksensor vorhanden, dann wird der ermittelte Druck automatisch in Druck auf NN umgerechnet.
;burstRx (noch experimentell)
:Hierbei bleibt der Sensor dauerhaft empfangsbereit (bei höherem Batterieverbrauch). Damit soll es möglich sein, die Sensorwerte on demand vom Sensor anzufordern.
;ledMode
:''on'' die LED leuchtet, wenn der Sensor Daten überträgt, ''off'' die LED leuchtet beim Übertragen der Daten nicht
;lowBatLimitTHPL
:Batteriespannung, ab der die Warnung für den Batteriewechsel ausgegeben wird.
;pairCentral
:???
;transmDevTryMax
:Anzahl der Wiederholungssendungen, sofern kein ACK empfangen wurde.

[[Datei:Universalsensor-RS485_mit_1-Wire-Sensoren.jpg|200px|thumb|right|Universalsensor-RS485-Version. Hier mit angeschlossenen 1-Wire Temperatursensoren]]

[[Datei:Universalsensor-RS485-Innen_Platine.jpg|200px|thumb|right|Universalsensor-RS485-Version. Hier mit optional bestückten SHT10 (Temperatur / Luftfeuchte), BMP180 (Luftdruck), TSL2561 (Helligkeit)]]

== OTA (OverTheAir) Firmwareupdate ==
Die Firmware des Sensor lässt sich, sofern er den so genannten OTAU-Bootloader besitzt, einfach per Funk updaten (OTA-Update = '''O'''ver '''T'''he '''A'''ir, also Update per Funk).

Das Firmwareupdate funktioniert aktuell nur mit [[CUL]]/[[COC]] oder [[HM-CFG-USB USB Konfigurations-Adapter|HM-CFG-USB]] unter Linux ([[HomeMatic_Firmware_Update#Firmware_Update_mit_CUL.2FHM-CFG-USB_unter_FHEM|Update mit CUL oder HM-CFG-USB unter Linux]]), mit dem "HomeMatic Firmware Update Tool" unter Windows ([[HomeMatic_Firmware_Update#Firmware_Update_mit_HM-CFG-USB_unter_Windows|Update mit HM-CFG-USB unter Windows]]) oder mit einer CCU2. Ein <code>set sensorname fwUpdate dateiname</code> in der Kommandozeile von FHEM funktioniert derzeit noch nicht.

Für das Update mit flash-ota ist folgendes zu machen:
# [[HomeMatic_Firmware_Update#Firmware_Update_mit_CUL.2FHM-CFG-USB_unter_FHEM|flash-ota herunterladen und installieren]].
# Firmware aus dem ZIP rausholen: https://github.com/kc-GitHub/Wettersensor/archive/v0.14_beta.zip
# flash-ota starten. Z.B. so: <code>sudo ./flash-ota -c /dev/ttyACM0 -f <firmware-file.eq3> -s <seriennummer></code>
# eine Batterie aus dem Sensor heraus nehmen, Configtaste drücken und gedrückt halten, Batterie wieder einlegen während die Configtaste weiter gedrückt bleibt.
# Jetzt sollte der Updateprozess starten.
# Sensor mit FHEM neu pairen. Dann erscheint auch die neue Firmwareversion in FHEM.

== Weitere Firmwareupdate-Möglichkeiten ==
Alternativ kann der Atmega328p auf der Platine mit einem Arduino-kompatiblen Bootloader ausgerüstet werden.
Damit lässt sich dann das Firmwareupdate per USB-UART-Adapter oder auch über den UART-Anschluss von einem [[Raspberry Pi]] einspielen.

== RS485-Version mit 1-Wire Temperatursensoren ==
Hier ist eine experimentelle Firmware, mit der man derzeit die RS485-Version des Sensors in ein 1-Wire - HomeMatic-Wired Interface "verwandeln" kann. Weiteres ist unter [[HWB-1WIRE-TMP10]] nachzulesen.

== Inbetriebnahme ==
# Das FHEM-Modul für den Sensor muss installiert werden. Dazu folgenden Befehl in das FHEM-Befehlsfeld eingeben: <br> <code>update HMConfig_SenTHPL.pm <nowiki>https://raw.githubusercontent.com/kc-GitHub/Wettersensor/master/Contrib/control-fhem.txt</nowiki></code><br>
# Anschließend muss FHEM neu gestartet werden: <code>shutdown restart</code>
# Batterien in den Sensor einlegen
# [[HomeMatic_Devices_pairen|CUL in den Pairingmodus schalten]]
# Configtaster auf dem Universalsensor drücken

== Zurücksetzen auf Werkseinstellungen ==
# Configtaster drücken -> LED blinkt
# Configtaster lange drücken (ca. 5-10 sek.) -> LED blinkt schnell
# Configtaster noch mal lange drücken (ca. 5-10 sek.) -> LED blinkt kurz und hört dann auf

== Links ==
* [https://github.com/kc-GitHub/Wettersensor Firmware der CC1101 (Funk) Version]
* [https://github.com/kc-GitHub/HM485-Lib/tree/thorsten Firmware der RS485 (Wired) Version]
* [https://github.com/kc-GitHub/Wettersensor/raw/master/Schematic/Schematic-RF.pdf Schaltplan und Platinenlayout der CC1101 (Funk) Version]
* [https://github.com/kc-GitHub/HM485-Lib/raw/thorsten/Schematic/Schematic-WIRED.pdf Schaltplan und Platinenlayout der RS485 (Wired) Version]
* [https://github.com/TomMajor/SmartHome/tree/master/HB-UNI-Sensor1 Firmware der 2018 Version]
* [https://github.com/TomMajor/SmartHome/tree/master/PCB/01_Sensor_PLHT_V2.01 Schaltplan und Platinenlayout der 2018 Version]
* {{Link2Forum|Topic=20620|LinkText=Thread im FHEM-Forum}}
* {{Link2Forum|Topic=22952|LinkText=Thread im FHEM-Forum zur Entwicklung der Wired-Firmware}}
[[Kategorie:HomeBrew]]
[[Kategorie:HomeMatic Components]]
[[Kategorie:868MHz]]

HomeMatic Fenster-Drehgriffkontakt Community-Nachbau

2019-08-26T11:41:10Z

PeMue: Einfügen der Versionsinformationen für die Platinen

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

Die Firmware ist identisch mit dem [https://www.elv.de/homematic-funk-fenster-drehgriffkontakt-1.html Originalen Sensor von ELV] und verhält sich dementsprechend auch gleich.

== Übersicht ==

Die Grundidee zu diesem Sensor wurde durch {{Link2Forum|Topic=71413.0|LinkText=Kawaci im Forum}} geliefert.
Die Umsetzung besteht aus einer Atmega328p Platine mit CC1101 Funkmodul (868 MHz) sowie
einer auf der [https://github.com/pa-pa/AskSinPP AskSin++] Portierung des BidCos-Protokolls aus den HomeMatic-Geräten.

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 v1.0/1.1 ==
'''Schaltplan:'''
[[Datei:FDGK_v1.0_sch.jpg]]

'''Platine v1.0 (Oberseite mit korrigierter Pinbelegung (=v1.1)):'''
[[Datei:FDGK_v1.0_top.jpg]]

'''Platine v1.0 (Unterseite, ohne bestücktes Radio):'''
[[Datei:FDGK_v1.0_bot.jpg]]

== Bauteilliste ==
Die Bauteilliste gibt es auf [https://github.com/pa-pa/HMSensor/blob/master/HMSensor-CR2032/Parts.xls GitHub].

In der Liste sind die Magnete und Reed-Kontakte nicht aufgeführt.
Folgende können verwendet werden:
* Reed-Kontakt 2x14mm [https://de.aliexpress.com/item/10pcs-N-O-Reed-switch-Magnetic-Switch-2-14mm-Normally-Open-Magnetic-Induction-switch/32803902404.html Aliexpress]
* Neodym Magnet 4x2mm [https://de.aliexpress.com/item/10-teile-los-Disk-magnet-4-2mm-N35-Starke-Disc-NdFeB-Rare-Earth-Magnet-4x2mm-Neodym/32946901529.html?spm=a2g0x.search0104.3.7.76d477adxmEm7W&ws_ab_test=searchweb0_0%2Csearchweb201602_2_10065_10068_10547_319_317_10548_10696_10084_453_10083_454_10618_10304_10307_10820_10821_537_10302_536_10902_10843_10059_10884_10887_321_322_10103%2Csearchweb201603_51%2CppcSwitch_0&algo_pvid=cfa21564-5a35-4c12-a921-71b0383402fc&algo_expid=cfa21564-5a35-4c12-a921-71b0383402fc-1 Aliexpress]

== Zusammenlöten der SMD Bauteile ==
Die Bestückung der Platine v1.0/1.1 ist im [https://forum.fhem.de/index.php/topic,71413.msg640858.html#msg640858 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 [https://wiki.fhem.de/wiki/HomeMatic_Fenster-Drehgriffkontakt_Community-Nachbau#Firmware Flashen der Firmware] das Radio (IC2) bzw. den Batteriehalter (BT1) bestücken.
Als Antenne (ANT) wird ein Draht mit 72 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 ===
{{Randnotiz|RNText=Firmware für 'ID=0030'}}
Dafür wird, mit Hilfe der [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=91780 makeota.html] der Bootloader mit den benötigten Daten gefüllt und anschließend generiert.

Die makeota.html wird dazu in einem beliebigen 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 [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=91779 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.

Seit 01/2018 gibt es die Firmware auch für das sog. ''lazy config''. Hierbei können die Register einfach z.B. durch das nächste Öffnen des Fensters ausgelesen werden, ohne dass die Config-Taste gedrückt werden muss.
Das Update auf ''lazy config'' geht auf zwei Arten:

Keine Änderung der 'ID=0030' und Durchführen eines [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=94541 Firmware] bzw. eines FHEM Updates oder
{{Randnotiz|RNText=Firmware für 'ID=00C3'}}
Aktualisierung der Firmware auf 'ID=00C3'. Die Dateien können hier: [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=94538 makeota.html], [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=94542 Firmware (hex)] bzw. [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=94541 Firmware (eq3)] heruntergeladen werden.

Verwendet man den Sensor in Kombination mit originaler eq3 Hardware, sollte man die zweite Möglichkeit wählen.

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

<pre>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</pre>
setzt die Fuses.

<pre>avrdude -p m328p -P usb -c usbasp -V -U flash:w:bootloader.hex</pre>
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 USB Konfigurations-Adapter|HM-CFG-USB]] unter Linux ([[HomeMatic_Firmware_Update#Firmware_Update_mit_CUL.2FHM-CFG-USB_unter_FHEM|Update mit CUL oder HM-CFG-USB unter Linux]]), mit dem "HomeMatic Firmware Update Tool" unter Windows ([[HomeMatic_Firmware_Update#Firmware_Update_mit_HM-CFG-USB_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:

<pre>./flash-ota -f avr_HM_SEC_RHS_201705271601.eq3 -s RHS0000000</pre>

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

<pre>./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</pre>

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 (Platine v1.0/1.1) ==
Den Magneten in den Drehring einbauen und diesen in das Gehäuse einbauen. Die Reedkontakte
Platzieren und mit einem Ohmmeter Messen, ob die Reedkontakte bei der entsprechenden Position
der Magnete schalten. Falls nicht, ggf. die Reedkontakte austauschen (Streuung!) bzw. einen stärkeren Magneten verwenden. Danach mittels Silberdraht bzw. Kupferlackdraht (an den zu
verlötenden Enden den Lack mittels eines Cuttermessers entfernen) die Reedkontakte gemäß
Bild verlöten und die Enden (GND, A0 bzw. A1) durch die vorgesehenen Öffnungen im Gehäuse führen.

''Verlötete Reedkontakte:''
[[Datei:HM_Fenstersensor-pic15.jpg]]

Danach die Antenne in die dafür vorgesehene Bohrung einführen und die Platine platzieren. Darauf achten, dass die Anschlüsse der Reedkontakte durch die dafür vorgesehenen Kontakte auf der Platine geführt werden.

''Einführen der Antenne:''
[[Datei:HM_Fenstersensor-pic17.jpg]]

''Platzierte Platine:''
[[Datei:HM_Fenstersensor-pic16.jpg]]

Nach Verlöten der drei Kontaktpunkte ist der Fensterdrehgriff fertig aufgebaut.

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

<pre>set <Device_Name> regSet msgRhsPosA <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>

== Montage ==
Bei der Standardeinstellung der Register gilt für die Platzierung des Magneten bei geöffnetem Fenster folgendes:
Bei links angeschlagenem Fenster muss der Magnet nach unten, bei rechts angeschlagenem nach oben.

== 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 [https://www.thingiverse.com/thing:2354704 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 {{Link2Forum|Topic=70413|LinkText=Service}} an.

== Links ==
*[https://forum.fhem.de/index.php/topic,71413.0.0.html Link zum Foren-Thread]
*[https://github.com/pa-pa/AskSinPP AskSinPP Libary]
*[https://github.com/pa-pa/HMSensor Alles Mögliche zu dem Projekt auf Github]
*[[HomeMatic_Type_threeStateSensor|CyclicInfoMsg aktivieren]]
*{{Link2Forum|Topic=70413|LinkText=3D-Druck service}}
*[[HomeMatic_Firmware_Update#Firmware_Update_mit_CUL.2FHM-CFG-USB_unter_FHEM|update-ota]]

[[Kategorie:HomeMatic Components‏‎]]
[[Kategorie:HomeBrew‏‎]]
[[Kategorie:868MHz]]

HomeMatic Fenster-Drehgriffkontakt Community-Nachbau

2019-03-16T17:05:10Z

PeMue: Link Magnete angepasst

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

Die Firmware ist identisch mit dem [https://www.elv.de/homematic-funk-fenster-drehgriffkontakt-1.html Originalen Sensor von ELV] und verhält sich dementsprechend auch gleich.

== Übersicht ==

Die Grundidee zu diesem Sensor wurde durch {{Link2Forum|Topic=71413.0|LinkText=Kawaci im Forum}} geliefert.
Die Umsetzung besteht aus einer Atmega328p Platine mit CC1101 Funkmodul (868 MHz) sowie
einer auf der [https://github.com/pa-pa/AskSinPP AskSin++] Portierung des BidCos-Protokolls aus den HomeMatic-Geräten.

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:'''
[[Datei:FDGK_v1.0_sch.jpg]]

'''Platine v1.0 (Oberseite mit korrigierter Pinbelegung):'''
[[Datei:FDGK_v1.0_top.jpg]]

'''Platine v1.0 (Unterseite, ohne bestücktes Radio):'''
[[Datei:FDGK_v1.0_bot.jpg]]

== Bauteilliste ==
Die Bauteilliste gibt es auf [https://github.com/pa-pa/HMSensor/blob/master/HMSensor-CR2032/Parts.xls GitHub].

In der Liste sind die Magnete und Reed-Kontakte nicht aufgeführt.
Folgende können verwendet werden:
* Reed-Kontakt 2x14mm [https://de.aliexpress.com/item/10pcs-N-O-Reed-switch-Magnetic-Switch-2-14mm-Normally-Open-Magnetic-Induction-switch/32803902404.html Aliexpress]
* Neodym Magnet 4x2mm [https://de.aliexpress.com/item/10-teile-los-Disk-magnet-4-2mm-N35-Starke-Disc-NdFeB-Rare-Earth-Magnet-4x2mm-Neodym/32946901529.html?spm=a2g0x.search0104.3.7.76d477adxmEm7W&ws_ab_test=searchweb0_0%2Csearchweb201602_2_10065_10068_10547_319_317_10548_10696_10084_453_10083_454_10618_10304_10307_10820_10821_537_10302_536_10902_10843_10059_10884_10887_321_322_10103%2Csearchweb201603_51%2CppcSwitch_0&algo_pvid=cfa21564-5a35-4c12-a921-71b0383402fc&algo_expid=cfa21564-5a35-4c12-a921-71b0383402fc-1 Aliexpress]

== Zusammenlöten der SMD Bauteile ==
Die Bestückung der Platine ist im [https://forum.fhem.de/index.php/topic,71413.msg640858.html#msg640858 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 [https://wiki.fhem.de/wiki/HomeMatic_Fenster-Drehgriffkontakt_Community-Nachbau#Firmware Flashen der Firmware] das Radio (IC2) bzw. den Batteriehalter (BT1) bestücken.
Als Antenne (ANT) wird ein Draht mit 72 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 ===
{{Randnotiz|RNText=Firmware für 'ID=0030'}}
Dafür wird, mit Hilfe der [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=91780 makeota.html] der Bootloader mit den benötigten Daten gefüllt und anschließend generiert.

Die makeota.html wird dazu in einem beliebigen 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 [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=91779 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.

Seit 01/2018 gibt es die Firmware auch für das sog. ''lazy config''. Hierbei können die Register einfach z.B. durch das nächste Öffnen des Fensters ausgelesen werden, ohne dass die Config-Taste gedrückt werden muss.
Das Update auf ''lazy config'' geht auf zwei Arten:

Keine Änderung der 'ID=0030' und Durchführen eines [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=94541 Firmware] bzw. eines FHEM Updates oder
{{Randnotiz|RNText=Firmware für 'ID=00C3'}}
Aktualisierung der Firmware auf 'ID=00C3'. Die Dateien können hier: [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=94538 makeota.html], [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=94542 Firmware (hex)] bzw. [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=94541 Firmware (eq3)] heruntergeladen werden.

Verwendet man den Sensor in Kombination mit originaler eq3 Hardware, sollte man die zweite Möglichkeit wählen.

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

<pre>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</pre>
setzt die Fuses.

<pre>avrdude -p m328p -P usb -c usbasp -V -U flash:w:bootloader.hex</pre>
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 USB Konfigurations-Adapter|HM-CFG-USB]] unter Linux ([[HomeMatic_Firmware_Update#Firmware_Update_mit_CUL.2FHM-CFG-USB_unter_FHEM|Update mit CUL oder HM-CFG-USB unter Linux]]), mit dem "HomeMatic Firmware Update Tool" unter Windows ([[HomeMatic_Firmware_Update#Firmware_Update_mit_HM-CFG-USB_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:

<pre>./flash-ota -f avr_HM_SEC_RHS_201705271601.eq3 -s RHS0000000</pre>

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

<pre>./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</pre>

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 ==
Den Magneten in den Drehring einbauen und diesen in das Gehäuse einbauen. Die Reedkontakte
Platzieren und mit einem Ohmmeter Messen, ob die Reedkontakte bei der entsprechenden Position
der Magnete schalten. Falls nicht, ggf. die Reedkontakte austauschen (Streuung!) bzw. einen stärkeren Magneten verwenden. Danach mittels Silberdraht bzw. Kupferlackdraht (an den zu
verlötenden Enden den Lack mittels eines Cuttermessers entfernen) die Reedkontakte gemäß
Bild verlöten und die Enden (GND, A0 bzw. A1) durch die vorgesehenen Öffnungen im Gehäuse führen.

''Verlötete Reedkontakte:''
[[Datei:HM_Fenstersensor-pic15.jpg]]

Danach die Antenne in die dafür vorgesehene Bohrung einführen und die Platine platzieren. Darauf achten, dass die Anschlüsse der Reedkontakte durch die dafür vorgesehenen Kontakte auf der Platine geführt werden.

''Einführen der Antenne:''
[[Datei:HM_Fenstersensor-pic17.jpg]]

''Platzierte Platine:''
[[Datei:HM_Fenstersensor-pic16.jpg]]

Nach Verlöten der drei Kontaktpunkte ist der Fensterdrehgriff fertig aufgebaut.

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

<pre>set <Device_Name> regSet msgRhsPosA <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>

== Montage ==
Bei der Standardeinstellung der Register gilt für die Platzierung des Magneten bei geöffnetem Fenster folgendes:
Bei links angeschlagenem Fenster muss der Magnet nach unten, bei rechts angeschlagenem nach oben.

== 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 [https://www.thingiverse.com/thing:2354704 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 {{Link2Forum|Topic=70413|LinkText=Service}} an.

== Links ==
*[https://forum.fhem.de/index.php/topic,71413.0.0.html Link zum Foren-Thread]
*[https://github.com/pa-pa/AskSinPP AskSinPP Libary]
*[https://github.com/pa-pa/HMSensor Alles Mögliche zu dem Projekt auf Github]
*[[HomeMatic_Type_threeStateSensor|CyclicInfoMsg aktivieren]]
*{{Link2Forum|Topic=70413|LinkText=3D-Druck service}}
*[[HomeMatic_Firmware_Update#Firmware_Update_mit_CUL.2FHM-CFG-USB_unter_FHEM|update-ota]]

[[Kategorie:HomeMatic Components‏‎]]
[[Kategorie:HomeBrew‏‎]]
[[Kategorie:868MHz]]

Easy-RS485-Bus

2019-02-23T16:30:35Z

PeMue: -e

{{Baustelle}}

Dieser Artikel ist im Entwurfsstadium.

= Überblick =

Ziel ist es eine standardisierte Umsetzung eines RS485 Buses z.B. für die FHEM easySensor Platinen zu beschreiben.
Als erste Nutzung ist die Anwendung für MySenors vorgehsehen. Andere Nutzungen sind natürlich auch möglich.

= Termininierung =
Die Terminierung ist ein sehr vielschichtiges Thema. Der Vorschlag von unten mit dem Widerstandsnetzwerk ist eine guter Kompromiss bezüglich Stromverbrauch und Stabilität.

Ohne Terminierung in der Theorie:
Bei 19200 Baud auf dem Bus ergibt sich ein Zeitfenster von ~50us pro Signalflanke, bei 50% maximale Anstiegzeit == 25us, Ausbreitungsgeschwindigkeit 21cm/ns.
Mit der angenommenen Faustregel: Einfache Laufzeit durch das Kabel maximal 1/6 der maximalen Anstiegzeit. 25us/6=4,2us, maximal mögliche Kabellänge 21cm * 1000 * 4.2 == 88200cm == 882m.

=> ergibt sichere 500 Meter...

[http://dcs-bios.a10c.de/rs485-resistors.html Online-Berechnung]

Beispiel zur einfachen Terminierung zwischen Pin1+2 eines RJ45 Steckers:

[[Datei:RS485-Termination.jpg|200px]]

Achtung: Für Homematic-Wired (HMW) ist allerdings das hier zu beachten: [[HomeMatic_Wired#Der_sogenannte_Busabschluss]]
D.h. wenn ein "normaler" 120Ohm Busabschluss verbaut ist, dann darf man das auf keinen Fall an einen HMW-Bus hängen. Besonders problematisch würde es werden, wenn zusätzlich noch der eq3-"Busabschluss" dranhängt.

Besser bewährt hat sich die Terminierung mit Widerstandsnetzwerk ähnlich wie bei Homematic Wired. Die Widerstandswerte sind anzupassen:
Bei höherer Spannung muss R5 vergrößert werden um zwischen GND und A auf ca. 5V zu kommen.

Problem: Die Leitung hat eine Kapazität. Diese muss bei Pegelwechseln geladen und entladen werden.
Bei höherer Geschwindigkeit oder schnellerer Transfer-Rate müssen die Widerstände verkleiner werden, damit steigt der Stromverbrauch am Bus, aber die Leistungen werden schneller auf den Normal-Pegel gezogen.

[[Datei:Schematic-Termination-24V.png|200px]]
[[Datei:Termination-24V.png|200px]]

+24V --- 22K---A---5K6---GND
B---4K7---GND
(Quelle: https://wiki.fhem.de/wiki/HomeMatic_Wired#Der_sogenannte_Busabschluss)

Ergibt ~5V an A und B wird nach GND gezogen

= Umsetzung =

== RJ45 ==

Standard:

Paar 1: Pin 4+5: blau/weiß: Frei/auf Pinheader, alternativ: Rückführung A+B

Paar 2: Pin 3+6: weiß/grün: Spannungsversorgung + / GND

Paar 3: Pin 1+2: weiß/orange: A+B kommend

Paar 4: Pin 7+8: weiß/braun: Zusätzliche Spannungsversorgung kommend, parallel zu Paar2, Alternative Nutzungen unter großer Vorsicht denkbar...

== 4 Poliger Anschluss ==
+ A B -

A) Terminator---GW--------Node---------Node--------Node---Terrminator

B) Terminator---GW-----Dose----Patchfeld---Patchfeld---Dose-----Node-----Node---Terminator

C) Mit Rückkanal: Terminator---GW----Dose---Patchfeld1---A=Patchfeld2====A--Node1
|| Patchfeld3====A--Node2----Terminator

[[Kategorie:NeedsEditing]]

HomeMatic Fenster-Drehgriffkontakt Community-Nachbau

2018-10-15T14:16:08Z

PeMue: Schreibfehler

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

Die Firmware ist identisch mit dem [https://www.elv.de/homematic-funk-fenster-drehgriffkontakt-1.html Originalen Sensor von ELV] und verhält sich dementsprechend auch gleich.

== Übersicht ==

Die Grundidee zu diesem Sensor wurde durch {{Link2Forum|Topic=71413.0|LinkText=Kawaci im Forum}} geliefert.
Die Umsetzung besteht aus einer Atmega328p Platine mit CC1101 Funkmodul (868 MHz) sowie
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 CR2032 Batteriehalterung auf der Platine durchgesetzt. Somit wird hier nicht näher auf andere Versionen (zwei Platinen zur Erfassung der Fensterstellung) eingegangen.

== Platine ==
'''Schaltplan:'''
[[Datei:FDGK_v1.0_sch.jpg]]

'''Platine v1.0 (Oberseite mit korrigierter Pinbelegung):'''
[[Datei:FDGK_v1.0_top.jpg]]

'''Platine v1.0 (Unterseite, ohne bestücktes Radio):'''
[[Datei:FDGK_v1.0_bot.jpg]]

== Bauteilliste ==
Die Bauteilliste gibt es auf [https://github.com/pa-pa/HMSensor/blob/master/HMSensor-CR2032/Parts.xls GitHub].

In der Liste sind die Magnete und Reed-Kontakte nicht aufgeführt.
Folgende können verwendet werden:
* Reed-Kontakt 2x14mm [https://de.aliexpress.com/item/10pcs-N-O-Reed-switch-Magnetic-Switch-2-14mm-Normally-Open-Magnetic-Induction-switch/32803902404.html Aliexpress]
* Neodym Magnet 4x2mm [https://de.aliexpress.com/item/32873144013/32873144013.html Aliexpress]

== Zusammenlöten der SMD Bauteile ==
Die Bestückung der Platine ist im [https://forum.fhem.de/index.php/topic,71413.msg640858.html#msg640858 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 [https://wiki.fhem.de/wiki/HomeMatic_Fenster-Drehgriffkontakt_Community-Nachbau#Firmware Flashen der Firmware] das Radio (IC2) bzw. den Batteriehalter (BT1) bestücken.
Als Antenne (ANT) wird ein Draht mit 72 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 ===
{{Randnotiz|RNText=Firmware für 'ID=0030'}}
Dafür wird, mit Hilfe der [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=91780 makeota.html] der Bootloader mit den benötigten Daten gefüllt und anschließend generiert.

Die makeota.html wird dazu in einem beliebigen 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 [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=91779 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.

Seit 01/2018 gibt es die Firmware auch für das sog. ''lazy config''. Hierbei können die Register einfach z.B. durch das nächste Öffnen des Fensters ausgelesen werden, ohne dass die Config-Taste gedrückt werden muss.
Das Update auf ''lazy config'' geht auf zwei Arten:

Keine Änderung der 'ID=0030' und Durchführen eines [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=94541 Firmware] bzw. eines FHEM Updates oder
{{Randnotiz|RNText=Firmware für 'ID=00C3'}}
Aktualisierung der Firmware auf 'ID=00C3'. Die Dateien können hier: [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=94538 makeota.html], [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=94542 Firmware (hex)] bzw. [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=94541 Firmware (eq3)] heruntergeladen werden.

Verwendet man den Sensor in Kombination mit originaler eq3 Hardware, sollte man die zweite Möglichkeit wählen.

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

<pre>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</pre>
setzt die Fuses.

<pre>avrdude -p m328p -P usb -c usbasp -V -U flash:w:bootloader.hex</pre>
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 USB Konfigurations-Adapter|HM-CFG-USB]] unter Linux ([[HomeMatic_Firmware_Update#Firmware_Update_mit_CUL.2FHM-CFG-USB_unter_FHEM|Update mit CUL oder HM-CFG-USB unter Linux]]), mit dem "HomeMatic Firmware Update Tool" unter Windows ([[HomeMatic_Firmware_Update#Firmware_Update_mit_HM-CFG-USB_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:

<pre>./flash-ota -f avr_HM_SEC_RHS_201705271601.eq3 -s RHS0000000</pre>

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

<pre>./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</pre>

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 ==
Den Magneten in den Drehring einbauen und diesen in das Gehäuse einbauen. Die Reedkontakte
Platzieren und mit einem Ohmmeter Messen, ob die Reedkontakte bei der entsprechenden Position
der Magnete schalten. Falls nicht, ggf. die Reedkontakte austauschen (Streuung!) bzw. einen stärkeren Magneten verwenden. Danach mittels Silberdraht bzw. Kupferlackdraht (an den zu
verlötenden Enden den Lack mittels eines Cuttermessers entfernen) die Reedkontakte gemäß
Bild verlöten und die Enden (GND, A0 bzw. A1) durch die vorgesehenen Öffnungen im Gehäuse führen.

''Verlötete Reedkontakte:''
[[Datei:HM_Fenstersensor-pic15.jpg]]

Danach die Antenne in die dafür vorgesehene Bohrung einführen und die Platine platzieren. Darauf achten, dass die Anschlüsse der Reedkontakte durch die dafür vorgesehenen Kontakte auf der Platine geführt werden.

''Einführen der Antenne:''
[[Datei:HM_Fenstersensor-pic17.jpg]]

''Platzierte Platine:''
[[Datei:HM_Fenstersensor-pic16.jpg]]

Nach Verlöten der drei Kontaktpunkte ist der Fensterdrehgriff fertig aufgebaut.

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

<pre>set <Device_Name> regSet msgRhsPosA <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>

== Montage ==
Bei der Standardeinstellung der Register gilt für die Platzierung des Magneten bei geöffnetem Fenster folgendes:
Bei links angeschlagenem Fenster muss der Magnet nach unten, bei rechts angeschlagenem nach oben.

== 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 [https://www.thingiverse.com/thing:2354704 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 {{Link2Forum|Topic=70413|LinkText=Service}} an.

== Links ==
*[https://forum.fhem.de/index.php/topic,71413.0.0.html Link zum Foren-Thread]
*[https://github.com/pa-pa/AskSinPP AskSinPP Libary]
*[https://github.com/pa-pa/HMSensor Alles Mögliche zu dem Projekt auf Github]
*[[HomeMatic_Type_threeStateSensor|CyclicInfoMsg aktivieren]]
*{{Link2Forum|Topic=70413|LinkText=3D-Druck service}}
*[[HomeMatic_Firmware_Update#Firmware_Update_mit_CUL.2FHM-CFG-USB_unter_FHEM|update-ota]]

[[Kategorie:HomeMatic Components‏‎]]
[[Kategorie:HomeBrew‏‎]]
[[Kategorie:868MHz]]

HM-MOD-RPI-PCB HomeMatic Funkmodul für Raspberry Pi

2018-06-11T19:26:03Z

PeMue: Pinbelegung korrigiert, letzter Link korrigiert, Schreibfehler korrigiert.

{{Infobox Hardware
|Bild=HM-MOD-RPI-PCB.jpg
|Bildbeschreibung=HomeMatic Funkmodul für Raspberry Pi
|HWProtocol=HomeMatic
|HWType=Gateway
|HWCategory=HomeMatic
|HWComm=868,3/869,525 MHz
|HWChannels=n/a
|HWVoltage=1,8–3,6 V DC
|HWPowerConsumption=50 mA max.
|HWPoweredBy=RasPi
|HWSize=19x41x14mm
|HWDeviceFHEM=[[HMUARTLGW]]
|HWManufacturer=ELV / eQ-3
}}

Das [[HM-MOD-RPI-PCB HomeMatic Funkmodul für Raspberry Pi]] ist eine Platine, die auf die GPIO-Schnittstelle des [[Raspberry Pi]] aufgesteckt werden und damit als [[Interface]] zu [[HomeMatic]] Geräten dienen kann.

== Aufbau, Einsatz und grundsätzliche Funktionsweise ==
Das Modul besteht aus zwei Teilplatinen, die von eQ-3 über den Internetshop von ELV (als Bausatz ab etwa 20€, fertig montiert ab etwa 30€) verkauft werden.

Das eigentliche Funkmodul wird mit HM-MOD-RPI-UART bezeichnet (und trägt den Aufdruck UART, im obigen Bild hinten teilweise verdeckt und mit der umrandeten 7 versehen), sie hat fünf einpolige Buchsen mit dem Rastermaß 2mm. Die Zusatzplatine zum Anschluss an die GPIO wird mit TRX1 bezeichnet (im obigen Bild vorn sichtbar mit dem Aufdruck HM-MOD-RPI-PCB), sie hat zwei sechspolige Buchsen mit dem Rastermaß 2,54mm. Die Zusatzplatine enthält im Wesentlichen Stützkondensatoren und erlaubt einen direkten Anschluss an die GPIO eines Raspberry Pi.
* Der vorgesehene Einsatz als Aufsteckmodul auf den GPIO Port des Raspberry erfordert eine Modell abhängige Konfiguration. Diese wird im Setupbereich des Wiki Artikel zum [[Raspberry_Pi]] beschrieben.

{{Randnotiz|RNText=Neben der hier beschriebenen Option das HM-MOD-RPI-PCB zu verwenden, besteht auch die Möglichkeit, damit auf demselben Raspberry eine virtuelle CCU zu betreiben, welche dann mit [[HMCCU]] eingebunden werden kann. Hierfür stehen mehrere Virtualisierungsvarianten zur Verfügung; eine kurze Darstellung, wie das mittels YAHM funktioniert, ist in diesem {{Link2Forum|Topic=79670|Message=718289|Forenbeitrag}} zu finden.}}Mit dieser Platine in Verbidnung mit dem FHEM-Modul [[HMUARTLGW]] ist nur der Betrieb von BidCoS-Geräten möglich. Zur Einbindung von Geräten, die HM-IP verwenden, ist derzeit (Stand Juni 2018) noch zwingend eine (ggf. virtualisierte) CCU2 oder neuer erforderlich.

Das Funkmodul stellt auf dem 868MHz-Frequenzband eine Verbindung zu Homematic-Geräten her. Das Modul wird über die serielle Schnittstelle an ein Gerät gekoppelt, dass diese serielle Schnittstelle auswerten und die Information dann weiterverarbeiten kann. Hier kommen beispielsweise in Frage: Raspberry Pi, WeMos mini, ESP8266-Module, USB-serielle Adapter. Bereits das UART-Funkmodul erlaubt eine serielle Anbindung (die entsprechenden Schnittstellen Tx und Rx sind vorhanden, sie basieren auf 3,3V), es kann aber auch die zusätzliche TRX1-Platine seriell verbunden werden. Des weiteren gibt es im Forum einen ([https://forum.fhem.de/index.php/topic,56606.0.html Thread]), in dem PeMue eine eigene Platinenversion (Schaltplan, Stückliste und vieles mehr) vorstellt.
=== Platine 1 -PCB-Modul ===
[[Datei:Hm-uart trx1.png|thumb|right|200px|Verkabelung beim HM-MOD-PCB]]
Am einfachsten ist es sicherlich, das kombinierte PCB-Modul (also beide Platinen UART und TRX1 durch eine Pfostenleiste miteinander verlötet) direkt auf die GPIO des Raspberry Pi aufzustecken. Das Bild rechts zeigt die entsprechende Verkabelung.
<br clear=all>
=== Platine 2 -UART-Modul ===
[[Datei:Verkabelung-HM-MOD-uart.png|thumb|right|200px|Verkabelung beim HM-MOD-UART]]
Will man das TRX1-Modul nicht verwenden, so kann man auch das UART-Modul direkt mit Rx/Tx des Raspberry Pi verbinden. Das Bild rechts zeigt die entsprechende Verkabelung. Hier sollten allerdings Stützkondensatoren an die Stromversorgung des UART angebracht werden, da Spannungsschwankungen sonst zu schwer interpretierbaren Fehlern führen können. Die Anschlüsse sind dem nachstehenden Bild zu entnehmen, allerdings ist hier nicht die UART-Platine, sondern das TRX1-Gegenstück zu sehen!

Sowohl serielle Schnittstelle des Raspberry Pi als auch das UART-Modul arbeiten mit 3,3V arbeitet, so dass man keine Spannungsteiler benötigt. Mehr Informationen zu den GPIOs findet man unter diesem [http://www.netzmafia.de/skripten/hardware/RasPi/RasPi_GPIO.html Link].

=== Zusammenbau und Verwendung ===
Man sollte die Antenne aus dem Gehäuse schauen lassen oder möglichst weit weg von jeder Elektronik positionieren. Außerdem bitte das Ende der Drahtantenne mit einem Klecks Heißkleber oder ähnlichem isolieren. Eine Berührung vor allem mit dem Innenleben des Raspberry Pi muss vermieden werden!

Bitte auf die richtige Lage (Bilder) beim Zusammenbau und auf Lötzinnbrücken achten. Das sind häufige Fehler beim Zusammenbau!

Beide Platinen können zusammengebaut oder auch nur das UART Modul getrennt verwendet werden.
[[Datei:HM-MOD-UART-Unten.jpg|thumb|left|200px|Montage des Moduls HM-MOD-UART unten]]
[[Datei:HM-MOD-UART-Oben.jpg|thumb|right|200px|Montage des Moduls HM-MOD-UART oben]]
Die originale Montage in der Anleitung von eq3 sieht den Zusammenbau PCB Modul unten und UART Modul oben vor(rechts). Damit passen die kleineren Pi Gehäuse nicht, das Gesamtmodul klemmt am Deckel.

Man kann ohne weiteres das UART Modul unter dem PCB Modul montieren (links), damit wird die Gesamthöhe geringer und es passt problemlos in jedes Gehäuse. Es kann sein das jetzt aber Kühlkörper oder ähnliches seitens der Pi Platine stören.
<br clear=all>

== Verwendung mit Raspberry Pi ==

=== Originaler Einsatzzweck im Raspberry ===
Die notwendige Konfiguration der Schnittstelle ist hier beschrieben: [[Raspberry_Pi#Verwendung_UART_f.C3.BCr_Zusatzmodule|Verwendung UART für Zusatzmodule]].
* Der Einsatz in FHEM für CUL_HM erfolgt mit dem Modul [[HMUARTLGW]]

=== Remoteanbindung - Pi + RPI Modul = LAN Modul ===

Eine andere Methode der Anbindung des Modul besteht darin, einen RPi (auf dem aber nicht FHEM läuft bzw. auf dieses Modul zugreift) und dem dort vorhandenen LAN-Anschluss zu verwenden. Dieser RPi greift mit einem seriellen Anschluss auf das Modul zu und der entfernte FHEM-Server gelangt über das Netzwerk an das HM-Modul. Die Installation gelingt wie folgt

'''Installation auf Remote Instanz'''

sudo apt-get install socat

Auf diesem Pi, also wo das Modul steckt:

sudo socat TCP4-LISTEN:2000,fork,reuseaddr /dev/ttyAMA0,raw,echo=0,b115200

Auf einen Debian Jessie mit systemd legt man am besten folgende Datei an:
/etc/systemd/system/hmlangw.service

[Install]
WantedBy=multi-user.target
Type=forking

[Service]
ExecStart=/usr/bin/socat TCP4-LISTEN:2000,fork,reuseaddr /dev/ttyAMA0,raw,echo=0,b115200
User=root
Restart=always
RestartSec=10

Dann kann mit

sudo systemctl enable hmlangw

der Service zum Autostart konfiguriert werden.
Auf dem Modul wo FHEM läuft und das Modul Remote angeschlossen werden soll:

define RM_HmUART_EG HMUARTLGW uart://<IP-Adresse>:2000
attr RM_HmUART hmId xxxxxx

Es handelt sich nicht um sharing der seriellen Schnittstelle und damit "verfügbar machen" des Moduls "all over the World"! Es handelt sich um ein exklusives "Kabel" von einem Server im Netzwerk zum Pi und über dessen lokaler Schnittstelle zum RPI Modul.

* FHEM Server: FHEM -> uart://IP:Port -> Netzwerk -> socat listener -> socat serial -> RPI Modul auf Remote Pi

== Verwendung mit anderer Hardware ==
=== Anbindung mit USB-Adapter ===
{{Randnotiz|RNTyp=r|RNText=Bitte beachten: Es sind immer wieder Exemplare mit [[CP2102]] im Umlauf, die mehr als 3.3V Spannung liefern! Vor dem Verbinden mit dem HM-Modul sollte daher geprüft werden, ob der interne Spannungswandler ordnungsgemäß funktioniert und wirklich nur 3.3V liefert. Bei den blauen Micro-Modulen kann man den Fehler nach dieser Anleitung beheben: [https://www.silabs.com/community/interface/forum.topic.html/cp2102_3_3v_outputi-EaVr Beitrag von PBudmark vom 08.07.2017].}}
[[Datei:PL2102 Modul.png|200px|thumb|right|Mod zur Herstellung der korrekten Spannung]]
Das UART-Modul kann ebenfalls mit einem USB-Adapter an ein USB-fähiges Gerät angeschlossen werden. Allerdings ist hier wieder auf den Spannnungspegel zu achten, unbedingt einen USB-Adapter mit 3,3 Volt Pegel nehmen! Grundsätzlich bewährt haben sich z.B. Modelle mit einem [[CP2102]], der auch ausreichend Stromreserven zum Betrieb des Moduls bietet. Dabei ist die serielle Schnittstelle wie üblich zu kreuzen, also

'''Verschaltung'''
3.3V <-> 3.3V
GND <-> GND
Rx <-> Tx
Tx <-> Rx

=== Anbindung mit ESP8266 ===
Es kann ein beliebiger ESP8266 verwendet werden. Beim ESP8266 gibt es zwei verschiedene Firmware-Möglichkeiten: ESPLink oder ESPEasy. Ebenso sind zwei verschiedene Schnittstellen möglich: Entweder direkt die serielle Schnittstelle (da die ESP auf 3,3V laufen, sind keine Spannungsteiler erforderlich, Verschaltung siehe oben) oder aber durch eine ''swapped'' Schnittstelle, bei der auf die digitalen Pins D7/D8 zurückgegriffen wird (siehe unten). Die letztere Verschaltung erfordert aber eine entsprechende Implementierung der Schnittstelle in der Firmware selbst (''serieller Server'' genannt), die beispielsweise bei ESPEasy nicht gegeben ist oder selbst kompiliert werden muss.

'''Verschaltung bei einem WeMos D1 mini'''
(UART) <-> (Wemos)
3.3V <-> 3.3V
GND <-> GND
Rx <-> D8
Tx <-> D7

Es gibt eine ausführliche Erläuterung für die Software unter [https://forum.fhem.de/index.php?action=dlattach;topic=56606.0;attach=68630].

Verwendet man ESP-Link, so muss neben der WLAN Konfiguration nur das Pin Assignment konfiguriert werden. Alle Pins auf disabled und UART pins auf swapped stellen.

Im Forum gibt es mehr Informationen zu diesen Adaptern, zum Beispiel {{Link2Forum|Topic=62651|LinkText="(amunra)-Platine für HM-MOD-UART-RPI..."}} oder {{Link2Forum|Topic=79559|LinkText="3. Sammelbestellung - Homematic WLAN Gateway"}}.

=== Betrieb mit einem LAN-TTL-Wandler ===
[[Datei:Hm-uart und usr-tcp232-T2.png|thumb|right|400px|Anschluß an die gängige Variante USR-TCP232-T2]]Auf gängigen Marktplätzen sind für etwas weniger als 10 Euro Module erhältlich, die einen seriellen Anschluss Im LAN bereitstellen können.

Die Module melden sich per DHCP im Netzwerk an, die Konfiguration und firmware updates können über ein Web-Interface oder ein Windows-Tool erfolgen.

=== Betrieb mit MapleCUx ===

Auch die seriellen Schnittstellen, die ein MapleCUL oder [[MapleCUN]] bereitstellen, können zum Anschluß des Moduls verwendet werden. Der MapleCUN stellt beide seriellen Schnittstellen je unter einem eigenen Port ins Netz.

== Definition in FHEM ==

Je nach physischem Anschluss erfolgt eine Anbindung in FHEM in unterschiedlicher Weise. Wurde ein USB-Adapter auf dem FHEM-Gerät selbst verwendet, definiert man das Gerät in FHEM wie folgt
define USB_HmUART HMUARTLGW /dev/ttyUSB0
Wurde dagegen das Gerät über WLAN oder LAN durch das UART-Modul angebunden, erfolgt die Einbindung in FHEM durch
define WLAN_HmUART HMUARTLGW uart://<IP-Adresse>:<Portnummer>
Portnummern:
*socat 2000
*esp-link 23
*MapleCUN 2324 bzw. 2325
*USR-TCP232-T2 entspr. Konfiguration.

=== Logbeispiel ===
Typischerweise meldet sich das Modul beim Start so:
2016.10.06 17:11:16 3: Opening myHmUART device /dev/ttyAMA0
2016.10.06 17:11:16 3: Setting myHmUART serial parameters to 115200,8,N,1
2016.10.06 17:11:16 3: myHmUART device opened
2016.10.06 17:11:17 3: HMUARTLGW myHmUART currently running Co_CPU_BL
2016.10.06 17:11:17 3: HMUARTLGW myHmUART currently running Co_CPU_App

=== Verwendung AES in FHEM===
Das Modul beherrscht AES.
Für weitere Informationen gibt es einen separaten Wiki Eintrag [[AES Encryption]]

=== Firmware Update des UART-Moduls mit FHEM ===

Die Module werden mit einer Firmware 1.2.1 ausgeliefert. Dies Firmware ist nicht für einen stabilen Betrieb geeignet,
die Firmware 1.4.1 ist die minimal lauffähige Version.

Die ersten zwei Schritte werden in der Kommandozeile auf Betriebssystemebene ausgeführt, also im "Terminal". Punkt 3 ist bis auf die Pfadeingabe in der FHEM Web Oberfläche auswählbar.

1. Firmware herunterladen
# Version 1.4.1
wget https://raw.githubusercontent.com/eq-3/occu/28045df83480122f90ab92f7c6e625f9bf3b61aa/firmware/HM-MOD-UART/coprocessor_update.eq3
# Alternativ die aktuellste
wget https://raw.githubusercontent.com/eq-3/occu/HEAD/firmware/HM-MOD-UART/coprocessor_update.eq3

2. Kopieren an einen Ort wo FHEM Zugriff hat, am Besten nach /opt/fhem/FHEM/firmware
sudo cp coprocessor_update.eq3 /opt/fhem/FHEM/firmware/

3. Flashen der neuen Firmware aus FHEM
set myHmUART updateCoPro /opt/fhem/FHEM/firmware/coprocessor_update.eq3

=== Firmware Update des UART-Moduls ohne FHEM ===

Sollte das Update über FHEM nicht funktionieren oder FHEM nicht verfügbar sein, kann die Firmware auch wie folgt eingespielt werden (Quelle: [http://heinz-otto.blogspot.com/2016/07/raspberry-pi-homematic-modul.html Ottos Technik Blog])

sudo su
apt-get update && apt-get -y install libusb-1.0-0-dev build-essential git
systemctl stop fhem
git clone git://git.zerfleddert.de/hmcfgusb
cd hmcfgusb/
make
# Firmware runterladen
wget https://raw.githubusercontent.com/eq-3/occu/ee68faf77e42ed5e3641790b43a710a3301cea7e/firmware/HM-MOD-UART/coprocessor_update.eq3
# eigentliches flashen:
./flash-hmmoduart -U /dev/ttyAMA0 coprocessor_update.eq3

=== Bekannte Probleme ===
Sollten beim Flashen der Firmware hartnäckige Probleme auftreten (kein Erfolg aber auch gar keine Fehlermeldungen) ist das Modul vom Strom zu trennen, ein Neustart des Pi reicht nicht!

Ein {{Link2Forum|Topic=41203|Message=340320|LinkText=Beitrag}} aus dem genannten Forenthread: ''Das Ding ist anscheinend wirklich einfach das Funkmodul aus der CCU2 (wird zumindest in der eQ-3 SW als CCU2 angesprochen) und spricht ein für FHEM vollkommen neues Protokoll.''

== Links ==
* {{Link2Forum|Topic=41203|LinkText=Forenthread}} mit Nachfrage zur Unterstützung dieses Geräts in FHEM
* {{Link2Forum|Topic=54511|LinkText=Modul für HomeMatic UART-Modul (RPi) und HomeMatic LAN Gateway}}
* [http://www.elv.de/homematic-funkmodul-fuer-raspberry-pi-bausatz.html Produktseite] bei ELV
* {{DocLink|elv|/Assets/Produkte/10/1040/104029/Downloads/104029_lan_gateway_um.pdf Bedienungsanleitung}}
* {{Link2Forum|Topic=56606|LinkText=Forenthread}} Hardware Thread mit vielen Varianten der Anbindung. In Post #26 gibt es die Detailbeschreibung in der angehängten PDF.

[[Kategorie:HomeMatic Components]]
[[Kategorie:Interfaces]]
[[Kategorie:Raspberry Pi]]
[[Kategorie:868MHz]]

HomeMatic Fenster-Drehgriffkontakt Community-Nachbau

2018-02-12T14:16:20Z

PeMue: Formatierung

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

Die Firmware ist identisch mit dem [https://www.elv.de/homematic-funk-fenster-drehgriffkontakt-1.html Originalen Sensor von ELV] und verhält sich dementsprechend auch gleich.

== Übersicht ==

Die Grundidee zu diesem Sensor wurde durch {{Link2Forum|Topic=71413.0|LinkText=Kawaci im Forum}} geliefert.
Die Umsetzung besteht aus einer Atmega328p Platine mit CC1101 Funkmodul (868 MHz) sowie
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 CR2032 Batteriehalterung auf der Platine durchgesetzt. Somit wird hier nicht näher auf andere Versionen (zwei Platinen zur Erfassung der Fensterstellung) eingegangen.

== Platine ==
'''Schaltplan:'''
[[Datei:FDGK_v1.0_sch.jpg]]

'''Platine v1.0 (Oberseite mit korrigierter Pinbelegung):'''
[[Datei:FDGK_v1.0_top.jpg]]

'''Platine v1.0 (Unterseite, ohne bestücktes Radio):'''
[[Datei:FDGK_v1.0_bot.jpg]]

== Bauteilliste ==
Die Bauteilliste gibt es auf [https://github.com/pa-pa/HMSensor/blob/master/HMSensor-CR2032/Parts.xls GitHub].

In der Liste sind die Magnete und Reed-Kontakte nicht aufgeführt.
Folgende können verwendet werden:
* Reed-Kontakt 2x14mm [https://de.aliexpress.com/item/10pcs-N-O-Reed-switch-Magnetic-Switch-2-14mm-Normally-Open-Magnetic-Induction-switch/32803902404.html Aliexpress]
* Neodym Magnet 2x2mm [https://de.aliexpress.com/item/100pcs-2x2mm-magnet-2x2-Super-strong-neo-neodymium-magnet-N35-D2x2-D2x2mm-permanent-magnet-D2-2mm/32693530575.html Aliexpress]

== Zusammenlöten der SMD Bauteile ==
Die Bestückung der Platine ist im [https://forum.fhem.de/index.php/topic,71413.msg640858.html#msg640858 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 [https://wiki.fhem.de/wiki/HomeMatic_Fenster-Drehgriffkontakt_Community-Nachbau#Firmware Flashen der Firmware] das Radio (IC2) bzw. den Batteriehalter (BT1) bestücken.
Als Antenne (ANT) wird ein Draht mit 72 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 ===
{{Randnotiz|RNText=Firmware für 'ID=0030'}}
Dafür wird, mit Hilfe der [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=91780 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 [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=91779 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.

Seit 01/2018 gibt es die Firmware auch für das sog. ''lazy config''. Hierbei können die Register einfach z.B. durch das nächste Öffnen des Fensters ausgelesen werden, ohne dass die Config-Taste gedrückt werden muss.
Das Update auf ''lazy config'' geht auf zwei Arten:

Keine Änderung der 'ID=0030' und Durchführen eines [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=94541 Firmware] bzw. eines FHEM Updates oder
{{Randnotiz|RNText=Firmware für 'ID=00C3'}}
Aktualisierung der Firmware auf 'ID=00C3'. Die Dateien können hier: [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=94538 makeota.html], [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=94542 Firmware (hex)] bzw. [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=94541 Firmware (eq3)] heruntergeladen werden.

Verwendet man den Sensor in Kombination mit originaler eq3 Hardware, sollte man die zweite Möglichkeit wählen.

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

<pre>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</pre>
Setzt die Fuses.

<pre>avrdude -p m328p -P usb -c usbasp -V -U flash:w:bootloader.hex</pre>
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 USB Konfigurations-Adapter|HM-CFG-USB]] unter Linux ([[HomeMatic_Firmware_Update#Firmware_Update_mit_CUL.2FHM-CFG-USB_unter_FHEM|Update mit CUL oder HM-CFG-USB unter Linux]]), mit dem "HomeMatic Firmware Update Tool" unter Windows ([[HomeMatic_Firmware_Update#Firmware_Update_mit_HM-CFG-USB_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:

<pre>./flash-ota -f avr_HM_SEC_RHS_201705271601.eq3 -s RHS0000000</pre>

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

<pre>./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</pre>

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 ==
Den Magneten in den Drehring einbauen und diesen in das Gehäuse einbauen. Die Reedkontakte
Platzieren und mit einem Ohmmeter Messen, ob die Reedkontakte bei der entsprechenden Position
der Magnete schalten. Falls nicht, ggf. die Reedkontakte austauschen (Streuung!) bzw. einen stärkeren Magneten verwenden. Danach mittels Silberdraht bzw. Kupferlackdraht (an den zu
verlötenden Enden den Lack mittels eines Cuttermessers entfernen) die Reedkontakte gemäß
Bild verlöten und die Enden (GND, A0 bzw. A1) durch die vorgesehenen Öffnungen im Gehäuse führen.

''Verlötete Reedkontakte:''
[[Datei:HM_Fenstersensor-pic15.jpg]]

Danach die Antenne in die dafür vorgesehene Bohrung einführen und die Platine platzieren. Darauf achten, dass die Anschlüsse der Reedkontakte durch die dafür vorgesehenen Kontakte auf der Platine geführt werden.

''Einführen der Antenne:''
[[Datei:HM_Fenstersensor-pic17.jpg]]

''Platzierte Platine:''
[[Datei:HM_Fenstersensor-pic16.jpg]]

Nach Verlöten der drei Kontaktpunkte ist der Fensterdrehgriff fertig aufgebaut.

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

<pre>set <Device_Name> regSet msgRhsPosA <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>

== 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 [https://www.thingiverse.com/thing:2354704 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 {{Link2Forum|Topic=70413|LinkText=Service}} an.

== Links ==
*[https://forum.fhem.de/index.php/topic,71413.0.0.html Link zum Foren-Thread]
*[https://github.com/pa-pa/AskSinPP AskSinPP Libary]
*[https://github.com/pa-pa/HMSensor Alles Mögliche zu dem Projekt auf Github]
*[[HomeMatic_Type_threeStateSensor|CyclicInfoMsg aktivieren]]
*{{Link2Forum|Topic=70413|LinkText=3D-Druck service}}
*[[HomeMatic_Firmware_Update#Firmware_Update_mit_CUL.2FHM-CFG-USB_unter_FHEM|update-ota]]

[[Kategorie:HomeMatic Components‏‎]]
[[Kategorie:HomeBrew‏‎]]

HomeMatic Fenster-Drehgriffkontakt Community-Nachbau

2018-02-12T14:12:23Z

PeMue: Firmware Update für lazy config

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

Die Firmware ist identisch mit dem [https://www.elv.de/homematic-funk-fenster-drehgriffkontakt-1.html Originalen Sensor von ELV] und verhält sich dementsprechend auch gleich.

== Übersicht ==

Die Grundidee zu diesem Sensor wurde durch {{Link2Forum|Topic=71413.0|LinkText=Kawaci im Forum}} geliefert.
Die Umsetzung besteht aus einer Atmega328p Platine mit CC1101 Funkmodul (868 MHz) sowie
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 CR2032 Batteriehalterung auf der Platine durchgesetzt. Somit wird hier nicht näher auf andere Versionen (zwei Platinen zur Erfassung der Fensterstellung) eingegangen.

== Platine ==
'''Schaltplan:'''
[[Datei:FDGK_v1.0_sch.jpg]]

'''Platine v1.0 (Oberseite mit korrigierter Pinbelegung):'''
[[Datei:FDGK_v1.0_top.jpg]]

'''Platine v1.0 (Unterseite, ohne bestücktes Radio):'''
[[Datei:FDGK_v1.0_bot.jpg]]

== Bauteilliste ==
Die Bauteilliste gibt es auf [https://github.com/pa-pa/HMSensor/blob/master/HMSensor-CR2032/Parts.xls GitHub].

In der Liste sind die Magnete und Reed-Kontakte nicht aufgeführt.
Folgende können verwendet werden:
* Reed-Kontakt 2x14mm [https://de.aliexpress.com/item/10pcs-N-O-Reed-switch-Magnetic-Switch-2-14mm-Normally-Open-Magnetic-Induction-switch/32803902404.html Aliexpress]
* Neodym Magnet 2x2mm [https://de.aliexpress.com/item/100pcs-2x2mm-magnet-2x2-Super-strong-neo-neodymium-magnet-N35-D2x2-D2x2mm-permanent-magnet-D2-2mm/32693530575.html Aliexpress]

== Zusammenlöten der SMD Bauteile ==
Die Bestückung der Platine ist im [https://forum.fhem.de/index.php/topic,71413.msg640858.html#msg640858 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 [https://wiki.fhem.de/wiki/HomeMatic_Fenster-Drehgriffkontakt_Community-Nachbau#Firmware Flashen der Firmware] das Radio (IC2) bzw. den Batteriehalter (BT1) bestücken.
Als Antenne (ANT) wird ein Draht mit 72 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 ===
{{Randnotiz|RNText=Firmware für 'ID=0030'}}
Dafür wird, mit Hilfe der [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=91780 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 [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=91779 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.

{{Randnotiz|RNText=Firmware für 'ID=00C3'}}
Seit 01/2018 gibt es die Firmware auch für das sog. ''lazy config''. Hierbei können die Register einfach z.B. durch das nächste Öffnen des Fensters ausgelesen werden, ohne dass die Config-Taste gedrückt werden muss.
Das Update auf ''lazy config'' geht auf zwei Arten: Keine Änderung der 'ID=0030' und Durchführen [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=94541 Firmware] bzw. eines FHEM Updates oder Aktualisierung der Firmware auf 'ID=00C3'. Die Dateien können hier [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=94538 makeota.html], [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=94542 Firmware (hex)] bzw. [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=94541 Firmware (eq3)] heruntergeladen werden. Verwendet man den Sensor in Kombination mit originaler eq3 Hardware, sollte man die zweite Möglichkeit wählen.

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

<pre>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</pre>
Setzt die Fuses.

<pre>avrdude -p m328p -P usb -c usbasp -V -U flash:w:bootloader.hex</pre>
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 USB Konfigurations-Adapter|HM-CFG-USB]] unter Linux ([[HomeMatic_Firmware_Update#Firmware_Update_mit_CUL.2FHM-CFG-USB_unter_FHEM|Update mit CUL oder HM-CFG-USB unter Linux]]), mit dem "HomeMatic Firmware Update Tool" unter Windows ([[HomeMatic_Firmware_Update#Firmware_Update_mit_HM-CFG-USB_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:

<pre>./flash-ota -f avr_HM_SEC_RHS_201705271601.eq3 -s RHS0000000</pre>

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

<pre>./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</pre>

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 ==
Den Magneten in den Drehring einbauen und diesen in das Gehäuse einbauen. Die Reedkontakte
Platzieren und mit einem Ohmmeter Messen, ob die Reedkontakte bei der entsprechenden Position
der Magnete schalten. Falls nicht, ggf. die Reedkontakte austauschen (Streuung!) bzw. einen stärkeren Magneten verwenden. Danach mittels Silberdraht bzw. Kupferlackdraht (an den zu
verlötenden Enden den Lack mittels eines Cuttermessers entfernen) die Reedkontakte gemäß
Bild verlöten und die Enden (GND, A0 bzw. A1) durch die vorgesehenen Öffnungen im Gehäuse führen.

''Verlötete Reedkontakte:''
[[Datei:HM_Fenstersensor-pic15.jpg]]

Danach die Antenne in die dafür vorgesehene Bohrung einführen und die Platine platzieren. Darauf achten, dass die Anschlüsse der Reedkontakte durch die dafür vorgesehenen Kontakte auf der Platine geführt werden.

''Einführen der Antenne:''
[[Datei:HM_Fenstersensor-pic17.jpg]]

''Platzierte Platine:''
[[Datei:HM_Fenstersensor-pic16.jpg]]

Nach Verlöten der drei Kontaktpunkte ist der Fensterdrehgriff fertig aufgebaut.

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

<pre>set <Device_Name> regSet msgRhsPosA <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>

== 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 [https://www.thingiverse.com/thing:2354704 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 {{Link2Forum|Topic=70413|LinkText=Service}} an.

== Links ==
*[https://forum.fhem.de/index.php/topic,71413.0.0.html Link zum Foren-Thread]
*[https://github.com/pa-pa/AskSinPP AskSinPP Libary]
*[https://github.com/pa-pa/HMSensor Alles Mögliche zu dem Projekt auf Github]
*[[HomeMatic_Type_threeStateSensor|CyclicInfoMsg aktivieren]]
*{{Link2Forum|Topic=70413|LinkText=3D-Druck service}}
*[[HomeMatic_Firmware_Update#Firmware_Update_mit_CUL.2FHM-CFG-USB_unter_FHEM|update-ota]]

[[Kategorie:HomeMatic Components‏‎]]
[[Kategorie:HomeBrew‏‎]]

HomeMatic Fenster-Drehgriffkontakt Community-Nachbau

2018-02-09T14:39:43Z

PeMue: Anpassung auf die verschiedenen HM-IDs.

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

Die Firmware ist identisch mit dem [https://www.elv.de/homematic-funk-fenster-drehgriffkontakt-1.html Originalen Sensor von ELV] und verhält sich dementsprechend auch gleich.

== Übersicht ==

Die Grundidee zu diesem Sensor wurde durch {{Link2Forum|Topic=71413.0|LinkText=Kawaci im Forum}} geliefert.
Die Umsetzung besteht aus einer Atmega328p Platine mit CC1101 Funkmodul (868 MHz) sowie
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 CR2032 Batteriehalterung auf der Platine durchgesetzt. Somit wird hier nicht näher auf andere Versionen (zwei Platinen zur Erfassung der Fensterstellung) eingegangen.

== Platine ==
'''Schaltplan:'''
[[Datei:FDGK_v1.0_sch.jpg]]

'''Platine v1.0 (Oberseite mit korrigierter Pinbelegung):'''
[[Datei:FDGK_v1.0_top.jpg]]

'''Platine v1.0 (Unterseite, ohne bestücktes Radio):'''
[[Datei:FDGK_v1.0_bot.jpg]]

== Bauteilliste ==
Die Bauteilliste gibt es auf [https://github.com/pa-pa/HMSensor/blob/master/HMSensor-CR2032/Parts.xls GitHub].

In der Liste sind die Magnete und Reed-Kontakte nicht aufgeführt.
Folgende können verwendet werden:
* Reed-Kontakt 2x14mm [https://de.aliexpress.com/item/10pcs-N-O-Reed-switch-Magnetic-Switch-2-14mm-Normally-Open-Magnetic-Induction-switch/32803902404.html Aliexpress]
* Neodym Magnet 2x2mm [https://de.aliexpress.com/item/100pcs-2x2mm-magnet-2x2-Super-strong-neo-neodymium-magnet-N35-D2x2-D2x2mm-permanent-magnet-D2-2mm/32693530575.html Aliexpress]

== Zusammenlöten der SMD Bauteile ==
Die Bestückung der Platine ist im [https://forum.fhem.de/index.php/topic,71413.msg640858.html#msg640858 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 [https://wiki.fhem.de/wiki/HomeMatic_Fenster-Drehgriffkontakt_Community-Nachbau#Firmware Flashen der Firmware] das Radio (IC2) bzw. den Batteriehalter (BT1) bestücken.
Als Antenne (ANT) wird ein Draht mit 72 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 ===
{{Randnotiz|RNText=Firmware für 'ID=0030'}}
Dafür wird, mit Hilfe der [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=91780 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 [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=91779 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.

{{Randnotiz|RNText=Firmware für 'ID=00C3'}}
Seit 01/2018 gibt es die Firmware auch für das sog. ''lazy config''. Hierbei können die Register einfach z.B. durch das nächste Öffnen des Fensters ausgelesen werden, ohne dass die Config-Taste gedrückt werden muss.
Das Update auf ''lazy config'' geht auf zwei Arten: Belassen der Firmware für 'ID=0030' und Durchführen eines FHEM Updates oder Aktualisierung der Firmware auf 'ID=00C3'. Die Dateien können hier [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=94538 makeota.html], [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=94542 Firmware (hex)] bzw. [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=94541 Firmware (eq3)] heruntergeladen werden.

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

<pre>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</pre>
Setzt die Fuses.

<pre>avrdude -p m328p -P usb -c usbasp -V -U flash:w:bootloader.hex</pre>
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 USB Konfigurations-Adapter|HM-CFG-USB]] unter Linux ([[HomeMatic_Firmware_Update#Firmware_Update_mit_CUL.2FHM-CFG-USB_unter_FHEM|Update mit CUL oder HM-CFG-USB unter Linux]]), mit dem "HomeMatic Firmware Update Tool" unter Windows ([[HomeMatic_Firmware_Update#Firmware_Update_mit_HM-CFG-USB_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:

<pre>./flash-ota -f avr_HM_SEC_RHS_201705271601.eq3 -s RHS0000000</pre>

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

<pre>./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</pre>

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 ==
Den Magneten in den Drehring einbauen und diesen in das Gehäuse einbauen. Die Reedkontakte
Platzieren und mit einem Ohmmeter Messen, ob die Reedkontakte bei der entsprechenden Position
der Magnete schalten. Falls nicht, ggf. die Reedkontakte austauschen (Streuung!) bzw. einen stärkeren Magneten verwenden. Danach mittels Silberdraht bzw. Kupferlackdraht (an den zu
verlötenden Enden den Lack mittels eines Cuttermessers entfernen) die Reedkontakte gemäß
Bild verlöten und die Enden (GND, A0 bzw. A1) durch die vorgesehenen Öffnungen im Gehäuse führen.

''Verlötete Reedkontakte:''
[[Datei:HM_Fenstersensor-pic15.jpg]]

Danach die Antenne in die dafür vorgesehene Bohrung einführen und die Platine platzieren. Darauf achten, dass die Anschlüsse der Reedkontakte durch die dafür vorgesehenen Kontakte auf der Platine geführt werden.

''Einführen der Antenne:''
[[Datei:HM_Fenstersensor-pic17.jpg]]

''Platzierte Platine:''
[[Datei:HM_Fenstersensor-pic16.jpg]]

Nach Verlöten der drei Kontaktpunkte ist der Fensterdrehgriff fertig aufgebaut.

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

<pre>set <Device_Name> regSet msgRhsPosA <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>

== 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 [https://www.thingiverse.com/thing:2354704 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 {{Link2Forum|Topic=70413|LinkText=Service}} an.

== Links ==
*[https://forum.fhem.de/index.php/topic,71413.0.0.html Link zum Foren-Thread]
*[https://github.com/pa-pa/AskSinPP AskSinPP Libary]
*[https://github.com/pa-pa/HMSensor Alles Mögliche zu dem Projekt auf Github]
*[[HomeMatic_Type_threeStateSensor|CyclicInfoMsg aktivieren]]
*{{Link2Forum|Topic=70413|LinkText=3D-Druck service}}
*[[HomeMatic_Firmware_Update#Firmware_Update_mit_CUL.2FHM-CFG-USB_unter_FHEM|update-ota]]

[[Kategorie:HomeMatic Components‏‎]]
[[Kategorie:HomeBrew‏‎]]

HomeMatic Fenster-Drehgriffkontakt Community-Nachbau

2018-02-08T21:09:09Z

PeMue: makeota.html aus den Links gelöscht, da in github eine alte Version liegt

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

Die Firmware ist identisch mit dem [https://www.elv.de/homematic-funk-fenster-drehgriffkontakt-1.html Originalen Sensor von ELV] und verhält sich dementsprechend auch gleich.

== Übersicht ==

Die Grundidee zu diesem Sensor wurde durch {{Link2Forum|Topic=71413.0|LinkText=Kawaci im Forum}} geliefert.
Die Umsetzung besteht aus einer Atmega328p Platine mit CC1101 Funkmodul (868 MHz) sowie
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 CR2032 Batteriehalterung auf der Platine durchgesetzt. Somit wird hier nicht näher auf andere Versionen (zwei Platinen zur Erfassung der Fensterstellung) eingegangen.

== Platine ==
'''Schaltplan:'''
[[Datei:FDGK_v1.0_sch.jpg]]

'''Platine v1.0 (Oberseite mit korrigierter Pinbelegung):'''
[[Datei:FDGK_v1.0_top.jpg]]

'''Platine v1.0 (Unterseite, ohne bestücktes Radio):'''
[[Datei:FDGK_v1.0_bot.jpg]]

== Bauteilliste ==
Die Bauteilliste gibt es auf [https://github.com/pa-pa/HMSensor/blob/master/HMSensor-CR2032/Parts.xls GitHub].

In der Liste sind die Magnete und Reed-Kontakte nicht aufgeführt.
Folgende können verwendet werden:
* Reed-Kontakt 2x14mm [https://de.aliexpress.com/item/10pcs-N-O-Reed-switch-Magnetic-Switch-2-14mm-Normally-Open-Magnetic-Induction-switch/32803902404.html Aliexpress]
* Neodym Magnet 2x2mm [https://de.aliexpress.com/item/100pcs-2x2mm-magnet-2x2-Super-strong-neo-neodymium-magnet-N35-D2x2-D2x2mm-permanent-magnet-D2-2mm/32693530575.html Aliexpress]

== Zusammenlöten der SMD Bauteile ==
Die Bestückung der Platine ist im [https://forum.fhem.de/index.php/topic,71413.msg640858.html#msg640858 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 [https://wiki.fhem.de/wiki/HomeMatic_Fenster-Drehgriffkontakt_Community-Nachbau#Firmware Flashen der Firmware] das Radio (IC2) bzw. den Batteriehalter (BT1) bestücken.
Als Antenne (ANT) wird ein Draht mit 72 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 [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=91780 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 [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=91779 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.

{{Randnotiz|RNText=Firmware für ''lazy config''}}
Seit 01/2018 gibt es die Firmware auch für das sog. ''lazy config''. Hierbei können die Register einfach z.B. durch das nächste Öffnen des Fensters ausgelesen werden, ohne dass die Config-Taste gedrückt werden muss.
Die Dateien können hier [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=94538 makeota.html], [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=94542 Firmware (hex)] bzw. [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=94541 Firmware (eq3)] heruntergeladen werden.

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

<pre>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</pre>
Setzt die Fuses.

<pre>avrdude -p m328p -P usb -c usbasp -V -U flash:w:bootloader.hex</pre>
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 USB Konfigurations-Adapter|HM-CFG-USB]] unter Linux ([[HomeMatic_Firmware_Update#Firmware_Update_mit_CUL.2FHM-CFG-USB_unter_FHEM|Update mit CUL oder HM-CFG-USB unter Linux]]), mit dem "HomeMatic Firmware Update Tool" unter Windows ([[HomeMatic_Firmware_Update#Firmware_Update_mit_HM-CFG-USB_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:

<pre>./flash-ota -f avr_HM_SEC_RHS_201705271601.eq3 -s RHS0000000</pre>

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

<pre>./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</pre>

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 ==
Den Magneten in den Drehring einbauen und diesen in das Gehäuse einbauen. Die Reedkontakte
Platzieren und mit einem Ohmmeter Messen, ob die Reedkontakte bei der entsprechenden Position
der Magnete schalten. Falls nicht, ggf. die Reedkontakte austauschen (Streuung!) bzw. einen stärkeren Magneten verwenden. Danach mittels Silberdraht bzw. Kupferlackdraht (an den zu
verlötenden Enden den Lack mittels eines Cuttermessers entfernen) die Reedkontakte gemäß
Bild verlöten und die Enden (GND, A0 bzw. A1) durch die vorgesehenen Öffnungen im Gehäuse führen.

''Verlötete Reedkontakte:''
[[Datei:HM_Fenstersensor-pic15.jpg]]

Danach die Antenne in die dafür vorgesehene Bohrung einführen und die Platine platzieren. Darauf achten, dass die Anschlüsse der Reedkontakte durch die dafür vorgesehenen Kontakte auf der Platine geführt werden.

''Einführen der Antenne:''
[[Datei:HM_Fenstersensor-pic17.jpg]]

''Platzierte Platine:''
[[Datei:HM_Fenstersensor-pic16.jpg]]

Nach Verlöten der drei Kontaktpunkte ist der Fensterdrehgriff fertig aufgebaut.

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

<pre>set <Device_Name> regSet msgRhsPosA <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>

== 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 [https://www.thingiverse.com/thing:2354704 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 {{Link2Forum|Topic=70413|LinkText=Service}} an.

== Links ==
*[https://forum.fhem.de/index.php/topic,71413.0.0.html Link zum Foren-Thread]
*[https://github.com/pa-pa/AskSinPP AskSinPP Libary]
*[https://github.com/pa-pa/HMSensor Alles Mögliche zu dem Projekt auf Github]
*[[HomeMatic_Type_threeStateSensor|CyclicInfoMsg aktivieren]]
*{{Link2Forum|Topic=70413|LinkText=3D-Druck service}}
*[[HomeMatic_Firmware_Update#Firmware_Update_mit_CUL.2FHM-CFG-USB_unter_FHEM|update-ota]]

[[Kategorie:HomeMatic Components‏‎]]
[[Kategorie:HomeBrew‏‎]]

HomeMatic Fenster-Drehgriffkontakt Community-Nachbau

2018-02-08T21:00:48Z

PeMue: Randnotiz eingefügt

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

Die Firmware ist identisch mit dem [https://www.elv.de/homematic-funk-fenster-drehgriffkontakt-1.html Originalen Sensor von ELV] und verhält sich dementsprechend auch gleich.

== Übersicht ==

Die Grundidee zu diesem Sensor wurde durch {{Link2Forum|Topic=71413.0|LinkText=Kawaci im Forum}} geliefert.
Die Umsetzung besteht aus einer Atmega328p Platine mit CC1101 Funkmodul (868 MHz) sowie
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 CR2032 Batteriehalterung auf der Platine durchgesetzt. Somit wird hier nicht näher auf andere Versionen (zwei Platinen zur Erfassung der Fensterstellung) eingegangen.

== Platine ==
'''Schaltplan:'''
[[Datei:FDGK_v1.0_sch.jpg]]

'''Platine v1.0 (Oberseite mit korrigierter Pinbelegung):'''
[[Datei:FDGK_v1.0_top.jpg]]

'''Platine v1.0 (Unterseite, ohne bestücktes Radio):'''
[[Datei:FDGK_v1.0_bot.jpg]]

== Bauteilliste ==
Die Bauteilliste gibt es auf [https://github.com/pa-pa/HMSensor/blob/master/HMSensor-CR2032/Parts.xls GitHub].

In der Liste sind die Magnete und Reed-Kontakte nicht aufgeführt.
Folgende können verwendet werden:
* Reed-Kontakt 2x14mm [https://de.aliexpress.com/item/10pcs-N-O-Reed-switch-Magnetic-Switch-2-14mm-Normally-Open-Magnetic-Induction-switch/32803902404.html Aliexpress]
* Neodym Magnet 2x2mm [https://de.aliexpress.com/item/100pcs-2x2mm-magnet-2x2-Super-strong-neo-neodymium-magnet-N35-D2x2-D2x2mm-permanent-magnet-D2-2mm/32693530575.html Aliexpress]

== Zusammenlöten der SMD Bauteile ==
Die Bestückung der Platine ist im [https://forum.fhem.de/index.php/topic,71413.msg640858.html#msg640858 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 [https://wiki.fhem.de/wiki/HomeMatic_Fenster-Drehgriffkontakt_Community-Nachbau#Firmware Flashen der Firmware] das Radio (IC2) bzw. den Batteriehalter (BT1) bestücken.
Als Antenne (ANT) wird ein Draht mit 72 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 [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=91780 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 [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=91779 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.

{{Randnotiz|RNText=Firmware für ''lazy config''}}
Seit 01/2018 gibt es die Firmware auch für das sog. ''lazy config''. Hierbei können die Register einfach z.B. durch das nächste Öffnen des Fensters ausgelesen werden, ohne dass die Config-Taste gedrückt werden muss.
Die Dateien können hier [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=94538 makeota.html], [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=94542 Firmware (hex)] bzw. [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=94541 Firmware (eq3)] heruntergeladen werden.

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

<pre>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</pre>
Setzt die Fuses.

<pre>avrdude -p m328p -P usb -c usbasp -V -U flash:w:bootloader.hex</pre>
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 USB Konfigurations-Adapter|HM-CFG-USB]] unter Linux ([[HomeMatic_Firmware_Update#Firmware_Update_mit_CUL.2FHM-CFG-USB_unter_FHEM|Update mit CUL oder HM-CFG-USB unter Linux]]), mit dem "HomeMatic Firmware Update Tool" unter Windows ([[HomeMatic_Firmware_Update#Firmware_Update_mit_HM-CFG-USB_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:

<pre>./flash-ota -f avr_HM_SEC_RHS_201705271601.eq3 -s RHS0000000</pre>

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

<pre>./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</pre>

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 ==
Den Magneten in den Drehring einbauen und diesen in das Gehäuse einbauen. Die Reedkontakte
Platzieren und mit einem Ohmmeter Messen, ob die Reedkontakte bei der entsprechenden Position
der Magnete schalten. Falls nicht, ggf. die Reedkontakte austauschen (Streuung!) bzw. einen stärkeren Magneten verwenden. Danach mittels Silberdraht bzw. Kupferlackdraht (an den zu
verlötenden Enden den Lack mittels eines Cuttermessers entfernen) die Reedkontakte gemäß
Bild verlöten und die Enden (GND, A0 bzw. A1) durch die vorgesehenen Öffnungen im Gehäuse führen.

''Verlötete Reedkontakte:''
[[Datei:HM_Fenstersensor-pic15.jpg]]

Danach die Antenne in die dafür vorgesehene Bohrung einführen und die Platine platzieren. Darauf achten, dass die Anschlüsse der Reedkontakte durch die dafür vorgesehenen Kontakte auf der Platine geführt werden.

''Einführen der Antenne:''
[[Datei:HM_Fenstersensor-pic17.jpg]]

''Platzierte Platine:''
[[Datei:HM_Fenstersensor-pic16.jpg]]

Nach Verlöten der drei Kontaktpunkte ist der Fensterdrehgriff fertig aufgebaut.

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

<pre>set <Device_Name> regSet msgRhsPosA <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>

== 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 [https://www.thingiverse.com/thing:2354704 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 {{Link2Forum|Topic=70413|LinkText=Service}} an.

== Links ==
*[https://forum.fhem.de/index.php/topic,71413.0.0.html Link zum Foren-Thread]
*[https://github.com/pa-pa/AskSinPP AskSinPP Libary]
*[https://github.com/pa-pa/HMSensor Alles mögliche zu dem Projekt auf Github]
*[https://raw.githubusercontent.com/pa-pa/AskSinPP/master/examples/HM-SEC-RHS/makeota.html makeota.html]
*[[HomeMatic_Type_threeStateSensor|CyclicInfoMsg aktivieren]]
*{{Link2Forum|Topic=70413|LinkText=3D-Druck service}}
*[[HomeMatic_Firmware_Update#Firmware_Update_mit_CUL.2FHM-CFG-USB_unter_FHEM|update-ota]]

[[Kategorie:HomeMatic Components‏‎]]
[[Kategorie:HomeBrew‏‎]]

HomeMatic Fenster-Drehgriffkontakt Community-Nachbau

2018-02-08T20:52:30Z

PeMue: Korrektur

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

Die Firmware ist identisch mit dem [https://www.elv.de/homematic-funk-fenster-drehgriffkontakt-1.html Originalen Sensor von ELV] und verhält sich dementsprechend auch gleich.

== Übersicht ==

Die Grundidee zu diesem Sensor wurde durch {{Link2Forum|Topic=71413.0|LinkText=Kawaci im Forum}} geliefert.
Die Umsetzung besteht aus einer Atmega328p Platine mit CC1101 Funkmodul (868 MHz) sowie
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 CR2032 Batteriehalterung auf der Platine durchgesetzt. Somit wird hier nicht näher auf andere Versionen (zwei Platinen zur Erfassung der Fensterstellung) eingegangen.

== Platine ==
'''Schaltplan:'''
[[Datei:FDGK_v1.0_sch.jpg]]

'''Platine v1.0 (Oberseite mit korrigierter Pinbelegung):'''
[[Datei:FDGK_v1.0_top.jpg]]

'''Platine v1.0 (Unterseite, ohne bestücktes Radio):'''
[[Datei:FDGK_v1.0_bot.jpg]]

== Bauteilliste ==
Die Bauteilliste gibt es auf [https://github.com/pa-pa/HMSensor/blob/master/HMSensor-CR2032/Parts.xls GitHub].

In der Liste sind die Magnete und Reed-Kontakte nicht aufgeführt.
Folgende können verwendet werden:
* Reed-Kontakt 2x14mm [https://de.aliexpress.com/item/10pcs-N-O-Reed-switch-Magnetic-Switch-2-14mm-Normally-Open-Magnetic-Induction-switch/32803902404.html Aliexpress]
* Neodym Magnet 2x2mm [https://de.aliexpress.com/item/100pcs-2x2mm-magnet-2x2-Super-strong-neo-neodymium-magnet-N35-D2x2-D2x2mm-permanent-magnet-D2-2mm/32693530575.html Aliexpress]

== Zusammenlöten der SMD Bauteile ==
Die Bestückung der Platine ist im [https://forum.fhem.de/index.php/topic,71413.msg640858.html#msg640858 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 [https://wiki.fhem.de/wiki/HomeMatic_Fenster-Drehgriffkontakt_Community-Nachbau#Firmware Flashen der Firmware] das Radio (IC2) bzw. den Batteriehalter (BT1) bestücken.
Als Antenne (ANT) wird ein Draht mit 72 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 [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=91780 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 [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=91779 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.

Seit 01/2018 gibt es die Firmware auch für das sog. ''lazy config''. Hierbei können die Register einfach z.B. durch das nächste Öffnen des Fensters ausgelesen werden, ohne dass die Config-Taste gedrückt werden muss.
Die Dateien können hier [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=94538 makeota.html], [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=94542 Firmware (hex)] bzw. [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=94541 Firmware (eq3)] heruntergeladen werden.

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

<pre>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</pre>
Setzt die Fuses.

<pre>avrdude -p m328p -P usb -c usbasp -V -U flash:w:bootloader.hex</pre>
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 USB Konfigurations-Adapter|HM-CFG-USB]] unter Linux ([[HomeMatic_Firmware_Update#Firmware_Update_mit_CUL.2FHM-CFG-USB_unter_FHEM|Update mit CUL oder HM-CFG-USB unter Linux]]), mit dem "HomeMatic Firmware Update Tool" unter Windows ([[HomeMatic_Firmware_Update#Firmware_Update_mit_HM-CFG-USB_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:

<pre>./flash-ota -f avr_HM_SEC_RHS_201705271601.eq3 -s RHS0000000</pre>

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

<pre>./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</pre>

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 ==
Den Magneten in den Drehring einbauen und diesen in das Gehäuse einbauen. Die Reedkontakte
Platzieren und mit einem Ohmmeter Messen, ob die Reedkontakte bei der entsprechenden Position
der Magnete schalten. Falls nicht, ggf. die Reedkontakte austauschen (Streuung!) bzw. einen stärkeren Magneten verwenden. Danach mittels Silberdraht bzw. Kupferlackdraht (an den zu
verlötenden Enden den Lack mittels eines Cuttermessers entfernen) die Reedkontakte gemäß
Bild verlöten und die Enden (GND, A0 bzw. A1) durch die vorgesehenen Öffnungen im Gehäuse führen.

''Verlötete Reedkontakte:''
[[Datei:HM_Fenstersensor-pic15.jpg]]

Danach die Antenne in die dafür vorgesehene Bohrung einführen und die Platine platzieren. Darauf achten, dass die Anschlüsse der Reedkontakte durch die dafür vorgesehenen Kontakte auf der Platine geführt werden.

''Einführen der Antenne:''
[[Datei:HM_Fenstersensor-pic17.jpg]]

''Platzierte Platine:''
[[Datei:HM_Fenstersensor-pic16.jpg]]

Nach Verlöten der drei Kontaktpunkte ist der Fensterdrehgriff fertig aufgebaut.

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

<pre>set <Device_Name> regSet msgRhsPosA <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>

== 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 [https://www.thingiverse.com/thing:2354704 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 {{Link2Forum|Topic=70413|LinkText=Service}} an.

== Links ==
*[https://forum.fhem.de/index.php/topic,71413.0.0.html Link zum Foren-Thread]
*[https://github.com/pa-pa/AskSinPP AskSinPP Libary]
*[https://github.com/pa-pa/HMSensor Alles mögliche zu dem Projekt auf Github]
*[https://raw.githubusercontent.com/pa-pa/AskSinPP/master/examples/HM-SEC-RHS/makeota.html makeota.html]
*[[HomeMatic_Type_threeStateSensor|CyclicInfoMsg aktivieren]]
*{{Link2Forum|Topic=70413|LinkText=3D-Druck service}}
*[[HomeMatic_Firmware_Update#Firmware_Update_mit_CUL.2FHM-CFG-USB_unter_FHEM|update-ota]]

[[Kategorie:HomeMatic Components‏‎]]
[[Kategorie:HomeBrew‏‎]]

HomeMatic Fenster-Drehgriffkontakt Community-Nachbau

2018-02-08T20:49:34Z

PeMue: Firmware für lazy config aktualisiert

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

Die Firmware ist identisch mit dem [https://www.elv.de/homematic-funk-fenster-drehgriffkontakt-1.html Originalen Sensor von ELV] und verhält sich dementsprechend auch gleich.

== Übersicht ==

Die Grundidee zu diesem Sensor wurde durch {{Link2Forum|Topic=71413.0|LinkText=Kawaci im Forum}} geliefert.
Die Umsetzung besteht aus einer Atmega328p Platine mit CC1101 Funkmodul (868 MHz) sowie
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 CR2032 Batteriehalterung auf der Platine durchgesetzt. Somit wird hier nicht näher auf andere Versionen (zwei Platinen zur Erfassung der Fensterstellung) eingegangen.

== Platine ==
'''Schaltplan:'''
[[Datei:FDGK_v1.0_sch.jpg]]

'''Platine v1.0 (Oberseite mit korrigierter Pinbelegung):'''
[[Datei:FDGK_v1.0_top.jpg]]

'''Platine v1.0 (Unterseite, ohne bestücktes Radio):'''
[[Datei:FDGK_v1.0_bot.jpg]]

== Bauteilliste ==
Die Bauteilliste gibt es auf [https://github.com/pa-pa/HMSensor/blob/master/HMSensor-CR2032/Parts.xls GitHub].

In der Liste sind die Magnete und Reed-Kontakte nicht aufgeführt.
Folgende können verwendet werden:
* Reed-Kontakt 2x14mm [https://de.aliexpress.com/item/10pcs-N-O-Reed-switch-Magnetic-Switch-2-14mm-Normally-Open-Magnetic-Induction-switch/32803902404.html Aliexpress]
* Neodym Magnet 2x2mm [https://de.aliexpress.com/item/100pcs-2x2mm-magnet-2x2-Super-strong-neo-neodymium-magnet-N35-D2x2-D2x2mm-permanent-magnet-D2-2mm/32693530575.html Aliexpress]

== Zusammenlöten der SMD Bauteile ==
Die Bestückung der Platine ist im [https://forum.fhem.de/index.php/topic,71413.msg640858.html#msg640858 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 [https://wiki.fhem.de/wiki/HomeMatic_Fenster-Drehgriffkontakt_Community-Nachbau#Firmware Flashen der Firmware] das Radio (IC2) bzw. den Batteriehalter (BT1) bestücken.
Als Antenne (ANT) wird ein Draht mit 72 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 [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=91780 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 [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=91779 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.

Seit 01/2018 gibt es die Firmware auch für das sog. ''lazy config''. Hierbei können Register mit Hilfe des nächsten z.B. Öffnen des Fensters ausgelesen werden, ohne dass die Config-Taste gedrückt werden muss.
Die Dateien sind hier: [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=94538 makeota.html], [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=94542 Firmware (hex)] bzw. [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=94541 Firmware (eq3)].

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

<pre>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</pre>
Setzt die Fuses.

<pre>avrdude -p m328p -P usb -c usbasp -V -U flash:w:bootloader.hex</pre>
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 USB Konfigurations-Adapter|HM-CFG-USB]] unter Linux ([[HomeMatic_Firmware_Update#Firmware_Update_mit_CUL.2FHM-CFG-USB_unter_FHEM|Update mit CUL oder HM-CFG-USB unter Linux]]), mit dem "HomeMatic Firmware Update Tool" unter Windows ([[HomeMatic_Firmware_Update#Firmware_Update_mit_HM-CFG-USB_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:

<pre>./flash-ota -f avr_HM_SEC_RHS_201705271601.eq3 -s RHS0000000</pre>

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

<pre>./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</pre>

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 ==
Den Magneten in den Drehring einbauen und diesen in das Gehäuse einbauen. Die Reedkontakte
Platzieren und mit einem Ohmmeter Messen, ob die Reedkontakte bei der entsprechenden Position
der Magnete schalten. Falls nicht, ggf. die Reedkontakte austauschen (Streuung!) bzw. einen stärkeren Magneten verwenden. Danach mittels Silberdraht bzw. Kupferlackdraht (an den zu
verlötenden Enden den Lack mittels eines Cuttermessers entfernen) die Reedkontakte gemäß
Bild verlöten und die Enden (GND, A0 bzw. A1) durch die vorgesehenen Öffnungen im Gehäuse führen.

''Verlötete Reedkontakte:''
[[Datei:HM_Fenstersensor-pic15.jpg]]

Danach die Antenne in die dafür vorgesehene Bohrung einführen und die Platine platzieren. Darauf achten, dass die Anschlüsse der Reedkontakte durch die dafür vorgesehenen Kontakte auf der Platine geführt werden.

''Einführen der Antenne:''
[[Datei:HM_Fenstersensor-pic17.jpg]]

''Platzierte Platine:''
[[Datei:HM_Fenstersensor-pic16.jpg]]

Nach Verlöten der drei Kontaktpunkte ist der Fensterdrehgriff fertig aufgebaut.

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

<pre>set <Device_Name> regSet msgRhsPosA <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>

== 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 [https://www.thingiverse.com/thing:2354704 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 {{Link2Forum|Topic=70413|LinkText=Service}} an.

== Links ==
*[https://forum.fhem.de/index.php/topic,71413.0.0.html Link zum Foren-Thread]
*[https://github.com/pa-pa/AskSinPP AskSinPP Libary]
*[https://github.com/pa-pa/HMSensor Alles mögliche zu dem Projekt auf Github]
*[https://raw.githubusercontent.com/pa-pa/AskSinPP/master/examples/HM-SEC-RHS/makeota.html makeota.html]
*[[HomeMatic_Type_threeStateSensor|CyclicInfoMsg aktivieren]]
*{{Link2Forum|Topic=70413|LinkText=3D-Druck service}}
*[[HomeMatic_Firmware_Update#Firmware_Update_mit_CUL.2FHM-CFG-USB_unter_FHEM|update-ota]]

[[Kategorie:HomeMatic Components‏‎]]
[[Kategorie:HomeBrew‏‎]]

MapleCUx und 1-wire

2018-01-20T10:30:02Z

PeMue: korrigierten Schaltplan verlinkt

== Einleitung ==
Der [https://wiki.fhem.de/wiki/MapleCUN mapleCUx] (mapleCUL für USB- bzw. mapleCUN für Netzwerkbetrieb) bietet die Möglichkeit, ähnlich wie der CUNO, über einen 1-wire Busmaster (DS2482) 1-wire Sensoren oder Aktoren zu betreiben.

Hierzu muss statt dem Radio CC2 eine entsprechende 1-wire Schaltung vorgesehen sein.

Wie beim CUNO gibt es hierfür zwei Möglichkeiten:
* In der Firmware des mapleCUx ist eine Möglichkeit enthalten, die 1-wire Temperatursensoren DS18S20 in das slowRF-Protokoll zu ''mappen''. 1-wire Temperatursensoren am mapleCUx werden in diesem Fall von FHEM automatisch als HMS-T eingebunden. Andere 1-wire Sensoren oder Aktoren werden von der Firmware hierbei nicht ausgewertet.
* Das Modul 00_OWX.pm kann mit dem mapleCUx kommunizieren und ermöglicht dadurch die Verwendung von allen 1-wire Sensoren bzw. Aktoren am mapleCUx.

In der Standardversion der CUNO-Firmware ist die Einschränkung enthalten, welche die Erkennung von 1-wire Devices durch die Firmware auf 10 beschränkt, s. unten.

== Hardware ==
Manche [https://forum.fhem.de/index.php/topic,60458.msg671078.html#msg671078 Selbstbau Platinen] sehen den entsprechenden 1-wire Busmaster mit Pegelwandler schon auf dem Layout vor.

Ist dies nicht der Fall, muss eine Schaltung wie hier gezeigt

[[File:MapleCUx_1-wire_sch_korr.png|600px]]

statt dem Radio CC2 vorgesehen werden.

== Firmware ==
Der 1-wire Bus wird durch die von der Firmware vorgesehenen Kommandos gesteuert. Diese sind in der Beschreibung der CUNO-Firmware nachzulesen, siehe [http://culfw.de/commandref.html#cmd_O [1]]

In dieser Firmware ist sowohl der 1-wire Suchalgorithmus implementiert, als auch das Lesen und Schreiben von einzelnen Bits und Bytes auf den 1-wire Bus. Mit diesen Low-Level Kommunikationsfunktionen lassen sich bei Verwendung des Modul 00_OWX.pm alle 1-wire Komponenten ansteuern.

In der Standardversion der CUNO bzw. mapleCUx-Firmware ist die Einschränkung enthalten, welche die Erkennung von 1-wire Devices auf 10 beschränkt. Will man dies erhöhen, muss in der Datei board.h die folgende Zeile mit einem Wert > 10 geändert und die Firmware für den mapleCux neu übersetzt und geflasht werden.

#define HAS_ONEWIRE 10 // OneWire Device Buffer, RAM: 10 * 8 Byte

== FHEM ==
Definition in FHEM:

Wenn der mapleCUx in FHEM so definiert ist

define mapleCUL CUL 192.168.69.145:2323 1536

kann der 1-wire Bus wie folgt definiert werden
define MapleOWire OWX mapleCUL

Wenn autocreate angeschaltet ist, werden die angeschlossenen 1-wire Devices nach einem Suchen per
get MapleOWire devices
automatisch angelegt und können danach nach eigenen Wünschen umbenannt werden.

== Literatur ==
*[1] CULFW Commandref http://culfw.de/commandref.html#cmd_O

[[Kategorie:CUL]]
[[Kategorie:1-Wire]]
[[Kategorie:Hardware Mods]]

Datei:MapleCUx 1-wire sch korr.png

2018-01-20T10:29:06Z

PeMue: korrigierter Schaltplan 1-wire für mapleCUx

korrigierter Schaltplan 1-wire für mapleCUx

MapleCUx und 1-wire

2018-01-20T06:11:24Z

PeMue: Link auf mapleCUN Wiki Artikel eingefügt

== Einleitung ==
Der [https://wiki.fhem.de/wiki/MapleCUN mapleCUx] (mapleCUL für USB- bzw. mapleCUN für Netzwerkbetrieb) bietet die Möglichkeit, ähnlich wie der CUNO, über einen 1-wire Busmaster (DS2482) 1-wire Sensoren oder Aktoren zu betreiben.

Hierzu muss statt dem Radio CC2 eine entsprechende 1-wire Schaltung vorgesehen sein.

Wie beim CUNO gibt es hierfür zwei Möglichkeiten:
* In der Firmware des mapleCUx ist eine Möglichkeit enthalten, die 1-wire Temperatursensoren DS18S20 in das slowRF-Protokoll zu ''mappen''. 1-wire Temperatursensoren am mapleCUx werden in diesem Fall von FHEM automatisch als HMS-T eingebunden. Andere 1-wire Sensoren oder Aktoren werden von der Firmware hierbei nicht ausgewertet.
* Das Modul 00_OWX.pm kann mit dem mapleCUx kommunizieren und ermöglicht dadurch die Verwendung von allen 1-wire Sensoren bzw. Aktoren am mapleCUx.

In der Standardversion der CUNO-Firmware ist die Einschränkung enthalten, welche die Erkennung von 1-wire Devices durch die Firmware auf 10 beschränkt, s. unten.

== Hardware ==
Manche [https://forum.fhem.de/index.php/topic,60458.msg671078.html#msg671078 Selbstbau Platinen] sehen den entsprechenden 1-wire Busmaster mit Pegelwandler schon auf dem Layout vor.

Ist dies nicht der Fall, muss eine Schaltung wie hier gezeigt

[[File:MapleCUx_1-wire_sch.jpg|600px]]

statt dem Radio CC2 vorgesehen werden.

== Firmware ==
Der 1-wire Bus wird durch die von der Firmware vorgesehenen Kommandos gesteuert. Diese sind in der Beschreibung der CUNO-Firmware nachzulesen, siehe [http://culfw.de/commandref.html#cmd_O [1]]

In dieser Firmware ist sowohl der 1-wire Suchalgorithmus implementiert, als auch das Lesen und Schreiben von einzelnen Bits und Bytes auf den 1-wire Bus. Mit diesen Low-Level Kommunikationsfunktionen lassen sich bei Verwendung des Modul 00_OWX.pm alle 1-wire Komponenten ansteuern.

In der Standardversion der CUNO bzw. mapleCUx-Firmware ist die Einschränkung enthalten, welche die Erkennung von 1-wire Devices auf 10 beschränkt. Will man dies erhöhen, muss in der Datei board.h die folgende Zeile mit einem Wert > 10 geändert und die Firmware für den mapleCux neu übersetzt und geflasht werden.

#define HAS_ONEWIRE 10 // OneWire Device Buffer, RAM: 10 * 8 Byte

== FHEM ==
Definition in FHEM:

Wenn der mapleCUx in FHEM so definiert ist

define mapleCUL CUL 192.168.69.145:2323 1536

kann der 1-wire Bus wie folgt definiert werden
define MapleOWire OWX mapleCUL

Wenn autocreate angeschaltet ist, werden die angeschlossenen 1-wire Devices nach einem Suchen per
get MapleOWire devices
automatisch angelegt und können danach nach eigenen Wünschen umbenannt werden.

== Literatur ==
*[1] CULFW Commandref http://culfw.de/commandref.html#cmd_O

[[Kategorie:CUL]]
[[Kategorie:1-Wire]]
[[Kategorie:Hardware Mods]]

MapleCUx und 1-wire

2018-01-20T06:08:33Z

PeMue: Korrektur

== Einleitung ==
Der mapleCUx (mapleCUL für USB- bzw. mapleCUN für Netzwerkbetrieb) bietet die Möglichkeit, ähnlich wie der CUNO, über einen 1-wire Busmaster (DS2482) 1-wire Sensoren oder Aktoren zu betreiben.

Hierzu muss statt dem Radio CC2 eine entsprechende 1-wire Schaltung vorgesehen sein.

Wie beim CUNO gibt es hierfür zwei Möglichkeiten:
* In der Firmware des mapleCUx ist eine Möglichkeit enthalten, die 1-wire Temperatursensoren DS18S20 in das slowRF-Protokoll zu ''mappen''. 1-wire Temperatursensoren am mapleCUx werden in diesem Fall von FHEM automatisch als HMS-T eingebunden. Andere 1-wire Sensoren oder Aktoren werden von der Firmware hierbei nicht ausgewertet.
* Das Modul 00_OWX.pm kann mit dem mapleCUx kommunizieren und ermöglicht dadurch die Verwendung von allen 1-wire Sensoren bzw. Aktoren am mapleCUx.

In der Standardversion der CUNO-Firmware ist die Einschränkung enthalten, welche die Erkennung von 1-wire Devices durch die Firmware auf 10 beschränkt, s. unten.

== Hardware ==
Manche [https://forum.fhem.de/index.php/topic,60458.msg671078.html#msg671078 Selbstbau Platinen] sehen den entsprechenden 1-wire Busmaster mit Pegelwandler schon auf dem Layout vor.

Ist dies nicht der Fall, muss eine Schaltung wie hier gezeigt

[[File:MapleCUx_1-wire_sch.jpg|600px]]

statt dem Radio CC2 vorgesehen werden.

== Firmware ==
Der 1-wire Bus wird durch die von der Firmware vorgesehenen Kommandos gesteuert. Diese sind in der Beschreibung der CUNO-Firmware nachzulesen, siehe [http://culfw.de/commandref.html#cmd_O [1]]

In dieser Firmware ist sowohl der 1-wire Suchalgorithmus implementiert, als auch das Lesen und Schreiben von einzelnen Bits und Bytes auf den 1-wire Bus. Mit diesen Low-Level Kommunikationsfunktionen lassen sich bei Verwendung des Modul 00_OWX.pm alle 1-wire Komponenten ansteuern.

In der Standardversion der CUNO bzw. mapleCUx-Firmware ist die Einschränkung enthalten, welche die Erkennung von 1-wire Devices auf 10 beschränkt. Will man dies erhöhen, muss in der Datei board.h die folgende Zeile mit einem Wert > 10 geändert und die Firmware für den mapleCux neu übersetzt und geflasht werden.

#define HAS_ONEWIRE 10 // OneWire Device Buffer, RAM: 10 * 8 Byte

== FHEM ==
Definition in FHEM:

Wenn der mapleCUx in FHEM so definiert ist

define mapleCUL CUL 192.168.69.145:2323 1536

kann der 1-wire Bus wie folgt definiert werden
define MapleOWire OWX mapleCUL

Wenn autocreate angeschaltet ist, werden die angeschlossenen 1-wire Devices nach einem Suchen per
get MapleOWire devices
automatisch angelegt und können danach nach eigenen Wünschen umbenannt werden.

== Literatur ==
*[1] CULFW Commandref http://culfw.de/commandref.html#cmd_O

[[Kategorie:CUL]]
[[Kategorie:1-Wire]]
[[Kategorie:Hardware Mods]]

MapleCUx und 1-wire

2018-01-20T06:03:53Z

PeMue: Schaltplan eingefügt

== Einleitung ==
Der mapleCUx (mapleCUL für USB- bzw. mapleCUN für Netzwerkbetrieb) bietet die Möglichkeit, ähnlich wie der CUNO, über einen 1-wire Busmaster (DS2482) 1-wire Sensoren oder Aktoren zu betreiben.

Hierzu muss das Radio CC2 durch eine entsprechende Schaltung ersetzt werden.

Wie beim CUNO gibt es hierfür zwei Möglichkeiten:
* In der Firmware des mapleCUx ist eine Möglichkeit enthalten, die 1-wire Temperatursensoren DS18S20 in das slowRF-Protokoll zu ''mappen''. 1-wire Temperatursensoren am mapleCUx werden in diesem Fall von FHEM automatisch als HMS-T eingebunden. Andere 1-wire Sensoren oder Aktoren werden von der Firmware hierbei nicht ausgewertet.
* Das Modul 00_OWX.pm kann mit dem mapleCUx kommunizieren und ermöglicht dadurch die Verwendung von allen 1-wire Sensoren bzw. Aktoren am mapleCUx.

In der Standardversion der CUNO-Firmware ist die Einschränkung enthalten, welche die Erkennung von 1-wire Devices durch die Firmware auf 10 beschränkt, s. unten.

== Hardware ==
Manche [https://forum.fhem.de/index.php/topic,60458.msg671078.html#msg671078 Selbstbau Platinen] sehen den entsprechenden 1-wire Busmaster mit Pegelwandler schon auf dem Layout vor.

Ist dies nicht der Fall, muss eine Schaltung wie hier gezeigt

[[File:MapleCUx_1-wire_sch.jpg|600px]]

statt dem Radio CC2 vorgesehen werden.

== Firmware ==
Der 1-wire Bus wird durch die von der Firmware vorgesehenen Kommandos gesteuert. Diese sind in der Beschreibung der CUNO-Firmware nachzulesen, siehe [http://culfw.de/commandref.html#cmd_O [1]]

In dieser Firmware ist sowohl der 1-wire Suchalgorithmus implementiert, als auch das Lesen und Schreiben von einzelnen Bits und Bytes auf den 1-wire Bus. Mit diesen Low-Level Kommunikationsfunktionen lassen sich bei Verwendung des Modul 00_OWX.pm alle 1-wire Komponenten ansteuern.

In der Standardversion der CUNO bzw. mapleCUx-Firmware ist die Einschränkung enthalten, welche die Erkennung von 1-wire Devices auf 10 beschränkt. Will man dies erhöhen, muss in der Datei board.h die folgende Zeile mit einem Wert > 10 geändert und die Firmware für den mapleCux neu übersetzt und geflasht werden.

#define HAS_ONEWIRE 10 // OneWire Device Buffer, RAM: 10 * 8 Byte

== FHEM ==
Definition in FHEM:

Wenn der mapleCUx in FHEM so definiert ist

define mapleCUL CUL 192.168.69.145:2323 1536

kann der 1-wire Bus wie folgt definiert werden
define MapleOWire OWX mapleCUL

Wenn autocreate angeschaltet ist, werden die angeschlossenen 1-wire Devices nach einem Suchen per
get MapleOWire devices
automatisch angelegt und können danach nach eigenen Wünschen umbenannt werden.

== Literatur ==
*[1] CULFW Commandref http://culfw.de/commandref.html#cmd_O

[[Kategorie:CUL]]
[[Kategorie:1-Wire]]
[[Kategorie:Hardware Mods]]

Datei:MapleCUx 1-wire sch.jpg

2018-01-20T06:02:26Z

PeMue: Telekatz' Schaltplan für 1-wire am mapleCUx

Telekatz' Schaltplan für 1-wire am mapleCUx

MapleCUx und 1-wire

2018-01-20T06:01:17Z

PeMue: Neuerstellung basierend auf pah's Artikel über CUNO

== Einleitung ==
Der mapleCUx (mapleCUL für USB- bzw. mapleCUN für Netzwerkbetrieb) bietet die Möglichkeit, ähnlich wie der CUNO, über einen 1-wire Busmaster (DS2482) 1-wire Sensoren oder Aktoren zu betreiben.

Hierzu muss das Radio CC2 durch eine entsprechende Schaltung ersetzt werden.

Wie beim CUNO gibt es hierfür zwei Möglichkeiten:
* In der Firmware des mapleCUx ist eine Möglichkeit enthalten, die 1-wire Temperatursensoren DS18S20 in das slowRF-Protokoll zu ''mappen''. 1-wire Temperatursensoren am mapleCUx werden in diesem Fall von FHEM automatisch als HMS-T eingebunden. Andere 1-wire Sensoren oder Aktoren werden von der Firmware hierbei nicht ausgewertet.
* Das Modul 00_OWX.pm kann mit dem mapleCUx kommunizieren und ermöglicht dadurch die Verwendung von allen 1-wire Sensoren bzw. Aktoren am mapleCUx.

In der Standardversion der CUNO-Firmware ist die Einschränkung enthalten, welche die Erkennung von 1-wire Devices durch die Firmware auf 10 beschränkt, s. unten.

== Hardware ==
Manche [https://forum.fhem.de/index.php/topic,60458.msg671078.html#msg671078 Selbstbau Platinen] sehen den entsprechenden 1-wire Busmaster mit Pegelwandler schon auf dem Layout vor.

Ist dies nicht der Fall, muss eine Schaltung wie hier gezeigt

[[File:CUNO_Mod.jpg|400px]] tbd. noch ändern

statt dem Radio CC2 vorgesehen werden.

== Firmware ==
Der 1-wire Bus wird durch die von der Firmware vorgesehenen Kommandos gesteuert. Diese sind in der Beschreibung der CUNO-Firmware nachzulesen, siehe [http://culfw.de/commandref.html#cmd_O [1]]

In dieser Firmware ist sowohl der 1-wire Suchalgorithmus implementiert, als auch das Lesen und Schreiben von einzelnen Bits und Bytes auf den 1-wire Bus. Mit diesen Low-Level Kommunikationsfunktionen lassen sich bei Verwendung des Modul 00_OWX.pm alle 1-wire Komponenten ansteuern.

In der Standardversion der CUNO bzw. mapleCUx-Firmware ist die Einschränkung enthalten, welche die Erkennung von 1-wire Devices auf 10 beschränkt. Will man dies erhöhen, muss in der Datei board.h die folgende Zeile mit einem Wert > 10 geändert und die Firmware für den mapleCux neu übersetzt und geflasht werden.

#define HAS_ONEWIRE 10 // OneWire Device Buffer, RAM: 10 * 8 Byte

== FHEM ==
Definition in FHEM:

Wenn der mapleCUx in FHEM so definiert ist

define mapleCUL CUL 192.168.69.145:2323 1536

kann der 1-wire Bus wie folgt definiert werden
define MapleOWire OWX mapleCUL

Wenn autocreate angeschaltet ist, werden die angeschlossenen 1-wire Devices nach einem Suchen per
get MapleOWire devices
automatisch angelegt und können danach nach eigenen Wünschen umbenannt werden.

== Literatur ==
*[1] CULFW Commandref http://culfw.de/commandref.html#cmd_O

[[Kategorie:CUL]]
[[Kategorie:1-Wire]]
[[Kategorie:Hardware Mods]]

CUNO und 1-wire

2018-01-19T21:24:00Z

PeMue: Nummern des Literaturverzeichnisses angepasst

== Einleitung ==
Der CUNO ist der Nachfolger des CUN von busware.de. Zusätzlich zu den Eigenschaften des CUN ist beim CUNO der Anschluss von [[1-Wire]]-Komponenten möglich (CUN-O, O für Onewire). Im CUNO ist ein DS2482 Busmaster-Chip verbaut, der über den internen I2C-Bus des CUNO angesteuert wird.

Dafür gibt es zwei Möglichkeiten:

* In der Firmware des CUNO ist eine Möglichkeit enthalten, die 1-Wire-Temperatursensoren DS18S20 in das Homematic-Protokoll zu ''mappen''. 1-Wire Temperatursensoren am CUNO werden dann von FHEM automatisch als HMS-T eingebunden. Andere 1-Wire Sensoren oder Aktoren werden von der Firmware nicht ausgewertet.
* Das Modul 00_OWX.pm (unter contrib/1-Wire) kann mit dem CUNO kommunizieren und ermöglicht dadurch die Verwendung von allen anderen 1-Wire Devices am CUNO. '''Achtung:''' Derzeit (November 2012) erzeugt die Abfrage des CUNO durch das Modul 00_OWX.pm so viel Overhead, dass bei mehr als vier gleichzeitig betriebenen 1-Wire Devices Instabilitäten auftreten können.

In der Standardversion der CUNO-Firmware ist außerdem eine Einschränkung enthalten, die die Erkennung von 1-Wire-Devices durch die Firmware auf 10 beschränkt, s. unten.

Der CUNO ist lt. Hersteller busware "end-of-life" und ist/wird ersetzt durch den weitgehend kompatiblen [http://www.busware.de/tiki-index.php?page=CUNX CUNX], einem CUNO ohne direkt verbaute Onewire-Schnittstelle, dafür mit einem Pigator-Slot, für den es wiederum (u. a.) einen Onewire-Modul gibt.

== Hardware ==
Der CUNO wird leider mit einer 4-poligen RJ10-Anschlussbuchse ausgeliefert (sog. Western-Stecker), die mit keinem sonstigen 1-Wire-System kompatibel ist. Darüber hinaus sind darin die beiden mittleren Adern zusammengelegt, im Anschlussbild aber unterschiedlich benannt (1-Wire bzw. 1-Wire Return). Deshalb muss man entweder

* einen entsprechenden RJ10-Stecker mitbestellen und selbst an ein Kabel ancrimpen,
* ein RJ10-Kabelende z.B. aus einem ausgeschlachteten Telefon verwenden oder
* die RJ10-Anschlussbuchse im CUNO selbst ersetzen. Das ist glücklicherweise leicht möglich, und bei CUNO vor Version 2.4 noch aus einem anderen Grund sinnvoll, siehe unten.

In der nebenstehenden Fotografie ist zu sehen, dass die RJ10-Buchse durch eine 3.5 mm Klinkenbuchse ersetzt wurde, das schwarze und das rote Kabel liefern die Pegel GND und 5 V, sowie das blaue Kabel die 1-Wire-Signale.

[[File:CUNO.JPG|400px|alt=CUNO modifiziert]]

Alternativ kann man auch Molex-Winkelstecker verwenden. Links wurde die RJ45 Buchse abgelötet und durch einen 4-poligen Molex Winkelstecker ersetzt. Vorteil dieser Lösung ist, das (von oben nach unten) 5V, 3,3V, 1-Wire Data und GND sauber heraus geführt sind.
Auf der rechten Seite wurde ein 5 Pol Molex Stecker an die vorhandenen Kontaktpunkte angelötet, um eine 5V Spannungsversorgung mit einem handelsüblichen 5V Netzteil zu ermöglichen. Mit "PWR" ist auf der Platine der 5V Anschluss bezeichnet (Pin 5 des Molex Steckers). An Pin 3 ist GND angeschlossen.

Es empfiehlt sich die beiden Stecker noch mit Heisskleber (o.ä.) im Gehäuse zu fixieren, um zu hohe mechanische Kräfte beim Ein- und Ausstecken von den empfindlichen Kontakten auf der Platine fern zu halten.

[[File:CUNO_Mod.jpg|400px]]

Das Ganze sieht dann am Ende so aus:

[[File:CUNO_Mod2.jpg|400px]]
[[File:CUNO_Mod3.jpg|400px]]

=== Level-Shifter vor Version 2.4 ===
Im CUNO vor Version 2.4 (ausgeliefert bis ca. Anfang Oktober 2012) wird der 1-Wire-Bus durch den CUNO nur mit einer Spannung von 3.3 V versorgt - diese Spannung liegt auch an der RJ10-Buchse an. Ein Signalpegel von 3.3 V auf der Datenleitung des 1-Wire Bus ist aber zu gering, um die angeschlossenen Sensoren parasitär mit Energie zu versorgen - sie müssen deshalb an den unmodifzierten CUNO tatsächlich mit drei Adern (3.3 V, GND und 1-Wire) angeschlossen werden. Im CUNO selbst stehen aber auch 5V zur Verfügung, wenn er durch ein USB-Kabel mit Spannung versorgt wird. Diese lassen sich sehr leicht "abgreifen" und an die (evtl. ersetzte) 1-Wire Anschlussbuchse führen.

Das ist allerdings nur eine "halbe" Lösung, weil der interne Busmaster Chip DS2482 immer noch mit 3,3 V betrieben wird. Dagegen kann ein einfacher [[1-Wire_Pegelwandler|Levelshifter]] helfen (insbesondere beim gleichzeitigen Umbau der Anschlussbuchse !), der auch die Datensignale auf dem Bus nach 5V umsetzt.

== Software ==
Der 1-Wire-Bus wird durch eine Anzahl von Kommandos gesteuert, die in der Beschreibung der CUNO-Firmware nachzulesen sind, siehe [http://culfw.de/commandref.html#cmd_O [1]]

In dieser Firmware ist sowohl der 1-Wire Suchalgorithmus implementiert, als auch das Lesen und Schreiben von einzelnen Bits und Bytes auf den 1-Wire Bus. Mit diesen Low-Level Kommunikationsfunktionen lassen sich bei Verwendung des Modul 00_OWX.pm (siehe contrib/1-Wire) alle 1-Wire Komponenten ansteuern.

In der Firmware ist auch noch eine High-Level Komponente eingebaut, die die Signale von Temperatursensoren (und nur diese !) auf das HomeMatic - System abbildet.

In der Standardversion der CUNO-Firmware ist eine Einschränkung enthalten, die die Erkennung von 1-Wire-Devices auf 10 beschränkt. Will man dies erhöhen, muss in der Datei board.h die folgende Zeile mit einem Wert > 10 geändert und die Firmware neu übersetzt und geflasht werden.

#define HAS_ONEWIRE 10 // OneWire Device Buffer, RAM: 10 * 8 Byte

Allerdings ist eine beliebige Erhöhung nicht möglich, das der CUNO relativ wenig Speicherplatz hat. Berichtet wurde, dass schon ab einem Wert von 30 Schwierigkeiten auftreten, indem die 1-Wire Devices nicht alle erkannt werden.

== Literatur ==
*[1] CULFW Commandref http://culfw.de/commandref.html#cmd_O

[[Kategorie:CUL]]
[[Kategorie:1-Wire]]
[[Kategorie:Hardware Mods]]

HomeMatic Fenster-Drehgriffkontakt Community-Nachbau

2018-01-01T13:09:56Z

PeMue:

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

Die Firmware ist identisch mit dem [https://www.elv.de/homematic-funk-fenster-drehgriffkontakt-1.html Originalen Sensor von ELV] und verhält sich dementsprechend auch gleich.

== Übersicht ==

Die Grundidee zu diesem Sensor wurde durch {{Link2Forum|Topic=71413.0|LinkText=Kawaci im Forum}} geliefert.
Die Umsetzung besteht aus einer Atmega328p Platine mit CC1101 Funkmodul (868 MHz) sowie
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 CR2032 Batteriehalterung auf der Platine durchgesetzt. Somit wird hier nicht näher auf andere Versionen (zwei Platinen zur Erfassung der Fensterstellung) eingegangen.

== Platine ==
'''Schaltplan:'''
[[Datei:FDGK_v1.0_sch.jpg]]

'''Platine v1.0 (Oberseite mit korrigierter Pinbelegung):'''
[[Datei:FDGK_v1.0_top.jpg]]

'''Platine v1.0 (Unterseite, ohne bestücktes Radio):'''
[[Datei:FDGK_v1.0_bot.jpg]]

== Bauteilliste ==
Die Bauteilliste gibt es auf [https://github.com/pa-pa/HMSensor/blob/master/HMSensor-CR2032/Parts.xls GitHub].

== Zusammenlöten der SMD Bauteile ==
Die Bestückung der Platine ist im [https://forum.fhem.de/index.php/topic,71413.msg640858.html#msg640858 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 [https://wiki.fhem.de/wiki/HomeMatic_Fenster-Drehgriffkontakt_Community-Nachbau#Firmware Flashen der Firmware] das Radio (IC2) bzw. den Batteriehalter (BT1) bestücken.
Als Antenne (ANT) wird ein Draht mit 72 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 [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=91780 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 [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=91779 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:

<pre>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</pre>
Setzt die Fuses.

<pre>avrdude -p m328p -P usb -c usbasp -V -U flash:w:bootloader.hex</pre>
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 USB Konfigurations-Adapter|HM-CFG-USB]] unter Linux ([[HomeMatic_Firmware_Update#Firmware_Update_mit_CUL.2FHM-CFG-USB_unter_FHEM|Update mit CUL oder HM-CFG-USB unter Linux]]), mit dem "HomeMatic Firmware Update Tool" unter Windows ([[HomeMatic_Firmware_Update#Firmware_Update_mit_HM-CFG-USB_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:

<pre>./flash-ota -f avr_HM_SEC_RHS_201705271601.eq3 -s RHS0000000</pre>

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

<pre>./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</pre>

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 ==
Den Magneten in den Drehring einbauen und diesen in das Gehäuse einbauen. Die Reedkontakte
Platzieren und mit einem Ohmmeter Messen, ob die Reedkontakte bei der entsprechenden Position
der Magnete schalten. Falls nicht, ggf. die Reedkontakte austauschen (Streuung!) bzw. einen stärkeren Magneten verwenden. Danach mittels Silberdraht bzw. Kupferlackdraht (an den zu
verlötenden Enden den Lack mittels eines Cuttermessers entfernen) die Reedkontakte gemäß
Bild verlöten und die Enden (GND, A0 bzw. A1) durch die vorgesehenen Öffnungen im Gehäuse führen.

''Verlötete Reedkontakte:''
[[Datei:HM_Fenstersensor-pic15.jpg]]

Danach die Antenne in die dafür vorgesehene Bohrung einführen und die Platine platzieren. Darauf achten, dass die Anschlüsse der Reedkontakte durch die dafür vorgesehenen Kontakte auf der Platine geführt werden.

''Einführen der Antenne:''
[[Datei:HM_Fenstersensor-pic17.jpg]]

''Platzierte Platine:''
[[Datei:HM_Fenstersensor-pic16.jpg]]

Nach Verlöten der drei Kontaktpunkte ist der Fensterdrehgriff fertig aufgebaut.

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

<pre>set <Device_Name> regSet msgRhsPosA <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>

== 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 [https://www.thingiverse.com/thing:2354704 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 {{Link2Forum|Topic=70413|LinkText=Service}} an.

== Links ==
*[https://forum.fhem.de/index.php/topic,71413.0.0.html Link zum Foren-Thread]
*[https://github.com/pa-pa/AskSinPP AskSinPP Libary]
*[https://github.com/pa-pa/HMSensor Alles mögliche zu dem Projekt auf Github]
*[https://raw.githubusercontent.com/pa-pa/AskSinPP/master/examples/HM-SEC-RHS/makeota.html makeota.html]
*[[HomeMatic_Type_threeStateSensor|CyclicInfoMsg aktivieren]]
*{{Link2Forum|Topic=70413|LinkText=3D-Druck service}}
*[[HomeMatic_Firmware_Update#Firmware_Update_mit_CUL.2FHM-CFG-USB_unter_FHEM|update-ota]]

[[Kategorie:HomeMatic Components‏‎]]
[[Kategorie:HomeBrew‏‎]]

HomeMatic Fenster-Drehgriffkontakt Community-Nachbau

2018-01-01T13:08:47Z

PeMue: Verlöten der Reedkontakte hinzugefügt

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

Die Firmware ist identisch mit dem [https://www.elv.de/homematic-funk-fenster-drehgriffkontakt-1.html Originalen Sensor von ELV] und verhält sich dementsprechend auch gleich.

== Übersicht ==

Die Grundidee zu diesem Sensor wurde durch {{Link2Forum|Topic=71413.0|LinkText=Kawaci im Forum}} geliefert.
Die Umsetzung besteht aus einer Atmega328p Platine mit CC1101 Funkmodul (868 MHz) sowie
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 CR2032 Batteriehalterung auf der Platine durchgesetzt. Somit wird hier nicht näher auf andere Versionen (zwei Platinen zur Erfassung der Fensterstellung) eingegangen.

== Platine ==
'''Schaltplan:'''
[[Datei:FDGK_v1.0_sch.jpg]]

'''Platine v1.0 (Oberseite mit korrigierter Pinbelegung):'''
[[Datei:FDGK_v1.0_top.jpg]]

'''Platine v1.0 (Unterseite, ohne bestücktes Radio):'''
[[Datei:FDGK_v1.0_bot.jpg]]

== Bauteilliste ==
Die Bauteilliste gibt es auf [https://github.com/pa-pa/HMSensor/blob/master/HMSensor-CR2032/Parts.xls GitHub].

== Zusammenlöten der SMD Bauteile ==
Die Bestückung der Platine ist im [https://forum.fhem.de/index.php/topic,71413.msg640858.html#msg640858 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 [https://wiki.fhem.de/wiki/HomeMatic_Fenster-Drehgriffkontakt_Community-Nachbau#Firmware Flashen der Firmware] das Radio (IC2) bzw. den Batteriehalter (BT1) bestücken.
Als Antenne (ANT) wird ein Draht mit 72 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 [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=91780 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 [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=91779 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:

<pre>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</pre>
Setzt die Fuses.

<pre>avrdude -p m328p -P usb -c usbasp -V -U flash:w:bootloader.hex</pre>
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 USB Konfigurations-Adapter|HM-CFG-USB]] unter Linux ([[HomeMatic_Firmware_Update#Firmware_Update_mit_CUL.2FHM-CFG-USB_unter_FHEM|Update mit CUL oder HM-CFG-USB unter Linux]]), mit dem "HomeMatic Firmware Update Tool" unter Windows ([[HomeMatic_Firmware_Update#Firmware_Update_mit_HM-CFG-USB_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:

<pre>./flash-ota -f avr_HM_SEC_RHS_201705271601.eq3 -s RHS0000000</pre>

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

<pre>./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</pre>

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 ==
Den Magneten in den Drehring einbauen und diesen in das Gehäuse einbauen. Die Reedkontakte
Platzieren und mit einem Ohmmeter Messen, ob die Reedkontakte bei der entsprechenden Position
der Magnete schalten. Falls nicht, ggf. die Reedkontakte austauschen (Streuung!) bzw. einen stärkeren Magneten verwenden. Danach mittels Silberdraht bzw. Kupferlackdraht (an den zu
verlötenden Enden den Lack mittels eines Cuttermessers entfernen) die Reedkontakte gemäß
Bild verlöten und die Enden (GND, A0 bzw. A1) durch die vorgesehenen Öffnungen im Gehäuse führen.

''Verlötete Reedkontakte:''
[[Datei:HM_Fenstersensor-pic15.jpg]]

Danach die Antenne in die dafür vorgesehene Bohrung einführen und die Platine platzieren. Darauf achten, dass die Anschlüsse der Reedkontakte durch die dafür vorgesehenen Kontakte auf der Platine geführt werden.

''Einführen der Antenne:''
[[Datei:HM_Fenstersensor-pic17.jpg]]

Nach Verlöten der drei Kontaktpunkte ist der Fensterdrehgriff fertig aufgebaut.

''Platzierte Platine:''
[[Datei:HM_Fenstersensor-pic16.jpg]]

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

<pre>set <Device_Name> regSet msgRhsPosA <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>

== 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 [https://www.thingiverse.com/thing:2354704 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 {{Link2Forum|Topic=70413|LinkText=Service}} an.

== Links ==
*[https://forum.fhem.de/index.php/topic,71413.0.0.html Link zum Foren-Thread]
*[https://github.com/pa-pa/AskSinPP AskSinPP Libary]
*[https://github.com/pa-pa/HMSensor Alles mögliche zu dem Projekt auf Github]
*[https://raw.githubusercontent.com/pa-pa/AskSinPP/master/examples/HM-SEC-RHS/makeota.html makeota.html]
*[[HomeMatic_Type_threeStateSensor|CyclicInfoMsg aktivieren]]
*{{Link2Forum|Topic=70413|LinkText=3D-Druck service}}
*[[HomeMatic_Firmware_Update#Firmware_Update_mit_CUL.2FHM-CFG-USB_unter_FHEM|update-ota]]

[[Kategorie:HomeMatic Components‏‎]]
[[Kategorie:HomeBrew‏‎]]

Datei:HM Fenstersensor-pic17.jpg

2018-01-01T12:58:01Z

PeMue: Bild Einführen der Antenne

Bild Einführen der Antenne

Datei:HM Fenstersensor-pic16.jpg

2018-01-01T12:57:35Z

PeMue: Bild Einbauen der Platine

Bild Einbauen der Platine

Datei:HM Fenstersensor-pic15.jpg

2018-01-01T12:56:57Z

PeMue: Bild Verlöten der Reed Kontakte

Bild Verlöten der Reed Kontakte

HomeMatic Fenster-Drehgriffkontakt Community-Nachbau

2018-01-01T12:55:53Z

PeMue:

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

Die Firmware ist identisch mit dem [https://www.elv.de/homematic-funk-fenster-drehgriffkontakt-1.html Originalen Sensor von ELV] und verhält sich dementsprechend auch gleich.

== Übersicht ==

Die Grundidee zu diesem Sensor wurde durch {{Link2Forum|Topic=71413.0|LinkText=Kawaci im Forum}} geliefert.
Die Umsetzung besteht aus einer Atmega328p Platine mit CC1101 Funkmodul (868 MHz) sowie
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 CR2032 Batteriehalterung auf der Platine durchgesetzt. Somit wird hier nicht näher auf andere Versionen (zwei Platinen zur Erfassung der Fensterstellung) eingegangen.

== Platine ==
'''Schaltplan:'''
[[Datei:FDGK_v1.0_sch.jpg]]

'''Platine v1.0 (Oberseite mit korrigierter Pinbelegung):'''
[[Datei:FDGK_v1.0_top.jpg]]

'''Platine v1.0 (Unterseite, ohne bestücktes Radio):'''
[[Datei:FDGK_v1.0_bot.jpg]]

== Bauteilliste ==
Die Bauteilliste gibt es auf [https://github.com/pa-pa/HMSensor/blob/master/HMSensor-CR2032/Parts.xls GitHub].

== Zusammenlöten der SMD Bauteile ==
Die Bestückung der Platine ist im [https://forum.fhem.de/index.php/topic,71413.msg640858.html#msg640858 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 [https://wiki.fhem.de/wiki/HomeMatic_Fenster-Drehgriffkontakt_Community-Nachbau#Firmware 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 [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=91780 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 [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=91779 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:

<pre>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</pre>
Setzt die Fuses.

<pre>avrdude -p m328p -P usb -c usbasp -V -U flash:w:bootloader.hex</pre>
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 USB Konfigurations-Adapter|HM-CFG-USB]] unter Linux ([[HomeMatic_Firmware_Update#Firmware_Update_mit_CUL.2FHM-CFG-USB_unter_FHEM|Update mit CUL oder HM-CFG-USB unter Linux]]), mit dem "HomeMatic Firmware Update Tool" unter Windows ([[HomeMatic_Firmware_Update#Firmware_Update_mit_HM-CFG-USB_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:

<pre>./flash-ota -f avr_HM_SEC_RHS_201705271601.eq3 -s RHS0000000</pre>

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

<pre>./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</pre>

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:

<pre>set <Device_Name> regSet msgRhsPosA <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>

== 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 [https://www.thingiverse.com/thing:2354704 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 {{Link2Forum|Topic=70413|LinkText=Service}} an.

== Links ==
*[https://forum.fhem.de/index.php/topic,71413.0.0.html Link zum Foren-Thread]
*[https://github.com/pa-pa/AskSinPP AskSinPP Libary]
*[https://github.com/pa-pa/HMSensor Alles mögliche zu dem Projekt auf Github]
*[https://raw.githubusercontent.com/pa-pa/AskSinPP/master/examples/HM-SEC-RHS/makeota.html makeota.html]
*[[HomeMatic_Type_threeStateSensor|CyclicInfoMsg aktivieren]]
*{{Link2Forum|Topic=70413|LinkText=3D-Druck service}}
*[[HomeMatic_Firmware_Update#Firmware_Update_mit_CUL.2FHM-CFG-USB_unter_FHEM|update-ota]]

[[Kategorie:HomeMatic Components‏‎]]
[[Kategorie:HomeBrew‏‎]]

HM-Sec-RHS Funk-Fenster-Drehgriffkontakt

2018-01-01T12:40:17Z

PeMue: Bild eingefügt

{{Infobox Hardware
|Bild=HM-Sec-RHS.jpg
|Bildbeschreibung=Fenster Drehgriffkontakt
|HWProtocol=HomeMatic
|HWType=[[HomeMatic Type threeStateSensor|threeStateSensor]]
|HWCategory=HomeMatic
|HWComm=868MHz
|HWChannels=1
|HWVoltage=3V
|HWPowerConsumption=ca. 2 Jahre
|HWPoweredBy=2x1,5V LR44
|HWSize=120*32*16 mm
|HWDeviceFHEM=[[CUL_HM]]
|HWManufacturer=ELV / eQ-3
}}
Der [[HM-Sec-RHS Funk-Fenster-Drehgriffkontakt]] ist ein [[HomeMatic Type threeStateSensor|threeStateSensor]] zur Überwachung eines Fenster-Drehgriffs.

== Features ==
Überwachung des Verriegelungszustandes einer Terrassentür oder eines Fensters anhand der Stellung des Drehgriffs.

== Batterien ==
Es werden zwei Stück Knopfzellen vom Typ LR44 (je nach Hersteller auch L1154, AG13, V13GA, A76 oder GPA76 genannt) benötigt. Diese sind Bestandteil der Lieferung, jedoch sollte man vor Installation / Inbetriebnahme die Spannung der Knopfzellen überprüfen. Diese sollte über 1,5 V liegen. Da Batterien eine begrenzte Lagerfähigkeit haben, kann es durchaus vorkommen, dass diese schon überlagert sind, also nicht mehr die für einen längeren Betrieb erforderliche Spannung haben bzw. halten können oder bereits nach ein paar Tagen leer (low) sind.

== Hinweise zum Betrieb mit FHEM ==
Es gelten die generell für den [[HomeMatic Type threeStateSensor|Typ threeStateSensor]] zusammengestellten Informationen.

=== Sendeverhalten anpassen ===
Leider sind die Drehgriffkontakte im Auslieferungszustand so eingestellt, dass bei Änderung des Fenstergriffes sofort(!) der Zustand übermittelt wird. Probleme bereitet es meist dann, wenn man recht zügig vom geschlossenen Zustand über "offen" in den angeklappten Zustand wechselt. Dann wird sowohl der "offen" als auch sofort danach der "Klapp" Zustand gesendet. Im Zusammenhang mit der unglücklichen Antennenlage im Gehäuse entstehen hier meist Kommunikationsprobleme. Um dies abzuändern, kann man dem Sensor "beibringen", nach einer Zustandsänderung mit einer Verzögerung zu senden. Dies erfolgt im folgenden Beispiel mit drei Sekunden:

:<code> set <device> regSet eventDlyTime 3 </code>
:<code> set <device> getConfig </code>

Es ist jeweils nach einem abgesetzten Befehl die Anlerntaste am Sensor zu drücken, um jeden Befehl einzeln zu übermitteln.

== Probleme beim Anbau ==

Der Sensor passt unter "Standard" Fensterdrehgriffe, Bei stärkerem Vierkant oder größeren Befestigungen (Sicherheitsdrehgriffe) kann man vorsichtig modifizieren. Aber Vorsicht! Der Detektor ist rein mechanisch.

[[Datei:HM-SEC-RHS-Detektor.JPG|200px|thumb|left|Sensor offen und schlecht modifiziert]]

== Links ==
* [http://www.techwriter.de/beispiel/funkeig1.htm Sendeeigenschaften verbessern] (ohne Gewähr, aber dringend empfohlen!)
* Montage- und Bedienungsanleitung {{DocLink|elv|/service/manuals/75643_HM_Sec_RHS_GE_V1_0.pdf Anleitung (PDF)}}

[[Kategorie:HomeMatic Components]]
[[Kategorie:Zustandssensoren]]

Datei:HM-Sec-RHS.jpg

2018-01-01T12:39:17Z

PeMue: Bild vom originalen HM-Sec-RHS Fensterdrehgriffkontakt.

Bild vom originalen HM-Sec-RHS Fensterdrehgriffkontakt.

HomeMatic Fenster-Drehgriffkontakt Community-Nachbau

2017-12-30T13:51:37Z

PeMue: Zweiplatinenlösung rausgeworfen

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

Die Firmware ist identisch mit dem [https://www.elv.de/homematic-funk-fenster-drehgriffkontakt-1.html Originalen Sensor von ELV] und verhält sich dementsprechend auch gleich.

== Übersicht ==

Die Grundidee zu diesem Sensor wurde durch {{Link2Forum|Topic=71413.0|LinkText=Kawaci im Forum}} geliefert.
Die Umsetzung besteht aus einer Atmega328p Platine mit CC1101 Funkmodul (868 MHz) sowie
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.

== Platine ==
'''Schaltplan:'''
[[Datei:FDGK_v1.0_sch.jpg]]

'''Platine v1.0 (Oberseite mit korrigierter Pinbelegung):'''
[[Datei:FDGK_v1.0_top.jpg]]

'''Platine v1.0 (Unterseite, ohne bestücktes Radio):'''
[[Datei:FDGK_v1.0_bot.jpg]]

== Bauteilliste ==
Die Bauteilliste gibt es auf [https://github.com/pa-pa/HMSensor/blob/master/HMSensor-CR2032/Parts.xls GitHub].

== Zusammenlöten der SMD Bauteile ==
Die Bestückung der Platine ist im [https://forum.fhem.de/index.php/topic,71413.msg640858.html#msg640858 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 [https://wiki.fhem.de/wiki/HomeMatic_Fenster-Drehgriffkontakt_Community-Nachbau#Firmware 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 [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=91780 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 [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=91779 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:

<pre>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</pre>
Setzt die Fuses.

<pre>avrdude -p m328p -P usb -c usbasp -V -U flash:w:bootloader.hex</pre>
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 USB Konfigurations-Adapter|HM-CFG-USB]] unter Linux ([[HomeMatic_Firmware_Update#Firmware_Update_mit_CUL.2FHM-CFG-USB_unter_FHEM|Update mit CUL oder HM-CFG-USB unter Linux]]), mit dem "HomeMatic Firmware Update Tool" unter Windows ([[HomeMatic_Firmware_Update#Firmware_Update_mit_HM-CFG-USB_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:

<pre>./flash-ota -f avr_HM_SEC_RHS_201705271601.eq3 -s RHS0000000</pre>

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

<pre>./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</pre>

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:

<pre>set <Device_Name> regSet msgRhsPosA <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>

== 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 [https://www.thingiverse.com/thing:2354704 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 {{Link2Forum|Topic=70413|LinkText=Service}} an.

== Links ==
*[https://forum.fhem.de/index.php/topic,71413.0.0.html Link zum Foren-Thread]
*[https://github.com/pa-pa/AskSinPP AskSinPP Libary]
*[https://github.com/pa-pa/HMSensor Alles mögliche zu dem Projekt auf Github]
*[https://raw.githubusercontent.com/pa-pa/AskSinPP/master/examples/HM-SEC-RHS/makeota.html makeota.html]
*[[HomeMatic_Type_threeStateSensor|CyclicInfoMsg aktivieren]]
*{{Link2Forum|Topic=70413|LinkText=3D-Druck service}}
*[[HomeMatic_Firmware_Update#Firmware_Update_mit_CUL.2FHM-CFG-USB_unter_FHEM|update-ota]]

[[Kategorie:HomeMatic Components‏‎]]
[[Kategorie:HomeBrew‏‎]]

HomeMatic Fenster-Drehgriffkontakt Community-Nachbau

2017-12-21T20:37:30Z

PeMue:

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

Die Firmware ist identisch mit dem [https://www.elv.de/homematic-funk-fenster-drehgriffkontakt-1.html Originalen Sensor von ELV] und verhält sich dementsprechend auch gleich.

== Übersicht ==

Die Grundidee zu diesem Sensor wurde durch {{Link2Forum|Topic=71413.0|LinkText=Kawaci im Forum}} geliefert.
Die Umsetzung besteht aus einer Atmega328p Platine mit CC1101 Funkmodul (868 MHz) sowie
einer auf der [https://github.com/pa-pa/AskSinPP 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:'''
[[Datei:FDGK_v1.0_sch.jpg]]

'''Platine v1.0 (Oberseite mit korrigierter Pinbelegung):'''
[[Datei:FDGK_v1.0_top.jpg]]

'''Platine v1.0 (Unterseite, ohne bestücktes Radio):'''
[[Datei:FDGK_v1.0_bot.jpg]]

== Bauteilliste ==
Die Bauteilliste gibt es auf [https://github.com/pa-pa/HMSensor/blob/master/HMSensor-CR2032/Parts.xls GitHub].

== Zusammenlöten der SMD Bauteile ==
Die Bestückung der Platine ist im [https://forum.fhem.de/index.php/topic,71413.msg640858.html#msg640858 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 [https://wiki.fhem.de/wiki/HomeMatic_Fenster-Drehgriffkontakt_Community-Nachbau#Firmware 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 [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=91780 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 Baterien 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 [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=91779 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:

<pre>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</pre>
Setzt die Fuses.

<pre>avrdude -p m328p -P usb -c usbasp -V -U flash:w:bootloader.hex</pre>
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 USB Konfigurations-Adapter|HM-CFG-USB]] unter Linux ([[HomeMatic_Firmware_Update#Firmware_Update_mit_CUL.2FHM-CFG-USB_unter_FHEM|Update mit CUL oder HM-CFG-USB unter Linux]]), mit dem "HomeMatic Firmware Update Tool" unter Windows ([[HomeMatic_Firmware_Update#Firmware_Update_mit_HM-CFG-USB_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:

<pre>./flash-ota -f avr_HM_SEC_RHS_201705271601.eq3 -s RHS0000000</pre>

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

<pre>./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</pre>

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 -> CLOSED

A0 geschlossen - PosB -> OPEN

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:

<pre>set <Device_Name> regSet msgRhsPosA <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>

== 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 [https://www.thingiverse.com/thing:2354704 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 {{Link2Forum|Topic=70413|LinkText=Service}} an.

== Links ==
*[https://forum.fhem.de/index.php/topic,71413.0.0.html Link zum Foren-Thread]
*[https://github.com/pa-pa/AskSinPP AskSinPP Libary]
*[https://github.com/pa-pa/HMSensor Alles mögliche zu dem Projekt auf Github]
*[https://raw.githubusercontent.com/pa-pa/AskSinPP/master/examples/HM-SEC-RHS/makeota.html makeota.html]
*[[HomeMatic_Type_threeStateSensor|CyclicInfoMsg aktivieren]]
*{{Link2Forum|Topic=70413|LinkText=3D-Druck service}}
*[[HomeMatic_Firmware_Update#Firmware_Update_mit_CUL.2FHM-CFG-USB_unter_FHEM|update-ota]]

[[Kategorie:HomeMatic Components‏‎]]
[[Kategorie:HomeBrew‏‎]]

HomeMatic Fenster-Drehgriffkontakt Community-Nachbau

2017-12-21T20:36:50Z

PeMue:

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

Die Firmware ist identisch mit dem [https://www.elv.de/homematic-funk-fenster-drehgriffkontakt-1.html Originalen Sensor von ELV] und verhält sich dementsprechend auch gleich.

== Übersicht ==

Die Grundidee zu diesem Sensor wurde durch {{Link2Forum|Topic=71413.0|LinkText=Kawaci im Forum}} geliefert.
Die Umsetzung besteht aus einer Atmega328p Platine mit CC1101 Funkmodul (868 MHz) sowie
einer auf der [https://github.com/pa-pa/AskSinPP 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:'''
[[Datei:FDGK_v1.0_sch.jpg]]

'''Platine v1.0 (Oberseite mit korrigierter Pinbelegung):'''
[[Datei:FDGK_v1.0_top.jpg]]

'''Platine v1.0 (Unterseite, ohne bestücktes Radio):'''
[[Datei:FDGK_v1.0_bot.jpg]]

== Bauteilliste ==
Die Bauteilliste gibt es auf [https://github.com/pa-pa/HMSensor/blob/master/HMSensor-CR2032/Parts.xls GitHub].

== Zusammenlöten der SMD Bauteile ==
Die Bestückung der Platine ist im [https://forum.fhem.de/index.php/topic,71413.msg640858.html#msg640858 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 [https://wiki.fhem.de/wiki/HomeMatic_Fenster-Drehgriffkontakt_Community-Nachbau#Firmware 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 Bootloaders ===

Dafür wird, mit Hilfe der [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=91780 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 Baterien 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 [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=91779 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:

<pre>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</pre>
Setzt die Fuses.

<pre>avrdude -p m328p -P usb -c usbasp -V -U flash:w:bootloader.hex</pre>
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 (Over The Air) Update ===
Hierzu wird flash-ota benötigt.

Flash-ota funktioniert aktuell nur mit [[CUL]]/[[COC]] oder [[HM-CFG-USB USB Konfigurations-Adapter|HM-CFG-USB]] unter Linux ([[HomeMatic_Firmware_Update#Firmware_Update_mit_CUL.2FHM-CFG-USB_unter_FHEM|Update mit CUL oder HM-CFG-USB unter Linux]]), mit dem "HomeMatic Firmware Update Tool" unter Windows ([[HomeMatic_Firmware_Update#Firmware_Update_mit_HM-CFG-USB_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:

<pre>./flash-ota -f avr_HM_SEC_RHS_201705271601.eq3 -s RHS0000000</pre>

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

<pre>./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</pre>

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 -> CLOSED

A0 geschlossen - PosB -> OPEN

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:

<pre>set <Device_Name> regSet msgRhsPosA <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>

== 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 [https://www.thingiverse.com/thing:2354704 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 {{Link2Forum|Topic=70413|LinkText=Service}} an.

== Links ==
*[https://forum.fhem.de/index.php/topic,71413.0.0.html Link zum Foren-Thread]
*[https://github.com/pa-pa/AskSinPP AskSinPP Libary]
*[https://github.com/pa-pa/HMSensor Alles mögliche zu dem Projekt auf Github]
*[https://raw.githubusercontent.com/pa-pa/AskSinPP/master/examples/HM-SEC-RHS/makeota.html makeota.html]
*[[HomeMatic_Type_threeStateSensor|CyclicInfoMsg aktivieren]]
*{{Link2Forum|Topic=70413|LinkText=3D-Druck service}}
*[[HomeMatic_Firmware_Update#Firmware_Update_mit_CUL.2FHM-CFG-USB_unter_FHEM|update-ota]]

[[Kategorie:HomeMatic Components‏‎]]
[[Kategorie:HomeBrew‏‎]]

HomeMatic Fenster-Drehgriffkontakt Community-Nachbau

2017-12-21T19:47:36Z

PeMue: Korrekturen

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

Die Firmware ist identisch mit dem [https://www.elv.de/homematic-funk-fenster-drehgriffkontakt-1.html Originalen Sensor von ELV] und verhält sich dementsprechend auch gleich.

== Übersicht ==

Die Grundidee zu diesem Sensor wurde durch {{Link2Forum|Topic=71413.0|LinkText=Kawaci im Forum}} geliefert.
Die Umsetzung besteht aus einer Atmega328p Platine mit CC1101 Funkmodul (868 MHz) sowie
einer auf der [https://github.com/pa-pa/AskSinPP 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:'''
[[Datei:FDGK_v1.0_sch.jpg]]

'''Platine v1.0 (Oberseite mit korrigierter Pinbelegung):'''
[[Datei:FDGK_v1.0_top.jpg]]

'''Platine v1.0 (Unterseite, ohne bestücktes Radio):'''
[[Datei:FDGK_v1.0_bot.jpg]]

== Bauteilliste ==
Die Bauteilliste gibt es auf [https://github.com/pa-pa/HMSensor/blob/master/HMSensor-CR2032/Parts.xls GitHub].

== Zusammenlöten der SMD Bauteile ==
Die Bestückung der Platine ist im [https://forum.fhem.de/index.php/topic,71413.msg640858.html#msg640858 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 [https://wiki.fhem.de/wiki/HomeMatic_Fenster-Drehgriffkontakt_Community-Nachbau#Firmware 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 Bootloaders ===

Dafür wird, mit Hilfe der [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=91780 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 Baterien 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 [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=91779 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:

<pre>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</pre>
Setzt die Fuses.

<pre>avrdude -p m328p -P usb -c usbasp -V -U flash:w:bootloader.hex</pre>
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 (Over The Air) Update ===
Hierzu wird flash-ota benötigt.

Flash-ota funktioniert aktuell nur mit [[CUL]]/[[COC]] oder [[HM-CFG-USB USB Konfigurations-Adapter|HM-CFG-USB]] unter Linux ([[HomeMatic_Firmware_Update#Firmware_Update_mit_CUL.2FHM-CFG-USB_unter_FHEM|Update mit CUL oder HM-CFG-USB unter Linux]]), mit dem "HomeMatic Firmware Update Tool" unter Windows ([[HomeMatic_Firmware_Update#Firmware_Update_mit_HM-CFG-USB_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:

<pre>./flash-ota -f avr_HM_SEC_RHS_201705271601.eq3 -s RHS0000000</pre>

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

<pre>./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</pre>

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 -> CLOSED

A0 geschlossen - PosB -> OPEN

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:

<pre>set <Device_Name> regSet msgRhsPosA <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>

== 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 [https://www.thingiverse.com/thing:2354704 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 {{Link2Forum|Topic=70413|LinkText=Service}} an.

== Links ==
*[https://forum.fhem.de/index.php/topic,71413.0.0.html Link zum Foren-Thread]
*[https://github.com/pa-pa/AskSinPP AskSinPP Libary]
*[https://github.com/pa-pa/HMSensor Alles mögliche zu dem Projekt auf Github]
*[https://raw.githubusercontent.com/pa-pa/AskSinPP/master/examples/HM-SEC-RHS/makeota.html makeota.html]
*[[HomeMatic_Type_threeStateSensor|CyclicInfoMsg aktivieren]]
*{{Link2Forum|Topic=70413|LinkText=3D-Druck service}}
*[[HomeMatic_Firmware_Update#Firmware_Update_mit_CUL.2FHM-CFG-USB_unter_FHEM|update-ota]]

[[Kategorie:HomeMatic Components‏‎]]
[[Kategorie:HomeBrew‏‎]]

HomeMatic Fenster-Drehgriffkontakt Community-Nachbau

2017-12-21T18:59:14Z

PeMue: Aktualisierung des Erzeugen des Bootloaders

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

Die Firmware ist identisch mit dem [https://www.elv.de/homematic-funk-fenster-drehgriffkontakt-1.html Originalen Sensor von ELV] und verhält sich dementsprechend auch gleich.

== Übersicht ==

Die Grundidee zu diesem Sensor wurde durch {{Link2Forum|Topic=71413.0|LinkText=Kawaci im Forum}} geliefert.
Die Umsetzung besteht aus einer Atmega328p Platine mit CC1101 Funkmodul (868 MHz) sowie
einer auf der [https://github.com/pa-pa/AskSinPP 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:'''
[[Datei:FDGK_v1.0_sch.jpg]]

'''Platine v1.0 (Oberseite mit korrigierter Pinbelegung):'''
[[Datei:FDGK_v1.0_top.jpg]]

'''Platine v1.0 (Unterseite, ohne bestücktes Radio):'''
[[Datei:FDGK_v1.0_bot.jpg]]

== Bauteilliste ==
Die Bauteilliste gibt es auf [https://github.com/pa-pa/HMSensor/blob/master/HMSensor-CR2032/Parts.xls GitHub].

== Zusammenlöten der SMD Bauteile ==
Die Bestückung der Platine ist im [https://forum.fhem.de/index.php/topic,71413.msg640858.html#msg640858 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 [https://wiki.fhem.de/wiki/HomeMatic_Fenster-Drehgriffkontakt_Community-Nachbau#Firmware 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 Bootloaders ===

Dafür wird, mit Hilfe der [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=91780 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 Baterien 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 [https://forum.fhem.de/index.php?action=dlattach;topic=71413.0;attach=91779 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 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:

<pre>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</pre>
Setzt die Fuses.

<pre>avrdude -p m328p -P usb -c usbasp -V -U flash:w:bootloader.hex</pre>
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 (Over The Air) Update ===
Hierzu wird flash-ota benötigt.

Flash-ota funktioniert aktuell nur mit [[CUL]]/[[COC]] oder [[HM-CFG-USB USB Konfigurations-Adapter|HM-CFG-USB]] unter Linux ([[HomeMatic_Firmware_Update#Firmware_Update_mit_CUL.2FHM-CFG-USB_unter_FHEM|Update mit CUL oder HM-CFG-USB unter Linux]]), mit dem "HomeMatic Firmware Update Tool" unter Windows ([[HomeMatic_Firmware_Update#Firmware_Update_mit_HM-CFG-USB_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:

<pre>./flash-ota -f avr_HM_SEC_RHS_201705271601.eq3 -s RHS0000000</pre>

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

<pre>./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</pre>

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 -> CLOSED

A0 geschlossen - PosB -> OPEN

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:

<pre>set <Device_Name> regSet msgRhsPosA <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>

== 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 [https://www.thingiverse.com/thing:2354704 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 {{Link2Forum|Topic=70413|LinkText=Service}} an.

== Links ==
*[https://forum.fhem.de/index.php/topic,71413.0.0.html Link zum Foren-Thread]
*[https://github.com/pa-pa/AskSinPP AskSinPP Libary]
*[https://github.com/pa-pa/HMSensor Alles mögliche zu dem Projekt auf Github]
*[https://raw.githubusercontent.com/pa-pa/AskSinPP/master/examples/HM-SEC-RHS/makeota.html makeota.html]
*[[HomeMatic_Type_threeStateSensor|CyclicInfoMsg aktivieren]]
*{{Link2Forum|Topic=70413|LinkText=3D-Druck service}}
*[[HomeMatic_Firmware_Update#Firmware_Update_mit_CUL.2FHM-CFG-USB_unter_FHEM|update-ota]]

[[Kategorie:HomeMatic Components‏‎]]
[[Kategorie:HomeBrew‏‎]]

HomeMatic Fenster-Drehgriffkontakt Community-Nachbau

2017-12-21T10:45:50Z

PeMue: Bestückung aktualisiert

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

Die Firmware ist identisch mit dem [https://www.elv.de/homematic-funk-fenster-drehgriffkontakt-1.html Originalen Sensor von ELV] und verhält sich dementsprechend auch gleich.

== Übersicht ==

Die Grundidee zu diesem Sensor wurde durch {{Link2Forum|Topic=71413.0|LinkText=Kawaci im Forum}} geliefert.
Die Umsetzung besteht aus einer Atmega328p Platine mit CC1101 Funkmodul (868 MHz) sowie
einer auf der [https://github.com/pa-pa/AskSinPP 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:'''
[[Datei:FDGK_v1.0_sch.jpg]]

'''Platine v1.0 (Oberseite mit korrigierter Pinbelegung):'''
[[Datei:FDGK_v1.0_top.jpg]]

'''Platine v1.0 (Unterseite, ohne bestücktes Radio):'''
[[Datei:FDGK_v1.0_bot.jpg]]

== Bauteilliste ==
Die Bauteilliste gibt es auf [https://github.com/pa-pa/HMSensor/blob/master/HMSensor-CR2032/Parts.xls GitHub].

== Zusammenlöten der SMD Bauteile ==
Die Bestückung der Platine ist im [https://forum.fhem.de/index.php/topic,71413.msg640858.html#msg640858 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 [https://wiki.fhem.de/wiki/HomeMatic_Fenster-Drehgriffkontakt_Community-Nachbau#Firmware 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 Bootloaders ===

Dafür wird, mit Hilfe der [https://raw.githubusercontent.com/pa-pa/AskSinPP/master/examples/HM-SEC-RHS/makeota.html makeota.html] der Bootloader mit den benötigten Daten gefüllt und anschließend generiert.

Die makeota.html muss dazu in einem Browser deiner Wahl aufgerufen werden.

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 sollten auf keinen Fall anschließend auf zwei Geräten identisch sein. Somit ist es sinnvoll, sich die eingegebenen Daten aufzuschreiben oder Screenshots zu machen.

Nun muss noch dem Bootloader bekannt gemacht werden, welche Batterien du mit deinem FDGK nutzt. Dies wählst du über die dropdown Liste "Power Presets" aus.

Dabei bedeutet:

*No StepUp = CR2032 Batterie
*StepUp single AA = eine AA Batterie und StepUp
*StepUp two AAA = zwei AAA Baterien und StepUP

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

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 geflashed.
Zum Laden des Bootloaders, sowie der Software werden die Arduino SDK bzw. avrdude und die erwähnte makeota.html benötigt.

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

<pre>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</pre>
Setzt die Fuses.

<pre>avrdude -p m328p -P usb -c usbasp -V -U flash:w:bootloader.hex</pre>
lädt den eigentlichen Bootloader. Dabei ist zu achten, dass "bootloader.hex" die bootloaderdatei 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 (Over The Air) Update ===
Hierzu wird flash-ota benötigt.

Flash-ota funktioniert aktuell nur mit [[CUL]]/[[COC]] oder [[HM-CFG-USB USB Konfigurations-Adapter|HM-CFG-USB]] unter Linux ([[HomeMatic_Firmware_Update#Firmware_Update_mit_CUL.2FHM-CFG-USB_unter_FHEM|Update mit CUL oder HM-CFG-USB unter Linux]]), mit dem "HomeMatic Firmware Update Tool" unter Windows ([[HomeMatic_Firmware_Update#Firmware_Update_mit_HM-CFG-USB_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:

<pre>./flash-ota -f avr_HM_SEC_RHS_201705271601.eq3 -s RHS0000000</pre>

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

<pre>./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</pre>

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 -> CLOSED

A0 geschlossen - PosB -> OPEN

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:

<pre>set <Device_Name> regSet msgRhsPosA <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>

== 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 [https://www.thingiverse.com/thing:2354704 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 {{Link2Forum|Topic=70413|LinkText=Service}} an.

== Links ==
*[https://forum.fhem.de/index.php/topic,71413.0.0.html Link zum Foren-Thread]
*[https://github.com/pa-pa/AskSinPP AskSinPP Libary]
*[https://github.com/pa-pa/HMSensor Alles mögliche zu dem Projekt auf Github]
*[https://raw.githubusercontent.com/pa-pa/AskSinPP/master/examples/HM-SEC-RHS/makeota.html makeota.html]
*[[HomeMatic_Type_threeStateSensor|CyclicInfoMsg aktivieren]]
*{{Link2Forum|Topic=70413|LinkText=3D-Druck service}}
*[[HomeMatic_Firmware_Update#Firmware_Update_mit_CUL.2FHM-CFG-USB_unter_FHEM|update-ota]]

[[Kategorie:HomeMatic Components‏‎]]
[[Kategorie:HomeBrew‏‎]]

HomeMatic Fenster-Drehgriffkontakt Community-Nachbau

2017-12-21T10:18:23Z

PeMue:

HomeMatic Fenster-Drehgriffkontakt Community-Nachbau

2017-12-21T10:16:15Z

PeMue:

Datei:FDGK v1.0 top.jpg

2017-12-20T21:00:35Z

PeMue: PeMue lud eine neue Version von Datei:FDGK v1.0 top.jpg hoch

Bild Fensterdrehgriffkontakt v1.0, Oberseite, Bild PeMue

Datei:FDGK v1.0 top.jpg

2017-12-20T20:52:39Z

PeMue: PeMue lud eine neue Version von Datei:FDGK v1.0 top.jpg hoch

Bild Fensterdrehgriffkontakt v1.0, Oberseite, Bild PeMue

Datei:FDGK v1.0 bot.jpg

2017-12-20T20:51:24Z

PeMue: PeMue lud eine neue Version von Datei:FDGK v1.0 bot.jpg hoch

Bild Fensterdrehgriffkontakt v1.0, Unterseite, Bild PeMue