Stabilisierung von RaspBerry Pi + COC

[Guest]

Originally posted by: <email address deleted>

Ich kämpfe, wie andere auch, mit dem Problem des immer noch instabilen
Raspberry Pi. Ich denke, dass eine kurze Zusammenfassung in einem neuen
Thread sinnvoll ist.

Erstens gibt es noch Ungereimtheiten bei der Hardware:
Ich betreibe einen COC mit Firmware 1.47, der COC behauptet, den
"Boot"-Befehl B nicht zu kennen - andere Forumsteilnehmer melden die
gleiche Firmware, aber einen funktionierenden B-Befehl.

Zweitens verschwndet der COC ab und zu ins Nirwana, meldet "Unknown
messages" direkt aus der Firmware. Es wäre schön, wenn der "B"-Befehl
funktionieren würde - dann könnte man den COC bei diesem Vorkommis auf
einfache Weise zurücksetzen. Derzeit keine Lösung in Sicht.

Drittens: Der Raspberry Pi hat selbst Probleme.

A:Offenbar hat der USB-Protokollstack irgendwelche Probleme. Und zwar
insbesondere dann, wenn man die neuesten Linux-Releases für den RPi
verwendet (  Nicht etwa, dass er dann ganz abstürzt - nein, nur das
Netzwerk stirbt. Sehr seltsame Nebenwirkung, das Problem ist aber bekannt
und wird in den entsprechenden Foren auch diskutiert. Ein workaround ist,
in die Datei /boot/cmdline.txt den Bootparameter

 dwc_otg.fiq_fix_enable=0

einzufügen. Bei mir hat das jedenfalls die gelegentlichen Abstürze des
Ethernet-Interface verhindert, das läuft also stabil.

B: Mein Betriebssystem befindet sich auf einer SD-Karte, die FHEM-Logfiles
lasse ich aber auf einen Mikro-USB-Stick schreiben. Diese Trennung hat sich
bewährt, weil beim Schreiben ab und zu Dateisystemfehler entstehen. Auf
FAT-Dateisystemen lassen diese sich in der Regel nur mit Datenverlust
beheben. Zu empfehlen ist deshalb, den Mikro-USB-Stick mit einem
ext4-Filesystem zu formatieren, bevor man ihn mountet. Das sorgt dafür,
dass Fehler sehr viel sicherer und meist ohne Datenverlust behoben werden
können.

C: Natürlich muss man auf dem RPi auch den Hardware-Watchdog laufen lassen,
damit die Kiste von selbst rebootet, wenn sie ganz hängt.

Insgesamt ergibt sich damit ein zufriedenstellendes Bild: Am RPi habe ich
derzeit laufen
- COC, daran fest 2 1-Wire devices
- USB-1-Wire Interface (ca. 10 m USB-Kabel) mit derzeit 4 1-Wire devices
- USB-Seriell Interface an Fotovoltaikanlage
- CUL mit abgesetzter Antenne
- CUNO via Netzwerk, daran variabel bis zu 8 1-Wire devices.

Alle paar Tage mal ein automatischer Reboot - aber sonst bestens und ohne
Aussetzer.

LG

pah

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[tostmann]

                                                 

Am 10.11.2012 um 16:14 schrieb Prof. Dr. Peter A. Henning:

> Erstens gibt es noch Ungereimtheiten bei der Hardware:
> Ich betreibe einen COC mit Firmware 1.47, der COC behauptet, den "Boot"-Befehl B nicht zu kennen - andere Forumsteilnehmer melden die gleiche Firmware, aber einen funktionierenden B-Befehl.

... diese lässt sich einfach erklären. B wurde im aktuellen HEAD Ende September entfernt, da COC per GPIO-Lines in den Bootloadermodus gebracht werden soll nicht per B - siehe Commit:

http://culfw.svn.sourceforge.net/viewvc/culfw?revision=316&view=revision

Da immer noch HEAD == 1.47 und COCs bei Auslieferung mit HEAD geflashed werden ist das unterschiedliche Verhalten möglich. Ein:

hexdump -C /sys/bus/i2c/devices/0-0050/eeprom
gibt auch den Tag des Flashens aus. Liegt das vor dem 26Nov gibt's halt noch ein "B" aber selbst das funktioniert nicht, daher wurde es entfernt.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[tostmann]

                                                 

Am 10.11.2012 um 16:14 schrieb Prof. Dr. Peter A. Henning:

> Zweitens verschwndet der COC ab und zu ins Nirwana, meldet "Unknown messages" direkt aus der Firmware. Es wäre schön, wenn der "B"-Befehl funktionieren würde - dann könnte man den COC bei diesem Vorkommis auf einfache Weise zurücksetzen. Derzeit keine Lösung in Sicht.

Kleiner Nachtrag:

Ein Reboot des COC wird, wie auf der Wiki-Seite beschrieben, durch:

echo "resetting 868MHz extension..."
if test ! -d /sys/class/gpio/gpio17; then echo 17 > /sys/class/gpio/export; fi
if test ! -d /sys/class/gpio/gpio18; then echo 18 > /sys/class/gpio/export; fi
echo out > /sys/class/gpio/gpio17/direction
echo out > /sys/class/gpio/gpio18/direction
echo 1 > /sys/class/gpio/gpio18/value
echo 0 > /sys/class/gpio/gpio17/value
sleep 1
echo 1 > /sys/class/gpio/gpio17/value
sleep 1

erreicht. Das kann man noch Kürzen, aber so ist es am Sichersten!

Das "Unknown messages" Problem ließe sich zudem direkt in FHEM lösen, da culfw alle Nachrichten mit LF abschliesst (im Gegensatz zu FHZ-Devices) kann man einfach in einem solchen Falle bis LF den Puffer leer lesen.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Gut, erledigt - der Kollege hat also nicht die aktuelle FW.

Danke

pah

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Äh, mein Fehler, sorry. Ich habe mich ungenau ausgedrückt: Natürlich
funktioniert diese Art des Bootens, so wie schon in einem anderen Thread
beschrieben. Schöner wäre es, den COC direkt booten zu können.

Und "keine Lösung in Sicht" bezog sich nicht auf das Booten, auch das war
missverständlich ausgedrückt. Sondern auf das Verschwinden im Nirwana.

LG

pah

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[tostmann]

                                                 

Am 10.11.2012 um 16:14 schrieb Prof. Dr. Peter A. Henning:

> nein, nur das Netzwerk stirbt

TuxRadios nutzen auch den LN9512 Chip für Ethernet/USB - dort hat sich das Erhöhen von:

vm.min_free_kbytes = 16384

in /etc/sysctl.conf sehr bewährt - beim RPi steht da noch die 8192 ...

Zum Anderen fände ich es beim Pi sinnvoll den Swap in eine separate Partition zu legen ...

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Swap geht schon in eine separate Partition. Das mit den 16384 werd ich mal
ausprobieren - war in den ganzen RPi-Foren nirgendwo zu finden.

LG

pah

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[tostmann]

                                                 

Am 10.11.2012 um 17:48 schrieb Prof. Dr. Peter A. Henning:

> Swap geht schon in eine separate Partition

Aber nicht per Default, da wird dphys-swapfile verwendet, der im eigentlichen Root-fs liegt ... => /var/swap

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Das ist sicher richtig, aber ich habe es auf eine separate Partition gelegt.

pah

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[det.]

                                                 

Hallo die Herren,

schön zu lesen, dass die Fehlersuche auf dem Weg zu einem stabilen RasPi mit COC und vieleicht auch letztendlich einer funktionierenden 1-wire Funktion des COC voll im Gange ist.
Mein RasPi lief im fhem2fhem Modus und alle FS20, FHT und KS300 Sachen mitloggend zuletzt 7 Tage ohne reboot, mit einem DS1820 am COC - bis ich den DS1820 testweise durch einen DS2406 ersetzt habe - mit Aktualisierungszeit von 10 anstatt 300. Das ging vieleicht 2-3 h gut, dann ging 1-wire PRESENT 0 und FS20 Geräte ließen sich über Webinterface FHEM auf RasPi auch nicht mehr schalten.
Zu den Tips oben im Post - über die Änderung der swap Einstellung liest man im Netz nichts wirkich Gutes - z.B. hier: http://raspberrypi.stackexchange.com/questions/70/how-to-set-up-swap-space
Was ist davon zu halten - bzw. gibt es eine Empfehlung (Hardware Swap Speichermedium und Kurzanleitung)?
Die anderen Sachen werde ich jetzt mal umsetzen und weitertesten.
lg det.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Nur 10 Sekunden Abfrageintervall setzen den COC echt unter Stress - und den
mag er offenbar nicht.

Für mich stellt sich allmählich die Frage, ob der Prozessor auf dem COC
nicht etwas überfordert ist. Auch beim CUNO klappt es noch nicht sehr gut
mit vielen 1-Wire Devices und schnellen Abfragen. Es macht wahrscheinlich
Sinn, eine reine 1-Wire Erweiterung für den RPi zu entwickeln, oder den
1-Wire Anschluss über den USB-Port des RPi zu verwirklichen.

LG

pah


--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[det.]

                                                 

Genau das war ja auch der Stresstest, nach dem das Ding so lange durchgehalten hatte... Das Device aus DS2406 und Sharp SSR werkelt inzwischen auf dem Boden und steuert die Warmwasserumwälzpumpe anstelle eines FS20 Funkschalters, der 2te Kanal überwacht den Druck im Heizkreislauf. Das alles funktioniert mit OWX absolut stabil, nur eben nicht auf dem RasPi.
Die Teile für den 2ten USB 1-wire Adapter mit DS2480 sind auf dem Weg mit Hongkong Post. Wenn der zusammengelötet ist, geht der Stresstest für den RasPi in eine neue Runde. Schauen wir mal...
lg det.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Ich habe die Teile für einen weiteren USB-Adapter schon, muss aber noch die
Zeit finden ...

Meine diversen Teile am USB des Raspberry Pi hängen übrigens inzwischen an
drei Hubs - ohne Probleme.

LG

pah

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Mal so, ne dumme Frage:
Der Adapter für 1-Wire sitzt doch beim COC auf dem konkurierenden I2C von
der RasPi, ist vielleicht der I2C ein Problem?
Ich habe ja schon öfters mit 1-wire gebastelt und bin bisher nicht in diese
Art von Probleme geraten, deshalb habe ich mich gefragt was hier anders ist
als bei meinen anderen "Projekten".
Ich hatte bisher WRT54 mit passiven Adapter zu 1-wire, lief mit vielen
DS1820 problemlos.
Hatte Arduino mit 1-wire, dort gabs hin und wieder hänger weil im Treiber
nicht lange genug auf die Antwort gewartet wurde --> festgehen der
Applikation auf Arduino, bei WD neustart (sieht ähnlich aus beim COC)
Etherape mit ECMD, bisher keine Probleme beim 1-wire, nur beim
ECMD-Protokoll ständig irgendwelche hänger.

Deshalb war ich ja glücklich das jemand 1-wire mit CUNO/COC nativ umgesetzt
hat.

Vielleicht findet ja jemand Zeit und guckt in die CULFW-Quellen der mehr
als ich davon versteht.

Weiter könnte ein Umbau des COC und nutzung des UART1 zum 1-wire Adapter am
1284p vielleicht was nutzen, da ist man weg vom I2C...

Nur malk so ein paar Gedanken von mir...

Gruß
VT


Am Montag, 12. November 2012 07:53:54 UTC+1 schrieb Prof. Dr. Peter A.
Henning:
>
> Ich habe die Teile für einen weiteren USB-Adapter schon, muss aber noch
> die Zeit finden ...
>
> Meine diversen Teile am USB des Raspberry Pi hängen übrigens inzwischen an
> drei Hubs - ohne Probleme.
>
> LG
>
> pah
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

I have 8 DS18B20 one-wire and 10 FHT80B on my COC

Everything works well for about three hours and then a reset and reboot is
required (using set COC raw B00 which works on my COC - revision 316?) It
does look from the logs as if it is the one-wire devices that are causing
the problems. My next step is to replace the PSU with a VERY expensive 5v
PSU  (cheap on eBay ! ) to see if that helps. After that I will try
disconnecting the one-wire bus to see how that works.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com