Hier gibt es ein Beispiel für einen Webserver, mit dem man die LED am ESP8266 ein- und ausschalten kann. https://github.com/espressif/arduino-esp32/blob/master/libraries/WiFi/examples/SimpleWiFiServer/SimpleWiFiServer.ino Es gibt in HTML ja aber auch die Möglichkeit Slider zu verwenden, wie geht das?
Javascript. Alles was interaktiv ist, ist heute Javascript.
:
Bearbeitet durch User
Name H. schrieb: > Javascript. Alles was interaktiv ist, ist heute Javascript. Bzw. AJAX. Das ist manchmal ganz nett, wenn man Messwerte und Zustände auf einer Seite anzeigen will, die sich aktualisieren sollen, ohne die Seite neu zu laden.
Slider? Es gibt range inputs:
1 | <input type="range" min="5" max="10" step="0.1" value="0" /> |
Oder meinst du Toggles? Die gibt es so nicht, es gibt nur Chekboxen und Radios, und Toggles sind dann mit CSS und/oder JS dekorierte Checkboxen: - Mit nur einem input element, aber nur in chrome und firefox wegen dem css appereance hack: https://jsfiddle.net/jdzhvgmx/ - input mit id + label element, geht dafür aber überall: https://jsfiddle.net/y5udk08b/ - input ohne id und span in label element, geht dafür aber überall: https://jsfiddle.net/subwdnoh/1/
>Javascript.
Davon habe ich auch schon mal gehört.
Hat jemand ein konkretes, einfaches Beispiel?
Wie funktioniert bei Java-Script die schnelle Datenübertragung vom
Mikrocontroller-Server zum Java-Script-Browser-PC-Client?
>Slider? Es gibt range inputs: ><input type="range" min="5" max="10" step="0.1" value="0" /> Danke. Damit bekomme ich den Slider auf die Webpage, aber wie kommen jetzt die Daten zum Server?
Hier sind zumindest Slider bei: https://babaawesam.com/2015/11/26/control-input-output-of-esp8266-with-ajax/ https://www.instructables.com/id/Easy-ESP8266-Arduino-Core-Web-Controls-With-EmbAJA/ https://www.arduinoforum.de/arduino-Thread-Vorstellung-ESP8266-Webserver-mit-AJAX
Sebastian R. schrieb: > Name H. schrieb: >> Javascript. Alles was interaktiv ist, ist heute Javascript. > > Bzw. AJAX. Das ist manchmal ganz nett, wenn man Messwerte und Zustände > auf einer Seite anzeigen will, die sich aktualisieren sollen, ohne die > Seite neu zu laden. Anstatt AJAX benutze ich lieber WebSockets.
Cornelius schrieb: > Wie funktioniert bei Java-Script die schnelle Datenübertragung vom > Mikrocontroller-Server zum Java-Script-Browser-PC-Client? Über eine gute Netzwerkverbindung?! Für dein Slider-Beispiel brauchst du zunächst aber mal keine Kenntnisse über die unteren Netzwerkschichten, es sei denn, du hast da noch Wissensdefizite. In dem Fall würde ich dir anraten, dich mal in ein paar Netzwerkgrundlagen am Beispiel HTTP einzulesen. Dann solltest du schauen, was Javascript überhaupt ist und wie es sich in diesen Kosmos im Zusammenspiel mit dem Browser überhaupt einreiht. Dann wirst du verstehen, warum eine Frage danach, wie bei Javascript die Datenübertragung funktioniert, nicht so viel Sinn macht, da Javascript selbst auch nur auf Dienste einer tieferen Ebene zugreift, so wie es C, Python, Java und Konsorten auch tun. Wenn du also verstanden hast, was etwas weiter unten passiert, weißt du auch, was du weiter oben brauchst und finden wirst, um Daten zu verschicken. Danach kannst du dich z.B. mit AJAX und den damit zusammenhängenden Klassen, die dir Javascript zur Verfügung stellt, befassen. Spätestens hier wird es keine Magie mehr sein, was da abläuft :)
Cornelius schrieb: > Danke. Damit bekomme ich den Slider auf die Webpage, aber wie kommen > jetzt die Daten zum Server? Ein Link erzeugt beim Anklicken einen http get request. Mit einem form kann man auch noch http post Requests erzeugen. Mit JS geht das mittlerweile beides einfach per fetch[1], also z.B. "fetch("/test/")" macht einen get Request auf test. Dann gibt es noch event listener. Man kann damit z.B. alle Änderungen an Formularen beobachten: https://jsfiddle.net/78pd0etn/ Mit "new Map(new FormData( VariableDieDieFormReferenziert ))" bekommt man ein Map Objekt mit den name->value Werten der Elemente in der Form. Mit "Array.from(new FormData( VariableDieDieFormReferenziert )).reduce((p,[k,v])=>(p[k]=v,p),Object.create(null))" bekommt man das selbe als POJSO statt als Map. Aus dem POJSO kann man unter anderem z.B. ein JSON String aller Werte erstellen, mit "JSON.stringify( DasPOJSOObjekt )". Das kann man dann mit fetch mitsenden, ist aber eventuell nicht trivial auf nem kleinen UC wieder zu parsen. Man so ein Objekt natürlich auch anderes serialisieren. Das alles muss man dann nur richtig kombinieren. Alternativ kann man die Daten auch mit nem guten alten submit button ganz ohne JS versenden. 1) https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch Ralf O. schrieb: > Anstatt AJAX benutze ich lieber WebSockets. Gibt es da mittlerweile brauchbare WebSocket Server für uCs? Das Protokoll ist zwar simpel, aber die Verbindungen offen zu halten bei den kleinen uCs braucht doch recht viele Ressourcen.
Ralf O. schrieb: > Anstatt AJAX benutze ich lieber WebSockets. Da ist es bei eingebetteten Systemen immer nur eine Frage der Ressourcen und ob es wirklich notwendig ist, eine permanente Verbindung seitens des Servers aufrecht zu erhalten, wenn lediglich eine handvoll Messwerte übertragen werden sollen. Websockets machen ja nur dann wirklich Sinn, wenn der Server Ereignisse an seine Clients verteilen muss, ein permanentes Polling ein zu großer Overhead wäre und die Clients nicht wissen, wann diese Ereignisse eintreten. Wenn allerdings der Client (wie in diesem Fall ein einfacher ESP) nur ein paar Werte erfahren möchte und es ihm überlassen ist, wann er diese abfragt, reicht das Prinzip "Wer es wissen will, kann mich ja fragen" (AJAX) vollkommen aus.
DPA schrieb: > Aus dem POJSO kann man unter anderem z.B. ein JSON String aller Werte > erstellen, mit "JSON.stringify( DasPOJSOObjekt )". Das kann man dann mit > fetch mitsenden, ist aber eventuell nicht trivial auf nem kleinen UC > wieder zu parsen. Wenn man schon so weit ist, dass die Daten konform beim Server ankommen, kann man die auch mit einer schlanken Bibliothek wie cJSON parsen. Das ist dann auch kein Hexenwerk mehr ;)
:
Bearbeitet durch User
A.. P. schrieb: > Websockets machen ja nur dann wirklich Sinn, wenn der Server Ereignisse > an seine Clients verteilen muss, ein permanentes Polling ein zu großer > Overhead wäre und die Clients nicht wissen, wann diese Ereignisse > eintreten. Beispiel: Ein ESP32-Programm, mit dem man die Position eines Servos vom Webbrowser aus mit einem Range-Slider einstellen kann. Dabei soll der ESP natürlich sofort auf Änderungen des Sliders reagieren, und die kommen manchmal sehr schnell, manchmal aber auch für eine ganze Weile gar nicht. Da macht Polling überhaupt keinen Sinn, und Websockets sind das Mittel der Wahl.
DPA schrieb: >Man kann damit z.B. alle Änderungen an Formularen beobachten: >https://jsfiddle.net/78pd0etn/ Danke für das Beispiel. Ich sehe auf der Seite ein Zahleneingabefeld und einen Slider. Allerdings sehe ich im HTML-code den Slider nicht: HTML
1 | <form> |
2 | <input/> |
3 | <input type="range" min="0" max="100" value="0"/> |
4 | </form> |
Und hier fehlt dann das zurücksenden:
1 | addEventListener("change",function(event){ |
2 | if(!event.target || !event.target.form) // Check if event from an element in a form. event.target is the element changed, event.target.form is the form. |
3 | return; |
4 | alert("A change was made, new value is "+event.target.value); |
5 | }, true); |
Wie müsste das dann konkret aussehen?
In dem Buch http://stefanfrings.de/mikrocontroller_buch/Einstieg%20in%20die%20Elektronik%20mit%20Mikrocontrollern%20-%20Band%202.pdf Ab Kapitel 10 sind die Grundlagen des HTTP Protokolls aus Sicht des µC Entwicklers erklärt. Für AJAX gibt es in der deutschen Wikipedia ein schönes Javascript-Beispiel, dass ohne Frameworks oder zusätzliche Libraries auskommt. SelfHTML kennst du hoffentlich, wenn nicht solltest du dich damit dringend beschäftigen: https://wiki.selfhtml.org/wiki/HTML/Tutorials/HTML-Einstieg
Cornelius schrieb: > Allerdings sehe ich im HTML-code den Slider nicht Bei XML öffnet man tags mit <tagname> und schliesst diese mit </tagname>, und tags ohne Inhalt kann man öffnen und soffort wieder schliessen, mit <tagname/>. Bei HTML, eine ursprünglich von SGML inspirierte Sprache, ist es etwas komplizierter. Hier gibt es regeln, welche Elemente in welchen vorkommen können, manchmal optionale closing tags, elemente, die nicht sofort geschlossen werden können (sind die meisten), und solche, welche immer selfclosing sind und keinen inhalt haben können. (bei letzteren lassen heutzutage viele das / in /> weg, das ist erlaubt.) Das ist noch eine starke vereinfachung, das wahre Ausmass des Chaos ist hier Dokumentiert: https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Content_categories Input Elemente sind immer selfclosing. Im code steht einmal "<input/>", das ist das text Eingabefeld. Strengenommen müsste ich eigentlich "<input type="text"/>" schreiben, weil das type attribut bei input feldern nicht optional ist, aber Browser können damit umgehen und nehmen text als default an. Der Slider ist die Zeile darunter, das "<input type="range" min="0" max="100" value="0"/>". Das "type" Attribut des "input" Elements hat den Wert "range", daher weis der Browser, dass es sich um einen Slider handelt. Die restlichen möglichen Typen für "input" Elemente sind hier gelistet: https://developer.mozilla.org/de/docs/Web/HTML/Element/Input MDN ist allgemein eine hervorragende Ressource, um die ganzen Browser APIs nachzuschauen. Wenn man z.B. "mdn input" oder "mdn fetch" oder "mdn change event" in Google eingibt, kommt meist die richtige Seite als erstes Ergebnis. Auch die JS DOM APIs findet man so, z.B. "mdn HTMLInputElement" für die JS APIs eines "input" Elements, also welche Felder und Methoden man bei diesen mit js abfragen/aufrufen kann. Die Liste aller Events ist auch ganz praktisch: https://developer.mozilla.org/de/docs/Web/Events Cornelius schrieb: > Und hier fehlt dann das zurücksenden: Das sind ja auch nur Beispiele, Wegweiser für Dinge die hie nützlich sein könnten. Wie man JS verwendet und das alles zusammenbaut, kannst nur du dir beibringen. Du willst doch nicht wie diese StackOverflow Copy&Paster enden, die nicht wissen, was sie da eigentlich tun. Lies doch einfach mal all das hier durch: https://developer.mozilla.org/de/docs/Web/JavaScript Oder versuch selbst durch ausprobieren herauszufinden, wie es funktioniert, falls dir das zu aufwändig ist.
>Du willst doch nicht wie diese StackOverflow >Copy&Paster enden, die nicht wissen, Ein Beispiel sagt mehr als tausend Worte. Überlicheweise lernt man anhand von Beispielen am einfachsten. Ist es denn so schwer, eins zu zeigen?
A.. P. schrieb: > Ralf O. schrieb: >> Anstatt AJAX benutze ich lieber WebSockets. > Websockets machen ja nur dann wirklich Sinn, wenn der Server Ereignisse > an seine Clients verteilen muss, ein permanentes Polling ein zu großer > Overhead wäre und die Clients nicht wissen, wann diese Ereignisse > eintreten. Wenn allerdings der Client (wie in diesem Fall ein einfacher > ESP) nur ein paar Werte erfahren möchte und es ihm überlassen ist, wann > er diese abfragt, reicht das Prinzip "Wer es wissen will, kann mich ja > fragen" (AJAX) vollkommen aus. Wenn er mit einem Slider allerdings die Helligkeit/Farbe einer LED regeln will und das Ergebnis einigermaßen Zeitnah sehen will dann ist eine Websocketverbindung das Mittel der Wahl. Obs für den ESP da schon was fertiges gibt hab ich noch nicht geschaut. Sascha
Für solche Zwecke nutze ich ganz gerne die Mongoose Library. Damit kommt man schnell zum Erfolg. https://github.com/cesanta/mongoose Hat Websockets, aber auch anderen Kram wie HTTP oder MQTT.
Cornelius schrieb: > Überlicheweise lernt man anhand von Beispielen am einfachsten. Nein, man lernt, indem man selbst überlegt, Fehler macht, man nachdenkt was man falsch macht, und es dann nochmal versucht. Die Sprachkonstrukte von Programmiersprachen ändern sich nicht, und die nötigen APIs (fetch, events (change, input, submit,...), DOM (HTMLInputElement, HTMLFormElement)) für die Lösung hab ich ja schon genannt. Auch ein paar nicht Triviale Code schnipsel (z.B. Auslesen & Serialisieren aller Inputs eines Formular Objekts) die helfen könnte hab ich geliefert. Der Rest ist eigentlich nur noch das zusammenzusetzen, also den EventListener part zum ermitteln von Änderungen nehmen, die Variable die auf das Form Objekt zeigt (event.target.form) in den Codeschnipsel für die Serialisierung einsetzen und in die Callback funktion bzw. in den Event Handler einfügen, und dann den Rückgabewert wie im MDN Artikel beschrieben der fetch Funktion übergeben. Dann in der Browser Console im Consolen und Netzwerk Tab nachsehen, ob es Fehler gibt oder etwas gesendet wird. Man muss nur die Puzzleteile Zusammensetzen. So schwer ist es doch nicht, auf die Lösung zu kommen. Ist dann zwar aber erst die Client Seite.
Sascha W. schrieb: > Wenn er mit einem Slider allerdings die Helligkeit/Farbe einer LED > regeln will und das Ergebnis einigermaßen Zeitnah sehen will dann ist > eine Websocketverbindung das Mittel der Wahl. Sind ja alles valide und legitime Beispiele, da erhebe ich ja keinen Einspruch gegen. Ich weiß nur nichts über die Absichten des TO, außer, dass er gerne wüsste, wie die Daten zum uC kommen. Und da reichen die Basics ja immer zunächst aus. Selbstverständlich kann man alles unendlich vertiefen und spezialisieren, aber bevor der TO nicht genaueres möchte, braucht er sich mit Themen wie Websocket m.M.n. noch nicht auseinandersetzen. Die Leute in diesem Forum neigen leider schnell dazu, Details ins Spiel zu bringen, nach denen noch keiner gefragt hat, was häufig zu unnötigen Diskussionen führt. Und sofern es ihm die Ressourcen nicht wert sind, ist er mit plain HTTP gut bedient. Trotzdem ein paar Worte zu den Beispielen: Sofern man nicht soetwas wie eine choreografierte Lichtinstallation anpeilt, bei dem es durchaus auf Laufzeitunterschiede im ms-Bereich ankommt, reicht einfaches HTTP vollkommen aus. Und sollte es dabei zu Latenzen von mehr als einigen Sekunden kommen, so wird man durch Websockets auch nicht gerettet. Dann muss man sowieso nochmal an anderen Stellen angreifen. Prinzip: KISS
Sebastian schrieb: >https://www.instructables.com/id/Easy-ESP8266-Arduino-Core-Web-Controls-With-EmbAJA/ Danke Sebastian. Der Link ist eigentlich gar nicht schlecht. Hier gibt es auch das Github-Repo dazu. https://github.com/tfry-git/EmbAJAX Allerdings finde ich die API sehr undurchsichtig und etwas schwierig zu verstehen. Hier gibt es eine sehr einfache API mit Websockets, die auch gleich 3 Slider beinhaltet: https://github.com/tttapa/ESP8266/tree/master/Examples/14.%20WebSocket/A-WebSocket_LED_control Leider geht das Beispiel nur in der Richtung vom Browser zum ESP aber es werden keine Rückmeldewerte dargestellt. Wie könnte man dafür sorgen, dass der Sliderwert im Webbrowser erscheint?
Hier gibt es ein ziemlich beeindruckendes Demo mit Online-Graph: http://midnightcow.tistory.com/m/entry/WebSocket-SVG-Arduino-and-LabVIEW Leider scheinen aber die Sourcen verschwunden. Es wird ein "SVG-Webpanel" erwähnt. Ob das wohl von Google ist?
Cornelius schrieb: > Wie könnte man dafür sorgen, dass der Sliderwert im Webbrowser > erscheint? Es wurde ja schon zweimal genannt: Websockets. Ich bin bestimmt kein Crack, habe aber genau das Problem am ESP32 damit gelöst bekommen.
>Es wurde ja schon zweimal genannt: Websockets. Ich bin bestimmt kein >Crack, habe aber genau das Problem am ESP32 damit gelöst bekommen. Genau, das habe ich einen Post weiter oben schon geschrieben. Hier gibt es dazu auch eine ganz gute Beschreibung: https://tttapa.github.io/ESP8266/Chap14%20-%20WebSocket.html Aber wie schon erwähnt, kann man zwar mit dem Slider einen Wert einstellen, man sieht aber im Browser nicht, welchen Wert. Ich würde gerne im Browser Werte vom ESP-Server darstellen. Es fehlt also die Datenübertragung vom ESP zum Browser.
Cornelius schrieb: > Leider geht das Beispiel nur in der Richtung vom Browser zum ESP aber es > werden keine Rückmeldewerte dargestellt. Wie könnte man dafür sorgen, > dass der Sliderwert im Webbrowser erscheint? Na indem du vom ESP über denselben Kanal eine Antwort o.ä. an den Browser zurücksendest. Ich verstehe ehrlich gesagt dein Problem bei der Sache gerade nicht ganz. Weißt du nicht, wie eine HTTP Antwort vom ESP verschickt wird oder weißt du nicht, wie du das über besagte Websockets löst? Oder weißt du nicht, welche Methoden du überhaupt verwenden musst?
Ich glaube, der TO braucht noch eine Weile, um die Grundlagen kennen zu lernen. Als da wären: HTML CSS Javascript AJAX TCP/IP HTTP 1.0 HTTP 1.1 Websockets
Ich denke der TO(?) sucht - genau wie ich - eine Vorlage (Template) bzw. ein Beispiel für den bidirektional von Analog Daten zwischen einem ESP und einem Browser. Anscheinend hat keiner der Diskussionsteilnehmer ein solches Beispiel. Ist ja nicht weiter schlimm, aber dass dann so viele belehrende Worte drum gemacht werden ist IMHO schade.
Er hat ja um Hilfe gebeten. Wenn wir schon kein konkreten Beispiel zum abgucken haben, so können wir ihm doch wenigstens mit den richtigen Stichworten dienen. Was ist daran schlecht?
>Wenn wir schon kein konkreten Beispiel zum >abgucken haben, so können wir ihm doch wenigstens mit den richtigen >Stichworten dienen. Warum ist es so schwer, ein konkretes Beispiel hin zu schreiben? Gut, ich habe gerade festgestellt, dass man kann hier nur
1 | haräf="xyz" |
schreiben, weil sonst der Spamfilter des Forums zu schlägt.
A.. P. schrieb: > Für dein Slider-Beispiel brauchst du > zunächst aber mal keine Kenntnisse über die unteren Netzwerkschichten, > es sei denn, du hast da noch Wissensdefizite. Der Satz hätte Aristoteles bestimmt gefallen. "Darüber mußt Du nichts wissen, es sei denn, Du weißt nichts darüber"
Cornelius schrieb: > Warum ist es so schwer, ein konkretes Beispiel hin zu schreiben? Zum einen, weil hier niemand weiß, wie z.B. deine Variablen heißen oder was du überhaupt verschicken willst. Außerdem haben hier doch schon mehrere Leute zig Hinweise auf Webserver-Implemetierungen auf dem ESP gegeben. Im großen Netz gibt es doch hunderte Beispiele dazu. Dann musst du lediglich deine eigenen Daten irgendwie serialisieren (als Beispiel wurde hier ja schon JSON genannt) und die schickst du dann zurück. Aber ein bisschen Hirnschmalz im Bezug auf deine Anwendung musst du schon reinstecken, hier wird dir keine deine Hausaufgaben machen. Markus F. schrieb: > Der Satz hätte Aristoteles bestimmt gefallen. > > "Darüber mußt Du nichts wissen, es sei denn, Du weißt nichts darüber" Zugegeben, etwas unglücklich formuliert :)
:
Bearbeitet durch User
Cornelius schrieb: > Warum ist es so schwer, ein konkretes Beispiel hin zu schreiben? Weil das davon abhängt, wie dein Webserver funktioniert und was du überhaupt haben willst. Es gibt mehrere Ansätze, die alle mehr oder weniger gut funktionieren. Klar kann ich mich ne Stunde hinsetzen und sowas fummeln, aber dann kommt höchstwahrscheinlich ein "aber so will ich das nicht, geht das nicht anders?" zurück und ich ärgere mich. Oder es funktioniert bei dir nicht, weil deine Umgebung anders ist und ich muss den Kram aus der Ferne bei dir debuggen. Wenn du einen kompetenten Kumpel bei dir um die Ecke fragst, dann ist das in ner halben Stunde durch. Denn der sieht dein System und kann testen. Und wenn man das noch mit nem Bierchen verbindet, dann ist das u.U. sogar ein schöner Abend statt Arbeitszeit.
Cornelius schrieb: > Warum ist es so schwer, ein konkretes Beispiel hin zu schreiben? Weil es nicht eine definitive Lösung gibt, sondern man das auf alle möglichen arten machen könnte. Auf der Browserseite gibt es von der W3C festgelegte APIs, die man verwenden kann, sofern man keine Libraries dafür verwendet (beispiel libraries: ajax->jquery, websocket socket.io (zusätzliches protokoll darüber)). Bei ajax sind die APIs des Browsers fetch oder das veraltete XMLHttpRequest. Bei websocket ist es WebSocket[1]. Bei WebSocket implementationen hat man einen Handler für eintreffende Nachrichten, und eine Funktion zum senden. Dann kann entweder Text, der in UTF-8 formatiert sein muss, oder Binärdaten gesendet werden. Wie das Serverseitig gemacht wird, ist von der serverseitig verwendeten WebSocket Implementierung abhängig. Du musst dich da also zuerst mal für eine entscheiden. Und dann ist es im Browser eigentlich egal, ob man ein Textfeld, ein Slider, oder ne checkbox hat. Änderungen bekommt man immer mit events mit, Werte spezifischer Inputs lesen und schreiben geht indem man deren .value und .checked properties ausliest oder setzt. Den restlichen DOM und Text manipuliert man eigentlich immer mit den methoden/properties: parent_node.appendChild(child_node), parent_node.removeChild(child_node), document.createElement("div") document.createTextNode("irgendein text"), element.innerHTML="" . Würden wir dir jetzt vorkauen, wie das geht, würdest du vermutlich bei der nächsten Checkbox wieder nachfragen, und dann vermutlich noch irgend einen neuen Webserver verlinken, der noch nicht genannt wurde. So kommt nam nirgends hin. 1) https://developer.mozilla.org/en-US/docs/Web/API/WebSocket PS: Ich bin der, drr vorher als DPA geschrieben hat.
Das hier kennst du? https://gist.github.com/bbx10/667e3d4f5f2c0831d00b Von da aus ist es nur ein kleiner Schritt statt einer Schaltfunktion einen Zahlwert zu übertragen. Für mich ein entscheidender Vorteil der Websockets-Lösung ist übrigens, dass auch mehrere HTML-clients quasi parallel darauf zugreifen können.
Dieter R. schrieb: > Für mich ein entscheidender Vorteil der Websockets-Lösung ist übrigens, > dass auch mehrere HTML-clients quasi parallel darauf zugreifen können. Ich dachte, jeder Client braucht dazu nach wie vor seine eigene quasi permanente Verbindung.
Autor: Dieter R. (dieter_r) >Das hier kennst du? https://gist.github.com/bbx10/667e3d4f5f2c0831d00b Vielen Dank für das Beispiel. >Ich dachte, jeder Client braucht dazu nach wie vor seine eigene quasi >permanente Verbindung. Na, wenigstens dürfte bei Dir jetzt langsam die Erkenntnis reifen, für was konkrete Beispiele gut sind anstatt sich in weitläufigem BlaBla zu ergehen.
Cornelius schrieb: > Stefanus F. schrieb: >>Ich dachte, jeder Client braucht dazu nach wie vor seine eigene quasi >>permanente Verbindung. > > Na, wenigstens dürfte bei Dir jetzt langsam die Erkenntnis reifen, für > was konkrete Beispiele gut sind anstatt sich in weitläufigem BlaBla zu > ergehen. Solange die WebSocket Verbindung offen ist besteht durchaus eine permanente Verbindung. Mit der WebSocket Library aus dem letzten Beispiel wären das maximal 5 gleichzeitige Verbindungen/Clients: https://github.com/Links2004/arduinoWebSockets/blob/master/src/WebSocketsServer.h#L31 Na, wenigstens dürfte bei Dir jetzt langsam die Erkenntnis reifen, für was das Verstehen von Protokollen und APIs gut sind anstatt sich nur aus Beispielen dinge zusammenzukopieren.
Beitrag #5644589 wurde von einem Moderator gelöscht.
Beitrag #5644689 wurde von einem Moderator gelöscht.
Jetzt gibt es ein kleines Problem: Firefox auf dem PC kann sich mit dem ESP verbinden und alles funktioniert wunderbar, wenn ich die IP-Adresse oben in das Addressfeld eingebe: 192.168.4.1 Wenn ich das ganze mit einem alten Samsung S3 versuche, stellt der Browser immer ein http voran: http://192.168.4.1/ und sage Webseite nicht verfügbar. Woran könnte das liegen?
Nun, das könnte daran liegen, dass ein Webserver immer mit HTTP arbeitet. Warum die Verbindung nicht klappt, müsste man mal untersuchen. Am http:// liegt es jedenfalls nicht. Dir fehlen Grundlagen, und zwar massiv.
Cornelius schrieb: > Wenn ich das ganze mit einem alten Samsung S3 versuche, stellt der > Browser immer ein http voran: > > http://192.168.4.1/ > > und sage Webseite nicht verfügbar. > > Woran könnte das liegen? Das http:// hast du immer, der Firefox hat nur die Unsitte, das nicht anzuzeigen, das ist nicht das Problem. Das / am ende macht hier auch keinen unterschied. Zunächst, informir dich mal über URI, URL und URNs: https://en.wikipedia.org/wiki/Uniform_Resource_Identifier (oder der standard, rfc3986: https://www.ietf.org/rfc/rfc3986.txt) Und das HTTP schema, rfc7230 abschnitt 2.7: https://tools.ietf.org/html/rfc7230#section-2.7 Stelle sicher, das das Phone mit dem selben Netz verbunden ist. Stelle im Zweifelsfall mal die Mobilen Daten ab, und stelle sicher, dass du weder VPN, noch Googles Beschleunigungsproxy, noch sonst ein Proxy auf dem Phone aktiviert hast. Kontrolliere eventuell nochmal, dass der Netzanteil der IP des Phone wirklich mit dem des UC übereinstimmt (im Zweifelsfall gibt es im Netz Subnetrechner dafür). Falls nicht, bist du in nem anderen Subnet, und du musst eventuell was am einem Router anpassen. Kontrolliere ausserdem, dass es nicht mehrere Geräte mit der IP 192.168.4.1 gibt. Wenn alles nichts hilft, musst du mit Wireshark und Debugmeldungen im UC nachsehen, ob und wo etwas ankommt, und wo etwas schief geht.
:
Bearbeitet durch User
>Stelle sicher, das das Phone mit dem selben Netz verbunden ist. Das Phone ist direkt mit dem ESP als AP verbunden. >Dir fehlen Grundlagen, und zwar massiv. Woher willst du das wissen?
Cornelius schrieb: >> Dir fehlen Grundlagen, und zwar massiv. > Woher willst du das wissen? Weil ich nicht komplett bescheuert bin. Cornelius schrieb: >> Stelle sicher, das das Phone mit dem selben Netz verbunden ist. > Das Phone ist direkt mit dem ESP als AP verbunden. Geh in die Netzwerkeinstellungen vom Telefon und lass dir die Details anzeigen. Gleiche mit dem ESP ab, dass das zusammenpasst. Android könnte ein funktionierendes DNS voraussetzen - stelle sicher, dass dein ESP das kann. Dass dein ESP einen DHCP-Server anbietet, davon gehe ich mal schlicht aus.
>Weil ich nicht komplett bescheuert bin.
Doch, bist du.
AP heist der ESP ist als Access-Point definiert. Da gibt's kein Telefon
und kein Router dazwischen. Ausserdem hatte ich schon geschrieben, dass
es mit dem Laptop funktioniert.
Cornelius schrieb: >> Weil ich nicht komplett bescheuert bin. > Doch, bist du. Achso, na dann funktioniert ja alles prächtig. Im Übrigen war mir dein Setup schon klar.
Cornelius schrieb: > Das Phone ist direkt mit dem ESP als AP verbunden. Wo in der Software wird der ESP als AP definiert? Über welche Software sprechen wir hier?
Eventuell hängt es auch mit dem Internetverbindungstest von Android zusammen. Wenn eine test URL nicht aufrufbar ist, ist ein wlan unter Android eigentlich nicht verwendbar: http://www.ateijelo.com/blog/2016/09/11/make-android-believe-it-has-internet-access Ich habe gehört das tolle daran soll sein, dass jede Version ne andere Domain nutzt.
Versuche mal 192.168.4.1/Index.html Ich gehe mal davon aus, dass du die auf dem ESP hast. Phones haben manchmal eine eigenwillige Interpretation. Gab es bei der Googlesuche nichts passendes? Ist vermutlich hilfreicher als hier zu fragen. Meine Erfahrung. Kannst du deinen Router, wenn du mit ihm verbunden bist, direkt über die IP aufrufen?
Daniel A. (daniel-a) >Eventuell hängt es auch mit dem Internetverbindungstest von Android >zusammen. Wenn eine test URL nicht aufrufbar ist, ist ein wlan unter >Android eigentlich nicht verwendbar: >http://www.ateijelo.com/blog/2016/09/11/make-android-believe-it-has-internet-access Um das zu testen, habe ich den ESP jetzt mal als STA an den Router gelassen und das Handy auch am Netzwerk angemeldet. Es kann jetzt ins Internet, aber den ESP auf 192.168.4.1 sieht es trotzdem nicht. Der PC sieht aber die Webseite. Die beiden sind nicht gleichzeitig im Netz um Konflikte mit mehreren geöffneten Sockets zu vermeiden.
Um einzugrenzen, ob das Problem beim ESP oder beim Phone liegt, könnte man das Phone und den PC mal mit dem Router verbinden, auf dem PC mit
1 | echo -e "HTTP/1.1 200 OK\r\n\r\nHello World" | netcat -l -p 2000 |
auf eine Verbindungen warten, und auf dem Phone schauen, ob beim PC was ankommt, wenn man IP_des_PC:2000 im Browser eingibt.
Ein kleiner Tipp: benutze die richtigen Begriffe, um Missverständnisse zu vermeiden. Man kann nur etwas sehen, was sich sichtbar präsentiert. Ein AP kann man zum Beispiel "sehen", oder einen Radio-Kanal. Aber nicht Webseiten. Die erscheinen nicht von alleine auf der Bildfläche. Webseiten muss man aktiv abrufen. Man kann nicht einmal den Webserver "sehen". Der Client (Browser) Baut eine Verbindung zum Server auf. Erst danach kann der Client überhaupt wissen, ob da ein Server existiert. Danach sendet der Client seine Anfrage, die der Server (typischerweise mit einem HTML Dokument) beantwortet. HTML Seiten enthalten meistens includes für weitere Dateien (CSS, Bilder, Javascript, dynamische Inhalte).
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.