Anlernen von Homematic IP-Geräten an RaspberryMatic

Einrichtung, Nutzung und Hilfe zu RaspberryMatic (OCCU auf Raspberry Pi)

Moderatoren: jmaus, Co-Administratoren

jkfm
Beiträge: 3
Registriert: 08.11.2018, 14:09

Re: Anlernen von Homematic IP-Geräten an RaspberryMatic

Beitrag von jkfm » 14.11.2018, 13:36

Hallo zusammen,
ich tippe weiterhin auf eine gestörte Funkverbindung von der RMatic zu dem jeweiligem Modul.
Bei mir hat eine Veränderung an der externen Antenne geholfen. Oder war es vielleicht nur Zufall?
Bei Dax war es eine schlechte Lötverbindung am Antennenmodul.
Bei horos72 hat nach der Entfernung der PiUSV alles funktioniert.

Bei vermuteten HF-Störungen könnte man vielleicht folgendes probieren:
- Antenne anders ausrichten
- eine externe abgesetzte Antenne verwenden
- das Steckernetzteil tauschen
- Ferritkern in die Stromzufuhr einbauen
- WLAN in der RMatic deaktivieren

Gruß
jkfm

qwertz
Beiträge: 141
Registriert: 15.02.2012, 19:35

Re: Anlernen von Homematic IP-Geräten an RaspberryMatic

Beitrag von qwertz » 14.11.2018, 19:30

Ein anderer Vorschlag ergibt sich hieraus:
viewtopic.php?f=19&t=45758&start=20#p463578

kurz gesagt:
Einfach mal 48h den Raspi in Ruhe lassen: kein Reboot, kein Gefummel, kein Backup-Restore, Modultausch o.Ä.

Dann nochmal probieren. Vielleicht muss sich der Raspi mal in Ruhe mit dem EQ3-Key-Server unterhalten.

dnalor
Beiträge: 3
Registriert: 12.11.2018, 20:29
Wohnort: Schweiz

Re: Anlernen von Homematic IP-Geräten an RaspberryMatic

Beitrag von dnalor » 15.11.2018, 07:35

Hallo
Vielen Dank für die Tips. Es hat mich sehr gefreut ein Echo auf meinen Input zu bekommen.
Inzwischen habe ich beide Ratschläge befolgt, das Problem besteht leider weiterhin.
Bis auf das Anbringen einer echten Funk-Antenne habe ich alles versucht. Dies werde ich nachholen sobald ich mir eine solche beschafft habe.
Im weiteren habe ich mir das neueste Funk-Modul beschafft. Leider sind die Lieferzeiten etwas lang weshalb ich hier vorerst nicht weiter komme.
Sobald ich das getestet habe werde ich es hier Posten.
Vielen Dank.

Gruss
Roland S.

Schattenschimmer
Beiträge: 117
Registriert: 20.03.2016, 20:49

Re: Anlernen von Homematic IP-Geräten an RaspberryMatic

Beitrag von Schattenschimmer » 18.11.2018, 20:41

Hallo,

ebenfalls vielen Dank für die Tipps.
Leider habe ich es immer noch nicht geschafft, den hmIP-BSL an die RaspiMatic (= RM) anzulernen.

Meine letzten erfolglosen Versuche:
1. anlernen mit meiner life-RM, auch mit einigen Tagen Pause ohne die RM "anzufassen"
2. anlernen mit dem gleichen Raspi, jedoch mit einer jungfräulichen SD-Karte und einem jungfräulichen Image V3.37.8.20181026
3. anlernen mit dem gleichen Raspi und dem jungfräulichen Image, jedoch mit dem kleinen Funkmodul HM-MOD-RPI anstelle dem großen Funkmodul RPI-RF-MOD. 1x halbe Anmeldung: hmIP-BSL erschien in der Geräteliste. Konfiguration, Bedienung und Löschen nicht möglich. Aktueller Status wird jedoch angezeigt. Stellt sich im Grunde dar, als ob die RM vom hmIP-BSL empfangen, aber nicht zum hmIP-BSL senden kann. Hatte ich schon mal mit der life RM, siehe weiter oben.
4. anlernen mit dem kleinen Funkmodul und nach einem Systemreset

Ich habe jeden Versuch mehrfach durchgehführt, Entfernung zur RM dieses Mal ca. 2m mit Sichtkontakt.


Versuch an der jungfräulichen CCU2 funktioniert spontan und problemlos.
HM-Geräte (ohne IP) lassen sich an der RM problemlos anlernen.


Auffällig bei der jungfräulichen RM:
Ich habe im Log des Routers nur zwei Arten von IP-Anfragen gesehen:
1. NTP-Server, jeder(!?!?!) NTP-Server alle 30 Sekunden(!) (eingetragen waren die serienmäßigen NTP-Pools). Es wurde erst ruhiger, als ich einen einzigen dedizierten NTP-Server eingetragen habe, dennnoch alle 30 Sekunden eine Anfrage (finde ich deutlich zu viel/oft, 1x täglich reicht locker).
Meine life RM hat übrigens einen NTP im LAN eingetragen.
2. Alle paar Minuten ein ICMP zur IP 172.217.21.238 (Kalifornien). Warum, weiß der Henker :roll:
3. Selbst bei dem Anlernversuch über Internet habe ich im Router sonst keine einzige Verbindung oder Anfragen sehen können. Diese hatte ich jedoch erwartet, da ja der Zertifikatsserver der eq-3 angefragt werden sollte - so habe ich es zumindest verstanden.

Dies ist mir im Router-Log aufgefallen. Ich kann gerne einen pcap-Trace machen, wenn dies jemanden interessieren sollte.
Ich habe die Versuche mit dynamischer IP und statischen IP-Settings gemacht, Unterschiede waren nicht zu erkennen.


Fragen:
Gibt es aussagekräftige Logs?
Welche Logs in der RM könnten hier weiterhelfen?


