Das Konzept der Sendung war damals recht einzigartig: Die Zuschauer konnten den kleinen Troll in kurzen Spielchen mit den DTMF-Tastentönen ihrer Telefon von Zuhause steuern. Auf dem Bildschirm sahen sie dann das Ergebnis ihrer Tastendrücke. Heute durch die stark unterschiedlichen Laufwege und -zeiten moderner TV-Verbreitungswege undenkbar – und auch damals schon nicht immer ganz problemlos.

Egal, vier Jahre lief das Ganze. Und ich wollte gerne mitspielen, hatte aber nie das Glück durchzukommen. Das plagt mich bis heute, wie ich auch in meiner Podcast-Episode zu Hugo kundtat. In der Episode gehe ich noch ein bisschen genauer auf das Spiel, die Sendung und die Produktion ein.

Pad One, Please! Der nächste Retro-Podcast

#005: Hugo trollt TV und Games

Play Episode Pause Episode

Mute/Unmute Episode Rewind 10 Seconds 1x Fast Forward 30 seconds

00:00 / 14:03

Amazon Apple Podcasts Deezer RSS Spotify

RSS Feed

Teilen

Link

Embed

Nun gibt es aber ja seit einer ganzen Weile Arduino- und ESP-Boards, mit denen man famose Dinge erschaffen kann wenn man dem Thema etwas Zeit widmet. Und da ich hier noch ein altes Telefon der Deutschen Bundespost rumfliegen habe, was den Retro-Charackter der Aktion nur noch weiter verstärkt, habe ich mich dran gemacht aus dem Telefon ein viel zu großes Numpad zu bauen, mit dem auch gleich noch Hugo Spielen kann.

Teileliste

Viel braucht es für dieses Projekt nicht, nämlich nur den ESP und das Telefon:

• Retro-Telefon „FeTAp“, hier ein FeTAp 0111 aus 1987
• ESP 32 S3 Zero
• optional: DIY Platine um Kabelwirrwarr zu vermeiden (siehe „Schaltplan“)

Naja gut, und natürlich Schraubendreher, einen Lötkolben und was man zu dessen Verwendung halt so benötigt.

Schaltplan

Damit das Ganze funktionieren kann, muss das Tastenfeld mit dem ESP32 verbunden werden. An dem Tastenfeld des Telefons ist ein kurzes Flachband. Also, genau genommen ist es auf der Platine des Telefons und muss von der befreit werden. Danach müssen folgende Pins entsprechend mit dem ESP32 verbunden werden.

Um es für mich etwas angenehmer zu gestalten, habe ich mir eine kleine Platine dafür gebaut. Ich bin immer noch begeistert für welche schmale Mark man heutzutage selbstgestaltete PCBs produzieren lassen kann. Ich pack hier mal meine Lösung in Form einer Gerber-File hin, mit der eine Nachbestellung möglich ist – Verwendung auf eigene Gefahr:

Funktionsweise

Das kleine ESP-Board ist in der Lage, als HID (Human Interface Device) über USB zu agieren. Damit gibt es sich in diesem Fall sozusagen als Keyboard aus. Drücke ich eine der Tasten auf dem Telefon, so wird ein Tastendruck (Keyboard.press()) ausgelöst, für 80 Milisekunden gehalten und danach wird die Taste wieder „losgelassen“ (Keyboard.release()).

Um den richtigen Tastendruck zu ermitteln, wird das Tastenfall in schnellen Intervallen auf Tastendrücke abgefragt – so wie es das Telefon selbst zuvor auch gemacht hat. Das Tastenfeld ist dabei als eine Art Matrix aufgebaut. Man kann Spannung dabei Zeilen und Reihenweise anlegen. Gebe ich also beispielsweise eine Spannung auf Spalte 2 und Zeile 3, so muss bei Druck der Taste 8 eine Spannung anliegen sofern diese gerade gedrückt wird. So funktioniert im Groben die Erkennung welche Taste gerade gedrückt wird. Simpel aber doch irgendwie faszinierend, wenn ich mir vorstelle in welchem flotten Intervall der ESP da über alle möglichen Konstellationen immer und immer wieder drüber ballert.

Software

Die Software besteht im Wesentlichen aus einer einzigen Datei. Ich entwickle in PlattformIO, entsprechend handelt es sich bei dem Projekt um ein solches. Ihr könnt den Code aber auch in die Arduino IDE kopieren, dann müsste ihr nur dafür sorgen dass ihr die entsprechend für den ESP32 S3 Zero konfiguriert. Außerdem müsst ihr vermutlich das #include <Arduino.h> rausnehmen und dem Sketch eine .ino-Dateiendung geben. Mehr dazu auch in der Readme. Das Projekt könnt ihr auf meinem GIthub-Profil auschecken oder runterladen.

Fazit

Das Projekt hier hat mir wahnsinnig Spaß gemacht. Ich hab keine Ahnung, ob es da draussen wirklich noch andere Verrückte gibt, die sich an sowas erfreuen. Aber falls ja: Hey, schön das du da bist und viel Spaß mit dem Projekt. Wer keine Lust auf basteln hat: Ich habe kürzlich erfahren, dass im Hi-Score in Hannover auch etwas ähnliches für jeden zum ausprobieren und Spielen stehen soll. Diese Werbung hier ist absolut freiwillig und unbezahlt, ich finde in der Retro-Community muss man zusammenhalten und gute Ideen teilen.

Und wenn ihr das Projekt mal umgesetzt haben solltet: Ich würde mich super über Rückmeldung freuen. Viel Spaß beim Zocken!

+ relativ günstig
+ kompakt
+ überschaubarer Stromverbrauch
+ optional mit GPS und Bluetooth
+ USB-Anschluss für schnellere Datenübertragung

– min. 5 V Versorgungsspannung (SIM800L lief auch mit 3.7 V)
– Status LED ungenau (moniert nicht verbunden zu sein, obwohl Daten gesendet und empfangen werden)

Videoanleitung

Hardware

Für mein Test-Setup verwende ich ein ESP32-WROOM-32D-Board. Andere Boards sind möglich. Ich verwende dieses Board aufgrund der Hardware-Serial, über die die Kommunikation zwischen ESP und A7670E-LTE-Modem läuft. Die Beschriftung auf dem Modem ist ein bisschen unübersichtlich. Auf meinem Board von oben nach unten:
G: GND, R: RXD, T: TXT, K: PWRKEY, V: VCC, G: GND, S-SLEEP

Für mein Setup genügt es, vom ESP TX/RX über Kreuz zu verbinden: Also: TX vom ESP auf RX vom Modem und umgekehrt. Außerdem teilen sich ESP und A7670E einen Ground. Das wars dann aber auch. Ich hatte zwischenzeitlich einen 2200μF-Kondensator verbaut, bis ich gesehen habe das genau für diesen Zweck bereits ein 4700μF-Kondensator auf dem Modem verbaut ist. Trotzdem kackte das Modem beim Einbuchen ins LTE-Netz ab und an ab – die Stromversorgung scheint da aber wohl dann nicht der Grund gewesen zu sein?!

Software

Getestet wurde das hier mit dem A7670E-Modul. Allerdings sollten die meisten Sketches auch mit anderen Boards von SIMCom funktionieren, sofern sie den gleichen Befehlssatz unterstützen.

Basis Sketch

Um es auch für Einsteiger verständlich zu halten, teile ich die einzelnen Funktion in kleine Snippets auf. So könnt ihr euch das raussuchen, was für euer Szenario am besten passt. Diese basieren auf folgender Basis, die zunächst nichts weiter macht als die Kommunikation mit dem A7670E sicherzustellen und die Antworten des Moduls im Serial Monitor euer (Arduino-)IDE anzuzeigen.

#include <Arduino.h>

#define RX_PIN 17 // RX-Pin des ESP-Boards
#define TX_PIN 16 // TX-Pin des ESP-Boards
HardwareSerial modem(2);

void setup() {
  Serial.begin(115200);

  delay(1000);
  Serial.println("Serial connection ready");

  modem.begin(115200, SERIAL_8N1, RX_PIN, TX_PIN);
  modem.println("AT"); // AT = Attention, Modem muss mit "OK" antworten
}

void loop() {
  while (modem.available()) {
    String resp = modem.readStringUntil('\n');
    resp.trim();
    if (resp.length() > 0) {
      Serial.println("Modem: " + resp); // Jede Antwort des Modems in der Serial gekennzeichnet ausgeben
    }
  }
}

Serial connection ready
Modem: AT
Modem: OK

Mobilfunkstatus Sketch

Um zu prüfen, ob das A7670E-Modul mit dem Mobilfunknetz verbunden ist, können wir es einfach selbst fragen.

