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
Super Beitrag. Habe den Teil mit dem alternativen Flashen ins FHEM Wiki übernommen. VG
AntwortenLöschenhttps://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi
Hallo,
AntwortenLöschenVielen Dank für den informativen Beitrag!
Eine Frage habe ich noch: Du schreibst "Raspberry PI B, B+, B2 oder B3".
ich habe einen Raspberry Pi Model B, 512MB RAM (Rev. 2.0), das sollte ja danach eigentlich passen.
Im ELV-Shop steht allerdings nur "Kompatibel mit Raspberry 2B und 3". Kannst du bestätigen, dass es auch mit dem Model B (ohne 2) funktioniert?
Danke und LG
Michael
Hallo Michael,
Löschenehrlich gesagt war ich immer davon ausgegangen, das es nur auf die GPIO ankommt.
Ich habe es gerade getestet, funktioniert unter FHEM auf einem Pi B. Ich vermute die Aussage von ELV trifft auf die Kombination RPI Modul & OCCU-SDK (Software) zu. Ich vermute die Software braucht den Pi 2.
Ich übernehme keine Garantie dafür, dass es läuft. Aber ich wüsste nicht warum es nicht laufen sollte.
Gruß Otto
Moin moin,
Löschensuper, vielen Dank! Dann werde ich mir das Ding jetzt bestellen und mal mit meinem alten Pi B ausprobieren. Will es ja sowieso direkt mit FHEM nutzen, wie hier beschrieben. Wenn du einen Reflink oder die Kundenwerbung für ELV oder so am Start hast, bestelle ich auch gerne darüber ;-)
Hallo Otto,
AntwortenLöschenvielen Dank für Deinen super Beitrag! Der hat mich ein großes Stück vorwärts gebracht.
Ich stehe jetzt aber gerade vor einem Problem, welche mich langsam aber sicher verzweifeln lässt...
Beim Versuch die neue Firmware auf das Modul zu laden hört der Vorgang nach spätestens 5 Sekunden auf oder bleibt direkt beim starten stehen.
Was mir noch auf gefallen ist, ist das ich bei mir kein serial1 habe, wenn ich ls -l /dev/ser* ausführe.
Hast Du eine Idee an der es liegen kann? Für jede Hilfe wäre ich sehr dankbar!
VG Marcel
Hallo Marcel, die Geräte serial1 und serial0 gibt es nicht bei allen Systemversionen. Also bei wheezy und jessie vor Mai 2016 ist das glaube ich normal. Schau ob Du ttyS0 hast.
LöschenWegen dem flashen, schau mal ob der Hinweis ganz am Ende hilft (gpio setzen).
Mehrfach versuchen, Modul mal vom Strom trennen.
Gruß Otto
ttyS0 wird mir auch nicht angezeigt. Er zeigt mir tty, tty0 - tty63, ttyAMA0 und ttyprintk an. Wofür genau ist das ttyS0? Und kann das der Grund sein, warum das flashen immer fehlschlägt?
LöschenDas setzen der GPIOs hab ich auch gerade noch ausprobiert. Leider keine Veränderung. Habe schon gefühlte 100 mal den Vorgang widerholt. Dann komplett abgeschaltet. Stromlos gemacht. Und das ganze wieder von vorne.
In FHEM steht auch folgendes im Log: HMUARTLGW myHmUART application switch failed, application-firmware probably corrupted!
Ist es evtl. auch möglich das mein Modul defekt ist?
VG Marcel
In 'Serielle Schnittstelle vorbereiten:', 'Zusammenfassung' muß es heißen:
AntwortenLöschen---
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
---
Danke :) - hier lag die Quelle des Fehlers. Habe gleich noch eine weitere Stelle korrigiert.
LöschenDanke für die Anleitung. Ich habe Raspi Model B mit Jessie lite.
AntwortenLöschenWenn man diese parallel zum Wiki verwendet stellen sich mir 2 Fragen:
1. Muss in /etc/inittab die Zeile
T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100
auskommentiert werden
2. Wie soll die Zeile in /boot/cmdline.txt aussehen?
Muss der Eintrag kgdboc=ttyAMA0,115200 auch gelöscht werden?
dwc_otg.lpm_enable=0 kgdboc=ttyAMA0,115200 console=tty1 elevator=deadline root=/dev/mmcblk0p2 rootfstype=ext4 fsck.repair=yes rootwait
Bitte alle Artikel genau lesen! Hier steht nichts anderes wie im Wiki. Die Zeile in der inittab ist nur für wheezy relevant, auf meinem jessie existiert diese Datei nicht. Meines Wissen existiert diese nicht mehr in Jessie. Ich sage explizit nichts darüber wie die Datei /boot/cmdline.txt aussehen muss, das ist individuell. Bei meinem Jessie existiert kein Eintrag mit kgboc... Da er aber wie console=... eine Verbindung zur Schnittstelle ttyAMA0 herstellen würde, würde ich ihn entfernen!
Löschentoller Beitrag danke.
AntwortenLöschenAber ich habe das Problem, dass bei meinem Raspberry 3 entweder WIFI oder HM-MOD-RPI-PCB funktioniert;d.h. wenn ich nur über WIFI auf den R3 zugreife, läuft HM-MOD-RPI-PCB nicht; aber wenn ich ein LAN-Kabel einstecken und reboote, dann funktioniert HM-MOD-RPI-PCB.
Hast du ev. Vorschläge was ich hier falsch mache?
Sorry, da kann ich Dir nicht helfen. Ich sehe da keinen Zusammenhang, habe das aber auch nicht probiert.
LöschenGruß Otto
Hi Otto, das ist eine klasse Anleitung, weil jeder Schritt sehr gut erklärt ist, was für Linux-Anfänger wirklich unerlässlich ist - hat man nicht immer :-)
AntwortenLöschenIch habe hier das Steckmodul HM-MOD-RPI-PCB auf einen Raspi B gesteckt, um es parallel mit einem LAN Gateway (HM-LGW-O-TW-W-EU-2) zu betreiben und somit Homematic IP-Geräte ansprechen zu können. Die beiden Geräte koexistieren bereits in fhem, ein mitlaufendes FileLog zeigt allerdings andauernd Events wie "UNKNOWNCODE A0A8A800200100056C8B500::-21:HW_DEVICE2".
Eine über das Steckmodul angelernte Funksteckdose kann nun problemlos über das neue Modul erkannt und geschaltet werden, nur wie jetzt ein Homematic IP-Gerät angelernt wird, ist mir völlig unklar. War da zuviel Wunschdenken bei mir vorhanden und das geht gar nicht? Oder fehlt noch etwas? Ich habe nirgends einen Hinweis dazu gefunden und bin für jeden Hinweis dankbar!
TIA Chris
Ooops, das war nicht ganz vollständig erklärt, die angelernte Funksteckdose ist natürlich noch ein Homematic-Gerät ;-)
LöschenDu kannst auf dem Pi mit der entsprechende Software eine CCU2 emulieren. Die kann auch IP Geräte, FHEM kann das nicht. Es gibt auch Projekte die auf dem Pi eine CCU2 und FHEM parallel laufen lassen - YAHM - Yet Another Homematic Management. Aber trotzdem kann das Modul dann nur eine der beiden Welten bedienen. Eine CCU2 kann mit HMCCU in FHEM abgebildet werden, eine echte Integration ist das nicht.
LöschenEs zu diesen Themen dutzende Artikel im FHEM Forum.
Die UNKNOWNCODE Meldung kommt eventuell von Deinen HM-IP Geräten.
Gruß Otto
Vielen Dank für diesen Hinweis, der Zusammenhang mit anderen Lösungen war mir nicht klar - werde mir also mal YAHM ansehen. Die Trennung der beiden Welten ist schon klar, so war es ja auch gedacht. Thnx Chris
LöschenHallo Otto,
AntwortenLöschenklasse Anleitung! Flashen hat erst nach dem Überbrücken von J1 funktioniert.
Nun zwiet mir FHEm an,dass myHmUART den STatus opened hat.
Auszug aus meiner fhem.cfg:
define myHmUART HMUARTLGW /dev/ttyAMA0
attr myHmUART devStateIcon .*:hm_ccu
attr myHmUART hmId 082965
attr myHmUART logIDs sys,all
attr myHmUART room System
Meine Fage:
Was muss ich tun, damit mir die CCU im WebGUI angezeigt wird? Dann müsste ich die angelernte HM-Wetterstation doch auch mit der dafür vorgesehenen iPhone-App sehen???
Ist aber beides nicht der Fall.
Beste Grüße von der Ostsee
Christian
Hallo Christian,
Löschensorry aber ich will nicht und ich werde hier nicht ein Supportforum betreiben. Bitte stelle die Frage im FHEM Forum, wobei ich sie ehrlich gesagt nicht verstehe, also drücke dies "CCU im WebGUI " dort präziser aus.
Gruß Otto
Der Kommentar wurde von einem Blog-Administrator entfernt.
AntwortenLöschenHallo Christian,
Löschensorry aber ich will nicht und ich werde hier nicht ein Supportforum betreiben. Fragen und Kritiken die im direkten Zusammenhang zu meinen Beiträgen stehen beantworte ich gerne - aber das geht eindeutig weiter. Also bitte stelle diese Frage im FHEM Support Forum.
Bitte hab auch Verständnis dass ich dieses lange Log wieder lösche, das hat hier nichts zu suchen.
Gruß Otto
Dieser Kommentar wurde vom Autor entfernt.
LöschenIrgendwie hat es die letzte Frage von Chris gelöscht ohne das ich dies wollte. Also nochmal mein Stand zu HM-IP
LöschenMan kann eine CCU2 in FHEM mit dem Modul HMCCU abbilden. Das ist aber eine völlig andere Sache, als wenn FHEM die Zentrale ist. Für mich käme diese Variante nicht in Frage. Sie ist für mich eine Krücke!
Mit dem hier besprochenen Modul kann man quasi mit verschiedener Software eine CCU2 bauen, das war nicht Inhalt meines Artikels. In der Qualität wie FHEM Zentrale für Homematic sein kann, geht das nicht für Homematic-IP! Eine "saubere" Integration beider Homematic Welten in FHEM gibt es derzeit nicht. Man kann mit beiden was machen, aber auf völlig unterschiedlichem Level.
Gruß Otto
Hi Otto,
AntwortenLöschensuper Anleitung!! Leider stehe ich vor einem Problem und sehe so langsam den Wald vor lauter Bäumen nicht mehr.
Ich verwende einen RPI3 mit Stretch.
Mittlerweile habe ich alles oben beschriebene sowie noch einiges mehr getestet, leider ohne Erfolg.
ls -l /dev/ser* wirft mir lediglich serial1 -> ttyS0 aus. Serial0 gibt es bei mir nicht.
Könntest du mir evtl. behilflich sein?
Habe es gelößt bekommen, hatte noch einen pivccu overlay eintrag in der boot/config.txt
LöschenHallo Otto,
AntwortenLöschenDanke für die Anleitung. Zu welchem Zeitpunkt wird das Modul auf die GPIO Ports aufgesteckt? Ich habe in der boot config wlan und bluetooth abgeschaltet per
dtoverlay=pi3-disable-wifi
dtoverlay=pi3-disable-bt
muss ich BT wieder aktivieren? Dankeschön
Hallo,
Löschenes ist völlig egal zu welchem Zeitpunkt Du das Modul steckst. Ich würde vermeiden es im laufenden Betrieb zu tun.
Es ist meines Wissens egal ob Du BT abgeschaltet hast. Ob es dann trotzdem ohne den Eintrag
dtoverlay=pi3-miniuart-bt
geht, habe ich nicht probiert. Ich denke aber nicht, da damit die Zuordnung der UART und miniUART getauscht wird. Meines Wissens funktioniert das Modul nur mit der UART.
Gruß Otto
Hallo,
AntwortenLöschenvielen Dank für die tolle Anleitung, leider steht bei mir immer, dass es disconnected ist. Ich kann auch nichts über die Konsole verändern. Ich melde mich über Putty und als Benutzer root mit meinem Passwort an, aber sobald ich einen Befehl eingebe kommt die Meldung
-sh: sudo: not found
ich hoffe du kannst mir helfen. Lieben Gruß Marcel
Hallo Marcel,
Löschenwenn Du als root angemeldet bist brauchst Du kein sudo. Allerdings wird das nichts mit dem Problem disconnected zu tun haben. Ich kann hier aber kein Supportforum betreiben. Vielleicht stellst Du Dein Problem im FHEM Forum ein.
Gruß Otto
Hallo och habe das Problem den 5v pin freizu halt und bin auch neu in dem ganzen thema (noch in Vorbereitung usw) und würde das modul gerne beim pi3 auf den pin 17 stecken geht das? Möchte fhem verwenden (sobal ich das ding mal endlich sauber aufgesetzt bekommnit der neusten version vom rasbian scretch und +blauzahn und wifi) was müste ich dann ändern oder ist das bei egal welcher instalart die sache mit dem socc
AntwortenLöschenLiebe Grüße leo dank im vorraus
(Und das mit dem umtauschen von dtoverlayfür bt /wifi ist soweit schon sinnig angekommen)
Hallo Otto diese Anleitung hat mir schon vor ein paar Jahren sehr geholfen! Jetzt meine Frage, da mein Raspberry 4 bald kommt.
AntwortenLöschenHat das wer schon mit dem 4er gemacht?
Oder was ist dann alles anders zu konfigurieren?
LG
edank
Ich denke da hat sich nichts geändert. Aber ich habe es noch nicht gemacht. Mittlerweile habe ich auch ein Script für das Setup gemacht. https://github.com/heinz-otto/raspberry/blob/master/setupUartPi3.sh
LöschenGruß Otto
Hallo Otto,
AntwortenLöschenes stimmt, es ist gleich geblieben!
Danke dir!
Liebe Grüße
Hallo Otto,
AntwortenLöschenkann das Modul HM-MOD-RPI-PCB mittlerweile in einem FHEM auch HmIP empfangen/verwalten?
Das selbe Modul nutzen schliesslich auch diverse CCU-Nachbauten, wie Yahm oder Raspberrymatic, und empfangen Homematic Classic und IP.
Wenn nicht, was würdest du empfehlen um HmIP zu nutzen? Eine originale CCU2, raspberrymatic, oder yahm?
Danke und Gruss
Adrian
Hallo Adrian,
LöschenKann HmIP: Nein, das Protokoll ist nicht öffentlich.
Ich habe Raspberrymatic im docker probiert, das würde ich erstmal auch empfehlen.
Gruß Otto
Hallo Otto, ich kann Dein Script nicht finden. Unter dem Link
AntwortenLöschenhttps://github.com/heinz-otto/raspberry/blob/master/setupUartPi3.sh
kommt eine Error Page 404
Kannst Du hier helfen?
Schau mal bitte direkt. Sorry ich habe das mal umbenannt.
Löschenhttps://github.com/heinz-otto/raspberry
Ich bin derzeit unterwegs und kann nur eingeschränkt arbeiten.
Gruß Otto
Ich habe den Link im Text korrigiert.
Löschen