Klimadatenexpress

Heute war mal das Ziel, ein Miniprojekt binnen Tagesfrist durchzuziehen. Ausgewählt habe ich dafür einen kleinen Klimalogger, da mich unsere “Wetterstation” wegen eines fast unleserlichen Displays fürchterlich nervt. Die Teile sind vorhanden und die erforderliche Software ist auch vorbereitet, wenngleich nicht spezifisch für die Lösung angepasst. Auch will ich wissen, ob die ESP32-Controller die Wetterverhältnisse im Außenbereich aushalten.

Projekt: Logger für Klimadaten

Kontakt: Boris Dirnfeldner

Link– eigenes Projekt –

Ziel:
An sich will ich wissen, wie sich die Controller-Elektronik in den verschiedenen Wetterverhältnissen von Hochsommer und Winter bewährt. In der Solaranlage werkelt ein Raspberry in einem DIN-Gehäuse und macht es sich dort selber warm, sollte also keine Probleme haben.
Der Controller hier dürfte weniger Komfort genießen, zumal er zwingend (bzw. der Sensor) dem Wetter ausgesetzt werden muss. Da ich in anderen Projekten auch mit Wettereinflüssen klarkommen muss, will ich erst mal ein einfaches Minimalsystem austesten.
Unabhängig davon sollen die Werte für andere Projekte verfügbar sein und für mich als Benutzer angezeigt werden.

Konzept:
Es soll eine kleine Einheit im Carport die wichtigsten Klimadaten erfassen (Temperatur, Luftfeuchte und Luftdruck) und per MQTT auf den Hausbus schicken. Eine Loggersoftware soll die Daten kontinuierlich in eine Datenbank wegsichern. Zuletzt soll eine kleine Webseite die aktuellsten Daten visualisieren.
Zeitrahmen für die Lösung ist ein Tag (bzw. eher ein halber da ich den Entschluss unter Tags getroffen habe). Der Sensor soll ein BME280 sein an einem kompakten ESP32 zur Netzwerkanbindung. Der Softwareanteil besteht neben der Controllersoftware aus weiteren Python-Services auf dem Haus-Raspberry. Der MQTT-Server ist schon da, ebenso ein WLAN zur Anbindung. Das Ganze soll in ein einfaches Gehäuse mit guter Durchlüftung. Als Stromversorgung soll ein altes USB-Netzteil mit 5V und Mikro-Stecker herhalten.

Software:
Für den ESP32 ist bereits das meiste als Basislibrary da und in C++/Arduino gelöst. Mit dabei ist ein fertiges Logging, ein Scheduler, Wifi-Anbindung und das rudimentäre MQTT-Handling. Primärer Aufwand ist die Produktausprägung einzuarbeiten, die Libs zu aktualisieren und manche Konfig-Details für das Heimnetz anzupassen. Die Umgebung kann so schnell dazu gebracht werden in einer definierten Zeitspanne den Sensor auszulesen und an den MQTT-Bus zu schicken.

Elektronik:
Der Teil ist eigentlich wirklich einfach. Ein BME280 Breakout-Board muss mit dem ESP Controller per 4 Leitungen verbunden werden (Strom und I2C). Diesmal soll es nicht mit Dupont-Kabeln laufen, sondern eine feste Kabelverbindung. Die Teile nehme ich damit ohne Pins aus dem Vorratsfundus (ungetestet). Da ich löten hasse, dauert es dann doch etwas. Danach Software draufgeladen und Testlauf. Siehe da, wieder mal geht nix, der Sensor wird nicht erkannt. Zum Glück und mit den Erfahrungen der letzten Runden habe ich einen I2C-Scanner als Controller-Software bereit, aber die findet auch nix. Strom bekommt der Sensor laut Multimeter. Vermutlich habe ich also wieder die I2C-Verbindungen verwechselt. Also die beiden Leitungen rausgelötet, mit dem Scanner umgekehrt getestet und siehe da, da taucht ein Gerät auf. Dabei zeigt sich auch, dass die Busadresse eine andere ist als sonst (0x77 statt 0x76). Also nun richtig angelötet und die Software angepasst und plötzlich liefert der Sensor auch Daten. Das Ganze wird in eine Kaugummidose aus Plastik reingepackt, die mit einigen Löchern versehen wurde zur Durchlüftung. Der Sensor ist mit einem Klebepad am Deckel montiert, der ESP klemmt im Gehäuse recht stabil drin. Da das Teil nicht bewegt wird, sollte es so erst mal passen.

