Dieser Artikel hat nur noch historischen Charakter.
Für die Himbeere gibt es seit einiger Zeit eine Homematic Modul HM-MOD-RPI-PCB. Der Bausatz ist simpel aufgebaut, es ist nur eine Buchsenleiste und zwei Platinen mit Pfostenverbinder zusammenlöten.
Der HM-CFG-USB Adapter ist schon nicht mehr lieferbar, den HM-CFG-LAN soll es bald nicht mehr geben. Damit wird diese Modul und die Implementierung in FHEM zunehmend interessant!
Seit 18.7.2016 ist das Modul direkt in FHEM und das CUL_HM Modul ist angepasst. Damit ist die Installation schon einen Schritt einfacher.
Es gibt einen Thread der alles beschreibt, im Wiki findet man zunehemend entsprechende Infos.
Ich schreibe mal wieder auf wie es bei mir funktioniert hat:
Zutaten:
Nach dem ersten Start den serial-getty Dienst deaktivieren:
Jetzt unbedingt neu starten!
Interessant ist auf alle Fälle das Script von Betateilchen. Allerdings installiert dies die SVN Version. Der normaler User sollte in Standard Setup verwenden.
Beim PI 3 wegen Timingproblemen muss man noch eventuell die /etc/init.d/fhem um sleep 10 am Anfang ergänzen
Laut Wiki ist jetzt auch das flashen der Firmware von FHEM aus möglich.
In der FHEM Kommandozeile:
Etwas warten das die Datei geladen wurde (LogFile prüfen) dann diesen Befehl eingeben und warten bis das Modul sich wieder meldet.
Falls das nicht funktioniert, hier noch die händische Methode:
Am Besten FHEM beenden, damit keine Zugriffe auf das Modul erfolgen!
Ein Beenden des Dienstes ändert daran nichts.
Wird der Dienst nicht gestartet stehend die Rechte auf
crw-rw---- 1 root dialout 204, 64 Jul 18 09:51 /dev/ttyAMA0
So müssen die Rechte auch aussehen! Und der User fhem muss in der Gruppe dialout sein!
Der Eintrag console=serial0,115200 in der /boot/cmdline.txt ist offenbar dafür verantwortlich, dass der Dienst trotz disable gestartet wird. Löscht man diesen Eintrag, wird der Dienst auch nicht gestartet. Unterm Strich kann man den Start des Dienstes auf zwei Arten verhindern:
Eigentlich würde ich ein systemctl mask serial-getty@ttyAMA0.service bevorzugen um den Dienst generell auszuschließen.
Eine Änderung wie früher beschrieben in der Datei /lib/systemd/system/hciuart.service ist nicht mehr notwendig!
Im laufenden Betrieb kann man auch so vorgehen
Man kann die korrekte Ansteuerung mit ls -l /dev/ser* überprüfen:
Mit dtoverlay=pi3-miniuart-bt (BT an ttyS0)
lrwxrwxrwx 1 root root 7 Jan 1 18:48 /dev/serial0 -> ttyAMA0
lrwxrwxrwx 1 root root 5 Jan 1 18:48 /dev/serial1 -> ttyS0
lrwxrwxrwx 1 root root 7 Jan 1 19:02 /dev/serial1 -> ttyAMA0
Im praktischen Betrieb muss man aber die eigene hmId setzen. Ohne das Attribute hmId empfängt das Modul scheinbar nichts.
Das attr qLen spielte bei mir nach einiger Zeit eine Rolle (Meldung im Log: queue is full, dropping packet), ich habe den Wert auf 60 gesetzt.
Um AES-CBC nutzen zu können (Rauchmelder SD-2) muss das Paket libcrypt-rijndael-perl installiert werden.
Das UART Modul merkt sich die hmId und die AES Schlüssel bis zur nächsten Änderung.
Das Modul HMUARTLGW unterstützt auch die Remoteanbindung des Raspberry mit socat. Näheres siehe Commandref.
Damit wird das Reset Pin am Modul definiert gesetzt
Der HM-CFG-USB Adapter ist schon nicht mehr lieferbar, den HM-CFG-LAN soll es bald nicht mehr geben. Damit wird diese Modul und die Implementierung in FHEM zunehmend interessant!
Seit 18.7.2016 ist das Modul direkt in FHEM und das CUL_HM Modul ist angepasst. Damit ist die Installation schon einen Schritt einfacher.
Es gibt einen Thread der alles beschreibt, im Wiki findet man zunehemend entsprechende Infos.
Ich schreibe mal wieder auf wie es bei mir funktioniert hat:
Zutaten:
- Raspberry PI B, B+, B2 oder B3
- Image Jessie-Lite vom 27.05.2016 oder aktueller
- System Grundkonfiguration: Zeitzone, Hostname, Kamera etc...
Serielle Schnittstelle vorbereiten:
Die folgenden Schritte kann man vor dem ersten Start auf der SD Karte (nach dem Image schreiben) ausführen oder aber nach dem ersten Start im Terminal.
- In der Datei /boot/cmdline.txt diesen Eintrag löschen: console=serial0,115200
- Die Datei /boot/config.txt um diese Zeile ergänzen: enable_uart=1
- Bei dem PI 3 muss die UART und die miniUART getauscht werden. Die Datei /boot/config.txt insgesamt um diese Zeilen ergänzen:
enable_uart=1
dtoverlay=pi3-miniuart-bt
core_freq=250
Statt core_freq kann man auch force_turbo=1 gesetzt werden. Wichtig ist hierbei, dass dei Taktfrequenz konstant bleibt.Nach dem ersten Start den serial-getty Dienst deaktivieren:
sudo systemctl disable serial-getty@ttyAMA0.service
Jetzt unbedingt neu starten!
Zusammenfassung
Falls man die Dateien im Image nicht vor dem ersten Start manipuliert hat, also nach dem ersten Start im Terminal:sudo su
echo "enable_uart=1" >> /boot/config.txt
echo "dtoverlay=pi3-miniuart-bt" >> /boot/config.txt # Nur beim Pi3 notwendig
echo "core_freq=250" >> /boot/config.txt
sed -i s/'\bconsole=serial0,115200 //' /boot/cmdline.txt
systemctl disable serial-getty@ttyAMA0.service
reboot
In jedem Fall braucht man einen Neustart. man kann also die obigen Zeilen auch in das Script zur Grundkonfiguration des raspberry einbinden und läuft nicht Gefahr die Dateien im /boot durch den falschen Windows Editor unbrauchbar zumachen.Setup von FHEM
Ganz nach persönlicher Vorliebe!Interessant ist auf alle Fälle das Script von Betateilchen. Allerdings installiert dies die SVN Version. Der normaler User sollte in Standard Setup verwenden.
Beim PI 3 wegen Timingproblemen muss man noch eventuell die /etc/init.d/fhem um sleep 10 am Anfang ergänzen
Nach Neustart in FHEM einfach die Definition
define myHmUART HMUARTLGW /dev/ttyAMA0
attr myHmUART hmId xxxxxx
Firmware flashen
Das frische Modul sollte noch mit neuer Firmware geflasht werden, die Originalversion war 1.2.1 empfohlen ist derzeit die 1.4.1 von eq3.Laut Wiki ist jetzt auch das flashen der Firmware von FHEM aus möglich.
In der FHEM Kommandozeile:
"wget -O FHEM/firmware/coprocessor_update.eq3 https://raw.githubusercontent.com/eq-3/occu/ee68faf77e42ed5e3641790b43a710a3301cea7e/firmware/HM-MOD-UART/coprocessor_update.eq3"
Etwas warten das die Datei geladen wurde (LogFile prüfen) dann diesen Befehl eingeben und warten bis das Modul sich wieder meldet.
set myHmUART updateCoPro FHEM/firmware/coprocessor_update.eq3
Falls das nicht funktioniert, hier noch die händische Methode:
Am Besten FHEM beenden, damit keine Zugriffe auf das Modul erfolgen!
sudo su
apt-get update && apt-get 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
Bei der letzten Zeile kamen mehrere Fehler. Ich habe es einfach mehrfach wiederholt und irgendwann ging es.
Sollten beim Firmwareupdate hartnäckig Fehler auftreten (oder einfach nichts passieren) muss das Modul mal vom Strom getrennt werden, neustart reicht nicht!
Sollten beim Firmwareupdate hartnäckig Fehler auftreten (oder einfach nichts passieren) muss das Modul mal vom Strom getrennt werden, neustart reicht nicht!
Hintergrundinformationen
Man kann die Grundkonfiguration mit raspi-config machen:- Zeitzone
- Hostnamen ändern
- Kamera aktivieren
- Serielle Schnittstelle aktivieren
- usw.
Man kann aber auch alles per Script machen:
# Zeitzone
echo "Europe/Berlin" > /etc/timezone
dpkg-reconfigure -f noninteractive tzdata
#Hostname noch testen!!!
hostname -b raspib
sed -i s/raspberrypi/raspib/ /etc/hosts
nano /etc/init.d/hostname.sh
nano /etc/hostname
rm /etc/ssh/ssh_host_*
dpkg-reconfigure openssh-server
#Kamera
echo "start_x=1" >> /boot/config.txt
echo "gpu_mem=128" >> /boot/config.txt
echo "disable_camera_led=1" >> /boot/config.txt
Achtung: Scripte immer unbedingt im Unix Code (nur LF) abspeichern!!!Die Sache mit den Rechten auf /dev/ttyAMA0
Der Start des Dienstes serial-getty@ttyAMA0.service setzt offenbar die Rechte auf.
crw--w---- 1 root tty 204, 64 Jul 15 20:36 /dev/ttyAMA0Ein Beenden des Dienstes ändert daran nichts.
Wird der Dienst nicht gestartet stehend die Rechte auf
crw-rw---- 1 root dialout 204, 64 Jul 18 09:51 /dev/ttyAMA0
So müssen die Rechte auch aussehen! Und der User fhem muss in der Gruppe dialout sein!
Die Sache mit dem Dienst serial-getty@ttyAMA0.service
Ein systemctl disable serial-getty@ttyAMA0.service verhindert zwar den automatischen Start aber nicht den manuellen Start bzw. den Start durch andere Prozesse. Erst der Befehl systemctl mask xxx verhindert jeglichen Start.Der Eintrag console=serial0,115200 in der /boot/cmdline.txt ist offenbar dafür verantwortlich, dass der Dienst trotz disable gestartet wird. Löscht man diesen Eintrag, wird der Dienst auch nicht gestartet. Unterm Strich kann man den Start des Dienstes auf zwei Arten verhindern:
sudo sed -i s/'\bconsole=serial0,115200 //' /boot/cmdline.txt
sudo systemctl disable serial-getty@ttyAMA0.service
odersudo su
systemctl stop serial-getty@ttyAMA0.service
systemctl disable serial-getty@ttyAMA0.service
systemctl mask serial-getty@ttyAMA0.service
chmod g=rw /dev/ttyAMA0
Eigentlich würde ich ein systemctl mask serial-getty@ttyAMA0.service bevorzugen um den Dienst generell auszuschließen.
Wenn Bluetooth beim Pi 3 funktionieren soll: ttyAMA0 und ttyS0 tauschen
Der Eintrag dtoverlay=pi3-miniuart-bt in der Datei /boot/config.txt sorgt dafür, dass die Ansteuerung des BT Moduls jeweils über den Alias serial1 erfolgt.Eine Änderung wie früher beschrieben in der Datei /lib/systemd/system/hciuart.service ist nicht mehr notwendig!
sed -i s/ttyAMA0/ttyS0/ /lib/systemd/system/hciuart.service
daemon reload
systemctl restart hciuart
Man kann die korrekte Ansteuerung mit ls -l /dev/ser* überprüfen:
Mit dtoverlay=pi3-miniuart-bt (BT an ttyS0)
lrwxrwxrwx 1 root root 7 Jan 1 18:48 /dev/serial0 -> ttyAMA0
lrwxrwxrwx 1 root root 5 Jan 1 18:48 /dev/serial1 -> ttyS0
Ohne dtoverlay=pi3-miniuart-bt (BT an ttyAMA0)
lrwxrwxrwx 1 root root 5 Jan 1 19:02 /dev/serial0 -> ttyS0lrwxrwxrwx 1 root root 7 Jan 1 19:02 /dev/serial1 -> ttyAMA0
Alternativ könnte man BT deaktivieren.
FHEM Setup
Die Einbindung in FHEM passiert mit dem Modul HMUARTLGW. Das HM-MOD-RPI-PCB hat einen eigene hmId.
define HMUART1 HMUARTLGW /dev/ttyAMA0
Im praktischen Betrieb muss man aber die eigene hmId setzen. Ohne das Attribute hmId empfängt das Modul scheinbar nichts.
attr HMUART1 hmId xxxxxx
Um AES-CBC nutzen zu können (Rauchmelder SD-2) muss das Paket libcrypt-rijndael-perl installiert werden.
Das UART Modul merkt sich die hmId und die AES Schlüssel bis zur nächsten Änderung.
Das Modul HMUARTLGW unterstützt auch die Remoteanbindung des Raspberry mit socat. Näheres siehe Commandref.
Probleme
FHEM startet mit knapp 100% CPU wenn das HM-MOD-RPI-PCB Modul einfach gesteckt wird.
Es hilft wenn man vor dem Stecken die Erkennung von FHEM ausschaltet.
oder unmittelbar nach der Neuinstallation!
Es hilft wenn man vor dem Stecken die Erkennung von FHEM ausschaltet.
attr initialUsbCheck disable 1
oder unmittelbar nach der Neuinstallation!
echo 'attr initialUsbCheck disable 1' >> /opt/fhem/fhem.cfg
Notizen
Eventuell braucht man mit der original Firmware (1.2.1) noch das:echo 18 >/sys/class/gpio/export
echo out >/sys/class/gpio/gpio18/direction
echo 1 >/sys/class/gpio/gpio18/value
Damit wird das Reset Pin am Modul definiert gesetzt