Freut mich, wenn es hilft.
Mit ner Meldung wirst Du doch nur wieder erinnert … 
, ist aber ansonsten eine Zeile mehr, je nach Meldung die Du möchtest.
Hallo Powerfreddy!
Meldung im Webfront dann sehe ich auf meinem Tablet ob zu Hause die Heizung spinnt, oder oder…
(IPS Homematic Läuft immer noch mit Zwangsbelebung)
Schönen Gruß:)
Egon
Ich verfolge das Thema nebenbei und für mich sieht es nach einen Fehler der CCU2 Firmware aus.
Hier das Wort zum Sonntag
-
Es gab zur 3.1 keine Änderungen an HomeMatic Modulen. (Ausnahme: Die Umbenennung der Auswahl in der HomeMatic Socket I/O Instanz-Konfiguration. Die hat aber nichts mit den Modulen zu tun.)
-
Da sich nichts geändert hat, bezweifle ich stark daran, dass IP-Symcon hier schuld ist. Zumal es mit CCU1 oder BidCos Service ja prima geht.
-
Durch ein IPS_ApplyChanges registriert sich IP-Symcon an der CCU neu, wodurch sich das Problem ja zu minimieren scheint. Ein Lösung ist das definitiv nicht. Ihr reduziert nur die Schwelle, in der ihr den Fehler merkt. Wenn der Abbruch aber schon nach 5 Minuten passiert, und dann euer Rauchmelder los geht, habt ihr nix gewonnen.
paresy
Dann eine Antwort zum Sonntag 
zu 1.) Könnte ja grundsätzlich auch ein Fehler sein, der schon länger existiert, der aber bisher nicht auffiel.
zu 2.) Wie könnte man das untersuchen bzw. kann man das überhaupt untersuchen? Befehle aus IPS an die CCU funktionieren, auch wenn der umgekehrte Weg (Auslösung über CCU) nicht geht. Scheint also irgendwas abzuschalten oder wegzufallen, was durch IPS_ApplyChanges wiederbelebt wird. Die Schnittstelle bleibt ja auch offen und meldet keinen Fehler.
Leider kenne ich mich zu wenig aus um das zu analysieren.
zu 3.) Sicherlich ist das keine Lösung, wie schon geschrieben, aber welche Möglichkeit gibt es sonst? Gut der Rückschritt auf die 2.5.4, wer es mag, ok. Wenn die Abbrüche häufiger auftreten vielleicht auch sinnvoller. Da bei meiner CCU die Abbrüche jetzt selten sind ist das nur zur Überbrückung bis ne neue (vielleicht bessere) Firmware rauskommt. Das mit dem Rauchmelder kann natürlich passieren, es gibt aber auch andere „möglicherweise“ eintretende Ereignisse, die eine Warnung verhindern … Bleibt also die Entscheidung jeden Einzelnen was er nach gründlicher Überlegung tut.
Die Doku kennst Du ?
Gruß
Bruno
Danke! 
Völlig abgesehen von den anderen „lustigen“ Fehlern der Version 2.7.8 … ich stelle mir ernsthaft die Frage ob sich CCU-seitig etwas genereller Natur geändert hat (z.B. Timing-Verhalten der Schnittstelle auf der Kiste …).
Da, wie schon erwähnt, alle Versionen seit der 2.5.4 (ich kenne durch Zufall deren 5!) das gleiche „ich-telefoniere-nach-kurzer-Zeit-nicht-mehr-nach-draußen-Verhalten“ zeigen, könnte das ja durchaus „Absicht“ sein
Wir werden es wohl erst mit der nächsten Version erfahren …
Ip-Symcon muß ja nicht unbedingt schuld sein - aber EQ3 wird sich ja kaum um Probleme seiner Produkte mit Fremdsoftware kümmern - die kümmern sich ja so wie es manchmal scheint, nicht mal ordentlich um die Probleme Ihrer Produkte
Da das Problem mit der 2.5.4 der CCU2 schon - wenn auch in geringerer Häufigkeit - bestanden hat, wird denke ich nichts anderes übrigbleiben, als IP-Symcon vernünftig an die CCU2 anzupassen ( nach Möglichkeit ohne erforderliche Workarounds von Usern ) - jedenfalls ist die CCU2 in dieser Konstellation nicht unbedingt mit dem IP-Symcon kompatibel.
Bei mir ist es seit einmal innerhalb der letzten 2 Tage vorgekommen, daß der Status eines Fensterkontaktes nicht richtig gemeldet wurde - aber dieses Mal hat die CCU2 selbst das Schließen des Fensters nicht mitbekommen ( bei der 2.5.4 ).
Sieht also so aus, als muß da EQ3 noch einiges an Hausaufgaben erledigen.
Bin am überlegen ob ich die CCU2 wieder zurückschicke und mir wieder eine alte CCU1 besorge.
Dank der Info aus dem Forum bin ich auf 2.5.4 zurückgeschwenkt. Seitdem laufen alle meine RTRs und Stellantrieb, sowie etliche Aktoren und Sensoren klaglos. Es bleibt bei einem Reichweitenproblem. Die Reichweite hat sich nicht verbessert, sondern verschlechtert. Wie kann man auch als Entwickler so blöd sein die Antenne wieder nach innen zu verlagern.
Schon bei der CCU1 bin ich bei einem Firmware-Wechsel (wegen der neuen wired-Module) fast an der Untätigkeit der CCU verzweifelt. Dann auf ein neues Release gewartet und gut wars.
Die Lübecker machen einen guten Job, letztlich muß eq-3, die Bastler aus Leer, per Technikfolgeabschätzung überlegen, was sie treiben, das scheint aber nicht der Fall zu sein.
Gruß
Bernd Aschendorf
Hallo Bernd!
Auch mit der 2.5.4 bleibt der Kram machmal hängen…(bei mir)
Die Lösung: CCU2 geht zurück.
LAN Adapter wieder in Betrieb = alles läuft.
(EQ3 bringts nicht hin, IPS-Macher liest am Rande mit)
Wann solls da was werden?
Schönen Gruß:)
Egon
Also ich finde den Part Technikfolgeabschätzung machen sie vorbildlich. Sie beobachten einen klaren Trend zur mehr Komfort im Haus und bedienen diesen Markt mit ständig neuen Marken, Modellen, Versprechungen. Dazu geben Sie keinerlei Garantie auf Ihre Geräte (hab jedenfalls noch keine gesehen). Das ist schon fast perfekt. Nachhaltigkeit ist uns egal, der Trend geht zu fire and forget.
Mittlerweile wird Firmen sogar China zu teuer und sie gehen nach Vietnam. (siehe Samsung)
Ich hatte mich mal mit einer Auffälligkeit (kein Hardwareproblem) bei HomeMatic an den Hersteller gewandt:
- Anfrage an eQ3 - Antwort: Bitte an den Händler wenden
- Anfrage an ELV - Antwort: Wurde das Teil bei uns gekauft
Äh… Was wird der Verkäufer wohl antworten. Schicken Sie es nach Leer?
Eigentlich müßte das Zeug mit folgendem Warnhinweis als Spielzeug vermarkten werden:
„Bitte beschäftigen Sie sich mit unseren Produkten nur, wenn Sie keine Herz- oder Kreislaufprobleme haben und Ihre Ehe gefestigt ist.“
Scheinbar habe ich gerade Glück, denn bei mir ist 2.5.4 stabil. Wäre auch blöd, denn ich habe alle relevanten Geräte von CCU nach CCU2 manuell portiert. Nur für meine Z-Eisenbahn bleibe ich auf der CCU1. Mal sehen, was der erste Weihnachtstag bringt. Vielleicht trifft das Problem ja auch nur auf einige Geräte zu.
Den Kommentar von Boui braucht man nicht kommentieren, nur ergänzen, es war alles perfekt dargestellt.
Nur gehört da noch folgendes hin:
Bedienungsanleitungen sind zum kurzzeitigen Feuern geeignet, angesichts des Preises ist das Feuer aber nur kurz an.
Auf Calls reagiert man sowieso nicht ! Nein, stimmt nicht, immerhin erhält man eine Bestätigungsmail !
Wenn Antworten kommen, dann tatsächlich:
-ELV ist nicht zuständig, da nicht Hersteller
-eq-3 ist nicht zuständig, da Hersteller, aber nicht Vertreiber
-Händler müssen sich an eq-3 wenden, da waren echte Highlights bei FHZ2000, ich weiß näheres
Zur Herstellung in China kann man nicht viel sagen, die produzieren das, was man in Ostfriesland ausheckt. Man kann aber sicher sein, daß die Ostfriesen häufig genug nach China fliegen. Angeblich wollen wir ja niedrige Preise.
Das soll aber nicht heißen, daß man Geräte, die man vertreibt, nicht ausführlichst testet, auf Anwender hört und Updates untersucht. Das geschieht in Leer in etwa 100, oder sind es mehr, Büros.
Gruß
Bernd Aschendorf
Wird langsam wie bei Domian :rolleyes:
Leider konnte noch niemand die Frage beantworten, ob und wie man die Thematik untersuchen kann. Warum treten die Probleme nicht bei allen gleich auf? Warum hat r4m3u5 (und jetzt auch andere) das Verhalten schon bei früheren Versionen festgestellt. Warum hilft ein Applychanges?
Bisher nur Vermutungen, Schuldzuweisungen und „denke“ und „könnte“ und „ach, wenn der Blitz einschlägt“ …
Zusatzfrage: Treten die Abbrüche auch bei der Raspi-CCU auf?
Mir wurde bisher jede Mail an eq-3 beantwortet. Klar versucht man erst abzuwimmeln, wobei das bei klar erkennbaren Fehlern nicht passiert ist, nur bei vielleicht möglichen Anwenderfehlern, laut Gesetz ist ja auch der Händler der Ansprechpartner. Wenn das kam habe ich mich an den Händler gewandt, wenn von dort keine Hilfe kam (weil Hersteller …) wieder an eq-3. Schon ging es. Kam vielleicht nicht immer was ich hören wollte, aber überwiegend.
Es gibt auch bei handbetätigten Geräten Probleme mit der Mechanik, … diese haben sich halt jetzt verlagert. Die Thematik LAN-Adapter hatten wir ja auch hinreichend … mal abwarten wie lange dies eine „Lösung“ ist. Erinnere nur an die Update-Intervalle.
Oh, heute Nacht ist die Schnittstelle genau 1x reaktiviert worden (habe jetzt auch ne Meldung eingebaut), sonst läuft das Teil 
Meine Meinung zum Thema
Gruß
Bruno
Mea culpa … ich konnte dann doch nicht die Finger davon lassen und bevor der Fred hier zu einem Musical wird die gute Nachricht: ich habe seit ca. 24 Std. das erste Mal seit Erscheinen der 2.7.8 auf meinen beiden CCU2s einen stabilen Zustand was die Kommunikation mit IPS angeht!
Wer es ausprobieren mag einfach mal den Workaround in Form eines Registry-Keys auf der IPS-Maschine importieren mit anschließendem Neustart (Entfernen durch Löschen des Keys und Neustart … ich brauche nicht zu erwähnen was bei „Fehlbedienung“ der Registry u.U. passieren könnte …):
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"TcpTimedWaitDelay"=dword:0000001e
Wirklich final gelöst ist das Ganze damit nicht, da nur das eigentliche Problem umgangen bzw. eingedämmt wird. Ich habe aber eine ziemlich gute Vorstellung wo der Hund begraben liegt. Dazu wären dann die DEVs gefragt … sowohl eq-3 als auch IPS
Was tut der Eintrag nun? Einfach erklärt: die Zeit bis eine TCP-Verbindung wirklich entfernt wird (und damit belegte Resourcen wieder freigegeben werden), nachdem sie bereits geschlossen wurde, wird auf 30 Sek. verkürzt (= der Minimal-Wert / „default“ sind 4 min.). Das sind die Verbindungen die als „TIME_WAIT“ bzw. „WARTEND“ gekennzeichnet sind wenn man „netstat“ aufruft, u.a. bekannt als „halboffene Verbindungen“. Kein Voodoo, eigentlich ein sinnvolles Feature (für Masochisten :rolleyes:: HIER gibt´s Details zu den Zusammenhängen). Unter XP gab es mal ein Limit von maximal 10 halboffenen Verbindungen → ist ab Vista aufwärts aber nicht mehr der Fall.
Wenn man sich das mal ganz fix für IPS <> CCU als Anzahl mit ´ner billigen Batch anschauen will (3 Sek. Intervall):
@echo off
:start
cls
@echo ===
netstat -n -a | find /C "5544"
@echo ===
ping 127.0.0.1 -w 3000 > nul
goto start
Bei einer weiteren CCU einfach den Port in der „netstat“-Zeile anpassen.
Was passiert im Fehlerfall? Die halboffenen Verbindungen vermehren sich derart, dass einer der beiden Delinquenten seinen Betrieb einstellt. Offensichtlich die CCU2, Stichwort „XmlRpc transport error“ oder ähnliche FMs. Wo genau die Grenze liegt lässt sich schwer von außen feststellen. In ruhigem Fahrwasser sind es in meinem Setup bereits an die 100 pro CCU2. Wenn viel Verkehr ist (Bewegungsmelder, Stati aktualisieren, Statusanzeigen „befüllen“, etc.) nimmt das dann ganz andere Ausmaße an.
Warum passiert das? Soweit ich es mitlesen konnte versucht z.B. die CCU bei einer nicht erhaltenen oder falschen Antwort des Gegenübers noch 10x ob da nicht doch eine sinnvolle Rückmeldung zu bekommen ist. Ist das nicht der Fall wird sie zickig und hält einfach die Klappe (mit Recht! :D). Blöde ist, dass sich keiner zuständig fühlt die Verbindung regelkonform zu beenden. Somit bleibt das Röhrchen (halb)offen. Erst nach den o.g. 4 Minuten sagt dann Windows: „Schluß jetzt!“. Trotzdem muss ja munter weitergequasselt werden: neue Verbindung, neuer Source-Port … wie sich das bei einem 4-Minuten-Timeout und steigender Anzahl Geräten bzw. Meldungen verhält kann sich jeder ungefähr ausmalen …
Anm. d. Red.: welche Seite nun wirklich Schuld/der eigentliche Auslöser für diesen ganzen Mist ist will und kann ich nicht sagen … u.a. in Ermangelung an Wissen tiefer gehender System-Interna. Den Schuh zieh ich mir auch nicht an. Mein Instinkt sagt mir aber, dass auf beiden Seiten noch Raum für Verbesserung ist …
Frohes Fest!
>>> Fast vergessen: mit „TcpTimedWaitDelay“ auf 30 Sek. schwankt es im Normalbetrieb zwischen 5 und 25 halboffenen Verbindungen. Durchaus das, was ich hier als normal einstufen würde.
Das werd ich doch sofort mal testen wenns klappt bist du mein Held
Gesendet von meinem iPhone mit Tapatalk
Saubere Arbeit. Respekt für diese hartnäckige Suche am System.
Niiiiiiiiarrgh! Noch nicht ganz blitzeblank! Zumindest hat es mal EINEN Tag gehalten, was ja schon ~23 Std. länger ist als vorher :mad::mad::mad:
Dec 17 08:50:03 homematic-ccu2 user.err rfd: XmlRpc transport error
Konnte bisher nur feststellen, dass genau EINER der Wandthermostate in IPS nicht aktuell ist. Ich stelle mal fest, Umgehungslösungen umgehen halt nur …
Ich lass es mal laufen. Interessiert mich jetzt schon ob sich das wieder „einkreiselt“ …
So … nun ist es schon Sport …
Kurz nach dem „XmlRpc transport error“ stirbt dann der Rest auch langsam vor sich hin (von CCU2 -> IPS). Befehle von IPS zur CCU2/zu den Aktoren gehen noch durch. Nach manuellem rfd-Neustart funktioniert es dann wieder in beide Richtungen.
Lustige, neue (oder vorher nicht wahrgenommene) FMs beim rfd-Start im Log:
Dec 17 09:36:22 homematic-ccu2 user.info rfd: (KEQxxxxxxx) CCU2CommController::sendBidcosRequest(): Retrying to send request (coprocessor was busy). Retry number 1
Dec 17 09:36:25 homematic-ccu2 user.debug rfd: (KEQxxxxxxx) CCU2CommController::waitForCoProcessorResponse(): Timeout while waiting for response.
Man könnte jetzt zum WATCHDOG noch einen Neustart des rfd bei Auftreten des Transport-Errors hinzufügen … mir fehlt aktuell nur die Motivation …
Cheers
/Jens
Einen WTF-Moment hab ich noch!!!
- die 2. CCU2 hatte den Fehler Sekunden nach der 1.
- die Uhrzeit auf derjenigen welchen die als erstes verwirrt war stand auf genau einer Minute in der Zukunft (beide holen sich die Zeit per NTP im LAN)
So … vorerst … mal wieder … 2.5.4 … dann schnell zum Doc und ´ne Amnesie machen lassen!
Wenn r4m3u5’s Vermutungen richtig sind, kann vielleicht die Änderung der 3.1 #3205 Abhilfe schaffen. Probiert es einfach mal aus.
paresy
Bin neu hier und bin mir nicht sicher ob das passt. Aber hat jemand schon diesen Thread gelesen:
http://homematic-forum.de/forum/viewtopic.php?f=26&t=13381&start=10
„Zur Erhöhung der Stabilität und zur Vermeidung von Problemen werden XMLRPC-Clients von der CCU2 getrennt, wenn diese Anfragen zehnmal nicht richtig beantworten. …
… wenn Dir die CCU ein Request schickt (und das ist so ein Event bzw in multicall verpackte Events) dann wird auch eine Antwort erwartet. Auf einen einzelnen Event solltest Du mit einem leeren String antworten, auf mehrere im Multicall sollte ein Array der selben größe gefüllt mir leeren Strings zurückgegeben werden. …“
Gesendet von meinem iPad mit Tapatalk
Ein Licht geht auf im Jammertal
Selbst wenn das nicht die Lösung sein sollte, es funktioniert bis jetzt mal sehr gut (berichte, falls es sich ändert), freut es mich, daß die Sache konstruktiv angegangen wird. Danke r4m3u5 und paresy.
[FiesModusAn] Schade für die, die ihre CCU schon zurückgeschickt haben und jetzt wieder mit LAN-Adapter oder CCU1 … [FiesModusAus]
Gruß
Bruno