Datenbank-Logger:
Der Logger wird einfach aus den anderen Projekten mit Python wiederverwertet. Die entsprechenden MQTT-Themen abonnieren und bei Eingang in getrennte Tabellen eine SQLite-Datenbank schreiben. Das Ganze noch als Service konfiguriert und schon ist das Teil fertig.

Weboberfläche:
Auch hier wird Bestandscode wiederverwertet. Die Oberfläche der Solaranlage stark vereinfacht (nur 3 Anzeigen), zeitbasierte Aktualisierung der Daten aus der Datenbank und schon sehe ich die Werte ansprechend dargestellt im Browser.

Zwischenfazit:
An sich funktioniert das alles. Allerdings fällt auf, dass im Vergleich der Sensor ca. 4°C mehr Temperatur anzeigt als die Wetterstation und ca. 8% mehr Luftfeuchte. Zwar folgen die Werte dem Tagesverlauf und sind auch nicht notwendigerweise gleich (weil der andere Sensor an der Außenseite des Carports hängt), sind aber trotzdem durchwegs und deutlich zu hoch. Nach etwas Recherche haben viele Leute das Problem speziell mit dem Sensor. Dabei gehen die Probleme von schlechten Fälschungen über Fabrikationsfehler hin zu Verfälschungen durch die Wärmeabgabe des ESP und des Sensors selber. Manche trennen Controller und Sensor um bis zu 20cm voneinander, andere arbeiten mit langsamen Lüftern. Da ich einen China-Nachbau habe, kann natürlich alles stimmen oder nichts. Leider fehlt mir auch ein kalibriertes Vergleichsmessgerät, damit muss ich mit der Wetterstation als Vergleich vorerst leben.

Anpassungen:
Eine vom Hersteller (Bosch) genannten Maßnahmen ist die Parametrisierung des Sensors. Anscheinend sollte der Sensor, je nach Einsatzgebiet, mit verschiedenen Parametern zu Filter und Sampling versehen werden. Die für Wettermessung geeigneten Parameter lassen sich leicht anpassen. Damit sollte der Sensor eigentlich besser funktionieren. Um die Wärme des ESP besser zu vermeiden läuft das System erst mal mit geöffnetem Deckel (damit der Sensor im Freien) und für den ESP sind zur Entlüftung noch ein Paar Löcher dazu gekommen (diesmal ins Gehäuse). Damit stimmt die Temperatur nun auf 0,5°C genau überein und ist damit auch gut genug. Die Luftfeuchte passt allerdings immer noch nicht.
Ein Versuch mit einer Trennwand aus Karton zur Abtrennung von ESP und Sensor verschlechtert das Ergebnis wieder. Vermutlich kommt nun wieder weniger Frischluft an den Sensor oder so. Da die Temperatur nun aber gut genug zu sein scheint, lasse ich das Teil erst mal so laufen. Wettertechnisch ist es ausreichend geschützt und für alles andere taugt das “Gehäuse” ohnehin nicht. Auf Lüfter oder ein gedrucktes Gehäuse verzichte ich erstmal, bis ich hier eine wirkliche Lösung habe. Auch würde es den gesetzten Zeitrahmen überschreiten.

Fazit:
An sich ist es ganz gut gelaufen. Das Konzept funktioniert und die Werte der Temperatur passen so. Damit kann ich ganz gut sehen, ob das Teil so über den Winter kommt oder ob Minusgrade hier zu viel des Guten sind. Ob ich beizeiten noch Korrekturen der Werte, z.B. über Offsets einbaue muss ich die nächsten Tage sehen. Grundsätzlich wäre auch ein neues Gehäuse oder ein anderer Sensor zum Vergleich eine Option. Aber vorerst bleibt es so wie es ist.

