Pairing Probleme mit HMUARTLGW (HM-LGW-O-TW-W-EU)

[muecke36]

Hallo zusammen,

zuerst mal noch frohe Weihnachten euch allen und schon mal einen guten Rutsch ins neue Jahr.

Ich habe meinen HMLAN Konfigurationsadapter durch ein LAN Gateway ersetzen müssen und habe jetzt Probleme beim Pairing mit vielen Devices (die RSSI Werte sind bei allen gut).

Mein LGW ist so definiert:

Code Auswählen Erweitern


defmod myHmLGW HMUARTLGW 192.x.x.x
attr myHmLGW hmId 000002

setstate myHmLGW opened
setstate myHmLGW 2016-12-25 06:25:26 D-HMIdAssigned 000002
setstate myHmLGW 2016-12-25 06:25:26 D-HMIdOriginal FFFFFF
setstate myHmLGW 2016-12-25 06:25:21 D-LANfirmware 1.1.5
setstate myHmLGW 2016-12-25 06:25:26 D-firmware 1.4.1
setstate myHmLGW 2016-12-25 06:25:21 D-serialNr NEQ1694427
setstate myHmLGW 2016-12-25 06:25:21 D-type eQ3-HM-LGW
setstate myHmLGW 2016-12-25 06:25:26 cond ok
setstate myHmLGW 2016-12-27 12:48:22 load 2
setstate myHmLGW 2016-12-25 06:25:26 loadLvl low
setstate myHmLGW 2016-12-25 06:25:21 state opened


Bei einigen Devices (z.B. UP Dimm Aktoren) funktioniert auch das neu pairen mittels PairSerial:

Code Auswählen Erweitern


defmod EG.wz.DI.Esstisch CUL_HM 1A72E5
attr EG.wz.DI.Esstisch userattr lightSceneParamsToSave lightSceneRestoreOnlyIfChanged:1,0
attr EG.wz.DI.Esstisch .devInfo 110100
attr EG.wz.DI.Esstisch .stc 20
attr EG.wz.DI.Esstisch IODev myHmLGW:keepAlive
attr EG.wz.DI.Esstisch alias Esstisch Licht
attr EG.wz.DI.Esstisch autoReadReg 4_reqStatus
attr EG.wz.DI.Esstisch expert 2_full
attr EG.wz.DI.Esstisch firmware 2.2
attr EG.wz.DI.Esstisch group EG
attr EG.wz.DI.Esstisch model HM-LC-Dim1TPBU-FM
attr EG.wz.DI.Esstisch room 0_Wohnzimmer
attr EG.wz.DI.Esstisch serialNr JEQ0207001
attr EG.wz.DI.Esstisch subType dimmer
attr EG.wz.DI.Esstisch webCmd pct

