Ich habe irgendwie das Problem, dass SetFHTMode-Befehle irgendwie nicht aus dem Buffer gehen (nur nach dem Timeout). D.h. ein Umschalten des Modes am FHT durch IPS ist bei mir nicht mehr möglich! … Liegt es an den Updates, das ich da was nicht mitbekommen habe??! Ist halt blöde, da die Befehle den Buffer vollstopfen.
Oder ist es ein Bug?
Nachtrag: nun kommen die Befehle scheinbar doch durch - dauert irgendwie exrem lange hmmmm
Vielleicht liegts ja an meiner FHZ1000PC … ich werde wohl auch demnächst mal umsteigen müssen, wenn es denn wirklich viel besser funktioniert.
Ich habe damit keine Probleme mehr seit ich von FHZ1000 auf FHZ1300WLAN umgestiegen bin ! Mit der FHZ1000 kam es bei mir auch mal vor dass der FHT Befehl in der FHZ hängenblieb, obwohl der Befehl zwar rausgeschickt wurde.
prinzipiell läuft die Sache seit beginn an ohne Probleme.
Auch die Umschaltung vom Mode (von IPS aus) ging bisher optimal.
Ich weiß nicht ob es seit dem letzten Update oder schon dem davor ist, dass es nicht mehr wirklich gut geht.
Heute Morgen hab ich es nochmal an zwei FHT#s probiert und bei beiden keinen Erfolg. Ich drehe am Rad (bisher nur an dem vom FHT ;-)), die Temperaturänderung wird von IPS erkannt und mein Script schaltet dann für 2h auf Manuellbetrieb um - d.h Temperaturänderungen aus dem Automatikscript werden ignoriert. Zur Anzeige für den Benutzer wird der Mode am FHT auf Manuell gesetzt… und genau das Funktioniert leider nicht mehr, weil der Befehl im Buffer hängen bleibt.
Bei mir bleiben zur Zeit die FHT berichten auch im queue stecken.
Es werden schon welche gesendet, aber die throughput ist sehr sehr langsam.
@Paresy:
Sorry fur diese Nachricht :o
Könntest du mir sagen wie die queue funktioniert? Wartest du auf ein CTS (clear to send) vom FHZ bis du etwas aus die queue zum FHZ ruber wanderen lasst?
Ist dies abhänglich vom datenverkehr die sonnst lauft? (Piri, FB, …)
Grusse,
–edit–
Die zu erwartene troughput liegt bei mir bei 7 setTemps pro 30 minuten in burst mode das heist das der queue pro 30 minuten mit 7 berichten belastet wird. Das schafft er aber nicht.
–edit–
Hallo,
habe bei mir mal gleich nachgeschaut. Habe das gleiche Problem die SetFHTMode-Befehle bleiben im Buffer stehen bis zum Timeout.
Alle anderen Befehle gehen schnell durch den Buffer. Hatte das Problem vor dem Update nicht. Es blieben zwar auch mal einige Befehle hängen, aber jetzt sind es nur und vor allem immer die mode.
Bei mir scheinen die FHT Requests auch sehr langsam durchzukommen. Ich bekomme die Target Response oft später als das Zeitintervall für eine neue Temperaturänderung vom Script (10 mn). Dadurch denkt mein Skript es wurde am Rad gedreht und steigt in den (virtuellen) manuellen Modus für 1 Stunde…
hatte heute mal wieder ein bissgen Zeit, ein Paar Sachen umzubauen in meinem Projekt. Ich will wirklich keine miese Laune verbreiten, aber seit der neusten BETA habe ich die gleichen Probleme. Nicht ein einziger Set_Mode Befehl will durch die FHZ.
@Admins: Ich war mir nicht schlüssig, ob dieser Post hierein passt oder in den BETA Sub-Forum !
Sobald ich die Core.Main.dll ausgetauscht habe ging wieder alles (also von BETA auf letzes Live-Update) !
Hallo,
ich habe auch eine 1300 FHZ und das Problem ist bei mir auch erst nach dem Update. Aber wie gesagt nur Mode Befehle, alle anderen sind jetzt super schnell.
Jetzt gibt es bei mir nur mehr das Mode-Problem. Die FHT Requests kommen jetzt schneller an. Hatte lange nicht mehr „desynchronisiert“ und durch Zufall wurden die Requests an alle FHT fast gleichzeitig geschikt. Das hat wohl zum Stau geführt.
Ich hab mich gesteren mal reingebissen in die FHT und FHZ sache.
Meine queue gleichte sich wie die frankfurter lufthafen. Niks lief, und alles stand in die schleife.
Habe der server mal restartet um die queue lössen zu können.
Meine config schiebt alle 30 minuten neue befehle an die FHT’s OHNE mode commando’s. Ich habe 7 FHT’s im einsatz.
Lassen wir denken in 2 minuten ‚slots‘ (cfr. flugverkehr - alle fluge bekommen ein ‚slot‘.)
Pro FHT kommen regelmässig berichte (IST, %)
per 30 minuten neue befehle (SOLL)
nacht’s die zeit synchro mit 1 FHT pro 12 minuten und KEINE commando’s weil er synct.
Da hat’s mir erwischt ! irgendwie war es zuviel. Der queue lief voll.
Wie geschrieben : gesteren mal recherchiert
Da ich der verdacht hatte das die slots uberfordert waren, gleich mal die 30 minuten cyclus geändert in eine stundenliche. Der queue mal neu gefult mit neue SOLL werte.
innerhalb von 8 minuten bekam ich alle aktuelle werte rein (IST, %)
Es blieben aber commando’s stehen im queue.
Hatte den verdacht das die einkommende berichte auch uber 's queue liefen… und dachte sche…sse - jetzt haben wir’s.
Flot gingen alle commando’s raus bis auf eine FHT-instanz die ständig (wahrscheinlich) time-out’s brach. Was stellte sich heraus? Eine FHT war nicht mehr angemeldet.
Batterien raus… 2 minuten gewartet. neue angemeldet, und neuer SOLL wert ruber geschickt. und hopla… in 3 minuten 3 commando’s raus. (SOLL, MODE, SOLL) (zum teufel das ging schnell )
Abwarten… das war gesteren abend.
Heute morgen: freu freu, queue ist lehr, alle ruckgabe werte anwesend und zeitlich angekommen. (Heute nacht hat die zeit synch nicht gelaufen - war gewollt)
Jetzt geht’s wieder von vorne an. Die stundenliche zyklus zuruck auf 30 minuten. Sehen wir mal.
Ich komme gerade darauf, dass mir das auch letzte Woche passiert ist. Eine FHT war ausgefallen (sogar am Rad konnte nichts geändert werden). Möglicherweise kamen die Queue Probleme davon.
Direkt mal nachgesehen: 7 FHT’s im einsatz, jede 30 minuten neue soll werte und der queue ist durch in 2 minuten 40.
heute nach mal die sync wieder probieren, sehen wie es lauft.
Hallo,
ich möchte dieses Problem noch mal anschieben. Gibt es schon neue Erkenntnisse über die Modebefehle, warum nur diese im Buffer hängen bleiben.
Die Heizperiode beginnt bald und es wäre für mich schon wichtig. Oder bin ich der einzige der dieses Problem hat.
)