Debugdaten über ESP8266 visualisieren

Deinen Ansatz musst du näher beschreiben.

Für Push-Nachrichren ist Webserver (HTTP) doch eher hinderlich. Für so etwas macht man einen wahnsinnigen Aufwand mit Single-Page Webapps und Websockets?

Und Wlan Ausfälle sind doch das letzte, was du da haben willst?

Kompakte Push-Nachrichten über serielle Schnittstelle senden geht doch schneller und zuverlässiger?

Bernd K. schrieb:

Die Frage ist, wie kann ich ein Array aus 200 byte-Werten schnell über eine Webseite visualisieren?

Schaue dir mal das SVG Dateiformat an. Wenn du HTML durch Verkettung von Zeichenketten erzeugen kannst, wird es dir auch nicht schwer Fallen, Grafiken in SVG zu erzeugen. Dieses Datei Format funktioniert nach dem selben Prinzip. Ein Javascript könnte die Seite (oder nur das Bild) regelmäßig neu laden.

https://wiki.selfhtml.org/wiki/SVG https://wiki.selfhtml.org/wiki/JavaScript/Location/reload

Eine andere Variante wäre, Daten im JSON Format an den Browser zu übertragen. Ein Stück Javascript würde die Daten mittels XMLHttpRequest vom ESP holen und dann in einem Canvas Objekt (eine bemalbare Fläche) visualisieren.

https://wiki.selfhtml.org/wiki/JSON https://wiki.selfhtml.org/wiki/JavaScript/XMLHttpRequest https://wiki.selfhtml.org/wiki/JavaScript/Canvas

Für Fragen zu Web basierten Anwendungen schau bei ... du weißt schon wo ... nach.

Falls du den MC, der im RAM zwischenpuffert nicht verändern kannst und es mit Webbrowser machen willst...

Das würde ich in drei Schritten machen.

Zuerst eine ganz normale HTML Seite. Wenn der Browser die Seite holt, die Daten vom MC holen und eine einfache Seite nur mit Text zusammenstellen.

Sobald das funktioniert, der zweite Schritt. Eine HTML Seite, die HTML, Rohdaten und Javascript enthält. Die Daten aufbereitet und darstellt. (Wenn du eine Grafik ausgeben willst - der ESP ist hat nicht genug Ressourcen. Besser als JS im Browser).

Dann eine HTML Seite, die nur einmal geladen wird. Und andauernd neue Daten bekommt und darstellt.

Am performantesten wird es mit Websockets, aber XMLHttpRequest wird auf der Serverseite einfacher. Mit kompakten Binärdaten wird es aufwendig, besser mit JSON.

Auf der Serverseite eine Schleife. Solange der Websocket existiert Daten holen und an den Browser senden. (Oder MC-Programm umbauen - sobald sich was tut, Daten sofort auf die RS232 schreiben).

Ich finde D3 ganz brauchbar, aber da hat jeder andere Ansichten. https://www.youtube.com/playlist?list=PLb0zKSynM2PBWuEhc1lhAzG0MPz8-rlKj

Eine Frage schrieb:

der ESP ist hat nicht genug Ressourcen

ESP Module haben mindestens 250 kB Flash frei und einige Kilobytes RAM. Wenn man SVG generiert, muss man das gar nicht alles am Stück im RAM halten. So wie man (HTML-) Text Schrittweise ausgeben kann, kann man das auch mit SVG tun.

SVG muss man nicht einmal als separate Datei ausliefern, es kann direkt in dem HTML Quelltext eingebettet werden. Ich würde aber trotzdem bevorzugen, es als separate Datei zu laden, weil man dann das regelmäßige erneuern auf die Grafik (anstatt der ganzen Webseite) beschränken kann. Das flackert weniger.

Mir ist gerade aufgefallen...

Dieses Tutorial für Push-Nachrichten über Websockets auf ESP8266 sieht vollständig und kompetent aus.

https://randomnerdtutorials.com/esp8266-nodemcu-websocket-server-arduino/

• Mach nen Websocket
• Nimm ne Library z.B. Plotly https://plotly.com/javascript/line-charts/

Bernd K. schrieb:

Ein Webserver auf einem ESP-01S Modul welches über RS232 mit dem Mikrocontroller verbunden ist, könnte das viel eleganter.

Stefans Rat mit den SVGs war schon sehr gut, aber das muß man nicht manuell generieren. Da gibt es Bibliotheken wie Flot [1] oder jqplot [2].

[1] https://www.flotcharts.org/ [2] http://www.jqplot.com/

Noch ein Kommentar schrieb:

Da gibt es Bibliotheken wie Flot oder jqplot

Guter Tipp - kleine Anmerkung. Bis alles richtig aussieht braucht man 100 Versuche. Programmcode kompilieren und ESP flashen wird zu aufwendig.

Das Elegante an Libraries wie den Genannten ist ja, daß man im Grunde auf der Serverseite nur zwei Dinge braucht: a) etwas, das das HTML-Dokument ausliefert sowie b) etwas, das die Daten per JSON liefert. Letztere Seite läßt sich entweder als Websocket mit Push-Funktionalität oder als simple Rest-Schnittstelle ausführen, während das clientseitige JavaScript dann einfach regelmäßig pollen muß.

Besser zwei Entwicklungsumgebungen. Die Oberfläche mit Browser und Javascript-IDE bzw. Texteditor entwickeln. Nur für die Entwicklung des Websocket/XMLHttpRequest Moduls den ESP benutzen.

Für die Entwicklung würde ich mir jedenfalls eine Art Dummy bauen, der auf meinem Entwicklungsrechner läuft, und die vorgenannten Funktionen anbietet. Ob man dafür zwei Entwicklungsumgebungen braucht? Ich glaube nicht, schon guter Texteditor reicht für beide Seiten sicherlich völlig aus.

Noch ein Kommentar schrieb:

Guter Tipp - kleine Anmerkung. Bis alles richtig aussieht braucht man 100 Versuche. Programmcode kompilieren und ESP flashen wird zu aufwendig.

Besser zwei Entwicklungsumgebungen.

Ja. Ich entwickle Teile meiner C Programme oft mit der Qt Creator IDE auf dem PC, und portiere das dann später auf den Mikrocontroller. Auf dem PC geht das viel schneller und es lässt sich auch besser debuggen.