Posts by tdl

Registriere dich jetzt, um exklusive Vorteile zu genießen! Als registriertes Mitglied kannst du Inhalte herunterladen und profitierst von einem werbefreien Forum.
Mach mit und werde Teil unserer Community!

    Ich habe es rausgefunden. Ersteinam musste ich das try: weglassen. Dann klappte es.

    Code
    while True:
    
        uhrzeit = (datetime.now().strftime("%H:%M"))
        uhrzeit = str(uhrzeit)
        if uhrzeit == weckzeit:
            print ("Kikeriki")
            break
        else:
            sleep(1)

    Aber danke trotzdem für den Denkanstoß mit dem String.

    Das time(hour=stunde, minute=minute).strftime("%H:%M:%S") gibt einen String zurück,

    Wenn du dann Int mit string vergleichst wird das nicht funktionieren.

    Danke. Diesen Fehler hatte ich überhaupt nicht auf dem Radar. Habe ich jetzt behoben und erst einmal hiermit getestet:

    Code
    weckzeit = time(hour=stunde, minute=minute).strftime("%H:%M")
    weckzeit = str(weckzeit)
    uhrzeit = datetime.now().strftime("%H:%M")
    uhrzeit = str(uhrzeit)
    print ("Jetzt ist es",uhrzeit,"Uhr.")
    print ("Wecken um", weckzeit,"Uhr.")
    if uhrzeit == weckzeit:
        print ("Urzeit ist gleich Weckzeit")
    else:
        print ("Ungleich")

    das funktioniert auch soweit.

    wenn ich aber im Script jetzt: (ich hab die Sekunden :%S rausgenommen, lässt sich so besser testen.

    ausführe, dann bekomme ich:

    Code
      File "./wecken", line 58
        
        ^
    SyntaxError: unexpected EOF while parsing

    Wobei "line 58" das Ende des Scripts und nur eine leere Zeile ist.

    Ich bin noch am Googeln, aber ich hab noch keine mir verständlich Erklärung gefunden, was diesen Fehler verursacht (Oder ich bin zu doof :baeh2: )

    Den einzigen Unterschied, den ich zu den anderen beiden while Trues sehe ist die exception. Soll ich jetzt eine Exeption für EOF Fehler einfügen? Kann ich mir nicht vorstellen.

    Hallo,

    eigentlich wollte ich ein wenig mit argv rumprobieren. Dazu kam mir die Idee einen Wecker zu programmieren, bei dem die Weckzeit als Arkument beim Aufruf mitgegeben wird. Das hat auch schneller geklappt als ich erwartete.


    Aber leider komme ich mit der anschliessenden Weckfunktion nicht weiter. Egal was ich auch bisher versucht habe ist das Ergebnis, dass er entweder nicht weckt (Printzeile "Kikeriki") oder aber EOF, Syntax oder unexpected unident Fehler ausgibt.

    Erreichen möchte ich, dass in der Schleife die Jetzt-Zeit (uhrzeit) mit der gesetzten Weckzeit (weckzeit) verglichen wird und solange diese nicht übereinstimmt soll er 1 Sekunde warten vor dem erneuten überprüfen. Stimmen beide Werte dann irgendwann überein soll die "Kikeriki" Zeile ausgegeben werden.

    Eigentlich ging ich davon aus, dass das der einfachere Teil wäre, bekomme es aber einfach nicht hin.

    Ich weiß. es gibt bestimmt bessere Arten einen Wecker zu programmieren, aber ich würde gern erst mal das hier zum laufen bekommen.


    Hier der Code, es geht nur um den unteren Teil ab # Zeit prüfen und wecken. Aufgerufen wird mit ./wecken 20 15 für 20:15 Uhr Weckzeit.

    Wenn du wissen willst, was beim Importieren von gpiozero abläuft -> Quellcode lesen. Oder einen Profiler laufen lassen:



    Python >>> import cProfile >>> cProfile.run('import gpiozero')

    Das gibt bei mir eine Fehlermeldung:

    Code
    Traceback (most recent call last):
      File "./profile.py", line 5, in <module>
        import cProfile
      File "/usr/lib/python3.7/cProfile.py", line 10, in <module>
        import profile as _pyprofile
      File "/home/pi/Motor/profile.py", line 6, in <module>
        cProfile.run("import gpiozero")
    AttributeError: module 'cProfile' has no attribute 'run'

    Was macht denn dieses cProfile?



    Da haben sich unsere Antworten überschnitten.

    Dass du ihn nicht mehr ausschalten kannst, ist schon mehr als komisch.


    Jedenfalls nutzt dein gpiozero aktuell RPi.GPIO als Backend. Ich hatte vermutet, dass gpiozero ein andere kaputtes Backend verwendet.

    Ist aber nicht der Fall.

    Hab den Code mit anderen Pins an einer LED probiert, die geht an und aus.

    Jetzt noch mal die Motorpins auf die von der LED gesteckt, den gleichen Code gestartet, Motor geht an und nicht mehr aus.

    Mach mal ein:



    Code print(motor.forward_device.pin_factory)

    <gpiozero.pins.rpigpio.RPiGPIOFactory object at 0xb6418ef0>


    Dein Beispielcode lässt den Motor zwar laufen aber leider nicht mehr ausgehen. Warum auch immer. Das motor_a.off() greift nicht.



    Ist es überhaupt sinnvoll auf Python zu setzen, wenn es nur um die Geschwindigkeit geht ?

    Da sollte irgendwas mit C doch schneller sein.

    Es geht mir nicht mal um die Geschwindigkeit an sich, eine Sekunde, damit kann ich bei der Anwendung schon noch leben, es irritiert mich lediglich, dass wenn ich einen Schalter umlege und dann erst eine ganze Maschinerie anläuft nur um ein simples "an" zu schalten.

    ch hatte schon verstanden was Du meinst und kenne diesen Effekt. (Siehe zweiten Satz in meinem Zitat oben! ;) )

    Wenn das Skript aber erstmal läuft und ein Motor oder eine LED z.B. per Taster o.ä. gesteuert werden soll, dann gibt es keine Verzögerungen.

    Sorry, ich hatte meine Antwort auf das SSH bezogen.

    Aber jetzt verstehe ich was du mit diesem Satz gemeint hattest. Genau diese Initialisierung, kann man die beschleunigen?


    Bei mir macht das keinen so großen Unterschied, aber auf meinem Test-Zero ist nur ein Raspberry Pi OS Lite und faulenzt vor sich hin.

    Bei mir ist auch nicht mehr drauf.


    Bei einer früheren Version von gpiozero gab es ja wohl schon mal so ein Problem (Link nach draußen), dass dann mit einem Upgrade behoben wurde. Ich hatte die Frage hier gestellt, in der Hoffnung, dass es ich bei meiner Verzögerung wieder um so etwas handelt und behoben werden kann.

    Das Schalten per SSH-Button ist ja, wenn ich das richtig in Erinnerung habe, eh eher selten und da würde mich persönlich eine Verzögerung nicht stören. Darum geht es Dir aber oder?

    Hi Hyle, nein, darum geht es nicht. Deshalb habe ich auch diese beiden einfachen Scripte oben erstellt, dass da keine anderen Faktoren mit reinspielen wie von dir angesprochen. Nur Motor an Motor aus Script Ende.

    Ich starte beide in der Konsole mit ./name.py und dann geht beim ersten Script der Motor direkt los, und beim zweiten dauert es etwas.

    Hängt jetzt auch nicht am Motor, den gleichen Effekt stelle ich fest wenn ich eine LED an und ausschalte. Mit gpiozero dauert es einen Moment bis die LED leuchtet. Wenn ich das über RPi.GPIO mache reagiert die LED sofort. Probier es mal selber aus. Achja, ich mache das ganze auf einem Pi Zero, ist der vielleicht zu schwach für gpiozero?

    Hallo,

    vor einiger Zeit hatte ich mit meiner Schloss-Steuerung von RPi.GPIO nach gpiozero gewechselt. (Link zum Thema)

    Warum? Naja, weil einem jeder erzählt RPi.GPIO ist veraltet, das neue gpiozero ist besser, schöner, einfacher...


    Seit diesem Wechsel reagiert meine Steuerung erst nach einer Verzögerung von fast 1 Sekunde.


    Ich hab das mal mit 2 einfachen Scripten nachgestellt und meine Vermutung, dass das tatsächlich an gpiozero liegt, hat sich bestätigt.

    Bei diesem Script startet der Motor quasi sofort:

    Und bei diesem erst mit ca. einer halben Sekunde Verzögerung :sleepy: :


    In einem anderen Beitrag las ich, dass gpiozero sowieso auf RPi.GPIO aufsetzt, dann kann letzteres ja eigentlich auch nicht veraltet sein (Beitrag #7). Denke mal das ist auch der Grund für die Verzögerung.

    Meine Frage: Kann man diese Verzögerung irgendwie wegbekommen/verkürzen oder hilft da nur wieder RPi.GPIO direkt zu verwenden?

    Was genau meinst Du mit, "die stammen aber alle vom gleichen Image"? Hast Du den Inhalt der SD-Karte kopiert/dupliziert und nicht geflasht?

    Ich versuch es mal zu erklären.

    Ich habe 2 Pi Zeros. Der eine hängt an meiner Tür und dreht am Rad Schlüssel und der andere ist mein "Test"-Pi.

    Die "Schliess-Anlage" habe ich schon länger, die hat vorher der 3. Pi über 2 lange Lankabel bis an die Tür mitbedient. Hat dieses Jahr einen Kabelbruch gegeben, da beschloss ich die Tür Geschichte separat mit eine Zero zu machen.

    Der Tür-Pi ist also recht frisch im Einsatz, da hatte ich beim Installieren und konfigurieren der nötigen Software so einige Probleme. Deshalb hatte ich mir noch einen 2. Pi, den Test-Pi, besorgt, den hab ich hier mit gleicher Schaltung direkt am Arbeitsplatz aufgebaut.


    Als der Tür-Pi halbwegs stabil lief hatte ich diese Karte mit dd gesichert. und für den Test Pi auf eine andere Karte aufgespielt und den Hostnamen geändert. (Deswegen dieses DOOP1 und DOOP2)

    Wenn ich nun auf dem Test Pi etwas erfolgreich geändert/verbessert/neu gemacht hatte, hab ich dieses Image wiederum gesichert und auf den Tür-pi zurückgespielt. Und dann dort den Hostnamen wieder zurück geändert.

    Schätze mal, dass da mi der Zeit so einiges durcheinander gekommen ist. Putty hat mir zwar auch immer wieder mal eine Meldung gebracht, wenn ich bei einem neuen Image mit den gleichen Zugangsdaten reinwollte, da hab ich mir aber nichts bei gedacht. Erst als du mir gezeigt hattest, dass ich mich auch einfach über die Konsole des PCs verbinden kann hab ich ja mal mitbekommen was da alles ausgetauscht wird.


    Fazit: Da werde ich wohl meine chaotische Arbeitsweise doch etwas ändern müssen. Hatte mir nichts dabei gedacht. :daumendreh2:


    Zu deiner zweiten Frage: sichern mit dd, dann pishrink und Wiederaufspielen mit "Bootfahiges USB Medium erstellen" . Wenigstens da habe ich, glaube ich, alles richtig gemacht :) .


    So long


    Thorsten

    Du hast aber keine identische Hostnamen auf deinen PIs gehabt-

    Nicht direkt, die stammen aber alle vom gleichen Image, da ist immer der gleiche Hostname drauf, den ich jedesmal nach dem Erststart abändere, und dann hatte ich auch mal die beiden Karten getauscht gehabt. Während ich am 3 Pi (Hostname Raspberrypi) nichts gemacht hatte. Und der ja auch dieses Problem nicht hatte.

    Du benutzt den Inline-Code anstelle von Code.

    Ich wollte den Inlinecode verwenden, aber nur für die eine Zeile und dann hat er im Editor egal was ich machte das Codefenster aufgemacht. und in der Vorschau stand dann der komplette Text mit drin obwohl der /tt Tag weiter oben gesetzt war... Sehr merkwürdig alles. :shy:



    history | grep ssh-keygen

    Da müsste dann im Ergebnis etwa Folgendes kommen:
    Code sudo ssh-keygen -f "/home/kubunt/.ssh/known_hosts" -R "meinraspberrypi.lan"

    Jepp genau das kam. Habs eben auf dem anderen Pi gemacht. Neuer Key wurde bei der Anmeldung gesetzt und...


    Aaah! Das scheint also tatsächlich daran gelegen zu haben.


    Hängt das jetzt tatsächlich mit den gleichen Hostnamen zusammen? Dann gewöhne ich mir das ab.


    rpi444 und Tigerbeere : Danke für eure Hilfe! Besonders natürlich dir rpi444, du hast dich da ja richtig rein gekniet.


    :danke_ATDE:

    He he he, ich muss mich noch mal zu Wort melden. Da war ich mit meinem letzten Post zu voreilig.

    Ich habe auf beiden Karten den gleichen Hostnamen vergeben. Nachdem ich jetzt nochmal die alte Karte einlegte und über die Linuxkonsole (nicht über Putty) eine Verbindung herstellen wollte, bekam ich eine Meldung, dass für diesen Host bereits ein Schlüssel vergeben sei den ich erst löschen solle, was ich dann auch tat.

    Danach wurde wohl ein neuer Schlüssel erstellt und jetzt schläft das System auf der alten Karte auf einmal nicht mehr ein.

    Kann so etwas tatsächlich die Ursache gewesen sein?

    Hab grad bei der Google Suche die Meldung entdeckt, an die ich mich erinnere:

    Allerdings stand bei mir dann noch eine Zeile wie ich den Key lösche


    Falls das wirklich die Lösung ist würde ich das gerne bei meinem "Tür-Pi" auch machen. Leider habe ich mir die Zeile jetzt nicht gemerkt, mit der ich diesen Key gelöscht hatte. Im Netz habe ich diese gefunden:

    ssh-keygen -R hostname [-f known_hosts_file]leider funktioniert diese Zeile weder wenn ich "hostname" mit dem entsprechenden Hostnamen noch mit der IP ersetze. Und irgendetwas scheint grad auch mit der Forensoftware nicht zu stimmen, im Editor sieht das noch richtig aus

    Hallo,

    neue SD Karten sind angekommen. SanDisk Class10.

    Gleich mal ausprobiert. Image drauf, gleiches Spiel.

    Gut, dann holen wir uns doch mal die neueste Download Version Pi OS lite. Runtergeladen, headless Dateien hinzugefügt (ssh, Wlan), gestartet und

    .

    .

    .

    Gleiches Spiel :conf:


    update und upgrade gemacht, keine Änderung :wallbash:


    Sollte es tatsächlich an der Hardware liegen? Aber wieso funktioniert das wenn in einer 2. Verbindung htop oder watch -n1 iwconfig z. B. läuft? Das wiederum kann doch nichts mit Hardware zu tun haben.


    Ist das einfach ein Übel mit dem ich leben muss? Ich meine außer auf die ssh Verbindung scheint sich das ja auf nichts auszuwirken. Die Programme laufen ja stabil und reagieren auch direkt.

    Was passiert beim sichern der SD-Karte? Wie hast Du diese Sicherung gemacht?

    Pi runterfahren, Karte entfernen und auf dem PC mit dd das Image runtergezogen. Anschließend mit pishrink verkleinert.

    Aufspielen einer Imagedatei auf die SD Karte mach ich mit der USB-Abbildherstellung die ich im Kontextmenü von Nemo bei Rechtsklick auf das Image vorgeschlagen bekomme.


    Das deinstallieren von Avahi und Trigger-happy hat leider auch keine Veränderung gebracht.