HM-LGW-O-TW-W-EU-2 / CUL als VCCU und AES

[automatisierer]

Du sagst es doch selbst: Die erste Kommunikation mit AES schlägt fehl. PreffIO hin oder her.

Es bringt mir also an dieser Stelle einfach Nichts. Punkt. Nimm´s hin

Letzter Versuch.
Wenn der preffIO das Device nicht erreicht, aber 'cond ok' ist, dann wird jede Kommunikation fehlschlagen. Die vccu sendet dann immer über das preffIO und nicht über den IO der bessere rssi Werte hat.

Beispiel - ohne preffIO:

Die FB sendet zu 1. mal
LGW und CUL empfangen
die vccu wertet die rssi Werte aus und entscheidet das der CUL das sendende IO wird.
die FB wird dem CUL zugewiesen
die vccu antwortet uber CUL - AES klappt wegen des timings nicht.
--Fehlversuch--

Die FB sendet zum 2. mal
LGW und CUL empfangen
die vccu wertet die rssi Werte aus und entscheidet das der CUL das sendende IO wird.
die FB ist dem CUL bereits zugewiesen
die vccu antwortet uber CUL - nun klappt AES, weil es nicht zu timning Problemen kommt.
--Befehl angekommen und ausgeführt--

Die FB sendet zum 3. mal
LGW und CUL empfangen
die vccu wertet die rssi Werte aus und entscheidet das der LGW das sendende IO wird.
die FB wird dem LGW zugewiesen
die vccu antwortet uber LGW - AES klappt wegen des timings nicht.
--Fehlversuch--

Die FB sendet zum 4. mal
LGW und CUL empfangen
die vccu wertet die rssi Werte aus und entscheidet das der LGW das sendende IO wird.
die FB ist dem LGW bereits zugewiesen
die vccu antwortet uber LGW - nun klappt AES, weil es nicht zu timning Problemen kommt.
--Befehl angekommen und ausgeführt--
usw...


Beispiel - mit preffIO:

Die FB sendet zu 1. mal
LGW und CUL empfangen
die vccu wertet die rssi Werte nicht aus, das preffIO wird das sendende IO.
die FB wird dem preffIO zugewiesen
vccu antwortet über preffIO - AES klappt wegen des timings nicht.
--Fehlversuch--

Die FB sendet zu 2. mal
LGW und CUL empfangen
die vccu wertet die rssi Werte nicht aus, das preffIO wird das sendende IO.
die FB ist dem preffIO bereits zugewiesen
vccu antwortet über preffIO - nun klappt AES, weil es nicht zu timning Problemen kommt.
--Befehl angekommen und ausgeführt--

Die FB sendet zu 3. mal
LGW und CUL empfangen
die vccu wertet die rssi Werte nicht aus, das preffIO wird das sendende IO.
die FB ist dem preffIO bereits zugewiesen
vccu antwortet über preffIO - FB ist außerhalb der Reichweite des preffIO
--Fehlversuch--

Die FB sendet zu 4. mal
LGW (preffIO aber disconnect) und CUL empfängt
die vccu wertet die rssi Werte aus, der CUL wird das sendende IO.
die FB wird dem CUL zugewiesen
vccu antwortet über CUL - AES klappt wegen des timings nicht.
--Fehlversuch--

[Klinki]

Das ist mal eine Ausführung. Danke dafür!

Deckt sich ja grundsätzlich auch mit meiner Beobachtung. Nur gibt es halt immer wieder die Fälle (die 10%), dass die AES-Signierung sporadisch nicht funktioniert. Man hat halt auch nicht immer Sniffing an oder Zeit sich damit zu beschäftigen.

Nur Dein letztes Beispiel ist mir nicht klar:

Code Auswählen Erweitern

Die FB sendet zu 4. mal
LGW (preffIO aber disconnect) und CUL empfängt
die vccu wertet die rssi Werte aus, der CUL wird das sendende IO.
die FB wird dem CUL zugewiesen
vccu antwortet über CUL - AES klappt wegen des timings nicht.
--Fehlversuch--

Die FB sollte doch bei den Versuchen 1-3 dem CUL zugewiesen werden - wenn LGW außer Reichweite, richtig? Dann müsste Versuch 2 doch eigentlich schon funktionieren...

[automatisierer]

