HomeControl PHP-Skripte

[enertegus]

Dafür gibt fertige, etablierte Standards, sorry, deswegen kann ich mich daran auch kaum beteiligen, "CF-Joins" sind mal was von lächerlich, das dämlich als umschreibung IMHO garnicht reicht.

Das mit den Joins sehe ich grundsätzlich ähnlich: Es wäre ziemlich "böld", wenn man jede GA wieder im EibPC und Homecontrol verknüpfen müsste - das ist mit CF leider so, aber das soll -wie oben bemerkt ja hier- nicht so werden (quasi vollzugriff auf den Bus). Um die Initalisierung des Servers zu handeln, werden wir wohl noch zwei Funktionen im EibPC reinbauen, sodass Zustände direkt im EibPC abgefragt werden können und nicht etwa ein "read" auf den Bus notwendig wird.
Am Ende soll nur das Makro eingebunden werden, und damit ist die Visu mit dem EibPC verbunden, fertig. Mit dem EibPCHomecontroll kann dann direkt gearbeitet werden. ohne für die Visu den EIbPC noch irgendwie programmieren zu müssen.
Daher sollen zumindest noch Schaltuhren im Makro (quasi unter der Haube) eingebaut werden.
Ob das nun aus Protokollsicht klingt "wie ein alter Hit von Modern Talking", wäre mir egal, Hauptsache es ist einfach für den Anwender.
Das Protokoll ist ja zudem offen für alle, die es modifizieren wollen.

[enertegus]

Ja, genau hier liegt wohl das Problem... der WebServer bedient mehrere Clients, davon weiss aber der eibPC nichts. Für den eibPC verhält sich der WebServer wie ein (einziger) ganz normaler CF Client.

Dann müssen wir an dieser Stelle wohl noch was verbessern...

[Gast]

Hallo Makki,

mit CommandConfusion voll auf dem falschen Dampfer.. HTTP, XML, JSON

Ein gutes Protokoll zeichnet sich auch durch Einfachheit und einfache Übertragbarkeit auf andere Systeme aus. Freilich ist das mit JSON, XML etc. auch zu erreichen. Dafür benötigen wir allerdings auf der eibPC Seite noch eine entsprechende Infrastruktur, sprich Funktionen, die in der Lage sind, XML und/oder JSON auch zu interpretieren. Was nicht ist, kann noch werden. Obwohl ich ein Freund von XML bin, muss man dabei aber auch beachten, dass der Overhead bei XML, besonders bei wenig Nutzdaten extrem ist. JSON ist allerdings auch so ein Bastelprotokoll... passt halt gut zu Javascript...

Unsere Probleme löst freilich auch keines Deiner Vorschläge, denn im Moment ist unser Kommunikationsprotokoll einfach noch unvollständig, zumindest in Bezug auf die Multiclientfähigkeit der Webserver basierenden Lösung. Aber das bekommen wir auch noch in den Griff, da es nicht an den gewählten Mitteln, sondern der Realisierung unsererseits liegt.

Ob der Webserver früher oder später in den eibPC verlegt wird, wird sich noch zeigen. Damit dürfte sich dann auch das Problem "Sonderport" lösen lassen. Auch hier ist aber mit Overhead zu rechnen. Ich würde allerdings noch ein wenig damit warten. Das W3C ist dabei, den HTML5 Standard endgültig zu verabschieden. Damit kehrt auch das WebSocket Konzept in den HTML Standard ein. Das bedeutet bidirektionale Kommunikation mit jedem HTML5 kompatiblen Browser, Chrome kann das heute schon.

Gruss
Arno

[makki]

Ich glaub ich muss mir das erstmal in der aktuellen Fassung anschauen (Schande über mein Haupt, Zeit<<Baustellen..), weil den Antworten entnehme ich: fürchte noch nicht ganz verstanden zu haben was da nun so genau passiert.
Irgendwie kommt das mit Homecontrol(lokal|PHP-Server) spricht CF mit PHP-Server (klingt grundsätzlich schon besser) der mit CF-Port des eibPC spricht halt irgendwie so wie Brust-Knie-Auge vor..

Mal unabhängig vom konkreten Client im Browser: Ich bzw. primär Chris M stricken da halt an was doch stark Artverwandten und wir haben da vor geraumer Zeit schon (weil das Thema bei mir nun auch nicht unbedingt in den Top10 steht) schon sehr viele Tests&Erfahrungen gesammelt was Protokoll, Effizienz usw. angeht.. z.B. bzgl. Skalierung auf 10,100 oder mehr Clients und wie der Akku dort nicht leergelutscht wird..
Ab dem IP-Stack des Clients bzw. der praktischen Anwendung kann ich auch glaube ich mitreden, bei DOM,CSS,JS&Co bin ich eher "Zuschauer"
Bis HTML5, so schön das ist&wird, will ich damit aber auch nicht warten. Das geht ja nach allem was ich sehe auch heute schon (zwar teilw. blutig, aber es geht)