Smartes Energiemanagement – Trippelschritte voran

Die Solaranlage liefert inzwischen viele nützliche Daten und Strom. Der Stromzähler liefert nun auch entsprechende Details. Eine der Fragen dabei ist, wie ich das Erzeugungsprofil der Anlage und unser Nutzungsprofil zusammen bekomme und welche Profile sind das überhaupt? Und passt die Anlagendimensionierung so oder wäre es doch sinnvoll mehr davon zu haben?

Projekt: Smart Power Manager

Kontakt: Boris Dirnfeldner

Link– eigenes Projekt –

Situation Solaranlage:
Obgleich so langsam der Herbst da ist und die Anlage nun schon erkennbar weniger Leistung liefert als noch im August, vor allem durch die geringeren Sonnenzeiten und das ausgeprägter bedeckte bzw. nebelige Wetter, kommt dann (wenn die Sonne durchkommt) immer noch einiges rüber. Natürlich immer in Relation zur Anlagengröße (ist ja ein Kleinsterzeuger mit 600Wp).
Das Monitoring ist inzwischen stabil und die meisten Bugs gefixt. Eine Weboberfläche liefert mir sehr genaue Informationen und hat inzwischen auch eine hinreichende Reife.
Eine nun konsequente nächste Frage ist, ob sich eine Erweiterung der Solarerzeugung (z.B. Carportdach oder Hausdach) lohnt und wie das Setup dafür aussehen muss. Oder welche Voraussetzungen müssen erfüllt sein, damit sich das lohnt?

Situation Monitoring Smartmeter:
In den letzten beiden Wochen konnte ich auch das Erfassen der Daten aus dem Energiezähler im Sicherungskasten stabil bekommen. Es werden nun die Bezugs- und Einspeisedaten sicher erfasst und stehen im Netz zur weiteren Verwertung zur Verfügung. Eine rudimentäre Weboberfläche zeigt mir die aktuellen Daten auch bei Bedarf an, aber da hänge ich eher in der Datenbank, wenn ich was wissen will. Das Smartmeter ist bei den Zählern ist um den Faktor 10 genauer als die Solaranlage (1Wh statt 10Wh) und gibt auch bei Messungen 4x die Minute noch Änderungen sicher an. Da dies auch für den Einspeisezähler gilt, kann die “Ungenauigkeit” der Solaranlage hier etwas ausgeglichen werden.

Konzept Powermanager:
Datenerfassung ist ja ganz lustig, sollte aber auch was bringen. Als erstes benötige ich mal eine Aussage wie es aussieht, wenn ich Strombezug, -verbrauch und -einspeisung miteinander in Bezug bringe.
Da ich die beiden Datenerfassungsgeräte vorerst nicht weiter mit anderen Aufgaben belasten möchte, ist dafür ein weiterer Raspberry im Büro angedacht. Das Teil ist derzeit nur als zentraler MQTT-Server tätig, hat also massig freie Zeit und ohnehin die Rolle einer “Zentrale”.
Auf Basis der bereits vorhandenen Skripte soll es wieder eine vergleichbare Lösung sein, die zum einen die Daten der beiden Logger einsammelt, diese verdichtet und dann in eine eigene Datenbank abspeichert. Relevante Daten werden (erst mal) wieder per Weboberfläche dargestellt.
Zum Einsammeln bieten sich die MQTT-Sendungen der Logger an.

