ESP8266 mit OLED Display in Blinddeckel

[wingfighter]

der Sketch müsste doch dann gleich in den "Normalmodus" gehen, oder?

Stimmt. Es gibt im Moment nur einen Grund, warum nichts angezeigt wird und das ist die Variable "config_running", die gesetzt wird, wenn der AP-Modus aktiv ist. Und wenn diese nicht gesetzt ist, werden die Screens angezeigt.

Ich hab die 1.6.7

Spricht etwas dagegen, wenn Du testweise mal die 1.6.8 nutzt?
Ich habe die 1.6.7 auch drauf. Werde mal testen, ob der von Dir beschriebene Effekt auftritt, wenn ich das *.bin damit erzeuge.

Ich frage mich allerdings, wie ich das bin-File OTA updaten soll, wenn ich gar nicht auf das GUI komme...

Das ginge ja "zur Not" auch mit dem Ur-ESP8266_Basic von Pf@nne. Du hattest ja geschrieben, dass die läuft.

[tomster]

Hab jetzt Mal auf 1.6.8 upgedated. Momentan kämpfe ich mich aber noch durch die Libraries, die mir die Install-Routine netterweise gelöscht hat...

Ja, stimmt, der Pf@nne'sche Sketch sollte das erledigen können.

So, nun hab ich den 0.33'er Sketch Mal mit 1.6.8 geflasht. Es gibt einen kleinen großen Fortschritt. Nun zeigt mir das Display am Anfang kurz Uhrzeit und Datum. Zunächst erst Epoch-Time, dann nach NTP-Update  die aktuelle Zeit. Danach ist aber wieder alles schwarz.
ABER:
Ich komm auf das WebGUI!!!

Und kaum hab ich einmal die Config gesichert, hab ich nun wieder die Screens! *freu*

[wingfighter]

Na das klingt doch schon mal gut.
Ich hab' Dir eine PM hinterlassen

[wingfighter]

So, nun habe ich auch das Font-Abstands-Problem gelöst.
Die Ursache für die unterschiedlichen Abstände ist die Art, wie der Font aus dem Tool TheDotFactory exportiert wird - nämlich linksbündig und Byte orientiert.
Breite Buchstaben, wie das kleine m, werden zentriert ausgegeben, weil sie das Maximum an Platz beanspruchen. Eine 1, ein ! oder ein i hingegen belegen ein Byte Breite und nutzen die linken 2 Bit, so dass rechts bis zum nächsten Buchstaben 6 Bit + Zeichenabstand (2 Bit) Luft sind. Viele Zeichen bestehen aus zwei Byte und belegen im rechten Byte gerade mal das MSB. Dann sind zum nächsten Buchstaben sogar 9 (7 +2) Bit Luft.

Ich habe jetzt die Routine zur Berechnung des gemittelten Ausgabe und die Ausgabe selber so umgestellt, dass vorher ermittelt wird, welches Bit im rechten Byte das rechteste Bit ist. Und dann wird der Buchstabe auch nur soweit bearbeitet, bis in allen 22 Zeile des Fonts dieses rechte Bit (LSB) ausgegeben ist. Der neue Buchstabe beginnt dann 2 Pixel rechts davon. Damit fallen alle leeren Bitspalten rechts vom LSB weg.

Und ich denke, so kann man die Ausgabe auch wieder gelten lassen.

Ich hab' mal Version V0.34 angehängt.

[tomster]

Nun sieht's doch wirklich Spitze aus! Allerdings bleibt nun immer weniger, was ICH zu diesem Projekt beitragen kann...

Ich hab mich am Mittwoch noch ein bisschen mit den Farben des Texts gespielt.
Zunächst dachte ich, dass die Farbe nach entsprechenden RGB-Werte in HEX mit vorangestellten 0x angegeben wird.
Nachdem dabei aber völlig abweichende Farben rausgekommen sind, hab ich gemerkt, dass Du die Farben nicht in RGB angibst, sondern in BGR. Hat das einen bestimmten Grund?

