Hallo community,
ich hoffe ihr könnt mir bei meinem Problem helfen...
Hardware:
- Raspberry Pi Rev. B (Made in the UK - Raspberry Pi (c) 2011.12)
- Busware RPi COC-Erweiterung
1 x Rasperry Pi - COC Erweiterung (RPI-COC) = 63,99EUR
Videokabel ohne
Version alle Optionen (Funk, Uhr, OneWire, EEPROM)
SD Karte ohne
Raspberry Pi ohne
Netzteil ohne
Gehäuse ohne
Frequenz 868MHz (FS20, HM, etc)
Antenne RP-SMA 868MHz +3dBi 5cm[/list]
Leider bekomme ich die beiden Komponenten nicht zum laufen.
Die COC Erweiterung habe ich ohne Spalten aufgesetzt und bekomme im Hexdump auch folgende Ausgabe:
root@raspberrypi:~# hexdump -C /sys/bus/i2c/devices/0-0050/eeprom
00000000 43 4f 43 20 56 31 2e 31 20 46 55 4c 4c 20 32 30 |COC V1.1 FULL 20|
00000010 31 33 2d 30 35 2d 30 33 0a ff ff ff ff ff ff ff |13-05-03........|
00000020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
00000100
Unter
/dev finde ich jedoch kein RTC device, ebenso gibt hwclock eine Fehlermeldung aus:
root@raspberrypi:~# if test -e /dev/rtc0; then hwclock -w; fi
root@raspberrypi:~# ls /dev/rtc0
ls: cannot access /dev/rtc0: No such file or directory
root@raspberrypi:~# hwclock -w
hwclock: Cannot access the Hardware Clock via any known method.
hwclock: Use the --debug option to see the details of our search for an access method.Ich habe derweil folgendes probiert:
- Das fertige SD-Card Image vom Busware FTP-Server
- Ein nacktes Debian Wheezy mit ausgetauschen Kernel Modulen (3.6.11-busware+) vom Busware FTP-Server
- Ebenfalls ein nacktes Debian Wheezy mit eigenen kompilierten Kernel mit dem Busware Patch
Zudem habe ich herausgefunden, wenn man FHEM aus dem Autostart entfernt und den RPi komplett stromlos macht, fängt die LED auf dem COC während des Boot Vorgangs an zu blinken. Sobald FHEM gestartet wird, hört das blinken sofort auf und ich erhalte im Log folgende Fehlermeldung:
2013.05.18 17:02:43 3: Opening COC device /dev/ttyAMA0
2013.05.18 17:02:43 3: Setting COC baudrate to 38400
2013.05.18 17:02:43 3: COC device opened
2013.05.18 17:02:43 3: COC: Possible commands: mCFiAZOGMRTVWXefltux
2013.05.18 17:02:46 1: Cannot init /dev/ttyAMA0, ignoring itBei einem anderen Versuch habe ich wieder stromlos ohne FHEM den Raspberry Pi gebooted. Dann habe ich mit via minicom mich auf den COC verbunden und konnte mittels "V" und "?" kommunizieren. Sobald ich den Befehl "X21" abgeschickt habe, hängt sich der COC irgendwie auf und muss stromlos gemacht werden. Das blinken der LED hört damit auch sofort auf.
Generell hatte ich auch den Fehler, dass ich die Fehlermeldung "Connecting to programmer: .avrdude: butterfly_recv(): programmer is not responding" beim Flasheb beokmme, bis ich herausgefunden hatte, dass man den COC nur flashen kann, wenn die LEDs blinken. Das hat dann auch funktioniert und ich habe die Firmware Versionen 1.52, 1.53 und 1.54 probiert.
Und damit verzweifel ich auch schon...
Wie verhält sich die LED auf dem COC im Normalzustand? Wenn FHEM und X21 laufen?
Nachdem ich diesen Beitrag (http://forum.fhem.de/index.php?t=msg&goto=77523&rid=0 (//forum.fhem.de/index.php?t=msg&goto=77523&rid=0)) gelesen habe, der exakt mein Problem beschreibt, bin ich nach Conrad und habe für einen völlig überteuerten Preis mir ein neuen zweiten Raspberry Pi Rev. B gekauft (Man will ja nicht bis zum Ende des langen Wochenende warten ;-)). Leider ohne Änderung.
Was mir beim durchforsten des Internets aufgefallen ist, dass immer wenn ich auf das gleiche Problem gestoßen bin, der Nutzer ebenfalls im Hexdump das Datum "13-05-03" stehen hat.
Kann es hier vielleicht ein einheitliches Problem mit der Serie sein?
Ich hoffe ihr (oder Herr Tostmann) selbst, kann mir bei diesem Problem helfen.
Viele Grüße und ein angenehmes Pfingstwochenende.
- tkempken
Nun habe ich mal die letzte COC.radio_only.hex (Version 1.49) geflasht:
2013.05.18 18:25:26 5: Cmd: >define COC CUL /dev/ttyAMA0@38400 1234<
2013.05.18 18:25:26 5: Loading ./FHEM/00_CUL.pm
2013.05.18 18:25:26 3: Opening COC device /dev/ttyAMA0
2013.05.18 18:25:26 3: Setting COC baudrate to 38400
2013.05.18 18:25:26 3: COC device opened
2013.05.18 18:25:26 5: SW: V
2013.05.18 18:25:26 5: CUL/RAW (ReadAnswer): V 1.49 CSM868
2013.05.18 18:25:26 5: SW: ?
2013.05.18 18:25:26 5: CUL/RAW (ReadAnswer): ? (? is unknown) Use one of m C
2013.05.18 18:25:26 5: CUL/RAW (ReadAnswer): F i A Z
2013.05.18 18:25:26 5: CUL/RAW (ReadAnswer): G M R T
2013.05.18 18:25:26 5: CUL/RAW (ReadAnswer): V W X e
2013.05.18 18:25:26 5: CUL/RAW (ReadAnswer): f l t u
2013.05.18 18:25:26 5: CUL/RAW (ReadAnswer): x
2013.05.18 18:25:26 3: COC: Possible commands: mCFiAZGMRTVWXefltux
2013.05.18 18:25:26 5: SW: X21
2013.05.18 18:25:26 5: SW: T01
2013.05.18 18:25:29 1: Cannot init /dev/ttyAMA0, ignoring it
Ausgabe sieht identisch aus wie beim COC-full in der Version 1.54:
2013.05.18 20:40:27 5: Cmd: >define COC CUL /dev/ttyAMA0@38400 1234<
2013.05.18 20:40:27 5: Loading ./FHEM/00_CUL.pm
2013.05.18 20:40:27 3: Opening COC device /dev/ttyAMA0
2013.05.18 20:40:28 3: Setting COC baudrate to 38400
2013.05.18 20:40:28 3: COC device opened
2013.05.18 20:40:28 5: SW: V
2013.05.18 20:40:28 5: CUL/RAW (ReadAnswer): V 1.54 CSM868
2013.05.18 20:40:28 5: SW: ?
2013.05.18 20:40:28 5: CUL/RAW (ReadAnswer): ? (? is unknown) Use one of m C
2013.05.18 20:40:28 5: CUL/RAW (ReadAnswer): F i A Z
2013.05.18 20:40:28 5: CUL/RAW (ReadAnswer): O G M R
2013.05.18 20:40:28 5: CUL/RAW (ReadAnswer): T V W X
2013.05.18 20:40:28 5: CUL/RAW (ReadAnswer): e f l t
2013.05.18 20:40:28 5: CUL/RAW (ReadAnswer): u x
2013.05.18 20:40:28 3: COC: Possible commands: mCFiAZOGMRTVWXefltux
2013.05.18 20:40:28 5: SW: X21
2013.05.18 20:40:28 5: SW: T01
2013.05.18 20:40:28 5: CUL/RAW (ReadAnswer):
2013.05.18 20:40:28 5: CUL/RAW (ReadAnswer):
2013.05.18 20:40:31 1: Cannot init /dev/ttyAMA0, ignoring it
Aber weiterhin keine Lösung :-(
Hallo tkempken,
ich habe zwar einen Rpi, aber keine COC.
Der Seite von Busware (//www.busware.de/tiki-index.php?page=COC_Installation) habe ich folgendes entnommen:
- der Prozessor mit dem CC1101 hängt an der seriellen Schnittstelle
- RTC, EEPROM und 1-wire Busmaster hängt am I2C Bus.
Daher würde ich auch zweistufig in der Fehlersuche vorgehen (die radioonly Firmware müsste die serielle Schnittstelle genauso gut bedienen können, wie die vollständige (mit 1-wire), was da anders ist, weiß ich aber nicht):
- Rpi booten und fhem stoppen
- gemäß
echo "calling COC bootloader..."
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 0 > /sys/class/gpio/gpio18/value
echo 0 > /sys/class/gpio/gpio17/value
sleep 1
echo 1 > /sys/class/gpio/gpio17/value
sleep 1
echo 1 > /sys/class/gpio/gpio18/value
avrdude -p atmega1284p -P /dev/ttyAMA0 -b 38400 -c avr109 -U flash:w:COC.hex
über die Konsole die radioonly Firmware flashen, dann sollte die serielle Schnittstelle im Kernel freigeschaltet sein und funktionieren
- danach fhem starten und versuchen, den COC einzubinden und Daten zu lesen
Aber so wie es aussieht, hast Du das alles schon gemacht. Es kommt zumindest bei der Versionsabfrage mit V beim Start von fhem die korrekte Version (1.49 bzw. 1.53) der Firmware. Mit X21 (//culfw.de/commandref.html#cmd_X) bzw. T01 (//culfw.de/commandref.html#cmd_T) wird SlowRF bzw. der eigene Hauscode initialisiert, was danach vom COC zurückkommt, weiß ich nicht, aber vermutlich kommt nicht das, was fhem erwartet ...
Daher meine Tipps:
- RPi mal ausschalten und COC runternehmen
- den Pfostenstecker auf dem RPi bzw. die Lötstellen der Buchse am COC anschauen (vermutlich ist der Stecker für das Flachbandkabel am RPi zu hoch und der COC kann nicht ganz draufgesteckt werden)
- COC wieder draufstecken und die Verbindungen zwischen RPi und COC mit dem Ohmmeter nachmessen (vor allem die Pins 1, 3, 5, 11, 13, 2, 8, 10 und 12 aus dem Schaltplan (//www.busware.de/tiki-download_file.php?fileId=68) (RASPBERRY-EXP)), Ziel <1 Ohm
- RPi einschalten und die 3,3 bzw. 5 V Spannung auf dem COC nachmessen
- ggf. mal diese Firmware (//forum.fhem.de/index.php?t=getfile&id=2788&rid=309) flashen
Gibt es eigentlich außer dem Pfostenstecker noch eine mechanische Fixierung der COC Platine (z.B. mit Schrauben)?
Bei der Inbetriebnahme des Rests (RTC, EEPROM, etc.) über den I2C Bus kann ich leider nicht helfen.
Gruß PeMue
ggf. gibt es hier (//www.rn-wissen.de/index.php/Raspberry_PI:_GPIO) noch die Pinbelegung des RPi ...
Gruß PeMue
Nabend,
danke für deinen Post!
Ich habe deine FW geflashed, leider hatte sie auch nach mehreren Reboots keine Verbesserung.
BTW: Wo im Forum hast du die gefunden?
Dann habe ich nochmal den COC abgenommen, und aufgesteckt... Keine Verbesserung...
Dann abgesteckt und die Kontakte durchgemessen, alles ok.
Erneut eingeschaltet und einfach mal sinnlos den COC im minicom zugespammt...
Seltsamerweise hat dieser erstmals reagiert...
Ich habe X00 dann T01 gesendet... dann jeglichem Müll :)
root@raspberrypi:~# minicom -D /dev/ttyAMA0 -b 38400
Welcome to minicom 2.6.1
OPTIONS: I18n
Compiled on Apr 28 2012, 19:24:31.
Port /dev/ttyAMA0
Press CTRL-A Z for help on special keys
V 1.54 CSM868
? (? is unknown) Use one of m C F i A Z G M R T V W X e f l t u x
? (? is unknown) Use one of m C F i A Z G M R T V W X e f l t u x
V 1.54 CSM868
V 1.54 CSM868
>>>>>X00
>>>>>T01
? (Nx43 is unknown) Use one of m C F i A Z G M R T V W X e f l t u x
? (Qx65 is unknown) Use one of m C F i A Z G M R T V W X e f l t u x
V 1.54 CSM868
? (Lx23 is unknown) Use one of m C F i A Z G M R T V W X e f l t u x
V 1.54 CSM868
>>>>>X21
>>>>>T01
81F6
>>>>>X21
>>>>>T01
81F6
E02065A86130000000005
TBB4DBC0103
TBB4DBC8103
Und tada... es funktioniert... WTF o.O
2013.05.18 22:45:52 5: Cmd: >define COC CUL /dev/ttyAMA0@38400 1234<
2013.05.18 22:45:52 5: Loading ./FHEM/00_CUL.pm
2013.05.18 22:45:52 3: Opening COC device /dev/ttyAMA0
2013.05.18 22:45:53 3: Setting COC baudrate to 38400
2013.05.18 22:45:53 3: COC device opened
2013.05.18 22:45:53 5: SW: V
2013.05.18 22:45:53 5: CUL/RAW (ReadAnswer): V 1.54 CSM868
2013.05.18 22:45:53 5: SW: ?
2013.05.18 22:45:53 5: CUL/RAW (ReadAnswer): ? (? is unknown) Use one of m C
2013.05.18 22:45:53 5: CUL/RAW (ReadAnswer): F i A Z
2013.05.18 22:45:53 5: CUL/RAW (ReadAnswer): G M R T
2013.05.18 22:45:53 5: CUL/RAW (ReadAnswer): V W X e
2013.05.18 22:45:53 5: CUL/RAW (ReadAnswer): f l t u
2013.05.18 22:45:53 5: CUL/RAW (ReadAnswer): x
2013.05.18 22:45:53 3: COC: Possible commands: mCFiAZGMRTVWXefltux
2013.05.18 22:45:53 5: SW: X21
2013.05.18 22:45:53 5: SW: T01
2013.05.18 22:45:53 5: CUL/RAW (ReadAnswer): 81F6
2013.05.18 22:45:53 5: GOT CUL fhtid: 81F6
2013.05.18 22:45:53 2: Setting CUL fhtid from 81F6 to 1234
2013.05.18 22:45:53 5: SW: T011234
...
2013.05.18 22:45:56 5: COC: E02065B861300000000 -71.5
2013.05.18 22:45:56 5: COC dispatch E02065B861300000000
2013.05.18 22:45:56 5: Loading ./FHEM/15_CUL_EM.pm
2013.05.18 22:45:56 1: CUL_EM detected, Code 6 CNT: 91 CUM: 4998 5MIN: 0 TOP: 0
2013.05.18 22:45:56 5: Triggering global (1 changes)
2013.05.18 22:45:56 5: Notify loop for global UNDEFINED CUL_EM_6 CUL_EM 6
2013.05.18 22:45:56 2: autocreate: define CUL_EM_6 CUL_EM 6
2
Ich hasse derartige Fehler :-( Man traut sich nun den Pi keinen millimeter zu bewegen...
Ich könnte mir vorstellen, dass es doch irgendwie mit der Verbindung zwischen COC und Pi zusammenhängt.
Mal abwarten wie lange es hält...
Hallo tkempken,
das wäre mein nächster Vorschlag gewesen: einach mit einem Terminalprogramm (//www.mikrocontroller.net/topic/66694) auf den COC zugreifen und versuchen, zu kommunizieren. Ist ja nicht schwer, die Hilfe kommt ja nach einem missverstandenen Befehl.
Die Firmware habe ich hier (http://forum.fhem.de/index.php?topic=11724.0) aus dem Forum.
Gibt es beim COC echt keine zusätzliche mechanische Fixierung außer der Pfostenleiste?
Gruß PeMue
Hallo,
bei mir die gleichen Symptome:
RPi Made in China
sudo hexdump -C /sys/bus/i2c/devices/0-0050/eeprom
00000000 43 4f 43 20 56 31 2e 31 20 46 55 4c 4c 20 32 30 |COC V1.1 FULL 20|
00000010 31 33 2d 30 35 2d 30 33 0a ff ff ff ff ff ff ff |13-05-03........|
00000020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
00000100
hwclock
hwclock: Cannot access the Hardware Clock via any known method.
hwclock: Use the --debug option to see the details of our search for an access method.
In fhem.log ebenfalls: Cannot init /dev/ttyAMA0, ignoring it, LED vom COC blinkt beim Hochfahren
vier mal und bleibt dann aus.
RPI Made in UK: COC läuft auf Anhieb. Dann nach Einbau in Gehäuse das gleiche wie oben.
Habe eben den COC noch einmal aufgesteckt und alle Pins durchgemessen.
Momentan läuft er wieder, warum weiß ich nicht.
Gruß,
Uwe
Hi uwe_k.
Frage: Ist der mit COC funktionierende RPI "made in UK" von busware oder von Farnell ?
Bei mir ergibt sich folgendes Bild - bei gleichen Board-Stamp 2011.12 der RPIs und identischer raspbian wheezy SD Card:
RPI "made in China" von RS: geht nicht
RPI "made in UK" von Farnell/element14: geht nicht
RPI "made in UK" von busware: geht
"geht nicht" bedeutet: identische Symptome wie im Thread geschildert.
"geht" bedeutet: RTC ansprechbar, FHEM / FS20 ansprechbar.
Aber es gibt doch einen wichtigen Unterschied zwischen den RPIs:
Die vom o.g. Problem Betroffenen sollten mal mit cat /proc/cpuinfo die HW-Revision (vorletzte Zeile) auslesen - bei mir: der nicht funktionierenden RPI made in China (RS) hat BCM2708 Rev. 000d, der funktionierende RPI made in UK (busware) hat Revision 000e, der nicht funktionierende RPI made in UK (Farnell) allerdings auch Rev.000e.
Da die gleiche SD Card und der gleiche COC verwendet wurde, kann das unterschiedliche Verhalten der RPIs kein SW-Thema sein. Dass sich bei mir auch die "made in UK" RPIs von Farnell und von busware unterschiedlich verhalten, wäre es wichtig, zu wissen, ob Eure funktionierenden RPIs "made in UK" auch von busware bezogen wurden und was /proc/cpuinfo als Revision meldet.
MfG - Rob
Hi,
habe zwei von UK (exp-Tech und Conrad Filiale).
Aber wie gesagt anfangs gleiche Symptome.
Seit meinem letzten Post rennt das mit eigener sd Card und Busware img.
Habe nur das Problem gehabt das sämtliche sd cards geschrottet wurden aufgrund zuviel IO.
Nutze daher die sd Card nur noch für den bootloader (/boot). alles andere (OS+apps) liegen auf einer USB Platte.
Versuch mal die buchsenleiste des COC mit etwas kontaktspray zu besprühen. Ich vermute stark das es nen desigbfehler ist.
LG
Hallo,
der RPi ist von Farnell, hat aber nach wenigen Tagen die gleichen Symptome gezeigt.
Habe den COC gegen einen CUL umgetauscht.
Irgendwelche Kontaktprobleme auf der Stiftleiste würde ich auch nicht ausschließen,
weil es oft nach Umstecken oder Einbau in Gehäuse aufgetreten ist.
Gruß,
UK
Hi.
Volltreffer mit Euren Hinweisen - es sind doch Kontaktprobleme, vor allem an Pin 1 und 26.
Habe mir aus halbierten einreihigen Stapelleisten und einer zweireihigen Stiftleiste einen Adapter gelötet, der die Buchsenleiste am COC voll durchstößt, womit endlich volle Federkraft der Buchsen gegeben ist - siehe Bild im Anhang. Und tadaaa - jetzt funzt es auch mit allen RPIs, made in China by RS, made in UK by Farnell und wie vorher schon beim made in UK von busware.
Danke für Eure wertvollen Hinweise. Case closed.
thx - Rob
(siehe Anhang / see attachement)