Ich gehe davon aus, daß es zumindest in meinem Fall ursächlich an der RaspberryMatic liegt, da die Annmeldung an der CCU2 völlig problemlos funktioniert.
Antenne/Funkmodul habe ich durch den Tauch des Funkmoduls ausgeschlossen, ebenso Konfigurationsfehler meinerseits durch ein jungfräuliches Image.
Oder benötigt hmIP irgendwelche Vorbereitungen?
Daß die Systemuhr richtig gehen muß, kann ich mir wegen der Zertifikate gut vorstellen. Ist noch mehr erforderlich?


Sollte jemand Interesse, Lust und Zeit haben: Ich kann gerne jemanden per Remote auf die RM schauen lassen. Vielleicht gibt es ja Verbesserungspotential.... :)


Vielen Dank fürs Lesen,
ein ratloser Carsten
Zuletzt geändert von Schattenschimmer am 18.11.2018, 20:52, insgesamt 1-mal geändert.
NAT ist heutzutage keine sicherere Technik, um Netzwerkgeräte aus dem www erreichbar zu machen!

shartelt
Beiträge: 1678
Registriert: 14.01.2015, 14:59

Re: Anlernen von Homematic IP-Geräten an RaspberryMatic

Beitrag von shartelt » 18.11.2018, 20:46

BSL, 3 verschiedene Bausätze, erfolgreich an der neuesten RaspberryMatic angelernt...

nur so zur info...dass es eben auch geht .)

Schattenschimmer
Beiträge: 117
Registriert: 20.03.2016, 20:49

Re: Anlernen von Homematic IP-Geräten an RaspberryMatic

Beitrag von Schattenschimmer » 18.11.2018, 20:55

Ich glaube gerne, daß es i.d.R. funktioniert. Sonst gäbe es deutlich mehr Meldungen in dieser Richtung. :)

Aber dennoch: Mir gehen echt die Ideen aus.
Einen Defekt am BSL schließe ich aus, da dieser an der CCU2 so schön funktioniert.

Oder habe ich irgendwo einen Denkfehler?
Ich lasse mich gerne korrigieren.... ;)
NAT ist heutzutage keine sicherere Technik, um Netzwerkgeräte aus dem www erreichbar zu machen!

hoedlmoser
Beiträge: 95
Registriert: 19.01.2015, 07:42

Re: Anlernen von Homematic IP-Geräten an RaspberryMatic

Beitrag von hoedlmoser » 18.11.2018, 23:22

Schattenschimmer hat geschrieben:
18.11.2018, 20:41
1. NTP-Server, jeder(!?!?!) NTP-Server alle 30 Sekunden(!)
das könnte man über den parameter minpoll in /etc/ntp.conf aussteuern, erhöht sich aber eh auf 1024 sekunden (parameter maxpoll). aktuellen poll wert kannst Du mit ntpq -p prüfen.

btw, ntp synct nicht hart, sondern berechnet den drift der uhr gegenüber der ntp server und stellt dann kontinuierlich nach.
Schattenschimmer hat geschrieben:
18.11.2018, 20:41
2. Alle paar Minuten ein ICMP zur IP 172.217.21.238 (Kalifornien). Warum, weiß der Henker :roll:
das sieht aber eher nach Google in Frankfurt aus. damit prüft die CCU ob sie verbindung ins internet hat. wenn nicht blinkt die led schnell blau.
Schattenschimmer hat geschrieben:
18.11.2018, 20:41
Gibt es aussagekräftige Logs?
Welche Logs in der RM könnten hier weiterhelfen?
die vom hmserver in /var/log vielleicht.
RaspberryMatic 3.41.11.20181126 on Charly with Pi 3B+ binded by openHAB 2.4.0 M7
Wahrheit kann erst wirken, wenn der Empfänger für sie reif ist. Nicht an der Wahrheit liegt es daher, wenn die Menschen noch so voller Unweisheit sind. Alle Geheimnisse liegen in vollkommener Offenheit vor uns. Nur wir stufen uns gegen sie ab, vom Stein bis zum Seher. Es gibt keine Geheimnisse an sich, es gibt nur Uneingeweihte aller Grade. (Christian Morgenstern)

Schattenschimmer
Beiträge: 117
Registriert: 20.03.2016, 20:49

Re: Anlernen von Homematic IP-Geräten an RaspberryMatic

Beitrag von Schattenschimmer » 23.11.2018, 20:18

Vielen Dank für die Hinweise! :)

ntpq -p ist praktisch, den kannte ich noch nicht.
Das ntp kein echter Sync ist, das ist mir klar. ^^

Ich habe mehrere IP locator mit 172.217.21.238 gefüttert, alle zeigen in die USA...die meisten nach Kalifornien.
Wie kommst Du auf Frankfurt?


Das wichtigste: Die hmserver.log
Zum relevanten Zeitpunkt (während dem Anlernvorgang) gibt es gerade mal drei Einträge in diesem Log:
Nov 23 20:00:19 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-6] SYSTEM: 0 Accesspoints in Queue
Nov 23 20:00:19 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-6] SYSTEM: Permanent-/Burstlistener Handler utilization: 0/50 used
Nov 23 20:00:19 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-6] SYSTEM: Eventlistener Handler utilization: 0/50 used
Der vorherige Eintrag ist 5 Minuten älter.
Ich kann in diesen drei Einträgen nichts erkennen....

Die anderen log-Dateien in /var/log/ sind mind. 5 Minuten älter, nur in der lighttp-access.log gibt es ständig neue Einträge.

Gibt es noch weitere Log-Dateien oder Daten, die Aufschluß geben könnten?


Übrigens:
Ich hatte den BSL vorhin mehrfach "halb" angemeldet. "halb" heißt, daß der Aktor Daten zum Raspi sendet, aber keine Daten empfängt.
Nach dem ersten Einschalten des BSL seit einigen Tagen war der BSL ohne weiteres zutun spontan "halb" angemeldet. :roll:


Bess demnähx,
Carsten
NAT ist heutzutage keine sicherere Technik, um Netzwerkgeräte aus dem www erreichbar zu machen!

hoedlmoser
Beiträge: 95
Registriert: 19.01.2015, 07:42

Re: Anlernen von Homematic IP-Geräten an RaspberryMatic

Beitrag von hoedlmoser » 24.11.2018, 12:27

Schattenschimmer hat geschrieben:
23.11.2018, 20:18
Ich habe mehrere IP locator mit 172.217.21.238 gefüttert, alle zeigen in die USA...die meisten nach Kalifornien.
Wie kommst Du auf Frankfurt?
sagt mein traceroute, der biegt beim DE-CIX gleich ab, und der hostname. für irgendwas in den USA würde ich mir einen ping > 100 ms erwarten.

Code: Alles auswählen

klaus@quad:~$ traceroute 172.217.21.238
traceroute to 172.217.21.238 (172.217.21.238), 30 hops max, 60 byte packets
 1  fwsense.dbg.kmp.or.at (10.21.11.1)  0.407 ms  0.374 ms  0.335 ms
 2  10.192.0.1 (10.192.0.1)  6.987 ms  6.941 ms  6.949 ms
 3  te43-c76-stp-01.net.kabelplus.at (195.202.135.9)  6.944 ms  6.925 ms  6.917 ms
 4  be210-asr9k-mae-ktz-01.net.kabelplu.at (195.202.135.145)  8.757 ms  8.633 ms  8.629 ms
 5  te0103-asr9k-upst-inx-01.net.kabelplus.at (195.202.134.233)  9.804 ms  12.790 ms  9.762 ms
 6  de-cix.fra.google.com (80.81.192.108)  21.898 ms  26.171 ms  26.136 ms
 7  108.170.252.65 (108.170.252.65)  32.857 ms  26.013 ms  25.858 ms
 8  108.170.235.251 (108.170.235.251)  24.879 ms  25.286 ms  25.223 ms
 9  fra16s13-in-f14.1e100.net (172.217.21.238)  24.759 ms  24.143 ms  24.579 ms
Schattenschimmer hat geschrieben:
23.11.2018, 20:18
Gibt es noch weitere Log-Dateien oder Daten, die Aufschluß geben könnten?
Du hast in Startseite > Einstellungen > Systemsteuerung > Zentralen-Wartung bei Fehlerprotokoll schon auf "Alles loggen" umgestellt? und zusätzlich könntest Du den hmserver noch gesprächiger machen, in dem Du in /usr/local/etc/config/log4j.xml in der category de.eq3 die priority auf TRACE stellst.

Code: Alles auswählen

	<category name="de.eq3">
		<priority value="TRACE" />
	</category>
danach nicht vergessen einmal zu rebooten.
RaspberryMatic 3.41.11.20181126 on Charly with Pi 3B+ binded by openHAB 2.4.0 M7
Wahrheit kann erst wirken, wenn der Empfänger für sie reif ist. Nicht an der Wahrheit liegt es daher, wenn die Menschen noch so voller Unweisheit sind. Alle Geheimnisse liegen in vollkommener Offenheit vor uns. Nur wir stufen uns gegen sie ab, vom Stein bis zum Seher. Es gibt keine Geheimnisse an sich, es gibt nur Uneingeweihte aller Grade. (Christian Morgenstern)

Schattenschimmer
Beiträge: 117
Registriert: 20.03.2016, 20:49

Re: Anlernen von Homematic IP-Geräten an RaspberryMatic

Beitrag von Schattenschimmer » 24.11.2018, 17:48

Die Sache mit der Location der IP wirft echt Fragen auf, ich kann Deiner Argumentation folgen.
Aber das würde hier wohl zu weit führen.....

Vielen Dank für den Tip, wie der hmserver gesprächiger wird.
Ich habe nun ein Log, in dem deutlich mehr drin steht. :)
Dieses Log habe ich von ~14000 Zeilen auf 130 Zeilen zusammengedampft. Dabei habe ich nur oberhalb und unterhalb von diesen 130 Zeilen gelöscht, nicht innerhalb. Die erkennbare Anmeldeprozedur des BSL wiederholt sich öfter, denklich sollte hier eine Anmeldeprozedur für die Analyse reichen.
Bei Interesse kann ich das komplette Log zumailen.

Zum Log:
Meines erachtens ist das Device 3014F711A0001A58A9A27FA7 das Korpus Delicti.
Für auffällig halte ich die timeout Meldungen ab Zeile 68: HMIP Stack response TIMEOUT

Liegt hier die Ursache vergraben?
Ich habe durch das Verhalten des BSL, wenn dieser mal angemeldet ist, den Eindruck, also ob die Kommunikation nicht bidirektional, sondern unidirektional (BSL --> hmserver) ist.

Leider fehlt mir das Hintergrundwissen, um dieses Puzzle zu einem Stück zusammenzutragen zu können.
Vielleicht kann mir jemand dabei helfen. :)
Sollten Informationen fehlen oder Fragen auftauchen, dann raus damit. Selbst einen Remotezugang (z.B. Teamviewer) für die geneigte, hilfsbereite Person schließe ich nicht aus.

Code: Alles auswählen