#include <Arduino.h>

#define RX_PIN 17
#define TX_PIN 16
HardwareSerial modem(2);

void setup() {
  Serial.begin(115200);

  delay(1000);
  Serial.println("Serial connection ready");

  modem.begin(115200, SERIAL_8N1, RX_PIN, TX_PIN);
  modem.println("AT");
}

void loop() {
  while (modem.available()) {
    String resp = modem.readStringUntil('\n');
    resp.trim();
    if (resp.length() > 0) {
      Serial.println("Modem: " + resp);
    }
  }

  static unsigned long lastRun = millis() - 18000;
  if (millis() - lastRun > 20000) { // Nach 2 Sekunden alle 20 Sekunden aktualisieren
    lastRun = millis();

    modem.println("AT+CSQ");      // Signalstärke
    modem.println("AT+CEREG?");   // LTE Netzregistrierung
    modem.println("AT+CGATT?");   // Datenregistrierung
    modem.println("AT+CGACT?");   // PDP Kontext aktiv? (Datenverbindung)
    modem.println("AT+CGPADDR");  // IP-Adresse
    modem.println("AT+NETOPEN?"); // Socket-Service Status
  }
}

Modem: AT+CSQ
Modem: +CSQ: 26,99
Modem: OK
Modem: AT+CEREG?
Modem: +CEREG: 0,1
Modem: OK
Modem: AT+CGATT?
Modem: +CGATT: 1
Modem: OK
Modem: AT+CGACT?
Modem: +CGACT: 1,1
Modem: +CGACT: 8,1
Modem: OK
Modem: AT+CGPADDR
Modem: +CGPADDR: 1,10.76.56.42
Modem: +CGPADDR: 8,0.0.0.0,254.128.0.0.0.0.0.0.194.209.178.131.245.194.29.154
Modem: OK
Modem: AT+NETOPEN?
Modem: +NETOPEN: 0
Modem: OK

+CSQ: 26,99: 26 ist die Signalqualität, Skala 0-31, 26 = ziemlich guter Empfang
+CEREG: 0,1: Erfolgreich im LTE-Netz eingebucht
+CGATT: 1: Datenverbindung aktiv
+CGACT: 1,1 & +CGACT: 8,1: Zwei Datenkontexte offen
+CGPADDR: 1,10.76.56.42
+CGPADDR: 8,0.0.0.0,254.128.0.0.0.0.0.0.194.209.178.131.245.194.29.154: IP-Adressen, die das Board erhalten hat

Ping Sketch

Ein grundlegender Test von Netzwerk-Kommunikation ist ein „ping“: Ein kleines Datenpaket wird an einen Server gesendet. Kommt das Paket an antwortet der Server und der Nutzer sieht, wie lange das Datenpaket auf Reise war.

#include <Arduino.h>

#define RX_PIN 17
#define TX_PIN 16
HardwareSerial modem(2);

void setup() {
  Serial.begin(115200);

  delay(1000);
  Serial.println("Serial connection ready");

  modem.begin(115200, SERIAL_8N1, RX_PIN, TX_PIN);
  modem.println("AT");
}

void loop() {
  while (modem.available()) {
    String resp = modem.readStringUntil('\n');
    resp.trim();
    if (resp.length() > 0) {
      Serial.println("Modem: " + resp);
    }
  }

  static unsigned long lastRun = millis() - 18000;
  if (millis() - lastRun > 20000) {
    lastRun = millis();

    modem.println("AT+CPING=\"8.8.8.8\",1,4"); // 4 Pings an Google DNS senden
  }
}

Modem: AT+CPING="8.8.8.8",1,4
Modem: OK
Modem: +CPING: 1,8.8.8.8,92,130,114
Modem: +CPING: 1,8.8.8.8,92,40,114
Modem: +CPING: 1,8.8.8.8,92,15,114
Modem: +CPING: 1,8.8.8.8,92,30,114
Modem: +CPING: 3,4,4,0,15,130,40

AT+CPING=“8.8.8.8″,1,4: 8.8.8.8 ist die Ziel-IP-Adresse, 1 steht für IPv4 (2 wäre IPv6), 4 ist die Anzahl der Wiederholungen
+CPING: 1,8.8.8.8,92,130,114: 1: Ping erfolgreich, der vorletzte Wert (hier 130) ist die Laufzeit in ms, die anderen Werte bitte dem Manual entnehmen
+CPING: 3,4,4,0,15,130,40: Zusammenfassung über die 4 Pings

Daten via HTTP abrufen (HTTP GET-Request)

#include <Arduino.h>

#define RX_PIN 17
#define TX_PIN 16
HardwareSerial modem(2);

void setup() {
  Serial.begin(115200);

  delay(1000);
  Serial.println("Serial connection ready");

  modem.begin(115200, SERIAL_8N1, RX_PIN, TX_PIN);
  modem.println("AT");
}

void loop() {
  while (modem.available()) {
    String resp = modem.readStringUntil('\n');
    resp.trim();
    if (resp.length() > 0) {
      Serial.println("Modem: " + resp);
    }
  }

  static unsigned long lastRun = millis() - 18000;
  if (millis() - lastRun > 20000) {
    lastRun = millis();

    modem.println("AT+HTTPINIT"); // HTTP-Service des Modems starten

    
    modem.println("AT+HTTPPARA=\"URL\",http://httpbin.org/get"); // Abzurufende Adresse
    modem.println("AT+HTTPACTION=0"); // 0 = GET, 1 = POST, 2 = HEAD, 3 = DELETE, 4 = PUT

    delay(2500); // Wir gehen davon aus, in 2.5s die Antwort zu erhalten. Vermutlich besser: AT+HTTPACTION auswerten, liefert die Content-Length

    modem.println("AT+HTTPHEAD"); // Ausgabe des Response Headers

    delay(200);

    modem.println("AT+HTTPREAD=99999"); // "Unsaubere Implementierung": Eigentlich AT+HTTPREAD? nutzen um Länge der Antwort zu ermitteln
    modem.println("AT+HTTPTERM"); // HTTP-Service nach Verwendung stoppen
  }
}