Das ist mal eine Ausführung. Danke dafür!

Deckt sich ja grundsätzlich auch mit meiner Beobachtung. Nur gibt es halt immer wieder die Fälle (die 10%), dass die AES-Signierung sporadisch nicht funktioniert. Man hat halt auch nicht immer Sniffing an oder Zeit sich damit zu beschäftigen.

Nur Dein letztes Beispiel ist mir nicht klar:

Code Auswählen Erweitern

Die FB sendet zu 4. mal
LGW (preffIO aber disconnect) und CUL empfängt
die vccu wertet die rssi Werte aus, der CUL wird das sendende IO.
die FB wird dem CUL zugewiesen
vccu antwortet über CUL - AES klappt wegen des timings nicht.
--Fehlversuch--

Die FB sollte doch bei den Versuchen 1-3 dem CUL zugewiesen werden - wenn LGW außer Reichweite, richtig? Dann müsste Versuch 2 doch eigentlich schon funktionieren...

ich war davon ausgegangen, dass der LGW der preffIO ist...

... gedacht ist nicht gesagt...


Ja, mit AES ist halt ein wenig schwierigwer als ohne. Da geantwortet werden muss und das in einem 'engen' Zeitfenster. Gerade bei beweglichen Devices gestaltet es sich schwierig, da sich die beiden Gesprächspartner 'unterhalten' müssen. Nutzt man AES bei Fernbedienungen nicht, dann müssen die IO's ja quasi nur zuhören. Und das können alle IO's gleichzeitig machen.

[Klinki]

ich war davon ausgegangen, dass der LGW der preffIO ist...

Deine Annahme war schon richtig. LGW ist das pref-IO. Ich will jetzt hier keine Haare spalten, es geht nur darum, ob ich Dein letztes Beispiel richtig verstanden habe.
Ich mache auch mal grad ein Beispiel:

1. Tastendruck
LGW ist prefIO und nicht erreichbar (rssi ist Minus Unendlich)
-> CUL empfängt
-> vccu wertet rssi aus und CUL wird das sendende IO
-> FB wird CUL zugewiesen
-> vccu antwortet über CUL - AES klappt wegen des timings nicht.
--Fehlversuch--

2. Tastendruck
LGW ist prefIO und nicht erreichbar (rssi ist Minus Unendlich)
-> CUL empfängt
-> der CUL ist der FB bereits als Sender zugewiesen
-> vccu antwortet über CUL
--AES funktioniert--

stimmt das woweit?

kurzum: wenn das sendende IO beim letzten Mal ein anderes war, geht die AES-Signierung immer schief? Kann man das so sagen?

[automatisierer]

wenn der LGW der preffIO ist, dann sendet die vccu immer über diesen IO - wirklich immer!! egal wie die rssi Werte sind. und egal über welchen IO die Sendung der FB empfangen wurde.

Die einzige Ausnahme in der die vccu von dem preffIO abweicht, ist, wenn der IO für die vccu nicht verfügbar ist. Das ist der Fall, wenn der IO z.B. den Zustand disconnected oder overload hat.

[Klinki]

Verstanden. Danke nochmal für Deine Mühe & Geduld!

Ist aber schon etwas unpraktisch wenn das LGW überhaupt nicht vom Device gesehen (also praktisch kein rssi) wird und es dennoch als IO benutzt wird. Für meinen Zweck aber genau das Richtige!

Nur noch eine Randbemerkung: Nach meinem ganzen "Rumgefummel" funktionierte die AES-Signierung über das LGW plötzlich gar nicht mehr. "Plötzlich" kann ich leider nicht näher beschreiben.
Das LGW hatte dabei nach wie vor den Status "open". Ohne AES funktionierte die Kommunikation auch nach wie vor.

Jedenfalls brachte es Abhilfe das LGW neu zu starten. Diesmal nicht über Stecker raus/rein, sondern über das NetFinder-Programm und "Gerät neu starten". Man kann dabei beobachten wie das Gerät dann für eine halbe Minuten aus dem Netzwerk verschwindet, ein ping also in´s Leere läuft.

Ein "close"/"open" oder "restart" per fhem reichte dabei nicht.

[frank]

