Ich habe ein Problem (das schon seit langem) mit dem ich mich im Moment nie so richtig befasst habe, das mir aber so langsam auf den Wecker geht, speziell dann immer wenn das Badezimmer morgens kalt ist.
Nach einer Nacht, in der quasi keine FHT Befehle gesendet wurden, kommt es (fast) immer dazu, dass der erste FHT, der angesprochenen werden sollte, nicht drauf reagiert.
So gegen 6.30h sollten meistens gemeinsam ein paar Räume aufheizen:
Badezimmer, Eltern Schlafzimmer, Küche, gefolgt von Flur und Kinderzimmern.
Je nachdem, welches Zimmer zuerst dran ist nach der Nacht, also der erste Schaltbefehl des Tages, geht quasi immer in die Hose ! Da alle FHT’s in einer Schleife abgearbeitet werden, kommt es immer dann darauf an, wo der Zähler gerade steht, welcher Raum der erste sein wird !
Doch sobald dieser ‚erste‘ Befehl in der Queue ist (und verenden wird) gehen alle drauffolgenden ratzfatz durch !
Wie könnte man das detektieren? Lauter als : „hmm komisch … wieso ist es hier noch kalt“ - oder iregendwie in IPS ?
Kan man diesem verhalten programatorisch nach vol ziehen ? Oder gibt es einem zufallsfaktor?
ich weiss nicht wie ich dem auf die Spur kommen könnte.
Fakte sind:
[li] Es ist FHZ unabhängig, da ich ja mehrere in Betreib habe und es keine Rolle spielt, auf welche dieser ‚erste‘ Befehl vergeben wird.
[/li]
[li] Meistens kommen 3 Räume in Frage, und es hängt einfach vom Schleifenzählerstand ab.
[/li] Beispiel:
Raum 1 ist #3 in Liste
Raum 2 ist #7 in Liste
Raum 3 ist #11 in Liste
Alle Temperaturen sollten zum gleichen Zeitpunkt geändert werden. Der Schleifenzähler steht nun auf 6 und springt auf 7, somit wäre der Temperaturwert von Raum 2, der in der Queue hängenbleibt, und alle drauffolgenden gehen dann durch. Es ist, wie schons gesagt, total unabhängig davon, ob Raum 1 nun an der FHZ#1, Raum 2 an der FHZ#2 und Raum 3 an der FHZ#3 hängt.
Mir ist das ganze ein Rätsel, und wie schons gesagt, es tritt mit einer sehr grossen Regelmässigkeit auf, als wie wenn die FHZ’s einschlafen, und erst der erste Befehl das ganze wieder aufweckt !
Ich hatte damals schon mal diesem einfrier eingenschaft anerkannt - aber war bezuglich die wochentliche durchlauf fur die ventile (ganz-offen und wieder ganz-zu) Da hat es die IPS nicht mitbekommen und könnte nicht mehr weiter - aber das hat Paresy schon längst beseitigd.
Ich glaube dein einfrieren hat mehr mit die funk-salat zu tun die HJH ganz schön beschrieben hat.
Es sind die FHT’s die das ‚fenster‘ offnet wo der bereit steht um signale empfangen zu können. Diese ‚fenster‘ wird durch ist- und %-werte annociert (mein deutsch schon mal wieder).
Hat es damit zu tun ? Das hiess das alle FHT’s synchronisiert laufen - wo wir davon ausgehen das das niemals vorkommen sollte… Also die nacht geht vorbei und alle FHT’s hängen im funk-salat fest. Das erste commando geht raus, wo die alle ihre interne a-synchron zeituhr wieder aktivieren. Danach laufen alle FHT’s wieder a-synchron und ubernehmen brave ihre kommando’s.
Das hiesse also das - wenn du einem log-file mitlaufen hättest - die %-wert und ist-werte nicht mehr reinkommen wurden uber eine bestimmte zeitlucke. Und mit diesem thema kämpfe ich zur zeit auch ! Ab und zu ist schluss fur 1-2 stunden.
Werde mir mal wieder etwas mehr mit diesem thema beschäftigen…
Franz, Denke es mal bitte durch - und implementiere mal bitte so ne log-file.
ich habe ein Watchdog Skript mitlaufen, dass mir genau sagt, wenn ein FHT einschläft. Aber hier ist das Problem seitens IPS, denn der ‚erste‘ Befehl kommt zum Buffer und bleibt dann dort. Wenn ich den gleichen SetTemp. nochmals manuell durchschicke (sogar nach ein paar Sekunden) kommt er in den Queue stehen an 2. Stelle, und wird dann aber sofort zum FHT geschickt, wobei der erste befehl dann immer noch im Queue festhängt !
Und es ist bestimmt nicht immer den gleichem FHT die es blocked ?
Vor 2 monate hat es mir auch erwischt das einem FHT nur ‚halb‘ angemeldet war und damit den queue uberlaufen lassen hat…
Man kann ja sehen, ob Werte im FHZ Buffer stehen und wieviele noch frei sind. Ich habe dazu mal ein Thread gesehen, irgendwas mit FHZ_FreeBuffer, o.ä ?
Interssant wäre auslesen zu können, wie der Timestamp eines jeden Befehl ist, somit könnte man gegebenfalls den ‚hängengebliebenen‘ Befehl nach einer vordefinierten Zeit nochmals senden !?
