[Erweiterung] -> HM-MOD-RPI-PCB HomeMatic Funkmodul für Raspberry Pi HomeMatic

[Kermit20]

Hallo,

da das Modul sicherlich an Verbreitung zunehmen wird, habe ich mir erlaubt (angelehnt an  Teile des bestehenden Artikels) die Aktivierung von UART für die Inbetriebnahme des Moduls für Wheezy zu ergänzen.

Kann das bei Zustimmung bitte jemand einpflegen ?

Ergänzung:

Code Auswählen Erweitern

Aktivierung der seriellen / UART Schnittstelle beim Raspberry Pi 2

Diese Beschreibung gilt für Wheezy Version Stand 26.07.2016.

Die Datei /boot/config.txt um diese Zeile ergänzen

enable_uart=1

In der Datei /boot/cmdline.txt diesen Eintrag löschen:

console=ttyAMA0,115200 

Die Datei sollte dann den folgenden Inhalt aufweisen:

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

Den Dienst serial-getty deaktivieren

in der Datei /etc/inittab wie folgt die Zeile (ziemlich am Ende) mit einer # auskommentieren

# T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100

Das System neu starten!

Tipp: Sollte euer HM-MOD-RPI-PCB nach der Einrichtung immer wieder den Status zwischen init und disconnect wechseln, schaut die aufgeführten Punkte erneut nach und macht ggf. einen reboot.



[Otto123]

Hallo ,

Kann ich machen  ich habe ja auch den Jessie Teil geschrieben

Ich setze mich die nächsten Tage dran, vielleicht hat ja noch jemand eine Ergänzung.

Gruß Otto

[Kermit20]

Da würde ich direkt mal in die Breche springen und wiederholt deine Vorlage nutzen um das FW Update zu beschreiben:

HowTo Firmware Update HM-MOD-RPI-PCB

Vorbereitende Schritte

# 1. Ordner von git kopieren
git clone git://git.zerfleddert.de/hmcfgusb
# 2. In den Ordner wechseln
cd hmcfgusb/
# 3. Fehlende Pakete nachinstallieren
apt-get install libusb-1.0-0-dev build-essential git
# 4. Kompilieren
make
# 5. Firmware runterladen
wget https://raw.githubusercontent.com/eq-3/occu/ee68faf77e42ed5e3641790b43a710a3301cea7e/firmware/HM-MOD-UART/coprocessor_update.eq3

Flashen der neuen Firmware

# 6. Modul vorher von FHEM "disconnecten" // set close
# 7. Flashbefehl aus dem Ordner "hmcfgusb/" heraus ausführen
./flash-hmmoduart -U /dev/ttyAMA0 coprocessor_update.eq3
# 8. Modul in FHEM wieder verbinden
# 9. Firmware Version checken

Flashvorgang RPi:

###################################

pi@pi ~/hmcfgusb $ ./flash-hmmoduart -U /dev/ttyAMA0 coprocessor_update.eq3
HM-MOD-UART flasher version 0.102-git

Reading firmware from coprocessor_update.eq3...
Firmware with 43 blocks successfully read.
Waiting for bootloader to settle...

HM-MOD-UART opened.

Flashing 43 blocks: |

Firmware update successfull!

###################################

Hinweis: Das Update hat ca. 20 - 30 Sekunden gedauert

[Kermit20]

Ein Punkt der mir noch fehlt ist die Beschreibung, wie man nun mit diesem Modul andere Geräte Updatet.... was meine ich gehen soll

[Otto123]

Ich dachte Firmware Update unter FHEM ist vom IO unabhängig, falls er es kann?

Die beiden anderen Dinge habe ich ins Wiki in einer ersten Version übernommen

Gruß Otto

[Kermit20]

Guten Morgen, ja da hast du recht... ich habe 3 Devices für neue Firmware und habe scheinbar immer etwas falsch gemacht oder die Prozedur ist anders bei 2 Geräten (Funkgong und Stromzähler) bei meinem Zwischenstecker hat es dann geklappt... daher würde sich maximal eine Zusammenfassung lohnen, bzw. Der andere Artikel muss nach Erprobung erweitert werden.

