Posts by Raspbuino

    So....

    ein gepflegtes Glas Rotwein, einen Döner, etwas Schokolade, eine ausgedehnte Runde mit unserer Hündin und so manchen Kaffee später melde ich mich nun von meinem nagelneu aufgespielten Raspbian Stretch mit folgendem Text, frisch aus dem Terminal kopiert:

    :bravo2:


    Das war es! Es hat was nicht zusammengepaßt! Was genau da im Hintergrund nicht zusammengearbeitet hat, werd ich wohl nie erfahren. Egal.


    Lieber Bernd,

    Du hast mir den entscheidenden Hinweis gegeben und dafür ein herzliches Dankeschön!!

    :danke_ATDE:


    Mir bleibt die Erkenntnis, dass ich das jetzt auch Stück für Stück bei den restlichen Raspis, die bei mir rumliegen, auch noch tun müßte. Alles zu seiner Zeit.

    Und natürlich, dass man nicht zu schnell aufgeben darf.

    Danke auch an das Forum an sich!


    Viele Grüße,

    Mirko

    Oh....

    danke fürs genaue Hinsehen!


    Also da sieht man wieder mal, wie schnell die Zeit vergeht. Hab zwar schon von Stretch gehört aber hab mir gedacht, naja, ich hab ja ein -normales- Update gemacht. Also alles gut.

    Nee, nix ist gut - einmal mehr muss man sich kümmern. Nichts bleibt wie es ist und das hat nicht immer nur Vorteile. Selber schuld also.

    Werd also zunächst Sicherungskopien machen und dann gehts an eine saubere Neuinstallation...

    Ich weiß ja nicht, ob ich der einzige bin, der das nicht grade jeden Tag macht. So sehr mit Linux gefällt - ich glaub ich werds nie wirklich verinnerlichen. Aber ich arbeite dran.

    Mmmist.

    ;)

    Hallo Bernd,


    tja - herzlichen Glückwunsch!

    Also bei mir klappt das so leider nicht und wie gesagt, VOR dem Update hats ja bei mir funktioniert (auch ohne den Eintrag in config.txt).

    Kontakte und Widerstand hab ich grad nochmal geprüft. Passt soweit.

    Werd auf nen anderen Sensor (SHT31-D über I2C) setzen. Hat mich die Tage echt genug Nerven gekostet.

    Interessant fänd ichs aber schon, ob ich der einzige bin, der nach dem Update die Probleme hat.


    Vielen Dank für Deine Mühe!


    Grüße,

    Mirko

    Hallo Bernd,

    erstmal herzlichen Dank, daß Du Dich der Sache angenommen hast!

    Hab mal den wesentlichen Code zusammengeschrieben und einen kleinen Hinweis habe ich vielleicht, in welcher Richtung etwas vielleicht nicht (mehr) ganz stimmt. Der Reihe nach.


    Das vorletzte Update/Upgrade vor dem letzten lief bestimmt schon vor etwa einem Jahr. Dazwischen hatte ich mich um sowas nicht mehr gekümmert. Im Grunde lief die Sache ja auch perfekt bis ich den Raspi nach einem Stromausfall eben ausgeschaltet hatte und mich zeitmäßig nicht weiter kümmern konnte (und einen Autostart hatte ich nicht programmiert). Auf jeden Fall aber war das schon Python 3. In Python 2 hab ich nie programmiert.


    Hier der Code, der so im "großen" Programm bisher funktioniert hat:

    Damit probiere ich im Moment jetzt halt etwas rum.

    Hab auf nem Breadboard jetzt auch nur den DHT22 angehängt und zwar mit dem Datenpin auf dem Raspi-Pin 3 (= BCM-Code 2). Widerstand zwischen Datenpin und VCC (3.3V) sind 8.2kOhm.


    Und "interessante" Hinweise kommen ans Licht.

    Der Codeschnipsel wird mit "sudo python3 DHT22test.py" gestartet.

    Ohne das "sudo" krieg ich folgende Fehlermeldung:


    Traceback (most recent call last):

    File "DHT22test.py", line 9, in <module>

    Feuchte, Temperatur = Adafruit_DHT.read(sensor, pin)

    File "/usr/local/lib/python3.4/dist-packages/Adafruit_DHT-1.3.1-py3.4-linux-armv7l.egg/Adafruit_DHT/common.py", line 77, in read

    return platform.read(sensor, pin)

    File "/usr/local/lib/python3.4/dist-packages/Adafruit_DHT-1.3.1-py3.4-linux-armv7l.egg/Adafruit_DHT/Beaglebone_Black.py", line 213, in read

    raise RuntimeError('Error accessing GPIO. Make sure program is run as root with sudo!')

    RuntimeError: Error accessing GPIO. Make sure program is run as root with sudo!


    Mit dem "sudo" läufts aber es sieht dann halt so aus:

    pi@raspberrypi:~/Mirko $ sudo python3 DHT22test.py

    Feuchte : None

    Temperatur: None


    Keine Daten also. Je nachdem, zu welchem Zeitpunkt ich das Programm beim Abbruch mit Strg+C "erwische", bekomme ich manchmal (nicht immer!) dann folgende Fehlermeldung bzw Hinweis:


    pi@raspberrypi:~/Mirko $ sudo python3 DHT22test.py

    Feuchte : None

    Temperatur: None

    ^CTraceback (most recent call last):

    File "DHT22test.py", line 9, in <module>

    Feuchte, Temperatur = Adafruit_DHT.read(sensor, pin)

    File "/usr/local/lib/python3.4/dist-packages/Adafruit_DHT-1.3.1-py3.4-linux-armv7l.egg/Adafruit_DHT/common.py", line 77, in read

    return platform.read(sensor, pin)

    File "/usr/local/lib/python3.4/dist-packages/Adafruit_DHT-1.3.1-py3.4-linux-armv7l.egg/Adafruit_DHT/Beaglebone_Black.py", line 208, in read

    result, humidity, temp = driver.read(sensor, gpio[0], gpio[1])

    KeyboardInterrupt


    Das hat mich jetzt echt stutzig gemacht und etwas ratlos.

    Scheinbar wird da auf nen Treiber zurückgegriffen, der eher was mit einem "Beaglebone_Black" anstellen will.

    Sehr verwirrend das alles (zumindest für mich :-/).


    Die Frage mit den Overlays kann ich nicht so ganz beantworten, weil ich da ehrlich gesagt nicht 100%ig firm bin, wonach ich da jetzt genau schauen müßte und wo da eine LOG-Datei versteckt ist, weiß ich leider auch nicht.

    Hier aber mal zumindest die Eintragungen aus config.txt:


    # For more options and information see

    # http://rpf.io/configtxtreadme

    # Some settings may impact device functionality. See link above for details


    # uncomment if you get no picture on HDMI for a default "safe" mode

    #hdmi_safe=1


    # uncomment this if your display has a black border of unused pixels visible

    # and your display can output without overscan

    #disable_overscan=1


    # uncomment the following to adjust overscan. Use positive numbers if console

    # goes off screen, and negative if there is too much border

    #overscan_left=16

    #overscan_right=16

    #overscan_top=16

    #overscan_bottom=16


    # uncomment to force a console size. By default it will be display's size minus

    # overscan.

    #framebuffer_width=1280

    #framebuffer_height=720


    # uncomment if hdmi display is not detected and composite is being output

    #hdmi_force_hotplug=1


    # uncomment to force a specific HDMI mode (this will force VGA)

    #hdmi_group=1

    #hdmi_mode=1


    # uncomment to force a HDMI mode rather than DVI. This can make audio work in

    # DMT (computer monitor) modes

    #hdmi_drive=2


    # uncomment to increase signal to HDMI, if you have interference, blanking, or

    # no display

    #config_hdmi_boost=4


    # uncomment for composite PAL

    #sdtv_mode=2


    #uncomment to overclock the arm. 700 MHz is the default.

    #arm_freq=800


    # Uncomment some or all of these to enable the optional hardware interfaces

    dtparam=i2c_arm=off

    #dtparam=i2s=on

    dtparam=spi=on


    # Uncomment this to enable the lirc-rpi module

    #dtoverlay=lirc-rpi


    # Additional overlays and parameters are documented /boot/overlays/README


    # Enable audio (loads snd_bcm2835)

    dtparam=audio=on


    # DS18B20

    dtoverlay=w1-gpio

    gpiopin=4


    ---------------------


    Wär toll, wenn Du oder jemand anderes noch einen weiteren Hinweis hätte.


    Viele Grüße,

    Mirko

    Hallo zusammen,


    manchmal möchte man doch echt verzweifeln. Also erstmal durchatmen.

    Mein DHT22, direkt an einem Raspberry Pi 2 Model B angeschlossen, läßt sich einfach nicht mehr auslesen, nachdem ich dem Raspi ein Update verpaßt hatte.

    Zuvor hatte alles wunderbar funktioniert. Es handelt sich dabei um eine kleine Wetterdatenstation mit einer Basisstation auf dem Schreibtisch (Raspi + DHT22 + DS18B20 + Funkmodul) und einer batteriebetriebenen Außenstation auf dem Balkon, basierend auf einem Atmega und diversen Sensoren (u.a. ein zweiter DHT22). Hatte sogar angefangen, das mal in einem kleinen Blog zu beschreiben (skunklog.de), da sind auch ein paar wenige Bilder drin. Nicht mehr ganz aktuell.


    Und ich bin mir fast sicher, dass es nur am Raspi-Update selber liegen kann.

    Weil:

    1.) der Tausch beider DHT22 zwischen Basisstation und Außenstation zeigt, dass beide DHT22 an der Außenstation einwandfrei Daten liefern, nicht aber der, der jeweils am Raspi angeschlossen ist.

    2.) Die Wetterdatenstation lief in der ersten Jahreshälfte mehrere Monate völlig stabil. Also kann ich mich beim Anschließen und Auswahl des Widerstands etc nicht wirklich vertan haben.

    3.) Nach einem Stromausfall lief das Teil mehrere Monate nicht mehr und erst die letzten Tage fand ich wieder Zeit, mich darum zu kümmern. Nach einem ersten Anschalten bzw Restart lief alles sofort wieder problemlos.

    4.) Dann "gönnte" ich mir eine Tasse Kaffee dem Raspi ein Update (sudo apt-get update, sudo apt-get upgrade). Tja... und erst seitdem krieg ich keine Daten mehr aus dem DHT22 am Raspi ausgelesen.


    Natürlich hab ich das Internet und auch dieses Forum hier entsprechend halbwegs durchsucht und scheinbar bin ich nicht ganz allein mit diesem Problem.

    Aber eine echte Lösung hab ich nicht gefunden. Das muss irgendwas mit der verwendeten Library (?) von Adafruit zu tun haben. Wo genau da der Hase im Pfeffer liegt, weiß ich aber eben nicht und im Moment gehen meine Gedanken eher in Richtung Verwendung eines alternativen Sensors (SHT31-D, auch von Adafruit). Der DHT22 war schon immer irgendwie speziell und fast wie eine Diva. Aber wie gesagt, wahrscheinlich liegts nicht am Sensor selber, sondern am Treiber oder was auch immer da von Adafruit verschlimmbessert wurde. Schon seltsam das.


    Hat jemand irgendeinen Tip für mich?

    :conf:


    Viele Grüße

    So...

    ich muss sagen, nachdem ich mich jetzt am Wochenende, motiviert durch diesen Thread, mal so richtig reingekniet und versucht hab, in die objektorientierte Programmierung einzusteigen, glaube ich sagen zu können, dass mit der Einstieg jetzt gelungen ist 8)

    Ich bin dabei, meinen bisherigen Code komplett umzukrempeln und Stück für Stück funktioniert es sogar und die Sache ist insgesamt schon deeeutlich übersichtlicher geworden. Ich bin zwar noch lange nicht fertig aber das ist jetzt in erster Linie Fleißarbeit.


    Ganz nebenbei bin ich dabei meine globale Variable losgeworden :bravo2:


    Den Thread hier möchte ich somit als sauber abgeschlossen betrachten.

    Herzlichen Dank ans Forum für die vielen Beiträge, die mir die letzten Tage eine echt steile Lernkurve beschert haben.

    :danke_ATDE:

    Grüße,

    Raspbuino

    Öhm,...sieht zwar schöner aus, aber self.counts zählt hier separat für jede erzeugte Instanz separat. Genau das soll ja nicht sein: ein einziger Zähler soll immer dann hochgezählt (oder bei Erreichen des Limits (hier 12) zurückgestellt) werden, sobald eine der Instanzen zur Aktion kommt.


    Ein anderes Detail ist mir aufgefallen. Da hätte ich ne Frage dazu.

    Vorher wurde ein Teil der Parameter beim Erzeugen der Instanzen übergeben (hier: die Intervalle) und ein weiterer Teil beim Aufrufen der Methoden (hier: die "Namen"). In Deinem optimierten Code nun werden beide Parameter schon beim Erzeugen der Instanzen übergeben.

    Kann ich das so sehen, dass es schlichtweg sauberer und effektiver ist, Parameter, die sich nicht ändern, immer beim Erzeugen der Instanz zu übergeben? Oder gibts noch andere Gründe? Danke jedenfalls für den Hinweis, das hat mir ein Stück weit die Augen geöffnet, wenn ichs richtig verstanden habe.

    Grüße,

    Raspbuino

    Nun, also...

    im Grunde wollte ich tatsächlich "nur" die globale Variable loswerden (schlechter Programmierstil etc...)

    Was der Code im Kern machen soll, hab ich (zumindest glaube ich das) in #30 beschrieben.

    Knackpunkt bei der Geschichte ist, dass zwei (aus bestimmten Daten speziell "zusammengebaute") Messages in recht genau einzuhaltenden Intervallen zu senden sind (damit werden Motoren gesteuert). "Gleichzeitig" sind aber ebensolche Messages zu empfangen, die in ähnlichen Zeitintervallen über den CanBus laufen. Hier sind die Daten enthalten, die mich interessieren. Soweit ich mich mit dem CanBus auskenne, sind die Daten, egal ob ein- oder ausgehend, sowieso rein sequentiell, d.h. da ist nichts wirklich parallel und wenn ich es nicht zu schlecht programmiere, dürfte das ohne Multithreading trotzdem ganz gut funktionieren.

    Und im ersten Test hat ja auch funktioniert. Mittlerweile, also quasi im Verlauf dieses Threads hab ich doch einiges umgeschrieben und ich glaube, jetzt auch eine gut brauchbare Lösung gefunden zu haben. Durchaus in Anlehnung an den Beispielcode in #20 von Tell (vielen Dank!) und zwar direkt um eine wichtige Funktionalität ergänzt, denn ich benötige bei den gesendeten Messages einen "zyklischen Zähler", der die ausgehenden Messages mit einer fortlaufenden Nummer versieht, die aber wieder auf Null gesetzt wird, sobald ein festgelegter Maximalwert erreicht ist. Und zwar über die unterschiedlichen Messages hinweg.

    Diese verschiedenen Messages sind jetzt genau das, was ich unter unter machwas() behandeln möchte.


    Somit wäre grob umrissen der Kern des Codes :

    Code
       while Abbruchbedingung == False:
        1) machwas_1() => Prüfen, ob es Zeit ist, Message1 zu senden. Falls ja, dann Message1 verfassen und senden
        2) machwas_2() => Prüfen, ob es Zeit ist, Message2 zu senden. Falls ja, dann Message2 verfassen und senden
        3) machwasanderes() => soviel wie möglich eingehende Messages sammeln und in einer Liste zwischenspeichern

    Schön ist, dass das nur für eine bestimmte Zeit (weniger als eine Minute) gemacht werden muss und danach ausreichend Zeit ist, die gesammelten Daten auszuwerten und zu speichern, bevor es wieder von vorne losgeht.

    Ich denke, es ist eine guteI dee, hier mit Objekten zu arbeiten. Dazu ein kleiner Beispielcode, mit dem ich das ausprobiert habe, was ich im Kern brauche. Und es klappt. Damit wird meine Code insgesamt auf jeden Fall übersichtlicher und so allmählich dämmerts mir, was Objektorientierung kann. Learning by doing halt.

    Die beiden Instanzen one, two wären dann also meine Sende-Messages. Das Lesen eingehender Daten ist da jetzt nicht explizit berücksichtigt. Das wäre ein separates Objekt. Jede Instanz hat hier ihren eigenen "Timer" und es gibt einen (!) gemeinsamen Zähler (Macher.counts) für beide Instanzen. Damit kann ich jetzt arbeiten, ich habe das Werkzeug, das ich brauche. Tagesziel ist erstmal erreicht. Ich bin ein bissl stolz auf mich aber gerne könnt ihr das jetzt auseinandernehmen (bitte seid gnädig: bis gestern wußte ich grad mal, wie man "Objekt" schreibt ;))


    Grüße,

    Raspbuino

    So siehts aus! :)

    Kurz zum Hintergrund: da läuft ein CanBus (mit ner PICAN2 - Platine übrigens) und es müssen sowohl Daten gesendet und Daten empfangen werden. In beiden Fällen sind Messages dabei, die im Bereich zwischen 10 und 50Hz rein/rausgehen. Es sind also zwei mehr oder weniger "parallele" Prozesse, die eben abwechselnd laufen müssen. Das Senden enthält mindestens zwei Aktionen, die mit unterschiedlichen aber doch relativ genau einzuhaltenden Intervallen ausgeführt werden müssen.

    In der verbleibenden Zeit müssen dann möglichst alle Daten eingesammelt werden, die reinkommen. Da kommts dann also drauf an, die Sache möglichst verlustfrei zu gestalten. Ich konnte nur hoffen, dass der Raspi schnell genug ist.


    Wie gesagt, ich hatte bereits kurz Gelegenheit, den Code auszuprobieren....und offensichtlich lief der Code ausreichend schnell.

    Hätte ich selber nicht gedacht, dass das auf Anhieb (zumindest grundsätzlich) funktioniert. Ich hab sowas noch nie vorher gemacht aber manchmal klappt halt auch was direkt und das ist dann ein echtes Erfolgserlebnis. Deswegen hab ich ja auch so einen Riesenspass mit dem Raspi, Python und dem ganzen Rest.


    Die gesammelten Daten hab ich noch nicht analysiert um behaupten zu können, diese wären vollständig aber es sah auf den ersten Blick gut aus. Weil es bereits funktioniert, bin ich da jetzt schon etwas entspannter unterwegs. Trotzdem will ich versuchen, dies auch "sicherzustellen".


    Heut hab ich mich endlich mal vorsichtig an die Programmierung einer Klasse gewagt. Ich kann behaupten, den Einstieg hab ich jetzt. Feine Sache das.


    Grüße,

    Raspbuino

    Ja, ich geh da voll mit.

    Aber step by step. Im Vergleich zu bisherigen Codes (kaum separate Funktionen) mach ich mittlerweile vieles ganz anders. Allein die relativ konsequente Verwendung von Funktionen macht schon sehr viel aus und macht den Code besser wartbar. KLassen sind dann der nächste Schritt. Und im Verlauf dieses Threads hab ich z.B. die Variablennamen konsequent auf die "Python-Norm" umgestellt, was gut war. Einiges konnte ich ausmisten und am Ende werd ich bestimmt irgendwie auch noch die globalen Variablen los. Im Moment jedenfalls hilfts und es funktioniert (und ich bin durchaus weit davon entfernt, den Überblick zu verlieren). Rein optisch ist es zum aktuellen Stand jedoch sehr wohl eleganter. Wie gesagt, ich arbeite noch dran ;)

    Grüße,

    Raspbuino

    Vielen Dank für die tollen Beiträge! Vor allem auch die Beispielcodes. Vielleicht krieg ichs mit der Klasse ja doch nochmal hin ;)

    Mittlerweile hatte ich Gelegenheit, den Kerncode der Steuerung auszuprobieren und das hat auch tatsächlich weitestgehend funktioniert. Ich muss aber gestehen, dass ich das jetzt doch erstmal mit ner globalen Variable gelöst hab.

    Das mag zwar nicht einem guten Stil entsprechen... andererseits war das deutlich eleganter umzusetzen als lokale Variablen über die Funktionen in zwei Ebenen auszutauschen. Ich hatte es ausprobiert und das sah deutlich unübersichtlicher aus und ich kann mir nicht vorstellen, dass das effizienter sein soll. Da lass ich mich aber gerne vom Gegenteil überzeugen. Schätze, da landen wir dann wieder bei einer Klasse.

    Da ich noch nicht fertig bin, werd ich an dem Thema aber dran bleiben und mir duchaus auch die Geschichte mit asyncio näher ansehen. Das könnte hier nämlich perfekt auf mein "Problem" passen.

    Grüße,

    Raspuino

    Danke für den Tipp! Könnte durchaus für mich interessant sein, weil es geht dabei durchaus darum, so manche Dinge mehr oder weniger parallel zu tun. Aber jetzt treib ich das erstmal so voran, bis es getestet werden kann und dann schau mer mal, wo ggf die Grenzen dabei liegen, wie ich es mache. Vielleicht ist es auch gar kein Problem. Aber mein Ziel ist nicht allein, die Geschichte "irgendwie" zum Laufen zu kriegen, sondern durchaus mit dem Anspruch, einen halbwegs gut wartbaren Code zu schreiben, der vielleicht auf seine Art auch, nun ja, schön ist. Und deswegen nehm ich den Hinweis weiter oben hinsichtlich Konventionen bei Namensgebung von Variablen ernst.

    Grüße,

    Raspbuino

    Hallo nochmal,

    so...Feierabend und schon wieder vor der Kiste... :)

    Quote

    Na ja, das ist halt so, wenn man mit Funktionen programmiert. Das ist schon die richtige "Eleganz"Das

    Das nehm ich dann gerne mal so mit! Ich denke, so mach ich das erstmal. Allerdings ist es so, dass ich mehr als eine Aktion hab, die zyklisch durchgeführt wird (aktuell zwei und zwar mit unterschiedlichen Frequenzen). Das heißt, ich muss zwei Variablen allein schon deswegen an die Funktion übergeben.

    Das mit yield bzw einer Generatorfunktion kannte ich bisher gar nicht. Hab das in meinem schlauen Buch grad nachgelesen und den Code ausprobiert. Sehr interessant - wär ich ansonsten sicherlich nicht so ohne Weiteres drübergestolpert.

    Das mit dem i-Tüpfelchen, nämlich einer Klasse, würde mich trotzdem interessieren. Vielleicht krieg ichs irgendwann noch gebacken.


    Vielen Dank soweit für die Hilfe! :thumbup:


    BTW: ( Linus) die Variablennamen überarbeite ich auch nochmal. Bin ich eh grad dabei; hab mir letzte Woche im Buchladen "Clean Code" gegönnt:

    "details matter"!


    Grüße,

    Raspbuino

    Hallo zusammen,

    auf die Schnelle erstmal ein Dankeschön für die ersten Antworten.

    Werd ich mir daheim dann genauer ansehen, vor allem den Ansatz mit der Coroutine von noisefloor find ich sehr interessant.

    Im Moment bin ich Brötchenverdienen und da ist leider nix mit Progrämmchen ausprobieren (so gerne ich das jetzt tun würde).


    Tell,

    das mit dem Hin- und Herschieben der Variable war mir schon klar. Ich wollte das halt gerne vermeiden, weil ich nach einer eleganteren Methode Ausschau halten möchte. Gerne will ich auf dem Weg dorthin etwas lernen aber selbst mit der ganzen Literatur, die ich dazu habe (und auch lese...) fehlt mir da scheinbar der richtige Funke, um den Einstieg zu finden. Wenn die bessere Lösung also ein Klasse wäre...wie könnte sowas aussehen?


    Grüße,

    Raspbuino

    Hallo zusammen,

    in einem kleinen Steuerprogramm muss ich mit bestimmter Frequenz (z.B. 10 oder 50Hz) immer wieder Daten senden.

    Das wird in einer Funktion gemacht. Im Grunde krieg ich das hin, indem ich die Zeitdifferenz zwischen time.time() und einem Initialwert (STARTZEIT) prüfe.

    Zur Verdeutlichung hab ich nen kleinen Code unten angefügt, der den Kern meines Anliegens beinhaltet.

    Das Problem ist, dass beim Aufruf der Funktion der Wert von STARTZEIT irgendwoher kommen muss und ich das nur hinbekomme, wenn ich den Wert in einer globalen Variable führe. Zwischen zwei Aufrufen der Funktion muss der Wert halt irgendwo gespeichert bleiben. In sofern funktioniert es nicht, dass der Wert erst in der Funktion jedesmal neu initialisiert wird.

    Meine Frage ist: gibt es einen besseren Weg, dies zu tun? Globale Variablen soll man ja möglichst vermeiden und ich möchte gerne herausfinden, wie das ein Profi machen würde.

    Natürlich kann man den Wert (STARTZEIT) auch immer wieder über lokale Variablen an die Funktion übergeben und den (ggf) neuen Wert über return(STARTZEIT) rausholen. Allerdings sagt mir mein Bauchgefühl, das geht bestimmt eleganter, nur reichen meine Python-Skills (noch) nicht so weit. Über diesen Punkt komme ich im Moment irgendwie nicht hinweg.

    Das mit Objektorientierung hab ich noch nicht so ganz geschnallt aber wenn das der bessere Weg ist, wäre ich für ein paar Hinweise dankbar...

    Ich hoffe, ich konnte mein Problem verständlich beschreiben ::)


    So...wollte den Thread hier noch kurz mit einem kleinen Feedback beenden.
    Zunächst nochmal vielen Dank für die Diskussion und Hilfe!
    Es hat mir geholfen, etwas klarer zu sehen und so wußte ich auch etwas genauer, wonach ich suchen muss.
    Mein Webseiten-Paket bei meinem Hoster erlaubt nur FTP (Netbeat, Level 1).
    Da ich im Grunde auch nur ein paar einfache Daten (ja, langweilig, Wetterdaten etc.) und Diagramme ablegen möchte, sehe ich die Sache mit den unverschlüsselt übertragenen Daten unkritisch. Immerhin weiß ich jetzt, dass mir (ohne ein anderes Paket einzukaufen) nur FTP bleibt. Dafür gehts jetzt auch recht einfach, und zwar mit dem Modul "ftplib"

    Code
    import ftplib


    :thumbs1: