Fehler im System, wie oft müsst ihr ran?

Begonnen von Jogi, 09 Juli 2018, 18:41:16

Vorheriges Thema - Nächstes Thema

sledge

Zitat von: Beta-User am 10 Juli 2018, 10:07:15

Vor allem die ESP8266 waren mir schon immer suspekt, und dem Hörensagen nach haben FritzBoxen auch Probleme, wenn die Zahl der WLAN-Geräte ein gewisses Maß überschreitet. Kann das aus genannten Gründen nicht verifizieren, aber wer seine Infrastruktur so aufbaut, sollte das m.E. ggf. im Auge behalten ;) .

Just my2ct.

Beta-User

Das kann ich (leidgeprüft) nur bestätigen. Ab ca. 15-20 WLAN-Teilnehmern in FHEM und den Smartphones der Familie kam es immer wieder zu WLAN-Problemen mit der Fritzbox.

Ergebnis:


  • LGW fliegt raus ==> Keine Temperaturen mehr, keine PCA301-Funktionalität.
  • WLAN-CUL fliegt raus ==> Kein Homematic mehr

Naja - man kann sich vorstellen, wie die Liste weiter geht.

Meine wesentlichen Änderungen:


  • Umstellung WLAN auf UNIFI => Keinerlei (!!) WLAN-Probleme mehr.
  • CUL Richtung HMUARTLGW migriert / abgelöst: Keinerlei Stress mit Homematic mehr

Mittlerweile ist mein WLAN-Zoo auf >40 Geräte angewachsen (smartbulbs usw) - läuft wunderbar, FHEM wird bei mir zwar regelmäßig aktualisiert, aber ansonsten muss ich da nicht ran. Freezes sind bei Null (gelogen, einer ist noch da, aber den kenn ich schon).

Und: 30 HM, 20 LaCrosse-Thermos, 10 PCA301 Steckdosen, 15-20 Onewire-Geräte (ein Busmaster), 2 LGW, diverse Netzwerkgeräte, 2 MAXCUN und 20 MAX-Fensterkontakte laufen seit den beiden Änderungen störungsfrei. Auf einem Zotac, kein Raspberry.

Vorher hatte ich diverse Watchdogs, notify usw, um den Zustand der diversen Interfaces zu überwachen - bei mir zumindest alles nicht mehr erforderlich.
FHEM: debian Intel-NUC / 25 x MAX!, 15 x HM-bidcos, MQTT, 3 x 1wire, 20 x Shelly, 20 x Tasmota, 12 x Yeelight, Opentherm-GW, Espeasy, alexa-fhem, kodi, unifi, musiccast, ...

connormcl

#16
Kann ich soweit Bestätigen...Ausfallfaktor am Anfang sehr hoch; nach Austausch und/oder Modifikation der Komponenten wurde es besser...
Nun kann ich 2-3 Monate ohne Neustart von FHEM leben.

Problemfelder waren bisher:

- Spannungsversorgung USB-Geräte: durch geeigneten aktiven Hub behoben
- Billig China-Arduino-Nanos: durch Austausch behoben
- LaCrosse Probleme: nanoCUL ungeeignet bei vielen Sensoren; Lösung durch JeeLink
- JeeLink und allgemeine Störstabilität: Lösung durch Ferritkerne um die USB-Leitungen
- Reichweite RFXCOM: durch mehrere Pis mit RFXCOMs behoben; mehrfacher Antennentausch war nicht erfolgreich
- Softwareunterstützung bei HM: mehrere Perl Libraries nicht verfügbar; Lösung durch CCU2 und schliesslich Raspberrymatic
- Stabilität Raspberry PI SD-Karten bei Stromverlust und anderem: Lösung zunächst durch USVs; schliesslich durch Read-Only Filesysteme gelöst
- Stabilität WIFI Raspberry PI als Access Point: Treiber auf ARM fehlerhaft; Lösung durch WIFI Dongles; Suche und Test war langwierig...
- Stabilität und Reichweite Bluetooth Raspberry PI: Lösung durch USB Dongle

Daneben bin ich grad noch dran einen Fallback Layer mittels Intertechno-SMS-Gateway einzuziehen, wenn Remote kein Zugriff mehr geht...

andies

Zitat von: connormcl am 11 Juli 2018, 00:11:40
- Stabilität Raspberry PI SD-Karten bei Stromverlust und anderem: Lösung zunächst durch USVs; schliesslich durch Read-Only Filesysteme gelöst
Kannst du das mal genauer beschreiben?


Gesendet von iPhone mit Tapatalk Pro
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

connormcl

Zitat von: andies am 11 Juli 2018, 06:01:11
Kannst du das mal genauer beschreiben?


Die Filesysteme auf den SD-Karten unterstützen kein Journaling (obwohl teilw. ext4) und können auch kein fsck beim booten. Somit zerschiessen sie sich nach und nach beim nicht sauberen herunterfahren oder bei Stromverlust. Zudem sind die SD-Karten empfindlich, wenn häufig drauf geschrieben wird.

Ich habe also einen USB-Stick mit ext4 und Journalling gemountet und Orte, an denen Dateien geschrieben werden (/var, /udev, ...) dorthin verlinkt. Danach habe ich /root und /boot auf read-only gestellt, so dass dies schon beim booten passiert (ist Distributionsabhängig, entweder über fstab oder Startskripte).

Im laufenden Betrieb bspw.: "mount -o remount,ro /"  für read-only und "mount -o remount,rw /" für read-write auf /
Mit "mount" kannst du noch prüfen, welche Dateisysteme noch auf rw stehen.

Wenn das alles soweit eingerichtet ist, kann man jederzeit den Stromstecker am Pi ziehen, ohne dass etwas passiert. Und die SD-Karte sollte aufgrund der minimierten Schreibvorgänge länger durchhalten.