Posts by meigrafd

    In dem Artikel wird aber ganz klar gesagt dass es nicht um Spionieren oder Versenden der Dokumente/Daten geht, sondern nur darüber nichts von diesem Feature gewusst zu haben.


    Eine Sicherheitsexpertin hat es untersucht und beschwert sich nur darüber dass Google die User über diese Funktion nicht informiert hat. Sie findet aber keine Sicherheitsverstoss.

    /var/ ist 2,6GB groß... das ist etwas zu viel :shy:


    Was genau verstehst du unter "Datenloger" ?

    Und was für ein Webserver läuft bzw was läuft darüber?

    Was ist an den Pi angeschlossen? Bitte ALLES nennen.

    Welches OS benutzt du?


    Poste mal bitte noch die Ausgabe von: du -sh /var/log/*

    Wenn auf dem Pi wirklich nichts anderes läuft würde ich einfach mal die Logdateien vom Webserver überprüfen - evtl. hast du fehlerhaften Code.


    => /var/log/apache2/


    Wenn sich da nichts auffälliges finden lässt könntest du als nächstes prüfen welches Wurzelverzeichnis auf der SD Karte am meisten Platz verballert:


    => du -sh /*

    (ausgabe bitte in CODE posten)

    Entschuldigung für meine Vorgehensweise aber letztlich habe ich das erreicht was ich wollte. Es hilft mir nicht weiter wenn ihr schreibt "das macht man nicht" "das geht so nicht" ohne mir Gründe zu nennen oder Alternativen genauer zu erklären. Ich bin leider nicht so erfahren im Programmieren..

    Wir haben Dich mehrmals nach genaueren Details gefragt um die Sache gemeinsam mit dir erarbeiten zu können, aber darauf hast Du bis heute nicht reagiert - also was erwartest du bitte? Dass wir das unaufgefordert dir auf einem Silbertablett vor die Füße legen?


    So wie Du uns hier systematisch ignoriert hast müssten wir Dich jetzt eigentlich auch ignorieren .. Allerdings laufen wir dann Gefahr dass du dein gefährliches Halbwissen auch noch anderen fragenden/hilfesuchenden mitteilst...


    Ok danke, hast du mir vielleicht einen Link zum einlesen ich tu mir schwer etwas brauchbares zu finden.. : )

    FAQ => Nützliche Links / Linksammlung => Befehle / andere Scripts ausführen => python #1

    Du brauchst ja eigentlich nur etwas das auf die Betätigung des Gebers reagiert.

    Also etwas das entweder ständig die Position prüft und mit dem vorherigen Zustand vergleicht, oder etwas das bei Veränderung etwas selbst auslöst. Und dann in deinem Script für Tkinter eine entsprechende Aktion durchführt. Letzteres unterscheidet sich nicht wirklich gegenüber einer "Tkinter mit GPIO bedienen" Anforderung und dieser Part scheint dir ja unklar zu sein?


    Soweit mir bekannt ist gibt es nur 2 Möglichkeiten ein betätigen einer 'button'-Schaltfläche zu simulieren - wo man nicht über den Touchscreen die Schaltfläche des Buttons drückt:

    1. Dem Button-Objekt zugewiesenen 'command' Callback direkt ausführen.

    2. Dem Button-Objekt zugewiesenen 'command' Callback mithilfe button.invoke() ausführen lassen.


    Nachteil ist bei 2. aber glaub ich das man optisch nicht sieht wie die Schaltfläche des Buttons gedrückt wird. Bei 1. sowieso nicht.

    Du willst also keine Lösung die FTP, HTTP oder SAMBA verwendet, aber trotzdem für die Nutzer einfach zu bedienen ist? Da bleibt dann leider quasi nichts mehr über :X

    Mit sudo meldet man sich nicht an ;) sudo ist ein Tool/Programm, kein Benutzer.


    In /etc/ liegen Systemkonfigurationsdateien. Da darf normalerweise nur der Administrator schreiben - root.

    Scripte haben in /etc/ nichts verloren. Jedes System-Verzeichnis hat seinen Sinn und Zweck. Wenn eine Anleitung sagt man solle ein Script in /etc/ ablegen ist die Anleitung für die Tonne. Klingt böse, ist aber einfach so.


    Schon die "Vorbereitung" der Anleitung sorgt bei mir dafür dass sich meine Nackenhaare aufrichten :stumm:

    Oder das dreckige Anpassen der Berechtigungen in /dev/ sind beim nächsten Reboot wieder weg, um dem Entgegen zu wirken wird via sudo crontab -e geöffnet und dort ein Befehl wieder mit sudo eingetragen... Doppelt hält besser? also taugt die Anleitung wirklich nichts.


    Entweder man legt so ein Script im Homedir des auszuführenden Benutzers ab, oder bei individuell hinzugefügten Scripts beispielsweise in /usr/local/bin/ oder /usr/bin/ damit wäre es zudem auch noch in einem PATH Verzeichnis.


    Man darf auch nicht außer Acht lassen das die Anleitung beschreiben dass ein anderes Image installiert werden soll: openhabian. Ob dieses Image zum einen dem aktuellen entspricht (was nicht der Fall ist) und zum anderen fehlerfrei ist, weiß vermutlich niemand.

    Wenn Du also seltsame Probleme hast dann versuch herauszufinden ob du diese auch mit dem offiziellen Raspbian Image hast.



    Als kleiner Tipp bzgl. deines Copy&Paste Problems:

    Nimm einfach als Zwischenschritt deinen PC. Kopiere den Code/Text von einer Webseite, füge ihn in eine temporäre Textdatei auf deinem PC ein. Dann kopierst du den Text aus eben dieser Textdatei auf deinem PC und fügst ihn dann erst in nano auf dem Pi ein. Damit verifizierst du dass der Text korrekt ins Clipboard aufgenommen wurde, was nämlich leider manchmal auch schon hierbei schiefgehen kann, weil die Webseite komische CODE-Blöcke nutzt o.ä.


    In jedem Fall empfielt es sich einen Linux Kompatiblen Editor zu verwenden.

    Irgendwer hat noch nie eine abgenutzte SD gesehen, irgendwer hatte auch noch nie eine kaputte Magnetscheibe... Aber trotzdem kann es solch Kuriosum geben.

    Ich führe dabei auch gerne immer wieder als Beispiel meinen seit ~2012 bei EDIS.at stehenden http://RaspberryPi.roxxs.org auf, in dem seither eine SD steckt und immer noch funktioniert. Aber wieso ist Alex_rpi seine SD gestorben? Wissen wir nicht



    Alex_rpi Wo steht das deine SSD SLC hätte?


    Die SDSSDA-120G-G25 verwendet MLC

    Die SDSSDA-120G-G27 verwendet TLC

    ...was ich auf die Schnelle herausfinden konnte...


    Wieso, Weshalb, Warum SLC, MLC, TLC kannst du zum Beispiel hier nachlesen: https://www.hardwareluxx.de/in…ien-bei-ssds.html?start=3

    die SSD sollte neu sein

    Bist du dir da wirklich absolut sicher?

    Es ist eher ungewöhnlich das ein Hersteller heutzutage noch eine so kleine SSD herstellt. Mag ja sein das Du sie erst kürzlich neu gekauft hast, bedeutet aber deshalb nicht das die SSD erst kürzlich vom Fließband kam.

    Ich hoffe, dass eine SSD viel mehr Schreib Zyklen aushält, als es eine SD Karte schafft und so die nächsten Jahre übersteht. Dazu kommt auch, dass die SSD viel schneller und größer ist als eine SD-Karte

    Nein, das ist ein Trugschluss.


    Die SSD ist vielleicht an einem SATA-Port schneller als eine SD, der limitierende Faktor ist hier aber die USB 2.0 Schnittstelle, die beim Pi noch dazu mit den anderen drei USB-Ports und der Netzwerkschnittstelle aufgeteilt wird... Bedeutet: Ist noch ein USB-Device angeschlossen, oder LAN wird beansprucht, bremst das die an USB angeschlossene SSD aus. Die SD hat aber einen eigenen und unabhängigen Bus, kann also nicht derart beeinträchtigt werden.

    Wenn du Glück hast und die SSD alleine an USB hängt und LAN auch nicht beansprucht wird, kann die SSD um 5mb/s schneller als deine SD sein... Es sei denn deine SD ist von der lahmen Sorte :X


    Dass eine SSD mehr Schreibzyklen verkraftet stimmt derart pauschal auch nicht. Es kann sogar sein das eine SD mehr verkraftet... Das kommt nämlich auf die technischen Details bzw Speichertechnologie an: SLC, MLC, TLC. Wenn deine SD-Karte SLC Bausteine verwendet, die SSD aber TLC, dann würde die SD länger überleben. Mal ganz davon abgesehen dass bei TLC die Performance im Vergleich zu MLC oder gar SLC sinkt, da der Controller mehr Zustände unterscheiden können muss.


    In einer SD-Karte ist ebenso wie bei einer SSD ein Controller verbaut, der einen Algorithmus für Schreibvorgänge etc enthält. Sicherlich gibt es von Hersteller zu Hersteller minimale Unterschiede, viele greifen aber auf Controller anderer Firmen zurück und stellen die Controller gar nicht selber her.

    Entscheidender wäre hier wie alt der jeweilige Controller wäre, da man hiervon ableiten könnte wie effizient und zuverlässig der arbeitet - daher auch die Eingangsfrage nach dem Alter der SSD: Um so älter das Device um so älter auch der Controller bzw dessen Firmware...


    Die Größe des Datenträgers spielt nur eine untergeordnete Rolle. Natürlich ist eine volle SD oder SSD nicht gut für die Lebensdauer. Natürlich hat ein großer Datenträger mehr Speicherzellen die abgenutzt werden können. Aber deshalb brauch man der Abnutzung der Speicherzellen nicht weniger Beachtung schenken... Denn letztlich kann das auch zu Datenverlust führen wenn der Controller ein Speicherzellen-Problem nicht rechtzeitig erkennt.



    Wenn also deine SD wirklich aufgrund von zu hohe Schreibbelastung den Dienst quittierte, wird es der SSD vermutlich nicht anders ergehen - das ist wirklich so. Dem kann man nur mit besonderen Maßnahmen entgegenwirken - egal ob SD oder SSD.


    Mein Sata zu usb Adapter hat eine Eigene Stromversorgung

    Wie genau sieht die aus? Eigenes Netzteil, oder über USB?


    Einfacher wärs wenn du einfach mal nen Link zu den Komponenten nennen würdest

    Ist die SSD schon etwas älter? Also nicht im Sinne von in deinem Besitz, sondern wann diese hergestellt wurde.


    Möglicherweise benötigt die SSD mehr Strom als der USB2.0 Port standardmäßig liefert. Der SATA-Adapter möchte auch versorgt sein damit er sein Dienst verrichtet. Schon mal mit einem aktiven USB-Hub probiert oder max_usb_current=1 in /boot/config.txt eingetragen?



    Übrigens: Wenn deine SD eine zu hohe Schreibbelastung hatte wirst du mit der SSD keinen Vorteil erhalten - beides basiert auf abnutzbaren NAND-Flash.

    Hatte ich gemacht, dann kam aber ein andere Fehler. Ich will dich auch nicht den ganzen Tag nerven, ist schließlich Ostern.

    Hier sind auch noch andere - also alles gut ;)


    Ich hab den Code nicht ausprobiert, stammt aus einem python3 Script, könnte sein das es damit zu tun hat - notfalls nimmst du erst mal die betroffenen Zeilen raus solange bis es geht ;)

    Zum testen am besten nicht in IDLE ausführen sondern schon über die Konsole - der Autostart nutzt ja auch nicht IDLE, zumal die IDLE-Umgebung etwas anders ist als über Konsole.


    Stell auch sicher das sonst kein anderes Script auf die RaspiCam zugreift.. Evtl. läuft auch noch das via Autostart ausgeführte Script im Hintergrund?


    Wichtig ist dass solche Ressourcen, die geöffnet wurden, auch nach Benutzung wieder geschlossen werden, sonst kriegst du irgendwann Probleme... In deinem Script aus Beitrag#1 hast du zB image_path zwar geöffnet aber nie geschlossen. Das try: Konstrukt hast du da auch etwas unpassend verwendet wodurch ggf cam nie geschlossen wurde sobald das Script beendet wurde. with kümmert sich eigenständig ums schließen. Mein Script ist auch noch nicht perfekt, wollte nur nicht zu viel auf ein mal ändern...

    Ggf. musst du jetzt ein mal rebooten damit der Out of resources Fehler verschwindet - durch das ganze rumprobieren zu viele noch offene handler.

    Wenn ich das Programm mit dem Befehl:


    python /home/pi/LS_s.py &


    in der rc.locale starte, dann funktioniert der Autostart:

    Und was spricht dagegen diese Variante zu verwenden?

    Das Programm empfängt zwar über UDP die Daten vom anderen Raspberry und sendet per Telegramm auch ein Bild, es ist aber ein alter Bild, es wird kein Neues aufgenommen.

    Dann schreib das Script mal passender:

    ..dann wäre es auch sinnvoll tmpfs für /tmp/ zu aktivieren - um die unnötigen Schreibvorgänge auf der SD zu vermeiden, sonst lebt die SD nicht lange..

    Schon mal versucht anstatt env direkt den Pfad zum Interpreter zu setzen?

    Code
    1. #!/usr/bin/python
    2. import telepot
    3. import picamera
    4. import socket
    5. # ....

    Ansonsten - wie schon gesagt - nicht mit Shebang arbeiten sondern die Datei beim ausführen dem Interpreter übergeben:

    Code
    1. python /home/pi/LS_s.py

    Dann spielt der Shebang nämlich keine Rolle.



    ..ich wiederhole mich ungerne..

    Das Betriebssystem ist auf allen Pi's identisch, einzig Kernel & Firmware können sich unterscheiden, haben aber auf diese Art von Autostart keinen Einfluss. Es gibt btw mehrere Autostart-Möglichkeiten.


    Ich würde die Ursache des Problems wie gesagt eher im Detail suchen:

    • /etc/rc.local muss Ausführrechte besitzen, sonst kann die Datei bei Systemstart nicht ausgeführt werden.
      • /etc/rc.local sollte man tunlichst nicht überschreiben, sondern wenn dann nur bearbeiten. Dann bleiben auch Ausführrechte etc erhalten.
    • Der Server muss selbstverständlich zu einem früheren Zeitpunkt erreichbar sein als der Client versucht eine Verbindung herzustellen.
      • Spielt Socket keine Rolle bedarf es auch keiner Verzögerung/Blockade ala sleep
    • Die Python-Script-Datei muss im Linux-Kompatiblen Format vorliegen.
      • Dazu gehört auch der Zeilenumbruch. Ggf. Übertragung von PC auf Pi kontrollieren. Wurde /etc/rc.local überschrieben ebenfalls diese Script-Datei kontrollieren.
    • Entweder die Python-Script-Datei direkt dem Interpreter zum verarbeiten übergeben, oder mit Ausführrechten und Shebang arbeiten.
      • Wird die Datei direkt dem Interpreten übergeben wird ein Shebang ignoriert: python /home/pi/LS_s.py
      • Unter Umständen befindet sich der im Shebang befindliche Befehl nicht im PATH - dort wo Linux nach den Befehlen sucht, zB ist ls auch nur ein Binary welches ausgeführt wird... Durch Angabe des absoluten Pfades umgeht man ggf PATH Probleme.