+ 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");
  }
}

So ging es mir mit meinem Nokia 5110: Ich habe es damals geliebt. Es war eins der ersten Nokias mit Snake. Ein so einfaches Spiel, das zumindest die Älteren unter uns wahrscheinlich alle noch kennen. Bisher stand es etwas verloren in meinem Regal. Und somit war es der perfekte Kandidat für dieses Projekt: Ein mit LEDs versehener Fotorahmen, welcher die Innereien des Nokia 51110 so richtig zur Geltung bringen sollte.

Die Komponenten

• Fotorahmen „SANNAHED“, 25x25cm, 6,- Euro
• D1 Mini, ESP8266*, ca. 5,- Euro
• WS2812B-LED-Streifen, 5V, 60 LEDs/m, 9,- Euro
• Magentkontaktstecker, ca. 3,-/Stk.
• USB-Stromanschlussboard, ca. 1,- Euro
• Sperrdiode, ca. 0,50 Euro
• Selbstgestalteter Fotohintergrund, ca. 5,- Euro
• Klebepads oder 2-Komponentenkleber, zwischen 2,- und 5,- Euro
• etwas Kabel, Lötkolben, Schrumpfschläuche

*) Wie sich während der Arbeit rausstellte, endet in der nahen Zukunft die Unterstützung von ESP8266-Boards seitens der eingesetzten WLED-Software. Für neue Projekte werden deshalb ESP32-basierte Boards empfohlen, die sich preislich aber nur wenig unterscheiden dürften.

Das Exponat

Das Nokia lies sich recht einfach auseinandernehmen: Nachdem man die Batterie entfernt hatte, offenbarten sich auf der Rückseite einige Torx-Schrauben mit denen man schnell im inneren war. Dort ging es dann ebenso schnell weiter. Das muss natürlich bei jedem Gerät der Fall sein, auch wenn früher noch mehr Teile verschraubt statt verklebt waren. Anders als es heute oft gängige Praxis ist. Wenn euer Exponat da etwas widerspenstiger ist, habt bitte im Hinterkopf: Verletzt euch nicht! Displays können brechen, Batterien können auslaufen oder man kann beim Versuch etwas aufzuhebeln abrutschen. Denkt da an eure Finger und eure Gesundheit. Lest dazu bitte auch folgenden Absatz.

Vorsicht: Gefahr!

Eine Sache, die man unabhängig von eurem Bastelvorhaben nicht unterschätzen sollte, ist die potentielle Gefahr, die von alten Batterien und Akkus ausgehen kann. Ich war überrascht zu sehen, dass bereits in meinem Nokia 5110 von 1998 ein Lithium-Ionen-Akku verbaut war. Die sind heute überall und sehr sicher, dennoch weiß man nie ob im inneren bereits Zersetzungseffekte eingetreten sind. Ich will das Thema auch gar nicht zu sehr stressen, das Netz ist voll mit Artikeln zu dem Thema. So viel nur: Ich habe mich bewußt dazu entschieden, den Akku auf dem Wertstoffhof abzugeben und ihn nicht in den Fotorahmen zu kleben.

Der kreative Teil

Nachdem das Telefon in seine Einzelteile zerlegt war, ging es um die Positionierung. Beim Nokia 5110 kommen viele ähnlich große zum Einsatz. Wenige Kleinteile, was die Positionierung etwas erschwerte. Nachdem ich mich für ein Layout entschieden hatte, ging es ans „designen“ des Hintergrunds. Ich habe das Wort absichtlich in Anführungszeichen gepackt: Denn hier muss man wirklich kein Experte oder Grafiker sein. Die Hardware, illuminiert durch die LEDs, ist der eigentliche Hingucker. Mit ein paar kurzen Texten, Erklärungen oder einfachen grafischen Elementen kann man viel erreichen.

In meinem Fall habe ich mir folgende Fragen gestellt:

• Wo positioniere ich den Namen des Telefons prominient?
• Kann ich einen kurzen Text schreiben, der etwas über die Geschichte erzählt?
• Kann ich die einzelnen Komponenten (Logic Board, Tastenfeld, Cover, …) benennen?
• Kann ich mit Pfeilgrafiken auf bestimmte Bauteile oder Features hinweisen?
• Wo soll der Rahmen stehen und welche Farbe hat er: empfiehlt sich ein heller oder ein dunkler Hintergrund?
• Welche zeitgemäße, moderne oder zurückhaltende Schriftart verwende ich?

In Affinity Photo habe ich daraufhin ein bisschen gebastelt, geschoben und experimentiert. Wenn ihr kein Grafikprogramm habt, könnt ihr euch das kostenfreie Tool GIMP besorgen, was in der Bedienung als Anfänger vielleicht etwas hakelig sein kann. Alternativ würde ich noch Canva ins Rennen werfen, was man eingeschränkt nach Registrierung kostenfrei nutzen kann.

Hardware & Software

Zum Einsatz kommen einmal mehr ein ESP8266-Board mit WLED-Software. Wie oben bereits angerissen, sollte man laut WLED-Website für neue Projekte inzwischen ESP32-Boards verwenden, da der 8266er-Chipsatz nicht mehr lange unterstützt werden wird.

Auf den ESP wird dann einfach die WLED-Software über den bekannten Webinstaller geflashed. Danach verbinde ich das zusätzliche USB-Board, an welches später das Netzteil angeschlossen wird, mit dem ESP und dem LED-Steifen. Dazwischen kommt noch eine Diode: Wird Strom an die externe USB-Buchse angeschlossen, soll dieser den ESP und den LED-Streifen versorgen. Schließe ich aber z.B. für ein Software-Update ein USB-Kabel an den ESP direkt an, soll dieser nicht den LED-Streifen mit Strom versorgen. Das könnte eine zu Hohe Last für den ESP oder euren USB-Anschluss am Rechner sein.

Apropos: Insbesondere wenn ihr sehr viele LEDs anschließen wollt, solltet ihr euch Gedanken um die Dicke eurer Kabel machen. Sind die zu dünn, können die sich auch entsprechend erhitzen und in Flammen aufgehen. Ich empfehle da immer den Rechner vom WLED-Projekt.

Danach habe ich die einzelnen LEDs mit dem Streifen verlötet. Dabei ist es wichtig auf die Reihenfolge zu achten! Auf den Streifen befindet sich ein kleiner Pfeil, welche die Laufrichtung anzeigt.

Um den Rahmen von seinem Innenleben trennen zu können, habe ich Magnetkontakte verwendet. Die hatte ich noch rumfliegen, boten sich an, sind aber komplett optional.

Komponenten befestigen

Nachdem das Foto auf dem Hintergrund aufgeklebt wurde, wurden die einzelnen Komponenten des 5110 wieder rum auf das Foto geklebt. Hierbei habe ich anfangs mit kleinen Klebepads gearbeitet. Die funktionieren auch gut, allerdings sollte man einerseits nicht zu wenige von ihnen verwenden und diese nicht in Türmchenbauweise zu hoch stapeln. Sowohl die Platine des Tastenfelds als auch das Cover der Front – beides große aber leichte Teile – kamen mir nach 1-2 Tagen entgegen.

Ich habe mich dann dazu entschieden, mit 2-Komponentenkleber aus dem Discounter weiterzumachen. Der war günstig, hält aber nach seinen 2 Stunden Trocknungszeit richtig gut. Als Abstandshalter verwende ich kleine Elemente aus dem 3D-Drucker. Da kann man aber auch sicher ein Stückchen Holz oder ähnliches verwenden, wenn man keinen 3D-Drucker zur Hand hat.

Im Nachgang würde ich definitiv immer wieder den Weg mit dem Kleber gehen. Es ist einfach super ärgerlich, wenn man 2 Tage später auf den Fotorahmen schaut und sich wundert, warum Teile plötzlich eine Etage tiefer liegen als erwartet und schlimmsten Falls noch etwas beschädigen.