Modem: AT+HTTPINIT
Modem: ERROR
Modem: AT+HTTPPARA="URL",http://httpbin.org/get
Modem: OK
Modem: AT+HTTPACTION=0
Modem: OK
Modem: +HTTPACTION: 0,200,255
Modem: AT+HTTPHEAD
Modem: +HTTPHEAD: 226
Modem: HTTP/1.1 200 OK
Modem: Date: Fri, 05 Sep 2025 15:28:01 GMT
Modem: Content-Type: application/json
Modem: Content-Length: 255
Modem: Connection: keep-alive
Modem: Server: gunicorn/19.9.0
Modem: Access-Control-Allow-Origin: *
Modem: Access-Control-Allow-Credentials: true
Modem: OK
Modem: AT+HTTPREAD?
Modem: +HTTPREAD: LEN,255
Modem: OK
Modem: AT+HTTPREAD=99999
Modem: OK
Modem: AT+HTTPTERM
Modem: OK
Modem: +HTTPREAD: 255
Modem: {
Modem: "args": {},
Modem: "headers": {
Modem: "Accept": "*/*",
Modem: "C "origin": "80.187.118.156",
Modem: "url": "http://httpbin.org/get"
Modem: }
Modem: +HTTPREAD: 0

+HTTPACTION: 0,200,255: 0 = Type der Anfrage (GET), 200 = Statuscode des Servers, 255 = Länge der Antwort in Bytes
+HTTPHEAD: 226: Start Ausgabe des Headers, 226 Bytes
+HTTPREAD: LEN,255: Eine Response liegt vor, 255 Bytes
+HTTPREAD: 255: Beginn der Ausgabe des Response bis HTTPREAD: 0

Daten via HTTP senden (HTTP POST, PUT, PATCH)

Im vorangegangenen Beispiel beim Abruf der Daten via HTTP haben wir etwas „gefuttelt“ was die Antworten anging. So haben wir mit delay gearbeitet und gehofft, dass bis dahin eine Antwort da ist. Damit kommen wir jetzt nicht mehr durch. Um den Code weiter lesbar zu halten, habe ich die Logik in einzelne Funktionen aufgeteilt.

#include <Arduino.h>

#define RX_PIN 17
#define TX_PIN 16
HardwareSerial modem(2);

String waitForURC(const char* token, unsigned long timeoutMs = 10000) { // URC: Unsolicited Result Code, Ereignisbasierte Melungen des Modems abfragen. In unserem Fall für die Antwort nach dem POST genutzt
  unsigned long start = millis();
  String buffer;

  while (millis() - start < timeoutMs) {
    while (modem.available()) {
      String line = modem.readStringUntil('\n');
      line.trim();

      if (line.length() > 0) {
        Serial.println("URC: " + line);
      }

      if (line.startsWith(token)) {
        return line;
      }
    }
  }
  Serial.println("Timeout beim Warten auf URC: " + String(token));
  return "";
}

void readHttpResponse() {
  modem.println("AT+HTTPREAD=99999"); // Wir lesen pauschal alles; Hier könnte man auch mit der genauen Zahl an Bytes arbeiten (was sauberer wäre), aber das LTE-Modul liefert nur solange Daten zurück, wie sie vorliegen.
  
  String response;
  unsigned long startTime = millis();

  while (millis() - startTime < 15000) {
    while (modem.available()) {
      String line = modem.readStringUntil('\n');
      line.trim();

      if (line.startsWith("+HTTPREAD:")) continue;
      if (line == "OK") {
        Serial.println("HTTP-Body:");
        Serial.println(response);
        return;
      }

      response += line + "\n";
    }
  }
  Serial.println("Timeout beim Lesen der Response!");
}

void httpPost(const char* url, const char* json) { // Methode speziell für den HTTP POST-Prozess
  modem.println("AT+HTTPINIT");
  modem.printf("AT+HTTPPARA=\"URL\",\"%s\"\r\n", url);
  modem.println("AT+HTTPPARA=\"CONTENT\",\"application/json\""); // Festsetzen des Inhalts auf JSON
  modem.printf("AT+HTTPDATA=%d,5000\r\n", strlen(json)); // Dem Modem mitteilen, dass gleich Daten kommen, die es für die Übermittlung aufzeichnen soll

  String dl = waitForURC("DOWNLOAD", 5000); // Warten bis das Modem mit "DOWNLOAD" antwortet, dann senden unseres JSON
  if (dl.length() > 0) {
    modem.print(json);
    if (waitForURC("OK", 5000).length() == 0) { // Im Anschluss auf die Bestätigung der Übertragung durch das Modem warten
      Serial.println("Modem or connection stuck, too many data sent or check wiring");
      return;
    }
  }

  modem.println("AT+HTTPACTION=1"); // 1 = POST
  String action = waitForURC("+HTTPACTION:", 15000); // Hier optimierter Ablauf: Sobald die Anfrage vom Modem versendet wurde, geht's weiter...

  if (action.length() > 0) {
    int method, status, len;
    if (sscanf(action.c_str(), "+HTTPACTION: %d,%d,%d", &method, &status, &len) == 3) {
      Serial.printf("HTTP Status: %d, Length: %d\n", status, len);

      if (status == 200 || status == 201) { // Status code 200/201 stehen für eine erfolgreiche Anfragen bei POST
        readHttpResponse(); // Auslesen der Antwort in einer eigenen Funktion dafür
      } else {
        Serial.println("Unexpected response");
      }
    }
  }

  modem.println("AT+HTTPTERM");
}

void setup() {
  Serial.begin(115200);

  delay(1000);
  Serial.println("Serial connection ready");

  modem.begin(115200, SERIAL_8N1, RX_PIN, TX_PIN);
  modem.println("AT");
}

void loop() {
  while (modem.available()) {
    String resp = modem.readStringUntil('\n');
    resp.trim();
    if (resp.length() > 0) {
      Serial.println("Modem: " + resp);
    }
  }

  static unsigned long lastRun = millis() - 18000;
  if (millis() - lastRun > 20000) {
    lastRun = millis();
    const char* json = "{\"temperature\":25.3,\"battery_level\":\"83\"}"; // Unsere Daten verpackt in JSON

    httpPost("http://httpbin.org/post", json); // Start des HTTP Post
  }
}

Serial connection ready
Modem: AT
Modem: OK
URC: AT+HTTPINIT
URC: OK
URC: AT+HTTPPARA="URL","http://httpbin.org/post"
URC: OK
URC: AT+HTTPPARA="CONTENT","application/json"
URC: OK
URC: AT+HTTPDATA=41,5000
URC: DOWNLOAD
URC: OK
URC: AT+HTTPACTION=1
URC: OK
URC: +HTTPACTION: 1,200,488
HTTP Status: 200, Length: 488
HTTP-Body:
AT+HTTPREAD=99999

Modem: +HTTPREAD: 488
Modem: {
Modem: "args": {},
Modem: "data": "{\"temperature\":25.3,\"battery_level\":\"83\"}",
Modem: "files": {},
Modem: "form": {},
Modem: "headers": {
Modem: "Accept": "*/*",
Modem: "Cache-Control": "no-cache",
Modem: "Content-Length": "41",
Modem: "Content-Type": "application/json",
Modem: "Host": "httpbin.org",
Modem: "X-Amzn-Trace-Id": "Root=1-68bd430d",
Modem: "url": "http://httpbin.org/post"
Modem: }
Modem: AT+HTTPTERM
Modem: OK
Modem: +HTTPREAD: 0

Dadurch das mit waitForURC auf ein Ereignis warten, verschieben sich hier die Ausgaben ein wenig.
AT+HTTPDATA=41,5000: Unsere zu sendenden Daten sind 41 Bytes lang, Timeout: 5 Sekunden
+HTTPACTION: 1,200,488: Die Übertragung war erfolgreich, 488 Bytes lang ist die Antwort
AT+HTTPREAD=99999: Wir lesen pauschal 99999 Bytes, das Modem liefert aber nur so viel Daten zurück wie vorhanden; Wir hätten hier auch die 488 aus der HTTPACTION-Antwort verwenden können. Das wäre sauberer gewesen, aber in manchen Fällen (bspw. „chunked“-Responses) liegt wieder Wert nicht vor. Wir haben es uns also einfacher gemacht
+HTTPREAD: 488: Beginn der Ausgabe der Antwort des Servers, enthält als Bestätigung unter „data“ das, was wir geposted haben

Besonderheiten bei HTTPS

Das 7670E-Modul ist dazu in der Lage Daten unverschlüsselt über HTTP, als auch verschlüsselt via HTTPS zu übertragen. Im besten Fall ist dazu nicht viel mehr nötig, als in den hier genannten Beispielen auf „http://“ ein „https://“ zu machen. Allerdings steckt der Teufel da gerne im Detail, denn HTTPS ≠ HTTPS.

Hier ein Mini-Exkurs: Werden im Netz Daten verschlüsselt übertragen, kommen dazu unterschiedliche Mechanismen zu tragen. So wird zum einen ein Verschlüsselungsalgorithmus zwischen Client und Server ausgehandelt., heutzutage oft TLS 1.2 oder größer. Neben diesem wird ein passendes Zertifikat benötigt. Gerade wenn es günstig sein soll, wird heute oft Lets Encrypt verwendet – mach ich auch so. Damit die Kommunikation aber wirklich sicher ist, müssen Betriebssysteme, Browser oder eben LTE-Module mit HTTPS-Support aber die Stammzertifikate der Anbieter kennen. Ein weiteres Thema ist Server Name Indication (SNI) in Verbindung mit virtuellen Hosts. Kurz um: Viele Dinge, die entweder eine vermeintlich sichere Verbindung unsicher machen können oder sie erst gar nicht zustand kommen lassen.

Wenn die Übertragung nicht gelingt…

…geht’s an Debugging. Folgende Sachen könnt ihr prüfen:

SNI aktivieren
Das Modul hat zur Laufzeit 8 SSL-Konfiguration im Speicher. Per Default ist da wenig konfiguriert, außer die Art der TLS-Verschlüsselung mit der Gegenseite automatisch ausgehandelt werden soll. Was dabei nicht konfiguriert wird ist Server Name Indication. Das kann aber essentiell sein, nämlich dann, wenn euer Server mit Virtual Hosts arbeitet. Aktiviert SNI vor dem AT+HTTPINIT mit:

modem.println("AT+CSSLCFG=\"enableSNI\",0,1")

SNI wird für den SSL-Kontext „0“ mit „1“ aktiviert. SSL-Kontext 0 ist der erste der genannten 8 möglichen und wird per default verwendet. Um die SSL-Kontext-ID anzupassen, kann man den Befehl AT+HTTPPARA=“SSLCFG“,2 nutzen, wobei hier die 2 symbolisch für die ID des Index steht, also 0-7.

HTTPACTION auswerten
Einen GET-Request starten wir ja mit AT+HTTPACTION=0. Das Modul gibt neben einem „OK“ auch weitere Informationen aus, im besten Fall sowas: +HTTPACTION: 0,200,81
Die 0 steht für die Art der Anfrage (GET), die 200 für den vom Server gesendeten Statuscode und 81 ist die Länge der Antwort. Ist die Antwort nicht erfolgreich, ist interessant was dort statt 200 steht. Eine 706 würden auf Probleme beim Lesen der Antwort hindeuten, aber gleichzeitig bekräftigen, dass der TLS-Handshake zuvor erfolgreich war, während eine 715 eben genau auf Probleme bei ebendiesem hinweisen würden. In dem Fall müsste man prüfen, ob der verwendete TLS-Standard auf deinem Server von dem LTE-Modul überhaupt unterstützt wird.

HTTP-Header auslesen
Mit AT+HTTPHEAD lässt sich nach dem Absenden der Anfrage der Antwort-Header auslesen. Hier können auch Hinweise auf das Problem aufgeführt sein, wenn man Glück hat. Das oben angesprochene SNI-Problem könnte beispielsweise hier benannt werden.

HTTPS GET Beispiel Sketch

Die oben genannte Punkte sind in diesem Beispiel berücksichtig, welcher bei mir erfolgreich funktionierte.

#include <Arduino.h>
 
#define RX_PIN 17
#define TX_PIN 16
HardwareSerial modem(2);


String waitForURC(const char* token, unsigned long timeoutMs = 10000) {
  unsigned long start = millis();
  String buffer;
 
  while (millis() - start < timeoutMs) {
    while (modem.available()) {
      String line = modem.readStringUntil('\n');
      line.trim();
 
      if (line.length() > 0) {
        Serial.println("URC: " + line);
      }
 
      if (line.startsWith(token)) {
        return line;
      }
    }
  }
  Serial.println("Timeout beim Warten auf URC: " + String(token));
  return "";
}


void setup() {
  Serial.begin(115200);
 
  delay(1000);
  Serial.println("Serial connection ready");
 
  modem.begin(115200, SERIAL_8N1, RX_PIN, TX_PIN);
  modem.println("AT");

  
}
 
void loop() {
  while (modem.available()) {
    String resp = modem.readStringUntil('\n');
    resp.trim();
    if (resp.length() > 0) {
      Serial.println("Modem: " + resp);
    }
  }
 
  static unsigned long lastRun = millis() - 18000;
  if (millis() - lastRun > 20000) {
    lastRun = millis();
 
    modem.println("AT+CSSLCFG=\"enableSNI\",0,1"); // SNI für SSL config ID 0 aktivieren
    
    modem.println("AT+HTTPINIT");
    
    modem.println("AT+HTTPPARA=\"URL\",https://phil.cossnet.de/lte_modul_test.html"); // Kleine selbstgehostete Test-HTML-Datei
    modem.println("AT+HTTPACTION=0");
 

    String response = waitForURC("+HTTPACTION", 5000); // Auf Antwort warten, offenbar dauert es bei HTTPS länger als bei HTTP
    if (response.length() > 0) {
      modem.println("AT+HTTPHEAD");
      modem.println("AT+HTTPREAD=99999");
    }
 
    delay(200);
    modem.println("AT+HTTPTERM");
  }
}

Sehr kleine 32x8er-LED-Module zu fairen Preisen und für den passenden Standart zum Betrieb der Awtrix-Firmware zu finden, ist gar nicht so einfach. So entstand die Idee, stattdessen einfach ein 320×172 Pixel großes Display zu verwenden. Mein Projekt ist am Ende keine eigenständige AWTRIX. Stattdessen spiegelt (oder „streamt“) sie sozusagen nur eine bereits in eurem Netzwerk vorhandene LED-Matrix mit laufender AWTRIX-Firmware drauf. Das läuft dann über Wifi und funktioniert erstaunlich gut und schnell.

Dokumentation

Die Dokumentation befindet sich noch im Aufbau, aber gerade wenn ihr die MQTT-Befehle nutzen wollt, die mit Version 1.1.0 mitkamen, habe ich euch die da schon Mal aufgeschrieben.

Die Teile

Um das Projekt nachzubauen benötigt ihr gar nicht viel. Löten ist optional: Nur wenn ihr die recht langen Kabel des Displays kürzen wollt, solltet ihr löten. Es geht aber auch ohne das, dann kann alles einfach zusammengesteckt werden.

• D1 Mini-Board (mit ESP8266-Chip)
• Waveshare 1.47″ LC-Display oder Noname (z.B. dieses)*
• 6x 2mm-Schrauben (z.B. 2×5 oder 2×8)
• einen 3D-Drucker**

*) Ich will betonen das ich keine Werbung für das Waveshare-Display machen will. Ich habe mich aus 3 Gründen für dieses (im Vergleich etwas teurere) Display entschieden: Zum einen ist die Platine des Boards nur minimal größer als das Display was 3D-Gehäuse kompakter werden lies. Außerdem bringt das Display auf der Rückseite direkt Muttern zum verschrauben mit und da es sich um ein „Markenprodukt“ handelt, solltet ihr beim Bestellen im besten Fall auf den Millimeter dasselbe Produkt erhalten. In der Theorie sollte auch jedes andere Display, welches einen ST7789-Chip mitbringt problemlos funktionieren wie das verlinkte Noname-Display.

**) Der 3D-Drucker ist optional. Ihr könnt das Projekt natürlich auch mit einem ganz eigenen Gehäuse oder in anderer Form nachbauen. Dann benötigt ihr nur die Hardwarekomponenten und könnt loslegen.

