Broken Things - Versionsgeschichte

Tut am 14. Mai 2025 um 17:21 Uhr

2025-05-14T17:21:20Z

Tut: /* ESP32 + ETH */

2025-05-14T17:17:23Z

‎ESP32 + ETH

Tut: /* Raspberry Pi Zero W(H) */

2025-05-14T17:08:59Z

‎Raspberry Pi Zero W(H)

Tut: /* Raspberry Pi Zero W(H) */

2025-05-14T17:00:07Z

‎Raspberry Pi Zero W(H)

Tut am 14. Mai 2025 um 16:59 Uhr

2025-05-14T16:59:40Z

Tut: /* Raspberry Pi Zero W(H) */

2025-05-14T16:54:34Z

‎Raspberry Pi Zero W(H)

Tut: /* Raspberry Pi Zero W(H) */

2025-05-14T16:33:26Z

‎Raspberry Pi Zero W(H)

Tut: Die Seite wurde neu angelegt: „== Broken Things == Dinge, die einfach unglaublich kaputt sind... === Raspberry Pi Zero W(H) === 400px Welcher Teufel hat si…“

2025-05-14T16:33:13Z

Die Seite wurde neu angelegt: „== Broken Things == Dinge, die einfach unglaublich kaputt sind... === Raspberry Pi Zero W(H) === 400px Welcher Teufel hat si…“

Neue Seite

== Broken Things ==
Dinge, die einfach unglaublich kaputt sind...

=== Raspberry Pi Zero W(H) ===
[[Datei:RaspiZero WLAN Fail.jpg|400px]]
Welcher Teufel hat sich den Raspberry Pi Zero konstruiert und mit einem Wifi ausgestattet, das insbesondere mit gängigen UniFi Wifi AP's nur so grottig funktioniert, dass ich meinen Raspberry zerschlagen habe?

Die Kombination Raspberry Pi Zero W mit UniFi-Wifis geht gar nicht:
* Der Raspberry hat so wenig Anschlüsse, dass man eigentlich nur per Wifi drauf zugreifen kann
* Wifi ist aber nicht zu gebrauchen, weil es die Verbindung immer nur für wenige Sekunden erlaubt, dann aber für mehr als 30(!) Sekunden nicht ansprechbar ist.

==> Ich hab alles mögliche probiert, Wifi-Power-Settings deaktiviert. '''Ich hab nun eine Lösung gefunden: Neht einen Hammer und zerkloppt diese Teile, die euch nutzlos Lebenzeit fressen.'''

← Nächstältere Version		Version vom 14. Mai 2025, 17:21 Uhr
Zeile 33:		Zeile 33:
	== ESP32 + ETH ==		== ESP32 + ETH ==
	Man aktiviert den Watchdog, sichert damit alle möglichen Tasks, wenn der WD anspringt gibt es einen Reset - u.a. wenn der Ping zum Router nicht mehr geht. Wie es der ESP32 schafft trotzdem reproduzierbar einzufrieren und trotz Watchdog keinen Reset zu machen, ist mir ein Rätsel. Man baut zum ESP32 via LAN eine TCP-Verbindung auf (egal ob Telnet, Monitor oder Websocket), versetzt dann den Client in einen Sleep-Zustand (Laptop Klappe zu oder Handy Display aus) --> ESP32 friert ein. Watchdog hilft nicht. Arduino Core 3.2.x bringt auch keine Besserung. Ich weiß nicht was das los ist - wie ist das überhaupt möglich das Watchdogs nicht greifen? Ich werde mich wieder um externe Hardware-Watchdogs betrieben an Ports bemühen müssen, die den ESP32 einen Hardware-Reset geben. Das ist sowas von 1990'er...		Man aktiviert den Watchdog, sichert damit alle möglichen Tasks, wenn der WD anspringt gibt es einen Reset - u.a. wenn der Ping zum Router nicht mehr geht. Wie es der ESP32 schafft trotzdem reproduzierbar einzufrieren und trotz Watchdog keinen Reset zu machen, ist mir ein Rätsel. Man baut zum ESP32 via LAN eine TCP-Verbindung auf (egal ob Telnet, Monitor oder Websocket), versetzt dann den Client in einen Sleep-Zustand (Laptop Klappe zu oder Handy Display aus) --> ESP32 friert ein. Watchdog hilft nicht. Arduino Core 3.2.x bringt auch keine Besserung. Ich weiß nicht was das los ist - wie ist das überhaupt möglich das Watchdogs nicht greifen? Ich werde mich wieder um externe Hardware-Watchdogs betrieben an Ports bemühen müssen, die den ESP32 einen Hardware-Reset geben. Das ist sowas von 1990'er...
		+
		+	== PlatformIO ==
		+	Eigentlich eine tolle Sache. Bis die Leute dahinter wohl zu gierig geworden sind und still und leise den Support eingestellt haben für vieles was derzeit "hip" ist. Updates für ESP32? Fehlanzeige! Updates für RP2040? Fehlanzeige! Wenn ihr euch wundert, warum Dinge nicht gescheit funktionieren, die eigentlich gefixt sein sollten, schmeißt Plattform-IO wieder runter, ersetzt es durch PIOArduino oder steigt auf die Systeme der Hersteller um.