Gesendet von meinem HUAWEI CRR-L09 mit Tapatalk

[Leeloo_Dallas]

Hallo zusammen,

Danke für eure Arbeit. Ich habe das Modul gerade ohne größere Schwierigkeiten in Betrieb genommen.

Ggf. könntet Ihr noch ins Wiki sowie in Otto's-Blog aufnehmen, dass das Flashen des Modul nur funktionieren kann, wenn auch die Jumperoberfläche J1 entsprechend gebrückt wurde.

Gruß
Leeloo

[Otto123]

Ggf. könntet Ihr noch ins Wiki sowie in Otto's-Blog aufnehmen, dass das Flashen des Modul nur funktionieren kann, wenn auch die Jumperoberfläche J1 entsprechend gebrückt wurde.

Hi Leelo,

das flashen hat bei mir immer ohne funktioniert.
Es gab noch die Varianten GPIO18 zu setzen damit das Modul mit alter Firmware überhaupt läuft.

Gruß Otto

[Leeloo_Dallas]

Hallo Otto,

ich habe heute morgen mein FHEM von "PI 1 und Busware CCD" auf einen "PI 2 mit HM-MOD-RPI-PCB-Modul" => umziehen lassen.
Mittels "Backup" und "Restore" habe ich die komplette Installation somit übernommen. Zusätzlich bin ich dem Ablauf aus Wiki bzw. aus deinem Blog gefolgt.

Da ich nicht alle Devices neu anlernen wollte, hab ich die Definition des "alten Busware CCD" nach "HM-MOD-RPI-PCB" geändert.
Bevor ich einen kompletten Systemtest mache, wollte ich noch auf die aktuellste Firmware umsteigen.
Dabei konnte ich leider erst dann Flashen (alle beschriebenen/bekannten Varianten durchprobiert) als ich den "Jumper" gebrückt habe.
Das mit dem GPIO18 hab ich erst jetzt, nach Deinem Hinweis, bei Deinen Notizen gefunden.

Meine Konfiguration scheint auch soweit zu laufen, nur die "Remotes", bei welchen ich bereits zuvor "AES" verwendet hab, zicken noch rum.
Ich muss mir das Ganze nochmals anschauen, ich denke es hängt daran, dass im "neuen HM-MOD-RPI-PCB-Modul" noch der Default-Wert gesetzt ist.
Noch stehe ich auf dem Schlauch, wo und wie ich das drehen kann. An meinen VCCU- Definition hat sich ja nichts geändert.

LG
Leeloo

Nachtrag:
Wird das Attribut "hmKey" auch auf dem Device "HM-MOD-RPI-PCB-Modul" gesetzt, dann funktionieren die Remotes.
Es ist wohl ähnlich wie mit der hmId. Dieses Attribut muss ja auch "real" sowie "virtuell" gesetzt werden.

[Otto123]

Hallo Leelo,

naja über GPIO18 könnte man ein Reset des Moduls machen.
Laut Doku würde GPIO17 über den Jumper auf den Programmiereingang wirken. Also der Jumper würde nur den Anschluss an GPIO17 bewirken. GPIO17 müsste dann auch noch definiert gesetzt werden.

Komisch, ich glaube ich habe nirgendwo gelesen, dass jemand den Jumper zum flashen setzen musste.

Und diese Diskussion besagt eigentlich, dass es eine völlig andere Programmierschnittstelle ist.

Gruß Otto

[JimPanse]

Nabend,

erst mal danke für die tollen Anleitungen im Wiki.
Ich habe heute auch das Modul erhalten und wollte es einbinden. Bis zu dem Punkt wo ich das Gerät in FEHM definiere, funktioniert es auch.
Nur jetzt habe ich 2 Probleme.

1. Ich habe festgestellt, dass FHEM nicht mehr automatisch startet wenn ich den Rasp neustarte
und
2. Und mein Logfile sieht leider so aus:

