RPi + COC = Verzweifelung

Begonnen von tkempken, 18 Mai 2013, 18:10:56

Vorheriges Thema - Nächstes Thema

tkempken

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 it


Bei 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) 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

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 :-(

PeMue

Hallo tkempken,

ich habe zwar einen Rpi, aber keine COC.
Der Seite von Busware 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 bzw. T01 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 (RASPBERRY-EXP)), Ziel <1 Ohm
- RPi einschalten und die 3,3 bzw. 5 V Spannung auf dem COC nachmessen
- ggf. mal diese Firmware 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
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

PeMue

ggf. gibt es hier noch die Pinbelegung des RPi ...

Gruß PeMue
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

tkempken

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...

PeMue

Hallo tkempken,

das wäre mein nächster Vorschlag gewesen: einach mit einem Terminalprogramm 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 aus dem Forum.

Gibt es beim COC echt keine zusätzliche mechanische Fixierung außer der Pfostenleiste?

Gruß PeMue
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

uwe_k

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

rstr

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

tkempken

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

uwe_k

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

rstr

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)