← Nächstältere Version		Version vom 14. Mai 2025, 17:17 Uhr
Zeile 32:		Zeile 32:

	== ESP32 + ETH ==		== ESP32 + ETH ==
		+	Man aktiviert den Watchdog, sichert damit alle möglichen Tasks, wenn der WD anspringt gibt es einen Reset - u.a. wenn der Ping zum Router nicht mehr geht. Wie es der ESP32 schafft trotzdem reproduzierbar einzufrieren und trotz Watchdog keinen Reset zu machen, ist mir ein Rätsel. Man baut zum ESP32 via LAN eine TCP-Verbindung auf (egal ob Telnet, Monitor oder Websocket), versetzt dann den Client in einen Sleep-Zustand (Laptop Klappe zu oder Handy Display aus) --> ESP32 friert ein. Watchdog hilft nicht. Arduino Core 3.2.x bringt auch keine Besserung. Ich weiß nicht was das los ist - wie ist das überhaupt möglich das Watchdogs nicht greifen? Ich werde mich wieder um externe Hardware-Watchdogs betrieben an Ports bemühen müssen, die den ESP32 einen Hardware-Reset geben. Das ist sowas von 1990'er...

@@ Zeile 6: / Zeile 6: @@
-Welcher Teufel hat sich den Raspberry Pi Zero konstruiert und mit einem Wifi ausgestattet, das insbesondere mit gängigen UniFi Wifi AP's nur so grottig funktioniert, dass ich meinen Raspberry zerschlagen habe?
+Welcher Teufel hat den Raspberry Pi Zero konstruiert und mit einem Wifi ausgestattet, das insbesondere mit gängigen UniFi Wifi AP's nur so grottig funktioniert, dass ich meinen Raspberry zerschlagen habe?
 Die Kombination Raspberry Pi Zero W mit UniFi-Wifis geht gar nicht:
@@ Zeile 27: / Zeile 27: @@
 reboot
 </pre>
 == ESP32 + ETH ==

@@ Zeile 19: / Zeile 19: @@
 In der c't habe ich einen Hinweis gefunden, vielleicht liegt es auch nur am Schreibschutz des Root-Filesystems. Als ich die Befehle allerdings eingeben wollte, gab es wieder Verbindungsabbrüche - so stark, dass es sogar "broken pipe" gab. Das gab dann "broken raspi"... Solltet ihr es wirklich schaffen, einen Raspberry Pi Zero W so in ein UniFi-Wifi zu bringen, dass die SSH-Verbindung wirklich ständig ohne Lags funktioniert, gebt doch bitte mal Rückmeldung, was dazu nötig war.
-c't Anleitung (bin nicht soweit gekommen ["broken pipe" --> "hammer up, broken raspberry"], ich vermute aber mal, dass auch das nichts bringt bei UniFi Wifi's):
+c't Anleitung (bin nicht soweit gekommen ["broken pipe" -hammer-> "broken raspberry"], ich vermute aber mal, dass auch das nichts bringt bei UniFi Wifi's):
 <pre>
 sudo su