Die Tage werd ich mich Mal an alternative Iconsets machen und die gschwind Photoshoppen. Dann hat man ein bisschen Auswahl, welche man verwenden möchte.

Ach ja, weil's mir grad einfällt bezüglich der MQTT-Werte:
Was hältst Du davon, wenn man den Sketch so umstrickt, dass MQTT-Devices, respektive deren Werte, subscribed und nicht gepushed werden? Also, wenn das überhaupt geht...
Ich denke da an den Einsatz mehrerer Displays. Momentan schreibt eine MQTT-Bridge ja die von einem Sensor empfangenen Werte mittels publish direkt auf das Display mittels z.B. ESP8266_1416929/Display/NHD_1.69/Screen_0. Kann man es nicht so einrichten, dass beim Einsatz mehrerer Displays (Wohnzimmer, Schflafzimmer, etc.) jedes Display einfach das gewünschte MQTT-Device pollt? Wäre doch sinnvoller, wenn man nur 1 Device anlegen müsste, welches dann von beliebig vielen Displays angezeigt werden kann, anstatt für jedes Display eine eigene Bridge anlegen zu müssen, oder?
Oder hab ich das System MQTT komplett  mißverstanden?

[tomster]

Ich habe jetzt die Routine zur Berechnung des gemittelten Ausgabe und die Ausgabe selber so umgestellt, dass vorher ermittelt wird, welches Bit im rechten Byte das rechteste Bit ist. Und dann wird der Buchstabe auch nur soweit bearbeitet, bis in allen 22 Zeile des Fonts dieses rechte Bit (LSB) ausgegeben ist. Der neue Buchstabe beginnt dann 2 Pixel rechts davon. Damit fallen alle leeren Bitspalten rechts vom LSB weg.

Und ich denke, so kann man die Ausgabe auch wieder gelten lassen.

Fast. Ein "Space" wird falsch dargestellt. Augenscheinlich kann der Sketch die korrekte Breite eines "Space" nicht ermitteln und verwendet (in meinem Fall) den davorstehenden Buchstaben doppelt. Ich habe also statt "Wetter Tal" WetterrTal" da stehen.

Zudem bekomme ich die MQTT-Sensorwerte in der horizontalen Ausrichtung nicht vernünftig "gemittelt". Ich hab Deinen Code ab Zeile 1650 ein bisschen angepasst, weil ich nicht die Platzhalter "0.00°C" haben wollte, sondern lieber etwas wie "n/a" um gleich zu sehen, ob vielleicht gar kein Wert übermittelt wurde. Drum muss ich ja den Linksversatz dynamisch ermitteln. Scheinbar zählt er aber die Pixel nicht korrekt:

Code Auswählen Erweitern


             OLED_FillArea_160128RGB(0, 160, 100, 128, BLACK);
             OLED_StringSmallFont_160128RGB(80 - countPixel(topDisplay)/2, 127, topDisplay , ORANGE, BLACK);   // Toptitle             
             OLED_FillArea_160128RGB(0, 160, 43, 95, BLACK);
             OLED_StringBigFont_160128RGB(80 - countPixel(strcat(charDisplay, webUnit))/2, 90, charDisplay, GRAY, BLACK);   // Value
             OLED_FadeIn_160128RGB(fadeInTime);
             milli_delay(delayTime);                     
             OLED_FadeOut_160128RGB(fadeOutTime);

[wingfighter]

Hallo tomster

Die Idee die Messwerte mittig zu stellen hatte ich auch schon. Aber die Ausgaberoutine basiert auf anderen Parametern. Daher greift "countPixel" nicht. Da das Display für diese großen Zeichen ein paar Pixel zu schmal ist, werden der Punkt und das Gradzeichen individuell gesetzt. Das lässt sich vorher schwer per "countPixel" ermitteln. Aber das setze ich noch um. So fällt das immer ins Auge.
Aber: Wir haben ja nur ausgewählte Ziffern und Sonderzeichen codiert. Daher wird ein "n/a" nicht funktionieren. Es sei denn, die drei Zeichen werden noch codiert. Wobei Sie in der Ausgaberoutine eine Sonderbehandlung benötigen, da Sie im Array ja nicht an ihrer ASCII-Position stehen. Und alle Zeichen des BigFont zu codieren halte ich für keine gute Idee. Wir sind schon bei knapp 80% Variablenspeicherauslastung.

