HomeMatic IP liefert keine Daten

Hi - ich habe bis auf eine Komponente nur IP Komponenten.

Für die „erweiterte“ Sommer-/Winterumschaltung habe ich den HM-LC-SW1 - das Teil hat noch nie Probleme gemacht. :wink:

Meine HMIP-eTRV haben bisher noch keine Probleme gezeigt, die SWSD manchmal. Dafür meine beiden HMIP-FSM(16) und die -SWDO und -PS umso mehr.

Ist irgendwie zum Auswachsen …

Gibt es irgendwelche Timeouts die man höher stellen könnte?

Grüße

RUE

Nö gibt es nicht, wozu auch.
Das ist eine stehende TCP Verbindung zum schalten der Geräte von IPS zur CCU.
Und zum empfangen der Events von der CCU ist IPS ‚nur‘ Server und wartet auf eingehende Verbindungen von der CCU auf dem Port des Ereignisservers.
Hast du im Log der CCU mal geschaut (xmlrpc Fehler o.ä.) ?
Paresys Vorschlag mit dem prüfen des Ereignisservers ausprobiert?
Michael

Hab ich … keine Probleme, CCU2 meldet sich sofort.

Ich kann auch keine Fehler im Log der CCU2 erkennen - das ist ja zum Mäusemelken!

Grüße

RUE

Äh, wieso CCU.
Das mit deine-ip ist IPS!

Michael

Danke für die Korrektur, hab mich von der Meldung irritieren lassen.
.Grüsse

RUE

Moin Moin!

Ich habe was zum Thema „Socket“ getrennt gefunden.

Offensichtlich wir der Socket immer dann beendet, wenn IP-Symcon meinen HMIP-FSM16 steuert oder sich die Handy-App verbindet.

Update der CCU2 und der Firmware im FSM habe ich eingespielt.

Mein Steuercommando an den Switch geht per „Wochenplan“ raus, Kommando: „HM_WriteValueBoolean(39517, „STATE“, true);“, welches direkt aus dem Wochenplan an den Kontakt gesendet wird.

Mach ich da was falsch, oder gibt es einen besseren Weg?

Bin für jeden Tip dankbar.

RUE

Ich habe übrigens nochmals geprüft, ob die CCU2 die Events nichts schickt.

Wireshark zeigt mir allerdings ganz sauber eine Kommunikation zwischen CCU2 und IP-Symcon - und zwar in beide Richtungen.

Trotzdem erfolgt kein Update der Datenbasis - irgendwelche Ideen?

Vor dem letzten Update hatte ich hier keine Probleme - was kann schiefgegangen sein?

Grüße

RUE

Hi RUE, hast du mit Wireshark auch auf Port 5544 geschaut? Das ist nämlich der Rückkanal. Der normale „hin“-Weg geht über Port 2001 bei Funk.

paresy

Ja, habe ich - ich kann die Info in den Daten zwar nicht lesen (wen wundert’s) :slight_smile:

Aber man sieht eindeutig, wie die CCU2 Daten auf dem Port schickt (ein Paket) und darauf auch eine Antwort erhält.

Grüße

RUE

Das solltest Du lesen können. Ist simples XML. Alles in Klartext und nicht verschlüsselt.
Michael

Dann ist das vielleicht der Ansatzpunkt

Danke

RUE

Moin Moin - hast Recht, hatte nicht lange genug mitgeschnitten.

Das macht es aber nicht einfacher … anbei schicke ich euch mal den Trace, der von der CCU2 an den Symcan Server geht. So auf den ersten Blick fällt mir nichts auf … aber ihr seid ja da die Spezialisten :slight_smile:

Den Trace habe ich am Win7 Symcon-Server direkt auf der virtuellen Netzwerkkarte gezogen.

Danke für eure Hilfe und Grüße

RUEtrace.zip (47.1 KB)

irgendwelche Ideen?

Kann ich irgendwo 4.2 downloaden und ein „sauberes“ downgrade fahren?
Nur zum Test …

Grüße

RUE

Das Trace sagt, dass die CCU nur ein Event als Antwort von IPS liefert (Ping Pong).
Sonst kommen gar keine Events von der CCU.
Downgrade geht am einfachsten über ein Backup, da häufig die Settings sich beim Update ändert und offiziell nicht unterstützt ist.
Michael

