ESP Webserver HTML Graphikelemente

Dein Google kaputt?

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?

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:
> 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.

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.

>Beispiel:
Ein Beispiel-Code wäre super!

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?

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.

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?

>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.

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.

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.

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?

>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?

>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.

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).