Eibd direkt mit PHP

[makki]

@thoern: nachdem ich glaube Du weisst was Du tust: es gibt ein .deb für cometvisu und eibd-clients im WG-repo. Auf einem Debian/Ubuntu macht das in alpha das es einfach geht..
Aber jetzt sind wir genau an dem Punkt öffentliche Beta vs. Entwicklerversion

Ich/wir sind da jetzt sicher "selbst schuld" (weil um jeden Entwickler froh!) aber ich möchte wirklich gerne vermeiden, pot. Anwender in diesem Stadium mit jedweden freaky-Details zu PHP,JS oder symlinks abzuschrecken, weil ein Anwender soll&wird davon am ende des Tages nichts können/wissen müssen.
So eine Sache ist aber gedanklich auch schnell als "Freakshow" verbrannt, das würde ich sehr gerne vermeiden.

Also: jeder der mag bekommt gerne Zugriff aufs Beta-Forum, ansonsten gibts SF und wenn jemand die Coding-Sünden aus den cgi-Clients tilgen will wegen mir auch die bcusdk-Liste..

Makki

[Chris M.]

Wirklich tolle Arbeit, was Ihr da macht mit der Comet-Visu. Mir schien dennoch, dass der Fredstarter auch gern ein wenig selbst "basteln" will.
"ich überlege gerade wie ich Eibd am besten per PHP ansprechen kann."

Das darf der Thread-Starter auch gerne. Je nach Level darf man gerne auch den sichtbaren Teil der CometVisu "wegwerfen" und nutzt einfach das bestehende Backend (richtig, das Backend liefern beim WireGate die CGIs) mit dem "CometVisu Client", was eine leicht zu verwendende JavaScript Bibliothek ist.

Das ganze HTML, etc. pp. was dann "optisch Wirksam" ist, kann der geneigte Nutzer dann komplett selbst aufsetzten (z.B. in Kombination mit PHP) - hat aber den Vorteil, dass das was Nervt schon da ist.