setstate EG.wz.DI.Esstisch CMDs_done
setstate EG.wz.DI.Esstisch 2016-12-23 12:04:56 .D-devInfo 110100
setstate EG.wz.DI.Esstisch 2016-12-23 12:04:56 .D-stc 20
setstate EG.wz.DI.Esstisch 2016-03-13 11:12:47 .R-fuseDelay 1 s
setstate EG.wz.DI.Esstisch 2016-12-23 10:51:14 .R-intKeyVisib set_invisib
setstate EG.wz.DI.Esstisch 2016-03-13 11:12:47 .R-ovrTempLvl 80 C
setstate EG.wz.DI.Esstisch 2016-03-13 11:12:47 .R-redLvl 40 %
setstate EG.wz.DI.Esstisch 2016-03-13 11:12:47 .R-redTempLvl 75 C
setstate EG.wz.DI.Esstisch 2016-03-13 11:12:47 .R-statusInfoMinDly 2 s
setstate EG.wz.DI.Esstisch 2016-03-13 11:12:47 .R-statusInfoRandom 1 s
setstate EG.wz.DI.Esstisch 2016-03-13 11:12:47 .R-transmitTryMax 6
setstate EG.wz.DI.Esstisch 2016-03-19 23:00:43 .peerListRDate 2016-03-19 23:00:43
setstate EG.wz.DI.Esstisch 2016-12-27 10:35:10 .protLastRcv 2016-12-27 10:35:10
setstate EG.wz.DI.Esstisch 2016-12-23 12:04:57 CommandAccepted yes
setstate EG.wz.DI.Esstisch 2016-12-23 12:04:56 D-firmware 2.2
setstate EG.wz.DI.Esstisch 2016-12-23 12:04:56 D-serialNr JEQ0207001
setstate EG.wz.DI.Esstisch 2016-12-22 20:58:48 PairedTo 0x000002
setstate EG.wz.DI.Esstisch 2016-03-13 11:12:47 R-logicCombination or
setstate EG.wz.DI.Esstisch 2016-12-23 10:51:14 R-pairCentral set_0x000002
setstate EG.wz.DI.Esstisch 2016-03-13 11:12:47 R-powerUpAction off
setstate EG.wz.DI.Esstisch 2016-03-19 23:00:42 RegL_01. 30:06 32:50 33:64 34:4B 35:50 56:00 57:24 59:01 00:00
setstate EG.wz.DI.Esstisch 2016-12-22 18:14:09 deviceMsg on (to 000001)
setstate EG.wz.DI.Esstisch 2016-12-22 18:14:09 dim stop:on
setstate EG.wz.DI.Esstisch 2016-12-22 20:54:08 level set_42
setstate EG.wz.DI.Esstisch 2016-07-21 23:13:37 levelMissed desired:100
setstate EG.wz.DI.Esstisch 2016-12-22 18:14:09 overheat off
setstate EG.wz.DI.Esstisch 2016-12-22 18:14:09 overload off
setstate EG.wz.DI.Esstisch 2016-12-22 18:14:09 pct 100
setstate EG.wz.DI.Esstisch 2016-12-22 18:14:09 phyLevel 100
setstate EG.wz.DI.Esstisch 2016-03-19 23:00:39 powerOn 2016-03-19 23:00:39
setstate EG.wz.DI.Esstisch 2016-12-22 18:14:09 recentStateType info
setstate EG.wz.DI.Esstisch 2016-12-22 18:14:09 reduced off
setstate EG.wz.DI.Esstisch 2016-12-24 23:51:28 state CMDs_done
setstate EG.wz.DI.Esstisch 2016-12-22 18:14:09 timedOn off


Diese devices funktionieren tadellos. Devices wie die Schaltaktoren hingegen liefern zwar erfolgreich ihren Status ab (wenn ich sie manuell einschalte sehe ich im FHEM dass sie eingeschaltet sind) aber das Pairing klappt nicht und schalten lassen sie sich auch nicht. Ich habe sogar versucht das Device komplett zu löschen und neu anzulernen. Das Device wird dann zwar angelegt aber das Pairing bricht nach 4 Wiederholungsversuchen erfolglos ab. Ein GetConfig mit anschließendem manuellem Schalten des Aktors endet auch in einem Timeout.

Ein Mitschnitt eines Pairing-Versuchs:

Code Auswählen Erweitern


