Uwe Berger

Elektronik-Bastler, die sich mit Mikrocontrollern beschäftigen, kennen bestimmt das Problem. Man hat eine coole Idee für ein Sensormodul, eine kleine Steuerung o.ä.. Schaut man aber in die Datenblätter der ausgesuchten Hardwarekomponenten, stellt sich die Frage, wie der rechnerisch hohe Stromverbrauch so in den Griff zu bekommen ist, dass die Schaltung möglichst lange autark, ohne „täglich“ Batterien wechseln zu müssen, arbeiten könnte. Im Rahmen des Vortrages wird die Herangehensweise an eine solche Fragestellung und deren praktische Umsetzung aufgezeigt.

In einem früheren Vortrag des Autors wurde dieses Thema vor allem theoretisch betrachtet. Es sollte damals aufgezeigt werden, dass mit geeigneten Programmiertechniken und Softwarestrukturen die aktive Laufzeit von Mikrocontroller-Firmware so beeinflusst werden kann, dass diese möglichst stromsparend arbeitet. Aber können solche softwaretechnischen Optimierungen auch wirklich, mit einfachen „Hausmitteln“, quantitativ gemessen werden? Ausgangspunkt war ein Sensormodul, welches via WLAN diverse Messwerte an ein Basissystem senden sollte. Es war geplant, dafür einen ESP-Mikrocontroller als zentrale Einheit einzusetzen. Am vorgesehenen Einsatzort dieses Moduls befand sich keine Steckdose. Die Errichtung einer Solaranlage mit „fettem“ Stromspeicher war keine Option. Für die Optimierung der Firmware des Sensormoduls wurde parallel eine einfache Schaltung zur Messung des Stromverbrauchs über die Zeit und entsprechende Software zur Visualisierung aufgebaut bzw. implementiert. Mit Hilfe dieses Messsystems war es dann komfortabel möglich, die „stromfressenden“ Programmlaufzeiten des eigentlichen Bastelobjektes schrittweise zu minimieren. Ergebnis ist ein WLAN-fähiges Sensormodul, welches tatsächlich über sehr lange Zeit vollkommen autark arbeiten kann. Als Stromversorgung reichen drei einfache NiMH-Akkus (Bauform: AA), kombiniert mit einem kleinen Solarmodul aus einer Gartenleuchte, aus. Die dabei gemachten Überlegungen, Erfahrungen und Resultate lassen sich mit Sicherheit auf ähnlich gelagerte Vorhaben übertragen. Dieser Vortrag liefert dafür einige Anhaltspunkte….

Aber man soll ja bekanntlich niemals nie sagen…! Neben den Gründen, warum ich plötzlich doch mein Zuhause mit vernetzbaren Leuchten, Schaltern, Sensoren etc. ausstatte, soll vor allem das "Wie" im Vordergrund dieses Vortrages stehen. Die gewählten Lösungen entsprechen nicht ganz den herkömmlichen Herangehensweisen. Grundgedanke dabei war, sich nicht auf einen oder wenige Hardwarehersteller und eine Softwarelösung festzulegen zu müssen. Bereits vorhandene, teilweise „artfremde“ Geräte sollten integrierbar sein. Zukünftige Ideen sollen problemlos und einfach umsetzbar sein. Vielleicht animiert dieser dabei entstandene „bunte Zoo“, den einen oder anderen Zuhörer, ein eventuelles „Nie“ in Sachen Hausautomation zu revidieren.

Kaffeemaschinen und Toaster, die über das Internet erreichbar sind, oder Jalousien, die sich selbst­ständig schließen und damit die Bewohner des Hauses aussperren, finde ich immer noch übertrie­ben. Aber bei manchen Dingen ist es schon lohnenswert, darüber nachzudenken, ob eine Automati­sierungslösung nicht doch angebracht wäre. Das erste Experiment wurde vor ein paar Monaten mit einem ConBee2-USB-Stick und einer, ei­gens dafür gekauften, Philips-Hue-Lampe unternommen. Durch das universelle Konzept des ver­wendeten ZigBee-Gateways der Firma „dresden elektronik“, hat sich mittlerweile ein große An­zahl von Lampen, Sensoren, Schaltern usw. unterschiedlicher Hersteller angesammelt. Ähnlich heterogen ist auch die Auswahl an Software, die ich zur Realisierung „meiner“ Smart-Home-Lösung benutzt habe. Als grundsätzliches Bindeglied zwischen den einzelnen Komponenten wird die Low-Code-Plattform Node-RED, teilweise in Verbindung mit der deCONZ Rest-API, verwendet. Damit konnten/können auch bereits vorhandene, auf den ersten Blick inkompatible, Geräte leicht in die Gesamtlösung integriert werden. Die Visualisierung von Zustandsinformationen wurde ebenfalls mittels Node-RED realisiert. Die Archivierung und Darstellung zeitlicher Verläufe wurde mit InfluxDB und Grafana umgesetzt. Im Rahmen des Vortrages werden die Komponenten dieses bunten Flickenteppichs einzeln und in ihrem Zusammenspiel vorgestellt.

