FHEM+RPi+COC+Busware

Begonnen von Howie, 15 Juni 2013, 18:15:28

Vorheriges Thema - Nächstes Thema

Howie

Hallo zusammen,

ich bekomme an meinem Pi den COC von Busware nicht zum laufen und komme nicht dahinter woran es liegt.
Ich habe das Forum schon die ganze Woche lang durchstöbert und allesmögliche ausprobiert....von Debian installieren und alle Einstellungen von Hand eintragen bis hin zum Img von Busware.
Hier meine Hardware:

RPi Made in China 2011.12
RPi COC V1.1 mit One Wire und RTC

Es gibt ja im Netz einen ganzen Haufen tutorials dennoch bin ich mir nicht sicher welche Schritte ich genau wofür machen muss.
Ich war der Meinung das es das einfachste wäre das Img von Busware zu benutzen.
Dazu gleich die Frage: Wird durch das Img der COC schon erkannt?
Ich bin davon ausgegangen das nur das Img schon reicht um mit dem COC zu komunizieren!?!?!

Wird durch das Img der COC bereits initialisiert?
Wenn ich den Pi starte leuchtet am COC nichts...egal mit welcher Konfiguration.
Ist der Pi hochgefahren und ich ziehe den COC ab und stecke ihn wieder auf blinkt die LED.
Nach einem reboot jedoch nicht mehr.
Das gleiche passiert wenn ich erst boote und den COC danach aufstecke.
Kann es sein das hier beim Bootvorgang etwas schief läuft?

Achso...die Platine steckt natürlich fest und ohne Spalt bis zum klicken auf dem Stecker.
Und auch richtig herum... ;-)

Für Hilfe wäre ich echt dankbar, ich weiß nämlich nicht mehr weiter:-(

Howie

Hallo,

hier nen kleines Update...
ich habe noch einige Versuche mit dem Busware Img gemacht und siehe da, warum auch immer, blinkt beim Neustart die LED am COC ca 8 mal.
Danach bleibt sie aus.
Nach einigen anderen ersuchen habe ich mir die fhem.cfg vorgenommen und alle einträge gelöscht außer die COC Initialisierung.
Jetzt blinkt die LED ständig....aber fhem läuft natürlich nicht mehr.
Also nach und nach wieder die Auskommentierung gelöscht.
Das Problem ist der Eintrag:

attr global modpath .                  # where our FHEM directory is
 
So wie ich die FHEM Reference verstehe ist hier nicht der Pfad "FHEM" hinterlegt. Aber welcher Pfad gehört hier rein?
Und wieso ist die Angabe dieses Pfades dafür verantwortlich das mein COC abstürzt?
Ist hier vielleicht die "ttyAMA0" atei hinterlegt?

Wäre nett wenn mich jemand aufklären könnte....
Bis dahin noch ein schönes Wochenende ;-)

Ernstl

Hallo Howie,

ich hatte das gleiche Problem wie Du. Bei mir war es einfach nur ein Kontaktproblem zwischen dem Pi und dem COC.

Das Image bei Busware passt eigentlich für die Grundfunktionen, mann muss nichts mehr einstellen das der Pi mit dem COC läuft (alles schon vorkonfiguriert)

Eigentlich hätte alles in Ordnung sein müssen, ich hatte auch kein Spalt zwischen dem Pi und dem COC wie auf dem Bild bei Busware!
Ich hab dann den Pi aus dem Gehäuse genommen, den COC gegenüber der Pins leicht angehoben und gebootet.
Der Pi mit dem COC hat dann einwandfrei funktioniert und die LED dauerhaft geblinkt (ist soweit ich weiß normal).

Bei mir hat es da "2 Stufen" beim Kontakt gegeben: COC minimal angehoben, LED nur leicht geblinkt. Minimal mehr angehoben hat die LED hell geblinkt, dann ist auch alles OK.
Hab dann den COC abgesteckt, die Pins auf dem Pi leicht (aber wirklich nur leicht) nach innen gebogen und den COC wieder aufgesteckt. Seitdem funktioniert alles einwandfrei.

in meiner fhem.cfg ist der gleiche Eintrag wie bei Dir:
attr global modpath .
daran muss auch nicht geändert werden soweit ich weiß, weil bei mir läuft alles.

Mfg, Ernstl


Howie

Hallo Ernstls,

vielen Dank für die Antwort.
Das mit den Kontakproblemen habe ich auch schon öfter gelesen.
Aber wenn ich den Eintrag "Modpath" ändere blinkt ja meine LED und das auch nach einem reboot.
Deshalb hatte ich Kontaktprobleme ausgeschlossen.
Nur wenn ich den Eintrag wieder auf original zurück ändere blinkt die LED nur beim booten.
War das bei dir auch so???


Ernstl

Hallo Howie,

soweit ich noch weiß hat die LED bei mir beim Booten auch geblinkt, aber dann nicht mehr. Ich hatte in der config nichts geändert, wie gesagt war das Kontaktproblem bei mir wie in "2 Stufen", bei der ersten hat die LED am COC zwar auch geblinkt, aber es hat nichts funktioniert (COC flashen ....). Wenn ich dann den COC gegenüber den Pins etwas mehr angehoben habe ist die LED heller geworden und dann war alles in Ordnung.

Grüße Ernstl

Howie

Hallo Ernstl,

das mit der LED ist bei mir genauso und ich bekomme jetzt auch ne Antwort von HWCLOCK.
Zwar ein falsches Datum aber immerhin...
Ich versuche jetzt erstmal zu funken und berichte später ob es funktioniert hat....vielen Dank erstmal und noch einen schönen Abend.

