Ankündigung

Einklappen
Keine Ankündigung bisher.

Misterhouse - Eigene Weboberfläche

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Chris M.
    antwortet
    Ich kenne MH zu wenig um hier Aussagen über die optimale Implementierung sagen zu können.

    Reim vom (theoretischen) Ressourcen-Verbrauch müsste eine offen gehaltene Verbindung bei sinnvoller Implementierung deutlich Ressourcen schonender sein.
    Da der Unterschied zum Pollen eh fließend ist, könnte man Gäste der Visu ja zu Lasten der Response in die resourcen optimale Ecke schieben...

    Was ist denn so normal bei Gastzugängen? 40 gleichzeitige User würde ich schon als sehr hoch einschätzen... (Selbst eine Größenordung weniger Gäste würde ich als viel erachten)

    Einen Kommentar schreiben:


  • NilsS
    antwortet
    yep das ist deutlich gesünder.. das sind immer 40 Anfragen pro Sekunde die alle das gleiche kriegen. Ansonsten hast du 40 offene Anfragen die ja auch noch alle die Resourcen die sich ändern überwachen müssen), Da wärst du dann bei shared memory und co.

    Einen Kommentar schreiben:


  • mike
    antwortet
    Zitat von NilsS Beitrag anzeigen
    Denk mal an einen Server mit Gastzugang 40 User lassen die Seite mal so 10 Minuten offen.
    Ist das für den Server gesünder in der Zeit 40*10*60 = 18000 Anfragen zu beantworten? Ich habe da keine Erfahrung. Scheint mir aber auch nicht so ohne zu sein.

    Einen Kommentar schreiben:


  • NilsS
    antwortet
    Zitat von mike Beitrag anzeigen
    Gleichzeitig wird nach dem Laden der Webseite zyklisch die Liste der auf der Seite dargestellten Items und deren Zustand an den Server geschickt. Dieser überprüft ob sich die Zustände inzwischen geändert haben und schickt dann eine Liste mit den Änderungen an den Client zurück. Hat sich nichts geändert, so wird eine leere Liste geschickt.
    Per Javascript werden die Änderungsmeldungen (bei denen auch ein neuer Grafikname dabei ist) in die Web-Seite eingepflegt. Das ganze geschieht sekündlich.
    sorry irgendwie überlesen, bin dann im diff drüber gestollpert

    Eine Optimierung hätte ich noch: Der Http-Server soll den Request so lange festhalten bis sich ein Zustand ändert und erst dann eine Antwort schicken. Dann würde man sich das dämliche Pollen sparen und die Reaktion wäre noch schneller. Problem hierbei ist nur, dass MH meckert wenn man einen Request länger als 2 Sekunden festhält und ich habe keine Idee, wie man den Zustandscheck in die Hauptpollschleife von MH hinein bekommt.
    lass es lieber das frisst nur speicher auf dem Server, lass den Server lieber sowas wie nochanges antworten, das verbrauch weniger Resourcen. Denk mal an einen Server mit Gastzugang 40 User lassen die Seite mal so 10 Minuten offen.

    Einen Kommentar schreiben:


  • NilsS
    antwortet
    es macht ja aber nur Sinn wenn du Statis dynamisch auf die Seite kriegst.
    die Abfragen kannst du auch mit target='devnull' in den Hintergrun befördern wenn du einfach ein frame im Hintergrund anlegst der 'devnull' heißt.

    Um änderungen zu erfassen muss der "server" aber wissen was alles auf der Seite ist damit er diese Meldungen auch in die regelmäßigen ajax anfragen packen kann.

    PS: du solltest die readystates abfangen. für den aufruf kannst du sonst auch einen syncronen (mlHttpReq.open('POST', strURL, false); zeile ~245 machen.

    Einen Kommentar schreiben:


  • mike
    antwortet
    Zitat von RaK Beitrag anzeigen
    Wer wäre denn mal in der Lage ein proof-of-concept zu erstellen?
    Ich habe mich mal daran versucht. Im Anhang ein entsprechender Patch.

    Um das zu verwenden muss man gd=1 in der mh.private.ini gesetzt haben. Und das GD-Paket muss natürlich installiert sein.

    Das ist nur eine technische Demo. Das Prinzip ist folgendes: Alle Statusänderungen werden per XMLHTTPRequest vorgenommen. Drückt man auf eine Grafik um ein Licht einzuschalten, so wird ein Request an den Http-Server (also MH) geschickt. Die Antwort auf diesen Request wird weggeschmissen.

    Nun hat man einen Zustand fast wie in der IPhone-Visu.

    Gleichzeitig wird nach dem Laden der Webseite zyklisch die Liste der auf der Seite dargestellten Items und deren Zustand an den Server geschickt. Dieser überprüft ob sich die Zustände inzwischen geändert haben und schickt dann eine Liste mit den Änderungen an den Client zurück. Hat sich nichts geändert, so wird eine leere Liste geschickt.
    Per Javascript werden die Änderungsmeldungen (bei denen auch ein neuer Grafikname dabei ist) in die Web-Seite eingepflegt. Das ganze geschieht sekündlich.

    Schaltet man also das Licht ein, so sieht man spätestens nach rund 1Sekunde den geänderten Zustand.

    Eine Optimierung hätte ich noch: Der Http-Server soll den Request so lange festhalten bis sich ein Zustand ändert und erst dann eine Antwort schicken. Dann würde man sich das dämliche Pollen sparen und die Reaktion wäre noch schneller. Problem hierbei ist nur, dass MH meckert wenn man einen Request länger als 2 Sekunden festhält und ich habe keine Idee, wie man den Zustandscheck in die Hauptpollschleife von MH hinein bekommt.
    Angehängte Dateien

    Einen Kommentar schreiben:


  • NilsS
    antwortet
    Zitat von mike Beitrag anzeigen
    Neu wäre es, wenn sich Text/Grafik ändert, wenn du auf einen Lichtschalter drückst.

    So etwas ist bei Ajax eigentlich nicht vorgesehen. Mit Ajax will man erreichen, dass auf Nutzeraktionen schnell reagiert wird. Die Ereignisquelle ist also der Nutzer der vor dem Bildschirm sitzt und rumklickt.

    Nun befindet sich die Ereignisquelle aber "auf dem Server". D.h. die Web-Oberfläche müsste "von aussen" erreichbar sein, damit der Server im Falle eines Ereignisses eine Meldung schicken kann. Das kann Ajax aber meines Wissens nach nicht.

    Alle Beispiele im Internet die Serverstatusänderungen anzeigen, machen das per Polling, d.h. in Javascript wird zyklisch ein Request an den Server geschickt und nach dem aktuellen Stand gefragt.
    ja so soll es doch auch sein, entweder im 1sec Takt eine Anfrage an den Server und der Server antwortet mit <nix /> ....
    oder Anfrage mit timeout und der Server verzögert die Antwort bis Timeout/Event.

    Die erste Variante ist hier aber sicher vorzuziehen, da Sie einfacher zu implementieren ist und 2. weniger Serverresourcen braucht. die 1 - 1.5 Sec verzögerung die zwischen Licht an und anzeige auf der Visu vergehen ist zu vernachlässigen.

    Einen Kommentar schreiben:


  • mike
    antwortet
    Zitat von Bodo Beitrag anzeigen
    Hallo Rak

    Also eine Veränderung von Text beim drücken eines Buttons wäre mein Anfang.

    xajax example

    Beispiel ist mit php und xajax mehr gekupfert als im Detail verstanden.
    Das ist aber nichts neues. Das macht die iPhone-Visu von RaK ja auch schon.

    Neu wäre es, wenn sich Text/Grafik ändert, wenn du auf einen Lichtschalter drückst.

    So etwas ist bei Ajax eigentlich nicht vorgesehen. Mit Ajax will man erreichen, dass auf Nutzeraktionen schnell reagiert wird. Die Ereignisquelle ist also der Nutzer der vor dem Bildschirm sitzt und rumklickt.

    Nun befindet sich die Ereignisquelle aber "auf dem Server". D.h. die Web-Oberfläche müsste "von aussen" erreichbar sein, damit der Server im Falle eines Ereignisses eine Meldung schicken kann. Das kann Ajax aber meines Wissens nach nicht.

    Alle Beispiele im Internet die Serverstatusänderungen anzeigen, machen das per Polling, d.h. in Javascript wird zyklisch ein Request an den Server geschickt und nach dem aktuellen Stand gefragt.

    Einen Kommentar schreiben:


  • NilsS
    antwortet
    so hab mal drauf geguckt.

    Anmerkungen:
    kein ajax: macht aus meiner Sicht auch kein Sinn per javascript ein dutzend Anfragen zu machen nur um die Statis einer Seite aus dem HTML zu parsen. Es sollte nur eine Antwort die alles für diese Seite enthällt zurückkommen.

    Frames: müssen heutzutage nicht sein.


    hab mal eben den source runtergeladen, da ist doch schon was code/examples/SOAP_examples.
    Also eine Möglichkeit auf die Objekte mit XML zuzugreifen wäre da.

    Den Aufbau der Seiten und die Plazierung der Elemente würde ich dann auch von diesem PerlSkript machen lassen.
    Dann sind wir wieder da wo wir angefangen haben.

    XML Datenbank die sagt was wo ist.(die Seiten definiert)
    Server (soapcgi.pl?) ....
    Javascript Client (siehe soapdemo.html, soaptest.html) ++ ein bisschen xml in HTML Javascript
    evtl. Sitebuilder aus Javascript heraus, da das Seitenbauen (erst Recht in XML) eins der wenigen Dinge ist die KEINEN SPASS machen an der CLI

    Einen Kommentar schreiben:


  • Bodo
    antwortet
    Zitat von NilsS Beitrag anzeigen
    Hat jemand vielleicht nen Misterhouse Gastzugang?
    Hi

    Misterhouse

    Ist noch ohne Funktion.

    Einen Kommentar schreiben:


  • NilsS
    antwortet
    Ich hab misterhouse noch nie verwendet daher weiß ich nicht was es schon gibt und was nicht.

    Hat sich hier im Thread so angehört als ob das irgendwie nicht ginge.

    EDIT:
    Hat jemand vielleicht nen Misterhouse Gastzugang?

    Einen Kommentar schreiben:


  • mike
    antwortet
    Die Teilprojekte in der Projektverwaltung sehen so aus, als ob Misterhouse komplett neu geschrieben werden soll ...

    Warum nicht einfach das bestehende Erweitern ?

    Einen Kommentar schreiben:


  • NilsS
    antwortet
    Projektverwaltung

    So das Projekt ist in der Projektverwaltung
    https://knx-user-forum.de/project.php?projectid=4

    Einen Kommentar schreiben:


  • EPIX
    antwortet
    nur malo so als Gedanke:

    es gibt doch eine opensource Weboberfläche für KNX:
    WEBknx von Jeff2000...

    kann man die nicht "umstricken"?

    Einen Kommentar schreiben:


  • NilsS
    antwortet
    Ich wollt auch mal n bisschen Senf dazugeben auch wenn ich eigentlich mit dem HS bedient bin.

    Die Visuseite sollte als Datenbank (evtl. XML) erstellt sein in der die Seite einen einmalige ID haben mit der sie identifiziert werden kann.
    Dann sollten die Elemente die die Seite enthällt mit Position und vorallem der Informationspfad(z.B. KNX/1/4/23 oder ähnliches) enthallten sein.
    Style evtl. aussen vor und mit CSS machen.
    Jetzt kann nämlich sowohl der Clientseite Javascript Teil die Seite aus dem XML aufbauen und danach die async ajax Anfrage and den Serverteil mit der eindeutigen SeitenID stellen. Als das auch der Serverteil auf die XML zugreift und weiß welche Elemente sie auf veränderung überwachen muss.
    Das ganze mit nem Timeout von sagen wir 60-120sek und die anzahl der Ajaxanfragen sowohl Clientseitig als auch Serverseitig überwachen.

    Einen Kommentar schreiben:

Lädt...
X