HM-MOD-RPI-PCB HomeMatic Funkmodul für Raspberry Pi: Unterschied zwischen den Versionen

Aus FHEMWiki
Zur Navigation springen Zur Suche springen
KKeine Bearbeitungszusammenfassung
(→‎Anbindung mit ESP8266: Tasmota eingefügt)
 
(113 dazwischenliegende Versionen von 9 Benutzern werden nicht angezeigt)
Zeile 14: Zeile 14:
|HWManufacturer=ELV / eQ-3  
|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.


Das [[HM-MOD-RPI-PCB HomeMatic Funkmodul für Raspberry Pi]] ist eine Zusatzplatine, 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.  


Wird häufig als Bausatz (zwei vorbereitete Steckerleisten sind an die Hauptplatine anzulöten) verkauft: ab € 20.
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 Verbindung 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.


Mitunter auch fertig montiert ab etwa € 30 zu finden.
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 ein {{Link2Forum|Topic=56606}}, in dem PeMue eine eigene Platinenversion (Schaltplan, Stückliste und vieles mehr) vorstellt.


== Features ==
=== Platine 1 -PCB-Modul ===
(Noch zu ergänzen)
[[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. Dabei ist zu beachten, dass sich nicht zwei Module die GPIO teilen können. Steckt schon ein Modul im Raspberry Pi, muss der Anschluss per USB, in einem zweiten Raspberry Pi oder per WLAN gewählt werden.
<br clear="all">


== Hinweise zum Betrieb mit FHEM ==
=== Platine 2 -UART-Modul ===
Juni 2016: Beginn der Entwicklung eines FHEM-Moduls (HMUARTLGW) für dieses Interface, beschrieben im Forum unter dem Titel {{Link2Forum|Topic=54511|LinkText=Modul für HomeMatic UART-Modul (RPi) und HomeMatic LAN Gateway}}. Dieses Modul unterstützt gleichzeitig auch das "neue" [[HM-LGW-O-TW-W-EU Funk-LAN Gateway|Funk-LAN Gateway HM-LGW-O-TW-W-EU]].
[[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!


Juli 2016: [[HMUARTLGW]] wird über FHEM [[update]] verteilt, damit ist dieses Funkmodul offiziell unterstützt.
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].


=== Vorbereitung serielle Schnittstelle unter Jessie / Stretch ===
=== Zusammenbau und Verwendung ===
Diese Beschreibung gilt für Jessie Version 27.05.2016.
Man sollte die Antenne aus dem Gehäuse schauen lassen oder gar eine externe Antenne anbringen. Idealerweise sollte das Ende der Drahtantenne mit einem Klecks Heißkleber oder ähnlichem isoliert werden; eine Berührung vor allem mit dem Innenleben des Raspberry Pi muss vermieden werden!
Die Grundlagen findet man hier: [[Raspberry Pi 3: GPIO-Port Module und Bluetooth]]


Die Datei /boot/config.txt um diese Zeile ergänzen
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 (Bild rechts). Damit schließen die kleineren Pi-Gehäuse nicht richtig: das Gesamtmodul klemmt am Deckel.


<pre>enable_uart=1</pre>
Man kann ohne weiteres das UART-Modul unter dem PCB-Modul montieren (Bild links), damit wird die Gesamthöhe geringer und es passt problemlos in jedes Gehäuse. Bitte vorher die genaue Situation prüfen: Es kann sein, dass damit Kühlkörper oder ähnliches seitens der Pi-Platine stören.


Beim PI 3 zusätzlich diese Zeilen ergänzen, bitte entweder core_freq oder force_turbo setzen.  
Man kann auch das PCB Modul kürzen und das UART Modul mit kurzen Drähten in einer Ebene verbinden (kein Bild).


<pre>dtoverlay=pi3-miniuart-bt
Bitte auf die richtige Lage (Bilder) beim Zusammenbau und auf Lötzinnbrücken achten. Da die Anschlüsse durchkontaktiert sind, bewirkt eine falsche Positionierung des UART-Moduls im schlimmsten Fall einen Kurzschluss. Man erkennt auf beiden Bildern, dass beim UART-Modul die Pinleiste einmal auf der einen und ein andermal auf der anderen Seite des Moduls angelötet werden muss!
core_freq=250
#Alternativ kann auch dieser Eintrag gesetzt werden
force_turbo=1</pre>
In der Datei /boot/cmdline.txt diesen Eintrag löschen:
<pre>console=serial0,115200 </pre>


Den Dienst serial-getty in der System Kommandozeile mit folgendem Befehl deaktivieren
<br clear="all">
== Verwendung ==
Das Modul muss, um verwendet zu werden, mit einer Hardware verbunden werden. Hier kommen mehrere Möglichkeiten in Betracht, die jeweils vor und Nachteile aufweisen. Sie werden jetzt nacheinander präsentiert. 


<pre>systemctl disable serial-getty@ttyAMA0.service</pre>
=== Anbindung an die GPIO im Raspberry ===
==== Installation ====
Man kann das  HM-MOD-RPI-PCB Modul direkt in die GPIOs eines Raspberry stecken. Das hat den Vorteil, dass das Gerät (mehr oder weniger) sofort betriebsbereit ist, aber den Nachteil, dass am RPi vorher mehrere Installationen zu erfolgen haben.  


Die '''<big>notwendige Konfiguration der Schnittstelle</big>''' 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]]
* Die automatische Erkennung der USB Geräte muss deaktiviert werden:
::<code>attr initialUsbCheck disable 1</code>
: Nach dem Setzen des Attributes muss die Änderung gespeichert werden (siehe [[save]])!


Der Benutzer fhem muss Mitglied in der Gruppe dialout sein! Bitte kontrollieren.
=== Anbindung über das Netzwerk===
<pre>groups fhem </pre>
Wenn das  HM-MOD-RPI-PCB Modul an einen RPi angeschlossen ist, kann man dieses Modul danach auch im Netzwerk verfügbar machen. Dieser Pi kann beliebige Aufgaben erledigen, nur das HM-MOD-RPI-PCB Modul selbst darf nicht lokal verwendet werden. Somit kann man bei einem Umzug des FHEM Servers das HM-MOD-RPI-PCB Modul einfach weiterhin nutzen oder einen vorhandene RaspberryPi zum "HMLAN" umbauen. Sollte man aber ausschließlich Zugriff auf das HM-MOD-RPI-PCB Modul im Netzwerk benötigen, empfiehlt sich auch aus Kostengründen (Stromverbrauch) eine andere Lösung.


Das System unbedingt neu starten!
Achtung! Auch über das Netzwerk darf immer '''nur eine Instanz auf das freigegebene Modul zugreifen'''!


=== Vorbereitung serielle Schnittstelle unter Wheezy===
Die Konfiguration der Schnittstelle ist in jedem Fall gleich: [[Raspberry Pi#Verwendung UART für Zusatzmodule|Verwendung UART für Zusatzmodule]].  
Diese Beschreibung gilt für Wheezy Version Stand 26.07.2016.


Die Datei /boot/config.txt um diese Zeile ergänzen
Die [[HM-MOD-RPI-PCB HomeMatic Funkmodul für Raspberry Pi#Definition in FHEM 2|Definition in FHEM]] erfolgt dann mit dem Parameter <code>uart:// .</code>


<pre>enable_uart=1</pre>
===== Variante mit ser2net =====
[https://forum.fhem.de/index.php/topic,124384.0.html '''Achtung!''' Mit der Version 4 hat sich die Konfiguration geändert!]


In der Datei /boot/cmdline.txt diesen Eintrag löschen:
Diese Installation auf dem Pi mit dem  HM-MOD-RPI-PCB Modul bitte im Kontext <code>sudo su</code> ausführen.  


<pre>console=ttyAMA0,115200</pre>
Bis zur ser2net '''Version 3'''


Die Datei sollte dann den folgenden Inhalt aufweisen:
<pre>apt-get install ser2net
echo "4000:raw:0:/dev/ttyAMA0:115200 NONE 1STOPBIT 8DATABITS HANGUP_WHEN_DONE" >> /etc/ser2net.conf
# Den Dienst neu starten
systemctl restart ser2net</pre>Ab der ser2net '''Version 4''' erfolgt die Konfiguration im anderen Format /etc/ser2net.yaml.  [https://man.archlinux.org/man/community/ser2net/ser2net.yaml.5.en manpage]<syntaxhighlight lang="bash">
cp /etc/ser2net.yaml /etc/ser2net.yaml.sav
cat <<EOI > /etc/ser2net.yaml
%YAML 1.1
---
# HM_MOD-RPI-PCB
connection: &con01
    accepter: tcp,4000
    connector: serialdev,
              /dev/ttyAMA0,
              115200n81,local
EOI
</syntaxhighlight>Zur Kommunikation zwischen FHEM und ser2net auf einem anderen Gerät im Netzwerk kann (mindestens ab Debian Bullseye) zusätzlich die Option "NOBREAK" im Connector (siehe [https://www.mankier.com/8/ser2net manpage]) erforderlich sein.


<pre>dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait</pre>
In der Service unit müssen Abhängigkeiten eingefügt werden, sonst startet der Dienst nach einem System reboot nicht:


Den Dienst serial-getty deaktivieren
<code>systemctl edit --full ser2net</code> siehe auch  [[Fhem.service (systemd unit file)|Wiki (systemd unit file)]]<syntaxhighlight lang="bash">
[Unit]
Description=Serial port to network proxy
Documentation=man:ser2net(8)
After=network-online.target
Wants=network-online.target


in der Datei /etc/inittab wie folgt die Zeile (ziemlich am Ende) mit einer # auskommentieren
[Service]
EnvironmentFile=-/etc/default/ser2net
ExecStart=/usr/sbin/ser2net -n -c $CONFFILE -P /run/ser2net.pid
Type=exec
Restart=on-failure


<pre># T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100</pre>
[Install]
Mit folgendem Befehlen überprüfen, dass kein getty auf der Schnittstelle läuft
WantedBy=multi-user.target
<pre>ps -A |grep getty
</syntaxhighlight>
cat /etc/inittab</pre>
{{Randnotiz|RNText=Tipp: Sollte der HM-MOD-RPI-PCB nach der Einrichtung immer wieder den Status zwischen init und disconnect wechseln, alle aufgeführten Punkte erneut kontrollieren! reboot nicht vergessen! In ganz hartnäckigen Fällen von der Stromversorgung trennen!}}


Der Benutzer fhem muss Mitglied in der Gruppe dialout sein! Bitte prüfen:
===== Variante mit socat =====
<pre>groups fhem</pre>
Installation auf dem Pi wo das Modul steckt bitte so installieren.
:<code>sudo apt-get install socat</code>
Zum Test kann man socat in der Kommandozeile starten
:<code>sudo socat TCP4-LISTEN:2000,fork,reuseaddr /dev/ttyAMA0,raw,echo=0,b115200 </code>


'''Das System unbedingt neu starten!'''
Für den dauerhaften Betrieb muss der Start von socat automatisch erfolgen.
Auf einem Debian Jessie mit systemd legt man z.B. einen Dienst durch folgende Datei an:
/etc/systemd/system/hmlangw.service
<syntaxhighlight lang="Text">
[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
</syntaxhighlight>
Dann kann mit
:<code>sudo systemctl enable hmlangw </code>
der Service zum Autostart konfiguriert werden.


=== Kontrolle ===
=== Anbindung mit USB-Adapter ===
Berechtigungen der Schnittstelle kontrollieren
{{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].}}
<pre>ls -l /dev/ttyAMA0</pre> liefert die Ausgabe unter Jessie / Stretch
[[Datei:PL2102 Modul.png|200px|thumb|right|Mod zur Herstellung der korrekten Spannung]]
<pre>crw-rw---- 1 root dialout 204, 64 Jul 27 23:39 /dev/ttyAMA0</pre>
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! Der Vorteil ist hier, dass hohe Geschwindigkeiten möglich sind und nicht wie bei WLAN Latenzen auftreten, aber es muss eben ein USB-Anschluss verfügbar sein.
bzw. unter wheezy
<pre>crw-rw---T 1 root dialout 204, 64 Aug  9 18:07 /dev/ttyAMA0</pre>
Nur unter Jessie und auf einem Pi3


Bitte kontrollieren, dass serial1 auf ttyS0 verlinkt ist. Andernfalls muss die Datei /lib/systemd/system/hciuart.service angepasst werden. Dort müsste ttyAMA0 durch ttyS0 ersetzt werden. Dies ist aber seit jessie Version Herbst 2016 nicht mehr nötig.
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
<pre>ls -l /dev/serial1
lrwxrwxrwx 1 root root 5 Jan 11 20:00 /dev/serial1 -> ttyS0</pre>


Bei Stretch wird serial0 auf ttyS0 verlinkt:
'''Verschaltung'''
<pre>
  3.3V <-> 3.3V
ls -l /dev/serial0
  GND  <-> GND
lrwxrwxrwx 1 root root 7 Okt 26 12:39 /dev/serial0 -> ttyAMA0</pre>
  Rx  <-> Tx
  Tx  <-> Rx


=== Definition in FHEM===
=== Anbindung mit ESP8266 ===
<pre>define myHmUART HMUARTLGW /dev/ttyAMA0
Hier ist der Vorteil, dass vor Ort nur WLAN verfügbar sein muss. Nachteilig kann sich auswirken, dass WLAN hohe Latenzen aufweisen kann und daher manchmal der Eindruck entsteht, das Modul sei gerade abwesend.
attr myHmUART hmId xxxxxx</pre>


=== Verwendung AES in FHEM===
Zum Anschluss kann ein beliebiger ESP8266 verwendet werden. Mit einigen Versionen (Beispiele im Forum: {{Link2Forum|Topic=102141|Message=956606|LinkText=ESP07}} sowie {{Link2Forum|Topic=102141|LinkText=Wemos mini pro}}) ist eine Anbindung anscheinend nicht oder nur schwer möglich - wobei dies auch an nicht funktionsfähigen Clonen liegen kann oder beim Wemos daran, dass dort die USB-Schnittstelle mit Tx/Rx nicht kalkulierbare Störungen auslöst. Ein Problem bei Wlan Anbindung kann die vergrößerte roundtrip delay darstellen.
Das Modul beherrscht AES.
 
Für weitere Informationen gibt es einen separaten Wiki Eintrag [[AES Encryption]]
Es gibt verschiedene ESP Firmware-Möglichkeiten: 
* [https://github.com/jeelabs/esp-link '''ESPLink'''] ist eine sehr stabile und nicht mehr aktiv weiterentwickelte Firmware, die die serielle Schnittstelle direkt mit WLAN verbindet und ohne größere Schwierigkeiten eingerichtet werden kann und funktioniert. Sie nutzt die serielle Schnittstelle des ESP. Allerdings erlaubt ESPLink nicht die Nutzung anderer GPIOs, so können beispielsweise keine anderen Sensoren mit angeschlossen bzw. ausgelesen werden. Verwendet man ESP-Link, so muss neben der WLAN Konfiguration nur das Pin Assignment konfiguriert werden. Alle Pins auf disabled stellen.
* [https://www.letscontrolit.com/wiki/index.php/ESPEasy '''ESPEasy'''] (neue Version: ESPMega) wird beständig weiterentwickelt und gestattet es, weitere Sensoren anzuschließen und deren Werte auszulesen. Insbesondere kann man mit ESPEasy auch zwei weitere Pins nutzen, um eine serielle Schnittstelle zu simulieren (so genannter ''serieller Server''). Man spricht auch von einer ''swapped'' Schnittstelle. Die {{Link2Forum|Topic=62651|LinkText=Platine von amunra}} nutzt eine solche Schnittstelle.  Allerdings gibt es mit einigen ESP8266-Geräten Schwierigkeiten, diese serielle Schnittstelle zu nutzen. So ist etwa ein serieller Server mit neueren ESP-Versionen anscheinend nicht lauffähig (siehe dazu {{Link2Forum|Topic=75422|LinkText=diesen Thread}}). Es gibt eine ältere Firmware-Version von PeMue, die  unmittelbar funktionsfähig scheint, siehe dazu {{Link2Forum|Topic=86592|LinkText=diesen Forenthread}}.
* '''Tasmota''' kann mit der Komponente TCP_Bridge ebenfalls das Modul ansteuern. Hier im [https://forum.fhem.de/index.php/topic,125817.msg1233521.html Forum] gibt es dazu eine ausführliche Anleitung und den Erfahrungsbericht. 
[[Datei:Esp-pin Konfiguration HMUART.png|200px|mini|esp-link Pin-Konfiguration beim swapped Server]]
Bei der seriellen Schnittstelle (da die ESP auf 3,3V laufen, sind keine Spannungsteiler erforderlich) findet man die Verschaltung unten. Bei der ''swapped'' Schnittstelle wird auf die digitalen Pins D7/D8 zurückgegriffen (siehe auch unten). Die letztere Verschaltung erfordert eine entsprechende Implementierung der Schnittstelle in der Firmware selbst, die beispielsweise bei ESPEasy unter Umständen nicht gegeben ist oder selbst kompiliert werden muss. 
 
'''Verschaltung bei einem WeMos D1 mini'''
  (UART) <-> (Wemos swapped) <-> (Wemos seriell)
  3.3V  <-> 3.3V            <-> 3.3V
  GND  <-> GND            <-> GND
  Rx    <-> D8              <-> Tx (D10 oder Tx)
  Tx    <-> D7              <-> Rx (D9 oder Rx)
 
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], siehe auch [https://www.esp8266.com/viewtopic.php?f=32&t=18669 diese Grafik der Pins des Wemos]
 
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"}}.
 
[[Datei:HM-CFG-WLAN-k.jpeg|thumb|left|200px|Anschluß an Wemos]]
Auf dem linken Foto ist der Anschluss des gesamten Moduls (Rastermaß 2,54mm statt 2mm!) an den Wemos zur Wifi-Einbindung abgebildet.
 
=== 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. Nähere Hinweise sind in den Artikeln [[Serial TTL to Ethernet Module]] sowie [[1W-IF-ETH]] zu finden.
 
Die Module melden sich per DHCP<ref>jedenfalls neuere firmware-Versionen</ref> im Netzwerk an, die Konfiguration erfolgt je nach Variante über ein Web-Interface, ein Windows-Tool oder eine Management-Software.
 
=== 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 ==
Die Funktion in FHEM hängt ab von der verwendeten Hardware. Die eigentliche Funktion wird mit dem Modul [[HMUARTLGW]] hergestellt. Alle dortigen Hinweise zur Konfiguration sind zu beachten! Man sollte sich auch mit den Grundlagen der [[HomeMatic]] Kommunikation vertraut machen.
 
Je nach physischem Anschluss erfolgt eine Anbindung in FHEM in unterschiedlicher Weise. Folgende Beispiele sind '''abweichend''' von der '''<big>[[HMUARTLGW#Define|Standardkonfiguration]]!</big>'''
 
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/ttyUSBx
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:
*ser2net 4000 (bzw. entsprechend gewählter Einstellung)
*socat 2000 (bzw. entsprechend gewählter Einstellung)
*esp-link 23
*MapleCUN 2324 bzw. 2325
*USR-TCP232-T2 entspr. Konfiguration.


=== Logbeispiel ===
=== Logbeispiel ===
Zeile 120: Zeile 212:
   2016.10.06 17:11:17 3: HMUARTLGW myHmUART currently running Co_CPU_App
   2016.10.06 17:11:17 3: HMUARTLGW myHmUART currently running Co_CPU_App


=== Firmware Update HM-MOD-RPI-PCB ===
=== Verwendung AES in FHEM===
Das Modul beherrscht AES.
Für weitere Informationen gibt es einen separaten Wiki Eintrag [[AES Encryption]]


Die Module werden mit einer Firmware 1.2.1 ausgeliefert. Dies Firmware ist nicht für einen stabilen Betrieb geeignet!
=== Firmware Update des UART-Moduls mit FHEM ===
Firmware 1.4.1 ist die minimal lauffähige Version!
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
Bitte den Befehl zum download inklusive der Anführungszeichen in die FHEM Kommandozeile eingeben!
# 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
'''Firmware herunterladen'''
sudo cp coprocessor_update.eq3 /opt/fhem/FHEM/firmware/
* Version 1.4.1
<syntaxhighlight lang="text">"wget -qO ./FHEM/firmware/coprocessor_update.eq3 https://raw.githubusercontent.com/eq-3/occu/28045df83480122f90ab92f7c6e625f9bf3b61aa/firmware/HM-MOD-UART/coprocessor_update.eq3"</syntaxhighlight>
* Alternativ die aktuellste (für den Betrieb mit dem Modul HMUARTLGW '''NICHT''' empfohlen)
<syntaxhighlight lang="text">"wget -qO ./FHEM/firmware/coprocessor_update.eq3 https://raw.githubusercontent.com/eq-3/occu/HEAD/firmware/HM-MOD-UART/coprocessor_update.eq3"</syntaxhighlight>
(Firmware neuer als 1.4.1 dient nur bei CCU-Klonen mit Mischbetrieb BidCOs, klassisch HomeMatic und HomeMatic IP, siehe {{Link2Forum|Topic=70752|LinkText=diesen Forenthread}}).


3. Flashen der neuen Firmware aus FHEM
'''Flashen der neuen Firmware'''
set myHmUART updateCoPro /opt/fhem/FHEM/firmware/coprocessor_update.eq3


=== Alternative Methode zum Firmware Update ohne FHEM ===
Erstmal überzeugen das die Firmware da ist: Z.B. mit dem Befehl in der FHEM Kommandozeile, die Ausgabe erfolgt in der Weboberfläche!
<syntaxhighlight lang="text">{qx(ls -lha ./FHEM/firmware)}</syntaxhighlight>
Wenn alles ok - Befehl zum flashen ausführen:
<syntaxhighlight lang="text">set myHmUART updateCoPro /opt/fhem/FHEM/firmware/coprocessor_update.eq3</syntaxhighlight>


=== 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])
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])


Zeile 153: Zeile 249:
   ./flash-hmmoduart -U /dev/ttyAMA0 coprocessor_update.eq3
   ./flash-hmmoduart -U /dev/ttyAMA0 coprocessor_update.eq3


{{Randnotiz|RNText=Tipp: Dieser Abschnitt ist noch in Bearbeitung und unter Umständen noch nicht "perfekt". Bitte gesamten Artikel durchlesen und beachten!
=== Bekannte Probleme ===
'''Weitere Varianten''' der Anbindung siehe Links zum Forum }}
* 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.''
== Alternative Anbindung ==
* Beim Raspberry 4 gibt es eine Einstellung zur Temperaturkontrolle, die muss deaktiviert werden. Siehe diesen {{Link2Forum|Topic=123223|Message=1178032|LinkText=Beitrag im Forum}}.
Im Forum gibt es mehr Informationen zu diesen Adaptern, zum Beispiel unter https://forum.fhem.de/index.php/topic,62651.0.html oder https://forum.fhem.de/index.php/topic,79559.0.html.
* Bei Verwendung mit einem USR TCP232-T2 Wandler kann es in der Default-Einstellung des Wandlers dazu kommen, dass obsolete Kommunikation gepuffert und nach einem Wiederverbinden unnötig an FHEM gesendet wird (siehe {{Link2Forum|Topic=123948|LinkText=dieses Foren-Thema}}). Im FHEM-Log gibt es in diesem Fall die Meldung "HMUART failed to enter App!"  Abhilfe schafft das Aktivieren der Option "Buffer Data before connected" unter "Expand Function" im WebUI des TCP-232.
 
=== USB Anbindung - USB-seriell Adapter + RPI Modul = Homematic USB Adapter ===
Unbedingt einen USB seriell Adapter mit 3,3 Volt Pegel nehmen! z.B. CP2102
 
'''Verschaltung'''
  3,3  -> 3,3
  gnd  -> gnd
  RX  -> TX
  TX  -> RX
 
Definition in FHEM
 
  define USB_HmUART HMUARTLGW /dev/ttyUSB0
 
=== WLAN Anbindung - ESP8266 + RPI Modul = Homematic WLAN Adapter ===
Es kann ein beliebiger ESP8266 mit ESP-Link Software verwendet werden.
 
'''Verschaltung'''
  (UART) -> (Wemos)
  3,3  -> 3,3
  Gnd  -> Gnd
  RX    -> D8
  TX    -> D7
 
Einstellung ESP-Link
 
Neben der WLAN Konfiguration muss nur das Pin assignment konfiguriert werden. Alle Pins auf disabled und UART pins auf swapped stellen.
 
Definition in FHEM
 
  define WLAN_HmUART HMUARTLGW uart://<IP-Adresse>:23
 
=== Remoteanbindung - Pi + RPI Modul = LAN Modul ===
 
 
Die Remoteanbindung ist kein Sharing des Moduls! Es darf an dem Remote Pi (wo das Modul sitzt) '''keinerlei''' Zugriff auf das Modul seitens einer etwaigen lokalen FHEM Instanz erfolgen.
 
'''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 Pi zu Pi zur Schnittstelle zum RPI Modul.
 
Lokaler Pi: FHEM -> uart://IP:Port -> Netzwerk -> socat listener -> socat serial -> RPI Modul auf Remote Pi
Remote  Pi: RPI Modul -> serial -> socat -> Netzwerk -> uart://IP:Port ->  FHEM auf lokalem Pi
 
== 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 ==
== Links ==
Zeile 243: Zeile 260:
* [http://www.elv.de/homematic-funkmodul-fuer-raspberry-pi-bausatz.html Produktseite] bei ELV
* [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}}
* {{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 #27 sind Detailbeschreibung in der PDF im Anhang
* {{Link2Forum|Topic=56606|LinkText=Forenthread}} Hardware Thread mit vielen Varianten der Anbindung. In Post #26 gibt es die Detailbeschreibung in der angehängten PDF.
:<hr />
<references />


[[Kategorie:HomeMatic Components]]
[[Kategorie:HomeMatic Components]]

Aktuelle Version vom 2. September 2022, 12:18 Uhr

HM-MOD-RPI-PCB HomeMatic Funkmodul für Raspberry Pi
HomeMatic Funkmodul für Raspberry Pi
Allgemein
Protokoll HomeMatic
Typ Gateway
Kategorie HomeMatic
Technische Details
Kommunikation 868,3/869,525 MHz
Kanäle n/a
Betriebsspannung 1,8–3,6 V DC
Leistungsaufnahme 50 mA max.
Versorgung RasPi
Abmessungen 19x41x14mm
Sonstiges
Modulname HMUARTLGW
Hersteller 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.
Info green.pngNeben 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 Beitrag zu finden.

Mit dieser Platine in Verbindung 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 ein Thema, in dem PeMue eine eigene Platinenversion (Schaltplan, Stückliste und vieles mehr) vorstellt.

Platine 1 -PCB-Modul

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. Dabei ist zu beachten, dass sich nicht zwei Module die GPIO teilen können. Steckt schon ein Modul im Raspberry Pi, muss der Anschluss per USB, in einem zweiten Raspberry Pi oder per WLAN gewählt werden.

Platine 2 -UART-Modul

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 Link.

Zusammenbau und Verwendung

Man sollte die Antenne aus dem Gehäuse schauen lassen oder gar eine externe Antenne anbringen. Idealerweise sollte das Ende der Drahtantenne mit einem Klecks Heißkleber oder ähnlichem isoliert werden; eine Berührung vor allem mit dem Innenleben des Raspberry Pi muss vermieden werden!

Beide Platinen können zusammengebaut oder auch nur das UART Modul getrennt verwendet werden.

Montage des Moduls HM-MOD-UART unten
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 (Bild rechts). Damit schließen die kleineren Pi-Gehäuse nicht richtig: das Gesamtmodul klemmt am Deckel.

Man kann ohne weiteres das UART-Modul unter dem PCB-Modul montieren (Bild links), damit wird die Gesamthöhe geringer und es passt problemlos in jedes Gehäuse. Bitte vorher die genaue Situation prüfen: Es kann sein, dass damit Kühlkörper oder ähnliches seitens der Pi-Platine stören.

Man kann auch das PCB Modul kürzen und das UART Modul mit kurzen Drähten in einer Ebene verbinden (kein Bild).

Bitte auf die richtige Lage (Bilder) beim Zusammenbau und auf Lötzinnbrücken achten. Da die Anschlüsse durchkontaktiert sind, bewirkt eine falsche Positionierung des UART-Moduls im schlimmsten Fall einen Kurzschluss. Man erkennt auf beiden Bildern, dass beim UART-Modul die Pinleiste einmal auf der einen und ein andermal auf der anderen Seite des Moduls angelötet werden muss!


Verwendung

Das Modul muss, um verwendet zu werden, mit einer Hardware verbunden werden. Hier kommen mehrere Möglichkeiten in Betracht, die jeweils vor und Nachteile aufweisen. Sie werden jetzt nacheinander präsentiert.

Anbindung an die GPIO im Raspberry

Installation

Man kann das HM-MOD-RPI-PCB Modul direkt in die GPIOs eines Raspberry stecken. Das hat den Vorteil, dass das Gerät (mehr oder weniger) sofort betriebsbereit ist, aber den Nachteil, dass am RPi vorher mehrere Installationen zu erfolgen haben.

Die notwendige Konfiguration der Schnittstelle ist hier beschrieben: Verwendung UART für Zusatzmodule.

  • Der Einsatz in FHEM für CUL_HM erfolgt mit dem Modul HMUARTLGW
  • Die automatische Erkennung der USB Geräte muss deaktiviert werden:
attr initialUsbCheck disable 1
Nach dem Setzen des Attributes muss die Änderung gespeichert werden (siehe save)!

Anbindung über das Netzwerk

Wenn das HM-MOD-RPI-PCB Modul an einen RPi angeschlossen ist, kann man dieses Modul danach auch im Netzwerk verfügbar machen. Dieser Pi kann beliebige Aufgaben erledigen, nur das HM-MOD-RPI-PCB Modul selbst darf nicht lokal verwendet werden. Somit kann man bei einem Umzug des FHEM Servers das HM-MOD-RPI-PCB Modul einfach weiterhin nutzen oder einen vorhandene RaspberryPi zum "HMLAN" umbauen. Sollte man aber ausschließlich Zugriff auf das HM-MOD-RPI-PCB Modul im Netzwerk benötigen, empfiehlt sich auch aus Kostengründen (Stromverbrauch) eine andere Lösung.

Achtung! Auch über das Netzwerk darf immer nur eine Instanz auf das freigegebene Modul zugreifen!

Die Konfiguration der Schnittstelle ist in jedem Fall gleich: Verwendung UART für Zusatzmodule.

Die Definition in FHEM erfolgt dann mit dem Parameter uart:// .

Variante mit ser2net

Achtung! Mit der Version 4 hat sich die Konfiguration geändert!

Diese Installation auf dem Pi mit dem HM-MOD-RPI-PCB Modul bitte im Kontext sudo su ausführen.

Bis zur ser2net Version 3

apt-get install ser2net
echo "4000:raw:0:/dev/ttyAMA0:115200 NONE 1STOPBIT 8DATABITS HANGUP_WHEN_DONE" >> /etc/ser2net.conf
# Den Dienst neu starten
systemctl restart ser2net

Ab der ser2net Version 4 erfolgt die Konfiguration im anderen Format /etc/ser2net.yaml. manpage

cp /etc/ser2net.yaml /etc/ser2net.yaml.sav
cat <<EOI > /etc/ser2net.yaml
%YAML 1.1
---
# HM_MOD-RPI-PCB
connection: &con01
    accepter: tcp,4000
    connector: serialdev,
              /dev/ttyAMA0,
              115200n81,local
EOI

Zur Kommunikation zwischen FHEM und ser2net auf einem anderen Gerät im Netzwerk kann (mindestens ab Debian Bullseye) zusätzlich die Option "NOBREAK" im Connector (siehe manpage) erforderlich sein.

In der Service unit müssen Abhängigkeiten eingefügt werden, sonst startet der Dienst nach einem System reboot nicht:

systemctl edit --full ser2net siehe auch Wiki (systemd unit file)

[Unit]
Description=Serial port to network proxy
Documentation=man:ser2net(8)
After=network-online.target
Wants=network-online.target

[Service]
EnvironmentFile=-/etc/default/ser2net
ExecStart=/usr/sbin/ser2net -n -c $CONFFILE -P /run/ser2net.pid
Type=exec
Restart=on-failure

[Install]
WantedBy=multi-user.target
Variante mit socat

Installation auf dem Pi wo das Modul steckt bitte so installieren.

sudo apt-get install socat

Zum Test kann man socat in der Kommandozeile starten

sudo socat TCP4-LISTEN:2000,fork,reuseaddr /dev/ttyAMA0,raw,echo=0,b115200

Für den dauerhaften Betrieb muss der Start von socat automatisch erfolgen. Auf einem Debian Jessie mit systemd legt man z.B. einen Dienst durch 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.

Anbindung mit USB-Adapter

X mark.svgBitte 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: Beitrag von PBudmark vom 08.07.2017.
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! Der Vorteil ist hier, dass hohe Geschwindigkeiten möglich sind und nicht wie bei WLAN Latenzen auftreten, aber es muss eben ein USB-Anschluss verfügbar sein.

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

Hier ist der Vorteil, dass vor Ort nur WLAN verfügbar sein muss. Nachteilig kann sich auswirken, dass WLAN hohe Latenzen aufweisen kann und daher manchmal der Eindruck entsteht, das Modul sei gerade abwesend.

Zum Anschluss kann ein beliebiger ESP8266 verwendet werden. Mit einigen Versionen (Beispiele im Forum: ESP07 sowie Wemos mini pro) ist eine Anbindung anscheinend nicht oder nur schwer möglich - wobei dies auch an nicht funktionsfähigen Clonen liegen kann oder beim Wemos daran, dass dort die USB-Schnittstelle mit Tx/Rx nicht kalkulierbare Störungen auslöst. Ein Problem bei Wlan Anbindung kann die vergrößerte roundtrip delay darstellen.

Es gibt verschiedene ESP Firmware-Möglichkeiten:

  • ESPLink ist eine sehr stabile und nicht mehr aktiv weiterentwickelte Firmware, die die serielle Schnittstelle direkt mit WLAN verbindet und ohne größere Schwierigkeiten eingerichtet werden kann und funktioniert. Sie nutzt die serielle Schnittstelle des ESP. Allerdings erlaubt ESPLink nicht die Nutzung anderer GPIOs, so können beispielsweise keine anderen Sensoren mit angeschlossen bzw. ausgelesen werden. Verwendet man ESP-Link, so muss neben der WLAN Konfiguration nur das Pin Assignment konfiguriert werden. Alle Pins auf disabled stellen.
  • ESPEasy (neue Version: ESPMega) wird beständig weiterentwickelt und gestattet es, weitere Sensoren anzuschließen und deren Werte auszulesen. Insbesondere kann man mit ESPEasy auch zwei weitere Pins nutzen, um eine serielle Schnittstelle zu simulieren (so genannter serieller Server). Man spricht auch von einer swapped Schnittstelle. Die Platine von amunra nutzt eine solche Schnittstelle. Allerdings gibt es mit einigen ESP8266-Geräten Schwierigkeiten, diese serielle Schnittstelle zu nutzen. So ist etwa ein serieller Server mit neueren ESP-Versionen anscheinend nicht lauffähig (siehe dazu diesen Thread). Es gibt eine ältere Firmware-Version von PeMue, die unmittelbar funktionsfähig scheint, siehe dazu diesen Forenthread.
  • Tasmota kann mit der Komponente TCP_Bridge ebenfalls das Modul ansteuern. Hier im Forum gibt es dazu eine ausführliche Anleitung und den Erfahrungsbericht.
esp-link Pin-Konfiguration beim swapped Server

Bei der seriellen Schnittstelle (da die ESP auf 3,3V laufen, sind keine Spannungsteiler erforderlich) findet man die Verschaltung unten. Bei der swapped Schnittstelle wird auf die digitalen Pins D7/D8 zurückgegriffen (siehe auch unten). Die letztere Verschaltung erfordert eine entsprechende Implementierung der Schnittstelle in der Firmware selbst, die beispielsweise bei ESPEasy unter Umständen nicht gegeben ist oder selbst kompiliert werden muss.

Verschaltung bei einem WeMos D1 mini

 (UART) <-> (Wemos swapped) <-> (Wemos seriell)
  3.3V  <-> 3.3V            <-> 3.3V
  GND   <-> GND             <-> GND
  Rx    <-> D8              <-> Tx (D10 oder Tx)
  Tx    <-> D7              <-> Rx (D9 oder Rx)
  

Es gibt eine ausführliche Erläuterung für die Software unter [1], siehe auch diese Grafik der Pins des Wemos

Im Forum gibt es mehr Informationen zu diesen Adaptern, zum Beispiel "(amunra)-Platine für HM-MOD-UART-RPI..." oder "3. Sammelbestellung - Homematic WLAN Gateway".

Anschluß an Wemos

Auf dem linken Foto ist der Anschluss des gesamten Moduls (Rastermaß 2,54mm statt 2mm!) an den Wemos zur Wifi-Einbindung abgebildet.

Betrieb mit einem LAN-TTL-Wandler

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. Nähere Hinweise sind in den Artikeln Serial TTL to Ethernet Module sowie 1W-IF-ETH zu finden.

Die Module melden sich per DHCP[1] im Netzwerk an, die Konfiguration erfolgt je nach Variante über ein Web-Interface, ein Windows-Tool oder eine Management-Software.

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

Die Funktion in FHEM hängt ab von der verwendeten Hardware. Die eigentliche Funktion wird mit dem Modul HMUARTLGW hergestellt. Alle dortigen Hinweise zur Konfiguration sind zu beachten! Man sollte sich auch mit den Grundlagen der HomeMatic Kommunikation vertraut machen.

Je nach physischem Anschluss erfolgt eine Anbindung in FHEM in unterschiedlicher Weise. Folgende Beispiele sind abweichend von der Standardkonfiguration!

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/ttyUSBx

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:

  • ser2net 4000 (bzw. entsprechend gewählter Einstellung)
  • socat 2000 (bzw. entsprechend gewählter Einstellung)
  • 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.

Bitte den Befehl zum download inklusive der Anführungszeichen in die FHEM Kommandozeile eingeben!

Firmware herunterladen

  • Version 1.4.1
"wget -qO ./FHEM/firmware/coprocessor_update.eq3 https://raw.githubusercontent.com/eq-3/occu/28045df83480122f90ab92f7c6e625f9bf3b61aa/firmware/HM-MOD-UART/coprocessor_update.eq3"
  • Alternativ die aktuellste (für den Betrieb mit dem Modul HMUARTLGW NICHT empfohlen)
"wget -qO ./FHEM/firmware/coprocessor_update.eq3 https://raw.githubusercontent.com/eq-3/occu/HEAD/firmware/HM-MOD-UART/coprocessor_update.eq3"

(Firmware neuer als 1.4.1 dient nur bei CCU-Klonen mit Mischbetrieb BidCOs, klassisch HomeMatic und HomeMatic IP, siehe diesen Forenthread).

Flashen der neuen Firmware

Erstmal überzeugen das die Firmware da ist: Z.B. mit dem Befehl in der FHEM Kommandozeile, die Ausgabe erfolgt in der Weboberfläche!

{qx(ls -lha ./FHEM/firmware)}

Wenn alles ok - Befehl zum flashen ausführen:

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: 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 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.
  • Beim Raspberry 4 gibt es eine Einstellung zur Temperaturkontrolle, die muss deaktiviert werden. Siehe diesen Beitrag im Forum.
  • Bei Verwendung mit einem USR TCP232-T2 Wandler kann es in der Default-Einstellung des Wandlers dazu kommen, dass obsolete Kommunikation gepuffert und nach einem Wiederverbinden unnötig an FHEM gesendet wird (siehe dieses Foren-Thema). Im FHEM-Log gibt es in diesem Fall die Meldung "HMUART failed to enter App!" Abhilfe schafft das Aktivieren der Option "Buffer Data before connected" unter "Expand Function" im WebUI des TCP-232.

Links


  1. jedenfalls neuere firmware-Versionen