@@ Zeile 1: / Zeile 1: @@
-== Broken Things ==
+= Broken Things =
 Dinge, die einfach unglaublich kaputt sind...
-=== Raspberry Pi Zero W(H) ===
+== Raspberry Pi Zero W(H) ==
 [[Datei:RaspiZero WLAN Fail.jpg|400px]]
@@ Zeile 12: / Zeile 12: @@
 * Wifi ist aber nicht zu gebrauchen, weil es die Verbindung immer nur für wenige Sekunden erlaubt, dann aber für mehr als 30(!) Sekunden nicht ansprechbar ist.
-==> Ich hab alles mögliche probiert, Wifi-Power-Save-Settings deaktiviert. '''Ich hab nun eine Lösung gefunden: Nehmt einen Hammer und zerkloppt diese Teile, die euch nutzlos Lebenzeit fressen.'''
+==> Ich hab alles mögliche probiert, Wifi-Power-Save-Settings deaktiviert.
 In der c't habe ich einen Hinweis gefunden, vielleicht liegt es auch nur am Schreibschutz des Root-Filesystems. Als ich die Befehle allerdings eingeben wollte, gab es wieder Verbindungsabbrüche - so stark, dass es sogar "broken pipe" gab. Das gab dann "broken raspi"... Solltet ihr es wirklich schaffen, einen Raspberry Pi Zero W so in ein UniFi-Wifi zu bringen, dass die SSH-Verbindung wirklich ständig ohne Lags funktioniert, gebt doch bitte mal Rückmeldung, was dazu nötig war.
-c't Anleitung (bin nicht soweit gekommen, ich vermute aber mal, dass auch das nichts bringt bei UniFi Wifi's):
+c't Anleitung (bin nicht soweit gekommen ["broken pipe" --> "hammer up, broken raspberry"], ich vermute aber mal, dass auch das nichts bringt bei UniFi Wifi's):
 <pre>
 sudo su
@@ Zeile 25: / Zeile 27: @@
 reboot
 </pre>

← Nächstältere Version		Version vom 14. Mai 2025, 16:54 Uhr
Zeile 12:		Zeile 12:
	* Wifi ist aber nicht zu gebrauchen, weil es die Verbindung immer nur für wenige Sekunden erlaubt, dann aber für mehr als 30(!) Sekunden nicht ansprechbar ist.		* Wifi ist aber nicht zu gebrauchen, weil es die Verbindung immer nur für wenige Sekunden erlaubt, dann aber für mehr als 30(!) Sekunden nicht ansprechbar ist.

−	==> Ich hab alles mögliche probiert, Wifi-Power-Settings deaktiviert. '''Ich hab nun eine Lösung gefunden: ~~Neht~~ einen Hammer und zerkloppt diese Teile, die euch nutzlos Lebenzeit fressen.'''	+	==> Ich hab alles mögliche probiert, Wifi-Power-Save-Settings deaktiviert. '''Ich hab nun eine Lösung gefunden: Nehmt einen Hammer und zerkloppt diese Teile, die euch nutzlos Lebenzeit fressen.'''
		+
		+
		+	In der c't habe ich einen Hinweis gefunden, vielleicht liegt es auch nur am Schreibschutz des Root-Filesystems. Als ich die Befehle allerdings eingeben wollte, gab es wieder Verbindungsabbrüche - so stark, dass es sogar "broken pipe" gab. Das gab dann "broken raspi"... Solltet ihr es wirklich schaffen, einen Raspberry Pi Zero W so in ein UniFi-Wifi zu bringen, dass die SSH-Verbindung wirklich ständig ohne Lags funktioniert, gebt doch bitte mal Rückmeldung, was dazu nötig war.
		+
		+	c't Anleitung (bin nicht soweit gekommen, ich vermute aber mal, dass auch das nichts bringt bei UniFi Wifi's):
		+	<pre>
		+	sudo su
		+	mount -o remount,rw
		+	echo "post-up" iw wlan0 set power_save off" >> /etc/network/interfaces
		+	mount -o remount,ro
		+	reboot
		+	</pre>