Also ich kann nix sagen es läuft eigentlich bestens bis auf wenn ich neue Akteure dazuhängen will er diese beim suchen nicht mehr findet die alten vorhandenen laufen prima
Brauche ich den Event server wenn ich die Homematic nur am netzwerk über einen router laufen lasse ?
Hab mein Problem gefunden es war die IP Adresse am Eventserver
lg
bim
Hallo Reinhard,
vielen Dank für den Tipp… Hatte ich doch nicht damit gerechnet, dass Windows Server 2008 Standardmäßig die Firewall aktiviert hat.
Habe sie Deaktiviert und keine Offensichtlichen Fehler mehr. Lediglich die Fehler im Logfile der CCU sind vorhanden. Soll aber ja lt. Paresy mit dem nächsten Update behoben sein.
Schönen rest Soontag noch.
//Sven
Guten Abend,
leider hilft das mit der Firewall nur halb. Einige Aktoren reagieren z.t. sehr starik verzögert zwischen 10 und 30 Sekunden. Leider lässt sich keine Regel ausmachen. Manchmal reagiert der selbe Aktor innerhalb einer Sekunde, dann dauerts wieder 10…
Muss nun also wieder downgraden :mad:
LG //Sven
Hallo Sven,
hast da TCPDump derinstalliert? Vielleicht liegt da eine Ursache.
Unter Telnet
cd /usr/local/etc/config/rc.d/
rm tcpdump
Grüße Reinhard
Hallo Reinhard,
vielen Dank für den Tipp. Habe ich gerade mal De-Installiert und die entsprechenden Daemons gekillt.
Mal sehen wie sich das System jetzt verhält. Zum Glück hatte ich Deinen Beitrag noch gelesen bevor ich mit dem Downgrade begonnen habe 
…ich werde Berichten.
//Sven
Btw: Hat schon mal jemand TOP auf der CCU zum laufen gebracht?
Hallo Sven,
hat das deinstallieren von TCPDump bei dir was gebracht?
Ich würde gerne auch wieder auf die aktuelle 
updaten…
Was TOP angeht bild ich mir ein das das mit einer älteren CCU-Firmware (4.xxx) noch ging.
Mit der 5.xxx gehts bei mir auch nicht mehr…
Hallo Chrisu,
es scheint so, dass es besser läuft. Einiges Schaltvorgänge brauchen aber immer noch 10 sekunden. Ich kann nicht wirklich festmachen wann das so ist.
Das fehlerprotokoll der CCU wird ja auch recht dichtgemüllt. Wenn ich recht gelesen habe ist das ein BUG, der die Funktion aber nicht beeinträchtigen soll. Ich gehe aber mal stark davon aus, dass es damit zusammenhängt. Eventuell hängt das ganze auch damit zusammen, das ich viele Aktoren an der CCU habe. Nun werde ich also erstmal wieder Downgraden… war bis jetzt aber zu faul. Muss erstmal herausfinden, welche Datei bei dem Upgrade ausgetauscht wurden um die dann aus der Sicherung wieder herzustellen.
//Sven
Hi,
danke für die Info.
Dann bleib ich vorläufig auf der 2.1er…
Vielleicht findet paresy ja noch was…
Ich habe nur Funkaktoren.
Nach Deaktivierung sämtlicher Firewalls funktioniert 2.3, jedoch kommt es immer wieder vor, dass es „hängt“ und nicht mehr geht.
Lässt man es dann eine Weile in Ruhe geht es wieder.
Die 2.2 hat bei mir stabiler funktioniert.
Was ich auch etwas seltsam finde ist, dass die Blcokierung einer Windows Firewall die CCU in die Knie zwingt.
Wie geht das denn?
Das fehlerprotokoll der CCU wird ja auch recht dichtgemüllt
In wie fern? In der aktuellen 2.3er Version sollte das nicht mehr passieren.
Was ich auch etwas seltsam finde ist, dass die Blcokierung einer Windows Firewall die CCU in die Knie zwingt.
Die CCU verschickt die „Events“ über einen Rückkanel, der HTTP Requests macht. Wenn eure Firewall diese „blockiert“, kann es auch die CCU blockieren.
paresy
Hallo Mic,
ich Denke nicht, dass es an der Firewall liegt. Ich habe an beiden Geräten (CCU und Windows Server2008) die Firewall komplett Deaktiviert. Trotzdem ist es so, dass die CCU zum ausführen von Befehlen (auch CCU interne) bis zu 60 sekunden benötigt. Ich habe IPS zunächst mal abgeklemmt und nutze es gar nicht :mad:
Das letzte was ich versucht hatte war, lediglich die IPS.EXE und IPS_CONSOLE.EXE aus der 2.2 in das aktuelle IPS Verzeichnis zu kopieren (den Rest habe ich auf 2.3 gelassen). Auf der CCU habe ich dann noch TCPDUMP gelöscht. Was dann folge war der Horror… nach neustart der CCU hatte ich sage und schreibe 50! i.W. fünfzig Fehler! Alle Geräte die per Funk laufen (bis auf die Heizungsregler und Rauchmelder). Hatten angeblich „Daten zur Übertragung“. Das wäre ja gar nicht mal schlimm… aber wenn ich den Knopf am Sender gedrückt habe hat sich rein gar nichts getan. das letzte Backup war natürlich vom November letzten Jahres (CCU Sicherung dauert bei mit ca. 30 minuten). Also erstmal gesichert und das alte Backup zurückgespielt. Alles Funktioniert - IPS hatte ich zwischenzeitlich gestoppt und komplett auf die 2.2 zurück Kopiert. Das Problem war nur, dass zwischenzeitlich neue Funk-Komponenten hinzugekommen waren und weil ich es damals nicht besser wusste ist natürlich ein Systemschlüssel in der CCU. Es half also nicht, das „frische“ Backup musste wieder rein. Nach 2-3 Stunden herumprobieren hatte ich dann einen Weg. Jede der 50 Komponenten musste abgelernt (incl. in den Werkszustand zurücksetzen), dann das Gerät Resetten (4 sek. drücke und dann nochmal 4 sek. drücken), und wieder neu anlernen. Das ganze hat dann so gute 8 Stunden gedauert… schöner Sonntag… Die CCU internen Programme mussten dann natürlich aufgrund der „neuen“ Geräte auch noch angepasst werden… ja… das übt 
Ich habe erhrlich gesagt keinen Plan wie das Passieren konnte, ob es einen Zusamenhang mit IPS gibt. Nur - seit dem sichere ich die CCU Regelmäßig, auch wenn das ´ne halbe Stunde dauert. Aber bekanntlich wird man ja aus Schaden Klug.
Ach ja… 5 Außen-Bewegungsmelder fehlen noch. Sie funktionieren zwar, aber sie stehen als Fehlerhaft, weil Daten zur Übertragung anstehen. Die muss ich noch abschrauben und neu anlernen 
Vielleicht hat einer von euch ja Ähnliche Erfahrung gemacht und kann diesbezüglich mal Feedback geben.
Liebe Grüße aus Flensburg
//Sven
Ist es wirklich klug eine Mischform 2.2 und 2.3 laufen zu lassen?
Geht es bei dir denn jetzt?
Wie gesagt bei mir sind alle Firewalls auch aus.
@Paresy
Aber warum sollte die CCU denn etwas schicken wollen, wenn sie nicht dazu aufgefordert werden kann, weil die Firewall dicht macht (in beide Richtungen)?
Irgendwie überlastet IPS die CCU, warum auch immer.
Können wir das irgendwie eingrenzen?
Mic
Gerade wieder.
Im Hometic Log steht hierzu nur das:
Sep 6 11:30:01 (none) cron.notice crond[973]: USER root pid 2078 cmd /bin/arm7setclock
Sep 6 11:32:13 (none) user.err rfd: HSSParameter::SetValue() true Put failed
Sep 6 11:41:00 (none) syslog.info – MARK –
Und im IPS Log steht das:
06.09.2010 11:30:40.656 | 0 | DEBUG | ExecuteThreadID #8 | Ausgeführt, Resultat: 1, Erfolgreich: True, Zeit: 20052 ms
06.09.2010 11:30:40.689 | 0 | DEBUG | ExecuteThreadID #8 | Skriptausführung: ips.php ~ Absender: WebInterface
06.09.2010 11:31:00.729 | 0 | DEBUG | ExecuteThreadID #8 | Ausgeführt, Resultat: 1, Erfolgreich: True, Zeit: 20040 ms
06.09.2010 11:31:00.783 | 0 | DEBUG | ExecuteThreadID #3 | Skriptausführung: ips.php ~ Absender: WebInterface
06.09.2010 11:31:20.829 | 0 | DEBUG | ExecuteThreadID #3 | Ausgeführt, Resultat: 1, Erfolgreich: True, Zeit: 20045 ms
06.09.2010 11:31:20.893 | 0 | DEBUG | ExecuteThreadID #2 | Skriptausführung: ips.php ~ Absender: WebInterface
06.09.2010 11:31:40.947 | 0 | DEBUG | ExecuteThreadID #2 | Ausgeführt, Resultat: 1, Erfolgreich: True, Zeit: 20054 ms
06.09.2010 11:31:41.03 | 0 | DEBUG | ExecuteThreadID #5 | Skriptausführung: ips.php ~ Absender: WebInterface
06.09.2010 11:32:01.53 | 0 | DEBUG | ExecuteThreadID #5 | Ausgeführt, Resultat: 1, Erfolgreich: True, Zeit: 20049 ms
06.09.2010 11:32:01.113 | 0 | DEBUG | ExecuteThreadID #5 | Skriptausführung: ips.php ~ Absender: WebInterface
06.09.2010 11:32:21.159 | 0 | DEBUG | ExecuteThreadID #5 | Ausgeführt, Resultat: 1, Erfolgreich: True, Zeit: 20046 ms
06.09.2010 11:32:21.221 | 0 | DEBUG | ExecuteThreadID #2 | Skriptausführung: ips.php ~ Absender: WebInterface
06.09.2010 11:32:41.261 | 0 | DEBUG | ExecuteThreadID #2 | Ausgeführt, Resultat: 1, Erfolgreich: True, Zeit: 20040 ms
06.09.2010 11:32:41.333 | 0 | DEBUG | ExecuteThreadID #3 | Skriptausführung: ips.php ~ Absender: WebInterface
06.09.2010 11:32:50.49 | 0 | DEBUG | ExecuteThreadID #8 | Skriptausführung: ips.php ~ Absender: WebInterface
06.09.2010 11:32:51.15 | 0 | DEBUG | ExecuteThreadID #8 | Ausgeführt, Resultat: 0, Erfolgreich: False, Zeit: 966 ms
06.09.2010 11:33:01.383 | 0 | DEBUG | ExecuteThreadID #3 | Ausgeführt, Resultat: 1, Erfolgreich: True, Zeit: 20050 ms
06.09.2010 11:33:01.443 | 0 | DEBUG | ExecuteThreadID #8 | Skriptausführung: ips.php ~ Absender: WebInterface
06.09.2010 11:33:21.489 | 0 | DEBUG | ExecuteThreadID #8 | Ausgeführt, Resultat: 1, Erfolgreich: True, Zeit: 20045 ms
06.09.2010 11:33:21.555 | 0 | DEBUG | ExecuteThreadID #8 | Skriptausführung: ips.php ~ Absender: WebInterface
Ich habe, wohlgemerkt nur einmal geklickt.
Von diesen Einträgen gibt es noch eine Menge, wohlgemerkt habe ich im Webinterface nichts gemacht, als nur einmal zu klicken und das auch erst eine halbe Stunde später.
06.09.2010 11:02:07.557 | 0 | DEBUG | ExecuteThreadID #5 | Ausgeführt, Resultat: 1, Erfolgreich: True, Zeit: 20060 ms
Das ganze fängt hiermit an:
06.09.2010 10:55:04.158 | 0 | DEBUG | ExecuteThreadID #2 | Skriptausführung: ips.php ~ Absender: WebInterface
06.09.2010 10:55:04.219 | 0 | DEBUG | ExecuteThreadID #2 | Ausgeführt, Resultat: 1, Erfolgreich: True, Zeit: 61 ms
06.09.2010 10:55:04.755 | 0 | DEBUG | ExecuteThreadID #2 | Skriptausführung: ips.php ~ Absender: WebInterface
06.09.2010 10:55:04.765 | 0 | DEBUG | ExecuteThreadID #7 | Skriptausführung: ips.php ~ Absender: WebInterface
06.09.2010 10:55:04.767 | 0 | DEBUG | ExecuteThreadID #10 | Skriptausführung: ips.php ~ Absender: WebInterface
06.09.2010 10:55:04.773 | 0 | DEBUG | ExecuteThreadID #1 | Skriptausführung: ips.php ~ Absender: WebInterface
06.09.2010 10:55:04.778 | 0 | DEBUG | ExecuteThreadID #8 | Skriptausführung: ips.php ~ Absender: WebInterface
06.09.2010 10:55:04.926 | 0 | DEBUG | ExecuteThreadID #2 | Ausgeführt, Resultat: 1, Erfolgreich: True, Zeit: 170 ms
06.09.2010 10:55:04.970 | 0 | DEBUG | ExecuteThreadID #8 | Ausgeführt, Resultat: 1, Erfolgreich: True, Zeit: 192 ms
06.09.2010 10:55:04.994 | 0 | DEBUG | ExecuteThreadID #7 | Ausgeführt, Resultat: 1, Erfolgreich: True, Zeit: 229 ms
06.09.2010 10:55:04.999 | 0 | DEBUG | ExecuteThreadID #10 | Ausgeführt, Resultat: 1, Erfolgreich: True, Zeit: 231 ms
06.09.2010 10:55:05.695 | 0 | DEBUG | ExecuteThreadID #7 | Skriptausführung: icon.php ~ Absender: WebInterface
06.09.2010 10:55:05.858 | 0 | DEBUG | ExecuteThreadID #7 | Ausgeführt, Resultat: 1, Erfolgreich: True, Zeit: 162 ms
Vorher war nichts dergleichen.
Hallo,
Geht es bei dir denn jetzt?
Nein, wie oben geschrieben läuft IPS derzeit nicht. Ich hatte es mit der 2.3 laufen, aber dann reagiert die CCU teilweise erst nach 30-60 sekunden!
Ich setzte noch eine IPhone-App von ´nem Drittanbieter ein, die funktioniert gar nicht wenn IPS 2.3 läuft. Gestern Abend stand ich in ´nem Dunklen haus und die Lichter gingen erst nach ´ner Minute an. Ab da hab ich IPS erstmal komplett abgeklemmt und die CCU neu gestartet. Jetzt gehen zumindest die wichtigsten Funktionen (die laufen zum Glück noch ohne IPS).
//Sven
Hallo,
ich möchte auch mal kurz was dazu schreiben. Ich hatte bis jetzt noch nie Probleme mit meiner CCU und IPS gehabt. Vor einer Woche hatte ich mir diese Skript;
Skript Seite
In mein IPS kopiert um per Webfront immer die Service Meldungen zu sehen.
Nach ca. 2 Tagen hatte ich zuerst Probleme mit IPS bekommen (Threads waren keine mehr frei) und später reagierten die Wired sowie Funk Module nicht mehr.
Dachte nur, dass es ein Ausrutscher war deswegen hab ich den Dienst neu gestartet und wieder getestet. Nach 1 - 2 Tagen wieder das gleiche Problem.
Jetzt hab ich testweise das Skript deaktiviert und bin schon im 3 Tag ohne Fehler. Warte jetzt noch bis morgen ab und wenn dann nichts passiert ist probier ich es wieder mit dem Skript.
Habt ihr eventuell auch das Skript laufen ?
Gruß
Nein ich lasse überhaupt keine regelmäßigen Skripte laufen.
Nachtrag von oben:
Alleine das öffnen uns „stehenlassen“ des Webfrontends bewirkt regelmäßige Log-Einträge:
06.09.2010 15:44:18.959 | 0 | DEBUG | ExecuteThreadID #10 | Ausgeführt, Resultat: 1, Erfolgreich: True, Zeit: 20038 ms
Was dauert hier 20s?
Ich habe zwei Rechner, auf denen IPS läuft und auf eine CCU zugreifen.
Kann das das Problem verursachen?
Ich habe das gleiche Problem. Win7 64Bit, aktuelle CCU Firmware. Ich muss die Firewall komplett ausschalten damit die CCU reagiert und Befehle von IPS annimmt. Weiterhin habe ich (wenn die Firewall aus ist) eine kurze Verzögerung bis der Befehl (z.B. Licht) ausgeführt wird. Das war unter 2.1 (hatte ich vorher installiert) nicht. Wenn ich diese Version zurück spiele geht alles wieder wie vorher ohne Probleme.
Tom
Hallo zusammen,
das ist mein erstes Posting hier :).
Bei mir läuft IPS seit Mai in einer relativ großen Homematic-Installation (125 Geräte / davon 90 wired).
Ich habe dabei die ganze Zeit die letzte Betaversion genutzt, da diese ja schon ohne TCPDump funktionierte.
Vor ca. zwei Wochen habe ich auf die Version 2.3 umgestellt und seitdem habe ich auch die hier schon beschriebenen Verzögerungen. Dies betrifft alle Vorgänge, in welche die CCU irgendwie involviert ist. Dabei ist es unerheblich, ob diese von IPS ausgelöst werden oder nicht. So dauert z.B. das Einschalten einer Lampe über eine Fernbedienung und Verarbeitung über ein CCU-Skript zwischen 1 - 30 Sekunden.
Nach einigem experimentieren, ist mir heute etwas im Debug-Modus des Homematic-Socket aufgefallen. Dort wird minütlich ein „Init“ transmitted, welches wahrscheinlich verschiedenen XML-RPC-Events auslöst (siehe Screenshot). Ein Event (newDevices) folgt in der Debug-Ausgabe immer erst nach 20 - 30 Sekunden. Versuche ich in dieser Zeit einen Schaltvorgang über meine Fernbedienung, wird dieser entsprechend verzögert. Außerhalb dieser Zeit funktioniert es (relativ) schnell.
Ich denke, die CCU ist mit diesem Init-Befehl beschäftigt und braucht deshalb solange für die Abarbeitung anderer Vorgänge.
Kann mir nun jemand sagen, weshalb dies minütlich ausgelöst wird? Ist dies so beabsichtigt?
MSC
