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??
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?
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
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.
:-\ aaaa OK,
Ich weiß ja nicht genau ob er entfleshed war .....
............ wenn man mit "hexdump -C" keine Auswertung bekommt ist er entfleshed ???
Ä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 ...
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?
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 ??????
Der COC wird doch vom FHEM erkannt hierüber kann ich doch mal die LED steuern???
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??
hwclock? Auf dem RasPi??
Das ist doch ein Linux-Befehl, um die Locale Uhr abzufragen??
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
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 :)
:)
----> 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?
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
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 ??
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?