Viele Daten, wie sie z. B. im IoT-Umfeld (Internet of Things) anfallen, sind Sensor- und Zustandswerte über die Zeit. Natürlich können solche Zeitreihen in herkömmlichen SQL-Datenbanken abgelegt werden, aber seit einigen Jahren gibt es für solche Anwendungsszenarien spezielle Datenbankmanagementsysteme (DBMS). InfluxDB ist einer der Vertreter dieser Zeitreihen-DBMS, welcher sehr weit verbreitet ist. Im Rahmen dieses Vortrages wird InfluxDB, auch im Vergleich zu den „herkömmlichen“ DBMS, anhand konkreter Beispiele vorgestellt. Ein kurzer Ausflug zu Grafana und Telegraf runden den Vortrag ab.

Viele Daten, die z.B. im IoT-Umfeld (Internet of Things) anfallen, sind Sensor-, Zustandswerte o.ä. die zu einem definierten Zeitpunkt ermittelt werden. Um Auswertungen, Statistiken u.ä. anzufertigen, oder auch nur den historischen Verlauf dieser Werte zu dokumentieren, landen sie häufig in Datenbanken. Bei einer großen Menge solcher Sensor- und Zustandsdaten, sollte das verwendete Datenbankmanagementsystem (DBMS) komfortabel und performant agieren können. Die typischen Vertreter, klassischerweise SQL-Datenbanken, sind dazu ohne weiteres in der Lage. Aber hat jemand schon mal eine SQL-Query bauen müssen, die z.B. folgendes ausgeben soll: „...den Verlauf der Luftdrucktendenz, der im Minutentakt abgelegten und im 5-Minutenraster zu mittelnden Luftdruckwerte, in Bezug auf dem ebenfalls zu mittelnden Wert von vor 3 Stunden, für den Zeitraum der letzten 24 Stunden...“? Spätestens ab da kann es unübersichtlich werden und man fragt sich, ob es nicht etwas einfacher geht? ...ja, natürlich, seit einigen Jahren gibt es für solche Anwendungsszenarien spezialisierte Zeitreihen-Datenbanksysteme! Ein weit verbreiteter Vertreter ist das DBMS InfluxDB. Die Open Source Software wird im Rahmen dieses Vortrages vorgestellt. Ziel ist es, den Begriff „Zeitreihen-DBMS“ zu verstehen. Für ein konkretes Anwendungsszenario soll die Arbeit mit InfluxDB erklärt werden. Letztendlich sollen die erarbeiteten Lösungen einer vergleichbaren Umsetzung mit Hilfe eines „klassischen“ DBMS gegenübergestellt werden. Für den Referenten ist (war) die Vorbereitung zu diesem Vortrag, ein Experiment. Es soll(te) ergründet werden, ob die, bei den eigenen Wetterdatenaufzeichnungen, anfallenden Massendaten, in einer InfluxDB besser aufgehoben sind. Da dabei ein Hauptfokus auf die spätere Visualisierung der Daten liegt, erfolgt abschließend auch ein Ausflug zu Grafana und Telegraf.

»Früher« war alles besser! Auf teilweise legendärer Hardware spielte man nächtelang coole Spiele. Nur leider sind meist die alten Computer im Laufe der Zeit abhanden gekommen oder funktionieren nicht mehr. Der Vortrag erklärt, wie man sich mithilfe entsprechender Emulatoren auf moderner Hardware die Stimmung der 80er und 90er zurückholen kann.

Wer kennt sie noch, die Ataris, C64, KCs oder ZX81? Oder auch diese ganzen „altmodischen“ Spielekonsolen, welche feierlich an den Fernseher angeschlossen wurden? Aber sicherlich kennt jeder noch, ein gewisses Lebensalter vorausgesetzt, sein Lieblingsspiel, welches er nächtelang, auf dieser „komischen“ Hardware gezockt hat! Wie schön wäre es doch, einfach diese Kiste wieder einzuschalten, den Joystick in die Hand zu nehmen und das liebgewonnene Run-and Jump-Spiel, mit seiner eintönigen Soundausgabe, zu starten? Bloß leider ist die alte Hardware beim letzten Umzug abhanden gekommen oder kaputt gegangen (hat da nicht sogar der Lebenspartner nachgeholfen?)... Kein Problem! Mit der richtigen Software (Emulatoren) auf modernen Rechnern (PC und/oder Raspberry Pi), kann man die 80er und 90er Jahre wieder auf seinen Monitor zaubern. Im Rahmen des Vortrages soll gezeigt werden, wie man das macht, was man dazu braucht und auch, welche rechtlichen Aspekte zu beachten sind. Sicherlich wird auch noch Zeit sein, das eine oder andere Retro-Projekt des Referenten kurz anzusprechen.