Software:
Einiges an Code ist ja schon vorhanden. Da ich mich über einige Codedubletten ärgere und ein Paar andere technische Schulden, geht es an alle 3 Pakete parallel. Code wird in ein Modul ausgelagert, vereinheitlicht und an ein Paar Stellen robuster gestaltet. Die MQTT-Meldungen mit den aktuellen Daten werden aufgenommen und verdichtet. Es stellt sich allerdings heraus, dass dieses System zwar gut und auch relativ stabil funktioniert, aber auch ziemlich umständlich ist, weil die Verarbeitung ausschließlich extern getriggert wird (durch die MQTT-Pakete) und damit auf viele Dinge geachtet werden muss. Die Lösung erscheint mir in der Folge dann doch zu anfällig und komplex, daher wurde das Konzept umgestellt auf eine Erfassung durch REST-Anfragen an die Logger direkt auf die Datenbanken. Dazu wurden in den beiden Skripten, die für die Weboberflächen zuständig sind, zusätzlich eine RESTful-Api reingepackt (die Oberfläche hat bereits eine Flask-basierende Basis) über die ich SQL-Anfragen ausführen kann. Damit bin ich wieder bei aktiven Anfragen basiert auf Scheduler-Zeitsteuerung und weg von den vielen Sonderfällen der event-basierten Bearbeitung. Derzeit laufen beide Schienen parallel, was mir die Prüfung der Daten erleichtert. Im Ergebnis bekomme ich nun die Daten für die Stromerzeugung, Strombezug und Stromeinspeisung in Tabellen gepackt in den Auflösungen Minute, Stunde und Tag. Dazu wird der Eigenverbrauch (also Erzeugung – Einspeisung) und der komplette Stromverbrauch berechnet (also Solarstromverbrauch + Bezug). Da die Solaranlage nur in 10Wh-Schritten die Zähler aktualisiert, sind Auflösungen <1 Minute hier nicht mehr sinnvoll.

Erste Erkenntnisse:
Die Daten sind ein wichtiger Schritt vorwärts. Leider funktioniert die exakte Korrelation auf Minutenbasis wegen der geringeren Messauflösung der Solaranlage nicht so gut, wenn nicht viel Sonne da ist (mehrere Minuten nix, dann wieder ein Block von 10Wh). Spätestens auf der Ebene Stunde ist das aber egal. Zur Erkennung einer Überversorgung durch die Solaranlage kann ich aber mit den Daten des Smartmeters arbeiten. Ich sehe weiterhin eine fast vollständige Verwertung der erzeugten Leistung, allerdings auch Überschuss, wenn die Sonne mal Gas gibt. Die Solaranlage ist damit recht gut für die Grundlastversorgung ausgelegt. Durch die Messauflösung von einer Minute kann ich auch gut Verbrauchsprofile sehen, z.B. wenn der Backofen aktiv ist. Damit kann ich nun ziemlich genau sagen, wann ich welche Energiemengen benötige (und wann nicht). Dampfbügeleisen und Backofen sind hier wohl die Könige des Strombezugs, dann Herd, Geschirrspüler und Waschmaschine.

Verbrauchs- und Erzeugungsdaten:
Über Nacht zieht das Haus aktuell etwa 250W. Tagsüber liege ich etwa 100W drüber. Damit brauche ich ca. 6KWh täglich zur Grundversorgung. Im realen Verbrauch sehe ich 10-12 KWh an normalen Tagen. Die Solaranlage lieferte an guten Sonnentagen bis zu 617W (Begrenzung durch den Wechselrichter), über den Tag aktuell bis zu 3 KWh, an optimalen Tagen knapp 4 KWh maximal.
Die Einspeisung ist vernachlässigbar (seit April 14 KWh), aber an guten Sonnentagen in der Spitzenzeit gut erkennbar.

