Posts by ghmartin77

    Ein ganz hervorragender Eintrag zur Historie und Interpretation des Load-Wertes:

    https://www.brendangregg.com/b…/linux-load-averages.html


    Und hier eine Betrachtung "seltsamer" Load-Peaks, die sich aus den mathematischen Berechnungsformeln ergeben:

    https://blog.avast.com/investi…ed-machines-every-7-hours


    Büssel was zu lesen, noch härter zu verdauen, aber ausgesprochen aufschlußreich :) Vielleicht auch Erklärungen für dein Phänomen in den beiden Artikeln?


    Grüße

    ghmartin77

    Zu (1) ist relativ wenig bekannt, nur:

    Es ist ein Pi4 mit 8 GB + Raspi-OS

    - offen: 32/64 Bit, light/full

    Aus den Logs des Raspi-Backup-Versuchs:


    Zur "Platte voll"-Theorie ebenfalls aus besagtem Log (gut, heißt nicht, dass das bei allen Versuchen so aussah):


    @DJ1NG:

    Du hattest bei einem deiner Versuche auch von einem Kernel Panic geschrieben. Gibt's dazu Details?

    Interessantes Rätsel... :)

    Hast du während des Backup-Laufs mal mit (h)top oder ähnlichem geguckt, wer sich da so viel Speicher einverleibt?

    <Wildes Raten>Hattest du irgendwann zwischen "Lief mal" und "Ist kaputt" Swapping deaktiviert?</Wildes Raten>

    Ergänzend dazu ist hier bisher auch unklar, ob dieser Befehl mit dem selben Ziellaufwerk schon einmal funktionierte oder ob es sich um eine andere SSD / HDD handelte.

    Beitrag #1:

    Aber ich habe mit den genauso kopiert damals, gerade WEIL er funktioniert hatte - auf die gleiche SSD am gleichen RPI.

    Code
    [ 1023.303991] Out of memory: Killed process 1257 (dd) total-vm:10940kB, anon-rss:4188kB, file-rss:508kB, shmem-rss:0kB, UID:0 pgtables:44kB oom_score_adj:0

    Würde tippen, dass sich die Lösung deines Problems hinter der Meldung oben verbirgt. Irgendein Prozess auf deiner Kiste frisst allen Speicher (vermutlich dd selbst), dann greift der Linux Process Reaper und schmeißt Prozesse raus.

    Details zum Mechanismus hier (hilft evtl. bei der Analyse): https://www.oracle.com/de/tech…cture/dev-oom-killer.html

    Passend zu "dd" hat mir Google noch das hier ausgespuckt: https://serverfault.com/questi…using-all-memory-and-swap

    Der Hinweis zur Direct-IO-Nutzung könnte zielführend sein: man dd | less +/direct


    Tipp am Rande: Such mal mit der Suchmaschine deines Vertrauens nach "linux screen", damit dir sterbende putty-Verbindungen nicht immer die Suppe versalzen...


    Good luck!

    Warum sollte man das wollen? Der Raspi hat doch genug Leistung, um selber MP3s abzuspielen. Der Klinkenausgang ist zwar Grütze, aber vermutlich auch nicht schlechter, als der Ausgang des DF-Players.

    Wenn du's partout machen willst: Der DF-Player redet über eine UART-Schnittstelle (TX/RX) mit seiner Umwelt.

    CPP-Library (für Mikrocontroller) zum Abgucken hier:

    https://github.com/Makuna/DFMiniMp3

    Protokoll-Beschreibung (furchtbare Qualität) hier: http://files.amperka.ru/datasheets/DFPlayer_Mini.pdf


    Warnung "DF-Player ist nicht DF-Player und unterschiedliche Modelle verhalten sich unterschiedlich" hier:

    https://github.com/ghmartin77/DFPlayerAnalyzer


    Empfehlung, wenn dir die Klinke am Pi qualitativ zu schlecht ist (oder du einen Zero einsetzt): PCM5102.


    Grüße

    ghmartin77

    Bist ein bissel sparsam mit deinen Informationen über die eingesetzte Hard- und Software. Schlagworte Tuya, Smart Life App und Home Assistant könnten aber diesen Weg ermöglichen:

    1) Tuya Firmware durch Tasmota ersetzen

    2) Tasmota bspw. über MQTT in Home Assistant integrieren.


    Anleitungen und Software hier:

    https://www.heise.de/ct/artike…ang-befreien-4283623.html

    https://github.com/ct-Open-Source/tuya-convert


    Anleitung zu Tasmota:

    https://tasmota.github.io/docs/


    Good luck

    ghmartin77

    Nachteil schon gefunden. Wenn das ausgeführt wird, wird erst mal die Datei geleert, bis der Topic ankommt.

    Das ist kein Nachteil, sondern schlicht Linux. Wenn du STDOUT mit > umleitest, wird eine evtl. existierende Datei geleert. Wenn du das nicht möchtest, musst du >> nehmen. Dann hast du aber wieder das "Problem" von oben.

    Noch spannender wird's, wenn keine neue Nachricht binnen einer Minute eingeht... :)


    Kommen wir vielleicht nochmal auf framps Frage oben zurück: Was genau möchtest du eigentlich erreichen?

    Dann können wir auch passende(re) Antworten geben. Vielleicht ist MQTT gar nicht die Lösung zu Deinem Problem?!

    Die Option -C ist doof, weil dann beendet er sich gleich wieder, ohne überhaupt etwas zu empfangen.

    Du musst die man page auch komplett lesen:

    Code
    -C
    Disconnect and exit the program immediately after the given count of messages have been received. This may be useful in
    shell scripts where on a single status value is required, for example.
    
    
    **** Combine with -R to print only the first set of fresh messages **** (i.e. that does not have the retained flag set), or with
    -T to filter which topics are processed.

    Abgesehen davon glaube ich mittlerweile: "You're holding it wrong" :)


    Spaß beiseite: MQTT ist in erster Linie keine Datenbank, die Werte hält, sondern ein Netzwerkprotokoll. Der einzige, der einen Status ähnlich einer Datenbank hält, ist der Broker/Server (hier aber auch maximal die letzte (retained) Message pro Topic. mosquitto_sub ist ein Client, der sich auf ausgewählte Topics registriert und dann die Werte des Brokers/Servers erhält, sobald diese ein Update erfahren. Einen alten Status (alt im Sinne von "Wert wurde übermittelt bevor der mosquitto_sub-Client sich verbunden hat") bekommst du nur für Nachrichten, die als "retain" übermittelt wurden.

    Wenn du die Daten dauerhaft speichern möchtest, ist's sinnvoll(er) sie bspw. in eine influxdb zu pumpen und dann ggfs. mit Grafana zu visualisieren.

    Dafür tut sich jetzt das nächste Problem auf, ich empfange die Nachricht und speichere sie so in eine Datei:

    mosquitto_sub -t topic -u benutzer -P geheim > /pfad/zur/nachricht.txt &

    Jetzt wird die letzte Nachricht aber nicht überschrieben, sondern in eine neue Zeile angehängt:


    Das Kommando macht nicht, was du dir vorstellst. mosquitto_sub, in der Art aufgerufen, empfängt einfach endlos eingehende Nachrichten und schreibt alles Empfangene auf STDOUT. Letzteres hast du mit > in eine Datei umgeleitet. Gehen 3 Nachrichten ein, stehen in der Datei halt genau diese 3 Nachrichten.


    <Wild_geraten>

    Was du möchtest ist vermutlich ein Aufruf von mosquitto_sub mit dem Parameter "-C". Schau dir dazu mal den entsprechenden Abschnitt unter "man mosquitto_sub" an.

    </Wild_geraten>

    Was mich zu meiner Anfangsfrage zurückführt , was auf dem ersten Bild zu sehen ist

    Ein IR-Abstandssensor. Über's Poti stellst du die Empfindlichkeit ein, zu der der OUT-Pin von High auf Low (oder umgekehrt geht). D1 ist vermutlich eine Diode, die leuchtet, sobald die Entfernungsschwelle unterschritten wird (optische Anzeige des OUT-Pins).


    Damit kannst du keine IR-Signale einer Fernbedienung auswerten.

    und wollte mir jetzt ein vernünftiges Dashboard auf einem Display basteln, wo ich sehe ob die Raspberrys überhaupt noch online sind, welche Temperatur u.s.w.

    Wenn's dir nicht darum geht, zu forschen und zu lernen, schlage ich das hier in fertig vor:

    Grafana + Telegraf + Template

    https://canox.net/2018/01/inst…f-auf-einem-raspberry-pi/

    https://grafana.com/grafana/dashboards/5955


    Zu deinem konkreten Interpretationspunkt der Ausgabe von "free" im jeweiligen System: Versuch mal jeweils "man free", vielleicht ergibt sich beim Lesen, wie die jeweilige Rechnungslogik ist.


    Grüße

    ghmartin77

    Ich möchte von euch keine fertigen Programme, da ich über probieren und studieren arbeiten wollen würde.

    OpenCV ist dein Freund: https://opencv.org/

    Entweder kriegst du deine Pfeilpositionen durch Differenzbildung vom Bild der leeren Dartscheibe mit dem Bild der beworfenen Dartscheibe raus oder du mixt noch AI mit rein. Ideen dazu hier:

    External Content www.youtube.com
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.
    (und in weiteren Videos des gleichen Kanals)

    Physik kaputt... Wenn du Signale um 20:20:27 schickst und die Ergebnisse um 20:22:19 empfangen werden, dann stimmt da was nicht :)


    Spaß beiseite: Wenn deine Verkabelung ok ist, ist vermutlich das Empfangsmodul Schrott. Der Typ definitiv. Ob dieses eine tatsächlich hinüber ist, lässt sich aus der Entfernung schwer sagen. Such mal nach superheterodynen Receivern. Habe mit RXB6 ganz gute Erfahrungen gemacht.

    Die Dinger, die du da hast, werden meist im Paar verkauft: Der Sender ist g'scheit genug, aber die Empfangsmodule kann man meist direkt in die Tonne hauen.


    Grüße

    ghmartin77

    Hm... bissel Google-Suche brachte das hier:

    https://www.az-delivery.de/blo…ni-uber-esp-now-verbinden

    + Gateway: https://gitlab.com/diy_bloke/e…SPNOW-receive-to-MQTT.ino

    Und ein Erklärbärvideo vom guten Andreas:

    External Content www.youtube.com
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.
    (inkl. Energieverbrauchsmessungen)

    Ohne Garantie, da nicht probiert, sondern nur Code überflogen: Der Code von readCard (https://github.com/xfjx/TonUINO/blob/DEV/Tonuino.ino#L1617) und writeCard sieht mir so aus, als würden auf den RFID-Karten/-Chips selbst Kommandos/Folder gespeichert, die dann ausgeführt bzw. abgespielt werden.

    Wenn also die SD-Karten der einzelnen Tonuinos den gleichen Content haben, sollten die RFID-Karten/-Chips übergreifend und gleichwertig mit mehreren Geräten genutzt werden können.