Hallo Michael,

gibt es irgendwo ein Dokument, was mich da weiterbringt?

Wie ist denn die Kommunikation spezifiziert, wann muss was kommen.

Möglicherweise liegt es ja tatsächlich an der neuen Firmware der CCU - aber auch das müsste ich ja nachweisen.
Aktuell ist da sowieso einiges schief gelaufen - mit der jetzigen Firmware sind die SWDOs z.B. „geschlossen“, wenn sie „offen“ sind. Heisst: stellt man in der WEB-UI die SWDO „Meldung bei offen“ auf „offen“, meldet der SWDO „geschlossen“ und z.B. alle Ventile fahren auf. Mann muss derzeit also „Meldung bei offen“ auf „geschlossen“ einstellen und umgekehrt…

Viele Grüße

RUE

Hallo zusammen und Danke für eure Hilfe - ich hab’s soweit eingrenzen/fixen können.

Nachdem ich nun versucht hatte auf eine CCU2 Version down zu graden, konnte ich auch hier keinen sinnvollen Zustand zu erreichen. Auch wenn ich genau wusste, dass mindestens eine der Versionen Events gesendet hat.

Ich hatte immer Kommunikation zwischen CCU2 und Syncom Server, habe Chats und Listenabgleiche gesehen - aber keinerlei Events.

Erst nachdem ich alle Komponenten einmal aus der CCU2 rausgeschmissen und neu eingebunden hatte, wurde ich die Ethernet-Losses los und habe auch die Events wieder bekommen.

Der Grund liegt also auf Seiten der CCU2 Firmware - ohnehin eher Bastelware, als professionelle Software. :frowning:

Nochmals Danke und Grüße

RUE

Guten Morgen - leider bastele ich immer noch an meinem Problem.

Nachdem mir unter Windows die Ideen augegangen sind, habe ich Symcon auf Ubuntu umgezogen.

Auch hier das gleiche Spiel … die CCU2 sendet rund 24 Stunden einwandfrei alle auftretenden Events, danach bricht die Kommunikation zusammen und ich finde einen Neustart des Eventservers und dann nur noch „PING-PONG“.

Alle Kommandos zur CCU2 gehen sauber rüber, aber es kommen keine Events zurück.

Als wenn der Socket noch belegt wäre.

Was mir auffällt - vielleicht ist aber auch das nur Zufall: vor dem „Neustart“ des Event-Servers sieht man das der Homematic Socket seine Konfig zu speichern versucht.

-------------------- snip snip snip ---------------------------------------

12:30:16 | 30657 | DEBUG | ScriptEngine | Skript ausgeführt - Ereignis: 38630 ~ Absender: TimerEvent
12:30:43 | 48053 | MESSAGE | HomeMatic Socket | Einstellungen gespeichert
12:30:43 | 48053 | MESSAGE | HomeMatic Socket | Stoppe Eventserver…
12:30:43 | 48053 | MESSAGE | HomeMatic Socket | Stopping event dispatch thread…
12:30:43 | 48053 | MESSAGE | HomeMatic Socket | Starte Eventserver…
12:30:43 | 48053 | MESSAGE | HomeMatic Socket | Creating event dispatch thread…
12:30:43 | 48053 | MESSAGE | Event Control | Wiederverbinden [HomeMatic Socket] erfolgreich
12:30:43 | 48053 | DEBUG | KernelMT | Nachricht IM_CHANGESTATUS für ID 48053 dauerte 183 ms (Modul: InstanceManager)
12:33:43 | 00000 | MESSAGE | Settings | Schreibe Einstellungen…
12:35:00 | 56472 | DEBUG | ScriptEngine | Skriptausführung - Ereignis: 56472 ~ Absender: TimerEvent
12:35:05 | 56472 | DEBUG | ScriptEngine | Skript ausgeführt - Ereignis: 56472 ~ Absender: TimerEvent
12:35:05 | 56472 | WARNING | ScriptEngine | Ergebnis für Ereignis 56472
<br />
<b>Warning</b>: Vorgang abgebrochen in <b>-</b> on line <b>1</b><br />

12:35:17 | 48053 | ERROR | TimerPool | HomeMatic Socket (KeepAlive): Vorgang abgebrochen

