HomeMatic IP liefert keine Daten

RUE · 19. September 2017 um 08:21

Guten morgen nochmals hier der versprochene Trace.

Offensichtlich klappt in der aktuellen Symcon Version der Reconnect nicht sauber - ist die CCU mal nicht sprechbereit, setzt Symcon zwar den Port wieder auf, bleibt aber taub.

Hier der Output vpon tcpdump (eingeschränkt auf den Port 5544) auf meinem Symcon-Server:

08:14:41.454885 IP 10.254.254.10.50013 > 10.254.254.11.5544: Flags [F.], seq 2036288756, ack 3007202411, win 490, length 0
08:14:41.454896 IP 10.254.254.11.5544 > 10.254.254.10.50013: Flags [.], ack 1, win 283, length 0
08:14:41.496398 IP 10.254.254.10.50018 > 10.254.254.11.5544: Flags [S], seq 932906122, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 5], length 0
08:14:41.496411 IP 10.254.254.11.5544 > 10.254.254.10.50018: Flags [S.], seq 1265381499, ack 932906123, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
08:14:41.497030 IP 10.254.254.10.50018 > 10.254.254.11.5544: Flags [.], ack 1, win 457, length 0
08:14:41.512690 IP 10.254.254.10.50018 > 10.254.254.11.5544: Flags [P.], seq 1:146, ack 1, win 457, length 145
08:14:41.512705 IP 10.254.254.11.5544 > 10.254.254.10.50018: Flags [.], ack 146, win 237, length 0
08:14:41.513129 IP 10.254.254.10.50018 > 10.254.254.11.5544: Flags [.], seq 146:1606, ack 1, win 457, length 1460
08:14:41.513133 IP 10.254.254.11.5544 > 10.254.254.10.50018: Flags [.], ack 1606, win 260, length 0
08:14:41.590613 IP 10.254.254.10.50018 > 10.254.254.11.5544: Flags [P.], seq 1606:2272, ack 1, win 457, length 666
08:14:41.590636 IP 10.254.254.11.5544 > 10.254.254.10.50018: Flags [.], ack 2272, win 283, length 0
08:14:41.590932 IP 10.254.254.11.5544 > 10.254.254.10.50018: Flags [P.], seq 1:440, ack 2272, win 283, length 439
08:14:41.590965 IP 10.254.254.11.5544 > 10.254.254.10.50018: Flags [F.], seq 440, ack 2272, win 283, length 0
08:14:41.591668 IP 10.254.254.10.50018 > 10.254.254.11.5544: Flags [.], ack 440, win 490, length 0
08:14:41.613963 IP 10.254.254.10.50018 > 10.254.254.11.5544: Flags [F.], seq 2272, ack 441, win 490, length 0
08:14:41.613970 IP 10.254.254.11.5544 > 10.254.254.10.50018: Flags [.], ack 2273, win 283, length 0
08:14:41.648777 IP 10.254.254.10.50019 > 10.254.254.11.5544: Flags [S], seq 2018725559, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 5], length 0
08:14:41.648791 IP 10.254.254.11.5544 > 10.254.254.10.50019: Flags [S.], seq 397438866, ack 2018725560, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
08:14:41.649374 IP 10.254.254.10.50019 > 10.254.254.11.5544: Flags [.], ack 1, win 457, length 0
08:14:41.654924 IP 10.254.254.10.50019 > 10.254.254.11.5544: Flags [P.], seq 1:414, ack 1, win 457, length 413
08:14:41.654936 IP 10.254.254.11.5544 > 10.254.254.10.50019: Flags [.], ack 414, win 237, length 0
08:14:41.655065 IP 10.254.254.11.5544 > 10.254.254.10.50019: Flags [P.], seq 1:205, ack 414, win 237, length 204
08:14:41.655094 IP 10.254.254.11.5544 > 10.254.254.10.50019: Flags [F.], seq 205, ack 414, win 237, length 0

Hier der Auzug des Logfiles für diesen Zeitpunkt:

Um die Aktion auszulösen habe ich ein Fenster geöffnet - im tcpdump sieht man den Event der CCU2 (10.254.254.10) eingehen. Syncom bestätigt ihn scheinbar auch (08:14:41 | 27547 und 08:14:46 | 27547 ) reagiert aber nicht weiter darauf, ich bekomme ihn nicht in die Anzeige.

Hier sieht man ja zumindest noch die Kommunikation, in den meisten Fällen sehe ich die eingehenden Pakete, Symcon reagiert aber überhaupt nicht darauf - so als wenn die Payload des Packetes nicht dekodiert werden könnte.

Wäre schön, wenn das jemand fixen, bzw einen Watchdog dafür bauen könnte - oder gibt es den bereits?

Danke und Grüße

RUE

RUE · 21. September 2017 um 11:18

So, ich denke jetzt hab ichs…

Offensichtlich geht wie vermutet beim Steuern des HmIP-FSM16 etwas schief.

Sobald Steuerkommandos zu diesem geschickt werden, werden wohl in der CCU2 Variablen/Parameter/Code - whatever überschrieben und die Kiste macht alles mögliche und stürzt final auch ab. Das würde dann auch eine eventuell verhunzte und nicht mehr zu dekodierende Payload erklären.

Ich habe die Steuerung des IO-Bausteins nun aus Symcon herausgenommen und lese nur noch Variablen mit - dieses scheint „Umweltverträglich“ zu sein. Nach einigen Reboots funktioniert nun schon einige Tage wieder alles problemlos.

Mein letzter Versuch war einfach nur auf eine Variable zu schreiben - nach einiger Zeit hatte ich wieder Totalausfall.

Aktuell steuert die CCU2 das Relais des FSM16 mit der internen Zeitsteuerung des Bausteins. Das funktioniert gut und hat scheinbar auch keinen Einfluss auf die CCU2 - man kann halt nicht mehr dynamisch eingreifen.

Eine Fehlermeldung diesbezüglich habe ich bei EQ3 eingekippt, Rückmeldung „wenn es XMLRPC angeht, wenden Sie sich an einen Integrator“ - sehr hilfreich!

Der FSM16 läuft jetzt im Automatikmode, damit habe ich nur noch einen Steuerpunkt im Baustein. Symcon zeigt mir aber nach wie vor alle 3x Receiver und 1x Transmitter an - kann das richtig sein?

Es wäre gut, wenn sich Symcon mit EQ3 mal zusammensetzen würde um die Fehlerquelle zu identifizieren.

Mir ist weiterhin aufgefallen, dass eigentlich auch innerhalb der CCU2 nicht alles ganz richtig tickt - mit dem neuen Standard-Protokoll werden alte Kontakte nicht mehr erkannt. Erst nach Umstellung der CCU2 aur „Legacy“ scheint wieder alles im grünen Bereich zu sein (betrifft auch teilweise Symcon, da ich den Eindruck hatte dass alte Kontakte nicht immer richtig reagieren). Auch das habe ich an EQ3 gemeldet.

Für den Moment läuft bei mir alles mit den Einschränkungen „Legacy“ und „FSM16“ kann nicht aus Symcon heraus bedient werden.

Viele Grüße

RUE

Powerfreddy · 21. September 2017 um 21:04

Geht bei mir problemlos

Gruß
Bruno

RUE · 21. September 2017 um 21:12

Hallo Bruno,

wie steuerst Du?

Wochenplan in IP-Symcon?
Welche CCU? - welche Firmware?
Fährst Du „Legacy“ oder „Standard“ Mode in der CCU?

Hast Du eine gemischte Installation so wie ich?

Nur monitoren geht bei mir auch … irgendwo muss doch das fehlende Puzzlestück sein

Grüße

RUE

Powerfreddy · 22. September 2017 um 06:28

Steuerung auf die Schnelle mal per WebUI-Button und per Skript. Wochenplan habe ich nicht probiert, macht aber sicher keinen Unterschied.

CCU2 - 2.29.22 - Community

Ja

???

RUE · 22. September 2017 um 08:09

Guten Morgen Bruno,

„Community“ hab ich noch nicht probiert - wo ist der eigentliche Unterschied? - nur mehr Debug-Messages und Scriptkontrolle?

