Posts by pgloor

python3-pyqt5.qtwebengine fehlt auf jeden Fall in den Raspian OS Bullseye Archiven. In den Debian armhf-Archiven ist es vorhanden.

python3-pyqt5.qtwebengine selber hat auch eine Anzahl von Abhängigkeiten, von denen ich mir vorstellen könnte, dass sie evtl. zu Problemen führen könnten.

Ich habe im Raspberry Pi Forum auch folgende Aussage gefunden:

Quote

Calibre is not supported in raspbian bullseye because the new version depends on qtwebengine which is not supported on armv6 and IIRC the old version had to be removed due to depending on old libraries.

If you are running on a pi2 or newer you should be able to install the packages from Debian.

Ich habe dann mal versucht python3-pyqt5.qtwebengine aus den Debian Archiven zu installieren und das hat soweit funktioniert. Auch calibre konnte ich danach damit installieren.

Die Debian-Archive habe ich einem Beitrag zum Thema aus linuxquestions.org entnommen.

Da ich mich mit den Archivverwaltungen auch nicht (mehr) gut auskenne war das Ganze ein Bastel, den ich ausser für einen Versuch auf meinen Systemen niemals anwenden würde. Deshalb verzichte ich an dieser Stelle auch auf nähere Details darüber wie ich es gemacht habe.

Erschwerend dazu kommt, dass die gpg Keys für die Debian Archive installiert werden müssen, was leider auch nicht mehr wie bisher funktioniert, da apt-key den Status deprecated hat und in Zukunft andere Methoden verwendet werden sollten. Noch funktioniert das Prüfen und Hinzufügen der Keys, wenn man als Keyserver z.B. keyserver.ubuntu.com angibt. Man bekommt dann die deprecated Meldung, die aber ignoriert werden kann.

Beispiel:

# gpg --keyserver keyserver.ubuntu.com --recv-keys 0E98404D386FA1D9
gpg: Schlüssel 73A4F27B8DD47936: "Debian Archive Automatic Signing Key (11/bullseye) <ftpmaster@debian.org>" nicht geändert
gpg: Anzahl insgesamt bearbeiteter Schlüssel: 1
gpg:                             unverändert: 1
#
# gpg --export 0E98404D386FA1D9 | apt-key add -
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
OK
#

0E98404D386FA1D9 ist die ID die wegen fehlender Keys beim apt update ausgegeben wird, wenn Debian Archive zu der /etc/apt/sources.list hinzugefügt werden.

Nachdem ich Calibre fehlerfrei installieren konnte habe ich es einmal in einer X-Session gestartet, ansonsten aber nicht mehr weiter getestet.

Interessant finde ich noch, dass Calibre auf Github anscheinend immer noch aktiv entwickelt wird und es sich nicht um ein "totes" Projekt handelt.

Ich kann nur kurz zusammengefasst sagen, wie ich das vom Prinzip her mit Backups mache. Es kommt immer auf die Situation an.

Container ohne Volumes sichere ich mit docker export in ein .tar File, das ich dann weg kopiere. Das tar-file kann ich ggf. wieder in ein Image importieren aus dem ich einen Container starten kann.

Für Volumes starte ich einen Container mit dem Volume und benutze diesen Container um die Daten mit wegzukopieren.

Bei Volumes mit Datenbanken (z.B. mysql) benutze ich ebenfalls einen Container mit dem Volume und extrahiere die Daten mit mysqldump in eine Datei um sie wegzukopieren. Die gesicherten Daten zippe ich, bevor ich sie wegkopiere.

Zur Wiederherstellung erstelle ich wieder ein neues Volume mit gleichem Namen und stelle die Daten im umgekehrten Sinn als oben beschrieben wieder her.

Bezüglich Volumes habe ich schon gehört, dass man einfach das ganze Verzeichnis sichern kann, aber genau das hat dann für mich bei einer Wiederherstellung nicht funktioniert.

Unter Umständen kann auch eine externe Festplatte schon Probleme verursachen. Dies ist insbesondere dann der Fall, wenn noch etwas anderes am USB hängt oder die Stromversorgung nicht 100% genügend und zuverlässig ist. Ich habe immer noch eine Toshiba Canvio rumliegen, die ich ohne aktivem Hub am Pi nie zum laufen gebracht habe. Ich hatte an anderer Stelle hier im Forum schon mal darüber berichtet.

