Hallo zusammen,
ich probiere jetzt schon mehrere Stunden, Raspberry Pi und COC (Radio only) ans Laufen zu bekommen. Inzwischen sehe ich vor lauter Wald die Bäume nicht mehr. Das Forum und Web habe ich auch schon nach Lösungen durchforstet.
Ich habe COC nach Anleitung von Busware installiert. Das Flashen funktioniert immer. Allerdings bekomme ich in FHEM immer die Meldung
2013.08.24 13:07:24 3: Opening COC device /dev/ttyAMA0
2013.08.24 13:07:24 3: Setting COC baudrate to 38400
2013.08.24 13:07:24 3: COC device opened
2013.08.24 13:08:00 1: Cannot init /dev/ttyAMA0, ignoring it
Es leuchtet am COC keine LED beim Booten. Ich habe die Installation auf meine 4 Pi (alle Made in China) probiert, bei keinem hat es funktioniert. Das Busware Image konnte ich nicht testen, da es auf keinem der 4 Pi bootet. Allerdings benötigt man nach meinem Verständnis für Radio only ja auch keinen angepassten Kernel oder?
Gibt es dafür eine Lösung oder ist es immer noch das Kontaktproblem obwohl ich flashen kann?
Ich habe viele Forumseinträge gefunden, aber keine wirkliche Lösung. Ich wäre für Hilfe sehr dankbar.
Jörg
Hast Du das hier berücksichtigt:
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
/boot/cmdline.txt - and reboot!
Ja, ist alles berücksichtigt. Das Flashen klappt ja auch wunderbar, da blinkt dann auch die LED des COC. Da dürfte mi "nicht befreiter Schnittstelle" meines Erachtens auch nicht gehen.
Aber mehr geht halt nicht.
Jörg
Hallo
Hier ein kurzes Update meiner Versuche zu COC und Raspberry Pi:
- Inzwischen ist es mit gelungen auf einem ältere Pi das Busware Image zu booten, leider ist das Symptom identisch. Die COC-Erweiterung kann zwar geflasht, aber nicht von FHEM angesprochen werden.
- Daraufhin habe ich folgendes ausprobiert:
echo "calling COC bootloader..."
if test ! -d /sys/class/gpio/gpio18; then echo 18 > /sys/class/gpio/export; fi
echo out > /sys/class/gpio/gpio18/direction
echo 0 > /sys/class/gpio/gpio18/value
echo 1 > /sys/class/gpio/gpio18/value
also alles was mit gpio17 zu tun hat einfach ausgelassen, Auch so ließ sich die Erweiterung zum geflasht werden bewegen. Ich habe inzwischen das Gefühl, dass gpio17 keine Effekt auf die COC-Erweiterung hat.
Außerdem scheint es Pis zu geben, die nur mit neueren Version von raspbian booten können.
Weiterhin bekomme ich die COC-Erweiterung mit meinen PIs nicht ans laufen.
Jörg
Hallo Jörg,
wenn Du es hin bekommst, den COC zurückzugeben und dafür einen CUL kaufst bist Du spontan jede Menge Frust und Ärger los und hast Platz im RPI für funktionierende Erweiterungsplatinen. Davon gab es hier im Forum schon einige zu kaufen. Wenn Du die Forumsuche mit COC und Problem bemühst siehst Du, wovon ich schreibe
Hallo,
es ist mir dann doch gelungen, mein Problem zu lösen. Hier nun eine Zusammenfassung was ich getan habe:
1. Ich habe insgesamt vier Pis. Zwei davon habe ich vor ca. 4 Wochen gekauft, die anderen vor ca. einem halben Jahr. Die neueren Pi booten mit dem Busware Image nicht. Die älteren lassen sich booten. Mit einem älteren Raspbian "wheezy" booten die neueren Pi ebenfalls nicht. Mit dem aktuellen Image aber sehr wohl.
-> Damit wäre also das erste Problem gelöst. Auf einem älteren Pi lässt sich das busware-Image booten.
2. Nach frustranen Versuchen mit der aktuellsten Firmware die ich über http://sourceforge.net/p/culfw/code/392/tree/ (//sourceforge.net/p/culfw/code/392/tree/) heruntergeladen habe, habe ich die Firmware aus dem Archiv http://culfw.de/culfw-1.55.tar.gz (//culfw.de/culfw-1.55.tar.gz) genommen. Und siehe da, es funktionierte sofort. Die aktuellste Firmware scheint also nicht zu funktionieren.
-> Somit habe ich jetzt eine funktionierende FHEM-Umgebung.
Um anderen Nutzern die oben genannten Problem (vor allem die busware-Image-Nutzung) zu ersparen, wäre es schön, wenn das Image auf eine neuere Release upgedatet würde.
Bis dann...
Jörg
Moin zusammen,
ich hab auch etliche Tage mit meinen 2 China-Pi's rumgeärgert, nachdem ich denn gelesen hatte das die häufig Probleme machen.
Hab ich mir noch eine UK-Version gekauft und siehe da es lief sofort alles ohne Probleme.
Gruß Sven
Hallo Jörg,
könntest Du bitte mal bei den verschiedenen RPi's mit
cat /proc/cpuinfonachschauen, welche Hardwareversionen funktionieren und welche nicht (siehe auch hier (//www.gtkdb.de/index_7_1831.html) bzw. hier (//raspberryalphaomega.org.uk/2013/02/06/automatic-raspberry-pi-board-revision-detection-model-a-b1-and-b2/)), es müsste so etwas herauskommen:
Hardware : BCM2708
Revision : 0002 <--Ich denke, das wäre für alle anderen mit diesem Problem hilfreich.
Danke + Gruß
PeMue
Hallo,
allem mein Pis haben
Hardware : BCM2708
Revision : 000d
Mit zweien funktioniert es, mit den anderen beiden nicht s.o.
Jörg
Hallo Jörg,
danke. Hast Du schon mal diesen Thread (http://forum.fhem.de/index.php?topic=12887.msg86199#msg86199) angeschaut? Ich denke, das könnten Kontaktprobleme sein. Interessant ist nur, dass Made in China und Made in UK dieselbe Hardware Version zeigt. Ich glaube eher, es liegt an den von busware verwendeten Gegensteckern ...
Gruß PeMue
Für die Statistiker:
COC erfolgreich getestet auf:
Hardware : BCM2708
Revision : 0008
Hardware : BCM2708
Revision : 000d
Hardware : BCM2708
Revision : 000f
Hallo,
ich glaube nicht wirklich an Kontaktprobleme. Ich habe gestern mal die Kontakte durchgemessen (Pin des Pis gegen Lötstelle der Steckerleiste) und keine Auffälligkeiten feststellen können. Vielmehr verhalten sich die Pis auf denen es nicht läuft ja auch in anderen Belangen merkwürdig.
Di Pis mit den die COC-Erweiterung funktioniert lassen sich mit älteren Raspbian "wheezy"-, Raspbmc- oder eben auch dem Busware-Image booten. Die Pis auf denen die COC-Erweiterung nicht funktioniert eben nicht. Hier muss ich auf das aktuelle Raspbian "wheezy" oder NOOBS zurückgreifen um booten zu können. Selbst die anschließende Installation des modifizierten Busware-Kernels sorgt dafür, dass nicht gebootet werden kann. Das Problem liegt also wohl eher in einer Inkompatibilität von "COC-Software" bzw. älteren Kernels und neueren Pis. Das Boot-Problem wir auch in anderen Foren diskutiert und auf die SD-Karten geschoben, was ich aber nicht wirklich glauben mag.
Bis dann...
Jörg
Hallo Jörg,
Viele haben wohl Probleme wenn ein Hynix CPU und Speicher verbaut sind, die mit Samsung CPU und Speicher sollen kompatibler sein.
Haben alle 4 Rpi Hynix Speicher ?
Gruß Sven
Ich hatte die gleichen Probleme mit einem COC (voll bestückt) und culfw Version 1.57 und 1.55
Flashen der Firmware funktionierte einwandfrei, allerdings konnte ich das COC - Modul nicht mit fhem zur Arbeit bewegen.
Beim Flashen blinkert die LED, nach Starten von Fhem geht nichts.
Erst nachdem ich culfw Version 1.52 geflasht habe funktioniert COC auch mit Fhem.
Ich habe einen RasPi mit 512MB, cpuinfo meldet:
BCM2708
000e
kawa
Zitat von: kawa0815 schrieb am Fr, 20 September 2013 17:24Flashen der Firmware funktionierte einwandfrei, allerdings konnte ich das COC - Modul nicht mit fhem zur Arbeit bewegen.
je nachdem, woher Du die Firmware hast, kommt es zu solchen Problemen, weil offenbar ein paar Firmwarefiles im Umlauf sind, die schlichtweg nicht funktionieren.
Schau mal in diesen Thread:
Link da hatte ich genau das gleiche Problem - und die Lösung ist auch dort zu finden.
Du sprichst sicher über die COC.radio_only.hex. Ich habe aber die COC.hex und diese vom SVN Server.
kawa
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
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
Hi,
schaut ruhig hier (http://forum.fhem.de/index.php?topic=14909.0) 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
Zitat von: jörg am 26 August 2013, 07:05:33
2. Nach frustranen Versuchen mit der aktuellsten Firmware die ich über http://sourceforge.net/p/culfw/code/392/tree/ (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 (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 (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.
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
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
Danke Jörg, es funktioniert so wie du es hier geschrieben hast.
Danke dir und Gruß
cerberus
Zitat von: rammelsberg am 30 September 2013, 21:08:05
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 ...
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
Evtl hilft dier dies
Zitathttp://forum.fhem.de/index.php/topic,18690.msg124755.html#msg124755
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? :-\
Ich habe das Problem auch mit dem Image von Busware, ich benutze weiterhin das "alte" Image,
da läuft es noch.
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
ZitatDie 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)
'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=$?
;;ZitatTo 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
Zitat
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.
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! :) :) :)
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?
Endlich geschafft:
- Alte Sicherung aufgespielt (mit altem FHEM 5.3) -> Fehlermeldung bleibt :(
- Genauso wie von Jörg beschrieben nochmal die COC Firmware geflasht -> COC blinkt und FS20 Module werden erkannt!!! :) :) :)
Jetzt werde ich nochmal versuchen, FHEM zu aktualisieren..
Bei mir hat es auch mit dem aktuellem Image geklappt.
Danke!
Hei Leute,
welche Version ist den die aktuellste die funktioniert?
Habe das COC ohne Clock..
Nutze schon lange FHEM mit dem COC. Bis jetzt nur mit MAX Komponenten.
Habe mir jedoch jetzt ein Aktor von HM gekauft. Jetzt benötige ich die Boost Funktion. Diese gibt es erst ab Mai 2013 glaube ich.
Leider funktioniert bei mir nur die COC Version 1.54 und diese ist vom April -.-
Und jetzt?
LG
http://sourceforge.net/p/culfw/code/HEAD/tree/trunk/culfw/Devices/COC/
V1.57
und die Anleitung zum flashen http://busware.de/tiki-index.php?page=COC_Installation
Merci! Werde es die Tage ausprobieren und dann hier berichten!
Bin leider aktuell im Examenstress... :/
Gesendet von meinem iPad mit Tapatalk
Hat geklappt! Danke!