Gruß Howie

Howie

Hallo zusammen,

bevor ich ganz es ganz vergesse hier nun die Auflösung meines Problems damit auch die Allgemeinheit was davon hat.
Ich habe den COC von Busware genau nach Anleitung installiert. Ohne Luftspalt zwischen Platine und Stecker.
Die led am COC blinkt während des hochfahrens ca 8 mal danach nicht mehr.
Deswegen hatte ich auch Kontaktprobleme ausgeschlossen.
Nach Ernstl´s Hilfe habe ich dann die Platine etwas angehoben und siehe da....die LED leuchtet tatsächlich heller und blinkt jetzt auch die ganze Zeit.
Danach war alles einfach....Image von Busware, Updates ziehen und Einstellungen ändern ein paar Aktoren einprogrammieren und einfach über das Webfrontent schalten...super Sache.

Mittlerweile habe ich alles auf nem Floorplan und versuche mich an 433MHz Steckdosen von REV.


micha80

Hallo zusammen,

Ich hatte auch genau die Probleme! Sieht nach einem einfachen wackler aus:

Wir haben in dem postenstecker die kontakte nach innen gebogen, schon leuchtet und blinkt die LED hell
und die hwclock wird auch gefunden! (für die Initialisierung muss rebootet werden! Wenn beim booten die LED nicht hell leuchtet, funktioniert es nicht)

Mit einer sehr dünnen spitzen Nadel geht es am besten...jeweils 2 pro gpio Pin

Ich hoffe, ich konnte jemandem helfen :)

MfG
Micha

rstr

Hi.
Und hiermit meldet sich noch einer mit demselben vermeintlichen "Wackler"-Problem.
Danke für Eure Hinweise dazu. Aber:
1) Das Biegen der Kontakte ist wohl kaum eine langfristig zuverlässige Sache.
2) Das Problem tritt auch dann auf, wenn man RPI und COC mit Pfostensteckverbinder / kurzem Flachbandkabel / rechtwinkligem Pfostenfeldstecker stabil verbindet !! Da kann nichts mehr wackeln.
3) Der positive Effekt (COC-LED blinkt dauerhaft, COC sendet FS20), der durch das zeitweilige Lockern / Anheben der Kontaktverbinder tatsächlich festzustellen ist, hält nach einem Reboot nicht an.
Ich habe mehr den Eindruck, dass durch das Lockern / Anheben irgendwie der COC neu startet. Den positiven Effekt hat man nämlich auch, wenn man radikal im Betrieb / unter Spannung die COC / RPI Verbindung komplett trennt und dann neu steckt. Damit wäre wohl die Firmware des COC (bei mir 1.55 CSM868, hexdump zeigt 2013-06-22) oder die Integration in wheezy oder fhem auch unter Verdacht.
Interessanter Hinweis aus anderen Beiträgen: RPI "made in China" wird öfter mit COC-Problemen benannt als RPI "made in UK" (meine RPIs sind alle HW-Rev. 2011.12, einer made in China: geht nicht, zwei made in UK: der von busware geht, der von Farnell nicht). Die auch vom o.g. Problem Betroffenen sollten mal mit cat /proc/cpuinfo die HW-Revision (vorletzte Zeile) auslesen (bei mir: die nicht funktionierenden RPIs made in China (RS) und made in UK (Farnell) haben BCM2708 Rev. 000d bzw. 000e, der funktionierende RPI made in UK von busware hat Revision 000e).

Da das Problem anscheinend einige Leute betrifft und damit wohl ein systematisches ist, schlage ich vor:
1) gemeinsam eine Stellungnahme von busware anzufordern, insbesondere, welche Abhängigkeiten des COC es zu HW-Revisions der RPIs gibt und was das besondere an den busware-RPIs ist, damit diese mit dem COC klarkommen
2) die diversen Steps zur Eingrenzung / Analyse des Problems und zur Verifikation von Teilkomponenten (HW / SW / FW) auf einer zentralen Wikiseite zusammenzustellen. Ich bin da gerne bereit, hierzu einen Beitrag zu leisten. Bitte also um Kommentare und wenn befürwortet um einen Vorschlag, wo diese "Checkliste" am besten aufgehoben wäre.

P.S.: Eine CUL/Fritzbox-Variante läuft bei mir einwandfrei und seit 1 Jahr stabil.
P.P.S.: Natürlich habe ich alle Steps auf der busware-Webseite und die von diversen Forumsbeiträgen befolgt, die COC-Initialisierung in /etc/init.d/fhem überprüft, das COC-Eeprom gecheckt, den getty auf ttyAMA0 im /etc/inittab auskommentiert, das busware-wheezy-Image benutzt, ... Da es ja bei identischer RPI-SW und COC-FW zu unterschiedlichen Verhaltensweisen des COC kommt, kann SW / FW / Konfiguration als Ursache ausgeschlossen werden; dito kann ich bei meinen Tests Kontaktprobleme als Quelle negieren. Die o.g. Erfahrungen zeigen dann auch, dass es nicht die /proc/cpuinfo-HW-Revision sein kann und auch nicht die "made in China" / "made in UK" Thematik.

Bleibt also die Frage, ob die bei Euch funktionierenden RPIs auch bei busware bezogen wurden bzw. die nicht-funktionierenden RPIs von anderen Quellen als busware stammen ?

MfG - Rob