Meine Beweggründe zur Nutzung externer Datenträger sind zum einen die oft beschworene Haltbarkeit der SD Karte und zum andern die Datensicherung. A propos Haltbarkeit: ich hatte schon mehr defekte Flash-Drives als defekte SD-Karten. Von den Western Digital HDD's die ich früher am Pi im EInsatz hatte ging noch nie eine kaputt.

Mittlerweile ist mein Speicherbedarf gering. Mit einer Ausnahme haben all meine Projekte auf 32 GB genügend Platz. Ich verwende deshalb nur noch 32 GB Sticks und Speicherkarten.

Meine zur Zeit aktiven Pi 2 und Pi 3 haben alle einen 32 GB San Disk Ultra Fit Stick. Meine beiden Pi 3 boote ich damit. Bei den Pi 2 benutze ich sie als externe Datenträger für häufige Schreiboperationen oder Backups.

Danke. Gut zu wissen, denn von den Pi 2 habe ich auch noch zwei.

Ich benutze seit vergangenem Wochenende Bullseye Lite (headless) auf einem Pi 3 Model B ohne +. Das funktioniert bei mir bis jetzt sehr gut.

Genau das habe ich jetzt auch gemacht. Das ist bei dieser popeligen Internet-Box der Swisscom zwar nicht unbedingt trivial, aber machbar.

InterGeek und rpi444 : Ja, sowas wie rpi3-lan und rpi3-wlan wäre machbar. Ich habe mehrere PI's und hatte diese immer nach dem Schema rpi<modell>-<nummer> benannt. Also z.B. rpi0-1, rpi2-1, rpi2-2, rpi3-1 etc. In der Regel ist alles abgeschaltet was ich nicht brauche.

Bei diesem Pi3 gibt es für mich eine Besonderheit. Ich benutze ihn normalerweise, wie die anderen Pi's, in einem Raum mit einem Switch. Die WLAN Verbindung ist in diesem Raum normalerweise eher schlecht. Ich benutze diesen Pi3 im Rahmen eines Projekts aber oft auch in einem anderen Raum in dem ich keinen Kabel-Anschluss, dafür aber eine gute WLAN Verbindung zum Router habe.

Deshalb benötige ich eine Lösung bei der ich diesen Pi einfach von einem Raum zum andern zügeln kann und ihn nach dem Starten sofort wieder verfügbar habe. Ist ein LAN-Anschluss vorhanden, über LAN und sonst über WLAN. Ob ich mich dabei mit dem Namen pi3-1-lan oder pi3-1-wlan verbinde spielt für mich keine Rolle.

Quote from Rasp-Berlin

Du hast geschrieben, dass er per LAN als PI3 und per WiFi als PI3-1 erreicht wird. Da man dem System nur einen Namen geben kann, müsste er den Namen, der ihm bei der Verbidnung per WiFi angegeben wird, überprüfen, was er nicht kann, oder steht er mit der WiFi-Adresse als PI3-1 in deinem DNS?

Je nachdem, mal mit der WiFi-Adresse (wlan0) als pi3-1 und mal mit der LAN Adresse (eth0) als pi3. Beim nächsten Neustart vielleicht wieder anders rum. Jetzt gerade hat die Lan-Adresse pi3-1 und die WiFi Adresse pi3.

Quote from InterGeek

Betreffend der Benennung deiner Geräte würde ich noch gerne folgendes anmerken. Wenn dein Heimnetz die Art Name.home nutzt, dann sollten die Geräte auch idealerweise den Namen Name.home haben und nicht nur Name.

Gute idee Leider nur halbwegs, da der Router .home voll mitnimmt. Also konkret führte mein Versuch dazu, dass nach einem Neustart die WiFi adresse im Router den Namen pi3-1.home bekommen hat und die LAN Adresse Namen pi3-1.home-1. Ein Nebeneffekt dabei ist, dass der Name pi3-1.home-1 nicht aufgelöst werden kann.

Das zeigt, dass der Router mit den -1 Endungen Probleme hat, bzw. bei Verbindungen mit gleichem Namen ein -1 anhängt. Die Domäne .home wird ebenfalls vom Router automatisch hinzugefügt.

