Warteschlange mit Optimierungsregeln für FHT-Kommunikation

IP-Symcon Skripte, PHP, SQL (Fragen)
1

Hallo zusammen,

ein Gedanke, der mich schon länger umtreibt ist eine intelligente Warteschlange für FHT-Kommunikation. Hat sich schon mal jemand anderes darüber Gedanken gemacht oder vielleicht schon etwas implementiert? Gerne würde ich das Thema ein wenig erörtern und würde mich auch ggf. an der Entwicklung versuchen oder beteiligen.

Meine Vorstellungen laufen folgendermaßen:

Prinzip:
Da die FHZ nur einen recht kleinen Puffer hat und FHT-Kommunikation nur in kleinen Zeitfenstern abläuft, ist es sinnvoll solche Kommunikationsanforderungen zentral zu sammeln, zu priorisieren und jeweils kurz vor dem entsprechenden Kommunikationszeitfenster auf eine möglichst leere FHZ zu schieben, so daß sie mit hoher Wahrscheinlichkeit unmittelbar zur Ausführung kommt.

Priorisierung:
Die Warteschlange sollte zuerst in der Reihenfolge der folgenden Prioritäten, erst danach chronologisch (FIFO) abgearbeitet werden, so daß die zeitkritischeren Dinge nicht versehentlich ausgebremst werden:

[ol]
[li]Zieltemperatur oder Modus einstellen, Reset
[/li][li]Temperatur- oder Modusabfrage
[/li][li]Programmierung, Zeiteinstellung oder sonstige Abfragen
[/li][/ol]

Überholvorgang:
Wenn das nächste Sendefenster für eine FHT relativ weit in der Zukunft liegt, kann u.U. in der Zwischenzeit ein Befehl für eine andere FHT abgesetzt werden, der eigentlich weiter hinten in der Warteschlange steht. So könnte die Warteschlange vorzeitig reduziert werden und der höherpriore Befehl kann trotzdem zum für ihn frühestmöglichen Zeitpunkt abgesetzt werden!

Verteilung:
Es muß auch berücksichtigt werden, daß für die veschiedenen FHTs ggf. verschiedene FHZs zuständig sind. Ich würde eher dazu tendieren, eine einzige Warteschlange abzuarbeiten und pro Durchlauf die Befehle links liegen zu lassen, die sich an eine FHZ mit zu vollem Puffer richten, als für jede FHZ eine eigene Warteschlange zu verwalten. Das ist aber Geschmackssache.

Optimierung:
Durch Feineinstellung der Parameter

[ul]
[li]Wie lange vor dem beginn des Sendezeitfensters wird ein Befehl frühestens an die FHZ übergeben
[/li][li]Wie lange vor dem Ende des Sendezeitfensters wird ein Befehl spätestens an die FHZ übergeben
[/li][/ul]
wird es sicherlich möglich sein, die Kommunikation sehr weit zu optimieren um auch relativ große Datenmengen in relativ kurzer Zeit an den Mann (die FHT) zu bringen. Ich zitiere hier die Wochenprogramme für ca. 10 FHTs vor einem Feiertag. Evtl. müssen die Feineinstellungen Parameter für unterschiedliche FHZ-Szenarien berücksichtigen: Unterschiedliche FHZ-Modelle, Anbindung über USB, WLAN, USB-over-LAN/WLAN.

Verarbeitung:
Ein Durchlauf zur Abarbeitung der Warteschlange sollte in jedem Fall getriggert werden, wenn ein neuer Befehl bei ihr eintrifft.
Bei jedem durchlauf wird pro FHT für deren nächsten Befehl jeder FHT der früheste Zeitpunkt bestimmt, zu dem er (ausreichend leerer FHZ-Puffer vorausgesetzt) abgesetzt werden kann. Zur frühesten dieser ermittelten Zeiten muß ein erneuter Durchlauf erfolgen. Ist die Warteschlange leer, muss u. U. trotzdem periodisch eine Synchronisation mit den FHT-Sendezeitfenstern stattfinden, denn diese verschieben sich ja mit der Zeit leicht, wenn ich recht informiert bin.

Metainformationen:
Gerade für das Fine-Tuning werden bestimmte Statistik- und Analysefunktionen pro FHZ wichtig sein:

[ul]
[li]Wieviele Befehle befinden sich in der Warteschlange?
[/li][li]Was ist die durchschnittliche Verweildauer?
[/li][li]Wie lauten die nächsten Zeitfenster der angemeldeten FHTs? (Kollisionen?)
[/li][li]Wie häufig kann ein neuer Befehl sofort abgesetzt werden?
[/li][li]Wie häufig muß ein neuer Befehl aufgrund zu vollem Puffer warten?
[/li][li]Wie häufig muß ein neuer Befehl warten, weil er zu lange vor dem nächsten Zeitfenster eintraf?
[/li][/ul]

