[GELÖST!] Pairing Thermostat <-> LAN-Gateway HM-LGW-O-TW-W-EU-2 nicht möglich!?

[Otto123]

Da würde ich der Empfangsreichweite der Nachbarn aber mal nachgehen. Die reden doch auch bloß dazwischen wenn Du versuchst zu pairen. Oder macht es wirklich bloß die Zentrale die paarunsgbereit ist? Ich bin da unsicher ...

Die Wandthermostate ...
Bei denen gab es noch das Problem, dass konstruktiv bedingt die Federn von den Batterien Kontakt mit der Leiterplatte bekommen können. Schau da mal nach, nicht das die schlecht montiert sind. Ich hatte mal den Fall, da war ein paar Tage nach dem Wechsel die Batterie wieder alle und der Thermostat hat sich komisch verhalten.

Gruß Otto

[DocCyber]

Die reden doch auch bloß dazwischen wenn Du versuchst zu pairen. Oder macht es wirklich bloß die Zentrale die paarunsgbereit ist? Ich bin da unsicher ...

Nun ja... Die quatschen natürlich ständig dazwischen. Aber dennoch gab es in meiner HM-Umgebung niemals ein Problem beim Pairing (am HM-CFG-LAN). Ich kann ja schlecht von meinen Nachbarn verlangen, den Funkverkehr ihrer Installation zu stoppen. 
Umgekehrt klappt es ja offenbar auch. Die arbeiten allerdings nicht mit FHEM, sondern mit  HM-CCUs. Ich glaube also nicht, dass das ein Problem darstellt.

konstruktiv bedingt die Federn von den Batterien Kontakt mit der Leiterplatte bekommen können. Schau da mal nach, nicht das die schlecht montiert sind.

Muss ich mal nachsehen, danke. Allerdings kann man die Gehäuse schlecht öffnen. Ich möchte sie nicht beschädigen, weil ich sie umtauschen möchte...

[xMaXiiMuSx]

Hallo zusammen,

ich bin neu im Bereich der Hausautomatisierung. Ich habe ebenfalls ein Problem mit dem LAN-Gateway. Habe, soweit ich das beurteilen kann, das Gateway erfolgreich nach Anleitung https://wiki.fhem.de/wiki/HM-LGW-O-TW-W-EU_Funk-LAN_Gateway eingebunden.
Leider geht es beim Punkt Firmware update nicht weiter.

Code Auswählen Erweitern

pi@raspberrypi:~ $ sudo apt-get install libc6-i386 lib32stdc++6
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
Paket libc6-i386 ist nicht verfügbar, wird aber von einem anderen Paket
referenziert. Das kann heißen, dass das Paket fehlt, dass es abgelöst
wurde oder nur aus einer anderen Quelle verfügbar ist.

E: Für Paket »libc6-i386« existiert kein Installationskandidat.
E: Paket lib32stdc++6 kann nicht gefunden werden.
E: Mittels regulärem Ausdruck »lib32stdc++6« konnte kein Paket gefunden werden.

Habe auch ein KeyMatic am laufen, das wurde anscheinen automatisch eingebunden, kann das sein? Glaube das ist geschehen, als ich die Fernbedienung an KeyMatic angelernt habe. Dieses kann ich jedoch nicht aus fhem ansteuern.

Über Hilfe würde ich mich sehr freuen, danke.

[DocCyber]

Meines Wissens ist ein FW Update nicht unbedingt nötig. Nur dann, wenn das Release älter ist.
Ich habe es nicht durchgeführt.
Die Details dazu stehen im Wiki (Wiki.fhem.de) zum Thema LAN Gateway.
Bei deinen Update Problemen kann ich dazu leider nichts sagen.

Keymatic habe ich nicht im Einsatz und kann aus Erfahrung also nichts sagen.

Normalerweise richtet FHEM neue Geräte selbst ein, sobald das Pairing erfolgreich war.

[Otto123]

Normalerweise richtet FHEM neue Geräte selbst ein, sobald das Pairing erfolgreich war.

Nicht ganz. FHEM richtet per autocreate die Geräte von HM ein wenn deren Anlernmessage kommt. Die wird erzeugt, wenn "der Anlernknopf am Gerät gedrückt" wird. Mit pairen hat dies allein nicht zu tun!
Aber die Geräte zeigen danach in der Regel vieles, man kann in FHEM darauf reagieren, steuern kann man damit aber nicht. Dafür muss gepairt werden.

Das mit dem Update ist aus meiner Sicht das falsche Vorgehen, Ich würde nur Punkt 3.3 im Wiki versuchen. Die beiden Punkte davor sind sicher historisch so da drin. Das wurde irgendwann durch die Entwicklung des Moduls HMUARTLGW  überholt.

