Raspberry Pi Add-On Board (nicht mehr verfügbar / Fertigung eingestellt)

[leuchte1]

Hallo,

hab die hier: http://www.ebay.de/itm/151264906318?_trksid=p2059210.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT

Lieferzeit ca. 10 Tage.

Gruss
Stefan

[pc1246]

Hallo Stefan und Karl

Danke, ich bin einfach zu bloed! Ich habe nach Antenne gesucht, da kommt natuerlich Antenna nicht als Ergebnis! Gut, da mein Draht ja funktioniert, kann ich auf den Chinesen warten!

Gruss Christoph

[raimundl]

Hallo!

Habe im Rahmen meiner Versuche nun einen DS2401 am OWBus angeschlossen (DS18B20 läuft problemlos):

DS2401 wurde automatisch erkannt und auch ausgewertet -present. Eine weitere Aktualisierung funktioniert aber nicht. Der Status ob present oder not present funkt nur beim booten.

Noch eine kurze Zusatzfrage: was symbolisiert die LED auf der TFT Platine genau?

LG

[locutus]

Der DS2401 sendet ja nur seine Seriennummer auf dem Bus. Ich kenne das Bauteil und das Verhalten des OWID Moduls nicht. Dazu sollte sich mal jemand äußern, der diese Konstellation aktiv nutzt.

Die LED signalisiert den Empfang und das Senden von Daten. 3 verschiedene Modi sind konfigurierbar: http://culfw.de/commandref.html#cmd_l

[Spezialtrick]

Wie hast du die 1-Wire Temperatursensoren angeschlossen, parasitär oder normal? Bitte im Normalbetrieb das Attribut

Code Auswählen Erweitern

attr OWio  buspower real
setzen.
Die DS18B20 sollten jeweils mit einem 100nF Kondensator zwischen +5V und GND zur Stabilisierung des Busses versehen werden.

Müssen die Kondensatoren direkt am DS18B20 verbunden werde oder kann ich sie auch direkt am Pi anbringen?

Das setzen von "attr OWio  buspower real" braucht leider kaum Besserung.

[Heffer]

Hallo,

nach mehrmonatigen Gebrauch des Raspberry Pi Add-On Boards meldet das FHEM-Logfile seit ein paar Tagen

2014.08.31 16:28:13 3: Opening CUL_0 device /dev/ttyAMA0
2014.08.31 16:28:13 3: Setting CUL_0 baudrate to 38400
2014.08.31 16:28:13 3: CUL_0 device opened
2014.08.31 16:28:23 1: Cannot init /dev/ttyAMA0, ignoring it (CUL_0)

Alle Versuche von mir das Problem zu beseitigen sind bisher gescheitert u.a. Durcharbeitung aller Punkte der Kurzanleitung.
minicom und "get CUL_0 Version" liefern

CUL_0 version => No answer

Lediglich die CUL-LED scheint auf Ereignisse der seriellen Schnittstelle zu reagieren. Das LCD läuft ohne Probleme.

Hat jemand eine Rat für mich ?

Viele Grüsse Heffer

[locutus]

Leuchte die LED chaotisch und ohne ein erkennbares Muster auf? In dem Fall belegt einen anderer Prozess die /dev/ttyAMA0 Schnittstelle.
Eventuell fehlen Userrechte:

Code Auswählen Erweitern

cd /opt
sudo chmod -R a+w fhem && sudo usermod -a -G tty pi && sudo usermod -a -G tty fhem

Müssen die Kondensatoren direkt am DS18B20 verbunden werde oder kann ich sie auch direkt am Pi anbringen?

Direkt an die +5V und GND Beinchen des Sensors anlöten.

[Heffer]

Hallo locutus,

die Userrechte sind es nicht. Deine Befehlszeile brachte keine Verbesserung.
Die LED blinkt nur bei Ein-/Ausgaben der seriellen Schnittstelle.

Heffer

[locutus]

Sehr eigenartig! Ist ein Firmware Update möglich?

[locutus]

Hallo kaihs,

ist dir schon aufgefallen, dass seit dem heutigen Update das Logfile regelrecht mit dem Wort display zugemüllt wird?