Vielen Dank an Spawn mit seinem Thread und Projekt eFHT Brick und an pshome und die anderen Teilnehmer für Ihre Beträge zum Thread FHT Uhrzeit setzen. Das sFHTs von Fredje muss ich mir noch genauer anschauen…

Was meint Ihr zu den Gedanken über die Warteschlange? Liege ich völlig daneben? Fehlen wichtige Punkte? Hat jemand sowas schon mal in Angriff genommen? Mag jemand mitmachen an Feinkonzept oder Umsetzung?

Grüßle,
moishe

2

So, ich habe nun mal angefangen, das ganze in Pseudocode zu modellieren und bin weiterhin für Tipps dankbar:


// Nur diese Funktion ist "public"
FHTQ_Enqueue(integer $FHT-ObjectID, integer $FHT_Function [, integer $option [, array $value-struct]])
{
    // determine timestamp
    // find or create FHTQ-Queue and FHTQ-Semaphore
    // determine priority
    // read queue - if there are elements for this FHT older than perhaps 12 hours, return with fail.
    // write function, option, value, timestamp and priority to queue and set $NEWELEMENTINQUEUE using semaphore
    // call or set timer for FHTQ_ProcessQueue()
}

// Diese Funktion sollte i.d.R. über Timer aufgerufen werden:
FHTQ_ProcessQueue()
{
    // ensure being the only such process by using uniqueness-semaphore: quit if semaphore unavailable.
    // find or create FHTQ-Queue and FHTQ-Semaphore
    // read queue and cancel $NEWELEMENTINQUEUE using semaphore
    // if queue is empty or new, find any FHZs and any connected FHTs. Cache which FHZ the FHT is connected to. Remove unconnected FHZs and FHTs and mark long unseen FHTs (POSTION and/or TEMPERATURE) as stale using time last seen (or 1 second past epoch, unless already set)
    // sort queue elements first by priorities and then by timestamps
    // for each element:
       // determine next window
       // if window is $STARTWINDOW, but not too close $ENDWINDOW, call FHTQ_ProcessRequest(integer $FHT-ObjectID, integer $FHT_Function, [integer $option], [array $value-struct])
            // on success dequeue element and go on to process next element
            // on fail determine set FHZ-specific SELFTIMER to just before next window unless already set to an earlier or by $STARTWINDOW close to earlier time.
    // for each FHZ determine whether there are only commands for FHTs marked stale with a timestamp older than one hour in queue and send them a RESET via FHTQ_ProcessRequest() - on success, update stale timestamp to current time.
    // if $NEWELEMENTINQUEUE is set, call or set timer for $SELF
    // release uniqueness-semaphore
}

// Diese Funktion sollte ausschließlich aus FHTQ_ProcessQueue() aufgerufen werden: 
FHTQ_ProcessRequest(integer $FHT-ObjectID, integer $FHT_Function, [integer $option], [array $value-struct])
{
    // determine, whether FHZ-buffer is empty.
    // on not empty return with fail
    // on empty, send command and immediately read bufferspaces
    // if buffer is filled with only one command, return with success, else return with fail
}
3

Hallo Moishe,

ist es eigentlich sicher, dass, wenn beispielsweise in die Queue der FHZ1000/1300 zuerst eine Tempänderung für beispielsweise FHT-„A“ geschrieben wurde, danach für FHT-„B“, FHT-„B“ aber eher Empfangsbereit ist, diese nicht doch dann rausgeht und NICHT erst blöd und stur wartet, bis „A“ die Änderung akzeptiert hat ?

Gruß Rolf

4

Hallo Rolf,

genau diese „dumm rumwarten“ (sowohl auf einen vermeintlich noch nicht nutzbaren Sendeslot als auch auf eine eine FHZ wenn noch eine andere verfügbar ist) machen einige Skripte, die ich hier gesehen habe und genau dem möchte ich Abhilfe schaffen.

Grüßle,
moishe

5

Hallo,

die Befehle in der Warteschlange werden selbstverständlich dann gesendet, wenn die FHT durch Meldung ihre Empfangsbereitschaft signalisieren und nicht in der Reihenfolge in der sie in der FHZ abgelegt wurden.

Der von Rolf beschriebene Fall tritt folglich nicht ein.

Auf der anderen Seite wirft das aber auch das Problem auf, dass man durch Scripting darauf keinen Einfluss hat. Wie ist also der Thread gemeint?

Grüße
Fabian