Raspberry Pi + COC und RFXTRX433 abstürze

Begonnen von duese, 06 März 2013, 07:55:59

Vorheriges Thema - Nächstes Thema

duese

Hallo zusammen,

habe schon hin und her überlegt in welche Rubrik ich posten soll und ob ich vielleicht bereits eine Info finde.
Ich habe folgendes Problem. Mein RPi mit COC inc. 1-Wire Erweiterung, allerdings 1-wire unbenutzt. Läuft an sich soweit stabil auch wenn ich die CUL433 anstecke. Wenn ich jedoch den RFXTRX433 anhänge, läuft es für kurze Zeit und stürzt mir dann nach einiger Zeit ab und ist nicht mehr erreichbar.
Ich möchte gerne von meiner FritzBox7390 die USB Komponenten entfernen und über den RPi in Zukunft laufen lassen, die beiden dann mit FHEM2FHEM verbinden (um Telefonfunktionen der Fritz zu integrieren), wobei ich mit FHEM2FHEM auch noch so meine Probleme habe, aber dazu würde ich dann später kommen. Grund für den Umzug auf den RPi ist, das die 7390 im Keller steht und von da der Empfang bis zum Dach nicht besonders erfreuend ist.

Vielleicht hat ja jemand eine Idee woran das ganze liegt und kann mir helfen.

Schöne Grüße
Daniel

Joachim

Moin Daniel,

obs wirklich eine Lösung ist, weiß ich nicht, aber schau Dir mal diesen Tread ab Beitrag #67154 an.

Stichwort Radio only Firmware.
Damit wäre wenigstens der 1-Wire Bereich ausgeschlossen, den Du ja eh nicht nutzt.

Gruß Joachim
FHEM aktuellste Version auf FB 7570 und 7390 mit Zebradem Toolbox Freetz
FHEM auf Raspberry
1-Wire mit LinkUSBi und Rs-Pi ds2482-800  1-Wire-9 Board; Max mit Cube, HMLAN
div. 1-Wire Sensoren; MAX-Thermostaten; Homematic-Komponenten, Zehnder KWL über RS-232

duese

Hallo Joachim,

habe gerade mal grobn durchgeguckt, da geht es aber überwiegent über 1-Wire, wenn ich das richtig verstehe.
Also den RPi und den COC mit 1-Wire habe ich von Busware zusammen mit der fertigen FHEM Karte. Die Version habe ich auf die aktuelle upgedatet. Scheinbar macht das ganze lediglich mit dem RFXTRX433 probleme. Könnte mir auch vorstellen das ganze auf 2 RPi's aufzuteilen mit CUL868, CUL433 und RFXTRX, das ganze dann für Telefonfunktionalität per FHEM2FHEM mit der FB verbinden.
Das 1-Wire mit dem COC Probleme macht hatte ich vor Zeiten schon mal gelesen, benutze ich derzeit jedoch nicht. Hatte mir das beim Kauf des COC als Option jedoch offen gelassen.

Schöne Grüße
Daniel

Joachim

Moin Daniel,

man sollte nicht im Halbschlaf ein Forum bedienen, hatte vergessen den Link anzuhängen.
Hier ist er, auch wenn Du ihn schon gefunden hast.
Link

Worum es mir ging, ist die Tatsache, dass schon im alten google groops Probleme mit dem RPI und Abstürzen gemeldet wurden.
Da ich selbst keinen RPI habe, habe ich die Treads immer nur überflogen.
Was mir im Hinterkopf geblieben ist, ist
- es gib ein Problem im Zusammenspiel mit 1-Wire, da du 1-Wire nicht nutzt wäre es möglich die Radio only Firmware
  zu
  nutzen und diese Fehlerquelle auszuschließen
  Zitat aus #67195
 
ZitatIm COC hängt der DS2482 direkt am I2C des RasPi (Multimaster-Mode, geshared mit dem 1284p CoPro), und hier
  liegt die Chance für das COC-Modul.
  - den Fullfeatured-COC mit der RadioOnly-FW flashen, somit lässt der 1284p die Finger vom DS2482.
  - und dann den RasPi direkt mit dem DS2482 kommunizieren lassen (i2c-libs und Kernel-Module)
 
- es geb Probleme mit dem Netzwerk
  --> Über Watchdog den Raspberry Pi neu Starten wen die Lanverbindug nicht mehr steht.
  --> http://forum.fhem.de/index.php?t=msg&goto=58795&rid=31&srch=rpi+netzwerk#msg_58795

aber es gibt hier garantiert noch Wissende die besser helfen können.

Gruß Joachim
FHEM aktuellste Version auf FB 7570 und 7390 mit Zebradem Toolbox Freetz
FHEM auf Raspberry
1-Wire mit LinkUSBi und Rs-Pi ds2482-800  1-Wire-9 Board; Max mit Cube, HMLAN
div. 1-Wire Sensoren; MAX-Thermostaten; Homematic-Komponenten, Zehnder KWL über RS-232

Prof. Dr. Peter Henning

