Ich würde ja eher CherryPy mit TKinter vergleichen, zumal CherryPi deutlich älter als Bottle ist. Was das Routing und andere Basics angeht, finde ich Bottle und Flask sehr gleich. Na ja, nicht weiter verwunderlich, weil Flask als Aprilscherz mit starken Anspielungen auf Bottle gestartet ist. Dass Flask ein "richtiges" Projekt wurde, kam erst danach.
Abgesehen davon ist Flask für dein Projekt in der Tat eine gute Wahl.
Gruß, noisefloor
Swp2000.de : du kannst auf jedem Rechner inkl. dem Raspeberry Pi so viel Software laufen lassen, bis:
1. die CPU am Limit ist
2. du zu wenig RAM hast
3. der Zugriff auf sonstigen Ressourcen (Laufwerke, Netzwerkports) irgendwas limitiert.
Ob das immer sinnvoll ist, ist was anderes. Siehe Anmerkung im letzten Absatz vom Post von DistroEx
Gruß, noisefloor
Du musst halt: Geduld haben. So wie du lernen willst, ist es 3-fach komplex:
* Du kannst Fehler bei der Programmierung machen.
* Du kannst Fehler bei der Ansteuerung der GPIOs machen.
* Du kannst Hardwareproblem haben.
Projekt haben ist grundsätzlich gut, (erstmal) ohne zusätzliche Hardware ist deutlich einfacher. Und immer in _kleinen Schritten vorgehen. Erst die Lichtschranke sicher im Griff haben, dann den Server ansteuern.
If ist wie ich es verstehe ien Bedingung, wo ich der Meinung bin, das erst wenn diese Erfüllt ist, das else zum tragen kommt.
Nein, falsch verstanden `if ... else` kannst du so übersetzen:
WENN/IF (Bedingung erfüllt) dann (führen diesen Programmcode aus) SONST/ELSE (führe jenen Programmcode aus).
Es kann _nie_ der Codeblock nach dem IF ausgeführt werden und _dann_ noch zusätzlich der ELSE Block. Geht nicht. Entweder das eine oder das andere. Gleiches gilt für if..elif..elif..else Kaskaden. Es wird immer nur ein Codeblock ausgeführt. Das ELSE ist übrigens optional, d.h. man muss kein ELSE zu jedem IF haben.
In der Python Doku wird es nochmal auf den Punkt gebraucht: "It selects exactly one of the suites by evaluating the expressions one by one until one is found to be true (see section Boolean operations for the definition of true and false); then that suite is executed (and no other part of the if statement is executed or evaluated). If all expressions are false, the suite of the else clause, if present, is executed."
Gruß, noisefloor
"aufgeräumt wird später" jetzt will ich das ding erst mal in aktion sehen...
Nochmal: du hast es nicht aufgeräumt, du hast es _schlechter_ gemacht. Die Änderung war total überflüssig. Und auch nochmal: für alles eine Ausrede haben, warum es schlecht ist, bringt dich nicht weiter.
Ist aber am Ende beides dein Problem. Und motiviert halt nicht dazu, dir zu helfen, weil du offensichtliche und einfache Tipps nicht annimmst.
Gruß, noisefloor
number = 0 # Schleifen zähler, der nie benutzt wird.
while number <5:
Das ist total sinnlos und noch viel schlimmer als `while 1`. Zumal dir gezeigt wurde, wie es besser / richtiger geht. Du willst doch besser werden, nicht schlechter.
Gruß, noisefloor
Das mit dem + habe ich aus Tutorials, das verstehe ich im Moment gerade,
Na ja, wenn jemand + zum zusammenstückeln von Strings benutzt, dann ist das schon fragwürdig mit den Python Skills des Tutorialschreibers. Das war noch nicht gut noch richtig. Das Thema wird auch im bereits dringend angeratenen Python Tutorial abgefrühstückt: https://docs.python.org/3/tutorial/inputoutput.html
- sleep (2) ist derzeit drin, damit ich online verfolgen kann, was die Unterbrechungen in Raspberry bewirken.
??? - was willst du denn verfolgen, wenn genau nichts passiert? `sleep(2)` unterbricht den Programmfluss an der Stelle, wo es steht, für 2 Sekunden.
Ansonsten sehe ich das eher so, dass du gerade an dir selber scheiterst, weil du für jeden Vorschlag für eine Änderung einen "Grund" hast, dass nicht zu ändern. Wenn du nichts änderst / verbesserst, kannst du auch nix lernen.
BTW, was mir gerade einfällt: die Person, für die die Zigaretten aus dem Stopfautomaten sind, könnte einfach aufhören zu rauchen. Dann a) hättest du ein Problem weniger und b) die rauchende Person potentiell mindestens ein Problem weniger *SCNR*
Gruß, noisefloor
Allgemeine Anmerkungen:
`while 1` ist unpythonisch, da Python Wahrheitswerte kennt. Besser: `while True`.
Strings stückelt man _nicht_ mit + zusammen, sondern es gibt f-Strings oder die ältere `format` Methode. Haben beide den Vorteil, dass sich Python um die korrekte Umwandlung des Objekts für den String kümmert. Also z.B. `print(f"Die gezählte Zahl ist {i}")`
Das `i = i +1` solltest du außerhalb von if / elif / else schreiben, damit du keine unnötig Codewiederholung hast.
pigpio wird importiert, aber nicht benutzt.
Sicher, dass `sleep(2)` an der Stelle sinnvoll ist? Können die Impulse nicht schneller kommen?
Sicher, dass `bounce_time` gleich null sinnvoll ist? Bounct die wirklich nicht?
Um zu sehen, wie schnelle die Signale kommen, kannst du das Programm erstmal zu gestalten:
from gpiozero import LED, Button
from datatime import datetime
button = Button(17,pull_up = True,bounce_time=None) # button ist Lichtschranke
led = LED(18) # LED zur Kontrolle des LS-Signals
button.when_pressed = led.on
button.when_released = led.off
i = 0 # Lichtschrankenimpule Startpos.
while True:
button.wait_for_press()
print(f'{datetime.now()}: Zähler ist {i}')
i = i + 1Hallo,
hyle: der absolute Mainstream ist: Django, FastAPI und Flask, bis zu einem gewissen Grad auch noch Bottle. Mainstream ist für allgemeine Sachen deshalb gut, weil es a) viele Leute gibt, die (ein bisschen 
) Ahnung davon haben und b) man dazu viele brauchbare Infos findet, besonders bei StackOverflow.
FastAPI ist in erster Linie für REST-APIs und ähnliches - auch, wenn andere Sachen damit auch gehen. Bottle bietet Kernfunktionalitäten und könnte / sollte hier ausreichen. Für Flask gilt das gleiche, aber Flask hat mit Jinja2 die bessere Template-Engine an Bord und das viel größere Ökosystem an Erweiterung, falls man mal eine braucht. Django kann alles, hat ein Anfangs etwas steilere Lernkurve, weil per Design der Code auf mehrere Dateien aufgeteilt wird (was einem gerade bei größeren Projekten sehr zu gute kommt), kann dafür OOTB sehr viel.
Wenn die besagte Anwendung die einzige bleibt, würde ich tendenziell bei Flask oder Bottle bleiben. Wenn da ggf. noch mehr, andere Oberflächen zu kommen und ggf. ein DB-Anbindung gebraucht wird, dann würde ich eher zu Django greifen.
Und dann für Flask, Bottle und Django die App über Waitress ode Gunicorn als WSGI Applikationsserver ausliefern.
Gruß, noisefloor
Bzgl. Kaufen: ich habe schon öfters direkt bei Pimoroni in England bestellt, das klappt absolut problemlos - Pimoroni ist schon seriöser Händler. Was du mal prüfen müsstest ist, ob du Zoll / Einfuhrumsatzsteuer auf das Display zahlen musst. Ich meine ja wegen des Warenwerts - Angabe ohne Gewähr. Bzgl. der Verzollung sollte dich normalerweise der Transporteur kontaktieren, dann muss du das an den Zahlen und der macht die Verzollung / die Einfuhr.
Wenn ich (in einem anderen Shop) in den USA bestelle und die Sendung mit FedEx kommt, klappt das absolut reibungslos. Keine Ahnung, mit wem Pimoroni verschickt, sollte theoretisch im Laufe des Checkouts irgendwo stehen. Ich würde aber mal davon ausgehen, dass das mit anderen etablierten Versender ähnlich gut funktioniert.
EDIT: es gibt per Stand jetzt "Internationally tracked" (was immer das auch ist), UPS und DHL.
Gruß, noisefloor
Was wollen uns diese Worte sagen?
Dass du die Grundlagen der Paket- und Systemverwaltung lernen solltest. Insbesonders die elementaren Grundlagen, wann man Root-Rechte braucht und ggf. auch warum. Des Weiteren macht es Sinn, die Meldung zu lesen und zumindest versuchen, zu verstehen. Im gegebenen Fall ist das ja ziemlich eindeutig, warum `apt-get install gufw` nicht funktioniert. Bist du beim Absetzen des Befehls root? Nein, bis du nicht. Musst du aber sein.
Lesestoff:
Gilt auch so gut wie alles für Raspberry Pi OS / Debian. Besonders die Artikel zu apt und apt-get.
Gruß, noisefloor
Ist es überhaupt möglich, in einem Skript zwei unterschiedliche GPIO zu nutzen...?
Du kannst alles nutzen, was zur Verfügung steht. Du kommst dann in den Bereich der nebenläufigen Programmierung. "nebenläufig" heißt, dass mehrere Dinge (quasi) gleichzeitig passieren können. gpiozero hat dafür Callback-Funktionen, die du an bestimmte Events bindest. Das ist jetzt speziell bei reagieren auf GPIO-Events (wie: Spannung liegt an oder nicht) nicht so schwierig, aber nebenläufige Programmierung ist nicht ein einfach, u.U. auch für fortgeschrittene Programmierer nicht. Weil: der Programmablauf ist halt nicht mehr zwangsläufig linear und der Programmcode muss auf Ereignisse reagieren können, die "irgendwann" eintreten. Und wenn dann noch Event A von Event B abhängt, wird's noch komplexer. Wie gesagt: alles machbar, aber dafür sollte man die Basics beherrschen, damit man überhaupt verstehen kann, was da passiert.
Und genau deswegen benutzt man auch möglichst kein `global`, weil: es macht den Zustand des Programms unübersichtlich bis nicht mehr nachvollziehbar, weil an irgendeiner Stelle etwas geändert wird, obwohl es an einer anderen Stelle gerade unpassend ist. Was zu unerwarteten Fehler (im besseren Fall) oder komischen Verhalten und Fehlfunktion (im schlechteren Fall) führen kann.
Gruß, noisefloor
Das Erschwernis das ich glaube zu sehen ist, das in Python Dialekte vorhanden sind (Python, Raspberry, GPIOs etc.)
Das stimmt nicht. Für Python gibt es _eine_ Sprachdefinition. Es gibt verschiedene Implementierungen, was bedeutet, das "wie" das Python im Hintergrund in irgendwas für die CPU verständliches (=Maschinencode) umgewandelt wird, kann variieren. Das ist für die als Anwender aber erstmal egal, weil du es erst mal gar nicht mit bekommst und mitbekommen musst.
Was i.d.R. synonym mit Python (=der Sprachdefinition) genutzt wird ist CPython, die Referenzimplementierung der Python Software Foundation. Das ist auf dem Raspberry Pi installiert, das bekommst du bei allen anderen Linux-Distro OOTB installiert, das bekommst du, wenn du unter Win Python aus dem Microsoft Store installierst, das bekommst du standardmäßig unter MacOS. Und selbst wenn du eine anderen Implementierung wie PyPy haben solltest - der Code, den du schreibst, ändert sich dadurch nicht.
GPIO steht für die Ein- / Ausgabepins (die GPIO Pins halt) des Raspberry Pi, das hat nichts mit Python zu tun. Es gibt halt Python Module zum Ansprechen der GPIO Pins wie das genannte gpiozero. Module gehören bei Python dazu, um die Funktionalität zu erweitern. Die Standardinstallation von Python besteht neben dem Kern, also was "build-in" ist, aus dutzenden Modulen. Des weiteren gibt es noch hunderttausende externe Module wie das bereits genannte gpiozero. Das ist aber für "richtige" Programmiersprachen normal, d.h. das ist bei z.B. JavaScript, Go, Rust, C, C++ etc nicht anders. Da unterscheidet sich nur das "wie", also wie externe Module eingebunden / installiert werden
Programmieren können hat viel mit Lernen und Verstehen zu tun. Das kann auch per Lerning by Doing sein. Wie schon gesagt wurde: auch ich würde die _dringend empfehlen, das Python-Tutorial in der Sprache deiner Wahl durchzuarbeiten, um die Grundlagen zu verstehen. Weil wenn du die drauf hast, dann kann man ggf. auch Anfagen, sich Codeschnipsel aus dem Internet zu suchen und für sich selber sinnvoll zusammenzubauen. "Blindes" Copy&Paste bringt nix - hast du auch schon gemerkt. Das Problemchen ist noch: im Internet gibt es viel alten (und schlechten) Code. Klassiker im Raspi Bereich: zum Ansprechen der GPIO Pins RPi.GPIO statt gpiozero als Modul verwenden. Letzteres ist seit Jahren Standard und in jeder Hinsicht besser und einfacher.
Und ja: Python ist im Vergleich zu anderen Sprachen einfach zu lernen. Das heißt aber _nicht_, dass das ein Selbstläufer ist und man aus dem Nichts mit wenig Wissen ein total tolles Programm schreiben kann.
Bzgl. Hilfe: gibt es hier. Allen _relevanten_ Code zeigen, beschreiben, was man erwartet, beschreiben, was aber passiert und - wenn vorhanden - die _volle_ Fehlermeldung _1:1_ posten. Kein Volltextprosa, keine eigene Beschreibung - mit Aussagen wie "2ter Fehler Pin nicht definiert oder so..." kann keiner was anfangen.
Des Weiteren solltest du beim Lernen mental dafür bereit sein, den Code mehrmals neu und besser zu schreiben. Gerade am Anfang sind die Chancen hoch, dass dir von einem Helfenden gesagt wird, was alles falsch ist und das am Ende effektiv 95% deines Code betrifft. Darfst du halt nicht persönlich nehmen, ist Teil des Lernprozesses. Refractoring ist Teil von Codeentwicklung, auch bei Profis.
Gruß, noisefloor
hyle : würde ich auch vermuten... Wie __blackjack__ schon sagte: das Skript ist nicht robust, aber dürfte eigentlich nicht das System zum Absturz bringen.
Gruß, noisefloor
Die Frage ist nur wie komme ich dann auf den Rpi es war meinst immer so keine Ssh bzw. VNC Verbindung möglich...
Wurde auch schon gesagt: persistente Logs aktivieren. Dann bleiben die Logs auch nach einem (erzwungenen) Neustart erhalten.
Gruß, noisefloor
Oder halt ab und an ins Log schauen und gezielt auf die Unit filtern. Den Befehl dazu hatte ich gepostet.
Wichtig: User Units werden gestoppt, wenn du dich _ausloggst_ . Also: eingeloggt bleiben. Oder enable-linger aktivieren. Einfach eingeloggt bleiben ist aber hier einfacher. Oder halt alternativ eine systemweite Unit. Die läuft von Systemstart bis zum Herunterfahren / Neustart.
Gruß, noisefloor
Na ja, DU musst halt mal die Fehlermeldung liefern, die das Programm zum Stoppen / Absturz bringt. Dann kann man dir (hoffentlich) weiter helfen.
Gruß, noisefloor
und ich weis nicht warum....
Deswegen ja der Vorschlag mit der systemweiten systemd Service Unit.
Wenn du es als systemweite Unit machst solltest du noch als Direktive `After=network-online.target` im Unitblock hinzufügen, weil das Skript ja per Netzwerk im InfluxDB kommuniziert, richtig?
Die Unit sähe dann so aus:
[Unit]
Description=SmartmeterTiNetz
After=network-online.target
[Service]
User=pi
ExecStart=/home/pi/pythonvenv/bin/python3 /home/pi/Desktop/SmartmeterTiNetz.py
Restart=always
[Install]
WantedBy=multi-user.targetWenn du die User Unit schon eingerichtet haben solltest -> erst deaktivieren und dann löschen, damit nicht ausversehen was kollidiert.
Gruß, noisefloor
hyle : für das Testskript für ich den `sleep` Zeitraum viel größer machen, wenn es per Service Unit läuft. OOTB laufen die `print` Ausgaben ins Log von systemd und man ballert sich grundlos das Log zu.
Zum eigentlichen Thema: braucht der TE wirklich eine User Unit = das Skript soll nur laufen, wenn der User eingeloggt ist? Nach meinem Verständnis soll das Skript doch immer laufen & logen? Ändert am prinzipiellen Vorgehen zwar "nur" an einer Stelle was - systemweite Unit vs. User Unit - kann aber nachher in der "realen Wlet" einen Unterschied machen.
Gruß, noisefloor
Hallo,
hyle : nee, Install darf nicht leer sein - damit wird ja definiert, bei welchem Target die Unit abgerufen wird. Da ist wohl ein Fehler bzw. fehlt eine Zeile im Wiki. Das Beispiel da ist auch nicht von mir.
Welche Fehlermeldungen gibt es denn noch zu der Unit? Das `Active: inactive (dead)` kann eigentlich nicht alles sein. Bitte mal die letzten Einträge zur Unit posten: `journalctl -u smartmeter.service -n 30`.
Gruß, noisefloor
Welches Zeichen kommt bei ALT + STRG + Q?
Gruß, noisefloor