Code Auswählen Erweitern

2016.12.20 23:26:08 1: HMUARTLGW myHmUART did not respond for the 1. time, resending
2016.12.20 23:26:11 1: HMUARTLGW myHmUART did not respond for the 2. time, resending
2016.12.20 23:26:14 1: HMUARTLGW myHmUART did not respond for the 3. time, resending
2016.12.20 23:26:17 1: HMUARTLGW myHmUART did not respond after all, reopening
2016.12.20 23:26:17 3: myHmUART device closed
2016.12.20 23:26:17 3: Setting myHmUART serial parameters to 115200,8,N,1
2016.12.20 23:26:17 1: /dev/ttyAMA0 reappeared (myHmUART)
2016.12.20 23:26:21 1: HMUARTLGW myHmUART did not respond for the 1. time, resending
2016.12.20 23:26:24 1: HMUARTLGW myHmUART did not respond for the 2. time, resending
2016.12.20 23:26:27 1: HMUARTLGW myHmUART did not respond for the 3. time, resending
2016.12.20 23:26:30 1: HMUARTLGW myHmUART did not respond after all, reopening
2016.12.20 23:26:30 3: myHmUART device closed
2016.12.20 23:26:30 3: Setting myHmUART serial parameters to 115200,8,N,1
2016.12.20 23:26:30 1: /dev/ttyAMA0 reappeared (myHmUART)


Kann mir einer sagen was ich verbockt habe?

[MadMax-FHEM]

Komisch, ich glaube ich habe nirgendwo gelesen, dass jemand den Jumper zum flashen setzen musste.

Kann ich nur zustimmen: ich musste auch nix "jumpern" um zu flashen...


@JimPanse: bereits neueste FW geflasht!?

[JimPanse]

@MadMax: Danke für den Hinweis, habe ich jetzt gemacht, aber sieht nicht viel besser aus

Code Auswählen Erweitern

2016.12.21 00:12:36 1: Including fhem.cfg
2016.12.21 00:12:36 3: telnetPort: port 7072 opened
2016.12.21 00:12:36 3: WEB: port 8083 opened
2016.12.21 00:12:36 3: WEBphone: port 8084 opened
2016.12.21 00:12:36 3: WEBtablet: port 8085 opened
2016.12.21 00:12:36 2: eventTypes: loaded 0 events from ./log/eventTypes.txt
2016.12.21 00:12:36 3: Opening myHmUART device /dev/ttyAMA0
2016.12.21 00:12:36 3: Setting myHmUART serial parameters to 115200,8,N,1
2016.12.21 00:12:36 3: myHmUART device opened
2016.12.21 00:12:36 1: Including ./log/fhem.save
2016.12.21 00:12:36 1: usb create starting
2016.12.21 00:12:37 1: usb create end
2016.12.21 00:12:37 0: Featurelevel: 5.7
2016.12.21 00:12:37 0: Server started with 14 defined entities (fhem.pl:12804/2016-12-17 perl:5.020002 os:linux user:fhem pid:781)
2016.12.21 00:12:41 1: HMUARTLGW myHmUART did not respond for the 1. time, resending
2016.12.21 00:12:44 1: HMUARTLGW myHmUART did not respond for the 2. time, resending
2016.12.21 00:12:47 1: HMUARTLGW myHmUART did not respond for the 3. time, resending
2016.12.21 00:12:50 1: HMUARTLGW myHmUART did not respond after all, reopening
2016.12.21 00:12:50 3: myHmUART device closed
2016.12.21 00:12:50 3: Setting myHmUART serial parameters to 115200,8,N,1
2016.12.21 00:12:50 1: /dev/ttyAMA0 reappeared (myHmUART)

Verstehe ich das richtig das er das Modul anfangs einmal richtig startet?

[MadMax-FHEM]

Deaktiviere doch mal den initial usb check:

Code Auswählen Erweitern

attr initialUsbCheck disable 1

Welchen PI hast du??