Der USB-Stack ist in der Linux-Portierung auf den RaspberryPi unter die Räder gekommen und sorgt für diese Instabilitäten. Das hat mit 1-Wire _gar nichts_ zu tun.

Lösungsvorschlag: Kernel-Update. Die neuesten Versionen arbeiten deutlich stabiler. Bei mir bedient ein RPi inzwischen drei verschiedene 1-Wire-Interfaces (über USB...) und einen weiteres USB/Seriell-Konverter. Ca. 1x pro Tag ins Nirwana, dank Watchdog aber innerhalb kürzester Zeit rebootet, so dass man das nahezu gar nicht merkt.

LG

pah

duese

Mit der CUL433 läuft es jetzt schon länger stabil, meinst du nach einem Kernelupdate bekomme ich auch den RFXTRX433 stabil ans laufen? Da ich mit dem RPi noch etwas unerfahren bin, weiß ich nicht genau, wie ich ein Kernelupdate angehen soll. Habe wie gesagt FHEM fertig auf der SD bekommen, habe höchstens mal auf einem weiteren RPi debian aufgespielt.

Willi

Stabilitätsprobleme können beim Pi verschiedene Ursachen Haben:
- Netzteil zu schwach, und/oder
- Probleme mit dem Kernel (USB)

Ich vermute Du setzt die Distribution von Busware ein und nicht die normale Distribution (Rasbian) ein?

Um Probleme mit dem Netzteil auszuschliessen, würde ich testweise alles vom Pi entfernen, was sonst noch so angeschlossen ist, also CUL433 und CoC (abstecken).
Ich vermute mal für CoC und RFXtrx433 gleichzeitig brauchst Du ein 1500 mA oder 2000 mA Netzteil.

Eine Lösung könnte sein, dass Du auf die normale Linux-Distribution (Rasbian) wechselt. Ich weiss allerdings nicht, ob diese CoC unterstützt bzw. was alles zu tun ist, damit CoC damit läuft.
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

duese

Ich werde das mal mit einem USB Hub (natürlich einen Stromversorgten) ausprobieren, damit sollten sich denke ich die Spannungsprobleme ausschließen. Zwar sollte der RFXTRX433 nicht an einem USB Hub funktionieren (laut RFXCOM), an meiner Fritzbox läuft dies über einen Stromversorgten USB Hub jedoch auch. An Spannungsversorgungsprobleme hatte ich auch schon gedacht. RFXCOM gibt vielleicht deswegen an, man solle keinen USB-Hub verwenden, da die von einem nicht Stromversorgten ausgehen. Der RPi ist dabei aufgrunddessen vielleicht ebenso zu sehen. Würde mir zumindest einiges erklären.
Die FHEM Version, die ich verwende ist eine fertige mitgelieferte von Busware.

det.

hallo duese,
habe seit ca 2 Wochen FHEM auf dem RPI mit CUL + RFXTRX + 2 Stück 1-wire DS2480 Adapter (alle 4 gemeinsam an einem aktiven USB Hub) mit Erfolg laufen. Der COC hat zumindest an meinem RPI in längerem Testlauf über viele Wochen nur Probleme gebracht, seit er in der Schublade liegt und durch den CUL ehemals von den FB7390 ersetzt wurde rennt es ohne Beanstandungen. Wenn nicht vor 14 Tagen mein VDSL total ausgefallen wäre und die T-COM zuerst auf eine defekte FB getippt hätte, wäre der Umstieg auf den RPI bei mir wohl ausgefallen.
Da den COC hier im Forum niemand haben wollte, werde ich mir einen weiteren RPI zulegen und das Experiment mit der radio only Firmware des COC nochmal wagen. Vieleicht geht es ja damit besser und ich kann mir noch paar MAX Device zulegen.
Auf der FB habe ich jetzt FHEM ausschließlich wegen der PRESENCE Erkennung der iPhones laufen - mit FHEM2FHEM auf dem RPI - das funktioniert fantastisch.
LG
det.

Willi

Zitat von: duese schrieb am Di, 12 März 2013 15:55Ich werde das mal mit einem USB Hub (natürlich einen Stromversorgten) ausprobieren, damit sollten sich denke ich die Spannungsprobleme ausschließen.

Schau auch mal nach dem Neustart des Pi in /var/log/messages, was für Meldungen dort vor dem Absturz geschrieben wurden.

FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

duese

in /var/log/messages werd ich bei gelegenheit mal reinsehen. Ich bin mir mittlerweile nicht mehr sicher, ob der gesamte Raspberry abschmiert, oder nur FHEM. Gestern habe ich einen USB Hub mit RFXTRX433 sowie CUL433 einmal mit und einmal ohne COC drangehängt. Per SSH war der RPi immer erreichbar nur nicht per FHEM. Werde heute oder morgen mal weitersehen.
Ansonsten zu den beschriebenen COC Problemen, läuft der reine RPi mit COC bei mir ohne Probleme.

Ansonsten steht auf der SD Karte von Busware Raspian (wheezy). Also denke ich das ich bereits Raspian verwende.

Prof. Dr. Peter Henning