Ich sehe bei dem Ansatz das "Backend" (in eurem Fall wohl aktuell PHP-Server/eibPC) da durchaus als wechselbare Komponente, die ob das nun ein (PHP|Web)Server, mh oder vielleicht sogar KNXnet/IP direkt ist, hängt im Optimalfall nur vom gewählten (und implementierten) backend ab.
Aber das Framework im JS-Client muss das natürlich halbwegs hergeben und jetzt lehne ich mich ganz weit aus dem Fenster: entsprechendes Kapseln und abstrahieren vorausgesetzt sollte das doch drin sein.
Warum? Weil sich damit IMHO die "kritische Masse" an interessierten Anwendern und vor allem Entwicklern deutlich steigert und damit auch schneller Fortschritt, Qualität (usw..)

Ob sich da Synergien ergeben könnten? Jedenfalls IMHO zielführender wenn 10 statt 5 an einer Sache sind. Nicht das ich jetzt die Lösung im Ärmel hätte, aber ein paar Puzzleteile mit denen ihr euch gerade ärgert glaube ich schon..

Zu meiner Verteidigung darf ich vielleicht noch hinzufügen: Wenn man erstmal Download suchen und zwei Patches applien muss, sowie davon ausgeht, das das ganze mit dem IMHO eben für so ziemlich alles untauglichen CF-Protokoll spricht (was wohl nicht so ist?), ists ehrlichgesagt aber schwierig, da die nötige Motivation herzustellen das auszuprobieren..

Makki

[Gast]

Hallo Makki,

Download ist einfach, siehe hier: https://knx-user-forum.de/eibpc/9233...mecontrol.html

Patches zusammensuchen bekommen wir auch noch in den Griff. I.d.R. baue ich Patches z.B. von Mike spätestens mit der nächsten Version ein, so dass obiger Link ausreicht.

Für einen Linuxer wundert mich aber Deine Einstellung. Immerhin ist es ein Open-Source, Public Domain Projekt. Da muss man halt mal hier und dort ein wenig Hand anlegen und sich eben damit tiefer befassen.

Die Diskussion im anderen Forum ist interessant. Wenn die dort diskutierten Konzepte ausgereift sind und tatsächlich einen Vorteil gg. der aktuellen Umsetzung bieten, können wir das gerne vertiefen. Ich persönlich setze jedoch im Moment auf das WebSocket Protokoll, da sich dadurch viele Klimmzüge, die wir heute mit dem COMET Konzept machen einfach erübrigen.

Durch die Kapselung, die ich vorgenommen habe, schätze ich den Aufwand für die Umstellung von HomeControl auf ein komplett anderes Protokoll auf vllt. 1-2 Tage zzgl. Tests. Voraussetzung dafür natürlich ist, dass man sich ein wenig in jQuery vertieft, um dessen Umsetzung objektorientierter Konzepte zu verstehen. Also nur zu...

Gruss
Arno

[makki]

Für einen Linuxer wundert mich aber Deine Einstellung. Immerhin ist es ein Open-Source, Public Domain Projekt. Da muss man halt mal hier und dort ein wenig Hand anlegen und sich eben damit tiefer befassen.

Das sollte keine Kritik werden und ist bestimmt nicht meine Einstellung sondern eher ein Hinweis: ich bin jedenfalls schon zweimal gescheitert das "mal eben kurz" auszuprobieren (vermutlich primär wegen dem CF-Joins-Zeugs, was ich nahe 0 kenne, nicht weiss wie es "in real" aussehen sollte und ehrlichgesagt auch eigentlich garnicht kennen will..)
Wenn ich nun nicht ganz dämlich bin, heisst das, das auch andere scheitern werden, was ich einfach schade fände..

Voraussetzung dafür natürlich ist, dass man sich ein wenig in jQuery vertieft, um dessen Umsetzung objektorientierter Konzepte zu verstehen. Also nur zu...

Gut, ist jetzt nicht gerade meine Welt aber man tut was man kann hab mich heute mal etwas durchgewühlt, eigentlich fast schon übersichtlich. Websockets hab ich mir auch mal näher angesehen, ehrlichgesagt sieht mir das aber noch nicht so ganz "ready for primetime" aus.. (Hier&heute verfügbare Browser, hier&heute verfügbare Webserver..)
Aber ich lese weiter und arbeite besser mal mein Backlog ab
Wiegesagt, eigentlich finde ich das Teil total cool, zuletzt funktioniert hat es bei mir aber mit mh (was ich als Backend wiederum "nicht so doll" fand..)

Makki

[mike]

Noch mal kurz zurück zum eigentlichen Thema:
Mir ist noch aufgefallen dass noch ein kleiner Patch fehlt. Browser mögen es anscheinend nicht (Chrome und Mozilla) wenn während des Ladens einer URL dieselbe URL in einem anderen Fenster geladen wird. In dem Augenblick wird dann das erste Laden abgewartet.
Das Problem tritt hier auf beim "Laden" der refresher.php. Öffnet man den Designer und möchte noch ein zweites Fenster mit der Runtime öffnen, dann bleibt die Runtime stehen, da auf das Beenden des Ladens der refresher.php im Designer gewartet wird. Da dieses "Laden" aber nie endet, hängt das endlos.

Mögliche Lösung ist der Patch, der an die URL etwas Zufall ranhängt.

Mike