iot – nicht trivial

22. September 20196. Oktober 2019

Die Fackel

Blinkender Kram hat es mir angetan. Für diejenigen, die mich kennen ist das nichts Neues.
Auf dem 31c3 hat eine herumstehende LED-Fackel meine Begeisterung und den haben-wollen-Drang entfacht. Ich habe mich gleich durchgefragt und konnte den Verantwortlichen für diese optische Illumination höherer Vergnügungsordnung ausfindig machen. Er hat mich innerhalb weniger Minuten technisch auf den Stand der Dinge gebracht und mir die Funktionsweise erklärt. Klug wie ich bin konnte ich von all dem gerade mal die Internetadresse verstehen, aber darüber bin ich heute sehr froh, denn sie legte den Grundstein für die Fackel Version 2.0.

Die Fackel besteht aus einem LED-Strip vom Typ WS2812B, den man schlicht auf eine (optimalerweise leergefutterte) zylinderförmige Chipsverpackung spiralförmig aufrollt.

Man kann die Chips auch in der Packung lassen, das hat keine Auswirkungen auf die Lichtintensität, aber erhöht unnötig das Gewicht. Der „mrks“ aus Regensburg schreibt davon, ein Abflussrohr genommen zu haben. Ich habe davon abgesehen, ich finde die Fackel kommt im Bad nicht so zur Geltung. Zumal ich dafür die Fliesen von der Wand hätte klopfen müssen.

In der ursprünglichen Version von „mrks“ wird die Ansteuerung der LED’s durch einen Arduino Micro vorgenommen. D.h. der Feuereffekt wird auf einem ATmega32u4 Prozessor berechnet, der speichertechnisch mit 2.5 kb RAM schon am Limit ist.

Da ich allerdings ein Freund von über-wlan-fernsteuerbaren Dingen bin (Thema iot), war mein definiertes Ziel, die Fackel auf einem ESP8266 zum Laufen zu kriegen.

Es gab zwar Vorbehalte, dass die Berechnung auf der CPU bei eingehenden WLAN-Pakete ins Stocken geraten würde, aber diese Befürchtungen haben sich aufgrund der viel höheren Performance (und gefühlt unbegrenztem RAM) als unbegründet erwiesen.

Es hat etwas länger gedauert bis ich den Programmcode ausreichend verstanden habe um ihn entsprechend abzuändern, letztendlich ist es mir jedoch gelungen, den Algorithmus auf den ESP8266 zu portieren.

Die erste Version nach der Portierung lief also genau wie auf dem Arduino, d.h. einfach programmatisch ohne irgendwelche Features, aber durch die neuen Hardware standen ganz neue Freiheitsgrade zur Verfügung.

Das erstmal genialste an der Angelegenheit ist, dass ich nun zur Ausgabe an den LED-Strip die FastLED-Bibliothek nutzen konnte. Sie hält jede Menge Funktionen vor, um den Strip bzw. die Ausgabe anderweitig zu beeinflussen. Ich schätze beispielsweise sehr die Fähigkeit, die Stromstärke der LED’s begrenzen zu können. D.h. ich kann im Code festlegen (mittlerweile auch live), dass beim Beleuchten z.B. maximal 1 Ampère verbraucht werden darf und kann somit als Stromversorgung auch einen USB-Anschluss nutzen. Steht ein größer dimensioniertes Netzteil zu Verfügung, kann die Stromaufnahme und damit die Helligkeit auch erheblich erhöht werden. Bei 60mA mal 300 LED’s können bis zu 18 Ampère benötigt werden. Dann kann man allerdings eher von einer Sonne anstatt einer Fackel sprechen und man sollte in der Umgebung vorsichtshalber Schweißerbrillen verteilen, um Netzhautschäden zu vermeiden.

Im weiteren Verlauf konnte ich die WLAN-Fähigkeit einbinden. Das Ziel sollte sein, die Fackel um weitere Lichteffekte zu ergänzen und diese selbstverständlich per WLAN steuerbar zu machen. Dazu habe ich den Code anderer Projekte (z.B. Tweaking4all oder StefanPetrick) mit dem der Fackel ergänzt und hatte nun eine erste Möglichkeit, zwischen unterschiedlichen Effekten auszuwählen. Leider kam es in dieser Phase zu einer Unannehmlichkeit, bei der ich fast das Handtuch geworfen hätte. Es war nicht möglich, aus gewissen Effektprogrammen in Andere zu wechseln. Wieder mal nicht trivial. Gewisse Effekte, einmal gestartet, hingen fest. Das war so genannte nested loops zuzuschreiben, d.h. der Prozessor hatte sich in „Unterschleifen“ derart mit dem Licht beschäftigt, dass er nicht mehr dazu kam, nach neuen WLAN-Befehlen Ausschau zu halten. Dies ist dem Design des ESP8266 geschuldet, der üblicherweise immer wiederholend eine Grundschleife (Loop) durchläuft. In dieser Grundschleife kann er auch nach Netzverkehr schauen, aber wenn die Grundschleife nicht mehr erreicht wird, dann ist eben Essig.