3D Druck

Wenn ihr das Projekt wie im Video gezeigt nachbauen möchtet, könnt ihr euch mein AWTRIX STREAM-Gehäuse drucken. Es besteht aus 3 Teilen: Einem Träger, auf dem das Display aufgeschraubt und das D1 Mini-Board aufgelegt wird. Sowie dem Hauptgehäuse und einer aufsteckbaren Front.

Zusammenbau

Im ersten Schritt solltet ihr das Display mit dem D1 Mini-Board verbinden. Die folgende Tabelle zeigt, welche Pin des Displays mit welchem Pin des Boards verbunden werden muss.

Wenn ihr nicht löten möchtet und das 3D-gedruckte Gehäuse verwenden möchtet, dann müsst ihr an der Stelle nur noch das Display mit 4 Schrauben an dem Träger anbringen und das Kabel vorsichtig verwickeln. Danach den Träger einschieben und von außen festschrauben. Front vorsichtig aufklippen und das wars. Weiter geht’s mit dem Flashen der Software.

Software

Um die Software auf das Board zu bekommen, müsst ihr es zunächst via USB mit eurem Rechner verbinden. Als nächstes benötigt ihr einen Chrome-basierten Browser, als Chrome selbst, Chromium, Brave oder MS Edge. Opera funktioniert u. U. auch. Dann geht ihr auf folgende Seite, auf der ich immer die aktuelle Software-Version bereitstelle:

Wählt dort das Projekt #002: AWTRIX STREAM vx.x.x (ehemals „Awtrix Mini“) aus und folgt den Anweisungen. Solltet ihr das lieber in Bewegtbild sehen wollen: Im Video zeige ich auch diesen Schritt.

Nach der Installation stellt das ESP-Board einen WLAN-Access Point zur Verfügung:

SSID: AWTRIX STREAM-Setup
Passwort: 12345678

Sobald ihr verbunden seit, sollte sich ein Konfigurationsmenü öffnen. Wenn die Seite nicht automatisch erscheint, verbindet euch auf die IP-Adresse http://192.168.4.1. Hier könnt ihr nun euer Wlan konfigurieren. Außerdem könnt ihr dem Board noch einen Hostname vergeben und – ganz wichtig – die IP-Adresse der AWTRIX, die kopiert werden soll und von der unsere neue AWTRIX STREAM ihre Daten erhält.

Sind alle Einstellungen vorgenommen sollte sich die AWTRIX STREAM direkt mit ihrer großen Schwester verbinden. Habt ihr euch „verkonfiguriert“, so startet bitte mit der Installation der Software von vorne und wählt unbedingt „Erase Device“ aus. Dann könnt ihr frisch durchstarten.

Changelog

Um euch auf dem laufenden zu halten, was sich bei der Software so getan hat, kopiere ich euch hier die Änderungen der letzten Versionen rein.

## v1.1.0 - 20.04.2025

[FEATURE] MQTT broker support
[FEATURE] Change settings via MQTT
[FEATURE] HTTP Basic Auth configuration to access secured AWTRIX hosts
[FEATURE] Toggle display via MQTT
[FEATURE] Reboot AWTRIX STREAM via MQTT
[FEATURE] Erase all settings via MQTT to start over
[FIX] Several layout/screen optimisations and new dialogs
[FIX] Reduce Overhead on HTTP calls for better performance
[FIX] Removed FPS counter on Serial connection for better performance
[CHORE] Name change to a more fancy "AWTRIX STREAM". Yeah!