du kannst deiner fernbedienung auch das lgw als "permanentes" io zuweisen, obwohl das io mit der vccu assigned ist.
wenn du das attribut IOgrp löscht, sendet immer das io, welches im attr IODev steht. hat natürlich den nachteil, dass auch bei "defektem" io kein roaming stattfindet.

[Klinki]

du kannst deiner fernbedienung auch das lgw als "permanentes" io zuweisen, obwohl das io mit der vccu assigned ist.
wenn du das attribut IOgrp löscht, sendet immer das io, welches im attr IODev steht. hat natürlich den nachteil, dass auch bei "defektem" io kein roaming stattfindet.

Hallo Frank,

Ich habe es jetzt ein paar Tage mit dem bevorzugten IO versucht. Es lief nicht sonderlich gut. Daraufhin habe ich denn man Deinen Tipp befolgt und IOgrp gelöscht und das LGW als IODev gesetzt. Die ersten Versuche waren bisher erfolgreich. Was ich aber noch nicht so recht verstehe: Der CUL scheint an der Kommunikation doch immer noch beteiligt zu sein - oder sehe ich das falsch?

Hier das Sniffing (Kommunikation hat geklappt):

Code Auswählen Erweitern

2017.01.12 07:21:51.952 4 : CUL_Parse: CUL_0 A 0B FF A240 39776C F0815F 033A17 -62.5
2017.01.12 07:21:52.085 4 : CUL_Parse: CUL_0 A 11 FF A002 F0815F 39776C 04A221000021080204 -72
2017-01-12 07:21:52.096 CUL_HM vccu aesKeyNbr: 02
2017.01.12 07:21:52.207 0 : HMUARTLGW meinLGW recv: 01 05 02 01 56 msg: FF A2 40 39776C F0815F 033A
2017-01-12 07:21:52.214 CUL_HM FB_Thomas aesCommToDev: pending
2017-01-12 07:21:52.225 CUL_HM FB_Thomas aesCommToDev: ok
2017.01.12 07:21:52.227 4 : CUL_Parse: CUL_0 A 19 FF A003 39776C F0815F 4907ABC589E58A235BD13DA4CD74DB371A -61
2017-01-12 07:21:52.240 CUL_HM FB_Thomas aesReqTo: vccu
2017.01.12 07:21:52.330 4 : CUL_Parse: CUL_0 A 0E FF 8002 F0815F 39776C 00CCB2FF1E06 -71
2017.01.12 07:21:52.452 4 : CUL_Parse: CUL_0 A 0B 00 A240 39776C F0815F 033A1B -60.5
2017-01-12 07:21:52.505 CUL_HM FB_Thomas_light trig_aes_vccu: ok:58
2017.01.12 07:21:52.586 4 : CUL_Parse: CUL_0 A 11 00 A002 F0815F 39776C 04465E00005E170205 -71.5
2017-01-12 07:21:52.600 CUL_HM vccu aesKeyNbr: 02
2017.01.12 07:21:52.708 0 : HMUARTLGW meinLGW recv: 01 05 02 01 55 msg: 00 A2 40 39776C F0815F 033A
2017-01-12 07:21:52.719 CUL_HM FB_Thomas aesCommToDev: pending
2017-01-12 07:21:52.731 CUL_HM FB_Thomas aesCommToDev: ok
2017.01.12 07:21:52.733 4 : CUL_Parse: CUL_0 A 19 00 A003 39776C F0815F 63971BF56298C1B94F6615B4FD9DA0681B -60.5
2017-01-12 07:21:52.749 CUL_HM FB_Thomas aesReqTo: vccu

Listing zur Fernbedienung:

Code Auswählen Erweitern