Nach Lektüre diverser Seiten besteht die einzige Chance darin, den Code so umzuschreiben, dass man ein gewisses Zeitmanagement implementiert. Es führt zu einem rudimentären Multitasking. D.h. jede Unterroutine wird nur nach Verstreichen einer gewissen Laufzeit (millis) aktiviert und auch nur einmal und nicht unendlich durchlaufen. Das setzt auch wieder voraus, dass alle benutzen Variablen global weitergenutzt werden müssen. Lange Rede, kurzer Sinn, das gesamte Konzept musste umgeschrieben werden, um zukünftigen Erweiterungen durch Effekte stand zu halten. Es sind noch lange nicht alle Routinen komplett angepasst, aber es funktioniert bereits ausreichend, d.h. der Loop wird häufig genug durchlaufen, um z.B. den Netzwerkverkehr ausreichend abzuholen und auszuwerten.

Im weiteren Verlauf habe ich noch MQTT-Funktionalität implementiert. Die Effekte können also auch durch eine schicke Oberfläche wie z.B. Node-Red bedient werden. Dem Einsatz im Wohnzimmer in einem sowieso schon hochautomatisieren Heimnetz steht also nichts im Wege.

In einer der letzten Schritte habe ich eine Wifi-Manager Bibliothek eingebunden. Mit ihrer Hilfe ist es möglich, den (wlan-) unkonfigurierten ESP8266 in einer ihm unbekannten Umgebung „auszusetzen“ und dann erst das WLAN einzurichten. Dazu spannt der Chip seinen eigenen WLAN-Accesspoint auf, mit dem man sich verbinden und dann die Credentials für das lokal vorhandene WLAN eingeben kann. Befindet man sich auf „freiem Feld“, d.h. nicht in der Nähe eines nutzbaren Accesspoints, so schaltet die Fackel in den Standalone-Betrieb um und man kann die Fackel über den nun aktivieren internen Accesspoint steuern. Das macht schon Laune.

Des Weiteren ist es möglich, die Effekte auch per Button durchzuschalten. Ich habe hierfür GPIO 14 (Wemos auf D5) konfiguriert. Wird der PIN mit Ground (GND) verbunden, wird ein Interrupt ausgelöst und der Zähler um ~~(mindestens)~~ Eins hochgezählt. Es steht noch auf der Verbesserungsliste, den Button zu entprellen, denn ohne Kondensator können leider auch mehrere Trigger gezählt werden, und bisher bekomme ich das programmtechnisch nicht zuverlässig abgefangen. D.h. wenn man den Button drückt, kann auch mehrere Effekt vorgesprungen werden, was eher einem Effekt-Lotto gleicht. Mittlerweile ist der Taster auch entprellt, was für mich nicht trivial war, da speziell bei der Nutzung des Interrupts Einiges zu beachten ist.

Wenn man GPIO 5 (D1) auf Ground zieht, werden die WLAN-Daten gelöscht und man kann es neu konfigurieren.

Die Software

Wer sich nun durch den Text gequält hat, entweder Fragezeichen, Ausrufezeichen oder Sternchen im Hirn hat, der darf endlich zum Herzstück des Ganzen übergehen, dem Code:

https://github.com/cruisinger/FireTorchESP

Der Code ist in Github abgelegt und ich bitte um Weiterentwicklung (z.B. per Pull-Requests) durch Erweiterung oder auch gerne durch Korrektur.

Die Hardware

Was die Hardware angeht, so werden folgende paar Teile benötigt:
1 x ESP8266 , ich bevorzuge das Wemos D1 Modul.
1 x WS2812B LED Strip , hier erhältlich
1 x Pegelwandler , hier erhältlich, oder hier
1 x Protoboard , hier erhältlich
1 x JST SM Adapter (3-polig)
2-3 x Mikro Taster als Effektumschalter, etc.
1 x 220µF Elko, zur Spannungsstabilisierung am Spannungseingang
1 x 1000µF Elko, zur Spannungsstabilisierung am LED-Strip
~~2-3 x 0,1µF Kondensator zum Entprellen der Taster~~

