HomeControl PHP-Skripte

[mike]

Die Homecontrol PHP-Skripte laufen nicht mit PHP5 in Standardeinstellung. Das liegt an einer in PHP5 geänderten Default-Einstellung für einen Parameter (magic_quotes_gpc).
Anbei ein Patch der das Problem löst.

Andererseits verstehe ich diese PHP-Skripte überhaupt nicht. Die lokale Variante der Kommunikation öffnet eine Verbindung die in 2 Richtungen verwendet wird. So verlangt es das Protokoll (Commandfusion) ja auch. Die Verbindung wird geöffnet, das Passwort wird geschickt, dann kommt die Antwort, ob das Passwort korrekt war und man schickt "i=1" um den aktuellen Status aller Objekte zu erhalten. D.h. das ganze ist ein Dialog. Nicht zu vergessen der Heartbeat ...

Die Skripte führen aber Monologe. Für jedes Schreiben zum eibPC wird ein neuer Socket aufgemacht. Der refresher.php macht einen Socket auf und wartet ohne Passwort, ohne "i=1" und ohne Heartbeat das der eibPc was zu ihm sagt. Wenn der eibPc das aber machen würde, dann wäre das ein Bug oder?

Verwende ich Homecontrol mit eibPC über die PHP-Skripte, dann funktioniert das nicht. Ich kann im Wireshark (network sniffer) die Kommunikation sehen. Zwischen Browser und Web-Server gibt es einen Dialog. D.h. Browser spricht write.php an und erhält eine Antwort. Die Kommunikation zwischen Web-Server und eibPc ist aber nur in Richtung eibPc. Dieser bestätigt zwar Telegramme, sendet aber keine Antworten. Er führt auch keine Aktionen aus, d.h. es werden keine EIB-Telegramme gesendet. Meiner Meinung nach ein vollkommen richtiges Verhalten, da ja kein "Login" stattgefunden hat.

Wenn Homecontrol in der lokalen Variante läuft, funktioniert es besser. Es findet ein richtiger Dialog statt und ich kann auf dem EIB schalten und bekomme auch Rückmeldungen. Was nicht funktioniert ist das Aktualisieren des Status, wenn ein Raum geladen wird. Dort wird "i=1" zum EibPc geschickt. Der eibPC schickt aber nicht den Status aller joins als Antwort, sondern nichts. D.h. ein Raumwechsel (anderes Panel laden) ist praktisch nicht verwendbar. Das scheint aber ein Problem des eibPc zu sein.

Wie funktioniert das bei euch?
Kommt da auf "i=1" tatsächlich eine Antwort?

Mike

[Gast]

Hallo mike,

zugegebenermaßen habe ich die Web-Variante nur mit dem Simulator getestet und bin davon ausgegangen, dass sich das beim eibPC genau so verhält.

Die Idee ist folgende:
write.php und refresher.php machen jeweils einen eigenen Socket zum eibPC auf. write.php schließt nach dem Schreiben das Socket sofort wieder. Meine Erwartung war bisher, dass der eibPC die Antworten an alle offenen Sockets zurückschickt und somit refresher.php also die Antworten mitbekommt. Ich glaube, da ist mein Denkfehler... ich war bisher davon ausgegangen, dass die Sockets zu einer IP Adresse zusammengefasst sind. Das scheint dann wohl nicht so zu sein.

Die Lösung:
Wir implementieren wieder Deine ursprüngliche Lösung des refreshers für Misterhouse. D.h. die Verbindung bleibt nur so lange offen, bis sich wieder etwas ändert, write.php und refresher.php werden also zusammengefasst. Den Heartbeat muss ich dann wohl innerhalb des Webservers implementieren.

Oder weißt Du eine Lösung, wie ich in einer offenen http Verbindung vom Client aus weitere Daten an den Server schicken kann?


Gruss
Arno

Edit: Habe gerade mich wieder ein wenig eingelesen, evt. wären named pipes eine Lösung, damit können writer.php und refresher.php "miteinander reden". Die Idee dahinter ist, die gesamte Socket Kommunikation der refresher.php zu überlassen. writer.php schreibt die Befehle in die Pipe, diese werden wiederum durch refresher.php ausgelesen und an den Socket weitergereicht. So müßte dass doch funktionieren, oder?

[mike]

Die Implementierung in Misterhouse war davon getrieben, dass ich möglichst kurze Verbindungen wollte. Allerdings hat das den großen Nachteil, das bei einem Verbindungsneuaufbau der im Browser bekannte Status mitgeschickt werden muss. Ansonsten verliert man u.U. Statusänderungen.