-------------------- snip snip snip ---------------------------------------

Das TimerEvent ist ein einfaches Kommando aus dem Wochenplan, welches an ein HMIP-IO geht.

Warum dieses abgebrochen wird ist mir auch nicht klar (es wird nur auf eine HMIP-Variable geschrieben).

Hier das Log, wenn der Event funktioniert:

-------------------- snip snip snip ------------------------------------------

06:00:00 | 56472 | DEBUG | ScriptEngine | Skriptausführung - Ereignis: 56472 ~ Absender: TimerEvent
06:00:00 | 29431 | MESSAGE | VariableManager | [Details nur zur Konfiguration\Aktoren\Strom Teich\SWITCH_VIRTUAL_RECEIVER\STATE] = true
06:00:00 | 56472 | DEBUG | ScriptEngine | Skript ausgeführt - Ereignis: 56472 ~ Absender: TimerEvent

-------------------- snip snip snip ------------------------------------------

Aus den Logs der CCU2 ist überhaupt nichts zu erkennen - keine Fehler, nichts.
Fast scheint es, dass sie das Problem überhaupt nicht „bemerkt“ und der Socket daher noch blockiert ist.

Manchmal hilft es die CCU2 neu zu starten. Eine wirklich saubere Funktion erhalte ich aber erst, wenn ich beide Teile neu starte … dann geht es wieder rund 24Stunden lang gut.

Hier das CCU2 Log:

--------------------- snip snip snip ------------------------------------------

Sep 8 12:30:01 ccu2.ruedi.local ReGaHss: Info: XmlRpcMethodEvent::execute: Event=„000B9569A516BD:3“.„STATE“=true […/Platform/DOM/iseXmlRpc.cpp (344)]
Sep 8 12:30:01 ccu2.ruedi.local ReGaHss: Info: XmlRpcMethodEvent::execute: Event=„000B9569A516BD:3“.„SECTION“=2 […/Platform/DOM/iseXmlRpc.cpp (344)]
Sep 8 12:30:01 ccu2.ruedi.local ReGaHss: Info: XmlRpcMethodEvent::execute: Event=„000B9569A516BD:3“.„PROCESS“=0 […/Platform/DOM/iseXmlRpc.cpp (344)]
Sep 8 12:30:01 ccu2.ruedi.local ReGaHss: Info: XmlRpcMethodEvent::execute: Event=„000397098A3BF5:0“.„RSSI_DEVICE“=-48 […/Platform/DOM/iseXmlRpc.cpp (34
4)]
Sep 8 12:30:01 ccu2.ruedi.local ReGaHss: Info: XmlRpcMethodEvent::execute: Event=„000397098A3BF5:0“.„DUTY_CYCLE“=false […/Platform/DOM/iseXmlRpc.cpp (3
44)]
Sep 8 12:30:01 ccu2.ruedi.local ReGaHss: Info: XmlRpcMethodEvent::execute: Event=„000397098A3BF5:0“.„LOW_BAT“=false […/Platform/DOM/iseXmlRpc.cpp (344)]
Sep 8 12:30:01 ccu2.ruedi.local ReGaHss: Info: XmlRpcMethodEvent::execute: Event=„000397098A3BF5:0“.„OPERATING_VOLTAGE“=2.800000 […/Platform/DOM/iseXmlRpc.cpp (344)]
Sep 8 12:30:01 ccu2.ruedi.local ReGaHss: Info: XmlRpcMethodEvent::execute: Event=„000397098A3BF5:0“.„UNREACH“=false […/Platform/DOM/iseXmlRpc.cpp (344)]
Sep 8 12:30:03 ccu2.ruedi.local ReGaHss: Info: XmlRpcMethodEvent::execute: Event=„CENTRAL“.„PONG“=„IPS“ […/Platform/DOM/iseXmlRpc.cpp (344)]
Sep 8 12:30:40 ccu2.ruedi.local ReGaHss: Info: TimerThread::ThreadFunction() - no timer exists, so Wait (60 s) ! […/Platform/RT/iseRTTimer.cpp (209)]
Sep 8 12:30:43 ccu2.ruedi.local rfd: IPS support system.multicall
Sep 8 12:30:43 ccu2.ruedi.local rfd: IPS support event
Sep 8 12:31:11 ccu2.ruedi.local ReGaHss: Info: XmlRpcMethodEvent::execute: Event=„CENTRAL“.„PONG“=„IPS“ […/Platform/DOM/iseXmlRpc.cpp (344)]
Sep 8 12:31:40 ccu2.ruedi.local ReGaHss: Info: TimerThread::ThreadFunction() - no timer exists, so Wait (60 s) ! […/Platform/RT/iseRTTimer.cpp (209)]
Sep 8 12:32:12 ccu2.ruedi.local ReGaHss: Info: XmlRpcMethodEvent::execute: Event=„CENTRAL“.„PONG“=„IPS“ […/Platform/DOM/iseXmlRpc.cpp (344)]
Sep 8 12:32:40 ccu2.ruedi.local ReGaHss: Info: TimerThread::ThreadFunction() - no timer exists, so Wait (60 s) ! […/Platform/RT/iseRTTimer.cpp (209)]
Sep 8 12:33:12 ccu2.ruedi.local ReGaHss: Info: XmlRpcMethodEvent::execute: Event=„CENTRAL“.„PONG“=„IPS“ […/Platform/DOM/iseXmlRpc.cpp (344)]
Sep 8 12:33:17 ccu2.ruedi.local ReGaHss: Info: CheckModifiedThread::ThreadFunction(): check modified flag […/Platform/RT/iseRTDOM.cpp (62)]

