COC empfängt nichts mehr .....

Begonnen von AET_FHEM, 12 Februar 2014, 13:54:15

Vorheriges Thema - Nächstes Thema

AET_FHEM

Hallo,

--> hoffentlich bin ich hier richtig, im CUL Forum mit meinem COC Problem..

mein COC arbeitete bis mir beim Umzug der Raspberry blöderweise aus der Hand gefallen ist, beim aufbrall löste sich die ANtennen halterung (SMA) der COC hat aber noch funktuniert wenn ich Geräte genau davor plaziert hatte....
Jetzt habe ich die SMA Buchse neu angelötet
- der COC wird erkannt, ich musste ihn neu Flashen, in FHEM erkennt er keine Geräte mehr  :-[ ...

kann mir jemand weiter helfen??

chris1284

#1
Also wenn er vorher liefe, runter gefallen war und du ihn deswegen (neben dem anlöten der Antenne) nochmal flashen musstest vermute ich einen defekt am COC. Wüsste nicht wie die Firmware, die vorher ja lief, sonst verloren gehen könnte.

Wie wird er denn in fhem angezeigt?

AET_FHEM

Hey,

er lief -->  viel runter lief immer noch (allerdings auf geringe Distanz) --> gelötet ---> lief nicht mehr ( bekam bei eingabe "hexdump -C /sys/bus/i2c/devices/0-0050/eeprom" keine auswertung) --> neu geflasht --> auswertung auf "hexdump -C /sys/bus/i2c/devices/0-0050/eeprom" OK --> kein Empfang ... :-(

in FHEM:
TYPE CUL
VERSION V 1.57 CSM868


Wernieman

Ich würde denken, er hat einen internen Bruch. Beim Löten (thermische Verzerrung) dürfte er dann endgültig .... wie schon vom chris1284 geschrieben, durch das Löten dürfte er nicht "entflashed" worden sein.
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

AET_FHEM

 :-\ aaaa OK,

Ich weiß ja nicht genau ob er entfleshed war .....
............ wenn man mit "hexdump -C"  keine Auswertung bekommt ist er entfleshed ???

Wernieman

Ärgerlich .... aber ich befürchte, er ist "von uns gegangen"...

P.S. ich hätte das Neuflashen als letzten Notnagel auch probiert ... Du kannst auch eventuell gucken, ob Dir Haarrisse auf der Platine auffallen. Aber mache Dir keine Hoffnungen ...
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

AET_FHEM

AAAAAAAAAAAAAAAAAAAAAAAAAAA

Oh nein .......... ich löte das ding mal wieder ab und Teste es nochmal.....

kann ich irgendwie testen ob das Ding noch tut oder nicht?

Wernieman

Beim CUL würde ich ja sagen, versuche mal eine direkte Serielle Verbindung und einfache "Befehle", wie z.B. Status-Led an/aus .... wie aber beim COC ??????
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

AET_FHEM

Der COC wird doch vom FHEM erkannt hierüber kann ich doch mal die LED steuern???

AET_FHEM

Der COC blinkt schnell beim flashen und dann wieder normal danach......

wen ich fhem nicht stope kann ich den COC nicht flashen

nach dem Flashen zweig er an


Writing | ################################################## | 100% 7.34s



avrdude: 23130 bytes of flash written
avrdude: verifying flash memory against COC.hex:
avrdude: load data flash data from input file COC.hex:
avrdude: input file COC.hex auto detected as Intel Hex
avrdude: input file COC.hex contains 23130 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 6.31s



avrdude: verifying ...
avrdude: 23130 bytes of flash verified

avrdude done.  Thank you.

aber hwclock --> gibt keine Ausgabe mher!!

Ist er wirklich kaputt?

Was kann man noch versuchen??

Wernieman

hwclock? Auf dem RasPi??
Das ist doch ein Linux-Befehl, um die Locale Uhr abzufragen??
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

chris1284

#11
der befehl läuft nur ohne fehler auf dem pi wenn die rtc des coc erkannt wird. der pi hat von haus aus keine hwclock
der befehl fragt die zeit derhwclock ab, nicht die der fakehwclock
@AET: evtl mal ne andere sd schnappen, kurz das aktuell image drauf, coc einrichten, testen
http://forum.fhem.de/index.php/topic,14427.msg127147.html#msg127147
als hilfestellung


oder
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

AET_FHEM

Hey Chris,

das mit der hwclock hat geklappt, aber das heisst ja nichts.... der kreiert ja nur eine neue hwclock oder....
--> ich bekomm jetzt ne Auswertung zu hwclock....

Das mit der SD-Karte werde ich heute mittag testen....

---> Solange er blinkt gebe ich die Hoffnung nicht auf  :)

AET_FHEM

 :)
