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

Pfriemler · 02 November 2016, 23:39:59

Also das Sendeintervall ist ca 3 Minuten bei Heizkörperthermostaten, Wandthermostaten und Temperatur-Differenz-Sensoren (andere habe ich nicht). Kürzer?
Ein Register zum Einstellen kenne ich nicht.
Ich nutze einen gleitenden Mittelwert der Sensoren als userReading und logge das über ein DOIF alle 15 Minuten.

Aber das ist hier offtopic...

timmyfromspace · 12 November 2016, 00:49:13

Moin moin,

erstmal danke für das Modul und die Tutorials, Hilfen etc.

Also ich hab ein pikantes Problem.

Habe das Homematic LAN-Gateway (Version 1.1.4, Update über Netfinder führt zu Version 1.1.1, Upgrade über eQ3-Tools nicht möglich, ist auch wurscht), Update für den Coprozessor über FHEM nicht möglich, weil:

2016.07.22 23:13:48 1: HMUARTLGW HmLGW wants to initiate encrypted communication, but Crypt::Rijndael is not installed.
2016.07.22 23:13:48 1: HMUARTLGW HmLGW:keepAlive wants to initiate encrypted communication, but Crypt::Rijndael is not installed.

^- diese Meldungen bekomme ich. Im Netfinder ist die Netzwerkverschlüsselung deaktiviert, habe das Gerät bisher in FHEM hinzugefügt / definiert, hmID gesetzt und optional das Passwort hinzugefügt, danach aber wieder entfernt, da ich derzeit keine AES-Verschlüsselung verwenden möchte oder kann.

Weil auf meinem System (DS213J) wird es erstmal schwierig bis unmöglich sein Crypt::Rijndael zu installieren, da das offizielle Perl-Paket sich schwer tut mit der Perl Installation per Make über Compiler-Links, bin heftigst gescheitert, ähnliches las ich zu allen möglichen Modulen in Synology Foren.
Active-Perl wegen kein X86_X64 möglich.

Also jemand ne Ahnung wie ich AES ausknipse?

Danke schonmal.

Gruß Tim

mgernoth · 12 November 2016, 11:41:09

Hallo,

Zitat von: timmyfromspace am 12 November 2016, 00:49:13
Habe das Homematic LAN-Gateway (Version 1.1.4, Update über Netfinder führt zu Version 1.1.1, Upgrade über eQ3-Tools nicht möglich, ist auch wurscht)

Alle Versionen <1.1.5 sind instabil, Du wirst damit keine Freude haben.

Zitat
Update für den Coprozessor über FHEM nicht möglich, weil:

2016.07.22 23:13:48 1: HMUARTLGW HmLGW wants to initiate encrypted communication, but Crypt::Rijndael is not installed.
2016.07.22 23:13:48 1: HMUARTLGW HmLGW:keepAlive wants to initiate encrypted communication, but Crypt::Rijndael is not installed.

^- diese Meldungen bekomme ich. Im Netfinder ist die Netzwerkverschlüsselung deaktiviert

Die Netzwerklverschlüsselung im GW ist noch aktiv!
Und da ist auch das Problem, weshalb Du kein Update der LAN-Firmware durchführen kannst: Die Verschlüsselung im HMLGW ist ab Werk aktiviert, du musst sie explizit über den Netfinder im HMLGW deaktivieren. Nur die Verschlüsselung bei Verbindungsaufbau im Netfinder zu deaktivieren bringt nichts, da er dann nicht mit dem GW reden kann (und das GW auch die neue FW nicht akzeptiert).

Also:

Netfinder eine verschlüsselte Verbindung mit dem GW herstellen lassen
LAN-Firmware updaten
Verschlüsselung des Gateways über den Netfinder deaktivieren

Dann brauchst du Crypt::Rijndael nur noch, falls Du HM-SEC-SD2 über Fhem steuern möchtest.

Viele Grüße
Michael

Klaus.A · 12 November 2016, 16:38:57

Hallo,

erst mal ganz großes DANKE für das Modul zum HM-LAN-Gateway. Ich hatte 4 x HMLAN, jetzt einen davon durch das LAN-Gateway ersetzt.

Ergebnisse:

Deutlich bessere RSSI-Werte (bei identischer Aufstellung) - 10% bis unglaubliche 30% Verbesserung. Aber Vorsicht: Dies kann durch die andere Ausrichtung der Antenne verursacht sein, ist also z.T. von der individuellen Situation abhängig.
Kürzere Schaltzeiten (weniger Re-Transmits? Oder besserer Durchsatz als beim HMLAN?)
Ein HMLAN hatte vorher immer noch die bekannten Disconnects - diese sind jetzt weg. (Stören sich mehrere HMLAN's gegenseitig?)

Ein Problem habe ich allerdings noch: Bei einem FHEM Shutdown/Restart verweigert das LAN-Gateway zunächst die Verbindung (es ist noch aktiv). Das führt zu einer unschönen temporären Änderung meiner als Preferred IO's gesetzten Zuweisungen der Devices. Das regelt sich im Lauf der Zeit wieder (je nach Kommunikations-Traffic).
Im Log ist zu erkennen wie HMLAN und LAN-Gateway unterschiedliche behandelt werden. Ich hänge einen Auszug des Logs hier an, danach kurze Beschreibung.

Code Auswählen


2016.11.12 14:04:21 1: HMLAN_Parse: HMLAN1 new condition disconnected
2016.11.12 14:04:21 3: Opening HMLAN1 device 192.168.53.104:1000
2016.11.12 14:04:21 1: HMLAN_Parse: HMLAN1 new condition init
2016.11.12 14:04:21 3: HMLAN1 device opened
2016.11.12 14:04:21 1: HMLAN_Parse: HMLAN2 new condition disconnected
2016.11.12 14:04:21 3: Opening HMLAN2 device 192.168.53.141:1000
2016.11.12 14:04:21 1: HMLAN_Parse: HMLAN2 new condition init
2016.11.12 14:04:21 3: HMLAN2 device opened
2016.11.12 14:04:21 1: HMLAN_Parse: HMLAN4 new condition disconnected
2016.11.12 14:04:21 3: Opening HMLAN4 device 192.168.53.140:1000
2016.11.12 14:04:21 1: HMLAN_Parse: HMLAN4 new condition init
2016.11.12 14:04:21 3: HMLAN4 device opened
2016.11.12 14:04:21 3: Opening HMLANGW3 device 192.168.53.137:2000
...
2016.11.12 14:04:49 0: Featurelevel: 5.7
2016.11.12 14:04:49 0: Server started with 535 defined entities (fhem.pl:12544/2016-11-11 perl:5.020002 os:linux user:fhem pid:989)
2016.11.12 14:04:49 1: HMLAN_Parse: HMLAN2 new condition ok
2016.11.12 14:04:50 1: HMLAN_Parse: HMLAN4 new condition ok
2016.11.12 14:04:50 1: HMLAN_Parse: HMLAN1 new condition ok
2016.11.12 14:04:50 3: Can't connect to 192.168.53.137:2000: 192.168.53.137: Connection reset by peer
2016.11.12 14:04:51 3: telnetForBlockingFn_1478955891: port 45263 opened
...
2016.11.12 14:05:51 3: Opening HMLANGW3:keepAlive device 192.168.53.137:2001
2016.11.12 14:05:51 1: 192.168.53.137:2000 reappeared (HMLANGW3)
2016.11.12 14:05:51 3: HMUARTLGW HMLANGW3 BidCoS-port opened
2016.11.12 14:05:51 3: HMUARTLGW HMLANGW3:keepAlive KeepAlive-port opened
2016.11.12 14:05:52 3: HMUARTLGW HMLANGW3 currently running Co_CPU_App
2016.11.12 14:05:55 3: HMUARTLGW HMLANGW3 currently running Co_CPU_BL
2016.11.12 14:05:55 3: HMUARTLGW HMLANGW3 currently running Co_CPU_App

Ablauf:

Bei FHEM-Start werden zunächst alle HMLAN-Adapter auf "disconnect" gesetzt, also abgehängt. (Hier HMLAN1, HMLAN2, HMLAN4 - Nr. 3 gibt es nicht mehr, ist entfernt, durch das LAN-Gateway ersetzt.). Danach ein Open und Init, sodass HMLAN-Adapter bereit sind.
Das LAN-Gateway (HMLANGW3 - von mir so benannt, IP 182.168.53.137) erhält ein "open", aber irgendwas muss da daneben gehen (s. weiter unten).
Nach der Server-Startmeldung wird die Bereitschaft der HMLAN-Adapter nochmals bestätigt, nur das HM-LAN-Gateway verweigert die Verbindung (Connection reset by peer).

Später kommt das Open auf den KeepAlive-Port des HM-LAN-Gateway, das folgende Open wird akzeptiert und das Gateway funktioniert. Erst jetzt - nachdem die Zuweisungen der IOs beim Server-Start bereits durchlaufen sind - ist das HM-LAN-Gateway betriebsbereit für FHEM. Die Zuweisungen sind zu diesem Zeitpunkt aber nicht wie vorgegeben (preferred IOs wurden zwangsläufig ignoriert).

Meine Frage: Habe ich irgendeine Möglichkeit dieses Verhalten zu beeinflussen? Mir fällt dazu nichts ein - es geht um die FHEM-Startphase. Aktuelle Firmware ist aufgespielt, AES im Gateway deaktiviert. VCCU ist eingerichtet, funktioniert einwandfrei. Irgendwie scheint der erste Open für das LAN-Gateway nicht zu funktionieren, und es ist dann blockiert.

Im laufenden Betrieb ganz große Klasse, stabil, schnell, hervorragende Reichweite. Am liebsten würde ich die anderen 3 HMLAN-Adapter auch ersetzen, aber mit den Startproblemen gibt's dann vermutlich ganz großes Chaos weil keines der Gateways beim Start zu spät erreichbar wäre?

Danke für jeden Hinweis.

Gruß, Klaus

timmyfromspace · 12 November 2016, 16:56:40

Danke für die Antwort Michael. Hab mit NetFinder (1.1.5) ein paar Probleme.

Also die Ausgangsituation ist Version 1.1.4 (wenn ich Factory resette) und sieht normal so aus:

http://i.imgur.com/Wk82yCv.png

Wenn ich die FW downloade und damit erfolgreich flashe (Update Firmware und Sicherheitsschlüssel), bekomme ich diesen Fehler:

https://raw.githubusercontent.com/eq-3/occu/28045df83480122f90ab92f7c6e625f9bf3b61aa/firmware/hm-lgw-o-tw-w-eu_update.eq3

http://i.imgur.com/XyGyF32.png

also es wird irgendwie nicht 1.1.5 für die Version angezeigt, sondern 1.1.1 :S. Nach Factory Reset wieder 1.1.4.
Bin Clueless.

Da ich ja auf Zack bin, habe ich mir dann Debian amd64 in ne VM installiert, eq3-Tools nach dem Wiki-Eintrag instaliert, Path gesetzt, Firmware ins richtige Verzeichnis. Aber das kack Tool kann mein Gateway unter meiner Seriennummer LEQ0602255 nicht finden (auch wenn ich in etc/hosts den DNS Namen eintrage) und über -h 192.168.2.35 also IP-Adressen basiert, meckert die CMD Zeile von wegen bitte entweder IP oder Seriennummer eingeben und tut nix :<

Jemand noch Ideen?

Klaus.A · 12 November 2016, 17:09:38

"Version 1.1.1" hatte ich auch zuerst nach dem Flashen gesehen und gedacht das ging voll daneben.

Dann auf "Update Device List" geklickt und - o Wunder - jetzt wurde 1.1.5 angezeigt. Warum das so war - keine Ahnung. Timing-Probleme? Fehler im Tool (ist 1.1.1 nur ein Default-Wert?)

Gruß Klaus

timmyfromspace · 12 November 2016, 17:37:22

Danke für den Tipp, könnte ja bei mir auch die Möglichkeit sein. Ich warte jetzt mal länger ab, nach einem Update Device List isses auf jeden Fall noch da, vielleicht ja nach ein paar Minuten/Stunden / nem Reboot aufgrund von Integrität oder so nimmer, who knows.

Klaus.A · 12 November 2016, 17:54:37

Noch ne Überraschung ... die Disconnects bei den HMLAN sind weg, aber jetzt hängt sich das LAN-Gateway weg:

Code Auswählen


2016.11.12 16:46:49 1: HMUARTLGW HMLANGW3:keepAlive KeepAlive sent 9.254s too late, this might cause a disconnect!
2016.11.12 16:46:49 1: 192.168.53.137:2001 disconnected, waiting to reappear (HMLANGW3:keepAlive)
2016.11.12 16:46:50 1: 192.168.53.137:2000 disconnected, waiting to reappear (HMLANGW3)
2016.11.12 16:46:50 3: Opening HMLANGW3:keepAlive device 192.168.53.137:2001
2016.11.12 16:46:50 1: 192.168.53.137:2000 reappeared (HMLANGW3)
2016.11.12 16:46:50 3: HMUARTLGW HMLANGW3 BidCoS-port opened
2016.11.12 16:46:50 3: HMLANGW3:keepAlive device opened
2016.11.12 16:46:50 3: HMUARTLGW HMLANGW3:keepAlive KeepAlive-port opened
2016.11.12 16:46:52 3: HMUARTLGW HMLANGW3 currently running Co_CPU_App
2016.11.12 16:46:54 3: HMUARTLGW HMLANGW3 currently running Co_CPU_BL
2016.11.12 16:46:54 3: HMUARTLGW HMLANGW3 currently running Co_CPU_App

KeepAlive fast 10 Sekunden zu spät? Zu einer Zeit in der nichts los war (zumindest nichts bekannt, weder in FHEM noch im LAN) - sonderbar, da habe ich keine Erklärung dafür. Einmal waren es 4,x Sekunden, jetzt mal 9,x Sekunden. Das weiter eingrenzen wird schwierig da nicht reproduzierbar.

Gruß Klaus

timmyfromspace · 12 November 2016, 18:30:40

Juhu, es ging. Problem war bei mir Windows 10 + Netfinder + Firmware Upgrade.

Mit ner VM unter Win7 gings direkt, nach einem aktualisieren 1.1.5 \o/

Also Warnung: Windows 10 ist da potentiell schlecht.

timmyfromspace · 12 November 2016, 18:51:03

Network Encryption nu auch im Netfinder (unter Windoof 7!) ausgestellt, aber immer noch:

2016.11.12 18:49:21 1 : HMUARTLGW meinLGW wants to initiate encrypted communication, but Crypt::Rijndael is not installed.

sowie set meinLGW updateCoPro /path/to/coprocessor_update_hm_only.eq3 und testweise mal das lgWPasswort reingetan.

Bringt leider nüschts, update Befehl bringt auch nix mehr neues.

Noch jemand ne Idee, wie ich mein Gerät dazu zwinge unverschlüsselt zu reden?

Danke schonmal.

Gruß Tim

Klaus.A · 12 November 2016, 20:25:34

@Tim:

Die Meldung bedeutet dass die Verschlüsselung im LAN-Gateway immer noch eingeschaltet ist. Es geht hier nicht um den Netzwerkzugriff mit dem Netfinder zum LAN-Gateway, sondern die Verschlüsselung IM LAN-Gateway, die es für die Kommunikation mit den Geräten nutzt. Hatte ich genauso erst falsch.

Ausschalten wie folgt:

Netfinder starten
Das LAN-Gateway muss in der Liste zu sehen sein. Kann ein paar Sekunden dauern.
Auswahl (Button): Netzwerkeinstellungen ändern
Eingabe: Passphrase ... => Password, auf der Rückseite des Gehäuses aufgedruckt

WICHTIG: Checkbox: "Netzwerkverschlüsselung" rausnehmen

Achtung: Voreinstellungen in diesem Dialog sind "DHCP on", "Auto-IP on"! Diese evtl. rausnehmen und die richtigen Werte für alle IPs eintragen (Gerät, Netzwerk-Gateway, DNS Server). Das kommt darauf an ob in einem DHCP-Server (soweit vorhanden) die IP-Zuweisung korrekt definiert ist (u.U. IP und MAC-Adresse für dauerhaft konstante IP).

Bei mir funktioniert das (und die Firmware-Updates) mit Windows 10 problemlos. Nein, Windows 10 ist hier nicht das Problem. Evtl. könnte die Java-Runtime zu alt sein?

Gruß, Klaus

timmyfromspace · 12 November 2016, 20:30:43

Danke für die Antwort Klaus, wie geschrieben habe ich genau das getan:

"Network Encryption nu auch im Netfinder (unter Windoof 7!) ausgestellt, aber immer noch:"

Problem besteht weiterhin. DHCP, Auto IP etc. aus und alle Sachen selbst eingestellt. Verbindung selbst ist ja auch okay, verschlüsselt aber irgendwie noch immer :3

Klaus.A · 12 November 2016, 22:09:13

Das HM-LAN-Gateway neu gestartet (geht auch aus dem Netfinder)?

Gruß, Klaus

timmyfromspace · 13 November 2016, 01:24:42

Normal schon, mit FW 1.1.5 (was ja vorher irgendwie nicht ging unter Win10 / dem JRE (wobei da Java ja direkt meckern sollte)) noch nicht explizit.

Jetzt gehts scheinbar gerade, puh, mürrische Teile

Danke Klaus!

mgernoth · 13 November 2016, 13:45:58

Zitat von: Klaus.A am 12 November 2016, 17:54:37
KeepAlive fast 10 Sekunden zu spät? Zu einer Zeit in der nichts los war (zumindest nichts bekannt, weder in FHEM noch im LAN) - sonderbar, da habe ich keine Erklärung dafür.

Fhem hat hier irgendwo (mindestens) 10s lang blockiert und der von HMUARTLGW aufgesetzte Timer feuerte deshalb zu spät. Das LGW möchte alle 15s per KeepAlive gestreichelt werden, ansonsten trennt es die Verbindung. Fhem-Hänger von 10s sind damit nicht wirklich kompatibel...

Viele Grüße
Michael