ESP8266 mit OLED Display in Blinddeckel

[tomster]

Dass die Dinger nix für Grobmotoriker sind, ist mir durchaus bewusst. Wenn ich mir aber die Konstruktion mit der Umlenkung durch die Platine um 180° ansehe, dann wäre ich davon ausgegangen, dass die Folien eine gewisse Unempfindlichkeit mitbringen müssten...

[Omega-5]

Dass die Dinger nix für Grobmotoriker sind, ist mir durchaus bewusst. Wenn ich mir aber die Konstruktion mit der Umlenkung durch die Platine um 180° ansehe, dann wäre ich davon ausgegangen, dass die Folien eine gewisse Unempfindlichkeit mitbringen müssten...

Outch, das sieht wirklich erschreckend aus. Allerdings bestand beim MINDSTORM das Kontaktproblem beim Übergang von der Folie zum Glasträger. "Leiterbahnen" auf dem Glas auf gedampft, Folie mit Leitkleber aufgebracht. 
Ich weiß nicht wie das bei diesem Display ist. War nur so ein Gedanke.

Gruß Friedrich

[wingfighter]

Hallo Tomster

Naja, die Screen-Ideen sehen ja schon mal gut aus.
Wenn Du in der Art mal alle Screens zusammenstellst, die Dir so vorschweben, kann man daraus was machen. Eventuell müsste man 1-3 Display-Prototypen definieren, damit solche Dinge, wie "große" Temperaturen und "kleine" Luftfeuchtigkeiten oder ähnliche Kombinationen, separat mit Daten gefüllt werden können.

Zurzeit binde ich das Template von Pf@nne ein, damit die Konfiguration möglichst ohne Eingriff in den Quellcode funktioniert. Dann kann man ein Update auch mal OTA einspielen und das Sketch holt sich die Konfiguration aus dem Speicher des ESP.
Im Moment muss ich nur noch die Subscribes umsetzen, so dass die von FHEM gesendeten Daten wieder angezeigt werden.
Dann habe ich mir vorgenommen, die OLED-Funktionen in das Template auszulagern und auch die NTP-Funktionen dorthin zu schieben. Dann wird das eigentliche Sketch übersichtlicher.

Für die Übertragung der kleinen Grafiken können wir auch auf die im  Speicher hinterlegte Grafiken zurück greifen oder diese uns per MQTT vom FHEM senden lassen. Das ist eine Frage des Aufwands.
Das Wetter selber würde ich z.B. von Yahoo holen. Die liefern das schön übersichtlich im JSON Datenformat aus.

Und wenn Du mit den Font-Test ein zufriedenstellendes Ergebnis gefunden hast, können wir auch den gesamten ASCII-Umfang einbauen. Im Moment habe ich nicht mal ein "-" vorgesehen. Das würde Deiner Ski-Affinität etwas entgegen wirken.

Gruß wingfighter

[Rince]

Dann habe ich mir vorgenommen, die OLED-Funktionen in das Template auszulagern und auch die NTP-Funktionen dorthin zu schieben.

Entschuldigung wenn ich mich einmische.

Möchtest du die Funktionen vielleicht in je ein eigenes Template auslagern? Dann könnte man einfacher deine Software auf z.B. ein anderes Display portieren.

[tomster]

Den Pf@nne'schen Ansatz hab ich mitverfolgt, mangels tieferem Einstieg aber noch nicht gänzlich verstanden. Die Grundidee gefällt mir aber sehr gut. Ein Grundframework, welches dann um die entsprechenden Funktionen erweitert wird. Ebenso die Idee mit Templates.

Prinzipiell reichen mir die beiden Displays schon. Temperatur würde dann zwar nochmal in "Berg" und "Tal" unterschieden, aber dabei würde am Layout nix geändert. Klar, wenn man auch die Graphiken per MQTT senden kann (wusste nicht, dass das geht), dann ist man wohl maximal flexibel. Ob man für das Wetter auf Yahoo oder sonstnochwas zurückgreift ist glaub ich egal. Das lassen wir Mal schön brav FHEM machen