Von dem direkten Sprechen des PHP mit dem eibd halte ich vergleichsweise wenig, da PHP eine Server-Technologie ist, die Visu aber auf dem Client sofort auf Aktionen am Bus reagieren soll (z.B. "Fenster offen" soll genau dann erscheinen, wenn das Fenster geöffnet wird. Und nicht irgendwann später. Das geht nur per COMET - und gibt's in dem CometVisu Client bereits fertig)

[franzler]

"Von dem direkten Sprechen des PHP mit dem eibd halte ich vergleichsweise wenig, da PHP eine Server-Technologie ist"

Das verstehe ich jetzt nicht so ganz.

"die Visu aber auf dem Client sofort auf Aktionen am Bus reagieren soll (z.B. "Fenster offen" soll genau dann erscheinen, wenn das Fenster geöffnet wird. Und nicht irgendwann später. Das geht nur per COMET"

Dann hat meine Ajax-Programmierung (PHP/Javascript) nicht mitbekommen, dass sie das eigentlich gar nicht kann.

[Chris M.]

"Von dem direkten Sprechen des PHP mit dem eibd halte ich vergleichsweise wenig, da PHP eine Server-Technologie ist"

Das verstehe ich jetzt nicht so ganz.

Die Frage ist, wo wann wie auf ein Ereignis reagiert werden soll.

Beispiel: Fenster (mit Öffnungsüberwachung) wird geöffnet, auf der Visu ist gerade die entsprechende Seite mit dem Fensterstatus offen => in dem Moment wo das Fenster geöffnet wird, soll sich auch die Status-Seite entsprechend ändern.

Der eibd bekommt die Änderung natürlich sofort mit, da der Sensor ja ein entsprechendes Paket verschickt.

Aber wie geht es dann weiter?

Der PHP kann damit herzlich wenig anfangen - denn dazu müsste er ja per HTTP dem Client das irgendwie mitteilen - aber der kann das gar nicht mitbekommen, da der Client dazu die Verbindung herstellen muss. Kann er aber nicht, da er ja gar nicht weiß, dass etwas spannendes passiert ist.
=> Das geht nur per Pollen, d.h. der Client fragt regelmäßig beim PHP nach, wie der Status ist.
Und wenn das Fenster direkt nach der letzten Anfrage geöffnet wurde, muss halt der User so lange warten, bis der nächste Poll-Request draußen ist.
Nun kann man natürlich die Polling-Zeit sehr kurz halten - aber das skaliert schlecht mit steigender Client-Anzahl und saugt den Akku bei mobilen Geräten schnell leer.

Die Lösung liegt darin, das einfach umzudrehen:
Der Client, d.h. der Web-Browser mit Hilfe von JavaScript, fragt beim Server (und der per binären CGIs, PERL, PHP, Python, was-auch-immer beim eibd) nach ob sich was geändert hat - und der Server antwortet erst, wenn sich etwas geändert hat. D.h. die Verbindung kann gerne mal ein paar Minuten offen bleiben, ohne dass sich etwas rührt.
=> Wenn das Fenster geöffnet wird und das KNX-Paket beim eibd ankommt wird auf der wartenden, offenen Verbindung als Antwort gesendet, dass auf GA1/2/3 jetzt der Wert 1 liegt.

"die Visu aber auf dem Client sofort auf Aktionen am Bus reagieren soll (z.B. "Fenster offen" soll genau dann erscheinen, wenn das Fenster geöffnet wird. Und nicht irgendwann später. Das geht nur per COMET"

Dann hat meine Ajax-Programmierung (PHP/Javascript) nicht mitbekommen, dass sie das eigentlich gar nicht kann.

Ich weiß nicht, was Deine Programmierung macht. Aber das oben beschriebene Verhalten ist das COMET-Pattern (auch bekannt als Long-Polling - nicht zu verwechseln mit klassischem Polling). Das verwendet typischer Weise auch AJAX als Grundlage...

=> Ist Deine Ajax-Programmierung nicht evtl. sogar eine Comet-Implementierung?

Übrigens: das Beckend bei der CometVisu war früher auch mal in PHP geschrieben. Aber damit das im Zweifel auch auf einer Fritz!Box oder anderen kleinen Systemen läuft, haben wir das inzwischen in zwei CGIs gepackt, die in C geschrieben sind.

[franzler]

"Nun kann man natürlich die Polling-Zeit sehr kurz halten - aber das skaliert schlecht mit steigender Client-Anzahl und saugt den Akku bei mobilen Geräten schnell leer."

Absolut deiner Meinung. Nur ich sehe in der Praxis viel zu selten Installationen mit mehreren oder gar vielen gleichzeitigen Visualisierungen. Ein einfaches Ajax-Polling (sinnvoll implementiert) mit kleinen Pollzeiten, die auch ein Alix-Server schafft, ist von der Comet-Variante nur mit der Atomuhr zu unterscheiden. Aber Comet ist natürlich dennoch eine Wohltat für den Server.

Ist Deine Ajax-Programmierung nicht evtl. sogar eine Comet-Implementierung?
Naja, also mein Backend hält dem Vergleich nicht Stand (alles Frickelwerk). Im Moment ein auf einer PHP-Schleife basierender "long poll" auf einen Index der geänderten GA's. Der Rest wird dann wieder per AJAX angefordert.

Ich bin mir durchaus bewusst, dass meine Umsetzung lang nicht in einer Liga mit dem tollen Gemeinschaftswerk Comet-Visu spielt. Aber ich hab Spaß dran, dass selbst umzusetzen (Warscheinlich ist das IT-Masochismus). Die größte Leistung eurer Visualisierung sehe ich ohnehin in der Nutzerschnittstelle. Wenn ich sowas für einen Klienten brauche, dann ist die Basis auf jeden Fall ein Wiregate mit Comet-Visu.

[thoern]

@thoern: nachdem ich glaube Du weisst was Du tust: es gibt ein .deb für cometvisu und eibd-clients im WG-repo.

Kannst mir mal sagen, wie das repo heisst (sources.list) und was ich da genau für ein Paket runterladen soll?

Also: jeder der mag bekommt gerne Zugriff aufs Beta-Forum, ansonsten gibts SF und wenn jemand die Coding-Sünden aus den cgi-Clients tilgen will wegen mir auch die bcusdk-Liste..

Makki

Am Zugriff aufs Beta-Forum wäre ich interessiert. Wo findet man das?

Gruß,
thoern

[makki]

Absolut deiner Meinung. Nur ich sehe in der Praxis viel zu selten Installationen mit mehreren oder gar vielen gleichzeitigen Visualisierungen.

In kurzform: wenn man eh schon weiss worum es geht und wie es richtig geht, sollte man es doch auch einfach so machen
Die Schnittstelle dafür ist im eibd selbst vorhanden!

Ein einfaches Ajax-Polling

Sorry, jegliches Polling ist mit verlaub bulls***. Die Gründe hast Du selbst schon genannt.. Ich bin kein begabter Entwickler aber ich verstehe Technologien und kann faule von geniessbaren Eiern unterscheiden

Im Moment ein auf einer PHP-Schleife basierender "long poll" auf einen Index der geänderten GA's. Der Rest wird dann wieder per AJAX angefordert.

Das klingt fast exakt nach dem was sich ein paar Leute da ausgedacht & auch schon genau so umgesetzt haben, OSS lebt davon das man das Rad nicht jeden Tag neu erfinden muss. (und das ist einer der wesentlichen Gründe warum ich an OSS glaube)

Aber ich hab Spaß dran, dass selbst umzusetzen (Warscheinlich ist das IT-Masochismus).

Verstehe ich nur zu gut, aber ich würde eben lieber jeden fähigen Entwickler dafür begeistern, 100 ungelöste Probleme zu bearbeiten als andere 100, bereits gelöste, nochmal kennenzulernen!

Kannst mir mal sagen, wie das repo heisst (sources.list) und was ich da genau für ein Paket runterladen soll?
Am Zugriff aufs Beta-Forum wäre ich interessiert.

a)

