Unzuverlässig: Tür- und Fenstersensor schalten nicht zuverlässig die Thermostate HKT ein oder aus

    Zitat von Juergen_A

    Duty Cycle Der Gesetzgeber hat für die verwendeten Funkfrequenzen im 868-MHz-Be...

    Ja, schön geschrieben ... ich war so gerührt, dass ich dabei weinen mußte :)

    Das ist ja das "Normalverhalten", dass auch ich beobachte. Ist aber kein Widerspruch zum Knock Out, denn das HKT kann ja gerade die IST-Temperatur an die SHC übertragen haben, vielleicht überträgt das HKT das ganze 64 mal weil ... ist ja wurscht warum ... das HKT bekommt eine Faustwatsche und geht für 90 Sekunden zu Boden und genau in diesen 90 Sekunden schließt Du das Fenster. Der TFS meldet den Event der SHC, passt, und dann wendet sich das TFS vertrauensvoll an das HKT, das da aber flachatmend am Boden liegt. Das TFS erreicht das HKT nicht und reagiert mit blink blink blink was nichts anderes bedeutet wie "HKT wach auf!" für "He alter was ist los?" würde es 5x blinken ...

    Zitat von Juergen_A

    Duty Cycle Der Gesetzgeber hat für die verwendeten Funkfrequenzen im 868-MHz-Be...

    Ihr stellt hier ja sehr phantasievolle Theorien vor. In der traurigen Realität können diese aber leider nicht bestehen, denn kaum ein SH-Gerät (nicht einmal der viel-funkende SHC) reisst das Limit des Duty-Cycle. Als ich vor etwa zwei Jahren zum ersten Mal von dieser 1%-Regel erfuhr, habe ich mir damit selber auch einige Theorien dazu zurechtgelegt. Als ich dann aber später einmal mit einem echten Experten darüber sprechen konnte, erfuhr ich, dass die Gerätekommunikation binnen Tausendstel Sekunden stattfindet und nur diese Tausendstel auch zur Berechnung herangezogen werden. Selbst der wildeste Traffic kommt somit niemals auf voll 36 Sekunden pro Stunde. Wäre schön gewesen, ist aber leider eine Sackgasse.

    Zitat von Dennis K.

    Das ist KEIN innogy Problem. Packe ich eine Seriennummer in ein PDF-Dokument und...

    Die Sache mit der Telefonanwahl ist bekannt und man kann angeblich tatsächlich innerhalb einer App entsprechende Felder so kodieren, dass diese von der automatischen Wählfunktion nicht berücksichtigt werden würden. Das ist dann so ähnlich wie die abgeschaltete "automatische Wortkorrektur" bei der Eingabe in ein Passwort-Feld. Es ist also prinzipiell ein Bug.
    @hand: In den meisten IT-Projekten, in denen ich beteiligt war, war Englisch die offizielle "Projektsprache" und auch Dokumentationen wurden immer in Englisch verfasst, z.B. um jederzeit eine "tellerrandübergreifende" Verständlichkeit zu gewährleisten, falls Teile davon an Drittanbieter gesendet werden mußten.

    Zitat von stayathome

    Schön, dass sich ein mit der Materie sehr vertrauter Forums–Teilnehmer THellweg...

    @hand: In den meisten IT-Projekten, in denen ich beteiligt war, war Englisch die offizielle "Projektsprache" und auch Dokumentationen wurden immer in Englisch verfasst, z.B. um jederzeit eine "tellerrandübergreifende" Verständlichkeit zu gewährleisten, falls Teile davon an Drittanbieter gesendet werden mußten

    Zitat von Juergen_A

    Duty Cycle Der Gesetzgeber hat für die verwendeten Funkfrequenzen im 868-MHz-Be...

    Nochmal hier, was ich an anderer Stelle schon mal geschrieben hatte:
    ich habe einen TFS, der mit *KEINEM* HKT gekoppelt ist und auch in *KEIN* Szenario eingebunden ist. Und auch der hat mir schon das 3x Blinken signalisiert ! Und das tollste: trotzdem waren die Zustandsänderungen (öffnen, schliessen) sauber in dem SHC mitprotokolliert !

    Zitat von Noge2016

    Liebe Community, ich lese die letzten Beiträge und danach die Startfrage. Was kö...

    Ich denke nicht, dass dieses System noch zu retten ist. Dazu ist es zu komplex, und die Software/Hardware Problemkombination zu gravierend..
    Ich hatte mir damals die RWE Heizungssteuerung zugelegt, da ich damit meine Buderus Heizung zu einem modernen Heizungssystem aufwerten wollte.
    Das Buderus Plugin ist aber auch völlig in der Versenkung verschwunden. Dem System läuft ja schon seit Jahren die Zeit davon, weil die Hardware, speziell die SHC technisch den Anforderungen einfach nicht gewachsen ist.
    Seit Wochen kann ich per iOS App nur noch mit dem Handy (welchem Bit muss ich ewig dankbar sein?) auf die SHC zugreifen. Wie ist es möglich, dass ein iPhone 6s mit der selben iOs Version funktioniert aber ein iPad Air nicht.
    Solch ein Verhalten ist nur mit dem blanken Software Chaos zu erklären, und antworten erhält man auch nicht. Da können wir noch Jahrzehnte unseres Lebens mit Resten und neu konfigurieren verbringen.
    Es bleibt wie es ist, ein SmartHome Roulette!

    Das Problem "WDS schalten die Temperaturabsenkung nicht dauerhaft zuverlässig" wird, dank vieler bereits übersendeter Logdateien und Beschreibungen der Benutzer von den Entwicklern der Innogy-Software untersucht. Aktuell wird dieses Problem so eingeschätzt, dass es sich nicht um einen neues (UI2.0 spezifisches) Problem handelt, sondern um eine Problematik, die es immer schon gab und von der auch andere SmartHome-Lösungen, die ebenfalls eQ3-Produkte verwenden, betroffen sind. Es gibt z.B. ähnich Beschwerden über das Telekomprodukt. Siehe Bild. Ob daher überhaupt eine Problemlösung über die Innogy-Software möglich sein kann, wird aktuell überprüft. Falls die Ursachen tatsächlich in der Firmware der Geräte liegen sollte, kann die Lösung nur über eine modifizierte Firmware kommen.

    Hallo lieber Herwig (hand),

    nachdem ich am Dienstag lesen musste, dass Du Dein gutes Dutzend SmartHome Geräte zurückgegeben hast, war ich zuerst etwas traurig und enttäuscht. Während meiner Fahrt zur Arbeit am Mittwochmorgen habe ich dann jedoch eine Idee zu einem Plan entwickelt und danach begonnen diesen in die Tat umzusetzen. Heute habe ich dazu eine positive Antwort aus Klagenfurt bekommen und daher wende ich mich nun noch einmal an Dich.

    Hier die Details des Plans (der Idee):

    Die von Dir zurückgegebenen SmartHome Geräte werden nun nicht von der KELAG an den deutschen Logistiker zurückgeschickt um dort eingestampft zu werden. Diese (Deine Original-Geräte) werden stattdessen aus dem normalen Retourenprozess abgezweigt und gehen direkt in die SmartHome-Entwicklungsabteilung. Damit ergibt sich für die Kollegen eine einmalige Chance, zu versuchen, die von Dir hier beschriebenen Probleme, mit exakt Deinen Original-Geräten, nachstellen zu können. Um diesen Test tatsächlich unter Originalbedingungen ausführen zu können, wäre es natürlich sehr sinnvoll dazu auch Deine (Original-) Szenarien verwenden zu können.

    Hierzu also jetzt meine Fragen an Dich:

    Ich habe gesehen, dass Du mindestens Deine Zentrale vor der Rückgabe mit einem Factory-Reset von Deinem Benutzerkonto entkoppelt hast. Hast Du Dein Benutzerkonto (und damit auch alle Deine Szenarien) ebenfalls gelöscht oder existieren diese Daten noch in der SmartHome-Datenbank und könnten diese ggf. reaktiviert werden?

    Da Du sicherlich nicht vorhaben wirst dieses Benutzerkonto jemals wieder zu verwenden, möchte ich Dich gerne fragen, ob Du Deine Anmeldedaten für die o.g. Tests zur Verfügung stellen würdest, falls das Benutzerkonto noch existiert?

    Falls das für Dich OK sein sollte, könntest Du bitte diese Infos (Benutzername und Passwort) der Innogy-Hotline mitteilen. Die Angabe Deiner damaligen INC-Nummer würde die Zuordnung dieser Infos problemlos ermöglichen.

    Ich würde mich sehr freuen wenn die von Dir beschriebenen Fehler damit insofern reproduzierbar wären, weil die Entwickler Deine Originalumgebung zum testen benutzen könnten und insbesondere wenn damit ein "besonders fieser" Bug gefixt werden könnte.

    So würde der Verlust eines wertvollen Community-Mitglieds, denn als solches sehe ich Dich, wenigstens noch einen positiven Nebeneffekt haben!

    Viele Grüße gen Süden,

    Thomas

    Ich versuche mal, diesen Thread wieder aus der Versenkung zu holen. Denn das hier in weit über 150 Kommentierungen (!) ausführlich beschriebene Problem der Kombination von HKT und TFS ist auch mit dem kürzlichen Update nicht behoben (und nervt total, da man diese Unzuverlässigkeit ständig kontrollieren muss) !!

    Ich konnte dies heute sogar an dem innogy-Demostand auf der e-world Messe in Essen provozieren (der Kollege mit Standdienst ist mein Zeuge) .
    3x Blinken mit allen sich daraus ergebenden Phänomenen.!!

    Moin,

    hier eine kleine Beschreibung, was sich bei mir gestern gezeigt hat:

    Nachdem ich (nach Neuaufsetzen des Systems wegen Umzugs) auch die oben geschilderten Probleme bei der Kombination TFS und HKT hatte, hat sich in letzter Zeit (2 -3 Wochen) ein recht zuverlässiger Zustand eingestellt. Alle HKTs haben das gemacht, was die TFSs vorgegeben haben.

    Gestern Morgen hat dann ein HKT gemeldet, dass die Batterien schwach seien. Ich habe die Batterien also getauscht. Danach erfolgte die Kalibrierfahrt des HKT (A1, A2 ...). Nach Einstellen der Zieltemperatur auf den gewünschten Zielwert konnte dann der Normalbetrieb eigentlich weiter gehen.

    Jedoch - beim nächsten Öffnen des Fensters erfolgte nur 3 x Blinken und keine Reaktion des HKT. Direkt danach habe ich das Fenster wieder geschlossen ... ebenso gefolgt von 3 x Blinken. Das ganze habe ich dann noch 3 x wiederholen müssen, bis das HKT dann auf den TFS reagierte.

    Frage in die Runde: Ob es wohl eine "Lernphase" für die HKT/TFS-Kombination gibt? Und ob wohl das HKT das Gelernte nach Neustart (nicht Reset) wohl wieder vergisst?

    Kann sonst jemand dieses Verhalten bestätigen? - Falls ja, wäre das vlt. ein guter Hinweis für die SH-Entwickler.

    VG und einen schönen Tag, Jürgen

    Nach dem Lesen aller Beiträge und au Grund meiner Erfahrungen aus V1 hier folgende Problemlösung:

    • In V1 habe ich die Unzuverlässigkeit der TFS/HKT Absenkung (und ich vermute auch, dass es mit der TFS-HKT Kommunikation zu tun hat) dadurch überwunden, dass ich den Zustand in einem "Profil" abgefragt habe: (1.) Bei TFS wird geschlossen HKT = X°C und (2.) wenn TFS geschlossen ist, dann HKT = X°C

    Mit obiger Vorgehensweise musste ich nicht mehr kontrollieren, ob die Absenkung funktioniert, denn sie hat 100%ig funktioniert!

    Vorschlag für V2, da hier die Schaltung von Zuständen und die Generierung komplexer Logikprofile kaum noch möglich ist:

    • Von der SHC wird nach der Protokollierung der TFS-Bedingung zur Sicherheit der Zustand ca. 5 Sek. nach Zustandsänderung nochmals an das HKT gesendet.

    Damit wird die Zuverlässigkeit von ca. 67% statistisch um nochmals 67% erhöht. Evtl. tatsächlich um noch mehr, wenn die HKT mglw. den ersten TFS Impuls zum "Aufwachen" benötigen und erst beim 2. "Befehl" die Zustandsaänderung am TFS richtig verarbeiten. Eine solche Zusatz-Info von SHC an HKT sollte sich doch in der SHC Software realisieren lassen, oder?

    VG D

    Zitat von Puffke

    Nach dem Lesen aller Beiträge und au Grund meiner Erfahrungen aus V1 hier folgen...

    Moin,
    ja, so ähnlich hab ich das - zumindest für 1 HKT umgesetzt. Jedoch, falls Du Deine Temperaturen über Zeitszenarien steuerst, würdest Du dieses jeweils gültige Temperatur nicht wissen, sondern eine fixe Temperatur setzen. Erst zum nächsten Schaltzeitpunkt der Zeitsteuerung würdest Du wieder auf Deine "eigentliche" Wunschtemp. wechseln.
    Beispiel: Dein Zeitszenario mach es von 6 Uhr bis 10 Uhr warm (21°) danach kühler (16°). Dein Fenster zu "Korrekturszenario" setzt 18°. Du machst das Fenster um 7 Uhr zu. Dann höättest Du von 7 Uhr bis 10 Uhr 18° , und nicht 21°.

    Zitat von Puffke

    Nach dem Lesen aller Beiträge und au Grund meiner Erfahrungen aus V1 hier folgen...

    Deswegen will ich das ja nicht über Szenarien einbinden, weil klar ist, dass das alle anderen Szenarien zerschießt, es sei denn, Du frickelst alle ootb Szenarien in einer Multikomplexen Umgebung selbst zusammen. Ich denke eher an eine SHC Software Aktualisierung, die von der SHC Software nach Mitteilung & Protokollierung des TFS "geöffnet" / "geschlossen" in der SHC zusätzlich zur direkten Kommunikation zwischen HKT zum TFS nochmals an das HKT sendet: Hallo, Du hast hoffentlich die Mitteilung des TFS verstanden, hier nochmals zur Sicherheit, TFS ist jetzt im Zustand X. Wenn das identisch mit Zeitverzögerung zum Befehl des TFS an das HKT gesendet wird, sollte das den gleichen Impuls auslösen, als wenn die TFS direkt an HKT kommunizieren und die Szenariern ansonsten unbeeinflusst lassen. Sozusagen als Sicherheitsbefehl, um zu gewährleisten, dass das HKT den TFS Befehl nicht gehört hat.

    Zitat von Puffke

    Nach dem Lesen aller Beiträge und au Grund meiner Erfahrungen aus V1 hier folgen...

    ah, verstehe
    Das wäre dann natürlich nichts, was wir als Anwender tun könnten - sondern eine Idee für die Weiterentwicklung. Ich kann mir vorstellen, dass es eine solche "repeat" Funktion bereits gibt, z. B. wenn ein HKT keine Bestätigung für die Änderung einer Zieltemperatur (z. B. aus einem "Schalt-Szenario") bekommt, müsste die SHC auch den Befehl wiederholen. Demnach wäre es vlt. gar nicht sooo eine große Ergänzung in der Entwicklung.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!

Benutzerkonto erstellen Anmelden