Geräte einbinden in FHEM auf RPI und HomeMatic-Funkmodul klappt nicht

[Otto123]

Postest Du bitte Deine Dateien
/boot/config.txt
/boot/cmdline.txt
/lib/systemd/system/hciuart.service

Mit welchem Editor hast Du die geändert?

Gruß Otto

[Fargo]

Hallo Otto,

das sind die Dateien:

config.txt:

Code Auswählen Erweitern

# For more options and information see
# http://www.raspberrypi.org/documentation/configuration/config-txt.md
# 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

# FHEM Settings
dtoverlay=pi3-miniuart-bt
enable_uart=1
force_turbo=1



cmdline.txt:

Code Auswählen Erweitern

dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait


hcuiart.service:

Code Auswählen Erweitern

[Unit]
Description=Configure Bluetooth Modems connected by UART
ConditionPathIsDirectory=/proc/device-tree/soc/gpio@7e200000/bt_pins
Before=bluetooth.service
After=dev-ttyS0.device

[Service]
Type=forking
ExecStart=/usr/bin/hciattach /dev/ttyS0 bcm43xx 921600 noflow -

[Install]
WantedBy=multi-user.target


Geändert alles mit nano.

Grüße
Fargo

[Benni]

Nur mal so zwischendurch:

Ich hatte die letzten Tage auch mit dem RPI-Modul zu kämpfen, es wollte sich von meiner, eigentlich relativ aktuellen FHEM-Installation einfach nicht zuverlässig ansprechen lassen (zwar remote mittels socat, aber das spielte letzlich keine Rolle).
Die Symptome waren im Endeffekt die selben wie hier.

Anscheinend war wohl aber doch mein letztes Update zu lange her und letztendlich hat ein simples FHEM-Update zum Erfolg geführt. Ich habe das Modul seither stabil auf cond ok in FHEM eingebunden

Da ich im Threadverlauf nichts dazu gefunden habe, hier mal die Frage and den TE:

Ist dein FHEM aktuell?

Führe doch ggf. mal ein

Code Auswählen Erweitern


update


und anschließend (nach erfolgreich abgeschlossenem update, wenn die entsprechende Meldung kommt) ein

Code Auswählen Erweitern


shutdown restart


in der FHEM Befehlszeile aus (vorher ggf. ein save nicht vergessen)

Wenn ich's richtig überflogen habe wird im verlinkten Installations-Tutorial nämlich nicht die alleraktuellste FHEM-Version (nightly) per apt-get installiert, sondern das vremeintliche stable-Paket.

[Fargo]

Hi Benni,

danke für den Hinweis. Ich hatte FHEM erst vorgestern installiert, aber ich habe jetzt noch mal ein Update gemacht.
Sieht leider so aus, als wäre das auch noch nicht des Rätsels Lösung gewesen :/

Grüße
Fargo

[Benni]

Den Pi vllt nochmal komplett runter fahren und vom Strom trennen, um das RPI-Modul neu zu initialisieren?

Wenn das auch nichts hilft überlasse ich das Feld gerne wieder den Linux-Profis

[Otto123]

Wenn das auch nichts hilft überlasse ich das Feld gerne wieder den Linux-Profis

Mich kannst Du  damit nicht meinen 

Was mir nicht gefällt:

force_turbo=1

in der /boot/config.txt

Ich galube mich zu erinnern, das die serielle Schnittstelle da irgendwie "dranhängt".
Füge mal bitte anstatt dieser die Zeile ein:

Code Auswählen Erweitern

core_freq=250

Gruß Otto

[Fargo]

Das mit force_turbo=1 bzw. core_freq=250 hat wohl was damit zu tun, ob das Netzteil >2,5 mAh verträgt. Ich hab eins mit 3,0 mAh, das sollte also passen. In dem Falle sei force_turbo=1 zu bevorzugen. Ich habe es aber umgestellt und danach auch wieder den Strom abgezogen, keine Veränderung.

Gibt es noch weitere kreative Ideen? 

Viele Grüße
Fargo

[budy]

Ich denke, du solltest dein Problem mal im passenden Thread posten, denn da liegt bestimmt auch der Maintainer des Moduls mit. Ich selbst hatte auch Schwierigkeiten, mein HMUARTLGW auf meinem RPi2 zum Laufen zu bekommen, obwohl ich auch alles soweit korrekt gemacht hatte.

Allerdings hatte ich eine andere Raspian Version drauf, da ich den Pi nicht nur für FHEM, sondern auch noch für einige andere Dinge verwende. Weil ich den IO sowieso woanders haben wollte, habe ich dann einen alten, unbenutzten RPi1 genommen und dort ein minimales System installiert und auf diesem den HMUARTLGW eingebunden, was sofort problemlos funktionierte. Diesen Pi habe ich dann per socat mit meinem FHEM übers LAN verbunden.

Gruß,
Stephan

[Otto123]

Hallo Fargo,

ich befürchte Dein Modul ist defekt.
Ich schaue morgen mal, ob man die serielle Kommunikation separat testen kann.
Gruß Otto

[Otto123]

Hallo Fargo,

ich glaube die serielle Kommunikation kann man nicht so einfach testen.
Kannst Du mal das attr verbose im Modul auf 5 setzen und schauen was so im Logfile passiert?

Code Auswählen Erweitern

attr myHmUART verbose 5

Gruß Otto

[Fargo]

Hallo Otto,

das hört sich leider nicht so gut an.

Ich habe den Parameter geändert, jetzt sieht die Log so aus:

Code Auswählen Erweitern

2016.11.20 11:46:08 4: HMUARTLGW myHmUART Reopen
2016.11.20 11:46:08 3: myHmUART device closed
2016.11.20 11:46:08 3: Setting myHmUART serial parameters to 115200,8,N,1
2016.11.20 11:46:08 1: /dev/ttyAMA0 reappeared (myHmUART)
2016.11.20 11:46:09 4: HMUARTLGW myHmUART StartInit
2016.11.20 11:46:09 5: HMUARTLGW myHmUART send: 00 00
2016.11.20 11:46:09 5: HMUARTLGW myHmUART send: (8): fd00030001009e03
2016.11.20 11:46:09 5: SW: fd00030001009e03
2016.11.20 11:46:12 1: HMUARTLGW myHmUART did not respond for the 1. time, resending
2016.11.20 11:46:12 5: HMUARTLGW myHmUART send: (8): fd00030001009e03
2016.11.20 11:46:12 5: SW: fd00030001009e03
2016.11.20 11:46:15 1: HMUARTLGW myHmUART did not respond for the 2. time, resending
2016.11.20 11:46:15 5: HMUARTLGW myHmUART send: (8): fd00030001009e03
2016.11.20 11:46:15 5: SW: fd00030001009e03
2016.11.20 11:46:18 1: HMUARTLGW myHmUART did not respond for the 3. time, resending
2016.11.20 11:46:18 5: HMUARTLGW myHmUART send: (8): fd00030001009e03
2016.11.20 11:46:18 5: SW: fd00030001009e03
2016.11.20 11:46:21 1: HMUARTLGW myHmUART did not respond after all, reopening

Auch das Event Log sagt mir folgendes in Endlosschleife:

Code Auswählen Erweitern

2016-11-20 11:46:08 HMUARTLGW myHmUART CONNECTED
2016-11-20 11:46:09 HMUARTLGW myHmUART cond: init
2016-11-20 11:46:21 HMUARTLGW myHmUART cond: disconnected
2016-11-20 11:46:21 HMUARTLGW myHmUART CONNECTED
2016-11-20 11:46:22 HMUARTLGW myHmUART cond: init
2016-11-20 11:46:34 HMUARTLGW myHmUART cond: disconnected
2016-11-20 11:46:34 HMUARTLGW myHmUART CONNECTED
2016-11-20 11:46:35 HMUARTLGW myHmUART cond: init
2016-11-20 11:46:47 HMUARTLGW myHmUART cond: disconnected


Ich habe schon überlegt, ob ich das Teil beim Löten vielleicht kaputtgemacht habe, sowas habe ich vorher noch nie gemacht. Darf z.B. keine Brücke mit dem Lötzinn zwischen zwei Pins entstehen? Das ist bei mir hier und da der Fall. Aber ich hätte vermutet, dass es dann eher einfach gar nicht funktioniert.

Grüße
Fargo

[Otto123]

Das Modul funktioniert nicht.
Wenn Du Brücken aus Zinn zwischen Deinen Lötpunkten produziert hast kann es nicht gehen. Poste mal ein Foto von den Lötstellen.

Da musst Du mit etwas entlötlitze das überschüssige Zinn entfernen. Also ein Stück Kuperlitze geht ersatzweise.

Gruß Otto

[Fargo]

Ich bin momentan unterwegs, daher kann ich erst mal kein Foto machen. Aber ich weiß ja, was ich da gemacht habe 

Danke dir sehr für deine Hilfe, ich werde mir die Tage Entlötlitze und vor allem schmaleren Lötzinn kaufen, dann dürfte das klappen. Ich melde mich wieder, sobald ich das alles erledigt habe und hoffentlich eine Erfolgsmeldung geben kann!

Viele Grüße
Fargo

[Benni]

Ich habe mich wohl auch zu früh gefreut 

Nach es anfangs stabil zu laufen schien, habe ich inzwischen leider auch wieder einige Einträge im Log, so alle 15-30 Minuten, teilweise auch innerhalb von wenigen Minuten mehrfach:

Code Auswählen Erweitern


2016.11.20 13:56:19 1: HMUARTLGW HMUART1 did not respond for the 1. time, resending
2016.11.20 13:56:22 1: HMUARTLGW HMUART1 did not respond for the 2. time, resending
2016.11.20 13:56:25 1: HMUARTLGW HMUART1 did not respond for the 3. time, resending
2016.11.20 13:56:28 1: HMUARTLGW HMUART1 did not respond after all, reopening
2016.11.20 13:56:28 3: HMUART1 device closed
2016.11.20 13:57:32 1: 192.168.178.68:2000 reappeared (HMUART1)
2016.11.20 13:57:33 3: HMUARTLGW HMUART1 currently running Co_CPU_App
2016.11.20 13:57:34 3: HMUARTLGW HMUART1 currently running Co_CPU_BL
2016.11.20 13:57:34 3: HMUARTLGW HMUART1 currently running Co_CPU_App


Meine Lötstellen habe ich eben noch mal einer Sichtprüfung unterzogen, die sehen aber eigentlich ganz gut aus.
Vielleicht werde ich es aber trotzdem nochmal komplett ent- und neu verlöten.

[budy]

Moin Benni,

dein HMUARTLGW ist ja auch auf einem anderen RPi... hast du mal geprüft, ob du da vielleicht ein Netzwerk-Problem hast? Meiner läuft seit Wochen per socat ohne irgendeinen Dropout.

Gruß,
Stephan