Nachdem ich die DIY-Wetterstation* und die dazugehörige Anzeige aufgezeichneter Wetterdaten* mittels Web-Script fertiggestellt hatte, fehlte eigentlich nur noch, wie bei käuflichen Wetterstationen, ein Anzeigedisplay, welches man sich ins Wohnzimmer stellen kann. So ist es damit möglich auch einmal einen Blick auf die aktuellen Temperaturen werfen zu können, ohne das Handy oder den PC anschalten zu müssen. Aus diesem Grund entstand fast zeitgleich mit der Wetterstation das Wetterdisplay, welches ich hier gern vorstellen möchte.
In diesem Beitrag werde ich versuchen die Vorteile der Displays der Firma Nextion und den Aspekt der Kommunikation zwischen Micro-Controller und Display ein wenig hervorzuheben, da man diesen Teil auch für andere Projekte gut verwenden könnte.
KOMMENTAR DES AUTORS
Hardwareauswahl
Die Auswahl der zu verwendenden Hardware stand bei diesem Projekt eigentlich schon vorab fest. Da die DIY-Wetterstation* die anzuzeigenden Wetterdaten in meinem lokalen Netzwerk ablegt, brauche ich natürlich eine Möglichkeit diese von da aus auch zum Display zu bekommen. Der einfachste Weg hierfür erschien mir die Verwendung des bereits bei der Wetterstation selbst eingesetzten ESP8266* Micro-Controllers, da dieser nicht nur Daten an ein Webscript senden, sondern auch eine Webseite auslesen kann.
In diesem Beitrag möchte ich nun noch auf das Speichern und Anzeigen der Messdaten, welche durch meine DIY ESP8266 Wetterstation* viertelstündlich an meinen NAS übermittelt werden, ein wenig näher eingehen. Da die Art der Daten dabei eigentlich nur eine untergeordnete Rolle spielt, habe ich diesen Beitrag von der Wetterstation getrennt erstellt, so könnte er vielleicht auch als Vorlage für die Anzeige anderer Daten als Inspiration dienen.
Datenempfang und Speicherung
Der Empfang und das Speichern der Messdaten ist recht trivial. Die Wetterstation ruft nach dem Verbinden mit dem Netzwerk ein PHP-Script auf, welches die Messwertdaten per HTTP_GET entgegennimmt und dann innerhalb einer Datei speichert. An dieser Stelle sei gesagt, dass das Sammeln der Daten natürlich genauso gut (oder vielleicht sogar besser) in einer Datenbank machbar wäre. Ich habe mich damals für die Dateivariante entschieden, da sich diese beim Erstellen der Scripte leichter überprüfen und debuggen lassen hat.
Um eine übersichtliche Einteilung der Daten zu erreichen, werden vom Script automatisch Unterordner für den aktuellen Monat des Jahres und den jeweiligen Tag der Messaufzeichnung wie folgt erstellt. Für den unwahrscheinlichen Fall, dass irgendwann eine zweite Wetterstation hinzukommen sollte, wird geprüft, ob der innerhalb der Wetterstation gesetzte Gerätename als oberste Verzeichnisebene vorhanden ist. Ist dies der Fall wird geprüft, ob der Ordner für den aktuellen Monat vorhanden ist – falls nicht, wird dieser erzeugt. Danach wird geprüft, ob der Ordner für den aktuellen Tag vorhanden ist – falls nicht, wird auch dieser erzeugt. Im letzten Schritt wird geprüft, ob innerhalb des Tagesordners die Messdatei vorhanden ist – falls nicht, wird diese ebenfalls erzeugt. Anschließend werden die Messdaten in diese Messdatei geschrieben und die Datei gespeichert.
Nachdem ich bereits diverse Elektronikprojekte umgesetzt hatte, entstand im Jahr 2018 die Idee ein wenig mehr mit Sensoren zu experimentieren. Da der Bau meiner Innenraumtemperatursensoren* nun schon einige Jahre her war und ich zwischenzeitlich immer mal wieder Temperatursensoren in anderen Projekten eingesetzt hatte, dachte ich mir das es diesmal ruhig ein wenig mehr als nur eine Temperaturmessung sein darf. Damit war die Idee der DIY-Wetterstation geboren, welche ich hier kurz vorstellen möchte.
Leider habe ich das Layout der Platine und die Verkabelung der Sensoren damals „on the fly“ erstellt und nicht dokumentiert, weshalb ich leider keinen detaillierten Schaltplan liefern kann. Da die Pin-Belegung der Sensoren aber nicht sonderlich kompliziert ist, denke ich das es kein Problem sein sollte, die Wetterstation auch ohne einen Schaltplan komplett, oder auch nur teilweise nachzubauen. Falls dennoch jemand Unterstützung benötigen sollte, dann kann er sich gern per Mail unter info@langer-sebastian.de an mich wenden.
Die letzten Tage habe ich meine HTML-basierte Software des „SLSS CarNet Command Centers“ (Hauptartikel: SLSS CarNet*) weiter um- und ausgebaut. Nach der Installation der Hardware im Sommer 2020 konnte ich auf meinen Testfahrten (welche coronabedingt leider nicht so häufig waren wie gehofft) einiges an Erfahrungen und Eindrücken sammeln. Die ersten Erkenntnisse daraus habe ich nun in Form von Updates und Verbesserungen in die Software einfließen lassen. Das es an der einen oder anderen Stelle Verbesserungspotential geben wird, war mir bereits bei der Entwicklung der Soft- und Hardware klar. Ich war ziemlich erstaunt, dass sowohl die GPS-Ortung inkl. Richtungs- und Geschwindigkeitserkennung, als auch andere Komponenten, welche ich vorher nicht während der Fahrt (also „in Bewegung“) testen konnte, auf Anhieb funktionierten. Somit beschränken sich die Verbesserungen auch eher auf Optimierungen in Sachen Performance, Usability und Reaktionsgeschwindigkeit.
Verbesserung der CAN-Bus Reaktionsgeschwindigkeit dank Python
Eine Sache, welche mich schon beim Erstellen der Software beschäftigte, war die Erkennung der über den CAN-Bus gesendeten Botschaften. Ursprünglich nutze ich hierfür ein PHP-Script, welches per „shell_exec()„-Befehl das Lesen der CAN-Daten übernahm. Das Problem hierbei war zum einen, dass dieses Script nicht in einer Endlosschleife laufen konnte, da die so gesammelten Daten nach Zeit-X gespeichert werden mussten und dafür der Lesevorgang beendet werden musste. Zum anderen lief dieses Script innerhalb des „Command Centers“ was dazu führt, dass CAN-Daten nur erfasst wurden, wenn dieses auf einem Gerät ausgeführt wurde.
Meine Leidenschaft für die „Bastelei“ mit Micro-Controllern hat mittlerweile auch in meiner beruflichen Tätigkeit als Prüfstandstechniker Einzug gehalten. So ist innerhalb der letzten Jahre das eine oder andere „Helferlein“ für die Erleichterung unserer täglichen Arbeit und das Meistern von speziellen Mess- und Prüfaufgaben entstanden. Der Anstoß für die Entwicklung eines neuen Gerätes war dabei meist der einfache Fakt, dass für die Umsetzung der benötigten Messungen keine Hardware verfügbar, oder die verfügbare Hardware für die Aufgabe nicht genau passend war. Da dieser Umstand beim Testen von Einzelkomponenten oder Teilgruppen relativ häufig vorkommt, fand ich immer wieder neue Herausforderungen und konnte somit auch Dinge realisieren, welche ich so in dieser Art vorher noch nicht umgesetzt hatte. So war zum Beispiel meine erste CAN-Bus Anwendung eines dieser Bastelprojekte.
Ein weiterer großer Vorteil dieser „Eigenanfertigungen“ ist, dass ich die zum Betrieb benötigten Ein- und Ausgaben direkt an die von unseren Prüfständen zur Verfügung gestellten Eingangs- und Ausgangsschnittstellen anpassen kann. So wurde bei den meisten meiner „schwarzen Kästchen“ die Steuerung per analogem Eingangssignal im Bereich von 0V – 10V realisiert, während die Rückgabe der Einstell- und Messwerte meist per CAN-Bus erfolgte. Dies ist dem Umstand geschuldet, dass der Treiber des verwendeten Messsystems nur auf dem CAN-Eingang des Prüfstandes lesen, aber nicht senden kann.
In der Vergangenheit gab es immer wieder die Anforderung Magnetventile, Motoren oder andere elektrische Komponenten mit einer vorzugebenden Frequenz – Tastverhältniseinstellung, also per Pulsweitenmodulation* / PWM* (https://www.elektronik-kompendium.de/sites/kom/0401111.htm), betreiben zu können.
Da die Digitalausgänge unser Prüfstandshardware keine hohen Schaltströme zulassen, wurde für die Ansteuerung von elektrischen Bauteilen meist eine Kombination aus vorgeschaltetem Reed-Relais und nachgeschalteten Kfz-Last-Relais verwendet. Leider ließen sich mit dieser Kombination keine hohen Schaltfrequenzen realisieren (max. ca. 30Hz bis 50Hz), was dazu führte, dass für Schaltanforderungen mit höheren Frequenzen meist Fahrzeugsteuergeräte und Kabelbäume aufgebaut, und die Ansteuerung kompliziert über deren Software realisiert werden musste.
Meine erste Idee war, den Relaisverbund durch ein Metall-Oxid-Halbleiter-Feldeffekttransistor* (kurz: MOSFET) zu ersetzen, womit sich die Schaltfrequenz um ein vielfaches erhöhen lässt und einer direkten Ansteuerung nichts mehr im Weg steht. Da ich bereits für andere Schaltaufgaben MOSFETs verwendet hatte, passte ich eine dieser Schaltungen an die neuen Anforderungen an. Als wir diese Schaltung am Prüfstand testeten, stellten wir jedoch fest, dass mit den digitalen Ausgängen der Messkarten keine stabilen Frequenzsignale erzeugt werden konnten. Hierbei liegt das Problem jedoch weniger an der Hardware selbst, sondern eher an dem in der Prüfsoftware eingestellten Software-Takt, welcher bei höherer CPU-Auslastung ab und an ins Stocken geriet. Dies war bei der Ansteuerung eines Magnetventils hörbar und auch in den aufgezeichneten Messdaten sichtbar.
Da man hiermit keine vernünftigen Messergebnisse erzeugen konnte, kam ich auf die Idee, die Ansteuerung von Frequenz und Tastverhältnis über einen Micro-Controller zu realisieren. Dieser sollte auf Grund seiner internen Timer und der hardwarenahen Programmierung problemlos ein stabiles PWM-Signal erzeugen können.
SLSS CarNet ist ein Projekt, welches im Winter 2019 seinen Anfang genommen hat. Ich und einige meiner Freunde sind begeisterte US-Car Fans. Außerdem spielte ich schon länger mit dem Gedanken mir einen Kleinbus zuzulegen um mit meiner Frau, unseren beiden Kindern und den Großeltern den einen oder anderen Ausflug unternehmen zu können, ohne immer auf 2 Fahrzeuge aufgeteilt sein zu müssen. So kombinierte ich die Schwärmerei für US-Cars mit dem Wunsch des Kleinbusses und kaufte im Dezember einen amerikanischen Chevrolet Express, welcher von der Explorer Van Corporation zu einem „rollenden Wohnzimmer“ umgebaut wurde.
Nach dem Kauf des Vans kam mir recht bald die Idee, diesen um ein paar Funktionen zu erweitern. So gibt es zum Beispiel in der vorderen Deckenverkleidung ein Bedienpanel auf dem 3 Schalter für die Steuerung der verschiedenen Beleuchtungen im Innenraum des Van angebracht sind. Diese Beleuchtung, wozu auch ein Sternenhimmel gehört, macht den hinteren Teil des Vans zu einer Chill-Out-Area, welche für nüchterne, deutsche Verhältnisse fast schon ein wenig übertrieben anmutet, für mich als Fan aber einfach dazu gehört. Leider sind diese Schalter aber eben nur Schalter. So ist es nicht möglich das Licht zu dimmen, sondern nur ein- oder auszuschalten. Was beim Sternenhimmel noch ganz in Ordnung ist, sieht beim Schalter für die Lesebeleuchtung schon anders aus. Betätigt man diesen, so erstrahlen ganze 8 Leseleuchten, welche von vorn bis hinten über die ganze Fahrzeuglänge verteilt sind, mit voller Leistung. Dies ist so hell, dass der Vorbesitzer bereits alle 5W Glassockel-Lampen durch orange Leuchtmittel, wie sie zum Beispiel für Seitenblinker verwendet werden, ersetzt hat. Leider ist das orange Licht nicht wirklich dunkler und so kam mir die Idee die Beleuchtung mittels Pulsweitenmodulation zu dimmen. Eine weitere Idee war, dem Van aufgrund seiner Größe eine Rückfahrkamera zu spendieren. Da ich das originale Radio nicht durch ein Doppel-Din Gerät mit Kameraeingang ersetzen wollte und mir die Monitore für die Nachrüstkameras eher nicht gefallen, musste also eine Individuallösung her. So stand der Entschluss fest ein eigenes System zu entwickeln, was all diese Funktionen in einer grafischen Oberfläche vereint.
Nachdem ich mich ein wenig in die Handhabung der Raspberry Pi* eingearbeitet hatte, dauerte es nicht lange und ich kaufte mir eine 2. Raspberry Pi* fürs Wohnzimmer. Diese sollte dort einige Schalt- und Messaufgaben (Helligkeitsmessung, Schalten von Geräten mit IR-Empfängern wie HiFi-Decoderstation, TV-Receiver, etc.) übernehmen, damit diese platzsparend auch im Schrank untergebracht werden konnten. Diese Funktionen waren recht zügig umgesetzt und nun lag dieser auch damals schon recht leistungsfähige Mini-Computer hinter dem TV. Da wir viel und gern Radio, vorzugsweise Rockmusik, hören und ein Teufel Soundsystem besitzen auf dem sich diese auch super anhört, kam mir die Idee die sich langweilende Raspberry Pi* um ein Web-Radio zu erweitern, mit welchem wir einfach und bequem zwischen verschiedenen Internet-Radiosendern auswählen können. Das Ganze sollte sich natürlich, wie soll es auch anders sein, nahtlos in die selbstgebaute GUI (englisch: graphical user interface) meiner DIY-Hausautomatisierung* einbinden lassen. Der Startschuss zur Entwicklung des SHAS-Radio war damit gefallen.
Hinweis:Da dieses Projekt mittlerweile doch recht umfangreich geworden ist und Programmierkenntnisse sowohl in HTML, PHP, JavaScript als auch Python erforderlich sind, möchte ich hier keine detaillierte Nachbauanleitung, sondern viel mehr eine Anregung, respektive einen Wegweiser aufzeigen, um technikinteressierten Bastlern vorab eine grobe Richtung beim Start der Umsetzung eines ähnlichen Projektes zu geben. Bei Bedarf gebe ich aber auch gern die zur Installation nötigen Dateien weiter.
KOMMENTAR DES AUTORS
Version 1 – Headless SHAS-Radio für die Hausautomatisierung (2014)
In seiner ersten Version sollte das Radio ohne direkte GUI erstellt werden und ausschließlich über das Netzwerk fernsteuerbar sein, da die Radiofunktion auf der Raspberry Pi* im Wohnzimmer genutzt, aber über die Oberfläche meiner DIY-Hausautomatisierung*, welche wiederum auf einer anderen Raspberry Pi* läuft, bedient werden sollte. Der Plan war den Aufbau so zu gestalten, dass ich bei Bedarf auch weitere Räume mit einer Raspberry Pi* ausstatten und somit um ein Webradio erweitern hätte können. Da die Hausautomatisierung größtenteils in HTML, Javascript und PHP umgesetzt wurde, lag es nahe, dass SHAS-Radio auch mit diesen Sprachen umzusetzen, da damit die Kommunikation zwischen Hausautomatisierung und Radio einfach zu realisieren ist.
Nachdem ich meine DIY-Hausautomatisierung* um viele Softwarefunktionen erweitert hatte und der Umstieg auf die Raspberry Pi* mich neugierig auf die Welt der Elektronikbasteleien gemacht hat, empfahl mir ein guter – ebenfalls technikaffiner – Freund, doch mal einen Blick auf das Micro-Controller-Board namens Arduino* zu werfen. Zu diesem Zeitpunkt hatte ich auf Grund meiner Ausbildung zwar bereits ein Grundverständnis von Elektrik und Elektronik, doch Micro-Controller waren komplettes Neuland für mich. Da das Thema aber so interessant war, bestellte ich mir das empfohlene Starter-Kit mit dem Namen Fritzing Creator Kit*, in welchem neben einem Arduino* Uno R3 auch einige elektronische Bauteile, ein Breadboard* und eine Handvoll Verbindungsleitungen zum Anschluss der Bauteile enthalten war. Nach ein wenig Rumspielerei mit den enthaltenen Bauteilen kam mir die Idee dem Micro-Controller eine sinnvolle Aufgabe zu geben. Einen Funk-Temperatursensor für meine Hausautomatisierung hatte ich schon länger auf meiner Nice-To-Have-Liste, doch leider gab es nichts passendes zu kaufen. Jetzt war die Zeit gekommen, es anzugehen diese selbst zu bauen.
Eines meiner älteren aber immer noch aktuellen Projekte ist meine DIY-Hausautomatisierung mit dem treffenden Namen SHAS für Sepp Home Automation Systems. Die Idee dahinter war unsere Mietwohnung ohne bauliche Veränderungen ein wenig „smarter“ zu machen. Das Verlegen von Bus-Leitungen oder installieren von Unterputz-Schaltaktuatoren war hierfür keine Option, das diese bei einem evtl. Wohnungswechsel zurück gebaut werden müssten. Der Einfall hierzu kam mir im Jahr 2010, als ich einen Bericht über „Das Haus der Zukunft“ im TV gesehen habe. In diesem konnte man per Tablet alle möglichen Funktionen wie Beleuchtung, Jalousien, Kamin, etc. bequem von der Couch aus steuern. Die Steuerung wurde durch einen eigenen Hausserver samt daran angeschlossenen Schaltaktuator realisiert. Ich fand das Thema total spannend, wusste aber sofort, dass so ein Aufbau für eine Mietwohnung schlichtweg nicht praktikabel ist.
Diese Internetseite verwendet Cookies und Google Analytics für die Analyse und Statistik. Wir nutzen Cookies zu unterschiedlichen Zwecken, unter anderem zur Analyse und für personalisierte Marketing-Mitteilungen. Durch die weitere Nutzung der Website stimmen Sie der Verwendung zu. Wenn Sie mehr zu diesem Thema erfahren möchten, dann gelangen Sie hier zu unseren Cookie- und hier zu unseren Datenschutzrichtlinien
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Notwendige Cookies helfen dabei, eine Webseite nutzbar zu machen, indem sie Grundfunktionen wie Seitennavigation und Zugriff auf sichere Bereiche der Webseite ermöglichen. Die Webseite kann ohne diese Cookies nicht richtig funktionieren.
Präferenz-Cookies
Präferenz-Cookies ermöglichen einer Webseite sich an Informationen zu erinnern, die die Art beeinflussen, wie sich eine Webseite verhält oder aussieht, wie z. B. Ihre bevorzugte Sprache oder die Region in der Sie sich befinden.
Marketing-Cookies
Marketing-Cookies werden verwendet, um Besuchern auf Webseiten zu folgen. Die Absicht ist, Anzeigen zu zeigen, die relevant und ansprechend für den einzelnen Benutzer sind und daher wertvoller für Publisher und werbetreibende Drittparteien sind.
Statistiken
Statistik-Cookies helfen Webseiten-Besitzern zu verstehen, wie Besucher mit Webseiten interagieren, indem Informationen anonym gesammelt und gemeldet werden.
Nicht klassifiziert
Nicht klassifizierte Cookies sind Cookies, die wir gerade versuchen zu klassifizieren, zusammen mit Anbietern von individuellen Cookies.