[Rince]

Für die Übertragung der kleinen Grafiken können wir auch auf die im  Speicher hinterlegte Grafiken zurück greifen oder diese uns per MQTT vom FHEM senden lassen. Das ist eine Frage des Aufwands.

Wenn du dss hinbekommst, bist du mein persönlicher Held.

Habe nur das bis jetzt gefunden für Bilder via MQTT senden:
https://developer.ibm.com/recipes/tutorials/sending-and-receiving-pictures-from-a-raspberry-pi-via-mqtt/

[Pf@nne]

Moin,

sind das denn dynamische erzeugte Bilder oder reicht es einmal erzeugte Bilder zur Anzeige zu bringen?
Ein vorher in das FS hochgeladene BPM anzuzeigen sollte nicht so aufwändig sein.

Habt ihr denn das MemoryWrite des Displays unter Kontrolle?

[tomster]

Ich denke, dass statische Bilder vollkommen ausreichend sind. Wird sich ja wohl keiner ein Webcam-Bild o.Ä. auf den Futzelschirm schicken lassen, oder? Halt! Wird sind ja FHEM'ler. Da ist quasi alles möglich...
Für den ersten Schritt langt statisch aber ganz sicher, mein ich. Je nach Platz im Flash auch gerne dort abgelegt. NFS/Samba-Share wird's ja für Sming nicht geben, oder?

[Rince]

Sming hat FTP, prinzipiell kann MQTT das aber auch.

Grob gerechnet hat ein BMP Bild in 128x160x24 (3x8 Bit für Farbe) 61 KB.
Video wird wohl nix, aber stell dir mal einen grafisches Temperaturverlauf / Luftfeuchte / Taupunkt - Diagramm vor. Fhem rendert, MQTT überträgt, Display zeigt an

[Pf@nne]

Habt ihr denn das MemoryWrite des Displays unter Kontrolle?

Die meisten Display besitzen einen MemoryWriteMode, damit kann der komplette Bildspeicher in einem Rutsch geschrieben werden.
Das ganze in einer Schleife mit dem geöffneten Pic.bmp, aus dem Byteweise gelesen wird und schon sollte der SPIFFS-File auf dem Display sein.

MQTT geht natürlich auch, da kann man das BMP in Paketen als Payload drann hängen.

[tomster]

Nach ein bissl Überlegung, wäre es vielleicht doch nicht schlecht auch die Windrichtung/-geschwindigkeit auf dem Display zu haben. Ich mach mir dazu Mal am Montag ein paar Gedanken auf meinem "richtigen" Rechner.

Zudem müsste man Ausprobieren, ob es von den Übertragungszeiten hinhaut aus dem Display ein Statusdisplay für Schalter zu machen. Beispiel:
Im Schalterprogramm ist ein Display verbaut und darunter ein HM 6-fach-Schalter zur Steuerung z.B. einer Squeezebox. Ich hab das derzeit ohne Display am Laufen. Funktionen: Ein/ Aus, Laut/ Leise und Playlist, bzw.Stationstasten rauf /runter. Bei Allem fehlt einem ja das Feedback. Ein/ Aus und Laut/Leise kann man ja mit seinen Sinnen gerade noch sofort erkennen. Nur bei Letzterem weiß man nach ein paar Klicks nicht mehr auf welcher Stationstaste man nun ist (außer man erkennt die Radiostation akustisch). Die Frage wäre nun, wie lange die Übertragungszeit von:
Stationstaste rauf->FHEM->MQTT-Device->Publish->Anzeige auf dem OLED dauert. Sprich, ob damit eine vernünftige Bedienung überhaupt möglich ist. Mal nur so als Idee...

[Pf@nne]

Grob gerechnet hat ein BMP Bild in 128x160x24 (3x8 Bit für Farbe) 61 KB.

