ESP8266 mit OLED Display in Blinddeckel

[wingfighter]

Ich nutze im Moment auch einen 12E. Aber tomster wollte wohl wegen des Platzes in der UP-Dose einen ESP-01 einsetzen.
Da dürfte es mit den GPIO's aber etwas knapp werden.

[Rince]

Aber tomster wollte wohl wegen des Platzes in der UP-Dose einen ESP-01 einsetzen.

Hm.
01: 14,3 x 24,8
12: 16 x 24

So riesig ist der Unterschied jetzt nicht. Jedenfalls keinesfalls ein Show-Stopper für ne UP-Dose. Aber kniffliger zu löten, da die 2,54mm Header fehlen.

Wenn man die ernsthaft in größeren Zahlen einsetzt, wäre evtl. eine kleine Adapterplatine Display - ESP nicht unschlau.

[AxelSchweiss]

Nur mal so als Mitleser  .. eventuell hilft es ja.
Es gibt bei Youtoube von einem Schweizer ein Video wie man den Flash von einem ESP-01 gegen den von einem ESP-12 tauscht.
https://www.youtube.com/watch?v=xyc1gCjguRU
Ist etwas frickelig aber machbar.
Wenns unbedingt die Größe macht 

[tomster]

Ich nutze im Moment auch einen 12E. Aber tomster wollte wohl wegen des Platzes in der UP-Dose einen ESP-01 einsetzen.

Fast. Ich möchte einen ESP-07 einsetzen. Eben weil es einen herausgeführten Antennenanschluss hat. Da ich nicht weiß wie sehr die UP-Dose und der Gira-Rahmen abschirmen, wollte ich eine Mickey-Maus-Blechantenne in die Flanke des Blinddeckels kleben. Damit ist die Antenne "außerhalb" des ganzen Blechs. Zudem gibt es ein Breakoutboard, welches wunderbar in den Rahmen passt. Ich habe heute aber auch eine Lieferung D1minis auf dem Schreibtisch gehabt. Die sind vom Formfactor ungefähr genauso groß.

Der nodeMCU passt zwar auch ins Gehäuse, aber nur gerade so. Der USB-Anschluß ist dann z.B. zur Stromversorgung nicht mehr nutzbar.

Ich weiß momentan zwar nicht was ich zuerst machen soll, aber die Displays machen sich im GIRA-Programm wirklich gut!
Habt ihr die TFTs auch schon mit Touchscreen gesehen?
Habt ihr noch weitere Links zu ggf. günstigeren Displays?

Das NewHaven-Display  habe ich ausgesucht weil a. ich kein anderes 1.8" gefunden habe, das (mit wenig Modifikationen) in den Blinddeckel passt und b. OLED ist. Mein Einsatzbereich soll in den Schlafzimmern sein. Da brauche ich ja eine Art Backlight. Vorteil vom OLED ist, dass eben jedes Pixel für sich leuchtet. Damit bleibt das Display im Gesamteindruck "dunkler", sprich die schwarzen Bereiche leuchten nicht. -> WAF

Touchscreens hab ich noch nicht gefunden. Zumindest keines mit 1.8 Zoll, von den Maßen passender Trägerplatine und/ oder entsprechender Auflösung. OLED sowieso nicht.

Displays gibt es wie Sand am Meer. Leider auch mit ebensovielen unterschiedlichen Chipsätzen. Da ich absoluter Arduino-Neuling bin, hab ich keine Ahnung welche Chipsätze unterstützt werden. Aber ohne die hervorragende Arbeit von wingfighter würde das NewHaven auch nicht laufen...

Eine Trägerplatine zum Aufstecken hab ich mit auch schon überlegt. Das ginge prinzipiell schon. Ich wollte aber einen Aufbau haben, der von der Höhe ggfls. auch als Aufputz-Blinddeckel funktioniert. Das geht mit einer Aufsteckplatine nicht. OK, die Plasitikclips, die den Deckel im Blechrahmen festhalten stören auch. Aber es wäre einfacher 2 kleine Schlitze in die Wand zu machen, in die die Clips passen (und der Rahmen dann bündig auf der Wand aufliegt), als noch zusätzlich den Platz für die ESP-Platine zu schaffen...

[tomster]

So, ich hab Deinen letzten Sketch Mal im Arduino geöffnet. Leider bekomme ich eine Fehlermeldung, auf die ich mir (wohl meiner Laienhaftigkeit geschuldet) keinen Reim drauf machen kann:

Code Auswählen Erweitern


NHD-1.69-160128UGC3_ESP8266_Temp_Hum:120: error: 'mqttCallback' was not declared in this scope

PubSubClient mqttClient(mqtt_server, 1883, mqttCallback, MQTTClient);
                                         
