LD2_Datenerfassung & Automation
LD2_Allgemein
Zugriffe: 7
Ein zentraler Gedanke bei LD2 sind produzierbare Prozesse.
Mein Ansatz ist, relevante Daten wie beispielsweise die Temperatur beim Schmelzen der Gelatine oder die Belichtungszeit zu dokumentiert, um Rück- und Aufschlüsse zu erhalten.
Das geht natürlich erstmal mit Zettel und Stift, Timern, Stoppuhr, Thermometern und dann mit Formularen bzw. Checklisten. Die analoge Dokumentation ist einfach in der Erstellung, lässt sich (mit zwei Löchern am Rand...) ordentlich archivieren, bereitet aber auch Probleme...
Händische (ungenaue) Messungen, unterschiedliche Zeitintervalle, vergessene Dokumentation usw. ließen den Wunsch nach „automatischer“ Dokumentation aufkommen.
Im Gegensatz zu den Anfängen um 1850 lassen sich heute die einzelnen Prozessschritte auf digitalem Weg erfassen, analysieren und vergleichen. Für die Erfassung dieser Daten braucht es Sensoren, die ihre Messwerte an ein System weiterleiten, das diese dann speichert und verarbeitet.
Wichtig dabei sind die Intervalle, die Messbereiche, Anforderungen und Toleranzen. Gemessen und dokumentiert werden müssen Temperaturen in Flüssigkeiten und der Luft zwischen 0 und 100° C, Luftfeuchte zwischen 0 und 100%, Helligkeitswerte (für die Belichtung), Zeiten, Schaltzustände, Stromverbrauch, Füllstände, …
Ich nutze einen Raspberry in Verbindung mit ioBroker, dem ein eigenes dickes Kapitel gewidmet wird.
Der Vorteil ist, dass viele verschiedene Systeme wie Stecker, Schalter, Sensoren, … eingebunden werden können, ohne firmenspezifische Soft- und Hardware zu benutzen, da der ioBroker als universelle Bridge fungiert und die Daten lokal speichert.
Da die Messung von Temperatur im Ofen oder beim Schmelzen von Gelatine über mehrere und wasserdichte Temperaturfühler gemessen werden müssen, die es in der „normalen Smarthomewelt“ nicht als fertiges Produkt gibt, kommen primär Bauelemente wie die der Firma Shelly oder auch Entwicklerboards auf Basis des ESP8266 zum Einsatz, der frei konfiguriert werden kann.
Ein wichtiger Punkt der auch für das System Raspberry und ioBroker spricht, ist die „Insellösung“. Die erfassten Daten werden nicht via Internet in einer Cloud bzw. einem Firmenserver gespeichert, sondern (bleiben) lokal.
Der Raspberry braucht wenig Strom, lässt sich mit Tastatur und Maus an einen Monitor oder Fernseher anschließen oder per Fernzugriff über das Netzwerk steuern und kann permanent oder bei Bedarf laufen.
Ein weiterer Vorteil sind die günstigen Preise der Elemente. So kostet ein Sensor, der Luftfeuchte und Temperatur misst ca. 10€ und Steckdosen mit Energiemessfunktion ca. 15€.
Es Bedarf ein wenig Recherche, Vorkenntnisse, Einarbeitung und „Nerd-TV“, doch das Ergebnis ist ein zugeschnittenes System, das Daten erfasst, anzeigt und auswertet.
Im nächsten Schritt wird es darum gehen, Automationen zu erstellen, die den Großteil der Prozesse steuern.
So kann/soll beispielsweise über Skripte auf Knopfdruck, einen Kalendereintrag oder als Reaktion auf ein definiertes Ereignis, der Ofen vorgewärmt, die Luftfeuchte geregelt werden oder Licht da angehen, wo, wenn und wie es gebraucht wird. Auch liesse sich mit der Technik eine Zeiterfassung, Lagerverwaltung und Auftragsdokumentation realisieren.
Es empfiehlt sich, das System über Aliasse auf zu bauen, die Position oder Funktion einzelner Sensoren beschreiben und dann mit realen Geräten verknüpft werden, was den Austausch von Geräten, die Visualisierung und das Skripten übersichtlicher macht.
EIN BEISPIEL…
Die Klimadaten an der Presse sollen während dem Arbeiten (Drucken) in Zeitintervallen von einer Minute geloggt werden. Die Daten werden als Graph visualiert und dienen der Steuerung von Heizung, Luftbe- bzw. entfeuchter. Mit einem kombiniertem Temperatur- und Luftfeuchtesensor (DHT20) an einem ESP8266, der nur bei Bedarf mit Strom versorgt wird, ist/wäre dieser unterfordert. Es ließen sich weitere Klimadaten erfassen, Taster anschließen und oder ein Display zur Anzeige (aktueller) Daten integrieren.
Bei der Dokumentation von Klimadaten braucht(e) es verschiedene Systeme, da der Raspberry nicht permanent laufen muss. So werden die Raum- und Außendaten über einen externe Server gespeichert und bei Bedarf abgerufen. Während der Prozesse kommen andere/weitere Klimasensoren zum Einsatz, die in kürzeren bzw. einstellbaren Intervallen Daten protokollieren.
Ein Problem bei der Mischung verschiedener Systeme (Hersteller) ist die Einheitlichkeit der Messergebnisse. Hier hilft der Abgleich über Referenzen und die entsprechende Korrektur (Offset) der Ergebnisse.
Dazu platziert man beispielsweise die Temperatursensoren gemeinsam in einem Glas mit Wasser, dessen Temperatur man ändert. Die angezeigten Werte müssten dann gleich sein. Ist das nicht der Fall, lassen sich die Korrekturen über Tasmota oder aber im ioBroker korrigieren. Bei Klimasensoren sollte man über einen längeren Zeitraum Vergleichsmessung anstellen.
Bei der Inbetriebnahme von smarten Steckern mit Messfunktion müssen diese ebenfalls mittels Refernezverbraucher oder einem geeichten Messgerät kalibriert werden.
Das aktuelle Setup in der LichtdruckWerkstatt
Ich habe viel experimentiert, getestet, geflasht, kaputt gemacht…
Primär bleiben die zentralen Elemente der Dokumentation übrig. Temperatur- und Feuchtekurven, Schaltzustände, Stromverbrauch und Datenpunkte. Über das Tablet oder den Rechner sehe ich die entsprechende Aufbereitung der Daten und kann den ein oder anderen „Schalter“ drücken.
Erste Versuche der Steuerung und Automatisierung
Der Wunsch ist, an einem physischen Gerät Einstellungen vornehmen und Werte ablesen zu können, das auch mit dem ioBroker kommuniziert. Thermometer oder Sous Vide mit einer (Funk-) Schnittstelle gibt es, doch sind die Wunschkandidaten (zur Zeit noch…) nicht integrierbar, da die Nerdwelt noch nicht aktiv wurde. Zum Teil scheitert die Automation an Touchschaltern…
Die Eigenkonstruktion besteht aus einem „normalen“ Sous Vide, der ein wenig manipuliert wird. Die Verbindungen / Schalter werden abgegriffen und mit einem ESP2866 verbunden, der die Steuerung via Skripte übernimmt. Dieses besagt in Kurzform: Füllstand im Wasserbad checken, Solltemperatur und Zeit einstellen, Startknopf. Wasser bewegen (Pumpe oder Quirl), mach den Heizstab an, wenn Temperatur kleiner als Solltemperatur. Aus wenn Solltemperatur erreicht ist oder Zeit abgelaufen ist. Setzte Solltemperatur (und Zeit) auf 0.
Grafisch sieht das so aus:
Zeiterfassung
Die Basis der Dokumentation und Automation könnte/sollte die Zeit sein, die sich mit Start- und Endpunkten (Zeitstempeln) in Form von Kalendereinträgen darstellen und steuern lassen.
Bei der Dokumentation wird ein „Zeitfenster“ aus Start- und Endpunkten generiert, das (automatisch) benamt wird. Hier müssen Parameter definiert werden, die einen (Teil-) Prozess abbilden. Das kann am Beispiel des Schmelzen die Zeit oder aber über den Stromverbrauch gesteuert werden.
Dazu könnten/müssten Temperatur x über Zeitraum y erreicht werden, was sich über ein Script lösen ließe, das die Funktionen der eingesetzten/verwendeten Geräte simuliert.
Bei der Verwendung des SouseVide, der den Prozess (Temperatur x über Zeitraum y) steuert, würde das heissen, dass das Schmelzen abgeschlossen ist, wenn der Stom ausgeht bzw. die Ist- kleiner ist als die Soll-Temperatur.
Für einen kompletten Prozessdurchlauf ergäben sich so verschiedene Zeitfenster, in denen die einzelnen Aktivitäten mit Laufnummern dokumentiert werden. Diese miteinander zu verknüpfen und zu einer Dokumentation zu sammeln, könnte mit Hilfe von Strich- oder QR-Codes vereinfacht werden.
Ein anderer / weiterer Ansatz ist die Darstellung des Prozess als Termin(e) in einem Kalender oder aber die grafische Darstellung in Form von Temperaturkurven, Schaltzuständen, …
Den kompletten Prozess als Zeitstrahl abbilden?
Im nächsten Schritt können und sollen Teile des Prozesses (im Vorfeld) automatisiert werden. Um z.B. die Wässerung zu automatisieren, bedarf es Skripte, die per regelmäßigem Termin (Cronjob), auf Knopfdruck (Start/Stop) oder auch automatisch (Terminabhängig mit Vorlauf) gestartet werden.
Display ESP8266 am
Umlaute
Bei der Dokumentation und Automation des Ofens lässt sich exemplarisch die Vorgehensweise beschreiben, wie die Techniken kommuniziert.
Die Aufgabe ist, die Temperatur(en) über bestimmte Zeiten zu regeln.
Ein Temperatur- und Luftfeuchtefühler (DHT11) wird im Ofen platziert und überträgt die Daten via Kabel an einen ESP8266 mit TASMOTA, der über wlan mit dem Raspberry kommuniziert und diese im ioBroker verarbeitet.
Die Daten werden bei Änderung oder nach Zeitvorgabe in eine Datenbank geschrieben und speisen die Visualisierung und Skripte mit aktuellen Werten, sowie grafische Charts für die Anzeige des Verlauf.
Ein Skript steuert die Heizmatte, indem bei der Solltemperatur ab und bei einem Grad darunter eingeschaltet wird (Hystese). Mittels der Luftfeuchte wird der Endpunkt der Trocknung gesteuert. Diese steigt erst auf ca 100% und sinkt dann, weil das Wasser verdunstet. Die Trocknung ist abgeschlossen, wenn die Feuchte wieder ansteigt.
Theorie:
Aus dieser Methode lässt sich dann ein Protokoll erstellen…
Es braucht weitere Datenpunkte, um den Prozess zu starten, zu dokumentieren und zu automatisieren. Ein geklickter „Start-Knopf“ in der Visualisierung steuert den Wert, registriert den Zeitpunkt und dient für Skripte. Sollwerte für Temperatur und Luftfeuchte werden per Auswahl, Zahlenfeld oder Schieberegler eingegeben.
So lassen sich die einzelnen Prozesse darstellen und Ergebnisse vergleichen.
Eine Idee ist, mit laufnummern zu arbeiten. So könnte jeder Prozessschritt
Dokumentiert und mit den Motiv oder der Platte gespeichert werden.
Ein Protokoll verbindet die einzelnen Prozesse miteinander. Der Gelatineansatz Nr. 545 wurde auf die Platte p7j6 mit dem Ofendurchlauf o123, mit Negativ/Motiv m24, der Bellichtung b88 und der Wäasserung 68 verwendet. …
Diese einzelnen Prozesse werden per „Knopfdruck“ gestartet. Ein Script legt eine neue Datenbank an und beinhaltet dann alle relevanten Daten, die in dem Zeitraum zwischen START und STOPP stattfinden.
Gegliedert werden könnte das als Job/Auftrag j005
Die Laufnummer beschreibt die Daten im Zeitraum, in dem es passierte.