Hi Leute,
ich möchte mit dem Raspberry Pi Ein- und Ausgänge über das Internet
einlesen und steuern. Dazu habe ich einen Apache Server mit PHP auf den
Raspberry installiert und möchte darüber verschiedene Befehle
bidirektional übertragen.
Leider habe ich keine Ahnung welche Möglichkeiten es dazu gibt. Ich mir
das so vor, ein PC, Android Phone etc. öffnet eine PHP Session auf dem
Raspberry. Anfragen könnten ganz einfach abgehandelt werden. Jedoch
weiss ich nicht, ob es funktioniert eine Verbindung offen zu halten,
sodass auch der Raspberry Pi zu einem beliebigen Zeitpunkt an den PC
zurücksenden kann.
Welche Möglichkeiten, Funktionsweisen oder Vorgehensweisen gibt es dazu.
Natürlich könnte ich eine einfache TCP/IP Verbindung aufbauen, aber da
ich den Zugriff auch über eine Webpage ermöglichen möchte, will ich
möglichst nur eine Zugriffsart implementieren.
Selbst Stichpunkte oder Vorschläge würden mir weiterhelfen. Webtechnisch
habe ich leider wenig Ahnung. Irgendwie muss das ja gehen. Ich denke
daran an mein Online Banking Portal. Nach einer bestimmten Zeit werde
ich automatisch ausgeloggt. Das passiert natürlich erstmals
Serverseitig, dennoch bekomme ich eine Nachricht, dass ich abgemeldet
wurde. So denke ich es gibt da Möglichkeiten.
Vielen Dank!
Die eine Möglichkeit ist, über JavaScript regelmäßig zu pollen ob der
Server neue Daten hat. Eine andere Möglichkeit sind WebSockets (ständige
Verbindung zwischen Client und Server), z.B. mit websocketd.
Thomas schrieb:> Ich denke> daran an mein Online Banking Portal. Nach einer bestimmten Zeit werde> ich automatisch ausgeloggt. Das passiert natürlich erstmals> Serverseitig, dennoch bekomme ich eine Nachricht, dass ich abgemeldet> wurde. So denke ich es gibt da Möglichkeiten.>> Vielen Dank!
das macht java script auf client seite.
wenn du die seite offen hast und nichts tust ist irgendwann die session
abgelaufen auf dem server.
da der client zyklisch nachfragt ob er noch angemeldet ist ist dann
deine Nachricht.
das gleiche kannst du mit nem cookie auch auf client seite lösen wenn du
davon ausgehen kannst dass er nicht manipuliert wird. oder als doppelte
sicherheit.
so oder so du musst bei php zyklisch nachfragen.
ansonsten brauchst du installierte software
Schon Mal vielen Dank für die Tipps und die Erklärung!!!
Ajax hab ich gleich mal ausprobiert. Läuft als Webpage richtig gut. Die
Methode im allgemeinen wäre perfekt!
Finde es nur schwer einen Java-Client (Darf auch ein C++ Client sein) zu
schreiben, der eine "Ajax"-Page anfragt und eben auch Javascript
ausführen kann. Server auf Java-basis (Servlets), welche Ajax
unterstützen gibt es einige.
Selbstgebasteltes Polling möchte ich nicht so anwenden (Ajax wäre ok)
Bin mir nicht sicher was alles hinter den Javascript Befehlen für Ajax
steckt. Im Grunde habe ich Ajax so verstanden, dass einfach ein erneuter
Request an den Server gestellt wird, dieser aber asynchron beantwortet
werden kann. Die Verbindung wird einfach solange offen gehalten.
Dies könnte ich natürlich auch tun. Einfach einen einfachen Http Request
an den Server stellen und auf eine Antwort warten, welche eventuell
"unendlich" lang auf sich warten lässt. Doch ist es nicht so, dass der
Server diese Verbindung eventuell nach einer bestimmten Zeit einfach
schließt? Ok in diesem Fall sende ich einfach erneut den Request. Nach
welcher Zeit schließt der Server die Verbindung? Dies ist sicherlich
abhängig von der Apache Konfiguration. Lösen die Funktionen bei der
Verwendung von Ajax unter Javascript dies auch so? Bauen diese immer
wieder erneut eine Verbindung auf oder steckt da noch mehr dahinter?
Ich habe dies mal ausprobiert.Ich sende einen einfachen Request per
Java. Ich frage eine php-Datei an. Diese php-Datei endet in einer
Endlosschleife. Bis zum Ende der Verbindung vergehen ca. 35sec.
Baue ich in die php-Datei eine Sleep Anweisung von 60sec ein, verlängert
sich die Zeit bis zur Schließung der Verbindung um 60sec also auf ca
105sec.
Benutze ich einen Webbrowser und rufe dort eine "Ajax" Seite auf welche
nach dem Laden einen Teil der Webpage von der gleichen php-Datei
bekommen soll funktioniert dies super. Es gibt keinen Abbruch. Egal, ob
mit oder ohne Sleep Funktion. Allerdings mit Endlosschleife. Die Seite
bleibt sauber bestehen.
Die Endlosschleife im php-Skript fragt ab, ob eine Datei am Server
existiert. Ist diese Vorhanden, bricht die "Endlosschleife" ab. Nach bis
zu ca 35sec konnte ich die Endlosschleife abbrechen lassen und die
Webpage wurde upgedatet. Bei einem Test wesentlich länger als 35sec
wurde die Webpage nicht mehr upgedatet. Es entsteht ein Fehler mit dem
Status 500 (Serverfehler) anschließend muss man auch wieder sehen, dass
die Seite erneut angefragt wird.
Stehen dann sonst irgendwelche Automatismen hinter den Funktionen von
Javascript für Ajax?
Für weitere Anregungen bin ich natürlich Dankbar. Der Vorschlag Ajax hat
mir schon sehr gut gefallen. Ich werde dies wohl so lösen.
Dennoch, gibt es in HTML5 nicht schon etwas "besseres"/"professionelles"
?
Auf Client-Seite genügt ein einfacher TCP-Socket. Damit setzt man ein
simples "handgestricktes" HTTP-POST-Statement ab, um z.B. eine PHP-Datei
auf dem Server abzurufen. So bekommt man Daten vom Server, die Daten des
Clienten sendet man als Parameter im POST-Request mit ...
Mache gerade sowas für eine Personal-Zeiterfassung, bei der auf
Clientseite ein Arduino mit RFID-Leser, einigen Tasten, LCD und Ethernet
steht, auf Server-Seite ein "gewöhnlicher" Apache mit PHP (für
Entwicklungs- und Testzwecke XAMPP).
Rolf Magnus schrieb:> Muß es denn unbedingt http sein, wenn der Client eh kein Browser> ist?
Ist schon ok, denn damit hat man ohne viel Aufwand einen fertigen
Multi-Client-fähigen Server - ist schon verlockend.
Man kann den HTTP-Datenverkehr ja auch ordentlich abspecken, für eine
Maschine-Maschine-Kommunikation müssen nicht unbedingt oppulente
Webseiten ausgetauscht werden, es genügt "Basiskommunikation" mit POST
und GET.
Thomas schrieb:> Im Grunde habe ich Ajax so verstanden, dass einfach ein erneuter Request> an den Server gestellt wird, dieser aber asynchron beantwortet werden> kann. Die Verbindung wird einfach solange offen gehalten.
Die Anfrage wird beantwortet, so schnell es der Server kann, es wird
nicht auf irgend etwas gewartet. Asynchron bedeutet, dass das Laden
nicht die Webseite im Browser blockiert.
Thomas schrieb:> Finde es nur schwer einen Java-Client (Darf auch ein C++ Client sein) zu> schreiben, der eine "Ajax"-Page anfragt und eben auch Javascript> ausführen kann.
Er muss weder AJAX können noch JavaScript ausführen, er muss einfach
periodisch GET/POST-Requests an den Server schicken und die Antwort
auswerten.
Andreas Schwarz schrieb:> Die Anfrage wird beantwortet, so schnell es der Server kann, es wird> nicht auf irgend etwas gewartet. Asynchron bedeutet, dass das Laden> nicht die Webseite im Browser blockiert.
das muss aber nicht sein. Ich habe selber eine Hausteuerung programmiert
wo der Request einfach maximal 2min blockiert. Wenn ein Event kommt,
dann wird er sofort beantwortet. Wenn nichts passiert sagt er nach 2 min
das nicht los war. Der Client starten danach einfach die nächste
Abfrage.
Somit habe ich eine "Echtzeit" Rückmeldung an den Browser bei wenig
Traffig und das einfach HTTP konform.
Websockets find ich sehr umständlich auf der Server-seite zu
programmieren.
Thomas schrieb:> Finde es nur schwer einen Java-Client (Darf auch ein C++ Client sein) zu> schreiben, der eine "Ajax"-Page anfragt und eben auch Javascript> ausführen kann.
Äh.... ich glaub du hast da ein Verständnisproblem. AJAX ist nur eine
Krücke welche es erlaubt aus JS asynchrone Anfragen an den Server zu
stellen (was so normal nicht vorgesehen ist).
In Java hast du das Problem doch überhauptnicht und kannst zu beliebigen
Zeitpunkten eine Anfrage (nix anderes ist ein AJAX call) starten, z.B.
über die URL Klasse (da muss man auch nix Handgestricktes nehmen!) da
benötigt man kein Javascript für.
Nebenbei kannst du in Android auch einfach einen BrowserFrame einbetten,
wenn du dir den mehrfachaufwand sparen willst und für alle Endgeräte nur
eine Website erstellen willst.
Peter II schrieb:> wo der Request einfach maximal 2min blockierthttp://en.wikipedia.org/wiki/Comet_%28programming%29Frank schrieb:> Man kann den HTTP-Datenverkehr ja auch ordentlich abspecken
HTTP hat nix mit Websites zu tun GET/POST/... sind HTTP was willst du
da noch abspecken?
Peter II schrieb:> Ich habe selber eine Hausteuerung programmiert> wo der Request einfach maximal 2min blockiert.
Das kann man sich mit PHP u.ä. nur dann leisten, wenn man sehr wenige
Clients hat die parallel zugreifen.
> Websockets find ich sehr umständlich auf der Server-seite zu> programmieren.
Schau dir mal websocketd oder die Ruby Websocket-Bibliothek an.
Andreas Schwarz schrieb:> Peter II schrieb:>> Ich habe selber eine Hausteuerung programmiert>> wo der Request einfach maximal 2min blockiert.>> Das kann man sich mit PHP u.ä. nur dann leisten, wenn man sehr wenige> Clients hat die parallel zugreifen.
mit PHP geht das eh nicht sinnvoll.
>> Websockets find ich sehr umständlich auf der Server-seite zu>> programmieren.>> Schau dir mal websocketd oder die Ruby Websocket-Bibliothek an.
ich habe es direkt in meiner Applikation programmiert, da spare ich mir
die ganze Interprocesskommunikation und kann direkt auf die Steuerung
zugreifen.
Es braucht genau die gleichen Resourcen wie ein WebSocket - jeweils ein
offene Socket.
Ok so habe ich es nun auch gemacht. Einfach ein HTTP Request dessen
Antwort einfach etwas länger dauert.
Hatte Ajax wirklich mehr zugesprochen. Aber umso besser! So wirk das
ziemlich einfach und es gibt keine großen Probleme. Ich dachte nur, dass
die Serververbindung viel zu schnell abgebrochen wird.
Wie oben schon festgestellt, wirkt sich ein sleep in einem PHP Skript
nicht anscheinend nicht auf die Server-Timeout Zeit aus. So habe ich in
meiner Endlosschleife einen sleep von 1sec eingebaut. Natürlich habe ich
dann auch nur eine Abfrageauflösung von einer Sekunde, konnte jedoch
einen Request über die ganze Nacht aufrecht erhalten. Geht bestimmt noch
vieeeeel länger. Selbst wenn ich die Sleep-Zeit auf 250ms runterstelle.
Dies gibt mir definitiv eine ausreichende Auflösung für die zyklische
Abfrage von Daten auf dem Server.
Frank schrieb:> Rolf Magnus schrieb:>> Muß es denn unbedingt http sein, wenn der Client eh kein Browser>> ist?>> Ist schon ok, denn damit hat man ohne viel Aufwand einen fertigen> Multi-Client-fähigen Server - ist schon verlockend.
Den Aufwand einen eigenen Webserver aufzusetzen ist doch recht hoch.
Habe schon mehrere eigene kleine Server implementiert. Es geht schon,
jedoch bekommt man niemals so schnell so etwas hin, was mit den
Fähigkeiten und Konfigurationsmöglichkeiten von Apache, PHP und MySql
gleichkommt. Darum diesmal kein eigener Server.
Rolf Magnus schrieb:> Muß es denn unbedingt http sein, wenn der Client eh kein Browser ist?
Ein Typ der Clients wird ein Browser sein. Daneben PC, Mac, Linux und
Android Applikationen.
Andreas Schwarz schrieb:> Peter II schrieb:>> Ich habe selber eine Hausteuerung programmiert>> wo der Request einfach maximal 2min blockiert.>> Das kann man sich mit PHP u.ä. nur dann leisten, wenn man sehr wenige> Clients hat die parallel zugreifen.
Mit wie vielen PHP Verbindungen kann ich denn rechnen? Ist das
Einstellungssache? Wo könnte es noch zu Engpässen kommen?
Vorerst gehe ich von einer Anzahl von maximal 5 Clients gleichzeitig
aus. Es wird zwar viel mehr Clients geben, da ich jedoch derjenige bin,
der die meisten davon nutzt, werden diese kaum gleichzeitig Verbunden
sein.
Thomas schrieb:> Mit wie vielen PHP Verbindungen kann ich denn rechnen? Ist das> Einstellungssache? Wo könnte es noch zu Engpässen kommen?
Das geht schon mit PHP, du must nur die Maximale Skriptlaufzeit anpassen
und etwas mit dem Speicher schauen, ABER:
Brauchst du wirklich eine Direktverbindung? Meist reicht pollen/auf
Anfrage doch völlig aus, "Echtzeit" kannst du so eh nie erreichen.
Bei paralleler Nutzung musst du eh im Server sicherstellen das es nicht
zu Inkonsistenzen kommt und ggf. den User darüber informieren.
Läubi .. schrieb:> Brauchst du wirklich eine Direktverbindung? Meist reicht pollen/auf> Anfrage doch völlig aus, "Echtzeit" kannst du so eh nie erreichen.
wenn er schon schreibt, das 1 Sekunde Verzögerung OK ist. Dann ist
pollen doch keine sinnvolle Option. Jede Sekunde eine Request addiert
sich auch schon im Traffic.
Läubi .. schrieb:> Peter II schrieb:>> Dann ist pollen doch keine sinnvolle Option>> Wieso? Weil die Gefahr besteht, das sich der Server zu Tode langweilt?
nein das die 200Mbyte Tarif schon nach 2 Tage verbraucht ist.
Es ist einfach nicht sehr sinnvoll, jede Sekunde einen neue abfrage zu
starten wenn es mit etwas nachdenken auch besser geht.
Peter II schrieb:> nein das die 200Mbyte Tarif schon nach 2 Tage verbraucht ist
Welcher 200MB Tarif??? Wer sagt das er 24h am Tag davor hängt? Welche
Datenmenge wird den hier tatsächlich übertragen? Man muss sich auch
nicht immer was zusammenspinnen... Ob es "besser geht kannst du doch
garnicht beurteilen, wenn sich die Daten alle 200ms ändern verursacht
comet in diesem Fall 5x mehr Request. Und die "jede Sekunde ein Update"
zweifel ich jetzt mal einfach eh als unnötig an.
Denn entweder es ändert sich alle Sekunde was, dann hilft ja nun alles
"nachdenken" nix, oder es ändert sich halt sehr viel seltener was, und
ob das dann sind auch 5, 10, 20 ... Sekunden (oder sogar nur auf
Anfrage) vollkommen ausreichend.
Läubi .. schrieb:> Peter II schrieb:> Denn entweder es ändert sich alle Sekunde was, dann hilft ja nun alles> "nachdenken" nix, oder es ändert sich halt sehr viel seltener was, und> ob das dann sind auch 5, 10, 20 ... Sekunden (oder sogar nur auf> Anfrage) vollkommen ausreichend.
einfach Beispiel:
Hausautomation dort wird er Status vom Licht angezeigt. Er ändert sich
am Tag ein paar mal. Aber es greifen 4 Personen darauf zu. Jeder soll
den aktuell Status sehen.
Dort ist es sinnvoll "sofort" die Änderung anzuzeigen, auch wenn es sich
selten ändert. Und ja wenn die Seite auf einem Handy läuft ist es
durchaus möglich das sie am Tag 24Stunden offen ist (nicht zwangsläufig
anzeigt wird)
Peter II schrieb:> Hausautomation dort wird er Status vom Licht angezeigt
Und das muss ich jetzt quasi sofort sehen?
Peter II schrieb:> Und ja wenn die Seite auf einem Handy läuft ist es durchaus möglich das> sie am Tag 24Stunden offen ist
Ja wenn... lass ihn doch erstmal eine erste Basisversion hinkriegen.
Den wenn das wirklich relevant ist, wäre ein Jetty-Server + Servlet
viel einfacher, als PHP und Apache, der hat eingebauten Support für
'Continuations' und ist sehr viel flexibler für so eine Aufgabe
insetzbar.
Läubi .. schrieb:> Peter II schrieb:>> Hausautomation dort wird er Status vom Licht angezeigt> Und das muss ich jetzt quasi sofort sehen?
ja, weil es sonst nervig ist.
> Den wenn das wirklich relevant ist, wäre ein Jetty-Server + Servlet> viel einfacher, als PHP und Apache, der hat eingebauten Support für> 'Continuations' und ist sehr viel flexibler für so eine Aufgabe> insetzbar.
habe oben schon geschrieben, das PHP dafür nicht Ideal ist.
