WordClock V2
Die erste Version meiner selbst gebauten WordClock wurde von einem Arduino Nano V3 befeuert und funktioniert dank der Vorarbeiten der Forumsmitglieder einwandfrei.
Ich habe dann den Fehler gemacht, die Uhr herumzuzeigen, was darin mündete, dass ich weitere Wort-Uhren bauen musste - Jeder der das Teil sah, wollte ebenfalls eins haben.
Da ich ziemliche Probleme mit den in der Arduino-Version verbauten Echtzeituhr-Modulen und den DCF77-Empfängern hatte, bin ich für die weiteren Ausgaben der Uhr auf die Version von Manuel Bracher (bracci) umgestiegen, die als Hirn eine NodeMCU-Platine bzw. den “ESP8266 D1 mini” einsetzt.
Da ich weiterhin die auch bei der Arduino-Version verwendeten LED-Stripes einsetzen wollte und die Front des Display aufgrund der Einschränkungen meiner CNC-Fräse nicht größer als 23 x 23 cm sein durfte, passte eine normale NodeMCU- oder WEMOS D1 mini-Platine nicht ins Konzept - genaugenommen nicht in den Rahmen.
Die zuerst als Alternative ins Auge gefassten ESP-01-Module sind zwar schön klein und sehr preiswert, haben aber leider keinen Analogeingang für die Helligkeitsregelung.
Bleibt zu erwähnen, dass selbst diese Winzlinge die
Firmware der QlockWiFive problemlos verarbeiten, wenn die Parameter in der Firmware passend eingestellt werden. Die automatische Helligkeitsregelung ist allerdings nicht möglich, meine Versuche, den A0-Pin direkt am IC
abzugreifen sind ins Leere gelaufen. Man kommt mit Hobbymitteln nicht an den Anschluss heran um dort einen Draht anzulöten.
Aktualisierung
Der ESP-01 kann einen I²C-Anschluss zur
Verfügung stellen, über den ein passender “Ambient Light Sensor”, der BH1750, für die Helligkeitsregelung angesprochen werden kann. Somit ist die Realisierung einer WordClock mit ESP-01 ebenfalls möglich.
Die nächst größeren ESP8266-Module am Markt, ESP-12E, sind schmal genug um in den verfügbaren Platz zu passen und stellen alle notwendigen Anschlüsse zur Verfügung, meine WordClock wird also auf einem ESP-12E basieren.
Dafür habe ich einen weiteren Adapter entworfen, der eingangsseitig pinkompatibel zum ESP-01-Programmieradapter ist und ansonsten als Breadboard für einen ESP-12E dient, dessen IOs - soweit frei nutzbar - auf Pins geführt sind. Zusätzlich sind noch für den Betrieb des ESP-12E notwendige PullUp- und PullDown-Widerstände sowie der Spannungsteiler-Widerstand für den LDR der WordClock implemetiert. Der LDR ist zwischen VCC (+3,3 V) und dem Pin 5 am Stecker SV2 anzuschließen.
(Click auf das Bild für größere Darstellung)
Das Board ist einseitig entflochten, es sind lediglich 2 Brücken notwendig. Um das Board so schmal wie möglich auslegen zu können, habe ich das Layoutsymbol des ESP-12
geändert, so dass die asymmetrisch angelegten Pads nach innen statt nach außen zeigen. Auf diese Weise konnte ich die Breite der Platine auf etwas über 20 mm beschränken, was noch in den Rahmen meiner WordClock hinein passt.
(Click auf das Bild für größere Darstellung)
Die vier Lötpads am oberen Rand der Platine sind in der Standardausführung der WordClock unbenutzt. Wird ein RTC-Modul DS3231 angeschlossen, erfolgt die
Zuführung des SQW-Signals über den Eingang GPIO13, das Lötpad ganz links in der Reihe. Diese Verwendung des SQW-Signals ist in der Bracci Standard-Firmware nicht enthalten.
Die bei der WordClock benutzten Anschlüsse sind auf den einreihigen Stecker links geführt - im Wesentlichen der Data-Ausgang für die LED-Stripes und der Analogeingang für den LDR. Daneben liegen hier die Anschlüsse für 3,3 V, GND sowie zwei nicht verwendete GPIO (GPIO4 und GPIO5) des ESP8266. Hier könnten z.B. ein Piezo -Lautsprecher und ein IR-Empfänger Anschluss finden, was aber in meiner Version der Firmware nicht berücksichtigt ist. Genauso kann über diese beiden Anschlüsse der I²C Bus nach außen geführt werden, um beispielsweise die RTC-Backupfunktion zu realisieren. Das ist notwendig, wenn die Uhr nicht permanent WLAN Zugang hat.
Programmiert wird der ESP-12E über den links zwischen den beiden Lötbrücken sitzenden 8-poligen Stecker. Der Programmieradapter wird über ein 8-poliges Kabel “Stecker auf Buchsen” am WordClock Board angeschlossen, dabei ist darauf zu achten, dass die Signale Rx und Tx überkreuz verbunden werden müssen. Alle andere Leitungen werden 1:1 verbunden.
Die Widerstände sind SMD-Typen und sitzen auf der Unterseite der Platine.
Die Schaltunterlagen im EAGLE Format sind hier bereit gestellt.
nota bene
Für den Betrieb des ESP-12E müssen bestimmte Pins des Chip auf bestimmte Potentiale gelegt werden.
Eine sehr übersichtliche Darstellung der den Bootvorgang betreffenden Pins am ESP8266 und weitere Informationen bzgl. Nutzung dieser Pins im eigenen Programm habe ich bei Forward Computing and Control gefunden.
Die Tabelle - angelehnt an die Darstellung bei Forward Computing and Control - der beim Bootvorgang und im Betrieb berücksichtigten Pins hier auf die Schnelle:
Man sieht, CH_PD und GPIO2 müssen zum Betrieb des Moduls immer auf High-Potential, GPIO15 immer auf Low-Potential gezogen werden - jeweils vorzugsweise über einen
Widerstand von z.B. 10 kΩ. GPIO0 entscheidet, ob vom Flash gebootet oder das Flash neu programmiert werden soll.
Die Widerstände für den Betriebsfall, also booten aus dem Flash, sind in der oben dargestellten Schaltung enthalten. Das Herunterziehen von GPIO0 zum Flashen erledigt der Programmieradapter.
Da die WordClock mit ESP keine Bedienelemente am Gehäuse benötigt - alle Einstellungen können über das WEB-Interface vorgenommen werden - habe ich die Front ohne Löcher für die Sensor-LEDs ausgeführt, alle anderen Eigenschaften entsprechen der ersten Version mit Arduino.
Die Bedienung ist natürlich vollkommen anders, weshalb ich hier eine auf meine Firmware-Version abgestimmte Anleitung zur Verfügung stelle. Auf Funktionen, die in der Firmware prinzipiell enthalten sind und per Compiler-Schalter ein- oder ausgeschaltet werden können, in meiner Version aber nicht enthalten sind, gehe ich nicht ein.
Hinweis
Nach einigen Monaten in Betrieb hat meine WordClock angefangen, unmotiviert zu
blitzen und zu flackern, meist dann, wenn sich die Raumhelligkeit verändert hat, aber auch zwischendurch ohne erkennbaren Anlass.
Einen Wackelkontakt konnte ich nach eingehender Untersuchung ausschließen. Andere
WordClocks mit identischem Aufbau funktionieren klaglos, es muss also an meiner Uhr liegen.
Letztlich stellte sich die Versorgungsspannung als Ursache für das Problem heraus.
Der ESP-12E wird in meiner Uhr durch ein StepDown Schaltnetzteil versorgt, dessen
Ausgangsspannung mit einem winzigen Poti eingestellt werden muss. Bei meinem Modul war die Spannung auf 3,28 V eingestellt. Nach Justierung der Spannung auf 3,32 V war
das Geflacker weg. Meine Empfehlung: Spannung auf 3,3 .. 3,5 V einstellen.
Das eigentliche Problem ist hierbei nicht die Betriebsspannung für den ESP sondern das zu niedrige High-Potential am Eingang des mit 5 V betriebenen LED-Stripe. Die erste LED hat schlichtweg den High-Pegel nicht sicher als Solchen erkannt.
Achtung, das Poti ist ziemlich schlecht zu bedienen und sein Wert ändert sich beim Bedienen teilweise sehr sprunghaft, auch gerne mal über die zulässigen 3,6 V hinaus. Es empfiehlt sich also, den ESP während des Einstellvorgangs von der Spannungsversorgung zu trennen.
Wer hier auf Nummer Sicher gehen will, nimmt lieber StepDown-Wandler die mit folgendem Suchstring in ebay zu finden sind: “Mini Buck Converter DC-DC 12-24V To 5V 3A”. Diese Module haben neben dem Poti noch eine Reihe Festwiderstände an Bord, mit denen sich konkrete Spannungen durch setzen eines Lötpunktes einstellen lassen. Die Verbindung zum Poti wird dafür aufgetrennt.
Aktualisierung
Ich habe bei meinen Wortuhren zwar die Möglichkeit implementiert, bei
OpenWeatherMap (OWM) die Wetterdaten für meinen Wohnort abzurufen und in der GUI anzuzeigen. Allerdings ist der Abruf der Daten synchron implementiert, das heißt,
jede volle Minute wird ein Aufruf an den Server von OWM abgesetzt und dann wird gewartet, bis die Anfrage beantwortet wird. Das dauert im Allgemeinen so acht bis neun
Sekunden. Kein großes Ding für eine Wort-Uhr, deren Display ja sowieso nur einmal in der Minute aktualisiert wird, sollte man meinen. Allerdings passiert die Aktualisierung
des Display und der Abruf - mit 8 Sekunden Pause - zeitgleich zu jeder vollen Minute.
Die Auswirkung ist gut zu sehen, vergleicht man die Anzeige der Wort-Uhr mit einer genau gehenden Uhr: Die Aktualisierung des Wort-Uhr Display erfolgt nicht zum Minutenwechsel, sondern 8 Sekunden später.
Auch hier könnte man sich wieder den Standpunkt zu eigen machen, egal, auf die paar Sekunden kommt es mir nicht an. Nun haben wir aber eine sekundengenaue Uhrzeit vom Internet Zeitserver an der Hand, also wollen wir die Uhr auch sekundengenau anzeigen lassen.
An der Antwortzeit des OWM Servers können wir nichts ändern. Die Firmware der Uhr auf asynchrone Abfrage bei OWM umzubauen wäre eine, wenn auch komplizierte, Möglichkeit.
Die einfachere Alternative ist, die Abfrage bei OWM auf einen Zeitpunkt zu verschieben, wo die verzögerte Antwort keine sichtbare Auswirkung hat.
In der aktuellsten Version der Firmware für die Wort-Uhr ist diese Verschiebung eingebaut.
Aktualisierung
Nach der Aktualisierung des ESP8266 Framework auf Version 3.0.2 lässt sich die
Firmware nicht mehr fehlerfrei übersetzen. Workaround war bisher, das alte Framework V2.7.4 zu verwenden. Thomas hat sich das nicht gefallen lassen und hat die
Lösung gefunden, die ich in die Sourcen eingebracht habe. Vielen Dank Thomas!
Verschiedene Warnungen werden in der aktualisierten Version des Framework schärfer bewertet und als Fehler interpretiert. In der Abfrage der Wetterinformationen bei OWM fehlte in einem Zweig der Rückgabewert. Das ist in der aktuellen Version ebenfalls gefixt.
Aktualisierung
Wie sagte mein Sohn so richtig zuletzt, als er von den Änderungen an der FW erfuhr...
“Never touch a running system”. Er hat ja so recht :)
Worum geht es?
In der letzten Aktualisierung habe ich den Umstieg auf das aktuelle ESP8266 Framework
beschrieben und dafür notwendige Korrekturen in die Firmware eingebracht.
Jetzt stellte sich heraus, dass durch den Umstieg auf das aktuelle Framework ca. 660 Fehler und über 400 Warnungen impliziert werden, die den Compiler zwar nicht davon abhalten, lauffähige Binaries zu erzeugen (???), die aber durch Inkompatibilitäten an verschiedenen Schnittstellen Funktionen der Uhr blockieren. Z.B. werden die Einstellungen, die über die Settings Seite der GUI erfolgen, nicht im EEPROM gespeichert. Andere Probleme sind ebenfalls möglich, das habe ich nicht weiter untersucht. Ich habe meine Umgebung wieder auf das nachweislich funktionierende Framework mit der Version V2.7.4 zurück gesetzt, jetzt läuft wieder alles wie vorgesehen. Die weiter oben beschriebenen Änderungen an den Sourcen konnten drin bleiben.
Aktualisierung
Tom setzt die Wort-Uhr in USA ein, folglich sollen Temperatur und andere Parameter in
der GUI auch in den landessprachlichen Einheiten angezeigt werden. Hier gab es neben Ungereimtheiten in der Darstellung auch krasse Fehler im Aufbau des HTML Code. Das ist in der aktuellen Firmware gefixt.
Zusätzlich hat sich im Laufe der Implementierung der Temperaturanzeige herausgestellt, dass es weltweit noch 19 Länder gibt, die Temperaturangaben - mindestens im Zusammenhang mit Wetterdaten - in Fahrenheit machen. Wer sich dafür näher interessiert findet hier Einzelheiten.
Für die Wort-Uhr ergibt sich daraus Bedarf für Erweiterungen. Der Aufruf an OWM muss zum einen die Information mitbringen, welches Maßsystem die gelieferten Werte berücksichtigen sollen, zum anderen muss die Landessprache festgelegt werden, in der die textuellen Angaben zum Wetter auszugeben sind.
Hier ein Beispiel für Deutschland:
Die Einheiten °C, relative Feuchte und hPa sowie die Beschreibung der aktuellen Wettersituation werden in der Firmware zusammengesetzt.
Für einen Ort in den USA sieht die Darstellung so aus:
Die Temperatur wird in °F (Fahrenheit) angegeben, der Luftfeuchte in % RH (percent relative humidity) und der Luftdruck in mbar.
Eine zusätzliche Hürde ergab sich, da die Wort-Uhr auch die Möglichkeit bietet, die Außentemperatur in großen Lettern auf dem Display darzustellen. Zwei Zahlen sind kein Problem, das ist so schon seit Beginn implementiert. Bei Angaben in Fahrenheit kann es aber durchaus vorkommen, dass der Temperaturwert dreistellig wird. 100 °F entsprechen etwa 38 °C, was in bestimmten Landstrichen in USA durchaus erreicht und überschritten wird. Um die drei Stellen anzeigen zu können, habe ich die Darstellung in diesem Fall als Laufschrift realisiert, wie das schon seit Längerem auch für den letzten Block der IP-Adresse der Uhr gilt, der kurz gezeigt wird, wenn die Uhr bootet.
Dass im Fall von dreistelligen Temperaturen das Pluszeichen nicht mehr dargestellt werden kann ist zu verschmerzen, denn man kann im allgemeinen davon ausgehen, dass dreistellige Fahrenheitwerte bei Lufttemperaturen im positiven Bereich liegen. Im negativen Temperaturbereich wird es erst dreistellig, wenn die Temperatur unter - 73 °C absinkt. In diesem Fall hätten wir ganz andere Probleme als ein fehlendes Vorzeichen auf dem Display der Wort-Uhr.
Hat die Wort-Uhr auch ein RTC Modul (Real Time Clock) oder einen Temperatur- und Luftfeuchtesensor DHT22, eingebaut, wird auch die Raumtemperatur in der GUI angezeigt:
Das Haus steht für Innentemperatur, der Baum deutet “außen” an.
Aktualisierung
Mich hat von Anfang an gestört, dass meine Wort-Uhren in den Laufschriften der Events
keine deutschen Umlaute darstellen können. Den Zeichengenerator einfach erweitern, so dass die deutschen Umlaute des erweiterten ASCII Zeichensatzes inklusive sind,
verbietet sich aus Platzgründen im Speicher, also habe ich nur die Definitionen für die sieben zusätzlichen Zeichen hinten angehängt und in der Routine zur Darstellung der
Laufschriften eine kleine Wandlung für die in Frage kommenden Zeichen implementiert.
for (byte k = 0; k < strLength; k++)
{
actCharTmp = str2disp[k];
// deutsche Umlaute zurecht rücken // deHarry, 2024-05-15
// Die Umlaute hängen als Block ab 0x7F direkt hinter den darstellbaren ASCII Zeichen
// und müssen für die Darstellung auf dem Display transponiert werden
switch (actCharTmp)
{
case 0xE4: actChar = 0x7f; break; // ä (siehe Letters.h)
case 0xF6: actChar = 0x80; break; // ö
case 0xFC: actChar = 0x81; break; // ü
case 0xDF: actChar = 0x82; break; // ß
case 0xC4: actChar = 0x83; break; // Ä
case 0xD6: actChar = 0x84; break; // Ö
case 0xDC: actChar = 0x85; break; // Ü
default: actChar = actCharTmp; break; // alle anderen Zeichen normal durchreichen
}
...
Zusätzlich mussten die deutschen Umlaute auch in der Routine zur Eingabe der Texte in der GUI freigeschaltet werden. In den Settings werden die Texte wie eingegeben gespeichert, die Transformation erfolgt ausschließlich für die Ausgabe auf dem Display.
Jetzt ist auch die Gratulation auf Deutsch möglich - “Herzlichen Glückwunsch!” ;)
Aktualisierung
Kürzlich wurde ich darauf angesprochen, dass die Wetterinformationen von
OpenWeatherMap nicht mehr in der GUI der Uhr erscheinen und dass sich die API geändert habe. Eine intensive Untersuchung des Problems ergab, dass offenbar nur keine Spaces mehr im location String des Aufrufs erlaubt sind.
“Karlsruhe, DE” wird also von der API abgelehnt, “Karlsruhe,DE” wird akzeptiert.
Die Firmware ist jetzt dahingehend erweitert, dass eventuell eingegebene Spaces vor der Speicherung in den Settings entfernt werden. Die Umwandlung auf Großbuchstaben ist schon länger drin.
Wer möchte kann seinen Standort auch per Longitude und Latitude Werten festlegen, dazu muss das Define LONLAT in der Datei Configuration.h, Zeile 16, aktiviert werden. Damit die Magie mit den Einheiten (°C/F) und textuellen Ausgaben (wolkig/cloudy) in der GUI weiterhin passt, muss zusätzlich zu den Lon und Lat Werten der Ort und das Landeskürzel in den Settings unter Location eingetragen sein. Passende Lon/Lat Werte kann man über Google Maps erhalten oder man nutzt die entsprechende API von OWM. Für diesen Dienst gilt der vorhandene ApiKey, der auch für die Wetterdaten der Uhr benutzt wird.
Aktualisierung
Nach einer umfassenden Aktualisierung aller Libraries und Boards Definitionen im Zuge
des Umstiegs von Arduino V1.8 auf Arduino V2.3 ließ sich die QlockWiFive Firmware nicht mehr fehlerfrei übersetzen. Von einer früheren solchen Katastrophe wusste ich
noch, dass die ESP Boards Platform nicht neuer als V2.7.4 sein darf. Der Rückschritt auf diese Version war diesmal allerdings nicht ausreichend, ich musste zusätzlich die FastLED
Library zurück auf V3.7.0 patchen. Diese Informationen habe ich jetzt im Sourcecode hinterlegt.
Tipp
Boards Definitionen und Libraries lassen sich in der Arduino IDE V2.x sehr einfach und übersichtlich anpassen/austauschen.
Ãœber “Type Updatable” findet man schnell in unserem Fall die Version 2.7.4 für den ESP
und für die FastLED Lib die Version 3.7.0
Weiterhin habe ich der Uhr ein vom Namen QlockWiFive abgeleitetes Favicon spendiert:
Die 5 ist im Browser leider kaum zu erkennen, aber wenn man’s weiß... ;)
Die jeweils aktuelle Firmware findet ihr auf der WordClock Seite.
Ich möchte nochmals ausdrücklich darauf hinweisen, dass die Firmware für meine WordClock ursprünglich von Manuel Bracher stammt und von mir nur für meine Zwecke angepasst und erweitert wurde.
Besucher seit
25.11.2000