--edit--
Damit man den aktuellen Stand des Projekts leichter findet, darf ich hier gleich am Anfang das GIT Repository vom Hauptentwickler wingfighter verlinken:
https://github.com/wingfighter/ESP8266_OLED_NHD-1.69-160128UGC3
Dennoch kommt man derzeit noch nicht umhin diesen Thread zumindest querzulesen, damit man versteht warum, wann, welche Änderungen erfolgt sind.
Ich habe unten stehend ein kurzes HowTo eingefügt.
--/edit--
Servus zusammen,
duch einige Denkanstösse in diversen Threads bin ich auf den Trichter gekommen ein Status-Display in mein Schalterprogramm (GIRA 55'er) zu integrieren.
Als Basis soll dabei ein ESP8266 dienen an den ein OLED-Display angeschlossen ist. FHEM soll dann Daten per WiFi an das Display schicken.
Vorweg gleich Eins: Ich bin elektronisch ein verhältnismäßig unbeleckter Laie, von daher mag sich auf dem Weg zum Ziel durchaus noch etwas ergeben, was man heutzutage neudeutsch als "Showstopper" bezeichnet. Hab auch zuvor noch nie etwas mit Arduino oder ESP gemacht. Andererseits: wenn ich etwas will, dann will ich ;-)
Zunächst habe ich mich auf die Suche nach einem Display gemacht, welches möglichst goß ist, aber trotzdem noch (mit PCB) in den Blindeckel passt. Das größte Display, das ich finden konnte hat eine Diagonale von 1.69" bei 160x128 Pixeln und ist zudem noch Full-Color:
http://www.newhavendisplay.com/nhd169160128ugc3-p-5603.html
Das Display hat einen SEPS525-Displaytreiber. Ich hab zwar noch keinen dezidierten Treiber-Sketch für den ESP gefunden, aber ich vertraue in meiner schier unendlichen Blauäugigkeit an eine irgendwie geartete Kompatibilität mit Arduino und/oder jemanden von Euch, der sowas schon gemacht hat, ohne es an die Große (Internet-)Glocke gehängt zu haben...
Auch wenn es noch himmelweit von einem funktionierenden Prototypen entfernt ist, hab ich mich schon Mal an die Arbeiten gemacht, die meinen Fähigkeiten am ehesten entsprechen für die ich jemanden kenne, der jemanden kennt, der...
Also hab ich kurzer Hand einen Spezl aufgetan der eine wunderbare Fräsbank hat und schon Mal in einen Blinddeckel einen Ausschnitt für das Dispay gefräst. Dummerweise passte aber die Platine des Displays um ein Büschel Laushaare nicht in den Deckel. Also haben wir zudem die Platine rundherum um ~1mm abgefräst. Nun passt sie.
Das Display baut ~2mm über die Platine auf. Das ist auch ungefähr die Materialdicke des Blinddeckels. Wenn dass zum Schluß sauber eingeklebt ist, wirkt es fast bündig. *freu*
Gedanklich versuche den Aufbau so niedrig zu halten, dass man den Blinddeckel mit den Platinchen ggfls. auch ohne vorhandene Dose direkt auf die Wand montieren kann. Als Stromversorgung soll ein Trafo in eine der darüberliegenden Steckdosen-/Schalterdosen hinter die entsprechenden Einsätze. Das wird zwar alles sauknapp und der Blinddeckel wird wohl auf das Rahmenblech geklebt werden müssen, aber vielleicht geht es.
Und wenn nicht? Dann fliegt eben eine Steckdose raus.
Einer der nächsten Schritte wird wohl sein, die Anbindung des ESP, wohl ein ESP8266-07 wegen einer möglichen externen Antenne, zu bewerkstelligen. Wenn hierzu jemand einen Ansatz hat, sowohl softwareseitig als auch eine hardwareseitig (vielleicht eine Trägerplatine gleich mit Temp-/ Feuchtesensor verbaut), nur her damit!
Natürlich auch mit allem Anderen, wie Ratschlägen, Kritik, etc.
Dies alles nur als kurze Vorabinformation. Und: mir eilt es überhaupt nicht. Lieber 5 Mal länger mit Überlegen verbracht, als sich die Arbeit 2 Mal gemacht.
Zudem ich in den nächsten Wochen leider viel im Ausland bin.
Für das tatsächliche Weiterbetreiben des Projekts wird natürlich keine Gewähr übernommen und der Rechtsweg ist wie immer ausgeschlossen. ;-)
Schönes Wochenende schon Mal,
Tom
-- Ein kleines HowTo: --
Wie die Verkablungen vorzunehmen ist, entnehmt ich bitte diesem Thread auf den Seiten 2ff.
Um die Firm-/ Software von wingfighter auf einen ESP8266, nodeMCU, Wemos D1 mini, etc. zu bekommen, verwende ich das Arduino IDE. Hier nun kurz die benötigten Schritte:
1. Arduino IDE runterladen:
Das Arduino IDE bekommt ihr hier: https://www.arduino.cc/en/Main/Software
2. Libraries nachinstallieren:
Arduino lagert einige Funktionen in sogenannte Libraries aus. Um den ESP8266 "nativ" aus dem IDE verwenden zu können, nutzt man einfach die Boardverwaltung. Dazu klickt ihr Datei -> Voreinstellungen und tragt unter "Zusätzliche Boardverwalter-URLs" den Link http://arduino.esp8266.com/package_esp8266com_index.json ein und bestätigt mit "OK". Nun einfach über Werkzeuge -> Board -> Boardverwalter die ESP8266-Library auswählen (vermutlich ganz unten) und installieren (das dauert ein bisschen). Ich habe V 2.1.0 installiert.
Nun könnt ihr unter Werkzeuge -> Board den von Euch verwendeten ESP auswählen.
Zusätzlich werden noch ein paar Libraries benötigt, die wir manuell nachladen und die jeweiligen Ordner in das libraries-Verzeichnis (z.B. C:\Programme\Arduino\libraries) von Arduino kopieren.
Benötigt werden:
1. Die Library für den von wingfighter verwendeten DHT-Sensor: https://github.com/adafruit/DHT-sensor-library
2. Die Time-Library: https://github.com/PaulStoffregen/Time
3. Die JSON-Library: https://github.com/bblanchon/ArduinoJson
4. Die MQTT-Library: https://github.com/knolleary/pubsubclient
5. Die OneWire-Library: https://github.com/PaulStoffregen/OneWire
6. Die "Dallas"-Linrary: https://github.com/milesburton/Arduino-Temperature-Control-Library
Diese Dateien einfach herunterladen, entpacken und in das library-Verzeichnis von Arduino kopieren.
3. Aktuelle Version aus dem GitHub Repository von wingfighter herunterladen:
In der ZIP-Datei ist ein Ordner ESP8266_Basic, den wir auch manuell in das library-Verzeichnis kopieren.
In den letzten Versionen der Firmware sind einige Dateien auf dem ESP in einen /data-Ordner ausgelagert. Man kann den Inhalt dieses Ordners über das Webinterface des ESPs aufspielen, oder aber ein nützliches Tool in das Arduino IDE integrieren. Dazu einfach das hier (https://github.com/esp8266/arduino-esp8266fs-plugin) herunterladen und nach Anleitung in den tools-Ordner kopieren.
Zur Sicherheit noch ein kurzer Neustart des Arduino IDEs und wir können eigentlich loslegen.
Sketch öffnen, Kompilieren und hoffentlich keine Fehlermeldungen bekommen. Wenn alles fehlerfrei durchläuft, könnt ihr den Sketch auf den ESP hochladen. Danach ein über Werkzeuge -> ESP8266 Sketch Data Upload den data-Ordner kopieren. Das dauert wiederum ein bisschen.
Nach einem Neustart solltet ihr nun auf dem Display einige wechselnde "Screens" angezeigt bekommen. Damit ist der Großteil geschafft. Alles weitere dann im Thread oder später hier an dieser Stelle.
Hallo Tomster,
ich hatte eine ähnliche Idee mit diesem ePaper Display:
http://www.reichelt.de/EA-EPA20-A/3/index.html?&ACTION=3&LA=446&ARTICLE=156564&artnr=EA+EPA20-A&SEARCH=epaper
Bauteile liegen zuhause ...
Gruß PeMue
Nach einem eInk-Display hab ich mich auch umgeschaut, aber leider keines gefunden welches mit "vernünftiger" Auflösung in einem quadratischen oder 4:3-Format daherkommt.
Zudem brauch ich eines mit Backlight.
Hilft dir nicht direkt, aber schau mal vorbei:
https://forum.fhem.de/index.php/topic,50637.0.html
Ich hab da andere günstige Displays, die am ESP8266 gehen könnten.
Hab mir welche bestellt, die können wir ausprobieren, wenn du mit dem OLED nicht weiter kommst.
Servus Rince,
Deinen Thread hab ich schon gelesen. Verfolge ich gespannt; wenn auch zugegebener Maßen rein aus technischem Interesse.
Die Adafruit-Displays sind nur leider recht teuer im Vergleich zu Ware vom Chinesen, wenn man eine Diagonale >= 1.5" möchte.
Aber Danke für Dein Angebot. Komme im OLED-Mißerfolgsfall auf Dich zurück!
Oh, in dem 3ten Post mit den vielen Links sind 2 für China Displays. 1 kostet <5€
Leider weicht der letzte Buchstabe hinter der Typenbezeichnung von dem (nicht lieferbarem) Adafruit Display ab. Von da her hoffe ich, dass es dennoch geht ohne es aber bis jetzt zu wissen ;)
Suche gerade eine Möglichkeit, ein Bild zu übertragen ohne dass es auf der SD Karte sein muss.
Hallo Tomster
Das sieht mechanisch schon mal gut aus. Die Idee finde ich super.
Ich habe mal ein bisschen gegoogled.
Hier findest Du ein fertiges Test-Sketch für einen Arduino. http://www.newhavendisplay.com/app_notes/Arduino_OLED_160128.txt (http://www.newhavendisplay.com/app_notes/Arduino_OLED_160128.txt)
Das wäre ja schon mal ein Anfang.
Und wenn das läuft, kann man das sicher recht unkompliziert auf einen ESP8266 mit ein paar externen Beinchen portieren.
Viele Grüße
wingfighter
Servus Wingfighter,
Danke für den Link. Wie bereits erwähnt, hab ich bislang noch keinerlei Arduinoerfahrung - geschweige mit dem ESP.
In wie weit ein Arduino-Sketch mit dem ESP, respektive dem dann von mir gewählten "Unterbau" kompatibel ist, kann ich noch nicht abschätzen.
Der Wunsch wäre natürlich eine möglichst "zusammenklickbare" (= höchst-user DAU-freundliche) Firmware, OTA-updatefähig, mit Web-UI, etc.
Welche da am Besten geeignet ist, muss ich wohl erst selber probieren. Selbiges gilt für die Verdrahtung.
Bislang war für mich ein "Breadboard" begriffsseitig eher ein Brotzeitbrettl als etwas Technisches ;-)
Zum ESP:
Da habe ich ja auch grade eine Baustelle, bzw. 2.
Zum einen kannst du ESPeasy nehmen. Das ist sehr userfreundlich. Hat aber so gut wie keine Displayunterstützung bis jetzt. Nur Text.
Dann gäbe es die Arduino IDE
Und zu guter Letzt noch Sming.
Letzteres scheint ein aussichtsreicher Kandidat sein.
Angeblich kompatibel zu den Arduino Bibliotheken (jedenfalls wenn diese mit dem ESP kompatibel sind!), Webserver, FTP Server, Dateisystem
Für Sming gibt es übrigens ein Chocolatey Repository (choco install Sming -y)
Vergessen zu erwähnen:
Da wir ja nicht jeweils am Ende der Welt wohnen:
Meine Displays und die Stromversorgung sollte nach Ostern eintreffen.
Da können wir uns auch mal nen Samstag zusamnen setzen und gemeinsam basteln/programmieren.
Nach Ostern klingt super! Meine Teile sind auch noch nicht alle da. Aber ich vermute der USB TTL kommt diese Woche.
Sming ist bislang auch mein theoretischer Favorit - hab ja "in Echt" noch nicht testen können.
Zudem bastel ich gerade noch an einer Platine, die man auf das Display aufstecken kann. Wenn sich das platzmäßig noch ausgeht, dann würde ich die zusammen mit einem anderen Platinenlayout an dem ich grad arbeite (ESP<->RS485) beim Chinesen machen lassen. Die brauchen dann eh ein paar Wochen.
:)
https://github.com/SmingHub/Sming/wiki/Windows-Quickstart
(Anleitung zur Installation von Sming)
Hallo tomster
Kurze Zwischen-Info:
Ich habe mir das Display mal bestellt. Ist heute gerade angekommen. Ich habe den verlinkten Test-Sketch auf einen Arduino-UNO geladen. Und nach ein bisschen Testen mit der Verdrahtung kommt jetzt das Testbild "Hallo World" mit einem schonen Regenbogenstreifen darunter. ;-)
Der nächste Schritt ist jetzt, das Sketch mal auf einem ESP8266-12E zu testen. Ich denke aber das wir ohne weiteres laufen, weil keine Bibliotheken eingebunden werden. Die Kommunikation über den I2C-Bus wird "von Hand" realisiert.
Ich werde berichten....
Gruß wingfighter
Uii, das klingt doch schon Mal sehr vielversprechend!
Ich bin noch zu nix weiter gekommen. Hab die letzten beiden Tage vergeblich versucht mit chocolatey das Sming-Paket auf meinem Win XP Rechner zu installieren. Muss mir wohl langsam doch Mal was Neueres zulegen...
Wie hast Du denn genau verdrahtet? Dann könnt ich wenigstens das schon Erledigen.
Oh, ich hab noch nix verdrahtet, mangels Displaylieferung bis jetzt :)
Die Verdrahtung ist in diesem Dokument http://www.phys.hawaii.edu/~idlab/taskAndSchedule/HVprojPage/NIM-HV-PSU-Presentation.pdf (http://www.phys.hawaii.edu/~idlab/taskAndSchedule/HVprojPage/NIM-HV-PSU-Presentation.pdf) Seite 9 ganz gut beschrieben.
Sie steht so auch in ähnlicher Form im Originaldokument. Ist hier aber in Details besser dargestellt.
Die PIN's auf Arduino-Seite sind in dem Test-Sketch vereinbart (hier nur die, die für die serielle Datenübertragung notwendig sind):
#define SDI_PIN 6 // SDI (serial mode) signal connected to pin 6 (DISPLAY-SDI)
#define SCL_PIN 7 // SCL (serial mdoe) signal connected to pin 7 (DISPLAY-SCL)
#define RS_PIN 8 // RS signal connected to pin 8 (DISPLAY-D/C)
#define RES_PIN 11 // /RES signal connected to pin 11 (DISPLAY-/RES)
#define CS_PIN 12 // /CS signal connected to pin 12 (DISPLAY-/CS)
Wichtig, sind auch alle Verbindungen mit GND. Mit PS an GND legt man z.B. fest, dass die serielle Datenübertragung genutzt werden soll.
Damit auch das Sketch das weiß, musst Du dort den Übertragungsmodus bzw. das Interface ebenfalls festlegen.
/*********************************/
/****** INTERFACE SELECTION ******/
/*********************************/
const unsigned char interface = 1; // 0 = 8-bit parallel (6800 mode) interface; 1 = 8-bit parallel (8080 mode) interface; 2 = 4-wire SPI interface
/*===============================*/
/*===============================*/
/*===============================*/
Hier steht als Interface original die 1. Dort muss eine 2 eingetragen werden, damit im Sketch die Routinen für die serielle Übertragung genutzt werden.
Die Anpassung des Sketches an den ESP8266 ist wahrscheinlich etwas aufwändiger, da dort einige GPIO's Low-aktiv sind. Das könnte Auswirkungen auf die Ansteuerlogik für die /RES und /CS Eingänge haben. Das gucke ich mir dann mal genauer an.
Nun aber erstmal viel Erfolg beim Testen.
So, das Demo-Sketch läuft jetzt auch auf einem ESP8266-12E NodeMCU.
Das Sketch stell ich hier https://github.com/wingfighter/ESP8266_OLED_NHD-1.69-160128UGC3.git (https://github.com/wingfighter/ESP8266_OLED_NHD-1.69-160128UGC3.git) bereit.
Die Pinbelegung ist natürlich etwas anders als beim Arduino UNO.
#define SDI_PIN 2 // SDI (serial mode) signal connected to D4
#define SCL_PIN 0 // SCL (serial mdoe) signal connected to D3
#define RS_PIN 4 // RS (D/C) signal connected D2
#define RES_PIN 5 // /RES signal connected to D1
#define CS_PIN 14 // /CS signal connected to D5
Der nächste Schritt wird sein, mal einen DHT22 anzuschließen und die beiden Messwerte auf dem Display auszugeben.
Gruß wingfighter
Huii, das geht ja zackig bei Dir. Zum Glück hab ich gestern meine nodeMCUs bekommen.
Ich werde morgen Mal versuchen die Löterei hinzubekommen und den Sketch zu flashen.
Super! Dein Test-Sketch läuft schon Mal! Ich bin schweeer begeistert!
Vielen Dank!
Cool :)
Nur mal als Idee, wenn man einen Doppelrahmen nimmt, könnte man unten drunter einen zweiten Blinddeckel setzen. Auf diesem 2. Blinddeckel könnte man mehrere kapazitive Taster realisieren, dazu gibt es im Netz viele Anleitungen z.B. http://playground.arduino.cc/Main/CapacitiveSensor?from=Main.CapSense
Dann hättet Ihr zusätzlich eine schöne Bedienmöglichkeit für das Display. Zusätzlich könnte man sicherlich einige nette Dinge damit realisieren, wie einen Raumcontroller
Wie hattet Ihr Euch eigentlich die Stromversorgung vorgestellt ?
Die Idee mit den kapazitiven Schaltern hatte ich am Freitag auch. Allerdings wollte ich die noch im gleichen Deckel mit unterbringen. Wird aber verdammt eng, wegen der Platine des Displays. Ich hab mit dem Display eh schon einen 4'er Rahmen; noch einer und der WAF ist perdu...
Zudem wollte ich die Sensoren von www.edisen.de verbauen, weil ich die schlichtweg mag ;-)
Der Kleinste liegt aber immer noch bei 15mm x15mm. Im eigenen Deckel ginge das sicher leichter. Um's Ausprobieren wird man aber auch dabei nicht herumkommen.
Stromversorgung hab ich mir mit Netzteil gedacht. Ist nicht günstig, und eigentlich abgekündigt, aber hat einen schönen Formfaktor und passt ggfls auch hinter einen Schalter/ Steckdose:
http://eu.mouser.com/ProductDetail/RECOM-Power/RAC03-33SCR-277/?qs=LQwAcjY4KXhSVRQNSKxrSA%3d%3d
Alternativ als 5V-Variante mit nachfolgendem Spannungsregler.
Für den Endeinbau möchte ich eh auf einen "reinen" ESP zurückgreifen. Der kommt dann auf ein Breadboard, so wie dieses:
http://www.ebay.de/itm/ESP8266-ESP-12E-Serial-Port-Wireless-WIFI-Module-IO-Adapter-Plate-Expansion/252240079584?_trksid=p2047675.c100011.m1850&_trkparms=aid%3D222007%26algo%3DSIC.MBE%26ao%3D1%26asc%3D20140107083420%26meid%3D9439acda22b244caa3b5cfaac84db848%26pid%3D100011%26rk%3D4%26rkt%3D10%26mehot%3Dag%26sd%3D141649607329
Das Board hätte zwar schon Pads vorgesehen für einen Spannungsregler, aber ich hab noch keinen gefunden, der SOT-89-3 ist und genügend mA für ESP und Display zur Verfügung stellt...
Zitat von: tomster am 20 März 2016, 10:57:01
Stromversorgung hab ich mir mit Netzteil gedacht. Ist nicht günstig, und eigentlich abgekündigt, aber hat einen schönen Formfaktor und passt ggfls auch hinter einen Schalter/ Steckdose:
http://eu.mouser.com/ProductDetail/RECOM-Power/RAC03-33SCR-277/?qs=LQwAcjY4KXhSVRQNSKxrSA%3d%3d
Die RECOM Alternativen im Standartgehäuse sind leider ein wenig groß.
Was eventuell geeignet ist, Udo hat in seinem YPORT (volkszaehler.org) dieses Modul PPM2.5SIP-05ELF eingesetzt.
http://www.peak-electronics.de/wp-content/uploads/2015/09/PPMxx-SIP_E_09_13.pdf (http://www.peak-electronics.de/wp-content/uploads/2015/09/PPMxx-SIP_E_09_13.pdf)
Gruß Friedrich
So, ich war mal wieder etwas aktiv und habe eine neue Version des Sketches hochgeladen: https://github.com/wingfighter/ESP8266_OLED_NHD-1.69-160128UGC3/blob/master/NHD-1.69-160128UGC3_ESP8266_Temp_Hum.ino (https://github.com/wingfighter/ESP8266_OLED_NHD-1.69-160128UGC3/blob/master/NHD-1.69-160128UGC3_ESP8266_Temp_Hum.ino)
Es ist jetzt folgendes realisiert:
- Es wird ein DHT22 abgefragt und die Messergebnisse im 2sek-Rhythmus als zentrale Information auf dem Display angezeigt.
- Das Modul meldet sich per WiFi am W-Lan-Router an (SSID und Password im Sketch eintragen).
- Wenn eine Internetverbindung besteht, holt sich das Modul per NTP die Zeit aus dem Internet und zeigt Uhrzeit und Datum im unteren Bereich des Displays an
- Die aus dem DHT22 kommenden Messwerte werden per mqtt an einen Broker (IP in Sketch eintragen) übertragen. Bei mir holt sich der fhem-Server diese Werte per mqtt ab und zeigt sie als Readings an
- Man kann per mqtt auch einen Ausgang setzen. Ist momentan aber nicht aktiviert.
ToDo:
- Der Font, der für die Anzeige der Messwerte verwendet wird, ist im Moment Verdana, Bold, 48pt. Das ist ein Mü zu groß.
- Der Font enthält nur die nötigsten Zeichen (0,1,2,3,4,5,6,7,8,9, °,C,.,%). Der Punkt ist programmtechnisch extra behandelt, damit der Platz reicht. Ist keine schöne Lösung . ;-(
- Wenn keine NTP-Erfolg, muss die Anzeige ausgeblendet werden. Eventuell kann auch ein lokaler Router als NTP-Server dienen. (Noch nicht getestet)
- Die OLED-Funktionen müssen in eine Bibliothek ausgelagert werden. Es fehlen Zeichenfunktionen (Linien, Kreise, Rechtecke, Füllen etc.)
- Wenn man - wie von T.ihmann vorgeschlagen - Taster einbaut, kann man auch für eine Anwendung des Displays im Küchenbereich eine prima Eieruhr mit Startknopf und evtl. Zeitwahltasten (4:45, 5:00, 5:30 min etc) realisieren ;-)
- Je nachdem, was Eure Test so ergeben ;-)
Die Sache mit dem Näherungssensor hatte ich auch schon überlegt. Wenn das Display mit der Helligkeit und der ständig wechselnden Anzeige im TV-Sichtfeld ist, dürfte es auf Dauer stören. (WAF!!!)
Eventuell lässt es sich dimmen und bei Annäherung auf volle Helligkeit schalten. Das sah beim ersten Lesen der Doku allerdings nicht so aus, als ob es diese Funktion gäbe. Also ginge noch - Display löschen und dann neu zeichnen.
Viele Spaß jetzt erst mal beim Testen
Gruß
wingfighter
Coool! Bin leider die näxten 10 Tage auf der (fast) anderen Seite der Welt. Testen geht leider nicht von hier.
Aber Anfang April hol ich alles nach. Ich möchte den Sketch vorallem auf dem ESP8266-07 an's Laufen bekommen, aus Platzgründen.
Wie man das Display dimmt muss ich suchen. Ich hatte da auf einer der 1000 Seiten, die ich durchgrschaut habe, was gelesen. Das war aber glaub ich gar nicht so leicht, wenn ich mich recht erinnere. Die wollten das aber auch mit einem Photowiderstand lösen. Ich schsu, ob ich die Seite wiederfinde.
Ist in meinem Fall (Schlafzimmer) sonst der WAF-Killer Nr. 1
Wegen der Schriftart:
Wenn man alle Zeichen hardcodet, wird's wohl schnell Essig mit dem Speicher. Sollte man nicht überlegen einen SD-Reader anzubinden und dort Graphiken und evtl. auch Zeichensätze unterzubringen?
Ansonsten, natürlich vielen Dank Wingfighter an Dich. Du hängst dich da ziemlich rein. Bin Dir was schuldig...
LG,
Tom
Ich habe ja auch ein Display am ESP im Hinterkopf.
Sming hätte:
Ein Dateisystem
Einen FTP Server (http auch)
Prinzipiell kann MQTT Bilder als Payload verschicken, wobei ich das nicht verstehe. Link im Link-Post der Uhr.
So oder so:
Bilder auf Server generieren, per HTTP/FTP/MQTT auf den ESP übertragen, dann anzeigen lassen.
Bei 160x120 Pixel auch mit 24Bit Farbtiefe sollte die Bildübertragung recht schnell gehen. Und so ein Messwert muss jetzt nicht sekündlich aktualisiert werden.
Ein Auswahlmenü würde ich permanent vorgerendert auf dem ESP lagern, das was sich verändert (Temperaturverläufe) remote Rendern lassen bei Bedarf.
Je nachdem wieviel EEprom ihr auf euren ESP Platinen habt, lohnt es sich auch das Dateisystem zu nutzen.
Das Dateisystem beim ESP hat jedoch eine Limitierung - es können maximal 1MB Blöcke gleichzeitig "geöffnet" sein - sprich das Dateisystem ist auf 1 MB limitiert
Wobei ich finde in 1MB kann man seeeeehr viel reinpacken - wenn man dann noch kompression verwendet (es gibt auch libs für arduino) lässt sich da noch mehr machen
Ich erinnere mich irgendwo gelesen zu haben, dass das EEprom nicht das hochwertigste ist. Wäre ja schade, wenn nach ein paar Monaten der Speicher hinüber wäre. Da sollte man evtl auf einen externen zurück greifen?!
@oli82
Gelesen habe ich das auch. Allein, mir fehlt der Glaube:
Ich denke diese Vermutung stammt noch aus der Anfangszeit der ESP-Programmierversuche, wo noch nicht klar war wie man den Flash-Speicher des ESPs komplett löschen kann.
Ergänzend:
http://www.esp8266.com/viewtopic.php?f=32&t=6109
ich werf mal folgendes mysensors Projekt in den thread:
https://www.openhardware.io/view/23/In-wall-LCD-SwitchScene-controller-for-MySensors
Da wäre auch ein Board beschreiben mit 220V Spannungsversorgung, Arduino Pro Mini und NRF24L01+ - eventuell lässt sich das Board als Vorlage für nen ESP nehmen
Hallo
Ich habe mir das Projekt aus Softwaresicht mal angeguckt. Die eine oder andere Idee kann man sicher noch adaptieren.
Bei den Displays ist aber die sehr unterschiedliche Programmierung die Herausforderung.
Ich habe mir das Datasheet in den letzten Tagen aber mal genauer angeguckt und auch die Register gefunden, über die die Helligkeit des Display gesteuert wird. Außerdem gibt es auch ein Bit um es ganz dunkel zu schalten.
Ich habe im Moment am A0 also ADC des ESP8266 einen Photowiderstand hängen und lasse so die Helligkeit regeln. Da muss man sicher eine individuelle Feinjustage für die Steilheit der Kurve vorsehen. Aber grundsätzlich funktioniert das Verfahren.
Ich hatte noch eine Idee, die aber zz an meinen fehlenden FHEM-Künsten scheitert.
Wie schon geschrieben, habe ich das MQTT-Protokoll implementiert. Die beiden Messwerte werden auch regelmäßig an FHEM übertragen.
Nun ist die Idee, dass man per publischSet_<Display_n> Messwerte (z.B. andere Raumtemperaturen oder die Außentemperatur etc.) an das Display übertragen kann.
Mann könnte z.B. 9 zusätzliche Displays im Sketch vorhalten und wenn sie per mqtt mit Zahlen gefüllt werden, rolliert die Anzeige über 2 + n Messwerte. Und wenn per mqtt eine "clear Display n" geschickt wird, wird der Inhalt gelöscht und die Anzeige aus dem Rollieren raus genommen.
Dazu wäre es aber sinvoll, dass die anzuzeigenden Werte automatisch an den Sketch gesendet werden.
Hier mal ein Ausschnitt aus dem Post in dem das MQTT-Modul vorgestellt wurde:
define heizung_kinderzimmer MQTT_DEVICE
attr heizung_kinderzimmer publishSet_desired-temp fhem/kinderzimmer/temperatur
Man kann auf diese Weise interaktiv einen Wert per MQTT an das Device senden und dort weiter verarbeiten. Das funktioniert auch grundsätzlich.
Nun würde ich aber eine FHEM-Variable - also z.B. die Raumtemperatur des Bades - immer wenn sie sich ändert automatisch senden wollen. Sicher kann man so etwas in der 99_myUtils.pm einbauen. Aber ich frage mich, ob es dafür nicht eine Lösung auf attr-Ebene gibt.
Ich stelle mir das in etwa so vor:
define heizung_kinderzimmer MQTT_DEVICE
attr heizung_kinderzimmer publishSet_desired-temp ReadingsVal(<TempDevice>, "temerature", "") fhem/kinderzimmer/temperatur
Nur gelingt es mir auf diese Weise nicht. Im ESP-Sketch kommt dann das "ReadingsVal(<TempDevice>" an. ;-(
Hat jemand eine Lösung für mich?
Gruß
wingfighter
Hallo,
verfolge diesen Thread ja gespannt!
Parallel bin ich über das hier gestolpert:
https://forum.fhem.de/index.php/topic,51267.0/topicseen.html
(https://forum.fhem.de/index.php/topic,51267.0/topicseen.html)
Weiter so!
Jetzt muss ich nur noch einen Platz finden wo ich das Display haben will und auch Strom da ist... ;-)
Gruß, Joachim
Hallo,
Super Projekt, ich versuche selber Software aufzustellen, aber mit einem Mono-oled und bin noch ziemlich am Anfang.
Bezüglich deines MQTT/Readingsproblem, schau mal hier :
https://forum.fhem.de/index.php?topic=27532.0 (https://forum.fhem.de/index.php?topic=27532.0)
Das Stichwort heißt MQTT_Bridge.
Habe es bei mir so in etwa am werkeln.
define mqtt_Temp_Aussen MQTT_BRIDGE Temp_Aussen
attr mqtt_Temp_Aussen IODev Mosquitto
attr mqtt_Temp_Aussen publishReading_humidity fhem/aussen/wetter/relFeuchte
attr mqtt_Temp_Aussen publishReading_temperature fhem/aussen/wetter/Temperatur
Temp_Aussen ist ein LaCrosse Sensor, welcher die Readings temperature und humidity hat.
Gesendet von meinem D5803 mit Tapatalk
Hallo Tiwo85
Die Richtung ESP8266->FHEM funktioniert auch sauber. Und auch das manuelle Senden von Werten von FHEM zum ESP8266 geht grundsätzlich.
Mir will es nur nicht gelingen, z.B. eine Außentemperatur, die von einem Sensor gemessen wird, der in FHEM eingebunden ist, automatisch per publishSet_<AußenTemperatur> an den ESP zu senden.
Gruß wingfighter
Ich verstehe glaube ich, was du meinst. Ich versuche es mal zu erklären.
Ich glaube das Problem liegt daran, daß du ein MQTT_DEVICE erstellt hast. Der Sensor ist ja als device in Fhem schon vorhanden also muss dazu eine Brücke / bridge zwischen fhem und mqtt geschaffen werden.
Define <BridgeName> MQTT_Bridge <SensorName>
Und da du ein einen gemessenen Wert, also ein reading publishen möchtest, musst du PublishReading_<Reading> <topic>
nehmen.
Gesendet von meinem D5803 mit Tapatalk
Danke für den Tipp.
Das war's.
Jetzt kann ich mich mal mit den n dynamischen Displays in der OLED-Anzeige widmen. ;-)
Hier https://forum.fhem.de/index.php/topic,50238.0.html (https://forum.fhem.de/index.php/topic,50238.0.html) ist übrigens noch ein guter Ansatz für eine Basis-Konfiguration, ohne bei jedem Modul eine individuell im Sketch "verdrahtete" Konfiguration zu implementieren.
Muss man auf jeden Fall weiter verfolgen.
So, ich habe noch ein bisschen am Programm erweitert.
Die aktuelle Version liegt wieder unter https://github.com/wingfighter/ESP8266_OLED_NHD-1.69-160128UGC3/blob/master/NHD-1.69-160128UGC3_ESP8266_Temp_Hum.ino (https://github.com/wingfighter/ESP8266_OLED_NHD-1.69-160128UGC3/blob/master/NHD-1.69-160128UGC3_ESP8266_Temp_Hum.ino).
Ich habe jetzt 10 zusätzliche Displays eingefügt, auf die im aktuellen Stand Werte in der Form xx.x geschrieben werden können.
Die Werte können an das Display per MQTT gesendet werden.
Im Sktech wird in Zeile 103 der Subcribe_Topic vereinbart auf den das Display lauschen soll:
#define display_topic "fhem/Display"
Möchte man z.B. eine Temperatur an Display 1 senden, sieht das auf der Mosquitto-Console so aus:
mosquitto_pub -t 'fhem/Display/1' -m '20.0'
Nun soll das ja möglichst automatisch ablaufen. Und wie schon in der vorigen Anfrage beantwortet, möchte ich aus FHEM heraus beispielhaft diverse Temperaturen und/oder Luftfeuchtigkeiten etc. übertragen.
In FHEM sieht das bei mir dann so aus:
Hier zunächst die Definition für die Werte des Sensors, der am ESP8266 hängt und seine Werte per MQTT an FHEM sendet:
define SB.TempHum MQTT_DEVICE
attr SB.TempHum IODev mqtt
attr SB.TempHum stateFormat state
attr SB.TempHum subscribeReading_Luftfeuchte fhem/Sensor/DHT22/Luftfeuchte
attr SB.TempHum subscribeReading_Temperatur fhem/Sensor/DHT22/Temperatur
Und hier die Definition für die zu übertragenden Werte an das Display. In diesem Fall ist es ein kombinierter Außenfühler für Temperatur und Luftfeuchte, der auf der Terrasse angebracht ist. Daher das TR im Namen.
define TR.Temperatur.mqtt MQTT_BRIDGE TR.Temperatur.Luftfeuchte
attr TR.Temperatur.mqtt IODev mqtt
attr TR.Temperatur.mqtt publishReading_temperature fhem/Display/1
attr TR.Temperatur.mqtt publishReading_humidity fhem/Display/2
So wie die Attribute definiert sind, werden allerdings weder genaue Messwertbezeichnungen noch Einheiten übertragen. So dass auf dem OLED-Display in der obersten Zeile "Display n" angezeigt wird. Als Einheit steht momentan °C fest in der Anzeige.
Hier sind wieder die FHEM-Profis gefragt, die mir bestimmt einen Tipp geben können, wie man einen String in der Art '<Wert>,<Einheit>,<DisplayName>' per MQTT senden kann.
Es bleibt noch offen, dass im Moment nur die benötigten Zeichen in Arrays hinterlegt sind. Diese im internen Speicher abzulegen und dann auch für alle ASCII 0-127, ist noch ein ToDo.
Und dann hätte ich da noch die Idee mit der Eieruhr, die per Taste, oder MQTT vom Handy aus gestartet werden kann. ;-)
Gruß wingfighter
PS: Habe mal die Verdrahtung des Testaufbaus angehängt.
Hallo
Ich habe den Font jetzt etwas verkleinert - Verdana Bolt 44pt.
Version V 0.11 im Anhang bzw. auf GitHub.
Übrigens:
Wenn man in ein Display einen Wert schreibt, so wie oben erläutert,
mosquitto_pub -t 'fhem/Display/1' -m '20.0'
kann man den auch wieder löschen, d.h. das Display aus der Anzeige-Rotation entfernen:
mosquitto_pub -t 'fhem/Display/1' -m 'clear'
Gruß
wingfighter
So bin wieder da, wenn auch maximal gejetlaggt...
Primaarbeit wingfighter! Werd ich morgen gleich Mal flashen und testen.
Und Mal schauen, wie man den Photowiderstand so hinbekommt, dass man ihn in meinem Deckel nicht sieht. Vielleicht reicht es ja aus, den Widerstand von hinten auf die Blende zu kleben...
Wegen der Schriftart:
Wie detailtreu (=fein aufgelöst) wirkt denn die Verdana Font? Ich bin ja prinzipiell eher ein Freund von diesen Thin-Fonts wie z.B. Roboto, die auch bei der Google-Skin verwendet wird. Meinst Du das bekommt das Display hin, so dass es auch nach etwas aussieht?
Das käme sicher auf einen Versuch an.
Aber bei solchen feinen Strukturen wie einem Thin-Font vermute ich, dass der Treppenstufen-Effekt sehr störend wirkt. Selbst bei dem Verdana Bolt sind Stufen zu erkennen.
Im Moment wird ja keine Kantenglättung der Schrift vorgenommen. Es wird nur das jeweilige Pixel in Vordergrund- bzw. Hintergrundfarbe gezeichnet.
Um eine Kantenglättung zu erreichen, musste man die Randpixel auf Pixelebene entweder dimmen können, oder - was evtl. geht - die Farben abdunkeln. Aber das ist natürlich reichlich aufwändig. Da wird man dann wahrscheinlich mit JPG's oder PNG'S je Digit arbeiten müssen.
Die Sache mit dem Fotowiderstand gefällt mir auch noch nicht so richtig. Ich vermute, dass hinter dem Rahmen die Lichtverhältnisse nicht ausreichend sind, damit man einen Effekt sieht.
Eventuell kann man ja einen beliebigen anderen Helligkeit abhängigen Parameter aus FHEM nehmen und ihn per MQTT zum Display senden. Den kann man dann auch nachts und in sonstigen Sondersituationen "manuell" einstellen, egal, wie die Lichtverhältnisse gerade sind.
Naja, schau's Dir erst mal an. Da gibt's sicher noch Einiges zu optimieren.
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?
Gruß
Pf@nne
@Pf@nne
Günstiger sind Displays mit ST7735 Chip. Unter 5€ / Stück mit Versand.
Läuft mit ESP8266. (Verdrahtung und Bezugsquelle im Magische-Uhr Thread)
Hintergrundbeleuchtung ist als extra Eingang ausgeführt, der PWM fähig ist.
Wobei 1,8" grenzwertig groß ist.
Grafikausgabe habe ich noch nicht am laufen, nur Textausgabe.
Ich bin mir aber sicher, dass die OLEDs um die es in diesem Thread geht ein schöneres Bild machen (vor allem blickwinkelstabiler)
Auch ein sehr interessantes Display. Allerdings wird es nicht ganz in einen GIRA-Rahmen passen. ;-) Von daher "müssen" wir hier erst einmal bei dem NHD-1.69-160128 bleiben, wenn's Farbe und klein sein soll.
Aber für 5€ wird es sicher das nächste Testobjekt.
@Pf@nne
Ich würde gern Teile Deiner Konfigurations-Library einbauen. Das ist ein sehr guter Ansatz, um nicht immer alle Parameter im Sketch vereinbaren zu müssen.
Allerdings müssen wir dann aufpassen, dass der Speicherplatz nicht ausgereizt wird. Dein Sketch hat 54.436 Bytes (66%). Meiner bis jetzt 36.184 Bytes (44%). Dass sind schon 110% ;-) Sicher sind eine Menge Komponenten doppelt. Aber da gäbe es sicher etwas zu optimieren.
Gruß
wingfighter
Welchen ESP nutz du denn?
Bei meinem 12e (4M) sind es mal gerade 32% und davon sind 26% ESPCore....... ich glaube nicht, das wie das Ding so schnell vollbekommen.... :-)
Mit der Library (Template) tu dir keinen Zwang an, dafür ist es ja gedacht.
Ist aber noch alpha, von daher mit Vorsicht zu genießen.....
;D
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.
ZitatAber 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.
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 (https://www.youtube.com/watch?v=xyc1gCjguRU)
Ist etwas frickelig aber machbar.
Wenns unbedingt die Größe macht ;D
Zitat von: wingfighter am 03 April 2016, 22:44:50
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.
Zitat
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...
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:
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?
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:
PubSubClient mqttClient(mqtt_server, 1883, mqttCallback, MQTTClient);
Also noch vor der ersten Funktion.
// 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
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
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...
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:
// 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.
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...
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?
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.
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...
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
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?
OK. Das ist ja schon mal gut.
Ja, die while(1)-Schleife lässt es endlos cyclen.
Was macht das Sketch denn, wenn das Display schwarz ist?
Überprüfe bitte auch mal, ob alle Anschlüsse, die in der unten stehenden Zeichnung mit GND verbunden sind, auch auf GND liegen.
Ohh, Mann. Das hab ich total übersehen, dass E, R/W und D10-D15 und CPU auf Low gezogen werden müssen...
Peinlich, peinlich :-[
Zitat von: wingfighter am 05 April 2016, 15:47:39
Überprüfe bitte auch mal, ob alle Anschlüsse, die in der unten stehenden Zeichnung mit GND verbunden sind, auch auf GND liegen.
Ändert leider am Verhalten auch nix. Das Display wird zwischendrin immer noch schwarz...
Eine Idee hätte ich noch.
Ich habe den VCC-Anschluss des DHT auf einem GPIO-Pin (D7) liegen, weil ich testen wollte, ob seine eventuelle Eigenwärme das Messergebnis verfälscht.
Diesen Pin schalte ich nur zum Messen kurz auf HIGH. Wenn Du da zufällig vom Display eine Leitung dran hast, kann das auch zu Deinem beschriebenen Effekt kommen.
Der Schalten passiert in Zeile 1597 und wird alle 10s aufgerufen. Kannst diese und die Zeile zum Ausschalten ja mal auskommentieren.
Hab bei mir nix an D7 hängen, aber ich probiere das morgen trotzdem Mal aus. Hab testweise ein 2. Set aufgebaut. Gleicher Effekt. Zudem scheint das Display einen Fehler zu haben, weil auf der rechten Seite viele Pixelstörungen angezeigt werden.
Bringt leider, fast wie erwartet, keine Besserung. Keine Ahnung was da nicht stimmen kann.
Hast Du eine andere CPU-Freq? Ich hab die standardmäßigen 80MHz im Arduino IDE eingestellt.
Ich habe bei mir an den Stadardeinstellungen nichts geändert. CPU läuft mit 80 MHz.
Kannst Du mir bitte nochmal sagen, was in der Zeit passiert, wenn das Display dunkel ist? Also was wird dann in auf der seriellen Konsole ausgegeben?
Gibt es jemanden der anderen Thread-Leser, der das Sketch schon mal erfolgreich oder -los testen konnte?
Passieren tut in der Zeit nicht viel, zumindest ausgabeseitig. Ein paar Messages der MQTT-Devices kommen rein:
Connecting to pillepalle
.........
WiFi connected
192.168.0.52
Starting UDP
Local port: 2390
sending NTP packet...
packet received, length=48
Seconds since Jan 1 1900 = 3668930471
Unix time = 1459941671
The MEZ time is 11:21:11
06.04.2016
Sommerzeit
!new Time set
Attempting MQTT connection...Connecting to MQTT server
Connected to MQTT server
Set Subscribe to : fhem/Display/#
Message arrived: topic: fhem/Display/2
Length: 2
Payload: 77
Payload message_buff[]: 77
Message arrived: topic: fhem/Display/1
Length: 3
Payload: 8.0
Payload message_buff[]: 8.0
Das sieht aber normal aus.
Da würde ich in der Tat auf das Display tippen.
Auf GitHUB habe ich ja unter Example auch ein Testscript liegen. Das basiert auf der Empfehlung aus der Display-Doku bzw. ist von der Herstellerseite.
Vielleicht solltest Du das mal testen, um die Ansteuerung des Display und das Display selber als Fehlerursache ausschließen zu können.
https://github.com/wingfighter/ESP8266_OLED_NHD-1.69-160128UGC3/tree/master/Example/NHD-1.69-160128UGC3_Test_ESP8266.ino (https://github.com/wingfighter/ESP8266_OLED_NHD-1.69-160128UGC3/tree/master/Example/NHD-1.69-160128UGC3_Test_ESP8266.ino)
Den Example-Sketch habe ich schon auf beiden Systemen ausprobiert.
Bei dem mit den Pixelfehlern schaut es so aus als hätte der Treiberchip auf dem Flachbandkabel einen Wackelkontakt-> Streifen über Streifen. Durch Rumdrücken auf dem Chip wird es deutlich besser. Ich vermute also Garantiefall.
Das andere System (mein bisheriges Testsystem) zeigt einwandfrei das "Testbild". Dauerhaft ohne schwarzen Bildschirm in wunderbaren Farben.
Mit deinem DHT-Sketch:
Beim Booten wird erst kurz eine Displayseite sichtbar. Quasi wie als hätte das Display den letzten Status vor dem Ausschalten "gespeichert". Dieser wird aber sofort durch den Sketch "geblanked". Dann ist für 10-20 Sekunden alles schwarz und es erscheint (in 7 von 10 Fällen) das Temperaturdisplay, dann das Luftfeuchtedisplay des DHTs. Dann wird der Bildschirm wieder schwarz. Beim nächsten oder übernächsten Cycle kommen dann die Displays des definierten MQTT-Devices hinzu. Erst meist mit 0.00, dann irgendwann auch mit Werten. Jeweils unterbrochen von unterschiedlich langen Schwarzzeiten (~10-120 Sekunden).
Ha!
Hab den Schuldigen ausgemacht. Der Sketch kommt nicht klar damit, wenn der Fotowiderstand nicht dranhängt.
Ich hab im Code die Zeilen 1617ff auskommentiert und nun geht's!
// Read analog port A0
// sensor_value = analogRead(SENSOR);
// int x = (sensor_value * 100 / 1023);
// Set Driving to OLED
// OLED_Driving_Current_160128RGB(223 * x / 100, 197 * x / 100, 179 * x / 100); //OLED initialization
Spiel mich grad parallel ein bisschen mit den Schriftarten. So ganz mag das aber noch nicht hinhauen. Ich hab bislang einfach die HEX-Angaben geändert, auf eine Robot Font. Da passen aber die Größen wohl noch nicht so richtig...
unsigned char Verdana[][148] = {
{
// @256 '0' (29 pixels wide)
0x00, 0x3F, 0x80, 0x00, // #######
0x00, 0xFF, 0xE0, 0x00, // ###########
0x01, 0xFF, 0xF0, 0x00, // #############
0x03, 0xF1, 0xF8, 0x00, // ###### ######
0x07, 0xC0, 0x7C, 0x00, // ##### #####
0x07, 0x80, 0x3E, 0x00, // #### #####
0x0F, 0x80, 0x1E, 0x00, // ##### ####
0x0F, 0x00, 0x1E, 0x00, // #### ####
0x0F, 0x00, 0x1F, 0x00, // #### #####
0x0F, 0x00, 0x1F, 0x00, // #### #####
0x0F, 0x00, 0x0F, 0x00, // #### ####
0x1F, 0x00, 0x0F, 0x00, // ##### ####
0x1F, 0x00, 0x0F, 0x00, // ##### ####
0x1F, 0x00, 0x0F, 0x00, // ##### ####
0x1F, 0x00, 0x0F, 0x00, // ##### ####
0x1F, 0x00, 0x0F, 0x00, // ##### ####
0x1F, 0x00, 0x0F, 0x00, // ##### ####
0x1F, 0x00, 0x0F, 0x00, // ##### ####
0x1F, 0x00, 0x0F, 0x00, // ##### ####
0x1F, 0x00, 0x0F, 0x00, // ##### ####
0x1F, 0x00, 0x0F, 0x00, // ##### ####
0x0F, 0x00, 0x0F, 0x00, // #### ####
0x0F, 0x00, 0x1F, 0x00, // #### #####
0x0F, 0x00, 0x1F, 0x00, // #### #####
0x0F, 0x00, 0x1E, 0x00, // #### ####
0x0F, 0x80, 0x1E, 0x00, // ##### ####
0x07, 0x80, 0x3E, 0x00, // #### #####
0x07, 0xC0, 0x7C, 0x00, // ##### #####
0x03, 0xF1, 0xF8, 0x00, // ###### ######
0x01, 0xFF, 0xF8, 0x00, // ##############
0x00, 0xFF, 0xE0, 0x00, // ###########
0x00, 0x3F, 0x80, 0x00, // #######
},
{
// @384 '1' (29 pixels wide)
0x00, 0x0F, 0x80, 0x00, // #####
0x07, 0xFF, 0x80, 0x00, // ############
0x07, 0xFF, 0x80, 0x00, // ############
0x07, 0xFF, 0x80, 0x00, // ############
0x07, 0xFF, 0x80, 0x00, // ############
0x00, 0x0F, 0x80, 0x00, // #####
0x00, 0x0F, 0x80, 0x00, // #####
0x00, 0x0F, 0x80, 0x00, // #####
0x00, 0x0F, 0x80, 0x00, // #####
0x00, 0x0F, 0x80, 0x00, // #####
0x00, 0x0F, 0x80, 0x00, // #####
0x00, 0x0F, 0x80, 0x00, // #####
0x00, 0x0F, 0x80, 0x00, // #####
0x00, 0x0F, 0x80, 0x00, // #####
0x00, 0x0F, 0x80, 0x00, // #####
0x00, 0x0F, 0x80, 0x00, // #####
0x00, 0x0F, 0x80, 0x00, // #####
0x00, 0x0F, 0x80, 0x00, // #####
0x00, 0x0F, 0x80, 0x00, // #####
0x00, 0x0F, 0x80, 0x00, // #####
0x00, 0x0F, 0x80, 0x00, // #####
0x00, 0x0F, 0x80, 0x00, // #####
0x00, 0x0F, 0x80, 0x00, // #####
0x00, 0x0F, 0x80, 0x00, // #####
0x00, 0x0F, 0x80, 0x00, // #####
0x00, 0x0F, 0x80, 0x00, // #####
0x00, 0x0F, 0x80, 0x00, // #####
0x00, 0x0F, 0x80, 0x00, // #####
0x00, 0x0F, 0x80, 0x00, // #####
0x00, 0x0F, 0x80, 0x00, // #####
0x00, 0x0F, 0x80, 0x00, // #####
0x00, 0x0F, 0x80, 0x00, // #####
},
{
// @512 '2' (29 pixels wide)
0x00, 0x3F, 0xC0, 0x00, // ########
0x00, 0xFF, 0xF0, 0x00, // ############
0x01, 0xFF, 0xF8, 0x00, // ##############
0x03, 0xF9, 0xFC, 0x00, // ####### #######
0x07, 0xC0, 0x7C, 0x00, // ##### #####
0x07, 0x80, 0x3E, 0x00, // #### #####
0x0F, 0x80, 0x1E, 0x00, // ##### ####
0x0F, 0x00, 0x1E, 0x00, // #### ####
0x0F, 0x00, 0x1E, 0x00, // #### ####
0x00, 0x00, 0x1E, 0x00, // ####
0x00, 0x00, 0x1E, 0x00, // ####
0x00, 0x00, 0x3E, 0x00, // #####
0x00, 0x00, 0x3C, 0x00, // ####
0x00, 0x00, 0x7C, 0x00, // #####
0x00, 0x00, 0x78, 0x00, // ####
0x00, 0x00, 0xF0, 0x00, // ####
0x00, 0x01, 0xF0, 0x00, // #####
0x00, 0x03, 0xE0, 0x00, // #####
0x00, 0x07, 0xC0, 0x00, // #####
0x00, 0x0F, 0x80, 0x00, // #####
0x00, 0x0F, 0x80, 0x00, // #####
0x00, 0x1F, 0x00, 0x00, // #####
0x00, 0x3E, 0x00, 0x00, // #####
0x00, 0x7C, 0x00, 0x00, // #####
0x00, 0xF8, 0x00, 0x00, // #####
0x01, 0xF0, 0x00, 0x00, // #####
0x03, 0xE0, 0x00, 0x00, // #####
0x03, 0xC0, 0x00, 0x00, // ####
0x07, 0xC0, 0x00, 0x00, // #####
0x0F, 0xFF, 0xFF, 0x00, // ####################
0x0F, 0xFF, 0xFF, 0x00, // ####################
0x0F, 0xFF, 0xFF, 0x00, // ####################
},
{
// @640 '3' (29 pixels wide)
0x00, 0x3F, 0xC0, 0x00, // ########
0x00, 0xFF, 0xF0, 0x00, // ############
0x01, 0xFF, 0xF8, 0x00, // ##############
0x03, 0xF1, 0xFC, 0x00, // ###### #######
0x07, 0xC0, 0x7E, 0x00, // ##### ######
0x0F, 0x80, 0x3E, 0x00, // ##### #####
0x0F, 0x80, 0x1E, 0x00, // ##### ####
0x0F, 0x00, 0x1E, 0x00, // #### ####
0x0F, 0x00, 0x1E, 0x00, // #### ####
0x00, 0x00, 0x1E, 0x00, // ####
0x00, 0x00, 0x1E, 0x00, // ####
0x00, 0x00, 0x3E, 0x00, // #####
0x00, 0x00, 0x3C, 0x00, // ####
0x00, 0x00, 0xF8, 0x00, // #####
0x00, 0x3F, 0xF0, 0x00, // ##########
0x00, 0x3F, 0xE0, 0x00, // #########
0x00, 0x3F, 0xF8, 0x00, // ###########
0x00, 0x00, 0xFC, 0x00, // ######
0x00, 0x00, 0x3E, 0x00, // #####
0x00, 0x00, 0x1E, 0x00, // ####
0x00, 0x00, 0x1F, 0x00, // #####
0x00, 0x00, 0x1F, 0x00, // #####
0x00, 0x00, 0x1F, 0x00, // #####
0x0F, 0x00, 0x1F, 0x00, // #### #####
0x0F, 0x00, 0x1F, 0x00, // #### #####
0x0F, 0x00, 0x1F, 0x00, // #### #####
0x0F, 0x80, 0x3E, 0x00, // ##### #####
0x07, 0xC0, 0x7E, 0x00, // ##### ######
0x07, 0xF1, 0xFC, 0x00, // ####### #######
0x01, 0xFF, 0xF8, 0x00, // ##############
0x00, 0xFF, 0xF0, 0x00, // ############
0x00, 0x3F, 0xC0, 0x00, // ########
},
{
// @768 '4' (29 pixels wide)
0x00, 0x00, 0xF8, 0x00, // #####
0x00, 0x01, 0xF8, 0x00, // ######
0x00, 0x01, 0xF8, 0x00, // ######
0x00, 0x03, 0xF8, 0x00, // #######
0x00, 0x07, 0xF8, 0x00, // ########
0x00, 0x07, 0xF8, 0x00, // ########
0x00, 0x0F, 0xF8, 0x00, // #########
0x00, 0x1F, 0xF8, 0x00, // ##########
0x00, 0x1E, 0xF8, 0x00, // #### #####
0x00, 0x3C, 0xF8, 0x00, // #### #####
0x00, 0x3C, 0xF8, 0x00, // #### #####
0x00, 0x78, 0xF8, 0x00, // #### #####
0x00, 0xF8, 0xF8, 0x00, // ##### #####
0x00, 0xF0, 0xF8, 0x00, // #### #####
0x01, 0xE0, 0xF8, 0x00, // #### #####
0x01, 0xE0, 0xF8, 0x00, // #### #####
0x03, 0xC0, 0xF8, 0x00, // #### #####
0x07, 0xC0, 0xF8, 0x00, // ##### #####
0x07, 0x80, 0xF8, 0x00, // #### #####
0x0F, 0x00, 0xF8, 0x00, // #### #####
0x0F, 0x00, 0xF8, 0x00, // #### #####
0x1F, 0xFF, 0xFF, 0x80, // ######################
0x1F, 0xFF, 0xFF, 0x80, // ######################
0x1F, 0xFF, 0xFF, 0x80, // ######################
0x1F, 0xFF, 0xFF, 0x80, // ######################
0x00, 0x00, 0xF8, 0x00, // #####
0x00, 0x00, 0xF8, 0x00, // #####
0x00, 0x00, 0xF8, 0x00, // #####
0x00, 0x00, 0xF8, 0x00, // #####
0x00, 0x00, 0xF8, 0x00, // #####
0x00, 0x00, 0xF8, 0x00, // #####
0x00, 0x00, 0xF8, 0x00, // #####
},
{
// @896 '5' (29 pixels wide)
0x01, 0xFF, 0xFE, 0x00, // ################
0x01, 0xFF, 0xFE, 0x00, // ################
0x03, 0xFF, 0xFE, 0x00, // #################
0x03, 0xC0, 0x00, 0x00, // ####
0x03, 0xC0, 0x00, 0x00, // ####
0x03, 0xC0, 0x00, 0x00, // ####
0x03, 0xC0, 0x00, 0x00, // ####
0x03, 0xC0, 0x00, 0x00, // ####
0x03, 0xC0, 0x00, 0x00, // ####
0x03, 0xC0, 0x00, 0x00, // ####
0x03, 0xC0, 0x00, 0x00, // ####
0x07, 0x9F, 0xC0, 0x00, // #### #######
0x07, 0xFF, 0xF0, 0x00, // ###############
0x07, 0xFF, 0xF8, 0x00, // ################
0x07, 0xFF, 0xFC, 0x00, // #################
0x07, 0xC0, 0x7E, 0x00, // ##### ######
0x07, 0x80, 0x3E, 0x00, // #### #####
0x07, 0x80, 0x1E, 0x00, // #### ####
0x00, 0x00, 0x1F, 0x00, // #####
0x00, 0x00, 0x1F, 0x00, // #####
0x00, 0x00, 0x0F, 0x00, // ####
0x00, 0x00, 0x0F, 0x00, // ####
0x00, 0x00, 0x0F, 0x00, // ####
0x0F, 0x00, 0x1F, 0x00, // #### #####
0x0F, 0x80, 0x1F, 0x00, // ##### #####
0x07, 0x80, 0x1E, 0x00, // #### ####
0x07, 0x80, 0x3E, 0x00, // #### #####
0x07, 0xC0, 0x7C, 0x00, // ##### #####
0x03, 0xF1, 0xFC, 0x00, // ###### #######
0x01, 0xFF, 0xF8, 0x00, // ##############
0x00, 0xFF, 0xF0, 0x00, // ############
0x00, 0x3F, 0x80, 0x00, // #######
},
{
// @1024 '6' (29 pixels wide)
0x00, 0x0F, 0xE0, 0x00, // #######
0x00, 0x3F, 0xFC, 0x00, // ############
0x00, 0xFF, 0xFC, 0x00, // ##############
0x01, 0xFC, 0x78, 0x00, // ####### ####
0x03, 0xF0, 0x00, 0x00, // ######
0x03, 0xC0, 0x00, 0x00, // ####
0x07, 0xC0, 0x00, 0x00, // #####
0x07, 0x80, 0x00, 0x00, // ####
0x07, 0x80, 0x00, 0x00, // ####
0x0F, 0x80, 0x00, 0x00, // #####
0x0F, 0x00, 0x00, 0x00, // ####
0x0F, 0x00, 0x00, 0x00, // ####
0x0F, 0x0F, 0xE0, 0x00, // #### #######
0x0F, 0x3F, 0xF8, 0x00, // #### ###########
0x0F, 0xF9, 0xFC, 0x00, // ######### #######
0x0F, 0xC0, 0x3E, 0x00, // ###### #####
0x0F, 0x80, 0x1E, 0x00, // ##### ####
0x0F, 0x00, 0x1F, 0x00, // #### #####
0x0F, 0x00, 0x0F, 0x00, // #### ####
0x0F, 0x00, 0x0F, 0x00, // #### ####
0x0F, 0x00, 0x0F, 0x00, // #### ####
0x0F, 0x00, 0x0F, 0x00, // #### ####
0x0F, 0x80, 0x0F, 0x00, // ##### ####
0x0F, 0x80, 0x0F, 0x00, // ##### ####
0x07, 0x80, 0x0F, 0x00, // #### ####
0x07, 0xC0, 0x1F, 0x00, // ##### #####
0x07, 0xC0, 0x1E, 0x00, // ##### ####
0x03, 0xE0, 0x3E, 0x00, // ##### #####
0x01, 0xF8, 0xFC, 0x00, // ###### ######
0x00, 0xFF, 0xF8, 0x00, // #############
0x00, 0x7F, 0xF0, 0x00, // ###########
0x00, 0x1F, 0xC0, 0x00, // #######
},
{
// @1152 '7' (29 pixels wide)
0x1F, 0xFF, 0xFF, 0x00, // #####################
0x1F, 0xFF, 0xFF, 0x00, // #####################
0x1F, 0xFF, 0xFF, 0x00, // #####################
0x00, 0x00, 0x0F, 0x00, // ####
0x00, 0x00, 0x1E, 0x00, // ####
0x00, 0x00, 0x3E, 0x00, // #####
0x00, 0x00, 0x3C, 0x00, // ####
0x00, 0x00, 0x78, 0x00, // ####
0x00, 0x00, 0xF0, 0x00, // ####
0x00, 0x00, 0xF0, 0x00, // ####
0x00, 0x01, 0xE0, 0x00, // ####
0x00, 0x03, 0xC0, 0x00, // ####
0x00, 0x03, 0xC0, 0x00, // ####
0x00, 0x07, 0x80, 0x00, // ####
0x00, 0x07, 0x80, 0x00, // ####
0x00, 0x0F, 0x00, 0x00, // ####
0x00, 0x0F, 0x00, 0x00, // ####
0x00, 0x0F, 0x00, 0x00, // ####
0x00, 0x1E, 0x00, 0x00, // ####
0x00, 0x1E, 0x00, 0x00, // ####
0x00, 0x1E, 0x00, 0x00, // ####
0x00, 0x3E, 0x00, 0x00, // #####
0x00, 0x3C, 0x00, 0x00, // ####
0x00, 0x3C, 0x00, 0x00, // ####
0x00, 0x3C, 0x00, 0x00, // ####
0x00, 0x3C, 0x00, 0x00, // ####
0x00, 0x3C, 0x00, 0x00, // ####
0x00, 0x3C, 0x00, 0x00, // ####
0x00, 0x3C, 0x00, 0x00, // ####
0x00, 0x3C, 0x00, 0x00, // ####
0x00, 0x3C, 0x00, 0x00, // ####
0x00, 0x3C, 0x00, 0x00, // ####
},
{
// @1280 '8' (29 pixels wide)
0x00, 0x3F, 0x80, 0x00, // #######
0x00, 0xFF, 0xF0, 0x00, // ############
0x03, 0xFF, 0xF8, 0x00, // ###############
0x03, 0xF1, 0xFC, 0x00, // ###### #######
0x07, 0xC0, 0x7C, 0x00, // ##### #####
0x07, 0x80, 0x3E, 0x00, // #### #####
0x0F, 0x80, 0x3E, 0x00, // ##### #####
0x0F, 0x80, 0x1E, 0x00, // ##### ####
0x0F, 0x00, 0x1E, 0x00, // #### ####
0x0F, 0x80, 0x1E, 0x00, // ##### ####
0x0F, 0x80, 0x1E, 0x00, // ##### ####
0x07, 0x80, 0x3E, 0x00, // #### #####
0x07, 0xC0, 0x3C, 0x00, // ##### ####
0x03, 0xE0, 0xF8, 0x00, // ##### #####
0x00, 0xFF, 0xF0, 0x00, // ############
0x00, 0x7F, 0xC0, 0x00, // #########
0x01, 0xFF, 0xF0, 0x00, // #############
0x03, 0xE0, 0x7C, 0x00, // ##### #####
0x07, 0x80, 0x3E, 0x00, // #### #####
0x0F, 0x00, 0x1E, 0x00, // #### ####
0x0F, 0x00, 0x1F, 0x00, // #### #####
0x1F, 0x00, 0x0F, 0x00, // ##### ####
0x1F, 0x00, 0x0F, 0x00, // ##### ####
0x1F, 0x00, 0x0F, 0x00, // ##### ####
0x1F, 0x00, 0x0F, 0x00, // ##### ####
0x0F, 0x00, 0x1F, 0x00, // #### #####
0x0F, 0x80, 0x1E, 0x00, // ##### ####
0x0F, 0xC0, 0x3E, 0x00, // ###### #####
0x07, 0xF1, 0xFC, 0x00, // ####### #######
0x03, 0xFF, 0xF8, 0x00, // ###############
0x01, 0xFF, 0xF0, 0x00, // #############
0x00, 0x3F, 0xC0, 0x00, // ########
},
{
// @1408 '9' (29 pixels wide)
0x00, 0x3F, 0x00, 0x00, // ######
0x00, 0xFF, 0xE0, 0x00, // ###########
0x03, 0xFF, 0xF0, 0x00, // ##############
0x07, 0xF3, 0xF8, 0x00, // ####### #######
0x07, 0xC0, 0x7C, 0x00, // ##### #####
0x0F, 0x80, 0x3C, 0x00, // ##### ####
0x0F, 0x00, 0x3E, 0x00, // #### #####
0x1F, 0x00, 0x1E, 0x00, // ##### ####
0x1F, 0x00, 0x1E, 0x00, // ##### ####
0x1E, 0x00, 0x1E, 0x00, // #### ####
0x1E, 0x00, 0x1E, 0x00, // #### ####
0x1E, 0x00, 0x1E, 0x00, // #### ####
0x1E, 0x00, 0x1E, 0x00, // #### ####
0x1F, 0x00, 0x1E, 0x00, // ##### ####
0x0F, 0x00, 0x1E, 0x00, // #### ####
0x0F, 0x00, 0x3E, 0x00, // #### #####
0x0F, 0x80, 0x3E, 0x00, // ##### #####
0x07, 0xC0, 0xFE, 0x00, // ##### #######
0x03, 0xFF, 0xFE, 0x00, // #################
0x01, 0xFF, 0xDE, 0x00, // ########### ####
0x00, 0x7F, 0x1E, 0x00, // ####### ####
0x00, 0x00, 0x1E, 0x00, // ####
0x00, 0x00, 0x1E, 0x00, // ####
0x00, 0x00, 0x1E, 0x00, // ####
0x00, 0x00, 0x3E, 0x00, // #####
0x00, 0x00, 0x3E, 0x00, // #####
0x00, 0x00, 0x7C, 0x00, // #####
0x00, 0x00, 0xF8, 0x00, // #####
0x03, 0xC3, 0xF8, 0x00, // #### #######
0x07, 0xFF, 0xF0, 0x00, // ###############
0x07, 0xFF, 0xC0, 0x00, // #############
0x00, 0xFF, 0x00, 0x00, // ########
},
{
// @1536 'C' (29 pixels wide)
0x00, 0x1F, 0xE0, 0x00, // ########
0x00, 0x7F, 0xFC, 0x00, // #############
0x01, 0xFF, 0xFE, 0x00, // ################
0x03, 0xF8, 0x7F, 0x00, // ####### #######
0x07, 0xE0, 0x1F, 0x80, // ###### ######
0x07, 0xC0, 0x07, 0xC0, // ##### #####
0x0F, 0x80, 0x07, 0xC0, // ##### #####
0x0F, 0x00, 0x03, 0xC0, // #### ####
0x1F, 0x00, 0x03, 0xE0, // ##### #####
0x1E, 0x00, 0x03, 0xE0, // #### #####
0x1E, 0x00, 0x00, 0x00, // ####
0x1E, 0x00, 0x00, 0x00, // ####
0x1E, 0x00, 0x00, 0x00, // ####
0x1E, 0x00, 0x00, 0x00, // ####
0x1E, 0x00, 0x00, 0x00, // ####
0x1E, 0x00, 0x00, 0x00, // ####
0x1E, 0x00, 0x00, 0x00, // ####
0x1E, 0x00, 0x00, 0x00, // ####
0x1E, 0x00, 0x00, 0x00, // ####
0x1E, 0x00, 0x00, 0x00, // ####
0x1E, 0x00, 0x00, 0x00, // ####
0x1E, 0x00, 0x00, 0x00, // ####
0x1E, 0x00, 0x03, 0xE0, // #### #####
0x1F, 0x00, 0x03, 0xE0, // ##### #####
0x0F, 0x00, 0x03, 0xC0, // #### ####
0x0F, 0x80, 0x07, 0xC0, // ##### #####
0x07, 0xC0, 0x07, 0x80, // ##### ####
0x07, 0xE0, 0x1F, 0x80, // ###### ######
0x03, 0xF8, 0x7F, 0x00, // ####### #######
0x01, 0xFF, 0xFE, 0x00, // ################
0x00, 0x7F, 0xF8, 0x00, // ############
0x00, 0x1F, 0xE0, 0x00, // ########
},
{
// @1664 '°' (29 pixels wide)
0x00, 0x1F, 0x00, 0x00, // #####
0x00, 0x3F, 0x80, 0x00, // #######
0x00, 0x7F, 0xC0, 0x00, // #########
0x00, 0xF3, 0xE0, 0x00, // #### #####
0x00, 0xE0, 0xE0, 0x00, // ### ###
0x00, 0xE0, 0xE0, 0x00, // ### ###
0x00, 0xE0, 0xE0, 0x00, // ### ###
0x00, 0xF1, 0xE0, 0x00, // #### ####
0x00, 0x7F, 0xC0, 0x00, // #########
0x00, 0x7F, 0xC0, 0x00, // #########
0x00, 0x3F, 0x00, 0x00, // ######
0x00, 0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, 0x00, //
},
{
// @0 '%' (29 pixels wide)
0x0F, 0xC0, 0x00, 0x00, // ######
0x1F, 0xE0, 0x00, 0x00, // ########
0x3F, 0xF0, 0x00, 0x00, // ##########
0x78, 0x78, 0x04, 0x00, // #### #### #
0x70, 0x38, 0x0F, 0x00, // ### ### ####
0xF0, 0x38, 0x0E, 0x00, // #### ### ###
0xF0, 0x3C, 0x1C, 0x00, // #### #### ###
0xF0, 0x3C, 0x1C, 0x00, // #### #### ###
0xF0, 0x3C, 0x38, 0x00, // #### #### ###
0xF0, 0x38, 0x78, 0x00, // #### ### ####
0x70, 0x38, 0x70, 0x00, // ### ### ###
0x78, 0x78, 0xE0, 0x00, // #### #### ###
0x3F, 0xF1, 0xE0, 0x00, // ########## ####
0x1F, 0xE1, 0xC0, 0x00, // ######## ###
0x0F, 0x83, 0x80, 0x00, // ##### ###
0x00, 0x03, 0x80, 0x00, // ###
0x00, 0x07, 0x00, 0x00, // ###
0x00, 0x0F, 0x0F, 0x80, // #### #####
0x00, 0x0E, 0x3F, 0xE0, // ### #########
0x00, 0x1C, 0x7F, 0xF0, // ### ###########
0x00, 0x3C, 0x70, 0x70, // #### ### ###
0x00, 0x38, 0xE0, 0x78, // ### ### ####
0x00, 0x70, 0xE0, 0x38, // ### ### ###
0x00, 0x70, 0xE0, 0x38, // ### ### ###
0x00, 0xE0, 0xE0, 0x38, // ### ### ###
0x01, 0xE0, 0xE0, 0x38, // #### ### ###
0x01, 0xC0, 0xE0, 0x38, // ### ### ###
0x03, 0x80, 0xF0, 0x78, // ### #### ####
0x03, 0x80, 0xF0, 0xF0, // ### #### ####
0x00, 0x00, 0x7F, 0xF0, // ###########
0x00, 0x00, 0x3F, 0xE0, // #########
0x00, 0x00, 0x0F, 0x80, // #####
},
{
// @0 '%' (29 pixels wide)
0x0F, 0xC0, 0x00, 0x00, // ######
0x1F, 0xE0, 0x00, 0x00, // ########
0x3F, 0xF0, 0x00, 0x00, // ##########
0x78, 0x78, 0x04, 0x00, // #### #### #
0x70, 0x38, 0x0F, 0x00, // ### ### ####
0xF0, 0x38, 0x0E, 0x00, // #### ### ###
0xF0, 0x3C, 0x1C, 0x00, // #### #### ###
0xF0, 0x3C, 0x1C, 0x00, // #### #### ###
0xF0, 0x3C, 0x38, 0x00, // #### #### ###
0xF0, 0x38, 0x78, 0x00, // #### ### ####
0x70, 0x38, 0x70, 0x00, // ### ### ###
0x78, 0x78, 0xE0, 0x00, // #### #### ###
0x3F, 0xF1, 0xE0, 0x00, // ########## ####
0x1F, 0xE1, 0xC0, 0x00, // ######## ###
0x0F, 0x83, 0x80, 0x00, // ##### ###
0x00, 0x03, 0x80, 0x00, // ###
0x00, 0x07, 0x00, 0x00, // ###
0x00, 0x0F, 0x0F, 0x80, // #### #####
0x00, 0x0E, 0x3F, 0xE0, // ### #########
0x00, 0x1C, 0x7F, 0xF0, // ### ###########
0x00, 0x3C, 0x70, 0x70, // #### ### ###
0x00, 0x38, 0xE0, 0x78, // ### ### ####
0x00, 0x70, 0xE0, 0x38, // ### ### ###
0x00, 0x70, 0xE0, 0x38, // ### ### ###
0x00, 0xE0, 0xE0, 0x38, // ### ### ###
0x01, 0xE0, 0xE0, 0x38, // #### ### ###
0x01, 0xC0, 0xE0, 0x38, // ### ### ###
0x03, 0x80, 0xF0, 0x78, // ### #### ####
0x03, 0x80, 0xF0, 0xF0, // ### #### ####
0x00, 0x00, 0x7F, 0xF0, // ###########
0x00, 0x00, 0x3F, 0xE0, // #########
0x00, 0x00, 0x0F, 0x80, // #####
},
{
// @128 '.' (29 pixels wide)
0x00, 0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, 0x00, //
0x00, 0x0F, 0x00, 0x00, // ####
0x00, 0x0F, 0x00, 0x00, // ####
0x00, 0x0F, 0x00, 0x00, // ####
0x00, 0x0F, 0x00, 0x00, // ####
}
};
Hallo Tomster
OK. Das habe ich natürlich nicht abgeprüft. Und ein offener ADC-Eingang misst Mist. Daher die unterschiedlich langen Dunkelphasen.
Ich habe jetzt in Zeile 56 eine Compiler-Direktive eingebaut, die bewirkt, dass die Helligkeitssteuerung nicht mit in das Programm übernommen wird, wenn kein Fotowiderstand angeschlossen ist.
Du müsstest den Kommentarstatus der Zeile entfernen, dann würde die Helligkeit geregelt werden.
Zudem habe ich Deinen Font eingebaut und die Ausgaben so angepasst, dass die Ausgabe wieder einigermaßen harmonisch aussieht. Wenn es eine Alternative bleibt, würde ich ebenfalls über eine Compiler-Direktive #VERDANA oder #ROBOT dem Anwender die Entscheidung überlassen, welchen Font er bevorzugt.
Beide Änderungen sind im angehängten Sketch berücksichtigt.
Gruß wingfighter
Hab's gerade ausprobiert. Funktioniert technisch einwandfrei. Ich glaube aber, ich muss an der Schriftgröße der Robot Font und dem Gesamtdesign noch ein bissl arbeiten. Die Zahlenwerte müssen irgendwie größer werden, damit das vom Design her passt, finde ich. Vielleicht muss das doch Roboto Thin werden...
Auch muss ich noch versuchen die Einheiten (%,°C, etc.) kleiner zu bekommen. Die nehmen sonst nur unnötig Platz für die eigentliche Anzeige des Werts weg.
Zudem stellt sich die Frage, ob man auch Piktogramme für Wetter oder Sonstiges aufnehmen sollte. Das kommt zwar letztendlich auf den verfügbaren Speicher an, aber es ist wahrscheinlich sinnvoll sich jetzt im Vorfeld Gedanken zu machen, wie es hernach aussehen soll. Der Sketch muss ja irgendwie für den User leicht verständlich sein, damit er die einzelnen Displays nach seinen Wünschen gestalten kann.
In meinem Fall soll das Display ja in erster Linie morgens einen schnellen Überblick über die Uhrzeit geben, und ob das Wetter dazu auffordert sofort das Haus zu Verlassen und Skifahren zu gehen, oder ob man sich nicht noch Mal umdreht und noch eine Stunde mutzelt. Von daher die Wetter-Piktogramme. Ich weiß, schon seeehr speziell, aber ich bin halt trotz Skifahraffinität ein fauler Stefften und steh ungern früh auf nur um dann festzustellen, dass gar kein Lift fährt weil es zuviel Wind hat ;-)
Hier Mal so ein grober Vorschlag:
Nur kurz als Update zur Hardware:
Ich muss feststellen, dass nun auch das zweite Display die ersten Vertikalstreifen zeigt. Ich weiß nicht, ob ich eine schlechte Charge erwischt habe, oder ob es sich möglicherweise um einen Konstruktionsfehler handelt. Ich habe dabei die Flachbandfolie, bzw. den darauf befestigten Treiberchip im Verdacht...
Zitat von: tomster am 07 April 2016, 15:12:20
Ich habe dabei die Flachbandfolie, bzw. den darauf befestigten Treiberchip im Verdacht...
Diese Folien sind
sehr empfindlich. Das Problem gab es früher auch beim LEGO MINDSTORMS NXT. Besonders der Übergang Folie-Display ist nicht ohne.
Es gibt auch entsprechende Warnungen im erweiterten Datenblatt. http://www.newhavendisplay.com/specs/precautions.pdf (http://www.newhavendisplay.com/specs/precautions.pdf)
Gruß Friedrich
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...
Zitat von: tomster am 07 April 2016, 17:07:10
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
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
ZitatDann 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.
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 ;-)
ZitatFü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/
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?
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?
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 8)
Zitat von: Pf@nne am 08 April 2016, 16:39:17
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.
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...
Zitat von: Rince am 08 April 2016, 17:56:24
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.
Also das ST7735 werkelt angeblich mit bis zu 65 MHz am SPI Bus vom ESP8266. Aber um das ging es hier ja nicht.
Zitat von: sumotoySince 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)
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.
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
Danke für Deine Rückmeldung.
Ich habe auch meine Bedenken hinsichtlich der Qualität/ Lebensdauer der Displays. Wie bereits geschrieben, habe ich bei meinen beiden Displays vertikale "Leerstreifen = Blind spots", die eine vernünftige Anzeige der Werte verhindern. Ich hab bei meinem Lieferanten zwar schon einen Garantie-Case aufgemacht, aber noch keine Rückmeldung. Zudem habe ich bei einem anderen Hersteller nach der reinen Displayeinheit inkl. FPC als Ersatzteil angefragt. Dieses hat genau die gleichen Maße, wie das Display von NewHaven und käme evtl. als Austausch in Frage. Auch ich halte uns hier auf dem Laufenden.
Bringt ja Nichts, wenn man sich viel Arbeit macht und dann die Hardware nach kurzer Zeit ausfällt. Auch wenn ich noch keine wirklich Alternative zu unseren OLEDs im Bezug auf Displaygröße, Farbe, etc. gefunden habe...
Hallo
So, am Sonntag Abend noch die aktuelle Version zum Testen. ;)
Wie schon in meinem letzten Post geschrieben, habe ich jetzt das ESP8266_Basic-Template von Pf@nne (https://forum.fhem.de/index.php/topic,50238.0 (https://forum.fhem.de/index.php/topic,50238.0)) eingebaut und um eine zweite Seite erweitert.
Wie in seinem Thread beschrieben, kann man den ESP per Handy über den intern aktiven Accesspoint konfigurieren, um dann im zweiten Schritt den Rest der Einstellungen über einen Browser zu erledigen. Die nötige IP wird ja während des ersten Schrittes angezeigt.
Auf der neu hinzugekommenen Seite zwei können die Bezeichnungen und Maßeinheiten für Screen 1-4 eingestellt werden. Außerdem werden die aktuellen Messwerte dort zur Kontrolle angezeigt.
Als Einheiten können im Moment "natürlich" nur °C und % angegeben werden, da ja zurzeit kein kompletter Zeichensatz implementiert ist.
Für die Funktion des aktuellen Sketches ist nunmehr auch das ESP8266_Basic-Template erforderlich. Allerdings nicht das Originale, sondern eine von mir erweiterte Version.
In der ZIP-Datei im Anhang befindet sich das aktuelle Web-Interface-basierende Sketch sowie das besagte Template. Beides findet sich ebenfalls auf GitHUB. Das Template muss in das Verzeichnis "...Users\<username>\Documents\Arduino\libraries\" kopiert werden. Da sollten auch die restlichen individuell installierten Libraries liegen.
In dem Template werden die MQTT-Publishs und -Subscribes automatisch zusammen gesetzt. U.a wird auch der interne Name des ESP-Moduls verwendet, der aber in der Web-Konfiguration angepasst werden kann.
Daraus ergeben sich für die Konfiguration in FHEM einige Änderungen.
Hier mal ein Beispiel:
define SB.TempHum MQTT_DEVICE
attr SB.TempHum IODev mqtt
attr SB.TempHum stateFormat state
attr SB.TempHum subscribeReading_Luftfeuchte ESP8266_12345678/Sensor/humidity/H1
attr SB.TempHum subscribeReading_Temperatur ESP8266_12345678/Sensor/temperature/T1
define TR.Temperatur.mqtt MQTT_BRIDGE TR.Temperatur.Luftfeuchte
attr TR.Temperatur.mqtt IODev mqtt
attr TR.Temperatur.mqtt publishReading_temperature ESP8266_12345678/Display/NHD_1.69/Screen_0
attr TR.Temperatur.mqtt publishReading_humidity ESP8266_12345678/Display/NHD_1.69/Screen_1
In meinem letzten Post hatte ich auch geschrieben, dass zumindest bei meinem Display das Festlegen eines Fensters und die Ausgabe nur in diesem Bereich nicht funktioniert. Die Programmierung der vier Register fürht dazu, dass die Anzeige eingefroren wird. Daher habe ich diese Funktion (FillArea) jetzt direkt im Sketch realisiert.
Vielleicht kann ja Jemand mal in einem Test-Sketch ausprobieren, ob das ein grundsätzliches Problem ist oder ich nur einen Denkfehler hatte oder mein Display einen Schaden hat.
Und nun erst einmal viel Spaß beim Testen.
Viele Grüße
wingfighter
Bei mir mosert Arduino, dass es ArduinoJson.h nicht finden kann. Bevor ich 'n falsches File ziehe: brauchst Du eine bestimmte Version, oder tut's die von bblanchon?
Ich habe mal in die Datei geguckt.
Deine Annahme war richtig
https://github.com/bblanchon/ArduinoJson (https://github.com/bblanchon/ArduinoJson)
So, nun bin ich dazugekommen, die neue Firmware zu Flashen. Läuft einwandfrei.
Für andere Tester vielleicht noch kurz zur Erläuterung:
Ich musste ein paar Libraries nachinstallieren:
ArduinoJson-master
OneWire-master
Arduino-Temperature-Control-Library-master
Das Default-Passwort für die SSID des ESPs lautet ESP8266config
@wingfighter
Ich hab Mal ein bisschen nach Wettericons gesucht und mit der Robotofont gespielt. Dabei dachte ich, dass es vielleicht einfacher ist, wenn man für die Wettericons ebenfalls einen Fontsatz und keine Graphiken verwendet. Vielleicht kann man ja sogar einen Fontsatz implementieren, der dann dynamisch in der Größe angepasst werden kann, anstatt jede Ziffer/Buchstabe im HEX-Code angeben zu müssen...
Dieser Fontsatz hier gefällt mir eigentlich nicht schlecht (und hat mit dem "Tornadosymbol" auch gleich etwas für meine Windwarnung dabei):
https://github.com/kickstandapps/WeatherIcons
Die Frage wird nur sein, ob der ESP noch genug Speicher hat um entweder einen Fontsatz oder alle Icons im Sketch unterzubrigen, oder ob man nicht doch lieber dynamisch per MQTT Graphiken publisht. Dazu kann ich als Laie nicht viel sagen.
Die Robotofont passt bei meiner Anforderung (möglichst groß, aber nicht so breit) mit den Standardparametern nicht auf's Display. Ich benötige ja im schlechtesten Fall 5 Stellen + Einheit (z.B. -14.4°). Das geht sich auf meinem Testmockup in Photoshop am Besten bei einer Schriftgröße des Temperaturwerts von 65px (Roboto Light wegen Erkennbarkeit) - allerdings nur, wenn ich die Laufweite auf 50% verringere. Sprich man muss die einzelnen Ziffern näher zusammenrücken. Dafür habe ich die Luftfeuchte in eine Extrazeile gepackt. Vom Design wollte ich es lieber ohne viel Farbe machen. Man kann aber einzelne Bereiche sicher recht leicht (vielleicht sogar wert-abhängig) mit Farbe versehen, indem man halt z.B. das Tornadoicon einfach rot anzeigen lässt.
Zudem sollte vielleicht das Intervall des Wechsels der einzelnen Screens anpassbar sein. Ich fände 5 Sekunden weniger "hektisch"... ;-)
Hallo tomster
Ich habe mich mal mit der Speicherung im Dateisystem des ESP beschäftigt.
Dank Pf@nnes Template gibt es dafür auch schon die passenden Funktionen.
Ich denke, es wird das einfachste sein, wenn wir speicherintensive Daten in das Dateisystem auslagern und bei Bedarf von dort lesen.
Dann sind wir bein der Art der verwendeten Grafiken und auch der Schriftzeichen flexibel.
Die von Dir genannte Seite mit den Wettersymbolen und dem Roboto-ähnlichen Font enthält "leider" nur echte Fontdateien. Ich denke, die auszulesen ist noch einmal eine andere Baustelle.
Daher würde ich dafür plädieren, für jedes verwendete Zeichen und dann - je nach verfügbarem Speicherplatz - auch für verschiedene Fonts, die Hex-Codierung als Datei zu hinterlegen.
Und in derselben Weise können wir dann auch die BMP's - nur dafür habe ich im Moment eine Möglichkeit des byteweisen Lesens und damit Schreibens in den Display-Speicher gefunden (danke Rince) - in verschiedener grafischer Ausprägung hinterlegen.
Als Dateiname wäre dann der Wetter-Symbol-Name sinnvoll (z.B. claudy.bmp, partly_cloudy.bmp etc.). Und wenn dann per MQTT ein 'claudy' oder 'sunny' oder 'raining' etc. an den ESP gesendet wird, kann man daraus den BMP-Dateinamen ermitteln und aus dem Dateisystem des ESP laden und anzeigen.
Für die Screen-Wiederholrate werde ich auf der zweiten Config-Seite eine Spalte einfügen, in der man je Screen die Anzeigedauer auswählen kann. Dann kann jeder die Anzeige -"Hektik" individuell steuern. ;-)
Bezüglich Deiner Font-Idee könntest Du ja dennoch so vorgehen, wie Du es beschrieben hast.
Einfach die Zahlen von 0-9 und die nötigen Sonderzeichen - also "- . °C %" - nebeneinander in PS in einen Bildstreifen schreiben und die Größe und Laufweite so einstellen, dass -99.9 °C auf 160 Pixel Breite passt. Besser noch -00.0°C, weil Nullen in den meisten Fonts die breiteste Ausprägung haben.
Ich kann im Sketch einstellen wie breit die Buchstaben sind. Sie sollten aber einheitlich breit sein, damit ich alle Zeichen mit der selben Schleife in den Speicher schreiben kann.
Konvertieren kannst Du die einzelnen Zeichen mit dem folgenden Tool: http://en.radzio.dxp.pl/bitmap_converter/LCDAssistant.zip (http://en.radzio.dxp.pl/bitmap_converter/LCDAssistant.zip)
Du würdest mir sehr helfen, wenn Du das Erzeugen der Hex-Arrays Deines Lieblingsfonts für mich übernehmen könntest.
Ich teste jetzt erst einmal ob die Idee mir der Speicherung der Wettersymbole, Auslesen und in den Displayspeicher schreiben umsetzbar ist.
Gruß
wingfighter
ZitatBezüglich Deiner Font-Idee könntest Du ja dennoch so vorgehen, wie Du es beschrieben hast.
Einfach die Zahlen von 0-9 und die nötigen Sonderzeichen - also "- . °C %" - nebeneinander in PS in einen Bildstreifen schreiben und die Größe und Laufweite so einstellen, dass -99.9 °C auf 160 Pixel Breite passt. Besser noch -00.0°C, weil Nullen in den meisten Fonts die breiteste Ausprägung haben.
Ich kann im Sketch einstellen wie breit die Buchstaben sind. Sie sollten aber einheitlich breit sein, damit ich alle Zeichen mit der selben Schleife in den Speicher schreiben kann.
Konvertieren kannst Du die einzelnen Zeichen mit dem folgenden Tool: http://en.radzio.dxp.pl/bitmap_converter/LCDAssistant.zip (http://en.radzio.dxp.pl/bitmap_converter/LCDAssistant.zip)
Du würdest mir sehr helfen, wenn Du das Erzeugen der Hex-Arrays Deines Lieblingsfonts für mich übernehmen könntest.
Mach ich! Ich hab deshalb nach Font-Dateien gesucht, weil man dann eine vernünftige Basis hat, um die Schrift vor und zurück bis zur fertigen "Endgröße" in HEX umzuwandeln.
Das mit "Bildern" zu machen fände ich fast zu umständlich. Ich mach das mit dem hier (http://www.eran.io/the-dot-factory-an-lcd-font-and-image-generator/).
Die einzelnen Buchstaben/ Ziffern mit fester Breite zu codieren ist aber blöde, weil dann z.B. bei einem Punkt eine ziemlich Platzverschwendung stattfindet...
Mit dem Punkt hast Du recht.
Das ist auch jetzt schon das einzige Zeichen, welches ich gesondert behandle, damit der Abstand nicht zu groß wird.
Alternativ wäre es aber eine Möglichkeit, in den ersten beiden Bytes des Hex-Arrays die Dimension - also Anzahl x-Pixel, Anzahl y-Pixel - zu schreiben, dann kann man beim Übertragen die Schleifen entsprechend anpassen.
Schau mal, ob das Konverter-Tool das hergibt.
Die jeweilige Breite direkt in's HEX-Array zu schreiben ist mir nicht gelungen. Aber "mein" Tool schreibt ein Array const FONT_CHAR_INFO , welches die jeweilige Breite der Chars angibt. Reicht das auch?
const uint_8 robotoLt_48ptBitmaps[] =
{
// @0 '-' (19 pixels wide)
0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, //
0xFF, 0xFF, 0xE0, // ###################
0xFF, 0xFF, 0xE0, // ###################
0xFF, 0xFF, 0xE0, // ###################
0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, //
0x00, 0x00, 0x00, //
// @141 '.' (5 pixels wide)
0x00, //
0x00, //
0x00, //
0x00, //
0x00, //
0x00, //
0x00, //
0x00, //
0x00, //
0x00, //
0x00, //
0x00, //
0x00, //
0x00, //
0x00, //
0x00, //
0x00, //
0x00, //
0x00, //
0x00, //
0x00, //
0x00, //
0x00, //
0x00, //
0x00, //
0x00, //
0x00, //
0x00, //
0x00, //
0x00, //
0x00, //
0x00, //
0x00, //
0x00, //
0x00, //
0x00, //
0x00, //
0x00, //
0x00, //
0x00, //
0x00, //
0x00, //
0xF8, // #####
0xF8, // #####
0xF8, // #####
0xF8, // #####
0xF8, // #####
// @188 '0' (28 pixels wide)
0x00, 0x00, 0x00, 0x00, //
0x00, 0xFF, 0xE0, 0x00, // ###########
0x03, 0xFF, 0xF8, 0x00, // ###############
0x07, 0xFF, 0xFE, 0x00, // ##################
0x0F, 0x80, 0x3F, 0x00, // ##### ######
0x1F, 0x00, 0x0F, 0x00, // ##### ####
0x3E, 0x00, 0x07, 0x80, // ##### ####
0x3C, 0x00, 0x03, 0xC0, // #### ####
0x78, 0x00, 0x03, 0xC0, // #### ####
0x78, 0x00, 0x01, 0xE0, // #### ####
0xF0, 0x00, 0x01, 0xE0, // #### ####
0xF0, 0x00, 0x00, 0xE0, // #### ###
0xF0, 0x00, 0x00, 0xE0, // #### ###
0xF0, 0x00, 0x00, 0xF0, // #### ####
0xE0, 0x00, 0x00, 0xF0, // ### ####
0xE0, 0x00, 0x00, 0xF0, // ### ####
0xE0, 0x00, 0x00, 0xF0, // ### ####
0xE0, 0x00, 0x00, 0xF0, // ### ####
0xE0, 0x00, 0x00, 0xF0, // ### ####
0xE0, 0x00, 0x00, 0xF0, // ### ####
0xE0, 0x00, 0x00, 0xF0, // ### ####
0xE0, 0x00, 0x00, 0xF0, // ### ####
0xE0, 0x00, 0x00, 0xF0, // ### ####
0xE0, 0x00, 0x00, 0xF0, // ### ####
0xE0, 0x00, 0x00, 0xF0, // ### ####
0xE0, 0x00, 0x00, 0xF0, // ### ####
0xE0, 0x00, 0x00, 0xF0, // ### ####
0xE0, 0x00, 0x00, 0xF0, // ### ####
0xE0, 0x00, 0x00, 0xF0, // ### ####
0xE0, 0x00, 0x00, 0xF0, // ### ####
0xE0, 0x00, 0x00, 0xF0, // ### ####
0xE0, 0x00, 0x00, 0xF0, // ### ####
0xE0, 0x00, 0x00, 0xF0, // ### ####
0xE0, 0x00, 0x00, 0xF0, // ### ####
0xF0, 0x00, 0x00, 0xF0, // #### ####
0xF0, 0x00, 0x00, 0xE0, // #### ###
0xF0, 0x00, 0x01, 0xE0, // #### ####
0xF0, 0x00, 0x01, 0xE0, // #### ####
0x78, 0x00, 0x01, 0xE0, // #### ####
0x78, 0x00, 0x03, 0xC0, // #### ####
0x3C, 0x00, 0x03, 0xC0, // #### ####
0x3E, 0x00, 0x07, 0x80, // ##### ####
0x1F, 0x00, 0x0F, 0x80, // ##### #####
0x0F, 0xC0, 0x3F, 0x00, // ###### ######
0x07, 0xFF, 0xFE, 0x00, // ##################
0x03, 0xFF, 0xF8, 0x00, // ###############
0x00, 0xFF, 0xE0, 0x00, // ###########
// @376 '1' (15 pixels wide)
0x00, 0x0E, // ###
0x07, 0xFE, // ##########
0xFF, 0xFE, // ###############
0xFF, 0xFE, // ###############
0xFE, 0x1E, // ####### ####
0x00, 0x1E, // ####
0x00, 0x1E, // ####
0x00, 0x1E, // ####
0x00, 0x1E, // ####
0x00, 0x1E, // ####
0x00, 0x1E, // ####
0x00, 0x1E, // ####
0x00, 0x1E, // ####
0x00, 0x1E, // ####
0x00, 0x1E, // ####
0x00, 0x1E, // ####
0x00, 0x1E, // ####
0x00, 0x1E, // ####
0x00, 0x1E, // ####
0x00, 0x1E, // ####
0x00, 0x1E, // ####
0x00, 0x1E, // ####
0x00, 0x1E, // ####
0x00, 0x1E, // ####
0x00, 0x1E, // ####
0x00, 0x1E, // ####
0x00, 0x1E, // ####
0x00, 0x1E, // ####
0x00, 0x1E, // ####
0x00, 0x1E, // ####
0x00, 0x1E, // ####
0x00, 0x1E, // ####
0x00, 0x1E, // ####
0x00, 0x1E, // ####
0x00, 0x1E, // ####
0x00, 0x1E, // ####
0x00, 0x1E, // ####
0x00, 0x1E, // ####
0x00, 0x1E, // ####
0x00, 0x1E, // ####
0x00, 0x1E, // ####
0x00, 0x1E, // ####
0x00, 0x1E, // ####
0x00, 0x1E, // ####
0x00, 0x1E, // ####
0x00, 0x1E, // ####
0x00, 0x1E, // ####
// @470 '2' (28 pixels wide)
0x00, 0x00, 0x00, 0x00, //
0x00, 0xFF, 0xF0, 0x00, // ############
0x03, 0xFF, 0xFC, 0x00, // ################
0x07, 0xFF, 0xFE, 0x00, // ##################
0x0F, 0x80, 0x3F, 0x00, // ##### ######
0x1F, 0x00, 0x0F, 0x80, // ##### #####
0x3E, 0x00, 0x07, 0x80, // ##### ####
0x3C, 0x00, 0x03, 0xC0, // #### ####
0x78, 0x00, 0x03, 0xC0, // #### ####
0x78, 0x00, 0x03, 0xC0, // #### ####
0x70, 0x00, 0x01, 0xC0, // ### ###
0xF0, 0x00, 0x01, 0xE0, // #### ####
0xF0, 0x00, 0x01, 0xE0, // #### ####
0xF0, 0x00, 0x01, 0xE0, // #### ####
0x00, 0x00, 0x01, 0xC0, // ###
0x00, 0x00, 0x03, 0xC0, // ####
0x00, 0x00, 0x03, 0xC0, // ####
0x00, 0x00, 0x03, 0xC0, // ####
0x00, 0x00, 0x07, 0x80, // ####
0x00, 0x00, 0x07, 0x80, // ####
0x00, 0x00, 0x0F, 0x00, // ####
0x00, 0x00, 0x0F, 0x00, // ####
0x00, 0x00, 0x1E, 0x00, // ####
0x00, 0x00, 0x3C, 0x00, // ####
0x00, 0x00, 0x78, 0x00, // ####
0x00, 0x00, 0x78, 0x00, // ####
0x00, 0x00, 0xF0, 0x00, // ####
0x00, 0x01, 0xE0, 0x00, // ####
0x00, 0x03, 0xC0, 0x00, // ####
0x00, 0x07, 0xC0, 0x00, // #####
0x00, 0x0F, 0x80, 0x00, // #####
0x00, 0x1F, 0x00, 0x00, // #####
0x00, 0x1E, 0x00, 0x00, // ####
0x00, 0x3C, 0x00, 0x00, // ####
0x00, 0x78, 0x00, 0x00, // ####
0x00, 0xF0, 0x00, 0x00, // ####
0x01, 0xF0, 0x00, 0x00, // #####
0x03, 0xE0, 0x00, 0x00, // #####
0x03, 0xC0, 0x00, 0x00, // ####
0x07, 0x80, 0x00, 0x00, // ####
0x0F, 0x00, 0x00, 0x00, // ####
0x1E, 0x00, 0x00, 0x00, // ####
0x3C, 0x00, 0x00, 0x00, // ####
0x7C, 0x00, 0x00, 0x00, // #####
0x7F, 0xFF, 0xFF, 0xF0, // ###########################
0x7F, 0xFF, 0xFF, 0xF0, // ###########################
0x7F, 0xFF, 0xFF, 0xF0, // ###########################
// @658 '3' (28 pixels wide)
0x00, 0x00, 0x00, 0x00, //
0x00, 0xFF, 0xF0, 0x00, // ############
0x03, 0xFF, 0xFC, 0x00, // ################
0x07, 0xFF, 0xFE, 0x00, // ##################
0x0F, 0xC0, 0x3F, 0x00, // ###### ######
0x1F, 0x00, 0x0F, 0x80, // ##### #####
0x3C, 0x00, 0x07, 0xC0, // #### #####
0x7C, 0x00, 0x03, 0xC0, // ##### ####
0x78, 0x00, 0x03, 0xC0, // #### ####
0x70, 0x00, 0x01, 0xE0, // ### ####
0xF0, 0x00, 0x01, 0xE0, // #### ####
0xF0, 0x00, 0x01, 0xE0, // #### ####
0xF0, 0x00, 0x01, 0xE0, // #### ####
0x00, 0x00, 0x01, 0xE0, // ####
0x00, 0x00, 0x01, 0xE0, // ####
0x00, 0x00, 0x01, 0xE0, // ####
0x00, 0x00, 0x01, 0xE0, // ####
0x00, 0x00, 0x03, 0xC0, // ####
0x00, 0x00, 0x07, 0xC0, // #####
0x00, 0x00, 0x07, 0x80, // ####
0x00, 0x00, 0x1F, 0x00, // #####
0x00, 0x00, 0xFE, 0x00, // #######
0x00, 0x7F, 0xF8, 0x00, // ############
0x00, 0x7F, 0xF0, 0x00, // ###########
0x00, 0x7F, 0xFC, 0x00, // #############
0x00, 0x00, 0x3F, 0x00, // ######
0x00, 0x00, 0x0F, 0x80, // #####
0x00, 0x00, 0x03, 0xC0, // ####
0x00, 0x00, 0x03, 0xC0, // ####
0x00, 0x00, 0x01, 0xE0, // ####
0x00, 0x00, 0x00, 0xE0, // ###
0x00, 0x00, 0x00, 0xF0, // ####
0x00, 0x00, 0x00, 0xF0, // ####
0x00, 0x00, 0x00, 0xF0, // ####
0xE0, 0x00, 0x00, 0xF0, // ### ####
0xE0, 0x00, 0x00, 0xF0, // ### ####
0xE0, 0x00, 0x00, 0xF0, // ### ####
0xF0, 0x00, 0x00, 0xF0, // #### ####
0xF0, 0x00, 0x00, 0xE0, // #### ###
0xF0, 0x00, 0x01, 0xE0, // #### ####
0x78, 0x00, 0x03, 0xE0, // #### #####
0x7C, 0x00, 0x03, 0xC0, // ##### ####
0x3E, 0x00, 0x0F, 0x80, // ##### #####
0x1F, 0x80, 0x1F, 0x80, // ###### ######
0x0F, 0xFF, 0xFF, 0x00, // ####################
0x03, 0xFF, 0xFC, 0x00, // ################
0x00, 0xFF, 0xF0, 0x00, // ############
// @846 '4' (32 pixels wide)
0x00, 0x00, 0x00, 0x00, //
0x00, 0x00, 0x0F, 0x80, // #####
0x00, 0x00, 0x0F, 0x80, // #####
0x00, 0x00, 0x1F, 0x80, // ######
0x00, 0x00, 0x1F, 0x80, // ######
0x00, 0x00, 0x3F, 0x80, // #######
0x00, 0x00, 0x7F, 0x80, // ########
0x00, 0x00, 0x77, 0x80, // ### ####
0x00, 0x00, 0xF7, 0x80, // #### ####
0x00, 0x01, 0xE7, 0x80, // #### ####
0x00, 0x01, 0xE7, 0x80, // #### ####
0x00, 0x03, 0xC7, 0x80, // #### ####
0x00, 0x07, 0xC7, 0x80, // ##### ####
0x00, 0x07, 0x87, 0x80, // #### ####
0x00, 0x0F, 0x07, 0x80, // #### ####
0x00, 0x0F, 0x07, 0x80, // #### ####
0x00, 0x1E, 0x07, 0x80, // #### ####
0x00, 0x3C, 0x07, 0x80, // #### ####
0x00, 0x3C, 0x07, 0x80, // #### ####
0x00, 0x78, 0x07, 0x80, // #### ####
0x00, 0xF0, 0x07, 0x80, // #### ####
0x00, 0xF0, 0x07, 0x80, // #### ####
0x01, 0xE0, 0x07, 0x80, // #### ####
0x03, 0xC0, 0x07, 0x80, // #### ####
0x03, 0xC0, 0x07, 0x80, // #### ####
0x07, 0x80, 0x07, 0x80, // #### ####
0x07, 0x00, 0x07, 0x80, // ### ####
0x0F, 0x00, 0x07, 0x80, // #### ####
0x1E, 0x00, 0x07, 0x80, // #### ####
0x1E, 0x00, 0x07, 0x80, // #### ####
0x3C, 0x00, 0x07, 0x80, // #### ####
0x78, 0x00, 0x07, 0x80, // #### ####
0x7F, 0xFF, 0xFF, 0xFF, // ###############################
0xFF, 0xFF, 0xFF, 0xFF, // ################################
0xFF, 0xFF, 0xFF, 0xFF, // ################################
0x00, 0x00, 0x07, 0x80, // ####
0x00, 0x00, 0x07, 0x80, // ####
0x00, 0x00, 0x07, 0x80, // ####
0x00, 0x00, 0x07, 0x80, // ####
0x00, 0x00, 0x07, 0x80, // ####
0x00, 0x00, 0x07, 0x80, // ####
0x00, 0x00, 0x07, 0x80, // ####
0x00, 0x00, 0x07, 0x80, // ####
0x00, 0x00, 0x07, 0x80, // ####
0x00, 0x00, 0x07, 0x80, // ####
0x00, 0x00, 0x07, 0x80, // ####
0x00, 0x00, 0x07, 0x80, // ####
// @1034 '5' (27 pixels wide)
0x00, 0x00, 0x00, 0x00, //
0x1F, 0xFF, 0xFF, 0x80, // ######################
0x1F, 0xFF, 0xFF, 0x80, // ######################
0x1F, 0xFF, 0xFF, 0x80, // ######################
0x1E, 0x00, 0x00, 0x00, // ####
0x1C, 0x00, 0x00, 0x00, // ###
0x1C, 0x00, 0x00, 0x00, // ###
0x1C, 0x00, 0x00, 0x00, // ###
0x1C, 0x00, 0x00, 0x00, // ###
0x1C, 0x00, 0x00, 0x00, // ###
0x3C, 0x00, 0x00, 0x00, // ####
0x3C, 0x00, 0x00, 0x00, // ####
0x3C, 0x00, 0x00, 0x00, // ####
0x3C, 0x00, 0x00, 0x00, // ####
0x3C, 0x00, 0x00, 0x00, // ####
0x38, 0x00, 0x00, 0x00, // ###
0x38, 0x00, 0x00, 0x00, // ###
0x38, 0x0F, 0x00, 0x00, // ### ####
0x38, 0xFF, 0xF0, 0x00, // ### ############
0x39, 0xFF, 0xFC, 0x00, // ### ###############
0x7F, 0xFF, 0xFE, 0x00, // ######################
0x7F, 0xC0, 0x7F, 0x00, // ######### #######
0x7E, 0x00, 0x1F, 0x80, // ###### ######
0x7C, 0x00, 0x0F, 0x80, // ##### #####
0x78, 0x00, 0x07, 0xC0, // #### #####
0x70, 0x00, 0x03, 0xC0, // ### ####
0x10, 0x00, 0x03, 0xC0, // # ####
0x00, 0x00, 0x01, 0xE0, // ####
0x00, 0x00, 0x01, 0xE0, // ####
0x00, 0x00, 0x01, 0xE0, // ####
0x00, 0x00, 0x01, 0xE0, // ####
0x00, 0x00, 0x01, 0xE0, // ####
0x00, 0x00, 0x01, 0xE0, // ####
0x00, 0x00, 0x01, 0xE0, // ####
0x00, 0x00, 0x01, 0xE0, // ####
0xF0, 0x00, 0x01, 0xE0, // #### ####
0xF0, 0x00, 0x01, 0xE0, // #### ####
0xF0, 0x00, 0x01, 0xE0, // #### ####
0x70, 0x00, 0x03, 0xC0, // ### ####
0x78, 0x00, 0x03, 0xC0, // #### ####
0x78, 0x00, 0x07, 0xC0, // #### #####
0x3C, 0x00, 0x07, 0x80, // #### ####
0x3E, 0x00, 0x0F, 0x00, // ##### ####
0x1F, 0x80, 0x3F, 0x00, // ###### ######
0x0F, 0xFF, 0xFE, 0x00, // ###################
0x03, 0xFF, 0xF8, 0x00, // ###############
0x00, 0xFF, 0xE0, 0x00, // ###########
// @1222 '6' (28 pixels wide)
0x00, 0x00, 0x00, 0x00, //
0x00, 0x7F, 0xF8, 0x00, // ############
0x01, 0xFF, 0xFF, 0x00, // #################
0x03, 0xFF, 0xFF, 0x00, // ##################
0x07, 0xE0, 0x0E, 0x00, // ###### ###
0x0F, 0x80, 0x00, 0x00, // #####
0x1F, 0x00, 0x00, 0x00, // #####
0x3E, 0x00, 0x00, 0x00, // #####
0x3C, 0x00, 0x00, 0x00, // ####
0x78, 0x00, 0x00, 0x00, // ####
0x78, 0x00, 0x00, 0x00, // ####
0x70, 0x00, 0x00, 0x00, // ###
0xF0, 0x00, 0x00, 0x00, // ####
0xF0, 0x00, 0x00, 0x00, // ####
0xF0, 0x00, 0x00, 0x00, // ####
0xF0, 0x00, 0x00, 0x00, // ####
0xF0, 0x00, 0x00, 0x00, // ####
0xF0, 0x00, 0x00, 0x00, // ####
0xF0, 0x1F, 0xE0, 0x00, // #### ########
0xF0, 0xFF, 0xF8, 0x00, // #### #############
0xF1, 0xFF, 0xFE, 0x00, // #### ################
0xF3, 0xE0, 0x7F, 0x00, // #### ##### #######
0xF7, 0x00, 0x0F, 0x80, // #### ### #####
0xFE, 0x00, 0x07, 0xC0, // ####### #####
0xFC, 0x00, 0x03, 0xC0, // ###### ####
0xF8, 0x00, 0x03, 0xE0, // ##### #####
0xF0, 0x00, 0x01, 0xE0, // #### ####
0xF0, 0x00, 0x01, 0xE0, // #### ####
0xF0, 0x00, 0x00, 0xE0, // #### ###
0xF0, 0x00, 0x00, 0xF0, // #### ####
0xF0, 0x00, 0x00, 0xF0, // #### ####
0xF0, 0x00, 0x00, 0xF0, // #### ####
0xF0, 0x00, 0x00, 0xF0, // #### ####
0xF0, 0x00, 0x00, 0xF0, // #### ####
0xF0, 0x00, 0x00, 0xF0, // #### ####
0xF0, 0x00, 0x00, 0xF0, // #### ####
0x70, 0x00, 0x00, 0xE0, // ### ###
0x78, 0x00, 0x01, 0xE0, // #### ####
0x78, 0x00, 0x01, 0xE0, // #### ####
0x3C, 0x00, 0x03, 0xC0, // #### ####
0x3C, 0x00, 0x03, 0xC0, // #### ####
0x1E, 0x00, 0x07, 0x80, // #### ####
0x0F, 0x00, 0x0F, 0x80, // #### #####
0x0F, 0xC0, 0x3F, 0x00, // ###### ######
0x03, 0xFF, 0xFE, 0x00, // #################
0x01, 0xFF, 0xF8, 0x00, // ##############
0x00, 0x7F, 0xE0, 0x00, // ##########
// @1410 '7' (29 pixels wide)
0x00, 0x00, 0x00, 0x00, //
0xFF, 0xFF, 0xFF, 0xF8, // #############################
0xFF, 0xFF, 0xFF, 0xF8, // #############################
0xFF, 0xFF, 0xFF, 0xF8, // #############################
0x00, 0x00, 0x00, 0x78, // ####
0x00, 0x00, 0x00, 0xF0, // ####
0x00, 0x00, 0x00, 0xF0, // ####
0x00, 0x00, 0x01, 0xE0, // ####
0x00, 0x00, 0x03, 0xC0, // ####
0x00, 0x00, 0x07, 0x80, // ####
0x00, 0x00, 0x07, 0x80, // ####
0x00, 0x00, 0x0F, 0x00, // ####
0x00, 0x00, 0x1E, 0x00, // ####
0x00, 0x00, 0x1E, 0x00, // ####
0x00, 0x00, 0x3C, 0x00, // ####
0x00, 0x00, 0x38, 0x00, // ###
0x00, 0x00, 0x78, 0x00, // ####
0x00, 0x00, 0x70, 0x00, // ###
0x00, 0x00, 0xF0, 0x00, // ####
0x00, 0x00, 0xE0, 0x00, // ###
0x00, 0x01, 0xE0, 0x00, // ####
0x00, 0x01, 0xC0, 0x00, // ###
0x00, 0x03, 0xC0, 0x00, // ####
0x00, 0x03, 0x80, 0x00, // ###
0x00, 0x07, 0x80, 0x00, // ####
0x00, 0x07, 0x80, 0x00, // ####
0x00, 0x07, 0x00, 0x00, // ###
0x00, 0x0F, 0x00, 0x00, // ####
0x00, 0x0F, 0x00, 0x00, // ####
0x00, 0x0F, 0x00, 0x00, // ####
0x00, 0x0E, 0x00, 0x00, // ###
0x00, 0x1E, 0x00, 0x00, // ####
0x00, 0x1E, 0x00, 0x00, // ####
0x00, 0x1E, 0x00, 0x00, // ####
0x00, 0x1E, 0x00, 0x00, // ####
0x00, 0x1C, 0x00, 0x00, // ###
0x00, 0x1C, 0x00, 0x00, // ###
0x00, 0x1C, 0x00, 0x00, // ###
0x00, 0x3C, 0x00, 0x00, // ####
0x00, 0x3C, 0x00, 0x00, // ####
0x00, 0x3C, 0x00, 0x00, // ####
0x00, 0x3C, 0x00, 0x00, // ####
0x00, 0x3C, 0x00, 0x00, // ####
0x00, 0x3C, 0x00, 0x00, // ####
0x00, 0x3C, 0x00, 0x00, // ####
0x00, 0x3C, 0x00, 0x00, // ####
0x00, 0x3C, 0x00, 0x00, // ####
// @1598 '8' (29 pixels wide)
0x00, 0x00, 0x00, 0x00, //
0x00, 0x7F, 0xF8, 0x00, // ############
0x01, 0xFF, 0xFE, 0x00, // ################
0x07, 0xFF, 0xFF, 0x00, // ###################
0x0F, 0xE0, 0x1F, 0x80, // ####### ######
0x1F, 0x80, 0x07, 0xC0, // ###### #####
0x1E, 0x00, 0x03, 0xE0, // #### #####
0x3E, 0x00, 0x01, 0xE0, // ##### ####
0x3C, 0x00, 0x01, 0xF0, // #### #####
0x3C, 0x00, 0x00, 0xF0, // #### ####
0x38, 0x00, 0x00, 0xF0, // ### ####
0x78, 0x00, 0x00, 0xF0, // #### ####
0x78, 0x00, 0x00, 0xF0, // #### ####
0x78, 0x00, 0x00, 0xF0, // #### ####
0x38, 0x00, 0x00, 0xF0, // ### ####
0x3C, 0x00, 0x00, 0xF0, // #### ####
0x3C, 0x00, 0x00, 0xE0, // #### ###
0x1E, 0x00, 0x01, 0xE0, // #### ####
0x1E, 0x00, 0x03, 0xC0, // #### ####
0x0F, 0x80, 0x07, 0xC0, // ##### #####
0x07, 0xC0, 0x0F, 0x80, // ##### #####
0x03, 0xFC, 0xFF, 0x00, // ######## ########
0x00, 0xFF, 0xFC, 0x00, // ##############
0x00, 0xFF, 0xF8, 0x00, // #############
0x03, 0xFF, 0xFE, 0x00, // #################
0x07, 0xE0, 0x1F, 0x80, // ###### ######
0x0F, 0x00, 0x07, 0xC0, // #### #####
0x1E, 0x00, 0x01, 0xE0, // #### ####
0x3C, 0x00, 0x00, 0xF0, // #### ####
0x78, 0x00, 0x00, 0xF0, // #### ####
0x78, 0x00, 0x00, 0x78, // #### ####
0x70, 0x00, 0x00, 0x78, // ### ####
0xF0, 0x00, 0x00, 0x78, // #### ####
0xF0, 0x00, 0x00, 0x38, // #### ###
0xF0, 0x00, 0x00, 0x38, // #### ###
0xF0, 0x00, 0x00, 0x38, // #### ###
0xF0, 0x00, 0x00, 0x78, // #### ####
0xF0, 0x00, 0x00, 0x78, // #### ####
0x78, 0x00, 0x00, 0x78, // #### ####
0x78, 0x00, 0x00, 0xF8, // #### #####
0x7C, 0x00, 0x00, 0xF0, // ##### ####
0x3E, 0x00, 0x01, 0xF0, // ##### #####
0x1F, 0x00, 0x07, 0xE0, // ##### ######
0x0F, 0xC0, 0x0F, 0xC0, // ###### ######
0x07, 0xFF, 0xFF, 0x80, // ####################
0x03, 0xFF, 0xFE, 0x00, // #################
0x00, 0x7F, 0xF8, 0x00, // ############
// @1786 '9' (28 pixels wide)
0x00, 0x00, 0x00, 0x00, //
0x00, 0xFF, 0xE0, 0x00, // ###########
0x01, 0xFF, 0xF8, 0x00, // ##############
0x07, 0xFF, 0xFE, 0x00, // ##################
0x0F, 0xC0, 0x3F, 0x00, // ###### ######
0x1F, 0x00, 0x0F, 0x80, // ##### #####
0x1E, 0x00, 0x07, 0x80, // #### ####
0x3C, 0x00, 0x03, 0xC0, // #### ####
0x7C, 0x00, 0x03, 0xC0, // ##### ####
0x78, 0x00, 0x01, 0xE0, // #### ####
0x78, 0x00, 0x01, 0xE0, // #### ####
0xF0, 0x00, 0x00, 0xE0, // #### ###
0xF0, 0x00, 0x00, 0xF0, // #### ####
0xF0, 0x00, 0x00, 0xF0, // #### ####
0xF0, 0x00, 0x00, 0xF0, // #### ####
0xF0, 0x00, 0x00, 0xF0, // #### ####
0xF0, 0x00, 0x00, 0xF0, // #### ####
0xF0, 0x00, 0x00, 0xF0, // #### ####
0xF0, 0x00, 0x00, 0xF0, // #### ####
0xF0, 0x00, 0x00, 0xF0, // #### ####
0xF0, 0x00, 0x00, 0xF0, // #### ####
0x78, 0x00, 0x00, 0xF0, // #### ####
0x78, 0x00, 0x01, 0xF0, // #### #####
0x7C, 0x00, 0x01, 0xF0, // ##### #####
0x3E, 0x00, 0x03, 0xF0, // ##### ######
0x1F, 0x00, 0x0F, 0xF0, // ##### ########
0x1F, 0x80, 0x1E, 0xF0, // ###### #### ####
0x0F, 0xF1, 0xFC, 0xF0, // ######## ####### ####
0x03, 0xFF, 0xF8, 0xF0, // ############### ####
0x01, 0xFF, 0xE0, 0xF0, // ############ ####
0x00, 0x3F, 0x80, 0xF0, // ####### ####
0x00, 0x00, 0x00, 0xF0, // ####
0x00, 0x00, 0x00, 0xF0, // ####
0x00, 0x00, 0x00, 0xF0, // ####
0x00, 0x00, 0x00, 0xF0, // ####
0x00, 0x00, 0x00, 0xF0, // ####
0x00, 0x00, 0x00, 0xE0, // ###
0x00, 0x00, 0x01, 0xE0, // ####
0x00, 0x00, 0x01, 0xE0, // ####
0x00, 0x00, 0x03, 0xC0, // ####
0x00, 0x00, 0x03, 0xC0, // ####
0x00, 0x00, 0x07, 0x80, // ####
0x08, 0x00, 0x1F, 0x80, // # ######
0x0E, 0x00, 0x3F, 0x00, // ### ######
0x0F, 0xFF, 0xFE, 0x00, // ###################
0x0F, 0xFF, 0xF8, 0x00, // #################
0x01, 0xFF, 0xE0, 0x00, // ############
// @1974 '°' (16 pixels wide)
0x00, 0x00, //
0x0F, 0xF0, // ########
0x1F, 0xF8, // ##########
0x3F, 0xFC, // ############
0x78, 0x1E, // #### ####
0x70, 0x0E, // ### ###
0x70, 0x06, // ### ##
0x60, 0x07, // ## ###
0xE0, 0x07, // ### ###
0x60, 0x07, // ## ###
0x70, 0x0E, // ### ###
0x70, 0x0E, // ### ###
0x3C, 0x3E, // #### #####
0x3F, 0xFC, // ############
0x1F, 0xF8, // ##########
0x07, 0xE0, // ######
0x00, 0x00, //
0x00, 0x00, //
0x00, 0x00, //
0x00, 0x00, //
0x00, 0x00, //
0x00, 0x00, //
0x00, 0x00, //
0x00, 0x00, //
0x00, 0x00, //
0x00, 0x00, //
0x00, 0x00, //
0x00, 0x00, //
0x00, 0x00, //
0x00, 0x00, //
0x00, 0x00, //
0x00, 0x00, //
0x00, 0x00, //
0x00, 0x00, //
0x00, 0x00, //
0x00, 0x00, //
0x00, 0x00, //
0x00, 0x00, //
0x00, 0x00, //
0x00, 0x00, //
0x00, 0x00, //
0x00, 0x00, //
0x00, 0x00, //
0x00, 0x00, //
0x00, 0x00, //
0x00, 0x00, //
0x00, 0x00, //
};
const FONT_CHAR_INFO robotoLt_48ptDescriptorsBlock0[] =
{
{3, 0}, // -
{1, 141}, // .
{0, 0}, // /
{4, 188}, // 0
{2, 376}, // 1
{4, 470}, // 2
{4, 658}, // 3
{4, 846}, // 4
{4, 1034}, // 5
{4, 1222}, // 6
{4, 1410}, // 7
{4, 1598}, // 8
{4, 1786}, // 9
};
const FONT_CHAR_INFO robotoLt_48ptDescriptorsBlock1[] =
{
{2, 1974}, // °
};
const FONT_CHAR_INFO_LOOKUP robotoLt_48ptBlockLookup[] =
{
{'-', '9', &robotoLt_48ptDescriptorsBlock0},
{'°', '°', &robotoLt_48ptDescriptorsBlock1},
};
const FONT_INFO robotoLt_48ptFontInfo =
{
'-', // Start character
'°', // End character
2, // Width, in pixels, of space character
robotoLt_48ptBlockLookup, // Character block lookup
NULL, // Character descriptor array
robotoLt_48ptBitmaps, // Character bitmap array
};
Ja, ich denke, eines dieser zusätzlichen Arrays können wir dafür nutzen.
Immer wieder sonntags.... ;-)
In der letzten Woche gab es eine Menge Neuerungen und Änderungen an dem NHD-1.69160128-Sketch.
Die möchte ich allen Interessierten natürlich gern zur Verfügung stellen. Natürlich sind noch diverse Dinge zu erledigen und sicher tauchen auch noch Fehler auf. Dafür sind wir ja in der Version noch weiter unter 1.0. ;-)
Folgende Änderungen und neue Funktionen sind eingeflossen:
- Der RobotLight-Font, wie ihn sich tomster gewünscht hat, ist jetzt der Standard für die Darstellung der Messwerte. Dazu nutze ich jetzt das von tomster vorgeschlagene Tool http://www.eran.io/the-dot-factory-an-lcd-font-and-image-generator/ (http://www.eran.io/the-dot-factory-an-lcd-font-and-image-generator/). Dabei kommen zwar völlig andere Arrays raus. Aber wenn wir jetzt noch etwas testen wollen, kann das Sketch damit umgehen, weil ich mir die Metrik aus dem Info-Array hole, welches zusammen mit dem Zeichensatz erstellt wird. Einzig dem C musste ich ein Pixel weg nehmen, sonst hätte es in der Breite nicht auf das Display gepasst. Den restlichen Text werde ich auch mal mit robootLight in 10 oder 11 testen,
- Es gibt jetzt Wettersymbole, die im Moment beispielhaft in der Anzeigerotation mit eingebaut sind. Zur Zeit verwende ich freie Symbole von http://www.iconarchive.com/tag/weather (http://www.iconarchive.com/tag/weather). Die sind für tomsters Geschmack sicher viel zu bunt. ;-) Aber auch da ist das Sketch so ausgelegt, das jederzeit andere Symbole verwendet werden können. Es gibt im Deklarationsbereich des Sketches ein Array (weatherIconFileName) in dem zurzeit max. 30 Dateinamen hinterlegt werden können.
Mehr zu den Icons weiter unten - Im Zusammenhang mit der Frage, wie die Dateien auf den ESP kommen, habe ich vor gehabt, dass Web-Portal zu erweitern. Dazu hätte sich das Demo-Sketch FSBrowser angeboten, dass u.a. genau dafür die Funktionen liefert. Allerdings - so habe ich nach Rücksprache mit Pf@nne erfahren - ist es nicht so einfach, solche Klassen orientierten Funktionen in andere Klassen (WebServer) sauber einzubinden. Die Rede ist von Callback- und Lamdafunktionen in C++. An der Stelle wird es dann sehr speziell, so dass ich einen anderen Weg gesucht habe. Im Moment ist die FSBrowser-Klasse im Sketch eingebunden. Das bedeutet aber, dass eine zweite WebServer-Instanz aktiviert wird. Da wir für die Konfiguration schon den Port 80 nutzen, habe ich diese auf den Port 81 gelegt. Aber das scheint den ESP zu überfordern. Mehr dazu gleich...
- Offen ist noch geblieben, wie im letzten Post angekündigt, den einzelnen Screens eine eigene Anzeigedauer konfigurierbar zur Verfügung zu stellen. Aber ich denke, das werde ich im Laufe der Woche nachholen können.
- Auch die Ausgestaltung der Screens mit den Wettersymbolen durch Beschreibungen wie "heute", "Morgen", "Übermorgen" etc. folgt in der nächsten Version
Damit Ihr das auch alles testen könnt, sind ein paar Voraussetzungen notwendig.
Das Sketch benötigt natürlich irgendwo die Symbole, die je nach Vorhersage irgendwo gespeichert und geladen werden müssen.
Dazu nutze ich den internen Speicher des ESP.
Es gibt nun min. zwei Verfahren, um die Dateien, die ich im Anhang mit in die ZIP-Dateien gepackt habe, auf den ESP zu übertragen.
Eine habe ich oben schon erwähnt. Unter http://<IP-Adresse-ESP>:81/edit kommt Ihr in den FSBrowser. Dort können die BMP-Dateien einzeln hochgeladen werden. Bei mir hatte der ESP damit aber diverse Performance-Probleme. Je nach Eurer Rückmeldung werde ich diese Variante dann auch wieder entfernen.
Die Implementierung der Funktionen aus der FSBrowser-Klasse in den vorhandenen WebServer in das Template ESP8266_Basic, habe ich auskommentiert. Wenn sich jemand mit Callback- und Lamda-Funktionen auskennt, wäre ich ihm natürlich dankbar, wenn wir diese Variante zum Laufen bekommen. Das wäre allemal eleganter und vielleicht auch performanter.
Der zweite Weg ist die Übertragung der BMP's aus der Arduino-IDE heraus. Dazu ist folgendes Addon erforderlich: https://github.com/esp8266/arduino-esp8266fs-plugin (https://github.com/esp8266/arduino-esp8266fs-plugin)
Dieses Tool überträgt alle Dateien, die in einem Verzeichnis ../data unterhalb des Sketch-Verzeichnisses liegen in das Filesystem des ESP. Dazu empfehle ich, das Sketch einmal
laufen zu lassen, weil dann das Filesystem auf dem ESP angelegt wird. (Wer die vorhergehenden Versionen mit Web-Interface schon genutzt hat, bei dem ist das schon erledigt.)
Diese Java-Tool hat aus meiner Sich für unsere Zwecke einen entscheidenden Nachteil. Es überträgt neben dem Ordner ../data auch das Binary des aktuellen Sketches. Das dauert recht lange und ist für unsere Zwecke nicht notwendig.
Man kann das Tool anpassen, da die Quellen offen liegen. Aber die Baustelle wollte ich nicht auch noch aufmachen.
Wenn die Dateien an den ESP bertragen worden sind, wird als quasi Platzhalter das Sonnensysmbol nach der Anzeige der Temperaturen und Luftfeuchte angezeigt.
Nun wäre das Ganze natürlich ohne Anbindung an einen Wetterdienst auch ziemlich zwecklos. Deshalb habe ich das MQTT-Protokoll bemüht und im Pf@nne-Template eine Erweiterung eingebaut, damit die Vorhersagen für die nächsten 5 Tage entgegen genommen und angezeigt werden können.
Dazu sind in FHEM natürlich ein paar Definitionen nötig. Das Weather-Modul nutzt die Yahoo-API um an das aktuelle Wetter zu gelangen. Also muss diese Modul als erstes konfiguriert werden.
# Wetter von Yahoo (123456 = DeinOrt, 600=alle 600 Sekunden (10min) Yahoo abfragen, de=Sprache Deutsch)
define Wetter Weather 123456 600 de
attr Wetter event-on-update-reading temperature,humidity,pressure,wind_speed,wind_chill,wind_direction,fc1_code,fc2_code,fc3_code,fc4_code,fc5_code,fc6_codeDie ID für Euern Ort könnt Ihr hier ermitteln: http://woeid.rosselliot.co.nz/ (http://woeid.rosselliot.co.nz/)
Damit bei Veränderungen die notwendigen Readings aktualisiert werden, muss fc[1..n]_code hier angegeben werden. In diesen Readings steht der zweistellige Wettercode, den ich im Sketch auswerte. Die Definition ist zu finden unter: https://developer.yahoo.com/weather/documentation.html#codes (https://developer.yahoo.com/weather/documentation.html#codes). Die Tabelle habe ich aber auch im Sketch hinterlegt. Die Beziehung zwischen Code und Dateiname wird in einem switch...case in der Funktion "void selectWeatherIcon(int day)" hergestellt. Mangels ausreichend unterschiedlicher Icons werden hier einige Codes auf ein Symbol gemappt.
Im zweiten Schritt muss dann noch die Definition für die MQTT-Publishs eingetragen werden.
Das sieht dann z.B. wie folgt aus:
define SB.Wetter.mqtt MQTT_BRIDGE Wetter
attr SB.Wetter.mqtt IODev mqtt
attr SB.Wetter.mqtt publishReading_fc1_code ESP8266_12345678/Weather/Forecast/Day_0
attr SB.Wetter.mqtt publishReading_fc2_code ESP8266_12345678/Weather/Forecast/Day_1
attr SB.Wetter.mqtt publishReading_fc3_code ESP8266_12345678/Weather/Forecast/Day_2
attr SB.Wetter.mqtt publishReading_fc4_code ESP8266_12345678/Weather/Forecast/Day_3
attr SB.Wetter.mqtt publishReading_fc5_code ESP8266_12345678/Weather/Forecast/Day_4
attr SB.Wetter.mqtt publishReading_fc6_code ESP8266_12345678/Weather/Forecast/Day_5
attr SB.Wetter.mqtt stateFormat transmission-stateDie Häufigkeit der Aktualisierung ist natürlich relativ gering. Mann kann aber in dem Weather-Objekt per Hand (FHEM-GUI) eine Update des Wetters anstoßen.
Im Moment wird auf dem Display aber nur Day_0 angezeigt. Den Rest implementiere ich. Eventuell mache ich es auch auf der Konfigurations-Seite [de]aktivierbar .
Im Anhang findet Ihr die Version V.0.30 des Sketches und die BMP's in dem passenden Unterverzeichnis für die Anzeige der Wettersymbole.
Noch ein Hinweis für die Schreibweise der Temperatur: Das °-Zeichen stammt aus dem erweiterten ASCII-Zeichensatz. Es lässt sich nach meiner Erfahrung nicht sauber verarbeiten. Deshalb verwende ich in den Konfigurationen statt dessen immer den '*'. Der Stern wird beim Anzeigen gegen die Darstellung des ° ausgetauscht. Diese Lösung halte ich momentan für einen gangbaren Ansatz. Ansonsten muss ich tiefer in die Codierung des °-Zeichens einsteigen.
Nun erst einmal viel Spaß und Erfolg beim Testen.
Freue mich natürlich über Feedback.
Viele Grüße
wingfighter
Servus wingfighter!
Hut ab! Schaut nach umfangreichen Arbeiten aus... Vielen Dank dafür!
Ich hab mir grad Mal den Sketch heruntergeladen. Neben dem Gefühl, dass die Einträge für den von Dir genutzten DHT22 wohl umfangreicher geworden sind (zumindest musste ich mehr auskommentieren, um die Fehlermeldungen beim Kompilieren zu minimieren), hänge ich wohl noch an (mindestens) einer Stelle.
Du schreibst:
Zitat
Die Implementierung der Funktionen aus der FSBrowser-Klasse in den vorhandenen WebServer in das Template ESP8266_Basic, habe ich auskommentiert.
Genau dazu bekomme ich aber noch eine Fehlermeldung, Highlight im Arduino IDE = Zeile 1921:
exit status 1
'class ESP8266_Basic' has no member named 'MyWeatherIcon'
Zudem noch der Anstoss zu einer Diskussion hinsichtlich der Wetter-Icons:
Ich habe auf meinem FHEM Yahoo wieder rausgeschmissen, weil die Server gelegentlich nicht zu erreichen sind und für meinen Standort am Berg keine vernünftigen Werte zur Verfügung stehen. Zudem nutzt wohl jeder ein anderes Modul und es wäre schade, wenn "unser" Display nur Yahoo anzeigen könnte. Wir sollten uns daher einen "Modus Vivendi" einfallen lassen, der eine flexible Nutzung der Wetterfunktion bietet, ohne viel Modifikationen am Sketch selbst tätigen zu müssen. Dummerweise geben aber die jeweiligen Module (respektive die dahinterliegenden Webseiten) unterschiedliche "Werte" zurück. So bekommt man Mal z.B. "partly cloudy" und manchmal eben auch "partlycloudy" ausgegeben.
Um den Änderungsaufwand am Sketch zumindest in Verbindung mit den user-gewünschten Iconsets gering zu halten, würde ich eine durchgängige Linie bei der Namenskonvention der Icons fahren. Evtl. könnten man dann eine Konfigurationsmaske wie bei den Einheiten der Sensorwerte machen (siehe angehängtes Bild).
Klar, könnte man auch in FHEM direkt machen, aber ich dachte halt...
Eine Möglihckeit auf dem ESP ein Samba-Share einzubinden und von dort die Icons zu holen gibt es nicht, oder?
Ich komm diese Woche leider nur sporadisch zum Weitertesten, aber wenn ich noch irgendwas übernehmen soll, lass es mich (im rahmen meiner begrenzten Fähigkeiten) wissen.
Hallo tomster
OK, die Fehlermeldung deutet darauf hin, dass die Erweiterungen in dem ESP8266_Basic-Template nicht greifen. Und da fallen mir auch gleich meine Sünden ein. Ich habe die aktuelle Version des Templates schlicht vergessen mit in die ZIP-Datei zu packen. Sorry.
Das hole ich nachher nach. So gegen 16:30 bin ich wieder an meinem Rechner und hänge die Dateien an meinen Post von gestern Abend an. ;-(
Über Yahoo-Wetter habe ich in der Tat auch schon eher schlechte Dinge, was die Vorhersage-Genauigkeit angeht, gehört. Daher wäre eine Alternative auf jeden Fall eine gute Idee.
Mir war auch schon aufgefallen, dass für die Benennung der Wettersituationen die verschiedensten Begriffe verwendet werden. Daher war ich auch froh, das in den von mir im Moment verwendeten Feldern numerische Codes übertragen werden.
Eventuell verwenden diese Codes auch andere Wetterdienste mit der selben Bedeutung. Dan bräuchte wir nichts zu ändern.
Hast Du einen Vorschlag, welcher alternative Dienst im FHEM einbindbar ist? Ich kenne nur das erwähnte Modul.
Bezüglich des Dateiuploads gibt es noch eine Klasse, die sich HTTPUploader nennt. Ich werde mal prüfen, ob wir die verwenden können. Ich glaube, Pf@nne hat die in seinem Template schon implementiert um das OTA-Update darüber zu realisieren.
Viele Grüße
wingfighter
Ich hab schon diverse Wetter-Module ausprobiert: Yahoo, JSON-Readings und Wunderground, Proplanta, etc.
So richtig passt zwar bei mir keines, aber genau darum möchte ich ja "unser" Display so flexibel wie möglich gestalten.
Und "durchgängige" Codes sind mir bis jetzt sowieso noch nicht untergekommen...
U. A. auch daher der Ansatz mit dem Mapping auf dem ESP. Man kann damit für egal welches Device, bzw. Reading angezeigt werden soll, das entsprechende Icon hinterlegen.
Das auch vor dem Hintergrund, dass es vielleicht auch Anwendungsfälle gibt, bei denen gar kein Wettericon, sondern vielleicht ein Schlüssel, etc. in Abhängigkeit eines beliebigen Sensorreadings angezeigt werden soll. Man müsste dann natürlich auch komma-/ semikolonspearierte Arrays zulassen, z.B.
partlycloudy.bmp -> partly cloudy;partlycloudy;partlycloudynight oder eben leicht bewölkt oder so.
Wenn jemand ein Reading auswerten will, dass z.B. ein "12" ausgibt, dann würde das so ebenfalls gehen.
Im Bezug auf den HTTP-Upload stellt sich mir immer noch die Frage, wieviel Speicher denn im ESP noch zur Verfügung steht. Nicht, dass das "Image platzt"...
Von daher wäre vielleicht ein Samba-Share (z.B. auf dem FHEM-Server) oder ein MQTT-Publish eines ganzen Bildes auch ein Ansatz, den man ernsthaft diskutieren sollte. Dafür hängt mein Ar*** aber code-seitig ein bisschen zu weit unten ;-) Ich hab keine Ahnung, was mit Pf@nneOS so alles geht...
OK. Ist natürlich eine Frage, an welche Stelle in dem Wetterinformationsprozess die Schnittstelle für die Auswertung gesetzt wird.
Je früher in dem Prozess solche sehr unterschiedlichen Informationen, die dasselbe meinen standardisiert werden, um so mehr weitere Teilprozesse kann ich mit der eindeutigen Information versorgen.
Daher ist es nicht der allerbeste Absatz, das Abfangen unterschiedlichster Ausdrücke für dasselbe Wetter erst im ESP zu realisieren.
Solche Konstrukte mit Semikolon sind natürlich auch nicht ganz trivial auszuwerten. Aber zum Glück gibt es auch eine Regex-Libraray für den Arduino. Damit könnte es funktionieren.
Wie ich geschrieben hatte, überträgt das Upload-Modul der IDE ja auch das bin-File. Und das hat im Moment etwas über 3 MB. Also zumindest in dem 12E-Modul kann von Speicherknappheit noch nicht die Rede sein. ;-)
Und wie versprochen, habe ich jetzt die aktualisierte Version von Pf@nnes ESP8266_Basic an meinen Post von gestern Abend angehängt. Dafür werde ich mir mal eine Versionierung einfallen lassen müssen. Im Moment steht immer noch V 0.200 unter den WebTabellen.
Also ich krieg Deinen Sketch nicht an's Laufen. Er kompiliert und flasht zwar wunderbar, aber nach dem Neustart des ESP's hab ich nur eine wie wild blinkende LED und einen schwarzen Bildschirm. Das WebIf ist leider auch nicht erreichbar...
--edit--
Hab grad nochmal geflasht und gesehen dass das Flöashen mit folgender Meldung endet:
Ungültige Bibliothek C:\Programme\Arduino\libraries\arduino-esp8266fs-plugin-master in C:\Programme\Arduino\libraries\arduino-esp8266fs-plugin-master gefunden
--edit's edit--
Ich Vollpfosten. Hab natürlich vergessen Arduino IDE neu zu starten... Nun bootet er durch.
Hallo tomster
Wenn Du etwas Zeit hast, würde ich Dich gern bitten wollen, dass Du Dich mal mit dem Font für die kleinen Schrift (Datum, Zeit, Überschriften etc. ) beschäftigst.
Ich habe das Sketch so umgebaut, dass Du das Ergebnis des Tools DotFactory direkt nutzen kannst. Am besten Du ersetzt nur den Bereich im Array - also alles zwischen { und }; .
Im Anhang findest Du die Version V 0.31 des Sketches und einen Screenshot, wie ich das Tool momentan eingestellt habe.
Getestet habe ich mit Roboto 14pts. Mir gefällt aber die Umsetzung des Tools nicht. Die Zeichen stehen teilweise am rechten oder linken Rand der genutzten Breite. Das führt dazu, dass zwischen den Zeichen unregelmäßige Lücken enstehen.
Vielleicht findest Du eine Einstellung, mit der eine konstante Laufweite umsetzbar ist.
Das Template ESP8266_Basic ist unverändert.
Vielen Dank für Deine Unterstützung
wingfighter
Aktuelle Version auch hier=> https://github.com/wingfighter/ESP8266_OLED_NHD-1.69-160128UGC3 (https://github.com/wingfighter/ESP8266_OLED_NHD-1.69-160128UGC3)
Hab grad ein bissl mit den Schriftarten gespielt. Dummerweise ist mir nun auch mein anderes Display fast abgekackt. Das hat plötzlich soviele schwarze Streifen, dass man die Schriften nicht mehr vernünftig erkennen kann. Ich denke, ich muss die Dinger ertsmal einschicken um weiter testen zu können...
Ich habe mir am Sonntag zwei neue bestellt. Sind heute per UPS angekommen. ;-)
Ich mir vorsichtshalber heute nachmittag auch ;-)
So, Displays sind gestern auch gekommen. Jetzt sieht's wieder fein aus. Allerdings verstehe ich jetzt Deine Aussage mit den unregelmäßigen Lücken zwischen den Buchstaben.
Nachdem ich den Sketch über Nacht durchlaufen hab lassen ist mir aber gerade aufgefallen, dass der Screen-Aufbau stellenweise "schlampig" erfolgt.
Ich hab dann beim Wechsel der Screens noch Artefakte vom vorhergehenden Screen. Das ist dann zwar spätestens beim nächsten Wechsel wieder weg, aber dennoch.
Am Wochenende versuch ich Mal mit den Schriftarten ein bisschen zu Probieren.
Hmm, irgendwas passt da wirklich noch nicht...
Ich bekomme mit dem Tool noch nicht einmal die gleiche Ausgabe wie Du hin. Wenn ich Deine Einstellungen verwende und eine 14pt Roboto-Font "codieren" lasse, dann sind meine Zeichen nur 19 Zeilen hoch. Deine 20. Damit stimmt natürlich auch das Mapping überhaupt nicht mehr...
Mach ich da was falsch?
Im Übrigen bekomme ich https://github.com/wingfighter/ESP8266_OLED_NHD-1.69-160128UGC3/tree/master/NHD-1.69-160128UGC3_WebConfigLib_ESP8266 nicht kompiliert. Er mosert immer wegen einer ungültigen Bibliothek in der arduino-esp8266fs-plugin-master Library.
Bibliothek Arduino-Temperature-Control-Library-master in Version 3.7.6 im Ordner: C:\Programme\Arduino\libraries\Arduino-Temperature-Control-Library-master wird verwendet
exit status 1
Fehler beim Kompilieren.
Ungültige Bibliothek C:\Programme\Arduino\libraries\arduino-esp8266fs-plugin-master in C:\Programme\Arduino\libraries\arduino-esp8266fs-plugin-master gefunden
Ungültige Bibliothek C:\Programme\Arduino\libraries\arduino-esp8266fs-plugin-master in C:\Programme\Arduino\libraries\arduino-esp8266fs-plugin-master gefunden
Was spräche eigentlich dagegen, die Ziffern als Images zu hinterlegen? Ich werde das Gefühl nicht los, dass die Wetter-Icons deutlich "sauberer" aufgelöst wirken, als die Schriftarten...
Hallo tomster
Den Fehler kann ich nicht genau nachvollziehen. Diese Library gibt es an der Stelle bei mir auch nicht.
Wenn Du die Daten aus GitHub verwendest, hast Du sicher die ESP8266_Basic-Dateien auch wieder in das libraries-Verzeichnis kopiert. Die habe ich nur wegen der Versionszugehörigkeit in dem Unterverzeichnis abgelegt.
Ich weiß, GitHub möchte eigentlich eine ReadMe haben. Das werde ich gelegentlich nachholen. ;-)
Du kannst die Arrays, die das Tool erzeugt, auch nicht ganz 1:1 verwenden. Darum hatte ich empfohlen, nur die Inhalte der Arrays (In der Version auf GitHub sind die in Datei Font.h ausgelagert) zu kopieren. Dann sollten aber zumindest die korrekte Metrik aus dem zweiten Array gelesen werden. Auch wenn die Position der Ziffern auf dem Display nicht ganz mittig ist, weil die Höhe nicht passt.
Bezüglich des Bildaufbaus habe ich eigentlich inzwischen überall Bereichslöschungen eingebaut, damit keine Pixel stehen bleiben. Ich hatte in einer der letzten beiden Versionen bei der Anzeige der per MQTT übertragenden Werte noch einen Fehler, der dazu geführt hat, dass das Display mit Zufallspixeln gefüllt wurde und des Sketch neu startet. Das ist zumindest in der Version auf GitHub behoben. Und im Post vom 25.04. sollte auch die korrekte Version liegen.
In dem Zusammenhang hätte ich eine Bitte.
Bei vielen Threads werden die aktuellen Dateien im ersten Post hinterlegt, weil jemand, der sich für ein Thema interessiert, immer dort anfängt zu lesen und im Zweifel auch nach neuen Versionen sucht.
Kannst Du Deinen Beitrag eventuell mal editieren und ein paar Screenshots und den Link zu GitHub dort hinterlegen?
Die unterschiedliche Darstellung zwischen den Wetter-Icons und der Schrift rührt übrigens daher, dass in den Bildern sehr viel mehr Farbabstufungen verwendet werden. Das führt am Rand der Symbole zum Antialiasing-Effekt. Daher sind dort keine Treppenstufen zu erkennen. Die Buchstaben werden ja digital Bit für Bit auf das Display geschrieben. Bit an oder Bit aus. Und da macht sich im Randbereich der Treppeneffekt bemerkbar.
Natürlich kann man die Zeichen auch als BMP hinterlegen. Wenn man in PS beim Text Antialiasing einstellt, werden im Randbereich Graustufen verwendet. Und dann sehen die Zahlen sicher schöner aus.
Ich werde das mal testen.
Gruß wingfighter
Klar, ich hab die Library an die richtige Stelle kopiert. Das IDE jammert ja auch nicht wegen dieser Lib, sondern anscheinende wegen dem FileSystem-Plugin. Ich glaub ich schmeiß das IDE Mal runter und installiere von vorne. Vielleicht wäre das auch gleich der richtige Moment um eine Art Howto zu schreiben ;-)
Vielleicht löst das auch ein paar Probleme, die mir heute aufgefallen sind:
Zumindest bei mir (auf einem Wemos D1 mini) ist weder Port 80 noch 81 per Browser erreichbar.
Testweise hab ich auch probiert das clear-icon.bmp mit dem ESP8266FS-Tool gegen ein BMP-File mit Text auszutauschen. Eben wegen dem Anti-Aliasing. Leider zeigt er dann nur einen schwarzen Screen an.
Ich kann zwar auch wunderbar mit den "gepixelten" Fontsets leben (kann ja locutus auch: https://forum.fhem.de/index.php/topic,52403.msg443552.html#msg443552 ), aber eine Überlegung sind die Graphiken sicher wert.
Wenn wir beispielsweise ein Feld für die Überschrift auf jeder Seite mit z.B. 32x160 Pixel festlegen würden, dann kann man eben diesen Teil selbst nach Belieben Photoshoppen und Hochladen (z.B. Display_1_Header.bmp). Dann kann sich jeder seine Schriftart, Farbe oder was auch immer aussuchen.
Die Aufteilung des Screens vertikal könnte dann
32px
64px
32px
aussehen.
Die dynamischen Werte würden dann aus einzelnen Ziffer-BMPs zusammengesetzt. Graphisch sicher die schönere Lösung, wenn auch nicht mehr ganz so flexibel.
Ach ja, den Link zu deinem GIT Repository hab ich im Eingangsthread eingefügt. Ist sicher mehr als sinnvoll.
LG,
Tom
Ich habe mich mal mit der Idee der BMP je Ziffer beschäftigt.
Ich halte das aus zwei Gründen für kein ganz so gute Idee.
Es ist recht aufwändig, für jede Ziffer ein BMP zu bauen. Das Bild muss dann eine weiße oder farbige Ziffer auf schwarzem Grund haben. Dabei muss das schwarz dem des Displays entsprechen, sonst erkennt man die Kante des Bildes. Das ist z.B. bei dem Wind-Symbol der Wetter-Icons zu erkennen.
Möchte jemand einen farbigen Hintergrund, wird es mit der Gleichheit der Bild- und Displayfarbe noch schwieriger.
Zudem wird der Bildaufbau langsamer, weil die BMP's bei jeder Anzeige-Runde aus dem Speicher geladen werden müssen.
Das zweite Argument ist die Auflösung unseres Sehvermögens.
Der Mensch hat eine Winkelauflösung von einer Bogenminute. Das sind 0,0167°. Daraus ergibt sich, dass er bei einem Betrachtungsabstand von z.B. 30cm Punkte mit einem Abstand von 0,087mm erkennen kann. Unser Display hat in der Senkrechten genau ein Zoll. Bei 128 Pixeln ergibt das einen Abstand von 0,19mm.
Wenn man das umrechnet, kommt man auf 0,68 m, ab der man keine einzelnen Pixel mehr erkennt. Die Treppenstufen erkennt allerdings man aus einem größeren Abstand, weil die aus 2-3 Pixeln bestehen.
Und nun hängt es natürlich vom Anwendungsfall ab, ob man das Display üblicherweise aus einer kleineren Entfernung abliest oder eben doch eher vom Sofa aus. ;-)
Und: Es kann auch nicht jeder mit PhotoShop oder ähnlichen Grafikprogrammen umgehen um sich seine individuellen Zeichen zu bauen.
Ansonsten habe ich auch mal versucht, die Übergänge zwischen den Anzeigen etwas weicher zu gestalten. Aber da speilt das Display nicht mit. Man kann die Helligkeit des Displays über drei Register steuern. Aber sie verändert sich nicht linear bis Null, sondern bleibt bis zum Wert 1 (von 255) recht hoch und schaltet dann auf aus. Ein softes FadeIn und FadeOut gelingt damit leider nicht. Eventuell gibt es aber dafür noch andere Register. Da muss ich mir die Doku noch einmal anschauen.
@tomster
Warum das Wemos D1 mini nicht per Port 80 oder 81 erreichbar sein soll, verstehe ich allerdings nicht. Den der Kern des Boards ist ja auch ein ESP8266. Und in dem läuft der Sketch und wird das W-Lan gesteuert.
Ich hab' mir mal so ein MiniModul bestellt. Passt sicher besser hinter das Display. Vielleicht kann ich den Effekt nachvollziehen.
Ich habe mal eine aktualisierte Version V 0.32 auf github hoch geladen.
- Der roboto Standard Font ist jetzt mit 22 Bit Höhe eingebunden.
- Bei den Einstellungen der einzelnen Screens können jetzt Anzeigedauern in Sekunden vorgegeben werden.
- Wie im vorigen Post beschrieben, habe ich mal testweise das Fading zwischen den Screens eingebaut - beurteilt selbst!
- Kleine Schönheitskorrekturen (u.a. automatisches Zentrieren der blauen Texte).
Gruß wingfighter
Uii, super. Werd ich gleich einmal ausprobieren.
Ich habe übrigens das 1. Posting dieses Threads um ein kleines HowTo erweitert. Das macht es wohl einfacher die einzelnen Libraries zusammenzusuchen.
--edit--
Das Fading fände ich eigentlich ganz gut, aber ist wohl in der Praxis nicht sauber umzusetzen. Ab einem gewissen Wert erfolgt wohl kein Fade mehr, sondern das Dispaly wird schlichtweg schwarz...
Ausserdem kommt es bei mir nach einigen erfolgreichen Screenwechseln plötzlich zum Ausfall der Anzeige mit spontanen Fehlern, respektive "Reboots". Hier Mal ein Auszug aus dem seriellen Monitor:
read config
mounting FS...
mounted file system
reading config file
opened config file
json success
Exception (28):
epc1=0x4000bf3c epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000000 depc=0x00000000
ctx: cont
sp: 3fff95a0 end: 3fff9830 offset: 01a0
>>>stack>>>
3fff9740: 3fff874c 3fffaf88 3fff6950 4020f1cc
3fff9750: 3ffeeb48 00000000 000003e8 40215175
3fff9760: 3fffaf04 3fffaf54 3ffec200 40215175
3fff9770: 3fffaf7c 00000200 3fffa184 402182a0
3fff9780: 3ffef70c 3fff874c 3fff874c 3fff8808
3fff9790: 3fffdad0 3fff874c 3fff6950 4020fe90
3fff97a0: 3ffebae4 3ffef70c 3fff874c 4020eba0
3fff97b0: 00400000 00000002 40215a48 3fff8810
3fff97c0: 4020153a 00000005 00000005 3fff8808
3fff97d0: 3fffdad0 3fff8450 3fff6950 40210131
3fff97e0: 3fffdad0 3fff874c 00000000 40208e49
3fff97f0: feefeffe feefeffe feefeffe feefeffe
3fff9800: feefeffe feefeffe feefeffe feefeffe
3fff9810: 3fffdad0 00000000 3fff8801 40215a8c
3fff9820: feefeffe feefeffe 3fff8810 40100958
<<<stack<<<
ets Jan 8 2013,rst cause:2, boot mode:(3,7)
load 0x4010f000, len 1264, room 16
tail 0
chksum 0x42
csum 0x42
~ld
============================================
Flash real id: 001640E0
Flash real size: 4194304
Flash ide size: 4194304
Flash ide speed: 40000000
Flash ide mode: DIO
Flash Chip configuration ok.
============================================
Dieses Spielchen wirderholt sich dann quasi bis zum Sanktnimmerleinstag. Wenn ich dann den data-Ordner neu flashe funktioniert es wieder ein paar Mal, danach geht es aber wieder in den obigen Loop.
-- edit --
Hab den Sketch testweise auch auf einem nodeMCU geflasht. Nach ein paar Cycles bekomme ich den gleichen Effekt. Der Sketch loopt...
Auch wenn ich nicht glaube, dass es daran liegt möchte ich noch erwähnen, dass ich derzeit kein MQTT-Device auf FHEM angelegt habe. Der Sketch läuft also mit dem Code, ohne dass er Daten von FHEM holt.
Das hatte ich auch ab und zu mal.
Die Fehlermeldung
ets Jan 8 2013,rst cause:2, boot mode:(3,7) sagt aus (http://www.esp8266.com/viewtopic.php?p=2096#p2112 (http://www.esp8266.com/viewtopic.php?p=2096#p2112)), dass Reset betätigt wurde. Das wirst Du sicher nicht in der Häufigkeit tun. ;-)
In verschiedenen Foren habe ich auch gelesen, dass gerade wegen dieses Fehlers über alternative Entwicklungsumgebungen nachgedacht wird. Hier im Forum gibt es dazu auch einen Thread (https://forum.fhem.de/index.php/topic,51356.0.html)
Eventuell löschst Du mal im Temp-Verzeichnis den Ordner, in dem sich die compilierten Daten befinden. Dann übersetzte die Arduino-IDE alle Module neu.
Ich vermute aber eher, dass die Struktur der config.json nicht mehr passt. Ich habe wegen der neu hinzugekommen Felder für die Anzeigedauer einiges an der Struktur geändert.
In der Datei ESP8266_Basic.cpp Zeile 668/669 habe ich das Löschen der vorhandenen config.json eingebaut und auskommentiert.
if (SPIFFS.exists("/config.json")) {
//file exists, reading and loading
Serial.println("reading config file");
// SPIFFS.remove("/config.json");
// return readOK;
File cfgFile = SPIFFS.open("/config.json", "r");
Wenn Du diese Zeilen einkommentierst, das Sketch überträgst und einmal durchlaufen lässt und dann wieder die Zeilen auskommentierst und das Sketch neu überträgst, wird die config.json neu angelegt und enthält alle Variablen, die benötigt werden.
:Fade
Der Übergang von der dunkelsten Darstellung zu schwarz ist übrigens der von 1 zu 0. Dazwischen gibt es leider keine Zwischenschritte. ;-)
Gruß wingfighter
Eigentlich müssten doch sowieso alle Module neu kompiliert werden, da doch beim Ändern des Boards von Wemos -> nodeMCU die Build-Optionen geändert werden, oder?
Ich hab nun Mal die Stellen in der ESP8266_Basic.cpp einkommentiert. Nun scheint es besser zu Laufen. Hab schon seit einigen Minuten keinen Reset mehr.
Leider nur bedingt. Sobald ich versuche per HTTP auf den ESP zuzugreifen kommt es wieder zum Reboot. Wenn auch augenscheinlich dann nur 1 Mal...
Fade:
Klar, dass der letzte Sprung von 1 auf 0 geht. Ich hab mich da wohl ein bissl ungenau ausgedrückt. Das Faden funktioniert von Screen 1 nach 2 nach 3 recht gut (Anzeige der Werte/ des Icons ca. 6 Sekunden von Fade in->Fade out. Von 3 zurück nach 1 kommt es aber zum beschriebenen Effekt. Es fadet aus bis schwarz (da ist der plötzliche Sprung am Ende) und braucht dann deutlich länger, bis wieder Screen 1 angezeigt wird (~ 12 Sekunden).
Stimmt, wenn Du das Board wechselt, sollte er eh alles neu compilieren.
Du hast nach dem Löschen der config.json aber die beiden Zeilen gleich wieder auskommentiert. Sonst löscht das Sketch beim Aufruf der Webseite die gerade angelegte config.json wieder. ;-)
Und das führt dann zum Absturz.
Witzigerweise kommt es aber mit den einkommentierten Zeilen nur 1 Mal zum Reboot beim Aufruf via HTTP. Danach bleibt der Sketch wieder stabil.
Wenn ich die Zeilen wieder auskommentiere, habe ich wieder den Reboot-Loop...
Ich hab auch spaßeshalber Mal einen älteren Stand (aber schon mit Pf@nne-OS) geflasht. Damit kann ich problemlos auf das WebUI zugreifen...
--edit--
Ach ja, und es scheint sich etwas dauerhaft am Sketch zu Ändern nach dem Aufrufversuch des GUIs , da ich auch bei einem PowerDown nach dem Auftreten des Bootloops wieder in den Bootloop gerate. Erst ein Neuflashen der data-Partition schafft Abhilfe...
Ich bilde mir auch ein, dass ich den Zeitpunkt des "Abkackens" besser bestimmen kann. Der Reboot passiert genau wenn der 3.Screen, also das BMP ausfaded und man zuvor auf das WebGUI zugreifen wollte. Man kann problemlos den Zugriffsversuch starten, wenn die 3 Screens angezeigt werden. Spätestens aber nach dem 3. Screen ist Essig mit dem Sketch.
OK. Ich habe gerade mal einen anderen nodeMCU genommen, auf dem ich vor einiger Zeit mal das Sketch getestet habe. Dort liegen definitiv alte Daten drauf. Und dann stürzt das Sketch genau an derselben Stelle ab wie bei Dir.
Es hat also etwas mit der alten FS-Struktur zu tun.
Aber auch dafür gibt's eine Zeile (657) in besagter Datei:
//clean FS, for testing
SPIFFS.format();
Damit wird natürlich das gesamte FS platt gemacht. Aber das führt zumindest in meiner Testumgebung zum Erfolg.
Hmm, ich kann zwar das FS platt machen, aber alsbald ich den Sketch danach wieder mit auskommentiertem "FS-platt" und der Data-Partition flashe, lande ich wieder im Bootloop...
Und das Sketch stürzt gleich beim Start an derselben Stelle ab, die Du in Post #116 beschrieben hast? Also nach "json success"?
Tausche mal bitte die Datei aus dem Anhang aus und poste das Ergebnis aus dem seriellen Monitor.
--edit--
Hab nochmal alle Libs deinstalliert und von Vorne angefangen. Der Sketch stürzt zwar auch mit der neuen ESP8266_Basic.cpp an der gleichen Stelle ab.
Aber nur 1 Mal = kein Loop:
============================================
Flash real id: 001640E0
Flash real size: 4194304
Flash ide size: 4194304
Flash ide speed: 40000000
Flash ide mode: DIO
Flash Chip configuration ok.
============================================
read config
mounting FS...
mounted file system
reading config file
opened config file
json success
cfgFile close...
cfgFile closed.
fsMount OK and File exist
mounting FS...for MyFile
mounted file system
MyFile does not exist
Connecting WiFi to: SSID
..........
WiFi connected with IP: 192.168.0.34
Starting UDP
Local port: 2390
with %p: cfg = 3fff78b5
with %p: cfg = 3fff78b5
with %p: MyOLEDDisplay = 3fff775c
with %p: oled = 3fff775c
Start WEB-Server
HTTP server started
Config:
########################################
WEBcfg Username: ESPuser
WEBcfg Password: ESPpass
----------------------------------------
AP SSID: ESP8266_13915244
AP Password: ESP8266config
----------------------------------------
WiFi SSID: SSID
WiFi Password: passwd
DHCP IP: 192.168.0.34
----------------------------------------
MQTT-Server IP:
MQTT-Server Port: 1883
MQTT-DeviceName: ESP8266_13915244
----------------------------------------
Update-Server IP:
FilePath:
########################################
sending NTP packet...
packet received, length=1073710956
HTTP FSBrowserServer started
FS File: /clear-icon.bmp, size: 27.05KB
FS File: /clear-night-icon.bmp, size: 27.05KB
FS File: /clouds-icon.bmp, size: 27.05KB
FS File: /clouds-night-icon.bmp, size: 27.05KB
FS File: /edit.htm.gz, size: 4.02KB
FS File: /favicon.ico, size: 1.12KB
FS File: /few-clouds-icon.bmp, size: 27.05KB
FS File: /few-clouds-night-icon.bmp, size: 27.05KB
FS File: /freezing-rain-icon.bmp, size: 27.05KB
FS File: /graphs.js.gz, size: 1.92KB
FS File: /hail-icon.bmp, size: 27.05KB
FS File: /index.htm, size: 3.63KB
FS File: /many-clouds-icon.bmp, size: 27.05KB
FS File: /showers-day-icon.bmp, size: 27.05KB
FS File: /showers-icon.bmp, size: 27.05KB
FS File: /showers-night-icon.bmp, size: 27.05KB
FS File: /showers-scattered-day-icon.bmp, size: 27.05KB
FS File: /showers-scattered-night.bmp, size: 27.05KB
FS File: /snow-icon.bmp, size: 27.05KB
FS File: /snow-rain-icon.bmp, size: 27.05KB
FS File: /snow-scattered-day-icon.bmp, size: 27.05KB
FS File: /snow-scattered-icon.bmp, size: 27.05KB
FS File: /snow-scattered-night-icon.bmp, size: 27.05KB
FS File: /storm-day-icon.bmp, size: 27.05KB
FS File: /storm-icon.bmp, size: 27.05KB
FS File: /storm-night-icon.bmp, size: 27.05KB
FS File: /sunny-icon.bmp, size: 27.05KB
FS File: /Wind-Flag-Storm-icon.bmp, size: 27.05KB
FS File: /config.json, size: 913B
### MQTT has disconnected...
Connecting to MQTT-Broker: :1883
sending NTP packet...
packet received, length=48
Seconds since Jan 1 1900 = 3671196927
Unix time = 1462208127
The MEZ time is 16:55:27
02.05.2016
Sommerzeit
!new Time set
Yahoo WeatherCode: 99
mounting FS...for BMPFile
mounted file system
reading BMPfile: /sunny-icon.bmp
### MQTT has disconnected...
Connecting to MQTT-Broker: :1883
Yahoo WeatherCode: 99
mounting FS...for BMPFile
mounted file system
reading BMPfile: /sunny-icon.bmp
incomming Callback, config has changed!!
Config:
########################################
WEBcfg Username: ESPuser
WEBcfg Password: ESPpass
----------------------------------------
AP SSID: ESP8266_13915244
AP Password: ESP8266config
----------------------------------------
WiFi SSID: SSID
WiFi Password: passwd
DHCP IP: 192.168.0.34
----------------------------------------
MQTT-Server IP:
MQTT-Server Port: 1883
MQTT-DeviceName: ESP8266_13915244
----------------------------------------
Update-Server IP:
FilePath:
########################################
saving config
Exception (29):
epc1=0x4000e1b2 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000000 depc=0x00000000
ctx: sys
sp: 3ffffd70 end: 3fffffb0 offset: 01a0
>>>stack>>>
3fffff10: 00000000 3fff5790 00000300 40100705
3fffff20: 0437ce2c 3fff5790 3fff41a0 40107448
3fffff30: 015143f4 3fff54b4 3fff99ec 4021da22
3fffff40: 40105930 00000000 4021dee2 00000008
3fffff50: 4023080c 00000000 4021df8f 3fff4254
3fffff60: 3fff5790 40237965 3fff5768 3fff5790
3fffff70: 40237965 60000600 3ffeff88 40237965
3fffff80: 402379aa 3fffdab0 00000000 3fffdcb0
3fffff90: 3fff57b8 3fffdad0 3fff8828 40215a1b
3fffffa0: 40000f49 40000f49 3fffdab0 40000f49
<<<stack<<<
ets Jan 8 2013,rst cause:2, boot mode:(3,7)
load 0x4010f000, len 1264, room 16
tail 0
chksum 0x42
csum 0x42
~ld
============================================
Flash real id: 001640E0
Flash real size: 4194304
Flash ide size: 4194304
Flash ide speed: 40000000
Flash ide mode: DIO
Flash Chip configuration ok.
============================================
read config
mounting FS...
mounted file system
reading config file
opened config file
json success
cfgFile close...
cfgFile closed.
fsMount OK and File exist
mounting FS...for MyFile
mounted file system
MyFile does not exist
Connecting WiFi to: SSID
..........
WiFi connected with IP: 192.168.0.34
Starting UDP
Local port: 2390
with %p: cfg = 3fff78b5
with %p: cfg = 3fff78b5
with %p: MyOLEDDisplay = 3fff775c
with %p: oled = 3fff775c
Start WEB-Server
HTTP server started
Config:
########################################
WEBcfg Username: ESPuser
WEBcfg Password: ESPpass
----------------------------------------
AP SSID: ESP8266_13915244
AP Password: ESP8266config
----------------------------------------
WiFi SSID: SSID
WiFi Password: passwd
DHCP IP: 192.168.0.34
----------------------------------------
MQTT-Server IP:
MQTT-Server Port: 1883
MQTT-DeviceName: ESP8266_13915244
----------------------------------------
Update-Server IP:
FilePath:
########################################
sending NTP packet...
packet received, length=1073710956
HTTP FSBrowserServer started
FS File: /clear-icon.bmp, size: 27.05KB
FS File: /clear-night-icon.bmp, size: 27.05KB
FS File: /clouds-icon.bmp, size: 27.05KB
FS File: /clouds-night-icon.bmp, size: 27.05KB
FS File: /edit.htm.gz, size: 4.02KB
FS File: /favicon.ico, size: 1.12KB
FS File: /few-clouds-icon.bmp, size: 27.05KB
FS File: /few-clouds-night-icon.bmp, size: 27.05KB
FS File: /freezing-rain-icon.bmp, size: 27.05KB
FS File: /graphs.js.gz, size: 1.92KB
FS File: /hail-icon.bmp, size: 27.05KB
FS File: /index.htm, size: 3.63KB
FS File: /many-clouds-icon.bmp, size: 27.05KB
FS File: /showers-day-icon.bmp, size: 27.05KB
FS File: /showers-icon.bmp, size: 27.05KB
FS File: /showers-night-icon.bmp, size: 27.05KB
FS File: /showers-scattered-day-icon.bmp, size: 27.05KB
FS File: /showers-scattered-night.bmp, size: 27.05KB
FS File: /snow-icon.bmp, size: 27.05KB
FS File: /snow-rain-icon.bmp, size: 27.05KB
FS File: /snow-scattered-day-icon.bmp, size: 27.05KB
FS File: /snow-scattered-icon.bmp, size: 27.05KB
FS File: /snow-scattered-night-icon.bmp, size: 27.05KB
FS File: /storm-day-icon.bmp, size: 27.05KB
FS File: /storm-icon.bmp, size: 27.05KB
FS File: /storm-night-icon.bmp, size: 27.05KB
FS File: /sunny-icon.bmp, size: 27.05KB
FS File: /Wind-Flag-Storm-icon.bmp, size: 27.05KB
FS File: /config.json, size: 913B
### MQTT has disconnected...
Connecting to MQTT-Broker: :1883
sending NTP packet...
packet received, length=48
Seconds since Jan 1 1900 = 3671196998
Unix time = 1462208198
The MEZ time is 16:56:38
02.05.2016
Sommerzeit
!new Time set
Yahoo WeatherCode: 99
mounting FS...for BMPFile
mounted file system
reading BMPfile: /sunny-icon.bmp
### MQTT has disconnected...
Connecting to MQTT-Broker: :1883
Yahoo WeatherCode: 99
mounting FS...for BMPFile
mounted file system
reading BMPfile: /sunny-icon.bmp
Zwei Dinge verwundern mich jedoch:
Zum Einem dass da "MyFile does not exist" steht und zum Anderen, dass ein Icon mit verstümmeltem Dateinamen "FS File: /showers-scattered-night-icon.bm?8l, size: 27.05KB" angegeben wird. Ich hab nun einfach Mal den langenen Dateinamen gekürzt.
Ach, ich blick's gar nicht mehr. Jetzt hab ich wieder einen Bootloop, wenn ich nach dem ersten Reboot durch das Aufrufen der Seite KEINEN eigen-angestossenen Reboot mache, sondern einfach nach dem Sketch-seitigen nochmal das WebGUI aufrufen möchte.
Eine Frage aber noch:
Als ich Deinen ersten Pf@nne-OS Sketch geflasht hatte, musste ich mich beim Erststart in das ESP-eigene WLAN einloggen um die Credentials meines WLANs eingeben zu können. Seither, auch nach zig-fachem Reflashen anderer Versionen muss ich das nicht mehr tun. Irgendwo "merkt" sich der ESP scheinbar diese Einstellungen. Kann es sein, dass da Bereiche des Flashs auch durch Neuflashen gar nicht gelöscht werden?
Hallo tomster
Der Gesamtflash ist in diverse Bereiche aufgeteilt. In einem läuft das aktuelle Sketch , in einem zweiten wird die per OTA-Update hochgeladene bin-Datei gespeichert, bis sie sauber übertragen wurde um erst dann den Flash-Vorgang zu starten und in einem weiteren befindet sich das Filesystem.
Beim Flashen wird nur der erste Bereich überschrieben. Daher bleiben alle anderen Daten erhalten. Wen Du eine neue Config erzwingen möchtest, musst Du also per SPIFFS.format(); das Filesystem löschen.
Da die eine Dateiendung mit Datenmüll aufgefüllt war, habe ich die Vermutung, dass hardwareseitig irgend etwas nicht stimmt. Eventuell ist die Spannung einfach nur instabil. Es wird ja in vielen Foren empfohlen, einen 10 µF-Elko parallel zur Stromversorgung zu schalten. Vielleicht kannst Du aber auch mal einen anderen USB-Port testen
Da ja inzwischen an den verschiedensten Stellen Fehler auftauchen, deutet das auf einen softwareunabhängigen Fehler hin.
Ich habe eine meinem Testboard auch eine zweite Sannungsversorgung nur für das Display hängen. Der nodeMCU wird über USB versorgt. (http://www.amazon.de/dp/B00KNRD3HM/ref=cm_sw_em_r_mt_dp_nw7jxb16D4EEE (http://www.amazon.de/dp/B00KNRD3HM/ref=cm_sw_em_r_mt_dp_nw7jxb16D4EEE))
Die Meldung "MyFile does not exist" ist übrigens normal. Pf@nne hat in seinem Template eine Datei vorgesehen, in der man eigene Variablen sichern kann. Die nutze ich aber zurzeit nicht. Daher diese Fehlermeldung.
Gruß wingfighter
Moin,
freut mich, dass ihr das Template so fleißig nutzt obwohl es bisher ja nur alpha-Status hat... 8)
Nach einer Anpassung des cfg-Umfangs lade ich die neuen Files immer einzeln hoch.
Dann sollte es wieder passen.
SPIFFs Upload
https://forum.fhem.de/index.php/topic,50238.msg446856.html#msg446856 (https://forum.fhem.de/index.php/topic,50238.msg446856.html#msg446856)
Weiterhin viel Erfolg...
Moin
Das hat bis jetzt bei mir immer dazu geführt, dass auch das gerade übersetzte Binary mit hochgeladen wurde. Zumindest sah das danach aus. Es hat aber 3,4MB und dauert entsprechend lange.
Ich habe für das java-Applet auch keine Config gefunden, in der man das abstellen könnte.
Man kann es ini den Quellen sicher auskommentieren. Aber das Java-Applet dann neu zu übersetzen setzt wieder eine Menge Arduino-IDE-KnowHow voraus. ;-(
Viele Grüße aus WL
Zitat von: wingfighter am 02 Mai 2016, 22:19:36
Daher bleiben alle anderen Daten erhalten. Wen Du eine neue Config erzwingen möchtest, musst Du also per SPIFFS.format(); das Filesystem löschen.
Nope. Auch ein einkommentiertes SPIFFS.format() löscht den Flashspeicher anscheinend nicht völlig. Die Credentials und meine SSID bleiben erhalten. Ich denke daher, dass wohl "nur" der /data-Bereich gelöscht wird. Ich habe auch Mal probiert den ESP nach dieser Anleitung (http://www.s6z.de/cms/index.php/homeautomation-homecontrol/hardwareplattformen/esp8266/131-loeschen-des-gesamten-flashspeichers) zu Löschen. Auch dabei bleiben die Credentials erhalten. Die müssen also in irgendeinen vom Flashen "verschonten" Bereich geschrieben werden...
Zitat
Da die eine Dateiendung mit Datenmüll aufgefüllt war, habe ich die Vermutung, dass hardwareseitig irgend etwas nicht stimmt.
Ich hatte einfach die Vermutung, dass es an der Zeichenanzahl des Dateinames gelegen hat. Du schreibst ja im Sketch explizit "// Weather icons 30 Dateien, max 30 Zeichen". Zumindest mit der Dateiendung komme ich bei der Datei aber auf 32 Zeichen... Und wenn ich bei der Datei im Namen einfach das "-icon" weglasse, bleibt der Dateiname auch unkorrumpiert.
Zitat
Eventuell ist die Spannung einfach nur instabil. Es wird ja in vielen Foren empfohlen, einen 10 µF-Elko parallel zur Stromversorgung zu schalten. Vielleicht kannst Du aber auch mal einen anderen USB-Port testen
Hab ich bereits. Auch wenn ich ein Netzteil von meinem Raspi (3A) verwende reagiert der Wemos/ Display zumindest optisch (dann hab ich ja keinen seriellen Monitor) genau gleich: Es bleibt schwarz und die LED am Wemos blinkt wie wild.
Zitat
Da ja inzwischen an den verschiedensten Stellen Fehler auftauchen, deutet das auf einen softwareunabhängigen Fehler hin.
Ich habe eine meinem Testboard auch eine zweite Sannungsversorgung nur für das Display hängen. Der nodeMCU wird über USB versorgt. (http://www.amazon.de/dp/B00KNRD3HM/ref=cm_sw_em_r_mt_dp_nw7jxb16D4EEE (http://www.amazon.de/dp/B00KNRD3HM/ref=cm_sw_em_r_mt_dp_nw7jxb16D4EEE))
Und genau hier denke ich ein bisschen anders. Wenn ich den Pf@nne'schen Sketch (unter Beibehaltung deines geänderten ESP8266_Basic-Ordners) flashe, dann kann ich problemlos auf das Webinterface zugreifen und auch Änderungen in den Inputfields für die (=Deine) Displaykonfiguration machen. Ich tippe daher auf einen Bug in einer Abfrageroutine/ Korrumpierung in den data-Bereich. Diese Vermutung stütze ich mehrheitlich auf die Erkenntnis, dass das Auftreten des Reboot-Loops ja "persistent" ist. Sprich, auch nach der Trennung der Stromversorgung/ Wiedereinschalten springt der Sketch sofort in den Reboot-Loop. Wenn ich aber den /data-Bereich per SPIFFS-Tool aus Arduino heraus neu flashe, läuft der Sketch wieder. Zumindest bis zum nächsten Versuch das WebGUI aufzurufen.
Zitat
Die Meldung "MyFile does not exist" ist übrigens normal. Pf@nne hat in seinem Template eine Datei vorgesehen, in der man eigene Variablen sichern kann. Die nutze ich aber zurzeit nicht. Daher diese Fehlermeldung.
Überredet. Dann ignoriere ich diese Meldung einfach geflissentlich ;-)
ZitatNope. Auch ein einkommentiertes SPIFFS.format() löscht den Flashspeicher anscheinend nicht völlig. Die Credentials und meine SSID bleiben erhalten. Ich denke daher, dass wohl "nur" der /data-Bereich gelöscht wird. Ich habe auch Mal probiert den ESP nach dieser Anleitung zu Löschen. Auch dabei bleiben die Credentials erhalten. Die müssen also in irgendeinen vom Flashen "verschonten" Bereich geschrieben werden...
Ja, das ist so. Es wird definitiv nur der Bereich gelöscht, in dem sich das File-System befindet, sonst würde ja das Sketch auch gelöscht werden. ;-)
Als ich mich mit dem ESP8266 begonnen habe zu beschäftigen, habe ich auch irgendwo gelesen, dass die WIFI-Login-Daten in einem separaten Bereich gespeichert werden, der von allen Löschaktionen verschont bleibt. In dem Text stand auch, wie man die Zugangsdaten löschen kann. Die Quelle habe ich aber nicht parat. Vielleicht findest Du über diesen Effekt etwas über Google.
ZitatWenn ich den Pf@nne'schen Sketch (unter Beibehaltung deines geänderten ESP8266_Basic-Ordners) flashe, dann kann ich problemlos auf das Webinterface zugreifen
Ich habe in meiner aktuellen Version eine kleine Änderung vorgenommen, die die Erreichbarkeit des Webinterfaces - zumindest im AP-Modus - erleichtert.
Die vielen Anzeigepausen zwischen den Screens verhindern ein schnelles Abarbeiten der void loop(){}-Schleife. Daher werden Webanfragen nur sehr zäh beantwortet.
Für die Erstkonfiguration nutze ich jetzt ein Flag, was Pf@nne setzt, wenn sich der ESP im AP-Konfig-Modus befindet, um das Aufbauen und anzeigen der Screens zu unterdrücken.
Für den Normalbetrieb hatte ich vor einiger Zeit auch schon versucht eine Lösung zu finden, wie man den Screenwechsel solange deaktiviert, wie man über die Web-Konfig Daten bearbeitet. Man muss diese Aktivitäten aber definitiv durch eine Aktion beenden, sonst kann das Sketch nicht wissen, wann es die Displays wieder anzeigen darf.
Und beim momentanen Aufbau der Anzeige-Schleife bleibt dem Webinterface nicht wirklich viel Zeit, die Anfragen entgegen zu nehmen.
Darum läuft der Aufruf der Webseite schon bisweilen in den Timeout.
Vielleicht ist es ein Lösungsansatz, das Display per MQTT in den Konfigurationsmodus zu versetzen. Und wenn man "Configuration speichern" klickt, wird das Config-Flag wieder zurück gesetzt.
ZitatWeather icons 30 Dateien, max 30 Zeichen". Zumindest mit der Dateiendung komme ich bei der Datei aber auf 32 Zeichen...
OK: Das sollte ich mal abfangen. ;-)
V0.33 hochgeladen.
Ich habe den Schwuppdizität der Configurations-Websites verbessert. Damit sollten ungeduldige Browser nicht mehr in einen Timeout laufen.
Leider funzt der Sketch bei mir in doppelter Hinsicht nicht. Ich bekomme keine Anzeige mehr auf dem Display und der Aufruf des WebGUIs endet immer noch in einem Reboot...
Die Anzeige ist solange deaktiviert bis die Konfiguration im AP-Mode abgeschlossen ist. Damit wird die Bedienung der Webseiten beschleunigt.
Welche IDE verwendest Du eigentlich? Ich nutze die 1.6.8.
Hast Du alle Libraries immer auf dem aktuellen Stand?
Es muss ja irgend einen Unterschied geben. Hm?
Ich mache heute Nachmittag mal eine bin-Datei fertig und sende Sie Dir per PM.
Vielleicht kannst Du sie mal per OTA-Update einspielen. Dann können wir eingrenzen, ob die Probleme von der Hardware oder der IDE kommen.
Welches ESP-Board muss ich dann einstellen?
Zitat von: wingfighter am 04 Mai 2016, 10:55:41
Die Anzeige ist solange deaktiviert bis die Konfiguration im AP-Mode abgeschlossen ist. Damit wird die Bedienung der Webseiten beschleunigt.
Jetzt nochmal langsam, zum mitdenken.
Da die Credentials ja ohnehin auf dem ESP gespeichert bleiben, lande ich doch gar nicht im AP-Mode.
Sprich, der Sketch müsste doch dann gleich in den "Normalmodus" gehen, oder?
Leider startet der Sketch nach dem Versuch des Aufrufs des GUIs einmalig neu. Wenn ich danach nochmals versuche das GUI zu erreichen, dann endet der Sketch im Reboot-Loop.
Dann hilft nur noch das Neuflashen.
ZitatWelche IDE verwendest Du eigentlich? Ich nutze die 1.6.8.
Ich hab die 1.6.7
ZitatHast Du alle Libraries immer auf dem aktuellen Stand?
Deine sowieso, und all diejenigen, die in der Bibliothekverwaltung als aktualisierbar angegeben waren auch.
ZitatIch mache heute Nachmittag mal eine bin-Datei fertig und sende Sie Dir per PM.
Vielleicht kannst Du sie mal per OTA-Update einspielen. Dann können wir eingrenzen, ob die Probleme von der Hardware oder der IDE kommen.
Welches ESP-Board muss ich dann einstellen?
Ich frage mich allerdings, wie ich das bin-File OTA updaten soll, wenn ich gar nicht auf das GUI komme...
Zur Verfügung hab ich hier WEMOS D1 mini und nodeMCU. Ich teste die Sketche immer auf beiden. Somit sollten die darauf verbauten ESP's
-EX und
12E Modelle sein.
Zitatder 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.
ZitatIch 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.
ZitatIch 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.
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*
Na das klingt doch schon mal gut.
Ich hab' Dir eine PM hinterlassen ;-)
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.
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?
Zitat von: wingfighter am 05 Mai 2016, 12:03:26
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:
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);
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:
ZitatOder 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
Zitat von: wingfighter am 06 Mai 2016, 17:15:29
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!
ZitatThe 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.:
anAlle/Wetter/MontagDieses Topic wird dann in jedem Client abboniert.
Weiterhin viel Spaß!
Gruß
Pf@nne
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?
Zitat von: wingfighter am 06 Mai 2016, 21:50:26
Deine Idee würde aber so nicht in das Template-Konzept passen.
Die subscribe´s können generell frei definiert werden.
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
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
Zitat von: wingfighter am 06 Mai 2016, 17:15:29
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:
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?
Zitat von: wingfighter am 09 Mai 2016, 00:27:04
- 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.
Zitat
@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 ;-)
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:
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
"Läääuuuft!"
Und wie! */me ist restlos begeistert, beeindruckt, dankbar und schlichtweg geplättet*
Die näxten Biers gehen auf mich!
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?
Ich hatte zumindest mit dem aktuellen Sketch seit 24h+ noch keinen Pixelfehler o.Ä. gesehen. Von daher gehe ich schon davon aus, dass ein gewisser Entwicklungsstand erreicht ist. Auch wenn ich persönlich die Dezimalstellen bei den Luftfeuchtewerten gerne weglassen wollte ;-)
Was ich allerdings noch zur Diskussion stellen möchte, ist welche Einstellungen vom User vorgenommen werden können (Farben, Layout, etc.) Ich denke wir beide wünschen uns, dass das Projekt auch von möglichst vielen anderen genutzt/ umgesetzt wird.
Entweder wir schreiben ich schreibe ein HowTo/ WiKi wie man die jeweiligen Einstellungen im Sketch verändert, oder wir passen das WebGUI entsprechend an. Ersteres ist IMHO dann der bessere Weg wenn wir erreichen wollen, dass sich der User ein gewisses "Hintergrundwissen" über den Aufbau des Sketches aneignen soll. Wenn dann der Sketch noch in der Form strukturiert und kommentiert ist, als dass man getrennte Bereiche für die unterschiedlichen Screens hat, dann glaube ich sind wir maximal flexibel aufgestellt.
Man könnte im Sketch ja vielleicht zunächst gewisse Variablen setzen. So á la:
// HEX-Farbcodierungen im Format 0xBGR
#define RED 0x0000FF
#define MAGENTA 0xFF00FF
#define GREEN 0x00FF00
#define BLUE 0xFF0000
#define WHITE 0xFFFFFF
#define BLACK 0x000000
#define YELLOW 0x00FFEE
#define ORANGE 0x00A5FF
#define GREY 0xD3D3D3
#define DefaultHeaderColor ORANGE
#define DefaultValueColor GREY
#define DefaultFooterColor GREY
Eventuell macht es auch Sinn ein zusätzliches "Template-File" (so wie bei der Font) anzulegen, in dem man das Layout angeben kann und welches am Rechner editiert/erstellt werden kann und dann hochgeladen wird.
In meinem speziellen Fall muss ich eh noch ein bissl am Layout schrauben, weil ich schon versuchen möchte möglichst nahe an das Layout meiner Mock-Ups zu kommen. Dazu müssen natürlich mehrere MQTT-Werte in einem Screen untergebracht werden...
Was meinst?
Die Auswahl der Farben für die Layoutdarstellung hatte ich mir auch noch vorgenommen. Das geht ja relativ einfach über Dropdownboxen im WebGui. Damit kann man zumindest das Blau und Gelb einstellen.
Eine komplett freie Layoutgestaltung mit Platzhaltern halte ich aber für recht anspruchsvoll. So eine Seitenbeschreibung - z.B. in XML - muss ja dann durch einen Parser geschickt werden um zumindest mal Variablen zu erkennen und diese durch interne Werte zu ersetzen.
Was wir natürlich noch umsetzen können, sind die kleinen Wettericons auf den Screens, auf denen Werte angezeigt werden. Dann kann man eventuell über die WebGui noch entscheiden, was dort angezeigt wird, und ob dann die 5-Tages-Vorschau-Screens noch dargestellt werden sollen.
Aber: Man muss immer den Arbeitsspeicher im Auge behalten. Alle Werte die der Benutzer individuell anpassen können soll, müssen zur Laufzeit in Variablen gehalten werden. Außerdem ist auch die HTML-Seite der WebGui eine große Variable. Jede Erweiterung vergrößert deren Speicherbedarf. Und der Bereich des Variablenspeicher liegt momentan bei 80% Auslastung. Diese Variablen in die config.json wegzuschreiben (außer die WebGui-Seiten), stellt sicher kein Problem dar. Der Bereich für das Filesystem ist groß genug.
Zitat von: wingfighter am 11 Mai 2016, 12:35:41
Eine komplett freie Layoutgestaltung mit Platzhaltern halte ich aber für recht anspruchsvoll. So eine Seitenbeschreibung - z.B. in XML - muss ja dann durch einen Parser geschickt werden um zumindest mal Variablen zu erkennen und diese durch interne Werte zu ersetzen.
Ich dachte auch nicht zwangsläufig an etwas XML-mäßiges, sondern quasi "nur" den Screen-Teil in ein eigenes File auszulagern. Quasi wie ein Skin-Template. Der geneigte User kann dann eigene Templates erstellen, oder eben einfach ein von anderen Usern erstelltes Design hochladen.
Anpassen muss er es ohnehin, weil ja die in die Skin integrierten Wertefelder wohl bei jedem anders aussehen. Also rein Klickibunti
soll's wird's nicht werden.