------------------------------- snip snip snip ------------------------------------

irgendwann gehen der CCU2 dann scheinbar die Sockets oder Handles aus und im Log findet sich folgendes:

------------------------------- snip snip snip ------------------------------------

Sep 8 20:06:05 ccu2.ruedi.local ReGaHss: Info: start web processing, worker thread #0 {„HTTP-Listener“} […/Platform/Internet/http/httpListener.cpp (205)]
Sep 8 20:06:05 ccu2.ruedi.local ReGaHss: Info: recvd 379 bytes by web server #0 […/Platform/Internet/http/httpServer.cpp (763)]
Sep 8 20:06:05 ccu2.ruedi.local ReGaHss: Info: IseSession GetSessionId from URL: /tclrega.exe […/Platform/Internet/http/iseSession.cpp (185)]
Sep 8 20:06:05 ccu2.ruedi.local ReGaHss: Info: invalid session - null pointer […/Platform/DOM/iseESPexec.cpp (2858)]
Sep 8 20:06:05 ccu2.ruedi.local ReGaHss: Info: http id #0 sends parsed file […/Platform/Internet/http/httpServer.cpp (2026)]
Sep 8 20:06:06 ccu2.ruedi.local ReGaHss: Info: start web processing, worker thread #0 {„HTTP-Listener“} […/Platform/Internet/http/httpListener.cpp (205)]
Sep 8 20:06:06 ccu2.ruedi.local ReGaHss: Info: recvd 743 bytes by web server #0 […/Platform/Internet/http/httpServer.cpp (763)]
Sep 8 20:06:06 ccu2.ruedi.local ReGaHss: Info: IseSession GetSessionId from URL: /esp/system.htm?sid=@6CH13eUvUm@&action=UpdateUI […/Platform/Internet/http/iseSession.cpp (185)]
Sep 8 20:06:06 ccu2.ruedi.local ReGaHss: Info: error page sent by id #0HTTP/1.1 500 Internal Server Error#015#012Server: ise GmbH HTTP-Server v2.0#015#012Accept-Ranges: bytes#015#012Cache-Control: no-store, no-cache#015#012Content-Type: text/html; charset=iso-8859-1#015#012#015#012<html><head></head><
Sep 8 20:06:09 ccu2.ruedi.local ReGaHss: Info: start web processing, worker thread #0 {„HTTP-Listener“} […/Platform/Internet/http/httpListener.cpp (205)]
Sep 8 20:06:09 ccu2.ruedi.local ReGaHss: Info: recvd 743 bytes by web server #0 […/Platform/Internet/http/httpServer.cpp (763)]
Sep 8 20:06:09 ccu2.ruedi.local ReGaHss: Info: IseSession GetSessionId from URL: /esp/system.htm?sid=@6CH13eUvUm@&action=UpdateUI […/Platform/Internet/http/iseSession.cpp (185)]
Sep 8 20:06:09 ccu2.ruedi.local ReGaHss: Info: error page sent by id #0HTTP/1.1 500 Internal Server Error#015#012Server: ise GmbH HTTP-Server v2.0#015#012Accept-Ranges: bytes#015#012Cache-Control: no-store, no-cache#015#012Content-Type: text/html; charset=iso-8859-1#015#012#015#012<html><head></head><
Sep 8 20:06:10 ccu2.ruedi.local ReGaHss: Info: start web processing, worker thread #0 {„HTTP-Listener“} […/Platform/Internet/http/httpListener.cpp (205)]