Ich habe eine Hardware-CCU2 (vielleicht sollte ich die mal in eine virtuelle Maschine umlagern) - an der hängen im wesentlichen HmIP-Komponenten (Fenstersensoren, Thermostatventile, Rauchmelder, ein FSM und ein SPI).

Parallel dazu - weil zum Inbetriebnahmezeitpuntk das noch nicht als HmIP gab, ein HM-LC-Sw1-PCB Modul, mit welchem ich die Heizungssteuerung beeinflusse. Seit Update der CCU auf das letzte Release gibt es nun Ärger (ich kann mich eigentlich nicht erinnern, vorher ein Problem mit dem FSM16 gehabt zu haben). Der LC-Sw1 wir im „Standard“-Mode nicht mehr gefunden und ich glaube auch, dass es Steuerungsprobleme gibt.

Ich habe alle Komponenten auf der aktuellen Firmware laufen - auch wenn das jedesmal ein ziemlicher Akt ist - irgendwie fallen mir nach dem Update alles Geräte aus der CCU raus und müssen neu angelernt werden. Ziemlich ärgerlich, aber ich glaube „normal“.

Wa ich nur sagen kann ist, dass solange der FSM16 von Symcon gesteuert wurde, hatte die CCU und Symcon Probleme, die ich jetzt seit einigen Tagen nicht mehr habe. Ob FSM16 der Auslöser ist, oder die Mischinstallation / das neue, tolle Protokoll kann ich nicht sagen. Leider habe ich keine Quellen und bin nicht der Entwickler
Ich sehe nur die Auswirkungen …und versuche durch Experimente einzugrenzen.

Naja, vielleicht wäre das wirklich mal eine Maßnahme einen LXC-Container mit der CCU2 Firmware zu füttern.

Hast Du Erfahrung … muss/kann man dann (ein Funkmodul habe ich im Server nicht) die alte CCU oder ein Funk-Gateway direkt ansteueren/als Relais benutzen, oder braucht es ein lokales Funkmodem?

Danke und Grüße

RUE

paresy · 22. September 2017 um 10:03

Bist du dir sicher, dass du IP-Symcon neustarten musst? Ich vermute stark, dass es ausreicht, wenn du den HomeMatic Socket deaktivierst und wieder reaktivierst nach einem CCU neustart. Dann meldet sich IPS wieder frisch an der CCU an und die CCU weiß dann bescheid, wohin die Events müssen.

Die Internal Server Errors sehen aus, als wenn diese vom WebServer der CCU kommen - somit dürften diese nicht die API zu IPS betreffen. Es sei denn, dass dadurch irgendwelche Nebeneffekte auftreten.

paresy

RUE · 22. September 2017 um 12:01

Hallo Paresy,

generell sieht es zunächst mal so aus, als ob sich Syncom immer sauber an der CCU anmeldet (Ping-Pong läuft auf jeden Fall los).

Der HTML500 Fehler und das extreme langsam werden der CCU lässt mich darauf schließen, dass die CCU2 entweder überlastet ist, oder ein Speicherfresser keine sinnvolle Funktion mehr zulässt. Das dann damit Symcon auch nicht mehr richtig funktionieren kann ist klar.

Besteht diese Situation relativ kurzfristig und startet man dann die CCU neu, kann Symcon einfach weiterarbeiten.
Er nach längerer Zeit (mehrere Stunden) tritt der Fall ein, dass beide Komponenten neu gestartet werden müssen - ich hab da relative lange rumgespielt. Ich habe so den Verdacht, dass Symcon durch die mehrfachen Verbindungsversuche einfach die Sockets ausgehen und daher keine Verbindung mehr zu Stande kommen kann. Leider sehe ich keine Fehlermeldung die mir da bei der Analyse helfen könnte.