Für mich ist die Sache jetzt nicht so wichtig. Ich wollte nur die Vermutung von hyle bestätigen, dass das Problem von reinhard auf ain Netzwerkproblem zurückzuführen sein könnte. Im Moment gehe ich davon aus, dass ich unter Stretch und Buster irgend einen einfachen Trick angewendet habe.

Ich verstehe diese Antwort nicht? Wer sagt denn, dass der Name nicht aufgelöst werden kann?

Das Problem das ich angesprochen habe ist, dass ich ein neues Raspberry Pi OS Lite (bullseye) auf meinem Pi 3 installiert habe und diesem über raspi-config den Namen pi3-1 gegeben habe. Zusätzlich habe ich über raspi-config noch das WLAN konfiguriert (SSID, passphrase und WLAN Country).

Dieser Pi ist über ein Kabel direkt mit dem Router verbunden, verbindet sich aber mit dem Router auch über WLAN. Der Router vergibt aber intern die Namen pi3-1 für die eine Verbindung und pi1 für die andere Verbindung. Welche Verbindung welchen Namen bekommt ist rein zufällig. Es scheint, dass die erste Verbindung, die zustande kommt den Namen pi3-1 bekommt, während der Name für die zweite Verbindung auf pi3 abgekürzt wird.

Mein PC ist mit DHCP konfiguriert, d.h. der Name wird über den Router aufgelöst. Verbinde ich mich nun vom PC mit ssh pi3-1 mit meinem Raspberry Pi, dann kann die Verbindung vom PC über das LAN-Kabel zum Router erfolgen und von dort weiter über das LAN-Kabel zum Raspberry Pi erfolgen. So hätte ich es gerne, wenn immer ein Kabel vorhanden ist.

Da sich der Router aber manchmal den Namen pi3-1 für den WLAN-Anschluss schnappt, bekomme ich bei der Namensauflösung die IP-Adresse des WLAN's im Raspberry, so dass die Verbindung zwischen dem Router und dem Raspberry über WLAN und nicht über das Kabel erfolgt. Ist dies der Fall, dann habe ich genau den beschriebenen Effekt, bei dem es manchmal schon bei der Eingabe von Befehlen im Terminalfenster ruckelt und klemmt.

Mit der richtigen Verbindung über Kabel ruckelt gar nichts und ich könnte in keiner Weise sagen, dass mein Pi 3 für Buster oder Bullseye zu schwach ist.

Wie bereits erwähnt, hatte ich mal eine Lösung für das Problem gefunden, so dass es in den letzten 2 - 3 Jahren auch mit Buster problemlos gelaufen ist. Ich kann es natürlich so lösen, dass ich feste IP Adressen konfiguriere und diese dann in meinem PC in der /etc/hosts definiere.

Ich habe mal folgenden Versuch gestartet:

1. Pi runtergefahren und abgeschaltet
2. Die beiden Geräte (pi3 und pi3-1) im Router aus der Geräteliste gelöscht
3. An meinem PC (Ubuntu) die DNS-Cache geleert
4. Meinen PC runtergefahren und abgeschaltet
5. Ca. drei Minuten gewartet
6. PC wieder hochgefahren
7. Pi wieder gestartet
8. Ca. drei Minuten gewartet

Danach war es so, dass jetzt im Router der LAN-Port mit dem Namen pi3-1 und der WLAN Port mit dem Namen pi3 ausgewiesen wird. Beide Ports haben je eine IPv4 und eine IPv6 Adresse. Die ausgewiesenen Namen pi3-1 und pi3 sind genau genommen pi3-1.home und pi3.home, was z.B. bei einem ping sichtbar wird.

Wenn ich mal etwas Zeit finde, werde ich versuchen wieder eine zuverlässig funktionierende Konfiguration hinzubekommen. Ich hatte früher schon mal gleiche Probleme, aber ich hatte mit der letzten Konfiguration mindestens seit 2019 keine Probleme mehr. Falls ich überhaupt was angepasst habe, dann kann es nur eine Kleinigkeit gewesen sein.

N.B. Eines hatte ich noch vergessen zu erwähnen. Wenn ich in diesem Zusammenhang von WLAN rede, dann meine ich immer WLAN zwischen dem Router und meinem Pi. An meinem PC habe ich kein WLAN, der ist im Netz immer mit dem Router verbunden. Beim Pi kommt es aber vor, dass ich den vom Kabel wegnehme und zum basteln in einem anderen Raum benutze, wo ich nur WLAN habe.