Bei einem PI3 läuft z.B. das BlueTooth-Modul auch auf /dev/ttyAMA0...
...folgendes könnte helfen:

http://heinz-otto.blogspot.de/2016/07/raspberry-pi-homematic-modul.html

Danke Otto!

Gruß, Joachim

[JimPanse]

@MadMax

Ich habe einen Raspi 3

Der Usb Check ist jetzt aus, der Rest leider wie gehabt...

Code Auswählen Erweitern

2016.12.21 00:37:48 1: Including fhem.cfg
2016.12.21 00:37:48 3: telnetPort: port 7072 opened
2016.12.21 00:37:49 3: WEB: port 8083 opened
2016.12.21 00:37:49 3: WEBphone: port 8084 opened
2016.12.21 00:37:49 3: WEBtablet: port 8085 opened
2016.12.21 00:37:49 2: eventTypes: loaded 4 events from ./log/eventTypes.txt
2016.12.21 00:37:49 3: Opening myHmUART device /dev/ttyAMA0
2016.12.21 00:37:49 3: Setting myHmUART serial parameters to 115200,8,N,1
2016.12.21 00:37:49 3: myHmUART device opened
2016.12.21 00:37:49 1: Including ./log/fhem.save
2016.12.21 00:37:49 0: Featurelevel: 5.7
2016.12.21 00:37:49 0: Server started with 14 defined entities (fhem.pl:12804/2016-12-17 perl:5.020002 os:linux user:fhem pid:789)
2016.12.21 00:37:53 1: HMUARTLGW myHmUART did not respond for the 1. time, resending
2016.12.21 00:37:56 1: HMUARTLGW myHmUART did not respond for the 2. time, resending
2016.12.21 00:37:59 1: HMUARTLGW myHmUART did not respond for the 3. time, resending
2016.12.21 00:38:02 1: HMUARTLGW myHmUART did not respond after all, reopening
2016.12.21 00:38:02 3: myHmUART device closed
2016.12.21 00:38:02 3: Setting myHmUART serial parameters to 115200,8,N,1
2016.12.21 00:38:02 1: /dev/ttyAMA0 reappeared (myHmUART)

Bin auch eigentlich mehr oder weniger nach Otto's Blog/ Wiki vorgegenagen

[MadMax-FHEM]

Hmmm,

