Sirius3 hat geschrieben:@DeaD_EyE: die Kombination aus globaler Variable `door` und ContextManager ist sehr komisch.
Stimmt. Sieht auch komisch aus und door ist vom Himmel gefallen.
Man kann Flask objekte an app.config übergben.
Sirius3 hat geschrieben:`setmode` setzt einen globalen Zustand, sollte also nur global am Anfang des Skripts gesetzt werden.
Ja und am besten nicht im gleichen Prozess. Kein Threading, Multiprocessing.
Sirius3 hat geschrieben:Kommunikation zwischen Hauptprogramm und Thread muß immer über spezielle Objekte stattfinden, hier Semaphore oder Du benutzt gleich nur einen Timer. Klarer wäre für mich ein dauernd laufender Thread, der über eine Queue mit den Routes kommuniziert, dann könnte man auch einfach mehrere open/close-Kommands ohne Fehlermeldung absetzen.
In einem aktuellen Projekt nutze ich multiprocessing.Process und unterschiedliche Module zu starten, die über mehrere message queues miteinander kommunizieren. Daneben wird noch ein namespace mit mehreren dicts jedem Process zur Verfügung gestellt, um den aktuellen Status zu teilen bzw. um dynamisch Konfigurationsänderungen vorzunehmen und ggf. die Prozesse neu zu starten. Kommuniziert wird über zmq. Das würde ich jetzt aber nicht unbedingt einem Anfänger empfehlen.
Queues wären Sinvoll. Man sollte wirklich den Teil des Webservers auslagern in eigenen Code und über queues kommunizieren. Ein manager Prozess kann die beiden Prozesse starten (Hardware, Webserver).
Code: Alles auswählen
import multiprocessing as mp
# Webservercode ausgelagert
from webserver import app
def do_something(cmd):
pass
def doorcode(queue):
while True:
command = queue.get() # hier blockiert er solange die queue leer ist.
do_something(command) # hier soll irgendwas geschaltet werden
manager = mp.Manager()
queue = manager.Queue()
app.config['queue'] = queue
webserver = mp.Process(target=app.run, kwargs={'host': '0.0.0.0', 'port': 5000})
webserver.start()
doorserver = mp.Process(target=doocode, args=[queue])
doorserver.start()
# ab hier müssten 4 Prozesse laufen.
# 1. Der aktuelle Code
# 2. Der Manager läuft in einem eigenen Prozess.
# 3. Webserver hat die queue in app.config['queue']
# 4. doorcode hat ebenso die Queue
Würde man dem Beispiel folgen, müsste es die Datei webserver.py geben, in der es das objekt app gibt.
app.run() startet die Eventloop des Webservers. Der Webserver gibt dann die Befehle an die queue weiter.
queue.put('befehl')
Auf der anderen Seite arbeitet der doorcode Process die Befehle ab.
Die Automatisierung ist das größere Problem.
Mit einer S7 wäre es ziemlich einfach.
Funktionen wie Start/Stop/Not-Halt/Quittieren sind mit zwei Bausteinen erledigt. Ein Flipflop mit Setzdominaz für den Not-Halt und eins für den Betrieb Automatik. Damit wären dann die oberen Funktionen erledigt. Dann nochmal zwei Bausteine für Linkslauf und Rechtslauf.
Hingegen ist es mit Python etwas anders. Wenn ich mir den Programmcode zum Ansteuern des Tors vor meinem geistigen Auge so vorstelle, sehe ich einmal Callbacks und Klassen. Die Callbacks (Interruptsteuerung, geht mit der Library) rufen die abstrahierten Methoden auf und ändern die Attribute in dem Objekt und steuern die Ausgänge. Abstrahiert in dem Sinne, dass die Lichtschranke die Methode stop() aufruft. Intern müsste dann der state auf Stop geändert werden, Antriebe deaktivieren und die Ausgänge für die Lampen setzen.
Ich muss jetzt mal so langsam Schluss machen.
sourceserver.info - sourceserver.info/wiki/ - ausgestorbener Support für HL2-Server
mit Linux und Websites an sich kennen wir uns besser aus als mit Python, wie gesagt Neueinsteiger 