------------------------------- snip snip snip ------------------------------------

Ein Neustart von Symcon führt dann dazu, dass die Daten manuell wieder gelesen werden können, die Events beiben trotzdem aus. Erst nach dem Neustart der CCU2 und Symcon funktioniert die Anlage wieder korrekt.

Ein Dauerping von der Linux-Maschine zur CCU2 bringt übrigens auch nichts - keine Verluste.

Vielleicht kann das helfen das Problem weiter einzugrenzen.

Ich bin echt für jede Idee dankbar.

Danke und Grüße

RUE

Das Spiel lässt sich leider wiederholen, mittlerweile habe ich die Anzahl der loggings des IPS-Servers reduziert.

Kominscherweise bin ich jetzt damit bei 36 Stunden Betrieb gelandet.

Final komme ich aber trotzdem wieder an den gleichen Punkt:

Sep 10 22:30:02 ccu2.ruedi.local ReGaHss: Info: XmlRpcMethodEvent::execute: Event=„CENTRAL“.„PONG“=„IPS“ [iseXmlRpc.cpp:344]
Sep 10 22:30:02 ccu2.ruedi.local ReGaHss: Info: XmlRpcMethodEvent::execute: PONG event identified. [iseXmlRpc.cpp:358]
Sep 10 22:30:02 ccu2.ruedi.local ReGaHss: Info: XmlRpcMethodEvent::execute: Event=„000C17099A0453:0“.„SABOTAGE“=false [iseXmlRpc.cpp:344]
Sep 10 22:30:02 ccu2.ruedi.local ReGaHss: Info: XmlRpcMethodEvent::execute: Event=„000C17099A0453:0“.„DUTY_CYCLE“=false [iseXmlRpc.cpp:344]
Sep 10 22:30:02 ccu2.ruedi.local ReGaHss: Info: XmlRpcMethodEvent::execute: Event=„000C17099A0453:0“.„LOW_BAT“=false [iseXmlRpc.cpp:344]
Sep 10 22:30:02 ccu2.ruedi.local ReGaHss: Info: XmlRpcMethodEvent::execute: Event=„000C17099A0453:0“.„UNREACH“=false [iseXmlRpc.cpp:344]
Sep 10 22:30:02 ccu2.ruedi.local ReGaHss: Info: XmlRpcMethodEvent::execute: Event=„000C17099A0453:0“.„RSSI_DEVICE“=-58 [iseXmlRpc.cpp:344]
Sep 10 22:30:02 ccu2.ruedi.local ReGaHss: Info: XmlRpcMethodEvent::execute: Event=„000C17099A0453:0“.„OPERATING_VOLTAGE“=2.900000 [iseXmlRpc.cpp:344]
Sep 10 22:30:02 ccu2.ruedi.local ReGaHss: Info: XmlRpcMethodEvent::execute: Event=„000C17099A0453:0“.„RSSI_PEER“=-63 [iseXmlRpc.cpp:344]
Sep 10 22:30:02 ccu2.ruedi.local ReGaHss: Info: XmlRpcMethodEvent::execute: Event=„000C17099A0453:0“.„ERROR_CODE“=0 [iseXmlRpc.cpp:344]
Sep 10 22:30:02 ccu2.ruedi.local ReGaHss: Info: XmlRpcMethodEvent::execute: Event=„000C17099A0453:1“.„PRESENCE_DETECTION_STATE“=false [iseXmlRpc.cpp:344]
Sep 10 22:30:02 ccu2.ruedi.local ReGaHss: Info: XmlRpcMethodEvent::execute: Event=„000C17099A0453:1“.„CURRENT_ILLUMINATION“=0.000000 [iseXmlRpc.cpp:344]
Sep 10 22:30:02 ccu2.ruedi.local ReGaHss: Info: XmlRpcMethodEvent::execute: Event=„000C17099A0453:1“.„PRESENCE_DETECTION_ACTIVE“=true [iseXmlRpc.cpp:344]
Sep 10 22:30:03 ccu2.ruedi.local ReGaHss: Info: XmlRpcMethodEvent::execute: Event=„000C17099A0453:1“.„ILLUMINATION“=0.000000 [iseXmlRpc.cpp:344]
Sep 10 22:30:04 ccu2.ruedi.local ReGaHss: Info: XmlRpcMethodEvent::execute: Event=„000397098A35EA:0“.„RSSI_DEVICE“=-66 [iseXmlRpc.cpp:344]
Sep 10 22:30:04 ccu2.ruedi.local ReGaHss: Info: XmlRpcMethodEvent::execute: Event=„000397098A35EA:0“.„DUTY_CYCLE“=false [iseXmlRpc.cpp:344]
Sep 10 22:30:04 ccu2.ruedi.local ReGaHss: Info: XmlRpcMethodEvent::execute: Event=„000397098A35EA:0“.„LOW_BAT“=false [iseXmlRpc.cpp:344]
Sep 10 22:30:04 ccu2.ruedi.local ReGaHss: Info: XmlRpcMethodEvent::execute: Event=„000397098A35EA:0“.„OPERATING_VOLTAGE“=2.700000 [iseXmlRpc.cpp:344]
Sep 10 22:30:04 ccu2.ruedi.local ReGaHss: Info: XmlRpcMethodEvent::execute: Event=„000397098A35EA:0“.„UNREACH“=false [iseXmlRpc.cpp:344]
Sep 10 22:30:52 ccu2.ruedi.local ReGaHss: Info: TimerThread::ThreadFunction() - no timer exists, so Wait (60 s) ! [iseRTTimer.cpp:209]
Sep 10 22:31:02 ccu2.ruedi.local ReGaHss: Info: XmlRpcMethodEvent::execute: Event=„CENTRAL“.„PONG“=„IPS“ [iseXmlRpc.cpp:344]
Sep 10 22:31:02 ccu2.ruedi.local ReGaHss: Info: XmlRpcMethodEvent::execute: PONG event identified. [iseXmlRpc.cpp:358]
Sep 10 22:31:52 ccu2.ruedi.local ReGaHss: Info: TimerThread::ThreadFunction() - no timer exists, so Wait (60 s) ! [iseRTTimer.cpp:209]
Sep 10 22:32:02 ccu2.ruedi.local ReGaHss: Info: XmlRpcMethodEvent::execute: Event=„CENTRAL“.„PONG“=„IPS“ [iseXmlRpc.cpp:344]
Sep 10 22:32:02 ccu2.ruedi.local ReGaHss: Info: XmlRpcMethodEvent::execute: PONG event identified. [iseXmlRpc.cpp:358]
Sep 10 22:32:52 ccu2.ruedi.local ReGaHss: Info: TimerThread::ThreadFunction() - no timer exists, so Wait (60 s) ! [iseRTTimer.cpp:209]
Sep 10 22:33:03 ccu2.ruedi.local ReGaHss: Info: XmlRpcMethodEvent::execute: Event=„CENTRAL“.„PONG“=„IPS“ [iseXmlRpc.cpp:344]
Sep 10 22:33:03 ccu2.ruedi.local ReGaHss: Info: XmlRpcMethodEvent::execute: PONG event identified. [iseXmlRpc.cpp:358]
Sep 10 22:33:52 ccu2.ruedi.local ReGaHss: Info: TimerThread::ThreadFunction() - no timer exists, so Wait (60 s) ! [iseRTTimer.cpp:209]
Sep 10 22:34:03 ccu2.ruedi.local ReGaHss: Info: XmlRpcMethodEvent::execute: Event=„CENTRAL“.„PONG“=„IPS“ [iseXmlRpc.cpp:344]
Sep 10 22:34:03 ccu2.ruedi.local ReGaHss: Info: XmlRpcMethodEvent::execute: PONG event identified. [iseXmlRpc.cpp:358]
Sep 10 22:34:52 ccu2.ruedi.local ReGaHss: Info: TimerThread::ThreadFunction() - no timer exists, so Wait (60 s) ! [iseRTTimer.cpp:209]
Sep 10 22:35:03 ccu2.ruedi.local ReGaHss: Info: XmlRpcMethodEvent::execute: Event=„CENTRAL“.„PONG“=„IPS“ [iseXmlRpc.cpp:344]
Sep 10 22:35:03 ccu2.ruedi.local ReGaHss: Info: XmlRpcMethodEvent::execute: PONG event identified. [iseXmlRpc.cpp:358]
Sep 10 22:35:52 ccu2.ruedi.local ReGaHss: Info: TimerThread::ThreadFunction() - no timer exists, so Wait (60 s) ! [iseRTTimer.cpp:209]
Sep 10 22:36:03 ccu2.ruedi.local ReGaHss: Info: XmlRpcMethodEvent::execute: Event=„CENTRAL“.„PONG“=„IPS“ [iseXmlRpc.cpp:344]
Sep 10 22:36:03 ccu2.ruedi.local ReGaHss: Info: XmlRpcMethodEvent::execute: PONG event identified. [iseXmlRpc.cpp:358]


