ESP32S Stromversorgung über 5V Pin

Bei einem Bastelprojekt (OpenDTU) mit einem ESP32 (genauer: DUBEUYEW SP-Cow ESP32 NodeMCU-32S ESP-WROOM-32 mit 38 Pins und USB-C) ist mir ein Fehler passiert. Diesen Fehler zu finden hat lange gedauert und nur irgendein Kommentar in einem Forum hat mich auf die Lösung gebracht. Falls noch jemand den gleichen Fehler macht, geht es hiermit vielleicht schneller zu einer Lösung.

Das war die Aufgabe: Ein ESP32 sollte zusammen mit einem SMD-Funkmodul in ein wasserdichtes Gehäuse eingebaut werden. Zur Stromversorgung sollte ein USB-Kabel dienen. Um Platz im Gehäuse zu sparen hab ich den Stecker abgeschnitten, um die 5V direkt an den 5V- und GND-Pin anzuschließen. Beim Testbetrieb (noch ohne Gehäuse) mit Stromversorgung über USB-C hat alles einwandfrei funktioniert. Gleich nach dem Einstecken leuchtet eine rote LED und kurz danach sieht man das OpenDTU WLAN und der ESP meldet sich im Heim-WLAN an (wenn man das schon konfiguriert hat).

Das Problem: Nach dem Einbau ins Gehäuse und dem Umstellen auf die 5V-Spannungsversorgung ging nichts mehr. Die rote LED war an, aber sonst nichts, kein OpenDTU WLAN und keine Anmeldung im Heim-WLAN. Und der ESP32 (also der große Chip in der Mitte) wurde relativ schnell heiß. Und das obwohl der 5V-Pin für Spannungen von 5 bis 12V gemacht ist.

Der Fehler: Ich hab beim Verkabeln nur auf die Beschriftung am ESP-Board geschaut, nicht auf die Pin-Out-Dokumentation (alles was ich als „Doku“ finden konnte war ein Bild bei Amazon). Und leider ist die Beschriftung am Board falsch. Der PIN direkt neben dem 5V ist nämlich nicht wie vermutet ein GND-Pin, sondern CMD. Am Board steht CND, was auch immer das sein soll. Leider dachte ich, das wäre der GND, auch weil es andere 38-Pin ESPs gibt, bei denen tatsächlich GND direkt neben dem 5V-Pin ist.

Kaum war GND an den richtigen Pin angeschlossen, schon hat alles funktioniert. Und das Board hat es auch überlebt.

Bild des ESP32-WROOM-32 von DUBEUYEW
Bild des ESP32-WROOM-32 von DUBEUYEW
ESP-32S, fehlerhafte Beschriftung neben 5V Pin
Hier steht CND, richtig wäre CMD. Leicht zu verwechseln mit GND.

Grafana: Bezeichnung (Label) für Werte ändern

Seit einiger Zeit nutze ich Grafana zum Erstellen grafischer Auswertungen und Dashboards. Die angezeigten Daten kommen aus einer InfluxDB. Dadurch sind die Bezeichnungen (Labels) der Werte in der Legende entweder „value“ (wenn nur ein Wert angezeigt wird) oder der Name des Measurements. Vor allem letzteres ist oft recht unschön, weil es sich um längere, zusammengesetzte Namen handelt. Man kann den angezeigten Namen sehr einfach ändern, man muss nur wissen wie:

  • Rechts oben „Overrides“ auswählen.
  • + Add field override
  • „Field with name“, dort den zu ersetzenden Namen auswählen.
  • + Add override property, dort „Standard options > Display name“ auswählen
  • Im Textfeld die neue Bezeichnung eingeben.

TP-Link HS 110 – Energieverbrauch zeigt nichts an

Ich nutze seit einiger Zeit mehrere Wifi-Steckdosen des Herstellers TP-Link vom Typ HS110. Damit kann man Elektrogeräte über WLAN ein- und ausschalten und den Energieverbrauch überwachen. Das funktioniert auch mit der Programmiersprache PHP und das gefällt mir. Eine der Steckdosen nutze ich zur automatischen Überwachung meines Gefrierschranks: Ist der Energieverbrauch über mehrere Stunden zu hoch oder zu niedrig, dann stimmt eventuell etwas nicht (Tür offen?).