Konfiguration

In der WLED-Oberfläche lassen sich nun unterschiedliche Segmente konfigurieren. In meinem Fall befinden neben dem LED-Streifen, der innen einmal um den Rahmen geht, 5 weitere LEDs unter der alten Hardware des Nokia. Über die Segmente ist mir mögliche, unterschiedliche Farben und Effekte für jede LED zu konfigurieren. So stelle ich ein:

• LED 1, Tastenfeld, Segment 1: Grün
• LED 2-3, Display, Segment 2: Weiß mit leichtem Blauton
• LED 4-5, Platine, Segment 3: Wechselnder, Bunter Farbeffekt

Die dann folgenden LEDs sind Teil des Streifens. Auch hier konfiguriere ich unterschiedliche Farben, sodass die einzelnen Komponenten (bunt) und Texte (weiß) unterschiedlich beleuchtet werden. Für wen das zu theoretisch war: Im Video zeige ich das nochmal ganz genau. Im Video wie hier der Hinweis: Speichern nicht vergessen, dass geschieht nämlich nicht automatisch!

Fazit

Ich bin mit dem Ergebnis sehr zufrieden. Bei der Konfiguration der LEDs tobe ich mich vielleicht noch ein bisschen aus, das ist mir vielleicht einen ticken zu farbintensiv. Aber da hat man ja alle Möglichkeiten dank WLED. Ein bisschen Zeit und Geduld sollte man für das Projekt mitbringen. Es sind, abhängig von der Anzahl der verwendeten LEDs, schon einige Arbeitsschritte. Aber es lohnt sich. Was die Kosten angeht, stehe ich am Ende bei irgendwas um die 20-30 Euro. Einige der Komponenten hatte ich noch hier und das Nokia 5110 habe ich jetzt natürlich nicht in die Rechnung mit aufgenommen – das ist eh unbezahlbar.

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.

Getauft auf den Namen „EchoTrack“ prüft dieses kleine und bunte Gadget kontinuierlich eure Internetverbindung, in dem es einen von euch definierten Host vier Mal pingt und euch danach den errechneten Mittelwert daraus anzeigt. Neben dem Host der angepingt werden soll könnt ihr zudem 2 Warnstufen definieren. Werden diese überschritten, so blinkt das Tool hektisch in orange oder rot um euch sofort zu informieren, dass der aktuelle Hinterhalt in Fortnite, Tarkov, Quake 3 Arena oder was ihr auch immer gerade zockt vielleicht nach hinten losgehen könnte – und es dann nicht (nur) am Skill gelegen hat.

Schaltplan

Um die Verkabelung ein bisschen transparenter zu machen, habe ich folgendes Schema für euch zusammengebastelt. Doc Brown würde sagen „mir fehlte die Zeit, es ist nicht ganz Maßstabsgetreu“: Statt einer 4-Digit-Anzeige verwendet natürlich wie im Video eine 6-Digit-Anzeige. Ich hab in meinem Tool einfach nicht die passende gefunden, die Anschlüsse sind aber natürlich die gleichen.

Die Teileliste

Wie auch bei den letzten Projekten, ist das hier auch recht günstig und mit wenigen Teilen zu realisieren. Wenn ihr das Gehäuse auch so drucken wollt, braucht ihr natürlich einen 3D-Drucker. Die Dateien dazu findet ihr weiter unten.

• 6-Stellen 7-Segment-Anzeige (z.B. bei eBay, Suche nach „TM1637 6-stellig 7-Segment“)
• D1 Mini ESP-Board (z.B. im Makershop oder bei Aliexpress noch günstiger)
• 5V WS2812b LED-Streifen (z.B. bei Amazon, achtet darauf dass die LEDs nah beieinander sind und der Streifen mit 5 Volt betrieben wird)
• Kapazitiver Touch-Sensor (sucht nach „TTP223“)
• PLA nach eurer Wahl, natürlich ist weißes oder durchsichtiges für die Rückseite von Vorteil
• Kabel/Litze und natürlich das passende Werkzeug wie Lötkolben oder Abisolierzange

