Hallo,
es gibt doch die Möglichkeit die von der FHZ empfangenen Daten im debug anzusehen. Dann kann man nachsehen (ich denke paresy kann da helfen), ob überhaupt Infos der FHTs reinkommen. Dazu braucht man nur mal die Solltemp ändern und ein paar Minuten warten. Man kann hier denke ich auch abgebrochene oder unvollständige Übertragungen erkennen.
MfG
Fabian
Fabian,
Meiner erfahrung lehrt mir das die commando’s wirklich raus gegen… glaub mir.
ABER
Aus batterie-spar massnahmen steht der empfanger im FHT nicht immer an, es gibt nur ‚fenster‘ worein er empfangt. Und da lauft ab-und-zu etwas schief. Auch bei gut-laufende anlagen.
Der empfang ist problematischer. Da gilt die FHZ1000 zu FHZ1300 vergleich.
Da alle data-telegramme von die FHT’s nur gesendet - aber niemals bestätigd - kommen manchmal 2 oder mehr telegramme am gleichen zeitpunkt an. Und da kann nur eine erfasst werden. Der andere ist damit ‚missing‘.
Hardware mässig ist der 1300-er meiner meinung ausgerusted mit einem empfang- und einem sende buffer. Der 1000-er hat nur eins. (nicht bestätigd - aber meine meinung).
Diese buffer sorgen dafur das die telegramme durch das programm erfasst sein können, und das sende-befehle raus gehen.
So lange ein buffer belegt ist lauft niks mehr. (Paresy hat fuer dieser zweck dem FHT-queue eingebaut)
Deshalb… sparsam sende befehle nutzen, damit man genugend zeitraume behallt um daten empfangen zu können.
Empfehlungs-werte : Anlage mit 1300-er und 8 FHT’s : nicht mehr wie 1 kommando’s pro 4 minuten im alltag. In 'burst’mode durfen 2 commando’s per 4 minuten rausgesendet werden -> aber da gibt es möglicherweise empfang-probleme.
1000-er anlage : max 5 FHT’s punkt und 1 sende befehl pro stunde.
@Fabian: das debuggen ist zeit-erforderlich. Damals 3 Tage @ 8 std/tag beschäftigd gewesen um die IPS fine-zu-tunen. Langweilig ! glaube mir.
Grusse,
Fredje
@Paresy: es gibt vielleicht ein grund wieso das thema wieder ‚hot‘ ist: Ab-und-zu bekomme ich 100% perc.-werte ohne das stellantriebe reagieren und ohne das es ein grund gibt 100% ventilöffnung zu benötigen. Und das von alle FHT’s. Aber ohne weitere nachforschungen gemacht zu haben, ist es mir ein rätsel.
Kann es eigentlich sein, dass sich die FHT auch gegenseitig „absprechen“ wer wann sendet? Mir kommt das irgendwie komisch vor. Ich habe gestern 5 FHTs an anderen Zentralen (FHZ1300) umgemeldet, jetzt ist da wieder der Wurm drin (Senden und Empfangen geht nur schlecht). Die ganzen FS20 Komponenten sind davon aber nicht betroffen 
Nein, das glaub ich nicht.
Ich denke das ist schlichtes Netwerk-Woodoo. Oder du hast eine Disharmonie im Protokoll-Schakra 
Toni
Und ich denke eher, die FHT’s hängen falsch im Raum und ergeben ein ungünstiges Feng Shui ! 
Nee, mal im Ernst. Ich kann die Probleme verstehen, da es während der ersten Testphase mit FHT’s sehr frustierend ist, da man nicht mal so auf Anhieb Befehle senden und empfangen kann, da man auf die Lust und Laune der FHZ angewiesen ist. Sie gibt den Ton an, leider !
Ich habe mit 11 FHT’s Null Probleme. Nicht ein einziges Telegramm ist in 2 Jahren verloren gegangen. Seit Paresy die IPS Request Geschichte eingebaut hat, läuft alles wie ein schweizer Uhrwerk. Natürlich, wie schon so oft hier erwähnt, man darf die FHZ nicht mit Befehlen zumüllen, denn sonst stellt sie auf stur, und man kann dann mal mehr als 45 minuten drauf warten, bis ein Befehl durchgeht.
Bei dem Empfang kann ich nur sagen: Verstell ich das Rad am FHT oder schliess ein Fenster ist die Meldung 95% unter 10 Sekunden in IPS angekommen. Für die restlichen 5% ist es unter 2 Minuten.
Kann es eigentlich sein, dass sich die FHT auch gegenseitig „absprechen“ wer wann sendet?
Das klingt zwar beschissen, aber manchmal krieg ich auch das Gefühl, dass meine FHT’s miteinander tuscheln, wer wann was sendet ! Also in der Praxis sieht es so aus, als wenn das System sich einpendeln würde. Bei mir ist es so, dass ich bei grösseren Umänderungen an den FHT Skripten immer merke, dass das ganze ein bis 2 Tage braucht, bis sich wieder alles eingependelt hat !
mfG Franz
Diesen Effekt habe ich auch schon bemerkt.
Ich habe das mal im debug nachverfolgt. Da steht im Moment wieder ziemlich oft „Chunk Incomplete“. (zum Testen sende ich seit einigen Wochen keine Werte an die FHTs) Daher vermute ich mal folgendes Problem:
Die FHTs senden in (nach ihrem internen Timer laufenden) regelmäßigen Abständen. Jetzt kommt dieser „normale“ Rhythmus durch Benutzereingriffe wie Senden anderer Sollwerte oder Drehen am Rad „durcheinander“. Da die Timer ja nicht synchron laufen sondern einer schneller/langsamer als der andere, kommt es im Laufe der Zeit zu Überschneidungen. Ähnlich einer Schwebung benachbarter Frequenzen. Jetzt gerade liegen die Messages von 3 FHTs direkt übereinander. Gestern waren sie noch 2-3 Sekunden auseinander.
Aber:
Jetzt kommt die (von mir ebenfalls gemachte) Beobachtung von guyabano ins Spiel. Da wir durch die Scripte in regelmäßigen Zeitabständen Daten senden, kommt es zu einer „Quasi-Synchronisation“ der FHTs. Und schon läufts rund.
Fazit: jebesser die zeitliche Steuerung der Scripte, desto besser die Funktion der FHTs.
Was haltet Ihr von meinen Vermutungen?
Fabian
Aber bei mir ist es so, dass die Befehle an die FHTs im Buffer hängen bleiben, hier wird also erstmal nichts regelmäßig gesendet.
Auch das ist verständlich:
Der Empfänger des FHT ist normalerweise deaktiviert. Die FHZ wartet nun bis ein FHT selbst gesendet hat. Danach ist ein kleiner Zeitschlitz zum Empfang „offen“ bis der FHT, wegen des Energiesparens; den Empfänger wieder deaktiviert. (siehe Beitrag von Fredje)
Will sagen:
Empfänget die FHZ keine plausiblen Daten vom FHT => sendet sie folglich auch keine Daten zum FHT - also bleiben die Daten bis zum Timeout im Buffer hängen.
Hast Du mal versucht, den problematischen FHT mit einem anderen zu tauschen, sodass sich die Entfernung zur FHZ ändert? Ich hatte schon (vermutlich durch schlechte Abstimmung) Probleme mit bestimmten Empfangssituationen.
Fabian
Hallo erstmal… bin ganz neu hier.
Diese Thema wurde scheinbar schon lange nicht mehr berührt. Aber falls sich ein Neuling (wie ich) nochmal bei der Problemsuche hierher verirrt, möchte ich mal ganz frech einen Lösungsvorschlag zum Thema - FHT sendet keine IST-Temperaturen - einwerfen:
Beobachtung:
Als ich mein IPS vor rund zwei Tagen eingerichtet habe, habe ich nur die für mich „interessante“ Variablen angelegt. Die Felder für zB. „Modus“ haben bei den FHT keine Variable bekommen. Das Problem mit den uralten IST-Werten hatte ich bis vorhin auch noch.
Problem (vermutlich):
Diese völlig unwichtigen Informationen, die regelmäßig von den FHTs ausgehen, haben sowas wie einen Datenstau (Pufferüberlauf?) verursacht. Frei nach dem Motto „mir hört ja eh keiner zu“ kommen dann auch die „interessanten“ IST-Temperaturen nicht mehr an.
Lösung (liegt dann wohl auf der Hand):
Für jeden „Schrott“ eine Variable anlegen (, in der Übersicht gut verstecken und im FHT verknüpfen. So fühlen sich die FHT wieder ernstgenommen und senden fleißig wieder ihre Daten…
… also bei mir läuft jetzt jedenfalls: Wenn die Daten noch aktueller wären, hätte ich schon eine Temperatur-Vorhersage!
MfG, Carsten
Hallo Carsten,
erst einmal herzlich willkommen im Forum!
interessant. Schau Dir mal WIIPS an, damit kannste Deine Temperaturwerte grafisch darstellen (unter anderem). Und auch das IPS-Together nicht zu vergessen.
Gruss Torro
Auch von mir ein herzliches Willkommen in der IPS-Gemeinde.
Ich fürchte es ist leider nicht so ganz simpel, wie es im ersten Moment aussieht.
Erstmal kann es nicht nicht daran liegen, dass keiner „zuhört“, da der FHT nur unidirektional sendet und die Zeit dafür auch noch selbst festlegt.
Es ist ihm sozusagen egal, ob jemand die Daten haben möchte.
Die Unregelmäßigkeiten (du wirst schon noch sehen :rolleyes:) haben imho zwei primäre Gründe:
Die Firmware der FHTs ist schon ein wenig merkwürdig. Aus nicht nachvollziehbaren Gründen
verweigert er manchmal die Zusammenarbeit.
Bei mehreren FHTs kommt es von Zeit zu Zeit zu einer Überlagerung der Datentelegramme.
Da jeder nach seiner eigenen Uhr läuft und diese nicht synchronisieren, senden sie irgendwann zeitgleich.
Dieser Zustand dauert nach meinen Logs etwa 1h.
Übrigens sendet der FHT nur die Ventilposition regelmäßig.
Die anderen Daten kommen mehr „nach Bedarf“
z.B. wenn sich die Raumtemp. geändert hat. Wenn sie sich nicht ändert
gibt es auch einen Zeitraum aber viel größer als die Pos.
Grüße und viel Spaß mit IPS
Fabian
Hallo Torro! Von Dir und Deinem WIIPS habe ich schon viel gelesen! Bin echt beeindruckt: Sowohl von dem Interface an sich, als auch von der Tatsache, daß Du Dein KnowHow so selbstlos (=kostenlos ) der Fangemeinde zur Verfügung stellst… weiter so!
In absehbarer Zeit werde ich mich zweifellos mal näher mit dem WIIPS auseinandersetzen. Allerdings bin ich momentan noch damit beschäftigt, ganz kläglich an dem Designer zu scheitern (mit so banalen Sachen wie: Wo stellt man die Hintergrundfarbe einer Groupbox ein… ).
@prof / Fabian:
Danke für den Tip! Das mit der Überlagerung habe ich wohl auch gerade erlebt: Ein FHT sendet eine Stunde keinen IST-Wert, danach aber wieder den selben Wert wie vorher. Sehr beruhigend, daß ich das als „normal“ hinnehmen darf!
Dennoch MUSS an meiner Beobachtung irgendwas dran sein. Bis zu meinem „Experiment“ gestern, hatten alle drei FHT mehr als sechs Stunden keine IST-Wert mehr geliefert. Seit ich dann zb. die Batterie-Meldung und Fensterdinger mit Variablen belegt hatte, kommen die Werte (fast) ganz regelmäßig rein… sonst habe ich nichts geändert (Standorte), kein Neustart des Servers und auch keine Daten zu den FHTs übertragen.
PS: Einer der FHT hat gar keinen Fensterkontakt und sendet trotzdem ständig ein „False“.
Meine Vermutung mit dem Datenstau bezog sich auch eher auf die FHZ1300 oder gar das IPS. (… ich hoffe, jetzt werd ich hier nicht gekickt! 
) Möglicherweise werden die Daten, die nicht mit Variablen belegt sind, nicht aus dem Puffer der FHZ abgerufen und bleiben „in der Leitung“ stecken!?
(Ich hatte auch schon irgendwo gelesen, daß bei einem „Leidensgenossen“ hier der RAM des Servers langsam voll lief… nach einem Neustart kamen dann zeitweise die Daten wieder an… vielleicht landet da der „Schrott“, den ich meinte? )
MfG, Carsten