Closed rocklobster42195 closed 5 years ago
Hi, versuche mal in der index.php die Zeile 120 so abzuändern, dass das Bild um 180° gedreht wird: $im = imagerotate($im, 180, 0); Bei mir klappt es nur so. Liegt wohl an der GD-Lib. Was bei mir auch nicht funktioniert, ist der in der Datei vorgeschlagene Workaround das Bild zwei mal um 180° zu drehen. Björn
Danke für den Hinweis, aber das hat auch leider nicht geklappt. Bei allen Drehvarianten bekomme ich nur die oben beschrieben Zeile angezeigt. Die GxEPD-Beispiele funktionieren übrigens. Boris
Hallo. Könnten Sie mal ein Foto des Displays machen und hier hochladen? Vielleicht klingelt es dann bei mir, was da schief läuft. Außerdem interessant wäre, was Sie im Browser sehen, wenn Sie debug=false setzen.
Hab auch ein 4.2, funzt die URL auch nicht: http://raz0rsedge.de/server/index.php/?debug=true&display=4.2bwr&content=metar_station&scale=18 (crosscheck webserver)? Ist im Projectcode das richtige Display eingebunden? #define DISPLAY_TYPE '4.2' || #define DISPLAY_TYPE '4.2bwr'
Moin,
mich wundert gerade, warum ein HTTP/1.1 301 Moved Permanently
vom Server zurück kommt. Das sollte theoretisch ein Code 200 sein. Außerdem sind 363 bytes an Daten auch zu wenig. Für das 4.2 b/w Display sollte so bei 1500 liegen... Ich würde auf ein Problem mit dem Server tippen. Hab im Moment mein Kit nicht hier, kann es aber heute Abend mal zu Hause testen.
Ach ja, im Arduino Sketch sollte auch #define DISPLAY_TYPE '4.2'
oder #define DISPLAY_TYPE '4.2bwr'
lauten und nicht #define DISPLAY_TYPE '4.2' || #define DISPLAY_TYPE '4.2bwr'
(Zeile 9 ).
Mit Brille konnte ich gestern sehen, dass das keine Zeichen sondern nur vier Pixelzeilen sind. Wahrscheinlich eine Fehlermeldung mit Pixeln dargestellt. Ich lasse mir jetzt die Grafik von einem Tomcat-Server liefern, das funktioniert bisher. Die Portnummer des Servers in der Web-Config wäre hilfreich.
Die Zeile HTTP/1.1 301 Moved Permanently
könnte das Problem sein. Offensichtlich ist im Webserver eine Umleitungsregel hinterlegt. Ein Browser folgt dieser Umleitung, die AsyncTCP-Bibliothek kann das aber nicht und das Display versucht, die angekommenen Byte anzuzeigen – was dann scheitert.
Leider fällt mir auch grad keine fertige Lösung ein, die man einsetzen könnte, um AsyncTCP um die Fähigkeiten aus HTTP zu erweitern.
Da es ja anscheinend wirklich an meinem Server liegt, kann das Ticket von mir aus geschlossen werden.
Redirects sind ja nichts komplett Exotisches und sollten funktionieren (kommt auch bei Hosting mal vor). Deshalb lass ich das mal offen, vielleicht kommt jemand auf eine Idee.
Man könnte den Parser, den ich z.B. für die Zeiten in #22 geschrieben hatte entsprechend anpassen und den Code 301 entsprechend handhaben. Jedoch denke ich, dass das eher von einer entsprechenden Bibliothek für einen asynchronen Webclient erledigt werden sollte. Diese müsste sich dann evtl. auch noch um weitere HTTP-spezifische Probleme kümmern. Jedoch scheint es da im Moment noch nichts brauchbares zu geben.
Hallo, ich habe exakt das gleiche Problem wie rocklobster42195. Ich bekomme ebenfalls die Fehlermeldungen korrekt angezeigt, kann am PC im Browser die Bilder richtig sehen, aber mit "/gfx?debug=false&content=static_image" bekomme ich auf dem E-Ink-Display nur die Pixelzeilen. Bei mir sind es allerdings nur ca. 2,1 Zeilen im Querformat am oberen Rand. Ich vermute das liegt daran, dass ich das Waveshare 7.5 habe und somit horizontal mehr Pixel zur Verfügung. Der Tipp mit dem Drehen funktioniert bei mir ebenfalls nicht, die GxEPD-Beispiele funktionieren ebenfalls einwandfrei. Meine Konfiguration ist allerdings ein wenig anders, ich habe einen
Hier die serielle Ausgabe (Danke @jamct wie das geht :-) )
ets Jun 8 2016 00:22:57
rst:0x1 (POWERON_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:1 load:0x3fff0018,len:4 load:0x3fff001c,len:956 load:0x40078000,len:0 load:0x40078000,len:13076 entry 0x40078a58 Basecamp V.0.1.6 MAC-Address: 30:ae:a4:45:47:98 Wait till the client is connected OnConnect
OnData: 319 Bytes HTTP/1.1 404 Not Found Server: nginx/1.10.3 Date: Wed, 14 Mar 2018 10:17:24 GMT Content-Type: text/html Content-Length: 169 Connection: close ProductionMode: 0 Printing 169 Bytes to the screen OnDisconnect update : 4267678 transmitDoneNot going to deep sleep. Reason: Not in production mode Not going to deep sleep. Reason: Not in production mode Wait till the client is connected OnConnect
Bei mir scheint das Problem aber doch ein anderes zu sein: "HTTP/1.1 404 Not Found"
Zur Vermutung von jamct, dass das an einem Redirect liegen könnte: Könnte es evtl. sein, dass das bei mir damit zusammenhängt, dass auf dem Server über nginx auch ein seafile-server (https) läuft? Das Testbild mit debug=true wird aber wie gesagt korrekt im Browser angezeigt.
Hier noch ein Bild der Anzeige
Werde jetzt mal versuchen den Tipp mit dem Tomcat-Server umzusetzen.
Viele Grüße
Tobias
Die serielle Ausgabe bekommen Sie über die Arduino-IDE:Per USB anschließen und über "Werkzeuge>Serieller Monitor" die Ausgabe öffnen. Dann ggf. den Reset-Button auf dem ESP-Board benutzen, damit er noch mal bei 0 anfängt.
@jamct: Vielen Dank, hab gerade oben die serielle Ausgabe ergänzt.
In der seriellen Ausgabe steht das Problem: "HTTP/1.1 404 Not Found". Die eingegebene Adresse existiert also nicht. Kann es sein, dass Sie sich von @rocklobster42195 auf eine falsche Spur haben leiten lassen und /gfx übernommen haben (das ist eine individuelle Anpassung durch den Nutzer)? Wenn Sie das Projekt herunterladen, heißt die Datei "/index.php?...".
Ich habe das Problem gefunden. Es war zwar nicht /gfx und ich weiß nicht genau warum, aber ich muss im Webinterface statt: /index.php/?debug=false&display=7.5&content=static_image nur /?debug=false&display=7.5&content=static_image angeben. Also das Weglassen von /index.php war die Lösung. Damit funktioniert die Anzeige einwandfrei.
Vielen Dank für die schnelle Hilfe! :-)
Zur Vollständigkeit: Die serielle Ausgabe ist dann folgende:
ets Jun 8 2016 00:22:57
rst:0xc (SW_CPU_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:1 load:0x3fff0018,len:4 load:0x3fff001c,len:956 load:0x40078000,len:0 load:0x40078000,len:13076 entry 0x40078a58 Basecamp V.0.1.6 MAC-Address: 30:ae:a4:45:47:98 Wait till the client is connected OnConnect
OnData: 1436 Bytes HTTP/1.1 200 OK Server: nginx/1.10.3 Date: Wed, 14 Mar 2018 10:56:00 GMT Content-Type: text/html; charset=UTF-8 Content-Length: 30720 Connection: close ProductionMode: 0 Printing 1276 Bytes to the screen OnData: 1436 Bytes Printing 1436 Bytes to the screen OnData: 1436 Bytes Printing 1436 Bytes to the screen OnData: 1436 Bytes Printing 1436 Bytes to the screen OnData: 1436 Bytes Printing 1436 Bytes to the screen OnData: 1436 Bytes Printing 1436 Bytes to the screen OnData: 1436 Bytes Printing 1436 Bytes to the screen OnData: 1436 Bytes Printing 1436 Bytes to the screen OnData: 1436 Bytes Printing 1436 Bytes to the screen OnData: 1436 Bytes Printing 1436 Bytes to the screen OnData: 1436 Bytes Printing 1436 Bytes to the screen OnData: 1436 Bytes Printing 1436 Bytes to the screen OnData: 1436 Bytes Printing 1436 Bytes to the screen OnData: 1436 Bytes Printing 1436 Bytes to the screen OnData: 1436 Bytes Printing 1436 Bytes to the screen OnData: 1436 Bytes Printing 1436 Bytes to the screen OnData: 1436 Bytes Printing 1436 Bytes to the screen OnData: 1436 Bytes Printing 1436 Bytes to the screen OnData: 1436 Bytes Printing 1436 Bytes to the screen OnData: 1436 Bytes Printing 1436 Bytes to the screen OnData: 1436 Bytes Printing 1436 Bytes to the screen OnData: 724 Bytes Printing 724 Bytes to the screen OnDisconnect
Hallo, das Problem ist der zusätzliche "/" nach dem index.php, ohne den sollte es gehen.
/index.php/?debug
Uh, klar! Ok, vielen Dank @netaddict für das Entfernen der Tomaten auf meinen Augen. 8-) => :-)
Ich weiß nicht, ob es das gleiche Problem ist. Auf dem Testserver (PC) wird die Grafik korrekt ausgegeben. Auf dem Produktionsserver allerdings wieder nicht. Ich bekomme wieder "zufällige" Pixelzeilen und danach erst die Grafik. Diese ist dann natürlich verschoben:
Das ist ein etwas anderes Problem, für das ich mal eine Lösung erarbeiten muss: Vor der Bildausgabe gibt der Server irgendwas zurück, was da nicht hingehört (z.B. eine Warning, weil eine Variable leer ist). Sie könnten mal per Browser das Bild mit debug=false öffnen und schauen, ob da lesbarer Text auftaucht, mit dem Sie etwas anfangen können.
Ich konnte das Problem (mein Foto) auf eine fehlerhafte Tomcat-Installation zurück führen. Anscheinend wurde meine Header nicht als solche identifiziert und wurden mit ausgegeben. Mit einer aktuellen Tomcat-Version läuft es jetzt.
Hallo, ich brauch mal eure Hilfe. ESP32 (Wemos) und Display (Waveshare 4.2) sind anscheinend korrekt angeschlossen. Ich bekomme die Anzeige "Wifi not configured (...)" auf dem Display zu sehen. Ich habe eine statische PNG auf den Server gelegt, mit "debug=true" wird die Grafik im Browser angezeigt. Gebe ich in der Web-Config aber "/gfx?debug=false&content=static_image" ein und speichere, wird eine Zeile mit kleinen Schriftzeichen (?) ausgegeben. Das ist übrigens bei allen Beispielen so.
Seriell bekomme ich dabei folgendes ausgegeben:
Ich weiß jetzt echt nicht mehr weiter und wäre für Tipps dankbar. Viele Grüße Boris