## v1.0.0 - 06.04.2025

Initial release 

FAQ

Benötige ich wirklich eine „richtige“ AWTRIX oder Ulanzi TC001 mit AWTRIX-Firmware oder läuft die AWTRIX STREAM auch Standalone?
Die AWTRIX STREAM wiederholt technisch gesehen nur das, was auf einer anderen LED-Matrix angezeigt wird. Sie kann nicht standalone betrieben werden.

Gibt es einen anderen Weg die AWTRIX STREAM zu nutzen ohne erst eine LED-Matrix kaufen zu müssen?
Ja. Wenn ihr noch ein ESP32-WROOM-32D-Board rumfliegen habt, könnt ihr da die AWTRIX-Firmware draufflashen. Die läuft dann auch ohne angeschlossene LED-Panele und kann so als Host fungieren.

Ist der Sourcecode verfügbar?
Ja, ihr findet das Projekt in meinem Github Repository unter der Attribution-NonCommercial-ShareAlike 4.0 International-Lizenz.

Kann ich mehrere AWTRIX STREAN auf eine Host AWTRIX loslassen?
Theoretisch ja. Jede AWTRIX STREAM verbindet sich über das WLAN via HTTP mit der Host AWTRIX. Das generiert Last auf der Host AWTRIX und kann irgendwann dazu führen, dass sich die AWTRIX STREAM nur noch seltener aktualisieren und alles etwas holpriger wirkt. Wo da genau die Grenze ist, kann ich nicht sagen. 2-3 gleichzeitig habe ich erfolgreich getestet. Eine größere Herausforderung stellt das WLAN da: Das sollte eine gute Signalstärke sowohl für Host also auch für AWTRIX STREAM bieten.

Im Kern kommen vier 8x8er RGB LED Matrixen und ein ESP32-WROOM-32D zum Einsatz. Ähnliche Komponenten wie wohl auch in der TC001 verbaut. Als Software verwende ich die „Awtrix 3“-Bibliothek (vormals „Awtrix light“, im Kern aber die gleiche Software). Das ist eine aktive OpenSource-Weiterentwicklung der Awtrix-Bibliothek, einer Software für eine inzwischen wieder eingestellte LED Matrix.

Um Geld zu sparen, kommt das Gehäuse aus dem 3D-Drucker. Es wurde selbst designed und ist extrem minimalistisch gehalten. Zentraler Punkt sind die Gitter, hinter welche die kleinen LED-Panels geklemmt werden können. Die Gitter selbst können dann mit kleinen Haken an der Ober- bzw. Unterseite ineinander gehangen werden. Das Ganze fügt sich dann wieder rum in das Gehäuse ein, welches dann durch eine dünne Front verkleidet wird. (Fast) Fertig ist LED-Matrix.

Auf der Rückseite habe ich den ESP32 festgeklebt und verlötet. Strom kommt über USB und geschaltet werden kann die Anzeige über einen kleinen Schalter an der Unterseite. Apropos Strom: Die Displays sind recht energiehungrig und emittieren je nach Helligkeit einiges an Wärme. Das sollte man im Blick haben: Zum einen damit das Gehäuse sich nicht verformt. Zum Anderen sollte ein entsprechend starkes Netzteil angeschloßen und im Querschnitt nicht zu dünne Kabel verwendet werden.
Da ich bei meiner günstigen Variante keine Schalter und Sensoren verbaue, fehlt der Software beim ersten Start somit auch die Information über die Raumhelligkeit. Entsprechend hell werden die Panels also beim ersten Start angesteuert.

Am Ende komme ich bei knapp unter 22,- Euro raus. Neben den reinen Elektrokomponenten einberechnet ist auch der Strom für den 3D-Drucker, der so ca. 17 Stunden lang gedruckt hat. Außerdem anteilig etwas für das PLA, die Kabel und den verwendeten Kleber um die beiden Hälften zu vereinen.

Am Ende bin ich echt zufrieden mit dem Ergebnis. Die Anzeige sieht schlicht aus, die Dot-Matrix-Ansicht sieht ordentlich aus. Wenn ich es mir wünschen könnte, hätte ich es gerne einen ticken schärfer an den Kanten gehabt. Aber das ist kein Problem, solange man nicht direkt mit der Nase vor der Anzeige steht.

3D-Druck & Dateien

In meinem Video seht ihr alles Wichtige zum Aufbau und der Konfiguration. Auch wie ihr die Displays ans Laufen bekommen könnt, wenn diese nach dem ersten Start nur Unfug anzeigen. Wenn ihr das Gehäuse selbst in euren 3D-Drucker packen wollt, findet ihr hier den Download. Bitte beachtet: Das ist natürlich jetzt absolut Custom-Made. Will sagen. Wenn eure LED-Panel bspw. leicht andere Dimensionen haben kann es sein, dass es schon nicht mehr passt und ihr den Druck selbst modifizieren müsst.

Zum Download stelle ich zwei Dateien. Der erste Download enthält eine STL-Dateien mit dem gesamten Modell. Im zweiten ZIP-Archiv befinden sich alle Elemente einzeln. Nutzt, womit ihr besser klar kommt.

Ansteuern der Awtrix 3

Nachdem das erste Video mit dem Zusammenbau der Matrix viele Leute interessiert hat, erkläre ich in einem zweiten Video betont anfängerfreundlich, wie die Matrix angesprochen wird. Mit dabei Infos, wie man eigene Apps gestaltet oder die eingebauten Effekte nutzt. Teil des Videos sind auch die folgenden Scripte, welche den Funktionsumfang eurer Matrix mit nützlichen Infos erweitern und vielleicht der Einstieg in eigene Erweiterungen sein könnten.

Python-Script: YouTube Abos

In diesem Zustand fungiert die Matrix rein als Display. Mit anderen Worten: Sie kann nix, abgesehen von der Uhrzeit und Datumsanzeige. Inhalte können aber ja einfach über die HTTP-API oder mittels MQTT überspielt werden. Für meinen Fall – ich möchte die Abozahlen meines YouTube-Kanals anzeigen – hilft mir dafür folgendes Python-Script:

import requests
import time

# YouTube API Informationen
youtube_api_key = "xxx"
channel_id = "xxx"

# Awtrix Light Matrix Informationen
awtrix_ip = "192.168.xxx.xxx"


def get_subscribers_count(api_key, channel_id):
    url = f"https://www.googleapis.com/youtube/v3/channels?part=statistics&id={channel_id}&key={api_key}"
    response = requests.get(url)
    data = response.json()
    subscribers = int(data["items"][0]["statistics"]["subscriberCount"])
    return subscribers

def send_app_to_awtrix(app_name, text, icon, duration):
    headers = {"Content-Type": "application/json"}
    data = {
        "text": text,
        "icon": icon,
        "duration": duration
        "lifetime": 600
    }

    awtrix_url = "http://"+ awtrix_ip + "/api/custom?name=" + app_name
    response = requests.post(awtrix_url, json=data, headers=headers)
    
    if (response.text != "OK"):
        print(response.text)

    time.sleep(duration * 4)

def host_available():
    try:
        result = subprocess.run(['ping', '-c', '1', awtrix_ip], capture_output=True, text=True, timeout=5)
        return result.returncode == 0

    except subprocess.TimeoutExpired:
        print(f"Timeout: {awtrix_ip} is not reachable")


def main():
    while True:
        try:
            if host_available:
                subscribers = get_subscribers_count(youtube_api_key, channel_id)
                send_app_to_awtrix("youtube", f"{subscribers}", 7320, 15)
            
            time.sleep(300)
        except Exception as e:
            print(f"Fehler: {e}")
            time.sleep(60)

if __name__ == "__main__":
    main()

In dem Code wird ein Icon mit der ID 7320 verwendet. Dazu sei gesagt: Über das Webinterface der Awtrix Light-Bibliothek lassen sich unter dem Punkt „Icons“ vorgefertigte Grafiken importieren. Diese stammen von developer.lametric.com, können dort ausgewählt und nutzerfreundlich eingespielt werden. Ach ja, und um die YouTube-API nutzen zu können, müsst ihr euch zunächst für die Nutzung bei Google freischalten. Kostet aber nix.

Python-Script: Wetter via OpenWeatherMap