2016.12.23 16:41:38 5: HMUARTLGW myHmLGW:keepAlive read raw (6): 3e4b39650d0a
2016.12.23 16:41:38 5: HMUARTLGW myHmLGW:keepAlive read (4): >K9e
2016.12.23 16:41:39 5: CUL_HM HM_1BE5BF protEvent:Info_Cleared
2016.12.23 16:41:39 3: CUL_HM set HM_1BE5BF clear msgEvents
2016.12.23 16:41:45 5: CUL_HM HM_1BE5BF protEvent:CMDs_pending pending:1
2016.12.23 16:41:45 5: CUL_HM HM_1BE5BF protEvent:CMDs_pending pending:2
2016.12.23 16:41:45 5: CUL_HM HM_1BE5BF protEvent:CMDs_pending pending:3
2016.12.23 16:41:45 3: CUL_HM set HM_1BE5BF getConfig
2016.12.23 16:41:45 5: HMUARTLGW myHmLGW HMUARTLGW_Write: As1015A0010000021BE5BF00040000000000
2016.12.23 16:41:45 5: HMUARTLGW myHmLGW send: 01 02 00 00 00 msg: 15 A0 01 000002 1BE5BF 00040000000000
2016.12.23 16:41:45 5: HMUARTLGW myHmLGW send: (27): fd001601ba0200000015a0010000021be5bf000400000000009286
2016.12.23 16:41:45 5: SW: fd001601ba0200000015a0010000021be5bf000400000000009286
2016.12.23 16:41:45 5: CUL_HM HM_1BE5BF protEvent:CMDs_processing... pending:2
2016.12.23 16:41:45 5: HMUARTLGW myHmLGW read raw (9): fd000401ba0404846b
2016.12.23 16:41:45 5: HMUARTLGW myHmLGW read (8): fd000401ba0404846b crc OK
2016.12.23 16:41:45 5: HMUARTLGW myHmLGW recv: 01 0404, state 100
2016.12.23 16:41:45 5: HMUARTLGW myHmLGW can't send due to unknown problem (no response?)
2016.12.23 16:41:47 5: HMUARTLGW myHmLGW checking credits (from timer)
2016.12.23 16:41:47 5: HMUARTLGW myHmLGW send: 00 08
2016.12.23 16:41:47 5: HMUARTLGW myHmLGW send: (8): fd000300bb080239
2016.12.23 16:41:47 5: SW: fd000300bb080239
2016.12.23 16:41:47 5: HMUARTLGW myHmLGW read raw (10): fd000500bb0402179011
2016.12.23 16:41:47 5: HMUARTLGW myHmLGW read (9): fd000500bb0402179011 crc OK
2016.12.23 16:41:47 5: HMUARTLGW myHmLGW recv: 00 040217, state 98
2016.12.23 16:41:47 5: HMUARTLGW myHmLGW GetSet Ack: 02, state 98
2016.12.23 16:41:47 5: HMUARTLGW myHmLGW roundtrip delay: 0.0038
2016.12.23 16:41:48 5: HMUARTLGW myHmLGW:keepAlive send (3): K9f
2016.12.23 16:41:48 5: SW: K9f

2016.12.23 16:41:48 5: HMUARTLGW myHmLGW:keepAlive read raw (6): 3e4b39660d0a
2016.12.23 16:41:48 5: HMUARTLGW myHmLGW:keepAlive read (4): >K9f
2016.12.23 16:41:50 4: CUL_HM_Resend: HM_1BE5BF nr 2
2016.12.23 16:41:50 5: HMUARTLGW myHmLGW HMUARTLGW_Write: As1015A0010000021BE5BF00040000000000
2016.12.23 16:41:50 5: HMUARTLGW myHmLGW send: 01 02 00 00 00 msg: 15 A0 01 000002 1BE5BF 00040000000000
2016.12.23 16:41:50 5: HMUARTLGW myHmLGW send: (27): fd001601bc0200000015a0010000021be5bf0004000000000004e3
2016.12.23 16:41:50 5: SW: fd001601bc0200000015a0010000021be5bf0004000000000004e3
2016.12.23 16:41:51 5: HMUARTLGW myHmLGW read raw (9): fd000401bc04048413
2016.12.23 16:41:51 5: HMUARTLGW myHmLGW read (8): fd000401bc04048413 crc OK
2016.12.23 16:41:51 5: HMUARTLGW myHmLGW recv: 01 0404, state 100
2016.12.23 16:41:51 5: HMUARTLGW myHmLGW can't send due to unknown problem (no response?)
2016.12.23 16:41:55 4: CUL_HM_Resend: HM_1BE5BF nr 3
2016.12.23 16:41:55 5: HMUARTLGW myHmLGW HMUARTLGW_Write: As1015A0010000021BE5BF00040000000000
2016.12.23 16:41:55 5: HMUARTLGW myHmLGW send: 01 02 00 00 00 msg: 15 A0 01 000002 1BE5BF 00040000000000
2016.12.23 16:41:55 5: HMUARTLGW myHmLGW send: (27): fd001601bd0200000015a0010000021be5bf00040000000000fdf0
2016.12.23 16:41:55 5: SW: fd001601bd0200000015a0010000021be5bf00040000000000fc7df0
2016.12.23 16:41:56 5: HMUARTLGW myHmLGW read raw (9): fd000401bd04040404
2016.12.23 16:41:56 5: HMUARTLGW myHmLGW read (8): fd000401bd04040404 crc OK
2016.12.23 16:41:56 5: HMUARTLGW myHmLGW recv: 01 0404, state 100
2016.12.23 16:41:56 5: HMUARTLGW myHmLGW can't send due to unknown problem (no response?)
2016.12.23 16:41:58 5: HMUARTLGW myHmLGW:keepAlive send (3): Ka0
2016.12.23 16:41:58 5: SW: Ka0