exit status 1
'mqttCallback' was not declared in this scope


MQTT ist doch declared. Nur einige Zeilen weiter unten, oder?

[wingfighter]

Hallo Tomster

Eine schnelle Antwort, damit Du weiter testen kannst:
Sicher nutzt Du die IDE > 1.6.5. Da ist wohl ein neuer Prcompiler rein gekommen, der - so wie es auch richtig ist - beim Übersetzen die Funktionen, die er findet, schon mal irgendwo im Qelltext dadrüber gesehen haben muss, damit er sie kennt. Entweder als reine Deklaration oder als komplette Funktion.
Ich bin deswegen wieder zur 1.6.5 zurück kgekerht, weil viele Sketche, die ich gestestet habe, keine saubere Reihenfolge in den Funktionsaufrufen hatten und der Compiler dann genau diese Fehlermedlung bgingt, die Du auch hattest.

In der vorletzten Version hatte ich die Deklaration noch im Sketch. Das müsste in etwa in Zeile 120 gewesen sein.

Trage dort einfach mal folgende Zeile ein:

Code Auswählen Erweitern

PubSubClient mqttClient(mqtt_server, 1883, mqttCallback, MQTTClient);

Also noch vor der ersten Funktion.

Code Auswählen Erweitern

// init MQTT-Client
WiFiClient MQTTClient;
PubSubClient mqttClient(mqtt_server, 1883, mqttCallback, MQTTClient);

/*********************************/
/******** FONT TABLE 5x8 *********/
/************* START *************/
/*********************************/

Das sollte dann so aussehen.
Und schreib mal, ob das die Ursache für den Fahler war.

Gruß wingfighter

[tomster]

Hmm, ich hoffe nicht, dass ich mit den Sketch-Versionen durcheinenander geraten bin, aber die Zeile steht bei mir schon genau so drin...
Genommen hab ich diese Variante:
https://forum.fhem.de/index.php/topic,50697.msg434439.html#msg434439

[tomster]

So, hab nochmal den Sketch-Ordner gelöscht, neu runtergeladen und von vorne begonnen. Nun kompiliert es!
Keine Ahnung was da gefehlt hat....

Wenn ich jetzt noch die MQTT-Devices in FHEM angelegt hätte (und diese Daten senden würden), dann vermute ich wäre ich genau da wo du jetzt bist

Anscheind ist jedoch die Zeit auch abhängig von einem Refresh eines Sensorwerts. Da bei mir aber nix gesendet wird, bleibt die Uhrzeit direkt nach dem Flashen quasi auf die Systemstartzeit festgenagelt, nach einem Reset nach nur einem Temp/Feuchte-Cycle schwarz...

[wingfighter]

So, jetzt habe ich mir den Sketch mal unter IDE 1.6.7-Bedingungen angeguckt.
Ich hatte vorhin nur die halbe "Wahrheit" geschrieben.

Zur Deklaration muss also eine Zeile eingetragen werden. Siehe folgender Ausschnitt:

Code Auswählen Erweitern

// init MQTT-Client
WiFiClient MQTTClient;
void mqttCallback(char* topic, byte* payload, unsigned int length);    // <---- Funktionsdeklaration
PubSubClient mqttClient(mqtt_server, 1883, mqttCallback, MQTTClient);

/*********************************/
/******** FONT TABLE 5x8 *********/
/************* START *************/
/*********************************/

Ich hatte vorhin das richtige gemeint und auf die Schnelle das falsche geschrieben.
Aber wenn es bei Dir jetzt dennoch compiliert, ist es ja erst einmal gut.

Zu Deiner Frage:
Die Standardmesswerte holt sich das Sketch vom angeschlossenen DHT22 - siehe Fritzingplan weiter oben. Das ist natürlich für den Endausbau nicht unbedingt notwendig, da ja ohnehin nicht viel Platz in der UP-Dose ist. Für den Test war es aber erst einmal hilfreich.
Die Uhrzeit holt sich das Sketch per NTP aus dem Internet. D.h., wenn Dein ESP kein Zugriff zum Internet hat, läuft die Uhr bei 00:00 01.01.1970 los. Das passiert auch, wenn der NTP-Server temporär nicht erreichbar ist. Für diesen Fall muss ich noch eine Routine einbauen, die dann regelmäßig probiert, die Zeit zu holen.
Eigentlich sollte das Stellen der Zeit auch funktionieren, wenn man als NTP-Server den Router einträgt (z.B. eine FritzBox). Das habe ich aber noch nicht getestet.

Wenn Du es  ohnehin nicht schon getan hast, schalte mal den seriellen Monitor ein. Ich lasse im Moment eine Menge Debug-Ausgaben machen, damit man eventuellen Fehlern leichter auf die Schliche kommt.

