ravenhall hat geschrieben:Aus meiner Sicht kann das schon sein. Und ich habe über dieses Problem schon einiges auf anderen Seiten gelesen, welche meine Beobachtungen bestätigten. Es scheint nicht unüblich zu sein, dass die optischen Sensoren so ein Problem haben. Natürlich ist der TFK ein reiner Sender. Die Frage ist, wie kann es sein, dass er sich, obwohl er nicht sendet, in einen vollen Duty Cycle hineinbewegt, aus dem er nicht mehr rauskommt?
Ob Du das anders siehst ist absolut egal... Wichtig ist nur das andere Anfänger Deine teilweise falschen Behauptungen und Ratschläge nicht aufschnappen und für wahr halten! Wenn beispielsweise die Batterien des TFK einen grenzwertigen Füllstand erreichen kommt es gerne mal vor das sie Fehlerhaft arbeiten.
Ich zitiere aus BA:
"Ist die Batterie so schwach, dass mehrere Male nach- einander ein Reset ausgelöst wurde, ohne dass da- zwischen erfolgreich gesendet wurde, wird bei den folgenden Fensterdetektionen nicht mehr gesendet, die LED zeigt dann nur noch für 0,5 Sekunden rot an."
Wenn Dein TFK sich selbst in den DC schießt liegt ein Defekt oder anderes Problem am Gerät vor das dafür sorgt das ständig irgendwas gesendet wir. Du sagst ja selbst das der DC nicht von selbst wieder fällt... Auch das spricht für einen technisches Problem am TFK.
Und wenn so ein TFK zum Dauersender mutiert ist es kein Wunder das die CCU durch ständiges antworten in den eigenen DC rennt wodurch wiederum andere Kommunikationsprobleme entstehen. Und das obwohl diese Geräte kein eigenes Problem haben.
ravenhall hat geschrieben:Die Geräte (ja es waren mehrere betroffen und ausschließlich TFKs) funktionierten vorher schon seit mehreren Monaten völlig normal. Es wurde auch kein Fenster/Tür geöffnet. Die TFKs der anderen Zimmer drum herum funktionierten ebenfalls normal. Damit kann man eine Funktstörung von außen ausschließen. Das einzige was geändert wurde, war das Programm, welches ich zugegebenermaßen völlig unbedarft einfach in der WebUI zusammengeklickt hatte (etwa so: Wenn TFK1 ein oder TFK2 ein oder ... TFKn ein, Dann setze Variable x auf wahr, Sonst setze Variable x auf falsch.).
Betroffen von was? Alle TFK rennen in den eigenen DC? Das wäre aber sehr unwahrscheinlich!! Oder haben alle nur Servicemeldungen verursacht? Bist Du Dir sicher das Du die Blinksignale richtig gedeutet hast?
Das klingt irgendwie danach das in diesem Raum eine Störquelle vorhanden war und die Sensoren ihre zyklischen Statusmeldungen nicht absetzen konnten. Da die CCU diese Meldungen aber stündlich erwartet wurde dann eine Servicemeldung generiert.
Etwas ähnliches auf einen Raum begrenztes Problem gab es vor einer Weile bei einem User auch schon. Bei ihm tauchten immer haufenweise Probleme in dem Raum auf sobald der PC eingeschaltet war.
Nochmal, ein Programm kann bei einem TFK KEINE Probleme verursachen!!! Ein Programm wie das genannte reagiert ausschließlich auf den vom TFK gemeldeten Status!! Einen TFK kann man nicht aktiv abfragen oder ansteuern. Der TFK weiß mit größter Sicherheit nicht mal das sein Status in einem Programm verwendet wird. Aus diesem Grund kann weder ein Programm noch eine Direktverknüpfung dafür sorgen das der TFK in den eigenen DC rennt!!
Die einzige Möglichkeit die ich mir vorstellen kann ist das beim übertragen der Konfigurationsdaten irgendwas schief läuft und die Software das TFK zum Amokläufer wird.
ravenhall hat geschrieben:Am Anfang funktionierte das Programm auch noch normal. Irgendwann kurz darauf kam aber bei dem Versuch, eines der Fenster zu öffnen, das bekannte Muster für Duty Cycle erschöpft am Kontakt selbst. Ein Versuch bei den anderen zeigte dasselbe Ergebnis. Stromlos machen half nichts auch nicht über eine längere Zeit. Es kam immer sofort nach dem Einsetzen der Batterien wieder die gleiche Meldung.
Das Programm kann ja auch nur solange normal funktionieren solange der TFK seinen Status vernünftig an die CCU meldet. Ist der DC erschöpft darf der TFK nicht mehr senden und das Programm arbeitet "gefühlt" nicht mehr richtig.
Die TFK mit gesichertem Modus senden zu lassen ist auch nicht wirklich ratsam. Hierdurch verdoppelt sich der Funkverkehr und es kommt schnell zu Verbindungsproblemen. "Gesichert" bedeutet lediglich das der Funkpartner sich authentifizieren muss und berechtigt ist das Funkpaket zu empfangen. Das Signal selbst wird dabei nicht verschlüsselt oder ähnliches. Die Funktion hat somit mehr Nachteile wie Vorteile.
Wenn stromlos machen und der dann folgende Reboot des TFK beim einlegen der Batterien den Fehler nicht behebt, dann haben die Geräte ein echtes Problem.
ravenhall hat geschrieben:Zwei in der selben Gruppe vorhandene HM-Sec-SC-2 hatten die ganze Zeit kein Problem, wohl aber alle in der Gruppe vorhandenen HM-Sec-SCo!
Irgendwann hatte ich dann das Programm in Verdacht, da die Sensoren aus dem ersten betroffenen Raum auch im Programm am Anfang standen. Nachdem ich das Programm erst deaktiviert und dann gelöscht hatte, kamen natürlich Probleme mit dem Duty Cycle der CCU2 dazu, welche sich auch nach zwei Tagen nicht mehr von alleine legten (ständiger Wert von 99%).
Das die SCo eher betroffen sind wie SC-2 ist auch logisch. Ein SCo muss sich mind. 1x pro Stunde bei der CCU melden und ein SC-2 lediglich 1x pro Tag. Meldet sich der SCo nicht pünktlich bei der CCU, dann wird eine "Kommunikation ist gestört" generiert.
Der DC ist garantiert nicht auf 99% gegangen weil Du das Programm gelöscht hast. Das genannte Programm hat absolut keinen Einfluss auf den DC der CCU!! Das Programm sorgt auf für keinerlei Funkverkehr. Es verarbeitet lediglich einen gemeldeten Status weiter.
ravenhall hat geschrieben:Zwischendurch behalf ich mir dann mit Zurücksetzen der Thermostate und direkter Verknüpfung ohne CCU2, damit wenigstens eine manuelle Heizungssteuerung funktionierte
Ob eine Direktverknüpfung mit oder ohne CCU erstellt wurde hat keinen Einfluss auf den DC der CCU. Bei Direktverknüpfungen lauscht die CCU lediglich mit wenn die Geräte sich unterhalten, sie greift aber in keinster Weise ein. Aber auch hier vermute ich einen Amokläufer in der Heizungssteuerung der permanent gesendet hat.
ravenhall hat geschrieben:Wie gesagt, drüberlernen ging in dem Moment natürlich nicht und ein Stromlosmachen half auch nicht. Eine extrem miese Konfiguration kann eigentlich nur an dem neuen Programm und der damit verbundenen Verknüpfung gelegen haben, sonst wurde nichts verändert und vorher und nachher lief alles 1A. Und wie soll man die Ursache finden, wenn gar nichts mehr geht!?
Mit mieser Konfiguration hatte ich andere Geräte wie z.b. einen Aktor mit Leistungsmessung gemeint. Solche Geräte kann man so mies konfigurieren das sie zum Problem fürs System werden.
Einen TFK kann man nicht so "verkonfigurieren" das er zum Problem wird!
Ein Programm legt keine Verknüpfungen mit Geräten an!! Programme werden ausschließlich von der CCU verarbeitet. Das beim erstmaligen einfügen eines Gerätes in Programmen die Konfigurationsdaten übertragen werden müssen hat ganz grob erklärt damit zu tun das die Statusänderungen ab sofort bestätigungspflichtig sind weil diese Änderungen von der CCU weiterverarbeitet werden müssen.
Wie man bei vollem DC der CCU am besten vorgeht um den Verursacher zu finden ist x-fach im Forum besprochen worden, das erspare ich mir an dieser Stelle. Mit Sicherheit ist planloses löschen von Geräten usw. der absolut falsche Weg.
ravenhall hat geschrieben:Tur mir leid, aber es funktioniert so (entspricht ja Punkt 1). Die Konfiguration ist in diesem Fall ja in der CCU2 noch vorhanden. Nach dem Reset am Gerät holten sich die TFKs sofort (!) wieder die Konfig und waren einsatzbereit
Leid tun muss Dir das nicht. Aber leider hast Du die gesamten Abläufe nicht verstanden.
Das den Anlernmodus der CCU aktivierst während Du am TFK per Gerätetaste den Werksreset auslöst ist absolut folgenlos. Auch ohne aktiven Anlernmodus der CCU hättest Du das selbe erreicht.
Du hast einfach nur einen ganz normalen Reset am Gerät ausgelöst und das Gerät hatte somit eine frische Konfiguration. Das Gerät war weder zwischenzeitlich abgelernt noch hat es sich selbstständig wieder angelernt. Es hat sich auch keine Konfigurationsdaten von der CCU geholt.
Das alles was Du glaubst getan zu haben hätte man nur durch den Dialog "löschen" über die CCU erreichen können.
ravenhall hat geschrieben:Eine Funkstörung schließe ich aus, da es an der CCU2 kein anderes Gerät gibt und die anderen Direktverbindungen sonst funktioniert haben.
Funkstörungen müssen nicht zwangsläufig aus der HM-Welt kommen. Es gibt hunderte Beispiele im Forum wo Fremdgeräte (Netzteil, Pumpen, DVBT und und und) die Ursache waren. Wenn aber die Direktverknüpfungen nicht gestört sind sondern nur der Funkverkehr der CCU, dann bestätigt sich die Vermutung das ein dauerfunkender Sensor/Aktor das Problem verursacht. Oder die CCU selbst ist Schuld weil sie dauernd unnötig Funkt. Das kann wiederum auch daran liegen das Du extrem viele Konfigurationen an sehr vielen Geräten unternommen hast und die CCU jetzt verzweifelt versucht die Daten an die betroffenen Geräte zu senden.
ravenhall hat geschrieben:Wie schon gesagt, das habe ich alles probiert (siehe oben) auch über mehrere Tage hinweg, also kein planloser Aktionismus, sondern in dem Fall der letzte Ausweg!
Da gehen die Meinungen auseinander. Jeder erfahrene "HomeMaticer" wird Dir hier wiedersprechen. Ein geordnetes lokalisieren des Problems wäre sicher sinnvoller gewesen wie die große Keule. Denn so hast Du einfach nur einen Zufallstreffer gelandet und weißt nicht mal wer oder was den Fehler verursacht hat.
ravenhall hat geschrieben:Genau das schließe ich aber aus, da die anderen Direktverbindungen funktionierten.
Und warum ist das so??? Logisch, weil DV`s komplett ohne CCU arbeiten. Nur weil die DV´s richtig arbeiten bedeutet das nicht das die CCU evtl. permanent damit beschäftigt ist sich mit einem einzigen Gerät zu unterhalten.
Außerdem würdest Du eine nicht funktionierende DV nur durch ausbleibende Schaltungen bemerken. Servicemeldungen werden durch nicht funktionierende DV´s nicht verursacht weil die CCU ja nicht beteiligt ist.
Hardware-Reset am Fensterkontakt (1x drücken mindestens 5 Sekunden, rotes blinken, dann noch einmal mind. 5 Sekunden drücken).
).