2016.12.23 16:41:58 5: HMUARTLGW myHmLGW:keepAlive read raw (6): 3e4b61300d0a
2016.12.23 16:41:58 5: HMUARTLGW myHmLGW:keepAlive read (4): >Ka0
2016.12.23 16:42:01 4: CUL_HM_Resend: HM_1BE5BF nr 4
2016.12.23 16:42:01 5: HMUARTLGW myHmLGW HMUARTLGW_Write: As1015A0010000021BE5BF00040000000000
2016.12.23 16:42:01 5: HMUARTLGW myHmLGW send: 01 02 00 00 00 msg: 15 A0 01 000002 1BE5BF 00040000000000
2016.12.23 16:42:01 5: HMUARTLGW myHmLGW send: (27): fd001601be0200000015a0010000021be5bf0004000000000076c0
2016.12.23 16:42:01 5: SW: fd001601be0200000015a0010000021be5bf0004000000000076c0
2016.12.23 16:42:02 5: HMUARTLGW myHmLGW read raw (9): fd000401be04040438
2016.12.23 16:42:02 5: HMUARTLGW myHmLGW read (8): fd000401be04040438 crc OK
2016.12.23 16:42:02 5: HMUARTLGW myHmLGW recv: 01 0404, state 100
2016.12.23 16:42:02 5: HMUARTLGW myHmLGW can't send due to unknown problem (no response?)
2016.12.23 16:42:02 5: HMUARTLGW myHmLGW checking credits (from send)
2016.12.23 16:42:02 5: HMUARTLGW myHmLGW send: 00 08
2016.12.23 16:42:02 5: HMUARTLGW myHmLGW send: (8): fd000300bf089a3a
2016.12.23 16:42:02 5: SW: fd000300bf089a3a
2016.12.23 16:42:02 5: HMUARTLGW myHmLGW read raw (10): fd000500bf0402184030
2016.12.23 16:42:02 5: HMUARTLGW myHmLGW read (9): fd000500bf0402184030 crc OK
2016.12.23 16:42:02 5: HMUARTLGW myHmLGW recv: 00 040218, state 98
2016.12.23 16:42:02 5: HMUARTLGW myHmLGW GetSet Ack: 02, state 98
2016.12.23 16:42:02 5: HMUARTLGW myHmLGW roundtrip delay: 0.0038
2016.12.23 16:42:02 5: HMUARTLGW myHmLGW checking credits (from timer)
2016.12.23 16:42:02 5: HMUARTLGW myHmLGW send: 00 08
2016.12.23 16:42:02 5: HMUARTLGW myHmLGW send: (8): fd000300c008983c
2016.12.23 16:42:02 5: SW: fd000300c008983c
2016.12.23 16:42:02 5: HMUARTLGW myHmLGW read raw (10): fd000500c0040218cc27
2016.12.23 16:42:02 5: HMUARTLGW myHmLGW read (9): fd000500c0040218cc27 crc OK
2016.12.23 16:42:02 5: HMUARTLGW myHmLGW recv: 00 040218, state 98
2016.12.23 16:42:02 5: HMUARTLGW myHmLGW GetSet Ack: 02, state 98
2016.12.23 16:42:02 5: HMUARTLGW myHmLGW roundtrip delay: 0.0039
2016.12.23 16:42:06 5: CUL_HM HM_1BE5BF protEvent:CMDs_done_Errors:1


Der Schaltaktor sieht danach so aus:

Code Auswählen Erweitern


defmod HM_1BE5BF CUL_HM 1BE5BF
attr HM_1BE5BF IODev myHmLGW
attr HM_1BE5BF autoReadReg 4_reqStatus
attr HM_1BE5BF expert 2_raw
attr HM_1BE5BF firmware 1.9
attr HM_1BE5BF model HM-LC-SW1-PL2
attr HM_1BE5BF room CUL_HM
attr HM_1BE5BF serialNr JEQ0465499
attr HM_1BE5BF subType switch
attr HM_1BE5BF verbose 5
attr HM_1BE5BF webCmd statusRequest:toggle:on:off