Zusammengebaut kann das Ganze dann so aussehen:

Was die Stromversorgung anbelangt, so sollte man sich ein ausreichend dimensioniertes Netzteil besorgen. Wenn man nicht den gesamten Raum zum Lesen ausleuchten will reicht für reine Effekte durchaus ein Netzteil mit 4 bis 5 Ampère aus. Die Fackel (als der Effekt/das Programm) leuchtet z.B. auch bei 1000 mA schon sehr eindrucksvoll. Für die volle Power sollten 18A ran, das wird aber auch dann entsprechend teuer. Den Stromverbrauch kann man – wie oben beschrieben – per Software ja begrenzen. Bei Unterdimensionierung sollte man noch eine Schmelzsicherung vorschalten.

Und wenn man das Ganze über Akku betreiben möchte, dann sollte man sich neben 2-4S LiPo Akku noch einen Step-Down Wandler zulegen. Ich habe gute Erfahrung mit Folgendem:
75W/5A Wandler
Bedenken sollte man auch Anschlussstecker und Zuleitung. Ich selbst nutze Deans-Stecker. Es gibt aber auch etliche andere Adapter.

Die Schaltung

Ein Bild sagt mehr als tausend Worte. Hier ist die Verschaltung:

Weitere Wünsche:
GUI mit responsive Design
Spannung der Batterie anzeigen, Unterspannungsabschaltung
Texte anzeigen
konfigurierbarer (Speech-) Timer
~~Debouncing der Taster~~
OTA – Firmware über WLAN flashbar machen
MSGEQ7 Sound Equilizer optional nutzen

Links:
A beginner’s guide to the ESP8266
http://esp8266-server.de/Tipps.html
http://werner.rothschopf.net/201809_arduino_esp8266_server_client_1.htm
https://jorgen-vikinggod.github.io/LEDMatrix/

14. Februar 201818. November 2020

Ritto over IP

Es war schon lange ein Wunsch von mir, darüber informiert zu werden, wenn der Postbote geklingelt hat. Bzw. wenn er nicht geklingelt hat.

Die Lösung zu dieser Aufgabe konnte ich nun endlich durch Vorarbeit anderer Bastler (Link funktioniert 2020 nicht mehr) und Dokumentierer fertig stellen: Ein ausgefeilter Hack der Ritto Türsprechanlage, der das Klingelsignal abgreift, per WLAN an MQTT meldet und auf dem Rückweg obendrein noch ermöglicht, den Türöffner von entfernt zu betätigen. Wie geil ist das eigentlich?

Bei dem bei uns verbauten Modell handelt es sich um ein Ritto Wohntelefon Twinbus 7630. Vermutlich wird der Eingriff jedoch auch bei ähnlichen Modellen funktionieren. Im Notfall kann man den Pins einfach mal mit dem Multimeter auf die Pelle rücken und nachmessen, ob sich spannungsmäßig etwas tut, wenn man klingelt.

Die Weiterentwicklung gegenüber der „Version“ meines Vorgängers besteht hauptsächtlich darin, dass dieses Modul nun auch von der Gesamtanlage gespeist wird, d.h. es ist keine weitere Stromversorgung notwendig. Wer würde auch sonst eine extra Leitung zum „Wohntelefon“ (was ein däml…. Name *Anm. d. Red.) legen, der Aufwand rentiert in den meisten Fällen schlicht nicht. Und Batteriebetrieb fällt sowieso schon mal ganz aus, es sei denn, man hat den seltenen Hang zum permaneten Akkuwechsel.
Das ESP-Modul samt Anhang über den Twinbus „schmarotzenderweise“ zu speisen ist im Übrigen wieder mal eine Angelegenheit der Kategorie „nicht trivial„. Wie in vielen Foren zu lesen ist, ist das gesamte Twinbus-System ziemlich zimperlich, was Eingriffe angeht und alles andere als robust. Die ganzen Warnungen, tunlichst die Finger davon zu lassen, es sei denn, man sei darauf aus, die Gegensprechanlage für das gesamte Haus lahm zu legen (inkl. der Kosten für den Technikereinsatz danach) rief selbstverständlich meine Neugierde auf den Plan.

Um Haftungsfragen auszuschließen, hier mein Disclaimer: Diese Dokumentation ist kein Aufruf zum Nachbau. Dass dieser Hack bei mir seit nun gut drei Jahren funktioniert ist keine Gewähr dafür, dass es nicht doch zu Schäden an der Ritto-Anlage kommen kann. D.h. jeder Nachbau erfolgt immer auf eigenes Risiko und eigene Verantwortung!

