HMUARTLGW: Modul für HomeMatic UART-Modul (RPi) und HomeMatic LAN Gateway

[Burny4600]

Danke für die Info.

Muss socat auf beiden System installiert werden oder reicht es auf dem Remote Pi aus?

[Ralf W.]

Immer da, wo Du es aufrufst. Bei meinen Rechnern gehört das zu meiner Grundinstallation.

MfG

[Burny4600]

Und wie sieht das mit dem Port aus.
Muss das der Telnetport sein der mit einem Passwort geschützt ist oder kann das ein beliebiger sein?

Jedenfalls bekomme ich mit dieser Konfiguration keine Verbindung zustande.

Entfernte FHEM-Instanz

Code Auswählen Erweitern

define HmUART HMUARTLGW /dev/ttyAMA0

Installation auf Remote Instanz

Code Auswählen Erweitern

sudo apt-get install socat
FHEM

Code Auswählen Erweitern

define RM_HmUART HMUARTLGW uart://192.xxx.xxx.xxx:2000

Code Auswählen Erweitern

~$ socat TCP4-LISTEN:2000,fork,reuseaddr /dev/ttyAMA0,raw,echo=0,b115200

[Otto123]

Es ist nicht dazu gedacht zwei FHEM Instanzen zu koppeln, sondern das RPI Modul über socat auf dem entfernten Raspi verfügbar zu machen.
Auf der von FHEM wo Du das entfernte RPI Modul verwenden willst bindest Du es mit uart://192.xxx.xxx.xxx:2000 an.
Also
PI1 -> FHEM -> uart://IP:Port -> Netzwerk -> Remote PI2 -> socat listener -> socat serial -> RPI Modul auf PI2

Gruß Otto

[Burny4600]

Da tut sich nichts.
Wenn ich auf dem Pi-1 wo das Modul angeschlossen ist folgende Konfiguration ausführe,

Code Auswählen Erweitern

define HmUART_EG HMUARTLGW /dev/ttyAMA0
define RM_HmUART_EG HMUARTLGW uart://192.168.17.185:2000
habe ich bei der uart Konfiguration immer ein disconnected beim STATE

Auf dem Pi-2 wo ich die Schnittstelle zusätzlich benötige führe ich auf der Console

Code Auswählen Erweitern

sudo socat TCP4-LISTEN:2000,fork,reuseaddr /dev/ttyAMA0,raw,echo=0,b115200
aus.
Dort wartet er und es tut sich nichts.

Was ich dann mit dem Rest als Konfiguration ausführen muss habe ich noch nicht begriffen.

socat serial -> RPI Modul auf PI2

Irgendwie stehe ich anscheind wieder einmal auf der Leitung.

[Otto123]

auf dem Pi wo das Modul angeschlossen ist:
Kein FHEM Zugriff!
Kein define HmUART_EG HMUARTLGW /dev/ttyAMA0
Kein define RM_HmUART_EG HMUARTLGW uart://192.168.17.185:2000
Auf diesem Pi, also wo das Modul steckt:

Code Auswählen Erweitern

sudo socat TCP4-LISTEN:2000,fork,reuseaddr /dev/ttyAMA0,raw,echo=0,b115200

Auf dem Modul wo FHEM läuft und das Modul Remote angeschlossen werden soll:

Code Auswählen Erweitern

define RM_HmUART_EG HMUARTLGW uart://192.168.17.185:2000

Es handelt sich nicht um sharing der seriellen Schnittstelle und damit "verfügbar machen" des Moduls all over the World!
Es handelt sich um ein exklusives "Kabel" von Pi zu Pi zur Schnittstelle zum RPI Modul.

Hätte ich besser so schreiben sollen?
PI1:              FHEM -> uart://IP:Port -> Netzwerk ->
Remote PI2: Netzwerk -> socat listener -> socat serial -> RPI Modul auf PI2
oder so:
RPI Modul auf PI2 -> serial -> socat -> Netzwerk -> uart://IP:Port ->  FHEM auf PI1

Gruß Otto

[dev0]

Hätte ich besser so schreiben sollen?

Respekt vor Deiner Geduld!

[Otto123]

Ich habe mir die Dinge zur Remote Anbindung mal gleich in den Wiki Artikel kopiert.
Ich spiele das dann selbst nochmal durch und ergänze das im Wiki 

Gruß Otto

[Burny4600]

Danke Otto!

Jetzt hab ich es geschnalt.
Den Aufruf in der Console
sudo socat TCP4-LISTEN:2000,fork,reuseaddr /dev/ttyAMA0,raw,echo=0,b115200

In welcher Datei lege ich diesen Befehl am besten ab damit dieser bei einem Neustart ausgeführt wird.
Würde die rc.local ohne sudo dafür verwenden.

[Omega]

Jetzt bin ich endlich mal wieder dazu gekommen, meinen LAN-Adapter anzuschließen (FHEM ist auf einem aktuellen Stand). Verbose steht bereits auf 1.
Ich habe jetzt wieder – wie schon vor einigen Wochen – haufenweise folgende Meldungen im Log.

Code Auswählen Erweitern


