Re: Raspberry Pi+Fhem+FHZ1300 = Crash :(

[Markus01]

Hallo,

ich habe bis vor einiger Zeit FHEM auf einem Debian-Notebook-Server mit dem FHT1300PC betrieben. Nachdem das System nicht mehr funktionierte und mir damals die Zeit zum neu Aufsetzen des Systems fehlte, bin ich vor Kurzem auf den Raspberry Pi aufmerksam geworden und habe mir mal wieder die Zeit genommen.

Ich habe jetzt allerdings das selbe Problem wie im folgenden Beitrag in der FHEM-GoogleGroup beschrieben:
https://groups.google.com/d/topic/fhem-users/6rhaLoqP1sk/discussion

Da es bisher kein Update zu diesem Thema gibt, frage ich hier mal in die Runde, ob es für die FTDI-Unterstützung in der Zwischenzeit eine Lösung gibt.

Falls nicht: Was ist der Unterschied zwischen der Lösung mit COC und CUL?

Danke schon mal für die Antworten!

[Dr. Boris Neubert]

Da es bisher kein Update zu diesem Thema gibt, frage ich hier mal in die Runde, ob es für die FTDI-Unterstützung in der Zwischenzeit eine Lösung gibt.

Bügel mal mit rpi-update den neuesten Kernel auf den  Raspberry. Vielleicht hilft's.

Grüße
Boris

[AitschPi]

...
Falls nicht: Was ist der Unterschied zwischen der Lösung mit COC und CUL?

Der CUL ist ein USB-Stick, muss also an einen USB-Port eines Rechners oder irgendwie über einen Netzwerk-USB(Host)-Adapter an das System angebunden werden. Der CUL ist damit sehr flexibel, ob am PI, der Fritzbox, einem PC, NAS,...

Der COC ist eine Entwicklung diekt für den RaspberryPi. Der COC ist eine Steckkarte und nutzt den internen Bus (GPIO) des Pi. Damit läßt der sich optimal in ein Gehäuse vom Pi mit integrieren und ist genau auf den Pi abgestimmt. Aber es kann eben nicht mal schnell hier oder da mit rangesteckt werden.

(Ich selber nutze das COC-Modul mit meinem Pi für den 865MHz-Bereich, für den 433MHz-Bereich habe ich mir dann den RFXtrx433 von RFXCOM zugelegt, der hängt dann am USB des Pi. Beide Module arbeiten sehr gut und auch sehr gut zusammen.)

[CrayT3E]

und wenn du FS20 und Homematik Produkte zusammen funktionieren benutzen willst, brauchst du nochmal n CUL 868

[Markus01]

Moin und Danke für die bisherigen Antworten!

Das Kernel-Update mit rpi-update habe ich durchgeführt, doch leider passiert immer noch der gleiche Effekt.

Sobald der FHZ1300PC per USB angeschlossen wurde, finden sich folgende Einträge in dmesg:

Code Auswählen Erweitern


[  206.618860] usb 1-1.3.4: new full-speed USB device number 6 using dwc_otg
[  206.724878] usb 1-1.3.4: New USB device found, idVendor=0403, idProduct=e0e8
[  206.724907] usb 1-1.3.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  206.724921] usb 1-1.3.4: Product: ELV FHZ 1300 PC
[  206.724933] usb 1-1.3.4: Manufacturer: ELV AG
[  206.724945] usb 1-1.3.4: SerialNumber: EL3HRN3J
[  206.781622] usbcore: registered new interface driver usbserial
[  206.783387] usbcore: registered new interface driver usbserial_generic
[  206.783554] USB Serial support registered for generic
[  206.783590] usbserial: USB Serial Driver core
[  206.798289] usbcore: registered new interface driver ftdi_sio
[  206.801137] USB Serial support registered for FTDI USB Serial Device
[  206.801941] ftdi_sio 1-1.3.4:1.0: FTDI USB Serial Device converter detected
[  206.802622] usb 1-1.3.4: Detected FT8U232AM
[  206.802651] usb 1-1.3.4: Number of endpoints 2
[  206.802667] usb 1-1.3.4: Endpoint 1 MaxPacketSize 64
[  206.802680] usb 1-1.3.4: Endpoint 2 MaxPacketSize 64
[  206.802693] usb 1-1.3.4: Setting MaxPacketSize 64
[  206.802952] ftdi_sio ttyUSB0: Unable to read latency timer: -32
[  206.803164] ftdi_sio ttyUSB0: Unable to write latency timer: -32
[  206.803846] usb 1-1.3.4: FTDI USB Serial Device converter now attached to ttyUSB0
[  206.803962] ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver


In der Konfigurationsdatei fhem.cfg wurde folgende Zeile eingefügt bzw. das #-Zeichen entfernt:

Code Auswählen Erweitern


define FHZ FHZ /dev/ttyUSB0


Beim neu laden der Konfiguration mit rereadcfg bleibt das System sofort stehen. Hier hilft nur noch Strom weg - Strom dran und vorher den FHZ1300PC vom USB trennen.

Jemand eine Idee woran es liegen könnte?

[TL]

Moin!

Ich habe eine Lösung gefunden, seit Mitternacht läuft FHEM auf meine RPi mit angeschlossenem FHZ_1300 und loggt fröhlich Daten...

Ich habe in der Datei /boot/cmdline.txt den Parameter "dwc_otg.speed=1" zusätzlich mit eingebaut. Nach einem reboot hat dann alles funktioniert. Der Parameter setzt die Geschwindigkeit für den USB-Bus hart auf 12MBit (USB 1.1). Offenbar ist der RPi sonst "überfordert". Wenn man - wie ich - am USB-Anschluss des RPi außer der FHZ_1300 keine weiteren Devices betreibt, dann ist das offenbar kein Problem.