Irgendwann Ende 2021 hat das allerdings nicht mehr funktioniert. Der Energieverbrauch zeigte keine Werte mehr an, weder in der Kasa App noch über die PHP-API. Allerdings nur bei einer der Steckdosen. Ich hab die Steckdosen zu unterschiedlichen Zeitpunkten bestellt und daher verschiedene Hardware-Versionen im Einsatz. Die Steckdose mit dem Problem hat die Hardware-Version 2.0 und die Firmware 1.5.4.

Mir ist dann aufgefallen, dass die Steckdose in der Kasa App kein sinnvolles Datum eingestellt hatte und es war auch nicht möglich, das Datum zu aktualisieren. Das Problem war, dass sich die Steckdose das Datum und die aktuelle Uhrzeit direkt aus dem Internet holen will (NTP: Network Time Protocol). Allerdings hatte ich die Steckdosen über die FritzBox gesperrt, so dass diese sich Datum und Uhrzeit nicht holen konnten. Die Sperre hatte ich gemacht um die Steckdosen daran zu hindern, irgendwelche Daten zurück an den Hersteller oder sonst irgendwo hin zu senden.

Ein kurzer Test bestätigte: Sobald die Sperre aufgehoben wird, holt sich die Steckdose das aktuelle Datum und die Uhrzeit. Damit funktioniert dann auch die Energieverbrauchsanzeige wieder.

Da ich den Internet-Zugriff für die Steckdoesen trotzdem beschränken wollte, hab ich für die Steckdosen ein eigenes Zugriffsprofil angelegt. Das geht bei einer FritzBox 7560 ganz einfach, bei anderen Modellen ist das vermutlich ähnlich.

Zunächst unter Internet > Filter > Listen eine Netzwerkanwendung „Alles außer NTP“ anlegen (dem Namen kann man frei wählen). Dort folgendes eintragen:

  • TCP, Quellport beliebig, Zielport beliebig
  • UDP Quellport beliebig, Zielport 1 – 122
  • UDP Quellport beliebig, Zielport 124 – 65535

Damit bleibt nur UDP 123 übrig, das ist der Port, über den das NTP-Protokoll läuft.

Jetzt kann man ein neues Zugriffsprofil anlegen und ihm einen Namen geben, z.B. TPHS110. Als gesperrte Netzwerkanwendungen wird das zuvor angelegte „Alles außer NTP“ ausgwählt. Damit dürfen Geräte mit diesem Profil nur noch über UDP auf den Zielport 123 zugreifen, also nur noch NTP.

Über den Internetseiten-Filter hab ich zusätzlich noch „nur bestimmte Seiten erlauben“ ausgewählt und die Seite cn.pool.net.org eingetragen, das ist der Server von dem sich die TP-Link Steckdosen Datum und Uhrzeit holen. Ob das nur für Internetseiten (also http über Port 80) gilt oder ob damit all Protokolle und Ports mit anderen Server-Namen gesperrt sind, weiß ich nicht.

Das Profil TPHS110 hab ich allen TP-Link Steckdosen zugewiesen, seitdem funktioniert der Energieverbrauchsmonitor wieder auf allen Geräten.

Signal-Cli: User is not registered.

Today I installed signal-cli to send messages from an Ubuntu server to the signal messenger on my cellphone. Everything worked fine, installation, user registration and verification. I did all this with my own (low privilege) user account.

As the next step I wanted to send messages with PHP by calling the signal-cli binary with system(). Therefore the Apache-user www-data needs to have the information about the registered signal account. It is stored in my own user’s home directory in ~/.local/share/signal-cli. There is a sub-directory called data, it contains one file for each registered phone number (the filename is the phone number). I copied the directory „data“ to a place where apache can find it (let’s say /opt/signal-cli/data). Then I tried to send messages with a command like this:

/usr/local/bin/signal-cli --config /opt/signal-cli/data -u +49123456789 send -m 'Hello World' +49987654321

That does not work, the error message will be „User is not registered.“

It took a while until I noticed my mistake: The config parameter should only be the basic directory for the signal configuration. There signal-cli expects a subdirectory „data“. So the right way to call signal-cli is this:

/usr/local/bin/signal-cli --config /opt/signal-cli -u +49123456789 send -m 'Hello World' +49987654321

WhatsApp Nachrichten auf ein anderes Smartphone kopieren