Nicht jeder unterhält einen YouTube-Kanal, aber bei überall gibt’s Wetter! Und so möchte man vielleicht Informationen wie die aktuelle Temperatur oder ob sich Regen nähert auf der Matrix anzeigen. Als Datenquelle kann dafür super die OpenWeatherMap dienen. Wer es nicht kennt: OWM ist inzwischen ein alter Hase wenn es darum geht, über eine (für die kleine Nutzung) kostenfreie API Wetterdaten für beliebige Standorte zu liefern. Einfach kurz mit E-Mail-Adresse anmelden, API-Key kopieren und los geht’s. Folgendes Python-Script holt sich Wetterinformationen von einem bestimmten Standort mittels Geo-Koordinaten und sendet das aktuelle Wetter mit Icon und Temperatur an die Awtrix:

import requests
import time

# OpenWeatherMap API Informationen
api_key = "..."
lat = "50.93"
lon = "6.95"

# OpenWeatherMap Icon -> Awtrix Icon
condition_mapping = {
    "01d": 1630,
    "01n": 962,
    "02d": 2286,
    "02n": 54631,
    "03d": 12246,
    "03n": 12246,
    "04d": 12294,
    "04n": 12294,
    "09d": 2284,
    "09n": 2284,
    "10d": 2416,
    "10n": 2416,
    "11d": 2981,
    "11n": 2981,
    "13d": 1673,
    "13n": 1673,
    "50d": 17056,
    "50n": 17056
}

# Awtrix Light Matrix Informationen
awtrix_ip = "192.168.xxx.xxx"


def get_weather(api_key, lat, lon):
    url = f"http://api.openweathermap.org/data/2.5/weather?lat={lat}&lon={lon}&appid={api_key}&units=metric"
    response = requests.get(url)
    data = response.json()

    if response.status_code == 200:
        icon = data["weather"][0]["icon"]
        temperature = data["main"]["temp"]
        return temperature, icon
    else:
        return None, None

def send_app_to_awtrix(app_name, text, icon, duration):
    headers = {"Content-Type": "application/json"}
    data = {
        "text": text,
        "icon": icon,
        "duration": duration
    }

    awtrix_url = "http://"+ awtrix_ip + "/api/custom?name=" + app_name
    response = requests.post(awtrix_url, json=data, headers=headers)
    
    if (response.text != "OK"):
        print(response.text)

    time.sleep(duration * 4)

def host_available():
    try:
        result = subprocess.run(['ping', '-c', '1', awtrix_ip], capture_output=True, text=True, timeout=5)
        return result.returncode == 0

    except subprocess.TimeoutExpired:
        print(f"Timeout: {awtrix_ip} is not reachable")


def main():
    while True:
        try:
            if host_available:
                temperature, icon = get_weather(api_key, lat, lon)

                if temperature is not None and icon is not None:
                    send_app_to_awtrix("owm", "{:.1f}°C".format(temperature), condition_mapping.get(icon), 15)
                else:
                    print("Failed to retrieve weather information.")

            time.sleep(300)

        except Exception as e:
            print(f"Fehler: {e}")
            time.sleep(60)

if __name__ == "__main__":
    main()

Teileliste

Die Anzahl der verwendeten Komponenten ist bei diesem Projekt recht überschaubar:

• 1x ESP32-Wroom-32D Entwicklerboard*
• 4x 8×8-RGB-LED-Panel, 5V, WS2812B, ca. 71 x 71 mm** (wie z.B. bei AliExpress)
• 1x Wippschalter I/O, 11×15 mm
• 1x Micro-USB-Board (wie z.B. bei Amazon)
• 1x USB-Netzteil, USB-Anschlusskabel und etwas Litze zur Verkabelung der Matrixen, des Boards, Schalters und des Micro-USB-Boards***
• „ecoPLA Weiß“ von 3DJake für das Gehäuse, Noname schwarzes PLA für das Pixel-Gitter im inneren
• Noname 2-Komponent-Kleber um die Gehäuse-Hälften miteinander zu verbinden

*) Mit großer Wahrscheinlichkeit funktionieren auch ESP-Boards ohne den Zusatz „D“. Ich habe die D-Variante im Video erwähnt, da diese zum einen meines Wissens in der TC001 verbaut ist und somit wohl die größte Kompatibilität gewährleistet ist. Außerdem benötigt euer ESP-Board GPIO-Pins bis 35, zumindest wenn ihr auch Licht- und Temperatursensoren verbauen wollt. Sonst immerhin bis GPIO-Pin 32, denn dort wird die Matrix angeschlossen. Wenn ihr ein Board ohne „D“-Zusatz habt welches aber die benötigten GPIO-Pins mitbringt, könnt ihr im Zweifel einfach „blind“ die Awtrix-Bibliothek flashen. Gelingt die Installation und könnt ihr danach auf das Webinterface zugreifen, so ist die Wahrscheinlichkeit relativ hoch, dass auch der Rest funktionieren sollte.

**) Ich habe genau dieses Modell bestellt, allerdings befürchte ich, dass die Module nicht immer die exakt 100% gleiche Größe haben werden und daher besser oder schlechter in die von mir designte Fassung passen. Es kann sein, dass hier Nacharbeiten eurerseits nötig werden. So fiel mir z.B. bereits auf, das die versprochenen 71 x 71 mm bei meinen Modulen nicht eingehalten werden. Am Ende zählt hier aber jeder Millimeter, da ich keine Abstände zwischen den einzelnen Matrixen haben und das Gehäuse so kompakt wie möglich halten wollte.

***) Ich habe hier ein altes 5W-USB-Netzteil verwendet, was in meinem Fall völlig ausreichend ist. Am Ende sind Stärke der verwendeten Litze sowie des Netzteils von der Frage abhängig, mit welcher Helligkeit ihr die Matrix betreiben möchtet. Je heller, desto mehr Strom muss das Netzteil liefern und die Kabel aushalten können. Ich betreibe das Display mit einer Helligkeit von 20 (Bereich: 0-255), was in meinem Fall völlig ausreicht. Dabei bleibe ich unter den genannten 5 Watt. Wird die Grenze überschritten fangen die LEDs an zuflackern und wahrscheinlich hängt sich das ESP-Board irgendwann auf.

Wichtige Hinweise

Bitte bedenke: Es handelt sich um ein privates Bastelprojekt eines Hobbyschraubers. Will sagen: So wie gezeigt funktioniert das Ganze gut, aber es bestehen auch Gefahren: Bspw. kann von zu dünnen Kabeln bei hoher Stromaufnahme der LEDs eine Brandgefahr ausgehen oder durch Abwärme das PLA verformen oder mehr. Bei Fehlanschluss des ESP-Boards kann selbiges Schaden nehmen. Heißt: Baut meine Sachen gerne nach, aber ihr handelt eigenverantwortlich. Ich will jeden ermutigen sich auch Themen anzunehmen, in denen er oder sie bisher keine Expertise besitzt, aber geht clever vor: Informiert euch abseits meines Blogs, lasst eure Errungenschaften nicht unbeaufsichtigt laufen usw. Man lernt nie aus.

Herausgekommen ist dabei ein „Command Control Center“. Der Name ist völlig übertrieben, ich weiss. Das Gehäuse ist eigens von mir skizziert und mittels 3D-Drucker selbst gedruckt. Wichtig war mir, dass es gut an meinen Schreibtisch (ein weit verbreitetes Modell eines schwedischen Möbelherstellers) passt und drei Taster beherbergen kann. Zusätzlich, um der Mächtigkeit des Begriffs „Command Control Center“ näher zu kommen, befindet sich im Gehäuse Platz für einen Schlüsselschalter, der die Spannungszufuhr für das verbaute D1 Mini ESP-Board steuert. Man hätte das mit Sicherheit auch anders lösen können, aber: Et soll ja auch Spaß machen!

Die Taster bieten neben ihrer eigentlichen Aufgabe des als Taster fungieren noch die Möglichkeit, einen LED-Ring leuchten zu lassen. Der symbolisiert ob die entsprechende Lampe ein- oder ausgeschaltet ist. In meinem Beispiel sind zwei Taster mit weißer und einer mit blauer LED verbaut. Die Taster sind mir im Nachgang etwas zu klein zum Drücken, dennoch mag ich sie und mit rund 4,- Euro waren sie recht günstig. Außerdem sind sie mit einer Eingangsspannung von 3 bis 9 Volt für die LED recht flexibel einsetzbar.

Im Inneren arbeitet ein D1 Mini Clone-Board, also ein ESP8266 der direkt Wifi onboard hat. Das ist wichtig, da die Homebridge, die bei mir als zusätzliche Ebene zu Apples Homekit im Einsatz ist, über API-Aufrufe über das lokale Netzwerk gesteuert wird. Von dem D1 Mini-Board brauch es 6 Pins: 3 für die Statusanzeige, also die jeweilige LED. Und eben 3 weitere für die Erkennung der Tastendrücke.