@xMaXiiMuSx: In diesem Thread geht es um Pairing Probleme mit dem Lan-Gateway. Firmware Update war nicht das Thema.

Gruß Otto

[DocCyber]

In diesem Thread geht es um Pairing Probleme mit dem Lan-Gateway.

Um darauf noch mal zurückzukommen:
Welchen Grund kann es dafür geben, dass Pairing am HM-CFG-LAN innerhalb von wenigen Sekunden erfolgreich durchgeführt werden kann, aber am LAN-Gateway mehrere Minuten verstreichen, teils bis zu einer halben Stunde?

[Otto123]

Guten Morgen,

Funktioniert denn jetzt das pairing der Thermostate?

[DocCyber]

Hallo Otto,

ich habe erst soeben damit beginnen können.

Folgendes habe ich gemacht:
Ich habe einen der Thermostate aus meiner bestehenden, funktionierenden HM-Umgebung rausgenommen, auf Werkseinstellung zurückgesetzt und den HM-CFG-LAN gestoppt (set HM-CFG-LAN close). Diesen Thermostaten habe ich dann mit der VCCU meiner der zweiten Umgebung (mit LAN-Gateway) angelernt.
Folgendes kann ich feststellen:
hmPairSerial funktioniert beim Thermostaten scheinbar tatsächlich nicht. Scheinbar deshalb, weil ich der LGW-Umgebung noch nicht so richtig traue.
mhPairForSec "funktioniert" zügig, aber ich warte noch immer noch auf ein erfolgreiches Pairing.
Wie gesagt: es dauert und dauert... Mittlerweile warte ich schon mehr als 30 Minuten. CMDs_pending. 

Warum ist das so?
An meinen Örtlichkeiten kann es nicht liegen. Beide Zentralen, also CFG-LAN wie auch LAN-GW, sind 2-3 Meter entfernt. Das anzulernende Gerät (Thermostat) ist identisch.
Da es mit dem CFG-LAN bis vorhin lief, kann es nur noch am LAN-GW oder am Softwaremodul liegen.
Habe ich etwas übersehen?

[xMaXiiMuSx]

Wie erkenne ich denn ob das pairing eines Gerätes erfolgreich war?

[Otto123]

Wie erkenne ich denn ob das pairing eines Gerätes erfolgreich war?

Daran das hmInfo nicht meckert oder das Gerät hat die readings ordentlich mit der hmId gefüllt. In der Art:
PairedTo 0x200DB8
R-pairCentral 0x200DB8

@DocCyber
hast Du nochmal mal ein getConfig am Thermostaten abgesetzt? Der sendet glaube ich etwas verzögert. Bereich 2,5 min - aber nicht 30 min!
CMDs_pending bedeutet, er will Daten senden und/oder wartet auf welche bekommt es aber nicht hin. Nochmal den Configtaster drücken? Ist beim Thermostaten boost - oder?

[DocCyber]

hast Du nochmal mal ein getConfig am Thermostaten abgesetzt?

Ja, das habe ich alles schon mehrfach wiederholt.

CMDs_pending bedeutet, er will Daten senden und/oder wartet auf welche bekommt es aber nicht hin.

Das ist mir durchaus klar.

Wie gesagt: Ich habe ungefähr 40 HM-Geräte in meiner etablierten Umgebung, und ich hatte bis dato keinerlei Pairing-Probleme. Alles immer mit hmPairForSec gemacht, und immer war alles innerhalb von wenigen Sekunden korrekt gepairt. Auch dieser Thermostat, der am LGW nun partout nicht will.
Immer noch CMDs_pending. Nach Stunden mittlerweile ...

[Otto123]

was sagt der load und loadLvl im HMLGW?

[DocCyber]

Aus meiner Sicht alles okay:

Code Auswählen Erweitern


