FHEM Forum

Hallo, ich wollte kurz meinen Homeserver auf Basis eines Banana-PI vorstellen.

Komponenten:
Banana-PI mit Bananian v14-9 und FHEM 5.6
PIFACE PI RACK als Steckboard (leicht modifiziert) um den GPIO-Port zu erweitern und die AddonBoads besser im Gehäuse einzubauen
2x SCC - Stackable CC1101 w/ MPU for Raspberry Pi von Busware (für Homematic und Slow-RF) mit externen 15cm Antennen über 4m Kabel
1x RPI2 I2C to 1-Wire Host Adapter for Raspberry Pi von Sheepwalk Electronics
1x Batterie CR2032 für die Echtzeituhr

Den USB-OTG Anschluss habe ich als USB-A Anschluss nach außen geführt um einen USB Stick als Speicher für die LOG´s und Datensicherung zu verwenden, so sind die beiden  anderen USB Anschlüsse des Banana PI noch frei für andere Anwendungen.

Grüße
cerberus

Wow, cool gemacht.
Hast Du für den Betrieb der SCC-Boards softwaretechnisch was machen müssen, oder laufen die am Banana out of the box?
Würde das SCC mechanisch auch direkt auf den Banana passen?

Gruß

     Olly

Hallo Olly, die SCC´s sind so wie von Busware beschrieben am PI eingerichtet. Direct passt das SCC nicht auf dem Banana, wenn dann musst du einen Stacking Header verwenden. Das war mir zu wackelig, daher hatte ich nach einer anderen Lösung gesucht.

Grüße
cerberus

Hallo cerberus,

super sieht sehr professionell aus.
Hat es einen besonderen Grund warum du keine SSD etc eingebaut hast?

Schöne grüße
Hannes

Gesendet von Tapatalk

Hallo Hannes, ich sehe dafür nicht unbedingt eine Notwenigkeit. Als LOG-Speicher reicht mir ein kostengünstiger USB Stick aus und das Debian + FHEM liegen sinnvollerweise auf einer Class 10 SD-Karte. Die LOG´s werden auf dem Stick gespeichert, so minimiere ich das Risiko mir die SD-Karte zu zerschießen wenn mal ein Stromausfall oder unkontrolliertes Runterfahren des System erfolgt.

Grüße
cerberus

sehr feine Sache ...  ;D

welche Ports belegen deine SCC ? ttyS0 oder ttyS1 ?

Zitat von: cerberus am 14 November 2014, 21:24:45
Hallo Hannes, ich sehe dafür nicht unbedingt eine Notwenigkeit. Als LOG-Speicher reicht mir ein kostengünstiger USB Stick aus und das Debian + FHEM liegen sinnvollerweise auf einer Class 10 SD-Karte. Die LOG´s werden auf dem Stick gespeichert, so minimiere ich das Risiko mir die SD-Karte zu zerschießen wenn mal ein Stromausfall oder unkontrolliertes Runterfahren des System erfolgt.

Grüße
cerberus

Hallo cerberus,

Danke für die Info.
Ich habe es auf dem RasberryPi auch so, und jetzt War die microSD kaputt und komischerweise auch das Dateisystem auf dem USB Sticker :-(

Schöne Grüße
Hannes

Gesendet von Tapatalk

Zitat von: noice am 20 November 2014, 23:23:11
welche Ports belegen deine SCC ? ttyS0 oder ttyS1 ?

Hallo noise, ich habe es so wie von Busware angegeben definiert.

define SCC CUL /dev/ttyS2@38400 1234

Grüße
cerberus

Hi cerberus,
Danke für die info. Bei mir scheint der Port belegt zu sein. Zumindest komm ich nicht auf meinen cul.
Grüße noice

Noice, benutzt du einen Raspberry oder Banana?

Schau mal hier bei Busware, vielleicht hilft das weiter.

http://busware.de/tiki-index.php?page=SCC_Installation (http://busware.de/tiki-index.php?page=SCC_Installation)

Hi cerberus, ich benutze den banana pi allerdings mit dem addon board von locutus und einem anderen image. Die Installation hab ich schon versucht Danke.

Zitat von: noice am 21 November 2014, 20:16:52
Hi cerberus, ich benutze den banana pi allerdings mit dem addon board von locutus und einem anderen image. Die Installation hab ich schon versucht Danke.

Hast Du eine Lösung gefunden? Ich krieg den COC weder unter bananian noch unter Raspbian auf dem BPi ans laufen. Laut fhem log schlägt der init auf ttyS2 fehl. Der COC ist in Ordnung. Wenn ich ihn auf den Raspi zurückstecke läuft er einwandfrei.

2014.12.20 23:56:23 3: Opening COC device /dev/ttyS2
2014.12.20 23:56:23 3: Setting COC baudrate to 38400
2014.12.20 23:56:23 3: COC device opened
2014.12.20 23:56:32 1: Cannot init /dev/ttyS2, ignoring it (COC)

Die Lösung ist das freischalten der seriellen Schnittstelle am BPi... Ich gugg im laufe des Tages nochmal nach der Lösung im detail ...

--- Mobil erstellt daher kurz gehalten --

Das wär Klasse! Danke im Voraus  :)

Etwas seltsam sehen die Rechte der ttyS* aus. ttyS0 ist in einer anderen Gruppe. Irgendwie bekommt ttyS2 immer ein neues Datum wenn ich fhem starte. fhem läuft unter root (htop) wenn ich das richtig sehe und sollte ja eigentlich zugreifen dürfen. Wie kann ich aus fhem ein paar mehr Meldungen rauskitzeln als dieses "Cannot init ". Selbst mit verbose 5 kommt nur das:

2014.12.21 13:29:55 5: Cmd: >define COC CUL /dev/ttyS2@38400 1234<
2014.12.21 13:29:55 5: Loading ./FHEM/00_CUL.pm
2014.12.21 13:29:55 3: Opening COC device /dev/ttyS2
2014.12.21 13:29:55 3: Setting COC baudrate to 38400
2014.12.21 13:29:55 3: COC device opened
2014.12.21 13:29:55 5: SW: V
2014.12.21 13:29:58 5: SW: V
2014.12.21 13:30:01 5: SW: V
2014.12.21 13:30:04 1: Cannot init /dev/ttyS2, ignoring it (COC)

stty bringt das (9600???) - wenn ich im define 9600 setze klappt es aber auch nicht
root@bananapi ~ # stty -F /dev/ttyS2
speed 9600 baud; line = 0;
kill = ^H; min = 100; time = 2;
-icrnl -imaxbel
-opost -onlcr
-isig -icanon -echo


root@bananapi ~ # ls -l /dev/ttyS*
crw-rw---- 1 root tty     4, 64 Jan  1  2010 /dev/ttyS0
crw-rw---T 1 root dialout 4, 65 Jan  1  2010 /dev/ttyS1
crw-rw---T 1 root dialout 4, 74 Jan  1  2010 /dev/ttyS10
crw-rw---T 1 root dialout 4, 75 Jan  1  2010 /dev/ttyS11
crw-rw---T 1 root dialout 4, 76 Jan  1  2010 /dev/ttyS12
crw-rw---T 1 root dialout 4, 77 Jan  1  2010 /dev/ttyS13
crw-rw---T 1 root dialout 4, 78 Jan  1  2010 /dev/ttyS14
crw-rw---T 1 root dialout 4, 79 Jan  1  2010 /dev/ttyS15
crw-rw---T 1 root dialout 4, 80 Jan  1  2010 /dev/ttyS16
crw-rw---T 1 root dialout 4, 81 Jan  1  2010 /dev/ttyS17
crw-rw---T 1 root dialout 4, 82 Jan  1  2010 /dev/ttyS18
crw-rw---T 1 root dialout 4, 83 Jan  1  2010 /dev/ttyS19
crw-rw---T 1 root dialout 4, 66 Dec 21 02:01 /dev/ttyS2
crw-rw---T 1 root dialout 4, 84 Jan  1  2010 /dev/ttyS20
crw-rw---T 1 root dialout 4, 85 Jan  1  2010 /dev/ttyS21
crw-rw---T 1 root dialout 4, 86 Jan  1  2010 /dev/ttyS22