Solaranlage erweitern oder nicht?
Es zeichnet es sich jetzt schon ab, dass ich mit zusätzlicher Anlagenleistung ohne Speichermöglichkeit meistens nichts anfangen kann bzw. nur relativ kurze Spitzenphasen besser abdecken kann. Damit ist auch erst mal die Frage einer Anlagenerweiterung vom Tisch, bis ich entweder einen bezahlbaren Stromspeicher finde oder geeignete Verbraucher mit Steuerungsmöglichkeit. Das Einspeisen ins Stromnetz ist derzeit eher unattraktiv, weil die Refinanzierungszeiten mir persönlich da noch deutlich zu lange sind und die Erträge zu gering. Erste Angebote mit Speichermöglichkeiten über die Netzversorger (“Strom-Cloud”) finde ich zwar konzeptionell interessant, sind allerdings auch bisher nicht attraktiver als Einspeisung und günstiger Ökostrombezug. Umgekehrt sind die Stromspeicher auch noch zu teuer, was wiederum zu lange zur Refinanzierung braucht. Und nur zum Spaß ist mir das Ganze dann derzeit zu aufwändig und auch zu teuer.

Weiterer Ausblick:
Mit dem direkten Vergleich Einspeiseleistung gegen Bezugsleistung kann ich nun Schaltschwellen für Verbraucher definieren, die nur bei Sonnenstromüberschuss laufen sollen.
Die Logik dafür kann im Logger des Smartmeters dazu gebaut werden und dann z.B. über MQTT wieder entsprechende Benachrichtigungen verteilen.
Ein erster Kandidat wird wohl eine Umwälzpumpe zur Algenbekämpfung im IBC-Wassertank sein, auch als Proof-of-Concept. Die Poolpumpe bleibt ein ständiger Kandidat, und mit etwas guten Willen und Zeit finden sich sicher weitere Kandidaten.
Ein kleiner Stromspeicher mit steuerbarer Leistungsregelung wäre eine Idee um mehr (zusätzliche) Solarleistung nutzbar zu machen, verbietet sich aber derzeit noch aus Kostengründen.
Vorerst werden aber fleißig weiter Daten gesammelt, auch um eine bessere Idee zu bekommen wie die Jahreszeiten hier Einfluss nehmen.

Smartclock – dem die Stunde schlägt.

Im Zuge der Konzeptarbeiten an der Heimautomatisierung zeigt sich immer wieder der Bedarf an einem Display bzw. einer Signalisierung allgemein. Da ich gerade Bock drauf hatte eine Uhr zu bauen, muss diese auch für den ersten Versuch dazu herhalten. 

Projekt: Smartclock

Kontakt: Boris Dirnfeldner

Link: – eigenes Projekt –

Mir haben diese Leuchtanzeigen auf Basis von WS2812 schon immer gefallen, zumal die Dinger ja auch mit so wenig Drahtverhau auskommen (VCC, GND und Signal). Die Ansteuerung erfolgt über ein serielles Protokoll (Eindraht) und fertige Libs für Arduino gibt es dazu auch. Nachdem ich einen Leuchtring mit 60 LEDs gefunden hatte, war klar das dies eine Uhr werden musste.

Anforderungen:

o Anzeige der Uhrzeit analog über den Leuchtring.
o Anzeige von Datum und Uhrzeit über LED-Segmentanzeigen digital
o Signalisierung von Zählerständen, über MQTT-Nachrichten im System zentral verteilt und von dort auch bezogen. Rückwärtszähler sollten bei <60 Sekunden am Ring präsent angezeigt werden.
o Signalisierung von Events über MQTT, die über “Flashen” am Ring dargestellt werden. Dabei soll es verschiedene Kritikalitäten geben, z.B. Rot für Alarme, Gelb z.B. für Türklingel etc.

Design:

Der Zeitgeber ist ein RTC vom Typ DS3231. Als Controller wird ein Arduino verwendet, der Analogring besteht aus 60 x WS2812 auf vier Platinen (je ein Viertelkreis). Die Digitalanzeigen sind mit TM1637 Display-Modulen aufgebaut die auch mit einer 2-Drahtverbindung seriell angesteuert werden (Signal + CLK).
Die Anbindung an den MQTT-Server erfolgt über einen ESP-01S und ESP-Link.

Aufbau und Inbetriebnahme:

Der RTC-Code ist kein Problem, auch die Ansteuerung eines TM1637 nicht. Nachdem die ersten Teile richtig funktionieren wird alles mal fliegend verdrahtet.
Und siehe da, es geht gar nix mehr.