Internals:
   AssignedPeerCnt 3
   CNT        165
   Clients    :CUL_HM:
   DEF        192.168.178.24
   DEVCNT     215
   DevState   99
   DevType    LGW
   DeviceName 192.168.178.24:2000
   FD         15
   FUUID      5e19b827-f33f-4dd6-9509-4a2257861abfdb55
   LastOpen   1580571934.89153
   NAME       LANgateway
   NOTIFYDEV  global
   NR         19
   NTFY_ORDER 50-LANgateway
   PARTIAL   
   RAWMSG     0500003A6B8002ABBA0040A1950101C800
   RSSI       -58
   STATE      opened
   TYPE       HMUARTLGW
   XmitOpen   1
   model      eQ3-HM-LGW
   msgLoadCurrent 1
   msgLoadHistory 0/0/-15/-7/0/-5/0/0/0/0/1/0
   msgLoadHistoryAbs 1/1/1/16/23/23/28/28/28/28/28/27/27
   owner      CAFE00
   owner_CCU  VCCU
   Helper:
     CreditTimer 344
     FW         66561
     Initialized 1
     SendCnt    24
     AckPending:
     LastSendLen:
       3
       3
     Log:
       IDs:
     PendingCMD:
     RoundTrip:
       Delay      0.0041351318359375
     loadLvl:
       lastHistory 1580577039.91427
   MatchList:
     1:CUL_HM   ^A......................
   Peers:
     4E6F4E     +4E6F4E,00,00,00
     6F49DB     +6F49DB,00,00,00
     6F4BCE     +6F4BCE,00,00,00
   READINGS:
     2020-02-01 16:45:39   D-HMIdAssigned  CAFE00
     2020-02-01 16:45:39   D-HMIdOriginal  FFFFFF
     2020-02-01 16:45:34   D-LANfirmware   1.1.5
     2020-02-01 16:45:39   D-firmware      1.4.1
     2020-02-01 16:45:34   D-serialNr      PEQ2247964
     2020-02-01 16:45:34   D-type          eQ3-HM-LGW
     2020-02-01 16:45:39   cond            ok
     2020-02-01 18:00:43   load            1
     2020-02-01 16:45:39   loadLvl         low
     2020-02-01 16:45:34   state           opened
   helper:
   keepAlive:
     CNT        25
     DEVCNT     24
     DevState   99
     DevType    LGW-KeepAlive
     DeviceName 192.168.178.24:2001
     FD         16
     LastOpen   1580571934.89734
     NAME       LANgateway:keepAlive
     NR         51
     PARTIAL   
     STATE      opened
     TEMPORARY  1
     TYPE       HMUARTLGW
     XmitOpen   0
     Helper:
       NextKeepAlive 1580577108.61653
       Log:
         Resolve    1
         IDs:
     READINGS:
       2020-02-01 16:45:34   state           opened
Attributes:
   hmId       CAFE00
   lgwPw      VAKGCBW6L!
   room       00_SYSTEM


Für heute ist erstmal Schluss mit fhem; es hat mich genug geärgert.
Fußball ist jetzt (noch!) wichtiger:
Leipzig - Gladbach. 

Melde mich morgen...

[Otto123]

Moin,

mir fiel da noch ein: Wie hast Du es mit der LAN Verschlüsselung gemacht? Ist die AN oder AUS?

Ich rede ja mit dem HM-LGW-O-TW-W-EU-2 nur theoretisch, ich habe selbst keins.

Gruß Otto

[DocCyber]

Guten Morgen Otto

mmm... Interessanter Aspekt

Ich habe keine diesbezüglichen Einstellungen gemacht, lediglich das vorgegebene Kennwort des LGW gesetzt. Gemäß commandref müsste die Verschlüsselung also eingeschaltet sein:

Code Auswählen Erweitern

lgwPw
AES password for the eQ-3 HomeMatic Wireless LAN Gateway. The default password is printed on the back of the device (but can be changed by the user). If AES communication is enabled on the LAN Gateway (default), this attribute has to be set to the correct value or communication will not be possible. In addition, the perl-module Crypt::Rijndael (which provides the AES cipher) must be installed.
Das Perlmodul Crypt::Rijndael habe ich aber nicht installiert, zumindest nicht wissentlich. Wie finde ich heraus, ob es schon serienmäßig beim Raspi-Setup installiert wurde - und wie installiere ich es, wenn es nicht drauf ist?

Andererseits: Die beiden Switches funktionieren ja, auch wenn das Paring hier auch eine Weile benötigte. Also müsste die Kommunikation grundsätzlich doch funktionieren?


Generell hatte ich heute früh den Gedanken, ob nicht die Raspi-Einstellungen nochmals gescheckt werden sollten. Wie berichtet, hatte ich ja zunächst mit der kleinen Funkplatine (HM-MOD-RPI-PCB) experimentiert und dazu etliche Änderungen (u.a. lt. deines Blogs) durchgeführt. Evtl ist mir dabei ein Fehler unterlaufen. Könnte es ein, dass diese Änderungen nun Probleme beim Betrieb des LGW verursachen, weil ich den HM-MOD-RPI-PCB ja nun doch nicht nicht im Einsatz habe? Nicht zuletzt auch wegen meiner Lötfähigkeiten. 

Wäre es ggf sogar sinnvoll, ein komplett neues Raspi-Setup zu starten, also das Image neu aufzuspielen? Es gibt schließlich seit Kurzem FHEM 6.0...