Hier noch was aus dem Banana Log
root@bananapi ~ # dmesg | grep ttyS
[    0.000000] Kernel command line: console=ttyS0,115200 console=tty0 sunxi_g2d_mem_reserve=0 sunxi_ve_mem_reserve=0 disp.screen0_output_mode=EDID:1280x720p50 hdmi.audio=EDID:0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
[    0.654588] sunxi-uart.0: ttyS0 at MMIO 0x1c28000 (irq = 33) is a U6_16550A
[    1.259811] console [ttyS0] enabled
[    1.300026] sunxi-uart.2: ttyS1 at MMIO 0x1c28800 (irq = 35) is a U6_16550A
[    1.343651] sunxi-uart.3: ttyS2 at MMIO 0x1c28c00 (irq = 36) is a U6_16550A
[    1.387248] sunxi-uart.7: ttyS3 at MMIO 0x1c29c00 (irq = 52) is a U6_16550A
root@bananapi ~ #


Nach einiger googelei habe ich einblick in die script.bin bekommen. Sieht eigentlich eingeschaltet aus?!

[uart_para3]
uart_used = 1
uart_port = 3
uart_type = 2
uart_tx = port:PH00<4><1><default><default>
uart_rx = port:PH01<4><1><default><default>


so ..
also ich musste meien UART3 schnittstelle freischalten. Allerdings benutze ich ein anderes Image.
das ganze habe ich mit bin2fex und fex2bin machen müssen
root@bananapi:/boot# bin2fex  bananapi.bin bananapi.fex

danach muss die bananapi.fex editiert werden:
[uart_para3]
uart_used = 0 <--- auf 1 setzen ..

dann das ganze wieder umgekert in .bin zurückschreiben
root@bananapi:/boot# fex2bin  bananapi.fex bananapi.bin

ups seh gerade du nutz ja ttyS2 .. bei mir läuft das unter ttyS1

bin mir jetzt nicht sicher unter welche UART der SCC läuft da es ja bei mir das addon Board von Locutus ist

ttyS2 gibt busware vor. Der para3 ist bei mir bereits eingeschaltet  :-\

[uart_para2]
uart_used = 1
uart_port = 2
uart_type = 4
uart_tx = port:PI18<3><1><default><default>
uart_rx = port:PI19<3><1><default><default>
uart_rts = port:PI16<3><1><default><default>
uart_cts = port:PI17<3><1><default><default>

[uart_para3]
uart_used = 1
uart_port = 3
uart_type = 2
uart_tx = port:PH00<4><1><default><default>
uart_rx = port:PH01<4><1><default><default>

[uart_para4]
uart_used = 0
uart_port = 4
uart_type = 2
uart_tx = port:PH04<4><1><default><default>
uart_rx = port:PH05<4><1><default><default>

[uart_para5]
uart_used = 0
uart_port = 5
uart_type = 2
uart_tx = port:PH06<4><1><default><default>
uart_rx = port:PH07<4><1><default><default>

[uart_para6]
uart_used = 0
uart_port = 6


mal mit ttyS1 probiert?

Joa, ich habe schon alle durchprobiert. Ich komm mit der Pin Bezeichnung in der Script.bin nicht wirklich klar. Sond denn PH00 und PH01 die Pins, die COC oder SCC benutzen? Laut dieser Seite wären das die physischen Pins 8 und 10

RPi: http://www.elektronik-kompendium.de/sites/raspberry-pi/1907101.htm
BPi: https://microdotup.wordpress.com/2014/07/04/87/

Sollte gleich sein und passen.

Laut dem hier ist es auch aktiv und laut bootlog liegt es auf ttyS2

[uart_para3]
uart_used = 1
uart_port = 3
uart_type = 2
uart_tx = port:PH00<4><1><default><default>
uart_rx = port:PH01<4><1><default><default>


screen /dev/ttyS2 38400 bringt mir auch nur eine leer konsole die auf nix reagiert. Ich bin so langsam am verzweifeln

jetzt steh ich auch etwas aufm schlauch .. mal ein anderes Image probiert?

die Anleitung von Busware hast du aber schon gemacht ... ?

Naja, was heißt Anleitung? Die GPIO 17+18 fahre ich in der rc.local ab. COC bestätigt den Reset auch mit 1x kurz aufblitzen. Verweise auf ttyAMA0 in der inittab gibt es nicht - wäre ja auch quatsch, da es den Anschluß auf dem BPi nicht gibt. Eine cmdline.txt gibt es auf dem BPi nicht. Mehr Anleitung ist ja nicht auf Busware. Die Firmware ist auf dem COC ja bereits vorhanden. Steck ich den COC auf den alten RPi funktioniert FHEM dort auf Anhieb.

Neben Bananian habe ich auch Raspbian getestet (allerdings nicht so intensiv wie Bananian)

Es gibt eine uEnv.txt (vermutlich als ersatz für die cmdline.txt) Aber auch da wird ttyS2 nicht irgendwie blockiert
bootargs=console=ttyS0,115200 console=tty0 sunxi_g2d_mem_reserve=0 sunxi_ve_mem_reserve=0 disp.screen0_output_mode=EDID:1280x720p50 hdmi.audio=EDID:0 c$
aload_script=fatload mmc 0 0x43000000 script.bin;
aload_kernel=fatload mmc 0 0x48000000 uImage; bootm 0x48000000;
uenvcmd=run aload_script aload_kernel


http://www.igorpecovnik.com/2014/09/07/banana-pi-debian-sd-image/ ich benutze dieses image... aber nur weil da die Display Treiber im Kernel sind
Evtl kann cerberus da weiter helfen... ich bin da leider raus...

Sollte mir noch was einfallen poste ich es hier

Ich habe das COC grad wieder auf den RPI gesteckt. Dabei fiel mir auf, das der COC nach dem Init schon arbeitet (ich hatte in FHEM noch ttyS2 eingestellt, was es auf dem RPI nicht gibt) Also geht scheinbar der Reset schief und COC initialisiert sich gar nicht auf dem BPi

An welcher stelle führst Du den init (echo pin 17/18) durch? Bei mir ist das in der rc.local, bevor fhem gestartet wird. Ist das eventuell zu früh oder passt da was nicht?


Kann es sein, das der UART2 die pins 17/18 belegt und diese dann nicht per echo gesetzt werden können bzw. müll bei rauskommt? Wobei ich nicht weiß ob PI18 dem /sys/class/gpio/gpio18 entspricht

[uart_para2]
uart_used = 1
uart_port = 2
uart_type = 4
uart_tx = port:PI18<3><1><default><default>
uart_rx = port:PI19<3><1><default><default>
uart_rts = port:PI16<3><1><default><default>
uart_cts = port:PI17<3><1><default><default>


den benötige ich normal nicht dem SCM.
Ich hatte aber irgendwo hier im forum gelesen das das jemand geändert hat ... also die startreihenfolge

hast du wiringPi installiert?

bekommst du unter fhem ein "opened" vom Cul wenn du das COC nicht installiert hast?

Ja, die wiringPi habe ich installiert, weil ich das gpio readall nicht hatte.

Das opened teste ich morgen - heute ist die Luft raus.

Jedenfalls nehme ich ganz stark an, das das COC nicht resettet wird. Nach einem Reset muß die gelbe LED blinkern wenn Telegramme eingehen. Das COC arbeitet ja quasi autark. Ich habe FHEM auf nem USB Stick, den ich für RPi und BPi gleichermaßen nutzen kann. Ich muß nur das Devive für das COC ändern. Beim Booten des RPi steht das noch auf ttyS2 was auf dem RPi ja fehlschlägt. Trotzdem empfängt das COC munter Telegramme und blitzt vor sich hin. Auf dem BPi ist das nicht so. Dort blitzt beim Reset die led nur kurz auf und dann nichts mehr