setstate HM_1BE5BF MISSING ACK
setstate HM_1BE5BF 2016-12-27 12:49:10 .D-devInfo 010100
setstate HM_1BE5BF 2016-12-27 12:49:10 .D-stc 10
setstate HM_1BE5BF 2016-12-27 12:49:10 .R-intKeyVisib set_invisib
setstate HM_1BE5BF 2016-12-27 12:49:11 .protLastRcv 2016-12-27 12:49:11
setstate HM_1BE5BF 2016-12-27 12:49:11 CommandAccepted yes
setstate HM_1BE5BF 2016-12-27 12:49:10 D-firmware 1.9
setstate HM_1BE5BF 2016-12-27 12:49:10 D-serialNr JEQ0465499
setstate HM_1BE5BF 2016-12-27 12:49:10 R-pairCentral set_0x000002
setstate HM_1BE5BF 2016-12-27 10:35:17 deviceMsg on (to broadcast)
setstate HM_1BE5BF 2016-12-27 10:35:17 level 100
setstate HM_1BE5BF 2016-12-27 10:35:17 pct 100
setstate HM_1BE5BF 2016-12-27 10:35:17 recentStateType info
setstate HM_1BE5BF 2016-12-27 12:48:19 state MISSING ACK
setstate HM_1BE5BF 2016-12-27 10:35:17 timedOn off


So langsam werde ich noch irre. Wieso funktionieren einige Devices und andere wieder nicht? Habt ihr noch einen Tipp?

Vielen Dank und viele Grüße
Micha

[Otto123]

Hallo Micha,

die Gretchenfrage: Warum überhaupt der Aufwand mit neu pairen?

Dein HM-LC-SW1-PL2 hat die Befehle nicht erhalten oder will nicht senden. Eventuell hilft Anlerntaste drücken.
Die gesnifften Nachrichten kann ich noch nicht richtig deuten, da fehlt mir das Wissen.

Hinweis, ein list vom device ist deutlich besser als die rawdefinition!.

Gruß Otto

[muecke36]

Hallo Otto,

gute Frage... Habe jetzt die HMID auf dieselbe wie bei dem bisherigen HMLAN Adapter gesetzt und jetzt klappt alles.

Vielen Dank für den Tipp und einen guten Rutsch
Micha

[Otto123]

Hallo Otto,

gute Frage... Habe jetzt die HMID auf dieselbe wie bei dem bisherigen HMLAN Adapter gesetzt und jetzt klappt alles.

Vielen Dank für den Tipp und einen guten Rutsch
Micha

genau so wird's gemacht!  oder VCCU und einfach den einen deaktivieren und den anderen aktivieren.

Guten Rutsch

[Puschel74]

einfach den einen deaktivieren und den anderen aktivieren.

Guten Rutsch

Was aber nicht so einfach klappt wenn der andere später dazu kommt und den einen ersetzen soll 
Dir übrigens auch einen Guten Rutsch @Otto123 

Ich habe meinen HMLAN Konfigurationsadapter durch ein LAN Gateway ersetzen müssen

Das beide die selbe HMID haben sollten ist vermutlich jetzt klar aber ...
Das Lan-Gateway wurde vermutlich erst später hinzu gefügt - soll heissen: Das LAN Gateway wird jetzt wohl auch Devices bedienen die VORHER schon definiert wurden.
Die Reihenfolge in der Konfig passt also nichtmehr.

Das ist der einzige (für mich plausible) Grund warum die fhem.cfg manuell bearbeitet werden sollte.
Das neue Gateway muss noch VOR der vCCU in der fhem.cfg stehen und beide (das Gateway UND die vCCU) müssen VOR dem ersten HM-Device in der fhem.cfg stehen.
Sonst gibt es spätestens beim nächsten restart (der bei einem update unweigerlich kommt) die nächst Frage woher diverse Meldungen im Logfile kommen 

[Otto123]

Das ist der einzige (für mich plausible) Grund warum die fhem.cfg manuell bearbeitet werden sollte.
Das neue Gateway muss noch VOR der vCCU in der fhem.cfg stehen und beide (das Gateway UND die vCCU) müssen VOR dem ersten HM-Device in der fhem.cfg stehen.
Sonst gibt es spätestens beim nächsten restart (der bei einem update unweigerlich kommt) die nächst Frage woher diverse Meldungen im Logfile kommen 

