Hallo zusammen,
ich versuche zurzeit, FHEM auf einem Raspberry Pi 3 mit dem UART-Modul HM-MOD-RPI-PCB von HomeMatic mit einigen Funkheizkörperthermostaten zum Laufen zu bringen.
Zunächst mal habe ich gemäß dieser Anleitung hier Raspbian Jesse Lite installiert und weiteren Schritte befolgt: http://www.meintechblog.de/2016/05/fhem-server-auf-dem-raspberry-pi-in-weniger-als-einer-stunde-einrichten/
Nebenbei habe ich mühsam (keinerlei Linux-Erfahrung ;D) das WLAN-Modul des RPI aktiviert mit dieser Anleitung: https://jankarres.de/2016/03/raspberry-pi-3-wlan-einrichten/
Nun habe ich FHEM erfolgreich installiert und über WLAN laufen, soweit kein Problem.
Im nächsten Schritt habe ich wie hier im Forum (https://forum.fhem.de/index.php/topic,54511.msg460972.html#msg460972) beschrieben das Funkmodul definiert und eine hmId vergeben, klappt ebenfalls:
define myHmUART HMUARTLGW /dev/ttyAMA0
attr myHmUART hmId ACDC11
Der nächste Schritt klappt dann leider nicht mehr: ich möchte das erste FHT einbinden. Dazu verusche ich, mit
set myHmUART hmPairForSec 600
in FHEM und der lange gedrückten Boost-Taste am FHT das ganze zu verbinden, finde allerdings nichts passendes (vielleicht erkenne ich es aber auch einfach nur nicht).
Ich habe hoffentlich keinen meiner Schritte vergessen und es ist einigermaßen verständlich. Ich bin leider mit meinem Latein am Ende, Neustarts etc. haben mich auch nicht weiter gebracht. Ich freue mich über jeden Hinweis ;)
Viele Grüße Fargo
Wie im Titel des verlinkten Beitrags zu sehen ist:
ZitatHMUARTLGW: Modul für HomeMatic UART-Modul (RPi) und HomeMatic LAN Gateway
Das Modul ist für Homematic-Geräte.
Zitatich möchte das erste FHT einbinden
FHT ist aber ein SlowRF-Abkömmling und lässt sich über ein HomeMatic-IO
NICHT verbinden - und das hat nichts mit FHEM zu tun.
FHT geht einwandfrei mit einem CUL-868 oder einem CUNO-868 - so hab ich meine FHT mit FHEM gepairt.
Edith: Ja ich weiß - HM sendet auch auf 868-MHz ... geht das nicht doch irgendwie ...
Kurz und knapp: Wenn das UART-Modul als rfmode SlowRF unterstützt dann vielleicht - sonst nicht.
Da ich die Entwicklung des UART-Moduls nur am Rande verfolgt habe weiß ich nicht ob es slowRF kann aber ich vermute mal nicht.
Und die Sendefrequenz ist vergleichbar mit der menschlichen Sprache.
HM wäre dann als Beispiel japanisch und FHT spricht "bayrisch" - beide sprechen eine menschliche Sprache (mehr oder weniger ::) ) aber ob sie sich verstehen ???
Hallo Fargo,
wenn du allerdings mit Funkheizkörperthermostaten ein HM-CC-RT-DN meinst dann sollte bei dir ein zusätzlicher Raum auftauchen der CUL-HM heißt. Dort sollte dann der Thermostat auftauchen.
Zitat von: Cobra am 18 November 2016, 20:31:32
Hallo Fargo,
wenn du allerdings mit Funkheizkörperthermostaten ein HM-CC-RT-DN meinst dann sollte bei dir ein zusätzlicher Raum auftauchen der CUL-HM heißt. Dort sollte dann der Thermostat auftauchen.
Daher darf man sich in einer freien Minute durchaus meinen angepinnten Beitrag durchlesen und die Frage entsprechend stellen.
Das würde so manche Glaskugel in die Rente schicken 8)
Allerdings setzte ich voraus das der Fragende den Unterschied zwischen FHT und HM-CC-RT-DN kennt und FHT nicht einfach global für
Funk-
Heizkörper-
Thermostat verwendet hat.
Zitat von: Puschel74 am 18 November 2016, 21:03:25
Daher darf man sich in einer freien Minute durchaus meinen angepinnten Beitrag durchlesen und die Frage entsprechend stellen.
Das würde so manche Glaskugel in die Rente schicken 8)
Allerdings setzte ich voraus das der Fragende den Unterschied zwischen FHT und HM-CC-RT-DN kennt und FHT nicht einfach global für Funk-Heizkörper-Thermostat verwendet hat.
Hallo Puschel,
ich meinte in der Tat die Funkheizkörper 105155 von HomeMatic, sorry. Ich dachte, in dem Kontext wäre das unmissverständlich - falsch gedacht, mir war nicht bewusst, dass es wohl Produkte mit dem Namen FHT gibt. Es gibt einen Grund, warum ich ins Anfängerforum geschrieben habe ;)
Hoffe mal, diese lassen sich mit meiner restlichen Hardware verbinden, sonst hätte ich den RPI und das Funkmodul umsonst gekauft.
Entschuldigt noch mal die Verwirrung ???
Viele Grüße
Fargo
Edit:
Zitat von: Cobra am 18 November 2016, 20:31:32
Hallo Fargo,
wenn du allerdings mit Funkheizkörperthermostaten ein HM-CC-RT-DN meinst dann sollte bei dir ein zusätzlicher Raum auftauchen der CUL-HM heißt. Dort sollte dann der Thermostat auftauchen.
Leider gibt es keinen zusätzlichen Raum oder irgendetwas anderes Zusätzliches, daher komme ich leider nicht weiter :/
Moin Fargo,
fangen wir mal am Anfang an. Zeig doch mal einen list deines UARTS:
list myHmUART
Dann habe ich eigentlich immer eine tail -f auf das aktuelle fhem.log offen, wenn ich irgendetwas mit neuen devices anstelle, da man da gleich sehen kann, was da abgeht - oder eben auch nicht. Wenn du das mal machst und dann den Booster-Taster für mehr als 4s drückst, dann sollte der RT für 30s in den Anlernmodus gehen. Gleichzeitig sollte im Logfenster einiges an Kommunikation durchlaufen, wenn der FHEM den RT sehen kann.
Gruß,
Stephan
Hallo budy,
bei mir sieht das Ergebnis von list myHmUART so aus:
Internals:
CNT 1
DEF /dev/ttyAMA0
DevState 1
DevType UART
DeviceName /dev/ttyAMA0@115200
FD 5
LastOpen 1479544114.77515
NAME myHmUART
NR 20
PARTIAL
STATE opened
TYPE HMUARTLGW
XmitOpen 0
Helper:
Ackpending:
1:
cmd 00
dst 0
frame FD00030001009E03
time 1479544115.7776
LastSendLen:
3
Log:
IDs:
Readings:
2016-11-19 09:17:12 D-type HM-MOD-UART
2016-11-19 09:28:35 cond init
2016-11-19 09:17:12 loadLvl suspended
2016-11-19 09:28:34 state opened
Attributes:
hmId ACDC11
room Wohnzimmer,Arbeitszimmer,Schlafzimmer,Flur,Küche,Badezimmer
Ich bin auf die Log gegangen, um überhaupt mal zu schauen was man da sehen kann. Es sieht so aus, als läge es an Verbindungsproblemen des Funkmoduls, denn die folgende Meldung wiederholt sich quasi endlos:
2016.11.19 09:29:26 3: Setting myHmUART serial parameters to 115200,8,N,1
2016.11.19 09:29:26 1: /dev/ttyAMA0 reappeared (myHmUART)
2016.11.19 09:29:30 1: HMUARTLGW myHmUART did not respond for the 1. time, resending
2016.11.19 09:29:33 1: HMUARTLGW myHmUART did not respond for the 2. time, resending
2016.11.19 09:29:36 1: HMUARTLGW myHmUART did not respond for the 3. time, resending
Wo und wie ich "eine tail -f auf das aktuelle fhem.log" öffnen kann, verstehe ich nicht ganz :-[
Viele Grüße
Fargo
Moin Fargo,
bist Du auch nach offiziellen Anleitungen vorgegangen? Kannst Du bitte Deine Einrichtung entsprechenden des Wikis und der dommandref prüfen!
http://www.fhemwiki.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi
Nach dem was Du sagst gibt es sicher ein Problem mit den seriellen Schnittstellen.
Gruß Otto
Ich würde da Otto recht geben... dein UARt sollte schon ein wenig mehr ausgeben, z.B. seine Fimware Version in den Readings. Ich gehe auch mal davon aus, dass das Teil nicht eichtig eingebungen ist.
Bei mir sehen die Readings so aus:
Readings:
2016-11-18 13:54:17 D-HMIdAssigned 29A07E
2016-11-18 13:54:17 D-HMIdOriginal 4C3ED9
2016-11-18 13:54:17 D-firmware 1.4.1
2016-11-18 13:54:17 D-serialNr NEQ0605573
2016-11-18 13:53:58 D-type HM-MOD-UART
2016-11-18 13:54:17 cond ok
2016-11-19 11:58:25 load 15
2016-11-18 13:54:17 loadLvl low
2016-11-18 13:54:12 state opened
Bei dir steht bei state: init, dass bedeutet, dass das Device noch gar nicht richtig konfiguriert ist.
Gruß,
Stephan
Zitat von: Otto123 am 19 November 2016, 09:56:23
Moin Fargo,
bist Du auch nach offiziellen Anleitungen vorgegangen? Kannst Du bitte Deine Einrichtung entsprechenden des Wikis und der dommandref prüfen!
http://www.fhemwiki.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi
Nach dem was Du sagst gibt es sicher ein Problem mit den seriellen Schnittstellen.
Gruß Otto
Die Einstellungen habe ich jetzt auch alle vorgenommen, anschließend neu gestartet und den RPI sogar einmal vom Strom genommen. Die Meldungen sind unverändert, es bleibt bei cond = init und ich finde keine Geräte.
Gibt es noch weitere Einstellungen, die ich eventuell übersehen habe?
Grüße
Fargo
Hi,
dann für mal bitte folgendes im Terminal (Betriebssystem) aus:ls -l /dev/ttyAMA0und poste die Ausgabe.
Gruß Otto
Hi Otto,
das Resultat sieht so aus:
crw-rw---- 1 root dialout 204, 64 Nov 19 15:29 /dev/ttyAMA0
Grüße
Fargo
Ist der Benutzer, der FHEM startet auch in der Gruppe dialout und darf somit das Device öffnen?
getent group dialout
Da müsste der FHEM User mit auftauchen.
Gruß,
Stephan
Wenn ich den Befehl ins Terminal eingebe, erscheint folgende Meldung:
dialout:x:20:pi
Ich weiß zwar nicht, was es bedeutet, aber ich kann mich auch nicht erinnern, etwas an diesen Einstellungen angepasst zu haben. Wie müsste ich das denn machen?
Viele Grüße
Fargo
Soweit erstmal alles ok, sieht bei mir auch so aus...
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
Hallo Otto,
das sind die Dateien:
config.txt:
# 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:
dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
hcuiart.service:
[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
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
update
und anschließend (nach erfolgreich abgeschlossenem update, wenn die entsprechende Meldung kommt) ein
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.
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
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 ;)
Zitat von: Benni am 19 November 2016, 17:05:14
Wenn das auch nichts hilft überlasse ich das Feld gerne wieder den Linux-Profis ;)
Mich kannst Du damit nicht meinen :-X
Was mir nicht gefällt:
Zitatforce_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:
core_freq=250Gruß Otto
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
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
Hallo Fargo,
ich befürchte Dein Modul ist defekt.
Ich schaue morgen mal, ob man die serielle Kommunikation separat testen kann.
Gruß Otto
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?
attr myHmUART verbose 5
Gruß Otto
Hallo Otto,
das hört sich leider nicht so gut an.
Ich habe den Parameter geändert, jetzt sieht die Log so aus:
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:
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
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
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
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:
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.
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
Hi Benni,
ich denke auch Du hast ein anderes Problem als Fargo.
Gruß Otto
Danke für die Hinweise!
Ich habe mit einem zweiten Modul (im Austausch am selben Pi) die selben Probleme, von daher schließe ich das Modul und dessen Verlötung auch erst mal aus.
Ich werde mal noch etwas rumprobieren...
Ich habe hier noch einen 2. Pi rumliegen, dann kann ich das mal noch per LAN-Anbindung, statt WLAN versuchen (anderes Dongle hätte ich auch noch) oder mal mit Pi-lokalem FHEM. Einen nodeMCU habe ich inzwischen auch noch da ....
Da sind also noch einige Möglichkeiten offen ;D
Ich werde ggf. berichten und den Thread erst mal wieder für Fargos Problem frei machen :)
Hi Benni,
dir viel Erfolg bei der Fehlersuche!
Bei mir wird es noch etwas dauern... ich musste mir erst mal einen neuen Lötkolben bestellen, meiner ist ein Vorkriegsmodell und wird nicht heiß genug. Habe das Funkmodul wahrscheinlich schon zu sehr angeschmolzen - Anfänger zahlt Lehrgeld ::)
Grüße
Fargo
Hallo zusammen,
ich kann zum Abschluss dieses Themas vermelden, dass ich das Funkmodul neu verlötet habe und nun geht es.
Danke noch mal an alle, die hilfreichen Input geliefert haben!
Viele Grüße
Fargo