Ich habe mir die 17/18 auch mal angeschaut. Der 18er sieht nach dem Reset genauso aus wie der 17 unten

BPi:
root@bananapi /sys/class/gpio/gpio17 # ls -l
total 0
-rw-r--r-- 1 root root 4096 Dec 22 00:02 active_low
lrwxrwxrwx 1 root root    0 Dec 22 00:02 device -> ../../../gpio-sunxi/
-rw-r--r-- 1 root root 4096 Dec 21 23:59 direction
-rw-r--r-- 1 root root 4096 Dec 22 00:02 edge
drwxr-xr-x 2 root root    0 Dec 22 00:02 power/
-rw-r--r-- 1 root root 4096 Dec 22 00:02 pull
lrwxrwxrwx 1 root root    0 Dec 21 23:59 subsystem -> ../../../../../class/gpio/
-rw-r--r-- 1 root root 4096 Dec 21 23:59 uevent
-rw-r--r-- 1 root root 4096 Dec 21 23:59 value
root@bananapi /sys/class/gpio/gpio17 # cat value
1
root@bananapi /sys/class/gpio/gpio17 # cat direction
out

RPi:
root@raspberrypi:~# cd /sys/class/gpio/gpio17
root@raspberrypi:/sys/class/gpio/gpio17# ls -l
total 0
-rwxrwx--- 1 root gpio 4096 Dec 21 23:13 active_low
-rwxrwx--- 1 root gpio 4096 Dec 21 23:13 direction
-rwxrwx--- 1 root gpio 4096 Dec 21 23:13 edge
drwxrwx--- 2 root gpio    0 Dec 21 23:13 power
lrwxrwxrwx 1 root gpio    0 Dec 21 23:13 subsystem -> ../../../../class/gpio
-rwxrwx--- 1 root gpio 4096 Dec 21 23:13 uevent
-rwxrwx--- 1 root gpio 4096 Dec 21 23:13 value
root@raspberrypi:/sys/class/gpio/gpio17# cat direction
out
root@raspberrypi:/sys/class/gpio/gpio17# cat value
1
root@raspberrypi:/sys/class/gpio/gpio17#

Mir fallen da auf Anhieb die Berechtigungen auf ... weiss aber nicht ob es damit zu tun hat

ach ähm .. das schon gemacht?

Man muss in der /etc/init.d/fhem unter Start folgendes einfügen.


if test ! -d /sys/class/gpio/gpio17; then echo 17 > /sys/class/gpio/export; fi
echo out > /sys/class/gpio/gpio17/direction
echo 1 > /sys/class/gpio/gpio17/value


Das verstehe ich jetzt nicht. In diesem Block (busware Anleitung) wird doch das gemacht und das steht in der rc.local

echo "resetting 868MHz extension..."
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 1 > /sys/class/gpio/gpio18/value
echo 0 > /sys/class/gpio/gpio17/value                                                                              <----------------
sleep 1
echo 1 > /sys/class/gpio/gpio17/value                                                                              <----------------
sleep 1

Also meine  /etc/init.d/fhem schaut wie folgt aus.

#!/bin/sh
# description: Start or stop the fhem server
# Added by Alex Peuchert

### BEGIN INIT INFO
# Provides:             fhem.pl
# Required-Start:       $local_fs $remote_fs
# Required-Stop:        $local_fs $remote_fs
# Default-Start:        2 3 4 5
# Default-Stop:         0 1 6
# Short-Description:    FHEM server
### END INIT INFO

set -e
cd /opt/fhem
port=7072

case "$1" in
'start')
if test ! -d /sys/class/gpio/gpio17; then echo 17 > /sys/class/gpio/export; fi
echo out > /sys/class/gpio/gpio17/direction
echo 1 > /sys/class/gpio/gpio17/value
        echo "Starting fhem..."
        perl fhem.pl fhem.cfg
        RETVAL=$?
        ;;
'stop')
        echo "Stopping fhem..."
        perl fhem.pl $port "shutdown"
        RETVAL=$?
        ;;
'status')
        cnt=`ps -ef | grep "fhem.pl" | grep -v grep | wc -l`
        if [ "$cnt" -eq "0" ] ; then
                echo "fhem is not running"
        else
                echo "fhem is running"
        fi
        ;;
*)
        echo "Usage: $0 { start | stop | status }"
        RETVAL=1
        ;;
esac
exit $RETVAL


Hallo!
habe das selbe problem mit dem IgorPecovnik Image, bekomme ttyS2 einfach nciht zum laufen :(

Habe leider auch noch keine Lösung  :-\

@Waldmensch: Ich habe hier auch einen BPI liegen, der mich ganz und gar nicht mag - Ähnliches Phenomen. Ich habe es nun aufgegeben - das Ding geht zurück. Schade eigentlich ;)

Hallo zusammen,
ich habe es geschafft einen Banana PRO mit dem Busware Pigator Onewire (mit CC1101 Modul) zum laufen zu bringen. ;D
.... an der Scnittstelle /dev/ttyS3

Gruß
Klaus

Welches Image hast Du für den Bananian genommen? Hast Du noch irgendwas am System "präpariert"?

Hallo,
das ist das "Raspian-Image", und "präpariert" habe ich auch so einiges.
- UART3 Schnittstelle freischalten (mit bin2fex und fex2bin die script.bin geändert)
-  RPi.GPIO installiert http://wiki.lemaker.org/RPi.GPIO (http://wiki.lemaker.org/RPi.GPIO)

und noch wie in der Busware-Anleitung beschrieben in der  /etc/rc.local Datei folgendes eingetragen:
> Many modules use the RESET pin. To enable those you must pull RESET HIGH by doing: <
echo 22 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio22/direction
echo 1 > /sys/class/gpio/gpio22/value

Gruß
Klaus

Okay, dann werde ich mir das Projekt nochmal auf den Tisch ziehen. Danke Dir

Probleme machte mir auch noch die 1-Wire Schnittstelle.
Abhilfe:
in der /etc/owfs.conf Datei folgende Zeile geändert:

server: port = 4304
das stand vorher
server = localhost:4304

Dadurch konnte ich per fhem nicht auf die 1Wire devices zugreifen.

Gruß
Klaus

Hallo dampf123

habe das gleiche Problem mit meinem BPi  :-\ ... Deine Lösung schreit förmlich nach einer Anleitung für Alle.
Hättest Du nicht Lust uns Schritt f. Schritt den Weg zu zeigen? Wäre ne Super Sache!!!  ;)

Gruß TeleDet

Moin zusammnen,
so eine Step by Step Anleitung werde ich wohl auch nicht reproduzierbar bringen können, da nicht der "Linux Guru" bin.
Es gibt da wohl zu viele verschiedene Hardware und Software Voraussetzungen.  :-\

Soweit es mir möglich ist, gebe ich natürlich gerne meine Erfahrungen weiter. Dazu ist ja schließlich das Forum da.

Gruß
Klaus

Das kann ich jetzt richtig gut nachvollziehen  ;) geht mir auch öfter so  :)
Man liest viele Lösungen für ein Problem, macht dies und das, plötzlich funktioniert
es und man kann eigentlich nicht mehr sagen welche Kombination dazu geführt hat.  ;D

Danke trotzdem das du hier hilfst!!!

Vieleicht kannst Du mir zumindest auf die Sprünge helfen wie du

Zitatmit bin2fex und fex2bin die script.bin geändert

hast?

Gruß TeleDet

Hallo TeleDet (hast du auch einen richtigen Namen ?)

klar kann ich versuchen dir auf die Sprünge zu helfen.
Was ist dir denn konkret unklar ?
Hast du das Tool zum konvertieren der script.bin in eine lesbare Text-Datei (.fex) schon installiert ?
das gibt es hier: http://linux-sunxi.org/Sunxi-tools (http://linux-sunxi.org/Sunxi-tools)
und hier ist eine Anleitung, an der ich mich orientiert hatte: http://www.forum-cubieboard.de/Thread-boot-script-bin-bearbeiten (http://www.forum-cubieboard.de/Thread-boot-script-bin-bearbeiten)