Hallo Puschel74,

wenn ich ganz ehrlich bin, ich habe das schon mal gelesen. Und habe das damals nicht richtig verstanden.
Und ich habe mir auch noch nie wegen meiner Installation einen Kopf gemacht und habe gerade gedacht: deswegen habe ich auch keine Fehlermeldungen im Log 
Jetzt habe ich mir mal meine fhem.cfg angeschaut. Und Du hast natürlich Recht, mein HMUART Modul steht relativ weit hinten.
Aber mein HMLAN steht ganz vorne.
Es ist also so, dass bei mir alles i.O ist weil mein HMLAN die Arbeit beim Start übernimmt!? Wenn ich den mal taub schalte sollte ich also Probleme beim Start haben?!

Na das werde ich mal durchspielen und dann mal meine fhem.cfg "sortieren".

danke für die Anregung und Gruß
Otto

[Puschel74]

Es ist also so, dass bei mir alles i.O ist weil mein HMLAN die Arbeit beim Start übernimmt!? Wenn ich den mal taub schalte sollte ich also Probleme beim Start haben?!

Öh, das glaube ich nicht.

Selbst mit einer vCCU hat jedes HM-Device ein IODev.
"Probleme" aka Meldungen im Logfile solltest du bekommen wenn beim einlesen der Konfig (was bei einem restart unweigerlich passiert) ein HM-Device definiert wird mit einem IODev das zu diesem
Zeitpunkt noch nicht existiert.

Das kann eigentlich nur daher kommen das ein bereits von Anfang an vorhandenes IODev gegen ein neueres getauscht wird - oder ein zusätzlich IODev später hinzu kommt.

Im worst-case (so wie bei mir und vermutlich auch vielen anderen FHEM-User) hast du deine IODev als erstes eingebunden - klar, ohne geht auch nichts.
Dann wurde eine vCCU definiert - so soll es auch sein.
Danach kamen die ersten Devices.
Naja Devices hat man idR mehr als IODev also alle brav mit der vCCU pairen und sich der Funktion dank peering oder FHEM erfreuen.
So fügt FHEM ein Device nach dem anderen in die fhem.cfg ein und zwar in der Reihenfolge wie sie gepairt/erkannt/angelegt wurden.

Nun kommt ein neues IODev hinzu - egal aus welchen Gründen (altes defekt oder einfach mal was zum versuchen oder warum auch immer).
Gehen wir mal davon aus das das alte defekt ist und ersetzt wurde.
Das neue wird natürlich gnadenlos an das Ende der fhem.cfg gestellt - woher soll FHEM auch wissen das das neue Teil vorne dran gehört.
Ein save wird vermutlich öfter gemacht als ein restart - ich starte FHEM z.B. nur neu wenn ich einen Grund dafür habe (update von FHEM ist bei mir der einzige Grund und ein FHEM-update gibt es bei mir sehr selten).
Also wird kein restart gemacht - muss nach einem einfügen eines neuen Devices auch nicht, es funktioniert ja alles und ist auch nicht notwendig.
Nun kommt es das es den User juckt und er macht ein FHEM-Update ... die Dateien werden runtergeladen ... danach steht ein shutdown/restart an und ... das war es dann.
Das Logfile wird geflutet mit z.B.

configfile: EG.ez.SD.Staubsauger: unknown IODev meinLGW specified

Sobald FHEM die gesamte Konfig eingelesen hat ist der Spuk auch schon vorbei - im laufenden Betrieb sind die Devices ja vorhanden.

Beim nächsten restart geht es aber dann wieder los.
Daher sind meine IODev am Anfang der Konfig (nach der Definition von autocreate) angesiedelt und ich hab keine Meldungen in Logfile.
Aber wie ich schon geschrieben habe:
Das ist der einzige (für mich plausible) Grund warum die fhem.cfg manuell bearbeitet werden sollte.

[Otto123]

Ok danke Dir!
Ausführlicher geht es nicht, ich habe es verstanden. 

Ich werde das mal umstellen, denn irgendwann denke ich mehr nicht dran.

Nochmal guten Rutsch!
Otto