Die Sache mit dem fehlenden Space stimmt natürlich. Das benötigt bei dem jetzigen Verfahren auch eine Sonderbehandlung. Denn ein Space hat kein gesetztes Bit, bis zu dem die Ausgabe erfolgen könnte. Daher wäre eine Space immer 2 Pixel davor und 2 Pixel danach breit. Aber ich denke, das wäre lösbar.
Im Moment gibt es sicher auch Probleme bei zweistelligen Minusgraden. Auf Deinem Berg wird das sicher öfter vorkommen. Da muss ich wohl mal zum Testen das Tiefkühlfach bemühen.

Und nun zu Deiner MQTT-Frage:

Oder hab ich das System MQTT komplett  mißverstanden?

Nun ja. Wie soll ich sagen?

Grundsätzlich steht durch die Protokoll-Definition MQTT das Verfahren fest, wer wem was schickt und wer auf was reagiert.
Wenn Du z.B. alles mitlesen möchtest, was durch den Broker kommuniziert wird, kannst Du ja z.B. eine # oder /# als Subscribe-Filter einstellen. Dann bekommt das IoT-Device alle Nachrichten und Du brauchst Dir nur das rausfiltern, was Du verarbeiten möchtest. Also: Auf der Empfangsebene alles lesen und auf der Verarbeitungsebene die gewünschten Werte raus fischen.

Damit die Abfrage aber nicht so komplex wird, wird über die Subscribe-Definition schon in der Empfangsebene gefiltert, was die Verarbeitungseben bekommen soll.
Und diese Filter sind in der ESP8266_Basic_data.cpp definiert. Und der oberste Knoten entspricht immer dem Device-Namen des ESP-Moduls.

Nun lässt das MQTT-Protokoll aber wie oben schon geschrieben auch Platzhalter zu. Leider aber nur auf der Subscriber-Seite. Das heißt, der Publisher sendet an EIN definiertes Device. Und wenn mehrere denselben Wert bekommen sollen, muss das auf der Publisher-Seite individuell für jeden Subscriber eingestellt werden.

Wenn Du aus dem Sketch heraus keine Daten pubilshen möchtest, kannst Du ja mal testen, ob Deine Idee funktioniert, wenn Du in allen Displays über die WebGui dasselbe MQTT-Device einstellst. Dann sollten eigentlich alle Displays auf ein Publish reagieren, was mit diesem generischen Namen beginnt. Also statt ESP8266_12345678 ein ESP8266 in allen Displays.

Viele Grüße
wingfighter

[Pf@nne]

Wenn Du aus dem Sketch heraus keine Daten pubilshen möchtest, kannst Du ja mal testen, ob Deine Idee funktioniert, wenn Du in allen Displays über die WebGui dasselbe MQTT-Device einstellst. Dann sollten eigentlich alle Displays auf ein Publish reagieren, was mit diesem generischen Namen beginnt. Also statt ESP8266_12345678 ein ESP8266 in allen Displays.

Das gibt murx, der MQTT-Client-Identifier muss einzigartig sein, sonst läßt dich der Broker nicht rein!

The MQTT client identifier
The client identifier is a 23 byte string that identifies an MQ Telemetry Transport client. Each identifier must be unique to only one connected client at a time. The identifier must contain only characters valid in a queue manager name. Within these constraints, you are able to use any identification string. It is important to have a procedure for allocating client identifiers, and a means of configuring a client with its chosen identifier.

Sinvoller Weise regelt man das über ein eigenes Topic z.B.:

Code Auswählen Erweitern

anAlle/Wetter/Montag
Dieses Topic wird dann in jedem Client abboniert.

Weiterhin viel Spaß!

Gruß
Pf@nne

[wingfighter]

Ja, den Gedanken, in jedem Client denselben Topic zu definieren, hatte ich mit meiner Idee auch. Aber da der mqttDeviceName auch zum Anmelden am Broker verwendet wird, fällt mein Vorschlag erstmal aus.
Deine Idee würde aber so nicht in das Template-Konzept passen. Oder habe ich da die Möglichkeit der freien Subscribe-Topic-Definition übersehen?

[Pf@nne]

Deine Idee würde aber so nicht in das Template-Konzept passen.

Die subscribe´s können generell frei definiert werden.

Code Auswählen Erweitern

bool ESP8266_Basic::start_MQTT(){

    //broker_subcribe();
String sub = cfg.mqttDeviceName;
sub += "/#";
mqtt_client.subscribe(sub.c_str());
    mqtt_client.loop();
mqtt_client.subscribe("anAlle/Wetter/Montag");
    mqtt_client.loop();


Richtig ist natürlich, dass der bisherige TopicTree im root den Devicenamen hat.
Womit man den dissector natürlich aushebelt.
Entweder müsste der Dissector angepasst werden oder man filter Manuell.
Wenn ich wieder in das Template einsteige werde ich das mal im Hinterkopf behalten.

Es ist in jedem Fall Sinnvoller von FEHM aus nur ein Publish zu senden, wer es haben möchte nimmt es sich.
Die Clients müsten sowohl gebundene (DeviceName) als auch ungebundene allgemeine Topics beherschen können.
Dazu könnte man vielleicht  einen separaten TopicTree nutzen....

Gruß
Pf@nne

[wingfighter]

Danke Pf@nne für den Tipp.
Das gestaltet sich gar nicht so kompliziert, wie im ersten Moment gedacht.
Ich habe mal eine Konfiguration für einen zweiten TopicTree-Root eingebaut. Er kann im WebGui auf der Seite 1  mit eingetragen werden und wird dann beim Broker als Subscribe mit registriert.
Somit kann der subTopicTree auch für Subscribes für "Alle" verwendet werden.
Da im Moment "nur" vier Ebenen abgefragt werden - also Root + drei weitere in die Tiefe, sollte der Second Subscribe  nur aus z.B. "Alle" oder "Jeder" o.ä. - also nur eine Ebene bestehen. Der Vorschlag aus dem letzten Post "anAlle/Wetter/Montag" würde ohne größere Umbauten im Moment nicht funktionieren.
Aber ich denke, das ist auch so eine gangbare Lösung.

Was ich in V0.35 angepasst habe:

• Die Spaces werden bei der Anzeige der smallFonts und BigFonts berücksichtigt
• Auch die Anzeige mit BigFonts wird jetzt zentriert.
• "Second Subscribe" zur Anzeige von "Broadcast-Wetterdaten"
• Anzeige der Wettericons für Tag 2-5 (zurzeit auskommentiert)
• Die config.json wird jetzt automatisch gelöscht, wenn sich die Struktur geändert hat. Bitte VOR dem flaschen noch einmal manuell löschen (geht ganz gut über http://<ip-ESP>/edit -> rechte Maustaste auf config.json -> delete

ToDo:

• Nach dem Eintragen des Second Subscribe muss das Sketch einmal neu gestartet werden, damit  die Registrierung am MQTT-Broker stattfinden kann.
• Für die Beschreibung der Wetter-Icons sollen die Daten direkt aus dem FHEM-Wetter-Modul übernommen werden. Dazu ist die Schrift (small Font) zu groß. Font.h wird um einen weiteren, kleinen Font erweitert, in das Filesystem verlegt und die Zeichen direkt von dort gelesen. Ein weiteres Font-Array dürfte den Variablen-Speicher des ESP sprengen
• Das "Copyright" in den beiden WebGui-Seiten wird nicht sauber geschrieben

@tomster
Ich bin Dir noch eine Antwort wegen der RGB-Werte schuldig.
Die gegenüber dem normalen Sprachgebrauch verdrehte Definition liegt am Display-Speicher. Man kann wohl auch RGB vorgeben. Aber BGR ist der Standard. Zuständig ist das Register 13h des SEPS525.

Die aktuelle Testversion hängt in gewohnter Form an diesem Post und steht auch bei GitHub online.
Bitte unbedingt die config.json löschen, sonst crasht das Sketch beim Versuch, nach dem Lesen der config.json die Variablen zu füllen.

Bei einer zukünftigen Anpassung wird die config gelöscht und mit Stanardwerten gefüllt. Das ganze wird im seriellen Monitor ausgeschrieben.

Viel Spaß und Erfolg beim Testen.
wingfighter

[tomster]

Nun ja. Wie soll ich sagen?

Hahaha, Danke, damit hast Du es mir freundlich beigebracht...
Damit lande ich aber schon bei der nächsten Frage. Wie muss ich denn die Definitionen in den MQTT-Devices auf FHEM anlegen, dass der Second Subscribe auch greift?
Derzeit sind ja z.B. die Temp-/ Humiditywerte nach folgender Ebendefinition angelegt:

Code Auswählen Erweitern


attr Aussen_TH.mqtt publishReading_humidity ESP8266_1234567/Display/NHD_1.69/Screen_1
attr Aussen_TH.mqtt publishReading_temperature ESP8266_1234567/Display/NHD_1.69/Screen_0

Der Sketch muss ja irgendwie wissen in welchem Screen er welchen Wert anzeigen soll. Wenn der Second Subscribe "nur" aus

alle/wetter besteht, dann fehlt ja genau diese Information, oder? Könntest Du mir vielleicht kurz erklären, wie die Definition in FHEM und im WebGUI aussehen müsste?

• Die config.json wird jetzt automatisch gelöscht, wenn sich die Struktur geändert hat. Bitte VOR dem flaschen noch einmal manuell löschen (geht ganz gut über http://<ip-ESP>/edit -> rechte Maustaste auf config.json -> delete

Leider konnte ich auf die /edit-Seite nicht zugreifen. Alternativ hilft aber nach dem Flashen des Sketches auch die /data-Partition neu zu Flashen.

@tomster
Ich bin Dir noch eine Antwort wegen der RGB-Werte schuldig.
Die gegenüber dem normalen Sprachgebrauch verdrehte Definition liegt am Display-Speicher. Man kann wohl auch RGB vorgeben. Aber BGR ist der Standard. Zuständig ist das Register 13h des SEPS525.

Danke für die Aufklärung. Ich kann mit BGR auch Leben. Jetzt weiß ich's ja

[wingfighter]

Hallo tomster

Wenn Du im "Second subscribe" z.B. "Alle" einstellst, hört der ESP auf "/Alle/#" und "Alle/#".
Der TopicTree im Sketch ist derselbe, wie bei "/ESP_1234567/#" bzw. "ESP_1234567/#".

Daher kannst Du in FHEM folgendes schreiben:

Code Auswählen Erweitern


attr Aussen_TH.mqtt publishReading_humidity Alle/Display/NHD_1.69/Screen_0
attr Aussen_TH.mqtt publishReading_temperature Alle/Display/NHD_1.69/Screen_1


oder eben einen anderen freien  Screen_n.

Gruß wingfighter

[tomster]

"Läääuuuft!"
Und wie! */me ist restlos begeistert, beeindruckt, dankbar und schlichtweg geplättet*
Die näxten Biers gehen auf mich!

[wingfighter]

Das freut mich!
Dann kann ich die oben beschriebenen ToDo's noch umsetzen und dann sollte das Display erst einmal eine Weile im Dauertest laufen. Oder gibt es noch Umsetzungsideen?