Die von dir nun implementierte Variante, dass eine Verbindung aufgebaut wird und dann in dieser Verbindung der Server als erstes die aktuellen Stati sendet, finde ich viel besser. Der "Nachteil" dass diese Verbindung u.U. ewig offen steht denke ich ist kein großen Problem. Natürlich kann man so keinen Webserver betreiben, der hunderte oder tausende solche Clients versorgt, aber für die hier vorgesehene Anwendung denke ich ist das ok. Der Webserver kann ja die Verbindung kürzer machen, indem er sie einfach schliesst. Die (noch aktiven) Clients bauen die Verbindung dann erneut auf.

Da PHP ein "shared nothing"-Ansatz verfolgt ist das zusammenführen von write.php und refresher.php natürlich eine harte Nuss. Es gibt in PHP ein Session-Konzept. Mit dem hatte ich schon mal gespielt, aber dort kann man keine Sockets verwenden. Die Idee mit der Named-Pipe ist natürlich super. Über das _SESSION-Array kann man den Namen der Named-Pipe an alle anderen Skripte verteilen und somit alle Datenströme in refresher.php bündeln. Aber gibt es unter Windows "named pipes"?
Ich kann ja mal versuchen das unter Linux zusammenzubauen .. Wird aber ein paar Tage dauern.

Da du ohne eibpc getestet hast, denke ich das der eibpc an dieser Schnittstelle noch unreif ist oder?
Wie gesagt auf "i=1" soll laut CF-Protokoll der Server (also eibpc) den aktuellen Zustand aller joins senden. Wobei Joins im Aus-Zustand nicht geschickt zu werden brauchen (ungünstig für Homecontrol, da HC auch den Zustand "unbekannt" kennt).
Bei meinem eibpc kommt aber nichts zurück. Insbesondere Frage ich mich wie das bei der Protokollerweiterung (die "auto-joins", die über die Gruppenadresse angesprochen werden) laufen soll. Dem eibpc bleibt ja eigentlich nichts weiter übrig als den Zustand aller bekannten Gruppenadressen und den Zustand aller definierten Joins zu senden. Das müsste also wahrscheinlich noch eingebaut werden. Wobei das Senden der Auto-Join-Zustände einen echten CF-Client wahrscheinlich verrückt machen würde.

Ich teste hauptsächlich mit einem linknx-Backend (und einem ein klein wenig modifziertem linknx). Dort klappt das Super (in der lokalen Variante). Es dauert beim Laden eines Panels allerdings einen Augenblick (rund 1 Sekunde) bis die Stati aktualisiert sind.

In deiner Refresher-Mimik ist vorgesehen, dass Homecontrol weiß welche Objekte dargestellt werden. Hier gäbe es beim linknx-Backend die Möglichkeit Anhand dieser Information nur den Status der wirklich zur Anzeige kommenden Objekte abzufragen und zu überwachen. Mit dem CF-Protokoll und insbesondere mit der Auto-Join-Mimik hat man da wohl keine Chance. Es sei denn das Protokoll wird noch weiter verbogen, indem man z.B. eine Folge von "i=d100 i=d101 i=ga-2/3/4" schickt und somit nur die Stati diverser Objekte abbonniert.

Dann könnte man auch die echten CF-Clients mit reinem CF versorgen (bei i=1 kommen nur Zustände der richtigen Joins zurück) und könnte die Auto-Join-Erweiterung vernünftig verwenden, indem Homecontrol nur diverse Auto-Join-Objekte abbonniert ...

Mike

[mike]

Hier jetzt ein Patch der wirklich die Kommunikation mit dem Backend über Web ermöglicht.

Statt named-pipes habe ich einen Socket verwendet. Die Scripte entsprechen dem shared-nothing-Prinzip von PHP. Es werden auch keine Sessions verwendet. Das ganze sollte auch unter MS-Windows laufen. Habe ich aber nicht probiert.

An write.php sind keine Änderungen nötig. Die refresher.php baut eine Verbindung zum Backend (eibPc) auf und erstellt einen Socket für die Kommunikation in Richtung Backend (für write.php). Die Socket-Nummer wird zu Homecontrol zurückgemeldet. Homecontrol verwendet diese Socket-Nummer dann mit write.php um, in die geöffnete Verbindung zum Backend, Daten zu schicken.

Damit funktioniert die Kommunikation mit eibPC und linknx als Backend. Wobei der eibPc als Backend, wegen der zuvor bereits beschriebenen Probleme nicht wirklich zu gebrauchen ist.

Mike

[Gast]

Hallo Mike,