[tomster]

Nein, nein. Die Uhrzeit zeigt er richtig an. WiFi & NTP funktionieren einwandfrei.
Nur beim Update der "Messwerte" scheint noch etwas im Argen zu liegen. Wenn ich KEINE mqtt-Devices in FHEM angelegt habe, dann läuft der Cycle der beiden Displays Temperature/ Humidity einmal durch (im definierten 2000ms Cycle). Dann ist das Display wieder für mindestens 1 Minute schwarz. Danach wieder 1-2 Cycles und wieder schwarz für einige Zeit.

Das Verhalten wird zwar mit angelegten Devices leicht besser (mehrere Cycles), aber auch dabei bleibt das Display wieder für längere Zeit schwarz...

[wingfighter]

Die beiden Messwerte, die mit Luftfeuchte und Temperatur überschrieben sind, holt sich der ESP vom angeschlossenen DHT22.
Die haben erst einmal nichts mit MQTT zu tun.
Wenn das Display allerdings komplett schwarz wird und nach einiger Zeit wieder etwas anzeigt, klingt das eher nach einem Reset und Neuanlauf des Sketches.
Das siehst Du aber in der Ausgabe des seriellen Monitors.
Hast Du zum Testen einen DHT22 am ESP angeschlossen? Wenn nicht muss ich das intern sicher abfangen.

Gerade ohne DHT22 getestet: Zeigt er halt 00.0 °C und 00.0 % an.
Hm?

[tomster]

Ja, bei mir zeigt auch die Nullwerte an. Leider nur 1 Cycle lang. Könnte gut sein, dass der Sketch rebootet. Ich check das morgen Mal (hab die Teile im Büro liegen) mit dem seriellen Monitor.

[tomster]

Mit der oben genannten zusätzlichen Zeile funktioniert es irgendwie "schlechter", also hab ich sie wieder rausgenommen.
In FHEM hab ich eine MQTT-Bridge, analog Deines Beispiels definiert.
Damit bekomme ich anfangs - wie erwartet - 4 Displays angezeigt:
Temperatur
Luftfeuchte
Display1
Display2

Danach ist es aber wieder für eine unterschiedlich lange Zeit schwarz, bis wieder die obigen Displays angezeigt werden.

Erst dachte ich, dass der Sketch versucht weitere Displays anzuzeigen, weil die blaue LED am ESP beim schwarzen Bildschirm ca. alle 2s kurz flackert. Da diese aber nicht existieren bleibt das Display schwarz. Leider ist aber kein wirkliches Intervall (z.B. 2s pro Display; 10 Displays = 20s) festzustellen. Die Intervalle bis wieder was angezeigt wird sind schlichtweg zufällig lang. Mal 15s, Mal 60s, Mal 80s, etc...

Ich hoffe nicht, dass die Art der Anbindung an FHEM einen Ausschlag gibt. Der ESP ist über WLAN -> VPN an das Netz angebunden, in dem der FHEM-Server hängt.

Meinst Du man könnte eine Art Splash-Display beim Booten einbauen, so dass man am Display sehen kann, dass neu gestartet wird? Eine Textzeile würde da ja reichen...

[wingfighter]

Hallo Tomster

Natürlich kann man ein paar Zeilen Debug-Text auf dem Display ausgeben. Aber dafür hatte ich ja die Ausgaben in dem seriellen Monitor vorgesehen. Der schreibt auch viel mehr aus, als sich auf dem Display anzeigen lässt. Klappt das bei Dir nicht? Der Monitor muss auf 115200 Baud stehen.

Ein "schlechter" funktionieren mit der Funktions-Deklaration klingt aber sehr unspezifisch. Die ist ja 'nur' für den Precompiler da und hat im fertigen Programm keine Auswirkung auf die Funktionalität.
Eventuell hast Du aber die "falsche" MQTT-Bibliothek in der Arduino-IDE importiert. Da gibt es verschiedene Parallel-Entwicklungen. Ich werden nachher mal schauen, welche ich verwende und sie hier verlinken oder anhängen.

Gruß wingfighter

[tomster]

Ok, die falsche Baudrate war das Problem. Nun schreibt er.

Ich habe zudem Mal im Sketch beim init des Displays nach dem "blanken" eine Textzeile "Starte..." eingefügt. Nun weiß ich zumindest, dass er in den Schwarzphasen wohl nicht rebootet. Warum er aber dennoch diese Schwarzphasen hat, erschließt sich mir noch nicht. Das Script sollte doch eigentlich durch die 4 Displays (DHT Temp, DHT Feuchte, FHEM Temp, FHEM Feuchte) unendlich cyclen, oder?