Nachtrag 18.1.2022 14:24: hostctl gibt Static hostname: pi3-1 aus.

Quote from hyle

Um das auch noch abzuklären...

Tritt das Problem auch auf, wenn Du Dich über die WLAN-IP per SSH verbindest oder nur, wenn der Hostname verwendet wird?

In meinem Fall, auch wenn ich mich über die WLAN IP verbinde.

Mein Router ist eine Internet-Box standard von Swisscom. Im Router ist mein Pi am WLAN Port nur mit einer IPv6 Adresse versehen. Der LAN Port hat jedoch eine IPv4 und eine IPv6 Adresse.

In der bisherigen Buster-Konfiguration hatte ich das Problem nicht.

Es kann aber gut sein, dass ich an der Konfiguration etwas vorgenommen hatte. Habe ich den LAN-Stecker gezogen und neu gebootet, wurde ich über WLAN verbunden. War der Stecker vor dem Booten drin, dann wurde ich über das LAN-Kabel verbunden.

Ich hatte am Wochende auf meinem Pi3 Bullseye installiert und hatte auch das nervige Problem... und es war genau das Problem, dass sich mein Pi über WLAN verbunden hat.

Mein Pi hat den Namen pi3-1. Auf dem WLAN Router ist er im LAN als pi3 und im WLAN als pi3-1 bekannt. Verbinde ich mich jetzt über ssh pi3-1 wird die Verbindung natürlich über WLAN gezogen.

Vorläufig habe ich noch keine Massnahme getroffen, ausser, dass ich mich über ssh pi3 verbinde.

Obwohl der Thread ein Jahr alt ist möchte ich hier noch eine Ergänzung anbringen. Dart ist eine Programmiersprache von Google, die zur Entwicklung client-optimierter Anwendungen, die auf verschiedenen Plattformen laufen können, ausgerichtet ist. Dart unterstützt 32-bit ARM ab v7 und neu auch 64-bit ARM.

Die hauptsächlichste Anwendung von Dart dürfte in Verbindung mit Flutter zu finden sein. Flutter ist ein komplettes UI-Toolkit von Google zum Erstellen von nativ kompilierten Anwendungen für Mobil-, Web-, Desktop- und IoT-Anwendungen. Mit Flutter ist es möglich, graphische Benutzeroberflächen zu erstellen, die für verschiedene Plattformen kompiliert werden können, ohne dass der Code speziell angepasst werden muss. So kann z.B. eine Chat-Anwendung auf einem iPhone, einem Android Smartphone oder in einem Browser laufen. Den einmal geschriebenen Code einfach für die Zielplattform kompilieren und gut ist (o.k. theoretisch ;)).

Im Gegensatz zu Dart ist für Flutter ein 64-bit Linux erforderlich. Für 32-Bit ARM V7 oder höher gibt es keine Unterstützung. Wie ich in einem Artikel gelesen habe, gibt es aber die Möglichkeit die Flutter Engine zu portieren. Und jetzt wird es für den Pi besonders interessant, denn es gibt unter dem Namen flutter-pi ein Open Source Projekt mit dem sich ein GUI auch für Anwendungen die ganz ohne X11 oder Wayland ausukommen erstellen lässt.

Während ich auf meinem Raspberry Pi 3 Model B mit der Programmiersprache Dart schon ausgiebig gespielt habe um deren Sinn und Möglichkeiten auszuloten, habe ich Flutter auf dem Pi bisher ausgelassen. Ich bin mir aber recht sicher, dass es nicht mehr lange dauern wird bis auf den 64-bit Pi's Dart in Verbindung mit Flutter Einzug hält, zumal es seit neustem auch eine Library (dart:ffi ) gibt um C API's aufzurufen. Also ich sehe hier Potential für tolle und spannende Anwendungen die sich mit relativ wenig Aufwand erstellen lassen.

Das Problem mit dem Power Management hatte ich gelöst in dem ich in der Datei /etc/rc.local in der Zeile vor exit 0 den folgenden Befehl eingefügt habe:

/sbin/iwconfig wlan0 power off

/etc/rc.local sieht bei mir jetzt so aus:

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

