hatte heute und zuletzt vor 5 Tagen das Phänomen, daß nach dem Neustart meiner CCUs (jeweils eine CCU1 und eine CCU2) die HM Sockets sich nicht mehr automatisch verbunden haben. Ansonsten funktioniert das immer problemlos seitdem das in einer der 4.1 Testing Versionen schon „behoben“ wurde. Aber vielleicht nicht ganz behoben …
Ich kann die Sockets händisch schließen und wieder öffnen, dann läuft alles normal weiter. Der Fehler ist nicht wirklich reproduzierbar kommt halt machmal vor … z.Z. habe ich die noch die Version vom 16.11.2016, a8847cc1ab82. Wurde nach dem 16.11. noch was an dem HM Socket geändert ?
Hallo paresy,
ich habe genau das selbe Problem (seit dem letzten Update(?)).
Im Einsatz sind zwei CCU2 (1x original, 1x Raspimatic).
Bei Neustart der CCUs bzw. auch beim Neustart von IPS 4.1 (auf Ubuntu, separater Rechner) werden die Sockets nicht verbunden. Hier hilft nur, die Funktion kurz aus- und dann wieder einzuschalten, also Haken über der IP-Adresse raus, speichern, dann wieder rein, speichern.
Updates werden regelmäßig geprüft und eingelesen. (sudo apt-get update, sudo apt-get upgrade)
Vielleicht helfen diese Hinweise.
Mit freundlichen Grüßen
Matthias
Ich habe zum nächsten Update einen weiteren Check eingebaut der diesmal auch Abbrüche im Rückkanal zu 100% erkennt. Somit sollte das Problem hoffentlich vollständig gelöst sein.
Also der Socket wird nicht rot und schalten geht wie immer, es kommt nur nix an Daten an. Ich probier mal im Testing Kanal die neueste Version.
Mein „Workaround“ sieht so aus, daß ich bei drei verschiedenen Sensoren prüfen wann das letzte mal Daten angekommen sind. Wenn im Durchschnitt nach 30 min. nichts kommt (normalerweise senden die HM Sensoren alle 2-4 min. Werte an die CCU) dann schließe und öffne ich den Socket manuell. Dann läuft wieder alles normal.
Habe gestern auf BETA upgedated, heute morrgen ging meine Weihnachtsbeleuchtung nicht mehr aus… lauter Fehler im Log „Socket nicht geöffnet“… Um 08 Uhr wäre Schalttermin gewesen…
Socket war geöffnet, er war nicht rot.
Es gab sonst keine Fehlermeldungen, im Moment öffne und schließe ich ihn alle 2 Minuten… da ich gleich weg muss…
seit gestern habe ich die neueste Testing 4.1 aufgespielt und habe jetzt den „PONG“ in meinen Meldungen (wir hatten das schon mal bzgl. der HM Verzögerung … :D)
also um 21:24:53 passiert irgendwas, ich vermute IPS stellt fest, daß die CCU2 nicht antwortet ???
was aber nicht ganz stimmen kann denn um 21:25:25 sendet die CCU2 noch Daten von einem Bewegungsmelder an IPS
erst um 21:25:37 beginnt dann ein „Neustart“ des Sockets" der CCU2 im Wohnzimmer (ich habe noch eine CCU1 im Keller die ist von dem Spuk nicht betroffen :))
Diesen PONG habe ich jetzt den Tag über 2-3 mal im Log-File beobachtet. Funktioniert immer gleich, nach der TimerPool Meldung dauert es ca. 1 min, in der auch jede Menge Daten von der CCU2 an IPS ankommen, bis der Socket sich schließt und wieder öffnet. Dazwischen hatte ich auch einmal von „CCU“ die Meldung (200), die hatte ich bisher auch noch nicht beobachtet ?!
Ich hoffe das hilft Euch weiter, insgesamt läuft das System sehr gut, man merkt von den Dingen im Hintergrund nichts. Bisher hatte ich auch keine Beobachtung mehr, daß über 30 min. und länger keine Daten mehr von der CCU2 ankamen, wobei ich das bisher auch nur selten ca. 1 x pro Woche hatte.
Wann ist denn das Phänomen zum ersten mal aufgetreten ? gehen denn Schaltbefehle ?
Bei mir betrifft es eigentlich nur die Daten die von der CCU2 zum IPS-Server kommen. Schalten kann ich immer, von daher müßte man prüfen ob nicht generell eine Komponete abgestürzt ist. Neustart von CCU2 und IPS könnte helfen.
Wie ist denn die CCU2 an den Server angeschlossen? Ist das per LAN Kabel oder per WLAN. Bei mir ist die Verbindung per WLAN sehr stabil, jedoch war mal mein WLAN Router defekt, da hatte ich ähnliche Probleme. Am besten mal systematisch alle Verbindungsprobleme ausschließen.
Ich habe auch ein Script auf der CCU2 laufen das alle Minute ein Ping an den IPS-Server schickt. Seit dem hatte ich den Eindruck, daß das die „Fitness“ der CCU2 erhöht, kann aber auch Einbildung sein …
Jedenfalls kann man den Erfolg des Ping Befehls in eine Statusvariable der CCU schreiben, so daß man ggf. da nachschauen kann ob die Pings ankommen.
Die Probleme traten jetzt erst mit dem Update auf 4.1 Beta auf. Schaltbefehle an Rolläden und „Weihnachtsbeleuchtung“ haben versagt, andere Schaltvorgänge, Beleuchtung Stellplatz etc. haben funktioniert, also nicht reproduzierbar.
Ich schließe und öffne nun im Script kurz vorm öffnen und schließen der Rolläden den HM Socket, heute morgen hat das funktioniert. Ich beoabachte das nun mal eine Weile.
Einen Ping von der CCU2 an IPS hatte ich, den habe ich jetzt deaktiviert um zu sehen ob daher ein Problem kommt.
CCU2 und IPS hatte ich mehrfach neu gestartet, nach dem Motto „Ein Boot tut guuut“ CCU2 ist via LAN angeschlossen.
Neu sind bei mir 2 Accesspoint im 2,4 und 5 GHZ Bereich von Ubiquiti Unifi die Modelle AP-AC Pro, aber nach allem was ich gelesen hatte ist es eher unwahrscheinlich dass diese die Frequenz 868 Mhz beinflussen.
Das WLAN der Fritzbox 6490 habe ich abgeschaltet.
Hab nur gemerkt, dass die HM Fensterkontakte die etwas weiter weg sind nicht gleich reagieren, und oft rot werden. Batterien natürlich schon gewechselt…
Hier bin ich gerade am testen wenn ich einen AP der in unmittelbarer Nähe ist abschalte ob es besser wird.
ich habe seitdem ich die neue Beta Version drauf habe heute ca. 10 x einen Reconnect gestartet, dazu hatte ich folgendes Script schon vor ca. 2 Jahren installiert, was bisher so ca. 2-3 x im Monat den Reconnect erzwungen hat. Das Script wird zyklisch alle 2 min gestartet. Falls die Verbindung zwischen IPS-Server und CCU2 abreißen sollte bekomme ich auch eine SMS:
$Instance = IPS_GetInstance(10188 /*[HomeMatic Socket im Wohnzimmer]*/);
$Status = $Instance['InstanceStatus'];
echo $Status;
$ipadr = "10.118.143.111";
/* check if CCU is alive */
$result = Sys_Ping($ipadr, 1000);
echo $result;
echo $Status;
if ($Status != 102) {
IPS_LogMessage("CCU Socket", $Status);
IPS_SetProperty(10188 /*[HomeMatic Socket im Wohnzimmer]*/, "Open", FALSE);
IPS_SetProperty(10188 /*[HomeMatic Socket im Wohnzimmer]*/, "Open", TRUE);
IPS_ApplyChanges(10188 /*[HomeMatic Socket im Wohnzimmer]*/);
IPS_RunScript(44621 /*[SMS\SMS HM-Reconnect]*/);
}
na ja ich habe ja 1000 SMS / Monat gratis, davon habe ich dann heute schon paar verbraucht :rolleyes:
Fazit irgendwie ist die Verbindung zwischen CCU2 und dem IPS jetzt viel instabiler und ich habe auch den Verdacht, daß das Problem der verzögerten Datenübertragung von CCU2 an IPS, was wir hierim Forum schon anderweitig diskutieren, damit zusammenhängt.
ja ich hatte es auch erst zyklisch, aber wenn gerade um diese Uhrzeit beim reconnect ein wichtiger Schaltvorgang ansteht würde der in die Hose gehen, deshalb mache ich es nur bei den wirklich wichtigen Vorgängen… Rolläden und Weihnachtsbeleuchtung… hat mit dem WAF Faktor zu tun
Beobachtet habe ich auch, dass die Meldungen von HM TFK auch oft verspätet eintreffen, irgendwie hängt das alles zusammen.
Aber ich seh gerade du machst ja vorher ein Ping ob die CCU2 noch lebt… ist natürlich auch eine Möglichkeit.
Ich denke aber dass die Jungs von Symcon das noch finden und dann hoffentlich fixen, ich warte ja noch auf Geschenke
ich habe gesehen paresy hat heute eine neue Beta freigegeben bei der die „PONG“ Verzögerung beseitigt sein soll:
IP-Symcon 4.10, 12.12.2016, d694bb8e8dea
Hab die gerade mal aufgespielt, mal sehen ob das was bringt …
Ja es wird sehr viel besser. Hatte jetzt nach 24 Stunden nur 1 x ein PONG, heute morgen um 6:41 Uhr (vielleicht war es ja der Wecker um die CCU2 aufzuwecken :rolleyes: )
Mal sehen wie es bis zum WE ausschaut. Wenn es so bleibt stell ich mal mein CCU2-Fitnessprogramm schrittweise ab und schau mal ob es auch was hinsichtlich der sonstigen Verzögerungen gebracht hat.
CCU2 ist via LAN angeschlossen.