Das ist es im Wesentlichen dann auch schon. Natürlich muss die Software noch angepasst werden. So müssen sogenannte „uniqueId“ hinterlegt werden. Dabei handelt es sich um eine eindeutige Identifikation eines jeden Geräts, welches über Homebridge geschaltet werden kann. Tastendrücke lösen dann entsprechende API-Anfragen aus, welche diese „uniqueId“ übermitteln, bzw. sie verwenden um in regelmäßigen Abständen nach dem Status (Licht an oder aus) bei der Homebridge nachfrage. Denn es könnte ja auch sein, dass eine Lampe oder Steckdose auf anderem Weg geschaltet wird.

Meinen Code stelle ich euch natürlich frei und als Open Source auf Github zur Verfügung. Die Datei für den 3D-Druck des Gehäuse findet ihr hier:

Den Code habe ich auf mein Github-Profil gepackt. Von dort könnt ihr alles einfach herunterladen oder via Git auschecken.

Damals hatte ich sowohl auf Mastodon als auch unter dem Video den Tipp erhalten, mir mal den BME280 oder den DS18B20 anzuschauen. Diese Sensoren seien deutlich besser als der DHT22. Gesagt getan: Den BME280 gab es für ca. 6 Euro im 5er Pack aus Fernost, den DS18B20 habe ich für so ziemlich denselben Preis bei einem deutschen Händler bestellt.

Alle drei Sensoren sind im Detail ein bisschen anders. So ist der DHT22 der Klassiker, er ist nicht ganz schmal, sehr gut mit Bibliotheken für Android oder ESP-Boards unterstützt und liefert neben der Temperatur auch die relative Luftfeuchte.

Der BME280 ist, nimmt man nur den Sensor für sich, sehr klein. Er wurde von Bosch entwickelt vor dem Hintergrund dort verbaut zu werden, wo wenig Energie und wenig Platz zur Verfügung steht. Neben Temperatur und relativer Feuchte kann er auch den Luftdruck ermitteln. Es gibt auch ein Modell, welches auf den Namen BMP280 hört. Dieser ist hingegen nicht in der Lage, die Luftfeuchte zu ermitteln. Auch für diese Sensoren gibt es einige gute Bibliotheken, welche die Verwendung relativ einfach machen. Allerdings muss man wissen, auf welcher Adresse der Sensor mittels I²C zu erreichen ist: In diesem Fall ist es 0x76, bei anderen 0x77.

Der DS18B20 ist gefühlt der Vielseitigste was seine unterschiedlichen Bauformen angeht. Neben der von mir verwendeten Variante gibt es u.a. auch in einer Wasserdichten Version. Allerdings kann er, anders als der DHT22 oder der BME280 rein die Temperatur ermitteln, nicht die Luftfeuchte. Übermittelt werden die Daten mit dem 1-Wire-Protokoll. Dabei handelt es sich um eine serielle Datenübertragung welche von der Firma Dallas Semiconductor entwickelt wurde. Der Name ist Programm: Es wird eben neben der Spannungsversorgung nur ein weiteres Kabel benötigt. Wobei, das stimmt nicht ganz: Für die Schaltung wird zudem ein Pull-Up-Widerstand benötigt. Sonst funktioniert das Ganze nicht. Keine große Herausforderung, wenn man es noch nie gemacht hat, sollte man sich dem Thema einmal annehmen.

Für meinen Vergleich habe ich mir auf meinem Steckfeld 3 Teststrecken gebaut. Beide sind vom Aufbau identisch: Von jedem Sensor existiert pro Teststrang ein Exemplar. Angeschlossen sind sie an einen D1 Mini Clone, welcher die Daten an meine InfluxDb und damit an an ein Grafana-Dashboard sendet über das die Auswertung stattfindet. Den Code stelle ich euch gerne bereit. Auch wenn man vermutlich dieses Setup so nicht benötigt, kann man sich vielleicht für eigene Projekte etwas abschauen wenn man neu in der Materie ist:

#include <Wire.h>
#include <SPI.h>
#include <Adafruit_BME280.h>
#include <OneWire.h>
#include <DallasTemperature.h>
#include <ESP8266WiFi.h>
#include <InfluxDbClient.h>
#include "DHT.h"
#include "secrets.h" // Einfache Konstanten-Sammlung für Credentials


#define ONE_WIRE_BUS 2 // GPIO PIN 2

InfluxDBClient influx(INFLUXDB_URL, INFLUXDB_ORG, INFLUXDB_BUCKET, INFLUXDB_TOKEN);
Point bmeSensor("bme_1");
Point dsSensor("ds_1");
Point dhtSensor("dht_1");


Adafruit_BME280 bme;
Adafruit_Sensor *bme_temp = bme.getTemperatureSensor();
Adafruit_Sensor *bme_humidity = bme.getHumiditySensor();

OneWire oneWire(ONE_WIRE_BUS);
DallasTemperature ds18b20(&oneWire);

DHT dht(14, DHT22); // GPIO PIN 14

void setup() {
  Serial.begin(9600);

  WiFi.mode(WIFI_STA);
  WiFi.begin(WIFI_SSID, WIFI_PASSWORD);

  while (WiFi.status() != WL_CONNECTED) {
    delay(500);
    Serial.print(".");
  }

  Serial.println("");
  Serial.print("Connected to ");
  Serial.println(WiFi.SSID());
  Serial.print("IP address:\t");
  Serial.println(WiFi.localIP());


  
  Serial.println(F("BME280 Sensor event test"));

  // Erzwinge Adresse 0x76 statt 0x77, nutzt die SCL/SDA Pins des D1 mini
  if (!bme.begin(0x76)) { 
    Serial.println(F("Could not find a valid BME280 sensor, check wiring!"));
    while (1) delay(10);
  }
  
  bme_temp->printSensorDetails();
  bme_humidity->printSensorDetails();

  ds18b20.begin();

  dht.begin();

  influx.setInsecure();
}

void loop() {
  sensors_event_t temp_event, pressure_event, humidity_event;
  bme_temp->getEvent(&temp_event);
  bme_humidity->getEvent(&humidity_event);
  
  Serial.print(F("BME280 Temperature: "));
  Serial.print(temp_event.temperature);
  Serial.println(" °C");

  Serial.print(F("BME280 Humidity: "));
  Serial.print(humidity_event.relative_humidity);
  Serial.println(" %");

  bmeSensor.addField("temperature", temp_event.temperature);
  bmeSensor.addField("humidity", humidity_event.relative_humidity);
  if (!influx.writePoint(bmeSensor)) {
    Serial.print("InfluxDB write failed: ");
    Serial.println(influx.getLastErrorMessage());
  }

  ds18b20.requestTemperatures();
  Serial.println("DS18B20 Temperature: " + String(ds18b20.getTempCByIndex(0)) + "°C");

  dsSensor.addField("temperature", ds18b20.getTempCByIndex(0));
  if (!influx.writePoint(dsSensor)) {
    Serial.print("InfluxDB write failed: ");
    Serial.println(influx.getLastErrorMessage());
  }

  Serial.println("DHT22 Temperature: " + String(dht.readTemperature()));
  Serial.println("DHT22 Humidity: " + String(dht.readHumidity()));
  dhtSensor.addField("temperature", dht.readTemperature());
  dhtSensor.addField("humidity", dht.readHumidity());
  if (!influx.writePoint(dhtSensor)) {
      Serial.print("InfluxDB write failed: ");
      Serial.println(influx.getLastErrorMessage());
    }

  delay(1000);
}

Für meinen Test habe ich das ganze Setup kurz in die „Kälte“ gestellt. Das sollte dazu dienen um zu sehen wie schnell die Sensoren der Raumtemperatur annähern. Als Referenz diente ein Thermometer, was mehrere Stunden im Raum stand. Zugegeben: ist wieder nicht hochgradig wissenschaftlich, aber für die Stichprobe in meinen Augen ausreichend.

Am Ende bestätigten sich eure Aussagen: Sowohl der DS18B20 als auch der BME280 sind weniger träge als der DHT22. Der DS18B20 ist bei der Disziplin das Rennpferd. Nach etwa 2-3 Minuten hatte er sich bereits bereits wieder angeglichen. Der BME280 war mit 5 Minuten unwesentlich langsamer, während der DHT22 ca. 10 Minuten brauchte. Hinzu kommt die Frage nach der Güte der Daten. Zwischen den drei DHT22 Sensoren lagen am Ende mehr als 1 Grad Unterschied. Auch hier waren beide andere Sensortypen deutlich besser mit ca. 0.2 Grad beim DS18B20 bzw. nur ca 0.1 Grad beim BME280. Der BME280 war auch der Sensor, der am nächsten am Standthermometer lag. Und das sowohl in Bezug auf die Temperatur als auch auf die relative Luftfeuchte.

