Hallo, ich möchte gerne meine Hausautomatisierung web fähig machen. Nachdem ich jetzt alle Schnittstellen funktionstüchtig habe, scheitere ich ein einer wahrscheinlich trivialen Problematik. Vielleicht erstmal kurz zum Aufbau: uC sendet Daten per RS232 an "Web Server" (in meinem Falle, dieser kleine TP-Link MR3020 mit integrierter RS232 Schnittstelle). Auf dem MR3020 ist Apache mit PHP installiert. Per PHP script habe ich nun Zugriff auf die serielle Schnittstelle und kann Daten senden und entgegen nehmen. Soweit so gut... Dieses Script muss allerdings im Hintergrund laufen und mir die Daten irgendwie anderen PHP Scripten zur Verfügung stellen (zur Visualisierung und Logging). Und genau da scheitere ich. Also nochmal im Klartext: Script A nimmt kontinuierlich alles von RS232 entgegen und bereitet die Daten auf (Endlosschleife) Script B,C,D soll nun auf Variablen von Script A zugreifen können. Ich habe es schon mit putenv() getenv() globals probiert, aber da fehlen mir einfach PHP Kenntnisse. Am liebsten wäre mir ja ein Array, auf das ich script übergreifend zugreifen kann. Ich habe schon mal über eine SQL Datenbank nachgedacht, aber das wäre zu oversized für meinen Nutzen. Hat jemand ne Ahnung wie man so etwas bewerkstelligt ? Danke, Gruß Alex
Alex schrieb: > Hat jemand ne Ahnung wie man so etwas bewerkstelligt ? naja vergiss erstmal dafür PHP. du braucht einen Dienst/Daemon der im hintergrund läuft. Das geht eventull mit PHP aber ich halte das nicht für sinnvoll. Ich würde es mit C oder Perl machen. Diesen programm läuft dann ständig im Hintergrund und kommuniziert über die schnittstelle. Wenn jetzt PHP ausgeführt wird müsste es verbindung zu dem Dienst aufnehmen, das könnte man über eine Pipe oder eine Socket erledigen. Dafür musst du dir aber auch noch ein Protokoll überlegen.
Vielleicht folgender Weg: Ein Script (als Dämon gestartet) liest die Daten ein und speichert diese in einer Datenbank. Das kann zB ein Perl oder Python script sein, aber auch PHI ist möglich. Ein anderes PHP Script kann die Daten dann aus der Datenbank lesen und diese dann schön aufbereitet anzeigen.
Interprozesskommunikation heißt hier das Stichwort. Das kann wie schon erwähnt über Pipes oder Sockets, über Shared-Memory, Message-Queues und/oder Semaphoren erfolgen. Was letztenlich das Mittel der Wahl ist, hängt auch stark von deinen konkreten Bedürfnissen ab.
Danke euch für die schnellen Antworten. Hatte gedacht ich stände kurz vor'm Ziel... ;-) Das mit den Sockets oder Shared Memory wird's wohl werden. Dann werde ich mich da wohl mal rein arbeiten müssen. Gruß Alex
Ich würde eindeutig zu einer Datenbank raten. Ansonsten gehen auch alle Informationen bei einem Stromausfall verloren.
Habe hier auch sowas laufen mit Perl für rs485 <-> sql und PHP für sql <-> html. Habe dafür die sqlite verwendet was ich so nicht mehr machen würde. Demnächst wird das auf memcached umgestellt. Wenn der Strom wieder da ist scannt das script den Bus und baut alles wieder auf, da brauch ich keine dauerhaften Speicher. Und für die Trends wurde das rrdtool erfunden :-)
Hi Tim, genau so hatte ich mir das vorgestellt. Ich will ja erst gar nicht sql da zwischen einbauen, weil das den Zweck verfehlt. Aber das cachen der Daten und bereitstellen für PHP ist nicht so einfach wie ich mir das vorgestellt habe. Nach den Ratschlägen war meine priorisierte Wahl, den Austausch über shared memory zu handeln. Hab ich jetzt mal eben ausprobiert und musste feststellen das OpenWRT das nicht unterstützt. Jetzt geht's an die Socket Kommunikation ran, aber ich befürchte das ich da auch wieder über ein paar Sachen stolpern werde. Weil ich möchte ja quasi den Server und Client auf dem gleichen System laufen lassen. Muss ich mich mal ran tasten. Wenn du noch eine gute Idee hast, dann raus damit.
ich würde einen kleinen Server in Java, PHP whatever schreiben und den für die Verteilung der Daten verantwortlich machen. Deine PHP-Scripte kommunizieren dann mit dem Server. Dafür benötigst du ein kleines Protokoll. Als Datenspeicher würde ich ein XML-File verwenden und/oder es im RAM lagern. Evtl würde ich quasi eine XML-Struktur im Ram lagern und das alle paar Minuten mal abspeichern. Für Java gibt es viele Vorlagen http://www.isb.bayern.de/gymnasium/faecher/mathematik-informatik/informatik/materialien/informatik-naturwissenschaftlich-jgst-12/ Da wäre ein Java-Server der mehrere Anfragen gleichzeitig unterstützt und mit String arbeitet. Das würde dir die Kommunikation erstmal erleichtern. Zu finden unter Kapitel 2
Sockets wollte ich nicht verwenden, weil das bei mehreren Gleichzeitigen Anfragen kompliziert wird. Oder die Timeouts müssen entsprechend kurz sein. Wenn du aber schon Sockets nutzen willst dann schleuse die Daten nicht nochmal durch PHP sondern per AJAX direkt an den Client. Mit jquery kann man dann die Webseiten schön im Hintergrund aktualisieren. Im Moment laufen die Daten bei mir nämlich so: RS485 -> Perl -> Datenbank -> PHP -> ajax+javascript -> Webseite Und diese x mal konvertieren ist bescheuert und wenig sicher. Brauchst also "nur" einen kleinen Webserver in dem RS232-Script. Die anderen Sachen (auser AJAX) würde ich aber weiterhin mit PHP erschlagen. So muss sich das Perlscript nur um die Dynamischen Daten kümmern :-)
Also wenn ich das richtig verstanden hab, dann ist das Script für die RS232 in php schon fertig und läuft. Der einfachste Weg aus meiner Sicht wäre die Daten einfach in n Textfile zu schreiben und das zu überschreiben
ein java-socket-Server wäre schnell umgesetzt (siehe meinen Link). Wichtig ist nur ein synchronized und die Auslagerung der Connection in einen thread (sollten es hunderte von anfragen gleichzeitig sein, so wäre das wiederum nicht ganz optimal). Ansonsten: was spricht denn gegen die vielen umformungen? Sauber gemanaged hält sich der wartungsaufwand in grenzen und die Logik ist recht einfach und die CPU soll sich ja nicht langweilen :P Wenn du kein SQL verwenden willst, wurde ich immer noch eine textdatei/xmldatei vorschlagen. Für einen synchronisierten zugriff musst du trotzdem sorgen (eig mit Hilfe eines (socket)Servers; lockdateien sind keine atomaren befehle -> probleme bei gleichzeitigen anfragen)
Markus Borti schrieb: > ein java-socket-Server wäre schnell umgesetzt (siehe meinen Link). Dein link ist Müll. Infomationen über den 12 Jahrgang einer Schule da hast du wohl den falschen link kopiert ?
Nein, der ist richtig. Das ist die Handreichung zum informatikunterricht der Q12 in Bayern. Zum lernen, wie er so einen Server umsetzen könnte, ist das meiner Meinung nach ganz gut geeignet und es war der schnellste Link, den ich hatte. Er kann natürlich auch ganz geschwind googeln :)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.