Was hier gesehen wird ist eine zukünftige Suite, mit der man Prozesse jeglicher Art nicht nur designen, sondern auch Steuern können soll. Das ganze soll natürlich einigermaßen erweiterbar sein (plugins!), sodass dem freudigen GPIO/MQTT/I2C/etc nichts im Wege steht.
2. Warum der Aufwand, dafür extra eine neue Software zu schreiben?
Es gab schlichtweg keine, die meinen Erwartungen entsprach. Diese waren: Eine einigermaßen simple Benutzeroberfläche ähnlich wie "Delphi" (falls das noch wer kennt) und eine redundante Steuerung von Anlagen über Internet und Lokal. Im Klartext: Wenn die Internetverbindung aus welchen Gründen auch immer ausfallen sollte, muss man direkt an der Anlage den Prozess Überwachen und Steuern können. Zudem ist der Lerneffekt enorm.
3. Warum nicht CraftBierPi ?
Weil CraftBierPi - wie der Name schon andeutet - eigentlich nur auf das Brauen ausgelegt ist. Diese Software ist mehr generalisiert.
4. Wie soll das ganze funktionieren?
Was man hier sieht ist erstmal die UI des Prozesseditors. In diesem stellt man einen Prozess zusammen und exportiert ihn. Was noch nicht dargestellt wird sind HTML-Elemente wie InputBoxen, Slider, Check- oder Radioboxen. Diese kann man der per Drag-And-Drop auf das entsprechende Element ziehen, sie werden später für die Steuerung benötigt und können z.B. Temperaturen anzeigen oder setzen. Zum Prozessschema wird dann im Prozessablaufseditor (kommt noch) der entsprechende Prozess als Flowchart gebaut. Sobald man also Prozessschema und Prozesssablauf hat, kann man diesen in die Prozesskontrolle laden und laufen lassen. Im Endeffekt ist das dann ein Programmieren das Prozesses in Blöcken, wie es schon in anderen Softwaren der Fall ist (So ähnich wie Scratch, falls das wer kennt).
Während des Prozesses kann natürlich jeder Schritt überschrieben werden um eventuelle Störungen zu beseitigen / wiedergutzumachen.
Die Software benögtigt - falls das nicht offensichtlich war - im Endeffekt zwei Rechner: Einen "Mainframe", der Rezepte / Prozesse / usw. verwaltet und einen, der direkt am Prozess angebunden ist (in meinem Fall ein RPi direkt am Einkochautomaten). Grund hierfür ist wie bereits die Redundanz.
Wann ETA?
Keine Ahnung. Ich schreibe diese Software als Ausgleich zum lernen fürs Studium
Was kommt als nächstes?
Jetzt wo der Prozesseditor fast funktioniert werde ich die HTML-Elemente einprogrammieren, sodass man diese auf die Knoten legen kann. Danach einige kosmetische Veränderungen am Prozesseditor. Sobald ich damit zufrieden, werde ich mich am Prozessablaufseditor/Programmeditor spielen.
Sobald die beiden Dinger laufen wird es langsam Zeit, mit der Hardware zu Interfacen und erste Tests zu fahren.
Wo? Und warum heißt das ADAM?
Auf: https://github.com/olutmatkaijian/ADAM
Und es heißt nur Vorläufig "ADAM" - "Automated Data Aquisition and Management", aber eventuell benenn ich sie noch um ("Monolith" wäre ein treffender Name).
Voraussetzungen
Eine Linux-Machine mit Python3 und Sqlite3 sollte ausreichen. Das im Github enthaltene "install_script.sh" sollte bei ausführung ein neues virutal environment anlegen und automatischen die notwenigen Packete installieren.
Mit "source ADAM_VENV/bin/activate" (dieser schritt ist wichtig) und danach "./run.sh" sollte sich der Server starten.
Schon benutzbar?
Nein.
So jetzt muss ich aber erstmal ruhen.
