bei mir liegt der Fehler so glaube ich an IPS. Mit der Zeit wird der Zeitraum immer länger. Der Socket läßt sich dann auch nicht mehr öffen und schließen. Bei mir sind dann auch beide CCU`s betroffen. Dann kommen auch keine Daten mehr herein. Erst nach einem Neustart des Servers ist wieder alles ok (für die nächsten 10 Tage). Bei den letzten 2 Mal konnte ich auch feststellen, daß auch von den 1-wire Netzen keine Daten mehr ankommen. Wenn nach dann den Ressoucenmonitor auf dem Server öffnet kann man feststellen, das IPS die logging.db wegschreibt und den Datenträger zu fast 100% auslastet.:mad:
Ich habe heute auf einen Hutschienenaktor umgebaut, also weg vom Batterieaktor und habe immer noch das gleiche Problem, an den Aktoren scheint es nicht zu liegen…
würde gerne wissen ob es schon weitere 4.1 Erfahrungen gibt. Bei 3.4 war das definitiv bei mir nicht der Fall, allerdings kann ich auch nicht ausschließen, dass es die CCU2 verursacht, ggf. durch ein FW Update…
Ich bin auf der 4.1 und habe das Problem immer noch, manchmal dauert es Minuten bzw. das Signal kommt gar nicht an, das nächste mal geht es sofort ohne Verzögerung. Hatte das Problem in der 3er Versionen auch nie.
Auch ich kann die CCU2 nicht komplett als Fehlerquelle ausschliessen, zumal mir die aktuelle Version abartig viele „Kommunikation gestört Meldungen“ liefert.
da du die neue FW 2.21.10 ansprichst wollte ich dich auf den Duty Cycle aufmerksam machen. Solltest du z. B. beim Start von IPS deine Geräte so wie ich abfragen, um die aktuellen Stati zu bekommen, dann kann nach mehrfachem Start von IPS schnell ein Problem auftreten.
Ich muss mich leider auch mal zum Thema melden:
Ich steuere einige Rolladen (aus historischen Gründen) über einen HM 4-Kanal Funkswitch, getriggert wird zum Beispiel über den HM Griffkontakt … seit der 4er IPS Version dauert es eine gefühlte Ewigkeit bis die Rollade nach dem Öffnen der Tür (Griffkontakt) anfängt zu verfahren. Ich habe das mal mit Log Ausgaben geprüft => der Übeltäter (Zeitfresser) ist der einfache Schreibbefehl auf den Switch
Das dauert sage und schreibe 4 Sekunden (IPS_LogMessage vor und nach dem Befehl).
Das war in der 3er Version nicht der Fall, da fuhr die Rollade gefühlt sofort mit dem Drehen des Türgriffs hoch oder runter.
Wenn ich noch etwas zur „Fehlerfindung“ beitragen kann bitte Info.
Du nutzt keine klassische CCU2? Bedeutet es kann nicht an der Firmware der CCU2 liegen?
Mich nervt diese Verzögerung total, 2-4 Sekunden wäre ja noch ok… Ich stehe manchmal 15 -30 Sekunden vor der Haustür bis diese aufgeht. Auch meine Frau ist genervt.(nicht gut).:mad: Manchmal geht die Tür sofort auf und manchmal dauert es Ewigkeiten.
Ich habe keine Idee was das ist, bei IPS 3.4 war das sicher nicht.
Ich hatte auch Probleme mit Verzögerungen von bis zu 10-15 Sek. nach dem Umstieg von RaspberryMatic auf eine org. CCU2. Nach dem Umstellen des Syslog Servers wie oben beschrieben (alles loggen) funktioniert es ohne Probleme.
Die fragliche HW spreche ich zur Zeit noch über einen LAN Adappter an. Ich werde das mal auf den RASPI mit YAHM umziehen und vergleichen wie sich das verhält …melde mich dann.
So, testweise mal einen Aktuator auf den PI (YAHM CCU2) umgezogen … siehe da, die Verzögerung ist weg, Reaktion wie früher … quasi direkt.
Werde in den nächsten Tagen wohl alles auf dem PI umziehen müssen…
Gruß Michael
Ich kenne mich leider nicht in Homegear oder in YAHM aus (Muss mich da erst mal einlesen ), würde es aber erstmal gerne mit dem Syslog Server oder Ping versuchen, kann mir jemand einen Hinweis geben wie ich das auf der CCU2 zum Laufen bekomme?
Danke für deinen Hinweis, ich hab den Thread gelesen, weiß aber nicht wirklich was dein Teil genau macht, was heißt Watchdog… du überwachst damit die CCU ? Du öffenest in IPS die homematic Socket…?? Kannst du mir in ein, zwei Sätzen das kurz erklären?
Anscheinend ist es so wenn die CCU regelmäßig etwas an IP-Symcon schickt funktioniert das auch mit der Reaktion auf einen Tastendruck. Wenn die CCU eine Zeit lang nichts an IP-Symcon schickt scheint diese irgendwie zu „schlafen“ was zu der Verzögerung führt. Hier hilft dann teilweise ein zurücksetzen des Homematic Sockets in IP-Symcon. Der Watchdog (s.o.) macht nichts anderes als von der CCU an IP-Symcon jede Minute eine kurzen Tastendruck zu schicken um die CCU beschäftigt zu halten. Sollte IP-Symcon nicht innerhalb von 2 Minuten erneut einen Tastendruck registrieren wird der Homematic Socket zurückgesetzt. Ist zwar nur ein Workarround aber es scheint zumindest eine Lösung zu sein.
So CCU2 Watchdog fast 6 Tage im Einsatz, möchte hier kurz berichten.
Leider hat sich das Problem nicht verbessert. Am ersten Tag waren die Meldung quasi in Echtzeit da, sprich Türöffner hat sofort funktioniert, aber je mehr Tage vergingen desto öfters mussten wir warten. Ich kann auch keine Regelmäßigkeit erkennen. Ich habe in IPS schon massivst die regelm. Ereignisse runtergefahren, ich erkenne aber nach wie vor keinen Zusammenhang, mal geht es schnell, mal dauert es ewig…Ich weiß nur unter 3.4 war das nicht der Fall. Will aber nicht behaupten, dass es an IPS liegt…
Habe noch die Hoffnung dass es irgendwann unter 4.1 oder mit einem CCU2 Update später gelöst wird.
Ich fahre in der Zwischenzeit einmal nachts iPS herunter und dann wieder hoch, da tritt das Phenomen seltener auf, aber trotzdem ist es noch da. Arbeite bereits mit der 4.1.
Bin seit vielen Jahren zufriedener Kunde und Fan von iPS aber das Thema stört mich massiv.
Ich kann nur sagen, das ich nicht glaube, das es an ips liegt, weil ich auch viel homematic habe und das auch ganz normal über ips angebunden habe, aber eben nicht über ccu sondern über homegear. Die Logik in der ccu braucht man ja nicht mehr. Und diese Kombi ist auf x86 Linux unschlagbar stabil, läuft beides auf einem System. Keine reboots über Monate. Bevor sich da jemand abplagt wäre es echt mal einen Versuch wert.
ich hatte seit einiger Zeit alle 2 min und später auch mal alle 5 min einen Ping von der CCU2 auf den IPS Server geschickt. Hatte damit keinen Effekt. Habe dann seit ein paar Tagen das auf 1 x pro Minute verkürzt, das scheint was zu bringen. Die Frage die sich jetzt stellt, betrifft das nur die Reaktion auf einen Tastendruck oder ist das allgemein eine Verzögerung, die Sensoren wie die Wetterstation oder Temp. Feuchte Sensoren genauso betrifft ? Werden deren Daten auch verzögert übermittelt und warum ist es bei 220V Aktoren nicht der Fall ?! Ich habe auch noch eine CCU1 und kann nicht feststellen, daß es hier zu Verzögerungen kommt, wobei ich da nur einen einzigen batteriebetriebenen Taster angeschlossen habe
Ich habe nun 6 Tage lang zwei Aktoren an meine alte CCU1 eingebunden diese in IPS zusätzlich eingebunden um damit mein Codeschloss für die Haustür zu bedienen.
Eingebunden ist ein HM Tür/Fensterkontakt und ein Hutschienenaktor.
Das Codeschloss gibt über den potentialfreien Ausgang die Info an den TK (Reedkontakt wurde deaktiviert). Der TK wird in IP Symcon ausgewertet und dann wird die Entscheidung getroffen ob die Tür per eingebauter Verriegelung geöffnet wird (Relais) oder per NUKI. Beides wird aus IPS angesteuert.
Vorab, es geht rasend schnell, kaum ist der Code eingegeben, das Licht des Codeschlosses ist grün, schon öffnet sich die Tür, in den ganzen Tagen war kein Delay von mehr als 2 Sekunden zu verzeichnen.
Ich behaupte damit, dass es nicht an IP-Symcon liegt, sondern an einem Kommunikationsproblem zwischen CCU2 und IP-Symcon.
Wünschen würde ich mir, dass sich die Symcon Entwicklung mit den Kollegen von EQ3 in Verbindung setzen um das Problem einzugrenzen. Diese nicht reproduzierbaren Verzögerungen in IPS nerven schon, ich hab das auch schon an anderen Aktoren beobachtet.
), würde es aber erstmal gerne mit dem Syslog Server oder Ping versuchen, kann mir jemand einen Hinweis geben wie ich das auf der CCU2 zum Laufen bekomme?