Raspberry Pi und COC - inzwischen ratlos

[kawa0815]

Du sprichst sicher über die COC.radio_only.hex. Ich habe aber die COC.hex und diese vom SVN Server.

kawa

[rammelsberg]

Hallo!

Ich hatte das gleiche Problem, mit dem "älteren" busware image auf der mitgelieferten SD Karte ging alles, dann update von debian und fhem gemacht und der COC war tot.
Flashen mit dem Busware image (full featured) funktioniert, i2c geht auch, aber die LED ist tot.
Neues Netzteil probiert, alle installationshinweise (kernel, tty Ausgaben...) beachtet, kein Erfolg.
Dann die von Jörg beschriebene alte FW vom COC installiert und die LED blinkt wieder, COC wird auch gefunden.
Ich hätte den Beitrag fast überlesen... ;-)

Super Forum!!!

Grüße,
Paul

[cerberus]

Hallo, ich habe auch gerade versucht auf die Version 1.57 zu flashen, allerdings funktioniert das COC danach nicht mehr. Diese neue Version ist erheblich größer als Version 1.55 , vielleicht liegt es daran. Ich bin auf Version 1.55 zurück und siehe da, es funktioniert wieder.

Gruß
cerberus

[nilven]

Hi,

schaut ruhig hier mal rein. Bei meinem COC regt sich nach sämtlichen Versionen nichts mehr, nur nach der COC_1.54, die dort angehangen ist (COC+ OneWire).

Grüße Ronny

[svenomatt]

2. Nach frustranen Versuchen mit der aktuellsten Firmware die ich über http://sourceforge.net/p/culfw/code/392/tree/ heruntergeladen habe, habe ich die Firmware aus dem Archiv http://culfw.de/culfw-1.55.tar.gz genommen. Und siehe da, es funktionierte sofort. Die aktuellste Firmware scheint also nicht zu funktionieren.

Hallo Leute,

bin ganz neu ihr, stehte seit einigen Tagen vor dem selben Problem wie Jörg, jedoch kann ich mit der Anleitung (Zitat) noch nicht richtig etwas anfangen

einfach http://culfw.de/culfw-1.55.tar.gz herunterladen, entpacken

und dann....

auch wenn die Frage idiotisch Klingel ich befasse mich erst seit kurzem mit dem COC


Ich bin für jede Hilfe dankbar.

[JoWiemann]

Hallo Zusammen,

Ausgangssituation:
- RPi mit COC aus einer der ersten Auslieferungen von busware
-  Hardware    : BCM2708
   Revision      : 0004
   Serial          : 000000001054ebcc

Heute auf Version 1.57 aus dem Trunk geflasht
-> COC wird nicht mehr angesprochen
-> Fehlermeldung im Log:
     - Opening COC device /dev/ttyAMA0
     - Setting COC baudrate to 38400
     - COC device opened
     - Cannot init /dev/ttyAMA0, ignoring it

Downgrade auf 1.55 aus Tags
-> selbe Situation wie 1.57

Sidegrade auf 1.55. von culw Homepage aus dem tar-file
-> wieder alles Ok

Und nun die Lösung:

Lädt man mit wget ohne die Ergänzung format=raw das hex-file runter, dann erhält man einen html-Header als Vorspann, der dann mitgeflasht wird und das gibt einfach murks.

Ich lade jetzt mit

Code Auswählen Erweitern

sudo wget http://sourceforge.net/p/culfw/code/HEAD/tree/trunk/culfw/Devices/COC/COC.hex?format=raw  -O /tmp/COC.hex

das hex-file herunter und schon funktionierts wieder.

Grüße Jörg

[cerberus]

Danke Jörg, es funktioniert so wie du es hier geschrieben hast.

Danke dir und Gruß
cerberus

[BastianW]

update von debian und fhem gemacht und der COC war tot.

Ich bin jetzt nicht der Linux krack ... aber ich befürchte mit dem update von debian wirst du den kernel geupdated haben... der im Busware image ist von ihnen speziell angepasst ...

[stoxx]

Hallo !!
Ich bin seit gestern ebenfalls stolzer Besitzer eines COC, habe aber leider - wie viele andere offenbar auch-  Probleme, das Teil zum laufen zu bringen.
1. Versuch:  SD Image von Busware ausprobiert. Ergebnis: Raspberry bootet nicht mehr.
2. Versuch:  Auf 2014-01-07-wheezy das neueste FHEM installiert und Busware Anleitung befolgt. Ergebnis: Bis zur Installation des "pre-compiled kernel" funktioniert auch alles ; aber genau nach diesem Schritt bootet der Raspberry wieder nicht mehr 

