FHT-Queue Optimizer

Die FHT-Queue ist eine feine Sache - sie kann aber auch Probleme bereiten.

Beispiel: Wenn ein Benutzer an einem Eingabeterminal entweder aus Spieltrieb, Unwissenheit, Experimentierfreudigkeit oder wie auch immer innerhalb von kurzer Zeit furchtbar viele FHT Einstellungen versursacht dann kann die Queue sehr schnell sehr lang werden.

So hat z.B. aktuell meine FHT Queue 129 (!) Einträge - wer weiss wie lange diese Queue zur Abarbeitung braucht…

In diesem Fall (den mit den 129 Einträgen) habe ich nur SetTemprature-Befehle für 4 verschiedene Heizungen mehrfach gesendet.

Eine Optimierung der FHT-Queue könnte so aussehen:

  • lösche alle Queue Einträge wenn:
    (Queue-Instance==Incoming-Instance) && (Queue-Cmd==Incoming-Cmd)

  • füge danach die neue Incoming-Instance mit Incoming-Cmd und Incoming-Value an die Queue an

Befehle die sich gegenseitig aufheben werden dadurch eliminiert und somit auch nicht mehr per Funk weggesendet. Statt 129 Einträge in der Queue wären dann bei mir nur noch 4.

Ich denke man hat keinen Einfluss auf die FHZ-Queue? Nunja, die packt eh nur 10 Befehle und das ist dann zeitlich noch ‚verträglich‘.

Gruss,
Olli

129 FHT Befehle in der Queue ? :eek: :eek:

Und dann wundern sich manche, warum keine FHT’s funktionnieren !

Also, man darf nie mehr als 1 bis 3 Befehle gleichzeitig in der FHZ Queue haben, sonst wird es schon schwierig.

Ich bin mal neugierig: Wie kann man 129 Befehle in der Queue haben, und was steht alles da drin?

Befehle die sich gegenseitig aufheben werden dadurch eliminiert und somit auch nicht mehr per Funk weggesendet.

Sowas musst du schon im Skript verhindern, dass der gleiche Befehle mehrmals gesendet wird.
Wenn dein FHT zB auf Auto steht, dann vermeide, dass ein weiteres ‚Auto‘ geschickt wird und damit unnütz den FHZ Buffer belastet.

So hat z.B. aktuell meine FHT Queue 129 (!) Einträge - wer weiss wie lange diese Queue zur Abarbeitung braucht…

max. 1 Stunde. Dann werden alle Befehle in einem Timeout landen und automatisch gelöscht werden!

mfG Franz

Genau dafür ist der obere Algorythmus da.

Ich habe mir mal alle deine Wünsche auf meine ToDo Liste getan… Gefallen mir alle ganz gut. Werde mal gucken, dass ich die demnächst einbaue.

paresy

Finde ich auch … nur habe ich irgendwie skeptisismus… wie kommt man zu wissen ob einer oder mehere FHT’s uberhaupt niks mitbekommen:
„hey! wieso lauft dieser FHT nicht? hmm komisch. Da send ich doch etwas. Der bekommt es nicht mit. Einmal gucken was los ist. Niks zu merken! ich sende und der bekommt niks…“
Wenn man den queue ansieht weis man das etwas schief ist. (So habe ich meine verabschiedeter FHT gemerkt - der queue lief uber - nach neue batterien und neue anmeldung lief der queue wieder)

Wie immer: my 2 cents in das sparschwein
Fredje

2 Cents pro Befehl oder pro „abgeschossenem“ FHT? :stuck_out_tongue:

Ok, dann für GGGss eine Ein-/Ausschaltfunktion des Optimierers:

FHZ_FHTBufferOptimizer( InstanceID: Integer, Status: Boolean);

Und für Entwickler die neue Skripte testen/entwickeln oder wie auch immer eine Funktion die den IPS-FHZ-FHT-Buffer leert:

FHZ_FHTBufferReset( InstanceID: Integer);

Anmerkung am Rande:
Die Funktionalität des IPS-Buffers kann man auch dank der Funktion FHZ_GetFreeFHTBuffer() vollständig selber Coden und dadurch den IPS internen Buffer ersetzen. Das hätte jedoch Nachteile bzgl. der IPS-Variablen für ‚target state IPS Request‘ - diese würden dann nicht mehr richtig funktionieren.

Gruss,
Olli

hehe :wink:

Da bin ich nicht einverstanden : keine funktionen sollen fur GGGss eingebaut werden. Ich unterlege mir den willen des forums.

War nur als ne art warnung gemeint.
Mann konnte einfach (denke ich) ein alarm-label sehen lassen wenn der queue automatisch gecleared gewesen ist. Dieser label konnte mann losschen uber ein reset knopf in das queue fenster.

Have a nice day