Wichtiger scheint mir aber wie wir der eigentlichen Ursache näher kommen können. Irgendeine Kombination scheint dazu zu führen, dass bei Schaltkommandos zum HmIP-FSM16 (FE 1.6.3) dieser Effekt ausgelöst wird. Seitdem ich die Zeitsteuerung herausgenommen habe, funktioniert alles, wie es soll - keinerlei Probleme mehr.
Einzig verwirrend ist die Anzeige der Schaltpunkte im Objektbaum - im „Auto“ Mode zeigt mir der FSM16 in der CCU nur noch einen steuerbaren Kontakt. Der Objektbau zeigt aber nach wie vor 3+1 Schaltpunkte. Was mir auch aufgefallen ist: im Objektbaum gibt es ja auch den Konfigurationspunkt für das Wochenprogramm des FSM16 - obwohl ich dieses jetzt ja nutze, ist dieses Objekt leer … ist das so normal?

Danke und Grüße

RUE

Powerfreddy · 22. September 2017 um 14:57

Neue Funktionen und einige Verbesserungen, spielt aber m.E. für Dich keine Rolle, da die eigentliche Kommunikation zhwischen Symcon und der CCU nicht klappt.

Seit Update der CCU auf das letzte Release gibt es nun Ärger …

Backup erstellen, Recovery mit Werksreset machen, Backup wieder einspielen, CCU neu starten

… fallen mir nach dem Update alles Geräte aus der CCU raus und müssen neu angelernt werden.

Ist momentan so

… solange der FSM16 von Symcon gesteuert wurde, …

Nach obiger Prozedur diesen Ablernen mit Werkszustand un wieder anlernen.

Naja, vielleicht wäre das wirklich mal eine Maßnahme einen LXC-Container mit der CCU2 Firmware zu füttern.

Hast Du Erfahrung … muss/kann man dann (ein Funkmodul habe ich im Server nicht) die alte CCU oder ein Funk-Gateway direkt ansteueren/als Relais benutzen, oder braucht es ein lokales Funkmodem?

Da braucht es keine Erfahrung, nur lesen … ohne Funkmodul geht nix.

RUE · 22. September 2017 um 19:44

Hallo Bruno und vielen Dank für die schnellen und ausführlichen Antworten.

Die Frage nach dem Modem ging eher in die Richtung „kann ich die CCU oder ein anderes LAN-Gateway als remote Funkmodem nutzen“ … hab ich wohl falsch formuliert.

Die CCU würde nämlich auf einer PROXMOX (I86 + QEMU + Proxmox + LXC) Installation Platz nehmen müssen.
Ein Funkmodem bekomme ich in den Server nicht so einfach rein

Die Resets habe ich dann nach vielen Fehlschlägen automatisch gemacht

Bin mal gespannt, wie lange das jetzt gut geht

Danke und Grüße

RUE

Powerfreddy · 22. September 2017 um 20:29

Habe Dich schon verstanden, die Antwort bleibt gleich. Ohne HMIP ginge das.

Hier war heute was, habe aber keine Ahnung davon
[gelÃ¶st] Installation als virtuelle Maschine â€¢ HomeMatic-Forum / FHZ-Forum

RUE · 25. September 2017 um 11:22

Hi Bruno und Danke für die Tipps.

War am Wochenende leider familiär ziemlich eingespannt, aber den Link schaue ich mir auf jeden Fall an.

Grüße

RUE

dpoessl · 29. Oktober 2017 um 09:24

Ich muss den Thread mal „missbrauchen“ weil ich nicht extra einen neuen aufmachen möchte.

Habe gestern meinen erste HM IP Komponente erworben.

Habe den Schaltaktor an die CCU2 angebunden und wollte ihn jetzt in IPS einbinden.

Die HM IP Geräte habe ja eine andere Seriennummer als die normalen HM Komponenten.

Das Teil taucht bei mir nicht im HM Konfigurator auf.

Lernt man die IP Komponenten anders an IPS an?

Nall-chan · 29. Oktober 2017 um 09:54

Schon mal deine Instanz vom Homematic-Socket geöffnet…
Dann solltest du deinen Fehler sehen.
Und das hatten wir gefühlt schon 10x im Forum, das der Haken vergessen wurde

Michael

PS: In IPS lernt man gar keine Geräte an…

dpoessl · 29. Oktober 2017 um 09:58

Dankeschön und Entschuldigung für die falsche Ausdrucksweise.