Bei einem neuen Smartphone will man normalerweise nicht mit einem leeren WhatsApp anfangen, sondern die Nachrichten, Bilder und alles andere vom alten Telefon kopieren. Das geht theoretisch ganz einfach und man findet diverse Anleitungen dazu im Netz. Kurz zusammengefasst:

  • Mit dem alten Telefon in den Flugmodus gehen, damit WhatsApp keine Daten mehr bekommt.
  • Vom alten Telefon den Ordner „WhatsApp“ vom Internen Telefonspeicher kopieren (z.B. über USB auf einen PC).
  • Den kompletten Ordner auf das neue Telefon kopieren.
  • Am neuen Telefon WhatsApp installieren und die Nachrichten wiederherstellen.
  • Wenn alles passt, dann vom alten Telefon WhatsApp deinstallieren, damit man Nachrichten nur noch am neuen Telefon bekommt.

Dummerweise vergessen die meisten Anleitungen, dass die neuesten WhatsApp-Nachrichten dann normalerweise nicht übertragen werden. WhatsApp speichert die Nachrichten nämlich nicht sofort in seiner Nachrichtendatei, sondern nur alle paar Stunden (bei mir war es einmal täglich, irgendwann nachts). Das sieht man auch am Änderungszeitpunkt der Nachrichtendatei (/WhatsApp/Databases/msgstore.db.crypt12).

Die Lösung ist ganz einfach: Bevor man die Dateien kopiert, geht man in die WhatsApp Einstellungen, dort auf „Chats“ und dort auf „Chats-Backup“. Unter „Letztes Backup“ sieht man, wann das letzte Backup gemacht wurde. Einfach auf den Button „Sichern“ klicken, dann schreibt WhatsApp auch die neuesten Nachrichten in die Nachrichtendatei msgstore.db.crypt12. Jetzt kopiert man die Dateien wie oben beschrieben.

Externe Domainnamen im internen Netz verwenden

Dieser Blog-Eintrag beschreibt ein paar kleine Problem, die man haben kann, wenn man mit dem Handy oder Tablet auf die Inhalte eines Servers im lokalen Netzwerk zugreifen und dabei den externen Hostnamen verwenden will.

Wenn man ein Webserver zu hause hat, dann hat man für diesen in der Regel auch einen externen Hostnamen, damit dieser aus dem Internet über diesen Hostnamen erreichbar ist (z.B. meinserver.example.com). So kann man dann von unterwegs zum Beispiel auf OwnCloud, NextCloud, E-Mails oder was auch immer zugreifen. Dafür gibt es ja diverse Möglichkeiten, z.B. über DynDNS Service oder für Besitzer einer FritzBox über MyFritz. Wenn man zu hause ist (also im eignen LAN/WLAN) sollte dieser Zugriff natürlich auch einwandfrei funktionieren. Damit meine ich, dass man den Server auch intern über seinen Hostnamen erreicht und diese Verbindung ausschließlich über das interne Netz erfolgt. Das hat dann diverse Vorteile:

  • SSL-Zertifikate für verschlüsselte Verbindungen (z.B. von Let’s Encrypt), können auch im eigenen Netz verwendet werden. Diese Zertifikate sind für den externen Hostname ausgestellt, also z.B. meinserver.example.com. Würde man intern über einen anderen Hostnamen oder die lokale IP-Adresse zugreifen, würde der Browser eine Fehlermeldung wegen dem ungültigen Hostnamen anzeigen (Firefox: SSL_ERROR_BAD_CERT_DOMAIN).
  • Man braucht am Mobilgeräte keine zwei Konfigurationen für interne und externe Zugriffe, z.B. für Datei-Synchronisation oder automatische Backups.
  • Man kann Dienste nutzen, die nur im lokalen Netz zur Verfügung gestellt werden und die extern nicht erreichbar sein sollen (z.B. die Smart-Home-Steuerung).
  • Lokale Zugriffe sind deutlich schneller, dazu gleich mehr.

Mir sind dabei ein paar Probleme aufgefallen, deren Lösung ich hier kurz beschreiben möchte.