Internals:
   CUL_0_MSGCNT 67
   CUL_0_RAWMSG A1900A00339776CF0815F63971BF56298C1B94F6615B4FD9DA068::-60.5:CUL_0
   CUL_0_RSSI -60.5
   CUL_0_TIME 2017-01-12 07:21:52
   DEF        39776C
   IODev      meinLGW
   LASTInputDev CUL_0
   MSGCNT     168
   NAME       FB_Thomas
   NOTIFYDEV  global
   NR         536
   NTFY_ORDER 50-FB_Thomas
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 FB_Thomas_armInt
   channel_02 FB_Thomas_armExt
   channel_03 FB_Thomas_light
   channel_04 FB_Thomas_disarm
   lastMsg    No:00 - t:03 s:39776C d:F0815F 63971BF56298C1B94F6615B4FD9DA068
   meinLGW_MSGCNT 101
   meinLGW_RAWMSG 0502015500A24039776CF0815F033A
   meinLGW_RSSI -85
   meinLGW_TIME 2017-01-12 07:21:52
   protEvt_AESCom-ok 23 last_at:2017-01-12 07:21:52
   protLastRcv 2017-01-12 07:21:52
   protSnd    66 last_at:2017-01-12 07:21:52
   protState  CMDs_done
   rssi_at_CUL_0 avg:-62 min:-91 max:-55.5 lst:-60.5 cnt:67
   rssi_at_meinLGW avg:-80.78 min:-89 max:-46 lst:-85 cnt:23
   Helper:
     Dblog:
       Battery:
         Logdb:
           TIME       1484202112.46633
           VALUE      ok
   Readings:
     2017-01-11 10:26:27   CommandAccepted yes
     2017-01-12 07:09:58   D-firmware      1.2
     2017-01-12 07:09:58   D-serialNr      MEQ0076971
     2017-01-11 10:12:02   PairedTo        0xF0815F
     2017-01-11 10:12:02   R-pairCentral   0xF0815F
     2017-01-11 10:12:01   RegL_00.        02:01 0A:F0 0B:81 0C:5F 18:00 00:00
     2017-01-12 07:21:52   aesCommToDev    ok
     2017-01-11 10:12:33   aesKeyNbr       00
     2017-01-12 07:21:52   aesReqTo        vccu
     2017-01-12 07:21:52   battery         ok
     2017-01-12 07:21:52   state           CMDs_done
   Helper:
     HM_CMDNR   0
     PONtest    1
     mId        00A5
     rxType     20
     supp_Pair_Rep 0
     Ack:
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +39776C,01,01,1E
       nextSend   1484202112.83503
       prefIO
       rxt        2
       vccu
       p:
         39776C
         01
         01
         1E
     Mrssi:
       mNo        00
       Io:
         CUL_0      -60.5
         meinLGW    -83
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       dev        1
     Rpt:
       IO         CUL_0
       flg        A
       ts         1484202112.73981
       ack:
         HASH(0x20df878)
         008002F0815F39776C00
     Rssi:
       At_cul_0:
         avg        -62.0074626865672
         cnt        67
         lst        -60.5
         max        -55.5
         min        -91
       At_meinlgw:
         avg        -80.7826086956522
         cnt        23
         lst        -85
         max        -46
         min        -89
     Tmpl:
   Role:
Attributes:
   IODev      meinLGW
   aesCommReq 1
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.2
   group      Fernbedienung
   model      HM-RC-Sec4-2
   room       EDV
   serialNr   MEQ0076971
   subType    remote
   webCmd     getConfig:clear msgEvents

[frank]

ich sehe im log keine message, die der cul sendet.
empfangen kann der cul natürlich weiterhin. wie willst du ihm das verbieten? man kann also nur das senden steuern. das sieht man immer schön an den internals:

Code Auswählen Erweitern

   IODev      meinLGW
   LASTInputDev CUL_0

gesendet wurde mit lgw, der letzte empfang kam vom cul.

was willst du eigentlich genau erreichen und was stört dich bisher?
nur die anzeige im log "bereinigen"?

[automatisierer]

ich sehe in dem IOgrp löschen und nur IOdev setzen keinen großen Unterschied.
außer das die vccu komplett hinten vor bleibt...

Zum Tjema AES im allgemeinen - Ich habe auch immer mal wieder Probleme damit. Ich habe mit dem neuen DOIFtools Modul (noch beta) das Funk und Event aufkommen in meinem HM-System deutlich verringert, von 2100 Events/h auf nun ca. 500. Dazu kam noch eine HM Messsteckdose für die Waschmaschine, die alleine hat wenn die Maschine lief ca 2000Events erzeugt - jetzt noch 150!
Seit dem funktionieren die AES Geräte besser!

[Klinki]

Hi Frank,

So lange die Kommunikation funktioniert, dürfen im Log auch die Lottozahlen von 1980 stehen 

Spaß beiseite: Ich verstehe es halt nicht. Bin davon ausgegangen, dass die Kommunikation (Senden/Empfangen) immer zwischen 2 Partnern stattfinden muss. In der zweiten Zeile

