Hallo zusammen,
ich versuche gerade, einen SCC auf einem RPi3 zum laufen zu bekommen. Scheinbar gibt es dabei ein größeres Problem.
Das Flashen ist auf dem RPi3 schon gescheitert. Dabei schien der Flashprogtrammer keine Verbindung zu bekommen.
Das habe ich umschifft, indem ich den SCC auf einem alten RPi geflasht hab.
Auf dem RPi3 bekommt aber offenbar auch FHEM keine Verbindung:
2016.03.06 19:10:54 3: SCC device opened
2016.03.06 19:11:03 1: Cannot init /dev/ttyAMA0, ignoring it (SCC)
Also habe ich die Chipkarte und das SCC auf einen RPI2 gesteckt. Der SCC blinkt und FHEM meldet erfolgreiche Initialisierung.
So falsch dann die Konfiguration also nicht sein.
Scheinbar ist das ttyAMA0-Device im RPi3 anderweitig belegt. Im dmesg steht eine Meldung, das Bluetooth den UART nutzt.
Ist das die Ursache und kann man Bluetooth (wird ohnehin nicht benötigt) abklemmen?
LG
Shardan
Ein paar Ergänzungen dazu:
Mittlerweile habe ich den Bluetooth-Daemon disabled (systemctl disable bluetooth), des weiteren ein "rfkill block bbluetooth" in der rc.local eingebaut, ebenso ein "initPower=false in der bluetooth- main.cfg.
Alles ohne Erfolg
Zwischendurch kam beim Reboot eine Meldung, dass Bluetooth nicht auf die ttyAMA0 zugreifen kann.
Scheinbar kommen sich SCC und Bluetooth hier gewaltig ins Gehege.
Ich zitiere mal aus einem englischen Beitrag:
Raspberry Pi 3 complications
It seems that changes made for the Raspberry Pi 3 currently prevent serial access over pins GPIO14 and GPIO15, which have worked on all other RPi cards. Fortunately, someone has written a overlay which resolves the issue. There are three steps:
1. Obtain the file pi3-disable-bt-overlay.dtb from this location (https://drive.google.com/file/d/0B8VsfKAD4-NOX0hMZjM1Sm1nU0k/view?pref=2&pli=1).
2. Copy the file to /boot/overlays:
$ sudo cp pi3-disable-bt-overlay.dtb /boot/overlays
3. Add two lines at the end of /boot/config.txt
# Allow the normal UART pins to work
dtoverlay=pi3-disable-bt-overlay
Then reboot your Raspberry Pi.
Suuuper... :)
Vielen Dank für die Hilfe, das funktioniert prompt!
Dann gehts auch mit dem Raspi3
Die serielle Schnittstelle des RPi3 heißt eigentlich /dev/ttyS0.
Auf RPi1 und 2 hieß sie noch /dev/ttyAMA0.
Siehe Raspberry Pi 3 UART baud rate workaround (https://frillip.com/raspberry-pi-3-uart-baud-rate-workaround/)
hm... ist das ttyAMA0 dann nur noch ein Link? Es funktioniert damit recht gut.
guck doch selbst nach ;)
cd /dev/
ls -la
smylinks sehen dann so aus:
root -> mmcblk0p2
Danke, ihr habt mir mit diesem Tipp sehr geholfen.
Endlich funktioniert mein Serial port am RPi3 mit dem Gertboard und meine Sensoren brauchen sich nicht mit Blinkzeichen mit mir verständigen.
:-)
Blöde Anfängerfrage: obtain the file.... Ok. Aber wie bekomme ich den dann vom Apache auf den Raspi?
In aktuellen raspbian-Versionen ist das pi3-disable-bt-overlay.dtb automatisch enthalten.
Achtung: nach dem letzten Update ist das Overlay umbenannt worden!
Es heißt jetzt pi3-disable-bt (ohne das "-overlay" am ende).
Einfügen in die /boot/config.txt:
dtoverlay=pi3-disable-bt
enable_uart=1
Dann geht es auch nach dem letzten Update von Jessie wieder....
Das Spiel um die seriellen Schnittstellen wird immer verwirrender.
Mit dem Raspbian Jessie (https://www.raspberrypi.org/downloads/raspbian/) Release Date 2016-05-27 hat sich auch der Symlink geändert.
pi@raspberrypi:~ $ ls -l /dev/serial*
lrwxrwxrwx 1 root root 5 Jul 10 09:30 /dev/serial0 -> ttyS0
lrwxrwxrwx 1 root root 7 Jul 10 09:30 /dev/serial1 -> ttyAMA0
/dev/serial0 ist am expansion Header verfügbar:
define <name> CUL /dev/serial0@38400 <FHTID>
/dev/serial1 ist für Bluetooth reserviert.
Ok, genau vor dem Problem stand ich heute auch; vielen Dank für die Aufklärung!!!
Noch ein Hinweis: bei der pi3-disable-bt hat sich nicht nur der Name geändert, sondern auch die Extension, wobei ich als DAU natürlich nicht sagen kann, ob das relevant ist.
Zum Thema:
Was mich jetzt immer noch verwirrt ist die Frage, ob der "Rest" der SCC- Einbindung so geblieben ist, also das Entfernen der ersten "console..." in der /boot/cmdline.txt ? Das hatte ich vorab schon gemacht, nach dem Hint hier aber nicht wieder rückgängig gemacht. Relevant?
@Lucutus:
Nach dem Einbauen der pi3-disable-bt funktioniert es ja nun, aber jetzt ist natürlich de BT deaktiviert (was einem beim Neustart deutlich rot anschreit auf der Konsole), den man ja eigentlich gut für Presenz o.ä. gebrauchen könnte...
Kann man nicht beides haben? Wenn ja, wie? Ich nix plan... ::)
Das pi3-disable-bt Overlay verwende ich erst gar nicht. Stattdessen sieht der Eintrag in /boot/config.txt am Ende wie folgt aus:
enable_uart=0
enable_uart=1
force_turbo=1
... und beide sind aktiviert:
ls -l /dev/serial*
lrwxrwxrwx 1 root root 5 Aug 2 21:30 /dev/serial0 -> ttyS0
lrwxrwxrwx 1 root root 7 Aug 2 21:30 /dev/serial1 -> ttyAMA0
... ich weiß zwar nicht, was genau damit bewirkt wird, aber bei mir klappt das so nicht ...
Mit Overlay:
BT ist deaktiviert (meckert beim Booten),
LAN funktioniert (nur lan0 in networks eingetragen),
WLAN funktioniert nicht wirklich (nur wlan0 in networks eingetragen und natürlich der Zugang in wpa-blablub),
SCC1 & SCC2 funktionieren
Mit Deinem Trick:
BT läuft,
LAN funktioniert (nur lan0 in networks eingetragen),
WLAN funktioniert nicht wirklich (nur wlan0 in networks eingetragen und natürlich der Zugang in wpa-blablub),
SCC1 & SCC2 funktionieren nicht.
Eigentlich wollte ich den PI3 als Headless irgendwo "verstecken", aber da in allen Fällen das WLAN nur gelegentlich funktioniert, kann ich das knicken...
Korrekt in der FB7390 eingebucht, alle Rechte, keine Verbindung via HTTP oder SSH, wenn doch, dann nur kurz.
Ping vom PI an heise.de funktioniert immer, ping auf lokale Systeme zeigt gleiches Verhalten wie in die andere Richtung... läuft ne Weile, hält mehrere Minuten an, läft mal weiter, mal nicht... vollkommen unkalkulierbar...
Nachtrag: Das parallel auf der PI-Konsole laufende Ping auf mein NAS stoppt genau in dem Moment, wo ich versuche, vom Client per HTTP oder SSH auf den PI zuzugreifen... reproduzierbar...
mir gibt das Busware SCC auf Raspberry Pi 3 mit Jessie LITE weiter Rätsel auf. Folgendes Verhalten habe ich, dass ich seit gut 2 Woche nicht in Griff bekomme, trotz Befolgung aller tipps in diesem Forum:
1) das /dev/ttyS0 gibt es bei mir (habe bt in /boot/config.txt deaktiviert) und es ist jetzt unter /dev gelistet
dtoverlay=pi3-disable-bt
enable_uart=0
2) das licht auf dem SCC blinkt wenn ich
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
direkt aufrufe oder in /etc/init.d/fhem aufnehme
3) folgende Initialisierung in der fhem.cfg
define CULINTERTECHNO CUL /dev/ttyS0@38400 1234
bringt folgende Fehlermeldung im fhem log
016.08.21 00:32:01 3: Opening CULINTERTECHNO device /dev/ttyS0
2016.08.21 00:32:01 1: PERL WARNING: can't getattr: Input/output error at ./FHEM/DevIo.pm line 383.
2016.08.21 00:32:01 3: Can't open /dev/ttyS0: Input/output error
4) wenn ich das FHEM Service stoppe und auf SCC mit minicom zugreifen versuche mit folgendem Befehl
minicom -b 38400 -o -D /dev/ttyS0
V ENTER
sehe ich folgenden output in der minicom, V + ENTER zeigt KEINE Reaktion (egal ob V Klein oder Groß). mit "screen" habe ich auch keine Verbindung zum SCC geschafft
Welcome to minicom 2.7
OPTIONS: I18n
Compiled on Jan 12 2014, 05:42:53.
Port /dev/ttyS0, 00:05:33
Press CTRL-A Z for help on special keys
STRG + A zeigt
CTRL-A Z for help | 38400 8N1 | NOR | Minicom 2.7 | VT102 | Offline | ttyS0
mir sind jetzt wirklich die ideen ausgegangen, hat noch irgendjemand tipps was ich tun kann?
viele herzlichen Dank
Wolfgang
... versuch es mal mit ttyAMA0 an Stelle von ttyS0 ...
ttyAMA0 ist in /dev/ gar nicht (mehr) vorhanden, nach dem deaktivieren von bt mittels overlay in /boot/config.txt wie oben beschrieben, dadurch existiert dann aber /dev/ttyS0
Busware verweist ja darauf, dass am RP3 ttyS0 verwendet wird: http://busware.de/tiki-index.php?page=SCC_Installation
Zitat
for a RPi 3:
define SCC CUL /dev/ttyS0@38400 1234
Sent from my iPhone using Tapatalk
Zitat von: wolfma am 21 August 2016, 11:13:20ttyAMA0 ist in /dev/ gar nicht (mehr) vorhanden, nach dem deaktivieren von bt mittels overlay in /boot/config.txt wie oben beschrieben, dadurch existiert dann aber /dev/ttyS0
Obwohl ich auch das Overlay benutzt habe, läuft das bei mir mit AMA0; hast du es denn ausprobiert, oder ist das Geschriebene nur eine Vermutung?
Hi,
leider keine Vermutung. Ich bin kein experte, aber soweit mein Verständnis reicht, habe ich es ausprobiert:
1) ls in /dev/ listed kein ttyAMA0
hier ein screenshot des outputs: http://bit.ly/2bGjMfC
2) minicom auf /dev/ttyAMA0 landet sofort wieder in der commandline
3) in fhem gehts auch nicht
init mit
# CUL 433 MHZ
# define CULINTERTECHNO CUL /dev/ttyS0@38400 1234
define CULINTERTECHNO CUL /dev/ttyAMA0@38400 1234
response im fhem log
2016.08.21 13:41:12 3: Opening CULINTERTECHNO device /dev/ttyAMA0
2016.08.21 13:41:12 3: Can't open /dev/ttyAMA0: No such file or directory
2016.08.21 13:41:13 1: Including ./log/fhem.save
2016.08.21 13:41:15 1: HMLAN_Parse: HMLAN1 new condition ok
... ok, dann ist bei meinem PI3 wohl was anders, denn da lief es bis zur gestrigen Umstellung auf ser2net (wegen FHEM- Umzug auf XEON) mit AMA0 vollkommen problemlos ... War ja auch nur so eine Idee eines DAU ...
hm.. danke trotzdem.. vielleicht noch eine grundlegende frage wo ich mir nicht sicher bin und das deshalb noch Quelle des Fehlers sein kann: welche FHEM Version benötige ich, reicht die aktuelle stable 5.7 + update im frontend, oder brauche ich die nightly? werde aus dem Satz
ZitatSCC itself and stacking support currently requires latest FHEM-svn revision 5274+ !
nicht schlau.. kann mit der SVN Revisionsnummer leider (noch) nichts anfangen.. ;)
... mach dir nichts draus; ich auch nicht ;)
Aber die SCC liefen bei mir von Anfang an, also über ein Jahr, erst auf einem 2+, dann auf einem 3+, nun auf einem alten 2 (mit 2xUSB) via Ser2Net. Demnach passt das seit min. einem Jahr mit den SCC...
Seltsam ist, das das V bei der minicom auf /dev/ttyS0 keine Versionsnummer zurückgibt, das klappte bei allen anderen in diversen Foreneinträgen. Kann es sein, das auf meiner SCC keine Firmware drauf ist, oder würde dann die LED auch nicht blinken?
Sent from my iPhone using Tapatalk
... doch, da sollte eine culfw drauf sein (ich hatte allerdings schnell die aculfw drauf gemacht), wenn du das Teil neu von Busware erworben hast; steht da zumindest so ...
Hab ich auch gelesen, aber kann ichs überprüfen, wenn der minicom versionstest nicht klappt?
Soll ich versuchen die firmware zu überschreiben um sicherzugehen?
Sent from my iPhone using Tapatalk
... uhhh, frag mich nicht: ich DAU das ;) Bin froh das beim Flashen der acul nichts schief gegangen ist ;)
Überprüfe mal wie die permission & group gesetzt sind, und probiere es danach nochmal aus.
ls -l /dev/ttyAMA0 /dev/ttyS0
crw-rw-rw- 1 root dialout 204, 64 Sep 2 16:55 /dev/ttyAMA0
crw-rw-rw- 1 root dialout 4, 64 Sep 2 16:42 /dev/ttyS0
Und welche Rechte hat FHEM?
id fhem
groups fhem
Der user fhem hat die primäre group dialout
Ich checke das heute abend und schicke euch die outputs, gerade keinen zugriff, aber danke schon mal für die inputs
Sent from my iPhone using Tapatalk
hier die gewünschten outputs
pi@raspberrypi:~ $ ls -l /dev/ttyAMA0 /dev/ttyS0
ls: cannot access /dev/ttyAMA0: No such file or directory
crw-rw---- 1 root dialout 4, 64 Aug 21 14:18 /dev/ttyS0
pi@raspberrypi:~ $ id fhem
uid=999(fhem) gid=20(dialout) groups=20(dialout)
pi@raspberrypi:~ $ groups fhem
fhem : dialout
ich habe jetzt noch folgendes probiert
sudo chmod 666 /dev/ttyS0
dann gibt
pi@raspberrypi:~ $ ls -l /dev/ttyAMA0 /dev/ttyS0
ls: cannot access /dev/ttyAMA0: No such file or directory
crw-rw-rw- 1 root dialout 4, 64 Aug 21 14:23 /dev/ttyS0
FHEM liefert bei restart weiterhin die selbe Fehlermeldung
2016.09.05 21:36:10 3: Opening CULINTERTECHNO device /dev/ttyS0
2016.09.05 21:36:10 1: PERL WARNING: can't getattr: Input/output error at ./FHEM/DevIo.pm line 383.
2016.09.05 21:36:10 3: Can't open /dev/ttyS0: Input/output error
2016.09.05 21:36:11 1: Including ./log/fhem.save
die minicom gibt bei V nichts zurück
SCC & CULINTERTECHNO passen nicht zusammen .....
define SCC CUL /dev/ttyAMA0@38400 1234
attr SCC group CUL
attr SCC hmId F95601
attr SCC model CUL
attr SCC rfmode HomeMatic
attr SCC room Technik
was mich wunder ist, dass das "V" bei der minicom keine Info ausgibt: Sprechen wir wirklich von busware SCC V2.0 ?
Denn dieses Module kommt mit micro code.
Also erst mal "minicom" lösen, was bedeuten kann das board zu flashen ... http://busware.de/tiki-index.php?page=SCC_Installation (http://busware.de/tiki-index.php?page=SCC_Installation)
--- Markus
mein Verständnis war, dass "SCC" der frei wählbare Name ist und daher habe ich das zur besseren Übersicht durch "CULINTERTECHNO" ersetzt. Habe aber jetzt wie angeregt in der FHEM Config wieder SCC verwendet, die Initialisierung sieht jetzt so aus:
# CUL 433 MHZ
define SCC CUL /dev/ttyS0@38400 1234
das ändert aber leider nichts an der response im FHEM log, die sieht weiterhin so aus:
2016.09.06 19:58:23 3: Opening SCC device /dev/ttyS0
2016.09.06 19:58:23 1: PERL WARNING: can't getattr: Input/output error at ./FHEM/DevIo.pm line 383.
2016.09.06 19:58:23 3: Can't open /dev/ttyS0: Input/output error
zur Frage ob es sich wirklich um SCC 2.0 von busware handelt, hier die Informationen von der Busware Rechnung, ausgestellt am 06.08.2016
1 x Stackable CC1101 transceiver board for Raspberry
- Frequency: 433MHz (IT, etc)
- Antenna: RP-SMA +3dBi 5cm (+16,80EUR)
- Firmware: none
- Mount kit: inclusive (+4,21EUR)
- Shield: none
am Modul selbst steht auf der blauen Platine aufgedruckt
Busware SCC V2.0
bleibt nur mehr der Tipp das board zu flashen, aber da komme ich zurück zu meiner vorhergehenden Frage: wie geht das, kann mit der Anleitung auf der busware seite leider nichts anfangen:
The makefile inside Device/SCC directory is prepared to flash new firmware by running:
make program
es gibt kein /SCC innerhalb von /dev/ttyS0 oder verstehe ich das komplett falsch..
danke,
lg
... schon witzig: Auf der Rechnung steht "keine", auf dem SCC die Revisionsnummer? Da würde ich ja mal stumpf bei BusWare nachfragen, auch wenn ich wenig Hoffnung habe, das von dort eine (sinnvolle) Antwort kommt (aus eigener Erfahrung) ...
Ansonsten gibt es zwei interessante Seiten, auf denen das m.E. gut erklärt ist:
http://www.fhemwiki.de/wiki/CUL_am_Raspberry_Pi_flashen
http://www.computerhilfen.de/info/fhem-cul-flashen-und-neue-firmware-installieren.html
Das bezieht sich zwar auf den CUL, aber der Vorgang ist identisch zum SCC (Taste) und und dem ganzen drum herum. Wer eine StepByStep für den SCC hat, kann ja auch mal einen Link bereit stellen ...
danke, das versuche ich, aber jetzt sehe ich gerade was anderes: auf der Rechnung die ich oben kopiert habe steht "Firmware: non" - das könnte es erklären..
... das meinte ich ja: Rechnung = none / auf dem SCC die FW- Rev ... Passt ja nicht zusammen ...
so... neverending story. Ich habe mich mittlerweile damit abgefunden, dass Busware wohl meine SCC ohne Firmware ausgeliefert hat, darum habe ich mich jetzt ans flashen gemacht - leider auch das nicht problemlos. Ich habe folgende Schritte gemacht:
sudo apt-get install dfu-programmer
sudo apt-get install build-essential
sudo apt-get install avrdude
cd /home/pi
wget http://culfw.de/culfw-1.66.tar.gz
gunzip culfw-1.66.tar.gz
tar xfv culfw-1.66.tar
cd culfw-1.66/
cd Devices/
cd SCC
-- KNOPF AM SCC MODUL GEDRÜCKT GEHALTEN UND
sudo make program
es kommt folgender output
calling radio frontends bootloader ...
KEEP THE MICRO BUTTON PRESSED AT DESIRED EXTENSION
if test ! -d /sys/class/gpio/gpio17; then echo 17 > /sys/class/gpio/export; fi
echo out > /sys/class/gpio/gpio17/direction
echo 0 > /sys/class/gpio/gpio17/value
if test ! -d /sys/class/gpio/gpio18; then echo 18 > /sys/class/gpio/export; fi
echo out > /sys/class/gpio/gpio18/direction
echo 0 > /sys/class/gpio/gpio18/value
echo 1 > /sys/class/gpio/gpio17/value
sleep 1
echo 1 > /sys/class/gpio/gpio18/value
echo in > /sys/class/gpio/gpio18/direction
echo 18 > /sys/class/gpio/unexport
avrdude -p atmega1284p -P /dev/ttyAMA0 -c avr109 -b 38400 -V -U flash:w:SCC.hex
avrdude: ser_open(): can't open device "/dev/ttyAMA0": No such file or directory
avrdude done. Thank you.
schnell kombiniert, dass ich ja den Raspberry pi 3, Jesyy habe und mit sudo nano makefile das /dev/ttyAMA0 auf /tty/ttyS0 geändert und sudo make program gleich nochmal mit gedrücktem SCC Knopf gestartet,
es kommt folgender output
calling radio frontends bootloader ...
KEEP THE MICRO BUTTON PRESSED AT DESIRED EXTENSION
if test ! -d /sys/class/gpio/gpio17; then echo 17 > /sys/class/gpio/export; fi
echo out > /sys/class/gpio/gpio17/direction
echo 0 > /sys/class/gpio/gpio17/value
if test ! -d /sys/class/gpio/gpio18; then echo 18 > /sys/class/gpio/export; fi
echo out > /sys/class/gpio/gpio18/direction
echo 0 > /sys/class/gpio/gpio18/value
echo 1 > /sys/class/gpio/gpio17/value
sleep 1
echo 1 > /sys/class/gpio/gpio18/value
echo in > /sys/class/gpio/gpio18/direction
echo 18 > /sys/class/gpio/unexport
avrdude -p atmega1284p -P /dev/ttyS0 -c avr109 -b 38400 -V -U flash:w:SCC.hex
avrdude: ser_open(): can't set attributes for device "/dev/ttyS0": Inappropriate ioctl for device
avrdude done. Thank you.
makefile:231: recipe for target 'program' failed
make: *** [program] Error 1
damit stehe ich leider wieder ratlos an.. wenn ich /dev/ttyS0 mit chmod 666 alle Rechte gebe, ändert das auch nichts, es kommt die selbe Fehlermeldung vom avrdude.
ergänzung, jetzt hab ichs.. in der /boot/config.txt war von einem meiner vielen versuche unabsichtlich enable_uart=0 gesetzt, auf =1 geändert, damit war das flashen erfolgreich,
interessanterweise ist damit zusätzlich zu ttyS0 auch ttyAMA0 aufgetaucht, minicom auf ttyS0 gibt nichts mit V zurück, auf ttAMA0 kommt jetzt endlich die Versionsnummer, in FHEM auch auf ttyAMA0 geändert und wir sind connected!!
herzlichen Dank für den Beistand an alle. Hauptfehler war definitiv, dass die SCC ab Werk nicht geflasht war und mir das nicht bewusst war..
conclusio für Rasperry pi 3 jessie:
1) /boot/config.txt muss folgende 2 zeilen am ende enthalten: dtoverlay=pi3-disable-bt sowie enable_uart=1
2) SCC muss Firmware enthalten (wenn minicom -b 38400 -o -D /dev/ttyAMA0 und minicom -b 38400 -o -D /dev/ttyS0 beim drücken von V keinen Output liefert, fehlt die Firmware, firmware kann mit folgender Befehlsfolge aufgespielt werden:
sudo apt-get install dfu-programmer
sudo apt-get install build-essential
sudo apt-get install avrdude
cd /home/pi
wget http://culfw.de/culfw-1.66.tar.gz
gunzip culfw-1.66.tar.gz
tar xfv culfw-1.66.tar
cd culfw-1.66/
cd Devices/
cd SCC
-- KNOPF AM SCC MODUL GEDRÜCKT GEHALTEN UND
sudo make program
wenn dabei eine fehlermeldung kommt, dass /dev/ttAMA0 nicht exisitiert, mit nano makefile das makefile öffnen und /dev/ttyAMA0 durch /dev/ttyS0 ersetzen und nochmal sudo make program mit gedrücktem knopf starten
Moin,
muss mich hier mal anhängen:
Habe meinen Raspberry Pi 3 mit Jessie gemäß der Anleitung:
https://wiki.fhem.de/wiki/Raspberry_Pi_3:_GPIO-Port_Module_und_Bluetooth
eingestellt, hab es nun nach langem Probieren geschafft, alle 3 SCCs (SCC1: 433Mhz, ohne rfMode, SCC2: 868Mhz, Max, SCC3: 868Mhz, slowRF) neu am RPi3 flashen zu können und auch minicom zeigte nun die Version des untersten SCCs (aculfw 1.66), die andren beiden SCCs sind mit der aktuellsten normalen culfw geflashed worden.
Habe das Ganze nun in Fhem hinzugefügt (s.u), nun erhalte ich die Fehlermeldung:
Zitat2017.02.18 11:11:24 3: Setting SCC1 serial parameters to 38400,8,N,1
2017.02.18 11:11:24 3: SCC1 device opened
2017.02.18 11:11:33 1: Cannot init /dev/ttyAMA0, ignoring it (SCC1)
2017.02.18 11:11:33 2: Switched SCC2 rfmode to MAX
2017.02.18 11:11:33 2: Switched SCC3 rfmode to SlowRF
Okay, dachte ich mir, starte ich mal neu...
Nach einem Neustart tut sich auch bei minicom nichts mehr, keine Versionsnummer, ich kann V drücken wie ich will...
In FHEM dasselbe Ergebnis wie oben.
Meine Konfigurationsdateien:
/boot/cmdline.txtZitat
#dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
/boot/config.txtZitat# For more options and information see
# http://www.raspberrypi.org/documentation/configuration/config-txt.md
# Some settings may impact device functionality. See link above for details
# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1
# uncomment this if your display has a black border of unused pixels visible
# and your display can output without overscan
#disable_overscan=1
# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16
# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720
# uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=1
# uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1
# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2
# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4
# uncomment for composite PAL
#sdtv_mode=2
#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800
# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on
# Uncomment this to enable the lirc-rpi module
#dtoverlay=lirc-rpi
# Additional overlays and parameters are documented /boot/overlays/README
# Enable audio (loads snd_bcm2835)
dtparam=audio=on
enable_uart=1
dtoverlay=pi3-miniuart-bt
enable_uart=1
force_turbo=1
/lib/systemd/system/hciuart.serviceZitat[Unit]
Description=Configure Bluetooth Modems connected by UART
ConditionPathIsDirectory=/proc/device-tree/soc/gpio@7e200000/bt_pins
Before=bluetooth.service
After=dev-serial1.device
[Service]
Type=forking
ExecStart=/usr/bin/hciattach /dev/serial1 bcm43xx 921600 noflow -
[Install]
WantedBy=multi-user.target
fhem.cfg (Ausschnitt)Zitatdefine SCC1 CUL /dev/ttyAMA0@38400 1234
define SCC2 STACKABLE_CC SCC1
attr SCC2 rfmode MAX
define SCC3 STACKABLE_CC SCC2
attr SCC3 rfmode SlowRF
Sieht da jemand einen Fehler?
Moin moin,
Zitat von: szoller am 18 Februar 2017, 11:16:30
Moin,
muss mich hier mal anhängen:
Habe meinen Raspberry Pi 3 mit Jessie gemäß der Anleitung:
https://wiki.fhem.de/wiki/Raspberry_Pi_3:_GPIO-Port_Module_und_Bluetooth
[...]
fhem.cfg (Ausschnitt)
Sieht da jemand einen Fehler?
Was mir nur auffällt beim überfliegen: hast Du für die unterste SCC1 auch ein rfmode-Attribut gesetzt? Das Device ttyAMA0 existiert auch und ist benutzbar? Wo (in welcher Datei) initialisierst Du denn die GPIO-Ports (zB in /etc/init.d/fhem mit dem folgenden Codeblock)?
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/valueHast Du mal versucht, ohne fhem zu starten nach einem Reboot des Pi die SCC manuell aus dem Reset zu holen und dann mit minicom darauf zuzugreifen?
lg, justme
Moin :)
Zitat von: justme75 am 24 Februar 2017, 10:02:06
Was mir nur auffällt beim überfliegen: hast Du für die unterste SCC1 auch ein rfmode-Attribut gesetzt?
Brauche ich das? Dachte bei 433Mhz wäre das nicht nötig (will damit v.a. IT ansprechen)
Zitat von: justme75 am 24 Februar 2017, 10:02:06
Das Device ttyAMA0 existiert auch und ist benutzbar?
Ja, das war vorhanden, bin da gemäß Anleitung vorgegangen...
Zitat von: justme75 am 24 Februar 2017, 10:02:06
Wo (in welcher Datei) initialisierst Du denn die GPIO-Ports (zB in /etc/init.d/fhem mit dem folgenden Codeblock)?
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 war der Knackpunkt. Mir war nicht klar, dass das bei jedem Start des RPi gemacht werden muss. Die Installation des alten RPi 1 ist schon etwas her...
Ist nun in der /etc/init.d/fhem drin und übersteht auch einen Neustart des Systems, klappt nun...
Vielen, viele Dank!