werde ich heute Abend gleich mal einbauen... sieht ganz danach aus, als müsste ich zum Wochenende mal eine neue Version rauslassen.
Ich war heute bei Enertex, wir haben das Ganze nochmal an der dortigen Installation unter Linux ausgetestet. Der Heartbeat in HomeControl muss noch von 5 auf 3 Sekunden verkürzt werden, da der eibPC ansonsten die Verbindung aufgrund eines Timeouts schließt. Dadurch könnte das eine oder andere Problem mit der Aktualisierung von Zuständen entstehen.

Ich denke, es ist kein Problem, das Protokoll dahingehend zu erweitern, dass der Zustand bestimmter Joins an HomeControl zurückgeschickt wird. Dazu müssen ja lediglich die Makros entsprechend angepasst werden. Ich versuche mich mal daran. Parallel dazu arbeitet Enertex an dem Makro für die direkte Verwendung der Gruppenadressen (ohne Joins).

Da ich den Verteiler momentan noch bei mir in der Wohnung stehen habe kann ich endlich auch ein paar Real-Life Tests machen.

Gruss
Arno

[Gast]

Hallo,

ok, Test ist soweit durchgelaufen. Bleibt noch das Problem mit dem unbekannten Zustand beim Starten...
Ich würde vorschlagen, dass wir das Protokoll so erweitern, dass der Join-Zustand bei Angabe von "[JoinId]=?" vom eibPC Makro erneut gesendet wird. So können wir auch das selektive Auslesen beim Laden eines Panels realisieren. Die Änderung muss nur im CF-Makro durchgeführt werden. Die Kompatibilität zu anderen CF Clients wird dadurch nicht beeinträchtigt.

Gruss
Arno

[mike]

Ich habe mir die CF-Macros mal angesehen.

Folgende Probleme sind aufgefallen:
1.) Es wird nur ein Client unterstützt. Mehrere Clients führen zu "wilder" Kommunikation, da immer der Client, der zuletzt etwas an eibPc gesendet hat die Antworten erhält. Da mehrere Clients jeweils ihr Heartbeat schicken geht das ziemlich durcheinander.
Das hat auch zur Folge, dass man je Visualisierung bzw. iViewer einen eigenen eibPC benötigt. Wenn man Homecontrol benutzt, darf man neben dem Designer keine Runtime laufen lassen.

2.) Der cycle der den Heartbeat überwacht muss mit dem Verbindungsaufbau synchronisiert sein. Das hängt auch ein bischen an 1. bzw. an der Art wie eibPc mit TCP-Verbindungen umgeht. Ein Verbindungsaufbau kann man nur dadurch erkennen, dass sich Name_Port oder Name_IPC ändert.
Wenn man im Browser die Seite neu lädt oder im iViewer neu verbindet, dann läuft der "alte" cycle ja noch. Wenn zwischen dem Ende der alten Kommunikation und dem ersten Heartbeat der neuen Kommunikation genau die Zykluszeit liegt, dann wird die gerade aufgebaute neue Verbindung wieder rausgeworfen. Gerade beim "Seite neu laden" im Browser kommt man sehr leicht in den Zeitbereich, da ein Reload ja sofort beginnt, aber am Anfang eine Verzögerung hat (für das Laden der Seite etc.). D.h. der Reload ist zu schnell, als das die alte Verbindung korrekt entsorgt wird, aber zu langsam um noch innerhalb des Zyklus einen erneuten Heartbeat zu senden.

3.) i=1 wird nur einmal ausgeführt. Richtig wäre bei jedem i=1 mit dem aktuellen Status zu antworten. Schlimmer noch, auch bei Verbindungsneuaufbau funktioniert i=1 nicht, wenn er innerhalb des Heartbeat-Timeouts passiert. Für letzteres wäre es ausreichend, bei erfolgreicher Passwortüberprüfung Name_Init=AUS zu setzen. Dann geht es einmal nach jeder Anmeldung.

Schön wäre es, wenn die Makros so umgeschrieben würden, dass viele Clients unterstützt werden. Da würden mir Arrays in den Sinn kommen, in denen über Port+Ip indiziert wird. Läuft der Heartbeat aus, dann würde das Array aufgeräumt werden.

Mike

[mike]

Ich würde vorschlagen, dass wir das Protokoll so erweitern, dass der Join-Zustand bei Angabe von "[JoinId]=?" vom eibPC Makro erneut gesendet wird. So können wir auch das selektive Auslesen beim Laden eines Panels realisieren. Die Änderung muss nur im CF-Makro durchgeführt werden. Die Kompatibilität zu anderen CF Clients wird dadurch nicht beeinträchtigt.

Das halte ich für eine gute Idee. Besser noch als die Idee mit dem selektiven Abo via i=[JoinId], da sich der eibPc dazu nichts speichern muss. Homecontrol wird dann zwar mit zuviel Statusinformationen versorgt, aber das ist ja nicht schlimm.

Mike

[SnowMaKeR]