# Print the IP address
_IP=$(hostname -I) || true
if [ "$_IP" ]; then
printf "My IP address is %s\n" "$_IP"
fi

/sbin/iwconfig wlan0 power off
exit 0

Dadurch wird bei jedem Start der Befehl iwconfig wlan0 power off ausgeführt. Das hat bei mir soweit immer funktioniert und die Situation entscheidend verbessert.

Nach einem Reboot bringt iwconfig folgendes Resultat:

$ iwconfig
lo        no wireless extensions.

eth0      no wireless extensions.

wlan0     IEEE 802.11  ESSID:off/any
Mode:Managed  Access Point: Not-Associated   Tx-Power=31 dBm
Retry short limit:7   RTS thr:off   Fragment thr:off
Power Management:off

Ich habe die Ursache zu meinem Problem gefunden. Es hat vermutlich nichts mit dem Problem des Thread-Erstellers zu tun.

Für meinen pi3-1 hatte ich vor langer Zeit Portweiterleitungen definiert. Dadurch wurden dem Namen pi3-1 statische IPv4 Adressen zugewiesen. Ich hatte bisher in Verbindung mit dem Pi noch nie eine IPv6 Adresse gesehen, d.h. wenn ich im Router die Details zu dem Gerät angeschaut habe, dann hat da immer eine IPv4 Adresse gestanden und wenn ich mich zum Pi verbunden habe, dann war das immer eine IPv4 Verbindung. Es wäre mir aufgefallen, wenn es nicht so gewesen wäre, da mir beim Login immer die IP des letzten Besuchs angezeigt wird.

Und genau das ist neu, meine Verbindungen sind jetzt immer IPv6 Verbindungen, was eigentlich richtig wäre, wenn IPv6 aktiviert ist. Was diesbezüglich eine Änderung bewirkt hat, weiss ich noch nicht, aber wenn ich im Pi IPv6 total abschalte, habe ich das Problem auch nicht mehr.

Der Router ist eine Internet-Box Standard (Hersteller Arcadyan) von Swisscom. Das .home fügt der Router hinzu. Alle Geräte im Netz am Router gehören zur internen Domain .home.

Mit dem Benennen meinte ich die Konfiguration des Hostnames. Ich habe mehrere Pi's. Am Netz ist meistens nur einer, manchmal zwei. Der erste Pi3 den ich gekauft habe, hat den Hostname pi3-1, der zweite pi3-2 etc.

Ich denke der Router hat (neu) ein Problem mit dem Postfix. Sind zwei Geräte mit gleichem Namen am Netz, dann hängt der am zweiten Gerät automatischen ein -1 an, am dritten ein -2 etc. Das machte bisher nie Probleme und ich vermute, dass sich mit dem letzten Update des Routers etwas geändert hat. Ich mache das schon mindestens drei Jahre so und hatte dieses Problem noch nie.

Falls es so ist werde ich meine Pi's einfach anders benennen (z.B. pi3-one etc). Da ich das Problem erst neu habe, dachte ich, dass ich es hier erwähne, als ich diesen Thread gesehen habe. Vielleicht ist es etwas am Raspberry Pi OS, das unsere Router anders als erwartet ticken lässt.

Ich stelle sei neustem auch ein anderes Verhalten bezüglich der Namensauflösung meiner Pi's in meinem Router fest. Ich benenne meine Pi's mit dem Modell und einem Postfix, wie z.B. pi3-1. Der vollständige Name im Router wäre dann pi3-1.home., wobei im Router nur pi3-1 angezeigt wird und ich mich damit von meinem Linux PC mit ssh pi3-1 einloggen kann.

Seit Kurzem funktioniert das nicht mehr richtig. Wenn ich den Pi oder den Router neu starte, dann steht im DNS des Routers nur noch der Name pi3 ohne meinen Prefix. Das bleibt so lange so, bis ich mich mit dem Namen pi3 verbinde. Bin ich eingeloggt, dann dauert es ein paar Sekunden und im Router wechselt der Name zum Namen des Hostnames.

eter@pi3-1:~ $ dig -x 192.168.1.106 +short @192.168.1.1
pi3.home.
peter@pi3-1:~ $ dig -x 192.168.1.106 +short @192.168.1.1
pi3-1.home.
peter@pi3-1:~ $ 