Die Platine bietet 24V an Kontakt Nr.5, das NodeMCU Board braucht 5V. Also braucht’s einen Spannungsregler. Testweise habe ich erst mal einen dumpfen 7805 genommen, der den Spannungsabfall einfach in Wärme verbrät.

Der wurde aber auch wegen der hohen Differenz von 19V bei den maximal 260mA ordentlich heiß. Hätte funktioniert, aber mangels Konvektionsmöglichkeit habe ich davon abgesehen. Außerdem bin ich auch nicht der Typ, der den Bug zum Feature macht alla „Hey, unser Wohntelefon hat noch eine Fingerwärmfunktion“.
Probiert habe ich also noch einen DC-DC Wandler (TracoPower TSR 1-2450 24 V/DC 5 V/DC 1 A 6 W), der mit der Anlage nicht funktionierte, aber der Zweite tut seine Arbeit perfekt. Es ist ein „FISM Fixed Isolated Modul“ (Würth Elektronik 177920531 24 V 5 V 0.2 A 1 W), macht zwar dauerhaft nur 200mA mit, aber für 5 Sekunden auch 300mA und sollte damit für die Stromspitzen ausreichen.

Davon abgesehen sollte ein obligatorischer Kondensator auch die Spitzen abfangen. Das Teil ist nun auch schon ein Jahr in Betrieb und funktioniert tadellos, nicht mal der Prozessor ESP8266 ist abgeschmiert.

Zur Übertragung des Klingelsignals ins WLAN habe ich mich für ein NodeMCU entschieden, da ich damit „quick & dirty“ schnell zum Ziel komme.

Es gibt auch elegantere oder schlankere Lösungen.

Heute würde ich nur noch ein ESP12F-Modul nehmen und gleich einen 24V->3,3V DC/DC Wandler davor setzen.

Ein ESP12 hat halt keine Spannungswandlung, keinen Serial-zu-USB-Chip (UART) und auch keine Flash-Logik. Diese Funktionen sind auf dem NodeMCU-Board „drumrum“ gebaut und erleichtern den Einstieg. Durch seine Verwendung kann ich zukünftig wesentlich einfacher Updates über die USB-Schnittstelle einspielen, sollte mal beim OTA-Update (über WLAN) etwas schief laufen.

Die selbe Funktionalität bietet übrigens auch ein Wemos D1-Board, falls das jemand noch nicht kennt.

Zur Ritto-Platine zurück: Mitte oben befindet sich die 24V Speisespannung für das WLAN-Modul und am Pin in der Mitte das Klingelsignal. Wenn jemand die Klingel betätigt, liegen dort 5 Volt an, die man auswerten kann. Der linke der drei Pins in Ground.

Unten rechts befinden sich die beiden Kontakte um den Türöffner zu betätigen. Diese kann man mit einem CMOS 4066, eine Art elektronisches Relais, durchschalten. Das kommt dem Tastendruck am Gerät gleich.

Umgekehrt funktioniert das Durchschalten per CMOS4066 zum ESP3266 leider nicht, da die Schaltzustände bei dieser elektronischen Variante sich nur in einer größeren Änderung des Widerstands unterscheiden. D.h. bei „Aus“ ist beim 4066 der Widerstand nicht unendlich und bei „Ein“ ist der Widerstand nicht gleich Null. Welchen Wert diese Widerstände haben, hängt mit der Speisespannung zusammen und ist nicht linear. Also muss eine andere Möglichkeit her, um den GPIO Pin zu schalten.

Diese Aufgabe kann man per Transistor bewältigen, indem man D2 auf Ground bzw. Low Level zieht. Wenn am Klingelkontakt die 5 V anliegen, wird der Transistor leitend und welchselt am GPIO D2 den Level. Ich habe einen BC547B genommen, aber ich gehe davon aus, dass auch sonst fast jeder übliche NPN-Transistor funktioniert. Davor ist zum Kingelkontakt ein 1 kΩ Widerstand.

Zur Stabilisierung und Entstörung habe ich noch einen 470 μF Kondensator hinter den DC-DC Wandler gehängt.

Die Schaltung kurz aufskizziert:

Der Versuchsaufbau auf dem Breadboard sieht folgendermaßen aus:

… und zum Testen muss die Schaltung natürlich auch an die Anlage:

Was bisher fehlt, ist die Software. Ich habe mich für die Firmware „Tasmota“ von Theo Arends entschieden.

mehr zu Tasmota:

Beim Einsatz von Tasmota (getestet mit Version 6.5.0.15) sind einige Einstellungen zu konfigurieren: Als Modul-Typ ist „Generic (18)“ für den ESP12 die richtige Wahl. An PIN D2 (GPIO4) ist der Klingelknopf verbunden und muss als „Button1 (17)“ eingestellt werden. Der Türöffner ist an PIN D1 (GPIO5) gelötet und sollte den Wert „Relay1 (21)“ erhalten. Damit die Tür nicht automatisch öffnet wenn jemand die Klingel drückt, muss die standardmäßige Verbindung zwischen Button1 und Relay1 softwaretechnisch unterbrochen werden (sonst wird das Relais aktiviert, wenn man den „Knopf“ drückt). Diese geschieht durch Setzen eines „buttontopic bell“-Befehls in der Console. Damit das Relais bei Aktivierung auch wieder selbsttätig loslässt muss zusätzlich der Befehl „Pulsetime 5“ (5 Sekunden Haltezeit) in der Konsole gesetzt werden.

siehe auch:
https://github.com/arendst/Sonoff-Tasmota/wiki/Button-usage#multi-press-functions

Ergänzung Juni 2019:

Die Tür öffne ich per mqtt topic „cmnd/Door/POWER1“ mit Payload „ON“.
Das Klingeln wird mir gemeldet über topic „cmnd/bell/POWER“ (bell wegen dem veränderten Buttontopic) mit Payload „TOGGLE“. Das Ganze werte ich über Node-Red aus und lasse per Pushover eine Benachrichtigung an mich verschicken.

Ergänzung November 2020:

Es ist sinnvoll, mindestens bei Verwendung von Tasmota als ESP-Firmware, die „Sleep-Funktion“ zu aktivieren. Sofern diese nicht mittlerweile standardmäßig (dynamic sleep) aktiv ist. Das reduziert den Stromverbrauch um mindestens die Hälfte!
Wer sich die Firmware selbst programmiert, sollte dies auch berücksichtigen.

Selbstverständlich kann man mit ein paar Bibliotheken relativ schnell selbst etwas zusammenschustern, aber das Angebot von Theo hat alles an Board, was man benötigt. Wer im ersten Step (noch) keine Lust auf das volle Paket mit MQTT und Node-Red hat, der kann den Türöffner erst mal nur über das Webfrontend steuern, welches sogar „responsive design’t“ ist und damit auch auf dem Smartphone schlank aussieht.

Das gesamte Konstrukt vom Breadboard habe ich, nach Versicherung dass auch alles funktioniert, schlicht auf einer Lochrasterplatine eingelötet. Bei einer nächsten Version würde ich vielleicht eine extra Platine fertigen lassen, aber es funktioniert auch so einwandfrei.

Richtig interessant wird die Sache, wenn man sich nun noch einen MQTT-Server mit z.B. Node-Red gönnt. Zugegebenermaßen ist das alles am Anfang natürlich etwas viel, aber mancher Bastler hat ja schon einen Teil der Infrastruktur zu Hause. Und MQTT ist nun wirklich nicht die Hürde. Es ist mit „apt-get install mosquitto“ ruckzuck auf Debian installiert und funktioniert danach einfach nur noch. -> Ja, der Satz ist zu Ende. Es tut was es soll und ist wartungsarm.
Als Server(-hardware) nutze ist selbst (aus Performancegründen) einen Intel NUC5CPYH, weil er einen AES-NI Chip und ausreichend Power/RAM hat, um immer alles „schnell mal noch“ drauf zu packen. Wer bereit ist, mehr mit Ressourcen zu haushalten kann auf den doch wesentlich günstigeren Raspberry 3b zurück greifen. Ein Einrichtungstutorial ist hier. Für die Einrichtung von Node-Red mit node.js unter Debian empfehle ich diese Anleitung. Zusätzliche Hinweise wegen dem begrenzten Arbeitsspeicher auf dem Raspberry Pi finden sich in diesen Artikel von Markus Ulsass.

Um letztendlich über das eigentliche Klingeln an der Tür benachrichtigt zu werden setze ich den Dienst Pushover, aufsetzend auf Node-Red, ein.

Da das ausführliche Beschreiben aller beteiligten Komponenten über die Hardware hinaus diesen Artikel sprengen würde, habe ich oben die wichtigsten Punkte gegen aussagekräftige Hilfeseiten verlinkt. Ich wünsche somit viel Spaß bei Nachbauen (wieder der Hinweis aus rechtlichen Gründen: NICHT NACHBAUEN) und freue mich auch über Feedback oder Verbesserungsvorschläge.