Ich geb gleich mal zu, dass ich mich mit dem HomeControll noch nicht beschäfftigt habe (Sommerloch :-) )

1.) Es wird nur ein Client unterstützt. Mehrere Clients führen zu "wilder" Kommunikation

Geht das nicht über die "Namens" Konfiguration?
Man muss dann zwar pro Endgerät alle Definitionen anlegen, was das alles aufbläht, aber es müsste funktionieren.

Oder hängt es damit zusammen, dass du direkt auf den EIBPC zugreifst?

[mike]

Oder hängt es damit zusammen, dass du direkt auf den EIBPC zugreifst?

Der Zugriff erfolgt direkt.
Was wäre die Alternative?

Mike

[enertegus]

Der Zugriff erfolgt direkt.
Was wäre die Alternative?
Mike

Man kann im Namen des Makros die IP des Clients angeben, der auf den EibPC zurgreift. Die Joins werden dann über diesen Namen der Makros angebunden.
EDIT: Das CommandFusion Makro wird derzeit umgebaut, um Homecontrol optimal an den EibPC anzupassen und die Sache zu vereinfachen:
Ziel:
- KNX-Verknüpfungen können direkt im "Basis-Makro" gemacht werden, d.h. keine "Joins" mehr.
- Schaltuhren ins Basismakro aufnehmen
- ergänzende Makros für die Verarbeitung von Variablen
Soll dann so ausschauen:

[Makros]
// Monstermakro enthält alles vom Buszugriff bis zur Schaltuhr
HomeControl(192.168.2.10, WandPanelWohnzimmer)
[EibPC]

D.h. das Panel greift alleine durch das Einbinden dieses Makros auf Bus zu bzw. programmiert die Schaltuhren, Szenen etc.
Logikverknüpfungen/Automatisierung kann dann wie gewohnt progammiert werden.

[mike]

Man kann im Namen des Makros die IP des Clients angeben, der auf den EibPC zurgreift. Die Joins werden dann über diesen Namen der Makros angebunden.

Naja das löst nicht das Problem, dass ich in einem Browserfenster den GUI-Designer offen habe und im anderen Fenster die Runtime. Die IP ist hier identisch.

Bei Homecontrol ist zumindest mein Anwendungsfall so, dass ich eine GUI Designe und auf diese dann mit mehreren Browsern (gleich Bedienpaneln) zugreife. Um hier mit Namen zu arbeiten müsste ich für jeden Rechner ein eigenes Join-Makro schreiben. Machbar, aber nicht besonders schön.

Und mal im Ernst. Das man auf einen Service auf einem Rechner über verschiedene Ports zugreift und eine isolierte Kommunikation erwartet ist nicht übertrieben, oder?

Ich habe das jetzt nicht ausprobiert. Könnte aber Wetten das der Web-Server im eibPC nicht dieses Problem hat ...

Mike

[SnowMaKeR]

Achso, jetzt versteh ich´s auch.
Du arbeitest mit dem Web-Server und von dem geht die Kommunikation aus, oder?

[Gast]

Du arbeitest mit dem Web-Server und von dem geht die Kommunikation aus, oder?

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.

Für die normale Kommunikation wäre das ja kein großes Problem, dann bekommen die Clients eben mehr Informationen als sie brauchen, anders sieht das aus mit dem Heartbeat. Den könnte man aber auch im Client und WebServer abfangen und anders verarbeiten. Für die Anmeldung müsste man sich noch etwas einfallen lassen.

Für die Initialisierung siehe Vorschlag von mir weiter oben.

Gruss
Arno

[makki]

Vorab: Mein Respekt vor eurer Entwicklungsarbeit, ehrlich gemeint und gesagt!

1.) Es wird nur ein Client unterstützt. Mehrere Clients führen zu "wilder" Kommunikation, da immer der Client, der zuletzt etwas an eibPc gesendet hat die Antworten erhält. Da mehrere Clients jeweils ihr Heartbeat schicken geht das ziemlich durcheinander.

Ach echt, menno! Das ein unpassendes, aus der hohlen Hüfte für eine Strick-Applikation erfundendes, Schönwetter-Protokoll wie CF fürs real-live nichts taugen wird, bitte Jungs (&Mädels natürlich): das wussten wir doch vorher schon !?
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.
Nochmal: ich schätze eure Software, ich finde sowohl das initiale für mh sehr gut als auch das aktuelle, was die Funktion angeht, technologisch seit ihr aber Client&Serverseitig IMHO mit CommandConfusion voll auf dem falschen Dampfer.. HTTP, XML, JSON; Logik im Client+Sonderlockenprotokoll+Sonderlockenport ist für mich ein klarer Fall für die 80er-Jahre Retro-Show..

Makki