Gruß,
 TL

[Markus01]

Hallo TL,

Danke für Deine Antwort, die allerdings bei mir nicht zum Erfolg führte :(
Ich werde wohl auf den CUL umsteigen und das FHZ1300PC verkaufen ...

Gruß,
Markus

[TL]

Moin Markus,

ich hatte den ganzen RPi nochmal neu aufgesetzt mit dem neuesten Debian-Image von Ende 2012. Außerdem scheint wohl auch eine sehr(!) gute Stromversorgung wichtig zu sein - ich habe ein 5V,1A Netzteil für den RPi spendiert.

Aber ich habe auch inzwischen gesehen, daß der RPi sich trotzdem sporadisch mal aufhängt. :-( Daher habe ich ihn an meine Netzwerkfähige Steckdose gehängt, die auch einen Watchdog beinhaltet. Damit wird der RPi alle paar Sekunden von der Steckdose angepingt und durch Aus- und Einschalten der Stromversorgung sehr schnell wieder hochgefahren, wenn das passiert. Möglicherweise wird das mit dem RPi also bei mir auch keine Dauerlösung sein... Schade eigentlich, denn es ist wirklich sehr elegant.

Gruß,
 TL

[Dr. Boris Neubert]

Aber ich habe auch inzwischen gesehen, daß der RPi sich trotzdem sporadisch mal aufhängt.

Ich hatte das Problem auch mit einem pl2303-seriell-Usb-Adapter. Mit einem Kernel-Update (rpi-update) konnte ich es zuverlässig lösen.

Viele Grüße
Boris

[Prof. Dr. Peter Henning]

Das Aufhängen des RPi ist ein bekanntes Problem - und wird tatsächlich auch durch den USB ausgelöst. Allerdings hat das noch niemand wirklich in den Griff bekommen, passiert auch mit neuem Kernel immer noch.

Ich überwache meinen RPi durch den eingebauten Hardware-Watchdog, das Ding fährt damit innerhalb von wenigen Sekunden wieder hoch wenn z.B. das Netz steht. Ich habe derzeit eine Idee in Arbeit, die auch FHEM durch diesen Watchdog überwacht. Und dann ein Skript aufruft, dass mit Hilfe einer einfach Heuristik entscheidet, was zu tun ist:
- COC-Neustart
- USB-neustart
- FHEM-Neustart
- Vollständiger Reboot

Von einem externen Watchdog, der die Stromversorgung bedient, kann ich abraten: Das birgt die erhebliche Gefahr, dass die SD-Karte korrumpiert wird.

LG

pah

[TL]

Moin!

Für mich sieht das "Aufhängen" des RPi nach einem vollständigen Systemstillstand aus - keine Reaktion mehr auf Tastatur oder Netzwerk, keine Ausgaben mehr in Logfiles oder auf dem Bildschirm... Falls der Crash also das Filesystem oder sogar die Metadaten der "Festplatte" aka SD-Karte selbst beschädigt hat, ist es wahrscheinlich schon vor dem Stromausschalten passiert. Oder irre ich mich da?

Gruß,
 TL

[Prof. Dr. Peter Henning]

Darauf würde ich nicht wetten. Denn selbst wenn 80% der Prozesse hängen, kann der Schreibvorgang auf die Karte noch im Gange sein. Und wenn dann die Versorgungsspannung weg ist, zerhaut es eben das Dateisystem.

LG

pah

[TL]

Hallo pah,

ich gebe Dir prinzipiell recht.

Ich gehe das "Risiko" aber ein, aus folgenden Gründen:

1) Mein Watchdog schaltet die Steckdose weg, wenn 3 pings hintereinander fehlschlagen. Die pings kommen in 3s Abstand, der timeout beträgt jeweils 9s. Also frühestens 15s nach dem ersten ping, der nicht zurückkommt, wird der Strom abgeschaltet. Bei den geringen Datenmengen, die das FHEM schreibt, gehe ich davon aus, das jede Dateioperation in dieser Zeit beendet werden kann.

2) Selbst wenn das nicht reicht - ich habe extrem selten erlebt, daß ein Journaling Filesystem tatsächlich richtig "kaputt" gegangen wäre, solange es keine Bugs in der Implementierung gab - normalerweise sind die wirklich sehr robust. (Und ich bin in der Branche tätig, habe mit sehr großen Filesystemen mit richtig viel I/O zu tun ;-) )

Eine 100%ige Garantie gibt es natürlich nie, das muß dann jeder selbst entscheiden.

Viele Grüße,
 TL

[thoweiss]

Hallo zusammen,

ich habe gestern einmal versucht mein HS485PCI Interface für meinen HS485-Bus von ELV am Raspbery Pi zum laufen zu bringen.

Leider wurde daraus nix - sobald FHEM das Interface initialisieren will - friert das System komplett ein.

Das HS485PCI hat einen FTDI FT232BM USB-> Seriell Wander eingebaut.

Der läuft mit dem Raspberry PI Kernel nicht (Kernelversion 3.6xx)

Ich werde die Kiste mal öffnen und mir anschauen ob ich den FTDI-Chip evtl gegen einen ander Chip tauschen kann.

Der FT232R soll angeblich gut am Pi funktionieren:

Mal sehen ob das klappt....

[thoweiss]

So ich habe jetzt mal meinen USB mit dem Parameter "dwc_otg.speed=1" auf USB1.1 gesetzt -
und oh Wunder dann läuft auch mein HS485PCI...

Ist natürlich eine extreme Performance-Bremse - aber als Übergangslösung gehts erstmal...