Beiträge von RTFM
-
-
-
Wenn ein Datentransfer beginnt, sendet der Bus-Master ein Reset Puls, worauf jeder Slave einen Presence Puls sendet. Daraufhin fordert der Bus Master den ROM Code (64 Bit ID) der Slaves an. Jeder Slave antwortet daraufhin mit seiner ROM-ID samt angehängter CRC Prüfsumme. [siehe DS18B20 Datenblatt]
Meldet sich ein Slave nicht mit einem Presence Pulse oder einer gültihen 64 Bit ROM-ID (z.B. CRC Fehler), wird kein Verzeichnis mit der ROM ID des Sensors im OWFS (One Wire File System) angelegt.
Das kann folgende Ursachen haben:
- Verdrahtungsfehler
- Kontaktfehler der Busverbindungen
- Mangelhafte Stromversorgung
- Ungünstige Bus-Kapazitäten / - Reflexionen
- Ungünstige Bus Struktur
Servus !
-
-
Wenn die grüne LED flackert, findet ein Datenverkehr der SD statt.
Beim "First Boot" eines OS kann es schon länger dauern, bis das OS vollständig eingerichtet wird. Auch ein check+repair des Filesystems kann länger dauern, wenn Du zuvor den Initialisierungsprozess mit Steckerziehen beendet hast. Warte einmal ein paar Minuten, bis das Flackern aufgehört hat.
Servus !
-
Was habe ich vergessen?
Dass derzeit nur mehr Python 3 unterstützt wird.
Dass sich ein DS18B20 grundsätzlich in der Gruppe 28 (und nicht 00) seiner ID meldet.
Dass zwei W1-Bus-Master am selben GPIO Pin nicht funktionieren.
Dass so ein "W1thermsensor" Programm auch seine Tücken haben kann.
Dass laut /boot/overlays/README -> Name: w1-gpio der interne "pullup" immer aktiviert wird.
Servus !
-
In einer der ersten Punkte wird gefordert, in der config.txt den VC4-KMS-V3D-Treiber zu deaktivieren.
Das betrifft aber nur den Pi-4 (laut Deiner Anleitung). Du redest von einem Pi 3B (ohne Plus)
Und in der Anleitung steht auch:
"Sollten Sie während der Verwendung unerwartet auf Probleme stoßen,
so können Sie uns selbstverständlich gerne kontaktieren."Servus !
-
Ein Image ist ein Speicherabbild vom ersten bis zum letzten Byte/Sektor.
Wenn Du ein zweites Image auf den Speicher (SD-Karte) schreibst, wird das vorherige natürlich überschrieben.
Servus !
-
1- Ok davon höre ich zum ersten mal?
2- Und wie bekommt man den weg?
3- Und warum ist er überhaupt aktiv. Ich hätte ihn nicht aktiviert
1. Dann hast Du die RaspberryPi Dokumentation (Hardware) nicht gelesen.
2. Das kann ich Dir nicht auswendig sagen. Dazu müsste ich (1.) durchlesen, aber das kannst Du auch.
3. Da fragst Du mich ? Wenn Dein Pi4 "nicht mehr" bootet, dann muss unmittelbar davor irgendwas passiert sein. Von einer Lösegeldforderung rede ich noch gar nicht.
Servus !
-
Es gibt schon ein schärferes Tool (hdparm), das aber aus gutem Grund im Pi-OS nicht vorinstalliert ist.
Wenn es aber um die "Gesundheit" eines Filesystems geht, sind bei jedem Filesystem Diagnosetools dabei.
Welche Plattenparameter willst Du denn wissen ?
Servus !
-
Wahrscheinlich ist im Pi4-eeprom "eeprom_write_protect" aktiviert.
Servus !
-
Ich würde nicht:
sudo iobroker stop [start], sondern
sudo systemctl stop iobroker [bzw. start] verwenden/versuchen.
Inzwischen wird ja systemd zur Boot- und Ablaufkontrolle verwendet.
Servus !
-
-
MotioneyeOS ist kein OS der RaspberryPi Foundation.
Wenn die Entwicker oder der Distributor von MotioneyeOS nicht auf den aktuellen Stand aufrüstet, kann der RaspberryPi nichts dafür. Niemand ist verpflichtet MotioneyeOS - in welcher Version auch immer - mit einer Pi-Camera-V3 zu verwenden.
Servus !
-
-
Du kannst nicht damit rechnen, dass jede aus dem Internet gefischte Anleitung auf Deinem Pi sofort fehlerfrei funktioniert.
Es gibt nicht nur einen Kernel und ein Grafiksystem ( wie bei Windows ), sondern viele von jedem.
Eine Anleitung funktioniert fehlerfrei nur auf dem System des Autors. Der wäre auch die erste Ansprechstelle, wenn bei Dir etwas nicht funktioniert.
Wenn sich Deine IT Kenntnisse auf die Bedienung der linken und rechten Maustatste beschränken solltest Du Dich erstmal mit den Grundlagen der IT und Linux Vertraut machen, bevor Du mit Projekten aus dem Internet loslegst.
Der Raspberrypi wurde auch nicht als Windows Ersatz, sondern als Lern- und Bastelsystem erfunden.
Servus !
-
Ich fühle mich einigermassen verar***t, und Du kannst Deinen Thread als erledigt markieren.
Servus !
-
Mach einmal ein update/upgrade.
Die Crux ist, Du brauchst dazu vermutlich das (verhasste) Passwort.
Das kannst Du aber umgehen, wenn Du in der Textkonsole mit sudo -i zu einer Interaktiven Root-Konsole wechselst.
Servus !
PS: Das Autologin beim Pi wurde nur dazu verwendet, um Neueinsteiger nicht gleich zu vergrämen.
-
Unter China-Ware, die man nicht verwenden soll, zählt sowas hier? https://www.amazon.de/stromsto%C3%9Fschalter-DC-12-V-Schaltausl%C3%B6ser-Relais-Einzelstabiles-Einkanal-Schaltkreis-Triggerschalter-Relais-Steuermodul-Steuerrelais-Modul/dp/B0BF99WSR6?tag=psblog-21 [Anzeige]
Ja.
Hier kommt noch erschwerend dazu, dass das Relay selbst gar kein bistabiles ist (laut Datenblatt), und erst durch die Beschaltung (bistabile Leiterplatte) zum bistabilen Modul gemacht wird. Genau das, was Du nicht haben willst.
Servus !
-
Da ist niemand gestolpert.
Da Du vor dem Update eine Swap-Partition angelegt hast, wurde beim Update der initrd lediglich in das neu generierte initrd.img die Swap Partition eingetragen, von der das (von suspend-to-disk / Hybernate abgelegte) RAM-Image wieder ins RAM geladen werden kann. Siehe < man initramfs.conf > - VARIABLES FOR LOCAL BOOT - RESUME
Richtig kaputt gemacht hast Du die boot-Partition der SSD aber erst, als Du von der SD dia alten Boot-Files auf die upgedateten boot-Files der SSD übertragen hast. Damit hast Du die neuen Boot-Files regelrecht niedergebügelt.
Verwende die letzte Datensicherung der SSD zum restore der SSD und mach das update/upgrade nochmals neu.
Servus !