Natürlich bedeutet die Erreichbarkeit des RPi, dass nur FHEM "abstürzt". Es ist aber auch noch nicht klar, ob FHEM nur mit sich selber spielt, also auf http requests nicht reagiert, oder wirklich tot ist. Bitte per

/etc/init.d/fhem status

überprüfen.

LG

pah


Prof. Dr. Peter Henning

Ich wäre an dem COC durchaus interessiert, habe nämlich inzwischen drei RPi im Einsatz.
Einer mit 3 USB-1Wire-Adaptern (verteilt auf 3 Stockwerke, geht bestens mit USB-Externdern), einer mit OWFS - und ein dritter zum Basteln. Ich denke nämlich dass man das COC/1-Wire Problem lösen kann.

LG

pah

duese

Ob mit oder ohne COC, glaube der hat damit nichts zu tun. Sobald ich den RFXTRX433 anstecke erreiche ich die ganze schoße nicht mehr.
/etc/init.d/fhem status
fhem is running
Habe den COC nun wieder am RPi , weiterhin habe ich den RFXTRX433 über einen USB-HUB (stromversorgten) angesteckt.
Ohne RFXTRX433 läuft alles stabil, mit RFXTRX433 erreiche ich keine Weboberfläche mehr.

Willi

Zitat von: duese schrieb am Sa, 16 März 2013 15:28Ob mit oder ohne COC, glaube der hat damit nichts zu tun. Sobald ich den RFXTRX433 anstecke erreiche ich die ganze schoße nicht mehr.
/etc/init.d/fhem status
fhem is running
Habe den COC nun wieder am RPi , weiterhin habe ich den RFXTRX433 über einen USB-HUB (stromversorgten) angesteckt.
Ohne RFXTRX433 läuft alles stabil, mit RFXTRX433 erreiche ich keine Weboberfläche mehr.
Kommst Du dann noch per SSH auf den PI oder stürzt dieser komplett ab?
Du könntest mal in /var/log/messages ansehen, ob dort eine Fehlermeldung erscheint bzw. was in fhem.log steht.


FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

Prof. Dr. Peter Henning

Wenn der RFX den Raspberry so beschäftigt, dass FHEM läuft, abernicht mehr erreichbar ist, werden auch keine Einträge im FHEM-Log zu sehen sein.

Log-Einträge wären also m.E. höchstens in /var/log/messages zu finden.

Desweiteren wäre interessant zu wissen, ob das Phänomen unabhängig davon ist, dass FHEM den RFX öffnen will. Der RPi hat schon mehrfach Probleme mit dem USB gehabt - es könnte also durchaus sein, dass schon das Anstecken des RFX dasselbe Verhalten hervorruft, obwohl FHEM mit diesem USB-Port und dem RFX gar nchts am Hut hat.

Relativ einfacher test also.

LG

pah

Markus M.

Das liegt an dem FTDI Treiber für die USB2Serial Ansteuerung.
Den USB Port auf USB 1.1 auszubremsen hilft.

/boot/config.txt
dwc_otg.speed=1 dwc_otg.microframe_schedule=1 dwc_otg.fiq_fix_enable=1 dwc_otg.lpm_enable=0 smsc95xx.turbo_mode=N sdhci-bcm2708.sync_after_dma=0 sdhci-bcm2708.enable_llm=1 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait


ARCH läuft auch sehr viel stabiler als Raspbian.
FHEM dev + HomeBridge + Lenovo Flex15 + HM-CFG-USB + RFXtrx433 + Fritz!Box 7590/7580/546E

HM Aktor/Sensor/Winmatic/Keymatic/Thermostat, HUE, Netatmo Weather/Security/Heating, Xiaomi AirPurifier/Vacuum, Withings Aura/BPM/Cardio/Go/Pulse/Thermo, VSX828, Harmony, Siro ERB15LE
https://paypal.me/mm0

duese

Danke für den Tip, leider hat mittlerweile mein RFXtrx433 auf unerklärliche weise eine Macke und kann irgendwie nur noch empfangen. Habe diesen momentan an einer Fritzbox. Werde es aber bei gelegenheit trotzdem mal testen.
Nehme mal an /boot/config.txt finde ich wenn ich die SD an einen Windoof PC anklemme, oder doch über SSH am RPI???

Gruß
Daniel

Markus M.

Zitat von: duese schrieb am Di, 23 April 2013 08:51Nehme mal an /boot/config.txt finde ich wenn ich die SD an einen Windoof PC anklemme, oder doch über SSH am RPI???

Beides geht (auf der Karte ohne boot/), mit SSH musst du nicht aufstehen ;-)
FHEM dev + HomeBridge + Lenovo Flex15 + HM-CFG-USB + RFXtrx433 + Fritz!Box 7590/7580/546E

HM Aktor/Sensor/Winmatic/Keymatic/Thermostat, HUE, Netatmo Weather/Security/Heating, Xiaomi AirPurifier/Vacuum, Withings Aura/BPM/Cardio/Go/Pulse/Thermo, VSX828, Harmony, Siro ERB15LE
https://paypal.me/mm0