Code Auswählen Erweitern

2017.01.12 07:21:52.085 4 : CUL_Parse: CUL_0 A 11 FF A002 F0815F 39776C 04A221000021080204 -72
steht, nach meinem Verständnis, dass das Device CUL_0 wieder an der Kommunikation beteiligt ist. Aber eigentlich sollte doch nur über das LGW gefunkt werden, oder gilt das nur für die Senderichtung? IODev heißt doch Input/Output Device...

Es geht mir um die Steuerung einer Alarmanlage (scharf/unscharf/Cancel) mit besagten Fernbedienungen. Da sicherheitskritisch mit AES-Signierung. Das muss nur im Funkbereich des LGW sauber funktionieren.
Nur funktioniert genau dies nicht sehr zuverlässig. Ich hatte gehofft, über die Sniffing-Logs die Probleme weiter eingrenzen zu können. Aber mir fehlt offensichtlich das Verständnis.
Mir wurde gesagt, dass die AES-Signierung nicht funktioniert, wenn mehrere IO-Devices beteiligt sind. Deshalb den habe ich den Eintrag mit der IOGruppe entfernt und nur noch ein Device.

Zum Tjema AES im allgemeinen - Ich habe auch immer mal wieder Probleme damit. Ich habe mit dem neuen DOIFtools Modul (noch beta) das Funk und Event aufkommen in meinem HM-System deutlich verringert, von 2100 Events/h auf nun ca. 500. Dazu kam noch eine HM Messsteckdose für die Waschmaschine, die alleine hat wenn die Maschine lief ca 2000Events erzeugt - jetzt noch 150!
Seit dem funktionieren die AES Geräte besser!

...das Thema werde ich mir mal anschauen!

Aber dennoch würde ich die Sniffing-Logs gerne besser verstehen. Gibt es diesbezüglich vielleicht Dokumentation oder einen Leitfaden?

Gruß
klinki

[frank]

Code Auswählen Erweitern

2017.01.12 07:21:52.085 4 : CUL_Parse: CUL_0 A 11 FF A002 F0815F 39776C 04A221000021080204 -72
cul_parse sind empfangene messages, beim senden dann cul_send. send gibt es in deinem log nicht.
es ist eine message von device F0815F an device 39776C. also deine zentrale an die fb. da der cul mdiese nicht gesendet hat muss sie vom lgw gesendet worden sein, falls du nur diese beiden io hast.

für aes doku würde ich das forum nach beiträgen von mgernoth durchsuchen und einen blick auf seine "homepage" empfehlen. https://git.zerfleddert.de/hmcfgusb/AES/

[Klinki]

Code Auswählen Erweitern

2017.01.12 07:21:52.085 4 : CUL_Parse: CUL_0 A 11 FF A002 F0815F 39776C 04A221000021080204 -72
cul_parse sind empfangene messages, beim senden dann cul_send. send gibt es in deinem log nicht.
es ist eine message von device F0815F an device 39776C. also deine zentrale an die fb. da der cul mdiese nicht gesendet hat muss sie vom lgw gesendet worden sein, falls du nur diese beiden io hast.

Verstehe ich das richtig und man sieht dieser Nachricht nicht an über welches IO sie geschickt wurde?

[frank]

Verstehe ich das richtig und man sieht dieser Nachricht nicht an über welches IO sie geschickt wurde?

richtig. man erkennt nur die sender id.

[Klinki]

Hier jetzt ein Beispiel für den Zustand wenn die AES-Signierung zuverlässig nicht funktioniert.
Es wird hier auch der AES-Key Nummer 00 verwendet. Ich meine, grundsätzlich ist der Index ja richtig: die VCCU kennt nur den einen AES-Key und beim Schlüssel steht ja auch im Reading KeyNbr 00.

Außer einem "Shutdown restart" ist seit dem letzten Posting nichts passiert

Code Auswählen Erweitern