Ich weiss nicht woher der Name pi3 (ohne Prefix) überhaupt kommt und ob es ein Server oder ein Router Problem ist. Ich arbeite so seit Jahren und habe das Problem erst diese Woche entdeckt. Zufällig machte ich gerade jetzt Updates und einen Neustart des Routers was vorher über längere Zeit nicht der Fall war.

Hallo Busfahrer,

ich bin gespannt auf deine Lösung und deine Erfahrungen mit dem Projekt. Ich habe mir vor zwei Jahren dazu Gedanken gemacht und wollte es mit einem Pi 2 in Angriff nehmen, als wir noch kein WoMo hatten.

Die Komponenten sind bei mir etwas grobschlächtiger ausgefallen. Für den Display habe ich einen Hud für den Pi 2. Das GPS ist ein USB 2.0 GNNS Receiver von ublox. Das Ding sieht aus wie eine optische Maus, nur ohne Rad und Tasten. Darüber hinaus habe ich noch (zwei verschiedene) Komponenten um den Luftdruck zu messen mit denen ich die Höhe ermitteln wollte. Das alles wollte ich in eine passende Box verbauen.

Das Material ist da, der Camper inzwischen auch, und ein paar Versuche mit den Komponenten habe ich auch gemacht. Nur fertiggebaut habe ich es nie

Es ist immer wieder etwas dazwischen gekommen und wenn wir Gelegenheit dazu hatten, dann waren wir lieber unterwegs als am Basteln. Dazu kommt, dass das Bauen und Löten weniger mein Ding ist als das Programmieren.

Wer weiss, vielleicht treffen wir uns mal zufällig unterwegs, wo ich dann deinen Tracker bewundern kann.

Peter

Ich kann mir nicht vorstellen, dass es ein Tool gibt um deine Installationen in Container umzuwandeln.

Als erstes stellt sich mir die Frage, was du unter einem Container verstehst (z.B. lxc, lxd, docker etc) und wie die "Installationen" aussehen, die du übertragen möchtest. Um welche Art von Server handelt es sich dabei?

Wie auch immer, grundsätzlich würde ich empfehlen auf dem Host (deinem Pi 4) die Container bereitzustellen und dann das was benötigt wird mit scp an die richtigen Stellen zu kopieren. Mich würde wundern, wenn dieser letzte Schritt nicht der einfachste Schritt im Rahmen deines Projektes wäre.

Leider ist die Geschichte hier noch nicht zu Ende. Ich ersetzte meinen defekten SONY Stick zuerst durch einen billigen 32 GB Kingston DataTraveler G4, der mir für meine Anwendungen aber viel zu langsam war. Ich erreichte Schreibgeschwindigkeiten zwischen 3.2 MB/s und maximal 8.5 MB/s (gemessen mit dd if=/dev/zero of=test.tst bs=4096 count=100000).

Dann ersetzte ich den Stick durch einen 64 GB SanDisk Extreme Go USB3.1 Stick. Der fühlte sich schon viel besser an, aber ich bin gar nicht zum Messen gekommen. Bereits nach dem 2. Reboot ist er wieder hängen geblieben. Nachdem ich ihn auf meinem PC unter Linux geöfffnet hatte, konnte ich damit auch wieder den Pi 3 starten.

Als ich fertig mit einrichten war und nochmals einen Reboot machte ist er wieder hängen geblieben. Diesmal wurde auch dieser Stick auf dem PC nicht mehr erkannt. Auch auf meinem Notebook mit Windows 10 wurde er nicht mehr erkannt. Das bedeutet, mein Pi hat mir jetzt zwei USB Sticks zerschossen, die teurer sind als der Pi selbst.

Da die Probleme immer beim Reboot aufgetreten sind, würde mich interessieren was die Ursache sein könnte. Darüber hinaus würde mich interessieren ob es irgendeine Möglichkeit gibt solche Sticks wieder zum Leben zu erwecken.

Nebenbei bemerkt ist das bereits der zweite Pi 3 bei dem ich Probleme mit dem USB Port hatte. Der erste hat gerade mal ein paar Monate gehalten. Dieser hier stammt aus Januar/Februar 2018 (Garantie-Austausch vom defekten Vorgänger). Ich habe einen weiteren Pi 3 den ich auch mit USB betreibe mit dem ich noch nie Probleme hatte.