Hilft dir das schon weiter ?

Gruß
Klaus

hallo dampf123

danke für die schnelle Antwort  :) Jede Info hilft immer irgendwie weiter  ;) ... eine änliche Anleitung hatte ich hier : http://www.rdklein.eu/rdpiforum/viewtopic.php?f=61&t=2641 (http://www.rdklein.eu/rdpiforum/viewtopic.php?f=61&t=2641)
auch schon gefunden. Mich würde eher interessieren welche Änderungen Du an der script.bin genau vorgenommen hast.

Gruß TeleDet

Hallo TeleDet,

ich habe in der script.bin nur

[uart_para3]
uart_used = 1
uart_port = 3
uart_type = 2
uart_tx = port:PH00<4><1><default><default>
uart_rx = port:PH01<4><1><default><default>

uart_used = 0   auf 1 geändert, das was hier auch schon vorne so beschrieben was ....

Gruß
Klaus

Hallo dampf123,

super dann lag ich doch schon richtig.  ;) Ich hatte fast befürchtet es musse noch mehr geändert werden!
Vielen Dank erst mal für Deine Hilfe ich werde es am WE ausprobieren und hoffe das es klappt.  ;)

Gruß TeleDet

Zitat von: cerberus am 14 November 2014, 09:31:26
1x Batterie CR2032 für die Echtzeituhr

Kannst du dazu noch was sagen?

An welchen der beiden Batterieanschlüsse muss die Knopfzelle, an BAT oder BAT1?

Muss dann noch softwareseitag was konfiguriert/installiert werden oder läuft das out of the box?

Kai

Zitat von: dampf123 am 11 März 2015, 19:56:14
ich habe in der script.bin nur

Code Auswählen Erweitern

[uart_para3]
uart_used = 1
uart_port = 3
uart_type = 2
uart_tx = port:PH00<4><1><default><default>
uart_rx = port:PH01<4><1><default><default>

uart_used = 0   auf 1 geändert, das was hier auch schon vorne so beschrieben was ....

Das hatte ich auch gemacht und bei mir lief es zuerst damit alleine auch nicht.