nach dem Flashen mal gebootet?
(ich weiß normalerweise heißt es das bei Windoof: boot tut gut...   / aber wer weiß und schaden kann's mal nicht)

Ist der PI up-to-date?

Also
sudo apt-get update
sudo apt-get upgrade

Weil je nachdem das passende overlay eingetragen werden muss...

Hab jetzt Otto's Blog nicht im Detail durchgelesen aber ich habe (zusätzlich) BlueTooth komplett deaktiviert...
...da ich es aktuell (noch) nicht brauche.

Ansonsten gehen mir (für heute) langsam die Ideen aus...
...bei mir lief die Installation eigentlich ganz einfach...

Das sind mal meine Notizen (ohne Gewähr, Kontrolle o.ä.) und sicher nicht so gut wie der Blog bzw. Wiki:

Disable BlueTooth:

sudo systemctl disable hciuart

sudo nano /boot/config.txt

# disable bluetooth
# alt:
#dtoverlay=pi3-disable-bt
dtoverlay=pi3-miniuart-bt
enable_uart=1
dtoverlay=pi3-miniuart-bt-overlay

Ansonsten habe ich nur noch den HMUART geflasht, fhem installiert und dann den HMUART definiert eine HMID vergeben und eine vccu angelegt...

Viel Erfolg, Joachim

P.S.: evtl. mal ein list des HMUART posten:

Code Auswählen Erweitern

list myHmUART

[JimPanse]

Ok Bluetooth habe ich jetzt deaktiviert.

Und ja habe den PI inzwischen mehrfach neu gestartet.
Kann dass evtl. damit zusammen hängen das FHEM nicht mehr automatisch startet?

Der Tipp mit der List des HMUART war ganz gut, aus welchem Grund auch immer wurde die Firmware nicht geflasht:

Code Auswählen Erweitern

Internals:
   CNT        1
   DEF        /dev/ttyAMA0
   DevState   1
   DevType    UART
   DeviceName /dev/ttyAMA0@115200
   FD         5
   LastOpen   1482279237.48201
   NAME       myHmUART
   NR         24
   PARTIAL
   STATE      opened
   TYPE       HMUARTLGW
   XmitOpen   0
   Helper:
     Ackpending:
       1:
         cmd        00
         dst        0
         frame      FD00030001009E03
         time       1482279238.4843
     LastSendLen:
       3
     Log:
       IDs:
   Readings:
     2016-12-20 23:10:21   D-HMIdAssigned  123456
     2016-12-20 23:08:34   D-HMIdOriginal  4F64B1
     2016-12-20 23:08:34   D-firmware      1.2.1
     2016-12-20 23:08:34   D-serialNr      NEQ1329046
     2016-12-21 01:13:05   D-type          HM-MOD-UART
     2016-12-21 01:13:58   cond            init
     2016-12-20 23:13:35   load            1
     2016-12-21 01:13:05   loadLvl         suspended
     2016-12-21 01:13:57   state           opened
Attributes:
   hmId       123456

[Otto123]

Guten Morgen,

Hab jetzt Otto's Blog nicht im Detail durchgelesen aber ich habe (zusätzlich) BlueTooth komplett deaktiviert...

Soviel ist es doch nicht
Ich glaube das ist auch nicht sauber:

dtoverlay=pi3-miniuart-bt
enable_uart=1
dtoverlay=pi3-miniuart-bt-overlay

Ich hatte verstanden, das eine oder das andere Overlay!?

Die Firmware wird noch alt angezeigt!

D-firmware      1.2.1

Wirklich geflashed?

Und nochmal der wichtige Hinweis:
Sollten beim Firmwareupdate hartnäckig Fehler auftreten (oder einfach nichts passieren) muss das Modul mal vom Strom getrennt werden, neustart reicht nicht!

Was gibt

Code Auswählen Erweitern

ls -l /dev/ttyAMA0aus?

Wenn FHEM nicht automatisch startet: Auszug von hier

Dagegen helfen zwei Methoden, entweder man macht den Start von fhem vom Netzwerk oder dem ntp Dienst abhängig,
# Den Systemstart von ntp abhängig machen

Code Auswählen Erweitern

sed -i s/'# Required-Start:       $local_fs $remote_fs/# Required-Start:       $local_fs $remote_fs $ntp/' /etc/init.d/fhem
systemctl daemon-reload
oder man fügt am Anfang vom Startscript /etc/init.d/fhem ein "sleep 10" ein.

Gruß Otto

[MadMax-FHEM]

Guten Morgen,Soviel ist es doch nicht
Ich glaube das ist auch nicht sauber:Ich hatte verstanden, das eine oder das andere Overlay!?

Jaja, ist nicht so viel
Aber da der Blog kam als mein Modul bereits lief habe ich den (nachträglich) nicht mehr durchgelesen...



Jep richtig nur ein overlay.
Aber mit jedem update/upgrade des PI-Linux (versch. Jessie "versionen") kam ein anderes overlay...

Daher ist ja eins bereit auskommentiert...

Ich nehme an, dass die liste von oben nach unten abgearbeitet wird

Daher würde ich denken das letzte overlay reicht (bei mir).
Bzw. kommt es (gefühlt) drauf an welche "Version" (also wann der letzte update/upgrade war)...


Gruß, Joachim

[Leeloo_Dallas]

Moin,

ich fand es ja auch komisch, aber wie bereits geschrieben konnte ich erst dann flashen, als ich diesen Jumper gebrückt hatte.
Aus diesem Grund hatte ich es euch auch zurück gemeldet.

LG
Leeloo

[JimPanse]

Ich glaube jetzt läuft es.
Musste wohl wirklich das Modul vom PI anziehen, erst dachte ich es reicht den PI vom Netz zu nehmen.
Mein Logfile sieht jetzt so aus:

Code Auswählen Erweitern

2016.12.21 11:18:16 1: Including fhem.cfg
2016.12.21 11:18:16 3: telnetPort: port 7072 opened
2016.12.21 11:18:16 3: WEB: port 8083 opened
2016.12.21 11:18:16 3: WEBphone: port 8084 opened
2016.12.21 11:18:16 3: WEBtablet: port 8085 opened
2016.12.21 11:18:16 2: eventTypes: loaded 4 events from ./log/eventTypes.txt
2016.12.21 11:18:16 3: Opening myHmUART device /dev/ttyAMA0
2016.12.21 11:18:16 3: Setting myHmUART serial parameters to 115200,8,N,1
2016.12.21 11:18:16 3: myHmUART device opened
2016.12.21 11:18:16 1: Including ./log/fhem.save
2016.12.21 11:18:16 0: Server shutdown
2016.12.21 11:23:34 1: Including fhem.cfg
2016.12.21 11:23:34 3: telnetPort: port 7072 opened
2016.12.21 11:23:35 3: WEB: port 8083 opened
2016.12.21 11:23:35 3: WEBphone: port 8084 opened
2016.12.21 11:23:35 3: WEBtablet: port 8085 opened
2016.12.21 11:23:35 2: eventTypes: loaded 4 events from ./log/eventTypes.txt
2016.12.21 11:23:35 3: Opening myHmUART device /dev/ttyAMA0
2016.12.21 11:23:35 3: Setting myHmUART serial parameters to 115200,8,N,1
2016.12.21 11:23:35 3: myHmUART device opened
2016.12.21 11:23:35 1: Including ./log/fhem.save
2016.12.21 11:23:35 0: Featurelevel: 5.7
2016.12.21 11:23:35 0: Server started with 14 defined entities (fhem.pl:12804/2016-12-17 perl:5.020002 os:linux user:fhem pid:625)

FHEM startet jetzt auch wieder, habe einfach das "sleep 10" aus der Datei wieder entfernt, jetzt läuft es.

Und der Vollständigkeit halber hier noch die Ausgabe von ls -l /dev/ttyAMA0

Code Auswählen Erweitern

pi@raspberrypi:~ $ ls -l /dev/ttyAMA0
crw-rw---- 1 root dialout 204, 64 Dez 21 11:28 /dev/ttyAMA0


Danke für eure Hilfe, dann kann es ja jetzt weiter gehen

[Otto123]

Hi JimPanse,

und die Firmware stimmt jetzt?

Gruß Otto

[JimPanse]

Hallo Otto,

ja ist jetzt auf FM 1.4.1

Gruß
Sascha

[Otto123]

Moin,

das verstehe ich noch nicht:

FHEM startet jetzt auch wieder, habe einfach das "sleep 10" aus der Datei wieder entfernt, jetzt läuft es.

Ich war bisher der Meinung falls der Start von FHEM klemmt hilft es wenn im Script sleep 10 steht und nicht das es dann den Start verhindert?

Gruß Otto

[Ray_Tracer]

Hi,

ich verwende das Modul übrigens an meinem FreeBSD 10.3 Server via USB FTDI seriell Adapter:

(http://thumbnails117.imagebam.com/52394/00c8c4523933583.jpg)

Nach dem Verkabeln mit etwas Wrap-Draht den USB TTL Adapter auf 3,3V stellen und anschließen:

Code Auswählen Erweitern


ugen1.4: <FTDI> at usbus1
uftdi0: <FT232R USB UART> on usbus1


Das entsprechende Kernelmodul wird automatisch geladen und das HM-MOD-RPI kann dann einfach via cua-Device angesprochen werden:

Code Auswählen Erweitern


define HMU HMUARTLGW /dev/cuaU0


Weitere Einstellungen (Baudrate, getty etc.) sind nicht notwendig.
Flashen via FHEM geht auch.

Die Devicenamen/-nummern können natürlich je nach Chip auf dem USB-TTL varieren...

[koitsch]

Hallo, ich weiß nicht ob ich hier richtig bin.
Ich habe einen neuen RPi 2 mit fhem mit dem  HM-MOD-RPI-PCB HomeMatic Funkmodul nach der Anleitung im WIKI aufgesetzt.
Das System sowie das fhem ist aktuell.

Wenn ich jetzt das Device definiere:
define myHmUART HMUARTLGW /dev/ttyAMA0
attr myHmUART hmId xxxxxx

kommt folgender Fehler:
ERROR:
Unknown module HMUARTLGW

Woran kann das liegen ? Muß ich noch ein Modul aktivieren?

Vielleicht kann mir jemand helfen?

Gruß Vinzent

[Otto123]

Hallo Vinzent,

ich denke Du musst einfach Update von FHEM machen. Das Modul ist erst ab Juli 2016  verfügbar und somit in der download Version 5.7 von 2015 nicht enthalten.

Gruß Otto

[koitsch]

Hallo Otto,

vielen Dank für die schnelle Antwort. Ich habe die Installation nach Deiner hervorragenden Anleitung gemacht.

Ja auch nach einem Update vom FHEM mit : UPD FHEM/00_HMUARTLGW.pm in der List of new / modified files --- fehlt im Verzeichnis /opt/fhem/FHEM$ das Modul 00_HMUARTLGW.pm !!! Nur das HM-Modul 00_HMLAN.pm ist vorhanden.

Wo kann ich das Modul herbekommen?

Viele Grüße aus Cottbus
Vinzent

[ph1959de]

Hallo, ich weiß nicht ob ich hier richtig bin.
Ich habe ...

Hmmm... eher nicht. Könntest Du / Ihr die Diskussion bitte vorzugsweise im Thread HMUARTLGW: Modul für HomeMatic UART... weiterführen? Hier geht's eher rein um die Wiki-Seite zu dem Modul.

Danke, Peter

[Otto123]

Hallo Vinzent,

einfach über ganz normal "update" . Also update ohne weitere Parameter in der Kommandozeile.

Ein Verzeichnis /opt/fhem/FHEM$ gibt es nicht, das Verzeichnis heißt /opt/fhem/FHEM

Was gibt dir version aus ?

Gruß Otto

[koitsch]

Hallo Otto,

vielen Dank für Deine Hilfe. Ich habe immer ein Update mit Parameter "update fhem" gemacht.
Ja mit einem "update" sieht es ganz anders aus; jetzt werden die Module geladen und ich kann das Device definieren.
Jetzt habe ich nur noch das Problem mit :
2017-01-16 01:59:45 HMUARTLGW HMUART1 DISCONNECTED
2017-01-16 01:59:48 HMUARTLGW HMUART1 cond: disconnected
2017-01-16 01:59:48 HMUARTLGW HMUART1 CONNECTED
2017-01-16 01:59:49 HMUARTLGW HMUART1 cond: init
2017-01-16 01:59:50 HMUARTLGW HMUART1 DISCONNECTED
2017-01-16 01:59:53 HMUARTLGW HMUART1 cond: disconnect

Ich denke, dazu werde ich noch etwas im Forum finden.
Nochmal vielen Dank.
Gruß Vinzent

[Otto123]

Moin Vinzent,

da arbeitet die serielle Schnittstelle nicht richtig.
Geh noch mal die Schritte im Wiki durch! Überprüfe die Rechte auf der Schnittstelle.

Schau eventuell hier mit rein -> http://heinz-otto.blogspot.de/2016/09/fhem-in-wenigen-schritten.html
Ich habe das aktuell für Pi3 und Pi2 genauso aufgesetzt.

Gruß Otto

[ph1959de]

Ich bitte nochmal darum, die technische Diskussion im entsprechenden Thread HMUARTLGW: Modul für HomeMatic UART... zu führen.

Ich mache hier "mal zu".