2016.10.22 17:55:50 1: HMUARTLGW HMLGW:keepAlive KeepAlive sent 4.083s too late, this might cause a disconnect!
2016.10.22 17:56:06 1: HMUARTLGW HMLGW:keepAlive KeepAlive sent 6.568s too late, this might cause a disconnect!
2016.10.22 17:56:07 1: 192.168.0.23:2001 disconnected, waiting to reappear (HMLGW:keepAlive)
2016.10.22 17:56:07 1: 192.168.0.23:2000 disconnected, waiting to reappear (HMLGW)
2016.10.22 17:56:07 1: 192.168.0.23:2000 reappeared (HMLGW)
2016.10.22 17:57:08 1: HMUARTLGW HMLGW:keepAlive KeepAlive sent 9.767s too late, this might cause a disconnect!
2016.10.22 17:57:09 1: 192.168.0.23:2001 disconnected, waiting to reappear (HMLGW:keepAlive)
2016.10.22 17:57:10 1: 192.168.0.23:2000 disconnected, waiting to reappear (HMLGW)
2016.10.22 17:57:10 1: 192.168.0.23:2000 reappeared (HMLGW)
2016.10.22 17:58:12 1: HMUARTLGW HMLGW:keepAlive KeepAlive sent 10.335s too late, this might cause a disconnect!
2016.10.22 17:58:12 1: 192.168.0.23:2001 disconnected, waiting to reappear (HMLGW:keepAlive)
2016.10.22 17:58:13 1: 192.168.0.23:2000 disconnected, waiting to reappear (HMLGW)
2016.10.22 17:58:13 1: 192.168.0.23:2000 reappeared (HMLGW)
2016.10.22 17:59:15 1: HMUARTLGW HMLGW:keepAlive KeepAlive sent 10.466s too late, this might cause a disconnect!
2016.10.22 17:59:16 1: 192.168.0.23:2001 disconnected, waiting to reappear (HMLGW:keepAlive)
2016.10.22 17:59:17 1: 192.168.0.23:2000 disconnected, waiting to reappear (HMLGW)
2016.10.22 17:59:17 1: 192.168.0.23:2000 reappeared (HMLGW)
2016.10.22 18:00:19 1: HMUARTLGW HMLGW:keepAlive KeepAlive sent 9.768s too late, this might cause a disconnect!
2016.10.22 18:00:20 1: 192.168.0.23:2001 disconnected, waiting to reappear (HMLGW:keepAlive)

Ich kann nicht glauben, dass das so ok ist.
Gibt es Stellschrauben, um da etwas zu verbessern?
Was könnte die Ursache für dieses Verhalten sein?

Gruß
Holger

[Gruvol]

Hallo allerseits,

ich habe anscheinend irgendetwas falsch gemacht, kann aber keinen Fehler finden.
Ich habe das hmuart in fhem angelegt und dieses hat auch den Status opened und ist auf firmware 1.4.1.
Danach habe ich wie empfohlen eine VCCU erstellt. Diese hat auch den Status "myHmUART:ok".
Da scheint für mich auch alles in Ordnung zu sein. Danach habe ich versucht das Heizungsthermostat 105155 gepaired.
Das scheint auch soweit funktioniert zu haben, da eine Menge an Devices in den Raum "CUL_HM" angelegt wurde.
In meinem Fall heißt das Device noch HM_440897, das ist aber erstmal egal.
Wenn ich auf das Thermostat drauf gehe habe ich dort allerdings den Status "CMDs_pending".
Desweiteren zeigt er mir bei den Readings nur Activity (dead), D-firmware, D-serialNr., RegL_00 und state wiederum mit "CMDs_pending". Meine Erwartung war, dass Ist - und Solltemperatur dort steht.
Es gibt noch einen Haufen anderer Devices zu dem Thermostat wie _Clima, _Climate, _ClimaTeam, _remote, _Weather, _WindowRec, jedoch ist dort überall ein Fragezeichen dahinter.
Habe ich etwas falsch gemacht, bzw. könnt ihr mir helfen, wie ich das Ding zum Fliegen bekomme?

Hat keiner eine Idee oder einen Tipp für mich?

Eine andere Frage, die ich habe. Ich habe gesehen, dass auch die Telekom solche Homematic Thermostate anbieten, sind das die identischen zu dem HomeMatic 105155 (HM-CC-RT-DN)? Da mir aufgefallen ist, dass diese identisch aussehen und teilweise deutlich günstiger sind.

Viele Grüße.

[Otto123]

Hallo Gruvol,

da Du jetzt doch eher ein Problem mit dem pairen des Thermostaten hast und es offenbar nicht unmittelbar mit dem Thread zu tun hat: Mach doch einen neuen Thread im Homematic Unterforum auf und stelle Deine Frage zum pairen und poste die Ausgabe eines

Code Auswählen Erweitern

list HM_440897

Die qivicon Schiene ist scheinbar so eine Produktionsrichtung von eq3 und zum Teil sollen das um etikettierte  Hm Produkte sein.

Gruß Otto

[Ma_Bo]

@Gruvol Ja, diese von dem grossen T habe ich auch teilweise im Einsatz : http://www.cw-mobile.de/search/?q=homematic

[MadMax-FHEM]

Eine andere Frage, die ich habe. Ich habe gesehen, dass auch die Telekom solche Homematic Thermostate anbieten, sind das die identischen zu dem HomeMatic 105155 (HM-CC-RT-DN)? Da mir aufgefallen ist, dass diese identisch aussehen und teilweise deutlich günstiger sind.

Hier wird auch drüber "diskutiert": https://forum.fhem.de/index.php/topic,58928.msg503200.html
aber sind wohl "identisch"...

Gruß, Joachim

[Wuppi68]

Ja die Telekom Geräte sind absolut baugleich - darfst nur nicht die Zigbee Geräte nehmen

sind nur aktuell im Personalverkauf wenig bis gar nicht Lieferbar