In diesem Forum habe ich schon ein paar Hinweise gefunden, das es an der Kompatibilität von COC-version und Raspberry liegen könnte: Ich habe einen Raspberry B, 512 MB und COC V1.2.
Da hier viele Experten unterwegs sind hoffe ich als blutiger Anfänger auf Hilfe !!!

Viele Grüße
stoxx

[chris1284]

Evtl hilft dier dies

http://forum.fhem.de/index.php/topic,18690.msg124755.html#msg124755

[stoxx]

Danke für den Tipp! Allerdings wird in dieser Beschreibung das SD Image von Busware verwendet. Wenn ich dieses verwende, startet mein Raspberry nicht mehr.  Alle anderen Einstellungen sind genauso wie dort beschrieben.
Momentan erhalte ich, wenn ich
hexdump -C /sys/bus/i2c/devices/0-0050/eeprom
eingebe, die Fehlermeldung:
hexdump: /sys/bus/i2c/devices/0-0050/eeprom: No such file or directory

Liegt aber wahrscheinlich daran, dass der Kernel noch nicht angepasst ist...
Gibt es denn jetzt nur noch die Möglichkeit, einen alten Raspberry Pi zu kaufen in der Hoffnung, dass dieser dann mit dem COC zusammenarbeitet? 

[d0np3p3]

Ich habe das Problem auch mit dem Image von Busware, ich benutze weiterhin das "alte" Image,
da läuft es noch.

[chris1284]

Das alte Image bzw die Kernelpatches werden mit dem aktuellen Rasbian-Image 2014-01-07 http://www.raspberrypi.org/downloads nicht mehr benötigt!

Hier die offizielle Aussage von Busware

Die Komponenten RTC und EEPROM werden mittlerweile vom Rasbian direkt unterstützt, sodass keine Patches nötig sind.
Die Kommunikation mit dem Co-Prozessor läuft seriell, nach setzen der beschriebenen GPIOs.

Bei mir läuft das aktuelle Image vom Link oben mit diesen Anpassungen:

"Start" -Sektion von  /etc/init.d/fhem bearbeiten ("nano /etc/init.d/fhem" ausführen)

Code Auswählen Erweitern


'start')
        echo "Resetting / booting COC (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
        echo "Starting fhem..."
        perl fhem.pl fhem.cfg
        RETVAL=$?
        ;;

To free-up the serial line used by COC remove any references to ttyAMA0 in:

    /etc/inittab - comment or delete: T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100
and
    /boot/cmdline.txt - and reboot!

für RTC

empty (#) or delete /etc/modprobe.d/raspi-blacklist.conf

insert  in  etc/rc.local above the exit0 line:

modprobe i2c-bcm2708
echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device  <---- ic2-1 für Modell B, ic2-0 für Modell A wen ich richtige liege
modprobe rtc-ds1307
hwclock -s

EEPROM nutze ich nicht, laut Aussage Busware sonst auch niemand wirklich, also ist es zu vernachlässigen (die HW-Clock eigentlich auch da der PI mit aktuellem Image eine Fake-HW-Clock hat)

Bei bedarf poste ich gerne meine Notizen für die Installation (bin selbst nicht sooo der Linuxer) die ich mir so gemacht habe und nach denen ich den PI durch spielereien schonmehrmals aufgesetzt habe und immer wieder den COC sofort nutzen konnte in FHEM.

[stoxx]

Habe die Lösung gefunden!!!
http://blog.rogiervandenberg.nl/2013/05/how-to-fix-boot-problems-with-hynix.html

Neues "bootcode.bin" und die "start.elf" auf das Image von Busware kopiert bzw. dort überschrieben und schon bootet das Teil tadellos! 

[stoxx]

Jetzt komme ich leider bei FHEM nicht weiter. Im Log-File steht:

2014.01.19 16:30:34 3: COC device opened
2014.01.19 16:30:43 1: Cannot init /dev/ttyAMA0, ignoring it

Habe zuvor ein Update von FHEM gemacht; kann das vielleicht eine Rolle spielen?