Das erste Problem ist mir bei OwnCloud aufgefallen. Über die App „FolderSync“ wollte ich von meinem Handy Backups auf OwnCoud sichern (über WebDav). Das war allerdings unglaublich langsam. Bei NextCloud war es das gleiche Problem. Auch andere Sync-Apps hatten das Problem. Wenn ich von meinem PC über WebDav Dateien auf OwnCloud oder NextCloud kopiert habe, war es schnell. Es musste also etwas mit der Verbindung von Handy zum Server zu tun haben. Die Logfiles vom Webserver haben mich dann auf die Ursache gebracht: Die Android-Geräte haben sich mit einer externen IP-Adresse zum Server verbunden. Wie kommt es dazu?

  1. Das Mobilgerät erhält seine IP-Adresse, Gateway und DNS-Server über DHCP vom Router (in meinem Fall eine Fritzbox). DNS-Server ist der Router.
  2. Beim Verbindungsaufbau zu meinserver.example.com fragt das Mobilgerät seinen DNS-Server (den Router) nach der IP-Adresse.
  3. Der Router kennt nur den internen Namen des Servers und fragt daher bei einem externen DNS-Servern nach.
  4. Dieser liefert die externe IP-Adresse zurück, die man momentan hat.
  5. Das Mobilgerät macht den Verbindungaufbau über die externe IP-Adresse. Damit verlässt sämtlicher Netzwerktraffic erst das lokale Netz, geht zum ersten Router des Providers und geht dann wieder zurück über den eigenen Router ins lokale Netz.

Ich musste also den Mobilgeräten irgendwie beibringen, dass der externe Hostname über die interne IP-Adresse viel schneller erreichbar ist als über die externe IP. Die einfachste Möglichkeit wäre eigentlich, wenn man den Hostname des Servers direkt am Router einstellen könnte. Dann könnte der die Frage nach der IP direkt beantworten. Zumindest die FritzBox kann das aber nicht, weil im Hostname keine Punkte erlaubt sind. Die Lösung war für mich DNSMASQ, ein kleiner DNS-Server, der am Server installiert wird und der die Frage nach seinem Hostname direkt mit seiner lokalen IP beantwortet (Testen unter Linux z.B. mit dig @meinserver meinserver.example.com, die Antwort sollte die lokale IP-Adresse sein, z.B. 192.168.0.2). Über die FritzBox kann man festlegen, dass alle Geräte, die ihre Netzwerkeinstellungen per DHCP erhalten, einen bestimmten DNS-Server nutzen sollen. Dort einfach die lokale IP-Adresse des Servers eintragen, auf dem DNSMASQ läuft (zweiter DNS-Server wird die FritzBox selbst).

Das zweite Problem hatte ich nach der Umstellung auf VDSL: Mit der neuen FritzBox 7560 hat das alles nicht mehr funktioniert, obwohl es noch so konfiguriert war, wie zuvor. Zumindest dachte ich das. Sämtliche Android-Mobilgeräte nutzten wieder die externe IP-Adresse. Mit den Apps „Ping & DNS“ und „DNS Debugger“ hab ich dann auch den Grund dafür gefunden: Über die neue FritzBox haben die Mobilgeräte IPv6-Netzwerkadressen erhalten und damit auch den eignen DNS-Server ignoriert. Die Lösung war in diesem Fall ganz einfach: IPv6 in der FritzBox abschalten und schon funktioniert es wieder wie zuvor.

Android: HTML-Datei von SD-Karte mit Chrome öffnen

Wenn man unter Android HTML-Dateien auf der SD-Karte hat, kann man diese über den Datei-Explorer nur in der HTML-Anzeige öffnen. Damit kann man aber nicht viel machen, z.B. keine anderen lokal verlinkten Dateien öffnen. Es gibt leider keine Möglichkeit, eine HTML-Datei direkt aus dem Explorer in Chrome zu öffnen, ohne eine App dafür zu installieren. Die App „Open in Browser“ kann das angeblich, ich hab das aber nicht getestet.

Es gibt aber eine einfache Möglichkeit, eine HTML-Datei in Chrome zu öffnen. Man muss nur die lokale URI wissen und einmal eingeben. Das kann man sich für später dann einfach als Lesezeichen speichern. Hier ein Beispiel: Wenn die Datei index.html auf der SD-Karte im Unter-Verzeichnis my_documents/test liegt (komplette URI: /storage/emulated/sdcard/my_documents/test/index.html), dann muss man folgendes in die Adresszeile von Chrome eingeben:

file:///sdcard/my_documents/test/index.html

Wichtig sind die drei „/“ hinter file:, wenn man hier (wie normalerweise üblich) nur zwei Slashes angibt, bekommt man die Meldung „Der Zugriff auf die Datei wurde verweigert“ (ERR_ACCESS_DENIED).

Ich nutze das für einige HTML-Dateien, die untereinander verlinkt sind und die regelmäßig mit FolderSync auf mein Mobiltelefon kopiert werden. Somit hab ich die Daten auch offline verfügbar. Und die Links von einer HTML-Datei zur nächsten funktionieren auch.

Getestet unter Android 7.1.1, vermutlich geht das mit früheren Versionen genauso.

