Das deutet eher auf anders geartete Probleme hin. Dauersender, Störsender, generell schlechte Empfangswerte, etc.
HM_RequestStatusist definitiv nicht das Allheilmittel und mit Vorsicht zu genießen, denn es ruft eben nicht nur gespeicherte Werte aus der CCU ab. Je nach Anzahl/Art der Geräte belastet das den Funkverkehr erheblich, also für „Dauerbetrieb“ absolut ungeeignet.
Ich setze es z.B. nur gezielt beim Start des IPS Dienstes ein um eine initiale Synchronisierung sicherzustellen.
Also Störsender können wir ausschließen. Das Phänomen war auch erst aufgetreten wie ich auf
die Version 4.0 upgedatet habe. Merkwürdigerweise auch nicht reproduzierbar. Ich habe gestern mal alles neu gestartet incl. Router und siehe da, jetzt läuft es z.Z. sehr flott, mal sehen wie lang
HM_RequestStatus wollte ich genau für diesen Zweck: Neustart und Einlesen des Status Quo verwenden, hab aber nach wie vor das Problem, daß ich nicht weiß wie ich jetzt die GUID von meinen beiden CCUs bekomme ?!
Aber unabhänhig davon kann man mit einem HM_RequestStatus auf einen Bewegungsmelder den MOTION Wert, der in der CCU gespeichert ist, von IPS abfragen ohne Funkverkehr zu erzeugen, da das ein batteriebetriebener Sender ist. Ich hab nämlich das komische Phänomen seit dem Update, daß der Bewegungsmelder brav seinen Zustand an die CCU2 sendet, die gibt aber nur den Helligkeitswert an IPS weiter und behält den MOTION Status für sich
Bei mir bringt das Dummy Prog. nichts. die Übermittlung dauert immernoch so lange.
Das kuriose ist das es auf meiner Pi Installation ca 12 Wochen problemlos ging.
Naja ich werde mal versuchen wieder auf den Lan Adapter zu wechseln. Mal sehen ob es was ändert.
ich habe seit einigen Wochen genau das gleiche Problem:
Scripte welche per Homematic Sender in IP-Symcon gestartet werden sind teils mehrere Sekunden verzögert.
Direktverknüpfungen vom selben Sender funktionieren dagegen sofort.
Beim Vergleich der jeweiligen Zeiten fällt auf das die CCU2 den Tastendruck sofort registriert - das Signal aber eben erst bis zu 15 sec. verzögert bei IP-Symcon ankommt.
Bin echt verzweifelt.
Habe die CCU2 schon mal getauscht gegen eine neue - hat nichts gebracht.
Den Server neu aufgesetzt und IP-Symcon neu installiert - hat nichts gebracht.
Die Netzwerkverbindung ist per kurzem Lankabel über einen Switch.
Interessant ist dass ich Programme über das Webfront von IP-Symcon starten kann - diese werden sofort und ohne Verzögerung ausgeführt.
Auch wenn ich einen Tastendruck in der CCU2 simuliere wird das Programm sofort ausgeführt. Das Problem tritt nur in Verbindung mit verschiedenen Funksendern auf. Irgendwie scheint die CCU2 da zu spinnen…
Vor ein paar Wochen noch ging alles ohne Probleme…
@ipsneuling
Falls das mit dem LanAdapter erfolgreich war lass es mich doch bitte wissen - dann verkaufe ich die CCU2 und steige auf diesen um…
Vielen lieben Dank schon im Voraus für Ideen was noch falsch sein könne!!
Ich bin leider zwecks Zeitmangel noch nicht zum wechseln gekommen.
Ich bin mir eigentlich ziemlich sicher das es an der Verbindung CCU2 zu PC liegt. Vllt liegt es am Betriebssystem…keine Ahnung.
Wie ich meine Installation auf dem Pi hatte funktionierte das mit der CCU2 ohne Probleme.
Ich sag bescheid sobald ich dazu gekommen bin.
Ich muß mich seit IPS V4 leider auch zum Kreis der Betroffenen Zählen… :rolleyes:
Zum Szenario oder was bisher geschah:
IPS4 Windows, heute Update eingespielt 8d4d59d793d1. Vorherige Versionen seit 2.7. ebenfalls betroffen. Bewertung früherer Versionen nicht möglich da Update auf V4 erst an diesem Datum vorgenommen.
IPS4 SymBox, heute Update eingespielt 8d4d59d793d1. Nicht produktiv - nur zu Testzwecken am Start.
CCU2 orginal mit Firmware 2.19.9.
LXCCU mit Firmware 2.15.7.
YAHM mit Firmware 2.19.9.
CCU2-Derivate (nicht alle gleichzeitig :)) hängen am selben Switch wie der IPS Rechner und die SymBox.
Funkstörungen sind auszuschliessen da die CCU2 den Knopfdruck des 6-fach Wandtasters immer 1-2 Sekunden später in der WebGUI anzeigt. Die Verzögerung ist meiner Ansicht nach der WebGUI geschuldet und nicht dem verspäteten eintreffen des Tastendruckes. BTW: Ich will es auch nicht an diesem speziellen Taster-Typ festmachen - es sind auch andere Sender betroffen.
Das Windows IPS läuft auf einem Xeon E3-1245 mit 32GB RAM und einer Auslastung von 3-25%. Ernsthaft ausgelastet ist die Maschine daher nicht.
Ich habe es mit und ohne DUMMY-Programm probiert. Im Ergebnis gab es keine Unterschiede.
Unterschiede gibt es aber sehr wohl zwischen SymBox und Windows IPS. Die Windows Maschine reagiert durchweg deutlich langsamer als die Symbox oder sie reagiert gar nicht. Es geht also (bei mir) nicht nur um eine Verzögerung sondern durchaus um totalen Verlust der Schaltsignale.
Anbei zwei Screenshots bezüglich des Zustandsverlaufs ein und desselben Datenpunktes - einmal link auf der Symbox und einmal rechts auf dem Windows IPS. Beide Systeme haben parallel Kontakt zu ein- und derselben logischen CCU2. Der Parallelbetrieb war nur ein Test um der Sache auf den Grund zu gehen - im Normalbetrieb hat nur das Windows IPS einen Kanal zur CCU2 geöffnet.
Da die Symbox die Schaltsignale von der CCU2 sauber bekommt kann man wohl ausschliessen, dass diese die Events nicht an IPS weiter gibt. Anhand der Timestamps sieht man, daß das Windows IPS da offensichtlich ein Problem hat. Es reagiert deutlich später oder gar nicht.
Ich weiss nicht ob es an IPS V4 liegt oder an etwas anderem auf dem Windows Server aber mit 3.4 kannte ich diese Probleme nicht. Am Windows Server (2008 R2) hatte ich nichts geändert - ich war voll und ganz mit der Umstellung auf V4 beschäftigt. Lediglich Treiberupdates für meine Portserver (Silex, Perle) hatte ich vorgenommen weil es nach dem Update Probleme mit deren virtuellen COM-Ports gab. Firewall und Virenschutz hatte ich auch an- bzw. abgeschaltet.
ich habe das Problem auch manchmal auf der Symbox.
Nicht wirklich oft aber bei einem Taster der ca. 5 mal täglich verwendet wird habe ich 3-5 mal/Monat eine Verzögerung von ca. 10-15 sec.
Wenn man die CCU2 kurz von Netz trennt kommen die Befehle für einen gewissen Zeitraum unverzögert an.
Spätestens am nächsten Tag ist es dann aber auch wieder vorbei.
Am Wochenende werde ich auf den Lan Adapter wechseln.
Wenn man die CCU2 kurz von Netz trennt kommen die Befehle für einen gewissen Zeitraum unverzögert an.
Spätestens am nächsten Tag ist es dann aber auch wieder vorbei.
Ja, das ist mir auch schon oft aufgefallen.
Ich habe mir das nun mal genauer angeschaut. Zumindest bei mir verhält sich das so:
Wie schon beschrieben: In der Weboberfläche der CCU2 wird der Tastendruck sofort registriert. Nur scheint er erst verzögert an IPS übertragen oder registriert zu werden: In der Konsole von IPS wird er jedenfalls erst mit der schon erwähnten Zeitverzögerung angezeigt.
Ich habe daraufhin mit Wireshark den Traffic geloggt um festzustellen auf welcher Seite das Problem liegt: Ich habe dabei festgestellt das die CCU2 den entsprechenden Befehl („Taster gedrückt“) erst mit einer Verzögerung aussendet. Interessanterweise tut sie dies zusammen mit anderen Befehlen die Sie „sowieso“ gerade jetzt senden wollte (z.B. Temperatur-Updates von der Heizungssteuerung). Es wird dann alles einfach in einem XML-Befehl übermittelt.
Kurz nach einem Neustart der CCU2 geht der Befehl „Taste gedrückt“ dagegen sofort von der CCU2 raus (als einzelne XML Messsage).
-> Zumindest in meinem Fall kann ich daher ausschließen das es an IPS liegt! Es ist ein „Problem“ der CCU2
Ich habe mir die Logs der CCU2 genauer angeschaut. Hier gibt es dann tatsächlich die Verzögerung: Tastendruck wird registriert, das senden des XML erfolgt dann aber erst mit starker Verzögerung.
Interessant wurde es dann erst als ich einen externen Syslog-Server eingerichtet habe. Dies wollte ich tun damit ich etwas mehr Log-Daten habe. Sobald ich diesen Server (auf dem gleichen Server wie IPS) eingerichtet hatte und die IP in der CCU2 hinterlegt hatte (alles loggen) waren alle Probleme verschwunden - keinerlei Verzögerungen mehr. auch nach mehreren Tagen.
Offensichtlich möchte die CCU2, bzw. deren Netzwerk-Port permanent „beschäftigt“ werden damit sie (zumindest in Teilen) nicht „einschläft“.
Zum verifizieren habe ich den Sslog-Server wieder raus genommen und ein kleines Programm auf der CCU2 hinterlegt welches einfach nur einen Ping an den IPS-Server aussendet. Das Programm wird über die CCU2 alle 1 min aufgerufen - siehe da: Probleme sind auch damit behoben.
Dabei muss man noch nicht mal den IPS-Server anpingen: Testweise habe ich einfach nur einen Ping auf mein Gateway abgesetzt - das tut es genauso.
Fazit: Irgendwie scheint es ein sehr seltsames Problem mit der CCU2 zu geben. Richtig verstehen kann ich meine Lösung auch nicht - immerhin sendet die CCU2 ja eigentlich andauert messages an IPS - keine Ahnung warum da das Eintragen eines Syslog-Servers oder ein Ping hilft.
@ipsneuling: Falls du die CCU2 nicht schon ausgetauscht hast kannst du ja mal probieren ob das auch bei dir funktioniert.
Ich habe mir die Logs der CCU2 genauer angeschaut. Hier gibt es dann tatsächlich die Verzögerung: Tastendruck wird registriert, das senden des XML erfolgt dann aber erst mit starker Verzögerung.
Ich hatte zwei IPS-Systeme testweise parallel laufen mit gleichzeitiger Verbindung zu ein und der selben CCU. Wie ich geschrieben hatte treten die Verzögerungen auf den Systemen unterschiedlich auf. Das würde dafür sprechen, dass die Problematik eine andere ist und sich nur die Symptome gleichen.
Interessant wurde es dann erst als ich einen externen Syslog-Server eingerichtet habe.
Ich habe seit jeher einen Syslog Server laufen auf den die CCU Meldungen schickt. Trotz dieser „Beschäftigungstherapie“ tritt das Problem bei mir auf.
Das würde dafür sprechen, dass die Problematik eine andere ist und sich nur die Symptome gleichen.
Ja, das vermute ich auch. Ich hatte eher Symptome die mit denen von ipsneuling deckungsgleich schienen (nie einen Totalverlust, nur Verzögerungen, vor allem nach längerer Nichtnutzung, nach CCU Neustart behoben).
Kommen die Pakete den sauber auf der Windows-Maschine an (wenn du den Traffic auf dem entsprechenden Server mitloggst (Wireshark o.ä.)?
Mit Wireshark war ich noch nicht zugange. Schien mir auch nicht notwendig da ich ja zwei IPS-Systeme gleichzeitig parallel am Start hatte. Da das eine den Event immer bekommt und das andere den selben Event nur verzögert oder gar nicht wahr nimmt hatte ich an Wireshark keinen Gedanken verschwendet.
Die Symptome kamen bei mir unmittelbar mit dem Update auf die 4.0. Da war ich mit Modulen noch gar nicht zugange. Mit denen habe ich erst ein paar Tage später angefangen als die schlimmsten Update-Baustellen beseitigt waren. Jetzt habe ich z.B. HomeMaticExtendend installiert.
Aber die Frage ist berechtigt - die Symbox ist in der Hinsicht jungfräulich. Mit der 4.1 hatte sich die Lage aber entspannt. Ab und zu tritt es noch auf aber das System ist mittlerweile wieder WAF-tauglich.
Auch ich habe das Problem und zwar erst seit ich auf der 4.0 bin. Vorher hat das immer einwandfrei funktioniert. Ich habe die CCU2 im Einsatz. Mit der Last auf dem IPS Server kann es nichts zu tun haben, ich habe das Phänomen auch wenn der vor sich hin idled.