Gestern um 22:36 haben die Übertragungen (bis auf die PONGS) zwischen CCU2 und IP-Symcon aufgehört, danach nur noch PONGs.

Leider macht es keinen Sinn die CCU ohne Symcon laufen zu lassen - da würde der Effekt nie auffallen.

Das Web-Interface der CCU2 ist soweit bedienbar, die Listung der Komponenten funktioniert auch - allerdings kann ich die Konfiguration einiger Komponenten nicht aufrufen. Wieder sieht es so aus, als wären der CCU die Sockets ausgegangen - aber im IPv6?

Keinerlei Fehlermeldungen, obwohl alles eingeschaltet ist.

Als nächstes muss ich mal einen Netzwerktrace machen.

Grüße

RUE

PS: Heute hat der Neustart der CCU2 völlig ausgereicht um das System zu stabilisieren.

Hallo - ich wollte nochmals einen Stauts geben.

Momentan sieht es wohl so aus, dass beide Seiten Probleme haben, um eine Betriebssystemabhängigkeit auszuschließen habe ich mittlerweile Symcon auf Ubuntu migriert.

Verursacht wird der Ausfall (noch nicht final bewiesen) vermutlich zwischen der CCU2 und einem HmIP-FSM16.

Nach einigen Befehlen zu diesem fängt die CCU2 an zu spinnen, wird langsam, Web-Interface wird unkontrolliert und auf der XML-Schittstelle gibt es u.a. EQ3 verhält sich hier recht inkompetent und arrogant - die von mir eingestellte Supportmeldung wird einfach als Problem anderer Leute eingestuft. Ich habe daraufhin nochmals genauer alle gefundenen Probleme gemeldet - jetzt meldet sich EQ3 garnicht mehr. Was für eine Firma.

Um das Problem zu umgehen, starte ich die CCU2 daher nun jede Nacht neu - das funktioniert von dieser Seite aus auch scheinbar einwandfrei.

Normalerweise klappt dann auch die Verbindung zwischen CCU und Symcon wieder. In sagen wir 1 aus 5 Fällen klappt die Verbindungsaufnahme aber scheinbar nicht mehr sauber. Der Verbindungsmanager meldet die Verbindung wieder als existierend, er nimmt aber scheinbar keine Traps der CCU mehr entgegen (nichts im Log zu erkennen).
Auf Seiten der CCU sieht man aber (zumindest im Logefile), dass diese die Events zu schicken scheint.
Ein manueller reload der Daten per Kommandoscript führt dann auch zu keinem Erfolg - das mache ich mitterlweile alle 2.5 Stunden, auf Variablen, die nicht innerhalb der letzten halben Stunde aktualisiert wurden - man wird ja langsam paranoid.

Wireshark trace mache beim nächsten mal, hatte heute keine Zeit.

Nach einem Neustart von Symcon funktioniert wieder alles einwandfrei.

Wenn ihr noch Ideen habt - immer raus damit …

Danke und Grüße

RUE