----> SING "Und er lebt noch er lebt noch ist nicht kaputt!"

mal kurz das was passiert ist:
ich dachte ich mach mal ein neues Projekt ein Mediaplayer mit Airplay und Squeezy Server Anbindung für meine Terrasse,
nach vielem Googlen und recherchieren bin ich dann auf SqueezePlug gestoßen und im Netz gibt es auch schon schöne Anleitungen für so ein Radio
...... also lange rede kurzer Sinn, ich hab mir einen zweiten Raspberry gekauft und bevor ich den als Radio betreibe hab ich das Ding mit Raspbian installiert und nur die Grund Installation von FHEM Installiert/Konfiguriert
- COC drauf neu geflasht hinzugefügt und ich muss sagen er empfängt!!!

--> meine Frage woran kann das liegen?
Vorgang:
- fhem.cfg (define COC CUL /dev/ttyAMA0@38400 1234)
- /etc/inittab (comment or delete: T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100)
- /boot/cmdline.txt (comment or delete: T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100)
- if test -e /dev/rtc0; then hwclock -w; fi
- averdude Installiert
- COC.hex herunter geladen
- neu geflasht mit:
________________________________________________________________
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
______________________________________________________________________

neu gestartet HMS hin gestellt und schon empfängt das Ding .....

Yüpii hÜPf sPrInG

---> Die Frage bleibt woran kann das liegen nach was muss ich suchen im alten System....
im alten System sind jetzt schon ein paar Server am Laufen schon einiges Installiert und eigentlich will ich den nicht neu aufsetzen....

hat jemand eine Idee?

JoWiemann

Hallo,

du hast nicht zufällig PiLight oder WiringPi. Beides benutzt in der Standard-Konfi die selebn GPIO wie der COC. Damit funktioniert der COC unter FHEM nicht mehr.

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

AET_FHEM

#15
Hallo,

leider nicht PiLight und WiringPi nutz ich nicht
der COC ist nur für den HMS definiert

Server>> define COC CUL /dev/ttyAMA0@38400 1234
Test >>> define COC CUL /dev/ttyAMA0@38400 1234

die einzigen Einstellungen im FHEM für den COC

_______________________________________________________

Der Unterschied:

/opr/fhem/fhem.cfg
Server>> define COC CUL /dev/ttyAMA0@38400 1234
Test >>> define COC CUL /dev/ttyAMA0@38400 1234

/etc/inittab
Server >> #T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100
Test  >>> #T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100

/boot/cmdline.txt
Server >> otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=dead$
Test >>>  dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 $

Server = altes System = COC empfängt nichts
Text = Test System = COC funktioniert

--> kann das der Fehler sein in der cmdline.txt ??

AET_FHEM

Da dachte ich mir ich änder einfach mal die /boot/cmdline.txt und sehe wie und was sich verändert
--> weil ich den Server nicht unbedingt jedesmal neu starten will versuche ich es mit der gegenprobe
das Test System ändern und abwarten ob er nichts mehr empfängt :-)

---> gesagt getan......
im Test System die  /boot/cmdline.txt geändert
von:
dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
auf:
otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait

---> und ich sehe das ...... ich was sehe :-(
der COC empfängt

Das kann es schon mal nicht sein ...
An was kann es den sonst noch liegen??
- Treiber??
- Wie sehe ich den in raspbian das der COC richtig erkannt wird und arbeitet?

habt ihr mir noch irgendwelche Tipps?