Nov 24 17:24:34 de.eq3.ccu.server.internal.RpcMessageHandler DEBUG [vert.x-eventloop-thread-3] rpc.api.bidcos Send Response for : system.multicall 
Nov 24 17:24:34 de.eq3.ccu.server.internal.BasicAPIHttpResponseHandler DEBUG [vert.x-eventloop-thread-1] io.vertx.ext.web.impl.HttpServerRequestWrapper@1b1212b 
Nov 24 17:24:44 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem TRACE [vert.x-eventloop-thread-6] SYSTEM: OTAU Watchdog is running a check 
Nov 24 17:24:44 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem DEBUG [vert.x-eventloop-thread-6] SYSTEM: No suitable AP found - cannot start any update handlers 
Nov 24 17:24:47 de.eq3.ccu.server.internal.BasicAPIHttpVertxHandler DEBUG [vert.x-eventloop-thread-1] io.vertx.ext.web.impl.HttpServerRequestWrapper@184bc0e 
Nov 24 17:24:47 de.eq3.ccu.server.internal.RpcMessageHandler DEBUG [vert.x-eventloop-thread-5] rpc.api.group Incoming Request: system.listMethods 
Nov 24 17:24:47 de.eq3.ccu.virtualdevice.service.internal.rega.VirtualDeviceHandlerRega DEBUG [vert.x-eventloop-thread-5] system.listMethods 
Nov 24 17:24:47 de.eq3.ccu.server.internal.RpcMessageHandler DEBUG [vert.x-eventloop-thread-5] rpc.api.group Send Response for : system.listMethods 
Nov 24 17:24:47 de.eq3.ccu.server.internal.BasicAPIHttpResponseHandler DEBUG [vert.x-eventloop-thread-1] io.vertx.ext.web.impl.HttpServerRequestWrapper@184bc0e 
Nov 24 17:24:56 de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler TRACE [vert.x-worker-thread-3] RPCMethod: setInstallMode called null -> 60 
Nov 24 17:24:56 de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler TRACE [vert.x-worker-thread-0] RPCMethod: getInstallMode called 
Nov 24 17:24:57 de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler TRACE [vert.x-worker-thread-1] RPCMethod: getInstallMode called 
Nov 24 17:24:57 de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler TRACE [vert.x-worker-thread-4] RPCMethod: getInstallMode called 
Nov 24 17:24:58 de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler TRACE [vert.x-worker-thread-2] RPCMethod: getInstallMode called 
Nov 24 17:24:58 de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler TRACE [vert.x-worker-thread-3] RPCMethod: getInstallMode called 
Nov 24 17:24:59 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem TRACE [vert.x-eventloop-thread-6] SYSTEM: OTAU Watchdog is running a check 
Nov 24 17:24:59 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem DEBUG [vert.x-eventloop-thread-6] SYSTEM: No suitable AP found - cannot start any update handlers 
Nov 24 17:24:59 de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler TRACE [vert.x-worker-thread-0] RPCMethod: getInstallMode called 
Nov 24 17:24:59 de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler TRACE [vert.x-worker-thread-1] RPCMethod: getInstallMode called 
Nov 24 17:25:00 de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler TRACE [vert.x-worker-thread-4] RPCMethod: getInstallMode called 
Nov 24 17:25:00 de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler TRACE [vert.x-worker-thread-2] RPCMethod: getInstallMode called 
Nov 24 17:25:01 de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler TRACE [vert.x-worker-thread-3] RPCMethod: getInstallMode called 
Nov 24 17:25:01 de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler TRACE [vert.x-worker-thread-0] RPCMethod: getInstallMode called 
Nov 24 17:25:02 de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler TRACE [vert.x-worker-thread-1] RPCMethod: getInstallMode called 
Nov 24 17:25:02 de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler TRACE [vert.x-worker-thread-4] RPCMethod: getInstallMode called 
Nov 24 17:25:03 de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler TRACE [vert.x-worker-thread-2] RPCMethod: getInstallMode called 
Nov 24 17:25:03 de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler TRACE [vert.x-worker-thread-3] RPCMethod: getInstallMode called 
Nov 24 17:25:03 de.eq3.cbcs.lib.hmiptrxcommadapter.internal.HMIPStack TRACE [Thread-6] IP Frame received: 01 00 8f 10 0c cb f0 00 03 10 30 14 f7 11 a0 00 1a 58 a9 a2 7f a7 00 01 00 00 01 68 01 00 02 00 03 b6 55 ba e8 7d e3 70 50 61 6f 16 79 7a d0 b1 f4  
Nov 24 17:25:03 de.eq3.cbcs.server.core.internal.HMIPTRXListener TRACE [Thread-6] HM /IP Frame received Frametype: HMIP_NM_DEVICE_INCLUSION_REQUEST 
Nov 24 17:25:03 de.eq3.cbcs.server.core.vertx.IncomingHMIPFrameHandler TRACE [vert.x-eventloop-thread-4] AP 3014F711A0001F58A992FBC0: HM /IP Frame received Frametype: HMIP_NM_DEVICE_INCLUSION_REQUEST 
Nov 24 17:25:03 de.eq3.cbcs.server.core.framehandling.HMIPNetworkManagementHandler TRACE [vert.x-eventloop-thread-4] AP 3014F711A0001F58A992FBC0: Inclusion Request device with SGTIN: 3014F711A0001A58A9A27FA7; accept Master Key: true; accept Local Key: true 
Nov 24 17:25:03 de.eq3.cbcs.server.core.framehandling.HMIPNetworkManagementHandler DEBUG [vert.x-eventloop-thread-4] AP 3014F711A0001F58A992FBC0: Accept re inclusion 3014F711A0001A58A9A27FA7, no matter which inclusion mode is active 
Nov 24 17:25:03 de.eq3.cbcs.server.core.framehandling.HMIPNetworkManagementHandler TRACE [vert.x-eventloop-thread-4] AP 3014F711A0001F58A992FBC0: Device 3014F711A0001A58A9A27FA7 Device description found. Type is DeviceType [label=HmIP-BSL, id=360, manufacturerCode=1, updatable=true, minVersion=0, maxVersion=0] 
Nov 24 17:25:03 de.eq3.cbcs.server.core.framehandling.HMIPNetworkManagementHandler TRACE [vert.x-eventloop-thread-4] AP 3014F711A0001F58A992FBC0: Device 3014F711A0001A58A9A27FA7 Received inclusion request for device already known. 
Nov 24 17:25:03 de.eq3.cbcs.server.core.framehandling.HMIPNetworkManagementHandler TRACE [vert.x-eventloop-thread-4] AP 3014F711A0001F58A992FBC0: Device 3014F711A0001A58A9A27FA7, Received inclusion request from known device was resetted and has a differnet radio address 
Nov 24 17:25:03 de.eq3.cbcs.server.core.vertx.HMIPAbstractWriterWorker TRACE [vert.x-worker-thread-0] handle: message: {"accesspoint.id":"3014F711A0001F58A992FBC0"} 
Nov 24 17:25:03 de.eq3.cbcs.devicemanagement.TransactionManager TRACE [vert.x-worker-thread-0] Start next transaction id: 541 with priority: PERMANENT_LISTENER 
Nov 24 17:25:03 de.eq3.cbcs.server.core.framehandling.HMIPNetworkManagementHandler DEBUG [vert.x-eventloop-thread-4] AP 3014F711A0001F58A992FBC0: Inclusion 3014F711A0001A58A9A27FA7: Step 1 Request handled 100CCB (100CCB) 
Nov 24 17:25:03 de.eq3.cbcs.server.core.vertx.HMIPAbstractWriterWorker TRACE [vert.x-worker-thread-0] AP 3014F711A0001F58A992FBC0: transaktionID: 541; executing task: de.eq3.cbcs.hmipcommand.GetInclusionDataCommand@1c6dce0 
Nov 24 17:25:03 de.eq3.cbcs.server.core.persistence.AbstractPersistency TRACE [vert.x-worker-thread-1] DEV 3014F711A0001A58A9A27FA7: Receive persistence command: PERSISTENCE_COMMAND_ADD_DEVICE 
Nov 24 17:25:03 de.eq3.cbcs.lib.hmiptrxcommadapter.internal.HMIPStack TRACE [Thread-6] AP 3014F711A0001F58A992FBC0: HMIP Stack response 1 
Nov 24 17:25:03 de.eq3.cbcs.server.core.internal.HMIPAdapterResponseListener TRACE [Thread-6] Receive adapter response for transacation: 541 type: ACK 
Nov 24 17:25:03 de.eq3.cbcs.server.core.internal.HMIPAdapterResponseListener DEBUG [Thread-6] AP 3014F711A0001F58A992FBC0: Inclusion 3014F711A0001A58A9A27FA7: Step 2 response from get inclusion data 100CCB (100CCB) -> Router null 
Nov 24 17:25:03 de.eq3.cbcs.server.core.vertx.KeyServerWorker DEBUG [vert.x-worker-thread-4] AP 3014F711A0001F58A992FBC0: Inclusion 3014F711A0001A58A9A27FA7: Step 3.0 KeyServerWorker Router null 
Nov 24 17:25:04 de.eq3.cbcs.legacy.bidcos.rpc.internal.LegacyNotificationHandler TRACE [vert.x-worker-thread-2] RESPONSE_ACK : {"caller.id":"event","request.id":-1,"notification.type":0,"accesspoint.id":"3014F711A0001F58A992FBC0"} 
Nov 24 17:25:04 de.eq3.cbcs.server.core.vertx.HMIPAbstractWriterWorker TRACE [vert.x-worker-thread-3] handle: message: {"accesspoint.id":"3014F711A0001F58A992FBC0"} 
Nov 24 17:25:04 de.eq3.cbcs.devicemanagement.TransactionManager TRACE [vert.x-worker-thread-3] There is no transaction, that should be done 
Nov 24 17:25:04 de.eq3.cbcs.server.core.vertx.keyserver.KeyServerOperation DEBUG [vert.x-worker-thread-4] AP 3014F711A0001F58A992FBC0: send data to Frontend Server (jdID 3014F711A0001A58A9A27FA7) at secgtw.homematic.com:8443 
Nov 24 17:25:04 de.eq3.cbcs.server.core.vertx.HMIPAbstractWriterWorker TRACE [vert.x-worker-thread-3] AP 3014F711A0001F58A992FBC0: no current Transaction; currentTransactionID: 541; currentTransaction: null; nextTask: null; hmipAdapter: de.eq3.cbcs.server.local.base.internal.ShareableHomeMaticIPTRXCommAdapter@3ef1b1 
Nov 24 17:25:04 de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler TRACE [vert.x-worker-thread-0] RPCMethod: getInstallMode called 
Nov 24 17:25:04 de.eq3.cbcs.server.core.vertx.keyserver.KeyServerOperation DEBUG [vert.x-worker-thread-4] AP 3014F711A0001F58A992FBC0: received response from Frontend Server (jdID 3014F711A0001A58A9A27FA7) 
Nov 24 17:25:04 de.eq3.cbcs.server.core.vertx.KeyServerWorker DEBUG [vert.x-worker-thread-4] AP 3014F711A0001F58A992FBC0: Inclusion 3014F711A0001A58A9A27FA7: Step 3.1 KeyServerWorker response Router null 
Nov 24 17:25:04 de.eq3.cbcs.server.core.vertx.DeviceInclusionAcceptHandler TRACE [vert.x-eventloop-thread-0] Accepting device inclusion request 
Nov 24 17:25:04 de.eq3.cbcs.server.core.vertx.DeviceInclusionAcceptHandler DEBUG [vert.x-eventloop-thread-0] AP 3014F711A0001F58A992FBC0: Inclusion 3014F711A0001A58A9A27FA7: Step 4.0.1 Accept device, Router null 
Nov 24 17:25:04 de.eq3.cbcs.server.core.vertx.DeviceInclusionAcceptHandler DEBUG [vert.x-eventloop-thread-0] AP 3014F711A0001F58A992FBC0: Inclusion 3014F711A0001A58A9A27FA7: Step 4.0.2.1 Accept device transaction started 
Nov 24 17:25:04 de.eq3.cbcs.server.core.vertx.HMIPAbstractWriterWorker TRACE [vert.x-worker-thread-3] handle: message: {"accesspoint.id":"3014F711A0001F58A992FBC0"} 
Nov 24 17:25:04 de.eq3.cbcs.devicemanagement.TransactionManager TRACE [vert.x-worker-thread-3] Start next transaction id: 542 with priority: PERMANENT_LISTENER 
Nov 24 17:25:04 de.eq3.cbcs.server.core.vertx.HMIPAbstractWriterWorker TRACE [vert.x-worker-thread-3] AP 3014F711A0001F58A992FBC0: transaktionID: 542; executing task: de.eq3.cbcs.hmipcommand.AddLinkPartnerCommand@17215c7 
Nov 24 17:25:04 de.eq3.cbcs.server.core.internal.HMIPTRXWriterWorker DEBUG [vert.x-worker-thread-3] AP 3014F711A0001F58A992FBC0: Inclusion 3014F711A0001A58A9A27FA7: Step 4.1 Add Link Partner 8FEEDA (Router 000000) 
Nov 24 17:25:04 de.eq3.cbcs.lib.hmiptrxcommadapter.internal.HMIPStack TRACE [Thread-6] AP 3014F711A0001F58A992FBC0: HMIP Stack response 1 
Nov 24 17:25:04 de.eq3.cbcs.server.core.internal.HMIPAdapterResponseListener TRACE [Thread-6] Receive adapter response for transacation: 542 type: ACK 
Nov 24 17:25:04 de.eq3.cbcs.server.core.internal.HMIPAdapterResponseListener DEBUG [Thread-6] AP 3014F711A0001F58A992FBC0: Inclusion 3014F711A0001A58A9A27FA7: Step 4.2 Add Link Partner Response 
Nov 24 17:25:04 de.eq3.cbcs.server.core.vertx.HMIPAbstractWriterWorker TRACE [vert.x-worker-thread-1] handle: message: {"accesspoint.id":"3014F711A0001F58A992FBC0"} 
Nov 24 17:25:04 de.eq3.cbcs.server.core.vertx.HMIPAbstractWriterWorker TRACE [vert.x-worker-thread-1] AP 3014F711A0001F58A992FBC0: transaktionID: 542; executing task: SendFrameCommand [frame=DeviceInclusionAcceptFrame : NetworkManagementHeader [frameType= DEVICE_INCLUSION_ACCEPT, macSource=000000, macDestination=100CCB, ipSource=000000, ipDestination=100CCB], sendMode=PERMANENT_LISTENER] 
Nov 24 17:25:04 de.eq3.cbcs.server.core.vertx.HMIPAbstractWriterWorker DEBUG [vert.x-worker-thread-1] AP 3014F711A0001F58A992FBC0: Inclusion 3014F711A0001A58A9A27FA7: Step 4.3 Send Inclusion Accept to 100CCB (100CCB) 
Nov 24 17:25:04 de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler TRACE [vert.x-worker-thread-0] RPCMethod: getInstallMode called 
Nov 24 17:25:04 de.eq3.cbcs.lib.hmiptrxcommadapter.internal.HMIPStack TRACE [Thread-6] AP 3014F711A0001F58A992FBC0: HMIP Stack response 3 
Nov 24 17:25:04 de.eq3.cbcs.lib.hmiptrxcommadapter.internal.HMIPStack DEBUG [Thread-6] AP 3014F711A0001F58A992FBC0: HMIP Stack response TIMEOUT 
Nov 24 17:25:04 de.eq3.cbcs.server.core.internal.HMIPAdapterResponseListener TRACE [Thread-6] Receive adapter response for transacation: 542 type: TIMEOUT 
Nov 24 17:25:04 de.eq3.cbcs.server.core.internal.HMIPAdapterResponseListener TRACE [Thread-6] AP 3014F711A0001F58A992FBC0: aborted transaction TIMEOUT - null 
Nov 24 17:25:04 de.eq3.cbcs.server.core.internal.HMIPAdapterResponseListener DEBUG [Thread-6] AP 3014F711A0001F58A992FBC0: Stack Timeout received 
Nov 24 17:25:04 de.eq3.cbcs.server.core.vertx.HMIPAbstractWriterWorker TRACE [vert.x-worker-thread-4] handle: message: {"accesspoint.id":"3014F711A0001F58A992FBC0"} 
Nov 24 17:25:04 de.eq3.cbcs.legacy.bidcos.rpc.internal.LegacyNotificationHandler TRACE [vert.x-worker-thread-2] RECEIVED_STATUS_DATA : {"caller.id":"event","request.id":-1,"notification.type":42,"accesspoint.id":"3014F711A0001F58A992FBC0","device.id":"3014F711A0001A58A9A27FA7","device.channel":0,"device.parameters.values":{"UNREACH":true}} 
Nov 24 17:25:04 de.eq3.cbcs.devicemanagement.TransactionManager TRACE [vert.x-worker-thread-4] Start next transaction id: 543 with priority: PERMANENT_LISTENER 
Nov 24 17:25:04 de.eq3.cbcs.legacy.bidcos.rpc.internal.LegacyNotificationHandler TRACE [vert.x-worker-thread-2] TIMEOUT : {"caller.id":"event","request.id":-1,"notification.type":2,"accesspoint.id":"3014F711A0001F58A992FBC0","device.id":"3014F711A0001A58A9A27FA7"} 
Nov 24 17:25:04 de.eq3.cbcs.server.core.vertx.HMIPAbstractWriterWorker TRACE [vert.x-worker-thread-4] AP 3014F711A0001F58A992FBC0: transaktionID: 543; executing task: SendFrameCommand [frame=RouteResponseFrame : RouteManagementHeader [commandType= ROUTE_RESPONSE, macSource=000000, macDestination=F00002], sendMode=PERMANENT_LISTENER] 
Nov 24 17:25:04 de.eq3.cbcs.legacy.bidcos.rpc.internal.LegacyBackendNotificationHandler DEBUG [vert.x-worker-thread-3] send event(s) to interface: 9977 http URL: http://127.0.0.1:1999 
Nov 24 17:25:04 de.eq3.cbcs.legacy.bidcos.rpc.internal.LegacyBackendNotificationHandler DEBUG [vert.x-worker-thread-2] send event(s) to interface: HmIP-RF_java http URL: http://127.0.0.1:9292/bidcos 
Nov 24 17:25:04 de.eq3.cbcs.legacy.bidcos.rpc.internal.LegacyBackendClient TRACE [vert.x-worker-thread-3] Call 9977 with event 001A58A9A27FA7:0 UNREACH = true 
Nov 24 17:25:04 de.eq3.cbcs.legacy.bidcos.rpc.internal.LegacyBackendClient TRACE [vert.x-worker-thread-2] Call HmIP-RF_java with event 001A58A9A27FA7:0 UNREACH = true 
Nov 24 17:25:04 de.eq3.ccu.server.internal.BasicAPIHttpVertxHandler DEBUG [vert.x-eventloop-thread-1] io.vertx.ext.web.impl.HttpServerRequestWrapper@1d2a8de 
Nov 24 17:25:04 de.eq3.ccu.server.internal.RpcMessageHandler DEBUG [vert.x-eventloop-thread-3] rpc.api.bidcos Incoming Request: event 
Nov 24 17:25:04 de.eq3.ccu.bidcos.dispatcher.BidCosRpcDispatcher DEBUG [vert.x-eventloop-thread-3] event interface: HmIP-RF_java device 001A58A9A27FA7:0: key:UNREACH = true 
Nov 24 17:25:04 de.eq3.ccu.server.internal.RpcMessageHandler DEBUG [vert.x-eventloop-thread-3] rpc.api.bidcos Send Response for : event 
Nov 24 17:25:04 de.eq3.ccu.server.internal.BasicAPIHttpResponseHandler DEBUG [vert.x-eventloop-thread-1] io.vertx.ext.web.impl.HttpServerRequestWrapper@1d2a8de 
Nov 24 17:25:05 de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler TRACE [vert.x-worker-thread-0] RPCMethod: getInstallMode called 
Nov 24 17:25:05 de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler TRACE [vert.x-worker-thread-1] RPCMethod: getInstallMode called 
Nov 24 17:25:05 de.eq3.cbcs.lib.hmiptrxcommadapter.internal.HMIPStack TRACE [Thread-6] AP 3014F711A0001F58A992FBC0: HMIP Stack response 3 
Nov 24 17:25:05 de.eq3.cbcs.lib.hmiptrxcommadapter.internal.HMIPStack DEBUG [Thread-6] AP 3014F711A0001F58A992FBC0: HMIP Stack response TIMEOUT 
Nov 24 17:25:05 de.eq3.cbcs.server.core.internal.HMIPAdapterResponseListener TRACE [Thread-6] Receive adapter response for transacation: 543 type: TIMEOUT 
Nov 24 17:25:05 de.eq3.cbcs.server.core.internal.HMIPAdapterResponseListener TRACE [Thread-6] AP 3014F711A0001F58A992FBC0: aborted transaction TIMEOUT - null 
Nov 24 17:25:05 de.eq3.cbcs.server.core.internal.HMIPAdapterResponseListener DEBUG [Thread-6] AP 3014F711A0001F58A992FBC0: Stack Timeout received 
Nov 24 17:25:05 de.eq3.cbcs.server.core.vertx.HMIPAbstractWriterWorker TRACE [vert.x-worker-thread-3] handle: message: {"accesspoint.id":"3014F711A0001F58A992FBC0"} 
Nov 24 17:25:05 de.eq3.cbcs.legacy.bidcos.rpc.internal.LegacyNotificationHandler TRACE [vert.x-worker-thread-4] RECEIVED_STATUS_DATA : {"caller.id":"event","request.id":-1,"notification.type":42,"accesspoint.id":"3014F711A0001F58A992FBC0","device.id":"3014F711A0001A58A9A27FA7","device.channel":0,"device.parameters.values":{"UNREACH":true}} 
Nov 24 17:25:05 de.eq3.cbcs.devicemanagement.TransactionManager TRACE [vert.x-worker-thread-3] There is no transaction, that should be done 
Nov 24 17:25:05 de.eq3.cbcs.server.core.vertx.HMIPAbstractWriterWorker TRACE [vert.x-worker-thread-3] AP 3014F711A0001F58A992FBC0: no current Transaction; currentTransactionID: 543; currentTransaction: null; nextTask: null; hmipAdapter: de.eq3.cbcs.server.local.base.internal.ShareableHomeMaticIPTRXCommAdapter@3ef1b1 
Nov 24 17:25:05 de.eq3.cbcs.legacy.bidcos.rpc.internal.LegacyBackendNotificationHandler DEBUG [vert.x-worker-thread-2] send event(s) to interface: HmIP-RF_java http URL: http://127.0.0.1:9292/bidcos 
Nov 24 17:25:05 de.eq3.cbcs.legacy.bidcos.rpc.internal.LegacyNotificationHandler TRACE [vert.x-worker-thread-4] TIMEOUT : {"caller.id":"event","request.id":-1,"notification.type":2,"accesspoint.id":"3014F711A0001F58A992FBC0","device.id":"3014F711A0001A58A9A27FA7"} 
Nov 24 17:25:05 de.eq3.cbcs.legacy.bidcos.rpc.internal.LegacyBackendNotificationHandler DEBUG [vert.x-worker-thread-3] send event(s) to interface: 9977 http URL: http://127.0.0.1:1999 
Nov 24 17:25:05 de.eq3.cbcs.legacy.bidcos.rpc.internal.LegacyBackendClient TRACE [vert.x-worker-thread-2] Call HmIP-RF_java with event 001A58A9A27FA7:0 UNREACH = true 
Nov 24 17:25:05 de.eq3.cbcs.legacy.bidcos.rpc.internal.LegacyBackendClient TRACE [vert.x-worker-thread-3] Call 9977 with event 001A58A9A27FA7:0 UNREACH = true 
Nov 24 17:25:05 de.eq3.ccu.server.internal.BasicAPIHttpVertxHandler DEBUG [vert.x-eventloop-thread-1] io.vertx.ext.web.impl.HttpServerRequestWrapper@168ba80 
Nov 24 17:25:05 de.eq3.ccu.server.internal.RpcMessageHandler DEBUG [vert.x-eventloop-thread-3] rpc.api.bidcos Incoming Request: event 
Nov 24 17:25:05 de.eq3.ccu.bidcos.dispatcher.BidCosRpcDispatcher DEBUG [vert.x-eventloop-thread-3] event interface: HmIP-RF_java device 001A58A9A27FA7:0: key:UNREACH = true 
Nov 24 17:25:05 de.eq3.ccu.server.internal.RpcMessageHandler DEBUG [vert.x-eventloop-thread-3] rpc.api.bidcos Send Response for : event 
Nov 24 17:25:05 de.eq3.ccu.server.internal.BasicAPIHttpResponseHandler DEBUG [vert.x-eventloop-thread-1] io.vertx.ext.web.impl.HttpServerRequestWrapper@168ba80 
Nov 24 17:25:06 de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler TRACE [vert.x-worker-thread-1] RPCMethod: getInstallMode called 
Nov 24 17:25:06 de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler TRACE [vert.x-worker-thread-0] RPCMethod: getInstallMode called 
Nov 24 17:25:06 de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler TRACE [vert.x-worker-thread-4] RPCMethod: getInstallMode called 
Nov 24 17:25:07 de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler TRACE [vert.x-worker-thread-3] RPCMethod: getInstallMode called 
Nov 24 17:25:07 de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler TRACE [vert.x-worker-thread-2] RPCMethod: getInstallMode called 
Nov 24 17:25:08 de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler TRACE [vert.x-worker-thread-1] RPCMethod: getInstallMode called 
Nov 24 17:25:08 de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler TRACE [vert.x-worker-thread-0] RPCMethod: getInstallMode called 
Nov 24 17:25:09 de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler TRACE [vert.x-worker-thread-4] RPCMethod: getInstallMode called 
Nov 24 17:25:09 de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler TRACE [vert.x-worker-thread-3] RPCMethod: getInstallMode called 
Nov 24 17:25:10 de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler TRACE [vert.x-worker-thread-2] RPCMethod: getInstallMode called 
Nov 24 17:25:10 de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler TRACE [vert.x-worker-thread-1] RPCMethod: getInstallMode called 
Nov 24 17:25:11 de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler TRACE [vert.x-worker-thread-0] RPCMethod: getInstallMode called 
Nov 24 17:25:11 de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler TRACE [vert.x-worker-thread-4] RPCMethod: getInstallMode called 
Nov 24 17:25:12 de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler TRACE [vert.x-worker-thread-3] RPCMethod: getInstallMode called 
Nov 24 17:25:12 de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler TRACE [vert.x-worker-thread-2] RPCMethod: getInstallMode called 
Nov 24 17:25:13 de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler TRACE [vert.x-worker-thread-1] RPCMethod: getInstallMode called 
Nov 24 17:25:13 de.eq3.ccu.server.internal.BasicAPIHttpVertxHandler DEBUG [vert.x-eventloop-thread-1] io.vertx.ext.web.impl.HttpServerRequestWrapper@cee466 
Nov 24 17:25:13 de.eq3.ccu.server.internal.RpcMessageHandler DEBUG [vert.x-eventloop-thread-3] rpc.api.bidcos Incoming Request: system.multicall 
Nov 24 17:25:13 de.eq3.ccu.bidcos.dispatcher.BidCosRpcDispatcher DEBUG [vert.x-eventloop-thread-3] event interface: BidCos-RF_java device OEQ1668924:2: key:ACTUAL_TEMPERATURE = 21.3 
Nov 24 17:25:13 de.eq3.ccu.bidcos.dispatcher.BidCosRpcDispatcher DEBUG [vert.x-eventloop-thread-3] event interface: BidCos-RF_java device OEQ1668924:2: key:ACTUAL_HUMIDITY = 48.0 
Nov 24 17:25:13 de.eq3.ccu.bidcos.dispatcher.BidCosRpcDispatcher DEBUG [vert.x-eventloop-thread-3] event interface: BidCos-RF_java device OEQ1668924:2: key:SET_TEMPERATURE = 21.0 
Nov 24 17:25:13 de.eq3.ccu.server.internal.RpcMessageHandler DEBUG [vert.x-eventloop-thread-3] rpc.api.bidcos Send Response for : system.multicall 
Nov 24 17:25:13 de.eq3.ccu.server.internal.BasicAPIHttpResponseHandler DEBUG [vert.x-eventloop-thread-1] io.vertx.ext.web.impl.HttpServerRequestWrapper@cee466 
Nov 24 17:25:13 de.eq3.cbcs.legacy.bidcos.rpc.LegacyServiceHandler TRACE [vert.x-worker-thread-0] RPCMethod: getInstallMode called 
NAT ist heutzutage keine sicherere Technik, um Netzwerkgeräte aus dem www erreichbar zu machen!

Antworten

Zurück zu „RaspberryMatic“