Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.

--- birdnet [2025/03/21 22:59] – varnholt
+++ birdnet [2026/03/07 23:29] (aktuell) – varnholt
@@ Zeile 16: / Zeile 16: @@
 nach der Installation gestartet sich der Pi automatisch. Leider geht weder http://birdnetpi.local/ (Ubuntu Apache Startpage) noch http://birdnetpi.local/index.php (404 not found).
-Nochmal den Ordner BirdNET-Pi gelöscht und nochmal installiert...
+Nach mehrmaligem installieren dann doch länger gesucht und die Lösung ist, dass man apache stoppen und disablen muss und caddy starten. Ob man wirklich noch die Rechte verdrehen muss weiss ich nicht. Ich habe es gemacht und es ging. Gefunden unter: [[https://github.com/mcguirepr89/BirdNET-Pi/issues/1194|https://github.com/mcguirepr89/BirdNET-Pi/issues/1194]]
+<code>
+sudo systemctl stop apache2
+sudo systemctl disable apache2
+sudo chmod -R g+rx /home/pi
+sudo systemctl start caddy
+sudo systemctl enable caddy
+</code>
+Dann geht [[http://birdnetpi.local|http://birdnetpi.local]]
+Jetzt hänge ich schon wieder x Stunden. Nach der Installation alles ausprobiert (ohne Mic). Dann runtergefahren, und am Fenster mit WIFI wieder gestartet - ohne Erfolg.
+* Problem 1: wlan0 und eth0 hatten dieselbe Adresse, bis ich im Router die "feste IP" ausgestellt habe.
+* Problem 2: ohne LAN-Kabel startet er erst gar nicht; mehrfach unterschiedliche Neuinstallationen nach x Versuchen mit DeepSeek und ChatGPT. Lösung (?): System installieren, Localization, Neustart, Wifi an, Neustart ohne LAN (dauert laaange), LASN rein, Systemupdate, Neustart ohne LAN (dauert immer noch laaaange) - und nein, es ging immer noch nicht - immer erst, wenn man LAN eingesteckt hat.
+Also: Raspberry Pi Imager heruntergeladen, WLAN Infos rein, er scheint zwei Dateien draus zu machen, cmdline.txt und firstrun.sh und dann ging' (mit nur noch 2* installieren der Software).
+cmdline.txt
+<code>
+console=serial0,115200 console=tty1 root=PARTUUID=8a438930-02 rootfstype=ext4 fsck.repair=yes rootwait quiet init=/usr/lib/raspberrypi-sys-mods/firstboot cfg80211.ieee80211_regdom=DE systemd.run=/boot/firstrun.sh systemd.run_success_action=reboot systemd.unit=kernel-command-line.target
+</code>
+firstrun.sh (oha, die ist 72 Zeilen lang) - aber es sieht so aus, als würde doch nur wieder eine /etc/wpa_supplicant/wpa_supplicant.conf angelegt werden
+Jetzt gehts an die Micro Probleme. Der Raspberry gibt über die 3.5mm Buchse nur Ton aus, man kann kein Mikro anschliessen! Nachdem in meiner Bastelkiste die USB Mikrofonkarten aufgetaucht sind, nehme ich jetzt das Konsolen eye, das sofort geht.
+Aber die Website geht nur mit ip und nicht (mehr) wie beim LAN mit dem Namen. Mal im Router den Namen eintragen und schauen, was passiert. Sollte vielleicht auch gehen (nach Neustart)
 Meine Ideen wären:
@@ Zeile 26: / Zeile 56: @@
 Stand 2025-05
+Immer mal wieder gab es keine Verbindung zum RaspberryPi, der hinter meinem macOS, der hinter meiner Fritz!Box hängt. Mit einem recht einfachen caddy auf dem raspberry und einem relativ einfachen forward im apache auf dem Mac. Nachdem es mal wieder NICHT ging, kamen Chat und ich darauf (nach längerem versuch, auf Daddy Seite nur ipv4 zuzulassen), dass es auch geht, am Mac retry und RequestHeader möglicherweise geholfen haben.
+<code>
+ProxyPass / http://192.168.178.72/ retry=0
+ProxyPassReverse / http://192.168.178.72/
+RequestHeader set Host "192.168.178.72"
+</code>
+----
+=== Ping Mac → Raspberry Pi funktioniert nicht ===
+## Symptom
+- `ping 192.168.178.72` vom Mac → `Request timeout`
+- Ping vom Pi zum Mac funktioniert aber
+## Ursache
+Wenn der Mac zusätzlich per Ethernet angeschlossen war (beide Interfaces im gleichen Subnetz 192.168.178.x), verwirrt sich macOS beim Routing. Eine manuell hinzugefügte statische Route bleibt dabei als „Leiche" zurück, auch nachdem das Ethernet-Kabel wieder gezogen wurde.
+## Diagnose
+```bash
+netstat -rn | grep 192.168.178.72
+```
+Wenn dort so eine Zeile erscheint, ist die kaputte Route noch aktiv:
+```
+.168.178.72/32  192.168.178.1      UGSc    en1
+```
+Die IP des Pi wird dann fälschlicherweise über den Router (Gateway) geleitet statt direkt.
+## Lösung
+```bash
+sudo route delete 192.168.178.72
+```
+Danach Ping erneut testen – sollte sofort funktionieren.
+## Wann tritt das auf?
+Immer dann, wenn der Mac zwischenzeitlich **gleichzeitig per Ethernet und WLAN** im selben Subnetz angeschlossen war.
+=== Apache Mac → Raspberry Pi funktioniert nicht ===
+## Symptom
+Der Aufruf thearkgarden.pikasso.eu.org geht nicht, aber aus dem terminal geht es, oder mit ip oder mit curl -vI http://prebird.fritz.box/ oder curl -v http://192.168.178.72/ -H 'Host: thearkgarden.pikasso.eu.org' IN /etc/hosts den Eintrag prüfen: 192.168.178.72 prebird.fritz.box
+## Lösung
+Nach mehreren Stunden 'Problemlösung' mit ChatGPT Pro hat Perplexity Pro geholfen. Es lag an einer falschen Konfigurationsdatei von brew httpd.
+<code>
+Homebrew‑Daemon frisch setzen:
+sudo brew services stop httpd
+sudo launchctl remove homebrew.mxcl.httpd 2>/dev/null || true
+sudo brew services cleanup
+sudo brew services start httpd    # mit oder ohne sudo, je nachdem ob systemweit oder userweit
+sudo launchctl bootout system/homebrew.mxcl.httpd 2>/dev/null || true
+sudo launchctl bootstrap system /Library/LaunchDaemons/homebrew.mxcl.httpd.plist
+</code>