wiregate1:~# cat /etc/apt/sources.list
...
# WireGate repository
deb http://repo.wiregate.de/wiregate wiregate-0.1 main
deb-src http://repo.wiregate.de/wiregate wiregate-0.1 main

b) kein Thema, ist weitergeleitet..

Makki

[thoern]

a)

wiregate1:~# cat /etc/apt/sources.list
...
# WireGate repository
deb http://repo.wiregate.de/wiregate wiregate-0.1 main
deb-src http://repo.wiregate.de/wiregate wiregate-0.1 main

b) kein Thema, ist weitergeleitet..

Makki

Hallo Makki,

vielen Dank. Installation hat funktioniert. Habe mir auch die eibd-clients-Sources gezogen und den Quellcode der beiden CGI's gefunden

Danke,
thoern

[makki]

..und den Quellcode der beiden CGI's gefunden

Schön Wiegesagt, ich wäre auch keinem routinierten C-Programmierer böse, wenn er das mal kurz 100% umschreibt und in richtig macht - ohne pot. buffer-overflows und so
Will sagen, meine Ehre bleibt intakt, wenn man das als Kernschrott identifiziert..

Makki

[thoern]

Schön Wiegesagt, ich wäre auch keinem routinierten C-Programmierer böse, wenn er das mal kurz 100% umschreibt und in richtig macht - ohne pot. buffer-overflows und so
Will sagen, meine Ehre bleibt intakt, wenn man das als Kernschrott identifiziert..

Makki

Also leider bin ich auch kein routinierter C-Programmer. Ich gehe mal davon aus, dass das schon funzen wird. Laufen die auch auf einem AMD64-Debian, oder muss ich die selbst kompilieren? Theoretisch müssten die dort auch laufen...

Gruß,
thoern

[makki]

- Schade, ich suchte jemanden, der meine Quickhacks für die harte Realität brauchbar macht, werd ichs wohl doch irgendwann lernen müssen
- Keine Ahnung, ich würde vermuten das ein AMD64 auch i386-Code ausführen kann aber meine generelle 64bit-Allergie ist da stärker als das ausprobiert zu haben/zu wissen (das Immunsystem fragt halt: for what that sh** ??)

Jedenfalls, die .deb-sources liegen auch da und lassen sich mit dpkg-buildpackage sicher auch auf amd64 bauen (bis auf die kostenlosen Buffer-overflows gibts keine depends zu ext. libs - was ich mittlerweile bereue weil vielleicht wäre es besser gewesen eine libcgi halt herzunehmen..), da es für armel und mips geht und vor 1-2 Versionen auch schon geklappt hat, bin ich mir da sogar fast sicher (man beachte: bcusdk/eibd gibts mittlerweile r0.0.5 [bei MS wäre das 50.0] mit Paketen von mkoegler inkl. amd64!)
Aber das sind eben meine schmutzigen CGI's fürs Cometvisu-Backend nicht drin.. (was wegen schmutzig auch 110% ok ist)
Trotzdem, wiegesagt, die lassen sich auf armel und mips bauen, das sollte mit amd64 dann auch sicher klappen..

Makki

[chrisper]

- Schade, ich suchte jemanden, der meine Quickhacks für die harte Realität brauchbar macht, werd ichs wohl doch irgendwann lernen müssen

Um was geht es denn genau? Gib mir mal ein (kleines) Beispiel.
C, C++, C# programmiere ich. Ist halt eine Frage der Zeit.

[mkoegler]

- Keine Ahnung, ich würde vermuten das ein AMD64 auch i386-Code ausführen kann aber meine generelle 64bit-Allergie ist da stärker als das ausprobiert zu haben/zu wissen

Ein 64 Bit Linux Kernel kann auch 32 Bit Code ausführen. Bei Statisch gelinkten Programmen ist das kein Problem - bei dynamsich gelinken (normalerweise der Default) braucht man die 32 Bit Libraries benötigten installiert.

OpenSuSE zB: ist seit langen ein Biarch System: Ziemlich viele Libraries kann man parallel als 32 und 64 Bit Version installieren. Es geht soweit, das man bis zu einen gewissen Grad) 32/64 Bit Packete mischen kann.

Debian auf der anderen Seite ist eine reine 32 Bit oder 64 Bit Installation. Unter 64 Bit gibt es ein paar Packete, die ein paar 32 Bit Libraries enthalten - wenn man mehr will, muss man mit chroots anfangen. Mit etwas Glück schaffen sie den Multi-Arch Support bis zur nächsten Release.

[mkoegler]

Um was geht es denn genau? Gib mir mal ein (kleines) Beispiel.
C, C++, C# programmiere ich. Ist halt eine Frage der Zeit.

SourceForge.net: BCU SDK with eibd:

[fegge]

Comet Visu

Hallo Zusammen!
Bin relativ neu hier.
Möchte gerne die Comet Visu auf die FritzBox bringen, aber ich finde im Forum nichts brauchbares wie das ganze funktioniert.
Habe nur gefunden das es geht aber nicht wie!!!!!!!!
Kann mir bitte jemand weiterhelfen?
Schönen Gruß
Fegge