Es zeigt sich recht schnell das die Stromversorgung mit Arduino für die Anzeige nicht mehr reicht, also die Stromversorgung separat aufbauen und schon ist alles gut.

Der Ring erfordert erstmal Lötarbeit damit aus den vier Teilen auch ein Ring wird (und das kann ich so gar nicht gut). Naja, irgendwie halten die Teile (mehr aus Mitleid) zusammen.
Die Ansteuerung ist ziemlich einfach, nur die Leuchtkraft der Module hat mich überrascht. Beim ersten Versuch (mit externer Stromversorgung, ich habe mit den TMs gelernt) war ich erst mal blind und hatte den Ring wortwörtlich im Auge eingebrannt am nachleuchten. Die Lib startet per Default alles in voller Leistung in Weiß, und das ist dann Abends im Zimmer hell!
Bei den nächsten Versuchen (mit erheblich weniger Leistung per Parameter) ist dann auch alles gut. Nach etwas Kodierarbeit zeigt sich auch eine uhrenähnliche Anzeige.

Jetzt kommen die TMs wieder dran und bekommen auch Code zur Anzeige von Datum und Zeit. Auch die Module lassen sich in der Helligkeit parametrisieren (was dann auch passiert).

Nachdem das alles läuft (die Uhr an sich ist damit fertig) geht es an die Netzwerkverbindung und die Signalisierung. Mit dem Ring sind einfache Blinksignale kein Problem, ein Satz von Funktionen habe ich schnell fertig.

Der ESP-01s ist auch schnell verbunden und die ESP-Link Firmware in Verbindung mit EL-Client Library bietet mir eine komfortable Anbindung an den MQTT-Server.
Leider zeigt sich hier ein übler Bug in der Firmware des ESP, der beim Empfang längerer MQTT-Nachrichten leider versagt und die Meldung verschluckt.
Das Problem hat leider auch ein anderes Problem erwischt (Beetbewässerung) und kann nicht zeitnah gelöst werden. Damit bekomme ich leider die Anbindung nicht zuverlässig hin.

Ich spiele mich noch etwas mit der Anzeige (mache z.B. Leuchtpunkte für die 5-Minuten-Markierung) und baue den Code für meine Library um, will aber das Teil so nicht fertigmachen.
Da ich etwas Zeitdruck an anderen Baustellen habe, bleibt der fertige Aufbau noch aus.

Fazit:

Die Uhr an sich läuft, der Aufbau in ein ansehnliches Gehäuse ist erstmal noch vertagt bis ich das Netzwerkthema unter Kontrolle habe. Sieht sehr danach aus als würde ich den Arduino ersetzen gegen was mit integrierten WLAN (z.B. ESP32).
Dann kommt auch die Zähleranzeige dazu und vermutlich ein Drehgeber zu Eingaben am Gerät. Vielleicht kommt ja noch ein “richtiges” Display rein, mal sehen. Vorerst geht es erst mal mit anderen Dingen weiter und dem Design vom Gehäuse.

Komponenten:
RTC DS3231 Echtzeituhr
TM1637 Display Module
WS2812 RGB-Ring (60)
Arduino Uno (Clone)
ESP01S WLAN-Modul
Schaltnetzteil 230V/5V
MQTT-Server im Netz

Überlegungen:
Da im Haus keine Alexa wohnt, aber ständig langlaufende Timer gebraucht werden, wäre doch eine relativ intelligente Uhr gar nicht so doof.

Schäden:
– Einmal Geblitzdingst beim ersten Start des Leuchtrings.
– Wegen MQTT-Problem ist die Uhr noch nicht smart.

Wir benutzen Cookies und Logs mit personenbezogenen Daten ausschließlich für essentielle Funktionen wie z.B. bei der Benutzeranmeldung oder der Fehlersuche. Für Videos werden weitere Cookies von Drittanbietern benötigt. Details finden sie unter dem Link "Weitere Informationen".