2017.01.12 11:21:41.007 4 : CUL_Parse: CUL_0 A 0B 2B A240 39776C F0815F 034122 -57
2017-01-12 11:21:41.048 CUL_HM FB_Thomas battery: ok
2017-01-12 11:21:41.048 CUL_HM FB_Thomas CMDs_done
2017-01-12 11:21:41.048 CUL_HM FB_Thomas FB_Thomas_light Short
2017-01-12 11:21:41.067 CUL_HM FB_Thomas_light Short (to vccu)
2017-01-12 11:21:41.067 CUL_HM FB_Thomas_light trigger: Short_65
2017-01-12 11:21:41.067 CUL_HM FB_Thomas_light trigger_cnt: 65
2017.01.12 11:21:41.141 4 : CUL_Parse: CUL_0 A 11 2B A002 F0815F 39776C 042C3F00003F0F0003 -72.5
2017-01-12 11:21:41.152 CUL_HM vccu aesKeyNbr: 00
2017.01.12 11:21:41.258 4 : CUL_Parse: CUL_0 A 0B 2C A240 39776C F0815F 034121 -57.5
2017-01-12 11:21:41.292 CUL_HM FB_Thomas battery: ok
2017-01-12 11:21:41.292 CUL_HM FB_Thomas CMDs_done
2017-01-12 11:21:41.292 CUL_HM FB_Thomas FB_Thomas_light Short
2017-01-12 11:21:41.312 CUL_HM FB_Thomas_light Short (to vccu)
2017-01-12 11:21:41.312 CUL_HM FB_Thomas_light trigger: Short_65
2017-01-12 11:21:41.312 CUL_HM FB_Thomas_light trigger_cnt: 65
2017.01.12 11:21:41.399 0 : HMUARTLGW meinLGW recv: 01 05 03 00 57 msg: 2B A2 40 39776C F0815F 0341
2017-01-12 11:21:41.407 CUL_HM FB_Thomas aesCommToDev: pending
2017-01-12 11:21:41.428 CUL_HM FB_Thomas_light trig_aes_vccu: fail:65
2017-01-12 11:21:41.432 CUL_HM FB_Thomas aesCommToDev: fail
2017.01.12 11:21:41.495 0 : HMUARTLGW meinLGW send: 00 08
2017.01.12 11:21:41.505 0 : HMUARTLGW meinLGW recv: 00 040203, state 98
2017.01.12 11:21:41.507 0 : HMUARTLGW meinLGW GetSet Ack: 02, state 98
2017.01.12 11:21:41.509 0 : HMUARTLGW meinLGW roundtrip delay: 0.0072
2017.01.12 11:21:41.512 4 : CUL_Parse: CUL_0 A 0B 2D A240 39776C F0815F 034120 -58
2017-01-12 11:21:41.546 CUL_HM FB_Thomas battery: ok
2017-01-12 11:21:41.546 CUL_HM FB_Thomas CMDs_done
2017-01-12 11:21:41.546 CUL_HM FB_Thomas FB_Thomas_light Short
2017-01-12 11:21:41.565 CUL_HM FB_Thomas_light Short (to vccu)
2017-01-12 11:21:41.565 CUL_HM FB_Thomas_light trigger: Short_65
2017-01-12 11:21:41.565 CUL_HM FB_Thomas_light trigger_cnt: 65
2017.01.12 11:21:41.641 4 : CUL_Parse: CUL_0 A 11 2D A002 F0815F 39776C 04963D00003D0F0002 -73
2017-01-12 11:21:41.652 CUL_HM vccu aesKeyNbr: 00
2017.01.12 11:21:41.763 0 : HMUARTLGW meinLGW recv: 01 05 03 00 58 msg: 2D A2 40 39776C F0815F 0341
2017-01-12 11:21:41.774 CUL_HM FB_Thomas aesCommToDev: pending
2017-01-12 11:21:41.797 CUL_HM FB_Thomas_light trig_aes_vccu: fail:65
2017-01-12 11:21:41.801 CUL_HM FB_Thomas aesCommToDev: fail
2017.01.12 11:21:41.803 4 : CUL_Parse: CUL_0 A 19 2D A003 39776C F0815F 882A2A12D50B5EF9D344F3C2CC54396120 -58
2017-01-12 11:21:41.816 CUL_HM FB_Thomas aesReqTo: vccu
2017-01-12 11:21:41.816 CUL_HM FB_Thomas CMDs_done
2017.01.12 11:21:48.066 0 : HMUARTLGW meinLGW:keepAlive send (3): K36
2017.01.12 11:21:48.074 0 : HMUARTLGW meinLGW:keepAlive read (4): >K36

..langsam macht es keinen Spaß mehr