Somit ist das auch mein persönlicher Testsieger, wenngleich der DS18B20 unmittelbar danach kommt. Der DHT22 ist mit Sicherheit kein schlechter Sensor, aber mit dem Wissen ist seine Zeit bei mir zu Hause wohl vorbei. Ich werde ihn zeitnah gegen die BME280er tauschen.

Mit dem CCS811 ist bereits seit einigen Jahren ein Sensor auf dem Markt, mit dem sich dies per se realisieren lassen sollte. Mein Exemplar lag bisher (einmalige Verwendung ausgenommen) ungenutzt in der Ecke. Zeit also, mal genauer zu schauen was der Sensor so kann – und eben vielleicht auch nicht!

Im „Bastelbedarf“ kommt der Sensor oft fertig aufgebaut auf einem kleinen Board, welches die Handhabe mit ihm erleichtert. Wie genau, das mag von Board zu Board etwas unterschiedlich sein. Ich beziehe mich hier auf ein fertiges Platinchen von Adafruit, welches die Verwendung in 2 Punkten erleichtert:

• Pull-Up-Widerstände: Für die Kommunikation mittels I²C sind diese nötig und bereits auf dem Board verlötet. Dies vereinfacht die Verkabelung in unserem Setup, zumindest wenn sonst nichts auf der I²C-Leitung kommuniziert
• Level-Shifting: Egal ob wir ein Development Board mit 3.3V oder 5V Spannung an den I/O-Ports verwenden, dieses Sensor-Modul kommt mit beidem klar

Bleiben am Ende also noch 4 Kabel nötig, um das Board zu betreiben: 3.3V oder eben 5V, Ground, sowie SDA und SCL für die Kommunikation.

Viel Code ist ebenfalls nicht nötig, da es unterschiedliche Bibliotheken gibt die einem die Arbeit erleichtern. Ich nutze in meinem Beispiel die passende Bibliothek zum Board: „Adafruit_CCS811„. Die ist vorab über die Arduino IDE zu installieren. Hier der Code aus meinem Video:

#include "Adafruit_CCS811.h"

Adafruit_CCS811 ccs;

void setup() {
  Serial.begin(115200);

  if (!ccs.begin()) {
    Serial.println("Keine Kommunikation mit Sensor, Verkabelung prüfen");
    while(1);
  }

  while(!ccs.available());
}

void loop() {  
  if (ccs.available() && !ccs.readData()) {

    Serial.print("CO2: ");
    Serial.print(ccs.geteCO2());
    Serial.print("ppm, TVOC: ");
    Serial.println(ccs.getTVOC());

  } else {
    Serial.println("Keine Daten empfangen");
    delay(5000);
  }

  delay(1000);
}

Wie man hier sieht ist es möglich mit der Methode getTVOC() die Gesamtzahl der sogenannten Volatile Organic Compounds (VOC) abzurufen. Übersetzt sind das flüchtige organische Verbindungen wie Kohlenwasserstoffe oder Alkohole die sich durch die Luft bewegen. Treffen solche Partikel auf den Sensor, so „zählt“ dieser sie. Mit der Methode geteCO2() lässt sich zudem das sog. equivalent carbon dioxide, also ein CO2-Äquivalent abfragen. Hierbei sollte man jedoch wissen, dass der Sensor nicht in der Lage ist CO2 zu messen. Der ausgegebene Wert ist eine Berechnung, die auf den TVOCs basiert. Entsprechend kann man sich die Frage nach der Güte der ausgegebenen Werte stellen.

Für einen groben Indikator in wie weit sich die Qualität der Luft in einem Raum über die Zeit verändert ist der Sensor aber allemal gut und in Form eines solchen fertig aufgebauten Boards auch für Einsteiger einfach nutzbar. Um die für diesen Sensor bestmöglichen Ergebnisse zu erhalten, sollte man zudem 2 Dinge beachten:

• Vor der ersten Verwendung, sollte der Sensor eine 48 Stunden lange „Burn-In“-Phase durchlaufen. Ergo: Er soll einfach „arbeiten“. Nach 48 Stunden ist er dann „eingebrannt“ und soll vernünftige Ergebnisse liefern
• Vor jeder Verwendung benötigt der Sensor etwa 20 Minuten, bis er „betriebswarm“ ist. Zuvor sind die Ergebnisse ungenau

Während der DHT 11 mit einer Auflösung von einem Grad etwas gröber unterwegs ist, kann der DHT 22 die Temperatur in 0.1 Grad Schritten messen. Oft bekommt man sie vormontiert für 5-10 Euro auf einer kleinen Platine, welche es ermöglicht den Sensor mit einer Spannung von 3.3 bis 5.5 Volt zu betreiben. Auch praktisch ist, dass es er nur einen Pin belegt. Sensoren anderer Bauart, die SPI/I2C verwenden, benötigen schnell mal 2 Pins.

Zudem gibt es für so ziemlich alle Plattformen fertige Bibliotheken, welche die Verwendung mit wenigen Zeilen Code ermöglichen, wie in diesem Mini-Arduino-Sketch:

#include "DHT.h"

DHT dht(1, DHT22); // 1 = GPIO Pin

void setup() {
  Serial.begin(9600);

  dht.begin();
}

void loop() {
  Serial.println(dht.readTemperature());

  delay(10000);
}

Bei mir sind auch zwei DHT 22 im Dauereinsatz. Sie sind an ein D1 Mini Clone Board angeschlossen, welche die Werte via Wifi an eine InfluxDB senden. Die Daten werden in einem Grafana-Dashboard ausgewertet. Und genau dort fiel mir kürzlich auf, dass einer der Sensoren mit knapp 90% eine sehr hohe Luftfeuchte ausgab, die einfach nicht stimmen konnte.

Also wechselte ich den Sensor. Und siehe da: ein neuer DHT 22 meldete schlagartig nur noch um die 60% Feuchte. Grund genug mich zu Fragen: Wie zuverlässig sind diese Sensoren eigentlich? Um das zu prüfen, habe ich 5 DHT 22 Sensoren unterschiedlichen Alters auf ein Steckbrett gepackt und die Werte verglichen.

Laut Datenblatt hat der DHT 22 eine Genauigkeit von +/- 0.5 Grad Celsius im in der Wohnung üblichen Temperaturbereich. Bei der Messung der relativen Luftfeuchte sollen es lediglich 2% sein. In meinem Test konnte ich das leider nicht bestätigen: Bei der gemessenen Temperatur wichen die Sensoren bis zu 2 Grad Celsius voneinander ab. Bei der Luftfeuchte war es noch extremer: Während zwei Sensoren um 90% anzeigten, lagen die anderen bei 55-60%.

Ein wie ich finde etwas überraschendes Ergebnis. Wenn ihr den Test in Gänze sehen möchtet, empfehle ich euch meinen kleinen Videobericht dazu.

-> DHT 22 Temperatur-Sensor-Vergleich auf YouTube

dump190 ist dabei das Programm der Wahl. Hiermit lassen sich die über den DVB-T Stick auf 1090 MHz empfangenen Signale in nutzbare Daten umwandeln. Die Software ist dabei ziemlich mächtig und kann die Daten theoretisch direkt für uns visualisieren oder zumindest lesbar und übersichtlich in der Linux-Konsole darstellen. Zusätzlich können die Daten via Netzwerk bereitgestellt werden. Genau das machen wir uns zu nutze.

Neben dump1090 auf dem Raspberry Pi nutzen wir einen Pico auf dem ein Micropython Script läuft. Dieses zieht die Daten über das Netzwerk und stellt sie auf einem kleinen runden TFT-Display ganz im Stile eines guten alten Radars aus Action Filmen dar.

Den Code zu diesem kleinen Experiment findet ihr in meinem Github Repository. Alles weitere im Video.

Alle Links die ihr benötigt
* Mein Code auf Github
* dump1090
* Micropython TFT Bibliothek

Mit einem kleinen Health Wearable möchte ich dem entgegenwirken. Ein kleiner Beschleunigungssensor soll dabei unauffällig die Neigung des Oberkörpers überwachen und die Ergebnisse in einer Grafik anzeigen.

Zugegeben: Das Ganze ist eher ein Versuch oder Proof of Concept und gleichermaßen ein Lehrprojekt bei dem ich einfach mal was ausprobieren wollte. Zum Einsatz kommen wieder ein NodeMCU Board und ein GY-61 3-Achsen ADXL335 Beschleunigungs-/Neigungssensor.

Die Software gibt’s natürlich wie immer auf meinem Github-Account. Alle weiteren Details finden sich im Video. Viel Spaß beim Nachbauen!