[leuchte1]

Hallo locotus,

leider krieg ich 1-wire nicht zum laufen. Teste gerade mit ein paar DS18b20 über OWX. Angeschlossen normal, buspower real ist gesetzt, Kabellänge 20cm. Ein Sensor wird sporadisch von OWterm erkannt und eingerichtet (läuft dann auch stabil). Sobald ich einen zweiten anschliesse oder ein längeres Kabel verwende wird nichts mehr erkannt.
get owio devices: OWX: 1-Wire devices found on bus OWIO
und im Log: OWX: No answer to CUL_0 device search

Vermutlich würden die von Dir bereits vorgeschlagenen Kondensatoren Abhilfe schaffen, ich hab nur dummerweise bereits Sensoren verkabelt und in meine Pufferspeicher verbaut. Die wieder auszubauen ist mir fast zu aufwendig.

Vielleicht hast Du ja noch eine Idee.

Gruss
Stefan

[kaihs]

Hallo kaihs,

ist dir schon aufgefallen, dass seit dem heutigen Update das Logfile regelrecht mit dem Wort display zugemüllt wird?

Ich habe gerade ein Update gemacht, habe aber nichts dergleichen.
Was steht da genau im Log?

Ich habe am FRAMEBUFFER Module schon seit längerem nichts mehr gemacht, falls du meinst es kommt von dort.

[locutus]

Ich weiß, dass du am FRAMEBUFER nichts geändert hast. Die Einträge im Logfile haben keinen Zeitstempel. So wie es aussieht, taucht display im Minutentakt auf.

Code Auswählen Erweitern

2014.09.01 21:37:50 3: set CUL433 led 00
display
display
display
display
2014.09.01 21:41:29 3: HTTPMOD got error in callback: connect to http://emoncms.org:80 timed out

fhem.cfg:

Code Auswählen Erweitern

define display FRAMEBUFFER /dev/fb1
attr display layoutBasedir /opt/fhem
attr display layoutList standard.txt steckdosen.txt webcam.txt
attr display startLayoutNo 0
attr display update_interval 1

@leuchte1
Wie viele Devices insgesamt hast du am 1-Wire Bus angeschlossen? Die Anzahl der Devices wird in board.h definiert und ist firmwareseitig auf 8 begrenzt.

Code Auswählen Erweitern

/* a maximum of 8 onewire devices is supported */
#define HAS_ONEWIRE         8      // OneWire Device Buffer, RAM: 10 * 8 Byte

[leuchte1]

@leuchte1
Wie viele Devices insgesamt hast du am 1-Wire Bus angeschlossen? Die Anzahl der Devices wird in board.h definiert und ist firmwareseitig auf 8 begrenzt.

Hallo,
bisher lief nur ein Device, seit heute abend werden 2 erkannt (keine Ahnung warum), sobald ich aber die Leitung verlängere oder ein weiteres anschliesse geht nichts mehr.

Gruss
Stefan

[kaihs]

Ich weiß, dass du am FRAMEBUFER nichts geändert hast. Die Einträge im Logfile haben keinen Zeitstempel. So wie es aussieht, taucht display im Minutentakt auf.

Hm, schon etwas rätselhaft. Wird das Display denn noch aktualisiert?

Die einzige Stelle im Code wo das evtl. herkommen könnte ist

Code Auswählen Erweitern


if (FRAMEBUFFER_readLayout($hash)) {
open($fd, "|".$fbv . ' -d '. $hash->{fhem}{fb_device});
binmode $fd;
print $fd FRAMEBUFFER_returnPNG($name);


Die print Anweisung könnte mglw. zu der Ausgabe führen, aber dazu müsste der open zwei Zeilen darüber fehlschlagen.

- Ist /dev/fb1 noch vorhanden?

Kannst du mal die hervorgehobenen Zeilen ergänzen? Wenn dann das display zwischen den beiden Logausgaben kommt ist das die Ursache.

               Log3 $name, 0, "vor print';
      print $fd FRAMEBUFFER_returnPNG($name);
                Log3 $name, 0, "nach print';


Ich schaue mir den Code noch mal in Ruhe an, ob ich da eine Ursache finden kann.