Die meisten Displays haben 2Byte für ein Pixel (RGB / 5-6-5) was dann 128x160x2 =  40.960 Byte = 40kB sind, das sehe ich bei Netzwerkgeschwindigleit nicht als Problem an.
Das sollte sehr flüssig gehn, man muss ja auch nicht immer gleich alles überschreiben, ein Icon oder eine Textzeile ändern ist ja nur ein Bruchteil.

Interessanter ist die SPI-Geschwindigkeit. bei 1MHz würde ein ganzer Screen 40.960 Byte / (1.000.000 / 8 = 125.000 Byte pro Sekunde) =  328ms brauche, was dann 3 FPS wären.
Für Text- oder Statusanzeigen sollte das gehen.

Kann aber auch sein, das der ESP mehr als 1MHz kann.

[Rince]

Also das ST7735 werkelt angeblich mit bis zu 65 MHz am SPI Bus vom ESP8266. Aber um das ging es hier ja nicht.

Since ST7735 cannot work over 65Mhz I had to modify a parameter in library settings to fix. Now tested and works with ESP8266 as it should, proof of working on github.
Thanks for feedbacks! - See more at: http://www.esp8266.com/viewtopic.php?f=29&t=8428#sthash.xELB5n96.dpuf

(mehr als 65 haben nicht funktioniert, steht im Thread beschrieben)

[tomster]

Nun, so der richtige Designhammer ist nicht draus geworden. Aber nun steht auch der Wind im Display.
Die beiden Icons links und rechts würde ich werteabhängig einblenden. Beispiel: Windspeed > 25 km/h -> Icon da, sonst nicht.

Das andere Beispiel wäre als Statusdisplay für z.B. eine Squeezelite-Instanz gedacht.

[wingfighter]

Hallo tomster

Na das sieht ja schon mal gut aus. Da kann man 'was d'rauß machen. 

Ich bin gerade dabei das HTML-Interface und Konfigurations-Sketch von Pf@nne (ESP8266_Basic) einzubauen und so zu erweitern, dass wir dort statische Angaben, wie z.B. Maßeinheiten oder Namen externer Messwert- oder anderer -zuspielungen konfigurieren können. Das erleichtert das Senden der Daten per MQTT.

Ich bin für die Anzeige der Icons, für die ich den Ausgabebereich des Displays auf die Icongröße einschränken würde, auf ein Problem gestoßen.
Normalerweise ist der Ausgabebereich auf 0-159 bzw. 0-127 definiert. Man kann sich aber Fenster definieren, in denen der Zeilenumbruch beim Schreiben (Das ist der von Pf@nne angesprochene MemoryWrite-Modus)  automatisch durch das Display gehändelt wird. Allerdings führt das Festlegen eines solchen Ausgabebereiches momentan dazu, dass das Display keine Änderungen mehr annimmt. Sicher habe ich da einen Denkfehler in der Programmierung. Muss ich mal ein paar Tage drüber nachdenken.

Bei den Versuchen, den Fehler einzugrenzen, habe ich das Display u.a. mit diversen Farben gefüllt. - Es gibt da übrigens verschiedene Modi (um mal auf den Post von Pf@nne zurück zu kommen). Im Moment habe ich den 18-Bit Modus aktiv. Also RGB 6-6-6 Bit. In einem anderen Test für die Library habe ich den 16-Bit-Modus aktiv - also 5-6-5 Bit.
Um Dateigröße zu sparen, ist das sicher ausreichend. - Jedenfalls ist mir beim Füllen des Gesamte-Displays mit der Farbe weiß aufgefallen, dass man im Bereich der momentan gelb dargestellten Temperaturen und Luftfeuchte-Werte die Zahlen noch erkennen kann. Das sieht aus, wie bei einem alten s/w-Monitor, wenn ständig dasselbe angezeigt wird.
Da sollten wir uns echt Gedanken um die Langzeitbeständigkeit solcher Displays machen.
Eventuell verschwindet der Schatten auch wieder.Das muss ich mal beobachten. 


Das mal kurz zum Zwischenstand

Viele Grüße
wingfighter