Hallo zusammen,
ich bin gerade dabei meine Homematic Funkmodul, welches über die GPIOs an meinen Raspberry Pi2b angeschlossen wird zu installieren.
Dabei bin ich nach folgender Anleitung vorgegangen: https://owsh.de/2017/08/raspberry-pi-homematic-funkmodul-installieren/
Noch zur Info, ich verwende Jessie.
Bis zu dem Part an dem ich das Softwareupdate durchführen möchte hat soweit alles geklappt. Ich habe die Dateien für das Softwareupdate herruntergeladen und kopiert. Wenn ich jetzt aber den Befehl in FHEM zum starten des Updates eingebe und dann meinen Pi neustarte habe ich immernoch die Alte Version (1.2.1).
Des weiteren ist mir aufgefallen, dass unter "cond" das reading von init zu disconnected ständig hin und her springt. Des weiteren wurde bei mir auch nicht automatisch ein neuer Raum CUL_HM angelegt.
Woran kann das alles liegen?
Grüße
Frag doch einfach mal dort nach, wo Du die offenbar nicht funktionierende Anleitung her hast...
Oder benutze die Forumsuche hier. Es gibt schon mehrere Threads zu Deinen Fragen.
Gesundes neues Jahr!
mach es bitte hiernach -> https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi
Die Beschreibung sollte passen. Beachte bitte das es Unterscheide beim P2 und P3 gibt in der Anleitung.
Wenn das cond hin und her springt ist das Modul quasi nicht aktiv, häufige Ursachen:
- falsch gelötet (Bild im Wiki beachten)
- UART nicht aktiv
- UART durch andere Prozesse belegt.
Solange das Modul nicht Fehlerfrei an der Hardware (bzw. in FHEM) läuft, braucht man sich keine Gedanke um Firmware Update zu machen.
Gruß Otto
Erstmal vielen Dank für eure Antworten und euch natülich auch ein gutes neues :)
Also ich habe das ganze nochmal nach der Anleitung von hier gemacht. Wobei man sagen muss, dass diese genau die selbe ist.
Das einzige wo ich mir nicht sicher bin, ist ob von der Formatierung her meine cmdline.txt Datei passt. Ich habe dort folgendes eingetragen:
dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwaitsystemctldisable serial-getty@ttyAMA0.service
Am Punkt wo man mit "groups fhem" überprüfen soll, ob der fhem Benutzer ein Mitglied in der Gruppe Dialout ist kommt bei mir die Meldung: fhem : dialout tty passt das soweit?
Wenn ich nun mit:
ls -l /dev/serial1
kontrollieren will, ob serial1 mit ttyS0 verlinkt ist kommt bei mir die Meldung:
Zugriff auf /dev/serial1 nicht möglich: Datei oder Verzeichnis nicht gefunden
Bei:
ls -l /dev/serial0 kommt die Meldung: lrwxrwxrwx 1 root root 7 Jan 1 17:54 /dev/serial0 -> ttyAMA0
Ist das normal so?
Ich habe das Funkmodul nochmal im ganz ausgeschaltenen zustand ausgebaut. Die Lötstellen sind soweit alle gut. Ich habe es auch nochmals mit dem Bild aus dem wiki verglichen und festgestellt, dass es auch richtig zusammengelötet ist. Auch das vom Strom trennen, wie es im Wiki empfohlen wird hat nichts geholfen.
Vielleicht ist noch zu erwähnen, dass ich einen nanoCUL über USB an dem Pi angeschlossen habe?
Des weiteren fällt mir ein, dass ich vor längerer Zeit mittels wiringPi und einem 433MHz Transmitter Steckdosen geschalten habe. Der Transmitter war damals über GPIO angeschlossen. Ich war eigentlich der Meinung dass ich wiringPi deinstalliert habe, könnte es dadurch evtl. auch zu Problemen kommen?
Grüße
Bastian
Hallo Bastian,
klingt soweit ok.
was ergibt die Ausgabe von folgendem Befehlsystemctl status serial-getty@ttyAMA0.service
Gruß Otto
Zitat von: Otto123 am 01 Januar 2018, 19:26:07
was sagt ein ?
Ich verstehe leider nicht ganz was du damit meinst. Wenn ich jedoch deinen Befehl eingebe bekomme ich folgende Ausgabe:
● serial-getty@ttyAMA0.service - Serial Getty on ttyAMA0
Loaded: loaded (/lib/systemd/system/serial-getty@.service; disabled)
Active: inactive (dead)
Docs: man:agetty(8)
man:systemd-getty-generator(8)
http://0pointer.de/blog/projects/serial-console.html
Ja das meinte ich ;)
Gut, der serial-getty ist deaktiviert das ist gut.
Wenn Du der Meinung bist sonst alles richtig gemacht zu haben - bleibt fast nur noch: Das Modul funktioniert nicht. Kannst Du bitte prüfen, ob du beide Teilplatinen richtig miteinander verlötet hast? Also nicht aus Versehen beide Platinen genau verdreht aufeinander? Kein Witz, gab es schon mindestens zwei mal.
Poste mal ein list von deinem device
Gruß Otto
Also das Modul hab ich definitiv richtig miteinander verlötet.
Zitat von: Otto123 am 01 Januar 2018, 22:34:28
Poste mal ein list von deinem device
Also einfach in fhem list eingeben und das alles hier reinstellen?
list <Name der Definition Deines Moduls>
wenn ich list<myHmUART> in FHEM eingebe passiert leider nichts.
Also ich gehe mal davon aus, dass "Name der Definition meines Moduls" myHmUART ist, das steht zumindest im Feld NAME im DeviceOverview.
list myHmUART
natürlich ohne < > die zwei Zeichen
Also jetzt komme ich mir endgültig dumm vor :D
ich habe alle möglichen Namen ausprobiert und es kam immer die Meldung: No device named ..... found
Ich habe es mit folgenden Namen probiert:
/dev/ttyAMA0
/dev/ttyAMA0@115200
myHmUART
edit: fragt mich nicht wieso, aber jetzt funktioniert der list befehl. Hier die Ausgabe:
Internals:
CNT 2
DEF /dev/ttyAMA0
DEVCNT 1
DevState 2
DevType UART
DeviceName /dev/ttyAMA0@115200
FD 5
LastOpen 1514906989.85153
NAME myHmUART
NR 221
PARTIAL
RAWMSG 0402436F5F4350555F424C
STATE opened
TYPE HMUARTLGW
XmitOpen 0
Helper:
Ackpending:
2:
cmd 03
dst 0
frame FD00030002039409
time 1514906990.89675
LastSendLen:
3
3
Log:
IDs:
Roundtrip:
Readings:
2018-01-02 15:39:01 D-type HM-MOD-UART
2018-01-02 16:29:50 cond init
2018-01-02 15:39:01 loadLvl suspended
2018-01-02 16:29:49 state opened
Attributes:
hmId 526461
Hmm, es sieht so aus als ob das Modul nicht völlig "weg" ist, das sieht nämlich so aus:
Internals:
CFGFN
DEF /dev/ttyAMA0
DevState 0
DevType UART
DeviceName /dev/ttyAMA0@115200
NAME HMUART1
NR 391562
PARTIAL
STATE disconnected
TYPE HMUARTLGW
XmitOpen 0
model HM-MOD-UART
Helper:
READINGS:
2018-01-02 19:36:17 D-type HM-MOD-UART
2018-01-02 19:36:17 cond disconnected
2018-01-02 19:36:17 loadLvl suspended
2018-01-02 19:36:17 state disconnected
Attributes:
Aber irgendetwas arbeitet an der seriellen Schnittstelle (UART) und lässt das Modul nicht zum Zuge kommen.
Wie hast Du die Dateien /boot/config.txt und /boot/cmdline.txt erstellt bzw bearbeitet? Mit Windows Editor?
Gruß Otto
ich hab die Dateien /boot/config.txt und /boot/cmdline.txt mittels dem Befehl "sudo nano" direkt in Putty bearbeitet.
Nur um nochmal sicher zu gehen, hier der Inhalt der Dateien:
# For more options and information see
# http://rpf.io/configtxtreadme
# Some settings may impact device functionality. See link above for details
# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1
# uncomment this if your display has a black border of unused pixels visible
# and your display can output without overscan
#disable_overscan=1
# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16
# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720
# uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=1
# uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1
# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2
# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4
# uncomment for composite PAL
#sdtv_mode=2
#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800
# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on
# Uncomment this to enable the lirc-rpi module
#dtoverlay=lirc-rpi
# Additional overlays and parameters are documented /boot/overlays/README
# Enable audio (loads snd_bcm2835)
dtparam=audio=on
#enable uart für homematic Funkmodul
enable_uart=1
und
dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait systemctl disable serial-getty@ttyAMA0.service
Das hast Du erstmal fein gemacht :)
Aber wozu steht das in der cmdline.txt?
systemctl disable serial-getty@ttyAMA0.service
Streich das bitte raus, die Deti darf auch wirklich bloß aus einer Zeile ohne Zeilenumbruch am bestehen!
Das gehört da nicht hin. Das gehörte in die Kommandozeile.
Gruß Otto
Ich habe meine cmdline.txt nun so geändert:
dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
und in der Kommandozeile
systemctl disable serial-getty@ttyAMA0.service
ausgeführt.
Danach habe ich einen Neustart durchgeführt. Leider mit dem gleichen Ergebnis, cond springt immernoch hin und her.
Dann habe ich den pi komplett herruntergefahren und vom Strom getrennt. Leider mit dem gleichen Ergebnis.
Sollte ich evtl. das Device in FHEM nochmal löschen und neu anlegen?
Nein. Es liegt nicht an der definition in FHEM.
Irgendwas in Deinem System blockiert die Schnittstelle. ich weiß nicht was.
kann es von meinem nanoCUL kommen? wohl kaum oder?
Des weiteren hatte ich ja schonmal erwähnt einen 433Mhz Transmitter angeschlossen hatte. Der wurde aber an anderen Pins des GPIO angeschlossen.
Wie könnte ich denn herausfinden was alles auf die UART Schnittstelle zugreift?
du hattest erwähnt, dass Du wiringpi deinstalliert hast. In der Tat könnte das ein Problem sein:
ZitatWiringPi includes a simplified serial port handling library. It can use the on-board serial port, or any USB serial device with no special distinctions between them. You just specify the device name in the initial open function.
Also suche in der Richtung! Ich habe leider keine Ahnung davon
Gruß Otto
Also da ich mir jetzt nicht sicher war was die UART Schnittstelle beansprucht habe ich mal FHEM testweise komplett neu aufgesetzt. Mein "altes" FHEM habe ich zuvor natürlich mit win32diskimager gesichert.
Dazu bin ich nach dieser Anleitung vorgegangen, natürlich nachdem ich Raspbian installiert habe:
https://haus-automatisierung.com/hardware/fhem/2016/05/07/fhem-tutorial-reihe-part-2-fhem-installieren-und-absichern.html
(leider hat das ganze bei mir mit der Anleitung aus dem Wiki nicht reibungsfrei funktioniert, weshalb ich diese verwendet habe.) Zur besseren Vergleichbarkeit macht das auch sinn diese Anleitung wieder zu verwenden, da ich nach dieser Anleitung bei meinem "altem" FHEM vorgegangen bin. Leider musste ich noch ein paar Pakete nachinstallieren.
Danach habe ich erneut nach dieser Anleitung mein HomematicModul installiert:
https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi
Zu welchem Zeitpunkt der Installation soll dieses eigentlich eingesteckt werden?
Bei dem Schritt im Wiki "Nur unter Jessie"
wird geschrieben, dass man kontrollieren soll, dass serial1 auf ttyS0 verlinkt ist. Wenn ich dazu den Befehl:
ls -l /dev/serial1 eingebe, kommt als Ausgabe: ls: Zugriff auf '/dev/serial1' nicht möglich: Datei oder Verzeichnis nicht gefunden
Da ist doch schon was faul oder ist das normal da ich Strech habe?
Bei Strech steht in der Anleitung dass serial0 auf ttySo verlinkt wird.
In der Anleitung ist folgender Code zu sehen:
ls -l /dev/serial0
lrwxrwxrwx 1 root root 7 Okt 26 12:39 /dev/serial0 -> ttyAMA0
Genau die gleiche Ausgabe erhalte ich auch. Jedoch frage ich mich wieso geschrieben wird, dass serial0 auf ttyS0 verlinkt wird und dann im code serial0 ->ttyAMA0 steht?
Naja, jedenfalls habe ich den pi wieder komplett vom Strom getrennt, das Modul angeschlossen und wieder gestartet. Leider immernoch mit dem gleichen Fehler. Wie kann das sein????
Ich werd noch echt wahnsinnig :-X
edit:
Ich habe mir gerade mal die /lib/systemd/system/hciuart.service angesehen, und festgestellt dass dort nichts von wegen ttyAMA0 oder ttyS0 steht. Was mich auch verwundert, ist dass anscheinend ein Bluetooth Modul aktiviert ist.
Unit]
Description=Configure Bluetooth Modems connected by UART
ConditionPathIsDirectory=/proc/device-tree/soc/gpio@7e200000/bt_pins
Before=bluetooth.service
Wants=dev-serial1.device
After=dev-serial1.device
[Service]
Type=forking
ExecStart=/usr/bin/btuart
[Install]
WantedBy=multi-user.target
Zitat von: basti2s am 03 Januar 2018, 14:32:24
(leider hat das ganze bei mir mit der Anleitung aus dem Wiki nicht reibungsfrei funktioniert, weshalb ich diese verwendet habe.) Zur besseren Vergleichbarkeit macht das auch sinn diese Anleitung wieder zu verwenden, da ich nach dieser Anleitung bei meinem "altem" FHEM vorgegangen bin. Leider musste ich noch ein paar Pakete nachinstallieren.
Zu welchem Zeitpunkt der Installation soll dieses eigentlich eingesteckt werden?
Da ist doch schon was faul oder ist das normal da ich Strech habe?
Bei Strech steht in der Anleitung dass serial0 auf ttySo verlinkt wird.
In der Anleitung ist folgender Code zu sehen:
ls -l /dev/serial0
lrwxrwxrwx 1 root root 7 Okt 26 12:39 /dev/serial0 -> ttyAMA0
Genau die gleiche Ausgabe erhalte ich auch. Jedoch frage ich mich wieso geschrieben wird, dass serial0 auf ttyS0 verlinkt wird und dann im code serial0 ->ttyAMA0 steht?
Die einzig richtige Anleitung zur FHEM Installation steht hier debian.fhem.de
Der Zeitpunkt wann Du das Modul steckst ist egal.
Da ist nichts faul, ich glaube dieser Abschnitt gilt für den Pi3
Warum das dort geschrieben steht weiß ich nicht mehr genau, ich glaube mich zu erinnern das die Schnittstellen intern und von Version zu Version unterschiedlich heißen.
Durch die ständige Änderung in den raspbian Versionen gab es immer wieder Änderungen vor allem beim Pi3, ich sollte diesen Wiki Artikel einfach löschen und neu machen und nur neues Raspbian berücksichtigen.
Ich installiere immer so und das funktioniert, egal welcher Pi -> http://heinz-otto.blogspot.de/2016/09/fhem-in-wenigen-schritten.html
Gruß Otto
Okay, also das fhem läuft ja.
Ich frage mich nur woran es liegt, dass das Homematic Modul immernoch nicht erkannt wird.
Kann es nicht an dieser Bluetooth Geschichte liegen?
Bzw. dass nichts von nichts von wegen ttyAMA0 oder ttyS0 in der /lib/systemd/system/hciuart.service steht?
edit: ich verwende den Raspberry Pi2B+
Du hast keinen Pi3, nur dort spielt das eine Rolle weil der die BT Schnittstelle original auf der UART hat.
Mach bitte das hier
Nimm ein frisches System: ein raspbian lite - kein noobs!
Nach der ersten Anmeldung:
im Terminalecho "enable_uart=1" >> /boot/config.txt
sed -i 's/\bconsole=serial0,115200 //' /boot/cmdline.txt
systemctl disable serial-getty@ttyAMA0.service
reboot
Wenn das nicht läuft, ist mit hoher Wahrscheinlichkeit dein Modul defekt.
Gruß Otto
ich hatte soeben Kontakt mit dem ELV Support. Die haben mir direkt zurückgeschrieben und meinten, dass sie mir ein neues Modul zusenden. Ich melde mich dann wieder, hoffentlich klappt es dann :)
Also hier nochmal das Update.
Es lag tatsächlich an dem Modul. Neues modul angeschlossen und alles hat funktioniert :)
Trotzdem vielen dank für deine Hilfe :)
Super, das freut mich. ;D
Zitat von: Otto123 am 02 Januar 2018, 20:14:25
Das hast Du erstmal fein gemacht :)
Aber wozu steht das in der cmdline.txt?
systemctl disable serial-getty@ttyAMA0.service
Streich das bitte raus, die Deti darf auch wirklich bloß aus einer Zeile ohne Zeilenumbruch am bestehen!
Das gehört da nicht hin. Das gehörte in die Kommandozeile.
Gruß Otto
Hallo Otto,
du schreibst in deinem Zitat das der befehl:
systemctl disable serial-getty@ttyAMA0.servicenicht in in die cmdline.txt kopiert werden soll sondern demnach rausgelöscht werden soll richtiG?
Wieso steht dann in der Fhem wiki anleitung das:
Den Dienst serial-getty deaktivieren
systemctl disable serial-getty@ttyAMA0.serviceich frag nur....
Gruss
Ich wiederhole mich:
Das gehört da nicht hin. Das gehörte in die Kommandozeile.
Ich habe es für Dich im Wiki konkretisiert. :-\
Nix konkretisiert [emoji17]
Gesendet von iPhone mit Tapatalk
ZitatDen Dienst serial-getty in der System Kommandozeile mit folgendem Befehl deaktivieren
systemctl disable serial-getty@ttyAMA0.service
Du musst im Browser F5 drücken?