Ubuntu 16.10: Größe der Icons am Desktop ändern

Mit dem Update von Ubuntu 16.04 auf 16.10 kommt auch eine neue Version des Dateimanagers Nautilus. Bei mir hatte das unter anderem die Folge, dass die Symbole am Desktop („Ubuntu Schreibtisch“) sehr groß dargestellt wurden. Direkt in den Einstellungen vom Nautilus habe ich nichts gefunden wie man die Icons wieder verkleinern kann. Die Icon-Größe in Nautilus konnte ich einstellen, aber das hatte keine Auswirkungen auf den Desktop.

Die Lösung war das kleine Hilfsprogramm dconf-editor (über Unity Dash oder einfach im Terminal starten). Auf der linken Seite öffnet man folgenden Pfad: org / gnome / nautilus / icon-view und dort stellt man den "default-zoom-level" auf "small". Wie der Name schon sagt, hat das auch Auswirkungen auf die Icon-Größe in der Symbolansicht von Nautilus. Mich stört das nicht, da ich fast ausschließlich die Listen-Ansicht verwende. Und außerdem bevorzuge ich den Dateimanager Nemo (so ähnlich wie Nautilus, nur besser), auf den hat diese Einstellung keine Auswirkung.

Screenshot dconf-editor
Screenshot dconf-editor

Full filesystem without content?

Since a few days I had a problem on my Ubuntu machine that I use at home: After logging in, the system showed a warning, that /tmp was nearly full. Checking it with df -h showed that over 95% of 10 gigabyte were used. But sudo du -hs /tmp/ showed that only 5 megabyte were used by files. /tmp has it’s own partition and uses the XFS filesystem. On askubuntu.com and serverfault.com I found some promising problem descriptions and possible solutions, but none of them fit for me. Finally xfs_repair solved the problem. For this you need to unmount /tmp, so I did this:

  • Edit /etc/fstab so that the tmp-partition will not be mounted on next boot (put „#“ at the beginning of the line that mounts /tmp)
  • Reboot, /tmp is now part of the root filesystem /.
  • Call sudo xfs_repair /dev/sdxY (replace sdxY by whatever your tmp-partition is).
  • Mount the partition somewhere temporarily (for example /mnt/tmp) and check with df -h if this solved the problem.
  • Edit /etc/fstab again to reactivate the tmp-partition. Then reboot and check again.

Funksteckdosen von REV Ritter über 433MHz schalten

Heute habe ich versucht eine paar Funksteckdosen von REV Ritter mit einem 433MHz Sendermodul (FS1000A) und einem Banana Pi zu schalten. Mit einem Raspberry Pi sollte es genauso funktionieren. Die Steckdosen mit der Artikelnummer 00834514 gibt es für ca. 15 Euro in Baumärkten oder bei Amazon (3 Steckdosen und eine Fernbedienung). Im Gegensatz zu meinen anderen Funksteckdosen von Mumbi (m-AFS102) kann man bei den REV-Steckdosen die Funk-Kennung nicht selbst einstellen. Man muss also zuerst mal ermitteln, welche Daten die Fernbedienung sendet. Dazu habe ich das Empfängermodul (XY-MK-5V) angeschlossen (VCC auf Pin 1, GND auf Pin 6, DATA auf Pin 12), die Software pilight nach dieser Anleitung installiert und den Service mit service pilight start gestartet. Dann einfach pilight-receive aufrufen, auf eine Taste der Fernbedienung drücken und die Ausgaben prüfen. Bei mir sah das ungefähr so aus:


{
"message": {
"id": 12345678,
"unit": 15,
"state": "on"
},
"origin": "receiver",
"protocol": "arctech_switch",
"uuid": "0000-01-23-45-1234ab",
"repeats": 2
}

Der gleiche Message-Block wurde mehrmals wiederholt, abwechselnd mit den Protokollen arctech_switch und arctech_contact. Zum Senden hab ich das Empfänger-Modul entfernt und das Sender-Modul angeschlossen (VCC auf Pin 1, GND auf Pin 6, DATA auf Pin 11). Jetzt musste ich nur noch das passende Protokoll finden, denn pilight-send hat kein offensichtlich passendes Protokoll angeboten. Funktioniert hat es dann mit dem Protokoll kaku_screen. Mit folgendem Befehl konnte ich dann die Steckdosen schalten:


# An
pilight-send -p kaku_screen -u 15 -i 12345678 -t
# Aus
pilight-send -p kaku_screen -u 15 -i 12345678 -f