Die Software

Damit aus Hardware mehr als nur ein Klumpen Einzelteile wird benötigt es natürlich auch die passende Software. Im Fall von EchoTrack habe ich die selbst geschrieben und dazu zum ersten Mal mit den Webtools von ESPHome experimentiert. Das ermöglicht eine – sofern ich alles richtig gemacht habe – einfache Installation über euren Browser. Vorausgesetzt ihr seid mit Chrome, Microsoft Edge oder Opera unterwegs. Wenn dem ist, findet ihr unter https://esp.datort.de den Installer. Wie das genau funktioniert, könnt ihr euch natürlich auch nochmal in meinem kleinen YouTube-Werk anschauen.

Der Installer funktioniert aktuell nur mit ESP-Boards mit 8266er-Chipsatz. Wenn ihr ein anderes Board verwenden möchtet, nutzt gerne den Quellcode aus meinem Github-Repository und erstellt euch einen eigenen Build.

3D-Dateien

Wie häufig bei diesen Projekten stelle ich die 3D-Dateien als STL wieder zum Download bereit. Ihr könnt die gerne modifizieren und für eigene Kreationen nutzen, wie es euch beliebt. Gedruckt habe ich in meinem Fall mit Cura. Bei den Einstellungen habe ich das Profile „Dynamic Quality – 0.16mm“ verwendet. Das Infill habe ich auf 100% gestellt. Supports sind nicht nötig, wenn ihr die Objekte so dreht, dass das „Front“-Modell nach mit der Vorderseite nach unten zeigt. Die Rückseite sollte ebenfalls auf dem Rücken liegen, dann passte das bei mir.

Wie genau der Zusammenbau lief und wie das ganze in Aktion aussieht, könnt ihr gerne dem Video entnehmen. Viel Spaß!

Neben der Awtrix 3 gibt es mit WLED ein zweites bereits seit Jahren bekanntes und etabliertes OpenSource-Projekt, welches RGB-LED-Matrixen oder auch LED-Streifen unterschiedlichster Art mit Inhalten versorgen kann. Das können dann einfach bis komplexe Animationen sein, teils sogar an Umgebungsgeräusche wie Musik angepasst. Oder eben auch bunte Pixelkunst, die dann auf der Kommode dazu beiträgt, einem Raum etwas mehr Farbe zu verleihen und damit eine andere Atmosphäre zu verschaffen.

Wie beim letzten Projekt wollte ich auch diesmal wieder alles selbst machen bezogen auf das Gehäuse. Entsprechend kommen erneut alle Teile aus dem 3D-Drucker. Dieses Mal habe ich mich dabei für ein graues PLA entschieden. Ich wollte gerne einen Kontrast zu der weißen Umgebung, in der das Ganze später stehen soll. Der „Trick“ ist der derselbe wie zuvor: Die Front des Gehäuses wird auf einen Rahmen aufgesetzt in dem die 8x8er-Matrixen festgezurrt sind. Dabei ist die Frontfläche nur 0.4mm stark, oder: Nur zwei Schichten PLA. Dadurch ist sie flexibel, aber stabil genug und lässt vor allem noch genug Licht durch. Nur zu heiß sollte es nicht werden.

Die Teileliste

Die Anzahl der Komponenten ist recht überschaubar, die LED-Matrixen kommen dabei wieder aus China. Die Preise dort sind einfach unschlagbar.

Disclaimer: Die Links sind KEINE Affiliate-Links. Ich verdiene nichts daran (hier ist eh alles privat), sie sollen euch nur zum schnellen Finden der verwendeten Komponenten dienen, die ihr natürlich überall anders ordern könnt.