Da ich mein busware COC (http://busware.de/tiki-index.php?page=COC), das bisher klaglos auf einem Raspberry Pi B (ohne +) lief, inzwischen auf einem Banana Pi zum laufen gebracht habe und meine Änderungen auch nachvollziehen kann, hier meine Erfahrungen.

Vorab zwei Hinweise:

1. Zum schnellen Test des COC, ohne fhem zu starten, kann man screen benutzen:

screen /dev/ttyS2 38400

und danach mal die Taste V mit Enter eingeben, sollte die Version der COC Firmware auswerfen. screen selbst kann man mit Strg-A k beenden.

2. Das COC wird bei mir wie auf dem Raspberry Pi immer erst zurückgesetzt. An welcher Stelle und wann man das macht, ist egal - es muss nur vor der Benutzung aktiviert werden. Man kann den folgenden Code in /etc/rc.local schreiben oder auch ins fhem Startskript /etc/init.d/fhem einfügen oder als separates Script speichern und ausführen.

Beispiel:

sudo nano /usr/local/bin/coc_reset.sh

Dann den Reset Code eingeben

echo "resetting 868MHz extension..."
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 1 > /sys/class/gpio/gpio18/value
echo 0 > /sys/class/gpio/gpio17/value
sleep 1
echo 1 > /sys/class/gpio/gpio17/value
sleep 1


und speichern. Zum Schluss die Datei noch ausführbar machen mit

sudo chmod +x /usr/local/bin/coc_reset.sh

und schon kann man jederzeit das COC mit Hilfe von /usr/local/bin/coc_reset.sh aktivieren.

---

Ich hatte erst mal verschiedene Images ausprobiert und folgendes festgestellt:

• Mit dem Lemaker Raspian for BananaPi v1412 (http://www.lemaker.org/resources/9-81/raspbian_for_bananapi.html) lief das COC sofort ohne Änderungen auf ttyS2. Dort fehlt aber der mir wichtige lirc raw Treiber sunxi_lirc, der dort vorhandene sunxi_ir läuft nur mit Fernbedienungen mit NEC Code.
• Beim Debian Wheezy Image 3.4.106 (http://mirror.igorpecovnik.com/Bananapi_Debian_2.4_wheezy_3.4.106.zip) von Igor Pečovnik (http://www.igorpecovnik.com/2014/09/07/banana-pi-debian-sd-image/) ist der lirc raw Treiber sunxi_lirc dabei, dafür funktionierte wie bei einigen Postern hier der COC nicht.
  Und genau hier habe ich mit meinen Änderungen angesetzt.

Ich habe die GPIO Konfigurationsdateien beider Systeme verglichen und da es kaum Unterschiede gab, die einzelnen Änderungen vom Lemaker Raspian Image in das Image von Igor nach und nach übernommen.
Beim Lemaker Image stecken die Infos in /boot/script.bin, beim Igor Image in /boot/bananapi.bin. Die Konfigurationsdateien müssen zuerst mit hilfe von bin2fex in ein lese- und editierbares Fex Format gewandelt werden, bei Igors Image heisst die Datei /boot/bananapi.bin

sudo bin2fex /boot/bananapi.bin /boot/bananapi.fex

Mir sind beim Image Igor Pečovnik (http://www.igorpecovnik.com/2014/09/07/banana-pi-debian-sd-image/) zwei Dinge aufgefallen, ein Fehler und eine Besonderheit:

• Besonderheit:
  Wenn man uarts mit uart_used = 1 aktiviert, kann es sein dass der Port nicht mit dem in der Konfigurations unter uart_port angegebenen Nummer übereinstimmt. Man testet danach einfach hoffnungslos ständig auf dem falschen Port.
  Das passiert dann, wenn man Lücken erzeugt, d.h. z.B. man aktiviert Port 0 (ttyS0), aber nicht Port 1 (was ja ttyS1 sein soll) oder 2 (ttyS2) und aktiviert dann aber wie von dampf123 geschrieben Port 3 (was ttyS3 sein sollte). Das System erstellt aber trotz der Angabe uart_port = 3 in unserem Bespiuel hier nur ttyS0  und ttyS1. Die Konfiguration von dampf123 wäre in diesem Fall (uart_used für [uart_para1] und [uart_para2] wären 0) so, dass ttyS0 die interne UART0 Schnittstelle ist und ttyS1 der COC
• Fehler in der Konfiguration:
  Auch mit der Kenntnis aus 1. konnte ich das COC bei mir immer noch nicht ansprechen! Da das COC für die serielle Kommunikation lediglich den Reset über gpio17 und gpio18 braucht (die gelbe LED blinkt dann im Sekundentakt) und dazu vier Banana Pi Ports benutzt, nämlich PH00 für TX, PH01 für RX, PI19 als gpio17 und PA02 als gpio18, musste der Fehler in der Konfiguration für PH00 oder PH01 zu suchen sein.

---

Ich habe also den Port für den COC aktiviert und den Fehler in der Konfigurationsdatei beseitigt. Hier meine Vorgehensweise:

1. Das Debian Wheezy Image 3.4.106 (http://mirror.igorpecovnik.com/Bananapi_Debian_2.4_wheezy_3.4.106.zip) von Igor Pečovnik (http://www.igorpecovnik.com/2014/09/07/banana-pi-debian-sd-image/) runterladen und auf eine SD-Karte installieren.

2. Nach dem booten auf dem BananaP Pi einloggen.

3. Die Konfigurationsdatei umwandeln

sudo bin2fex /boot/bananapi.bin /boot/bananapi.fex

4. Mit sudo nano /boot/bananapi.fex die Konfiguration bearbeiten.

Hier meine i2C-Bus und uart Konfiguration:

[twi0_para]
twi0_used = 1
twi0_scl = port:PB00<2><default><default><default>
twi0_sda = port:PB01<2><default><default><default>

[twi1_para]
twi1_used = 1
twi1_scl = port:PB18<2><default><default><default>
twi1_sda = port:PB19<2><default><default><default>

[twi2_para]
twi2_used = 1
twi2_scl = port:PB20<2><default><default><default>
twi2_sda = port:PB21<2><default><default><default>

[twi3_para]
twi3_used = 1
twi3_scl = port:PI00<3><default><default><default>
twi3_sda = port:PI01<3><default><default><default>

[uart_para0]
uart_used = 1
uart_port = 0
uart_type = 2
uart_tx = port:PB22<2><1><default><default>
uart_rx = port:PB23<2><1><default><default>

[uart_para1]
uart_used = 0
uart_port = 1
uart_type = 8
uart_tx = port:PA10<4><1><default><default>
uart_rx = port:PA11<4><1><default><default>
uart_rts = port:PA12<4><1><default><default>
uart_cts = port:PA13<4><1><default><default>
uart_dtr = port:PA14<4><1><default><default>
uart_dsr = port:PA15<4><1><default><default>
uart_dcd = port:PA16<4><1><default><default>
uart_ring = port:PA17<4><1><default><default>

[uart_para2]
uart_used = 1
uart_port = 2
uart_type = 4
uart_tx = port:PI18<3><1><default><default>
uart_rx = port:PI19<3><1><default><default>
uart_rts = port:PI16<3><1><default><default>
uart_cts = port:PI17<3><1><default><default>

[uart_para3]
uart_used = 1
uart_port = 3
uart_type = 2
uart_tx = port:PH00<4><1><default><default>
uart_rx = port:PH01<4><1><default><default>

[uart_para4]
uart_used = 0
uart_port = 4
uart_type = 2
uart_tx = port:PH04<4><1><default><default>
uart_rx = port:PH05<4><1><default><default>

[uart_para5]
uart_used = 0
uart_port = 5
uart_type = 2
uart_tx = port:PH06<4><1><default><default>
uart_rx = port:PH07<4><1><default><default>

[uart_para6]
uart_used = 0
uart_port = 6
uart_type = 2
uart_tx = port:PA12<4><1><default><default>
uart_rx = port:PA13<4><1><default><default>

[uart_para7]
uart_used = 1
uart_port = 7
uart_type = 2
uart_tx = port:PI20<3><1><default><default>
uart_rx = port:PI21<3><1><default><default>


Zusätzlich die Konfiguration für usbc0 mit folgendem ersetzen:

[usbc0]
usb_used = 1
usb_port_type = 2
usb_detect_type = 1
usb_id_gpio = port:PH04<0><1><default><default>
usb_det_vbus_gpio = port:PH05<0><0><default><default>
usb_drv_vbus_gpio = port:PB09<1><0><default><0>
usb_restrict_gpio = port:PH00<1><0><default><0>
usb_host_init_state = 0
usb_restric_flag = 0
usb_restric_voltage = 3550000
usb_restric_capacity = 5


Hier stecken zwei Änderungen:
usb_detect_type sollte  1 sein und usb_restrict_gpio hatte eine Schreibfehler, der wohl zu Ungereimtheiten auf PH00 (das ist der COC TX) führten.

Das ganze mit Strg-o [Enter] und Strg-x speichern und nano beenden.

5. Die Konfiguration ins Binärformat zurückwandeln

sudo fex2bin /boot/bananapi.fex /boot/bananapi.bin


So, nach dem Booten (sudo reboot) sollte das COC mit Hilfe von /usr/local/bin/coc_reset.sh anfangen zu blinken und sich mit screen /dev/ttyS2 38400 (hier mal das große V und [Enter] eingeben, verlassen mit Strg-A k) ansprechen lassen. Achtung, Hinweis von oben beachten: Der Port ist hier nicht, wie die Konfiguration vermuten läßt, mit ttyS3 sondern mit ttyS2 erreichbar. Das kommt daher, das [uart_para1] uart_used = 0 ist - das verschiebt die Portnummerierung, obwohl es dafür das Keyword uart_port gibt.

Wenn das funktioniert, kann man das fest in fhem.cfg eintragen:

define COC CUL /dev/ttyS2@38400 1234


Hoffe, euer COC läuft nun auch mit eurem Banana Pi.


Gruß, Norbert

Vielen Dank für die Anleitung. Ich habe sie genau 1:1 befolgt und auch den typo gefunden. Leider kommt unter screen nichts wenn ich V + Return eingebe. Beim Reset blitzt mein COC auch nur einmal ganz kurz, statt zu blinken. Das COC funzt an einem Raspberry einwandfrei.

Der Serial relevante Teil in dmesg:

[    0.517099] msgmni has been set to 1441
[    0.524781] alg: No test for stdrng (krng)
[    0.531542] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
[    0.534498] io scheduler noop registered
[    0.537749] io scheduler deadline registered
[    0.541472] io scheduler cfq registered (default)
[    0.546377] sunxi disp driver loaded (/dev/disp api 1.0)
[    0.551959] Serial: 8250/16550 driver, 8 ports, IRQ sharing disabled
[    0.556814] [uart]: used uart info.: 0x8d
[    0.561553] [uart]: serial probe 0 irq 33 mapbase 0x01c28000
[    0.585210] sunxi-uart.0: ttyS0 at MMIO 0x1c28000 (irq = 33) is a U6_16550A
[    0.590148] [uart]: serial probe 2 irq 35 mapbase 0x01c28800
[    0.613710] sunxi-uart.2: ttyS1 at MMIO 0x1c28800 (irq = 35) is a U6_16550A
[    0.618601] [uart]: serial probe 3 irq 36 mapbase 0x01c28c00
[    0.642158] sunxi-uart.3: ttyS2 at MMIO 0x1c28c00 (irq = 36) is a U6_16550A
[    0.647026] [uart]: serial probe 7 irq 52 mapbase 0x01c29c00
[    0.670572] sunxi-uart.7: ttyS3 at MMIO 0x1c29c00 (irq = 52) is a U6_16550A
[    0.673166] G2D: drv_g2d_init
[    0.676541] G2D: Module initialized.major:250
[    0.685754] brd: module loaded
[    0.691775] loop: module loaded
[    0.694075] nand driver is disabled
[    0.697864] gpio count < =0 ,gpio_count is: 0
[    0.703841] sw_ahci sw_ahci.0: controller can't do PMP, turning off CAP_PMP
[    0.708348] ahci: SSS flag set, parallel bus scan disabled
[    0.715782] sw_ahci sw_ahci.0: AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl platform mode


Dann schau dir mal deine Fex-Datei genauer an. Irgendeine Device-Einstellung benutzt bei dir den PI19 (=gpio17) und/oder PA02 (gpio18). Wenn ein anderer Gerätetreiber die gleichen Pins wie die für den COC-Betrieb in beschlag nimmt, kannst du reseten bist du schwarz wirst - du legst die beiden Pins gpio17 und 18 zwar mit dem Reset-Script entsprechend, aber ein anderer Treiber setzt diese sofort wieder zurück.
Falls du nicht weiterkommst, schick mal deine Fex (oder Bin) Konfigurationsdatei, ich schau dann gerne mal rein...

Gruß,
Norbert

Vielen Dank! Die Fex Datei ist im Anhang. Das COC ist die Version mit RTC und onewire. Ich hatte auch schon das bananian Image getestet - war genau das selbe. Das Image ist ganz frisch runtergeladen und nur die Fex Datei ist geändert wie oben beschrieben. Am Banana hängt nichts weiter dran. Der Banana ist ein Banana Pro mit WLAN on Board

Edit: In der Fex Datei haben die Ports alle eine andere Syntax. Ich habe keinen Plan was gpio18/17 übersetzt in diese PXxx sind. Sonst hätte ich auch schonmal gesucht. Es gibt da zwar ein paar Tabellen im Netz, aber nichts woraus ich schlau werde. Das einzige wäre dies http://www.elektronik-kompendium.de/sites/raspberry-pi/1907101.htm woraus ich den gpio17 als PI19 erkenne und sehe, das er am uart_para2 genutzt wird

Dein Link mit der PIN-Belegung der BPi ist goldrichtig:

Ich habe wohl das gleich COC (http://busware.de/tiki-index.php?page=COC) - im Schaltplan (http://busware.de/tiki-download_file.php?fileId=68) siehst du, dass das COC folgende PINx verwendet (Spannungsversorgung hab ich hier weggelassen):

COC	GPIO Leiste	RaspberryPi	BananaPI (Angabe in der .Fex)
TX	PIN8	GPIO 14	PH00
RX	PIN10	GPIO 15	PH01
MOD_RESET	PIN11	GPIO 17	PI19
MOD_BS	PIN12	GPIO 18	PH02
I2C Data (SDA)	PIN3	GPIO 2	PB21
I2C Clk (SCL)	PIN5	GPIO 3	PB20

Bei Ansprechen der Ports für den Reset hast du leider die Bezeichnungen vom Raspberry (da eben gpio17 und gpio18), in der .Fex nimmst du Bezug auf die BananaPi Ports - daher kommt die Verwirrung.

Alles was mit in der .Fex PH00, PH01, PI19 und PH02 kolldiert könnte problematisch sein.


Die Fex für deinen Pro hat u.a. auch eine andere Konfiguration für z.B. Wifi

Versuch es mal mit der Änderung die ich anhängt habe. Dort sind genau die Änderungen für meinen BPi drin.

Die COC Schnittstelle sollte hier auf /dev/ttyS2 sein und das COC muss nach dem Reset dauerhaft im Sekundentak blinken. Ansonsten nimm dir auch mal deine boot.cmd vor, ich habe dort alles unnötige mit ttyS1/ttyS2 raus:
(Beachte: Ich habe einen anderen Kernel, den für den BPi, da steht bei dir dann wohl der Pro Kernel)

setenv bootargs console=tty0 consoleblank=0 disp.screen0_output_mode=EDID:1280x720p60 hdmi.audio=EDID:0 root=/dev/mmcblk0p1 rootwait sunxi_ve_mem_reserve=0 sunxi_g2d_mem_reserve=0 sunxi_no_mali_mem_reserve sunxi_fb_mem_reserve=16 panic=10
ext4load mmc 0 0x43000000 /boot/bananapi.bin
ext4load mmc 0 0x48000000 /boot/vmlinuz-3.4.106-bananapi
bootz 0x48000000


Änderungen an der boot.cmd musst du noch umwandeln mit:

sudo mkimage -C none -A arm -T script -d boot.cmd boot.scr


Im Übrigen hilft die dmesg Ausgabe hier nix, die gibt auch nur das wieder was in der .Fex konfiguriert wurde aber nicht was tatsächlich funktioniert - hier hilft nur der Test mir screen.

Würde mich langsam wundern, wenn es mit der .Fex hier auch nicht funktioniert...

Ich habe exakt das image, was du verlinkt hast. Meinst Du das hat 2 unterschiedliche configurationen/ kernel eingebaut? In jedem Fall teste ich dein fex heute abend.


Edit: Mit Deiner .fex leider keine Änderung, es bleibt bei 1x kurz aufblitzen beim starten des Reset Script. Entsprechend bei Screen auch keine Ausgabe. Die boot.cmd finde ich nirgendwo, muß ich die erst erstellen?

Edit2: irgendwie habe ich hier im Forum keinen Antworten Button mehr. Ich kann nur meinen bestehenden Beiträge editieren :-/

Edit3: boot.cmd gefunden. Da ist aber nichts drin mit ttyS1 oder 2. Also auch nix zu entfernen

Der Antworten Button ist wieder da :)

@Waldmensch, du schreibst

Zitat von: Waldmensch am 27 März 2015, 06:18:16
Der Banana ist ein Banana Pro mit WLAN on Board

und

Zitat von: Waldmensch am 27 März 2015, 13:32:36
Ich habe exakt das image, was du verlinkt hast.

Da kann was nicht stimmen  ;D

Ich habe den Banana Pi (nicht Pro!) und hatte in meinem Beitrag auch das Image für den Banana Pi verlinkt.

Das Image für den BPi Pro liegt unter Raspbian For BananaPro v1412 (http://www.lemaker.org/bananapro/141-271/raspbian_for_bananapro.html), das Image für den BPi unter Lemaker Raspian for BananaPi v1412 (http://www.lemaker.org/resources/9-81/raspbian_for_bananapi.html).

Beide IMages basieren zwar auf der gleichen Version, exakt das Image in meinem BPi ist deines hoffentlich nicht  :).

Also entweder verwendest du das Pro Image (http://www.lemaker.org/bananapro/141-271/raspbian_for_bananapro.html), das auf der gleichen Version wie meines basiert oder du verwendest wirklich exakt das gleiche wie das von mir verlinkte.
Dann benutzt du allerdings ein BPi Image auf einen BPi Pro - in dem Fall solltest du vielleicht erst mal das richtige Pro Image (http://www.lemaker.org/bananapro/141-271/raspbian_for_bananapro.html) runterladen.

Na ich bin deiner Anleitung gefolgt und da steht unter Eins

Zitat1. Das Debian Wheezy Image 3.4.106 von Igor Pečovnik runterladen und auf eine SD-Karte installieren.

Und das habe ich genau so gemacht. Das Raspbian ist doch was ganz anderes?

Du hast recht, sorry. Hab jetzt selbst das Image verwechselt. Das Image von Igor ist natürlich auch für den Pro...
Ich mach jetzt erst mal Pause...  ;)

Ich habe jetzt das Raspbian für den Pro drauf. Das COC gibt wieder nur einen kurzen "Blitz" beim Reset.

- Beim Raspbian muss man die sunxi tools erst bauen- gemacht.
- Die Datei heißt /boot/script.bin - in script.fex gewandelt

hier der UART Teil (komplette unveränderte fex im Anhang):
[uart_para0]
uart_used = 1
uart_port = 0
uart_type = 2
uart_tx = port:PB22<2><1><default><default>
uart_rx = port:PB23<2><1><default><default>

[uart_para1]
uart_used = 0
uart_port = 1
uart_type = 8
uart_tx = port:PA10<4><1><default><default>
uart_rx = port:PA11<4><1><default><default>
uart_rts = port:PA12<4><1><default><default>
uart_cts = port:PA13<4><1><default><default>
uart_dtr = port:PA14<4><1><default><default>
uart_dsr = port:PA15<4><1><default><default>
uart_dcd = port:PA16<4><1><default><default>
uart_ring = port:PA17<4><1><default><default>

[uart_para2]
uart_used = 1
uart_port = 2
uart_type = 4
uart_tx = port:PI18<3><1><default><default>
uart_rx = port:PI19<3><1><default><default>
uart_rts = port:PI16<3><1><default><default>
uart_cts = port:PI17<3><1><default><default>

[uart_para3]
uart_used = 0
uart_port = 3
uart_type = 2
uart_tx = port:PH00<4><1><default><default>
uart_rx = port:PH01<4><1><default><default>

[uart_para4]
uart_used = 1
uart_port = 4
uart_type = 2
uart_tx = port:PH04<4><1><default><default>
uart_rx = port:PH05<4><1><default><default>

[uart_para5]
uart_used = 0
uart_port = 5
uart_type = 2
uart_tx = port:PH06<4><1><default><default>
uart_rx = port:PH07<4><1><default><default>

[uart_para6]
uart_used = 0
uart_port = 6
uart_type = 2
uart_tx = port:PA12<4><1><default><default>
uart_rx = port:PA13<4><1><default><default>

[uart_para7]
uart_used = 1
uart_port = 7
uart_type = 2
uart_tx = port:PI20<3><1><default><default>
uart_rx = port:PI21<3><1><default><default>



Der [uart_para2] enthält den PI19, also habe ich den deaktiviert. Der PH02 wird von pmu_adaptet genutzt pmu_adpdet = port:PH02<0><default><default><default> wobei ich eher glaube, dass das adapter heißen soll. Ich trau mich aber auch nicht [pmu_para] generell zu deaktivieren.

Also ich bin echt mit meinem Latein am Ende.

Kann es an der COC Firmware liegen, das es auf dem RPI läuft, auf dem BPI aber nicht? Gabs da nochmal Änderungen auf COC Seite? Habe meine alte coc.hex gefunden, die auf dem COC ist, die ist vom 18.1.2014

Halleluja!!!!!

Neue, aktuelle Firmware auf den COC geflasht (mit dem RPI an dem der COC lief). COC wieder auf den BananaPro gesteckt, Reset script gestartet -> Er blitzt kurz und fängt an zu blinken  :o. Screen aufgerufen, Mist, ist gar nicht installiert. Draufgetüdelt und mit  screen /dev/ttyS2 38400 gestartet. Großes "V" + Return - voila: V 1.63 CSM868

Also, bei wem ein etwas älterer COC nicht will - unbedingt mal die neueste Firmware draufmachen: http://sourceforge.net/p/culfw/code/HEAD/tree/trunk/culfw/Devices/COC/

Zitat von: Waldmensch am 28 März 2015, 22:02:57
Halleluja!!!!!
Großes "V" + Return - voila: V 1.63 CSM868

Also, bei wem ein etwas älterer COC nicht will - unbedingt mal die neueste Firmware draufmachen: http://sourceforge.net/p/culfw/code/HEAD/tree/trunk/culfw/Devices/COC/

Super, na das ist doch ein Erfolg. :D

Weißt du zufällig, welche COC Firmware vorher bei dir drauf war?

Ich kann von mir bestätigen, dass auch die V 1.62 CSM868 mit dem BPi läuft.

Ich habe mal die alte FW mit einem Hex Editor angeschaut, da findet man aber nix, was auf einen Versionsstring schließen läßt. Ich kann nur sagen, das sie am 18.1.2014 auf meiner Platte gelandet ist. Kann sie auch mal mit anhängen, wenn Du forschen willst.

Wenn dein Filedatum stimmt hattest du laut Repository History (http://sourceforge.net/p/culfw/code/499/log/?path=/trunk/culfw/Devices/COC) maximal eine v1.57 drauf, die stammt vom 2013-07-02.

Die nächste Änderung (aber immer noch 1.57) gab es erst am 2014-02-15 und die 1.58 kam am 2014-03-14 raus.

Also kann man davon ausgehen das eine COC Firmware <=1.57 nicht mit dem BPi läuft.

Ich habe die ALTE Firmware aus Januar 2014 hier mal angehangen, falls jemand Lust auf die Gegenprobe hat. Die angehängte Firmware funktionierte NICHT auf meinem BananaPro. Wer die testweise flasht, sollte einen RaspberryPi in der Hinterhand haben, um notfalls zurückzuflashen.

Zusammenfassend muß ich aber sagen, das zwischen einem RaspBerry (erste Version) und dem BananaPro schon Welten in der Performance liegen. FHEM Webinterface läuft wesentlich flüssiger.

Hallo an alle BPi Mitstreiter  ;) ;D

Erst mal vielen, vielen Dank an Curzon ! ... Dank Dir und Deiner Anleitung hat die tagelange Grübelei
ein Ende und die bei Google sind jetzt sicher wegen der abnehmenden Trafikzahlen etwas erleichtert.   ;D

Mein BPi läuft nun auch mit busware COC und mein RPi gönnt sich eine Verschnaufpause ob der vielen
Daten in den LOG-Files von FHEM.  ;)

Übrigens Waldmensch ... im Gegensatz zu Dir hatte ich wohl Glück im Unglück. Als ich meinen
COC vom RPi getrennt hatte hat sich irgendwie die FW verabschiedet ... respektive ich habe den COC
nur mit Neuinstallation der FW wieder zum leben erwecken können! Hatte natürlich dann auch gleich die
neueste genommen -> V 1.63 CSM868 ... wat n zufall  ::)

Also noch mal großartige Arbeit Curzon !!! Ich denke diese Anleitung gehört ins FHEM-WIKI !!!

Gruß TeleDet

Auf jeden Fall sollte das ins wiki!

Mal noch in die Runde gefragt: Das COC hat ja eine RTC und OneWire an Bord. Muß man da noch was aktivieren bzw. konfigurieren? Zumindest die RTC sollte schon genutzt werden, wenn sie schon dranhängt.

Edit: Habe rausgefunden, das zwar i2c im Kernel integriert ist, der Dallas Treiber failed aber beim modprobe FATAL: Module rtc-ds1307 not found Schade

Zitat von: Waldmensch am 29 März 2015, 23:19:57
Mal noch in die Runde gefragt: Das COC hat ja eine RTC und OneWire an Bord. Muß man da noch was aktivieren bzw. konfigurieren? Zumindest die RTC sollte schon genutzt werden, wenn sie schon dranhängt.

Edit: Habe rausgefunden, das zwar i2c im Kernel integriert ist, der Dallas Treiber failed aber beim modprobe FATAL: Module rtc-ds1307 not found Schade

Das Module brauchst du nicht laden, die RTC kannst du über I2C ansprechen.

Dazu musst du allerdings zuvor in der .Fex die I2C Schnittstelle zum COC aktiviert haben, die beiden Pins liegen beim COC auf PB21 (SDA) und PB20 (SDC):

COC	GPIO Leiste	RaspberryPi	BananaPI (Angabe in der .Fex)
I2C Data (SDA)	PIN3	GPIO 2	PB21
I2C Clk (SCL)	PIN5	GPIO 3	PB20

Edit: Eine Übersicht der BPi Steckplätze findest du unter Banana Pi - Pin definition (http://wiki.lemaker.org/Pin_definition).
Die Beschreibung der .FEX Datei findest du unter linux sunxi - Fex Guide (http://linux-sunxi.org/Fex_Guide)

Also wie gehabt  .FEX erstellen, editieren (z.B. I²C #2 aktivieren) und Fex-Datei zurückwandeln ins BIN-Format:

# sudo bin2fex /boot/bananapi.bin /boot/bananapi.fex
# sudo nano /boot/bananapi.fex

I²C Schnittstelle 2 aktivieren:

[twi2_para]
twi2_used = 1
twi2_scl = port:PB20<2><default><default><default>
twi2_sda = port:PB21<2><default><default><default>


Anschliessend:

sudo fex2bin /boot/bananapi.fex /boot/bananapi.bin


Nach einem Neustart des BPi die I2C Schnittstelle 2 unter /sys/class/i2c-adapter/i2c-2/ im System vorhanden sein. Noch ein Test, ob die Treiber auch geladen sind:

# sudo cat /sys/class/i2c-adapter/i2c-2/device/uevent
DRIVER=sunxi-i2c
MODALIAS=platform:sunxi-i2c


Nun aktivierst du die RTC auf dem COC mit:

# echo ds1307 0x68 | sudo tee /sys/class/i2c-adapter/i2c-2/new_device
ds1307 0x68


Jetzt prüfen wir, ob das geklappt hat:

1. Unter /sys/class/i2c-adapter/i2c-2/ sollte ein die COC RTC unter 2-0068 auftauchen und der passende Treiber aktiviert sein:

# sudo cat /sys/class/i2c-adapter/i2c-2/2-0068/modalias
i2c:ds1307


2. sudo ls /dev/rtc* sollte zwei RTCs ausgeben, die interne /dev/rtc0 und die externe vom COC /dev/rtc1

Jetzt haben wir's fast. Die COC RTC läßt sich zum Test auslesen:

# sudo hwclock --rtc=/dev/rtc1 -r
Fr 07 Jan 2000 04:03:03 CET  -0.461191 seconds


Setzen läßt sich die COC RTC nun auch mit hwclock.

BPi Systemzeit in COC RTC schreiben:

sudo hwclock --rtc=/dev/rtc1 --systohc

Beliebige Systemzeit in COC RTC schreiben:

sudo hwclock --rtc=/dev/rtc1 --set --date="2015-03-30 11:38:00"

Systemzeit nach COC RTC stellen:

sudo hwclock --rtc=/dev/rtc1 --hctosys

Mehr dazu liefert man hwclock.


Wenn man nun die COC RTC als Uhr verwenden will, ändert man das permanent in zwei Dateien:

1. Ändere /etc/rc.local und füge die Zeilen zum aktivieren der COC RTC hinzu:

echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-2/new_device

2. Ändere in /etc/init.d/hwclock.sh die Zeile

HCTOSYS_DEVICE=rtc1

,um die COC RTC zu verwenden.

Also bis zum device komme, dann wird aber nur eins angezeigt:

root@lemaker ~ > cat /sys/class/i2c-adapter/i2c-2/device/uevent
DRIVER=sunxi-i2c
MODALIAS=platform:sunxi-i2c
root@lemaker ~ > cat /sys/class/i2c-adapter/i2c-2/2-0068/modalias
cat: /sys/class/i2c-adapter/i2c-2/2-0068/modalias: No such file or directory
root@lemaker ~ > echo ds1307 0x68 | sudo tee /sys/class/i2c-adapter/i2c-2/new_device
ds1307 0x68
root@lemaker ~ > cat /sys/class/i2c-adapter/i2c-2/2-0068/modalias
i2c:ds1307
root@lemaker ~ > ls /dev/rtc*
/dev/rtc0
root@lemaker ~ >

Die Fex war schon richtig bei Überprüfung. Image ist immernoch das Raspbian für den BPro

Dazu fallen mir spntan zwei Fragen ein, da die Uhr auf dem COC sich wohl nicht aktivieren läßt:

Welche der beiden aktuellen Firmware 1.63 hast du auf den COC geflashed? Die full oder radio only?
Ich habe meine COC Firmware durch clonen des Repository als Quelltext geladen, auf dem BPi übersetzt und die full version geflashed.

Was gibt den i2cdetect -y 2 aus?

Ich habe natürlich die aktuelle "full" geflasht

root@lemaker ~ > i2cdetect -y 2
-bash: i2cdetect: command not found

ic2-tools installiert, danach:
root@lemaker ~ > i2cdetect -y 2
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- 18 -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 51 52 53 54 55 56 57 -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
root@lemaker ~ >

Kann es sein, das das Raspbian die originale RTC auf dem BPI Board gar nicht installiert und die vom COC die einzige ist und somit auf /dev/rtc0 ?

Zitat von: Waldmensch am 31 März 2015, 09:29:00
Kann es sein, das das Raspbian die originale RTC auf dem BPI Board gar nicht installiert und die vom COC die einzige ist und somit auf /dev/rtc0 ?

Das verrät dir dmesg (hier bei mir nach einem reboot des BPi):
# dmesg -T | grep "rtc"
[Mo Mär 30 15:48:31 2015] sunxi-rtc sunxi-rtc: Warning: RTC time is wrong!
[Mo Mär 30 15:48:31 2015] sunxi-rtc sunxi-rtc: rtc core: registered rtc as rtc0
[Mo Mär 30 15:48:33 2015] sunxi-rtc sunxi-rtc: setting system clock to 2010-01-01 00:00:00 UTC (1262304000)
[Mo Mär 30 15:49:22 2015] rtc-ds1307 2-0068: rtc core: registered ds1307 as rtc1
[Mo Mär 30 15:49:22 2015] rtc-ds1307 2-0068: 56 bytes nvram


sunxi-rtc ist die interne BPi, die ist nach einem Reset nicht gestellt (da der BPi keine Batterie hat), deshalb die Warnung. Welche rtc benutzt wird siehst du ja hinter "registred ... as"

Warum sollte es bei mir auch klappen :(

root@lemaker ~ > dmesg -T | grep "rtc"
[Tue Mar 31 20:08:24 2015] sunxi-rtc sunxi-rtc: rtc core: registered rtc as rtc0
[Tue Mar 31 20:08:36 2015] sunxi-rtc sunxi-rtc: setting system clock to 2015-03-31 18:08:36 UTC (1427825316)


Ich glaube mein Problem ist der fehlende Treiber im Raspian
root@lemaker ~ > modprobe rtc-ds1307
FATAL: Module rtc-ds1307 not found.


Zitat von: Waldmensch am 31 März 2015, 23:24:48
Ich glaube mein Problem ist der fehlende Treiber im Raspian

Dann bleibt nur die harte Tour  ;D

Howto: Build and install a modified linux kernel directly on Bananian (http://forum.lemaker.org/2657-1-3-howto_build_and_install_a_modified_linux_kernel_directly_on_bananian.html)

Du musst vor dem Compile folgende Option in linux-bananapi/arch/arm/configs/sun7i_defconfig hinzufügen:

CONFIG_RTC_DRV_DS1307=m

und dann den Kernel und Module übersetzen (Dauer um die 3h).

Danach sollte ein

# modprobe rtc-ds1307
# echo ds1307 0x68 | sudo tee /sys/class/i2c-adapter/i2c-2/new_device


funktionieren.

Mit Bananian bringst Du jetzt nach Raspbian und der von Igor die Dritte Distro ins Spiel. Welche benutzt Du denn aktuell? Bei Dir scheint es ja drin zu sein. Vielleicht ist es einfacher gleich die zu nehmen. FHEM liegt sowieso auf einem Stick bei mir.

Wie in meinem ursprünglichen Post (http://forum.fhem.de/index.php/topic,29102.msg278082.html#msg278082) beschrieben, verwende ich immer noch genau das Debian Wheezy Image 3.4.106 (http://mirror.igorpecovnik.com/Bananapi_Debian_2.4_wheezy_3.4.106.zip) mit der boot.cmd und Fex die hier anhängt.

Ich hatte mich ein einziges mal in meinem Post #53 (http://forum.fhem.de/index.php/topic,29102.msg279062.html#msg279062) vertan, aber auch entschuldigt  :D - wenn dich das verwirrt wäre Urlaub angesagt.
Etwas mehr Kampfgeist bitte ;) - mein Link oben sollte doch nur Helfen es mal mit einem Image zu probieren, für das es eine Anleitung zum Selbsterstellen gibt und man das fehlende Modul compilieren kann.

Zitat von: cerberus am 14 November 2014, 09:31:26
Hallo, ich wollte kurz meinen Homeserver auf Basis eines Banana-PI vorstellen.

Hallo,

klasse, könntest du was zu dem Gehäuse sagen? Maße?
und wie bringt man Ihn dazu die Logs auf den OTG Stick zu schreiben?

Danke

Ich habe nun auch endlich meinen BananaPi am laufen. Ich habe ihn gewählt, weil er 4 serielle Schnittstellen bietet. Somit kann ich HMUART, CUL868 und CUL433 direkt betreiben. Weiterhin habe ich 3 DS2482-100 1Wire Busmaster am i2c Bus dran. Damit kann ich jetzt ganz auf Geräte am USB verzichten. Das ganze steckt in einem alten Routergehäuse. Damit hat man einen sehr flexiblen FHEM-Server.

Zitat von: papa am 13 Januar 2017, 23:10:08
Ich habe ihn gewählt, weil er 4 serielle Schnittstellen bietet. Somit kann ich HMUART, CUL868 und CUL433 direkt betreiben. .........
Damit hat man einen sehr flexiblen FHEM-Server.

Genau dafür ist er Spitze, SATA hast Du vergessen mit aufzuzählen!!! :)
Obwohl nur Dualcore, völlig ausreichend!!!
Bei mir läuft, läuft,..... das Teil. Ohne Experimente wahrscheinlich mit einer uptime von irgendwo 1 Jahr. :)
Zusätzlich habe ich darauf noch einen Baikalserver.

CK