• 4x 8×8 WS2812B LED Matrix (5V) (=> Aliexpress)
• 1x ESP8266 D1 Mini (Clone) (=> Makershop)
• 1x Ein-/Aus-Schalter, 11×15 mm (z.B. bei eBay)
• 1x USB-Breakoutboard zur Spannungsversorgung (=> Amazon)
• 8x 1.4×3.5er Schräubchen

Neben diesen Teilen kommt natürlich noch Kabel zum Einsatz. Achtet darauf, dass dessen Durchschnitt nicht zu dünn ist, denn je nach Konfiguration können die LED in Gänze ein paar Ampere schlucken. Bedenkt dabei auch, dass ihr ein PLA-Gehäuse vor euch habt: Der verbrauchte Strom wird zu nicht kleinen Teilen auch in Abwärme verteilt. Betreibt die Matrix also bitte eher gedimt. Ich habe in der Software ein Verbrauchslimit von 850 mA konfiguriert, damit bin ich bisher gut gefahren.
Außerdem noch verwendet: PLA in grau und schwarz, 2-Komponenten-Epoxidharz zum befestigen von Front- und Rückseite, div. kleine Kabelbinder

Schaltplan

Um den Nachbau etwas zu vereinfachen, findet ihr hier einen Schaltplan zum Anschluss der Komponenten, so wie ich sie im Video verbunden habe.

3D-Druck: STL Download

Hier alle Dateien die ihr benötigt, möchtet ihr das Projekt nachdrucken. Alle Dateien wurden mit „dynaschmischer Qualität“ in 0.16mm gedruckt, bis auf die Front. Diese wurde in „Standardqualität“ mit 0.2mm gedruckt. Für den Rahmen sind Supports nötig. Ich habe es so gedruckt, dass die Rückseite unten liegt. Ich habe versucht die Form so zu optimieren, dass sich die Supports im Nachgang einfach entfernen lassen und würde behaupten, dass mir das gelungen ist. Das Gitter in dem die LED-Matrixen befestigt werden druckt auf dem Kopf liegend, also so das die Pins zum befestigen der LED-Module zuletzt gedruckt werden. Diese Pins sind sehr fragil weil filigran. Dadurch, dass mein Drucker sie nicht perfekt abrunden kann, lassen sich die Boards etwas schwer einsetzen, wie man ja auch im Video sieht. Geht da vorsichtig vor, dann geht das klar.

Links

• WLED Installationstool
• Pixel Art Converter-Dokumentation
• Pixel Art Converter Github Repository
• „Piskel“ Online Pixel Editor zum Design eigener Pixelart

Wichtige Hinweise

Bitte beachte: 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. 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 kein Expertise besitzt, aber seid clever: Informiert euch abseits meines Blogs, lasst eure Errungenschaften nicht unbeaufsichtigt laufen usw. Lernen, machen, clever sein!

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.

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

Deshalb und weil ich wissen wollte, wann meine Internetleitung „dicht“ ist baute ich mir ein kleines Tool, mit dem genau das angezeigt wird. So funktionierts: Drei 8×8-Anzeigen werden in Reihe geschaltet und angeschlossen an ein NodeMCU-Board mit ESP8266-Chip. Sehr praktisch: Das Board bringt direkt Wifi mit. Über das Wifi verbinde ich mich nämlich mit meiner Fritzbox. Hier direkt die erste Einschränkung: Euer Router muss die Informationen zur Nutzung eurer Internetverbindung im Netzwerk verfügbar machen. Die Fritzbox (und vermutlich noch zahlreiche andere Router) bieten da ein spezielles Protokoll namens TR-064 für an. Mehr dazu im Video. Aber ohne das funktioniert es nicht.

Über das Wifi ruft das Board dann recht flott getaktet immer wieder die aktuelle Bandbreitennutzung ab und stellt die Informationen in Balkendiagrammen auf den über MAX7219 angesteuerten Displays dar. Garniert wird das ganze im kleinen Rahmen mit ein paar Animationen. Das Auge will ja auch was davon haben. Auch dieses Video ist in englischer Sprache.